Christoph Hellwig wrote: > I think we have a rather bad race in the logmanager read completion > hadnling. See jfs_logmgr.c:lbmRead(): > > generic_make_request(READ, &bp->l_bh); > run_task_queue(&tq_disk); > > wait_event(bp->l_ioevent, (bp->l_flag != lbmREAD)); > > lbmREAD get's cleared by lbmIODone without any atomicy guarntees. > A possible soloution might be to use bitops on ->l_flag, but that > would make lbmWrite rather ugly.
Is this really a race? Since lbmIODone is not racing with anyone else trying to modify bp->l_flag, that should be safe. I think the design of wait_event ensures that as long as lbmIODone resets the lbmREAD flag before calling wakeup (LCACHE_WAKEUP), lbmRead will be awakened if it needs to be. > > I'd prefer to always take the LCACHE_LOCK for ->l_flag manipulations. I believe we should only have to protect l_flag with a spinlock if we have contention between two threads both trying to modify it. -- David Kleikamp IBM Linux Technology Center _______________________________________________ Jfs-discussion mailing list [EMAIL PROTECTED] http://www-124.ibm.com/developerworks/oss/mailman/listinfo/jfs-discussion
