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

NULL deref in vn_rdwr() #447

Closed
bill-mcgonigle opened this issue Nov 11, 2011 · 5 comments
Closed

NULL deref in vn_rdwr() #447

bill-mcgonigle opened this issue Nov 11, 2011 · 5 comments
Milestone

Comments

@bill-mcgonigle
Copy link

This was triggered by:

zfs send -v storage@backup | zfs recv -v backup/storage

Nov 10 22:29:18 librescu kernel: [276116.076509] BUG: unable to handle kernel NULL pointer dereference at           (null)
Nov 10 22:29:18 librescu kernel: [276116.076629] IP: [<ffffffffa02633c3>] vn_rdwr+0x28/0xac [spl]
Nov 10 22:29:18 librescu kernel: [276116.076716] PGD 145729067 PUD 11a922067 PMD 0 
Nov 10 22:29:18 librescu kernel: [276116.076784] Oops: 0000 [#1] SMP 
Nov 10 22:29:18 librescu kernel: [276116.076834] CPU 0 
Nov 10 22:29:18 librescu kernel: [276116.076861] Modules linked in: nfsd lockd nfs_acl auth_rpcgss ppdev parport_pc lp parport sunrpc bridge stp llc xt_recent nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack zfs(P) sha256_generic dm_crypt zcommon(P) znvpair(P) zavl(P) zunicode(P) spl zlib_deflate snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd soundcore microcode snd_page_alloc sp5100_tco i2c_piix4 k10temp xhci_hcd edac_core edac_mce_amd asus_atk0110 r8169 mii shpchp xen_netback xen_blkback xen_gntdev xen_evtchn xenfs raid1 mptsas mptscsih mptbase scsi_transport_sas wmi radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan]
Nov 10 22:29:18 librescu kernel: [276116.077444] 
Nov 10 22:29:18 librescu kernel: [276116.077444] Pid: 16299, comm: zfs Tainted: P            2.6.40-4.fc15.x86_64 #1 System manufacturer System Product Name/M4A88TD-V EVO/USB3
Nov 10 22:29:18 librescu kernel: [276116.077444] RIP: e030:[<ffffffffa02633c3>]  [<ffffffffa02633c3>] vn_rdwr+0x28/0xac [spl]
Nov 10 22:29:18 librescu kernel: [276116.077444] RSP: e02b:ffff88011baf5ca8  EFLAGS: 00010206
Nov 10 22:29:18 librescu kernel: [276116.077444] RAX: 0000000000000001 RBX: 0000000000000138 RCX: 0000000000000138
Nov 10 22:29:18 librescu kernel: [276116.077444] RDX: ffff880154e9a200 RSI: ffff880154e9a200 RDI: 0000000000000000
Nov 10 22:29:18 librescu kernel: [276116.077444] RBP: ffff88011baf5cd8 R08: 0000000000000000 R09: 0000000000000001
Nov 10 22:29:18 librescu kernel: [276116.077444] R10: 0000000000000000 R11: 0000000000000200 R12: ffff88011baf5d10
Nov 10 22:29:18 librescu kernel: [276116.077444] R13: ffff880154e9a200 R14: 0000000000000000 R15: 0000000000000000
Nov 10 22:29:18 librescu kernel: [276116.077444] FS:  00007fce530c6c20(0000) GS:ffff8803dc8c6000(0000) knlGS:0000000000000000
Nov 10 22:29:18 librescu kernel: [276116.077444] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
Nov 10 22:29:18 librescu kernel: [276116.077444] CR2: 0000000000000000 CR3: 00000002d8f82000 CR4: 0000000000000660
Nov 10 22:29:18 librescu kernel: [276116.077444] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Nov 10 22:29:18 librescu kernel: [276116.077444] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Nov 10 22:29:18 librescu kernel: [276116.077444] Process zfs (pid: 16299, threadinfo ffff88011baf4000, task ffff8801a7a9ae60)
Nov 10 22:29:18 librescu kernel: [276116.077444] Stack:
Nov 10 22:29:18 librescu kernel: [276116.077444]  ffff88011baf5cd8 ffffffff8104008b ffff88011baf5cc8 ffff88011baf5d68
Nov 10 22:29:18 librescu kernel: [276116.077444]  0000000000000138 ffff880154e9a200 ffff88011baf5d38 ffffffffa05c9563
Nov 10 22:29:18 librescu kernel: [276116.077444]  0000000000000400 ffffffffffffffff ffff88035dd3b300 ffff88011baf5d10
Nov 10 22:29:18 librescu kernel: [276116.077444] Call Trace:
Nov 10 22:29:18 librescu kernel: [276116.077444]  [<ffffffff8104008b>] ? arch_local_save_flags+0xb/0xd
Nov 10 22:29:18 librescu kernel: [276116.077444]  [<ffffffffa05c9563>] dump_bytes+0x78/0x90 [zfs]
Nov 10 22:29:18 librescu kernel: [276116.077444]  [<ffffffffa05d589b>] ? dsl_dataset_name+0xc6/0xd8 [zfs]
Nov 10 22:29:18 librescu kernel: [276116.077444]  [<ffffffffa05ca585>] dmu_sendbackup+0x29e/0x383 [zfs]
Nov 10 22:29:18 librescu kernel: [276116.077444]  [<ffffffffa0614332>] zfs_ioc_send+0x1df/0x245 [zfs]
Nov 10 22:29:18 librescu kernel: [276116.077444]  [<ffffffffa0618ca5>] zfsdev_ioctl+0x10c/0x165 [zfs]
Nov 10 22:29:18 librescu kernel: [276116.077444]  [<ffffffff81134aea>] do_vfs_ioctl+0x460/0x4a1
Nov 10 22:29:18 librescu kernel: [276116.077444]  [<ffffffff81126701>] ? fsnotify_modify+0x5f/0x67
Nov 10 22:29:18 librescu kernel: [276116.077444]  [<ffffffff81134b81>] sys_ioctl+0x56/0x79
Nov 10 22:29:18 librescu kernel: [276116.077444]  [<ffffffff814bd7c2>] system_call_fastpath+0x16/0x1b
Nov 10 22:29:18 librescu kernel: [276116.077444] Code: d8 5d c3 55 48 89 e5 41 55 41 54 53 48 83 ec 18 66 66 66 66 90 f7 45 10 00 04 00 00 4c 8b 65 28 89 f8 48 89 f7 48 89 cb 48 89 d6 
Nov 10 22:29:18 librescu kernel: [276116.077444] RIP  [<ffffffffa02633c3>] vn_rdwr+0x28/0xac [spl]
Nov 10 22:29:18 librescu kernel: [276116.077444]  RSP <ffff88011baf5ca8>
Nov 10 22:29:18 librescu kernel: [276116.077444] CR2: 0000000000000000
Nov 10 22:29:18 librescu kernel: [276116.077444] ---[ end trace c03a6e7121d41faa ]---

I have rc6 with the two commits for #287 applied.

@behlendorf
Copy link
Contributor

There was a small vn_rdwr() fix made after 0.6.0-rc6 was tagged to handle 'zfs send' with a file target but you bug does look different, openzfs/spl@f3989ed . We'll certainly try and reproduce this but you might also want to try cherry-pick this fix until 0.6.0-rc7 is tagged.

@luki-mbi
Copy link

Brian,
"zfs send" of any kind (to file or pipe, replication stream, snapshot stream, ...) still results in a kernel oops, even with the fix described above.

BUG: unable to handle kernel NULL pointer dereference at (null)
[31211.456078] IP: [] vn_rdwr+0x28/0xc2 [spl]

Any advice?

@behlendorf
Copy link
Contributor

Try a clean check of the latest spl/zfs master branches. I've heard of no other reports of send/recv being broken.

@bill-mcgonigle
Copy link
Author

I cloned spl and zfs from git this morning, built/installed RPM's (--force), rebooted, did a recursive snapshot on a pool's filesystems, and did a recursive send/recv from that pool to another, and did not get any oopses.

I'll sleep better tonight having a backup!

@behlendorf
Copy link
Contributor

Excellent! Let's call it fixed!

ahrens pushed a commit to ahrens/zfs that referenced this issue Sep 23, 2021
Follow up from openzfs#404 and openzfs#422 where we used an iterator fold() where
we really wanted to use reduce().
pcd1193182 pushed a commit to pcd1193182/zfs that referenced this issue Jun 27, 2022
Currently, zcache devices are automatically expanded when the agent
starts.

This commit adds that ability to expand zcache devices while the agent
is running, with the new `zcache expand DISK` subcommand.

Note that we still auto-expand on open.  In the future we'll make the
appstack use `zcache expand`, and then we can remove the auto-expand
code.
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

No branches or pull requests

3 participants