public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jerome Glisse <jglisse@redhat.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Igor Stoppa <igor.stoppa@huawei.com>,
	Linux-MM <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-security-module@vger.kernel.org,
	"kernel-hardening@lists.openwall.com" 
	<kernel-hardening@lists.openwall.com>,
	Kees Cook <keescook@google.com>
Subject: Re: [RFC] Tagging of vmalloc pages for supporting the pmalloc allocator
Date: Thu, 3 Aug 2017 10:47:46 -0400	[thread overview]
Message-ID: <20170803144746.GA9501@redhat.com> (raw)
In-Reply-To: <20170803135549.GW12521@dhcp22.suse.cz>

On Thu, Aug 03, 2017 at 03:55:50PM +0200, Michal Hocko wrote:
> On Thu 03-08-17 15:20:31, Igor Stoppa wrote:
> > On 03/08/17 14:48, Michal Hocko wrote:
> > > On Thu 03-08-17 13:11:45, Igor Stoppa wrote:
> > >> On 02/08/17 20:08, Jerome Glisse wrote:
> > >>> On Wed, Aug 02, 2017 at 06:14:28PM +0300, Igor Stoppa wrote:
> > 
> > [...]
> > 
> > >>>> from include/linux/mm_types.h:
> > >>>>
> > >>>> struct page {
> > >>>> ...
> > >>>>   union {
> > >>>>     unsigned long private;		/* Mapping-private opaque data:
> > >>>> 				 	 * usually used for buffer_heads
> > >>>> 					 * if PagePrivate set; used for
> > >>>> 					 * swp_entry_t if PageSwapCache;
> > >>>> 					 * indicates order in the buddy
> > >>>> 					 * system if PG_buddy is set.
> > >>>> 					 */
> > 
> > [...]
> > 
> > >> If the "Mapping-private" was dropped or somehow connected exclusively to
> > >> the cases listed in the comment, then I think it would be more clear
> > >> that the comment needs to be intended as related to mapping in certain
> > >> cases only.
> > >> But it is otherwise ok to use the "private" field for whatever purpose
> > >> it might be suitable, as long as it is not already in use.
> > > 
> > > I would recommend adding a new field into the enum...
> > 
> > s/enum/union/ ?
> > 
> > If not, I am not sure what is the enum that you are talking about.
> 
> yeah, fat fingers on my side
> 
> > 
> > [...]
> > 
> > >> But, to reply more specifically to your advice, yes, I think I could add
> > >> a flag to vm_struct and then retrieve its value, for the address being
> > >> processed, by passing through find_vm_area().
> > > 
> > > ... and you can store vm_struct pointer to the struct page there 
> > 
> > "there" as in the new field of the union?
> > btw, what would be a meaningful name, since "private" is already taken?
> > 
> > For simplicity, I'll use, for now, "private2"
> 
> why not explicit vm_area?
> 
> > > and you> won't need to do the slow find_vm_area. I haven't checked
> > very closely
> > > but this should be possible in principle. I guess other callers might
> > > benefit from this as well.
> > 
> > I am confused about this: if "private2" is a pointer, but when I get an
> > address, I do not even know if the address represents a valid pmalloc
> > page, how can i know when it's ok to dereference "private2"?
> 
> because you can make all pages which back vmalloc mappings have vm_area
> pointer set.

Note that i think this might break some device driver that use vmap()
i think some of them use private field to store device driver specific
informations. But there likely is an unuse field in struct page that
can be use for that.

Jérôme

  parent reply	other threads:[~2017-08-03 14:47 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-02 15:14 [RFC] Tagging of vmalloc pages for supporting the pmalloc allocator Igor Stoppa
2017-08-02 17:08 ` Jerome Glisse
2017-08-03 10:11   ` Igor Stoppa
2017-08-03 11:48     ` Michal Hocko
2017-08-03 12:20       ` Igor Stoppa
2017-08-03 13:55         ` Michal Hocko
2017-08-03 14:41           ` Igor Stoppa
2017-08-03 14:47           ` Jerome Glisse [this message]
2017-08-03 15:06             ` Igor Stoppa
2017-08-03 15:15               ` Michal Hocko
2017-08-04  8:02                 ` Igor Stoppa
2017-08-04  8:12                   ` Michal Hocko
2017-08-07 11:26                     ` Igor Stoppa
2017-08-07 11:34                       ` Michal Hocko
2017-08-07 13:31                       ` Jerome Glisse
2017-08-07 14:13                         ` Igor Stoppa
2017-08-07 19:12                           ` Jerome Glisse
2017-08-08 12:59                             ` Igor Stoppa
2017-08-08 23:15                               ` Jerome Glisse
2017-08-09  7:27                                 ` Igor Stoppa
2017-08-10  7:14                                 ` Michal Hocko

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=20170803144746.GA9501@redhat.com \
    --to=jglisse@redhat.com \
    --cc=igor.stoppa@huawei.com \
    --cc=keescook@google.com \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-security-module@vger.kernel.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