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=-9.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 57B18C433E1 for ; Mon, 13 Jul 2020 16:09:34 +0000 (UTC) Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (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 22BEF2076D for ; Mon, 13 Jul 2020 16:09:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="r7ELJ2cB" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 22BEF2076D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-nvdimm-bounces@lists.01.org Received: from ml01.vlan13.01.org (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 17F6E1181290E; Mon, 13 Jul 2020 09:09:34 -0700 (PDT) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2a00:1450:4864:20::543; helo=mail-ed1-x543.google.com; envelope-from=dan.j.williams@intel.com; receiver= Received: from mail-ed1-x543.google.com (mail-ed1-x543.google.com [IPv6:2a00:1450:4864:20::543]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 16E47118128FB for ; Mon, 13 Jul 2020 09:09:30 -0700 (PDT) Received: by mail-ed1-x543.google.com with SMTP id by13so14127687edb.11 for ; Mon, 13 Jul 2020 09:09:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XPX1344KqFXDG152MSs7m1f71nuvQxMI0VbbfK01bWI=; b=r7ELJ2cBdTaQzo9pqUPojaVz6tHhKqoH2KZY2zuAlJN0hbnOqbT4c12Oy38pcBR/Nj utOjvomkH01KnV48ustA657XHya8dxhiC4zKoTXDfmRE5M9q3CaTL/2f1Ttg6runvIq7 RWnzutbQaMQZuQkbRYM6KLs9dYVs2pWP8m2YSi7TYPnwA2kYkHbV3zTVnZD3+aGspwQv visTBbIeQ8KXGdQAzK/GZmGnfQOSTPpyx1Y/65IykomzQzj2jp7TFsb05AzbD0WDujBa O7/7Q4OI36y4JCe9b58Hkm5W/23aJBSWmta1Co+BkMqTd+7t5uECfERRweordez+CtHr OHsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XPX1344KqFXDG152MSs7m1f71nuvQxMI0VbbfK01bWI=; b=aQy+RAP3Yp73dW3FS5PIU3oeuQQHL1Gud4+ZPU+w8XKnI3EFyl2G4lwLTCkoALLJCT DJCWBfDPwls1k2LG+KvXPc6+npuGZ+yOg8eL7oAOeZvdPkZpOfuqI67Ks4T87c5dc1ae RP3ktShAMjntfffwyGxA+YtdXgnxyA59DzS2j0AD9l68aopCDKERwDwnuYhTYlqPdi+m uL4Ci8AvQE/8bIFHxQUov4aEFwakT8HXHsR9lGRRFb8LepplBP/pjxpt/InylSG5aJQA UwhEgZcRoSgz2+psr2xXgGQcWbIx6CJOvopEhIbSY+OPpWlKZw8veb5EP2ISzNgP7onz XIOg== X-Gm-Message-State: AOAM533wI1WDGcNtgUUYwiOlfAGITMg1YDMQng78jcZkqBuGq1jfxIy8 J5KxiZGdXAzkClTI1HDV1TGk9fyVNd/B1X27SstuNA== X-Google-Smtp-Source: ABdhPJzkfFp48TgN6o9u+tichXDgD3w2nI1pgUIrildgifHznsxd6AynKdQoAl6SqJnCRUpI/mZg24+ERLg8WLos9MU= X-Received: by 2002:a50:ee8a:: with SMTP id f10mr95726edr.383.1594656569387; Mon, 13 Jul 2020 09:09:29 -0700 (PDT) MIME-Version: 1.0 References: <159457116473.754248.7879464730875147365.stgit@dwillia2-desk3.amr.corp.intel.com> <159457125753.754248.6000936585361264069.stgit@dwillia2-desk3.amr.corp.intel.com> <20200712170945.GA194499@kroah.com> <20200713155222.GB267581@kroah.com> In-Reply-To: <20200713155222.GB267581@kroah.com> From: Dan Williams Date: Mon, 13 Jul 2020 09:09:18 -0700 Message-ID: Subject: Re: [PATCH v2 17/22] drivers/base: Make device_find_child_by_name() compatible with sysfs inputs To: Greg Kroah-Hartman Message-ID-Hash: WA2XNDJZBZL537BTVWFKTJJRSGUE7C6S X-Message-ID-Hash: WA2XNDJZBZL537BTVWFKTJJRSGUE7C6S X-MailFrom: dan.j.williams@intel.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header CC: linux-nvdimm , "Rafael J. Wysocki" , Peter Zijlstra , Dave Hansen , Ard Biesheuvel , Linux MM , Linux Kernel Mailing List , Linux ACPI , Christoph Hellwig , Joao Martins X-Mailman-Version: 3.1.1 Precedence: list List-Id: "Linux-nvdimm developer list." Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Mon, Jul 13, 2020 at 8:52 AM Greg Kroah-Hartman wrote: > > On Mon, Jul 13, 2020 at 08:39:43AM -0700, Dan Williams wrote: > > On Sun, Jul 12, 2020 at 10:09 AM Greg Kroah-Hartman > > wrote: > > > > > > On Sun, Jul 12, 2020 at 09:27:37AM -0700, Dan Williams wrote: > > > > Use sysfs_streq() in device_find_child_by_name() to allow it to use a > > > > sysfs input string that might contain a trailing newline. > > > > > > > > The other "device by name" interfaces, > > > > {bus,driver,class}_find_device_by_name(), already account for sysfs > > > > strings. > > > > > > > > Cc: Greg Kroah-Hartman > > > > Cc: "Rafael J. Wysocki" > > > > Signed-off-by: Dan Williams > > > > --- > > > > drivers/base/core.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/base/core.c b/drivers/base/core.c > > > > index 67d39a90b45c..5d31b962c898 100644 > > > > --- a/drivers/base/core.c > > > > +++ b/drivers/base/core.c > > > > @@ -3078,7 +3078,7 @@ struct device *device_find_child_by_name(struct device *parent, > > > > > > > > klist_iter_init(&parent->p->klist_children, &i); > > > > while ((child = next_device(&i))) > > > > - if (!strcmp(dev_name(child), name) && get_device(child)) > > > > + if (sysfs_streq(dev_name(child), name) && get_device(child)) > > > > > > Who wants to call this function with a name passed from userspace? > > > > > > Not objecting to it, just curious... > > > > > > > The series that incorporates this patch adds a partitioning mechanism > > to "device-dax region" devices with an: > > "echo 1 > regionX/create" to create a new partition / sub-instance > > of a region, and... > > "echo $devname > regionX/delete" to delete. Where $devname is > > searched in the child devices of regionX to trigger device_del(). > > Shouldn't that be done in configfs, not sysfs? I see configfs as an awkward fit for this situation. configfs wants to software define kernel objects whereas this facility wants to augment existing kernel enumerated device objects. The region device is created by firmware policy and is optionally partitioned, configfs objects don't exist at all until created. So for this I see sysfs + 'scheme to trigger child device creation' as just enough mechanism that does not warrant full blown configfs. I believe it was debates like this [1] that have led me to the camp of sysfs being capable of some device creation dynamism and leave configfs for purely software constructed objects. [1]: https://lore.kernel.org/lkml/17377.42813.479466.690408@cse.unsw.edu.au/ > > This arrangement avoids one of the design mistakes of libnvdimm which > > uses a sysfs attribute of the device to delete itself. Parent-device > > triggered deletion rather than self-deletion avoids those locking > > entanglements. > > Ugh, yeah, getting rid of that would be great, it's a mess. I think > scsi still does that :( Yeah, both nvdimm and scsi both end up need to delay device deletion to its own thread, and it has led to bugs in the nvdimm case. _______________________________________________ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-leave@lists.01.org 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,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 F1921C433E8 for ; Mon, 13 Jul 2020 16:09:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D0D82206F0 for ; Mon, 13 Jul 2020 16:09:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="r7ELJ2cB" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729700AbgGMQJb (ORCPT ); Mon, 13 Jul 2020 12:09:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45142 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729649AbgGMQJb (ORCPT ); Mon, 13 Jul 2020 12:09:31 -0400 Received: from mail-ed1-x543.google.com (mail-ed1-x543.google.com [IPv6:2a00:1450:4864:20::543]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BDE45C061794 for ; Mon, 13 Jul 2020 09:09:30 -0700 (PDT) Received: by mail-ed1-x543.google.com with SMTP id n2so14139127edr.5 for ; Mon, 13 Jul 2020 09:09:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XPX1344KqFXDG152MSs7m1f71nuvQxMI0VbbfK01bWI=; b=r7ELJ2cBdTaQzo9pqUPojaVz6tHhKqoH2KZY2zuAlJN0hbnOqbT4c12Oy38pcBR/Nj utOjvomkH01KnV48ustA657XHya8dxhiC4zKoTXDfmRE5M9q3CaTL/2f1Ttg6runvIq7 RWnzutbQaMQZuQkbRYM6KLs9dYVs2pWP8m2YSi7TYPnwA2kYkHbV3zTVnZD3+aGspwQv visTBbIeQ8KXGdQAzK/GZmGnfQOSTPpyx1Y/65IykomzQzj2jp7TFsb05AzbD0WDujBa O7/7Q4OI36y4JCe9b58Hkm5W/23aJBSWmta1Co+BkMqTd+7t5uECfERRweordez+CtHr OHsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XPX1344KqFXDG152MSs7m1f71nuvQxMI0VbbfK01bWI=; b=mZnYcOZQHcqd9kO42bD2j/fe/3NmQxBBE4Vpsy5z6EAu/+cbcRqX1IxIK6eUFFhILN vo65Rc0c5Da0M6lpnFzzX8hwj9PookV+VkWujGPjcPqxWlZP4HLR4rJ5Bm9N5yNOqUZM sEdVX61IwqG85sBqDYV3MnujT0PLp0gKnXVpFAuQW+oRX/LyEm6rFdpSlhm3fqnmWpyx eR3CYZZeKWECAByINAEjYeEtfx2w2eCRn2rgPUewWfXdeEDwyYAgL9YdK4FgZAWDVDg8 e6TezPtpdoKgM5sQ+vj0c/dnmJFstvYC9gnho5tnAMqC/Nmae5fu4XIXKZrG8M5TZpKY 2wWQ== X-Gm-Message-State: AOAM5338bD9O/o8vqyIwi6z0bm+/gYwdd2T/BOItptxbN5CG8vDbyDwC 6aospAQds/Mze4JYT3sT5e40cALqFc1rTCztDuLg1A== X-Google-Smtp-Source: ABdhPJzkfFp48TgN6o9u+tichXDgD3w2nI1pgUIrildgifHznsxd6AynKdQoAl6SqJnCRUpI/mZg24+ERLg8WLos9MU= X-Received: by 2002:a50:ee8a:: with SMTP id f10mr95726edr.383.1594656569387; Mon, 13 Jul 2020 09:09:29 -0700 (PDT) MIME-Version: 1.0 References: <159457116473.754248.7879464730875147365.stgit@dwillia2-desk3.amr.corp.intel.com> <159457125753.754248.6000936585361264069.stgit@dwillia2-desk3.amr.corp.intel.com> <20200712170945.GA194499@kroah.com> <20200713155222.GB267581@kroah.com> In-Reply-To: <20200713155222.GB267581@kroah.com> From: Dan Williams Date: Mon, 13 Jul 2020 09:09:18 -0700 Message-ID: Subject: Re: [PATCH v2 17/22] drivers/base: Make device_find_child_by_name() compatible with sysfs inputs To: Greg Kroah-Hartman Cc: linux-nvdimm , "Rafael J. Wysocki" , Peter Zijlstra , Vishal L Verma , Dave Hansen , Ard Biesheuvel , Linux MM , Linux Kernel Mailing List , Linux ACPI , Christoph Hellwig , Joao Martins Content-Type: text/plain; charset="UTF-8" Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Mon, Jul 13, 2020 at 8:52 AM Greg Kroah-Hartman wrote: > > On Mon, Jul 13, 2020 at 08:39:43AM -0700, Dan Williams wrote: > > On Sun, Jul 12, 2020 at 10:09 AM Greg Kroah-Hartman > > wrote: > > > > > > On Sun, Jul 12, 2020 at 09:27:37AM -0700, Dan Williams wrote: > > > > Use sysfs_streq() in device_find_child_by_name() to allow it to use a > > > > sysfs input string that might contain a trailing newline. > > > > > > > > The other "device by name" interfaces, > > > > {bus,driver,class}_find_device_by_name(), already account for sysfs > > > > strings. > > > > > > > > Cc: Greg Kroah-Hartman > > > > Cc: "Rafael J. Wysocki" > > > > Signed-off-by: Dan Williams > > > > --- > > > > drivers/base/core.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/base/core.c b/drivers/base/core.c > > > > index 67d39a90b45c..5d31b962c898 100644 > > > > --- a/drivers/base/core.c > > > > +++ b/drivers/base/core.c > > > > @@ -3078,7 +3078,7 @@ struct device *device_find_child_by_name(struct device *parent, > > > > > > > > klist_iter_init(&parent->p->klist_children, &i); > > > > while ((child = next_device(&i))) > > > > - if (!strcmp(dev_name(child), name) && get_device(child)) > > > > + if (sysfs_streq(dev_name(child), name) && get_device(child)) > > > > > > Who wants to call this function with a name passed from userspace? > > > > > > Not objecting to it, just curious... > > > > > > > The series that incorporates this patch adds a partitioning mechanism > > to "device-dax region" devices with an: > > "echo 1 > regionX/create" to create a new partition / sub-instance > > of a region, and... > > "echo $devname > regionX/delete" to delete. Where $devname is > > searched in the child devices of regionX to trigger device_del(). > > Shouldn't that be done in configfs, not sysfs? I see configfs as an awkward fit for this situation. configfs wants to software define kernel objects whereas this facility wants to augment existing kernel enumerated device objects. The region device is created by firmware policy and is optionally partitioned, configfs objects don't exist at all until created. So for this I see sysfs + 'scheme to trigger child device creation' as just enough mechanism that does not warrant full blown configfs. I believe it was debates like this [1] that have led me to the camp of sysfs being capable of some device creation dynamism and leave configfs for purely software constructed objects. [1]: https://lore.kernel.org/lkml/17377.42813.479466.690408@cse.unsw.edu.au/ > > This arrangement avoids one of the design mistakes of libnvdimm which > > uses a sysfs attribute of the device to delete itself. Parent-device > > triggered deletion rather than self-deletion avoids those locking > > entanglements. > > Ugh, yeah, getting rid of that would be great, it's a mess. I think > scsi still does that :( Yeah, both nvdimm and scsi both end up need to delay device deletion to its own thread, and it has led to bugs in the nvdimm case. 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,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 63910C433EA for ; Mon, 13 Jul 2020 16:09:33 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 27243206F0 for ; Mon, 13 Jul 2020 16:09:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="r7ELJ2cB" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 27243206F0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 977418D0012; Mon, 13 Jul 2020 12:09:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 926AB8D0001; Mon, 13 Jul 2020 12:09:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 816C38D0012; Mon, 13 Jul 2020 12:09:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0230.hostedemail.com [216.40.44.230]) by kanga.kvack.org (Postfix) with ESMTP id 6605E8D0001 for ; Mon, 13 Jul 2020 12:09:32 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id B314C181AEF00 for ; Mon, 13 Jul 2020 16:09:31 +0000 (UTC) X-FDA: 77033537742.13.gold94_161438c26ee9 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin13.hostedemail.com (Postfix) with ESMTP id 8CFA418140B70 for ; Mon, 13 Jul 2020 16:09:31 +0000 (UTC) X-HE-Tag: gold94_161438c26ee9 X-Filterd-Recvd-Size: 6565 Received: from mail-ed1-f68.google.com (mail-ed1-f68.google.com [209.85.208.68]) by imf19.hostedemail.com (Postfix) with ESMTP for ; Mon, 13 Jul 2020 16:09:30 +0000 (UTC) Received: by mail-ed1-f68.google.com with SMTP id g20so14178872edm.4 for ; Mon, 13 Jul 2020 09:09:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XPX1344KqFXDG152MSs7m1f71nuvQxMI0VbbfK01bWI=; b=r7ELJ2cBdTaQzo9pqUPojaVz6tHhKqoH2KZY2zuAlJN0hbnOqbT4c12Oy38pcBR/Nj utOjvomkH01KnV48ustA657XHya8dxhiC4zKoTXDfmRE5M9q3CaTL/2f1Ttg6runvIq7 RWnzutbQaMQZuQkbRYM6KLs9dYVs2pWP8m2YSi7TYPnwA2kYkHbV3zTVnZD3+aGspwQv visTBbIeQ8KXGdQAzK/GZmGnfQOSTPpyx1Y/65IykomzQzj2jp7TFsb05AzbD0WDujBa O7/7Q4OI36y4JCe9b58Hkm5W/23aJBSWmta1Co+BkMqTd+7t5uECfERRweordez+CtHr OHsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XPX1344KqFXDG152MSs7m1f71nuvQxMI0VbbfK01bWI=; b=Wg0nh7w1RUl2JYm9f1P+OSOB76OuiWQESAKV4iXTgzzVkRRfAfS6RSn5v2FYitHXcC BhLWFgsZcH96VqDYln8EhNABDrFau5cBVtPeeHNJLDofGpwBiuNKS6NqPfYoW0p9fp7W X/9+41Cd/KxggCoxjWt2YL+Kbhupqk1B9UH7gxJHrV/sFb2oFkq+y6qwsr8LPwq+qBgQ WhaPcM/sGWaNZHqWEo1ZPQYXTyfhPp660Hld4setLkNL4lSfQ6aymTYJ+xa3Wh+Ev/3v NeFzeMCJcCgLrSHn40C4DbfSPXXpDDpWHRnLklmVYFukVsxeZaJqjG0wRAYFURMlJ3HX xE0w== X-Gm-Message-State: AOAM533FLAFry056wJkqyFfkBVqkMLSQ0ntaConu9pFXyTSJfrJyoriE +C7MclO53L3hC5JhNLQyqD7VciKzxUIgk5WCvRUeOu3H1AY= X-Google-Smtp-Source: ABdhPJzkfFp48TgN6o9u+tichXDgD3w2nI1pgUIrildgifHznsxd6AynKdQoAl6SqJnCRUpI/mZg24+ERLg8WLos9MU= X-Received: by 2002:a50:ee8a:: with SMTP id f10mr95726edr.383.1594656569387; Mon, 13 Jul 2020 09:09:29 -0700 (PDT) MIME-Version: 1.0 References: <159457116473.754248.7879464730875147365.stgit@dwillia2-desk3.amr.corp.intel.com> <159457125753.754248.6000936585361264069.stgit@dwillia2-desk3.amr.corp.intel.com> <20200712170945.GA194499@kroah.com> <20200713155222.GB267581@kroah.com> In-Reply-To: <20200713155222.GB267581@kroah.com> From: Dan Williams Date: Mon, 13 Jul 2020 09:09:18 -0700 Message-ID: Subject: Re: [PATCH v2 17/22] drivers/base: Make device_find_child_by_name() compatible with sysfs inputs To: Greg Kroah-Hartman Cc: linux-nvdimm , "Rafael J. Wysocki" , Peter Zijlstra , Vishal L Verma , Dave Hansen , Ard Biesheuvel , Linux MM , Linux Kernel Mailing List , Linux ACPI , Christoph Hellwig , Joao Martins Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 8CFA418140B70 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Jul 13, 2020 at 8:52 AM Greg Kroah-Hartman wrote: > > On Mon, Jul 13, 2020 at 08:39:43AM -0700, Dan Williams wrote: > > On Sun, Jul 12, 2020 at 10:09 AM Greg Kroah-Hartman > > wrote: > > > > > > On Sun, Jul 12, 2020 at 09:27:37AM -0700, Dan Williams wrote: > > > > Use sysfs_streq() in device_find_child_by_name() to allow it to use a > > > > sysfs input string that might contain a trailing newline. > > > > > > > > The other "device by name" interfaces, > > > > {bus,driver,class}_find_device_by_name(), already account for sysfs > > > > strings. > > > > > > > > Cc: Greg Kroah-Hartman > > > > Cc: "Rafael J. Wysocki" > > > > Signed-off-by: Dan Williams > > > > --- > > > > drivers/base/core.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/base/core.c b/drivers/base/core.c > > > > index 67d39a90b45c..5d31b962c898 100644 > > > > --- a/drivers/base/core.c > > > > +++ b/drivers/base/core.c > > > > @@ -3078,7 +3078,7 @@ struct device *device_find_child_by_name(struct device *parent, > > > > > > > > klist_iter_init(&parent->p->klist_children, &i); > > > > while ((child = next_device(&i))) > > > > - if (!strcmp(dev_name(child), name) && get_device(child)) > > > > + if (sysfs_streq(dev_name(child), name) && get_device(child)) > > > > > > Who wants to call this function with a name passed from userspace? > > > > > > Not objecting to it, just curious... > > > > > > > The series that incorporates this patch adds a partitioning mechanism > > to "device-dax region" devices with an: > > "echo 1 > regionX/create" to create a new partition / sub-instance > > of a region, and... > > "echo $devname > regionX/delete" to delete. Where $devname is > > searched in the child devices of regionX to trigger device_del(). > > Shouldn't that be done in configfs, not sysfs? I see configfs as an awkward fit for this situation. configfs wants to software define kernel objects whereas this facility wants to augment existing kernel enumerated device objects. The region device is created by firmware policy and is optionally partitioned, configfs objects don't exist at all until created. So for this I see sysfs + 'scheme to trigger child device creation' as just enough mechanism that does not warrant full blown configfs. I believe it was debates like this [1] that have led me to the camp of sysfs being capable of some device creation dynamism and leave configfs for purely software constructed objects. [1]: https://lore.kernel.org/lkml/17377.42813.479466.690408@cse.unsw.edu.au/ > > This arrangement avoids one of the design mistakes of libnvdimm which > > uses a sysfs attribute of the device to delete itself. Parent-device > > triggered deletion rather than self-deletion avoids those locking > > entanglements. > > Ugh, yeah, getting rid of that would be great, it's a mess. I think > scsi still does that :( Yeah, both nvdimm and scsi both end up need to delay device deletion to its own thread, and it has led to bugs in the nvdimm case.