linux-next: manual merge of the drm-msm-fixes tree with the origin tree

linux-next: manual merge of the drm-msm-fixes tree with the origin tree

[Mark Brown]

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

Hi all,

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

  drivers/gpu/drm/msm/msm_iommu.c

between commits:

  48634a9ea06a4 ("drm/msm: Adjust msm_iommu_pagetable_prealloc_allocate() allocation type")
  69050f8d6d075 ("treewide: Replace kmalloc with kmalloc_obj for non-scalar types")
  bf4afc53b77ae ("Convert 'alloc_obj' family to use the new default GFP_KERNEL argument")

from the origin tree and commit:

  6f6f3535192dd ("drm/msm: Adjust msm_iommu_pagetable_prealloc_allocate() allocation type")

from the drm-msm-fixes 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 --combined drivers/gpu/drm/msm/msm_iommu.c
index 7d449e5202c5d,271baf4dc4e80..0000000000000
--- a/drivers/gpu/drm/msm/msm_iommu.c
+++ b/drivers/gpu/drm/msm/msm_iommu.c
@@@ -332,7 -332,7 +332,7 @@@ msm_iommu_pagetable_prealloc_allocate(s
  	struct kmem_cache *pt_cache = get_pt_cache(mmu);
  	int ret;
  
 -	p->pages = kvmalloc_array(p->count, sizeof(*p->pages), GFP_KERNEL);
 +	p->pages = kvmalloc_objs(*p->pages, p->count);
  	if (!p->pages)
  		return -ENOMEM;
  
@@@ -521,7 -521,7 +521,7 @@@ struct msm_mmu *msm_iommu_pagetable_cre
  	if (WARN_ONCE(!ttbr1_cfg, "No per-process page tables"))
  		return ERR_PTR(-ENODEV);
  
 -	pagetable = kzalloc(sizeof(*pagetable), GFP_KERNEL);
 +	pagetable = kzalloc_obj(*pagetable);
  	if (!pagetable)
  		return ERR_PTR(-ENOMEM);
  
@@@ -734,7 -734,7 +734,7 @@@ struct msm_mmu *msm_iommu_new(struct de
  
  	iommu_set_pgtable_quirks(domain, quirks);
  
 -	iommu = kzalloc(sizeof(*iommu), GFP_KERNEL);
 +	iommu = kzalloc_obj(*iommu);
  	if (!iommu) {
  		iommu_domain_free(domain);
  		return ERR_PTR(-ENOMEM);

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

Re: linux-next: manual merge of the drm-msm-fixes tree with the origin tree

[Dmitry Baryshkov]

On Wed, 25 Feb 2026 at 15:22, Mark Brown <broonie@kernel.org> wrote:
>
> Hi all,
>
> Today's linux-next merge of the drm-msm-fixes tree got a conflict in:
>
>   drivers/gpu/drm/msm/msm_iommu.c
>
> between commits:
>
>   48634a9ea06a4 ("drm/msm: Adjust msm_iommu_pagetable_prealloc_allocate() allocation type")

Kees, why was it landed? And how? It was not Ack'ed (nor was it
requested) to go through the non-drm-msm tree. There was no note that
it got applied. What is going on?

>   69050f8d6d075 ("treewide: Replace kmalloc with kmalloc_obj for non-scalar types")
>   bf4afc53b77ae ("Convert 'alloc_obj' family to use the new default GFP_KERNEL argument")
>
> from the origin tree and commit:
>
>   6f6f3535192dd ("drm/msm: Adjust msm_iommu_pagetable_prealloc_allocate() allocation type")
>
> from the drm-msm-fixes 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 --combined drivers/gpu/drm/msm/msm_iommu.c
> index 7d449e5202c5d,271baf4dc4e80..0000000000000
> --- a/drivers/gpu/drm/msm/msm_iommu.c
> +++ b/drivers/gpu/drm/msm/msm_iommu.c
> @@@ -332,7 -332,7 +332,7 @@@ msm_iommu_pagetable_prealloc_allocate(s
>         struct kmem_cache *pt_cache = get_pt_cache(mmu);
>         int ret;
>
>  -      p->pages = kvmalloc_array(p->count, sizeof(*p->pages), GFP_KERNEL);
>  +      p->pages = kvmalloc_objs(*p->pages, p->count);
>         if (!p->pages)
>                 return -ENOMEM;
>
> @@@ -521,7 -521,7 +521,7 @@@ struct msm_mmu *msm_iommu_pagetable_cre
>         if (WARN_ONCE(!ttbr1_cfg, "No per-process page tables"))
>                 return ERR_PTR(-ENODEV);
>
>  -      pagetable = kzalloc(sizeof(*pagetable), GFP_KERNEL);
>  +      pagetable = kzalloc_obj(*pagetable);
>         if (!pagetable)
>                 return ERR_PTR(-ENOMEM);
>
> @@@ -734,7 -734,7 +734,7 @@@ struct msm_mmu *msm_iommu_new(struct de
>
>         iommu_set_pgtable_quirks(domain, quirks);
>
>  -      iommu = kzalloc(sizeof(*iommu), GFP_KERNEL);
>  +      iommu = kzalloc_obj(*iommu);
>         if (!iommu) {
>                 iommu_domain_free(domain);
>                 return ERR_PTR(-ENOMEM);



-- 
With best wishes
Dmitry

Re: linux-next: manual merge of the drm-msm-fixes tree with the origin tree

[Kees Cook]

On Wed, Feb 25, 2026 at 07:42:12PM +0200, Dmitry Baryshkov wrote:
> On Wed, 25 Feb 2026 at 15:22, Mark Brown <broonie@kernel.org> wrote:
> >
> > Hi all,
> >
> > Today's linux-next merge of the drm-msm-fixes tree got a conflict in:
> >
> >   drivers/gpu/drm/msm/msm_iommu.c
> >
> > between commits:
> >
> >   48634a9ea06a4 ("drm/msm: Adjust msm_iommu_pagetable_prealloc_allocate() allocation type")
> 
> Kees, why was it landed? And how? It was not Ack'ed (nor was it
> requested) to go through the non-drm-msm tree. There was no note that
> it got applied. What is going on?

It was a prerequisite for the tree-wide changes, so I had to send it to
Linus ahead of the -rc1 release. Sorry for the collision there! I waited
as long as I could, but the msm-fixes tree wasn't sent for -rc1, so I
had to include the patch in the prep patches:
https://lore.kernel.org/lkml/202602191029.2F0E7F01@keescook/

-- 
Kees Cook

Re: linux-next: manual merge of the drm-msm-fixes tree with the origin tree

[Dmitry Baryshkov]

On Wed, 25 Feb 2026 at 19:56, Kees Cook <kees@kernel.org> wrote:
>
> On Wed, Feb 25, 2026 at 07:42:12PM +0200, Dmitry Baryshkov wrote:
> > On Wed, 25 Feb 2026 at 15:22, Mark Brown <broonie@kernel.org> wrote:
> > >
> > > Hi all,
> > >
> > > Today's linux-next merge of the drm-msm-fixes tree got a conflict in:
> > >
> > >   drivers/gpu/drm/msm/msm_iommu.c
> > >
> > > between commits:
> > >
> > >   48634a9ea06a4 ("drm/msm: Adjust msm_iommu_pagetable_prealloc_allocate() allocation type")
> >
> > Kees, why was it landed? And how? It was not Ack'ed (nor was it
> > requested) to go through the non-drm-msm tree. There was no note that
> > it got applied. What is going on?
>
> It was a prerequisite for the tree-wide changes, so I had to send it to
> Linus ahead of the -rc1 release. Sorry for the collision there! I waited
> as long as I could, but the msm-fixes tree wasn't sent for -rc1, so I
> had to include the patch in the prep patches:
> https://lore.kernel.org/lkml/202602191029.2F0E7F01@keescook/

Was it coordinated with drm/msm maintainers? Not with me at least. Did
we hear anything from you, like `Would you ack merging it through the
XYZ tree`? Did we at least get the `b4 ty` or `picked up, sorry, I was
in a rush to merge my changes which were tested in linux-next`? Nope.
Is it how the community is expected to work? Not really.

-- 
With best wishes
Dmitry

Re: linux-next: manual merge of the drm-msm-fixes tree with the origin tree

[Kees Cook]

On Wed, Feb 25, 2026 at 08:11:21PM +0200, Dmitry Baryshkov wrote:
> On Wed, 25 Feb 2026 at 19:56, Kees Cook <kees@kernel.org> wrote:
> >
> > On Wed, Feb 25, 2026 at 07:42:12PM +0200, Dmitry Baryshkov wrote:
> > > On Wed, 25 Feb 2026 at 15:22, Mark Brown <broonie@kernel.org> wrote:
> > > >
> > > > Hi all,
> > > >
> > > > Today's linux-next merge of the drm-msm-fixes tree got a conflict in:
> > > >
> > > >   drivers/gpu/drm/msm/msm_iommu.c
> > > >
> > > > between commits:
> > > >
> > > >   48634a9ea06a4 ("drm/msm: Adjust msm_iommu_pagetable_prealloc_allocate() allocation type")
> > >
> > > Kees, why was it landed? And how? It was not Ack'ed (nor was it
> > > requested) to go through the non-drm-msm tree. There was no note that
> > > it got applied. What is going on?
> >
> > It was a prerequisite for the tree-wide changes, so I had to send it to
> > Linus ahead of the -rc1 release. Sorry for the collision there! I waited
> > as long as I could, but the msm-fixes tree wasn't sent for -rc1, so I
> > had to include the patch in the prep patches:
> > https://lore.kernel.org/lkml/202602191029.2F0E7F01@keescook/
> 
> Was it coordinated with drm/msm maintainers? Not with me at least. Did
> we hear anything from you, like `Would you ack merging it through the
> XYZ tree`? Did we at least get the `b4 ty` or `picked up, sorry, I was
> in a rush to merge my changes which were tested in linux-next`? Nope.
> Is it how the community is expected to work? Not really.

I apologize for not communicating this in a more direct and timely
fashion. It was a rare case, and I didn't follow the expected
procedures. I'll be sure to do such notifications if there is ever need
for such out-of-band patch handling like this again. It's been a lot of
years since I did my last large-scale tree-wide refactoring, so I was
a bit rusty.

-- 
Kees Cook