Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Snapshots was allowed to mount as read-write and attempt to write to that snapshot lead a kernel panic #6510

Closed
Low-power opened this issue Aug 15, 2017 · 1 comment · Fixed by #6515

Comments

@Low-power
Copy link
Contributor

Low-power commented Aug 15, 2017

System information

Type Version/Name
Distribution Name Debian GNU/Linux
Distribution Version 9
Linux Kernel 4.9
Architecture amd64
ZFS Version 0.7.1
SPL Version 0.7.1

The console screenshot are [removed link]

Describe the problem you're observing

I was suppressed at first when I discovered I could just mount -o remount,rw a snapshot file system under the .zfs/snapshot/ directory. When I trying to create a file in a rw mounted snapshot, expecting some errors, but the kernel then panics, the panic message is "dirtying snapshot!".

Describe how to reproduce the problem

Create a snapshot;
Browse the snapshot from .zfs/snapshot/ or mount the snapshot directly;
Run a mount -o remount,rw <path> to remount the snapshot file system read-write;
Modify the read-write mounted file system, such as creating new file or truncating exist file.

Include any warning/errors/backtraces from the system logs

[removed link]

zfs-on-linux-snapshot-rw-mount-panic

@loli10K loli10K self-assigned this Aug 15, 2017
@tuxoko
Copy link
Contributor

tuxoko commented Aug 15, 2017

We should add a check in zpl_remount_fs

behlendorf pushed a commit that referenced this issue Aug 17, 2017
It's not enough to preserve/restore MS_RDONLY on the superblock flags
to avoid remounting a snapshot read-write: be explicit about our
intentions to the VFS layer so the readonly bit is updated correctly
in do_remount_sb().

Reviewed-by: Chunwei Chen <tuxoko@gmail.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: loli10K <ezomori.nozomu@gmail.com>
Closes #6510 
Closes #6515
tonyhutter pushed a commit that referenced this issue Aug 22, 2017
It's not enough to preserve/restore MS_RDONLY on the superblock flags
to avoid remounting a snapshot read-write: be explicit about our
intentions to the VFS layer so the readonly bit is updated correctly
in do_remount_sb().

Reviewed-by: Chunwei Chen <tuxoko@gmail.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: loli10K <ezomori.nozomu@gmail.com>
Closes #6510
Closes #6515
Fabian-Gruenbichler pushed a commit to Fabian-Gruenbichler/zfs that referenced this issue Sep 29, 2017
It's not enough to preserve/restore MS_RDONLY on the superblock flags
to avoid remounting a snapshot read-write: be explicit about our
intentions to the VFS layer so the readonly bit is updated correctly
in do_remount_sb().

Reviewed-by: Chunwei Chen <tuxoko@gmail.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: loli10K <ezomori.nozomu@gmail.com>
Closes openzfs#6510
Closes openzfs#6515
FransUrbo pushed a commit to FransUrbo/zfs that referenced this issue Apr 28, 2019
It's not enough to preserve/restore MS_RDONLY on the superblock flags
to avoid remounting a snapshot read-write: be explicit about our
intentions to the VFS layer so the readonly bit is updated correctly
in do_remount_sb().

Reviewed-by: Chunwei Chen <tuxoko@gmail.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: loli10K <ezomori.nozomu@gmail.com>
Closes openzfs#6510 
Closes openzfs#6515
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants