[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z4DxS37yJ2EfI_rS@gondor.apana.org.au>
Date: Fri, 10 Jan 2025 18:07:07 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Breno Leitao <leitao@...ian.org>
Cc: Michael Kelley <mhklinux@...look.com>,
"saeedm@...dia.com" <saeedm@...dia.com>,
"tariqt@...dia.com" <tariqt@...dia.com>,
"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Thomas Graf <tgraf@...g.ch>, Tejun Heo <tj@...nel.org>,
Hao Luo <haoluo@...gle.com>, Josh Don <joshdon@...gle.com>,
Barret Rhoden <brho@...gle.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] rhashtable: Fix potential deadlock by moving
schedule_work outside lock
On Fri, Jan 10, 2025 at 01:49:44AM -0800, Breno Leitao wrote:
>
> That is what I though originally as well, but I was not convinced. While
> reading the code, I understood that, if new_tbl is not NULL, then
> PTR_ERR(data) will be -ENOENT.
>
> In which case `net_tbl` will not be NULL, and PTR_ERR(data) != -ENOENT?
The bug arises when an insertion succeeds. So new_tbl is NULL.
The original value of data should have been -ENOENT, however,
it gets overwritten after rhashtable_insert_one (data is now
NULL).
Cheers,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists