linux-next: manual merge of the scsi-mkp tree with the scsi tree

linux-next: manual merge of the scsi-mkp tree with the scsi tree

[Mark Brown]

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

Hi all,

Today's linux-next merge of the scsi-mkp tree got a conflict in:

  drivers/scsi/mpi3mr/mpi3mr_transport.c

between commit:

  29e3f0856e854 ("scsi: mpi3mr: Fix SAS port allocation and registration error handling")

from the scsi tree and commit:

  0b5b2fb484f3b ("Merge tag 'v7.3-rc2' into 7.4/scsi-staging")

from the scsi-mkp 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/scsi/mpi3mr/mpi3mr_transport.c
index a3412cd4ca5bc,8ee7ce1480c8d..0000000000000
--- a/drivers/scsi/mpi3mr/mpi3mr_transport.c
+++ b/drivers/scsi/mpi3mr/mpi3mr_transport.c
@@@ -1567,10 -1567,12 +1567,10 @@@ static struct mpi3mr_sas_port *mpi3mr_s
  	}
  
  	list_for_each_entry_safe(mr_sas_phy, next, &mr_sas_port->phy_list,
- 	    port_siblings) {
+ 				 port_siblings) {
  		mr_sas_phy->phy_belongs_to_port = 0;
  		list_del(&mr_sas_phy->port_siblings);
  	}
 -	if (tgtdev)
 -		mpi3mr_tgtdev_put(tgtdev);
  	kfree(mr_sas_port);
  	return NULL;
  }

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

Re: linux-next: manual merge of the scsi-mkp tree with the scsi tree

[Geert Uytterhoeven]

Hi Mark,

On Mon, 28 Sept 2026 at 16:23, Mark Brown <broonie@kernel.org> wrote:
> Today's linux-next merge of the scsi-mkp tree got a conflict in:
>
>   drivers/scsi/mpi3mr/mpi3mr_transport.c
>
> between commit:
>
>   29e3f0856e854 ("scsi: mpi3mr: Fix SAS port allocation and registration error handling")
>
> from the scsi tree and commit:
>
>   0b5b2fb484f3b ("Merge tag 'v7.3-rc2' into 7.4/scsi-staging")
>
> from the scsi-mkp 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/scsi/mpi3mr/mpi3mr_transport.c
> index a3412cd4ca5bc,8ee7ce1480c8d..0000000000000
> --- a/drivers/scsi/mpi3mr/mpi3mr_transport.c
> +++ b/drivers/scsi/mpi3mr/mpi3mr_transport.c
> @@@ -1567,10 -1567,12 +1567,10 @@@ static struct mpi3mr_sas_port *mpi3mr_s
>         }
>
>         list_for_each_entry_safe(mr_sas_phy, next, &mr_sas_port->phy_list,
> -           port_siblings) {
> +                                port_siblings) {
>                 mr_sas_phy->phy_belongs_to_port = 0;
>                 list_del(&mr_sas_phy->port_siblings);
>         }
>  -      if (tgtdev)
>  -              mpi3mr_tgtdev_put(tgtdev);
>         kfree(mr_sas_port);
>         return NULL;
>   }

Are you sure this is correct?
Martin's conflict resolution in 0b5b2fb484f3b kept the

       if (tgtdev)
               mpi3mr_tgtdev_put(tgtdev);

part.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: linux-next: manual merge of the scsi-mkp tree with the scsi tree

[Mark Brown]

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

On Tue, Sep 29, 2026 at 10:48:09AM +0200, Geert Uytterhoeven wrote:
> On Mon, 28 Sept 2026 at 16:23, Mark Brown <broonie@kernel.org> wrote:

> >         }
> >  -      if (tgtdev)
> >  -              mpi3mr_tgtdev_put(tgtdev);
> >         kfree(mr_sas_port);
> >         return NULL;
> >   }

> Are you sure this is correct?
> Martin's conflict resolution in 0b5b2fb484f3b kept the

>        if (tgtdev)
>                mpi3mr_tgtdev_put(tgtdev);

> part.

Dunno.  There was another put came in further up the function.

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

Re: linux-next: manual merge of the scsi-mkp tree with the scsi tree

[Geert Uytterhoeven]

Hi Mark,

On Tue, 29 Sept 2026 at 13:07, Mark Brown <broonie@kernel.org> wrote:
> On Tue, Sep 29, 2026 at 10:48:09AM +0200, Geert Uytterhoeven wrote:
> > On Mon, 28 Sept 2026 at 16:23, Mark Brown <broonie@kernel.org> wrote:
>
> > >         }
> > >  -      if (tgtdev)
> > >  -              mpi3mr_tgtdev_put(tgtdev);
> > >         kfree(mr_sas_port);
> > >         return NULL;
> > >   }
>
> > Are you sure this is correct?
> > Martin's conflict resolution in 0b5b2fb484f3b kept the
>
> >        if (tgtdev)
> >                mpi3mr_tgtdev_put(tgtdev);
>
> > part.
>
> Dunno.  There was another put came in further up the function.

Right. So Martin's resolution looks incorrect, too, as it calls
mpi3mr_tgtdev_put(tgtdev) twice.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: linux-next: manual merge of the scsi-mkp tree with the scsi tree

[Ranjan Kumar]

[-- Attachment #1.1: Type: text/plain, Size: 2575 bytes --]

Hi Geert and Mark,

Author of commit 29e3f0856e854 here - confirming Geert is right, this is a
genuine double-put, not a style difference.

mpi3mr_tgtdev_put() is a plain kref_put(&s->ref_count, mpi3mr_free_tgtdev).
The block earlier in the same function already does the full cleanup on
this error path:

if (tgtdev) {
        tgtdev->dev_spec.sas_sata_inf.pend_sas_rphy_add = 0;
        tgtdev->dev_spec.sas_sata_inf.rphy = NULL;
        mpi3mr_tgtdev_put(tgtdev);
}

The "if (tgtdev) mpi3mr_tgtdev_put(tgtdev)" right before kfree(mr_sas_port)
is a second,
independent fix for the same underlying leak that duplicates it.
With both present, this path releases the reference twice for what should
be a
single release - either double-decrementing a refcount another caller still
relies on,
or touching freed memory if this was the last reference.

The fix is to drop the second occurrence and keep the first,
since it also clears pend_sas_rphy_add/rphy before releasing the reference,
which the duplicate does not:

list_for_each_entry_safe(mr_sas_phy, next, &mr_sas_port->phy_list,
port_siblings) {
mr_sas_phy->phy_belongs_to_port = 0;
list_del(&mr_sas_phy->port_siblings);
}
- if (tgtdev)
- mpi3mr_tgtdev_put(tgtdev);
kfree(mr_sas_port);

Thanks,
Ranjan


On Wed, Sep 30, 2026 at 12:42 PM Geert Uytterhoeven <geert@linux-m68k.org>
wrote:

> Hi Mark,
>
> On Tue, 29 Sept 2026 at 13:07, Mark Brown <broonie@kernel.org> wrote:
> > On Tue, Sep 29, 2026 at 10:48:09AM +0200, Geert Uytterhoeven wrote:
> > > On Mon, 28 Sept 2026 at 16:23, Mark Brown <broonie@kernel.org> wrote:
> >
> > > >         }
> > > >  -      if (tgtdev)
> > > >  -              mpi3mr_tgtdev_put(tgtdev);
> > > >         kfree(mr_sas_port);
> > > >         return NULL;
> > > >   }
> >
> > > Are you sure this is correct?
> > > Martin's conflict resolution in 0b5b2fb484f3b kept the
> >
> > >        if (tgtdev)
> > >                mpi3mr_tgtdev_put(tgtdev);
> >
> > > part.
> >
> > Dunno.  There was another put came in further up the function.
>
> Right. So Martin's resolution looks incorrect, too, as it calls
> mpi3mr_tgtdev_put(tgtdev) twice.
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker.
> But
> when I'm talking to journalists I just say "programmer" or something like
> that.
>                                 -- Linus Torvalds
>

[-- Attachment #1.2: Type: text/html, Size: 3457 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5469 bytes --]

Re: linux-next: manual merge of the scsi-mkp tree with the scsi tree

[Mark Brown]

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

On Wed, Sep 30, 2026 at 03:11:20PM +0530, Ranjan Kumar wrote:
> Hi Geert and Mark,
> 
> Author of commit 29e3f0856e854 here - confirming Geert is right, this is a
> genuine double-put, not a style difference.

You probably want comments for this, the code as it is indended looks
like a bug.

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

Re: linux-next: manual merge of the scsi-mkp tree with the scsi tree

[Martin K. Petersen]

Ranjan,

> The fix is to drop the second occurrence and keep the first, since it
> also clears pend_sas_rphy_add/rphy before releasing the reference,
> which the duplicate does not:

Been traveling for a couple of days. I'll fix first thing tomorrow.

-- 
Martin K. Petersen

linux-next: manual merge of the scsi-mkp tree with the scsi tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the scsi-mkp tree got a conflict in:

  drivers/ufs/core/ufshcd.c

between commit:

  86eb94bf8006 ("scsi: Revert "scsi: ufs: core: Initialize devfreq synchronously"")

from the scsi tree and commit:

  543a827b1db3 ("scsi: core: Clean up struct ufs_saved_pwr_info")

from the scsi-mkp 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.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/ufs/core/ufshcd.c
index c32a927ac5d1,03c47f9a2750..000000000000
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@@ -8422,22 -8429,6 +8422,21 @@@ static int ufshcd_add_lus(struct ufs_hb
  	if (ret)
  		goto out;
  
 +	/* Initialize devfreq after UFS device is detected */
 +	if (ufshcd_is_clkscaling_supported(hba)) {
- 		memcpy(&hba->clk_scaling.saved_pwr_info.info,
++		memcpy(&hba->clk_scaling.saved_pwr_info,
 +			&hba->pwr_info,
 +			sizeof(struct ufs_pa_layer_attr));
- 		hba->clk_scaling.saved_pwr_info.is_valid = true;
 +		hba->clk_scaling.is_allowed = true;
 +
 +		ret = ufshcd_devfreq_init(hba);
 +		if (ret)
 +			goto out;
 +
 +		hba->clk_scaling.is_enabled = true;
 +		ufshcd_init_clk_scaling_sysfs(hba);
 +	}
 +
  	ufs_bsg_probe(hba);
  	ufshpb_init(hba);
  	scsi_scan_host(hba->host);

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

Re: linux-next: manual merge of the scsi-mkp tree with the scsi tree

[James Bottomley]

On Fri, 2018-01-26 at 09:39 +1100, Stephen Rothwell wrote:
> Hi Martin,
> 
> Today's linux-next merge of the scsi-mkp tree got a conflict in:
> 
>   drivers/scsi/qla2xxx/qla_init.c
> 
> between commit:
> 
>   07a21872cf2b ("scsi: qla2xxx: Fix queue ID for async abort with
> Multiqueue")
> 
> from the scsi tree and commit:
> 
>   b027a5ace443 ("scsi: qla2xxx: Fix queue ID for async abort with
> Multiqueue")
> 
> from the scsi-mkp tree.
> 
> Looks like you have updated your tree after James has merged it :-(

OK, I pulled my tree into sync now.  I also added the postmerge tree,
which I can rebase if it causes you similar problems (it's based on the
block tree).

James

linux-next: manual merge of the scsi-mkp tree with the scsi tree

[Stephen Rothwell]

Hi Martin,

Today's linux-next merge of the scsi-mkp tree got a conflict in:

  drivers/scsi/qla2xxx/qla_init.c

between commit:

  07a21872cf2b ("scsi: qla2xxx: Fix queue ID for async abort with Multiqueue")

from the scsi tree and commit:

  b027a5ace443 ("scsi: qla2xxx: Fix queue ID for async abort with Multiqueue")

from the scsi-mkp tree.

Looks like you have updated your tree after James has merged it :-(

I fixed it up (I just used the latter version) 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.



-- 
Cheers,
Stephen Rothwell

linux-next: manual merge of the scsi-mkp tree with the scsi tree

[Stephen Rothwell]

Hi Martin,

Today's linux-next merge of the scsi-mkp tree got a conflict in:

  drivers/scsi/ufs/ufs-qcom.c

Again this is caused by the rebase of the scsi-mkp tree (including
commits already in the scsi tree) followed by more changes to this file.

I fixed it up (I used the scsi-mkp tree version) 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.

-- 
Cheers,
Stephen Rothwell