From: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Larry Finger <Larry.Finger@lwfinger.net>,
Phillip Potter <phil@philpotter.co.uk>,
linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] staging: r8188eu: Use kzalloc() with GFP_ATOMIC in atomic context
Date: Sun, 07 Nov 2021 14:15:59 +0100 [thread overview]
Message-ID: <6109499.H5l3i5aCOD@localhost.localdomain> (raw)
In-Reply-To: <YYfIywQ3AqrWbi8z@kroah.com>
On Sunday, November 7, 2021 1:38:35 PM CET Greg Kroah-Hartman wrote:
> On Sun, Nov 07, 2021 at 12:43:51PM +0100, Fabio M. De Francesco wrote:
> > On Monday, November 1, 2021 8:18:47 PM CET Fabio M. De Francesco wrote:
> > > Use the GFP_ATOMIC flag of kzalloc() with two memory allocation in
> > > report_del_sta_event(). This function is called while holding
spinlocks,
> > > therefore it is not allowed to sleep. With the GFP_ATOMIC type flag,
the
> > > allocation is high priority and must not sleep.
> > >
> > > This issue is detected by Smatch which emits the following warning:
> > > "drivers/staging/r8188eu/core/rtw_mlme_ext.c:6848
report_del_sta_event()
> > > warn: sleeping in atomic context".
> > >
> > > After the change, the post-commit hook output the following message:
> > > "CHECK: Prefer kzalloc(sizeof(*pcmd_obj)...) over
> > > kzalloc(sizeof(struct cmd_obj)...)".
> > >
> > > According to the above "CHECK", use the preferred style in the first
> > > kzalloc().
> > >
> > > Fixes: 79f712ea994d ("staging: r8188eu: Remove wrappers for kalloc()
and
> > kzalloc()")
> > > Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com>
> > > ---
> > > [...]
> > Please let me know if there is something that prevents this patch to be
> > applied. I have no problem in changing / adding whatever it is needed.
>
> Nothing needs to be done, I am waiting for 5.16-rc1 to be released
> before I pick up this patch, and others that will be targeted for
> 5.16-final. Only then will I queue them up, as the automated email you
> should have gotten when you submitted the patch said would happen.
>
> Just relax, there is no rush here :)
>
Oh, sorry Greg. There must be something that I haven't understand about the
development process... :(
Obviously I agree that there is no rush here :)
As I said, this morning I read git log and saw patches that seemed more
recent; thus I thought that was the case to ask. I just (wrongly) thought
that the v3 of the patch got unnoticed or dropped because of some requests
that I had missed.
Thanks for the explanation,
Fabio
> thanks,
>
> greg k-h
>
next prev parent reply other threads:[~2021-11-07 13:16 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-01 19:18 [PATCH v3] staging: r8188eu: Use kzalloc() with GFP_ATOMIC in atomic context Fabio M. De Francesco
2021-11-05 13:25 ` Dan Carpenter
2021-11-05 15:18 ` Fabio M. De Francesco
2021-11-05 15:36 ` Dan Carpenter
2021-11-05 16:05 ` Fabio M. De Francesco
2021-11-07 11:43 ` Fabio M. De Francesco
2021-11-07 12:38 ` Greg Kroah-Hartman
2021-11-07 13:15 ` Fabio M. De Francesco [this message]
2021-11-07 13:29 ` Greg Kroah-Hartman
2021-11-07 14:03 ` Fabio M. De Francesco
2021-11-07 14:17 ` Greg Kroah-Hartman
2021-11-07 14:30 ` Fabio M. De Francesco
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=6109499.H5l3i5aCOD@localhost.localdomain \
--to=fmdefrancesco@gmail.com \
--cc=Larry.Finger@lwfinger.net \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=phil@philpotter.co.uk \
/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