From: Matthew Wilcox <willy@infradead.org>
To: Christopher Lameter <cl@linux.com>
Cc: Waiman Long <longman@redhat.com>, Oleg Nesterov <oleg@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
selinux@vger.kernel.org, Paul Moore <paul@paul-moore.com>,
Stephen Smalley <sds@tycho.nsa.gov>,
Eric Paris <eparis@parisplace.org>,
"Peter Zijlstra (Intel)" <peterz@infradead.org>
Subject: Re: [PATCH 2/4] signal: Make flush_sigqueue() use free_q to release memory
Date: Mon, 25 Mar 2019 08:26:14 -0700 [thread overview]
Message-ID: <20190325152613.GG10344@bombadil.infradead.org> (raw)
In-Reply-To: <01000169b534b9e8-31a2af2c-c396-47f9-8534-4cbd934ef09d-000000@email.amazonses.com>
On Mon, Mar 25, 2019 at 02:15:25PM +0000, Christopher Lameter wrote:
> On Fri, 22 Mar 2019, Matthew Wilcox wrote:
>
> > On Fri, Mar 22, 2019 at 07:39:31PM +0000, Christopher Lameter wrote:
> > > On Fri, 22 Mar 2019, Waiman Long wrote:
> > >
> > > > >
> > > > >> I am looking forward to it.
> > > > > There is also alrady rcu being used in these paths. kfree_rcu() would not
> > > > > be enough? It is an estalished mechanism that is mature and well
> > > > > understood.
> > > > >
> > > > In this case, the memory objects are from kmem caches, so they can't
> > > > freed using kfree_rcu().
> > >
> > > Oh they can. kfree() can free memory from any slab cache.
> >
> > Only for SLAB and SLUB. SLOB requires that you pass a pointer to the
> > slab cache; it has no way to look up the slab cache from the object.
>
> Well then we could either fix SLOB to conform to the others or add a
> kmem_cache_free_rcu() variant.
The problem with a kmem_cache_free_rcu() variant is that we now have
three pointers to store -- the object pointer, the slab pointer and the
rcu next pointer.
I spent some time looking at how SLOB might be fixed, and I didn't come
up with a good idea. Currently SLOB stores the size of the object in the
four bytes before the object, unless the object is "allocated from a slab
cache", in which case the size is taken from the cache pointer instead.
So calling kfree() on a pointer allocated using kmem_cache_alloc() will
cause corruption as it attempts to determine the length of the object.
Options:
1. Dispense with this optimisation and always store the size of the
object before the object.
2. Add a kmem_cache flag that says whether objects in this cache may be
freed with kfree(). Only dispense with this optimisation for slabs
with this flag set.
3. Change SLOB to segregate objects by size. If someone has gone to
the trouble of creating a kmem_cache, this is a pretty good hint that
there will be a lot of objects of this size allocated, so this could
help SLOB fight fragmentation.
Any other bright ideas?
next prev parent reply other threads:[~2019-03-25 15:26 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-21 21:45 [PATCH 0/4] Signal: Fix hard lockup problem in flush_sigqueue() Waiman Long
2019-03-21 21:45 ` [PATCH 1/4] mm: Implement kmem objects freeing queue Waiman Long
2019-03-22 17:47 ` Christopher Lameter
2019-03-21 21:45 ` [PATCH 2/4] signal: Make flush_sigqueue() use free_q to release memory Waiman Long
2019-03-22 1:52 ` Matthew Wilcox
2019-03-22 11:16 ` Oleg Nesterov
2019-03-22 16:10 ` Waiman Long
2019-03-22 17:50 ` Christopher Lameter
2019-03-22 18:12 ` Waiman Long
2019-03-22 19:39 ` Christopher Lameter
2019-03-22 19:59 ` Matthew Wilcox
2019-03-25 14:15 ` Christopher Lameter
2019-03-25 15:26 ` Matthew Wilcox [this message]
2019-03-25 16:16 ` Christopher Lameter
2019-03-26 13:36 ` Oleg Nesterov
2019-03-26 13:29 ` Oleg Nesterov
2019-03-21 21:45 ` [PATCH 3/4] signal: Add free_uid_to_q() Waiman Long
2019-03-21 21:45 ` [PATCH 4/4] mm: Do periodic rescheduling when freeing objects in kmem_free_up_q() Waiman Long
2019-03-21 22:00 ` Peter Zijlstra
2019-03-22 14:35 ` Waiman Long
2019-03-22 10:15 ` [PATCH 0/4] Signal: Fix hard lockup problem in flush_sigqueue() Matthew Wilcox
2019-03-22 11:49 ` Oleg Nesterov
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=20190325152613.GG10344@bombadil.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=eparis@parisplace.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=longman@redhat.com \
--cc=oleg@redhat.com \
--cc=paul@paul-moore.com \
--cc=penberg@kernel.org \
--cc=peterz@infradead.org \
--cc=rientjes@google.com \
--cc=sds@tycho.nsa.gov \
--cc=selinux@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).