Linux kernel -stable discussions
 help / color / mirror / Atom feed
* LTS 5.15 and state of lpfc
@ 2022-10-24  2:25 James Smart
  2022-10-24  4:08 ` Greg Kroah-Hartman
  0 siblings, 1 reply; 3+ messages in thread
From: James Smart @ 2022-10-24  2:25 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin, stable; +Cc: Martin K. Petersen, Justin Tee

Greg, Sasha,

We were notified of an lpfc issue in the LTS 5.15 kernel. Its a pretty 
fundamental error that keeps us from connecting to the FC switch.

In the past several kernel releases, we have been reworking areas of the 
driver to fix issues in the broader design rather than continuing to 
create a patchwork on an issue-by-issue basis. This means there are a 
lot of inter-related patches.

In this case, it appears that a portion of the "path split" rework was 
pulled into 5.15, and the portion that wasn't picked up introduced the 
error.

I had Justin look at simply reverting patches, which wasn't too bad, but 
we have identified an issue in the result. The fix, of course, is 
embedded into the "path split" patches.

I don't think we want to create one-off patches that won't move forward, 
so I had him look at rolling forward to pick up all the "path split" 
patches. This looks like a fairly viable alternative.  The steps are 
listed below. This brings it up to a point that is pretty close to the 
content in 5.18.y

How do we best resolve this in the 5.15 LTS tree ?

-- james



Here are the steps to roll-forward:


1.) git remote add -t 6.1/scsi-staging mkp-scsi 
https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git
2.) git fetch mkp-scsi
3.) git rebase -i 1c5e670d6a5a~

4.) Remove the following commits:
1c5e670d6a5a scsi: lpfc: SLI path split: Refactor lpfc_iocbq
c56cc7fefc31 scsi: lpfc: SLI path split: Refactor fast and slow paths to 
native SLI4
b4543dbea84c scsi: lpfc: SLI path split: Refactor SCSI paths
2b5ef6430c21 scsi: lpfc: Remove extra atomic_inc on cmd_pending in 
queuecommand after VMID
9a570069cdbb scsi: lpfc: Fix locking for lpfc_sli_iocbq_lookup()
6e99860de6f4 scsi: lpfc: Fix element offset in __lpfc_sli_release_iocbq_s4()
17bf429b913b scsi: lpfc: Resolve some cleanup issues following SLI path 
refactoring

Rebase is expected to be clean after removal of mentioned patches.

5.) Cherry-pick SLI path split patches from mkp-scsi:
git cherry-pick a680a9298e7b 1b64aa9eae28 561341425bcc 6831ce129f19 
cad93a089031 3bea83b68d54 3f607dcb43f1 e0367dfe90d6 9d41f08aa2eb 
351849800157 2d1928c57df6 61910d6a5243 3512ac094293 31a59f75702f 
0e082d926f59

6.) Cherry-pick the atomic_inc VMID fix:
git cherry-pick 0948a9c53860

7.) Cherry-pick all known SLI path split fixes:
git cherry-pick 7294a9bcaa7e c26bd6602e1d c2024e3b33ee cc28fac16ab7 
775266207105 84c6f99e3907 596fc8adb171 44ba9786b673 24e1f056677e 
e27f05147bff

All the cherry-picks are expected to apply cleanly.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: LTS 5.15 and state of lpfc
  2022-10-24  2:25 LTS 5.15 and state of lpfc James Smart
@ 2022-10-24  4:08 ` Greg Kroah-Hartman
  2022-10-24 14:01   ` James Smart
  0 siblings, 1 reply; 3+ messages in thread
From: Greg Kroah-Hartman @ 2022-10-24  4:08 UTC (permalink / raw)
  To: James Smart; +Cc: Sasha Levin, stable, Martin K. Petersen, Justin Tee

On Sun, Oct 23, 2022 at 07:25:05PM -0700, James Smart wrote:
> Greg, Sasha,
> 
> We were notified of an lpfc issue in the LTS 5.15 kernel. Its a pretty
> fundamental error that keeps us from connecting to the FC switch.
> 
> In the past several kernel releases, we have been reworking areas of the
> driver to fix issues in the broader design rather than continuing to create
> a patchwork on an issue-by-issue basis. This means there are a lot of
> inter-related patches.
> 
> In this case, it appears that a portion of the "path split" rework was
> pulled into 5.15, and the portion that wasn't picked up introduced the
> error.
> 
> I had Justin look at simply reverting patches, which wasn't too bad, but we
> have identified an issue in the result. The fix, of course, is embedded into
> the "path split" patches.
> 
> I don't think we want to create one-off patches that won't move forward, so
> I had him look at rolling forward to pick up all the "path split" patches.
> This looks like a fairly viable alternative.  The steps are listed below.
> This brings it up to a point that is pretty close to the content in 5.18.y
> 
> How do we best resolve this in the 5.15 LTS tree ?
> 
> -- james
> 
> 
> 
> Here are the steps to roll-forward:
> 
> 
> 1.) git remote add -t 6.1/scsi-staging mkp-scsi
> https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git
> 2.) git fetch mkp-scsi
> 3.) git rebase -i 1c5e670d6a5a~

What will the rebase -i do?

> 
> 4.) Remove the following commits:
> 1c5e670d6a5a scsi: lpfc: SLI path split: Refactor lpfc_iocbq
> c56cc7fefc31 scsi: lpfc: SLI path split: Refactor fast and slow paths to
> native SLI4
> b4543dbea84c scsi: lpfc: SLI path split: Refactor SCSI paths
> 2b5ef6430c21 scsi: lpfc: Remove extra atomic_inc on cmd_pending in
> queuecommand after VMID
> 9a570069cdbb scsi: lpfc: Fix locking for lpfc_sli_iocbq_lookup()
> 6e99860de6f4 scsi: lpfc: Fix element offset in __lpfc_sli_release_iocbq_s4()
> 17bf429b913b scsi: lpfc: Resolve some cleanup issues following SLI path
> refactoring
> 
> Rebase is expected to be clean after removal of mentioned patches.

Ah, you want the rebase to just remove the commits.  That is nice, but
we can't do that as part of a released branch for obvious reasons.

We need real reverts.

> 5.) Cherry-pick SLI path split patches from mkp-scsi:
> git cherry-pick a680a9298e7b 1b64aa9eae28 561341425bcc 6831ce129f19
> cad93a089031 3bea83b68d54 3f607dcb43f1 e0367dfe90d6 9d41f08aa2eb
> 351849800157 2d1928c57df6 61910d6a5243 3512ac094293 31a59f75702f
> 0e082d926f59

All of these commits are already in Linus's tree, right?  So why do we
need an additional branch?

> 
> 6.) Cherry-pick the atomic_inc VMID fix:
> git cherry-pick 0948a9c53860
> 
> 7.) Cherry-pick all known SLI path split fixes:
> git cherry-pick 7294a9bcaa7e c26bd6602e1d c2024e3b33ee cc28fac16ab7
> 775266207105 84c6f99e3907 596fc8adb171 44ba9786b673 24e1f056677e
> e27f05147bff
> 
> All the cherry-picks are expected to apply cleanly.

Can you just send a patch series that does all of this so that we know
it is correct and works properly?  I'll be glad to take that into
5.15.y.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: LTS 5.15 and state of lpfc
  2022-10-24  4:08 ` Greg Kroah-Hartman
@ 2022-10-24 14:01   ` James Smart
  0 siblings, 0 replies; 3+ messages in thread
From: James Smart @ 2022-10-24 14:01 UTC (permalink / raw)
  To: Greg Kroah-Hartman; +Cc: Sasha Levin, stable, Martin K. Petersen, Justin Tee

On 10/23/2022 9:08 PM, Greg Kroah-Hartman wrote:
> 
> Can you just send a patch series that does all of this so that we know
> it is correct and works properly?  I'll be glad to take that into
> 5.15.y.
> 
> thanks,
> 
> greg k-h

Yep. I wasn't sure how you wanted to approach it.

-- james


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-10-24 15:44 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-10-24  2:25 LTS 5.15 and state of lpfc James Smart
2022-10-24  4:08 ` Greg Kroah-Hartman
2022-10-24 14:01   ` James Smart

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox