Received: by 10.223.185.116 with SMTP id b49csp8975983wrg; Fri, 2 Mar 2018 11:06:08 -0800 (PST) X-Google-Smtp-Source: AG47ELtQTuUaFCKBGwpMMIqyF8O1nWTX5Egp9He+a6xeNL0lY99v7SWfc8CfwrvT/baNwPs/zSDs X-Received: by 2002:a17:902:f81:: with SMTP id 1-v6mr5924893plz.265.1520017568679; Fri, 02 Mar 2018 11:06:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520017568; cv=none; d=google.com; s=arc-20160816; b=yl8KwDprVWUJ+rtUsFWefQlJ3nI6N2xMkFBlHIMPv107NWHCBrcOmlzavedzNmZrVc HviYCEAWBirEk5XXNV37D6jmIgdNPWAYiIxWCNmfhfNf78Vvog5igGMobWDKmLKhFQZZ /UNs/hSxc6LW7LQ+fp6A0LOMACtm+eh8/VXhVu5YqHJppD1zLK5+eZ3sILoP9C5swJg9 msHwCxsX6H5RnxknVA+0OQ+hUgRRm9P3S4duuBSa1Osl138OCVBs+OnItKmou5RcSCHf RRVzqpqJrjxXXcZr2amEGeYpYIM+2Hb7l6kuYjBC82Ts6s4QL0Vou56f/z0Yc6DM4VBE NIqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=RrUB4RRihTa1VBBa7Cl+KzDYj7J6jx3ZK8Q+osQu/To=; b=Fr/Xh6al0K6z+8NDUI+swfp+qPmunx0MnKwhnv/ws3MvVxaV8SntoPmN1WxLkhqeR4 r0Gs7ZcytsEAs6FleD8SuGQ1qRf+uOXLGioAZd/LyYcQjYOzVp7whf8RvqilAoAH5srn fHjouDsw3lIZS8wk+Hsg7QqiO6YVNCMH0raFf5rtSEd2pI5hX++0GVIy4kNLHH7gqo59 cCJNchTTONCmPtN+6Mgr5fax06elEfoLOzCNw+6k2iZw17VjS6jwVNksnRjXWo9UCX0R OH+BUVuV73+7I5R/cpkkOHejulSubL53v4xxVTMTyIXDFji7rcragFrnHKPvSdAvmtYU ddQQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 64-v6si5295819ply.209.2018.03.02.11.05.53; Fri, 02 Mar 2018 11:06:08 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1428443AbeCBOBE (ORCPT + 99 others); Fri, 2 Mar 2018 09:01:04 -0500 Received: from mx2.suse.de ([195.135.220.15]:55475 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1424382AbeCBOBC (ORCPT ); Fri, 2 Mar 2018 09:01:02 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 5FF85B4D1; Fri, 2 Mar 2018 14:01:01 +0000 (UTC) Date: Fri, 2 Mar 2018 15:00:59 +0100 From: Michal Hocko To: "Lee, Chun-Yi" Cc: "Rafael J . Wysocki" , linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, "Lee, Chun-Yi" , Len Brown Subject: Re: [PATCH] ACPI / scan: Send the change uevent with offine environmental data Message-ID: <20180302140059.GA12772@dhcp22.suse.cz> References: <20180302063508.15818-1-jlee@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180302063508.15818-1-jlee@suse.com> User-Agent: Mutt/1.9.3 (2018-01-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 02-03-18 14:35:08, Lee, Chun-Yi wrote: > In current design of ACPI container offline, Kernel emits > KOBJ_CHANGE uevent to user space to indidate that the ejection of > the container was triggered by platform. (caa73ea15 patch) > > A pure KOBJ_CHANGE uevent is not enough for user space to identify > the purpose. For example, a "udevadm trigger" command can also > be used to emit change event to all udev rules. A udev rule can not > identify that the event is from kernel for offline or from udevadm > for other purpose. Then the offline action in udev rule may also be > triggered by udevadm tool. > > So, similar to the change uevent of dock, kernel sends the > KOBJ_CHANGE uevent with a offline environmental data to indicate > purpose. It's useful by udev rule for using ENV{EVENT} filter. Looks reasonable to me. I have also tested this on Huawei Kunlun server which hits the offline & online storm as a result of udevadm triggered and a container udev rule which hooks into change event and offlines all devices attached to the container. This patch allowed the udev rule to be more targeted at the offline event. > Cc: Michal Hocko > Cc: "Rafael J. Wysocki" > Cc: Len Brown > Signed-off-by: "Lee, Chun-Yi" Acked-by: Michal Hocko Tested-by: Michal Hocko > --- > drivers/acpi/scan.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c > index 8e63d93..f6dca9b 100644 > --- a/drivers/acpi/scan.c > +++ b/drivers/acpi/scan.c > @@ -116,6 +116,7 @@ bool acpi_scan_is_offline(struct acpi_device *adev, bool uevent) > { > struct acpi_device_physical_node *pn; > bool offline = true; > + static const char *envp[] = { "EVENT=offline", NULL }; > > /* > * acpi_container_offline() calls this for all of the container's > @@ -126,7 +127,7 @@ bool acpi_scan_is_offline(struct acpi_device *adev, bool uevent) > list_for_each_entry(pn, &adev->physical_node_list, node) > if (device_supports_offline(pn->dev) && !pn->dev->offline) { > if (uevent) > - kobject_uevent(&pn->dev->kobj, KOBJ_CHANGE); > + kobject_uevent_env(&pn->dev->kobj, KOBJ_CHANGE, envp); > > offline = false; > break; > -- > 2.10.2 -- Michal Hocko SUSE Labs