[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6E9B7F9B8D47F98B+d6fd7e8f-de81-4ec3-b3ae-f85bbb744e66@chenxiaosong.com>
Date: Mon, 16 Jun 2025 15:49:05 +0800
From: ChenXiaoSong <chenxiaosong@...nxiaosong.com>
To: Jeff Layton <jlayton@...nel.org>
Cc: Olga Kornievskaia <okorniev@...hat.com>,
Li Lingfeng <lilingfeng3@...wei.com>, Dai Ngo <Dai.Ngo@...cle.com>,
Neil Brown <neilb@...e.de>, Chuck Lever <chuck.lever@...cle.com>,
Tom Talpey <tom@...pey.com>, linux-nfs@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/5] nfsd: prevent callback tasks running concurrently
Hi Jeff:
Do you have any suggestions for this null-ptr-deref issue?
Here is the link to the vmcore analysis:
https://chenxiaosong.com/en/nfs/en-null-ptr-deref-in-nfsd4_probe_callback.html
Thanks,
ChenXiaoSong.
在 2025/6/11 15:12, ChenXiaoSong 写道:
> 在 2025/6/10 19:09, Jeff Layton 写道:
>>
>> Synchronization was probably too strong a word. I remember looking over
>> this code and convincing myself that the probe callback wasn't subject
>> to the same races as the others, but I think that was mostly because
>> the outcome of those races was not harmful. Note that the probe itself
>> can actually be run at the start of a completely unrelated callback to
>> the same client.
>>
>> So you hit a NULL pointer in __queue_work()? The work_struct is
>> embedded in the nfs4_client so that would probably imply that that the
>> nfs4_client struct was corrupt?
>>
>> You may want to get a vmcore and analyze it if you can reproduce this.
>
> Thanks for your reply.
>
> I have already got a vmcore. Here is the link to the vmcore analysis:
>
> https://chenxiaosong.com/en/nfs/en-null-ptr-deref-in-
> nfsd4_probe_callback.html
>
> Please let me know if you need any more detailed information.
>
> Thanks,
> ChenXiaoSong.
Powered by blists - more mailing lists