Received: by 2002:a05:7412:251c:b0:e2:908c:2ebd with SMTP id w28csp2033273rda; Tue, 24 Oct 2023 10:12:02 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHc+F0jhCTkE33mOVFb05DnFF+sMXHhnGQh9QJsfdCYu+qMKmzugmSIgBdW7lasRwvq08pe X-Received: by 2002:a05:6358:f55:b0:168:e366:6139 with SMTP id c21-20020a0563580f5500b00168e3666139mr4964597rwj.11.1698167522142; Tue, 24 Oct 2023 10:12:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698167522; cv=none; d=google.com; s=arc-20160816; b=DTjmqb9V3NA/vzms1PTUtZKw0fhj9RckWy6dvDGiPUxo33KIWVZDODVK/Apuk1hlYl Nbj9QcCmsXGQf7+A9XMaVU2g2yI1lZ9kR1cj7z19MkNub759/sLPCKDNbpQyGm5Uo8FD FYF2KHtqhHdSoGYerlIR8F21aDXe5RPFva/gNbEx0Ke4fd9mTimao1CjMhflRRf4xC/K aUD2QGg/MAlrKj4396U3zZ7DJkgSRo73NEplm2g/JzmNAVMBwnnkgx9o0rgMlJTcTikd aY6AbOgw3U2ZrrY6yM+Q9vK9KcCE1hRpP4Zsvv/k9/TQkpw3v2Ly6Br42JtN+eRqSwcp XY8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=o1khzDX1keNEyWsPgh3vfJw+ISuLV9hIPkHVBRhgdOU=; fh=vKiCxiLdrAbrgKNAGM5vEdqbxtXvr2eAEBvG7fBtjBc=; b=xNULalZlGOMDWaPsCTsaUKOaeaRECLaoXkl37SetVHjgU298zc+tV2oH7cjZ2iFiW3 5rf4PsWwLOJjzyt4fVrhuRiQjDA104wDGq6o/QPAaQBd8RNzkxmFX3pA7vxBFRm2xScT RclLYK41pDVQD6XCCb9s1zhpoelSqLMj6iaAKIBCPLEmc3FAdGejUW49ZC/Bm8mVyAlu Lg8B/WH/1WZRYWFB5bl4zEjWRbmrl7JQVrUqnckc3aKQDE4AMQk2oD9ByYscS71rVuc3 R6vWwhLcGP8k0dxt3+Nvg/+yCKLt1BZHXncMZ79yW1ZFZg/r05TxBdfCfMawGtx0AoIJ Ohyg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="W/C1GcAH"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from fry.vger.email (fry.vger.email. [23.128.96.38]) by mx.google.com with ESMTPS id r198-20020a632bcf000000b005acd2009192si9132715pgr.13.2023.10.24.10.11.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Oct 2023 10:12:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="W/C1GcAH"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id 446FE80707A7; Tue, 24 Oct 2023 10:11:48 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234854AbjJXRLk (ORCPT + 99 others); Tue, 24 Oct 2023 13:11:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43284 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230262AbjJXRLh (ORCPT ); Tue, 24 Oct 2023 13:11:37 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0752D186 for ; Tue, 24 Oct 2023 10:11:35 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 400C6C433C9; Tue, 24 Oct 2023 17:11:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1698167494; bh=3daQE+NKeT2HgtEmf8nv00ubawI1EkzNRd4aZ5XC2fE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=W/C1GcAHsAqVHg9ylfxZ1lKouys91bX4NLLWD+AIgIn8aJ9SDVb6DWH1F0X3hGrHk dwxOjapptyaddgVg5onSzACP+m4XCbN9ozTP1K9Ee1oLeH4uZ138wzh0cSWqEFazh0 Y5t9kq5GW5KP8R4ShzIJQX7MCz/S11EmvoZDgpt0= Date: Tue, 24 Oct 2023 19:11:31 +0200 From: "gregkh@linuxfoundation.org" To: Alan Stern Cc: "Li, Meng" , "linux-usb@vger.kernel.org" , "usb-storage@lists.one-eyed-alien.net" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] usb: storage: add shutdown function for usb storage driver Message-ID: <2023102459-protector-frequency-1033@gregkh> References: <20231023054111.2744872-1-Meng.Li@windriver.com> <33bd0779-bfe7-4c87-8fe6-ea8455df3b6b@rowland.harvard.edu> <3fe5b43c-a5aa-4c6a-8614-03a4d9dd53e2@rowland.harvard.edu> <2023102428-zit-quickness-9b73@gregkh> <5107f6ca-e972-4af1-a21d-6c95778969f3@rowland.harvard.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5107f6ca-e972-4af1-a21d-6c95778969f3@rowland.harvard.edu> X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Tue, 24 Oct 2023 10:11:48 -0700 (PDT) On Tue, Oct 24, 2023 at 11:58:37AM -0400, Alan Stern wrote: > On Tue, Oct 24, 2023 at 05:45:40PM +0200, gregkh@linuxfoundation.org wrote: > > On Tue, Oct 24, 2023 at 11:35:19AM -0400, Alan Stern wrote: > > > Okay, that's a different matter. In fact, I don't know what is supposed > > > to happen during a clean reboot. > > > > Define "clean" :) > > In this case, I mean what happens when you give the "reboot" command. That's a userspace binary/script/whatever that can do loads of different things not involving the kernel, so it all depends on the user's system as to what will happen here. Many "good" userspace implementation of reboot will go and sync and unmount all mounted disks in the correct order, before the kernel is told to reboot. All we can do in the kernel is act on the reboot system call. So perhaps the original poster here can see why his userspace isn't correctly shutting down their storage devices? > > reboot is a system thing that happens before the reboot syscall happens. > > So which are we talking nabout here? > > > > > Greg, do you know? Should we take the time to disconnect all the USB > > > devices during a system shutdown? > > > > In the past we have not. And if we switch to do so, we might get some > > complaints as we would now delaying the shutdown process to be longer > > than before. > > Yes, that's what I'm afraid of. > > > > What happens with non-USB disk drives? Or other removable devices? > > > > It would have to come from "above" in the device tree, so does the PCI > > or platform bus say that they should be shut down and their child > > devices? > > Well, the PCI layer invokes the HCD's ->shutdown callback. But the > usb-storage driver and usbcore don't know this has happened, so they > start logging errors because they are suddenly unable to communicate > with a USB drive. Meng Li is unhappy about these error messages. > > Adding a shutdown callback of sorts to usb-storage allows the driver to > know that it shouldn't communicate with the drive any more, which > prevents the error message from appearing. That's what this patch does. > > But that's all it does. Basically it creates a layering violation just > to prevent some error messages from showing up in the system log during > a shutdown or reboot. The question is whether we want to do this at > all, and if we do, shouldn't it be handled at the usbcore level rather > than just within usb-storage? We should do this within the usb core if we care about it, but why did the USB device suddenly go away before the USB storage driver was told about it? That feels like something else is pulling the power on the device that is out-of-band here. thanks, greg k-h