Bugzilla – Bug 140453
fault in sysfs_release in kernel-xen
Last modified: 2006-05-23 23:08:01 UTC
I can cause a fault (in user context) on the (updated) kernel‑xen kernels in both 10.0 and 10.1. I've done this same test on XenSource's 2.6.12.6 and it doesn't fault. 1. Create a VM. 2. As root: udevinfo ‑a ‑p /sys/bus/xen‑backend/drivers/vbd/vbd‑2‑769/ 3. udevinfo is terminated; look at the fault in /var/log/messages. Dec 20 16:09:10 ccoffing3 kernel: general protection fault: 0000 [1] SMP Dec 20 16:09:10 ccoffing3 kernel: CPU 2 Dec 20 16:09:10 ccoffing3 kernel: Modules linked in: ipt_physdev iptable_filter ip_tables af_packet bridge button battery ipv6 ac usbhid ide_cd cdrom ohci1394 ieee1394 pcnet32 mii snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd i2c_nforce2 i2c_core ehci_hcd generic ohci_hcd usbcore forcedeth soundcore snd_page_alloc parport_pc lp parport dm_mod reiserfs fan thermal processor sata_nv libata amd74xx sd_mod scsi_mod ide_disk ide_core Dec 20 16:09:10 ccoffing3 kernel: Pid: 9651, comm: udevinfo Not tainted 2.6.13-15.7-xen Dec 20 16:09:10 ccoffing3 kernel: RIP: e030:[<ffffffff801cd374>] <ffffffff801cd374>{sysfs_release+84} Dec 20 16:09:10 ccoffing3 kernel: RSP: e02b:ffff880159021ed8 EFLAGS: 00010216 Dec 20 16:09:10 ccoffing3 kernel: RAX: 36372f322f6464f6 RBX: 36372f322f646276 RCX: 0000000000000034 Dec 20 16:09:10 ccoffing3 kernel: RDX: 0000000000000000 RSI: ffffffff80235510 RDI: ffff8801ae40893c Dec 20 16:09:10 ccoffing3 kernel: RBP: ffff8801afd5f900 R08: 0000000000001008 R09: 00002aaaaabc5c00 Dec 20 16:09:10 ccoffing3 kernel: R10: 0000000000000004 R11: ffffffffff577080 R12: ffff8801ac5f2138 Dec 20 16:09:10 ccoffing3 kernel: R13: ffff8801b03e2f00 R14: ffff8801ac5f2138 R15: ffff880152225530 Dec 20 16:09:10 ccoffing3 kernel: FS: 00002aaaaadf46d0(0000) GS:ffffffff804e2480(0000) knlGS:ffffffff804e2480 Dec 20 16:09:10 ccoffing3 kernel: CS: e033 DS: 0000 ES: 0000 Dec 20 16:09:10 ccoffing3 kernel: Process udevinfo (pid: 9651, threadinfo ffff880159020000, task ffff8801ac5a1820) Dec 20 16:09:10 ccoffing3 kernel: Stack: 0000000000000010 0000000000000010 ffff8801ac9f7cc0 ffffffff80188f92 Dec 20 16:09:10 ccoffing3 kernel: ffff8801ac5f2138 ffff8801ac9f7cc0 0000000000000000 ffff8801acb6eac0 Dec 20 16:09:10 ccoffing3 kernel: ffff8801ac9f7cc0 000000000050e880 Dec 20 16:09:10 ccoffing3 kernel: Call Trace:<ffffffff80188f92>{__fput+194} <ffffffff80185fe8>{filp_close+104} Dec 20 16:09:10 ccoffing3 kernel: <ffffffff80186657>{sys_close+151} <ffffffff80112c72>{system_call+134} Dec 20 16:09:10 ccoffing3 kernel: <ffffffff80112bec>{system_call+0} Dec 20 16:09:10 ccoffing3 kernel: Dec 20 16:09:10 ccoffing3 kernel: Code: ff 08 83 3b 02 75 0c 48 8b bb 90 05 00 00 e8 19 83 f6 ff 48 Dec 20 16:09:10 ccoffing3 kernel: RIP <ffffffff801cd374>{sysfs_release+84} RSP <ffff880159021ed8>
looks like a xen specific issue...
Jan? IIRC you've mentioned on some list you know that one ...
Created attachment 61679 [details] fixing a possible reason I didn't observe the bug, I just noticed two warnings during the build that pointed out a merge problem, which possibly is responsible for the observed problem. I asked Charles to test out whether the problem would be gone with the patch.
Yes, that patch fixes the problem on the 10.1 (HEAD) kernel. Check it in... The 10.0 kernel is still broken on Xen, regardless of the patch, however...
Sure, that patch shouldn't even apply on the 10.0 tree. The latter has a similar problem, but in a different place. I'll get a patch ready once I checked in the current set of changes from Charles/KY.
Patches checked in to HEAD and SL100_BRANCH.
Marking as resolved fixed because Jan checked in the patches. 10.1 has been built with these fixes in it. (tag 10.1-2)