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.

Sign up for GitHub

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

Jump to bottom

OpenZFS 2.2.0 copy_file_range(2) from unencrypted to encrypted panic #15464

Closed
mmatuska opened this issue Oct 30, 2023 · 2 comments
Closed

OpenZFS 2.2.0 copy_file_range(2) from unencrypted to encrypted panic #15464

mmatuska opened this issue Oct 30, 2023 · 2 comments
Labels
Type: Defect Incorrect behavior (e.g. crash, hang)

Comments

@mmatuska
Copy link
Contributor

System information

Type Version/Name
Distribution Name Ubuntu
Distribution Version 23.10
Kernel Version 6.5.0-10-generic
Architecture x86_64
OpenZFS Version 2.2.0 (compiled from source)

Describe the problem you're observing

When copying a file using copy_file_range(2) e.g. using cp(1) from an unencrypted dataset to an encrypted dataset on the same pool, the target file is not readable and the process hangs. The pool reports a corrupted file. The same problem happens on FreeBSD, too.

Describe how to reproduce the problem

Create an encrypted dataset and copy a file from an unencrypted dataset on the same pool using cp(1).
When you copy the same file with rsync(1), it is copied correctly.

Include any warning/errors/backtraces from the system logs

[ 9343.915334] PANIC: unencrypted block in encrypted object set 35489
[ 9343.915343] Showing stack for process 11163
[ 9343.915348] CPU: 12 PID: 11163 Comm: cat Tainted: P           OE      6.5.0-10-generic #10-Ubuntu
[ 9343.915353] Hardware name: LENOVO 21K9000CGE/21K9000CGE, BIOS R2FET31W (1.11 ) 08/03/2023
[ 9343.915356] Call Trace:
[ 9343.915359]  <TASK>
[ 9343.915364]  dump_stack_lvl+0x48/0x70
[ 9343.915378]  dump_stack+0x10/0x20
[ 9343.915386]  vcmn_err+0xe8/0x120 [spl]
[ 9343.915415]  zfs_panic_recover+0x75/0xa0 [zfs]
[ 9343.915528]  dbuf_read_impl.constprop.0+0x8c5/0x930 [zfs]
[ 9343.915601]  dbuf_read+0xf3/0x620 [zfs]
[ 9343.915657]  dmu_buf_hold_array_by_dnode+0x116/0x6a0 [zfs]
[ 9343.915722]  dmu_read_uio_dnode+0x5a/0x150 [zfs]
[ 9343.915778]  ? srso_alias_return_thunk+0x5/0x7f
[ 9343.915783]  dmu_read_uio_dbuf+0x48/0x70 [zfs]
[ 9343.915838]  zfs_read+0x143/0x400 [zfs]
[ 9343.915912]  zpl_iter_read+0xfb/0x1c0 [zfs]
[ 9343.915979]  vfs_read+0x20a/0x360
[ 9343.915985]  ksys_read+0x73/0x100
[ 9343.915987]  __x64_sys_read+0x19/0x30
[ 9343.915990]  do_syscall_64+0x59/0x90
[ 9343.915993]  ? srso_alias_return_thunk+0x5/0x7f
[ 9343.915994]  ? do_user_addr_fault+0x238/0x6b0
[ 9343.915997]  ? srso_alias_return_thunk+0x5/0x7f
[ 9343.915999]  ? exit_to_user_mode_prepare+0x30/0xb0
[ 9343.916003]  ? srso_alias_return_thunk+0x5/0x7f
[ 9343.916005]  ? irqentry_exit_to_user_mode+0x17/0x20
[ 9343.916007]  ? srso_alias_return_thunk+0x5/0x7f
[ 9343.916009]  ? irqentry_exit+0x43/0x50
[ 9343.916010]  ? srso_alias_return_thunk+0x5/0x7f
[ 9343.916012]  ? exc_page_fault+0x94/0x1b0
[ 9343.916015]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
[ 9343.916018] RIP: 0033:0x7f5a81131721
[ 9343.916056] Code: 00 48 8b 15 f9 36 0e 00 f7 d8 64 89 02 b8 ff ff ff ff eb c3 e8 a0 e6 01 00 f3 0f 1e fa 80 3d 25 be 0e 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 57 c3 66 0f 1f 44 00 00 48 83 ec 28 48 89 54
[ 9343.916057] RSP: 002b:00007ffe4d5a6858 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
[ 9343.916060] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5a81131721
[ 9343.916061] RDX: 0000000000020000 RSI: 00007f5a80209000 RDI: 0000000000000003
[ 9343.916062] RBP: 0000000000020000 R08: 00000000ffffffff R09: 0000000000000000
[ 9343.916063] R10: 0000000000000022 R11: 0000000000000246 R12: 00007f5a80209000
[ 9343.916064] R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000000000
[ 9343.916067]  </TASK>
@mmatuska mmatuska added the Type: Defect Incorrect behavior (e.g. crash, hang) label Oct 30, 2023
mmatuska added a commit to mmatuska/zfs that referenced this issue Oct 30, 2023
@mmatuska
Fix block cloning between unencrypted and encrypted datasets
1b435a9 
When copying data to or from an encrypted dataset, block cloning
should be used only when it is the same dataset. The current code
checked only if the source was encrypted and the check should
happen more early to avoid unnecessary operations.

We may relax this condition in the future by supporting block cloning
between encrypted datasets using the same key.

Fixes openzfs#15464

Signed-off-by:  Martin Matuska <mm@FreeBSD.org>
@mmatuska mmatuska mentioned this issue Oct 30, 2023
Merged
13 tasks
mmatuska added a commit to mmatuska/zfs that referenced this issue Oct 30, 2023
@mmatuska
Fix block cloning between unencrypted and encrypted datasets
02d18a2 
Block cloning from an encrypted dataset into an unencrypted dataset
and vice versa is not possible. The current code did allow cloning
unencrypted files into an encrypted dataset causing a panic when
these were accessed. Block cloning between encrypted and encrypted
is currently supported on the same filesystem only.

Fixes openzfs#15464

Signed-off-by:  Martin Matuska <mm@FreeBSD.org>
mmatuska added a commit to mmatuska/zfs that referenced this issue Oct 30, 2023
@mmatuska
Fix block cloning between unencrypted and encrypted datasets
2a52466 
Block cloning from an encrypted dataset into an unencrypted dataset
and vice versa is not possible. The current code did allow cloning
unencrypted files into an encrypted dataset causing a panic when
these were accessed. Block cloning between encrypted and encrypted
is currently supported on the same filesystem only.

Fixes openzfs#15464

Signed-off-by:  Martin Matuska <mm@FreeBSD.org>
@65a
Copy link

65a commented Nov 1, 2023

I suspect this was also #15275

mmatuska added a commit to mmatuska/zfs that referenced this issue Nov 3, 2023
@mmatuska
Fix block cloning between unencrypted and encrypted datasets
fb4fe77 
Block cloning from an encrypted dataset into an unencrypted dataset
and vice versa is not possible. The current code did allow cloning
unencrypted files into an encrypted dataset causing a panic when
these were accessed. Block cloning between encrypted and encrypted
is currently supported on the same filesystem only.

Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Kay Pedersen <mail@mkwg.de>
Reviewed-by: Rob N <robn@despairlabs.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Martin Matuska <mm@FreeBSD.org>
Closes openzfs#15464
Closes openzfs#15465
@oromenahar oromenahar mentioned this issue Nov 5, 2023
Closed
behlendorf pushed a commit that referenced this issue Nov 6, 2023
@mmatuska @behlendorf
Fix block cloning between unencrypted and encrypted datasets
459c99f 
Block cloning from an encrypted dataset into an unencrypted dataset
and vice versa is not possible. The current code did allow cloning
unencrypted files into an encrypted dataset causing a panic when
these were accessed. Block cloning between encrypted and encrypted
is currently supported on the same filesystem only.

Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Kay Pedersen <mail@mkwg.de>
Reviewed-by: Rob N <robn@despairlabs.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Martin Matuska <mm@FreeBSD.org>
Closes #15464
Closes #15465
@mnd999
Copy link

mnd999 commented Nov 11, 2023 •
edited

omfg this made it into a release? I don't see any testing improvements in the PR that fixed it. Surely something as fundamental as cp should get some testing love.

@rincebrain rincebrain mentioned this issue Nov 15, 2023
Merged
13 tasks
lundman pushed a commit to openzfsonwindows/openzfs that referenced this issue Dec 12, 2023
@mmatuska @lundman
Fix block cloning between unencrypted and encrypted datasets
82729fd 
Block cloning from an encrypted dataset into an unencrypted dataset
and vice versa is not possible. The current code did allow cloning
unencrypted files into an encrypted dataset causing a panic when
these were accessed. Block cloning between encrypted and encrypted
is currently supported on the same filesystem only.

Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Kay Pedersen <mail@mkwg.de>
Reviewed-by: Rob N <robn@despairlabs.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Martin Matuska <mm@FreeBSD.org>
Closes openzfs#15464
Closes openzfs#15465
@ago ago mentioned this issue Apr 9, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Type: Defect Incorrect behavior (e.g. crash, hang)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@mmatuska @mnd999 @65a