Hi, On Sat, 2005-03-05 at 00:04, Andrew Morton wrote:
> Perhaps we could also fix this by elevating b_jcount whenever the jh is > being moved between lists? Possible. But jcount isn't atomic, and it requires the bh_journal_head lock to modify. Taking and dropping the lock twice around the __unfile/__refile pair, once to inc jcount and once again to drop it, is probably unnecessarily expensive. We can probably do with just holding the bh_journal_head lock alone in most cases. The specific case we're stumbling on here is the t_locked_list. The problem manifests itself when we walk that list, but we think it is actually caused when we first add it to the list: __journal_unfile_buffer(jh); __journal_file_buffer(jh, commit_transaction, BJ_Locked); __journal_unfile_buffer does no locking of its own. We're calling this point with the buffer locked, j_list_lock held and the bh_state lock held. Trouble is, that's not enough; journal_put_journal_head() can nuke the buffer with merely the bh_journal_head lock held. In the code above it would be enough to take the journal_head_lock over the unfile/file pair. Andrew, can you remember why we ended up with both of those locks in the first place? If we can do it, the efficient way out here is to abandon the journal_head_lock and use the bh_state_lock for both. We already hold that over many of the key refile spots, and this would avoid the need to take yet another lock in those paths. --Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/