All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Matthew Wilcox <willy@infradead.org>,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	Courtney Cavin <courtney.cavin@sonymobile.com>
Subject: Re: Preemptible idr_alloc() in QRTR code
Date: Tue, 26 Jan 2021 11:00:05 -0600	[thread overview]
Message-ID: <YBBKla3I2TxMFIvZ@builder.lan> (raw)
In-Reply-To: <20210126162154.GD80448@C02TD0UTHF1T.local>

On Tue 26 Jan 10:21 CST 2021, Mark Rutland wrote:

> On Tue, Jan 26, 2021 at 02:58:33PM +0000, Matthew Wilcox wrote:
> > On Tue, Jan 26, 2021 at 10:47:34AM +0000, Mark Rutland wrote:
> > > Hi,
> > > 
> > > When fuzzing arm64 with Syzkaller, I'm seeing some splats where
> > > this_cpu_ptr() is used in the bowels of idr_alloc(), by way of
> > > radix_tree_node_alloc(), in a preemptible context:
> > 
> > I sent a patch to fix this last June.  The maintainer seems to be
> > under the impression that I care an awful lot more about their
> > code than I do.
> > 
> > https://lore.kernel.org/netdev/20200605120037.17427-1-willy@infradead.org/
> 
> Ah; I hadn't spotted the (glaringly obvious) GFP_ATOMIC abuse, thanks
> for the pointer, and sorry for the noise.
> 

I'm afraid this isn't as obvious to me as it is to you. Are you saying
that one must not use GFP_ATOMIC in non-atomic contexts?


That said, glancing at the code I'm puzzled to why it would use
GFP_ATOMIC.

> It looks like Eric was after a fix that trivially backported to v4.7
> (and hence couldn't rely on xarray) but instead it just got left broken
> for months. :/
> 
> Bjorn, is this something you care about? You seem to have the most
> commits to the file, and otherwise the official maintainer is Dave
> Miller per get_maintainer.pl.
> 

I certainly care about qrtr working and remember glancing at Matthew's
patch, but seems like I never found time to properly review it.

> It is very tempting to make the config option depend on BROKEN...
> 

I hear you and that would be bad, so I'll make sure to take a proper
look at this and Matthew's patch.

Thanks,
Bjorn

  reply	other threads:[~2021-01-27  0:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-26 10:47 Preemptible idr_alloc() in QRTR code Mark Rutland
2021-01-26 14:58 ` Matthew Wilcox
2021-01-26 16:21   ` Mark Rutland
2021-01-26 17:00     ` Bjorn Andersson [this message]
2021-01-26 18:36       ` Mark Rutland
2021-01-27  0:41         ` Matthew Wilcox

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=YBBKla3I2TxMFIvZ@builder.lan \
    --to=bjorn.andersson@linaro.org \
    --cc=courtney.cavin@sonymobile.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=netdev@vger.kernel.org \
    --cc=willy@infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.