Re: [PATCHv3 33/33] mm, x86: introduce PR_SET_MAX_VADDR and PR_GET_MAX_VADDR

[Dmitry Safonov]

On 03/06/2017 05:17 PM, Kirill A. Shutemov wrote:
> On Mon, Mar 06, 2017 at 05:00:28PM +0300, Dmitry Safonov wrote:
> > 2017-02-21 15:42 GMT+03:00 Kirill A. Shutemov <kirill@xxxxxxxxxxxxx>:
> > > On Tue, Feb 21, 2017 at 02:54:20PM +0300, Dmitry Safonov wrote:
> > > > 2017-02-17 19:50 GMT+03:00 Andy Lutomirski <luto@xxxxxxxxxxxxxx>:
> > > > > On Fri, Feb 17, 2017 at 6:13 AM, Kirill A. Shutemov
> > > > > <kirill.shutemov@xxxxxxxxxxxxxxx> wrote:
> > > > > > This patch introduces two new prctl(2) handles to manage maximum virtual
> > > > > > address available to userspace to map.
> > > > ...
> > > > > Anyway, can you and Dmitry try to reconcile your patches?
> > > >
> > > > So, how can I help that?
> > > > Is there the patch's version, on which I could rebase?
> > > > Here are BTW the last patches, which I will resend with trivial ifdef-fixup
> > > > after the merge window:
> > > > http://marc.info/?i=20170214183621.2537-1-dsafonov%20()%20virtuozzo%20!%20com
> > >
> > > Could you check if this patch collides with anything you do:
> > >
> > > http://lkml.kernel.org/r/20170220131515.GA9502@xxxxxxxxxxxxxxxxxx
> >
> > Ok, sorry for the late reply - it was the merge window anyway and I've got
> > urgent work to do.
> >
> > Let's see:
> >
> > I'll need minor merge fixup here:
> > > -#define TASK_UNMAPPED_BASE (PAGE_ALIGN(TASK_SIZE / 3))
> > > +#define TASK_UNMAPPED_BASE (PAGE_ALIGN(DEFAULT_MAP_WINDOW / 3))
> > while in my patches:
> > > +#define __TASK_UNMAPPED_BASE(task_size)        (PAGE_ALIGN(task_size / 3))
> > > +#define TASK_UNMAPPED_BASE             __TASK_UNMAPPED_BASE(TASK_SIZE)
> >
> > This should be just fine with my changes:
> > > - info.high_limit = end;
> > > + info.high_limit = min(end, DEFAULT_MAP_WINDOW);
> >
> > This will need another minor fixup:
> > > -#define MAX_GAP (TASK_SIZE/6*5)
> > > +#define MAX_GAP (DEFAULT_MAP_WINDOW/6*5)
> > I've moved it from macro to mmap_base() as local var,
> > which depends on task_size parameter.
> >
> > That's all, as far as I can see at this moment.
> > Does not seems hard to fix. So I suggest sending patches sets
> > in parallel, the second accepted will rebase the set.
> > Is it convenient for you?
>
> Works for me.
>
> In fact, I've just sent v4 of the patchset.

Ok, thanks.

--
             Dmitry