Message ID | 20231030121523.0b2225a7@gandalf.local.home |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:d641:0:b0:403:3b70:6f57 with SMTP id cy1csp2332132vqb; Mon, 30 Oct 2023 09:16:12 -0700 (PDT) X-Google-Smtp-Source: AGHT+IG75C/gnSw/jxydo2vL6Mg3cZ9XM8HUnnXBKg5YflY5z5ecKuMSq45Yh1HALxYJSwrPD1q2 X-Received: by 2002:a17:902:f34d:b0:1ca:7086:60ec with SMTP id q13-20020a170902f34d00b001ca708660ecmr8625535ple.65.1698682571792; Mon, 30 Oct 2023 09:16:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698682571; cv=none; d=google.com; s=arc-20160816; b=pCKxEY9K1l1OZ8ZY8EGXnWzEJiKLh3dY49VZt/UtCATOJDy3RRuVIbAdlLZDtuUGut R8dMH7+e31CKiUt7tIxLi6xP6I3KgZCVzf8MRINkt+8YqQvIGxqQrOAKHuJDXFWvUjm0 ol37Ciq3W5fnX+3YpZJ5gTIuSe/J1aar6U5C6pazEWuWjIvRsOrZYbd/GsLaO7mhwiIW AO7K2SdXkkDe+N7mnsVnstQIcgGSGzCKWOoKlRDcwZ83IJN3BzQGxkPV5xWftMLfN5EQ jf3Z0+GkZLAJnYjW398cM1pyUmBSvu3DNz62bareNOJermR1Mz/7KS23zJlzCVzHYnFe Et/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:subject:cc:to:from:date; bh=fybyNUlaRkOzeht4mzbMH1mxFE+UWKnHVXwEYLD4kH0=; fh=GwUA7iixakkO5NTXBBRh1SUU4bI3bHSxo/Z9KQ16JZ0=; b=Pg+rFN6LsHF2ESVVXL3FdRacCqW/GQvlKv2se/JC9aLSzJ4NlB2fwJGH2fG9C97V4M cx5mE7U7AjCSr5iOCdzghPkZNyi/UL/dDuTCCSgnxDkjXUQ+i3Lc1Qk2KhgjX4SCwLJw 9ztTxdALfFKhAad05mKHnkAnUsg6SOfQgzg7ixhf5bZBUzLakK4Ce0jDrmQLCjfHnJrX d5mvLj2XdD+GqMGOPomWG4VOY6FUitwxcJvhc6Ggq77WQ7eKgtQi3Jj/GHeLNj25pCab 2/vv+ghMJ5wKagyEsFg9Psu+UKq5UOR8IEjy9mCenymMFgiW6hc+jRhwyEi+Rc7Xr2UR 7WDw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from snail.vger.email (snail.vger.email. [2620:137:e000::3:7]) by mx.google.com with ESMTPS id l8-20020a170903244800b001c566ea86eesi2619618pls.177.2023.10.30.09.16.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Oct 2023 09:16:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 8FA2D806E4C9; Mon, 30 Oct 2023 09:15:42 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232492AbjJ3QPc (ORCPT <rfc822;chrisjones.unixmen@gmail.com> + 32 others); Mon, 30 Oct 2023 12:15:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55540 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229514AbjJ3QP3 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 30 Oct 2023 12:15:29 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5DEC183 for <linux-kernel@vger.kernel.org>; Mon, 30 Oct 2023 09:15:26 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7391CC433C7; Mon, 30 Oct 2023 16:15:25 +0000 (UTC) Date: Mon, 30 Oct 2023 12:15:23 -0400 From: Steven Rostedt <rostedt@goodmis.org> To: LKML <linux-kernel@vger.kernel.org>, Linux Trace Kernel <linux-trace-kernel@vger.kernel.org> Cc: Masami Hiramatsu <mhiramat@kernel.org>, Mark Rutland <mark.rutland@arm.com> Subject: [PATCH] eventfs: Fix kerneldoc of eventfs_remove_rec() Message-ID: <20231030121523.0b2225a7@gandalf.local.home> X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Mon, 30 Oct 2023 09:15:42 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1781197776058047478 X-GMAIL-MSGID: 1781197776058047478 |
Series |
eventfs: Fix kerneldoc of eventfs_remove_rec()
|
|
Commit Message
Steven Rostedt
Oct. 30, 2023, 4:15 p.m. UTC
From: "Steven Rostedt (Google)" <rostedt@goodmis.org> The eventfs_remove_rec() had some missing parameters in the kerneldoc comment above it. Also, rephrase the description a bit more to have a bit more correct grammar. Fixes: 5790b1fb3d672 ("eventfs: Remove eventfs_file and just use eventfs_inode"); Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202310052216.4SgqasWo-lkp@intel.com/ Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> --- fs/tracefs/event_inode.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
Comments
On 10/30/2023 9:45 PM, Steven Rostedt wrote: > From: "Steven Rostedt (Google)" <rostedt@goodmis.org> > > The eventfs_remove_rec() had some missing parameters in the kerneldoc > comment above it. Also, rephrase the description a bit more to have a bit > more correct grammar. > > Fixes: 5790b1fb3d672 ("eventfs: Remove eventfs_file and just use eventfs_inode"); > Reported-by: kernel test robot <lkp@intel.com> > Closes: https://lore.kernel.org/oe-kbuild-all/202310052216.4SgqasWo-lkp@intel.com/ > Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com> -Mukesh > --- > fs/tracefs/event_inode.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/fs/tracefs/event_inode.c b/fs/tracefs/event_inode.c > index 5a3cc5394294..1c28e013201f 100644 > --- a/fs/tracefs/event_inode.c > +++ b/fs/tracefs/event_inode.c > @@ -977,9 +977,11 @@ static void free_rcu_ei(struct rcu_head *head) > /** > * eventfs_remove_rec - remove eventfs dir or file from list > * @ei: eventfs_inode to be removed. > + * @head: the list head to place the deleted @ei and children > + * @level: prevent recursion from going more than 3 levels deep. > * > - * This function recursively remove eventfs_inode which > - * contains info of file or dir. > + * This function recursively removes eventfs_inodes which > + * contains info of files and/or directories. > */ > static void eventfs_remove_rec(struct eventfs_inode *ei, struct list_head *head, int level) > {
On Mon, 30 Oct 2023 21:57:13 +0530 Mukesh Ojha <quic_mojha@quicinc.com> wrote: > On 10/30/2023 9:45 PM, Steven Rostedt wrote: > > From: "Steven Rostedt (Google)" <rostedt@goodmis.org> > > > > The eventfs_remove_rec() had some missing parameters in the kerneldoc > > comment above it. Also, rephrase the description a bit more to have a bit > > more correct grammar. > > > > Fixes: 5790b1fb3d672 ("eventfs: Remove eventfs_file and just use eventfs_inode"); > > Reported-by: kernel test robot <lkp@intel.com> > > Closes: https://lore.kernel.org/oe-kbuild-all/202310052216.4SgqasWo-lkp@intel.com/ > > Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> > > Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com> Hi Mukesh! First, I want to thank you for your reviews. We certainly need more reviewers. But I need to also state that "Reviewed-by" tags should not be sent so lightly. The only times a Reviewed-by tag should be sent is if you participated in the discussion of the code, you have authored some of the code that is being modified, or are marked as a reviewer of the code in the MAINTAINERS file. For example, you added to the discussion here: https://lore.kernel.org/all/65dcdd9c-a75b-4fe7-bdcf-471a5602db20@linaro.org/ And adding your Reviewed-by tag is appropriate. But when a maintainer receives a Reviewed-by from someone they don't know, without any discussion in the patch, it may make that maintainer think that the person sending the Reviewed-by is only out to get listed in the LWN "Reviewed-by" count. I review other developers' code all the time, and unless the code touches something I worked on or I'm marked as a reviewer in the MAINTAINERS file, I do not send a Reviewed-by tag unless I added some input to the patch in question. My advice to you is to keep up the reviewing, I appreciate it (I really do!), but don't send out Reviewed-by tags unless you are marked as a reviewer of the code, or participated in a discussion on that code. Thanks, -- Steve
On 11/2/2023 1:30 AM, Steven Rostedt wrote: > On Mon, 30 Oct 2023 21:57:13 +0530 > Mukesh Ojha <quic_mojha@quicinc.com> wrote: > >> On 10/30/2023 9:45 PM, Steven Rostedt wrote: >>> From: "Steven Rostedt (Google)" <rostedt@goodmis.org> >>> >>> The eventfs_remove_rec() had some missing parameters in the kerneldoc >>> comment above it. Also, rephrase the description a bit more to have a bit >>> more correct grammar. >>> >>> Fixes: 5790b1fb3d672 ("eventfs: Remove eventfs_file and just use eventfs_inode"); >>> Reported-by: kernel test robot <lkp@intel.com> >>> Closes: https://lore.kernel.org/oe-kbuild-all/202310052216.4SgqasWo-lkp@intel.com/ >>> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> >> >> Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com> > > Hi Mukesh! > > First, I want to thank you for your reviews. We certainly need more > reviewers. > > But I need to also state that "Reviewed-by" tags should not be sent so > lightly. The only times a Reviewed-by tag should be sent is if you > participated in the discussion of the code, you have authored some of > the code that is being modified, or are marked as a reviewer of the code in > the MAINTAINERS file. Thanks Steven for writing a suggestion note for me. I will try to participate and take this in a good way..but i thought for easier change where there is no discussion is needed., it is fine to add if you have spent time in checking the code and change is proper. > > For example, you added to the discussion here: > > https://lore.kernel.org/all/65dcdd9c-a75b-4fe7-bdcf-471a5602db20@linaro.org/ > > And adding your Reviewed-by tag is appropriate. > > But when a maintainer receives a Reviewed-by from someone they don't know, > without any discussion in the patch, it may make that maintainer think that > the person sending the Reviewed-by is only out to get listed in the LWN > "Reviewed-by" count. I understand.. > > I review other developers' code all the time, and unless the code touches > something I worked on or I'm marked as a reviewer in the MAINTAINERS file, > I do not send a Reviewed-by tag unless I added some input to the patch in > question. Will keep this in mind. To get involve in LKML discussion, Sending Reviewed-by may not be important but the discussions/engagement/contribution is . > > My advice to you is to keep up the reviewing, I appreciate it (I really > do!), but don't send out Reviewed-by tags unless you are marked as a > reviewer of the code, or participated in a discussion on that code. Sure, thanks, will try to do my bit. -Mukesh > > Thanks, > > -- Steve >
On Thu, 2 Nov 2023 12:05:33 +0530 Mukesh Ojha <quic_mojha@quicinc.com> wrote: > I will try to participate and take this in a good way..but i thought > for easier change where there is no discussion is needed., it is fine > to add if you have spent time in checking the code and change is proper. If it's easy then automated bots will likely catch any issues. No need to say you looked at it too. Otherwise we'll get 20 Reviewed-by tags on comment changes. A Reviewed-by tag has much more meaning when the code being reviewed is not trivial, where questions about correctness is needed. In other words, if something doesn't look quite right, ask. If it is, and the author explains the reason it is, the fact that the explanation is now documented in the archives is useful. Thanks, -- Steve
diff --git a/fs/tracefs/event_inode.c b/fs/tracefs/event_inode.c index 5a3cc5394294..1c28e013201f 100644 --- a/fs/tracefs/event_inode.c +++ b/fs/tracefs/event_inode.c @@ -977,9 +977,11 @@ static void free_rcu_ei(struct rcu_head *head) /** * eventfs_remove_rec - remove eventfs dir or file from list * @ei: eventfs_inode to be removed. + * @head: the list head to place the deleted @ei and children + * @level: prevent recursion from going more than 3 levels deep. * - * This function recursively remove eventfs_inode which - * contains info of file or dir. + * This function recursively removes eventfs_inodes which + * contains info of files and/or directories. */ static void eventfs_remove_rec(struct eventfs_inode *ei, struct list_head *head, int level) {