Message ID | 20230428031111.322-1-rdunlap@infradead.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp668894vqo; Thu, 27 Apr 2023 20:14:16 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4kuxZg0Lxgv9+hlSCz4+w3SV17G/P9G8kGR+G2Tz0RWkqopSXsa1WntlJFfOo975oCdSqj X-Received: by 2002:a17:90a:f601:b0:247:944d:b75e with SMTP id bw1-20020a17090af60100b00247944db75emr4305952pjb.12.1682651656297; Thu, 27 Apr 2023 20:14:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1682651656; cv=none; d=google.com; s=arc-20160816; b=0eHuQ7IIrc18pbI7JcyddRIoATMNHz/UNgpIXfX6qEoxsyxOYALHzFdYh1mx8zSrT1 s7j6hNH0L4EctxU6QpEYgCfpQ76F+OLJ2mRjbHfClPaTl+N/WTFIlo9uuT1l453fX+pZ 5P/dcASuTajebE/+sN+ORH2QwNPz6OodHFD0qkON9+5IqGNP01UMYiEs1cMboVyxdRSl T9o/lsGLPHwC1LFPXF8JuRReyaAjixn4LuSiOvn5anwf4o+OvxQ66fQZivIFVx6Xxaec gSWGk9XrmTsgrFqddDBCpl5J4mT0i9QFX+BHJqGjbEJIPQbvrbtHoxD0bfyHzailM3gY /BgA== 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:date:subject:cc:to:from:dkim-signature; bh=iPaNTRr4YG/Sa60FYBv4xjWiredPl874QL6Kp29pXgA=; b=aRqY45+lS8GsHc0jK4LCpypbHtISbjdVJaRyDyb/Uz5OtLq60sQPktVIKeaT7LmCg/ huKa6AknZegkwwMBbI0y3FxveIwtpTvXVlYjTqoIsqn+5HxDDt96/TWfm2GGvaiI/kaH fS/aQnn4eaNZkSGEx722k0Qf44J8qKMeDXAyYb6zxBnf/jci446xxlicdRLA/nXqcxZj xOlnP+xZQQNbsP3j1TTxplEVnpabkA6b35adi2I7+1/jY9KuysaX8LQXiJW0aXDCn/PR ivb02mzEmZk8FMpKxh3Ua+PTHwktVw64SumLJsWDQfo4bcO8t07/vmK8lKL0taPjSq5V B94w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20210309 header.b=c2UtG5vz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id lp6-20020a17090b4a8600b002470e893981si1330940pjb.79.2023.04.27.20.14.01; Thu, 27 Apr 2023 20:14:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20210309 header.b=c2UtG5vz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344956AbjD1DMM (ORCPT <rfc822;zxc52fgh@gmail.com> + 99 others); Thu, 27 Apr 2023 23:12:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50608 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344947AbjD1DLk (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 27 Apr 2023 23:11:40 -0400 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8430B3C24 for <linux-kernel@vger.kernel.org>; Thu, 27 Apr 2023 20:11:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Transfer-Encoding: MIME-Version:Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:Content-Type: Content-ID:Content-Description:In-Reply-To:References; bh=iPaNTRr4YG/Sa60FYBv4xjWiredPl874QL6Kp29pXgA=; b=c2UtG5vz34cTtmPnNN9tMfsZrG sZo3oPG8rn0EzKN8JGMj5ssvBOK6Jr/tR2rQ0ZRvokxojShaLG58AZVRVhRNe6ThCu+OeNTGC8yed JHg6ZSpBnXhFxnmq5Hf3V8hXShiaa6kdJCfZUn80Pq9yDTj3IWzqLnQt1yvcv5Td55+IjjAP38HD5 FD9xumFNW8vkL2Xr+K7CKnV7NjzZYY3CpXzFWbShtEYpJG0PHWS58kBEuN9r+suS2GmMzY6tN7cQK bzh8995whBVqaQFQJDaewRURgmEFlsAlznGxzR1uoovYPDu289BV8UkUEH8UMJYTQtW0xutFwACO2 bWiA//6A==; Received: from [2601:1c2:980:9ec0::2764] (helo=bombadil.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.96 #2 (Red Hat Linux)) id 1psEVs-0082rS-0n; Fri, 28 Apr 2023 03:11:12 +0000 From: Randy Dunlap <rdunlap@infradead.org> To: linux-kernel@vger.kernel.org Cc: Randy Dunlap <rdunlap@infradead.org>, Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, "Peter Zijlstra (Intel)" <peterz@infradead.org>, Ingo Molnar <mingo@redhat.com> Subject: [PATCH -next] sched: fix cid_lock kernel-doc warnings Date: Thu, 27 Apr 2023 20:11:11 -0700 Message-Id: <20230428031111.322-1-rdunlap@infradead.org> X-Mailer: git-send-email 2.40.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED 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-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1764388143420231492?= X-GMAIL-MSGID: =?utf-8?q?1764388143420231492?= |
Series |
[-next] sched: fix cid_lock kernel-doc warnings
|
|
Commit Message
Randy Dunlap
April 28, 2023, 3:11 a.m. UTC
Fix kernel-doc warnings for cid_lock and use_cid_lock.
These comments are not in kernel-doc format.
kernel/sched/core.c:11496: warning: Cannot understand * @cid_lock: Guarantee forward-progress of cid allocation.
on line 11496 - I thought it was a doc line
kernel/sched/core.c:11505: warning: Cannot understand * @use_cid_lock: Select cid allocation behavior: lock-free vs spinlock.
on line 11505 - I thought it was a doc line
Fixes: 223baf9d17f2 ("sched: Fix performance regression introduced by mm_cid")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
---
kernel/sched/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Comments
On 2023-04-27 23:11, Randy Dunlap wrote: > Fix kernel-doc warnings for cid_lock and use_cid_lock. > These comments are not in kernel-doc format. > > kernel/sched/core.c:11496: warning: Cannot understand * @cid_lock: Guarantee forward-progress of cid allocation. > on line 11496 - I thought it was a doc line > kernel/sched/core.c:11505: warning: Cannot understand * @use_cid_lock: Select cid allocation behavior: lock-free vs spinlock. > on line 11505 - I thought it was a doc line > Right. It made sense to have those as kernel-doc when those were mm_struct fields in previous versions of the patch, but not anymore now that those are stand-alone static variables. Acked-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Thanks, Mathieu > Fixes: 223baf9d17f2 ("sched: Fix performance regression introduced by mm_cid") > Signed-off-by: Randy Dunlap <rdunlap@infradead.org> > Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> > Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org> > Cc: Ingo Molnar <mingo@redhat.com> > --- > kernel/sched/core.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff -- a/kernel/sched/core.c b/kernel/sched/core.c > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -11492,7 +11492,7 @@ void call_trace_sched_update_nr_running( > > #ifdef CONFIG_SCHED_MM_CID > > -/** > +/* > * @cid_lock: Guarantee forward-progress of cid allocation. > * > * Concurrency ID allocation within a bitmap is mostly lock-free. The cid_lock > @@ -11501,7 +11501,7 @@ void call_trace_sched_update_nr_running( > */ > DEFINE_RAW_SPINLOCK(cid_lock); > > -/** > +/* > * @use_cid_lock: Select cid allocation behavior: lock-free vs spinlock. > * > * When @use_cid_lock is 0, the cid allocation is lock-free. When contention is
On Thu, Apr 27, 2023 at 08:11:11PM -0700, Randy Dunlap wrote: > Fix kernel-doc warnings for cid_lock and use_cid_lock. > These comments are not in kernel-doc format. > > kernel/sched/core.c:11496: warning: Cannot understand * @cid_lock: Guarantee forward-progress of cid allocation. > on line 11496 - I thought it was a doc line > kernel/sched/core.c:11505: warning: Cannot understand * @use_cid_lock: Select cid allocation behavior: lock-free vs spinlock. > on line 11505 - I thought it was a doc line > > Fixes: 223baf9d17f2 ("sched: Fix performance regression introduced by mm_cid") > Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Blergh, so mostly I avoid kerneldoc like the plague; because then you get random people doing 'fixups' that end up making the actual comment unreadable garbage. Mostly my answer to any such patch is to simply remove the extra * and call it fixed. But now the thing presumes to know better? :-( Anyway, in this case I suppose we can add it on and see, there's still a fair number of actual kerneldoc comments in that file. > kernel/sched/core.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff -- a/kernel/sched/core.c b/kernel/sched/core.c > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -11492,7 +11492,7 @@ void call_trace_sched_update_nr_running( > > #ifdef CONFIG_SCHED_MM_CID > > -/** > +/* > * @cid_lock: Guarantee forward-progress of cid allocation. > * > * Concurrency ID allocation within a bitmap is mostly lock-free. The cid_lock > @@ -11501,7 +11501,7 @@ void call_trace_sched_update_nr_running( > */ > DEFINE_RAW_SPINLOCK(cid_lock); > > -/** > +/* > * @use_cid_lock: Select cid allocation behavior: lock-free vs spinlock. > * > * When @use_cid_lock is 0, the cid allocation is lock-free. When contention is
On Mon, May 01, 2023 at 03:20:20PM +0200, Peter Zijlstra wrote: > On Thu, Apr 27, 2023 at 08:11:11PM -0700, Randy Dunlap wrote: > > Fix kernel-doc warnings for cid_lock and use_cid_lock. > > These comments are not in kernel-doc format. > > > > kernel/sched/core.c:11496: warning: Cannot understand * @cid_lock: Guarantee forward-progress of cid allocation. > > on line 11496 - I thought it was a doc line > > kernel/sched/core.c:11505: warning: Cannot understand * @use_cid_lock: Select cid allocation behavior: lock-free vs spinlock. > > on line 11505 - I thought it was a doc line > > > > Fixes: 223baf9d17f2 ("sched: Fix performance regression introduced by mm_cid") > > Signed-off-by: Randy Dunlap <rdunlap@infradead.org> > > Blergh, so mostly I avoid kerneldoc like the plague; because then you > get random people doing 'fixups' that end up making the actual comment > unreadable garbage. > > Mostly my answer to any such patch is to simply remove the extra * and > call it fixed. > > But now the thing presumes to know better? :-( Bah, I should go sleep more.. this removes them. All good.
diff -- a/kernel/sched/core.c b/kernel/sched/core.c --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -11492,7 +11492,7 @@ void call_trace_sched_update_nr_running( #ifdef CONFIG_SCHED_MM_CID -/** +/* * @cid_lock: Guarantee forward-progress of cid allocation. * * Concurrency ID allocation within a bitmap is mostly lock-free. The cid_lock @@ -11501,7 +11501,7 @@ void call_trace_sched_update_nr_running( */ DEFINE_RAW_SPINLOCK(cid_lock); -/** +/* * @use_cid_lock: Select cid allocation behavior: lock-free vs spinlock. * * When @use_cid_lock is 0, the cid allocation is lock-free. When contention is