diff mbox

[PATCHv2] ARM32: Support mremap() for sigpage/vDSO

Message ID 20170414132529.8337-1-dsafonov@virtuozzo.com (mailing list archive)
State New, archived
Headers show

Commit Message

Dmitry Safonov April 14, 2017, 1:25 p.m. UTC
CRIU restores application mappings on the same place where they
were before Checkpoint. That means, that we need to move vDSO
and sigpage during restore on exactly the same place where
they were before C/R.

Make mremap() code update mm->context.{sigpage,vdso} pointers
during VMA move. Sigpage is used for landing after handling
a signal - if the pointer is not updated during moving, the
application might crash on any signal after mremap().

vDSO pointer on ARM32 is used only for setting auxv at this moment,
update it during mremap() in case of future usage.

Without those updates, current work of CRIU on ARM32 is not reliable.
Historically, we error Checkpointing if we find vDSO page on ARM32
and suggest user to disable CONFIG_VDSO.
But that's not correct - it goes from x86 where signal processing
is ended in vDSO blob. For arm32 it's sigpage, which is not disabled
with `CONFIG_VDSO=n'.

Looks like C/R was working by luck - because userspace on ARM32 at
this moment always sets SA_RESTORER.

Cc: linux-arm-kernel@lists.infradead.org
Cc: Russell King <linux@armlinux.org.uk>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Cc: Pavel Emelyanov <xemul@virtuozzo.com>
Cc: Christopher Covington <cov@codeaurora.org>
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
---
v2: (buildbot) Fix (unsinged long) to (void*) cast warning.

 arch/arm/kernel/process.c |  8 ++++++++
 arch/arm/kernel/vdso.c    | 18 ++++++++++++++++++
 arch/x86/entry/vdso/vma.c |  3 ---
 mm/mmap.c                 |  4 ++++
 4 files changed, 30 insertions(+), 3 deletions(-)

Comments

Dmitry Safonov April 25, 2017, 5:18 p.m. UTC | #1
On 04/14/2017 04:25 PM, Dmitry Safonov wrote:
> CRIU restores application mappings on the same place where they
> were before Checkpoint. That means, that we need to move vDSO
> and sigpage during restore on exactly the same place where
> they were before C/R.
> 
> Make mremap() code update mm->context.{sigpage,vdso} pointers
> during VMA move. Sigpage is used for landing after handling
> a signal - if the pointer is not updated during moving, the
> application might crash on any signal after mremap().
> 
> vDSO pointer on ARM32 is used only for setting auxv at this moment,
> update it during mremap() in case of future usage.
> 
> Without those updates, current work of CRIU on ARM32 is not reliable.
> Historically, we error Checkpointing if we find vDSO page on ARM32
> and suggest user to disable CONFIG_VDSO.
> But that's not correct - it goes from x86 where signal processing
> is ended in vDSO blob. For arm32 it's sigpage, which is not disabled
> with `CONFIG_VDSO=n'.
> 
> Looks like C/R was working by luck - because userspace on ARM32 at
> this moment always sets SA_RESTORER.
> 
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Andy Lutomirski <luto@amacapital.net>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Cyrill Gorcunov <gorcunov@openvz.org>
> Cc: Pavel Emelyanov <xemul@virtuozzo.com>
> Cc: Christopher Covington <cov@codeaurora.org>
> Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
> ---
> v2: (buildbot) Fix (unsinged long) to (void*) cast warning.
> 
>   arch/arm/kernel/process.c |  8 ++++++++
>   arch/arm/kernel/vdso.c    | 18 ++++++++++++++++++
>   arch/x86/entry/vdso/vma.c |  3 ---
>   mm/mmap.c                 |  4 ++++
>   4 files changed, 30 insertions(+), 3 deletions(-)

Ping?

> 
> diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
> index 939e8b58c59d..1e6039cac68d 100644
> --- a/arch/arm/kernel/process.c
> +++ b/arch/arm/kernel/process.c
> @@ -404,9 +404,17 @@ static unsigned long sigpage_addr(const struct mm_struct *mm,
>   static struct page *signal_page;
>   extern struct page *get_signal_page(void);
>   
> +static int sigpage_mremap(const struct vm_special_mapping *sm,
> +		struct vm_area_struct *new_vma)
> +{
> +	current->mm->context.sigpage = new_vma->vm_start;
> +	return 0;
> +}
> +
>   static const struct vm_special_mapping sigpage_mapping = {
>   	.name = "[sigpage]",
>   	.pages = &signal_page,
> +	.mremap = sigpage_mremap,
>   };
>   
>   int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
> diff --git a/arch/arm/kernel/vdso.c b/arch/arm/kernel/vdso.c
> index 53cf86cf2d1a..a4d6dc0f2427 100644
> --- a/arch/arm/kernel/vdso.c
> +++ b/arch/arm/kernel/vdso.c
> @@ -54,8 +54,26 @@ static const struct vm_special_mapping vdso_data_mapping = {
>   	.pages = &vdso_data_page,
>   };
>   
> +static int vdso_mremap(const struct vm_special_mapping *sm,
> +		struct vm_area_struct *new_vma)
> +{
> +	unsigned long new_size = new_vma->vm_end - new_vma->vm_start;
> +	unsigned long vdso_size;
> +
> +	/* without VVAR page */
> +	vdso_size = (vdso_total_pages - 1) << PAGE_SHIFT;
> +
> +	if (vdso_size != new_size)
> +		return -EINVAL;
> +
> +	current->mm->context.vdso = new_vma->vm_start;
> +
> +	return 0;
> +}
> +
>   static struct vm_special_mapping vdso_text_mapping __ro_after_init = {
>   	.name = "[vdso]",
> +	.mremap = vdso_mremap,
>   };
>   
>   struct elfinfo {
> diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
> index 226ca70dc6bd..363730caa60e 100644
> --- a/arch/x86/entry/vdso/vma.c
> +++ b/arch/x86/entry/vdso/vma.c
> @@ -77,9 +77,6 @@ static int vdso_mremap(const struct vm_special_mapping *sm,
>   	if (image->size != new_size)
>   		return -EINVAL;
>   
> -	if (WARN_ON_ONCE(current->mm != new_vma->vm_mm))
> -		return -EFAULT;
> -
>   	vdso_fix_landing(image, new_vma);
>   	current->mm->context.vdso = (void __user *)new_vma->vm_start;
>   
> diff --git a/mm/mmap.c b/mm/mmap.c
> index bfbe8856d134..534aef99cfe9 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -3152,8 +3152,12 @@ 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;
>   }
>   
>
Dmitry Safonov May 18, 2017, 11:13 a.m. UTC | #2
On 04/25/2017 08:18 PM, Dmitry Safonov wrote:
> On 04/14/2017 04:25 PM, Dmitry Safonov wrote:
>> CRIU restores application mappings on the same place where they
>> were before Checkpoint. That means, that we need to move vDSO
>> and sigpage during restore on exactly the same place where
>> they were before C/R.
>>
>> Make mremap() code update mm->context.{sigpage,vdso} pointers
>> during VMA move. Sigpage is used for landing after handling
>> a signal - if the pointer is not updated during moving, the
>> application might crash on any signal after mremap().
>>
>> vDSO pointer on ARM32 is used only for setting auxv at this moment,
>> update it during mremap() in case of future usage.
>>
>> Without those updates, current work of CRIU on ARM32 is not reliable.
>> Historically, we error Checkpointing if we find vDSO page on ARM32
>> and suggest user to disable CONFIG_VDSO.
>> But that's not correct - it goes from x86 where signal processing
>> is ended in vDSO blob. For arm32 it's sigpage, which is not disabled
>> with `CONFIG_VDSO=n'.
>>
>> Looks like C/R was working by luck - because userspace on ARM32 at
>> this moment always sets SA_RESTORER.
>>
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: Russell King <linux@armlinux.org.uk>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: Andy Lutomirski <luto@amacapital.net>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Cyrill Gorcunov <gorcunov@openvz.org>
>> Cc: Pavel Emelyanov <xemul@virtuozzo.com>
>> Cc: Christopher Covington <cov@codeaurora.org>
>> Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
>> ---
>> v2: (buildbot) Fix (unsinged long) to (void*) cast warning.
>>
>>   arch/arm/kernel/process.c |  8 ++++++++
>>   arch/arm/kernel/vdso.c    | 18 ++++++++++++++++++
>>   arch/x86/entry/vdso/vma.c |  3 ---
>>   mm/mmap.c                 |  4 ++++
>>   4 files changed, 30 insertions(+), 3 deletions(-)
> 
> Ping?

Ping?

> 
>>
>> diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
>> index 939e8b58c59d..1e6039cac68d 100644
>> --- a/arch/arm/kernel/process.c
>> +++ b/arch/arm/kernel/process.c
>> @@ -404,9 +404,17 @@ static unsigned long sigpage_addr(const struct 
>> mm_struct *mm,
>>   static struct page *signal_page;
>>   extern struct page *get_signal_page(void);
>> +static int sigpage_mremap(const struct vm_special_mapping *sm,
>> +        struct vm_area_struct *new_vma)
>> +{
>> +    current->mm->context.sigpage = new_vma->vm_start;
>> +    return 0;
>> +}
>> +
>>   static const struct vm_special_mapping sigpage_mapping = {
>>       .name = "[sigpage]",
>>       .pages = &signal_page,
>> +    .mremap = sigpage_mremap,
>>   };
>>   int arch_setup_additional_pages(struct linux_binprm *bprm, int 
>> uses_interp)
>> diff --git a/arch/arm/kernel/vdso.c b/arch/arm/kernel/vdso.c
>> index 53cf86cf2d1a..a4d6dc0f2427 100644
>> --- a/arch/arm/kernel/vdso.c
>> +++ b/arch/arm/kernel/vdso.c
>> @@ -54,8 +54,26 @@ static const struct vm_special_mapping 
>> vdso_data_mapping = {
>>       .pages = &vdso_data_page,
>>   };
>> +static int vdso_mremap(const struct vm_special_mapping *sm,
>> +        struct vm_area_struct *new_vma)
>> +{
>> +    unsigned long new_size = new_vma->vm_end - new_vma->vm_start;
>> +    unsigned long vdso_size;
>> +
>> +    /* without VVAR page */
>> +    vdso_size = (vdso_total_pages - 1) << PAGE_SHIFT;
>> +
>> +    if (vdso_size != new_size)
>> +        return -EINVAL;
>> +
>> +    current->mm->context.vdso = new_vma->vm_start;
>> +
>> +    return 0;
>> +}
>> +
>>   static struct vm_special_mapping vdso_text_mapping __ro_after_init = {
>>       .name = "[vdso]",
>> +    .mremap = vdso_mremap,
>>   };
>>   struct elfinfo {
>> diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
>> index 226ca70dc6bd..363730caa60e 100644
>> --- a/arch/x86/entry/vdso/vma.c
>> +++ b/arch/x86/entry/vdso/vma.c
>> @@ -77,9 +77,6 @@ static int vdso_mremap(const struct 
>> vm_special_mapping *sm,
>>       if (image->size != new_size)
>>           return -EINVAL;
>> -    if (WARN_ON_ONCE(current->mm != new_vma->vm_mm))
>> -        return -EFAULT;
>> -
>>       vdso_fix_landing(image, new_vma);
>>       current->mm->context.vdso = (void __user *)new_vma->vm_start;
>> diff --git a/mm/mmap.c b/mm/mmap.c
>> index bfbe8856d134..534aef99cfe9 100644
>> --- a/mm/mmap.c
>> +++ b/mm/mmap.c
>> @@ -3152,8 +3152,12 @@ 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;
>>   }
>>
> 
>
Russell King (Oracle) May 23, 2017, 8:09 p.m. UTC | #3
On Thu, May 18, 2017 at 02:13:29PM +0300, Dmitry Safonov wrote:
> On 04/25/2017 08:18 PM, Dmitry Safonov wrote:
> >On 04/14/2017 04:25 PM, Dmitry Safonov wrote:
> >>CRIU restores application mappings on the same place where they
> >>were before Checkpoint. That means, that we need to move vDSO
> >>and sigpage during restore on exactly the same place where
> >>they were before C/R.
> >>
> >>Make mremap() code update mm->context.{sigpage,vdso} pointers
> >>during VMA move. Sigpage is used for landing after handling
> >>a signal - if the pointer is not updated during moving, the
> >>application might crash on any signal after mremap().
> >>
> >>vDSO pointer on ARM32 is used only for setting auxv at this moment,
> >>update it during mremap() in case of future usage.
> >>
> >>Without those updates, current work of CRIU on ARM32 is not reliable.
> >>Historically, we error Checkpointing if we find vDSO page on ARM32
> >>and suggest user to disable CONFIG_VDSO.
> >>But that's not correct - it goes from x86 where signal processing
> >>is ended in vDSO blob. For arm32 it's sigpage, which is not disabled
> >>with `CONFIG_VDSO=n'.
> >>
> >>Looks like C/R was working by luck - because userspace on ARM32 at
> >>this moment always sets SA_RESTORER.
> >>
> >>Cc: linux-arm-kernel@lists.infradead.org
> >>Cc: Russell King <linux@armlinux.org.uk>
> >>Cc: Will Deacon <will.deacon@arm.com>
> >>Cc: Andy Lutomirski <luto@amacapital.net>
> >>Cc: Thomas Gleixner <tglx@linutronix.de>
> >>Cc: Cyrill Gorcunov <gorcunov@openvz.org>
> >>Cc: Pavel Emelyanov <xemul@virtuozzo.com>
> >>Cc: Christopher Covington <cov@codeaurora.org>
> >>Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
> >>---
> >>v2: (buildbot) Fix (unsinged long) to (void*) cast warning.
> >>
> >>  arch/arm/kernel/process.c |  8 ++++++++
> >>  arch/arm/kernel/vdso.c    | 18 ++++++++++++++++++
> >>  arch/x86/entry/vdso/vma.c |  3 ---
> >>  mm/mmap.c                 |  4 ++++
> >>  4 files changed, 30 insertions(+), 3 deletions(-)
> >
> >Ping?
> 
> Ping?

I'm mostly happy with the ARM bits, but I can't take the patch without
acks from others because it touches other architectures/generic code.
Dmitry Safonov May 24, 2017, 10:09 a.m. UTC | #4
+ Adding back to CC x86 guys - as I've removed in ping messages.

On 05/23/2017 11:09 PM, Russell King - ARM Linux wrote:
> On Thu, May 18, 2017 at 02:13:29PM +0300, Dmitry Safonov wrote:
>> On 04/25/2017 08:18 PM, Dmitry Safonov wrote:
>>> On 04/14/2017 04:25 PM, Dmitry Safonov wrote:
>>>> CRIU restores application mappings on the same place where they
>>>> were before Checkpoint. That means, that we need to move vDSO
>>>> and sigpage during restore on exactly the same place where
>>>> they were before C/R.
>>>>
>>>> Make mremap() code update mm->context.{sigpage,vdso} pointers
>>>> during VMA move. Sigpage is used for landing after handling
>>>> a signal - if the pointer is not updated during moving, the
>>>> application might crash on any signal after mremap().
>>>>
>>>> vDSO pointer on ARM32 is used only for setting auxv at this moment,
>>>> update it during mremap() in case of future usage.
>>>>
>>>> Without those updates, current work of CRIU on ARM32 is not reliable.
>>>> Historically, we error Checkpointing if we find vDSO page on ARM32
>>>> and suggest user to disable CONFIG_VDSO.
>>>> But that's not correct - it goes from x86 where signal processing
>>>> is ended in vDSO blob. For arm32 it's sigpage, which is not disabled
>>>> with `CONFIG_VDSO=n'.
>>>>
>>>> Looks like C/R was working by luck - because userspace on ARM32 at
>>>> this moment always sets SA_RESTORER.
>>>>
>>>> Cc: linux-arm-kernel@lists.infradead.org
>>>> Cc: Russell King <linux@armlinux.org.uk>
>>>> Cc: Will Deacon <will.deacon@arm.com>
>>>> Cc: Andy Lutomirski <luto@amacapital.net>
>>>> Cc: Thomas Gleixner <tglx@linutronix.de>
>>>> Cc: Cyrill Gorcunov <gorcunov@openvz.org>
>>>> Cc: Pavel Emelyanov <xemul@virtuozzo.com>
>>>> Cc: Christopher Covington <cov@codeaurora.org>
>>>> Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
>>>> ---
>>>> v2: (buildbot) Fix (unsinged long) to (void*) cast warning.
>>>>
>>>>   arch/arm/kernel/process.c |  8 ++++++++
>>>>   arch/arm/kernel/vdso.c    | 18 ++++++++++++++++++
>>>>   arch/x86/entry/vdso/vma.c |  3 ---
>>>>   mm/mmap.c                 |  4 ++++
>>>>   4 files changed, 30 insertions(+), 3 deletions(-)
>>>
>>> Ping?
>>
>> Ping?
> 
> I'm mostly happy with the ARM bits, but I can't take the patch without
> acks from others because it touches other architectures/generic code.
> 

Fair enough, thanks.

Andy, does moving of this WARN_ON() looks good to you?
I've done it to reuse it over arches and between vdso/sigpage mappings,
reducing code duplication.

Here is the patch, so you don't need to search it in the mailbox:
https://patchwork.kernel.org/patch/9681273/
Andy Lutomirski May 24, 2017, 4:44 p.m. UTC | #5
On Wed, May 24, 2017 at 3:09 AM, Dmitry Safonov <dsafonov@virtuozzo.com> wrote:
> + Adding back to CC x86 guys - as I've removed in ping messages.
>
> On 05/23/2017 11:09 PM, Russell King - ARM Linux wrote:
>>
>> On Thu, May 18, 2017 at 02:13:29PM +0300, Dmitry Safonov wrote:
>>>
>>> On 04/25/2017 08:18 PM, Dmitry Safonov wrote:
>>>>
>>>> On 04/14/2017 04:25 PM, Dmitry Safonov wrote:
>>>>>
>>>>> CRIU restores application mappings on the same place where they
>>>>> were before Checkpoint. That means, that we need to move vDSO
>>>>> and sigpage during restore on exactly the same place where
>>>>> they were before C/R.
>>>>>
>>>>> Make mremap() code update mm->context.{sigpage,vdso} pointers
>>>>> during VMA move. Sigpage is used for landing after handling
>>>>> a signal - if the pointer is not updated during moving, the
>>>>> application might crash on any signal after mremap().
>>>>>
>>>>> vDSO pointer on ARM32 is used only for setting auxv at this moment,
>>>>> update it during mremap() in case of future usage.
>>>>>
>>>>> Without those updates, current work of CRIU on ARM32 is not reliable.
>>>>> Historically, we error Checkpointing if we find vDSO page on ARM32
>>>>> and suggest user to disable CONFIG_VDSO.
>>>>> But that's not correct - it goes from x86 where signal processing
>>>>> is ended in vDSO blob. For arm32 it's sigpage, which is not disabled
>>>>> with `CONFIG_VDSO=n'.
>>>>>
>>>>> Looks like C/R was working by luck - because userspace on ARM32 at
>>>>> this moment always sets SA_RESTORER.
>>>>>
>>>>> Cc: linux-arm-kernel@lists.infradead.org
>>>>> Cc: Russell King <linux@armlinux.org.uk>
>>>>> Cc: Will Deacon <will.deacon@arm.com>
>>>>> Cc: Andy Lutomirski <luto@amacapital.net>
>>>>> Cc: Thomas Gleixner <tglx@linutronix.de>
>>>>> Cc: Cyrill Gorcunov <gorcunov@openvz.org>
>>>>> Cc: Pavel Emelyanov <xemul@virtuozzo.com>
>>>>> Cc: Christopher Covington <cov@codeaurora.org>
>>>>> Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
>>>>> ---
>>>>> v2: (buildbot) Fix (unsinged long) to (void*) cast warning.
>>>>>
>>>>>   arch/arm/kernel/process.c |  8 ++++++++
>>>>>   arch/arm/kernel/vdso.c    | 18 ++++++++++++++++++
>>>>>   arch/x86/entry/vdso/vma.c |  3 ---
>>>>>   mm/mmap.c                 |  4 ++++
>>>>>   4 files changed, 30 insertions(+), 3 deletions(-)
>>>>
>>>>
>>>> Ping?
>>>
>>>
>>> Ping?
>>
>>
>> I'm mostly happy with the ARM bits, but I can't take the patch without
>> acks from others because it touches other architectures/generic code.
>>
>
> Fair enough, thanks.
>
> Andy, does moving of this WARN_ON() looks good to you?
> I've done it to reuse it over arches and between vdso/sigpage mappings,
> reducing code duplication.

Acked-by: Andy Lutomirski <luto@kernel.org> # For the x86 bit

>
> Here is the patch, so you don't need to search it in the mailbox:
> https://patchwork.kernel.org/patch/9681273/
>
> --
>              Dmitry
Dmitry Safonov June 19, 2017, 2:50 p.m. UTC | #6
On 05/24/2017 07:44 PM, Andy Lutomirski wrote:
> On Wed, May 24, 2017 at 3:09 AM, Dmitry Safonov <dsafonov@virtuozzo.com> wrote:
>> + Adding back to CC x86 guys - as I've removed in ping messages.
>>
>> On 05/23/2017 11:09 PM, Russell King - ARM Linux wrote:
>>>
>>> On Thu, May 18, 2017 at 02:13:29PM +0300, Dmitry Safonov wrote:
>>>>
>>>> On 04/25/2017 08:18 PM, Dmitry Safonov wrote:
>>>>>
>>>>> On 04/14/2017 04:25 PM, Dmitry Safonov wrote:
>>>>>>
>>>>>> CRIU restores application mappings on the same place where they
>>>>>> were before Checkpoint. That means, that we need to move vDSO
>>>>>> and sigpage during restore on exactly the same place where
>>>>>> they were before C/R.
>>>>>>
>>>>>> Make mremap() code update mm->context.{sigpage,vdso} pointers
>>>>>> during VMA move. Sigpage is used for landing after handling
>>>>>> a signal - if the pointer is not updated during moving, the
>>>>>> application might crash on any signal after mremap().
>>>>>>
>>>>>> vDSO pointer on ARM32 is used only for setting auxv at this moment,
>>>>>> update it during mremap() in case of future usage.
>>>>>>
>>>>>> Without those updates, current work of CRIU on ARM32 is not reliable.
>>>>>> Historically, we error Checkpointing if we find vDSO page on ARM32
>>>>>> and suggest user to disable CONFIG_VDSO.
>>>>>> But that's not correct - it goes from x86 where signal processing
>>>>>> is ended in vDSO blob. For arm32 it's sigpage, which is not disabled
>>>>>> with `CONFIG_VDSO=n'.
>>>>>>
>>>>>> Looks like C/R was working by luck - because userspace on ARM32 at
>>>>>> this moment always sets SA_RESTORER.
>>>>>>
>>>>>> Cc: linux-arm-kernel@lists.infradead.org
>>>>>> Cc: Russell King <linux@armlinux.org.uk>
>>>>>> Cc: Will Deacon <will.deacon@arm.com>
>>>>>> Cc: Andy Lutomirski <luto@amacapital.net>
>>>>>> Cc: Thomas Gleixner <tglx@linutronix.de>
>>>>>> Cc: Cyrill Gorcunov <gorcunov@openvz.org>
>>>>>> Cc: Pavel Emelyanov <xemul@virtuozzo.com>
>>>>>> Cc: Christopher Covington <cov@codeaurora.org>
>>>>>> Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
>>>>>> ---
>>>>>> v2: (buildbot) Fix (unsinged long) to (void*) cast warning.
>>>>>>
>>>>>>    arch/arm/kernel/process.c |  8 ++++++++
>>>>>>    arch/arm/kernel/vdso.c    | 18 ++++++++++++++++++
>>>>>>    arch/x86/entry/vdso/vma.c |  3 ---
>>>>>>    mm/mmap.c                 |  4 ++++
>>>>>>    4 files changed, 30 insertions(+), 3 deletions(-)
>>>>>
>>>>>
>>>>> Ping?
>>>>
>>>>
>>>> Ping?
>>>
>>>
>>> I'm mostly happy with the ARM bits, but I can't take the patch without
>>> acks from others because it touches other architectures/generic code.
>>>
>>
>> Fair enough, thanks.
>>
>> Andy, does moving of this WARN_ON() looks good to you?
>> I've done it to reuse it over arches and between vdso/sigpage mappings,
>> reducing code duplication.
> 
> Acked-by: Andy Lutomirski <luto@kernel.org> # For the x86 bit

Hi Russell,

Should I resend this with ack, or send it to your patch system,
or you'll take it from mail?

Thanks,
              Dmitry
Russell King (Oracle) June 19, 2017, 4:10 p.m. UTC | #7
On Mon, Jun 19, 2017 at 05:50:23PM +0300, Dmitry Safonov wrote:
> Should I resend this with ack, or send it to your patch system,
> or you'll take it from mail?

As most of it is ARM stuff, I suppose it should go via the ARM tree
unless anyone has objections.  Please put it in the patch system as
I won't get to it until towards the end of this week (I'm remotely
attending a conference.)  Thanks.
diff mbox

Patch

diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index 939e8b58c59d..1e6039cac68d 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -404,9 +404,17 @@  static unsigned long sigpage_addr(const struct mm_struct *mm,
 static struct page *signal_page;
 extern struct page *get_signal_page(void);
 
+static int sigpage_mremap(const struct vm_special_mapping *sm,
+		struct vm_area_struct *new_vma)
+{
+	current->mm->context.sigpage = new_vma->vm_start;
+	return 0;
+}
+
 static const struct vm_special_mapping sigpage_mapping = {
 	.name = "[sigpage]",
 	.pages = &signal_page,
+	.mremap = sigpage_mremap,
 };
 
 int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
diff --git a/arch/arm/kernel/vdso.c b/arch/arm/kernel/vdso.c
index 53cf86cf2d1a..a4d6dc0f2427 100644
--- a/arch/arm/kernel/vdso.c
+++ b/arch/arm/kernel/vdso.c
@@ -54,8 +54,26 @@  static const struct vm_special_mapping vdso_data_mapping = {
 	.pages = &vdso_data_page,
 };
 
+static int vdso_mremap(const struct vm_special_mapping *sm,
+		struct vm_area_struct *new_vma)
+{
+	unsigned long new_size = new_vma->vm_end - new_vma->vm_start;
+	unsigned long vdso_size;
+
+	/* without VVAR page */
+	vdso_size = (vdso_total_pages - 1) << PAGE_SHIFT;
+
+	if (vdso_size != new_size)
+		return -EINVAL;
+
+	current->mm->context.vdso = new_vma->vm_start;
+
+	return 0;
+}
+
 static struct vm_special_mapping vdso_text_mapping __ro_after_init = {
 	.name = "[vdso]",
+	.mremap = vdso_mremap,
 };
 
 struct elfinfo {
diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
index 226ca70dc6bd..363730caa60e 100644
--- a/arch/x86/entry/vdso/vma.c
+++ b/arch/x86/entry/vdso/vma.c
@@ -77,9 +77,6 @@  static int vdso_mremap(const struct vm_special_mapping *sm,
 	if (image->size != new_size)
 		return -EINVAL;
 
-	if (WARN_ON_ONCE(current->mm != new_vma->vm_mm))
-		return -EFAULT;
-
 	vdso_fix_landing(image, new_vma);
 	current->mm->context.vdso = (void __user *)new_vma->vm_start;
 
diff --git a/mm/mmap.c b/mm/mmap.c
index bfbe8856d134..534aef99cfe9 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -3152,8 +3152,12 @@  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;
 }