From: Leon Romanovsky <leon@kernel.org>
To: Hillf Danton <hdanton@sina.com>, Tejun Heo <tj@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
Lai Jiangshan <jiangshanlai@gmail.com>,
Zqiang <qiang.zhang1211@gmail.com>,
linux-kernel@vger.kernel.org, Gal Pressman <gal@nvidia.com>,
Tariq Toukan <tariqt@nvidia.com>,
RDMA mailing list <linux-rdma@vger.kernel.org>
Subject: Re: [PATCH -rc] workqueue: Reimplement UAF fix to avoid lockdep worning
Date: Tue, 4 Jun 2024 14:38:34 +0300 [thread overview]
Message-ID: <20240604113834.GO3884@unreal> (raw)
In-Reply-To: <20240604105456.1668-1-hdanton@sina.com>
On Tue, Jun 04, 2024 at 06:54:56PM +0800, Hillf Danton wrote:
> On Tue, 4 Jun 2024 11:09:58 +0300 Leon Romanovsky <leon@kernel.org>
> > On Mon, Jun 03, 2024 at 10:10:36AM -1000, Tejun Heo wrote:
> > >
> > > And KASAN is reporting use-after-free on a completely unrelated VFS object.
> > > I can't tell for sure from the logs alone but lockdep_register_key()
> > > iterates entries in the hashtable trying to find whether the key is a
> > > duplicate and it could be that that walk is triggering the use-after-free
> > > warning. If so, it doesn't really have much to do with workqueue. The
> > > corruption happened elsewhere and workqueue just happens to traverse the
> > > hashtable afterwards.
> >
> > The problem is that revert of commit 643445531829
> > ("workqueue: Fix UAF report by KASAN in pwq_release_workfn()")
> > fixed these use-after-free reports.
> >
> Given revert makes sense,
Thanks, it is very rare situation where call to flush/drain queue
(in our case kthread_flush_worker) in the middle of the allocation
flow can be correct. I can't remember any such case.
So even we don't fully understand the root cause, the reimplementation
is still valid and improves existing code.
Thanks
next prev parent reply other threads:[~2024-06-04 11:38 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-28 8:39 [PATCH -rc] workqueue: Reimplement UAF fix to avoid lockdep worning Leon Romanovsky
2024-06-04 14:21 ` Imre Deak
2024-05-30 21:42 ` Tejun Heo
2024-05-31 3:48 ` Leon Romanovsky
2024-05-31 17:45 ` Tejun Heo
2024-06-02 6:56 ` Leon Romanovsky
2024-06-03 20:10 ` Tejun Heo
2024-06-04 8:09 ` Leon Romanovsky
2024-06-04 10:54 ` Hillf Danton
2024-06-04 11:38 ` Leon Romanovsky [this message]
2024-06-04 16:30 ` Tejun Heo
2024-06-04 18:58 ` Leon Romanovsky
2024-06-04 20:04 ` Tejun Heo
2024-06-05 11:10 ` Hillf Danton
2024-06-06 7:38 ` Leon Romanovsky
2024-06-06 10:29 ` Leon Romanovsky
2024-06-07 11:04 ` Hillf Danton
2024-06-04 11:40 ` Leon Romanovsky
2024-06-04 13:16 ` Tariq Toukan
2024-06-04 14:30 ` Imre Deak
2024-06-04 15:20 ` Dan Williams
2024-06-04 15:45 ` Imre Deak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240604113834.GO3884@unreal \
--to=leon@kernel.org \
--cc=gal@nvidia.com \
--cc=hdanton@sina.com \
--cc=jiangshanlai@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=qiang.zhang1211@gmail.com \
--cc=tariqt@nvidia.com \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.