On Tue, Apr 1, 2025 at 6:24 PM NeilBrown <neilb@xxxxxxx> wrote: > > On Tue, 01 Apr 2025, Olga Kornievskaia wrote: > > On Mon, Mar 31, 2025 at 10:49 AM Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > > > > > > On 3/30/25 8:10 PM, NeilBrown wrote: > > > > On Mon, 31 Mar 2025, Olga Kornievskaia wrote: > > > >> > > > >> This code would also make the behaviour consistent with prior to > > > >> 4cc9b9f2bf4d. But now I question whether or not the new behaviour is > > > >> what is desired going forward or not? > > > >> > > > >> Here's another thing to consider: the same command done over nfsv4 > > > >> returns an error. I guess nobody ever complained that flock over v3 > > > >> was successful but failed over v4? > > > > > > > > That is useful. Given that: > > > > - exclusive flock without write access over v4 never worked > > > > - As Tom notes, new man pages document that exclusive flock without write access > > > > isn't expected to work over NFS > > > > - it is hard to think of a genuine use case for exclusive flock without > > > > write access > > > > > > > > I'm inclined to leave this code as it is and declare your failing test > > > > to no longer be invalid. > > > > > > For the record, which test exactly is failing? Is there a BugLink? > > > > Test is just an flock()? > > > > But what motivated you to perform that specific test: > exclusive flock over NFSv3 on a file you didn't have write permission to > ?? > > Is it part of a test suite? Or is it done by some application? or .... A long story. It started with xfstest failing for sec=tls policy (ie thus the other 2 patches in the series). But I saw that it's just an flock that was failing so I stopped doing xfstest and just using an flock. But as I started digging into the bisected patch I was trying to understand the code and thus started using other export policies. > NeilBrown
