Hi, On Wed, Aug 16, 2023 at 7:37 AM Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > On Mon, 2023-08-14 at 17:11 -0400, Alexander Aring wrote: > > This patch removes to handle non-blocking lock requests as asynchronous > > lock request returning FILE_LOCK_DEFERRED. When fl_lmops and lm_grant() > > is set and a non-blocking lock request returns FILE_LOCK_DEFERRED will > > end in an WARNING to signal the user the misusage of the API. > > > > Probably need to rephrase the word salad in the first sentence of the > commit log. I had to go over it a few times to understand what was going > on here. > ok. I will go over it again. > In any case, I'm guessing that the idea here is that GFS2/DLM shouldn't > ever return FILE_LOCK_DEFERRED if this is a non-wait request (i.e. > someone called F_SETLK instead of F_SETLKW)? > Yes, non-wait requests (meaning trylock) does not return FILE_LOCK_DEFERRED. I added in some patch a WARN_ON() if this would be the case. However I mentioned in other patches there is this mismatch between F_SETLK from lockd and figure out if it's wait and non-wait if FL_SLEEP is set, but somehow if it's not coming from lockd (lm_grant is not set) it's going over the cmd if it's F_SETLKW. So far I understand DLM should never make this decision over the F_SETLK vs F_SETLKW it should always check on FL_SLEEP. I can change it to use FL_SLEEP only. > That may be ok, but again, lockd goes to great lengths to avoid blocking > and I think it's generally a good idea. If an upcall to DLM can take a > long time, it might be a good idea to continue to allow a !wait request > to return FILE_LOCK_DEFERRED. > In the case of DLM there is no difference between upcall/downcall if lockd does other operations like unlock/cancellation requests. We don't do the optimization there, why are we doing it for !wait requests... but okay I can change it. > I guess this really depends on the current behavior today though. Does > DLM ever return FILE_LOCK_DEFERRED on a non-blocking lock request? > I change it so that it doesn't do it, but I can change it !wait requests will return FILE_LOCK_DEFERRED and be handled asynchronously. - Alex
