From: David Rientjes <rientjes@google.com>
To: Andrey Ryabinin <a.ryabinin@samsung.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Dave Kleikamp <shaggy@kernel.org>, Christoph Hellwig <hch@lst.de>,
Sebastian Ott <sebott@linux.vnet.ibm.com>,
Mikulas Patocka <mpatocka@redhat.com>,
Catalin Marinas <catalin.marinas@arm.com>,
LKML <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
jfs-discussion@lists.sourceforge.net
Subject: Re: [patch v2 4/4] mm, mempool: poison elements backed by page allocator
Date: Thu, 2 Apr 2015 18:04:00 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.10.1504021803170.20229@chino.kir.corp.google.com> (raw)
In-Reply-To: <551A861B.7020701@samsung.com>
On Tue, 31 Mar 2015, Andrey Ryabinin wrote:
> > We don't have a need to set PAGE_EXT_DEBUG_POISON on these pages sitting
> > in the reserved pool, nor do we have a need to do kmap_atomic() since it's
> > already mapped and must be mapped to be on the reserved pool, which is
> > handled by mempool_free().
> >
>
> Hmm.. I just realized that this statement might be wrong.
> Why pages has to be mapped to be on reserved pool?
> mempool could be used for highmem pages and there is no need to kmap()
> until these pages will be used.
>
> drbd (drivers/block/drbd) already uses mempool for highmem pages:
>
Yes, you're exactly right, I didn't see this because the mempool is
created in one file and then solely used in another file, but regardless
we still need protection from this usecase.
next prev parent reply other threads:[~2015-04-03 1:04 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-24 23:08 [patch 1/4] fs, jfs: remove slab object constructor David Rientjes
2015-03-24 23:09 ` [patch 2/4] mm, mempool: disallow mempools based on slab caches with constructors David Rientjes
2015-03-24 23:09 ` [patch v2 3/4] mm, mempool: poison elements backed by slab allocator David Rientjes
2015-03-24 23:10 ` [patch v2 4/4] mm, mempool: poison elements backed by page allocator David Rientjes
2015-03-25 21:55 ` Andrew Morton
2015-03-26 16:07 ` Andrey Ryabinin
2015-03-26 20:38 ` Andrey Ryabinin
2015-03-26 22:50 ` David Rientjes
2015-03-30 8:53 ` Andrey Ryabinin
2015-03-31 11:33 ` Andrey Ryabinin
2015-04-03 1:04 ` David Rientjes [this message]
2015-04-03 1:07 ` [patch -mm] mm, mempool: poison elements backed by page allocator fix fix David Rientjes
2015-03-24 23:41 ` [patch 1/4] fs, jfs: remove slab object constructor Dave Kleikamp
2015-03-26 2:18 ` Mikulas Patocka
2015-03-26 2:37 ` David Rientjes
2015-03-26 7:28 ` Christoph Hellwig
2015-03-26 14:57 ` Dave Kleikamp
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=alpine.DEB.2.10.1504021803170.20229@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=a.ryabinin@samsung.com \
--cc=akpm@linux-foundation.org \
--cc=catalin.marinas@arm.com \
--cc=hch@lst.de \
--cc=jfs-discussion@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mpatocka@redhat.com \
--cc=sebott@linux.vnet.ibm.com \
--cc=shaggy@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).