public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: John David Anglin <dave.anglin@bell.net>,
	Bart Van Assche <bvanassche@acm.org>,
	linux-parisc <linux-parisc@vger.kernel.org>,
	linux-scsi@vger.kernel.org, stable@vger.kernel.org
Subject: Re: Broken Domain Validation in 6.1.84+
Date: Sun, 7 Apr 2024 08:16:06 +0200	[thread overview]
Message-ID: <2024040722-seminar-policy-72d8@gregkh> (raw)
In-Reply-To: <189127aefff8abdabd41312663ee58c06de9de87.camel@HansenPartnership.com>

On Sat, Apr 06, 2024 at 02:51:36PM -0400, James Bottomley wrote:
> [cc stable to see if they have any ideas about fixing this]
> On Sat, 2024-04-06 at 12:16 -0400, John David Anglin wrote:
> > On 2024-04-06 11:06 a.m., James Bottomley wrote:
> > > On Sat, 2024-04-06 at 10:30 -0400, John David Anglin wrote:
> > > > On 2024-04-05 3:36 p.m., Bart Van Assche wrote:
> > > > > On 4/4/24 13:07, John David Anglin wrote:
> > > > > > On 2024-04-04 12:32 p.m., Bart Van Assche wrote:
> > > > > > > Can you please help with verifying whether this kernel warn
> > > > > > > ing is only triggered by the 6.1 stable kernel series or
> > > > > > > whether it is also
> > > > > > > triggered by a vanilla kernel, e.g. kernel v6.8? That will 
> > > > > > > tell us whether we 
> > > > > > > need to review the upstream changes or the backp
> > > > > > > orts on the v6.1 branch.
> > > > > > Stable kernel v6.8.3 is okay.
> > > > > Would it be possible to bisect this issue on the linux-6.1.y
> > > > > branch? That probably will be faster than reviewing all
> > > > > backports
> > > > > of SCSI patches on that branch.
> > > > The warning triggers with v6.1.81.  It doesn't trigger with
> > > > v6.1.80.
> > > It's this patch:
> > > 
> > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.1.y&id=cf33e6ca12d814e1be2263cb76960d0019d7fb94
> > > 
> > > The specific problem being that the update to scsi_execute doesn't
> > > set the sense_len that the WARN_ON is checking.
> > > 
> > > This isn't a problem in mainline because we've converted all uses
> > > of scsi_execute.  Stable needs to either complete the conversion or
> > > back out the inital patch. This change depends on the above change:
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.1.y&id=b73dd5f9997279715cd450ee8ca599aaff2eabb9
> > 
> > Thus, more than just the initial patch needs to be backed out.
> 
> OK, so the reason the bad patch got pulled in is because it's a
> precursor of this fixes tagged backport:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.1.y&id=b73dd5f9997279715cd450ee8ca599aaff2eabb9
> 
> Which is presumably the other patch you had to back out to fix the
> issue.
> 
> The problem is that Mike's series updating and then removing
> scsi_execute() went into the tree as one series, so no-one notice the
> first patch had this bug because the buggy routine got removed at the
> end of the series.  This also means there's nothing to fix and backport
> in upstream.
> 
> The bug is also more widely spread than simply domain validation,
> because every use of scsi_execute in the current stable tree will trip
> this.
> 
> I'm not sure what the best fix is.  I can certainly come up with a one
> line fix for stable adding the missing length in the #define, but it
> can't come from upstream as stated above.  We could back the two
> patches out then do a stable specific fix for the UAS problem (I don't
> think we can leave the UAS patch backed out because the problem was
> pretty serious).
> 
> What does stable want to do?

We want to do whatever is in Linus's tree if at all possible.  Or revert
anything we applied that we shouldn't have.  Either one is fine with us,
just let us know what to do here.

thanks,

greg k-h

  reply	other threads:[~2024-04-07  6:16 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-04 16:20 Broken Domain Validation in 6.1.84+ John David Anglin
2024-04-04 16:32 ` Bart Van Assche
2024-04-04 20:07   ` John David Anglin
2024-04-05 19:36     ` Bart Van Assche
2024-04-06 14:30       ` John David Anglin
2024-04-06 15:06         ` James Bottomley
2024-04-06 16:16           ` John David Anglin
2024-04-06 18:51             ` James Bottomley
2024-04-07  6:16               ` Greg KH [this message]
2024-04-07 13:19             ` Martin K. Petersen
2024-04-08  0:58               ` John David Anglin
2024-04-08 13:46                 ` Martin K. Petersen
2024-04-08 14:17                   ` John David Anglin
2024-04-08 14:32                     ` Martin K. Petersen
2024-04-08 15:17               ` John David Anglin
2024-04-08 17:19                 ` Martin K. Petersen
2024-04-11  4:40                   ` Cyril Brulebois
2024-04-11  7:29                   ` Greg KH

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=2024040722-seminar-policy-72d8@gregkh \
    --to=greg@kroah.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=bvanassche@acm.org \
    --cc=dave.anglin@bell.net \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    /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