All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Matthew Brost" <matthew.brost@intel.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2] drm/pagemap: Fix folio allocation fallback and use-after-put
Date: Wed, 05 Aug 2026 05:29:11 +0000	[thread overview]
Message-ID: <20260805052912.424AB1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260805051744.3481873-1-matthew.brost@intel.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Unconditional use of __GFP_NOWARN suppresses OOM warnings for order-0 allocations.
--

--- Patch [1]: [PATCH v2] drm/pagemap: Fix folio allocation fallback and use-after-put ---
commit 8cbd3237a69e546db0a488ed740897837ca90e44
Author: Matthew Brost <matthew.brost@intel.com>

drm/pagemap: Fix folio allocation fallback and use-after-put

This commit fixes an issue where higher-order folio allocations lacking
warning suppression would spam the kernel log on failure. It adds a fallback
path to use order-0 allocations for the entire range if the higher-order
allocation fails. It also fixes a use-after-free issue when retrieving the
folio order after the page reference was dropped.

> diff --git a/drivers/gpu/drm/drm_pagemap.c b/drivers/gpu/drm/drm_pagemap.c
> index 15c78eca180b7..aeb8ba0017e5f 100644
> --- a/drivers/gpu/drm/drm_pagemap.c
> +++ b/drivers/gpu/drm/drm_pagemap.c
> @@ -886,11 +886,34 @@ static int drm_pagemap_migrate_populate_ram_pfn(struct vm_area_struct *vas,
>  
>  		order = folio_order(page_folio(src_page));
>  
> -		/* TODO: Support fallback to single pages if THP allocation fails */
>  		if (vas)
> -			folio = vma_alloc_folio(GFP_HIGHUSER, order, vas, addr);
> +			folio = vma_alloc_folio(GFP_HIGHUSER | __GFP_NOWARN, order, vas, addr);
>  		else
> -			folio = folio_alloc(GFP_HIGHUSER, order);
> +			folio = folio_alloc(GFP_HIGHUSER | __GFP_NOWARN, order);

[Severity: Medium]
The commit message notes that __GFP_NOWARN is added to the higher-order
allocation, but does this unconditionally apply __GFP_NOWARN even when
order is 0?

If the source page is order-0, the primary allocation in
drm_pagemap_migrate_populate_ram_pfn() will use __GFP_NOWARN. If that
allocation fails, the subsequent fallback block is skipped because its
condition requires a non-zero order.

This means the function will jump directly to the free_pages error path
without logging any OOM warning for the failed order-0 allocation. Since
the fallback order-0 allocations explicitly use GFP_HIGHUSER without
__GFP_NOWARN, should the primary allocation also avoid __GFP_NOWARN when
order is 0?

> +
> +		if (!folio && order) {
> +			/*
> +			 * Higher-order allocation failed, fall back to

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260805051744.3481873-1-matthew.brost@intel.com?part=1

  reply	other threads:[~2026-08-05  5:29 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-05  5:17 [PATCH v2] drm/pagemap: Fix folio allocation fallback and use-after-put Matthew Brost
2026-08-05  5:29 ` sashiko-bot [this message]
2026-08-05  5:41 ` ✓ CI.KUnit: success for drm/pagemap: Fix folio allocation fallback and use-after-put (rev2) Patchwork
2026-08-05  6:23 ` ✗ Xe.CI.BAT: failure " Patchwork
2026-08-05 13:05 ` ✓ Xe.CI.FULL: success " Patchwork

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=20260805052912.424AB1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=matthew.brost@intel.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.