The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Jing Wu <realwujing@gmail.com>
To: wangzhaolong@fnnas.com
Cc: jirislaby@kernel.org, gregkh@linuxfoundation.org,
	linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
	yuanql9@chinatelecom.cn
Subject: Re: [PATCH v6] serial: 8250: fix use-after-free in IRQ chain handling
Date: Wed,  8 Jul 2026 16:47:17 +0800	[thread overview]
Message-ID: <20260708084717.421487-1-realwujing@gmail.com> (raw)
In-Reply-To: <20260708072306.3921604-1-wangzhaolong@fnnas.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2401 bytes --]

> This accusation is not acceptable.

It's not an accusation.  It's a timeline.

Your v1 predates ours by one day — not in dispute.  But your v1 didn't
work.  You confirmed this yourself on May 29 when you wrote "v3 fixes
the Bugzilla reproducer on my setup" — on *our* v3 thread, not yours.
If your v1 already fixed the problem, you wouldn't have needed to test
our v3 and report back.

> That same locking change also closes the irq_info UAF window

Your v1 commit message never mentions use-after-free.  It discusses only
"Unbalanced enable for IRQ."  Our v1 was the first to identify and
document both races.  Claiming retroactively that your v1 "also" fixed
UAF is revisionist.

> For v3, the irq_chain_mutex rename was made in response to Jiri's review
> comment

Jiri made that comment on *our* v6, not yours.  He reviewed our code.
You took a review comment from our thread and applied it to your patch
as if it were your own insight.

> The __must_hold() and lockdep_assert_held() additions ... are not the
> functional fix.

They were added in our v5, reviewed by Greg on our v4.  You copied them
into your v3 and listed them as "Changes in v3" with zero attribution.

Now look at the timeline:

  Jul 7 22:06  Our v6 — posted to the list
  Jul 8 11:11  Your v2 — next morning, same lock-move skeleton
  Jul 8 15:23  Your v3 — hours later, copies irq_chain_mutex rename,
               __must_hold(), lockdep_assert_held() from our v5/v7

If we hadn't replied to Jiri and sent v6, would your v2 exist the next
morning?  If we hadn't renamed hash_mutex in v7, would your v3 appear
hours later with the same rename?  The answer is obvious.

> I do not agree to a Co-developed-by tag for my patch

We added Co-developed-by for you on our v7.  The only reason we did so
is that you confirmed the fix worked on your setup — nothing more.  You
reported the bug, you tested the fix, we credited you.  That's what
open source contributors do.

You, on the other hand, copied our lockdep annotations, our static
analysis annotations, our mutex rename — all reviewed by Jiri and Greg
on *our* patches — and passed them off as your own changelog entries.
And now you're saying you won't extend the same basic courtesy in return.
Copying is fine under GPLv2.  Presenting it as your own work is not.

You reported the bug.  We fixed it.  You copied our improvements.  Add
the tags.

Jing

  parent reply	other threads:[~2026-07-08  8:47 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-27  9:20 [PATCH] serial: 8250: serialize shared IRQ startup Wang Zhaolong
2026-06-24  2:49 ` Wang Zhaolong
2026-07-08  3:11 ` [PATCH v2] serial: 8250: fix shared IRQ startup race causing IRQ warning Wang Zhaolong
2026-07-08  6:03   ` Jiri Slaby
2026-07-08  6:20     ` Wang Zhaolong
2026-07-10 12:14       ` Greg KH
2026-07-08  7:23   ` [PATCH v3] " Wang Zhaolong
2026-07-08  7:45     ` Jing Wu
2026-07-08  8:47     ` Jing Wu [this message]
  -- strict thread matches above, loose matches on Subject: below --
2026-07-07 14:06 [PATCH v6] serial: 8250: fix use-after-free in IRQ chain handling Qiliang Yuan
2026-07-08  6:03 ` Jiri Slaby
2026-07-08  6:34   ` Jing Wu
2026-07-08  7:11   ` Jing Wu
2026-07-08  7:33   ` Wang Zhaolong
2026-07-08  7:57     ` Jing Wu
2026-07-08  8:20       ` Wang Zhaolong
2026-07-08  7:39   ` Jing Wu
2026-07-08  7:53     ` Wang Zhaolong
2026-07-08  8:08       ` Jing Wu
2026-07-08  8:32         ` Wang Zhaolong
     [not found]         ` <5cf37150673ea4d5c28f94db91cdf68504b50522.9be37cbd.7a04.4d7e.b20e.d3f90675af6e@feishu.cn>
2026-07-10 12:17           ` Greg KH
2026-07-10 13:15             ` Wang Zhaolong
2026-07-10 13:28               ` Greg KH
2026-07-08  8:43       ` Jing Wu
2026-07-08  8:45       ` Jing Wu

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=20260708084717.421487-1-realwujing@gmail.com \
    --to=realwujing@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jirislaby@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=wangzhaolong@fnnas.com \
    --cc=yuanql9@chinatelecom.cn \
    /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