On 12/15/20 8:33 AM, Matthew Wilcox wrote: > On Tue, Dec 15, 2020 at 08:29:40AM -0700, Jens Axboe wrote: >> On 12/15/20 5:24 AM, Matthew Wilcox wrote: >>> On Mon, Dec 14, 2020 at 12:13:22PM -0700, Jens Axboe wrote: >>>> +++ b/fs/namei.c >>>> @@ -686,6 +686,8 @@ static bool try_to_unlazy(struct nameidata *nd) >>>> BUG_ON(!(nd->flags & LOOKUP_RCU)); >>>> >>>> nd->flags &= ~LOOKUP_RCU; >>>> + if (nd->flags & LOOKUP_NONBLOCK) >>>> + goto out1; >>> >>> If we try a walk in a non-blocking context, it fails, then we punt to >>> a thread, do we want to prohibit that thread trying an RCU walk first? >>> I can see arguments both ways -- this may only be a temporary RCU walk >>> failure, or we may never be able to RCU walk this path. >> >> In my opinion, it's not worth it trying to over complicate matters by >> handling the retry side differently. Better to just keep them the >> same. We'd need a lookup anyway to avoid aliasing. > > but by clearing LOOKUP_RCU here, aren't you making the retry handle > things differently? maybe i got lost. That's already how it works, I'm just clearing LOOKUP_NONBLOCK (which relies on LOOKUP_RCU) when we're clearing LOOKUP_RCU. I can try and benchmark skipping LOOKUP_RCU when we do the blocking retry, but my gut tells me it'll be noise. -- Jens Axboe
