On Mon, Mar 16, 2015 at 05:27:31AM -0700, Christoph Hellwig wrote: > On Mon, Mar 16, 2015 at 08:20:04AM -0400, Jeff Layton wrote: > > I just tried a v3.19 kernel on the server and could reproduce this > > there with generic/011 as well, so this looks like a preexisting bug of > > some sort. Perhaps the recent client changes to allow parallel opens > > are helping to expose it? > > That sounds like a good explanation, as I've never seen this before > those changes were merged. Possibly unrelated, but I'm suspicious of the release_open_stateid() on nfs4_get_vfs_file() failure: I believe a) we're not holding any locks over those two calls, and b) the stateid is globally visible ever since init_open_stateid. So by the time we call release_open_stateid(), another open could have found that stateid and be trying to work with it, right? Maybe I'm missing something. nfs4_get_vfs_file() is where an actual vfs open can happen, so it's doing a lot of work, and can sleep--so it seems a particularly likely point for someone else to race with us. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
