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  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:   Mon, 16 Jan 2017 06:24:02 -0800
From:   James Bottomley <>
To:     Ingo Molnar <>
Cc:     Andrew Morton <>,
        Linus Torvalds <>,
        Sathya Prakash <>,
        Chaitra P B <>,
        Suganath Prabu Subramani 
        Sreekanth Reddy <>,
        Hannes Reinecke <>,
        linux-scsi <>,
        linux-kernel <>,
        Thomas Gleixner <>
Subject: Re: [PATCH] Revert "scsi: mpt3sas: Fix secure erase premature

On Mon, 2017-01-16 at 10:22 +0100, Ingo Molnar wrote:
> * James Bottomley <> wrote:
> > On Sun, 2017-01-15 at 10:19 +0100, Ingo Molnar wrote:
> > > So there's a new mpt3sas SCSI driver boot regression, introduced
> > > in 
> > > this merge window, which made one of my servers unbootable.
> > 
> > We're not reverting a fix that would cause regressions for others. 
> You really need to reconsider that stance ...
> > However, The fix was manifestly wrong, so does this fix of the fix
> > work for you:
> > 
> >
> > 
> > It's been languishing a bit because no-one seemed to care enough to
> > test or review it.  IOf you can add a tested by, that will give the
> > two
> > we need to push it.
> I have tested your other patch that you pointed to:
> Which patch fixes the bug too (I removed my revert first) - so you
> can add my:
>   Reported-by: Ingo Molnar <>
>   Tested-by: Ingo Molnar <>

Thanks ... just checking you tested the second version with the
concurrency part?

> BTW., is it wise to work around the out of spec firmware in the 
> mpt3sas code and leave the overly optimistic assumptions in the SCSI 
> code intact? The problem is that other SCSI hardware could be 
> affected as well - and especially enterprise class server hardware 
> has long testing and thus regression latencies (as my example
> proves).

Realistically, there is no other card.  Every other SAS implementation
uses the in-kernel SAT, which does the right thing.  We've suggested on
a few occasions that the mpt SAS might like to use it as well, given we
keep tripping on SAT problems in their firmware.

> Wouldn't it be more robust to only submit one pass-through command at 
> a time from the SCSI layer, and maybe opt-in hardware that is known 
> to implement the SAT standard fully?

Unfortunately it's a lot more complex: the standard gives a queueing
mechanism for SAT pass through, so mostly you *can* have multiple
commands outstanding, so it looks like we shouldn't globally restrict
that.  However, it seems the mpt3 firmware is using a queue single
command model *and* not doing the right thing with return codes hence
the failure.  Since the failure mode is mpt3 specific, I think the best
place for the fix is in their code.  We can revisit this decision if
something else comes along that also has this problem (UAS springs to


> (But I'm just kibitzing here really.)

Powered by blists - more mailing lists