On Mon, 27 Jul 2015 09:44:07 -0400 Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx> wrote: > On Mon, Jul 27, 2015 at 7:07 AM, Jeff Layton > <jeff.layton@xxxxxxxxxxxxxxx> wrote: > > > > On Mon, 27 Jul 2015 06:59:49 -0400 > > Jeff Layton <jlayton@xxxxxxxxxxxxxxx> wrote: > > > > > Currently, we check to see if an open stateid needs updating, and then > > > update the stateid if so. The check and update however are not atomic, > > > so it's easily possible to end up finding an old seqid when we check > > > it only to have it updated by a newer one before we can get around to > > > updating it ourselves. > > What am I missing? AFAICS, we always hold a write lock on the > state->seqlock in those functions. > > The state->state_lock protects the state->lock_states list. It > shouldn't have any function as far as protecting open stateids. > > Trond Ahh my bad. You aren't missing anything. I was thinking that the write_seqlock calls would just bump a counter, and missed the fact that they have a spinlock embedded within them. In that case, there is no bug here and this patch can be dropped. Thanks! -- Jeff Layton <jeff.layton@xxxxxxxxxxxxxxx> -- 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
