Re: [Bug report] Recurring oops, 5.15.x, possibly during or soon after client mount

[Chuck Lever III <chuck.lever@oracle.com>]

Hi Jonathan-

> On Jan 16, 2022, at 5:06 PM, Jonathan Woithe <jwoithe@just42.net> wrote:
> 
> On Sun, Jan 16, 2022 at 07:53:36AM +1030, Jonathan Woithe wrote:
>> On Sat, Jan 15, 2022 at 07:46:06PM +0000, Chuck Lever III wrote:
>>>> On Jan 15, 2022, at 3:14 AM, Jonathan Woithe <jwoithe@just42.net> wrote:
>>>> On Fri, Jan 14, 2022 at 03:18:01PM +0000, Chuck Lever III wrote:
>>>>>> Recently we migrated an NFS server from a 32-bit environment running 
>>>>>> kernel 4.14.128 to a 64-bit 5.15.x kernel.  The NFS configuration remained
>>>>>> unchanged between the two systems.
>>>>>> 
>>>>>> On two separate occasions since the upgrade (5 Jan under 5.15.10, 14 Jan
>>>>>> under 5.15.12) the kernel has oopsed at around the time that an NFS client
>>>>>> machine is turned on for the day.  On both occasions the call trace was
>>>>>> essentially identical.  The full oops sequence is at the end of this email. 
>>>>>> The oops was not observed when running the 4.14.128 kernel.
>>>>>> 
>>>>>> Is there anything more I can provide to help track down the cause of the
>>>>>> oops?
>>>>> 
>>>>> A possible culprit is 7f024fcd5c97 ("Keep read and write fds with each
>>>>> nlm_file"), which was introduced in or around v5.15.  You could try a
>>>>> simple test and back the server down to v5.14.y to see if the problem
>>>>> persists.
> 
> FYI I have now put the kernel.org 5.14.21 kernel on the affected system and
> booted it.  Since the oops has taken between 1 and 2 weeks to be triggered
> in the past, we may have to wait a few weeks to be certain of an outcome. 
> If there's anything else you need from me in the interim please ask.

If you identify a particular client that triggers the issue, it would be
helpful to know:

- The client's kernel version
- What was running on the client before it was shut down
- Whether the application and client shut down was clean


--
Chuck Lever