public inbox for linux-next@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	"DRM XE List" <intel-xe@lists.freedesktop.org>
Cc: Kees Cook <kees@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	Matthew Brost <matthew.brost@intel.com>,
	Satyanarayana K V P <satyanarayana.k.v.p@intel.com>
Subject: linux-next: manual merge of the drm-xe tree with the origin tree
Date: Mon, 23 Feb 2026 13:34:53 +0000	[thread overview]
Message-ID: <aZxXfTCmjfTd-lUL@sirena.org.uk> (raw)

[-- Attachment #1: Type: text/plain, Size: 2594 bytes --]

Hi all,

Today's linux-next merge of the drm-xe tree got a conflict in:

  drivers/gpu/drm/drm_suballoc.c

between commit:

  69050f8d6d075 ("treewide: Replace kmalloc with kmalloc_obj for non-scalar types")

from the origin tree and commit:

  16843e6638b74 ("drm/sa: Split drm_suballoc_new() into SA alloc and init helpers")

from the drm-xe tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

diff --cc drivers/gpu/drm/drm_suballoc.c
index e44ad39e310cd,dc9bef3c0419d..0000000000000
--- a/drivers/gpu/drm/drm_suballoc.c
+++ b/drivers/gpu/drm/drm_suballoc.c
@@@ -293,13 -293,37 +293,37 @@@ static bool drm_suballoc_next_hole(stru
  }
  
  /**
-  * drm_suballoc_new() - Make a suballocation.
+  * drm_suballoc_alloc() - Allocate uninitialized suballoc object.
+  * @gfp: gfp flags used for memory allocation.
+  *
+  * Allocate memory for an uninitialized suballoc object. Intended usage is
+  * allocate memory for suballoc object outside of a reclaim tainted context
+  * and then be initialized at a later time in a reclaim tainted context.
+  *
+  * @drm_suballoc_free() should be used to release the memory if returned
+  * suballoc object is in uninitialized state.
+  *
+  * Return: a new uninitialized suballoc object, or an ERR_PTR(-ENOMEM).
+  */
+ struct drm_suballoc *drm_suballoc_alloc(gfp_t gfp)
+ {
+ 	struct drm_suballoc *sa;
+ 
 -	sa = kmalloc(sizeof(*sa), gfp);
++	sa = kmalloc_obj(*sa, gfp);
+ 	if (!sa)
+ 		return ERR_PTR(-ENOMEM);
+ 
+ 	sa->manager = NULL;
+ 
+ 	return sa;
+ }
+ EXPORT_SYMBOL(drm_suballoc_alloc);
+ 
+ /**
+  * drm_suballoc_insert() - Initialize a suballocation and insert a hole.
   * @sa_manager: pointer to the sa_manager
+  * @sa: The struct drm_suballoc.
   * @size: number of bytes we want to suballocate.
-  * @gfp: gfp flags used for memory allocation. Typically GFP_KERNEL but
-  *       the argument is provided for suballocations from reclaim context or
-  *       where the caller wants to avoid pipelining rather than wait for
-  *       reclaim.
   * @intr: Whether to perform waits interruptible. This should typically
   *        always be true, unless the caller needs to propagate a
   *        non-interruptible context from above layers.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

             reply	other threads:[~2026-02-23 13:34 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-23 13:34 Mark Brown [this message]
  -- strict thread matches above, loose matches on Subject: below --
2026-03-23 16:11 linux-next: manual merge of the drm-xe tree with the origin tree Mark Brown
2026-02-24 12:43 Mark Brown
2026-02-23 13:39 Mark Brown
2026-02-23 13:35 Mark Brown
2025-09-15 22:18 Mark Brown

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=aZxXfTCmjfTd-lUL@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=kees@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=matthew.brost@intel.com \
    --cc=satyanarayana.k.v.p@intel.com \
    --cc=thomas.hellstrom@linux.intel.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