Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp1152007pxb; Sat, 9 Jan 2021 09:12:11 -0800 (PST) X-Google-Smtp-Source: ABdhPJw+23S90IHvFB6g6BjzXXY1/ansm93UP0yo5lbF1ZjYxSIL2YCdrxIFG6kIabM7S12fLCvM X-Received: by 2002:a05:6402:5193:: with SMTP id q19mr9108968edd.264.1610212331809; Sat, 09 Jan 2021 09:12:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610212331; cv=none; d=google.com; s=arc-20160816; b=JcSSQjPJwYSWLX3bPHWcfvWJw7oxijcVjkrHi/++PC58fqQNH74J/f/f8DJrmb4uzK 9vR1n5eif7Ym9Bsbgz/PVX4NjvVGotKCEUcb6l0BMm2cInluj8kjErxEbXxgt4Y/8Og3 c272rNetI0DN4uqWMqdzt9alaWPdjodj0NHw9bmPdcyRl89HUAeMUNPverRFPk0L5amp XXaB55JsIkXORocUehU9r+eoXWNGDowvgpei7hoPlRkMGf3fNeoHiEm9oFgcmCfkyiY2 g+eZhAawFrIRF4kAK78eiRYassjRnOmurFp7NEHclIVfASx7ZjK5e9Ur1WP5qRPSM0UN ycKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=EL3usNsR6RJ/kaN0gX4dE0zjZk+adUFE1G3dRPjGzc4=; b=DMb/AkQC76NCoLwtuOnrDruH276Iu2L76RDLbit/2/SOjq25RRL3QhqKJTc3jjwUsR NT+IcOvH5+xRXqHzO3cd6d736uZDUqy43QeWV7sEb66qnmnWBMLQ2owL1NzbUSlCGced LVNO++B5CC2iFyiFqexN+Iksf2tqHMm+IPT0g9NoGH8il/7d2GUiia1qTnDjH2dW9oDp B5WED1/rmOmNSfGRLjpFO6j5SauVzq4+kpWDYBk8CZAY3gVZ177pB9rIVVFjtVeRUDXm GzQrAXiCToC/pMovLN68fh3woqTz4TZFKI0tf5qbTIhuVW274fvsizUsuxD+YPsZv8PW /oXQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=pvdQP6wQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q3si3455143ejb.395.2021.01.09.09.11.47; Sat, 09 Jan 2021 09:12:11 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=pvdQP6wQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726294AbhAIRKv (ORCPT + 99 others); Sat, 9 Jan 2021 12:10:51 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51456 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726013AbhAIRKu (ORCPT ); Sat, 9 Jan 2021 12:10:50 -0500 Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 230F1C06179F for ; Sat, 9 Jan 2021 09:10:10 -0800 (PST) Received: by mail-yb1-xb2e.google.com with SMTP id y128so12597588ybf.10 for ; Sat, 09 Jan 2021 09:10:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EL3usNsR6RJ/kaN0gX4dE0zjZk+adUFE1G3dRPjGzc4=; b=pvdQP6wQkmLKyKoYbBICYKmMe81Lh1oUOvgaduNtneTY4/Dw9v7yK3RuKYojT7mPE6 dFAN3j0PWoI7ZliFe1xz6xiBR/Qy0kLkAQnbsI05LC9pWOcfvg8/GBxE/JEs7sgn+9DH h7ou9N+XOh3i+Zo+BR0lz5Z28ovaX4PK45UOgwpcoBtpSfxuUHMk2El22tndLV6MdghH G/7n3iPQOnPVDjldgLXeOE+EslcU8Ch3eeswEwLOBjJYKvmVBthWxJLLYz5hzFxkV1rh +EFteDKsqKscftKsKcAqpJqAGCIUtKlVvOvHVg88tdFA2A4+Id/r7Au6bGGts2uqN2NS Lkaw== 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=EL3usNsR6RJ/kaN0gX4dE0zjZk+adUFE1G3dRPjGzc4=; b=iC534ITjCSBXwRWW8/dAZ4N5B8Vl9oQ1FuMH1g2CUaARUSiyj2/Xvdt3C++nWSRqGw mpLMzf6xhlplHjZYQNu2TLFXS2l4wrGjqM85fXa7sL/yhrcEbocA0eeLPvEBOitqeprx P9ZeSlVCK/asEpHuSD9qX/1ayNfhkMBiZPw6z+Y+i3hCIEogSDg3ojLKTrV+haBxOMpr WK8PG23gC2hSGj/PfCNnJJh0Mb2KKuk+3AwUMyVpmIRM0kUGVjwWPkTaNb/OUoUCP4I/ RPGzCPGgmGx6L35PbKqGopSkfGmfDvzEQhOldMkVjz6DwoPepK+97ewx+d1bj34/6liF JYfQ== X-Gm-Message-State: AOAM533DieQurhBumMC8IjnIUQH+hrKHbuaqYDw4e4mLQ3HaIe2kbd02 hLcqPRWWP+76dwf2gdzhJDEjJxD4eQgtjYwCke7mtw== X-Received: by 2002:a25:2506:: with SMTP id l6mr14836274ybl.32.1610212209019; Sat, 09 Jan 2021 09:10:09 -0800 (PST) MIME-Version: 1.0 References: <20210108012427.766318-1-saravanak@google.com> <9ec99f2f0e1e75e11f2d7d013dc78203@walle.cc> <7f10c6c94729dfa48e18f7f4b038403a@walle.cc> In-Reply-To: <7f10c6c94729dfa48e18f7f4b038403a@walle.cc> From: Saravana Kannan Date: Sat, 9 Jan 2021 09:09:32 -0800 Message-ID: Subject: Re: [PATCH v3] driver core: Fix device link device name collision To: Michael Walle Cc: Greg Kroah-Hartman , "Rafael J. Wysocki" , stable , Android Kernel Team , LKML Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jan 9, 2021 at 8:49 AM Michael Walle wrote: > > Am 2021-01-08 18:22, schrieb Saravana Kannan: > > On Fri, Jan 8, 2021 at 12:16 AM Michael Walle wrote: > >> > >> Am 2021-01-08 02:24, schrieb Saravana Kannan: > >> > The device link device's name was of the form: > >> > -- > >> > > >> > This can cause name collision as reported here [1] as device names are > >> > not globally unique. Since device names have to be unique within the > >> > bus/class, add the bus/class name as a prefix to the device names used > >> > to > >> > construct the device link device name. > >> > > >> > So the devuce link device's name will be of the form: > >> > :--: > >> > > >> > [1] - > >> > https://lore.kernel.org/lkml/20201229033440.32142-1-michael@walle.cc/ > >> > > >> > Cc: stable@vger.kernel.org > >> > Fixes: 287905e68dd2 ("driver core: Expose device link details in > >> > sysfs") > >> > Reported-by: Michael Walle > >> > Signed-off-by: Saravana Kannan > >> > --- > >> [..] > >> > >> The changes are missing for the error path and > >> devlink_remove_symlinks(), > >> right? > > > > Removing symlinks doesn't need the name. Just needs the "handle". So > > we are good there. > > I don't get it. What is the "handle"? Without the patch below > kernfs_remove_by_name() in sysfs_remove_link will return -ENOENT. With > the patch it will return 0. > > And even if it would work, how is this even logical: Ah sorry, I confused it with removing device attrs. I need to fix up the symlink remove path. > > snprintf(buf, len, "consumer:%s:%s", dev_bus_name(con), dev_name(con)); > ret = sysfs_create_link(&sup->kobj, &link->link_dev.kobj, buf); > if (ret) > goto err_con_dev; > snprintf(buf, len, "supplier:%s:%s", dev_bus_name(sup), dev_name(sup)); > ret = sysfs_create_link(&con->kobj, &link->link_dev.kobj, buf); > if (ret) > goto err_sup_dev; > [..] > err_sup_dev: > snprintf(buf, len, "consumer:%s", dev_name(con)); > sysfs_remove_link(&sup->kobj, buf); > > You call sysfs_create_link("consumer:bus_name:dev_name") but the > corresponding rollback is sysfs_remove_link("consumer:dev_name"), that > is super confusing. > > >> diff --git a/drivers/base/core.c b/drivers/base/core.c > >> index 4140a69dfe18..385e16d92874 100644 > >> --- a/drivers/base/core.c > >> +++ b/drivers/base/core.c > >> @@ -485,7 +485,7 @@ static int devlink_add_symlinks(struct device > >> *dev, > >> goto out; > >> > >> err_sup_dev: > >> - snprintf(buf, len, "consumer:%s", dev_name(con)); > >> + snprintf(buf, len, "consumer:%s:%s", dev_bus_name(con), > >> dev_name(con)); > >> sysfs_remove_link(&sup->kobj, buf); > >> err_con_dev: > >> sysfs_remove_link(&link->link_dev.kobj, "consumer"); > >> @@ -508,7 +508,9 @@ static void devlink_remove_symlinks(struct device > >> *dev, > >> sysfs_remove_link(&link->link_dev.kobj, "consumer"); > >> sysfs_remove_link(&link->link_dev.kobj, "supplier"); > >> > >> - len = max(strlen(dev_name(sup)), strlen(dev_name(con))); > >> + len = max(strlen(dev_bus_name(sup)) + strlen(dev_name(sup)), > >> + strlen(dev_bus_name(con)) + strlen(dev_name(con))); > >> + len += strlen(":"); > >> len += strlen("supplier:") + 1; > >> buf = kzalloc(len, GFP_KERNEL); > >> if (!buf) { > >> @@ -516,9 +518,9 @@ static void devlink_remove_symlinks(struct device > >> *dev, > >> return; > >> } > >> > >> - snprintf(buf, len, "supplier:%s", dev_name(sup)); > >> + snprintf(buf, len, "supplier:%s:%s", dev_bus_name(sup), > >> dev_name(sup)); > >> sysfs_remove_link(&con->kobj, buf); > >> - snprintf(buf, len, "consumer:%s", dev_name(con)); > >> + snprintf(buf, len, "consumer:%s:%s", dev_bus_name(sup), > >> dev_name(con)); Ah I completely skimmed over this code thinking it was code from my patch. Like I said, I was struggling with the length of the email due to the logs. Anyway, I'll fix up the remove symlink path too. Thanks for catching that. > btw this should be dev_bus_name(con). > > >> sysfs_remove_link(&sup->kobj, buf); > >> kfree(buf); > >> } > >> > >> With these changes: > >> > >> Tested-by: Michael Walle > > > > Greg, > > > > I think it's good to pick up this version if you don't see any issues. > > Why so fast? Sorry, didn't mean to rush. I was just trying to say I wasn't planning on a v4 because I thought your Tested-by was for my unchanged v4, but clearly I need to send a v4. -Saravana