linux-kernel - Re: [PATCH v2 7/7] staging: r8188eu: convert DBG_88E calls in core/rtw_sta

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] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 14 Jan 2022 00:32:48 +0000
From:   Phillip Potter <phil@...lpotter.co.uk>
To:     Pavel Skripkin <paskripkin@...il.com>
Cc:     Larry.Finger@...inger.net, straube.linux@...il.com,
        martin@...ser.cx, linux-staging@...ts.linux.dev,
        linux-kernel@...r.kernel.org, gregkh@...uxfoundation.org
Subject: Re: [PATCH v2 7/7] staging: r8188eu: convert DBG_88E calls in
 core/rtw_sta_mgt.c

On Tue, Jan 11, 2022 at 12:05:09AM +0300, Pavel Skripkin wrote:
> Hi Phillip,
> 
> On 1/10/22 12:00, Phillip Potter wrote:
> > Convert the DBG_88E macro calls in core/rtw_sta_mgt.c to use pr_debug,
> > as their information may be useful to observers, and this gets the
> > driver closer to the point of being able to remove DBG_88E itself.
> > 
> > These calls are at points in the call chain where use of dev_dbg or
> > netdev_dbg isn't possible due to lack of device pointer, so plain
> > pr_debug is appropriate here.
> > 
> > Signed-off-by: Phillip Potter <phil@...lpotter.co.uk>
> > ---
> >   drivers/staging/r8188eu/core/rtw_sta_mgt.c | 4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/staging/r8188eu/core/rtw_sta_mgt.c b/drivers/staging/r8188eu/core/rtw_sta_mgt.c
> > index 54561ff239a0..de5406a5870c 100644
> > --- a/drivers/staging/r8188eu/core/rtw_sta_mgt.c
> > +++ b/drivers/staging/r8188eu/core/rtw_sta_mgt.c
> > @@ -104,7 +104,7 @@ inline int rtw_stainfo_offset(struct sta_priv *stapriv, struct sta_info *sta)
> >   	int offset = (((u8 *)sta) - stapriv->pstainfo_buf) / sizeof(struct sta_info);
> >   	if (!stainfo_offset_valid(offset))
> > -		DBG_88E("%s invalid offset(%d), out of range!!!", __func__, offset);
> > +		pr_debug("invalid offset(%d), out of range!!!", offset);
> >   	return offset;
> >   }
> 
> There is only one caller of this function and it also checks if offset is
> valid. I think, this check with debug message can be removed from this
> function.
> 

Dear Pavel,

Thank you for your feedback, much appreciated. Good call on this one, I
can take it out in a subsequent v3 series.

> > @@ -112,7 +112,7 @@ inline int rtw_stainfo_offset(struct sta_priv *stapriv, struct sta_info *sta)
> >   inline struct sta_info *rtw_get_stainfo_by_offset(struct sta_priv *stapriv, int offset)
> >   {
> >   	if (!stainfo_offset_valid(offset))
> > -		DBG_88E("%s invalid offset(%d), out of range!!!", __func__, offset);
> > +		pr_debug("invalid offset(%d), out of range!!!", offset);
> >   	return (struct sta_info *)(stapriv->pstainfo_buf + offset * sizeof(struct sta_info));
> >   }
> 
> Is it safe to proceed with invalid offset? Debug message says it's out of
> range, so might be we should just return with an error?
> 
> 
> 
> 
> With regards,
> Pavel Skripkin

I would need to check the code, but good observation. I wanted to limit
the scope of this series explicitly to DBG_88E calls, but might be worth
changing this at the same time.

Regards,
Phil