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

zfs on 32bit: xattr causes oops #594

Closed
adeeln opened this issue Mar 5, 2012 · 4 comments
Closed

zfs on 32bit: xattr causes oops #594

adeeln opened this issue Mar 5, 2012 · 4 comments
Milestone

Comments

@adeeln
Copy link

adeeln commented Mar 5, 2012

While getting ZFS to work on a 32bit box, I encountered a bug where accessing any file caused an oops...here's the log:

2012-03-04T21:34:58.062225-05:00 localhost kernel: BUG: unable to handle kernel NULL pointer dereference at 000000e6
Message from syslogd@localhost at Mar 4 21:34:58 ...kernel:Oops: 0000 [#1] SMP
Message from syslogd@localhost at Mar 4 21:34:58 ... kernel:Process ls (pid: 3751, ti=5c478000 task=5bfc2300 task.ti=5c478000)
Message from syslogd@localhost at Mar 4 21:34:58 ... kernel:Stack:
Message from syslogd@localhost at Mar 4 21:34:58 ... kernel:Call Trace:
Message from syslogd@localhost at Mar 4 21:34:58 ... kernel:Code: 58 20 8b 5b 18 8b 5b 4c 85 db 74 04 ff d3 89 c6 89 f0 5b 5e 5d c3 55 89 e5 57 89 c7 56 31 c0 53 83 ec 08 8b 32 85 f6 75 2e eb 35 <8b> 08 89 45 ec 89 4d f0 89 f1 eb 04 ff 45 f0 41 8b 45 f0 8a 18
Message from syslogd@localhost at Mar 4 21:34:58 ... kernel:EIP: [<401a5e4d>] xattr_resolve_name+0x15/0x51 SS:ESP 0068:5c479e20
Message from syslogd@localhost at Mar 4 21:34:58 ... kernel:CR2: 00000000000000e6
2012-03-04T21:34:58.062288-05:00 localhost kernel: IP: [<401a5e4d>] xattr_resolve_name+0x15/0x51
2012-03-04T21:34:58.062294-05:00 localhost kernel: *pde = 00000000
2012-03-04T21:34:58.062298-05:00 localhost kernel: Oops: 0000 [#1] SMP
2012-03-04T21:34:58.062307-05:00 localhost kernel: Modules linked in: ipv6 zfs(P) zcommon(P) znvpair(P) zavl(P) zunicode(P) spl(O) i2c_i801 processor evdev thermal_sys i2c_core container button scsi_transport_iscsi e1000 zlib_deflate ext4 jbd2 mbcache scsi_wait_scan usbhid ohci_hcd uhci_hcd usb_storage ehci_hcd usbcore usb_common ata_piix ahci libahci
2012-03-04T21:34:58.062312-05:00 localhost kernel:
2012-03-04T21:34:58.062319-05:00 localhost kernel: Pid: 3751, comm: ls Tainted: P O 3.2.1-gentoo-r2 #2 Supermicro X5DP8/X5DP8
2012-03-04T21:34:58.062325-05:00 localhost kernel: EIP: 0060:[<401a5e4d>] EFLAGS: 00010202 CPU: 0
2012-03-04T21:34:58.062332-05:00 localhost kernel: EIP is at xattr_resolve_name+0x15/0x51
2012-03-04T21:34:58.062337-05:00 localhost kernel: EAX: 000000e6 EBX: 401a5e75 ECX: 5c479e84 EDX: 5c479e48
2012-03-04T21:34:58.062342-05:00 localhost kernel: ESI: 5c479e84 EDI: 5ff6d9e0 EBP: 5c479e34 ESP: 5c479e20
2012-03-04T21:34:58.062347-05:00 localhost kernel: DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
2012-03-04T21:34:58.062351-05:00 localhost kernel: Process ls (pid: 3751, ti=5c478000 task=5bfc2300 task.ti=5c478000)
2012-03-04T21:34:58.062355-05:00 localhost kernel: Stack:
2012-03-04T21:34:58.062360-05:00 localhost kernel: 5ff57438 5ff696ed 401a5e89 5c33b780 5c33b780 5c479e54 401a5ea7 401a6102
2012-03-04T21:34:58.062365-05:00 localhost kernel: 00000004 00000000 5c479e84 401a5e89 5c479e84 5c479e70 401a61ee 00000000
2012-03-04T21:34:58.062370-05:00 localhost kernel: 00000000 00000017 00000000 00000000 5c479f90 401a6280 00000000 00000000
2012-03-04T21:34:58.062374-05:00 localhost kernel: Call Trace:
2012-03-04T21:34:58.062379-05:00 localhost kernel: [<401a5e89>] ? xattr_resolve_name+0x51/0x51
2012-03-04T21:34:58.062383-05:00 localhost kernel: [<401a5ea7>] generic_getxattr+0x1e/0x48
2012-03-04T21:34:58.062388-05:00 localhost kernel: [<401a6102>] ? xattr_permission+0x53/0xed
2012-03-04T21:34:58.062393-05:00 localhost kernel: [<401a5e89>] ? xattr_resolve_name+0x51/0x51
2012-03-04T21:34:58.062494-05:00 localhost kernel: [<401a61ee>] vfs_getxattr+0x52/0x59
2012-03-04T21:34:58.062504-05:00 localhost kernel: [<401a6280>] getxattr+0x8b/0xde
2012-03-04T21:34:58.062512-05:00 localhost kernel: [<40199305>] ? path_lookupat+0x4ad/0x501
2012-03-04T21:34:58.062518-05:00 localhost kernel: [<4019a062>] ? user_path_at_empty+0x4c/0x68
2012-03-04T21:34:58.062522-05:00 localhost kernel: [<4019a062>] ? user_path_at_empty+0x4c/0x68
2012-03-04T21:34:58.062527-05:00 localhost kernel: [<4019a098>] ? user_path_at+0x1a/0x1f
2012-03-04T21:34:58.062531-05:00 localhost kernel: [<401a6846>] sys_getxattr+0x3a/0x4c
2012-03-04T21:34:58.062536-05:00 localhost kernel: [<40360290>] sysenter_do_call+0x12/0x26
2012-03-04T21:34:58.062544-05:00 localhost kernel: Code: 58 20 8b 5b 18 8b 5b 4c 85 db 74 04 ff d3 89 c6 89 f0 5b 5e 5d c3 55 89 e5 57 89 c7 56 31 c0 53 83 ec 08 8b 32 85 f6 75 2e eb 35 <8b> 08 89 45 ec 89 4d f0 89 f1 eb 04 ff 45 f0 41 8b 45 f0 8a 18
2012-03-04T21:34:58.062550-05:00 localhost kernel: EIP: [<401a5e4d>] xattr_resolve_name+0x15/0x51 SS:ESP 0068:5c479e20
2012-03-04T21:34:58.062554-05:00 localhost kernel: CR2: 00000000000000e6
2012-03-04T21:34:58.062559-05:00 localhost kernel: ---[ end trace 78a8dec2e46fec25 ]---

The temporary fix was to set the xattr attribute in zfs off, i.e. zfs set xattr=off tank/ROOT

@behlendorf
Copy link
Contributor

Thanks for filing this and mentioning it was a 32-bit issue. If you could also include the distribution and kernel version in the bug report that would be helpful.

@adeeln
Copy link
Author

adeeln commented Mar 9, 2012

Sure, sorry; its a Gentoo install, using sys-kernel/gentoo-sources-3.2.1-r2 & the in portage-tree genkernel-9999

@behlendorf
Copy link
Contributor

Can you please give the above patch a try, I expect it will resolve the issue. Unfortunately, I wasn't able to reproduce it locally.

behlendorf added a commit to behlendorf/zfs that referenced this issue Mar 15, 2012
The xattr_resolve_name() helper function expects the registered
list of xattr handlers to be NULL terminated.  This NULL was
accidentally missing which could result in a NULL dereference.

Interestingly this issue only manifested itself on certain 32-bit
systems.  Presumably on 64-bit kernels we just always happen to
get lucky and the memory following the structure is zeroed.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Issue openzfs#594
@adeeln
Copy link
Author

adeeln commented Mar 16, 2012

Yup, the patch seems to have resolved the oops; at least I can't reproduce it anymore with the same setup/commands. For completeness, I was copying from an ext4 mounted root partition to a mounted zfs partition with:

rsync -rax --exclude /proc --exclude /dev --exclude /sys --exclude /tmp --exclude /mnt / /mnt/gentoo

doing a cp -a also caused the problem. The only way I was able to do any copying was by using: tar cp / | tar xfp -C /mnt/gentoo

The ext4 partition was mounted as:
/dev/sda2 on / type ext4 (rw,noatime,user_xattr,barrier=1,data=ordered)

while the zfs partition was mounted as:
system/ROOT on /mnt/gentoo type zfs (rw)

@adeeln adeeln closed this as completed Mar 16, 2012
behlendorf pushed a commit to behlendorf/zfs that referenced this issue May 21, 2018
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: George Melikov <mail@gmelikov.ru>
Closes openzfs#594
pcd1193182 pushed a commit to pcd1193182/zfs that referenced this issue Sep 26, 2023
…aster

Merge remote-tracking branch '6.0/stage' into 'master'
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

2 participants