linux-kernel - Re: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

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:   Fri, 19 May 2017 11:24:39 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     Keith Busch <keith.busch@...el.com>
Cc:     Christoph Hellwig <hch@...radead.org>,
        Andy Lutomirski <luto@...nel.org>,
        Jens Axboe <axboe@...nel.dk>, Sagi Grimberg <sagi@...mberg.me>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-nvme <linux-nvme@...ts.infradead.org>,
        Kai-Heng Feng <kai.heng.feng@...onical.com>,
        Mario Limonciello <mario_limonciello@...l.com>,
        Christoph Hellwig <hch@....de>
Subject: Re: [PATCH] nvme: Change our APST table to be no more aggressive than
 Intel RSTe

On Fri, May 19, 2017 at 7:18 AM, Keith Busch <keith.busch@...el.com> wrote:
> On Thu, May 18, 2017 at 11:35:05PM -0700, Christoph Hellwig wrote:
>> On Thu, May 18, 2017 at 06:13:55PM -0700, Andy Lutomirski wrote:
>> > a) Leave the Dell quirk in place until someone from Dell or Samsung
>> > figures out what's actually going on.  Add a blanket quirk turning off
>> > the deepest sleep state on all Intel devices [1] at least until
>> > someone from Intel figures out what's going on -- Hi, Keith!  Deal
>> > with any other problems as they're reported.
>>
>> I think we should just blacklist the 60p entirely.  It also seems to
>> corrupt data 100% reliable when used with XFS.
>
> I assume you're talking about the 600p/p3100. That family of devices
> prefer 4k alignment, and patch below will enforce that, fixing all
> access issues. I wasn't planning to post it because my understanding is
> an imminent f/w update will make it unnecessary.
>
> I understand there is a different issue specific to the KBL NUC platforms
> that exposes some other errata, but I don't know much about that.

We can quirk by firmware version.  The report said:

vid : 0x8086
ssvid : 0x8086
sn : BTPY63850F281P0H
mn : INTEL SSDPEKKW010T7
fr : PSF104C

Any chance you can check what firmware versions have the issue?

--Andy