Re: [PATCH] cgroup: drop unneeded semicolon

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1153082744-1785653222=:26964
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT



On Sat, 1 Aug 2026, Waiman Long wrote:

> On 8/1/26 3:09 PM, Julia Lawall wrote:
> > When a function-like macro expands to an expression, that expression
> > doesn't need a semicolon after it.  All uses have been verified to
> > have their own semicolons.
> >
> > This was found using the following Coccinelle semantic patch:
> >
> > @r@
> > identifier i : script:ocaml() { String.lowercase_ascii i = i };
> > expression e;
> > @@
> >
> > *#define i(...) e;
> >
> > Signed-off-by: Julia Lawall <[email protected]>
> >
> > ---
> >   kernel/cgroup/cgroup.c |    2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
> > index 38f8d9df8..f87fc4550 100644
> > --- a/kernel/cgroup/cgroup.c
> > +++ b/kernel/cgroup/cgroup.c
> > @@ -104,7 +104,7 @@ DEFINE_PERCPU_RWSEM(cgroup_threadgroup_rwsem);
> >   #define cgroup_assert_mutex_or_rcu_locked()				\
> >   	RCU_LOCKDEP_WARN(!rcu_read_lock_held() &&			\
> >   			   !lockdep_is_held(&cgroup_mutex),		\
> > -			   "cgroup_mutex or RCU read lock required");
> > +			   "cgroup_mutex or RCU read lock required")
> >     /*
> >    * cgroup destruction makes heavy use of work items and there can be a lot
> >
> The RCU_LOCKDEP_WARN() macro is basically a "do { ...} while (0...)"
> statement. It doesn't have a ';' at the end.  So your commit log isn't right.

OK.  Indeed I didn't take into account the definition of the macro.  The
usage context does have another semincolon, which is what is mentioned in
the commit log.

>
> An additional semicolon at the end doesn't harm. By removing the semicolon,
> even if not needed, may make people wonder if it is right when reading the
> code wasting their time to figure out if it is all right. So I don't see any
> advantage in removing it.

No problem to drop the patch if you don't think it's useful.

julia
--8323329-1153082744-1785653222=:26964--