linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Phillip Potter <phil@philpotter.co.uk>
To: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	Michael Straube <straube.linux@gmail.com>,
	Larry Finger <Larry.Finger@lwfinger.net>,
	"open list:STAGING SUBSYSTEM" <linux-staging@lists.linux.dev>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/3] staging: r8188eu: simplify c2h_evt_hdl function
Date: Sun, 29 Aug 2021 11:49:42 +0100	[thread overview]
Message-ID: <CAA=Fs0meC_nVjb2gESnmz2pPgzNa4=QT_jnteAh4B8Cds6_0fQ@mail.gmail.com> (raw)
In-Reply-To: <21174665.bKA57LRvRV@localhost.localdomain>

On Sun, 29 Aug 2021 at 09:52, Fabio M. De Francesco
<fmdefrancesco@gmail.com> wrote:
>
> >  static s32 c2h_evt_hdl(struct adapter *adapter, struct c2h_evt_hdr *c2h_evt, c2h_id_filter filter)
> >  {
> > -     s32 ret = _FAIL;
> >       u8 buf[16];
> >
> > -     if (!c2h_evt) {
> > -             /* No c2h event in cmd_obj, read c2h event before handling*/
> > -             if (c2h_evt_read(adapter, buf) == _SUCCESS) {
> > -                     c2h_evt = (struct c2h_evt_hdr *)buf;
>
> Dear Philip,
>
> Not related to your patch, but what kind of odd assignment is it? c2h_evt takes
> the address of a local variable and therefore it crashes the kernel whenever
> someone decides to dereference it after this function returns and unwinds
> the stack...

Dear Fabio,

Thank you for taking a look firstly, really appreciate it :-) As for the line:
c2h_evt = (struct c2h_evt_hdr *)buf;

in the original code before I removed it, bear in mind that this
pointer assignment is
happening into the parameter variable c2h_evt, which is a copy of the
passed in argument,
as C is pass-by-value. Therefore, after the c2h_evt_hdl function
returns, the value passed
in as the argument for this parameter would still have its original
pointer value (or NULL).

It would not therefore be possible to deference the pointer to this
stack-allocated memory
from outside the function, even in the original code. I agree though,
its purpose is dubious.
Originally, the wrapper function rtw_hal_c2h_handler would have passed
it through to the
function assigned to the c2h_handler function pointer, but there was
no such function in
this driver, so it was never executed.

>
> > +     if (!c2h_evt)
> > +             c2h_evt_read(adapter, buf);
>
> Having said that, I strongly doubt that this path is ever taken. I didn't check the call
> chain, but it may be that the function in never called or, if it is called, it always
> has a valid c2h_evt argument.
>
> Actually I don't mean to suggest something specific. It simply looks odd, so I'd check
> and if this happens to be the case, I'd remove the whole c2h_evt_hdl().
>
> Regards,
>
> Fabio

As alluded to, removing the whole of c2h_evt_hdl would lead to
c2h_evt_read no longer
being executed, which would mean the reads from the adapter register
don't happen, and
nor does the clearing by c2h_evt_clear(adapter); - in particular, the
comment there mentions
the FW not updating the next command message if this isn't executed when needed.

This may be perfectly fine, but I thought this approach is safer due
to the above.

Regards,
Phil

  reply	other threads:[~2021-08-29 10:51 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-28 21:24 [PATCH 0/3] staging: r8188eu: cleanup c2h_handler code Phillip Potter
2021-08-28 21:24 ` [PATCH 1/3] staging: r8188eu: remove c2h_handler field from struct hal_ops Phillip Potter
2021-08-28 21:24 ` [PATCH 2/3] staging: r8188eu: simplify c2h_evt_hdl function Phillip Potter
2021-08-29  8:52   ` Fabio M. De Francesco
2021-08-29 10:49     ` Phillip Potter [this message]
2021-08-29 12:35       ` Fabio M. De Francesco
2021-08-29 11:54   ` Pavel Skripkin
2021-08-29 23:18     ` Phillip Potter
2021-08-30  8:06       ` Pavel Skripkin
2021-08-28 21:24 ` [PATCH 3/3] staging: r8188eu: remove rtw_hal_c2h_handler function Phillip Potter
2021-08-29 12:48 ` [PATCH 0/3] staging: r8188eu: cleanup c2h_handler code Fabio M. De Francesco
2021-08-29 22:59   ` Phillip Potter
2021-08-29 15:04 ` Michael Straube
2021-08-29 22:57   ` Phillip Potter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAA=Fs0meC_nVjb2gESnmz2pPgzNa4=QT_jnteAh4B8Cds6_0fQ@mail.gmail.com' \
    --to=phil@philpotter.co.uk \
    --cc=Larry.Finger@lwfinger.net \
    --cc=fmdefrancesco@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=straube.linux@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).