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]

Message-ID: <yq1h8x0ekf3.fsf@oracle.com>
Date:   Mon, 21 Aug 2017 16:27:12 -0400
From:   "Martin K. Petersen" <martin.petersen@...cle.com>
To:     Brian King <brking@...ux.vnet.ibm.com>
Cc:     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>,
        "linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
        "hch\@lst.de" <hch@....de>,
        "linux-scsi\@vger.kernel.org" <linux-scsi@...r.kernel.org>,
        "sfr\@canb.auug.org.au" <sfr@...b.auug.org.au>,
        "sachinp\@linux.vnet.ibm.com" <sachinp@...ux.vnet.ibm.com>,
        "linux-next\@vger.kernel.org" <linux-next@...r.kernel.org>,
        "hare\@suse.com" <hare@...e.com>,
        "mpe\@ellerman.id.au" <mpe@...erman.id.au>
Subject: Re: [BUG][bisected 270065e] linux-next fails to boot on powerpc


Brian,

>> Thanks for the detailed analysis. This is very helpful. Have you
>> considered to change the ipr driver such that it terminates REPORT
>> SUPPORTED OPERATION CODES commands with the appropriate check
>> condition code instead of DID_ERROR?
>
> Yes. That data is actually in the sense buffer, but since I'm also
> setting DID_ERROR, scsi_decide_disposition isn't using it. I've got a
> patch to do just as you suggest, to stop setting DID_ERROR when there
> is more detailed error data available, but it will need some
> additional testing before I submit, as it will impact much more than
> just this case.

I agree. In this case where a command is not supported, a check
condition would be a better way to signal the failure to the SCSI
midlayer.

-- 
Martin K. Petersen	Oracle Linux Engineering