linux-kernel - Re: [PATCH v2 1/2] nvme-apple: Reset controller during shutdown

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: <60A924B7-9F29-4AF1-9DF8-EA90DBA48B3E@marcan.st>
Date:   Thu, 19 Jan 2023 16:58:29 +0900
From:   "Hector Martin \"marcan\"" <marcan@...can.st>
To:     Christoph Hellwig <hch@....de>, Janne Grunau <j@...nau.net>
CC:     Sven Peter <sven@...npeter.dev>, Keith Busch <kbusch@...nel.org>,
        Jens Axboe <axboe@...com>, Sagi Grimberg <sagi@...mberg.me>,
        Alyssa Rosenzweig <alyssa@...enzweig.io>,
        Eric Curtin <ecurtin@...hat.com>, asahi@...ts.linux.dev,
        linux-arm-kernel@...ts.infradead.org,
        linux-nvme@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] nvme-apple: Reset controller during shutdown

(Replying from mobile, please excuse formatting)

I'm actually not sure exactly how this works any more. The previous series I sent (which had slightly different logic) worked for me on a t8103 Mac Mini in smoke tests and I'd assumed fixed the issue, but it turned out to fail (in a different way) on other machines/circumstances. This one seems to work everywhere, but I can't explain exactly why. Maybe we do in fact need to issue an NVMe disable before shutting down the firmware to reliably come up properly on firmware restart.

Maybe something like this?

/*
 * Always disable the NVMe controller after shutdown.
 * We need to do this to bring it back up later anyway,
 * and we can't do it while the firmware is not running
 * (e.g. in the resume reset path before RTKit is
 * initialized), so for Apple controllers it makes sense to
 * unconditionally do it here. Additionally, this sequence
 * of events is reliable, while others (like disabling after
 * bringing back the firmware on resume) seem to run
 * into trouble under some circumstances.
 *
 * Both U-Boot and m1n1 also use this convention
 * (i.e. an ANS NVMe controller is handed off with
 * firmware shut down, in an NVMe disabled state,
 * after a clean shutdown).
 */

On 2023年1月19日 15:14:52 JST, Christoph Hellwig <hch@....de> wrote:
>Folks, can you chime in if this comment makes sense?  I'd really
>like to send the patches off to Jens before rc5.
>
>On Wed, Jan 18, 2023 at 06:24:50AM +0100, Christoph Hellwig wrote:
>> On Tue, Jan 17, 2023 at 07:25:00PM +0100, Janne Grunau wrote:
>> > +		/*
>> > +		 * Always reset the NVMe controller on shutdown. The reset is
>> > +		 * required to shutdown the co-processor cleanly.
>> > +		 */
>> 
>> Hmm.  This comment doesn't seem to match the discussion we had last
>> week.  Which would be:
>> 
>> 		/*
>> 		 * NVMe requires a reset before setting up a controller to
>> 		 * ensure it is in a clean state.  For NVMe PCIe this is
>> 		 * done in the setup path to be able to deal with controllers
>> 		 * in any kind of state.  For for Apple devices, the firmware
>> 		 * will not be available at that time and the reset will
>> 		 * time out.  Thus reset after shutting the NVMe controller
>> 		 * down and before shutting the firmware down.
>> 		 */
>---end quoted text---
>

-- 
Hector Martin "marcan" (marcan@...can.st)
Public key: https://mrcn.st/pub