Re: [PATCH v3] remoteproc: Fix NULL vs IS_ERR() checking in rproc_create_trace_file

[Mathieu Poirier]

On Mon, Jan 17, 2022 at 04:31:23PM -0600, Bjorn Andersson wrote:
> On Mon 17 Jan 11:06 CST 2022, Mathieu Poirier wrote:
> 
> > On Wed, Jan 05, 2022 at 01:10:22PM +0000, Miaoqian Lin wrote:
> > > The debugfs_create_file() function doesn't return NULL.
> > > It returns error pointers. Fix check in rproc_create_trace_file
> > > and make it returns return error pointers.
> > 
> > s/"returns return"/return
> > 
> > > Fix check in rproc_handle_trace to propagate the error code.
> > > 
> > > Signed-off-by: Miaoqian Lin <linmq006@xxxxxxxxx>
> > > ---
> > > Changes in v2:
> > > - return PTR_ERR(tfile) in rproc_create_trace_file
> > > - fix check in rproc_handle_trace()
> > > Changes in v3:
> > > - return tfile to fix incorrect return type in v2
> > > ---
> > >  drivers/remoteproc/remoteproc_core.c    | 6 ++++--
> > >  drivers/remoteproc/remoteproc_debugfs.c | 4 +---
> > >  2 files changed, 5 insertions(+), 5 deletions(-)
> > >
> > 
> > I will fix the above, add a proper "Fixes" tag and apply this patch to
> > rproc-next when v5.17-rc1 comes out next week.
> > 
> 
> We're actually not supposed to check debugfs_create_*() for errors.

I'm interested in knowing more about this - can you expand on the specifics or
perharps provide a link?

> 
> > Thanks,
> > Mathieu
> > 
> > > diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> > > index 775df165eb45..5608408f8eac 100644
> > > --- a/drivers/remoteproc/remoteproc_core.c
> > > +++ b/drivers/remoteproc/remoteproc_core.c
> > > @@ -656,6 +656,7 @@ static int rproc_handle_trace(struct rproc *rproc, void *ptr,
> > >  	struct rproc_debug_trace *trace;
> > >  	struct device *dev = &rproc->dev;
> > >  	char name[15];
> > > +	int ret;
> > >  
> > >  	if (sizeof(*rsc) > avail) {
> > >  		dev_err(dev, "trace rsc is truncated\n");
> > > @@ -684,9 +685,10 @@ static int rproc_handle_trace(struct rproc *rproc, void *ptr,
> > >  
> > >  	/* create the debugfs entry */
> > >  	trace->tfile = rproc_create_trace_file(name, rproc, trace);
> > > -	if (!trace->tfile) {
> > > +	if (IS_ERR(trace->tfile)) {
> > > +		ret = PTR_ERR(trace->tfile);
> > >  		kfree(trace);
> > > -		return -EINVAL;
> > > +		return ret;
> 
> 
> And actually catching and propagating the error here means that we will
> start failing rproc_boot() for firmware including a RSC_TRACE when
> debugfs is disabled...
> 
> So if we really want to save the heap space we should at least cleanly
> ignore the error, by cleaning up and returning 0 here.

Humm... To me the _intent_ of the upstream code has always been to propagate
errors reported by rproc_create_trace_file().  The fact that is hasn't happen
because of inappropriate error handling is something that should be corrected.  

That being said disabling debugfs is a common practice for production systems
and I agree that handling such a condition by returning 0 when
rproc_create_trace_file() returns -ENODEV is the right thing to do.   

Thanks,
Mathieu

> 
> > >  	}
> > >  
> > >  	list_add_tail(&trace->node, &rproc->traces);
> > > diff --git a/drivers/remoteproc/remoteproc_debugfs.c b/drivers/remoteproc/remoteproc_debugfs.c
> > > index b5a1e3b697d9..2ae59a365b7e 100644
> > > --- a/drivers/remoteproc/remoteproc_debugfs.c
> > > +++ b/drivers/remoteproc/remoteproc_debugfs.c
> > > @@ -390,10 +390,8 @@ struct dentry *rproc_create_trace_file(const char *name, struct rproc *rproc,
> > >  
> > >  	tfile = debugfs_create_file(name, 0400, rproc->dbg_dir, trace,
> > >  				    &trace_rproc_ops);
> > > -	if (!tfile) {
> > > +	if (IS_ERR(tfile))
> > >  		dev_err(&rproc->dev, "failed to create debugfs trace entry\n");
> 
> And I therefor think this function would be better reduced to:
> 
> 	return debugfs_create_file(...);
> 
> Regards,
> Bjorn
> 
> > > -		return NULL;
> > > -	}
> > >  
> > >  	return tfile;
> > >  }
> > > -- 
> > > 2.17.1
> > >