All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrei Vagin <avagin@gmail.com>
To: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Dmitry Safonov <dima@arista.com>
Subject: Re: [PATCH 5/5] arm64/vdso: Restrict splitting VVAR VMA
Date: Sun, 23 Feb 2020 15:30:13 -0800	[thread overview]
Message-ID: <20200223233013.GB349924@gmail.com> (raw)
In-Reply-To: <df8fa53c-5c21-b620-0254-ffefdd3a8834@arm.com>

On Thu, Feb 20, 2020 at 12:22:52PM +0000, Vincenzo Frascino wrote:
> Hi Andrei,
> 
> On 04/02/2020 17:59, Andrei Vagin wrote:
> > Forbid splitting VVAR VMA resulting in a stricter ABI and reducing the
> > amount of corner-cases to consider while working further on VDSO time
> > namespace support.
> > 
> > As the offset from timens to VVAR page is computed compile-time, the pages
> > in VVAR should stay together and not being partically mremap()'ed.
> > 
> 
> I agree on the concept, but why do we need to redefine mremap?
> special_mapping_mremap() (mm/mmap.c +3317) seems doing already the same thing if
> we leave mremap == NULL as is.
> 

Hmmm. I have read the code of special_mapping_mremap() and I don't see where
it restricts splitting the vvar mapping.

Here is the code what I see in the source:

static int special_mapping_mremap(struct vm_area_struct *new_vma)
{
        struct vm_special_mapping *sm = new_vma->vm_private_data;

        if (WARN_ON_ONCE(current->mm != new_vma->vm_mm))
                return -EFAULT;

        if (sm->mremap)
                return sm->mremap(sm, new_vma);

        return 0;
}

And I have checked that without this patch, I can remap only one page of
the vvar mapping.

Thanks,
Andrei


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Andrei Vagin <avagin@gmail.com>
To: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Dmitry Safonov <dima@arista.com>
Subject: Re: [PATCH 5/5] arm64/vdso: Restrict splitting VVAR VMA
Date: Sun, 23 Feb 2020 15:30:13 -0800	[thread overview]
Message-ID: <20200223233013.GB349924@gmail.com> (raw)
In-Reply-To: <df8fa53c-5c21-b620-0254-ffefdd3a8834@arm.com>

On Thu, Feb 20, 2020 at 12:22:52PM +0000, Vincenzo Frascino wrote:
> Hi Andrei,
> 
> On 04/02/2020 17:59, Andrei Vagin wrote:
> > Forbid splitting VVAR VMA resulting in a stricter ABI and reducing the
> > amount of corner-cases to consider while working further on VDSO time
> > namespace support.
> > 
> > As the offset from timens to VVAR page is computed compile-time, the pages
> > in VVAR should stay together and not being partically mremap()'ed.
> > 
> 
> I agree on the concept, but why do we need to redefine mremap?
> special_mapping_mremap() (mm/mmap.c +3317) seems doing already the same thing if
> we leave mremap == NULL as is.
> 

Hmmm. I have read the code of special_mapping_mremap() and I don't see where
it restricts splitting the vvar mapping.

Here is the code what I see in the source:

static int special_mapping_mremap(struct vm_area_struct *new_vma)
{
        struct vm_special_mapping *sm = new_vma->vm_private_data;

        if (WARN_ON_ONCE(current->mm != new_vma->vm_mm))
                return -EFAULT;

        if (sm->mremap)
                return sm->mremap(sm, new_vma);

        return 0;
}

And I have checked that without this patch, I can remap only one page of
the vvar mapping.

Thanks,
Andrei


  reply	other threads:[~2020-02-23 23:30 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-04 17:59 [PATCH 0/5] arm64: add the time namespace support Andrei Vagin
2020-02-04 17:59 ` Andrei Vagin
2020-02-04 17:59 ` [PATCH 1/5] arm64/vdso: use the fault callback to map vvar pages Andrei Vagin
2020-02-04 17:59   ` Andrei Vagin
2020-02-20 12:36   ` Vincenzo Frascino
2020-02-20 12:36     ` Vincenzo Frascino
2020-02-04 17:59 ` [PATCH 2/5] arm64/vdso: Zap vvar pages when switching to a time namespace Andrei Vagin
2020-02-04 17:59   ` Andrei Vagin
2020-02-04 17:59 ` [PATCH 3/5] arm64/vdso: Add time napespace page Andrei Vagin
2020-02-04 17:59   ` Andrei Vagin
2020-02-20 12:03   ` Vincenzo Frascino
2020-02-20 12:03     ` Vincenzo Frascino
2020-02-04 17:59 ` [PATCH 4/5] arm64/vdso: Handle faults on timens page Andrei Vagin
2020-02-04 17:59   ` Andrei Vagin
2020-02-20 12:07   ` Vincenzo Frascino
2020-02-20 12:07     ` Vincenzo Frascino
2020-02-04 17:59 ` [PATCH 5/5] arm64/vdso: Restrict splitting VVAR VMA Andrei Vagin
2020-02-04 17:59   ` Andrei Vagin
2020-02-20 12:22   ` Vincenzo Frascino
2020-02-20 12:22     ` Vincenzo Frascino
2020-02-23 23:30     ` Andrei Vagin [this message]
2020-02-23 23:30       ` Andrei Vagin
2020-02-24 10:08       ` Vincenzo Frascino
2020-02-24 10:08         ` Vincenzo Frascino
2020-02-17 15:34 ` [PATCH 0/5] arm64: add the time namespace support Andrei Vagin
2020-02-17 15:34   ` Andrei Vagin
2020-02-17 18:25   ` Vincenzo Frascino
2020-02-17 18:25     ` Vincenzo Frascino
2020-02-20 12:40 ` Vincenzo Frascino
2020-02-20 12:40   ` Vincenzo Frascino
2020-02-23  8:08   ` Andrei Vagin
2020-02-23  8:08     ` Andrei Vagin

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=20200223233013.GB349924@gmail.com \
    --to=avagin@gmail.com \
    --cc=dima@arista.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=vincenzo.frascino@arm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.