From: Leon Romanovsky <leon@kernel.org>
To: Tejun Heo <tj@kernel.org>
Cc: Hillf Danton <hdanton@sina.com>,
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 21:58:04 +0300 [thread overview]
Message-ID: <20240604185804.GT3884@unreal> (raw)
In-Reply-To: <Zl9BOaPDsQBc8hSL@slm.duckdns.org>
On Tue, Jun 04, 2024 at 06:30:49AM -1000, Tejun Heo wrote:
> Hello, Leon.
>
> On Tue, Jun 04, 2024 at 02:38:34PM +0300, Leon Romanovsky wrote:
> > 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.
>
> It's not valid. pwq release is async and while wq free in the error path
> isn't. The flush is there so that we finish the async part before
> synchronize error handling. The patch you posted will can lead to double
> free after a pwq allocation failure. We can make the error path synchronous
> but the pwq free path should be updated first so that it stays synchronous
> in the error path. Note that it *needs* to be asynchronous in non-error
> paths, so it's going to be a bit subtle one way or the other.
But at that point, we didn't add newly created WQ to any list which will execute
that asynchronous release. Did I miss something?
Anyway, I understand that the lockdep_register_key() corruption comes
from something else. Do you have any idea what can cause it? How can we
help debug this issue?
Thanks
>
> Thanks.
>
> --
> tejun
>
next prev parent reply other threads:[~2024-06-04 18:58 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
2024-06-04 16:30 ` Tejun Heo
2024-06-04 18:58 ` Leon Romanovsky [this message]
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=20240604185804.GT3884@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.