From: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
To: Chuck Lever III <chuck.lever@oracle.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-stable <stable@vger.kernel.org>,
"patches@lists.linux.dev" <patches@lists.linux.dev>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Guenter Roeck <linux@roeck-us.net>,
"shuah@kernel.org" <shuah@kernel.org>,
"patches@kernelci.org" <patches@kernelci.org>,
"lkft-triage@lists.linaro.org" <lkft-triage@lists.linaro.org>,
"pavel@denx.de" <pavel@denx.de>,
"jonathanh@nvidia.com" <jonathanh@nvidia.com>,
"f.fainelli@gmail.com" <f.fainelli@gmail.com>,
"sudipm.mukherjee@gmail.com" <sudipm.mukherjee@gmail.com>,
"srw@sladewatkins.net" <srw@sladewatkins.net>,
"rwarsow@gmx.de" <rwarsow@gmx.de>,
"conor@kernel.org" <conor@kernel.org>,
"allen.lkml@gmail.com" <allen.lkml@gmail.com>,
"broonie@kernel.org" <broonie@kernel.org>,
Calum Mackay <calum.mackay@oracle.com>,
Vegard Nossum <vegard.nossum@oracle.com>,
Darren Kenny <darren.kenny@oracle.com>,
Ramanan Govindarajan <ramanan.govindarajan@oracle.com>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH 5.15 00/57] 5.15.155-rc1 review
Date: Sat, 13 Apr 2024 01:41:52 +0530 [thread overview]
Message-ID: <21c9bcf9-2d44-4ab2-b05c-a1712ac1a434@oracle.com> (raw)
In-Reply-To: <27E1E4C4-86C3-4D78-AF85-50C1612675E0@oracle.com>
Hi Greg, Chuck,
On 12/04/24 21:27, Chuck Lever III wrote:
>
>
>> I have noticed a regression in lts test case with nfsv4 and this was overlooked in the previous cycle(5.15.154). So the regression is from 153-->154 update. And I think that is due to nfs backports we had in 5.15.154.
>>
>> # ./runltp -d /tmpdir -s fcntl17
>>
>> <<<test_start>>>
>> tag=fcntl17 stime=1712915065
...
>> fcntl17 1 TFAIL : fcntl17.c:429: Alarm expired, deadlock not detected
>> fcntl17 0 TWARN : fcntl17.c:430: You may need to kill child processes by hand
>> fcntl17 2 TPASS : Block 1 PASSED
>> fcntl17 0 TINFO : Exit block 1
>> fcntl17 0 TWARN : tst_tmpdir.c:342: tst_rmdir: rmobj(/tmpdir/ltp-jRFBtBQhhx/LTP_fcn9Xy4hM) failed: unlink(/tmpdir/ltp-jRFBtBQhhx/LTP_fcn9Xy4hM) failed; errno=2: ENOENT
>>
>>
>> Steps used after installing latest ltp:
>>
>> $ mkdir /tmpdir
>> $ yum install nfs-utils -y
>> $ echo "/media *(rw,no_root_squash,sync)" >/etc/exports
>> $ systemctl start nfs-server.service
>> $ mount -o rw,nfsvers=3 127.0.0.1:/media /tmpdir
>> $ cd /opt/ltp
>> $ ./runltp -d /tmpdir -s fcntl17
>>
>>
>>
>> This does not happen in 5.15.153 tag.
>>
>> Adding nfs people to the CC list
>
> The reproducer uses NFSv3, but the bug report says NFSv4
> at the top.
>
> I was able to reproduce this on my nfsd-5.15.y branch
> with NFSv3.
>
> A bisect would be most helpful.
>
I was able to bisect: here are the results:
2267b2e84593bd3d61a1188e68fba06307fa9dab is the first bad commit
commit 2267b2e84593bd3d61a1188e68fba06307fa9dab
Author: Alexander Aring <aahringo@redhat.com>
Date: Tue Sep 12 17:53:18 2023 -0400
lockd: introduce safe async lock op
[ Upstream commit 2dd10de8e6bcbacf85ad758b904543c294820c63 ]
This patch reverts mostly commit 40595cdc93ed ("nfs: block notification
on fs with its own ->lock") and introduces an EXPORT_OP_ASYNC_LOCK
export flag to signal that the "own ->lock" implementation supports
async lock requests. The only main user is DLM that is used by GFS2 and
OCFS2 filesystem. Those implement their own lock() implementation and
return FILE_LOCK_DEFERRED as return value. Since commit 40595cdc93ed
("nfs: block notification on fs with its own ->lock") the DLM
implementation were never updated. This patch should prepare for DLM
to set the EXPORT_OP_ASYNC_LOCK export flag and update the DLM
plock implementation regarding to it.
Acked-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Alexander Aring <aahringo@redhat.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Documentation/filesystems/nfs/exporting.rst | 7 +++++++
fs/lockd/svclock.c | 4 +---
fs/nfsd/nfs4state.c | 10 +++++++---
include/linux/exportfs.h | 14 ++++++++++++++
4 files changed, 29 insertions(+), 6 deletions(-)
Bisect log:
==========
git bisect start
# status: waiting for both good and bad commits
# bad: [cdfd0a7f01396303e9d4fb3513a1127636f12e5e] Linux 5.15.154
git bisect bad cdfd0a7f01396303e9d4fb3513a1127636f12e5e
# status: waiting for good commit(s), bad commit known
# good: [9465fef4ae351749f7068da8c78af4ca27e61928] Linux 5.15.153
git bisect good 9465fef4ae351749f7068da8c78af4ca27e61928
# good: [4420d19ed4e4fe2adc9bed8a49bf195db1137458] NFSD: Report average
age of filecache items
git bisect good 4420d19ed4e4fe2adc9bed8a49bf195db1137458
# good: [94e412c945e64579798204aee7bc669d0acfaf79] nfsd: fix courtesy
client with deny mode handling in nfs4_upgrade_open
git bisect good 94e412c945e64579798204aee7bc669d0acfaf79
# bad: [254f1c2521716cafc63530750ce313059f5d5979] iwlwifi: mvm: rfi: use
kmemdup() to replace kzalloc + memcpy
git bisect bad 254f1c2521716cafc63530750ce313059f5d5979
# bad: [e635f652696ef6f1230621cfd89c350cb5ec6169] serial: sc16is7xx:
convert from _raw_ to _noinc_ regmap functions for FIFO
git bisect bad e635f652696ef6f1230621cfd89c350cb5ec6169
# good: [05b452e8748bcf92c00725691437e16d46af7c28] nfsd: Fix creation
time serialization order
git bisect good 05b452e8748bcf92c00725691437e16d46af7c28
# bad: [ccd9fe71b9ee46ebcecec8aec5c4f1e1ddd35dfd] nfsd: Fix a regression
in nfsd_setattr()
git bisect bad ccd9fe71b9ee46ebcecec8aec5c4f1e1ddd35dfd
# bad: [2267b2e84593bd3d61a1188e68fba06307fa9dab] lockd: introduce safe
async lock op
git bisect bad 2267b2e84593bd3d61a1188e68fba06307fa9dab
# good: [56e5eeff6cfa4bd6ffa2b2ae5b8bfc1c28044faf] nfsd: separate
nfsd_last_thread() from nfsd_put()
git bisect good 56e5eeff6cfa4bd6ffa2b2ae5b8bfc1c28044faf
# good: [6e5fed48d8b7b25f8517a1292b62a3a86a5aec91] NFSD: fix possible
oops when nfsd/pool_stats is closed.
git bisect good 6e5fed48d8b7b25f8517a1292b62a3a86a5aec91
# first bad commit: [2267b2e84593bd3d61a1188e68fba06307fa9dab] lockd:
introduce safe async lock op
Hope the above might help.
I didnot test the revert of culprit commit on top of 5.15.154 yet.
Thanks,
Harshit
next prev parent reply other threads:[~2024-04-12 20:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20240411095407.982258070@linuxfoundation.org>
2024-04-12 10:25 ` [PATCH 5.15 00/57] 5.15.155-rc1 review Harshit Mogalapalli
2024-04-12 10:50 ` Greg Kroah-Hartman
2024-04-12 15:57 ` Chuck Lever III
2024-04-12 20:06 ` Calum Mackay
2024-04-12 20:11 ` Harshit Mogalapalli [this message]
2024-04-12 20:23 ` Chuck Lever
2024-04-12 21:34 ` Harshit Mogalapalli
2024-04-13 15:56 ` Chuck Lever
2024-04-14 6:13 ` Greg Kroah-Hartman
2024-04-15 13:31 ` Chuck Lever
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=21c9bcf9-2d44-4ab2-b05c-a1712ac1a434@oracle.com \
--to=harshit.m.mogalapalli@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=allen.lkml@gmail.com \
--cc=broonie@kernel.org \
--cc=calum.mackay@oracle.com \
--cc=chuck.lever@oracle.com \
--cc=conor@kernel.org \
--cc=darren.kenny@oracle.com \
--cc=f.fainelli@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=jonathanh@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=lkft-triage@lists.linaro.org \
--cc=patches@kernelci.org \
--cc=patches@lists.linux.dev \
--cc=pavel@denx.de \
--cc=ramanan.govindarajan@oracle.com \
--cc=rwarsow@gmx.de \
--cc=shuah@kernel.org \
--cc=srw@sladewatkins.net \
--cc=stable@vger.kernel.org \
--cc=sudipm.mukherjee@gmail.com \
--cc=torvalds@linux-foundation.org \
--cc=vegard.nossum@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).