From: Matthew Wilcox <willy@infradead.org>
To: Igor Stoppa <igor.stoppa@gmail.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>,
Michal Hocko <mhocko@kernel.org>,
linux-mm@kvack.org
Subject: Re: Distinguishing VMalloc pages
Date: Tue, 12 Jun 2018 04:36:15 -0700 [thread overview]
Message-ID: <20180612113615.GB19433@bombadil.infradead.org> (raw)
In-Reply-To: <c99d981a-d55e-1759-a14a-4ef856072618@gmail.com>
On Tue, Jun 12, 2018 at 12:54:09PM +0300, Igor Stoppa wrote:
> On 11/06/18 15:11, Matthew Wilcox wrote:
> > I tried to use the page->mapping field in my earlier patch and that was
> > a problem because page_mapping() would return non-NULL, which broke
> > user-space unmapping of vmalloced pages through the zap_pte_range ->
> > set_page_dirty path.
>
> This seems pretty similar to what I am doing in a preparatory patch for
> pmalloc (I'm still working on this, I just got swamped in day-job related
> stuff, but I am progressing toward an example with IMA).
> So it looks like my patch won't work, after all?
>
> Although, in your case, you noticed a problem with userspace, while I do
> not care at all about that, so maybe there is some wriggling space there ...
Yes; if your pages can never be mapped to userspace, then there's no
problem. Many other users of struct page use the page->mapping field
for other purposes.
> Why not having a reference (either direct or indirect) to the actual
> vmap area, and then the flag there, instead?
Because what we're trying to do is find out "Given a random struct page,
what is it used for". It might be page cache, it might be slab, it
might be anything. We can't go round randomly dereferencing pointers
and seeing what pot of gold is at the end of that rainbow.
> I do not know the specific use case you have in mind - if any - but I
> think that if one is already trying to figure out what sort of use the
> vmalloc page is put to, then probably pretty soon there will be a need
> for a reference to the area.
>
> So what if the page could hold a reference the area, where there would
> be more space available for specifying what it is used for?
It might be useful to refer to the earlier patch which included that
information:
https://www.spinics.net/lists/linux-mm/msg152818.html
next prev parent reply other threads:[~2018-06-12 11:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-11 12:11 Matthew Wilcox
2018-06-11 17:25 ` Christopher Lameter
2018-06-11 17:59 ` Matthew Wilcox
2018-06-12 9:54 ` Igor Stoppa
2018-06-12 11:36 ` Matthew Wilcox [this message]
2018-06-12 12:35 ` Igor Stoppa
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=20180612113615.GB19433@bombadil.infradead.org \
--to=willy@infradead.org \
--cc=aryabinin@virtuozzo.com \
--cc=igor.stoppa@gmail.com \
--cc=linux-mm@kvack.org \
--cc=mhocko@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