in smp (2 * Xeon w/ HT for 4 logical processors) it oopses w/ a NULL pointer exception as branchput_gen() seems to get a NULL putmap.
On Wed, 2006-01-18 at 18:37 -0500, Shaya Potter wrote: > actually change that, seems the machine I tested this on, was booted > into up mode. so not just an smp race. > > On Wed, 2006-01-18 at 18:18 -0500, Shaya Potter wrote: > > there seems to be a race condition that I hit regularly when running > > postmark on a dual 3.06mhz xeon blade. > > > > basically, I do a heavy duty postmark > > > > set size 512 10240 > > set number 20000 > > set transactions 200000 > > set subdirectories 200 > > set read 4096 > > set write 4096 > > set buffering false > > > > and have it branch every 60 seconds. (--add new ; --mode old ro) > > > > this is using the latest snapshot > > > > unionfs-20060117-2031 > > > > kernel trace (echo t > /proc/sysrq-trigger) gives > > > > unionctl D C030B520 0 3237 3235 (NOTLB) > > ea885ea8 00000086 c26e5a20 c030b520 f8e17d20 f8e0c7a5 f8e0e060 00000297 > > dfc33000 f71e2300 f782e520 00085578 be7b2551 000000ec c26e5b70 > > f7616818 > > ea885ebc c26e5a20 c26e5a20 c024c73d f8e11906 0000015c f761681c > > f74cfe18 > > Call Trace: > > [<c024c73d>] rwsem_down_write_failed+0x8d/0x170 > > [<f8ddfbd4>] .text.lock.branchman+0x12a/0x1a6 [unionfs] > > [<f8e08334>] unionfs_ioctl+0x2a4/0x3f0 [unionfs] > > [<c015ba6e>] do_ioctl+0x6e/0x80 > > [<c015bc55>] vfs_ioctl+0x65/0x1e0 > > [<c015be37>] sys_ioctl+0x67/0x90 > > [<c0102493>] syscall_call+0x7/0xb > > > > i.e. unionctl is waiting to get the read/write semaphore as write so > > that it can do the ioctl. implying that either something is blocked > > holding it as read or something is blocked holding it as write. > > > > but > > > > postmark D C030B520 0 3210 2796 (NOTLB) > > f74cfe04 00000086 f782e520 c030b520 ea8a7ea4 c2655480 0000003a 000021d8 > > 00000000 00000000 00000000 0000025a be7b35ca 000000ec f782e670 > > f7616818 > > f74cfe18 f782e520 0000000c c024c5cd f74cfe28 c010f017 f761681c > > f761681c > > Call Trace: > > [<c024c5cd>] rwsem_down_read_failed+0x8d/0x170 > > [<c010f017>] __wake_up_locked+0x27/0x30 > > [<f8dc303a>] .text.lock.dentry+0x1f/0x1c5 [unionfs] > > [<c024c5cd>] rwsem_down_read_failed+0x8d/0x170 > > [<f8e03282>] unionfs_file_revalidate+0x122/0x2ba0 [unionfs] > > [<f8e09d54>] fist_dprint_internal+0x14/0x80 [unionfs] > > [<f8e084f3>] unionfs_flush+0x73/0xd2f [unionfs] > > [<f8dc3798>] unionfs_write+0x1b8/0x1f0 [unionfs] > > [<c014a2bf>] vfs_write+0xff/0x160 > > [<c0149806>] filp_close+0x76/0x90 > > [<c0149870>] sys_close+0x50/0x60 > > [<c0102493>] syscall_call+0x7/0xb > > > > can't get the read, implying that something is blocked holding it as > > write. > > > > however, unless something is blowing up in such a way that doesn't cause > > the kernel to complain, I don't see how any write_locks can be taken > > without being released (it's only in branchman.c, and seems pretty > > simple). > > > > > > _______________________________________________ > > unionfs mailing list > > [email protected] > > http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs > > _______________________________________________ > unionfs mailing list > [email protected] > http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs _______________________________________________ unionfs mailing list [email protected] http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
