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
