linux-kernel - Re: [BUG][bisected 270065e] linux-next fails to boot on powerpc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 17 Aug 2017 17:06:38 +1000
From:   Michael Ellerman <mpe@...erman.id.au>
To:     Bart Van Assche <Bart.VanAssche@....com>,
        "linuxppc-dev\@lists.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
        "abdhalee\@linux.vnet.ibm.com" <abdhalee@...ux.vnet.ibm.com>
Cc:     "sachinp\@linux.vnet.ibm.com" <sachinp@...ux.vnet.ibm.com>,
        "sfr\@canb.auug.org.au" <sfr@...b.auug.org.au>,
        "hare\@suse.com" <hare@...e.com>,
        "martin.petersen\@oracle.com" <martin.petersen@...cle.com>,
        "linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-next\@vger.kernel.org" <linux-next@...r.kernel.org>,
        "hch\@lst.de" <hch@....de>
Subject: Re: [BUG][bisected 270065e] linux-next fails to boot on powerpc

Bart Van Assche <Bart.VanAssche@....com> writes:

> On Wed, 2017-08-16 at 22:30 +0530, Abdul Haleem wrote:
>> As of next-20170809, linux-next on powerpc boot hung with below trace
>> message.
>> [ ... ]
>> System booted fine when the below commit is reverted: 
>
> Hello Abdul,
>
> Can you check whether applying the following commit on top of next-20170809
> fixes this regression:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/commit/?h=4.13/scsi-fixes&id=b0e17a9b0df29590c45dfb296f541270a5941f41

That's already in next-20170816, which still exhibits the bug.

We know that reverting it fixes the bug, but I can also fix it by doing
a partial revert, ie:

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 582769116f66..95f1428c5bc9 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -190,7 +190,9 @@ static void __scsi_queue_insert(struct scsi_cmnd *cmd, int reason, int unbusy)
 	 */
 	cmd->result = 0;
 	if (q->mq_ops) {
-		scsi_mq_requeue_cmd(cmd);
+		struct scsi_device *sdev = cmd->device;
+		blk_mq_requeue_request(cmd->request, true);
+		put_device(&sdev->sdev_gendev);
 		return;
 	}
 	spin_lock_irqsave(q->queue_lock, flags);


That's basically inlining the old version of scsi_mq_requeue_cmd() at
the other call site in __scsi_queue_insert().

Now I guess that was fairly obvious, if you look closely at the commit,
and the fact that we're not hitting the WARN_ON() you added.

Anyway let me know if there's anything else I can try.

cheers