Re: [PATCH 0/7] lockd: fix races that can result in stuck filelocks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> On Mar 12, 2023, at 11:33 AM, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
> 
> On Fri, Mar 3, 2023 at 4:54 PM Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote:
>> 
>> 
>> 
>>> On Mar 3, 2023, at 7:15 AM, Jeff Layton <jlayton@xxxxxxxxxx> wrote:
>>> 
>>> I sent the first patch in this series the other day, but didn't get any
>>> responses.
>> 
>> We'll have to work out who will take which patches in this set.
>> Once fully reviewed, I can take the set if the client maintainers
>> send Acks for 2-4 and 6-7.
>> 
>> nfsd-next for v6.4 is not yet open. I can work on setting that up
>> today.
>> 
>> 
>>> Since then I've had time to follow up on the client-side part
>>> of this problem, which eventually also pointed out yet another bug on
>>> the server side. There are also a couple of cleanup patches in here too,
>>> and a patch to add some tracepoints that I found useful while diagnosing
>>> this.
>>> 
>>> With this set on both client and server, I'm now able to run Yongcheng's
>>> test for an hour straight with no stuck locks.
> 
> My nfstest_lock test occasionally gets into an endless wait loop for the lock in
> one of the optests.
> 
> AFAIK, this started happening after I upgraded my client machine to v5.15.88.
> Does this seem related to the client bug fixes in this patch set?

I will let Jeff tackle that question. He did not add a Fixes:
tag, so it's difficult to say off-hand.


> If so, is this bug a regression?

If your test misbehavior is related to these fixes, then probably
yes. But this is the first I've heard of a longer-term problem.


> and why are the fixes aimed for v6.4?

Because these are test failures, not failures of non-artificial
workloads. Also because we haven't heard reports, potential or
otherwise, of a regression, until now.

Since they are test failures only, there doesn't seem to be an
urgency to get them into 6.3-rc. I prefer to let these sit in
-next for a bit, therefore. As we are well aware, patches that
go into -rc are rather aggressively pulled into stable, and I
would like to have some confidence that these fixes do not
introduce further problems.

You are welcome to petition for faster integration. It would
help if you had a positive test result to share with us.

--
Chuck Lever






[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux