Hi Jonathan-
> On Jan 16, 2022, at 5:06 PM, Jonathan Woithe <jwoithe@xxxxxxxxxx> 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@xxxxxxxxxx> 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
