From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 544F3C433E0 for ; Thu, 30 Jul 2020 15:54:45 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C3A03206F5 for ; Thu, 30 Jul 2020 15:54:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C3A03206F5 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=canonical.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 4BHZjX3MnSzDqDW for ; Fri, 31 Jul 2020 01:54:40 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=canonical.com (client-ip=91.189.89.112; helo=youngberry.canonical.com; envelope-from=cascardo@canonical.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=fail (p=none dis=none) header.from=canonical.com Received: from youngberry.canonical.com (youngberry.canonical.com [91.189.89.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4BHZHF56n6zDqf4 for ; Fri, 31 Jul 2020 01:35:21 +1000 (AEST) Received: from 1.general.cascardo.us.vpn ([10.172.70.58] helo=mussarela) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1k1AaI-0006gK-Tp; Thu, 30 Jul 2020 15:35:07 +0000 Date: Thu, 30 Jul 2020 12:35:02 -0300 From: Thadeu Lima de Souza Cascardo To: Greg KH Subject: Re: [PATCH v2] powerpc/vio: drop bus_type from parent device Message-ID: <20200730153502.GD6828@mussarela> References: <20200406155748.6761-1-cascardo@canonical.com> <87ime56bax.fsf@mpe.ellerman.id.au> <20200730053716.GA3862178@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200730053716.GA3862178@kroah.com> X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Rajnoha , linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Thu, Jul 30, 2020 at 07:37:16AM +0200, Greg KH wrote: > On Thu, Jul 30, 2020 at 11:28:38AM +1000, Michael Ellerman wrote: > > [ Added Peter & Greg to Cc ] > > > > Thadeu Lima de Souza Cascardo writes: > > > Commit df44b479654f62b478c18ee4d8bc4e9f897a9844 ("kobject: return error > > > code if writing /sys/.../uevent fails") started returning failure when > > > writing to /sys/devices/vio/uevent. > > > > > > This causes an early udevadm trigger to fail. On some installer versions of > > > Ubuntu, this will cause init to exit, thus panicing the system very early > > > during boot. > > > > > > Removing the bus_type from the parent device will remove some of the extra > > > empty files from /sys/devices/vio/, but will keep the rest of the layout > > > for vio devices, keeping them under /sys/devices/vio/. > > > > What exactly does it change? > > > > I'm finding it hard to evaluate if this change is going to cause a > > regression somehow. > > > > I'm also not clear on why removing the bus type is correct, apart from > > whether it fixes the bug you're seeing. > > > > > It has been tested that uevents for vio devices don't change after this > > > fix, they still contain MODALIAS. > > > > > > Signed-off-by: Thadeu Lima de Souza Cascardo > > > Fixes: df44b479654f ("kobject: return error code if writing /sys/.../uevent fails") > > > > AFAICS there haven't been any other fixes for that commit. Do we know > > why it is only vio that was affected? (possibly because it's a fake bus > > to begin with?) > > So there was an error previously, the core was ignoring it, and now it > isn't and to fix that you want to remove describing what bus a device is > on? > > Huh??? > > > > > cheers > > > > > diff --git a/arch/powerpc/platforms/pseries/vio.c b/arch/powerpc/platforms/pseries/vio.c > > > index 37f1f25ba804..a94dab3972a0 100644 > > > --- a/arch/powerpc/platforms/pseries/vio.c > > > +++ b/arch/powerpc/platforms/pseries/vio.c > > > @@ -36,7 +36,6 @@ static struct vio_dev vio_bus_device = { /* fake "parent" device */ > > > .name = "vio", > > > .type = "", > > > .dev.init_name = "vio", > > > - .dev.bus = &vio_bus_type, > > > }; > > Wait, a static 'struct device'? You all are playing with fire there. > That's a reference counted object, and should never be declared like > that at all. > > I see you register it, but never unregister it, why? Why is it even > needed? > > And if you remove the bus type of it, it will show up in a different > part of sysfs, so I think this patch will show a user-visable change, > right? > > thanks, > > greg k-h As the comment says, it's a "fake parent device". There is a user-visible change, which is removing some attributes from the object, but it's still showing up on the same path. Returning an error code like df44b479654f does is also a user visible change and it breaks installer images that panic early on boot. I could investigate an alternative here, which would be not fail when writing to uevent for this specific fake device. Cascardo.