Received-SPF: pass (google.com: domain of linux-kernel+bounces-141977-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Date: Fri, 12 Apr 2024 07:22:59 +0200
From: Greg KH <gregkh@linuxfoundation.org>
To: Julia Lawall <julia.lawall@inria.fr>
Cc: Roman Storozhenko <romeusmeister@gmail.com>, jirislaby@kernel.org,
	skhan@linuxfoundation.org, javier.carrasco.cruz@gmail.com,
	linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org
Subject: Re: [PATCH] sysrq: Auto release device node using __free attribute
Message-ID: <2024041211-statistic-reformist-bf70@gregkh>
References: <20240411180256.61001-1-romeusmeister@gmail.com>
 <2024041111-tummy-boil-a6aa@gregkh>
 <b6b33aa-faef-6919-7125-c2db11e784ee@inria.fr>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <b6b33aa-faef-6919-7125-c2db11e784ee@inria.fr>

On Thu, Apr 11, 2024 at 08:17:07PM +0200, Julia Lawall wrote:
> 
> 
> On Thu, 11 Apr 2024, Greg KH wrote:
> 
> > On Thu, Apr 11, 2024 at 08:02:56PM +0200, Roman Storozhenko wrote:
> > > Add a cleanup function attribute '__free(device_node)' to the device node
> > > pointer initialization statement and remove the pairing cleanup function
> > > call of 'of_node_put' at the end of the function.
> > > The '_free()' attrubute is introduced by scope-based resource management
> > > in-kernel framework implemented in 'cleanup.h'. A pointer marked with
> > > '__free()' attribute makes a compiler insert a cleanup function call
> > > to the places where the pointer goes out of the scope. This feature
> > > allows to get rid of manual cleanup function calls.
> > >
> > > Suggested-by: Julia.Lawall <Julia.Lawall@inria.fr>
> > > Signed-off-by: Roman Storozhenko <romeusmeister@gmail.com>
> > > ---
> > > This patch targets the next tree:
> > > tree: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> > > tag: next-20240411
> > > ---
> > >  drivers/tty/sysrq.c | 7 +++----
> > >  1 file changed, 3 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
> > > index 02217e3c916b..1d1261f618c0 100644
> > > --- a/drivers/tty/sysrq.c
> > > +++ b/drivers/tty/sysrq.c
> > > @@ -758,11 +758,12 @@ static void sysrq_detect_reset_sequence(struct sysrq_state *state,
> > >  static void sysrq_of_get_keyreset_config(void)
> > >  {
> > >  	u32 key;
> > > -	struct device_node *np;
> > >  	struct property *prop;
> > >  	const __be32 *p;
> > >
> > > -	np = of_find_node_by_path("/chosen/linux,sysrq-reset-seq");
> > > +	struct device_node *np __free(device_node) =
> > > +		of_find_node_by_path("/chosen/linux,sysrq-reset-seq");
> > > +
> > >  	if (!np) {
> > >  		pr_debug("No sysrq node found");
> > >  		return;
> > > @@ -781,8 +782,6 @@ static void sysrq_of_get_keyreset_config(void)
> > >
> > >  	/* Get reset timeout if any. */
> > >  	of_property_read_u32(np, "timeout-ms", &sysrq_reset_downtime_ms);
> > > -
> > > -	of_node_put(np);
> > >  }
> > >  #else
> > >  static void sysrq_of_get_keyreset_config(void)
> >
> > Also, this change really makes no sense at all, the pointer never goes
> > out of scope except when the function is over, at the bottom.  So why
> > make this complex change at all for no benefit?
> >
> > In other words, properly understand the change you are making and only
> > make it if it actually makes sense.  It does not make any sense here,
> > right?
> 
> Maybe it would be nice to get rid of of_node_puts in the general case?

That's a call for the of maintainer to make, and then if so, to do it
across the whole tree, right?

> Even though this one is not very annoying, there are some other functions
> where there are many of_node_puts, and convoluted error handling code to
> incorporate them on both the success and failure path.  So maybe it would
> be better to avoid the situation of having them sometimes and not having
> them other times?  But this is an opinion, and if the general consensus is
> to only get rid of the cases that currently add complexity, then that is
> possible too.

Let's keep things simple until it has to be complex please.

thanks,

greg k-h