linux-kernel - Re: [PATCH] nvme: Fix nvme_get/set_features() with a NULL result pointer

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 for Android: free password hash cracker in your pocket

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

Message-ID: <8f272cfe-6cc9-0699-6613-49dc09152c65@fb.com>
Date:   Fri, 26 Aug 2016 09:06:31 -0600
From:   Jens Axboe <axboe@...com>
To:     Andy Lutomirski <luto@...capital.net>
CC:     <linux-nvme@...ts.infradead.org>,
        Keith Busch <keith.busch@...el.com>,
        Christoph Hellwig <hch@....de>,
        stable <stable@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] nvme: Fix nvme_get/set_features() with a NULL result
 pointer

On 08/26/2016 08:31 AM, Andy Lutomirski wrote:
> On Aug 25, 2016 4:20 PM, "Jens Axboe" <axboe@...com> wrote:
>>
>> On 08/25/2016 01:54 AM, Andy Lutomirski wrote:
>>>
>>> On Thu, Aug 25, 2016 at 12:38 AM, Christoph Hellwig <hch@....de> wrote:
>>>>
>>>> Ooops, yes.
>>>>
>>>> Are you looking into new nvme_set_features users?  Another thing
>>>> we need to tackle is either replacing dma_addr argument with a
>>>> a real kernel pointer (or just kill it until users show up)
>>>
>>>
>>> I am, and I have a patch to do the former (and to add a length
>>> argument).  But that's not -stable material.
>>>
>>> While I have your attention: the new use is to enable APST (power
>>> saving).  In theory, it seems like I should integrate with dev_pm_qos
>>> so that the standard interface for setting a latency limit will work,
>>> but, on brief inspection, there are literally no drivers in the entire
>>> tree that do this.  Am I missing something?  My current draft patch
>>> just adds a sysfs attribute.  (It saves a *lot* of power on my laptop,
>>> so supporting APST is worth doing.)
>>
>>
>> Care to send out what you have? I'd be interested in seeing how much I
>> can save on my laptop, haven't played with APST yet.
>
> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=nvme/power
>
> There are some todos:
>
>  - Default to a nonzero latency (e.g. 7ms?  My SSD needs 5.5ms for max
> power saving.)  To test it, write something like 7000000 to
> apst_max_latency_ns.
>
>  - Add a real changelog.
>
>  - Optionally add a sysfs binfile or other interface to allow
> uploading an entire custom table.
>
>  - Consider *deleting* the SCSI translation layer's power saving code.
> It looks almost entirely bogus to me.  It has an off-by-one in its
> NPSS handling, it hardcodes power state indices which is total BS, it
> ignores the distinction between operational and non-operational states
> (which I think matters for non-APST usage).  It also seems likely to
> be that it's never been used, since it's one of the formerly
> crashy-looking set_features users.
>
> You can inspect what it's doing with something like:
>
> # nvme get-feature -f 0x0c -H -s 0 /dev/nvme0
>
> if you have nvme-cli installed.

Thanks, I'll give it a whirl. One issue in a previous patch - you have
nvme_set_features() take a const buffer, which makes sense. But then you
pass it to __nvme_submit_sync_cmd(), which of course takes both
read/write commands, and hence the buffer isn't const.

-- 
Jens Axboe