linux-kernel - Re: [PATCH next] coresight: Fix a NULL vs IS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250724132944.GK3137075@e132581.arm.com>
Date: Thu, 24 Jul 2025 14:29:44 +0100
From: Leo Yan <leo.yan@....com>
To: Anshuman Khandual <anshuman.khandual@....com>
Cc: Dan Carpenter <dan.carpenter@...aro.org>,
	Yuanfang Zhang <quic_yuanfang@...cinc.com>,
	Suzuki K Poulose <suzuki.poulose@....com>,
	Mike Leach <mike.leach@...aro.org>,
	James Clark <james.clark@...aro.org>,
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
	coresight@...ts.linaro.org, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org
Subject: Re: [PATCH next] coresight: Fix a NULL vs IS_ERR() bug in probe

On Mon, Jul 21, 2025 at 04:46:30PM +0530, Anshuman Khandual wrote:

[...]

> > diff --git a/drivers/hwtracing/coresight/coresight-tnoc.c b/drivers/hwtracing/coresight/coresight-tnoc.c
> > index 0e4164707eea..d542df46ea39 100644
> > --- a/drivers/hwtracing/coresight/coresight-tnoc.c
> > +++ b/drivers/hwtracing/coresight/coresight-tnoc.c
> > @@ -183,8 +183,8 @@ static int trace_noc_probe(struct amba_device *adev, const struct amba_id *id)
> >  	dev_set_drvdata(dev, drvdata);
> >  
> >  	drvdata->base = devm_ioremap_resource(dev, &adev->res);
> > -	if (!drvdata->base)
> > -		return -ENOMEM;
> > +	if (IS_ERR(drvdata->base))
> > +		return PTR_ERR(drvdata->base);
> >  
> >  	spin_lock_init(&drvdata->spinlock);
> >  
> 
> Do we still have more similar instances in coresight ?

It is a bit shame that I have enabled smatch for static checking but
did not verify this series.

I can confirm that the coresight driver does not have such issue in the
current code base. After merging the CoreSight clock fix series, we
should be able to dismiss all errors reported by smatch in CoreSight
drivers.

A side topic, I observed that smatch does not like the long functions
in drivers/hwtracing/coresight/coresight-etm4x-core.c. So I built a
smatch version with relaxed limits.

---8<---

diff --git a/smatch_implied.c b/smatch_implied.c                        
index 9055d676..7469f1ac 100644                                         
--- a/smatch_implied.c                                                  
+++ b/smatch_implied.c                                                  
@@ -462,13 +462,13 @@ static int going_too_slow(void)                   
                return 1;                                               
        }                                                               
                                                                        
-       if (time_parsing_function() < 60) {                             
+       if (time_parsing_function() < 300) {                            
                implications_off = false;                               
                return 0;                                               
        }                                                               
                                                                        
        if (!__inline_fn && printed != cur_func_sym) {                  
-               sm_perror("turning off implications after 60 seconds"); 
+               sm_perror("turning off implications after 300 seconds");
                printed = cur_func_sym;                                 
        }                                                               
        implications_off = true;                                        
diff --git a/smatch_slist.c b/smatch_slist.c                            
index cc3d73b7..039cdae7 100644                                         
--- a/smatch_slist.c                                                    
+++ b/smatch_slist.c                                                    
@@ -321,7 +321,7 @@ char *alloc_sname(const char *str)                  
 }                                                                      
                                                                        
 static struct symbol *oom_func;                                        
-static int oom_limit = 3000000;  /* Start with a 3GB limit */          
+static int oom_limit = 4000000;  /* Start with a 4GB limit */          
 int out_of_memory(void)                                                
 {                                                                      
        if (oom_func)                                                   
@@ -332,7 +332,7 @@ int out_of_memory(void)                             
         * It works out OK for the kernel and so it should work         
         * for most other projects as well.                             
         */                                                             
-       if (sm_state_counter * sizeof(struct sm_state) >= 100000000)    
+       if (sm_state_counter * sizeof(struct sm_state) >= 500000000)    
                return 1;                                               
                                                                        
        /*