From: "Tobin C. Harding" <me@tobin.cc>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "Tobin C. Harding" <tobin@kernel.org>, LKP <lkp@01.org>,
Roman Gushchin <guro@fb.com>, Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Matthew Wilcox <willy@infradead.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
kernel test robot <lkp@intel.com>
Subject: Re: [PATCH 1/1] slob: Only use list functions when safe to do so
Date: Wed, 3 Apr 2019 06:05:38 +1100 [thread overview]
Message-ID: <20190402190538.GA5084@eros.localdomain> (raw)
In-Reply-To: <20190401214128.c671d1126b14745a43937969@linux-foundation.org>
On Mon, Apr 01, 2019 at 09:41:28PM -0700, Andrew Morton wrote:
> On Tue, 2 Apr 2019 14:29:57 +1100 "Tobin C. Harding" <tobin@kernel.org> wrote:
>
> > Currently we call (indirectly) list_del() then we manually try to combat
> > the fact that the list may be in an undefined state by getting 'prev'
> > and 'next' pointers in a somewhat contrived manner. It is hard to
> > verify that this works for all initial states of the list. Clearly the
> > author (me) got it wrong the first time because the 0day kernel testing
> > robot managed to crash the kernel thanks to this code.
> >
> > All this is done in order to do an optimisation aimed at preventing
> > fragmentation at the start of a slab. We can just skip this
> > optimisation any time the list is put into an undefined state since this
> > only occurs when an allocation completely fills the slab and in this
> > case the optimisation is unnecessary since we have not fragmented the slab
> > by this allocation.
> >
> > Change the page pointer passed to slob_alloc_page() to be a double
> > pointer so that we can set it to NULL to indicate that the page was
> > removed from the list. Skip the optimisation if the page was removed.
> >
> > Found thanks to the kernel test robot, email subject:
> >
> > 340d3d6178 ("mm/slob.c: respect list_head abstraction layer"): kernel BUG at lib/list_debug.c:31!
> >
>
> It's regrettable that this fixes
> slob-respect-list_head-abstraction-layer.patch but doesn't apply to
> that patch - slob-use-slab_list-instead-of-lru.patch gets in the way.
> So we end up with a patch series which introduces a bug and later
> fixes it.
Yes I thought that also. Do you rebase the mm tree? Did you apply this
right after slob-use-slab_list-instead-of-lru or to the current tip? If
it is applied to the tip does this effect the ability to later bisect in
between these two commits (if the need arises for some unrelated reason)?
> I guess we can live with that but if the need comes to respin this
> series, please do simply fix
> slob-respect-list_head-abstraction-layer.patch so we get a clean
> series.
If its not too much work for you to apply the new series I'll do another
version just to get this right.
Tobin.
next prev parent reply other threads:[~2019-04-02 19:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-02 3:29 [PATCH 0/1] slob: Fix list_head bug during allocation Tobin C. Harding
2019-04-02 3:29 ` [PATCH 1/1] slob: Only use list functions when safe to do so Tobin C. Harding
2019-04-02 4:41 ` Andrew Morton
2019-04-02 19:05 ` Tobin C. Harding [this message]
2019-04-02 19:12 ` Andrew Morton
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=20190402190538.GA5084@eros.localdomain \
--to=me@tobin.cc \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=guro@fb.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lkp@01.org \
--cc=lkp@intel.com \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=tobin@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox