public inbox for linux-rdma@vger.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Leon Romanovsky <leon@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 10:04:08 -1000	[thread overview]
Message-ID: <Zl9zOH2hUramwNSi@slm.duckdns.org> (raw)
In-Reply-To: <20240604185804.GT3884@unreal>

Hello,

On Tue, Jun 04, 2024 at 09:58:04PM +0300, Leon Romanovsky wrote:
> But at that point, we didn't add newly created WQ to any list which will execute
> that asynchronous release. Did I miss something?

So, wq itself is not the problem. There are multiple pwq's that get attached
to a wq and each pwq is refcnt'd and released asynchronously. Over time,
during wq init, how the error paths behave diverged - pwq's still take the
async path while wq error path stayed synchronous. The flush is there to
match them. A cleaner solution would be either turning everything async or
sync.

> 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?

It looks like other guys are already looking at another commit, but focusing
on the backtrace which prematurely freed the reported object (rather than
the backtrace which stumbled upon it while walking shared data structure)
should help finding the actual culprit.

Thanks.

-- 
tejun

  reply	other threads:[~2024-06-04 20:04 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-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
2024-06-04 20:04                 ` Tejun Heo [this message]
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:21 ` Imre Deak
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=Zl9zOH2hUramwNSi@slm.duckdns.org \
    --to=tj@kernel.org \
    --cc=gal@nvidia.com \
    --cc=hdanton@sina.com \
    --cc=jiangshanlai@gmail.com \
    --cc=leon@kernel.org \
    --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 \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox