linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oliver Sang <oliver.sang@intel.com>
To: Christoph Hellwig <hch@lst.de>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux Memory Management List <linux-mm@kvack.org>,
	lkp@lists.01.org, lkp@intel.com
Subject: Re: [scsi]  61b3baad24: last_state.load_disk_fail
Date: Fri, 3 Sep 2021 14:28:00 +0800	[thread overview]
Message-ID: <20210903062800.GB29784@xsang-OptiPlex-9020> (raw)
In-Reply-To: <20210820091627.GA6035@lst.de>

Hi, Christoph Hellwig,

On Fri, Aug 20, 2021 at 11:16:27AM +0200, Christoph Hellwig wrote:
> On Fri, Aug 20, 2021 at 03:40:13PM +0800, Oliver Sang wrote:
> > Hi, Christoph Hellwig,
> > 
> > recently we checked this commit again, and find it has a new commit id
> > as well as the parent:
> >     f2542a3be3277 scsi: scsi_ioctl: Move the "block layer" SCSI ioctl handling to drivers/scsi
> >     7353dc06c9a8e scsi: scsi_ioctl: Simplify SCSI passthrough permission checking
> > 
> > so we tested it again, and found the issue is still reproduced in
> > our environment persistently.
> > 
> > we also tried another platform, and could reproduce, too.
> >     Intel(R) Xeon(R) CPU E7-8890 v3 @ 2.50GHz
> > 
> > in parent dmesg (attached as dmesg-7353dc06c9.xz),
> > it's clear that the disk mounted without problem:
> > [   31.549031][ T1791] XFS (sda1): Mounting V5 Filesystem
> > [   31.591680][ T1791] XFS (sda1): Starting recovery (logdev: internal)
> > [   31.608990][ T1791] XFS (sda1): Ending recovery (logdev: internal)
> > [   31.625155][ T1791] xfs filesystem being mounted at /opt/rootfs supports timestamps until 2038 (0x7fffffff)
> > 
> > but in the dmesg for commit f2542a3be3277 (attached as dmesg-f2542a3be3.xz),
> > which is from the identical test environment except kernel,
> > just failed like below:
> > [   62.411699][ T1661] can't load the disk /dev/disk/by-id/ata-INTEL_SSDSC2BA400G4_BTHV634503K3400NGN-part1, skip testing...
> 
> Really strange.  This message is printed when wait_load_disk fails.
> 
> The kernel has probed all disks before, then apparently something
> is installed using dpkg and then it waits for this rootfs (which
> obviously isn't the root at that point).
> 
> Also at least on my debian testing and oldstable systems a plain
> blkid call never even calls SG_IO or related ioctls (which makes sense
> given that it looks at the file system labels).
> 
> Does tis issue just show up on one particular system or on multiple
> different ones?

we observed this on multiple platforms,
and now we confirmed this was fixed by below commit:

commit 04a71cdc46a94b13ee876290ad961b4886e24c76
Author:     Halil Pasic <pasic@linux.ibm.com>
AuthorDate: Mon Aug 23 15:34:58 2021 +0200
Commit:     Martin K. Petersen <martin.petersen@oracle.com>
CommitDate: Tue Aug 24 22:56:32 2021 -0400

    scsi: core: scsi_ioctl: Fix error code propagation in SG_IO

    Link: https://lore.kernel.org/r/20210823133458.3536824-1-pasic@linux.ibm.com
    Fixes: f2542a3be327 ("scsi: scsi_ioctl: Move the "block layer" SCSI ioctl handling to drivers/scsi")
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

diff --git a/drivers/scsi/scsi_ioctl.c b/drivers/scsi/scsi_ioctl.c
index 7b2b0a1581f4f..6ff2207bd45a0 100644
--- a/drivers/scsi/scsi_ioctl.c
+++ b/drivers/scsi/scsi_ioctl.c
@@ -874,7 +874,7 @@ static int scsi_ioctl_sg_io(struct scsi_device *sdev, struct gendisk *disk,
                return error;
        if (put_sg_io_hdr(&hdr, argp))
                return -EFAULT;
-       return 0;
+       return error;
 }

 /**



      reply	other threads:[~2021-09-03  6:10 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-29  8:25 kernel test robot
2021-08-20  7:40 ` Oliver Sang
2021-08-20  9:16   ` Christoph Hellwig
2021-09-03  6:28     ` Oliver Sang [this message]

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=20210903062800.GB29784@xsang-OptiPlex-9020 \
    --to=oliver.sang@intel.com \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lkp@intel.com \
    --cc=lkp@lists.01.org \
    --cc=martin.petersen@oracle.com \
    --subject='Re: [scsi]  61b3baad24: last_state.load_disk_fail' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).