All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Safonov <0x7f454c46@gmail.com>
To: Andy Lutomirski <luto@kernel.org>, Dmitry Safonov <dima@arista.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Andrew Morton <akpm@linux-foundation.org>,
	Arnd Bergmann <arnd@arndb.de>, Borislav Petkov <bp@alien8.de>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Christophe Leroy <christophe.leroy@csgroup.eu>,
	Guo Ren <guoren@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
	Ingo Molnar <mingo@redhat.com>, Oleg Nesterov <oleg@redhat.com>,
	Russell King <linux@armlinux.org.uk>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	Will Deacon <will@kernel.org>, X86 ML <x86@kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Albert Ou <aou@eecs.berkeley.edu>,
	"David S. Miller" <davem@davemloft.net>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Linux FS Devel <linux-fsdevel@vger.kernel.org>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Heiko Carstens <hca@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	linux-s390 <linux-s390@vger.kernel.org>,
	sparclinux <sparclinux@vger.kernel.org>,
	"open list:MIPS" <linux-mips@vger.kernel.org>
Subject: Re: [PATCH 00/19] Add generic user_landing tracking
Date: Mon, 9 Nov 2020 01:27:27 +0000	[thread overview]
Message-ID: <9f416ebd-2535-1b57-7033-e1755e906743@gmail.com> (raw)
In-Reply-To: <CALCETrW-hHyh3nF3ATmy61PCy1iFqVhVYX+-ptBCMP5Bf7aJ0w@mail.gmail.com>

On 11/8/20 7:07 PM, Andy Lutomirski wrote:
> On Sat, Nov 7, 2020 at 9:17 PM Dmitry Safonov <dima@arista.com> wrote:
>>
>> Started from discussion [1], where was noted that currently a couple of
>> architectures support mremap() for vdso/sigpage, but not munmap().
>> If an application maps something on the ex-place of vdso/sigpage,
>> later after processing signal it will land there (good luck!)
>>
>> Patches set is based on linux-next (next-20201106) and it depends on
>> changes in x86/cleanups (those reclaim TIF_IA32/TIF_X32) and also
>> on my changes in akpm (fixing several mremap() issues).
>>
>> Logically, the patches set divides on:
>> - patch       1: cleanup for patches in x86/cleanups
>> - patches  2-11: cleanups for arch_setup_additional_pages()
> 
> I like these cleanups, although I think you should stop using terms
> like "new-born".  A task being exec'd is not newborn at all -- it's in
> the middle of a transformation.

Thank you for looking at them, Andy :-)

Yeah, somehow I thought about new-execed process as a new-born binary.
I'll try to improve changelogs in v2.

Thanks,
         Dmitry

WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Safonov <0x7f454c46@gmail.com>
To: Andy Lutomirski <luto@kernel.org>, Dmitry Safonov <dima@arista.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Oleg Nesterov <oleg@redhat.com>, Guo Ren <guoren@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	sparclinux <sparclinux@vger.kernel.org>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	Will Deacon <will@kernel.org>,
	linux-s390 <linux-s390@vger.kernel.org>,
	Vasily Gorbik <gor@linux.ibm.com>, X86 ML <x86@kernel.org>,
	Russell King <linux@armlinux.org.uk>,
	Christophe Leroy <christophe.leroy@csgroup.eu>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Ingo Molnar <mingo@redhat.com>,
	"open list:MIPS" <linux-mips@vger.kernel.org>,
	Albert Ou <aou@eecs.berkeley.edu>, Arnd Bergmann <arnd@arndb.de>,
	Heiko Carstens <hca@linux.ibm.com>,
	Borislav Petkov <bp@alien8.de>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	LKML <linux-kernel@vger.kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Linux FS Devel <linux-fsdevel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH 00/19] Add generic user_landing tracking
Date: Mon, 09 Nov 2020 01:27:27 +0000	[thread overview]
Message-ID: <9f416ebd-2535-1b57-7033-e1755e906743@gmail.com> (raw)
In-Reply-To: <CALCETrW-hHyh3nF3ATmy61PCy1iFqVhVYX+-ptBCMP5Bf7aJ0w@mail.gmail.com>

On 11/8/20 7:07 PM, Andy Lutomirski wrote:
> On Sat, Nov 7, 2020 at 9:17 PM Dmitry Safonov <dima@arista.com> wrote:
>>
>> Started from discussion [1], where was noted that currently a couple of
>> architectures support mremap() for vdso/sigpage, but not munmap().
>> If an application maps something on the ex-place of vdso/sigpage,
>> later after processing signal it will land there (good luck!)
>>
>> Patches set is based on linux-next (next-20201106) and it depends on
>> changes in x86/cleanups (those reclaim TIF_IA32/TIF_X32) and also
>> on my changes in akpm (fixing several mremap() issues).
>>
>> Logically, the patches set divides on:
>> - patch       1: cleanup for patches in x86/cleanups
>> - patches  2-11: cleanups for arch_setup_additional_pages()
> 
> I like these cleanups, although I think you should stop using terms
> like "new-born".  A task being exec'd is not newborn at all -- it's in
> the middle of a transformation.

Thank you for looking at them, Andy :-)

Yeah, somehow I thought about new-execed process as a new-born binary.
I'll try to improve changelogs in v2.

Thanks,
         Dmitry

WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Safonov <0x7f454c46@gmail.com>
To: Andy Lutomirski <luto@kernel.org>, Dmitry Safonov <dima@arista.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Oleg Nesterov <oleg@redhat.com>, Guo Ren <guoren@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	sparclinux <sparclinux@vger.kernel.org>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	Will Deacon <will@kernel.org>,
	linux-s390 <linux-s390@vger.kernel.org>,
	Vasily Gorbik <gor@linux.ibm.com>, X86 ML <x86@kernel.org>,
	Russell King <linux@armlinux.org.uk>,
	Christophe Leroy <christophe.leroy@csgroup.eu>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Ingo Molnar <mingo@redhat.com>,
	"open list:MIPS" <linux-mips@vger.kernel.org>,
	Albert Ou <aou@eecs.berkeley.edu>, Arnd Bergmann <arnd@arndb.de>,
	Heiko Carstens <hca@linux.ibm.com>,
	Borislav Petkov <bp@alien8.de>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	LKML <linux-kernel@vger.kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Linux FS Devel <linux-fsdevel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH 00/19] Add generic user_landing tracking
Date: Mon, 9 Nov 2020 01:27:27 +0000	[thread overview]
Message-ID: <9f416ebd-2535-1b57-7033-e1755e906743@gmail.com> (raw)
In-Reply-To: <CALCETrW-hHyh3nF3ATmy61PCy1iFqVhVYX+-ptBCMP5Bf7aJ0w@mail.gmail.com>

On 11/8/20 7:07 PM, Andy Lutomirski wrote:
> On Sat, Nov 7, 2020 at 9:17 PM Dmitry Safonov <dima@arista.com> wrote:
>>
>> Started from discussion [1], where was noted that currently a couple of
>> architectures support mremap() for vdso/sigpage, but not munmap().
>> If an application maps something on the ex-place of vdso/sigpage,
>> later after processing signal it will land there (good luck!)
>>
>> Patches set is based on linux-next (next-20201106) and it depends on
>> changes in x86/cleanups (those reclaim TIF_IA32/TIF_X32) and also
>> on my changes in akpm (fixing several mremap() issues).
>>
>> Logically, the patches set divides on:
>> - patch       1: cleanup for patches in x86/cleanups
>> - patches  2-11: cleanups for arch_setup_additional_pages()
> 
> I like these cleanups, although I think you should stop using terms
> like "new-born".  A task being exec'd is not newborn at all -- it's in
> the middle of a transformation.

Thank you for looking at them, Andy :-)

Yeah, somehow I thought about new-execed process as a new-born binary.
I'll try to improve changelogs in v2.

Thanks,
         Dmitry

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

  reply	other threads:[~2020-11-09  1:27 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-08  5:17 [PATCH 00/19] Add generic user_landing tracking Dmitry Safonov
2020-11-08  5:17 ` Dmitry Safonov
2020-11-08  5:17 ` Dmitry Safonov
2020-11-08  5:17 ` [PATCH 01/19] x86/elf: Check in_x32_syscall() in compat_arch_setup_additional_pages() Dmitry Safonov
2020-11-08  5:17 ` [PATCH 02/19] elf: Move arch_setup_additional_pages() to generic elf.h Dmitry Safonov
2020-11-13  6:58   ` kernel test robot
2020-11-13  6:58     ` kernel test robot
2020-11-13  7:01   ` kernel test robot
2020-11-13  7:01     ` kernel test robot
2020-11-08  5:17 ` [PATCH 03/19] arm64: Use in_compat_task() in arch_setup_additional_pages() Dmitry Safonov
2020-11-08  5:17   ` Dmitry Safonov
2020-11-08  5:17 ` [PATCH 04/19] x86: Remove compat_arch_setup_additional_pages() Dmitry Safonov
2020-11-08  5:17 ` [PATCH 05/19] elf: " Dmitry Safonov
2020-11-08  5:17 ` [PATCH 06/19] elf/vdso: Reuse arch_setup_additional_pages() parameters Dmitry Safonov
2020-11-13  6:57   ` kernel test robot
2020-11-13  6:57     ` kernel test robot
2020-11-13  8:04   ` kernel test robot
2020-11-13  8:04     ` kernel test robot
2020-11-08  5:17 ` [PATCH 07/19] elf: Use sysinfo_ehdr in ARCH_DLINFO() Dmitry Safonov
2020-11-08  5:17   ` Dmitry Safonov
2020-11-08  5:17 ` [PATCH 08/19] arm/vdso: Remove vdso pointer from mm->context Dmitry Safonov
2020-11-08  5:17 ` [PATCH 09/19] s390/vdso: Remove vdso_base " Dmitry Safonov
2020-11-08  5:17 ` [PATCH 10/19] sparc/vdso: Remove vdso " Dmitry Safonov
2020-11-08  5:17   ` Dmitry Safonov
2020-11-08  5:17 ` [PATCH 11/19] mm/mmap: Make vm_special_mapping::mremap return void Dmitry Safonov
2020-11-08  5:17 ` [PATCH 12/19] x86/signal: Land on &frame->retcode when vdso isn't mapped Dmitry Safonov
2020-11-08 19:06   ` Andy Lutomirski
2020-11-09  1:22     ` Dmitry Safonov
2020-11-08  5:17 ` [PATCH 13/19] x86/signal: Check if vdso_image_32 is mapped before trying to land on it Dmitry Safonov
2020-11-08  5:17 ` [PATCH 14/19] mm: Add user_landing in mm_struct Dmitry Safonov
2020-11-08 19:04   ` Andy Lutomirski
2020-11-09  1:25     ` Dmitry Safonov
2020-11-08  5:17 ` [PATCH 15/19] x86/vdso: Migrate to user_landing Dmitry Safonov
2020-11-08  5:17 ` [PATCH 16/19] arm/vdso: " Dmitry Safonov
2020-11-08  5:17 ` [PATCH 17/19] arm64/vdso: Migrate compat signals " Dmitry Safonov
2020-11-08  5:17 ` [PATCH 18/19] arm64/vdso: Migrate native " Dmitry Safonov
2020-11-08  5:17 ` [PATCH 19/19] mips/vdso: Migrate " Dmitry Safonov
2020-11-13  9:58   ` kernel test robot
2020-11-13  9:58     ` kernel test robot
2020-11-08 19:07 ` [PATCH 00/19] Add generic user_landing tracking Andy Lutomirski
2020-11-08 19:07   ` Andy Lutomirski
2020-11-08 19:07   ` Andy Lutomirski
2020-11-09  1:27   ` Dmitry Safonov [this message]
2020-11-09  1:27     ` Dmitry Safonov
2020-11-09  1:27     ` Dmitry Safonov

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=9f416ebd-2535-1b57-7033-e1755e906743@gmail.com \
    --to=0x7f454c46@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=aou@eecs.berkeley.edu \
    --cc=arnd@arndb.de \
    --cc=borntraeger@de.ibm.com \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=christophe.leroy@csgroup.eu \
    --cc=davem@davemloft.net \
    --cc=dima@arista.com \
    --cc=gor@linux.ibm.com \
    --cc=guoren@kernel.org \
    --cc=hca@linux.ibm.com \
    --cc=hpa@zytor.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=oleg@redhat.com \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=sparclinux@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tsbogend@alpha.franken.de \
    --cc=vincenzo.frascino@arm.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=will@kernel.org \
    --cc=x86@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 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.