All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Arnd Bergmann <arnd@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Christoph Hellwig <hch@lst.de>,
	"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>
Cc: "mark.rutland@arm.com" <mark.rutland@arm.com>,
	"dalias@libc.org" <dalias@libc.org>,
	"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
	"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
	"peterz@infradead.org" <peterz@infradead.org>,
	"jcmvbkbc@gmail.com" <jcmvbkbc@gmail.com>,
	"guoren@kernel.org" <guoren@kernel.org>,
	"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
	"linux-hexagon@vger.kernel.org" <linux-hexagon@vger.kernel.org>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	"will@kernel.org" <will@kernel.org>,
	"ardb@kernel.org" <ardb@kernel.org>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	"bcain@codeaurora.org" <bcain@codeaurora.org>,
	"deller@gmx.de" <deller@gmx.de>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux@armlinux.org.uk" <linux@armlinux.org.uk>,
	"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"geert@linux-m68k.org" <geert@linux-m68k.org>,
	"linux-snps-arc@lists.infradead.org" 
	<linux-snps-arc@lists.infradead.org>,
	"linux-xtensa@linux-xtensa.org" <linux-xtensa@linux-xtensa.org>,
	"hca@linux.ibm.com" <hca@linux.ibm.com>,
	"linux-alpha@vger.kernel.org" <linux-alpha@vger.kernel.org>,
	"linux-um@lists.infradead.org" <linux-um@lists.infradead.org>,
	"linux-m68k@lists.linux-m68k.org"
	<linux-m68k@lists.linux-m68k.org>,
	"openrisc@lists.librecores.org" <openrisc@lists.librecores.org>,
	"green.hu@gmail.com" <green.hu@gmail.com>,
	"shorne@gmail.com" <shorne@gmail.com>,
	"monstr@monstr.eu" <monstr@monstr.eu>,
	"tsbogend@alpha.franken.de" <tsbogend@alpha.franken.de>,
	"linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,
	"nickhu@andestech.com" <nickhu@andestech.com>,
	"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
	"dinguyen@kernel.org" <dinguyen@kernel.org>,
	"ebiederm@xmission.com" <ebiederm@xmission.com>,
	"richard@nod.at" <richard@nod.at>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"davem@davemloft.net" <davem@davemloft.net>
Subject: Re: [PATCH v2 00/18] clean up asm/uaccess.h, kill set_fs for good
Date: Thu, 17 Feb 2022 07:20:11 +0000	[thread overview]
Message-ID: <00496df2-f9f2-2547-3ca3-7989e4713d6b@csgroup.eu> (raw)
In-Reply-To: <20220216131332.1489939-1-arnd@kernel.org>



Le 16/02/2022 à 14:13, Arnd Bergmann a écrit :
> From: Arnd Bergmann <arnd@arndb.de>
> 
> Christoph Hellwig and a few others spent a huge effort on removing
> set_fs() from most of the important architectures, but about half the
> other architectures were never completed even though most of them don't
> actually use set_fs() at all.
> 
> I did a patch for microblaze at some point, which turned out to be fairly
> generic, and now ported it to most other architectures, using new generic
> implementations of access_ok() and __{get,put}_kernel_nocheck().
> 
> Three architectures (sparc64, ia64, and sh) needed some extra work,
> which I also completed.
> 
> The final series contains extra cleanup changes that touch all
> architectures. Please review and test these, so we can merge them
> for v5.18.

As a further cleanup, have you thought about making a generic version of 
clear_user() ? On almost all architectures, clear_user() does an 
access_ok() then calls __clear_user() or similar.

Maybe also the same with put_user() and get_user() ? After all it is 
just access_ok() followed by __put_user() or __get_user() ? It seems 
more tricky though, as some architectures seems to have less trivial 
stuff there.

I also see all architectures have a prototype for strncpy_from_user() 
and strnlen_user(). Could be a common prototype instead when we have 
GENERIC_STRNCPY_FROM_USER / GENERIC_STRNLEN_USER

And we have also 
user_access_begin()/user_read_access_begin()/user_write_access_begin() 
which call access_ok() then do the real work. Could be made generic with 
call to some arch specific __user_access_begin() and friends after the 
access_ok() and eventually the might_fault().

Christophe

WARNING: multiple messages have this Message-ID (diff)
From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Arnd Bergmann <arnd@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Christoph Hellwig <hch@lst.de>,
	"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>
Cc: "mark.rutland@arm.com" <mark.rutland@arm.com>,
	"dalias@libc.org" <dalias@libc.org>,
	"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
	 "linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
	"peterz@infradead.org" <peterz@infradead.org>,
	"jcmvbkbc@gmail.com" <jcmvbkbc@gmail.com>,
	"guoren@kernel.org" <guoren@kernel.org>,
	"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
	"linux-hexagon@vger.kernel.org" <linux-hexagon@vger.kernel.org>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	"will@kernel.org" <will@kernel.org>,
	"ardb@kernel.org" <ardb@kernel.org>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	"bcain@codeaurora.org" <bcain@codeaurora.org>,
	"deller@gmx.de" <deller@gmx.de>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux@armlinux.org.uk" <linux@armlinux.org.uk>,
	"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"geert@linux-m68k.org" <geert@linux-m68k.org>,
	"linux-snps-arc@lists.infradead.org"
	<linux-snps-arc@lists.infradead.org>,
	"linux-xtensa@linux-xtensa.org" <linux-xtensa@linux-xtensa.org>,
	"hca@linux.ibm.com" <hca@linux.ibm.com>,
	"linux-alpha@vger.kernel.org" <linux-alpha@vger.kernel.org>,
	"linux-um@lists.infradead.org" <linux-um@lists.infradead.org>,
	"linux-m68k@lists.linux-m68k.org"
	<linux-m68k@lists.linux-m68k.org>,
	"openrisc@lists.librecores.org" <openrisc@lists.librecores.org>,
	"green.hu@gmail.com" <green.hu@gmail.com>,
	"shorne@gmail.com" <shorne@gmail.com>,
	"monstr@monstr.eu" <monstr@monstr.eu>,
	 "tsbogend@alpha.franken.de" <tsbogend@alpha.franken.de>,
	"linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,
	"nickhu@andestech.com" <nickhu@andestech.com>,
	"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
	"dinguyen@kernel.org" <dinguyen@kernel.org>,
	"ebiederm@xmission.com" <ebiederm@xmission.com>,
	"richard@nod.at" <richard@nod.at>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"davem@davemloft.net" <davem@davemloft.net>
Subject: Re: [PATCH v2 00/18] clean up asm/uaccess.h, kill set_fs for good
Date: Thu, 17 Feb 2022 07:20:11 +0000	[thread overview]
Message-ID: <00496df2-f9f2-2547-3ca3-7989e4713d6b@csgroup.eu> (raw)
In-Reply-To: <20220216131332.1489939-1-arnd@kernel.org>



Le 16/02/2022 à 14:13, Arnd Bergmann a écrit :
> From: Arnd Bergmann <arnd@arndb.de>
> 
> Christoph Hellwig and a few others spent a huge effort on removing
> set_fs() from most of the important architectures, but about half the
> other architectures were never completed even though most of them don't
> actually use set_fs() at all.
> 
> I did a patch for microblaze at some point, which turned out to be fairly
> generic, and now ported it to most other architectures, using new generic
> implementations of access_ok() and __{get,put}_kernel_nocheck().
> 
> Three architectures (sparc64, ia64, and sh) needed some extra work,
> which I also completed.
> 
> The final series contains extra cleanup changes that touch all
> architectures. Please review and test these, so we can merge them
> for v5.18.

As a further cleanup, have you thought about making a generic version of 
clear_user() ? On almost all architectures, clear_user() does an 
access_ok() then calls __clear_user() or similar.

Maybe also the same with put_user() and get_user() ? After all it is 
just access_ok() followed by __put_user() or __get_user() ? It seems 
more tricky though, as some architectures seems to have less trivial 
stuff there.

I also see all architectures have a prototype for strncpy_from_user() 
and strnlen_user(). Could be a common prototype instead when we have 
GENERIC_STRNCPY_FROM_USER / GENERIC_STRNLEN_USER

And we have also 
user_access_begin()/user_read_access_begin()/user_write_access_begin() 
which call access_ok() then do the real work. Could be made generic with 
call to some arch specific __user_access_begin() and friends after the 
access_ok() and eventually the might_fault().

Christophe
_______________________________________________
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: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Arnd Bergmann <arnd@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Christoph Hellwig <hch@lst.de>,
	"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>
Cc: "mark.rutland@arm.com" <mark.rutland@arm.com>,
	"dalias@libc.org" <dalias@libc.org>,
	"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
	 "linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
	"peterz@infradead.org" <peterz@infradead.org>,
	"jcmvbkbc@gmail.com" <jcmvbkbc@gmail.com>,
	"guoren@kernel.org" <guoren@kernel.org>,
	"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
	"linux-hexagon@vger.kernel.org" <linux-hexagon@vger.kernel.org>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	"will@kernel.org" <will@kernel.org>,
	"ardb@kernel.org" <ardb@kernel.org>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	"bcain@codeaurora.org" <bcain@codeaurora.org>,
	"deller@gmx.de" <deller@gmx.de>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux@armlinux.org.uk" <linux@armlinux.org.uk>,
	"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"geert@linux-m68k.org" <geert@linux-m68k.org>,
	"linux-snps-arc@lists.infradead.org"
	<linux-snps-arc@lists.infradead.org>,
	"linux-xtensa@linux-xtensa.org" <linux-xtensa@linux-xtensa.org>,
	"hca@linux.ibm.com" <hca@linux.ibm.com>,
	"linux-alpha@vger.kernel.org" <linux-alpha@vger.kernel.org>,
	"linux-um@lists.infradead.org" <linux-um@lists.infradead.org>,
	"linux-m68k@lists.linux-m68k.org"
	<linux-m68k@lists.linux-m68k.org>,
	"openrisc@lists.librecores.org" <openrisc@lists.librecores.org>,
	"green.hu@gmail.com" <green.hu@gmail.com>,
	"shorne@gmail.com" <shorne@gmail.com>,
	"monstr@monstr.eu" <monstr@monstr.eu>,
	 "tsbogend@alpha.franken.de" <tsbogend@alpha.franken.de>,
	"linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,
	"nickhu@andestech.com" <nickhu@andestech.com>,
	"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
	"dinguyen@kernel.org" <dinguyen@kernel.org>,
	"ebiederm@xmission.com" <ebiederm@xmission.com>,
	"richard@nod.at" <richard@nod.at>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"davem@davemloft.net" <davem@davemloft.net>
Subject: Re: [PATCH v2 00/18] clean up asm/uaccess.h, kill set_fs for good
Date: Thu, 17 Feb 2022 07:20:11 +0000	[thread overview]
Message-ID: <00496df2-f9f2-2547-3ca3-7989e4713d6b@csgroup.eu> (raw)
In-Reply-To: <20220216131332.1489939-1-arnd@kernel.org>



Le 16/02/2022 à 14:13, Arnd Bergmann a écrit :
> From: Arnd Bergmann <arnd@arndb.de>
> 
> Christoph Hellwig and a few others spent a huge effort on removing
> set_fs() from most of the important architectures, but about half the
> other architectures were never completed even though most of them don't
> actually use set_fs() at all.
> 
> I did a patch for microblaze at some point, which turned out to be fairly
> generic, and now ported it to most other architectures, using new generic
> implementations of access_ok() and __{get,put}_kernel_nocheck().
> 
> Three architectures (sparc64, ia64, and sh) needed some extra work,
> which I also completed.
> 
> The final series contains extra cleanup changes that touch all
> architectures. Please review and test these, so we can merge them
> for v5.18.

As a further cleanup, have you thought about making a generic version of 
clear_user() ? On almost all architectures, clear_user() does an 
access_ok() then calls __clear_user() or similar.

Maybe also the same with put_user() and get_user() ? After all it is 
just access_ok() followed by __put_user() or __get_user() ? It seems 
more tricky though, as some architectures seems to have less trivial 
stuff there.

I also see all architectures have a prototype for strncpy_from_user() 
and strnlen_user(). Could be a common prototype instead when we have 
GENERIC_STRNCPY_FROM_USER / GENERIC_STRNLEN_USER

And we have also 
user_access_begin()/user_read_access_begin()/user_write_access_begin() 
which call access_ok() then do the real work. Could be made generic with 
call to some arch specific __user_access_begin() and friends after the 
access_ok() and eventually the might_fault().

Christophe
_______________________________________________
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: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Arnd Bergmann <arnd@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Christoph Hellwig <hch@lst.de>,
	"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>
Cc: "mark.rutland@arm.com" <mark.rutland@arm.com>,
	"dalias@libc.org" <dalias@libc.org>,
	"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
	"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
	"peterz@infradead.org" <peterz@infradead.org>,
	"jcmvbkbc@gmail.com" <jcmvbkbc@gmail.com>,
	"guoren@kernel.org" <guoren@kernel.org>,
	"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	"will@kernel.org" <will@kernel.org>,
	"ardb@kernel.org" <ardb@kernel.org>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	"bcain@codeaurora.org" <bcain@codeaurora.org>,
	"linux-hexagon@vger.kernel.org" <linux-hexagon@vger.kernel.org>,
	"deller@gmx.de" <deller@gmx.de>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux@armlinux.org.uk" <linux@armlinux.org.uk>,
	"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"geert@linux-m68k.org" <geert@linux-m68k.org>,
	"linux-snps-arc@lists.infradead.org"
	<linux-snps-arc@lists.infradead.org>,
	"linux-xtensa@linux-xtensa.org" <linux-xtensa@linux-xtensa.org>,
	"hca@linux.ibm.com" <hca@linux.ibm.com>,
	"linux-um@lists.infradead.org" <linux-um@lists.infradead.org>,
	"richard@nod.at" <richard@nod.at>,
	"linux-m68k@lists.linux-m68k.org"
	<linux-m68k@lists.linux-m68k.org>,
	"openrisc@lists.librecores.org" <openrisc@lists.librecores.org>,
	"green.hu@gmail.com" <green.hu@gmail.com>,
	"shorne@gmail.com" <shorne@gmail.com>,
	"monstr@monstr.eu" <monstr@monstr.eu>,
	"tsbogend@alpha.franken.de" <tsbogend@alpha.franken.de>,
	"nickhu@andestech.com" <nickhu@andestech.com>,
	"linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,
	"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
	"dinguyen@kernel.org" <dinguyen@kernel.org>,
	"ebiederm@xmission.com" <ebiederm@xmission.com>,
	"linux-alpha@vger.kernel.org" <linux-alpha@vger.kernel.org>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"davem@davemloft.net" <davem@davemloft.net>
Subject: Re: [PATCH v2 00/18] clean up asm/uaccess.h, kill set_fs for good
Date: Thu, 17 Feb 2022 07:20:11 +0000	[thread overview]
Message-ID: <00496df2-f9f2-2547-3ca3-7989e4713d6b@csgroup.eu> (raw)
In-Reply-To: <20220216131332.1489939-1-arnd@kernel.org>



Le 16/02/2022 à 14:13, Arnd Bergmann a écrit :
> From: Arnd Bergmann <arnd@arndb.de>
> 
> Christoph Hellwig and a few others spent a huge effort on removing
> set_fs() from most of the important architectures, but about half the
> other architectures were never completed even though most of them don't
> actually use set_fs() at all.
> 
> I did a patch for microblaze at some point, which turned out to be fairly
> generic, and now ported it to most other architectures, using new generic
> implementations of access_ok() and __{get,put}_kernel_nocheck().
> 
> Three architectures (sparc64, ia64, and sh) needed some extra work,
> which I also completed.
> 
> The final series contains extra cleanup changes that touch all
> architectures. Please review and test these, so we can merge them
> for v5.18.

As a further cleanup, have you thought about making a generic version of 
clear_user() ? On almost all architectures, clear_user() does an 
access_ok() then calls __clear_user() or similar.

Maybe also the same with put_user() and get_user() ? After all it is 
just access_ok() followed by __put_user() or __get_user() ? It seems 
more tricky though, as some architectures seems to have less trivial 
stuff there.

I also see all architectures have a prototype for strncpy_from_user() 
and strnlen_user(). Could be a common prototype instead when we have 
GENERIC_STRNCPY_FROM_USER / GENERIC_STRNLEN_USER

And we have also 
user_access_begin()/user_read_access_begin()/user_write_access_begin() 
which call access_ok() then do the real work. Could be made generic with 
call to some arch specific __user_access_begin() and friends after the 
access_ok() and eventually the might_fault().

Christophe

WARNING: multiple messages have this Message-ID (diff)
From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: openrisc@lists.librecores.org
Subject: [OpenRISC] [PATCH v2 00/18] clean up asm/uaccess.h, kill set_fs for good
Date: Thu, 17 Feb 2022 07:20:11 +0000	[thread overview]
Message-ID: <00496df2-f9f2-2547-3ca3-7989e4713d6b@csgroup.eu> (raw)
In-Reply-To: <20220216131332.1489939-1-arnd@kernel.org>



Le 16/02/2022 à 14:13, Arnd Bergmann a écrit :
> From: Arnd Bergmann <arnd@arndb.de>
> 
> Christoph Hellwig and a few others spent a huge effort on removing
> set_fs() from most of the important architectures, but about half the
> other architectures were never completed even though most of them don't
> actually use set_fs() at all.
> 
> I did a patch for microblaze at some point, which turned out to be fairly
> generic, and now ported it to most other architectures, using new generic
> implementations of access_ok() and __{get,put}_kernel_nocheck().
> 
> Three architectures (sparc64, ia64, and sh) needed some extra work,
> which I also completed.
> 
> The final series contains extra cleanup changes that touch all
> architectures. Please review and test these, so we can merge them
> for v5.18.

As a further cleanup, have you thought about making a generic version of 
clear_user() ? On almost all architectures, clear_user() does an 
access_ok() then calls __clear_user() or similar.

Maybe also the same with put_user() and get_user() ? After all it is 
just access_ok() followed by __put_user() or __get_user() ? It seems 
more tricky though, as some architectures seems to have less trivial 
stuff there.

I also see all architectures have a prototype for strncpy_from_user() 
and strnlen_user(). Could be a common prototype instead when we have 
GENERIC_STRNCPY_FROM_USER / GENERIC_STRNLEN_USER

And we have also 
user_access_begin()/user_read_access_begin()/user_write_access_begin() 
which call access_ok() then do the real work. Could be made generic with 
call to some arch specific __user_access_begin() and friends after the 
access_ok() and eventually the might_fault().

Christophe

WARNING: multiple messages have this Message-ID (diff)
From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Arnd Bergmann <arnd@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Christoph Hellwig <hch@lst.de>,
	"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>
Cc: "mark.rutland@arm.com" <mark.rutland@arm.com>,
	"dalias@libc.org" <dalias@libc.org>,
	"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
	"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
	"peterz@infradead.org" <peterz@infradead.org>,
	"jcmvbkbc@gmail.com" <jcmvbkbc@gmail.com>,
	"guoren@kernel.org" <guoren@kernel.org>,
	"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
	"linux-hexagon@vger.kernel.org" <linux-hexagon@vger.kernel.org>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	"will@kernel.org" <will@kernel.org>,
	"ardb@kernel.org" <ardb@kernel.org>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	"bcain@codeaurora.org" <bcain@codeaurora.org>,
	"deller@gmx.de" <deller@gmx.de>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux@armlinux.org.uk" <linux@armlinux.org.uk>,
	"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"geert@linux-m68k.org" <geert@linux-m68k.org>,
	"linux-snps-arc@lists.infradead.org"
	<linux-snps-arc@lists.infradead.org>,
	"linux-xtensa@linux-xtensa.org" <linux-xtensa@linux-xtensa.org>,
	"hca@linux.ibm.com" <hca@linux.ibm.com>,
	"linux-alpha@vger.kernel.org" <linux-alpha@vger.kernel.org>,
	"linux-um@lists.infradead.org" <linux-um@lists.infradead.org>,
	"linux-m68k@lists.linux-m68k.org"
	<linux-m68k@lists.linux-m68k.org>,
	"openrisc@lists.librecores.org" <openrisc@lists.librecores.org>,
	"green.hu@gmail.com" <green.hu@gmail.com>,
	"shorne@gmail.com" <shorne@gmail.com>,
	"monstr@monstr.eu" <monstr@monstr.eu>,
	"tsbogend@alpha.franken.de" <tsbogend@alpha.franken.de>,
	"linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,
	"nickhu@andestech.com" <nickhu@andestech.com>,
	"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
	"dinguyen@kernel.org" <dinguyen@kernel.org>,
	"ebiederm@xmission.com" <ebiederm@xmission.com>,
	"richard@nod.at" <richard@nod.at>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"davem@davemloft.net" <davem@davemloft.net>
Subject: Re: [PATCH v2 00/18] clean up asm/uaccess.h, kill set_fs for good
Date: Thu, 17 Feb 2022 07:20:11 +0000	[thread overview]
Message-ID: <00496df2-f9f2-2547-3ca3-7989e4713d6b@csgroup.eu> (raw)
In-Reply-To: <20220216131332.1489939-1-arnd@kernel.org>

DQoNCkxlIDE2LzAyLzIwMjIgw6AgMTQ6MTMsIEFybmQgQmVyZ21hbm4gYSDDqWNyaXTCoDoNCj4g
RnJvbTogQXJuZCBCZXJnbWFubiA8YXJuZEBhcm5kYi5kZT4NCj4gDQo+IENocmlzdG9waCBIZWxs
d2lnIGFuZCBhIGZldyBvdGhlcnMgc3BlbnQgYSBodWdlIGVmZm9ydCBvbiByZW1vdmluZw0KPiBz
ZXRfZnMoKSBmcm9tIG1vc3Qgb2YgdGhlIGltcG9ydGFudCBhcmNoaXRlY3R1cmVzLCBidXQgYWJv
dXQgaGFsZiB0aGUNCj4gb3RoZXIgYXJjaGl0ZWN0dXJlcyB3ZXJlIG5ldmVyIGNvbXBsZXRlZCBl
dmVuIHRob3VnaCBtb3N0IG9mIHRoZW0gZG9uJ3QNCj4gYWN0dWFsbHkgdXNlIHNldF9mcygpIGF0
IGFsbC4NCj4gDQo+IEkgZGlkIGEgcGF0Y2ggZm9yIG1pY3JvYmxhemUgYXQgc29tZSBwb2ludCwg
d2hpY2ggdHVybmVkIG91dCB0byBiZSBmYWlybHkNCj4gZ2VuZXJpYywgYW5kIG5vdyBwb3J0ZWQg
aXQgdG8gbW9zdCBvdGhlciBhcmNoaXRlY3R1cmVzLCB1c2luZyBuZXcgZ2VuZXJpYw0KPiBpbXBs
ZW1lbnRhdGlvbnMgb2YgYWNjZXNzX29rKCkgYW5kIF9fe2dldCxwdXR9X2tlcm5lbF9ub2NoZWNr
KCkuDQo+IA0KPiBUaHJlZSBhcmNoaXRlY3R1cmVzIChzcGFyYzY0LCBpYTY0LCBhbmQgc2gpIG5l
ZWRlZCBzb21lIGV4dHJhIHdvcmssDQo+IHdoaWNoIEkgYWxzbyBjb21wbGV0ZWQuDQo+IA0KPiBU
aGUgZmluYWwgc2VyaWVzIGNvbnRhaW5zIGV4dHJhIGNsZWFudXAgY2hhbmdlcyB0aGF0IHRvdWNo
IGFsbA0KPiBhcmNoaXRlY3R1cmVzLiBQbGVhc2UgcmV2aWV3IGFuZCB0ZXN0IHRoZXNlLCBzbyB3
ZSBjYW4gbWVyZ2UgdGhlbQ0KPiBmb3IgdjUuMTguDQoNCkFzIGEgZnVydGhlciBjbGVhbnVwLCBo
YXZlIHlvdSB0aG91Z2h0IGFib3V0IG1ha2luZyBhIGdlbmVyaWMgdmVyc2lvbiBvZiANCmNsZWFy
X3VzZXIoKSA/IE9uIGFsbW9zdCBhbGwgYXJjaGl0ZWN0dXJlcywgY2xlYXJfdXNlcigpIGRvZXMg
YW4gDQphY2Nlc3Nfb2soKSB0aGVuIGNhbGxzIF9fY2xlYXJfdXNlcigpIG9yIHNpbWlsYXIuDQoN
Ck1heWJlIGFsc28gdGhlIHNhbWUgd2l0aCBwdXRfdXNlcigpIGFuZCBnZXRfdXNlcigpID8gQWZ0
ZXIgYWxsIGl0IGlzIA0KanVzdCBhY2Nlc3Nfb2soKSBmb2xsb3dlZCBieSBfX3B1dF91c2VyKCkg
b3IgX19nZXRfdXNlcigpID8gSXQgc2VlbXMgDQptb3JlIHRyaWNreSB0aG91Z2gsIGFzIHNvbWUg
YXJjaGl0ZWN0dXJlcyBzZWVtcyB0byBoYXZlIGxlc3MgdHJpdmlhbCANCnN0dWZmIHRoZXJlLg0K
DQpJIGFsc28gc2VlIGFsbCBhcmNoaXRlY3R1cmVzIGhhdmUgYSBwcm90b3R5cGUgZm9yIHN0cm5j
cHlfZnJvbV91c2VyKCkgDQphbmQgc3Rybmxlbl91c2VyKCkuIENvdWxkIGJlIGEgY29tbW9uIHBy
b3RvdHlwZSBpbnN0ZWFkIHdoZW4gd2UgaGF2ZSANCkdFTkVSSUNfU1RSTkNQWV9GUk9NX1VTRVIg
LyBHRU5FUklDX1NUUk5MRU5fVVNFUg0KDQpBbmQgd2UgaGF2ZSBhbHNvIA0KdXNlcl9hY2Nlc3Nf
YmVnaW4oKS91c2VyX3JlYWRfYWNjZXNzX2JlZ2luKCkvdXNlcl93cml0ZV9hY2Nlc3NfYmVnaW4o
KSANCndoaWNoIGNhbGwgYWNjZXNzX29rKCkgdGhlbiBkbyB0aGUgcmVhbCB3b3JrLiBDb3VsZCBi
ZSBtYWRlIGdlbmVyaWMgd2l0aCANCmNhbGwgdG8gc29tZSBhcmNoIHNwZWNpZmljIF9fdXNlcl9h
Y2Nlc3NfYmVnaW4oKSBhbmQgZnJpZW5kcyBhZnRlciB0aGUgDQphY2Nlc3Nfb2soKSBhbmQgZXZl
bnR1YWxseSB0aGUgbWlnaHRfZmF1bHQoKS4NCg0KQ2hyaXN0b3BoZQ=

WARNING: multiple messages have this Message-ID (diff)
From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Arnd Bergmann <arnd@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Christoph Hellwig <hch@lst.de>,
	"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>
Cc: "mark.rutland@arm.com" <mark.rutland@arm.com>,
	"dalias@libc.org" <dalias@libc.org>,
	"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
	"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
	"peterz@infradead.org" <peterz@infradead.org>,
	"jcmvbkbc@gmail.com" <jcmvbkbc@gmail.com>,
	"guoren@kernel.org" <guoren@kernel.org>,
	"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
	"linux-hexagon@vger.kernel.org" <linux-hexagon@vger.kernel.org>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	"will@kernel.org" <will@kernel.org>,
	"ardb@kernel.org" <ardb@kernel.org>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	"bcain@codeaurora.org" <bcain@codeaurora.org>,
	"deller@gmx.de" <deller@gmx.de>,
	"x86@kernel.org" <x86@kernel.org>,
	linux
Subject: Re: [PATCH v2 00/18] clean up asm/uaccess.h, kill set_fs for good
Date: Thu, 17 Feb 2022 07:20:11 +0000	[thread overview]
Message-ID: <00496df2-f9f2-2547-3ca3-7989e4713d6b@csgroup.eu> (raw)
In-Reply-To: <20220216131332.1489939-1-arnd@kernel.org>



Le 16/02/2022 à 14:13, Arnd Bergmann a écrit :
> From: Arnd Bergmann <arnd@arndb.de>
> 
> Christoph Hellwig and a few others spent a huge effort on removing
> set_fs() from most of the important architectures, but about half the
> other architectures were never completed even though most of them don't
> actually use set_fs() at all.
> 
> I did a patch for microblaze at some point, which turned out to be fairly
> generic, and now ported it to most other architectures, using new generic
> implementations of access_ok() and __{get,put}_kernel_nocheck().
> 
> Three architectures (sparc64, ia64, and sh) needed some extra work,
> which I also completed.
> 
> The final series contains extra cleanup changes that touch all
> architectures. Please review and test these, so we can merge them
> for v5.18.

As a further cleanup, have you thought about making a generic version of 
clear_user() ? On almost all architectures, clear_user() does an 
access_ok() then calls __clear_user() or similar.

Maybe also the same with put_user() and get_user() ? After all it is 
just access_ok() followed by __put_user() or __get_user() ? It seems 
more tricky though, as some architectures seems to have less trivial 
stuff there.

I also see all architectures have a prototype for strncpy_from_user() 
and strnlen_user(). Could be a common prototype instead when we have 
GENERIC_STRNCPY_FROM_USER / GENERIC_STRNLEN_USER

And we have also 
user_access_begin()/user_read_access_begin()/user_write_access_begin() 
which call access_ok() then do the real work. Could be made generic with 
call to some arch specific __user_access_begin() and friends after the 
access_ok() and eventually the might_fault().

Christophe

  parent reply	other threads:[~2022-02-17  7:20 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 ` 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 ` [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   ` 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 ` [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   ` 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: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     ` 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-25  4:28   ` Dinh Nguyen
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-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   ` 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-18  6:25   ` Christoph Hellwig
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-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   ` [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 ` [PATCH v2 05/18] x86: remove __range_not_ok() Arnd Bergmann
2022-02-16 13:13   ` 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-18  6:28   ` Christoph Hellwig
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  7:29     ` Arnd Bergmann
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 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   ` 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-18  6:29   ` Christoph Hellwig
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-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   ` 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-18  6:29   ` Christoph Hellwig
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-23 23:30   ` Dinh Nguyen
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-24  7:05     ` Arnd Bergmann
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-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   ` [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-18  6:30   ` Christoph Hellwig
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  8:55   ` Geert Uytterhoeven
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-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   ` 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-21 13:24   ` Thomas Bogendoerfer
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 14:31     ` Arnd Bergmann
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 15:21       ` Thomas Bogendoerfer
2022-02-21 15:21         ` Thomas Bogendoerfer
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-22 16:36       ` 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-23 20:05     ` Linus Torvalds
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  7:41   ` Thomas Bogendoerfer
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  9:26     ` Arnd Bergmann
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-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   ` 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-18  6:30   ` Christoph Hellwig
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  9:00   ` Geert Uytterhoeven
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:24     ` Arnd Bergmann
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-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   ` 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 ` [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   ` 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-18  6:31   ` Christoph Hellwig
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-25  4:30   ` Dinh Nguyen
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-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   ` 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-17  7:52   ` 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 19:15   ` Andy Lutomirski
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-18  7:16     ` Arnd Bergmann
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  9:30     ` David Laight
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 18:07       ` Andy Lutomirski
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  6:34   ` Christoph Hellwig
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  7:23     ` Arnd Bergmann
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  9:04   ` Geert Uytterhoeven
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-24  8:29   ` Stafford Horne
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:41     ` Arnd Bergmann
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-25  4:31   ` Dinh Nguyen
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-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   ` 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-18  6:35   ` Christoph Hellwig
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  7:15     ` Arnd Bergmann
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-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   ` 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 18:34   ` Sam Ravnborg
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:41     ` 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 22:01       ` Arnd Bergmann
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 13:13 ` [PATCH v2 16/18] sh: " Arnd Bergmann
2022-02-16 13:13   ` 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-18  6:36   ` Christoph Hellwig
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-16 13:13 ` [PATCH v2 17/18] ia64: " Arnd Bergmann
2022-02-16 13:13   ` 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 ` [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   ` 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 18:44   ` Sam Ravnborg
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 22:02     ` Arnd Bergmann
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-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     ` [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-18  6:37   ` Christoph Hellwig
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  7:10     ` Arnd Bergmann
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 10:18   ` Sergey Matyukevich
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-24  8:45   ` Stafford Horne
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-25  4:33   ` Dinh Nguyen
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-17  7:20 ` Christophe Leroy [this message]
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:49   ` Arnd Bergmann
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-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         ` 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  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       ` 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-17  8:13 ` Arnd Bergmann
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

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=00496df2-f9f2-2547-3ca3-7989e4713d6b@csgroup.eu \
    --to=christophe.leroy@csgroup.eu \
    --cc=akpm@linux-foundation.org \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=arnd@kernel.org \
    --cc=bcain@codeaurora.org \
    --cc=dalias@libc.org \
    --cc=davem@davemloft.net \
    --cc=deller@gmx.de \
    --cc=dinguyen@kernel.org \
    --cc=ebiederm@xmission.com \
    --cc=geert@linux-m68k.org \
    --cc=green.hu@gmail.com \
    --cc=guoren@kernel.org \
    --cc=hca@linux.ibm.com \
    --cc=hch@lst.de \
    --cc=jcmvbkbc@gmail.com \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-csky@vger.kernel.org \
    --cc=linux-hexagon@vger.kernel.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux-snps-arc@lists.infradead.org \
    --cc=linux-um@lists.infradead.org \
    --cc=linux-xtensa@linux-xtensa.org \
    --cc=linux@armlinux.org.uk \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=monstr@monstr.eu \
    --cc=nickhu@andestech.com \
    --cc=openrisc@lists.librecores.org \
    --cc=peterz@infradead.org \
    --cc=richard@nod.at \
    --cc=shorne@gmail.com \
    --cc=sparclinux@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=tsbogend@alpha.franken.de \
    --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.