Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753903AbcCWXES (ORCPT ); Wed, 23 Mar 2016 19:04:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53148 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751160AbcCWXER (ORCPT ); Wed, 23 Mar 2016 19:04:17 -0400 Date: Wed, 23 Mar 2016 17:04:15 -0600 From: Alex Williamson To: Wei Yang Cc: treding@nvidia.com, joro@8bytes.org, iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org Subject: Re: [Patch V2 2/2] iommu: remove sysfs_link to device in iommu_group/devices when failed Message-ID: <20160323170415.65ecf521@t450s.home> In-Reply-To: <1458771911-30785-3-git-send-email-richard.weiyang@gmail.com> References: <1458771911-30785-1-git-send-email-richard.weiyang@gmail.com> <1458771911-30785-3-git-send-email-richard.weiyang@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Wed, 23 Mar 2016 23:04:16 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1143 Lines: 33 On Wed, 23 Mar 2016 22:25:11 +0000 Wei Yang wrote: > The original code forgets to remove the sysfs_link to a device in > iommu_group/devices directory, when the creation fails or conflicts on the > name. > > This patch tries to remove the sysfs_link on the failure. > > Signed-off-by: Wei Yang > --- > drivers/iommu/iommu.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c > index 2696a38..8f480ba 100644 > --- a/drivers/iommu/iommu.c > +++ b/drivers/iommu/iommu.c > @@ -403,6 +403,7 @@ rename: > ret = sysfs_create_link_nowarn(group->devices_kobj, > &dev->kobj, device->name); > if (ret) { > + sysfs_remove_link(group->devices_kobj, device->name); > kfree(device->name); > if (ret == -EEXIST && i >= 0) { > /* If we failed to create a link, potentially due to a conflicting link already present, then aren't we arbitrarily removing that conflicting link with this change? If sysfs_create_link_nowarn() fails then we haven't created a link of our own to remove. This looks wrong. Thanks, Alex