[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <64E3DD4D765DEAD1+87aeb2d4-3732-4e57-ada6-098dbf0a7feb@chenxiaosong.com>
Date: Wed, 11 Jun 2025 15:12:55 +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
在 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