Received: by 2002:a05:6a10:9e8c:0:0:0:0 with SMTP id y12csp1078293pxx; Fri, 30 Oct 2020 01:04:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyOsoNZxH9qzfIHQ4/4ANSrKYlsNBVHhw5jJbOFldQUgisfGyeVRVq83+r3zVc5PD0AA3N0 X-Received: by 2002:a05:6402:142a:: with SMTP id c10mr1013924edx.261.1604045091864; Fri, 30 Oct 2020 01:04:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1604045091; cv=none; d=google.com; s=arc-20160816; b=kSitF3B1RHkzWkGqD15Dn5OwastONvum5/qoATqkMqsD4z+kUBQ9f1kVqFmUvbzik3 y4SyHMDENO3RgrJGCvFn0FfZdhdYGB9bKKBdgab2jr9KbJ/7kcl+VPivgkrTHyD8UCcN LgFeCYevk30n8DbAHge0cOLy6IdQZ72G9xHYzuM4HiKFgwICwix9pYiGlkubuC5xUKhy SuN5+VO0/NdTEi1HeKdOT4sP82+bTYxYizAgCOUoqbFIQhsS3oqTJWG2l7PWts5gf0p0 cCUO7hLC1RXikwdQfgCT8dcLafFIirzRwDWFus2l25R12+2wo5eO4tkrG6V732tCL+qr LPmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=iDfc8gB5Ud+LcOZETBnYPqUNNLsj4PyiWV/93kwTrxw=; b=DdKsWKafpNLXyScuQv1oMAU3R2I7XSqqaGxmXqG7nbngmrkYkw43ygqaVZ7qh9c0JX OQay1pskyWlqNZCRtdxH1hZnFRrpapzFnjplUDdNQLa9Gy6ozA3gnXx7sJl54mgJtC9L gtXpv0IKD2TWiu7RRPnndw71rv3F68ljKWtxK4v7KNakEcEzOL8THRn5zdIn59IfbGER 2FQqpkwIfQ+x7e89NOUtbfEpzU251XyaXCjTXBDB6ZdsDH60mDq6rJiQYlZVI8T6ZEl7 y9jG9uDJI6zO8fkgVq45VEvKYkhvTaXmZAe31I75/nOx5hb8By2LuCUErFOUNdjn5/+j lolg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=VbONgRrL; 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=fail (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k23si4370503ejk.246.2020.10.30.01.04.21; Fri, 30 Oct 2020 01:04:51 -0700 (PDT) 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=@kernel.org header.s=default header.b=VbONgRrL; 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=fail (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725995AbgJ3ICw (ORCPT + 99 others); Fri, 30 Oct 2020 04:02:52 -0400 Received: from mail.kernel.org ([198.145.29.99]:33702 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725790AbgJ3ICw (ORCPT ); Fri, 30 Oct 2020 04:02:52 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id B7F6F206DD; Fri, 30 Oct 2020 08:02:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1604044948; bh=sjpPspkLsWiWbFSLHAjaeQlueI6WT5/q7Z9EziIU0wQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=VbONgRrLC42ZQFZhvxtyCZWX4k4LA6yxZEzKU7qVlAJvFRe1crGjYUjeJGfeEVdOf lVayfrDrNhKZq358K3LswRdStjL7Gwo1L8DNtWjDUn2MPqzmRuEjmiM2BBUb/dBOHH Orh7h2x797L4hI4r7sZjjgnytACUICBpQ7aGblkk= Date: Fri, 30 Oct 2020 09:03:16 +0100 From: Greg KH To: Deepak R Varma Cc: outreachy-kernel@googlegroups.com, Alex Deucher , Christian =?iso-8859-1?Q?K=F6nig?= , David Airlie , Daniel Vetter , amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, melissa.srw@gmail.com, daniel.vetter@ffwll.ch Subject: Re: [Outreachy kernel] [PATCH] drm/amdgpu: use DEFINE_DEBUGFS_ATTRIBUTE with debugfs_create_file_unsafe() Message-ID: <20201030080316.GA1612206@kroah.com> References: <20201030032245.GA274478@my--box> <20201030071120.GA1493629@kroah.com> <20201030075716.GA6976@my--box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201030075716.GA6976@my--box> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 30, 2020 at 01:27:16PM +0530, Deepak R Varma wrote: > On Fri, Oct 30, 2020 at 08:11:20AM +0100, Greg KH wrote: > > On Fri, Oct 30, 2020 at 08:52:45AM +0530, Deepak R Varma wrote: > > > Using DEFINE_DEBUGFS_ATTRIBUTE macro with debugfs_create_file_unsafe() > > > function in place of the debugfs_create_file() function will make the > > > file operation struct "reset" aware of the file's lifetime. Additional > > > details here: https://lists.archive.carbon60.com/linux/kernel/2369498 > > > > > > Issue reported by Coccinelle script: > > > scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci > > > > > > Signed-off-by: Deepak R Varma > > > --- > > > Please Note: This is a Outreachy project task patch. > > > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 20 ++++++++++---------- > > > 1 file changed, 10 insertions(+), 10 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > > > index 2d125b8b15ee..f076b1ba7319 100644 > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > > > @@ -1551,29 +1551,29 @@ static int amdgpu_debugfs_sclk_set(void *data, u64 val) > > > return 0; > > > } > > > > > > -DEFINE_SIMPLE_ATTRIBUTE(fops_ib_preempt, NULL, > > > - amdgpu_debugfs_ib_preempt, "%llu\n"); > > > +DEFINE_DEBUGFS_ATTRIBUTE(fops_ib_preempt, NULL, > > > + amdgpu_debugfs_ib_preempt, "%llu\n"); > > > > Are you sure this is ok? Do these devices need this additional > > "protection"? Do they have the problem that these macros were written > > for? > > > > Same for the other patches you just submitted here, I think you need to > > somehow "prove" that these changes are necessary, checkpatch isn't able > > to determine this all the time. > > Hi Greg, > Based on my understanding, the current function debugfs_create_file() > adds an overhead of lifetime managing proxy for such fop structs. This > should be applicable to these set of drivers as well. Hence I think this > change will be useful. Why do these drivers need these changes? Are these files dynamically removed from the system at random times? There is a reason we didn't just do a global search/replace for this in the kernel when the new functions were added, so I don't know why checkpatch is now saying it must be done. thanks, greg k-h