Messages in this thread | | | Date | Mon, 6 Mar 2017 17:17:46 +0300 | From | "Kirill A. Shutemov" <> | Subject | Re: [PATCHv3 33/33] mm, x86: introduce PR_SET_MAX_VADDR and PR_GET_MAX_VADDR |
| |
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@shutemov.name>: > > On Tue, Feb 21, 2017 at 02:54:20PM +0300, Dmitry Safonov wrote: > >> 2017-02-17 19:50 GMT+03:00 Andy Lutomirski <luto@amacapital.net>: > >> > On Fri, Feb 17, 2017 at 6:13 AM, Kirill A. Shutemov > >> > <kirill.shutemov@linux.intel.com> 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@node.shutemov.name > > 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.
-- Kirill A. Shutemov
| |