All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Gou Hao <gouhao@uniontech.com>,
	maddy@linux.ibm.com, mpe@ellerman.id.au, npiggin@gmail.com,
	chleroy@kernel.org, maarten.lankhorst@linux.intel.com,
	mripard@kernel.org, tzimmermann@suse.de, airlied@gmail.com,
	simona@ffwll.ch, bharat@chelsio.com, jgg@ziepe.ca,
	namcao@linutronix.de, ynorov@nvidia.com, sshegde@linux.ibm.com,
	nilay@linux.ibm.com, clg@kaod.org, linuxppc-dev@lists.ozlabs.org,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-rdma@vger.kernel.org, linux-mm@kvack.org,
	gouhaojake@163.com, kernel@uniontech.com
Subject: Re: [PATCH v2 0/6] remove dead NULL checks after GFP_NOFAIL allocations and fix xive use-after-free
Date: Sun, 26 Jul 2026 11:24:19 +0300	[thread overview]
Message-ID: <20260726082419.GF12003@unreal> (raw)
In-Reply-To: <20260725202632.dcb325658896a470df91cf57@linux-foundation.org>

On Sat, Jul 25, 2026 at 08:26:32PM -0700, Andrew Morton wrote:
> On Fri, 24 Jul 2026 10:28:45 +0800 Gou Hao <gouhao@uniontech.com> wrote:
> 
> > This is a code cleanup series that removes unreachable
> > NULL checks (and associated error handling) that follow allocations
> > using __GFP_NOFAIL, which guarantees non-NULL return.
> 
> Sigh.
> 
> Back when Linux ran on an abacus, I added __GFP_NOFAIL because four or
> five sites (file systems) were infinitely looping on alloc_pages until
> it succeeded.  I figured we should move this operation into the page
> allocator so we could easily find those sites and fix them to Not Do
> That.
> 
> I made it very clear (changelog and code comments) that no new code
> should use __GFP_NOFAIL.  How did that work out?
> 
> hp2:/usr/src/linux-7.2-rc4> grep -r __GFP_NOFAIL | wc -l
> 241
> 
> So much lameness!   My immediate reaction to your patchset is "No.  Fix
> the damn code instead".  But I've resoundingly lost that fight.
> 
> 
> Thanks, I'll scoop up the entire series.  If individual patches pop up
> in linux-next then I'll drop the mm.git copies.
> 
> 
> 
> AI review has a shower of possible pre-existing issues.  I'm seeing
> use-after-free, double-free, leak, system hang, NULL pointer
> dereference, usual stuff :(
> 
> They're in powerpc and cxgb4, if maintainers are interested.
> 
> 	https://sashiko.dev/#/patchset/20260724022851.466017-1-gouhao@uniontech.com

Regarding cxgb4, yes, I'm looking into it.

Thanks



  reply	other threads:[~2026-07-26  8:24 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-24  2:28 [PATCH v2 0/6] remove dead NULL checks after GFP_NOFAIL allocations and fix xive use-after-free Gou Hao
2026-07-24  2:28 ` [PATCH v2 1/6] powerpc/xive: remove dead NULL check after GFP_NOFAIL allocation Gou Hao
2026-07-24  4:55   ` Cédric Le Goater
2026-07-24  2:28 ` [PATCH v2 2/6] powerpc/xive: add error return value to xive_smp_probe() Gou Hao
2026-07-24  4:55   ` Cédric Le Goater
2026-07-24  2:28 ` [PATCH v2 3/6] powerpc/xive: fix use-after-free of xive_ipis Gou Hao
2026-07-24  2:44   ` sashiko-bot
2026-07-24  4:58   ` Cédric Le Goater
2026-07-24  2:28 ` [PATCH v2 4/6] drm: remove dead WARN_ON NULL check after GFP_NOFAIL allocation Gou Hao
2026-07-24  2:28 ` [PATCH v2 5/6] lib/test_hmm: remove dead NULL checks after GFP_NOFAIL allocations Gou Hao
2026-07-24  2:28 ` [PATCH v2 6/6] RDMA/cxgb4: " Gou Hao
2026-07-24  2:53   ` sashiko-bot
2026-07-24  7:34   ` Potnuri Bharat Teja
2026-07-26  3:26 ` [PATCH v2 0/6] remove dead NULL checks after GFP_NOFAIL allocations and fix xive use-after-free Andrew Morton
2026-07-26  8:24   ` Leon Romanovsky [this message]
2026-07-26  8:23 ` (subset) " Leon Romanovsky

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=20260726082419.GF12003@unreal \
    --to=leon@kernel.org \
    --cc=airlied@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=bharat@chelsio.com \
    --cc=chleroy@kernel.org \
    --cc=clg@kaod.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gouhao@uniontech.com \
    --cc=gouhaojake@163.com \
    --cc=jgg@ziepe.ca \
    --cc=kernel@uniontech.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=maddy@linux.ibm.com \
    --cc=mpe@ellerman.id.au \
    --cc=mripard@kernel.org \
    --cc=namcao@linutronix.de \
    --cc=nilay@linux.ibm.com \
    --cc=npiggin@gmail.com \
    --cc=simona@ffwll.ch \
    --cc=sshegde@linux.ibm.com \
    --cc=tzimmermann@suse.de \
    --cc=ynorov@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 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.