mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Wentao Liang <vulab@iscas.ac.cn>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Jani Nikula <jani.nikula@linux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Tvrtko Ursulin <tursulin@ursulin.net>,
	David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm/i915: Fix vm reference leak in mock_gem_device()
Date: Sat, 7 Nov 2026 14:30:22 -0500	[thread overview]
Message-ID: <2026110723-lure-fifteen-b69d@gregkh> (raw)
In-Reply-To: <1794071392.2684479.vulab@iscas.ac.cn>

On Sat, Nov 07, 2026 at 05:09:52PM +0000, Wentao Liang wrote:
> Hi Joonas,
> 
> First of all, I sincerely apologize for my very late reply, and thank you
> for taking the time to raise these concerns.
> 
> I have read your message carefully. Your criticism is justified, not only
> regarding this particular patch, but also regarding the way I have been
> submitting patches to the kernel community.
> 
> For this patch, I failed to properly assess the severity and scope of the
> issue before submitting it. This is a selftest-only cleanup, and it should
> never have been marked for stable backporting. I also failed to pay
> sufficient attention to the subsystem's coding conventions and teardown
> ordering. These are things I should have checked myself before asking
> maintainers to review the change.
> 
> I have revisited the relevant code and revised the patch to address these
> issues. The v2 removes the Fixes and stable tags, corrects the subject
> prefix, and adjusts the cleanup ordering. I understand that correcting
> these details now does not excuse the lack of care in the original
> submission.
> 
> I also want to be transparent about the use of AI tools. The initial
> finding came from static analysis, and I used DeepSeek and GPT 6.1 Sol to
> help examine the finding and prepare the patch. However, I was the one
> who decided to submit it, and I am fully responsible for its correctness,
> testing, and presentation. Using these tools does not reduce that
> responsibility, and I should not have submitted a patch without
> sufficient independent verification.
> 
> More importantly, I owe you and the other maintainers an apology for my
> broader submission practices. I submitted far too many patches in a short
> period of time without giving each one the attention it deserved. I also
> failed to respond to review comments and requests for changes, including
> requests to acknowledge AI assistance. I understand how frustrating this
> must have been, especially when maintainers are spending their own
> limited time reviewing contributions.
> 
> You were right to question whether I was taking the review process
> seriously. Looking back at how I handled those submissions, I can
> understand why they gave that impression. I regret that my actions wasted
> maintainers' time and undermined their trust in my contributions.
> 
> I am changing how I approach kernel contributions. I will stop submitting
> patches in bulk, review outstanding feedback individually, and prioritize
> resolving existing discussions over sending new patches. Going forward, I
> will submit changes only after I have examined the relevant code paths,
> checked the subsystem conventions, and performed appropriate validation. I
> will also make sure that any AI assistance is properly acknowledged.
> 
> I understand that trust cannot be restored simply by writing an apology.
> It will take consistent care and follow-through in future contributions,
> and I intend to demonstrate that through my actions.

Thank you for finally responding to these massive responses that seem to
have been ignored.

Please go back and respond to all of your previous submissions and ask
the maintainers involved to ignore them and not accept them so that they
do not unnecessarily take the time to review the patches.

Then follow what you say you are going to do here, one patch at a time,
and build up some actual experience doing fixes, not blanket massive
patch floods that are obviously wrong and harmful to us.

greg k-h

  reply	other threads:[~2026-11-07 19:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-16 17:19 Wentao Liang
2026-09-17  6:57 ` Joonas Lahtinen
2026-11-07 17:09   ` Wentao Liang
2026-11-07 19:30     ` Greg KH [this message]
2026-11-07 17:10   ` [PATCH v2] drm/i915/selftests: Release GT VM reference on mock device teardown Wentao Liang

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=2026110723-lure-fifteen-b69d@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=airlied@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rodrigo.vivi@intel.com \
    --cc=simona@ffwll.ch \
    --cc=tursulin@ursulin.net \
    --cc=vulab@iscas.ac.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

all inboxes | Powered by JetHome®