On Tue, Oct 13, 2015 at 8:26 AM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote:
>
> On Mon, Oct 12, 2015 at 11:47 PM, Trond Myklebust
> <trond.myklebust@xxxxxxxxxxxxxxx> wrote:
> > On Mon, Oct 12, 2015 at 5:55 PM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote:
> >> It'll be nice to know when we return delegations synchronously or not.
> >
> > Why? This patch forces us to carry an otherwise completely unnecessary
> > parameter, so at the very minimum we should have a discussion of what
> > the real use cases are.
>
> I used it to diagnose the race of open and delegreturn. If it's kept
How were you using it?
> that some delegreturns are synchronous and others are not I think the
> information is useful.
The only difference between synchronous and asynchronous in this case
is whether or not the process that launched the delegreturn actually
waits for it to complete; a signal could easily prevent it from doing
so without interrupting the delegreturn call itself.
IOW: for complete information when debugging races here, you really
need to examine the return value from the wait call.
> Speaking of there is a race between state manager thread returning
> used delegations and new open. Previously I thought it was evict
> inode...
Is this with commit 5e99b532bb95 ("nfs4: reset states to use
open_stateid when returning delegation voluntarily") applied?
--
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
