All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Bogendoerfer <tsbogend-I1c7kopa9pxLokYuJOExCg@public.gmane.org>
To: Arnd Bergmann <arnd-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Linus Torvalds
	<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
	Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>,
	linux-arch <linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Linux-MM <linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org>,
	Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
	Linux Kernel Mailing List
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
	Russell King - ARM Linux
	<linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>,
	Will Deacon <will-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Guo Ren <guoren-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Brian Cain <bcain-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	Geert Uytterhoeven
	<geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>,
	Michal Simek <monstr-pSz03upnqPeHXe+LvDLADg@public.gmane.org>,
	Nick Hu <nickhu-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>,
	Greentime Hu <green.hu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Dinh Nguyen <dinguyen-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Stafford Horne <shorne-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Helge Deller <deller-Mmb7MZpHnFY@public.gmane.org>,
	Michael Ellerman <mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org>,
	Pe
Subject: Re: [PATCH v2 09/18] mips: use simpler access_ok()
Date: Mon, 21 Feb 2022 16:21:30 +0100	[thread overview]
Message-ID: <20220221152130.GA17373@alpha.franken.de> (raw)
In-Reply-To: <CAK8P3a2usZWPDDDUcscwS0aVKsY6aLXFGFPqYNkm4hcDERim9w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Mon, Feb 21, 2022 at 03:31:23PM +0100, Arnd Bergmann wrote:
> On Mon, Feb 21, 2022 at 2:24 PM Thomas Bogendoerfer
> <tsbogend-I1c7kopa9pxLokYuJOExCg@public.gmane.org> wrote:
> > On Wed, Feb 16, 2022 at 02:13:23PM +0100, Arnd Bergmann wrote:
> > >
> > > diff --git a/arch/mips/include/asm/uaccess.h b/arch/mips/include/asm/uaccess.h
> > > index db9a8e002b62..d7c89dc3426c 100644
> >
> > this doesn't work. For every access above maximum implemented virtual address
> > space of the CPU an address error will be issued, but not a TLB miss.
> > And address error isn't able to handle this situation.
> 
> Ah, so the __ex_table entry only catches TLB misses?

no, but there is no __ex_table handling in address error hanlder (yet).

> Does this mean it also traps for kernel memory accesses, or do those
> work again?

it will trap for every access.


> If the addresses on mips64 are separate like on
> sparc64 or s390, the entire access_ok() step could be replaced
> by a fixup code in the exception handler. I suppose this depends on
> CONFIG_EVA and you still need a limit check at least when EVA is
> disabled.

only EVA has seperate address spaces for kernel/user.

> > Is there a reason to not also #define TASK_SIZE_MAX   __UA_LIMIT like
> > for the 32bit case ?
> >
> 
> For 32-bit, the __UA_LIMIT is a compile-time constant, so the check
> ends up being trivial. On all other architectures, the same thing can
> be done after the set_fs removal, so I was hoping it would work here
> as well.

ic

> I suspect doing the generic (size <= limit) && (addr <= (limit - size))
> check on mips64 with the runtime limit ends up slightly slower
> than the current code that checks a bit mask instead. If you like,
> I'll update it this way, otherwise I'd need help in form of a patch
> that changes the exception handling so __get_user/__put_user
> also return -EFAULT for an address error.

that's what the patch does. For aligned accesses the patch should
do the right thing, but it breaks unaligned get_user/put_user.
Checking if the trapping vaddr is between end of CPU VM space and
TASK_MAX_SIZE before exception handling should do the trick. I'll
send a patch, if this works.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

WARNING: multiple messages have this Message-ID (diff)
From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Christoph Hellwig <hch@lst.de>,
	linux-arch <linux-arch@vger.kernel.org>,
	Linux-MM <linux-mm@kvack.org>,
	Linux API <linux-api@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Russell King - ARM Linux <linux@armlinux.org.uk>,
	Will Deacon <will@kernel.org>, Guo Ren <guoren@kernel.org>,
	Brian Cain <bcain@codeaurora.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Michal Simek <monstr@monstr.eu>, Nick Hu <nickhu@andestech.com>,
	Greentime Hu <green.hu@gmail.com>,
	Dinh Nguyen <dinguyen@kernel.org>,
	Stafford Horne <shorne@gmail.com>, Helge Deller <deller@gmx.de>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Heiko Carstens <hca@linux.ibm.com>, Rich Felker <dalias@libc.org>,
	David Miller <davem@davemloft.net>,
	Richard Weinberger <richard@nod.at>,
	the arch/x86 maintainers <x86@kernel.org>,
	Max Filippov <jcmvbkbc@gmail.com>,
	"Eric W . Biederman" <ebiederm@xmission.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	alpha <linux-alpha@vger.kernel.org>,
	"open list:SYNOPSYS ARC ARCHITECTURE" 
	<linux-snps-arc@lists.infradead.org>,
	linux-csky@vger.kernel.org,
	"open list:QUALCOMM HEXAGON..." <linux-hexagon@vger.kernel.org>,
	linux-ia64@vger.kernel.org,
	linux-m68k <linux-m68k@lists.linux-m68k.org>,
	"open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>,
	Openrisc <openrisc@lists.librecores.org>,
	Parisc List <linux-parisc@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	linux-s390 <linux-s390@vger.kernel.org>,
	Linux-sh list <linux-sh@vger.kernel.org>,
	sparclinux <sparclinux@vger.kernel.org>,
	linux-um <linux-um@lists.infradead.org>,
	"open list:TENSILICA XTENSA PORT (xtensa)" 
	<linux-xtensa@linux-xtensa.org>
Subject: Re: [PATCH v2 09/18] mips: use simpler access_ok()
Date: Mon, 21 Feb 2022 16:21:30 +0100	[thread overview]
Message-ID: <20220221152130.GA17373@alpha.franken.de> (raw)
In-Reply-To: <CAK8P3a2usZWPDDDUcscwS0aVKsY6aLXFGFPqYNkm4hcDERim9w@mail.gmail.com>

On Mon, Feb 21, 2022 at 03:31:23PM +0100, Arnd Bergmann wrote:
> On Mon, Feb 21, 2022 at 2:24 PM Thomas Bogendoerfer
> <tsbogend@alpha.franken.de> wrote:
> > On Wed, Feb 16, 2022 at 02:13:23PM +0100, Arnd Bergmann wrote:
> > >
> > > diff --git a/arch/mips/include/asm/uaccess.h b/arch/mips/include/asm/uaccess.h
> > > index db9a8e002b62..d7c89dc3426c 100644
> >
> > this doesn't work. For every access above maximum implemented virtual address
> > space of the CPU an address error will be issued, but not a TLB miss.
> > And address error isn't able to handle this situation.
> 
> Ah, so the __ex_table entry only catches TLB misses?

no, but there is no __ex_table handling in address error hanlder (yet).

> Does this mean it also traps for kernel memory accesses, or do those
> work again?

it will trap for every access.


> If the addresses on mips64 are separate like on
> sparc64 or s390, the entire access_ok() step could be replaced
> by a fixup code in the exception handler. I suppose this depends on
> CONFIG_EVA and you still need a limit check at least when EVA is
> disabled.

only EVA has seperate address spaces for kernel/user.

> > Is there a reason to not also #define TASK_SIZE_MAX   __UA_LIMIT like
> > for the 32bit case ?
> >
> 
> For 32-bit, the __UA_LIMIT is a compile-time constant, so the check
> ends up being trivial. On all other architectures, the same thing can
> be done after the set_fs removal, so I was hoping it would work here
> as well.

ic

> I suspect doing the generic (size <= limit) && (addr <= (limit - size))
> check on mips64 with the runtime limit ends up slightly slower
> than the current code that checks a bit mask instead. If you like,
> I'll update it this way, otherwise I'd need help in form of a patch
> that changes the exception handling so __get_user/__put_user
> also return -EFAULT for an address error.

that's what the patch does. For aligned accesses the patch should
do the right thing, but it breaks unaligned get_user/put_user.
Checking if the trapping vaddr is between end of CPU VM space and
TASK_MAX_SIZE before exception handling should do the trick. I'll
send a patch, if this works.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

WARNING: multiple messages have this Message-ID (diff)
From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Christoph Hellwig <hch@lst.de>,
	linux-arch <linux-arch@vger.kernel.org>,
	Linux-MM <linux-mm@kvack.org>,
	Linux API <linux-api@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Russell King - ARM Linux <linux@armlinux.org.uk>,
	Will Deacon <will@kernel.org>, Guo Ren <guoren@kernel.org>,
	Brian Cain <bcain@codeaurora.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Michal Simek <monstr@monstr.eu>, Nick Hu <nickhu@andestech.com>,
	Greentime Hu <green.hu@gmail.com>,
	Dinh Nguyen <dinguyen@kernel.org>,
	Stafford Horne <shorne@gmail.com>, Helge Deller <deller@gmx.de>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Heiko Carstens <hca@linux.ibm.com>, Rich Felker <dalias@libc.org>,
	David Miller <davem@davemloft.net>,
	Richard Weinberger <richard@nod.at>,
	the arch/x86 maintainers <x86@kernel.org>,
	Max Filippov <jcmvbkbc@gmail.com>,
	"Eric W . Biederman" <ebiederm@xmission.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	alpha <linux-alpha@vger.kernel.org>,
	"open list:SYNOPSYS ARC ARCHITECTURE"
	<linux-snps-arc@lists.infradead.org>,
	linux-csky@vger.kernel.org,
	"open list:QUALCOMM HEXAGON..." <linux-hexagon@vger.kernel.org>,
	linux-ia64@vger.kernel.org,
	linux-m68k <linux-m68k@lists.linux-m68k.org>,
	"open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>,
	Openrisc <openrisc@lists.librecores.org>,
	Parisc List <linux-parisc@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	linux-s390 <linux-s390@vger.kernel.org>,
	Linux-sh list <linux-sh@vger.kernel.org>,
	sparclinux <sparclinux@vger.kernel.org>,
	linux-um <linux-um@lists.infradead.org>,
	"open list:TENSILICA XTENSA PORT (xtensa)"
	<linux-xtensa@linux-xtensa.org>
Subject: Re: [PATCH v2 09/18] mips: use simpler access_ok()
Date: Mon, 21 Feb 2022 15:21:30 +0000	[thread overview]
Message-ID: <20220221152130.GA17373@alpha.franken.de> (raw)
In-Reply-To: <CAK8P3a2usZWPDDDUcscwS0aVKsY6aLXFGFPqYNkm4hcDERim9w@mail.gmail.com>

On Mon, Feb 21, 2022 at 03:31:23PM +0100, Arnd Bergmann wrote:
> On Mon, Feb 21, 2022 at 2:24 PM Thomas Bogendoerfer
> <tsbogend@alpha.franken.de> wrote:
> > On Wed, Feb 16, 2022 at 02:13:23PM +0100, Arnd Bergmann wrote:
> > >
> > > diff --git a/arch/mips/include/asm/uaccess.h b/arch/mips/include/asm/uaccess.h
> > > index db9a8e002b62..d7c89dc3426c 100644
> >
> > this doesn't work. For every access above maximum implemented virtual address
> > space of the CPU an address error will be issued, but not a TLB miss.
> > And address error isn't able to handle this situation.
> 
> Ah, so the __ex_table entry only catches TLB misses?

no, but there is no __ex_table handling in address error hanlder (yet).

> Does this mean it also traps for kernel memory accesses, or do those
> work again?

it will trap for every access.


> If the addresses on mips64 are separate like on
> sparc64 or s390, the entire access_ok() step could be replaced
> by a fixup code in the exception handler. I suppose this depends on
> CONFIG_EVA and you still need a limit check at least when EVA is
> disabled.

only EVA has seperate address spaces for kernel/user.

> > Is there a reason to not also #define TASK_SIZE_MAX   __UA_LIMIT like
> > for the 32bit case ?
> >
> 
> For 32-bit, the __UA_LIMIT is a compile-time constant, so the check
> ends up being trivial. On all other architectures, the same thing can
> be done after the set_fs removal, so I was hoping it would work here
> as well.

ic

> I suspect doing the generic (size <= limit) && (addr <= (limit - size))
> check on mips64 with the runtime limit ends up slightly slower
> than the current code that checks a bit mask instead. If you like,
> I'll update it this way, otherwise I'd need help in form of a patch
> that changes the exception handling so __get_user/__put_user
> also return -EFAULT for an address error.

that's what the patch does. For aligned accesses the patch should
do the right thing, but it breaks unaligned get_user/put_user.
Checking if the trapping vaddr is between end of CPU VM space and
TASK_MAX_SIZE before exception handling should do the trick. I'll
send a patch, if this works.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

WARNING: multiple messages have this Message-ID (diff)
From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Christoph Hellwig <hch@lst.de>,
	linux-arch <linux-arch@vger.kernel.org>,
	Linux-MM <linux-mm@kvack.org>,
	Linux API <linux-api@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Russell King - ARM Linux <linux@armlinux.org.uk>,
	Will Deacon <will@kernel.org>, Guo Ren <guoren@kernel.org>,
	Brian Cain <bcain@codeaurora.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Michal Simek <monstr@monstr.eu>, Nick Hu <nickhu@andestech.com>,
	Greentime Hu <green.hu@gmail.com>,
	Dinh Nguyen <dinguyen@kernel.org>,
	Stafford Horne <shorne@gmail.com>, Helge Deller <deller@gmx.de>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Heiko Carstens <hca@linux.ibm.com>, Rich Felker <dalias@libc.org>,
	David Miller <davem@davemloft.net>,
	Richard Weinberger <richard@nod.at>,
	the arch/x86 maintainers <x86@kernel.org>,
	Max Filippov <jcmvbkbc@gmail.com>,
	"Eric W . Biederman" <ebiederm@xmission.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	alpha <linux-alpha@vger.kernel.org>,
	"open list:SYNOPSYS ARC ARCHITECTURE"
	<linux-snps-arc@lists.infradead.org>,
	linux-csky@vger.kernel.org,
	"open list:QUALCOMM HEXAGON..." <linux-hexagon@vger.kernel.org>,
	linux-ia64@vger.kernel.org,
	linux-m68k <linux-m68k@lists.linux-m68k.org>,
	"open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>,
	Openrisc <openrisc@lists.librecores.org>,
	Parisc List <linux-parisc@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	linux-s390 <linux-s390@vger.kernel.org>,
	Linux-sh list <linux-sh@vger.kernel.org>,
	sparclinux <sparclinux@vger.kernel.org>,
	linux-um <linux-um@lists.infradead.org>,
	"open list:TENSILICA XTENSA PORT (xtensa)"
	<linux-xtensa@linux-xtensa.org>
Subject: Re: [PATCH v2 09/18] mips: use simpler access_ok()
Date: Mon, 21 Feb 2022 16:21:30 +0100	[thread overview]
Message-ID: <20220221152130.GA17373@alpha.franken.de> (raw)
In-Reply-To: <CAK8P3a2usZWPDDDUcscwS0aVKsY6aLXFGFPqYNkm4hcDERim9w@mail.gmail.com>

On Mon, Feb 21, 2022 at 03:31:23PM +0100, Arnd Bergmann wrote:
> On Mon, Feb 21, 2022 at 2:24 PM Thomas Bogendoerfer
> <tsbogend@alpha.franken.de> wrote:
> > On Wed, Feb 16, 2022 at 02:13:23PM +0100, Arnd Bergmann wrote:
> > >
> > > diff --git a/arch/mips/include/asm/uaccess.h b/arch/mips/include/asm/uaccess.h
> > > index db9a8e002b62..d7c89dc3426c 100644
> >
> > this doesn't work. For every access above maximum implemented virtual address
> > space of the CPU an address error will be issued, but not a TLB miss.
> > And address error isn't able to handle this situation.
> 
> Ah, so the __ex_table entry only catches TLB misses?

no, but there is no __ex_table handling in address error hanlder (yet).

> Does this mean it also traps for kernel memory accesses, or do those
> work again?

it will trap for every access.


> If the addresses on mips64 are separate like on
> sparc64 or s390, the entire access_ok() step could be replaced
> by a fixup code in the exception handler. I suppose this depends on
> CONFIG_EVA and you still need a limit check at least when EVA is
> disabled.

only EVA has seperate address spaces for kernel/user.

> > Is there a reason to not also #define TASK_SIZE_MAX   __UA_LIMIT like
> > for the 32bit case ?
> >
> 
> For 32-bit, the __UA_LIMIT is a compile-time constant, so the check
> ends up being trivial. On all other architectures, the same thing can
> be done after the set_fs removal, so I was hoping it would work here
> as well.

ic

> I suspect doing the generic (size <= limit) && (addr <= (limit - size))
> check on mips64 with the runtime limit ends up slightly slower
> than the current code that checks a bit mask instead. If you like,
> I'll update it this way, otherwise I'd need help in form of a patch
> that changes the exception handling so __get_user/__put_user
> also return -EFAULT for an address error.

that's what the patch does. For aligned accesses the patch should
do the right thing, but it breaks unaligned get_user/put_user.
Checking if the trapping vaddr is between end of CPU VM space and
TASK_MAX_SIZE before exception handling should do the trick. I'll
send a patch, if this works.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

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

WARNING: multiple messages have this Message-ID (diff)
From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Christoph Hellwig <hch@lst.de>,
	linux-arch <linux-arch@vger.kernel.org>,
	Linux-MM <linux-mm@kvack.org>,
	Linux API <linux-api@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Russell King - ARM Linux <linux@armlinux.org.uk>,
	Will Deacon <will@kernel.org>, Guo Ren <guoren@kernel.org>,
	Brian Cain <bcain@codeaurora.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Michal Simek <monstr@monstr.eu>, Nick Hu <nickhu@andestech.com>,
	Greentime Hu <green.hu@gmail.com>,
	Dinh Nguyen <dinguyen@kernel.org>,
	Stafford Horne <shorne@gmail.com>, Helge Deller <deller@gmx.de>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Heiko Carstens <hca@linux.ibm.com>, Rich Felker <dalias@libc.org>,
	David Miller <davem@davemloft.net>,
	Richard Weinberger <richard@nod.at>,
	the arch/x86 maintainers <x86@kernel.org>,
	Max Filippov <jcmvbkbc@gmail.com>,
	"Eric W . Biederman" <ebiederm@xmission.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	alpha <linux-alpha@vger.kernel.org>,
	"open list:SYNOPSYS ARC ARCHITECTURE"
	<linux-snps-arc@lists.infradead.org>,
	linux-csky@vger.kernel.org,
	"open list:QUALCOMM HEXAGON..." <linux-hexagon@vger.kernel.org>,
	linux-ia64@vger.kernel.org,
	linux-m68k <linux-m68k@lists.linux-m68k.org>,
	"open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>,
	Openrisc <openrisc@lists.librecores.org>,
	Parisc List <linux-parisc@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	linux-s390 <linux-s390@vger.kernel.org>,
	Linux-sh list <linux-sh@vger.kernel.org>,
	sparclinux <sparclinux@vger.kernel.org>,
	linux-um <linux-um@lists.infradead.org>,
	"open list:TENSILICA XTENSA PORT (xtensa)"
	<linux-xtensa@linux-xtensa.org>
Subject: Re: [PATCH v2 09/18] mips: use simpler access_ok()
Date: Mon, 21 Feb 2022 16:21:30 +0100	[thread overview]
Message-ID: <20220221152130.GA17373@alpha.franken.de> (raw)
In-Reply-To: <CAK8P3a2usZWPDDDUcscwS0aVKsY6aLXFGFPqYNkm4hcDERim9w@mail.gmail.com>

On Mon, Feb 21, 2022 at 03:31:23PM +0100, Arnd Bergmann wrote:
> On Mon, Feb 21, 2022 at 2:24 PM Thomas Bogendoerfer
> <tsbogend@alpha.franken.de> wrote:
> > On Wed, Feb 16, 2022 at 02:13:23PM +0100, Arnd Bergmann wrote:
> > >
> > > diff --git a/arch/mips/include/asm/uaccess.h b/arch/mips/include/asm/uaccess.h
> > > index db9a8e002b62..d7c89dc3426c 100644
> >
> > this doesn't work. For every access above maximum implemented virtual address
> > space of the CPU an address error will be issued, but not a TLB miss.
> > And address error isn't able to handle this situation.
> 
> Ah, so the __ex_table entry only catches TLB misses?

no, but there is no __ex_table handling in address error hanlder (yet).

> Does this mean it also traps for kernel memory accesses, or do those
> work again?

it will trap for every access.


> If the addresses on mips64 are separate like on
> sparc64 or s390, the entire access_ok() step could be replaced
> by a fixup code in the exception handler. I suppose this depends on
> CONFIG_EVA and you still need a limit check at least when EVA is
> disabled.

only EVA has seperate address spaces for kernel/user.

> > Is there a reason to not also #define TASK_SIZE_MAX   __UA_LIMIT like
> > for the 32bit case ?
> >
> 
> For 32-bit, the __UA_LIMIT is a compile-time constant, so the check
> ends up being trivial. On all other architectures, the same thing can
> be done after the set_fs removal, so I was hoping it would work here
> as well.

ic

> I suspect doing the generic (size <= limit) && (addr <= (limit - size))
> check on mips64 with the runtime limit ends up slightly slower
> than the current code that checks a bit mask instead. If you like,
> I'll update it this way, otherwise I'd need help in form of a patch
> that changes the exception handling so __get_user/__put_user
> also return -EFAULT for an address error.

that's what the patch does. For aligned accesses the patch should
do the right thing, but it breaks unaligned get_user/put_user.
Checking if the trapping vaddr is between end of CPU VM space and
TASK_MAX_SIZE before exception handling should do the trick. I'll
send a patch, if this works.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

WARNING: multiple messages have this Message-ID (diff)
From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
To: openrisc@lists.librecores.org
Subject: [OpenRISC] [PATCH v2 09/18] mips: use simpler access_ok()
Date: Mon, 21 Feb 2022 16:21:30 +0100	[thread overview]
Message-ID: <20220221152130.GA17373@alpha.franken.de> (raw)
In-Reply-To: <CAK8P3a2usZWPDDDUcscwS0aVKsY6aLXFGFPqYNkm4hcDERim9w@mail.gmail.com>

On Mon, Feb 21, 2022 at 03:31:23PM +0100, Arnd Bergmann wrote:
> On Mon, Feb 21, 2022 at 2:24 PM Thomas Bogendoerfer
> <tsbogend@alpha.franken.de> wrote:
> > On Wed, Feb 16, 2022 at 02:13:23PM +0100, Arnd Bergmann wrote:
> > >
> > > diff --git a/arch/mips/include/asm/uaccess.h b/arch/mips/include/asm/uaccess.h
> > > index db9a8e002b62..d7c89dc3426c 100644
> >
> > this doesn't work. For every access above maximum implemented virtual address
> > space of the CPU an address error will be issued, but not a TLB miss.
> > And address error isn't able to handle this situation.
> 
> Ah, so the __ex_table entry only catches TLB misses?

no, but there is no __ex_table handling in address error hanlder (yet).

> Does this mean it also traps for kernel memory accesses, or do those
> work again?

it will trap for every access.


> If the addresses on mips64 are separate like on
> sparc64 or s390, the entire access_ok() step could be replaced
> by a fixup code in the exception handler. I suppose this depends on
> CONFIG_EVA and you still need a limit check at least when EVA is
> disabled.

only EVA has seperate address spaces for kernel/user.

> > Is there a reason to not also #define TASK_SIZE_MAX   __UA_LIMIT like
> > for the 32bit case ?
> >
> 
> For 32-bit, the __UA_LIMIT is a compile-time constant, so the check
> ends up being trivial. On all other architectures, the same thing can
> be done after the set_fs removal, so I was hoping it would work here
> as well.

ic

> I suspect doing the generic (size <= limit) && (addr <= (limit - size))
> check on mips64 with the runtime limit ends up slightly slower
> than the current code that checks a bit mask instead. If you like,
> I'll update it this way, otherwise I'd need help in form of a patch
> that changes the exception handling so __get_user/__put_user
> also return -EFAULT for an address error.

that's what the patch does. For aligned accesses the patch should
do the right thing, but it breaks unaligned get_user/put_user.
Checking if the trapping vaddr is between end of CPU VM space and
TASK_MAX_SIZE before exception handling should do the trick. I'll
send a patch, if this works.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

WARNING: multiple messages have this Message-ID (diff)
From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Rich Felker <dalias@libc.org>,
	linux-ia64@vger.kernel.org,
	Linux-sh list <linux-sh@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	"open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>,
	Linux-MM <linux-mm@kvack.org>, Guo Ren <guoren@kernel.org>,
	sparclinux <sparclinux@vger.kernel.org>,
	"open list:QUALCOMM HEXAGON..." <linux-hexagon@vger.kernel.org>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	Will Deacon <will@kernel.org>, Christoph Hellwig <hch@lst.de>,
	linux-arch <linux-arch@vger.kernel.org>,
	linux-s390 <linux-s390@vger.kernel.org>,
	Brian Cain <bcain@codeaurora.org>, Helge Deller <deller@gmx.de>,
	the arch/x86 maintainers <x86@kernel.org>,
	Russell King - ARM Linux <linux@armlinux.org.uk>,
	linux-csky@vger.kernel.org, Ard Biesheuvel <ardb@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	"open list:SYNOPSYS ARC ARCHITECTURE"
	<linux-snps-arc@lists.infradead.org>,
	"open list:TENSILICA XTENSA PORT \(xtensa\)"
	<linux-xtensa@linux-xtensa.org>, Arnd Bergmann <arnd@arndb.de>,
	Heiko Carstens <hca@linux.ibm.com>,
	alpha <linux-alpha@vger.kernel.org>,
	linux-um <linux-um@lists.infradead.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	linux-m68k <linux-m68k@lists.linux-m68k.org>,
	Openrisc <openrisc@lists.librecores.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Stafford Horne <shorne@gmail.com>,
	Michal Simek <monstr@monstr.eu>,
	Parisc List <linux-parisc@vger.kernel.org>,
	Nick Hu <nickhu@andestech.com>, Max Filippov <jcmvbkbc@gmail.com>,
	Linux API <linux-api@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Dinh Nguyen <dinguyen@kernel.org>,
	"Eric W . Biederman" <ebiederm@xmission.com>,
	Richard Weinberger <richard@nod.at>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	David Miller <davem@davemloft.net>,
	Greentime Hu <green.hu@gmail.com>
Subject: Re: [PATCH v2 09/18] mips: use simpler access_ok()
Date: Mon, 21 Feb 2022 16:21:30 +0100	[thread overview]
Message-ID: <20220221152130.GA17373@alpha.franken.de> (raw)
In-Reply-To: <CAK8P3a2usZWPDDDUcscwS0aVKsY6aLXFGFPqYNkm4hcDERim9w@mail.gmail.com>

On Mon, Feb 21, 2022 at 03:31:23PM +0100, Arnd Bergmann wrote:
> On Mon, Feb 21, 2022 at 2:24 PM Thomas Bogendoerfer
> <tsbogend@alpha.franken.de> wrote:
> > On Wed, Feb 16, 2022 at 02:13:23PM +0100, Arnd Bergmann wrote:
> > >
> > > diff --git a/arch/mips/include/asm/uaccess.h b/arch/mips/include/asm/uaccess.h
> > > index db9a8e002b62..d7c89dc3426c 100644
> >
> > this doesn't work. For every access above maximum implemented virtual address
> > space of the CPU an address error will be issued, but not a TLB miss.
> > And address error isn't able to handle this situation.
> 
> Ah, so the __ex_table entry only catches TLB misses?

no, but there is no __ex_table handling in address error hanlder (yet).

> Does this mean it also traps for kernel memory accesses, or do those
> work again?

it will trap for every access.


> If the addresses on mips64 are separate like on
> sparc64 or s390, the entire access_ok() step could be replaced
> by a fixup code in the exception handler. I suppose this depends on
> CONFIG_EVA and you still need a limit check at least when EVA is
> disabled.

only EVA has seperate address spaces for kernel/user.

> > Is there a reason to not also #define TASK_SIZE_MAX   __UA_LIMIT like
> > for the 32bit case ?
> >
> 
> For 32-bit, the __UA_LIMIT is a compile-time constant, so the check
> ends up being trivial. On all other architectures, the same thing can
> be done after the set_fs removal, so I was hoping it would work here
> as well.

ic

> I suspect doing the generic (size <= limit) && (addr <= (limit - size))
> check on mips64 with the runtime limit ends up slightly slower
> than the current code that checks a bit mask instead. If you like,
> I'll update it this way, otherwise I'd need help in form of a patch
> that changes the exception handling so __get_user/__put_user
> also return -EFAULT for an address error.

that's what the patch does. For aligned accesses the patch should
do the right thing, but it breaks unaligned get_user/put_user.
Checking if the trapping vaddr is between end of CPU VM space and
TASK_MAX_SIZE before exception handling should do the trick. I'll
send a patch, if this works.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

  parent reply	other threads:[~2022-02-21 15:21 UTC|newest]

Thread overview: 528+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-16 13:13 [PATCH v2 00/18] clean up asm/uaccess.h, kill set_fs for good Arnd Bergmann
2022-02-16 13:13 ` Arnd Bergmann
2022-02-16 13:13 ` [OpenRISC] " Arnd Bergmann
2022-02-16 13:13 ` Arnd Bergmann
2022-02-16 13:13 ` Arnd Bergmann
2022-02-16 13:13 ` Arnd Bergmann
2022-02-16 13:13 ` Arnd Bergmann
2022-02-16 13:13 ` [PATCH v2 01/18] uaccess: fix integer overflow on access_ok() Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` [OpenRISC] " Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13 ` [PATCH v2 02/18] uaccess: fix nios2 and microblaze get_user_8() Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` [OpenRISC] " Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:35   ` David Laight
2022-02-16 13:35     ` David Laight
2022-02-16 13:35     ` [OpenRISC] " David Laight
2022-02-16 13:35     ` David Laight
2022-02-16 13:35     ` David Laight
2022-02-16 13:35     ` David Laight
2022-02-18  6:25   ` Christoph Hellwig
2022-02-18  6:25     ` Christoph Hellwig
2022-02-18  6:25     ` [OpenRISC] " Christoph Hellwig
2022-02-18  6:25     ` Christoph Hellwig
2022-02-18  6:25     ` Christoph Hellwig
2022-02-18  6:25     ` Christoph Hellwig
2022-02-18  6:25     ` Christoph Hellwig
2022-02-25  4:28   ` Dinh Nguyen
2022-02-25  4:28     ` Dinh Nguyen
2022-02-25  4:28     ` [OpenRISC] " Dinh Nguyen
2022-02-25  4:28     ` Dinh Nguyen
2022-02-25  4:28     ` Dinh Nguyen
2022-02-25  4:28     ` Dinh Nguyen
2022-02-25  4:28     ` Dinh Nguyen
2022-02-16 13:13 ` [PATCH v2 03/18] nds32: fix access_ok() checks in get/put_user Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` [OpenRISC] " Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-18  6:25   ` Christoph Hellwig
2022-02-18  6:25     ` Christoph Hellwig
2022-02-18  6:25     ` [OpenRISC] " Christoph Hellwig
2022-02-18  6:25     ` Christoph Hellwig
2022-02-18  6:25     ` Christoph Hellwig
2022-02-18  6:25     ` Christoph Hellwig
2022-02-18  6:25     ` Christoph Hellwig
2022-02-16 13:13 ` [PATCH v2 04/18] sparc64: add __{get,put}_kernel_nocheck() Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` [OpenRISC] [PATCH v2 04/18] sparc64: add __{get, put}_kernel_nocheck() Arnd Bergmann
2022-02-16 13:13   ` [PATCH v2 04/18] sparc64: add __{get,put}_kernel_nocheck() Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13 ` [PATCH v2 05/18] x86: remove __range_not_ok() Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` [OpenRISC] " Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-18  6:28   ` Christoph Hellwig
2022-02-18  6:28     ` Christoph Hellwig
2022-02-18  6:28     ` [OpenRISC] " Christoph Hellwig
2022-02-18  6:28     ` Christoph Hellwig
2022-02-18  6:28     ` Christoph Hellwig
2022-02-18  6:28     ` Christoph Hellwig
2022-02-18  6:28     ` Christoph Hellwig
2022-02-18  7:29     ` Arnd Bergmann
2022-02-18  7:29       ` Arnd Bergmann
2022-02-18  7:29       ` [OpenRISC] " Arnd Bergmann
2022-02-18  7:29       ` Arnd Bergmann
2022-02-18  7:29       ` Arnd Bergmann
2022-02-18  7:29       ` Arnd Bergmann
2022-02-18  7:29       ` Arnd Bergmann
2022-02-18 15:45     ` David Laight
2022-02-18 15:45       ` David Laight
2022-02-18 15:45       ` [OpenRISC] " David Laight
2022-02-18 15:45       ` David Laight
2022-02-18 15:45       ` David Laight
2022-02-18 15:45       ` David Laight
2022-02-16 13:13 ` [PATCH v2 06/18] x86: use more conventional access_ok() definition Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` [OpenRISC] " Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-18  6:29   ` Christoph Hellwig
2022-02-18  6:29     ` Christoph Hellwig
2022-02-18  6:29     ` [OpenRISC] " Christoph Hellwig
2022-02-18  6:29     ` Christoph Hellwig
2022-02-18  6:29     ` Christoph Hellwig
2022-02-18  6:29     ` Christoph Hellwig
2022-02-18  6:29     ` Christoph Hellwig
2022-02-16 13:13 ` [PATCH v2 07/18] nios2: drop access_ok() check from __put_user() Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` [OpenRISC] " Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-18  6:29   ` Christoph Hellwig
2022-02-18  6:29     ` Christoph Hellwig
2022-02-18  6:29     ` [OpenRISC] " Christoph Hellwig
2022-02-18  6:29     ` Christoph Hellwig
2022-02-18  6:29     ` Christoph Hellwig
2022-02-18  6:29     ` Christoph Hellwig
2022-02-18  6:29     ` Christoph Hellwig
2022-02-23 23:30   ` Dinh Nguyen
2022-02-23 23:30     ` Dinh Nguyen
2022-02-23 23:30     ` [OpenRISC] " Dinh Nguyen
2022-02-23 23:30     ` Dinh Nguyen
2022-02-23 23:30     ` Dinh Nguyen
2022-02-23 23:30     ` Dinh Nguyen
2022-02-23 23:30     ` Dinh Nguyen
2022-02-24  7:05     ` Arnd Bergmann
2022-02-24  7:05       ` Arnd Bergmann
2022-02-24  7:05       ` [OpenRISC] " Arnd Bergmann
2022-02-24  7:05       ` Arnd Bergmann
2022-02-24  7:05       ` Arnd Bergmann
2022-02-24  7:05       ` Arnd Bergmann
2022-02-24  7:05       ` Arnd Bergmann
2022-02-16 13:13 ` [PATCH v2 08/18] uaccess: add generic __{get,put}_kernel_nofault Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` [OpenRISC] [PATCH v2 08/18] uaccess: add generic __{get, put}_kernel_nofault Arnd Bergmann
2022-02-16 13:13   ` [PATCH v2 08/18] uaccess: add generic __{get,put}_kernel_nofault Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
     [not found]   ` <20220216131332.1489939-9-arnd-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2022-02-18  6:30     ` Christoph Hellwig
2022-02-18  6:30       ` Christoph Hellwig
2022-02-18  6:30       ` [OpenRISC] [PATCH v2 08/18] uaccess: add generic __{get, put}_kernel_nofault Christoph Hellwig
2022-02-18  6:30       ` [PATCH v2 08/18] uaccess: add generic __{get,put}_kernel_nofault Christoph Hellwig
2022-02-18  6:30       ` Christoph Hellwig
2022-02-18  6:30       ` Christoph Hellwig
2022-02-18  6:30       ` Christoph Hellwig
2022-02-18  8:55   ` Geert Uytterhoeven
2022-02-18  8:55     ` Geert Uytterhoeven
2022-02-18  8:55     ` [OpenRISC] [PATCH v2 08/18] uaccess: add generic __{get, put}_kernel_nofault Geert Uytterhoeven
2022-02-18  8:55     ` [PATCH v2 08/18] uaccess: add generic __{get,put}_kernel_nofault Geert Uytterhoeven
2022-02-18  8:55     ` Geert Uytterhoeven
2022-02-18  8:55     ` Geert Uytterhoeven
2022-02-18  8:55     ` Geert Uytterhoeven
2022-02-16 13:13 ` [PATCH v2 09/18] mips: use simpler access_ok() Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` [OpenRISC] " Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-21 13:24   ` Thomas Bogendoerfer
2022-02-21 13:24     ` Thomas Bogendoerfer
2022-02-21 13:24     ` [OpenRISC] " Thomas Bogendoerfer
2022-02-21 13:24     ` Thomas Bogendoerfer
2022-02-21 13:24     ` Thomas Bogendoerfer
2022-02-21 13:24     ` Thomas Bogendoerfer
2022-02-21 13:24     ` Thomas Bogendoerfer
2022-02-21 14:31     ` Arnd Bergmann
2022-02-21 14:31       ` Arnd Bergmann
2022-02-21 14:31       ` [OpenRISC] " Arnd Bergmann
2022-02-21 14:31       ` Arnd Bergmann
2022-02-21 14:31       ` Arnd Bergmann
2022-02-21 14:31       ` Arnd Bergmann
2022-02-21 14:31       ` Arnd Bergmann
     [not found]       ` <CAK8P3a2usZWPDDDUcscwS0aVKsY6aLXFGFPqYNkm4hcDERim9w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2022-02-21 15:21         ` Thomas Bogendoerfer [this message]
2022-02-21 15:21           ` Thomas Bogendoerfer
2022-02-21 15:21           ` [OpenRISC] " Thomas Bogendoerfer
2022-02-21 15:21           ` Thomas Bogendoerfer
2022-02-21 15:21           ` Thomas Bogendoerfer
2022-02-21 15:21           ` Thomas Bogendoerfer
2022-02-21 15:21           ` Thomas Bogendoerfer
2022-02-22 16:36       ` Thomas Bogendoerfer
2022-02-22 16:36         ` Thomas Bogendoerfer
2022-02-22 16:36         ` [OpenRISC] " Thomas Bogendoerfer
2022-02-22 16:36         ` Thomas Bogendoerfer
2022-02-22 16:36         ` Thomas Bogendoerfer
2022-02-22 16:36         ` Thomas Bogendoerfer
2022-02-22 16:36         ` Thomas Bogendoerfer
2022-02-23 20:05     ` Linus Torvalds
2022-02-23 20:05       ` Linus Torvalds
2022-02-23 20:05       ` [OpenRISC] " Linus Torvalds
2022-02-23 20:05       ` Linus Torvalds
2022-02-23 20:05       ` Linus Torvalds
2022-02-23 20:05       ` Linus Torvalds
2022-02-23 20:05       ` Linus Torvalds
2022-02-23  7:41   ` Thomas Bogendoerfer
2022-02-23  7:41     ` Thomas Bogendoerfer
2022-02-23  7:41     ` [OpenRISC] " Thomas Bogendoerfer
2022-02-23  7:41     ` Thomas Bogendoerfer
2022-02-23  7:41     ` Thomas Bogendoerfer
2022-02-23  7:41     ` Thomas Bogendoerfer
2022-02-23  7:41     ` Thomas Bogendoerfer
2022-02-23  9:26     ` Arnd Bergmann
2022-02-23  9:26       ` Arnd Bergmann
2022-02-23  9:26       ` [OpenRISC] " Arnd Bergmann
2022-02-23  9:26       ` Arnd Bergmann
2022-02-23  9:26       ` Arnd Bergmann
2022-02-23  9:26       ` Arnd Bergmann
2022-02-23  9:26       ` Arnd Bergmann
2022-02-16 13:13 ` [PATCH v2 10/18] m68k: fix access_ok for coldfire Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` [OpenRISC] " Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-18  6:30   ` Christoph Hellwig
2022-02-18  6:30     ` Christoph Hellwig
2022-02-18  6:30     ` [OpenRISC] " Christoph Hellwig
2022-02-18  6:30     ` Christoph Hellwig
2022-02-18  6:30     ` Christoph Hellwig
2022-02-18  6:30     ` Christoph Hellwig
2022-02-18  6:30     ` Christoph Hellwig
2022-02-18  9:00   ` Geert Uytterhoeven
2022-02-18  9:00     ` Geert Uytterhoeven
2022-02-18  9:00     ` [OpenRISC] " Geert Uytterhoeven
2022-02-18  9:00     ` Geert Uytterhoeven
2022-02-18  9:00     ` Geert Uytterhoeven
2022-02-18  9:00     ` Geert Uytterhoeven
2022-02-18  9:00     ` Geert Uytterhoeven
2022-02-18  9:24     ` Arnd Bergmann
2022-02-18  9:24       ` Arnd Bergmann
2022-02-18  9:24       ` [OpenRISC] " Arnd Bergmann
2022-02-18  9:24       ` Arnd Bergmann
2022-02-18  9:24       ` Arnd Bergmann
2022-02-18  9:24       ` Arnd Bergmann
2022-02-18  9:24       ` Arnd Bergmann
2022-02-16 13:13 ` [PATCH v2 11/18] arm64: simplify access_ok() Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` [OpenRISC] " Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13 ` [PATCH v2 12/18] uaccess: fix type mismatch warnings from access_ok() Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` [OpenRISC] " Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-18  6:31   ` Christoph Hellwig
2022-02-18  6:31     ` Christoph Hellwig
2022-02-18  6:31     ` [OpenRISC] " Christoph Hellwig
2022-02-18  6:31     ` Christoph Hellwig
2022-02-18  6:31     ` Christoph Hellwig
2022-02-18  6:31     ` Christoph Hellwig
2022-02-18  6:31     ` Christoph Hellwig
2022-02-25  4:30   ` Dinh Nguyen
2022-02-25  4:30     ` Dinh Nguyen
2022-02-25  4:30     ` [OpenRISC] " Dinh Nguyen
2022-02-25  4:30     ` Dinh Nguyen
2022-02-25  4:30     ` Dinh Nguyen
2022-02-25  4:30     ` Dinh Nguyen
2022-02-25  4:30     ` Dinh Nguyen
2022-02-16 13:13 ` [PATCH v2 13/18] uaccess: generalize access_ok() Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` [OpenRISC] " Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-17  7:52   ` Arnd Bergmann
2022-02-17  7:52     ` Arnd Bergmann
2022-02-17  7:52     ` [OpenRISC] " Arnd Bergmann
2022-02-17  7:52     ` Arnd Bergmann
2022-02-17  7:52     ` Arnd Bergmann
2022-02-17  7:52     ` Arnd Bergmann
2022-02-17  7:52     ` Arnd Bergmann
     [not found]   ` <20220216131332.1489939-14-arnd-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2022-02-17 19:15     ` Andy Lutomirski
2022-02-17 19:15       ` Andy Lutomirski
2022-02-17 19:15       ` [OpenRISC] " Andy Lutomirski
2022-02-17 19:15       ` Andy Lutomirski
2022-02-17 19:15       ` Andy Lutomirski
2022-02-17 19:15       ` Andy Lutomirski
2022-02-17 19:15       ` Andy Lutomirski
2022-02-18  7:16       ` Arnd Bergmann
2022-02-18  7:16         ` Arnd Bergmann
2022-02-18  7:16         ` [OpenRISC] " Arnd Bergmann
2022-02-18  7:16         ` Arnd Bergmann
2022-02-18  7:16         ` Arnd Bergmann
2022-02-18  7:16         ` Arnd Bergmann
2022-02-18  7:16         ` Arnd Bergmann
2022-02-18  9:30       ` David Laight
2022-02-18  9:30         ` David Laight
2022-02-18  9:30         ` [OpenRISC] " David Laight
2022-02-18  9:30         ` David Laight
2022-02-18  9:30         ` David Laight
2022-02-18  9:30         ` David Laight
2022-02-18  9:30         ` David Laight
2022-02-18 18:07         ` Andy Lutomirski
2022-02-18 18:07           ` Andy Lutomirski
2022-02-18 18:07           ` [OpenRISC] " Andy Lutomirski
2022-02-18 18:07           ` Andy Lutomirski
2022-02-18 18:07           ` Andy Lutomirski
2022-02-18 18:07           ` Andy Lutomirski
2022-02-18 18:07           ` Andy Lutomirski
2022-02-18  6:34   ` Christoph Hellwig
2022-02-18  6:34     ` Christoph Hellwig
2022-02-18  6:34     ` [OpenRISC] " Christoph Hellwig
2022-02-18  6:34     ` Christoph Hellwig
2022-02-18  6:34     ` Christoph Hellwig
2022-02-18  6:34     ` Christoph Hellwig
2022-02-18  6:34     ` Christoph Hellwig
2022-02-18  7:23     ` Arnd Bergmann
2022-02-18  7:23       ` Arnd Bergmann
2022-02-18  7:23       ` [OpenRISC] " Arnd Bergmann
2022-02-18  7:23       ` Arnd Bergmann
2022-02-18  7:23       ` Arnd Bergmann
2022-02-18  7:23       ` Arnd Bergmann
2022-02-18  7:23       ` Arnd Bergmann
2022-02-18  9:04   ` Geert Uytterhoeven
2022-02-18  9:04     ` Geert Uytterhoeven
2022-02-18  9:04     ` [OpenRISC] " Geert Uytterhoeven
2022-02-18  9:04     ` Geert Uytterhoeven
2022-02-18  9:04     ` Geert Uytterhoeven
2022-02-18  9:04     ` Geert Uytterhoeven
2022-02-18  9:04     ` Geert Uytterhoeven
2022-02-24  8:29   ` Stafford Horne
2022-02-24  8:29     ` Stafford Horne
2022-02-24  8:29     ` [OpenRISC] " Stafford Horne
2022-02-24  8:29     ` Stafford Horne
2022-02-24  8:29     ` Stafford Horne
2022-02-24  8:29     ` Stafford Horne
2022-02-24  8:29     ` Stafford Horne
2022-02-24  8:41     ` Arnd Bergmann
2022-02-24  8:41       ` Arnd Bergmann
2022-02-24  8:41       ` [OpenRISC] " Arnd Bergmann
2022-02-24  8:41       ` Arnd Bergmann
2022-02-24  8:41       ` Arnd Bergmann
2022-02-24  8:41       ` Arnd Bergmann
2022-02-24  8:41       ` Arnd Bergmann
2022-02-25  4:31   ` Dinh Nguyen
2022-02-25  4:31     ` Dinh Nguyen
2022-02-25  4:31     ` [OpenRISC] " Dinh Nguyen
2022-02-25  4:31     ` Dinh Nguyen
2022-02-25  4:31     ` Dinh Nguyen
2022-02-25  4:31     ` Dinh Nguyen
2022-02-25  4:31     ` Dinh Nguyen
2022-02-16 13:13 ` [PATCH v2 14/18] lib/test_lockup: fix kernel pointer check for separate address spaces Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` [OpenRISC] " Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-18  6:35   ` Christoph Hellwig
2022-02-18  6:35     ` Christoph Hellwig
2022-02-18  6:35     ` [OpenRISC] " Christoph Hellwig
2022-02-18  6:35     ` Christoph Hellwig
2022-02-18  6:35     ` Christoph Hellwig
2022-02-18  6:35     ` Christoph Hellwig
2022-02-18  6:35     ` Christoph Hellwig
2022-02-18  7:15     ` Arnd Bergmann
2022-02-18  7:15       ` Arnd Bergmann
2022-02-18  7:15       ` [OpenRISC] " Arnd Bergmann
2022-02-18  7:15       ` Arnd Bergmann
2022-02-18  7:15       ` Arnd Bergmann
2022-02-18  7:15       ` Arnd Bergmann
2022-02-18  7:15       ` Arnd Bergmann
2022-02-16 13:13 ` [PATCH v2 15/18] sparc64: remove CONFIG_SET_FS support Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` [OpenRISC] " Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 18:34   ` Sam Ravnborg
2022-02-16 18:34     ` Sam Ravnborg
2022-02-16 18:34     ` [OpenRISC] " Sam Ravnborg
2022-02-16 18:34     ` Sam Ravnborg
2022-02-16 18:34     ` Sam Ravnborg
2022-02-16 18:34     ` Sam Ravnborg
2022-02-16 18:34     ` Sam Ravnborg
2022-02-16 18:41     ` Sam Ravnborg
2022-02-16 18:41       ` Sam Ravnborg
2022-02-16 18:41       ` [OpenRISC] " Sam Ravnborg
2022-02-16 18:41       ` Sam Ravnborg
2022-02-16 18:41       ` Sam Ravnborg
2022-02-16 18:41       ` Sam Ravnborg
2022-02-16 18:41       ` Sam Ravnborg
2022-02-16 22:01       ` Arnd Bergmann
2022-02-16 22:01         ` Arnd Bergmann
2022-02-16 22:01         ` [OpenRISC] " Arnd Bergmann
2022-02-16 22:01         ` Arnd Bergmann
2022-02-16 22:01         ` Arnd Bergmann
2022-02-16 22:01         ` Arnd Bergmann
2022-02-16 22:01         ` Arnd Bergmann
2022-02-16 13:13 ` [PATCH v2 16/18] sh: " Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` [OpenRISC] " Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-18  6:36   ` Christoph Hellwig
2022-02-18  6:36     ` Christoph Hellwig
2022-02-18  6:36     ` [OpenRISC] " Christoph Hellwig
2022-02-18  6:36     ` Christoph Hellwig
2022-02-18  6:36     ` Christoph Hellwig
2022-02-18  6:36     ` Christoph Hellwig
2022-02-18  6:36     ` Christoph Hellwig
2022-02-16 13:13 ` [PATCH v2 17/18] ia64: " Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` [OpenRISC] " Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13 ` [PATCH v2 18/18] uaccess: drop maining CONFIG_SET_FS users Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` [OpenRISC] " Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 13:13   ` Arnd Bergmann
2022-02-16 18:44   ` Sam Ravnborg
2022-02-16 18:44     ` Sam Ravnborg
2022-02-16 18:44     ` [OpenRISC] " Sam Ravnborg
2022-02-16 18:44     ` Sam Ravnborg
2022-02-16 18:44     ` Sam Ravnborg
2022-02-16 18:44     ` Sam Ravnborg
2022-02-16 18:44     ` Sam Ravnborg
2022-02-16 22:02     ` Arnd Bergmann
2022-02-16 22:02       ` Arnd Bergmann
2022-02-16 22:02       ` [OpenRISC] " Arnd Bergmann
2022-02-16 22:02       ` Arnd Bergmann
2022-02-16 22:02       ` Arnd Bergmann
2022-02-16 22:02       ` Arnd Bergmann
2022-02-16 22:02       ` Arnd Bergmann
2022-02-17 22:36   ` Eric W. Biederman
2022-02-17 22:36     ` Eric W. Biederman
2022-02-17 22:36     ` [OpenRISC] " Eric W. Biederman
2022-02-17 22:36     ` Eric W. Biederman
2022-02-17 22:36     ` Eric W. Biederman
2022-02-17 22:36     ` Eric W. Biederman
2022-02-17 22:36     ` Eric W. Biederman
2022-02-18  6:37   ` Christoph Hellwig
2022-02-18  6:37     ` Christoph Hellwig
2022-02-18  6:37     ` [OpenRISC] " Christoph Hellwig
2022-02-18  6:37     ` Christoph Hellwig
2022-02-18  6:37     ` Christoph Hellwig
2022-02-18  6:37     ` Christoph Hellwig
2022-02-18  6:37     ` Christoph Hellwig
2022-02-18  7:10     ` Arnd Bergmann
2022-02-18  7:10       ` Arnd Bergmann
2022-02-18  7:10       ` [OpenRISC] " Arnd Bergmann
2022-02-18  7:10       ` Arnd Bergmann
2022-02-18  7:10       ` Arnd Bergmann
2022-02-18  7:10       ` Arnd Bergmann
2022-02-18  7:10       ` Arnd Bergmann
2022-02-18 10:18   ` Sergey Matyukevich
2022-02-18 10:18     ` Sergey Matyukevich
2022-02-18 10:18     ` [OpenRISC] " Sergey Matyukevich
2022-02-18 10:18     ` Sergey Matyukevich
2022-02-18 10:18     ` Sergey Matyukevich
2022-02-18 10:18     ` Sergey Matyukevich
2022-02-18 10:18     ` Sergey Matyukevich
2022-02-24  8:45   ` Stafford Horne
2022-02-24  8:45     ` Stafford Horne
2022-02-24  8:45     ` [OpenRISC] " Stafford Horne
2022-02-24  8:45     ` Stafford Horne
2022-02-24  8:45     ` Stafford Horne
2022-02-24  8:45     ` Stafford Horne
2022-02-24  8:45     ` Stafford Horne
2022-02-25  4:33   ` Dinh Nguyen
2022-02-25  4:33     ` Dinh Nguyen
2022-02-25  4:33     ` [OpenRISC] " Dinh Nguyen
2022-02-25  4:33     ` Dinh Nguyen
2022-02-25  4:33     ` Dinh Nguyen
2022-02-25  4:33     ` Dinh Nguyen
2022-02-25  4:33     ` Dinh Nguyen
2022-02-17  7:20 ` [PATCH v2 00/18] clean up asm/uaccess.h, kill set_fs for good Christophe Leroy
2022-02-17  7:20   ` Christophe Leroy
2022-02-17  7:20   ` [OpenRISC] " Christophe Leroy
2022-02-17  7:20   ` Christophe Leroy
2022-02-17  7:20   ` Christophe Leroy
2022-02-17  7:20   ` Christophe Leroy
2022-02-17  7:20   ` Christophe Leroy
     [not found]   ` <00496df2-f9f2-2547-3ca3-7989e4713d6b-2tlSp11Fh4xulxpn9UvDqw@public.gmane.org>
2022-02-17  7:49     ` Arnd Bergmann
2022-02-17  7:49       ` Arnd Bergmann
2022-02-17  7:49       ` [OpenRISC] " Arnd Bergmann
2022-02-17  7:49       ` Arnd Bergmann
2022-02-17  7:49       ` Arnd Bergmann
2022-02-17  7:49       ` Arnd Bergmann
2022-02-17  7:49       ` Arnd Bergmann
2022-02-18  2:21       ` Al Viro
2022-02-18  2:21         ` Al Viro
2022-02-18  2:21         ` [OpenRISC] " Al Viro
2022-02-18  2:21         ` Al Viro
2022-02-18  2:21         ` Al Viro
2022-02-18  2:21         ` Al Viro
2022-02-18  9:20         ` Arnd Bergmann
2022-02-18  9:20           ` Arnd Bergmann
2022-02-18  9:20           ` [OpenRISC] " Arnd Bergmann
2022-02-18  9:20           ` Arnd Bergmann
2022-02-18  9:20           ` Arnd Bergmann
2022-02-18  9:20           ` Arnd Bergmann
2022-02-18  9:20           ` Arnd Bergmann
2022-02-18  1:50   ` Al Viro
2022-02-18  1:50     ` Al Viro
2022-02-18  1:50     ` [OpenRISC] " Al Viro
2022-02-18  1:50     ` Al Viro
2022-02-18  1:50     ` Al Viro
2022-02-18  1:50     ` Al Viro
2022-02-18 10:01     ` Christophe Leroy
2022-02-18 10:01       ` Christophe Leroy
2022-02-18 10:01       ` [OpenRISC] " Christophe Leroy
2022-02-18 10:01       ` Christophe Leroy
2022-02-18 10:01       ` Christophe Leroy
2022-02-18 10:01       ` Christophe Leroy
2022-02-18 10:01       ` Christophe Leroy
2022-02-17  8:13 ` Arnd Bergmann
2022-02-17  8:13   ` Arnd Bergmann
2022-02-17  8:13   ` [OpenRISC] " Arnd Bergmann
2022-02-17  8:13   ` Arnd Bergmann
2022-02-17  8:13   ` Arnd Bergmann
2022-02-17  8:13   ` Arnd Bergmann
2022-02-17  8:13   ` Arnd Bergmann

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=20220221152130.GA17373@alpha.franken.de \
    --to=tsbogend-i1c7kopa9pxlokyujoexcg@public.gmane.org \
    --cc=arnd-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=arnd-r2nGTMty4D4@public.gmane.org \
    --cc=bcain-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
    --cc=deller-Mmb7MZpHnFY@public.gmane.org \
    --cc=dinguyen-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org \
    --cc=green.hu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=guoren-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=hch-jcswGhMUV9g@public.gmane.org \
    --cc=linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org \
    --cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
    --cc=monstr-pSz03upnqPeHXe+LvDLADg@public.gmane.org \
    --cc=mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org \
    --cc=nickhu-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org \
    --cc=shorne-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
    --cc=viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org \
    --cc=will-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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.