Hello,
we have exactly the same issue with unionfs and firefox. We did apply the
patch posted above. The kernel oops occurs every time firefox is launched.
Syslog shows the following:
Aug 26 18:57:09 fix BUG: unable to handle kernel NULL pointer dereference at
000000a0
Aug 26 18:57:09 fix IP: [<c02306c0>] unionfs_setattr+0x3c0/0x3f0
Aug 26 18:57:09 fix *pdpt = 00000000364a7001 *pde = 0000000000000000
Aug 26 18:57:09 fix Oops: 0000 [#1] PREEMPT SMP
Aug 26 18:57:09 fix last sysfs file:
/sys/devices/pci0000:00/0000:00:18.3/resource
Aug 26 18:57:09 fix Modules linked in: nvidia(P) s626drv snd_intel8x0
snd_ac97_codec ac97_bus snd_pcm snd_timer snd snd_page_alloc amd64_agp
agpgart
Aug 26 18:57:09 fix
Aug 26 18:57:09 fix Pid: 6572, comm: firefox Tainted: P
(2.6.29.4-unionfs-rtai-SMP #23)
Aug 26 18:57:09 fix EIP: 0060:[<c02306c0>] EFLAGS: 00010202 CPU: 0
Aug 26 18:57:09 fix EIP is at unionfs_setattr+0x3c0/0x3f0
Aug 26 18:57:09 fix EAX: 00000000 EBX: e342f1a0 ECX: e34306a4 EDX: f652a800
Aug 26 18:57:09 fix ESI: e34306cc EDI: 00000000 EBP: f6c0fee8 ESP: f6c0fe94
Aug 26 18:57:09 fix DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Aug 26 18:57:09 fix Process firefox (pid: 6572, ti=f6c0e000 task=e9f64b40
task.ti=f6c0e000)
Aug 26 18:57:09 fix I-pipe domain Linux
Aug 26 18:57:09 fix Stack:
Aug 26 18:57:09 fix c01866a5 00000000 e342fae0 00000000 f6c0fed4 e3433cec
00000004 f6c0e000
Aug 26 18:57:09 fix c05e4180 f6c0ff30 e342f198 00000000 e3434c6c ea212a5c
00000000 f77e45c0
Aug 26 18:57:09 fix f6504800 e34306a4 f6c0ff30 00002068 00000000 f6c0ff24
c019295d 00000000
Aug 26 18:57:09 fix Call Trace:
Aug 26 18:57:09 fix [<c01866a5>] ? generic_permission+0x75/0x130
Aug 26 18:57:09 fix [<c019295d>] ? notify_change+0xed/0x330
Aug 26 18:57:09 fix [<c0194f0a>] ? mntput_no_expire+0x1a/0x110
Aug 26 18:57:09 fix [<c013b870>] ? autoremove_wake_function+0x0/0x50
Aug 26 18:57:09 fix [<c017dda8>] ? do_truncate+0x68/0x90
Aug 26 18:57:09 fix [<c0189895>] ? do_unlinkat+0x45/0x160
Aug 26 18:57:09 fix [<c017dec8>] ? do_sys_ftruncate+0xf8/0x170
Aug 26 18:57:09 fix [<c017dfa4>] ? sys_ftruncate+0x24/0x30
Aug 26 18:57:09 fix [<c0103426>] ? sysenter_do_call+0x12/0x16
Aug 26 18:57:09 fix Code: 46 60 8b 55 d0 8b 02 84 c0 79 0c 8b 57 4c 8b 47 50
89 56 4c 89 46 50 89 fa 89 f0 e8 4b d5 f6 ff 8b 4d d4 8b 51 58 e9 0e fd ff
ff <8b> 87 a0 00 00 00 85 c0 0f 84 93 fe ff ff f6 40 30 01 0f 84 89
Aug 26 18:57:09 fix EIP: [<c02306c0>] unionfs_setattr+0x3c0/0x3f0 SS:ESP
0068:f6c0fe94
I tried to track down the problem and came to a similar conclusion as in the
previous post:
lower_inode = unionfs_lower_inode(inode); ==> lower_inode == NULL
I tried to solve the problem by adding the following directly after the
previous call:
if (!lower_inode) {
pr_info("unionfs: lower_inode NULL
(name=%s)\n",dentry->d_name.name);
err = -EINVAL;
goto out;
}
This evaluation became true occasionally but the oops still occurred (still
NULL pointer dereference in unionfs_setattr). I tried adding additional
debug information, checking for every pointer if it is NULL directly before
dereferencing a pointer or calling a function in which dereferencing would
be performed. Unfortunately, although none of those checks were triggered
(only the evaluation shown above was triggered), the NULL pointer
dereference did NOT occur anymore on our test-systems.
Therefore I believe this must be some sort of race condition and I am not
sure how to continue debugging as I am not accustomed enough with linux vfs.
E.g., does vfs ensure that a dentry stays in existence while fs driver
functions like unionfs_setattr are called? If this is not the case dentry
could become invalid during superblock-locking and the subsequent lock on
dentry could lead to the NULL pointer dereference.
Btw, using the identical hardware with a 64-bit kernel (otherwise same
kernel-options) and 64-bit software does not lead to the problem with
firefox (well certainly not every time firefox is started as with the 32-bit
version). This further supports the assumption of a race condition as timing
will certainly be different. However, also on the 64-bit system there was a
unionfs-related crash, this time in __unionfs_d_revalidate. Unfortunately
the complete oops was not visible so I do not know if this was also a NULL
pointer dereference and I can only assume this problem could be related.
Best regards,
Thomas
_______________________________________________
unionfs mailing list: http://unionfs.filesystems.org/
unionfs@mail.fsl.cs.sunysb.edu
http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
