From: David Laight <David.Laight@ACULAB.COM>
To: 'Ard Biesheuvel' <ardb@kernel.org>, Arnd Bergmann <arnd@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
Rich Felker <dalias@libc.org>,
"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
"open list:MIPS" <linux-mips@vger.kernel.org>,
Linux Memory Management List <linux-mm@kvack.org>,
Guo Ren <guoren@kernel.org>,
"open list:SPARC + UltraSPARC (sparc/sparc64)"
<sparclinux@vger.kernel.org>,
"linux-hexagon@vger.kernel.org" <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>,
"open list:S390" <linux-s390@vger.kernel.org>,
Brian Cain <bcain@codeaurora.org>, Helge Deller <deller@gmx.de>,
X86 ML <x8>
Subject: RE: [PATCH 08/14] arm64: simplify access_ok()
Date: Tue, 15 Feb 2022 09:30:41 +0000 [thread overview]
Message-ID: <153bb1887f484ed79ce8224845a4b2ea@AcuMS.aculab.com> (raw)
In-Reply-To: <CAMj1kXHixUFjV=4m3tzfGz7AiRWc-VczymbKuZq7dyZZNuLKxQ@mail.gmail.com>
From: Ard Biesheuvel
> Sent: 15 February 2022 08:18
>
> On Mon, 14 Feb 2022 at 17:37, Arnd Bergmann <arnd@kernel.org> wrote:
> >
> > From: Arnd Bergmann <arnd@arndb.de>
> >
> > arm64 has an inline asm implementation of access_ok() that is derived from
> > the 32-bit arm version and optimized for the case that both the limit and
> > the size are variable. With set_fs() gone, the limit is always constant,
> > and the size usually is as well, so just using the default implementation
> > reduces the check into a comparison against a constant that can be
> > scheduled by the compiler.
> >
> > On a defconfig build, this saves over 28KB of .text.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > arch/arm64/include/asm/uaccess.h | 28 +++++-----------------------
> > 1 file changed, 5 insertions(+), 23 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
> > index 357f7bd9c981..e8dce0cc5eaa 100644
> > --- a/arch/arm64/include/asm/uaccess.h
> > +++ b/arch/arm64/include/asm/uaccess.h
> > @@ -26,6 +26,8 @@
> > #include <asm/memory.h>
> > #include <asm/extable.h>
> >
> > +static inline int __access_ok(const void __user *ptr, unsigned long size);
> > +
> > /*
> > * Test whether a block of memory is a valid user space address.
> > * Returns 1 if the range is valid, 0 otherwise.
> > @@ -33,10 +35,8 @@
> > * This is equivalent to the following test:
> > * (u65)addr + (u65)size <= (u65)TASK_SIZE_MAX
> > */
> > -static inline unsigned long __access_ok(const void __user *addr, unsigned long size)
> > +static inline int access_ok(const void __user *addr, unsigned long size)
> > {
> > - unsigned long ret, limit = TASK_SIZE_MAX - 1;
> > -
> > /*
> > * Asynchronous I/O running in a kernel thread does not have the
> > * TIF_TAGGED_ADDR flag of the process owning the mm, so always untag
> > @@ -46,27 +46,9 @@ static inline unsigned long __access_ok(const void __user *addr, unsigned long s
> > (current->flags & PF_KTHREAD || test_thread_flag(TIF_TAGGED_ADDR)))
> > addr = untagged_addr(addr);
> >
> > - __chk_user_ptr(addr);
> > - asm volatile(
> > - // A + B <= C + 1 for all A,B,C, in four easy steps:
> > - // 1: X = A + B; X' = X % 2^64
> > - " adds %0, %3, %2\n"
> > - // 2: Set C = 0 if X > 2^64, to guarantee X' > C in step 4
> > - " csel %1, xzr, %1, hi\n"
> > - // 3: Set X' = ~0 if X >= 2^64. For X == 2^64, this decrements X'
> > - // to compensate for the carry flag being set in step 4. For
> > - // X > 2^64, X' merely has to remain nonzero, which it does.
> > - " csinv %0, %0, xzr, cc\n"
> > - // 4: For X < 2^64, this gives us X' - C - 1 <= 0, where the -1
> > - // comes from the carry in being clear. Otherwise, we are
> > - // testing X' - C == 0, subject to the previous adjustments.
> > - " sbcs xzr, %0, %1\n"
> > - " cset %0, ls\n"
> > - : "=&r" (ret), "+r" (limit) : "Ir" (size), "0" (addr) : "cc");
> > -
> > - return ret;
> > + return likely(__access_ok(addr, size));
> > }
> > -#define __access_ok __access_ok
> > +#define access_ok access_ok
> >
> > #include <asm-generic/access_ok.h>
> >
> > --
> > 2.29.2
> >
>
> With set_fs() out of the picture, wouldn't it be sufficient to check
> that bit #55 is clear? (the bit that selects between TTBR0 and TTBR1)
> That would also remove the need to strip the tag from the address.
>
> Something like
>
> asm goto("tbnz %0, #55, %2 \n"
> "tbnz %1, #55, %2 \n"
> :: "r"(addr), "r"(addr + size - 1) :: notok);
> return 1;
> notok:
> return 0;
>
> with an additional sanity check on the size which the compiler could
> eliminate for compile-time constant values.
Is there are reason not to just use:
size < 1u << 48 && !((addr | (addr + size - 1)) & 1u << 55)
(The -1 can be removed if the last user page is never mapped)
Ugg, is arm64 addressing as horrid as it looks - with the 'kernel'
bit in the middle of the virtual address space?
It seems to be:
<zero:4><tag:4><kernel:1><ignored:7><address:48>
Although I found some references to 44 bit VA and to code using the
'ignored' bits as tags - relying on the hardware ignoring them.
There might be some feature that uses the top 4 bits as well.
Another option is assuming that accesses are 'reasonably sequential',
removing the length check and ensuring there is an unmapped page
between valid user and kernel addresses.
That probably requires and unmapped page at the bottom of kernel space
which may not be achievable.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
WARNING: multiple messages have this Message-ID (diff)
From: David Laight <David.Laight@ACULAB.COM>
To: 'Ard Biesheuvel' <ardb@kernel.org>, Arnd Bergmann <arnd@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
Rich Felker <dalias@libc.org>,
"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
"open list:MIPS" <linux-mips@vger.kernel.org>,
"Linux Memory Management List" <linux-mm@kvack.org>,
Guo Ren <guoren@kernel.org>,
"open list:SPARC + UltraSPARC (sparc/sparc64)"
<sparclinux@vger.kernel.org>,
"linux-hexagon@vger.kernel.org" <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>,
"open list:S390" <linux-s390@vger.kernel.org>,
Brian Cain <bcain@codeaurora.org>, Helge Deller <deller@gmx.de>,
X86 ML <x86@kernel.org>, Russell King <linux@armlinux.org.uk>,
"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
Ingo Molnar <mingo@redhat.com>,
"Geert Uytterhoeven" <geert@linux-m68k.org>,
"linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>,
Robin Murphy <robin.murphy@arm.com>,
"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>,
"open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)"
<linuxppc-dev@lists.ozlabs.org>,
linux-m68k <linux-m68k@lists.linux-m68k.org>,
"openrisc@lists.librecores.org" <openrisc@lists.librecores.org>,
Greentime Hu <green.hu@gmail.com>,
"Stafford Horne" <shorne@gmail.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
"monstr@monstr.eu" <monstr@monstr.eu>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
"open list:PARISC ARCHITECTURE" <linux-parisc@vger.kernel.org>,
Nick Hu <nickhu@andestech.com>, Max Filippov <jcmvbkbc@gmail.com>,
"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"dinguyen@kernel.org" <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 S. Miller" <davem@davemloft.net>
Subject: RE: [PATCH 08/14] arm64: simplify access_ok()
Date: Tue, 15 Feb 2022 09:30:41 +0000 [thread overview]
Message-ID: <153bb1887f484ed79ce8224845a4b2ea@AcuMS.aculab.com> (raw)
In-Reply-To: <CAMj1kXHixUFjV=4m3tzfGz7AiRWc-VczymbKuZq7dyZZNuLKxQ@mail.gmail.com>
From: Ard Biesheuvel
> Sent: 15 February 2022 08:18
>
> On Mon, 14 Feb 2022 at 17:37, Arnd Bergmann <arnd@kernel.org> wrote:
> >
> > From: Arnd Bergmann <arnd@arndb.de>
> >
> > arm64 has an inline asm implementation of access_ok() that is derived from
> > the 32-bit arm version and optimized for the case that both the limit and
> > the size are variable. With set_fs() gone, the limit is always constant,
> > and the size usually is as well, so just using the default implementation
> > reduces the check into a comparison against a constant that can be
> > scheduled by the compiler.
> >
> > On a defconfig build, this saves over 28KB of .text.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > arch/arm64/include/asm/uaccess.h | 28 +++++-----------------------
> > 1 file changed, 5 insertions(+), 23 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
> > index 357f7bd9c981..e8dce0cc5eaa 100644
> > --- a/arch/arm64/include/asm/uaccess.h
> > +++ b/arch/arm64/include/asm/uaccess.h
> > @@ -26,6 +26,8 @@
> > #include <asm/memory.h>
> > #include <asm/extable.h>
> >
> > +static inline int __access_ok(const void __user *ptr, unsigned long size);
> > +
> > /*
> > * Test whether a block of memory is a valid user space address.
> > * Returns 1 if the range is valid, 0 otherwise.
> > @@ -33,10 +35,8 @@
> > * This is equivalent to the following test:
> > * (u65)addr + (u65)size <= (u65)TASK_SIZE_MAX
> > */
> > -static inline unsigned long __access_ok(const void __user *addr, unsigned long size)
> > +static inline int access_ok(const void __user *addr, unsigned long size)
> > {
> > - unsigned long ret, limit = TASK_SIZE_MAX - 1;
> > -
> > /*
> > * Asynchronous I/O running in a kernel thread does not have the
> > * TIF_TAGGED_ADDR flag of the process owning the mm, so always untag
> > @@ -46,27 +46,9 @@ static inline unsigned long __access_ok(const void __user *addr, unsigned long s
> > (current->flags & PF_KTHREAD || test_thread_flag(TIF_TAGGED_ADDR)))
> > addr = untagged_addr(addr);
> >
> > - __chk_user_ptr(addr);
> > - asm volatile(
> > - // A + B <= C + 1 for all A,B,C, in four easy steps:
> > - // 1: X = A + B; X' = X % 2^64
> > - " adds %0, %3, %2\n"
> > - // 2: Set C = 0 if X > 2^64, to guarantee X' > C in step 4
> > - " csel %1, xzr, %1, hi\n"
> > - // 3: Set X' = ~0 if X >= 2^64. For X == 2^64, this decrements X'
> > - // to compensate for the carry flag being set in step 4. For
> > - // X > 2^64, X' merely has to remain nonzero, which it does.
> > - " csinv %0, %0, xzr, cc\n"
> > - // 4: For X < 2^64, this gives us X' - C - 1 <= 0, where the -1
> > - // comes from the carry in being clear. Otherwise, we are
> > - // testing X' - C == 0, subject to the previous adjustments.
> > - " sbcs xzr, %0, %1\n"
> > - " cset %0, ls\n"
> > - : "=&r" (ret), "+r" (limit) : "Ir" (size), "0" (addr) : "cc");
> > -
> > - return ret;
> > + return likely(__access_ok(addr, size));
> > }
> > -#define __access_ok __access_ok
> > +#define access_ok access_ok
> >
> > #include <asm-generic/access_ok.h>
> >
> > --
> > 2.29.2
> >
>
> With set_fs() out of the picture, wouldn't it be sufficient to check
> that bit #55 is clear? (the bit that selects between TTBR0 and TTBR1)
> That would also remove the need to strip the tag from the address.
>
> Something like
>
> asm goto("tbnz %0, #55, %2 \n"
> "tbnz %1, #55, %2 \n"
> :: "r"(addr), "r"(addr + size - 1) :: notok);
> return 1;
> notok:
> return 0;
>
> with an additional sanity check on the size which the compiler could
> eliminate for compile-time constant values.
Is there are reason not to just use:
size < 1u << 48 && !((addr | (addr + size - 1)) & 1u << 55)
(The -1 can be removed if the last user page is never mapped)
Ugg, is arm64 addressing as horrid as it looks - with the 'kernel'
bit in the middle of the virtual address space?
It seems to be:
<zero:4><tag:4><kernel:1><ignored:7><address:48>
Although I found some references to 44 bit VA and to code using the
'ignored' bits as tags - relying on the hardware ignoring them.
There might be some feature that uses the top 4 bits as well.
Another option is assuming that accesses are 'reasonably sequential',
removing the length check and ensuring there is an unmapped page
between valid user and kernel addresses.
That probably requires and unmapped page at the bottom of kernel space
which may not be achievable.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
WARNING: multiple messages have this Message-ID (diff)
From: David Laight <David.Laight@ACULAB.COM>
To: 'Ard Biesheuvel' <ardb@kernel.org>, Arnd Bergmann <arnd@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
Rich Felker <dalias@libc.org>,
"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
"open list:MIPS" <linux-mips@vger.kernel.org>,
Linux Memory Management List <linux-mm@kvack.org>,
Guo Ren <guoren@kernel.org>,
"open list:SPARC + UltraSPARC (sparc/sparc64)"
<sparclinux@vger.kernel.org>,
"linux-hexagon@vger.kernel.org" <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>,
"open list:S390" <linux-s390@vger.kernel.org>,
Brian Cain <bcain@codeaurora.org>, Helge Deller <deller@gmx.de>,
X86 ML <x86@kernel.org>, Russell King <linux@armlinux.org.uk>,
"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
Ingo Molnar <mingo@redhat.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
"linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>,
Robin Murphy <robin.murphy@arm.com>,
"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>,
"open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)"
<linuxppc-dev@lists.ozlabs.org>,
linux-m68k <linux-m68k@lists.linux-m68k.org>,
"openrisc@lists.librecores.org" <openrisc@lists.librecores.org>,
Greentime Hu <green.hu@gmail.com>,
Stafford Horne <shorne@gmail.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
"monstr@monstr.eu" <monstr@monstr.eu>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
"open list:PARISC ARCHITECTURE" <linux-parisc@vger.kernel.org>,
Nick Hu <nickhu@andestech.com>, Max Filippov <jcmvbkbc@gmail.com>,
"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"dinguyen@kernel.org" <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 S. Miller" <davem@davemloft.net>
Subject: RE: [PATCH 08/14] arm64: simplify access_ok()
Date: Tue, 15 Feb 2022 09:30:41 +0000 [thread overview]
Message-ID: <153bb1887f484ed79ce8224845a4b2ea@AcuMS.aculab.com> (raw)
In-Reply-To: <CAMj1kXHixUFjV=4m3tzfGz7AiRWc-VczymbKuZq7dyZZNuLKxQ@mail.gmail.com>
RnJvbTogQXJkIEJpZXNoZXV2ZWwNCj4gU2VudDogMTUgRmVicnVhcnkgMjAyMiAwODoxOA0KPiAN
Cj4gT24gTW9uLCAxNCBGZWIgMjAyMiBhdCAxNzozNywgQXJuZCBCZXJnbWFubiA8YXJuZEBrZXJu
ZWwub3JnPiB3cm90ZToNCj4gPg0KPiA+IEZyb206IEFybmQgQmVyZ21hbm4gPGFybmRAYXJuZGIu
ZGU+DQo+ID4NCj4gPiBhcm02NCBoYXMgYW4gaW5saW5lIGFzbSBpbXBsZW1lbnRhdGlvbiBvZiBh
Y2Nlc3Nfb2soKSB0aGF0IGlzIGRlcml2ZWQgZnJvbQ0KPiA+IHRoZSAzMi1iaXQgYXJtIHZlcnNp
b24gYW5kIG9wdGltaXplZCBmb3IgdGhlIGNhc2UgdGhhdCBib3RoIHRoZSBsaW1pdCBhbmQNCj4g
PiB0aGUgc2l6ZSBhcmUgdmFyaWFibGUuIFdpdGggc2V0X2ZzKCkgZ29uZSwgdGhlIGxpbWl0IGlz
IGFsd2F5cyBjb25zdGFudCwNCj4gPiBhbmQgdGhlIHNpemUgdXN1YWxseSBpcyBhcyB3ZWxsLCBz
byBqdXN0IHVzaW5nIHRoZSBkZWZhdWx0IGltcGxlbWVudGF0aW9uDQo+ID4gcmVkdWNlcyB0aGUg
Y2hlY2sgaW50byBhIGNvbXBhcmlzb24gYWdhaW5zdCBhIGNvbnN0YW50IHRoYXQgY2FuIGJlDQo+
ID4gc2NoZWR1bGVkIGJ5IHRoZSBjb21waWxlci4NCj4gPg0KPiA+IE9uIGEgZGVmY29uZmlnIGJ1
aWxkLCB0aGlzIHNhdmVzIG92ZXIgMjhLQiBvZiAudGV4dC4NCj4gPg0KPiA+IFNpZ25lZC1vZmYt
Ynk6IEFybmQgQmVyZ21hbm4gPGFybmRAYXJuZGIuZGU+DQo+ID4gLS0tDQo+ID4gIGFyY2gvYXJt
NjQvaW5jbHVkZS9hc20vdWFjY2Vzcy5oIHwgMjggKysrKystLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQ0KPiA+ICAxIGZpbGUgY2hhbmdlZCwgNSBpbnNlcnRpb25zKCspLCAyMyBkZWxldGlvbnMoLSkN
Cj4gPg0KPiA+IGRpZmYgLS1naXQgYS9hcmNoL2FybTY0L2luY2x1ZGUvYXNtL3VhY2Nlc3MuaCBi
L2FyY2gvYXJtNjQvaW5jbHVkZS9hc20vdWFjY2Vzcy5oDQo+ID4gaW5kZXggMzU3ZjdiZDljOTgx
Li5lOGRjZTBjYzVlYWEgMTAwNjQ0DQo+ID4gLS0tIGEvYXJjaC9hcm02NC9pbmNsdWRlL2FzbS91
YWNjZXNzLmgNCj4gPiArKysgYi9hcmNoL2FybTY0L2luY2x1ZGUvYXNtL3VhY2Nlc3MuaA0KPiA+
IEBAIC0yNiw2ICsyNiw4IEBADQo+ID4gICNpbmNsdWRlIDxhc20vbWVtb3J5Lmg+DQo+ID4gICNp
bmNsdWRlIDxhc20vZXh0YWJsZS5oPg0KPiA+DQo+ID4gK3N0YXRpYyBpbmxpbmUgaW50IF9fYWNj
ZXNzX29rKGNvbnN0IHZvaWQgX191c2VyICpwdHIsIHVuc2lnbmVkIGxvbmcgc2l6ZSk7DQo+ID4g
Kw0KPiA+ICAvKg0KPiA+ICAgKiBUZXN0IHdoZXRoZXIgYSBibG9jayBvZiBtZW1vcnkgaXMgYSB2
YWxpZCB1c2VyIHNwYWNlIGFkZHJlc3MuDQo+ID4gICAqIFJldHVybnMgMSBpZiB0aGUgcmFuZ2Ug
aXMgdmFsaWQsIDAgb3RoZXJ3aXNlLg0KPiA+IEBAIC0zMywxMCArMzUsOCBAQA0KPiA+ICAgKiBU
aGlzIGlzIGVxdWl2YWxlbnQgdG8gdGhlIGZvbGxvd2luZyB0ZXN0Og0KPiA+ICAgKiAodTY1KWFk
ZHIgKyAodTY1KXNpemUgPD0gKHU2NSlUQVNLX1NJWkVfTUFYDQo+ID4gICAqLw0KPiA+IC1zdGF0
aWMgaW5saW5lIHVuc2lnbmVkIGxvbmcgX19hY2Nlc3Nfb2soY29uc3Qgdm9pZCBfX3VzZXIgKmFk
ZHIsIHVuc2lnbmVkIGxvbmcgc2l6ZSkNCj4gPiArc3RhdGljIGlubGluZSBpbnQgYWNjZXNzX29r
KGNvbnN0IHZvaWQgX191c2VyICphZGRyLCB1bnNpZ25lZCBsb25nIHNpemUpDQo+ID4gIHsNCj4g
PiAtICAgICAgIHVuc2lnbmVkIGxvbmcgcmV0LCBsaW1pdCA9IFRBU0tfU0laRV9NQVggLSAxOw0K
PiA+IC0NCj4gPiAgICAgICAgIC8qDQo+ID4gICAgICAgICAgKiBBc3luY2hyb25vdXMgSS9PIHJ1
bm5pbmcgaW4gYSBrZXJuZWwgdGhyZWFkIGRvZXMgbm90IGhhdmUgdGhlDQo+ID4gICAgICAgICAg
KiBUSUZfVEFHR0VEX0FERFIgZmxhZyBvZiB0aGUgcHJvY2VzcyBvd25pbmcgdGhlIG1tLCBzbyBh
bHdheXMgdW50YWcNCj4gPiBAQCAtNDYsMjcgKzQ2LDkgQEAgc3RhdGljIGlubGluZSB1bnNpZ25l
ZCBsb25nIF9fYWNjZXNzX29rKGNvbnN0IHZvaWQgX191c2VyICphZGRyLCB1bnNpZ25lZCBsb25n
IHMNCj4gPiAgICAgICAgICAgICAoY3VycmVudC0+ZmxhZ3MgJiBQRl9LVEhSRUFEIHx8IHRlc3Rf
dGhyZWFkX2ZsYWcoVElGX1RBR0dFRF9BRERSKSkpDQo+ID4gICAgICAgICAgICAgICAgIGFkZHIg
PSB1bnRhZ2dlZF9hZGRyKGFkZHIpOw0KPiA+DQo+ID4gLSAgICAgICBfX2Noa191c2VyX3B0cihh
ZGRyKTsNCj4gPiAtICAgICAgIGFzbSB2b2xhdGlsZSgNCj4gPiAtICAgICAgIC8vIEEgKyBCIDw9
IEMgKyAxIGZvciBhbGwgQSxCLEMsIGluIGZvdXIgZWFzeSBzdGVwczoNCj4gPiAtICAgICAgIC8v
IDE6IFggPSBBICsgQjsgWCcgPSBYICUgMl42NA0KPiA+IC0gICAgICAgIiAgICAgICBhZGRzICAg
ICUwLCAlMywgJTJcbiINCj4gPiAtICAgICAgIC8vIDI6IFNldCBDID0gMCBpZiBYID4gMl42NCwg
dG8gZ3VhcmFudGVlIFgnID4gQyBpbiBzdGVwIDQNCj4gPiAtICAgICAgICIgICAgICAgY3NlbCAg
ICAlMSwgeHpyLCAlMSwgaGlcbiINCj4gPiAtICAgICAgIC8vIDM6IFNldCBYJyA9IH4wIGlmIFgg
Pj0gMl42NC4gRm9yIFggPT0gMl42NCwgdGhpcyBkZWNyZW1lbnRzIFgnDQo+ID4gLSAgICAgICAv
LyAgICB0byBjb21wZW5zYXRlIGZvciB0aGUgY2FycnkgZmxhZyBiZWluZyBzZXQgaW4gc3RlcCA0
LiBGb3INCj4gPiAtICAgICAgIC8vICAgIFggPiAyXjY0LCBYJyBtZXJlbHkgaGFzIHRvIHJlbWFp
biBub256ZXJvLCB3aGljaCBpdCBkb2VzLg0KPiA+IC0gICAgICAgIiAgICAgICBjc2ludiAgICUw
LCAlMCwgeHpyLCBjY1xuIg0KPiA+IC0gICAgICAgLy8gNDogRm9yIFggPCAyXjY0LCB0aGlzIGdp
dmVzIHVzIFgnIC0gQyAtIDEgPD0gMCwgd2hlcmUgdGhlIC0xDQo+ID4gLSAgICAgICAvLyAgICBj
b21lcyBmcm9tIHRoZSBjYXJyeSBpbiBiZWluZyBjbGVhci4gT3RoZXJ3aXNlLCB3ZSBhcmUNCj4g
PiAtICAgICAgIC8vICAgIHRlc3RpbmcgWCcgLSBDID09IDAsIHN1YmplY3QgdG8gdGhlIHByZXZp
b3VzIGFkanVzdG1lbnRzLg0KPiA+IC0gICAgICAgIiAgICAgICBzYmNzICAgIHh6ciwgJTAsICUx
XG4iDQo+ID4gLSAgICAgICAiICAgICAgIGNzZXQgICAgJTAsIGxzXG4iDQo+ID4gLSAgICAgICA6
ICI9JnIiIChyZXQpLCAiK3IiIChsaW1pdCkgOiAiSXIiIChzaXplKSwgIjAiIChhZGRyKSA6ICJj
YyIpOw0KPiA+IC0NCj4gPiAtICAgICAgIHJldHVybiByZXQ7DQo+ID4gKyAgICAgICByZXR1cm4g
bGlrZWx5KF9fYWNjZXNzX29rKGFkZHIsIHNpemUpKTsNCj4gPiAgfQ0KPiA+IC0jZGVmaW5lIF9f
YWNjZXNzX29rIF9fYWNjZXNzX29rDQo+ID4gKyNkZWZpbmUgYWNjZXNzX29rIGFjY2Vzc19vaw0K
PiA+DQo+ID4gICNpbmNsdWRlIDxhc20tZ2VuZXJpYy9hY2Nlc3Nfb2suaD4NCj4gPg0KPiA+IC0t
DQo+ID4gMi4yOS4yDQo+ID4NCj4gDQo+IFdpdGggc2V0X2ZzKCkgb3V0IG9mIHRoZSBwaWN0dXJl
LCB3b3VsZG4ndCBpdCBiZSBzdWZmaWNpZW50IHRvIGNoZWNrDQo+IHRoYXQgYml0ICM1NSBpcyBj
bGVhcj8gKHRoZSBiaXQgdGhhdCBzZWxlY3RzIGJldHdlZW4gVFRCUjAgYW5kIFRUQlIxKQ0KPiBU
aGF0IHdvdWxkIGFsc28gcmVtb3ZlIHRoZSBuZWVkIHRvIHN0cmlwIHRoZSB0YWcgZnJvbSB0aGUg
YWRkcmVzcy4NCj4gDQo+IFNvbWV0aGluZyBsaWtlDQo+IA0KPiAgICAgYXNtIGdvdG8oInRibnog
ICUwLCAjNTUsICUyICAgICBcbiINCj4gICAgICAgICAgICAgICJ0Ym56ICAlMSwgIzU1LCAlMiAg
ICAgXG4iDQo+ICAgICAgICAgICAgICA6OiAiciIoYWRkciksICJyIihhZGRyICsgc2l6ZSAtIDEp
IDo6IG5vdG9rKTsNCj4gICAgIHJldHVybiAxOw0KPiBub3RvazoNCj4gICAgIHJldHVybiAwOw0K
PiANCj4gd2l0aCBhbiBhZGRpdGlvbmFsIHNhbml0eSBjaGVjayBvbiB0aGUgc2l6ZSB3aGljaCB0
aGUgY29tcGlsZXIgY291bGQNCj4gZWxpbWluYXRlIGZvciBjb21waWxlLXRpbWUgY29uc3RhbnQg
dmFsdWVzLg0KDQpJcyB0aGVyZSBhcmUgcmVhc29uIG5vdCB0byBqdXN0IHVzZToNCglzaXplIDwg
MXUgPDwgNDggJiYgISgoYWRkciB8IChhZGRyICsgc2l6ZSAtIDEpKSAmIDF1IDw8IDU1KQ0KDQoo
VGhlIC0xIGNhbiBiZSByZW1vdmVkIGlmIHRoZSBsYXN0IHVzZXIgcGFnZSBpcyBuZXZlciBtYXBw
ZWQpDQoNClVnZywgaXMgYXJtNjQgYWRkcmVzc2luZyBhcyBob3JyaWQgYXMgaXQgbG9va3MgLSB3
aXRoIHRoZSAna2VybmVsJw0KYml0IGluIHRoZSBtaWRkbGUgb2YgdGhlIHZpcnR1YWwgYWRkcmVz
cyBzcGFjZT8NCkl0IHNlZW1zIHRvIGJlOg0KCTx6ZXJvOjQ+PHRhZzo0PjxrZXJuZWw6MT48aWdu
b3JlZDo3PjxhZGRyZXNzOjQ4Pg0KQWx0aG91Z2ggSSBmb3VuZCBzb21lIHJlZmVyZW5jZXMgdG8g
NDQgYml0IFZBIGFuZCB0byBjb2RlIHVzaW5nIHRoZQ0KJ2lnbm9yZWQnIGJpdHMgYXMgdGFncyAt
IHJlbHlpbmcgb24gdGhlIGhhcmR3YXJlIGlnbm9yaW5nIHRoZW0uDQpUaGVyZSBtaWdodCBiZSBz
b21lIGZlYXR1cmUgdGhhdCB1c2VzIHRoZSB0b3AgNCBiaXRzIGFzIHdlbGwuDQoNCkFub3RoZXIg
b3B0aW9uIGlzIGFzc3VtaW5nIHRoYXQgYWNjZXNzZXMgYXJlICdyZWFzb25hYmx5IHNlcXVlbnRp
YWwnLA0KcmVtb3ZpbmcgdGhlIGxlbmd0aCBjaGVjayBhbmQgZW5zdXJpbmcgdGhlcmUgaXMgYW4g
dW5tYXBwZWQgcGFnZQ0KYmV0d2VlbiB2YWxpZCB1c2VyIGFuZCBrZXJuZWwgYWRkcmVzc2VzLg0K
VGhhdCBwcm9iYWJseSByZXF1aXJlcyBhbmQgdW5tYXBwZWQgcGFnZSBhdCB0aGUgYm90dG9tIG9m
IGtlcm5lbCBzcGFjZQ0Kd2hpY2ggbWF5IG5vdCBiZSBhY2hpZXZhYmxlLg0KDQoJRGF2aWQNCg0K
LQ0KUmVnaXN0ZXJlZCBBZGRyZXNzIExha2VzaWRlLCBCcmFtbGV5IFJvYWQsIE1vdW50IEZhcm0s
IE1pbHRvbiBLZXluZXMsIE1LMSAxUFQsIFVLDQpSZWdpc3RyYXRpb24gTm86IDEzOTczODYgKFdh
bGVzKQ0K
WARNING: multiple messages have this Message-ID (diff)
From: David Laight <David.Laight@ACULAB.COM>
To: 'Ard Biesheuvel' <ardb@kernel.org>, Arnd Bergmann <arnd@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
Rich Felker <dalias@libc.org>,
"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
"open list:MIPS" <linux-mips@vger.kernel.org>,
"Linux Memory Management List" <linux-mm@kvack.org>,
Guo Ren <guoren@kernel.org>,
"open list:SPARC + UltraSPARC (sparc/sparc64)"
<sparclinux@vger.kernel.org>,
"linux-hexagon@vger.kernel.org" <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>,
"open list:S390" <linux-s390@vger.kernel.org>,
Brian Cain <bcain@codeaurora.org>, Helge Deller <deller@gmx.de>,
X86 ML <x86@kernel.org>, Russell King <linux@armlinux.org.uk>,
"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
Ingo Molnar <mingo@redhat.com>,
"Geert Uytterhoeven" <geert@linux-m68k.org>,
"linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>,
Robin Murphy <robin.murphy@arm.com>,
"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>,
"open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)"
<linuxppc-dev@lists.ozlabs.org>,
linux-m68k <linux-m68k@lists.linux-m68k.org>,
"openrisc@lists.librecores.org" <openrisc@lists.librecores.org>,
Greentime Hu <green.hu@gmail.com>,
"Stafford Horne" <shorne@gmail.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
"monstr@monstr.eu" <monstr@monstr.eu>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
"open list:PARISC ARCHITECTURE" <linux-parisc@vger.kernel.org>,
Nick Hu <nickhu@andestech.com>, Max Filippov <jcmvbkbc@gmail.com>,
"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"dinguyen@kernel.org" <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 S. Miller" <davem@davemloft.net>
Subject: RE: [PATCH 08/14] arm64: simplify access_ok()
Date: Tue, 15 Feb 2022 09:30:41 +0000 [thread overview]
Message-ID: <153bb1887f484ed79ce8224845a4b2ea@AcuMS.aculab.com> (raw)
In-Reply-To: <CAMj1kXHixUFjV=4m3tzfGz7AiRWc-VczymbKuZq7dyZZNuLKxQ@mail.gmail.com>
From: Ard Biesheuvel
> Sent: 15 February 2022 08:18
>
> On Mon, 14 Feb 2022 at 17:37, Arnd Bergmann <arnd@kernel.org> wrote:
> >
> > From: Arnd Bergmann <arnd@arndb.de>
> >
> > arm64 has an inline asm implementation of access_ok() that is derived from
> > the 32-bit arm version and optimized for the case that both the limit and
> > the size are variable. With set_fs() gone, the limit is always constant,
> > and the size usually is as well, so just using the default implementation
> > reduces the check into a comparison against a constant that can be
> > scheduled by the compiler.
> >
> > On a defconfig build, this saves over 28KB of .text.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > arch/arm64/include/asm/uaccess.h | 28 +++++-----------------------
> > 1 file changed, 5 insertions(+), 23 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
> > index 357f7bd9c981..e8dce0cc5eaa 100644
> > --- a/arch/arm64/include/asm/uaccess.h
> > +++ b/arch/arm64/include/asm/uaccess.h
> > @@ -26,6 +26,8 @@
> > #include <asm/memory.h>
> > #include <asm/extable.h>
> >
> > +static inline int __access_ok(const void __user *ptr, unsigned long size);
> > +
> > /*
> > * Test whether a block of memory is a valid user space address.
> > * Returns 1 if the range is valid, 0 otherwise.
> > @@ -33,10 +35,8 @@
> > * This is equivalent to the following test:
> > * (u65)addr + (u65)size <= (u65)TASK_SIZE_MAX
> > */
> > -static inline unsigned long __access_ok(const void __user *addr, unsigned long size)
> > +static inline int access_ok(const void __user *addr, unsigned long size)
> > {
> > - unsigned long ret, limit = TASK_SIZE_MAX - 1;
> > -
> > /*
> > * Asynchronous I/O running in a kernel thread does not have the
> > * TIF_TAGGED_ADDR flag of the process owning the mm, so always untag
> > @@ -46,27 +46,9 @@ static inline unsigned long __access_ok(const void __user *addr, unsigned long s
> > (current->flags & PF_KTHREAD || test_thread_flag(TIF_TAGGED_ADDR)))
> > addr = untagged_addr(addr);
> >
> > - __chk_user_ptr(addr);
> > - asm volatile(
> > - // A + B <= C + 1 for all A,B,C, in four easy steps:
> > - // 1: X = A + B; X' = X % 2^64
> > - " adds %0, %3, %2\n"
> > - // 2: Set C = 0 if X > 2^64, to guarantee X' > C in step 4
> > - " csel %1, xzr, %1, hi\n"
> > - // 3: Set X' = ~0 if X >= 2^64. For X == 2^64, this decrements X'
> > - // to compensate for the carry flag being set in step 4. For
> > - // X > 2^64, X' merely has to remain nonzero, which it does.
> > - " csinv %0, %0, xzr, cc\n"
> > - // 4: For X < 2^64, this gives us X' - C - 1 <= 0, where the -1
> > - // comes from the carry in being clear. Otherwise, we are
> > - // testing X' - C == 0, subject to the previous adjustments.
> > - " sbcs xzr, %0, %1\n"
> > - " cset %0, ls\n"
> > - : "=&r" (ret), "+r" (limit) : "Ir" (size), "0" (addr) : "cc");
> > -
> > - return ret;
> > + return likely(__access_ok(addr, size));
> > }
> > -#define __access_ok __access_ok
> > +#define access_ok access_ok
> >
> > #include <asm-generic/access_ok.h>
> >
> > --
> > 2.29.2
> >
>
> With set_fs() out of the picture, wouldn't it be sufficient to check
> that bit #55 is clear? (the bit that selects between TTBR0 and TTBR1)
> That would also remove the need to strip the tag from the address.
>
> Something like
>
> asm goto("tbnz %0, #55, %2 \n"
> "tbnz %1, #55, %2 \n"
> :: "r"(addr), "r"(addr + size - 1) :: notok);
> return 1;
> notok:
> return 0;
>
> with an additional sanity check on the size which the compiler could
> eliminate for compile-time constant values.
Is there are reason not to just use:
size < 1u << 48 && !((addr | (addr + size - 1)) & 1u << 55)
(The -1 can be removed if the last user page is never mapped)
Ugg, is arm64 addressing as horrid as it looks - with the 'kernel'
bit in the middle of the virtual address space?
It seems to be:
<zero:4><tag:4><kernel:1><ignored:7><address:48>
Although I found some references to 44 bit VA and to code using the
'ignored' bits as tags - relying on the hardware ignoring them.
There might be some feature that uses the top 4 bits as well.
Another option is assuming that accesses are 'reasonably sequential',
removing the length check and ensuring there is an unmapped page
between valid user and kernel addresses.
That probably requires and unmapped page at the bottom of kernel space
which may not be achievable.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
_______________________________________________
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: David Laight <David.Laight@ACULAB.COM>
To: 'Ard Biesheuvel' <ardb@kernel.org>, Arnd Bergmann <arnd@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
Rich Felker <dalias@libc.org>,
"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
"open list:MIPS" <linux-mips@vger.kernel.org>,
"Linux Memory Management List" <linux-mm@kvack.org>,
Guo Ren <guoren@kernel.org>,
"open list:SPARC + UltraSPARC (sparc/sparc64)"
<sparclinux@vger.kernel.org>,
"linux-hexagon@vger.kernel.org" <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>,
"open list:S390" <linux-s390@vger.kernel.org>,
Brian Cain <bcain@codeaurora.org>, Helge Deller <deller@gmx.de>,
X86 ML <x86@kernel.org>, Russell King <linux@armlinux.org.uk>,
"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
Ingo Molnar <mingo@redhat.com>,
"Geert Uytterhoeven" <geert@linux-m68k.org>,
"linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>,
Robin Murphy <robin.murphy@arm.com>,
"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>,
"open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)"
<linuxppc-dev@lists.ozlabs.org>,
linux-m68k <linux-m68k@lists.linux-m68k.org>,
"openrisc@lists.librecores.org" <openrisc@lists.librecores.org>,
Greentime Hu <green.hu@gmail.com>,
"Stafford Horne" <shorne@gmail.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
"monstr@monstr.eu" <monstr@monstr.eu>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
"open list:PARISC ARCHITECTURE" <linux-parisc@vger.kernel.org>,
Nick Hu <nickhu@andestech.com>, Max Filippov <jcmvbkbc@gmail.com>,
"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"dinguyen@kernel.org" <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 S. Miller" <davem@davemloft.net>
Subject: RE: [PATCH 08/14] arm64: simplify access_ok()
Date: Tue, 15 Feb 2022 09:30:41 +0000 [thread overview]
Message-ID: <153bb1887f484ed79ce8224845a4b2ea@AcuMS.aculab.com> (raw)
In-Reply-To: <CAMj1kXHixUFjV=4m3tzfGz7AiRWc-VczymbKuZq7dyZZNuLKxQ@mail.gmail.com>
From: Ard Biesheuvel
> Sent: 15 February 2022 08:18
>
> On Mon, 14 Feb 2022 at 17:37, Arnd Bergmann <arnd@kernel.org> wrote:
> >
> > From: Arnd Bergmann <arnd@arndb.de>
> >
> > arm64 has an inline asm implementation of access_ok() that is derived from
> > the 32-bit arm version and optimized for the case that both the limit and
> > the size are variable. With set_fs() gone, the limit is always constant,
> > and the size usually is as well, so just using the default implementation
> > reduces the check into a comparison against a constant that can be
> > scheduled by the compiler.
> >
> > On a defconfig build, this saves over 28KB of .text.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > arch/arm64/include/asm/uaccess.h | 28 +++++-----------------------
> > 1 file changed, 5 insertions(+), 23 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
> > index 357f7bd9c981..e8dce0cc5eaa 100644
> > --- a/arch/arm64/include/asm/uaccess.h
> > +++ b/arch/arm64/include/asm/uaccess.h
> > @@ -26,6 +26,8 @@
> > #include <asm/memory.h>
> > #include <asm/extable.h>
> >
> > +static inline int __access_ok(const void __user *ptr, unsigned long size);
> > +
> > /*
> > * Test whether a block of memory is a valid user space address.
> > * Returns 1 if the range is valid, 0 otherwise.
> > @@ -33,10 +35,8 @@
> > * This is equivalent to the following test:
> > * (u65)addr + (u65)size <= (u65)TASK_SIZE_MAX
> > */
> > -static inline unsigned long __access_ok(const void __user *addr, unsigned long size)
> > +static inline int access_ok(const void __user *addr, unsigned long size)
> > {
> > - unsigned long ret, limit = TASK_SIZE_MAX - 1;
> > -
> > /*
> > * Asynchronous I/O running in a kernel thread does not have the
> > * TIF_TAGGED_ADDR flag of the process owning the mm, so always untag
> > @@ -46,27 +46,9 @@ static inline unsigned long __access_ok(const void __user *addr, unsigned long s
> > (current->flags & PF_KTHREAD || test_thread_flag(TIF_TAGGED_ADDR)))
> > addr = untagged_addr(addr);
> >
> > - __chk_user_ptr(addr);
> > - asm volatile(
> > - // A + B <= C + 1 for all A,B,C, in four easy steps:
> > - // 1: X = A + B; X' = X % 2^64
> > - " adds %0, %3, %2\n"
> > - // 2: Set C = 0 if X > 2^64, to guarantee X' > C in step 4
> > - " csel %1, xzr, %1, hi\n"
> > - // 3: Set X' = ~0 if X >= 2^64. For X == 2^64, this decrements X'
> > - // to compensate for the carry flag being set in step 4. For
> > - // X > 2^64, X' merely has to remain nonzero, which it does.
> > - " csinv %0, %0, xzr, cc\n"
> > - // 4: For X < 2^64, this gives us X' - C - 1 <= 0, where the -1
> > - // comes from the carry in being clear. Otherwise, we are
> > - // testing X' - C == 0, subject to the previous adjustments.
> > - " sbcs xzr, %0, %1\n"
> > - " cset %0, ls\n"
> > - : "=&r" (ret), "+r" (limit) : "Ir" (size), "0" (addr) : "cc");
> > -
> > - return ret;
> > + return likely(__access_ok(addr, size));
> > }
> > -#define __access_ok __access_ok
> > +#define access_ok access_ok
> >
> > #include <asm-generic/access_ok.h>
> >
> > --
> > 2.29.2
> >
>
> With set_fs() out of the picture, wouldn't it be sufficient to check
> that bit #55 is clear? (the bit that selects between TTBR0 and TTBR1)
> That would also remove the need to strip the tag from the address.
>
> Something like
>
> asm goto("tbnz %0, #55, %2 \n"
> "tbnz %1, #55, %2 \n"
> :: "r"(addr), "r"(addr + size - 1) :: notok);
> return 1;
> notok:
> return 0;
>
> with an additional sanity check on the size which the compiler could
> eliminate for compile-time constant values.
Is there are reason not to just use:
size < 1u << 48 && !((addr | (addr + size - 1)) & 1u << 55)
(The -1 can be removed if the last user page is never mapped)
Ugg, is arm64 addressing as horrid as it looks - with the 'kernel'
bit in the middle of the virtual address space?
It seems to be:
<zero:4><tag:4><kernel:1><ignored:7><address:48>
Although I found some references to 44 bit VA and to code using the
'ignored' bits as tags - relying on the hardware ignoring them.
There might be some feature that uses the top 4 bits as well.
Another option is assuming that accesses are 'reasonably sequential',
removing the length check and ensuring there is an unmapped page
between valid user and kernel addresses.
That probably requires and unmapped page at the bottom of kernel space
which may not be achievable.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
_______________________________________________
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: David Laight <David.Laight@ACULAB.COM>
To: 'Ard Biesheuvel' <ardb@kernel.org>, Arnd Bergmann <arnd@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
Rich Felker <dalias@libc.org>,
"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
"open list:MIPS" <linux-mips@vger.kernel.org>,
"Linux Memory Management List <linux-mm@kvack.org>,
Guo Ren <guoren@kernel.org>,
open list:SPARC + UltraSPARC (sparc/sparc64)"
<sparclinux@vger.kernel.org>,
"linux-hexagon@vger.kernel.org" <linux-hexagon@vger.kernel.org>,
linux-riscv <linux-riscv@lists.infradead.org>,
Will Deacon <will@kernel.org>,
"S390 <linux-s390@vger.kernel.org>,
Brian Cain <bcain@codeaurora.org>, Helge Deller" <deller@gmx.de>,
X86 ML <x86@kernel.org>, Russell King <linux@armlinux.org.uk>,
"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
Ingo Molnar <mingo@redhat.com>,
"Geert" Uytterhoeven" <geert@linux-m68k.org>,
"linux-snps-arc@lists.infradead.org,
linux-snps-arc@lists.infradead.org,
Robin Murphy <robin.murphy@arm.com>,
"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>,
"LINUX FOR POWERPC <linuxppc-dev@lists.ozlabs.org>,
linux-m68k (32-BIT AND 64-BIT)" <linux-m68k@lists.linux-m68k.org>,
"openrisc@lists.librecores.org" <openrisc@lists.librecores.org>,
Greentime Hu <green.hu@gmail.com>,
"Stafford Horne <shorne@gmail.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
monstr@monstr.eu" <monstr@monstr.eu>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
"open list:PARISC ARCHITECTURE" <linux-parisc@vger.kernel.org>,
Nick Hu <nickhu@andestech.com>, Max Filippov <jcmvbkbc@gmail.com>,
"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"dinguyen@kernel.org" <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 S. Miller" <davem@davemloft.net>
Subject: RE: [PATCH 08/14] arm64: simplify access_ok()
Date: Tue, 15 Feb 2022 09:30:41 +0000 [thread overview]
Message-ID: <153bb1887f484ed79ce8224845a4b2ea@AcuMS.aculab.com> (raw)
In-Reply-To: <CAMj1kXHixUFjV=4m3tzfGz7AiRWc-VczymbKuZq7dyZZNuLKxQ@mail.gmail.com>
From: Ard Biesheuvel
> Sent: 15 February 2022 08:18
>
> On Mon, 14 Feb 2022 at 17:37, Arnd Bergmann <arnd@kernel.org> wrote:
> >
> > From: Arnd Bergmann <arnd@arndb.de>
> >
> > arm64 has an inline asm implementation of access_ok() that is derived from
> > the 32-bit arm version and optimized for the case that both the limit and
> > the size are variable. With set_fs() gone, the limit is always constant,
> > and the size usually is as well, so just using the default implementation
> > reduces the check into a comparison against a constant that can be
> > scheduled by the compiler.
> >
> > On a defconfig build, this saves over 28KB of .text.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > arch/arm64/include/asm/uaccess.h | 28 +++++-----------------------
> > 1 file changed, 5 insertions(+), 23 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
> > index 357f7bd9c981..e8dce0cc5eaa 100644
> > --- a/arch/arm64/include/asm/uaccess.h
> > +++ b/arch/arm64/include/asm/uaccess.h
> > @@ -26,6 +26,8 @@
> > #include <asm/memory.h>
> > #include <asm/extable.h>
> >
> > +static inline int __access_ok(const void __user *ptr, unsigned long size);
> > +
> > /*
> > * Test whether a block of memory is a valid user space address.
> > * Returns 1 if the range is valid, 0 otherwise.
> > @@ -33,10 +35,8 @@
> > * This is equivalent to the following test:
> > * (u65)addr + (u65)size <= (u65)TASK_SIZE_MAX
> > */
> > -static inline unsigned long __access_ok(const void __user *addr, unsigned long size)
> > +static inline int access_ok(const void __user *addr, unsigned long size)
> > {
> > - unsigned long ret, limit = TASK_SIZE_MAX - 1;
> > -
> > /*
> > * Asynchronous I/O running in a kernel thread does not have the
> > * TIF_TAGGED_ADDR flag of the process owning the mm, so always untag
> > @@ -46,27 +46,9 @@ static inline unsigned long __access_ok(const void __user *addr, unsigned long s
> > (current->flags & PF_KTHREAD || test_thread_flag(TIF_TAGGED_ADDR)))
> > addr = untagged_addr(addr);
> >
> > - __chk_user_ptr(addr);
> > - asm volatile(
> > - // A + B <= C + 1 for all A,B,C, in four easy steps:
> > - // 1: X = A + B; X' = X % 2^64
> > - " adds %0, %3, %2\n"
> > - // 2: Set C = 0 if X > 2^64, to guarantee X' > C in step 4
> > - " csel %1, xzr, %1, hi\n"
> > - // 3: Set X' = ~0 if X >= 2^64. For X == 2^64, this decrements X'
> > - // to compensate for the carry flag being set in step 4. For
> > - // X > 2^64, X' merely has to remain nonzero, which it does.
> > - " csinv %0, %0, xzr, cc\n"
> > - // 4: For X < 2^64, this gives us X' - C - 1 <= 0, where the -1
> > - // comes from the carry in being clear. Otherwise, we are
> > - // testing X' - C == 0, subject to the previous adjustments.
> > - " sbcs xzr, %0, %1\n"
> > - " cset %0, ls\n"
> > - : "=&r" (ret), "+r" (limit) : "Ir" (size), "0" (addr) : "cc");
> > -
> > - return ret;
> > + return likely(__access_ok(addr, size));
> > }
> > -#define __access_ok __access_ok
> > +#define access_ok access_ok
> >
> > #include <asm-generic/access_ok.h>
> >
> > --
> > 2.29.2
> >
>
> With set_fs() out of the picture, wouldn't it be sufficient to check
> that bit #55 is clear? (the bit that selects between TTBR0 and TTBR1)
> That would also remove the need to strip the tag from the address.
>
> Something like
>
> asm goto("tbnz %0, #55, %2 \n"
> "tbnz %1, #55, %2 \n"
> :: "r"(addr), "r"(addr + size - 1) :: notok);
> return 1;
> notok:
> return 0;
>
> with an additional sanity check on the size which the compiler could
> eliminate for compile-time constant values.
Is there are reason not to just use:
size < 1u << 48 && !((addr | (addr + size - 1)) & 1u << 55)
(The -1 can be removed if the last user page is never mapped)
Ugg, is arm64 addressing as horrid as it looks - with the 'kernel'
bit in the middle of the virtual address space?
It seems to be:
<zero:4><tag:4><kernel:1><ignored:7><address:48>
Although I found some references to 44 bit VA and to code using the
'ignored' bits as tags - relying on the hardware ignoring them.
There might be some feature that uses the top 4 bits as well.
Another option is assuming that accesses are 'reasonably sequential',
removing the length check and ensuring there is an unmapped page
between valid user and kernel addresses.
That probably requires and unmapped page at the bottom of kernel space
which may not be achievable.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
WARNING: multiple messages have this Message-ID (diff)
From: David Laight <David.Laight@ACULAB.COM>
To: openrisc@lists.librecores.org
Subject: [OpenRISC] [PATCH 08/14] arm64: simplify access_ok()
Date: Tue, 15 Feb 2022 09:30:41 +0000 [thread overview]
Message-ID: <153bb1887f484ed79ce8224845a4b2ea@AcuMS.aculab.com> (raw)
In-Reply-To: <CAMj1kXHixUFjV=4m3tzfGz7AiRWc-VczymbKuZq7dyZZNuLKxQ@mail.gmail.com>
From: Ard Biesheuvel
> Sent: 15 February 2022 08:18
>
> On Mon, 14 Feb 2022 at 17:37, Arnd Bergmann <arnd@kernel.org> wrote:
> >
> > From: Arnd Bergmann <arnd@arndb.de>
> >
> > arm64 has an inline asm implementation of access_ok() that is derived from
> > the 32-bit arm version and optimized for the case that both the limit and
> > the size are variable. With set_fs() gone, the limit is always constant,
> > and the size usually is as well, so just using the default implementation
> > reduces the check into a comparison against a constant that can be
> > scheduled by the compiler.
> >
> > On a defconfig build, this saves over 28KB of .text.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > arch/arm64/include/asm/uaccess.h | 28 +++++-----------------------
> > 1 file changed, 5 insertions(+), 23 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
> > index 357f7bd9c981..e8dce0cc5eaa 100644
> > --- a/arch/arm64/include/asm/uaccess.h
> > +++ b/arch/arm64/include/asm/uaccess.h
> > @@ -26,6 +26,8 @@
> > #include <asm/memory.h>
> > #include <asm/extable.h>
> >
> > +static inline int __access_ok(const void __user *ptr, unsigned long size);
> > +
> > /*
> > * Test whether a block of memory is a valid user space address.
> > * Returns 1 if the range is valid, 0 otherwise.
> > @@ -33,10 +35,8 @@
> > * This is equivalent to the following test:
> > * (u65)addr + (u65)size <= (u65)TASK_SIZE_MAX
> > */
> > -static inline unsigned long __access_ok(const void __user *addr, unsigned long size)
> > +static inline int access_ok(const void __user *addr, unsigned long size)
> > {
> > - unsigned long ret, limit = TASK_SIZE_MAX - 1;
> > -
> > /*
> > * Asynchronous I/O running in a kernel thread does not have the
> > * TIF_TAGGED_ADDR flag of the process owning the mm, so always untag
> > @@ -46,27 +46,9 @@ static inline unsigned long __access_ok(const void __user *addr, unsigned long s
> > (current->flags & PF_KTHREAD || test_thread_flag(TIF_TAGGED_ADDR)))
> > addr = untagged_addr(addr);
> >
> > - __chk_user_ptr(addr);
> > - asm volatile(
> > - // A + B <= C + 1 for all A,B,C, in four easy steps:
> > - // 1: X = A + B; X' = X % 2^64
> > - " adds %0, %3, %2\n"
> > - // 2: Set C = 0 if X > 2^64, to guarantee X' > C in step 4
> > - " csel %1, xzr, %1, hi\n"
> > - // 3: Set X' = ~0 if X >= 2^64. For X == 2^64, this decrements X'
> > - // to compensate for the carry flag being set in step 4. For
> > - // X > 2^64, X' merely has to remain nonzero, which it does.
> > - " csinv %0, %0, xzr, cc\n"
> > - // 4: For X < 2^64, this gives us X' - C - 1 <= 0, where the -1
> > - // comes from the carry in being clear. Otherwise, we are
> > - // testing X' - C == 0, subject to the previous adjustments.
> > - " sbcs xzr, %0, %1\n"
> > - " cset %0, ls\n"
> > - : "=&r" (ret), "+r" (limit) : "Ir" (size), "0" (addr) : "cc");
> > -
> > - return ret;
> > + return likely(__access_ok(addr, size));
> > }
> > -#define __access_ok __access_ok
> > +#define access_ok access_ok
> >
> > #include <asm-generic/access_ok.h>
> >
> > --
> > 2.29.2
> >
>
> With set_fs() out of the picture, wouldn't it be sufficient to check
> that bit #55 is clear? (the bit that selects between TTBR0 and TTBR1)
> That would also remove the need to strip the tag from the address.
>
> Something like
>
> asm goto("tbnz %0, #55, %2 \n"
> "tbnz %1, #55, %2 \n"
> :: "r"(addr), "r"(addr + size - 1) :: notok);
> return 1;
> notok:
> return 0;
>
> with an additional sanity check on the size which the compiler could
> eliminate for compile-time constant values.
Is there are reason not to just use:
size < 1u << 48 && !((addr | (addr + size - 1)) & 1u << 55)
(The -1 can be removed if the last user page is never mapped)
Ugg, is arm64 addressing as horrid as it looks - with the 'kernel'
bit in the middle of the virtual address space?
It seems to be:
<zero:4><tag:4><kernel:1><ignored:7><address:48>
Although I found some references to 44 bit VA and to code using the
'ignored' bits as tags - relying on the hardware ignoring them.
There might be some feature that uses the top 4 bits as well.
Another option is assuming that accesses are 'reasonably sequential',
removing the length check and ensuring there is an unmapped page
between valid user and kernel addresses.
That probably requires and unmapped page at the bottom of kernel space
which may not be achievable.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
WARNING: multiple messages have this Message-ID (diff)
From: David Laight <David.Laight@ACULAB.COM>
To: 'Ard Biesheuvel' <ardb@kernel.org>, Arnd Bergmann <arnd@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
Rich Felker <dalias@libc.org>,
"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Memory Management List <linux-mm@kvack.org>,
Guo Ren <guoren@kernel.org>,
"open list:SPARC + UltraSPARC \(sparc/sparc64\)"
<sparclinux@vger.kernel.org>,
linux-riscv <linux-riscv@lists.infradead.org>,
"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
Will Deacon <will@kernel.org>, Christoph Hellwig <hch@lst.de>,
linux-arch <linux-arch@vger.kernel.org>,
"open list:S390" <linux-s390@vger.kernel.org>,
Brian Cain <bcain@codeaurora.org>,
"linux-hexagon@vger.kernel.org" <linux-hexagon@vger.kernel.org>,
Helge Deller <deller@gmx.de>, X86 ML <x86@kernel.org>,
Russell King <linux@armlinux.org.uk>,
"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Ingo Molnar <mingo@redhat.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
"linux-snps-arc@lists.infradead.org"
<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>,
linux-um <linux-um@lists.infradead.org>,
Richard Weinberger <richard@nod.at>,
linux-m68k <linux-m68k@lists.linux-m68k.org>,
"openrisc@lists.librecores.org" <openrisc@lists.librecores.org>,
Greentime Hu <green.hu@gmail.com>,
Stafford Horne <shorne@gmail.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
"monstr@monstr.eu" <monstr@monstr.eu>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Nick Hu <nickhu@andestech.com>,
"open list:PARISC ARCHITECTURE" <linux-parisc@vger.kernel.org>,
Max Filippov <jcmvbkbc@gmail.com>,
"open list:LINUX FOR POWERPC \(32-BIT AND 64-BIT\)"
<linuxppc-dev@lists.ozlabs.org>,
"open list:MIPS" <linux-mips@vger.kernel.org>,
"dinguyen@kernel.org" <dinguyen@kernel.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
alpha <linux-alpha@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Robin Murphy <robin.murphy@arm.com>,
"David S. Miller" <davem@davemloft.net>
Subject: RE: [PATCH 08/14] arm64: simplify access_ok()
Date: Tue, 15 Feb 2022 09:30:41 +0000 [thread overview]
Message-ID: <153bb1887f484ed79ce8224845a4b2ea@AcuMS.aculab.com> (raw)
In-Reply-To: <CAMj1kXHixUFjV=4m3tzfGz7AiRWc-VczymbKuZq7dyZZNuLKxQ@mail.gmail.com>
From: Ard Biesheuvel
> Sent: 15 February 2022 08:18
>
> On Mon, 14 Feb 2022 at 17:37, Arnd Bergmann <arnd@kernel.org> wrote:
> >
> > From: Arnd Bergmann <arnd@arndb.de>
> >
> > arm64 has an inline asm implementation of access_ok() that is derived from
> > the 32-bit arm version and optimized for the case that both the limit and
> > the size are variable. With set_fs() gone, the limit is always constant,
> > and the size usually is as well, so just using the default implementation
> > reduces the check into a comparison against a constant that can be
> > scheduled by the compiler.
> >
> > On a defconfig build, this saves over 28KB of .text.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > arch/arm64/include/asm/uaccess.h | 28 +++++-----------------------
> > 1 file changed, 5 insertions(+), 23 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
> > index 357f7bd9c981..e8dce0cc5eaa 100644
> > --- a/arch/arm64/include/asm/uaccess.h
> > +++ b/arch/arm64/include/asm/uaccess.h
> > @@ -26,6 +26,8 @@
> > #include <asm/memory.h>
> > #include <asm/extable.h>
> >
> > +static inline int __access_ok(const void __user *ptr, unsigned long size);
> > +
> > /*
> > * Test whether a block of memory is a valid user space address.
> > * Returns 1 if the range is valid, 0 otherwise.
> > @@ -33,10 +35,8 @@
> > * This is equivalent to the following test:
> > * (u65)addr + (u65)size <= (u65)TASK_SIZE_MAX
> > */
> > -static inline unsigned long __access_ok(const void __user *addr, unsigned long size)
> > +static inline int access_ok(const void __user *addr, unsigned long size)
> > {
> > - unsigned long ret, limit = TASK_SIZE_MAX - 1;
> > -
> > /*
> > * Asynchronous I/O running in a kernel thread does not have the
> > * TIF_TAGGED_ADDR flag of the process owning the mm, so always untag
> > @@ -46,27 +46,9 @@ static inline unsigned long __access_ok(const void __user *addr, unsigned long s
> > (current->flags & PF_KTHREAD || test_thread_flag(TIF_TAGGED_ADDR)))
> > addr = untagged_addr(addr);
> >
> > - __chk_user_ptr(addr);
> > - asm volatile(
> > - // A + B <= C + 1 for all A,B,C, in four easy steps:
> > - // 1: X = A + B; X' = X % 2^64
> > - " adds %0, %3, %2\n"
> > - // 2: Set C = 0 if X > 2^64, to guarantee X' > C in step 4
> > - " csel %1, xzr, %1, hi\n"
> > - // 3: Set X' = ~0 if X >= 2^64. For X == 2^64, this decrements X'
> > - // to compensate for the carry flag being set in step 4. For
> > - // X > 2^64, X' merely has to remain nonzero, which it does.
> > - " csinv %0, %0, xzr, cc\n"
> > - // 4: For X < 2^64, this gives us X' - C - 1 <= 0, where the -1
> > - // comes from the carry in being clear. Otherwise, we are
> > - // testing X' - C == 0, subject to the previous adjustments.
> > - " sbcs xzr, %0, %1\n"
> > - " cset %0, ls\n"
> > - : "=&r" (ret), "+r" (limit) : "Ir" (size), "0" (addr) : "cc");
> > -
> > - return ret;
> > + return likely(__access_ok(addr, size));
> > }
> > -#define __access_ok __access_ok
> > +#define access_ok access_ok
> >
> > #include <asm-generic/access_ok.h>
> >
> > --
> > 2.29.2
> >
>
> With set_fs() out of the picture, wouldn't it be sufficient to check
> that bit #55 is clear? (the bit that selects between TTBR0 and TTBR1)
> That would also remove the need to strip the tag from the address.
>
> Something like
>
> asm goto("tbnz %0, #55, %2 \n"
> "tbnz %1, #55, %2 \n"
> :: "r"(addr), "r"(addr + size - 1) :: notok);
> return 1;
> notok:
> return 0;
>
> with an additional sanity check on the size which the compiler could
> eliminate for compile-time constant values.
Is there are reason not to just use:
size < 1u << 48 && !((addr | (addr + size - 1)) & 1u << 55)
(The -1 can be removed if the last user page is never mapped)
Ugg, is arm64 addressing as horrid as it looks - with the 'kernel'
bit in the middle of the virtual address space?
It seems to be:
<zero:4><tag:4><kernel:1><ignored:7><address:48>
Although I found some references to 44 bit VA and to code using the
'ignored' bits as tags - relying on the hardware ignoring them.
There might be some feature that uses the top 4 bits as well.
Another option is assuming that accesses are 'reasonably sequential',
removing the length check and ensuring there is an unmapped page
between valid user and kernel addresses.
That probably requires and unmapped page at the bottom of kernel space
which may not be achievable.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2022-02-15 9:30 UTC|newest]
Thread overview: 450+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-14 16:34 [PATCH 00/14] clean up asm/uaccess.h, kill set_fs for good Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` [OpenRISC] " Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` [PATCH 01/14] uaccess: fix integer overflow on access_ok() Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` [OpenRISC] " Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:58 ` Christoph Hellwig
2022-02-14 16:58 ` Christoph Hellwig
2022-02-14 16:58 ` [OpenRISC] " Christoph Hellwig
2022-02-14 16:58 ` Christoph Hellwig
2022-02-14 16:58 ` Christoph Hellwig
2022-02-14 16:58 ` Christoph Hellwig
2022-02-14 16:58 ` Christoph Hellwig
2022-02-14 16:58 ` Christoph Hellwig
2022-02-14 16:34 ` [PATCH 02/14] sparc64: add __{get,put}_kernel_nocheck() Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` [OpenRISC] [PATCH 02/14] sparc64: add __{get, put}_kernel_nocheck() Arnd Bergmann
2022-02-14 16:34 ` [PATCH 02/14] sparc64: add __{get,put}_kernel_nocheck() Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` [PATCH 03/14] nds32: fix access_ok() checks in get/put_user Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` [OpenRISC] " Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 17:01 ` Christoph Hellwig
2022-02-14 17:01 ` Christoph Hellwig
2022-02-14 17:01 ` [OpenRISC] " Christoph Hellwig
2022-02-14 17:01 ` Christoph Hellwig
2022-02-14 17:01 ` Christoph Hellwig
2022-02-14 17:01 ` Christoph Hellwig
2022-02-14 17:01 ` Christoph Hellwig
2022-02-14 17:01 ` Christoph Hellwig
2022-02-14 17:10 ` David Laight
2022-02-14 17:10 ` David Laight
2022-02-14 17:10 ` [OpenRISC] " David Laight
2022-02-14 17:10 ` David Laight
2022-02-14 17:10 ` David Laight
2022-02-14 17:10 ` David Laight
2022-02-15 9:18 ` Arnd Bergmann
2022-02-15 9:18 ` Arnd Bergmann
2022-02-15 9:18 ` [OpenRISC] " Arnd Bergmann
2022-02-15 9:18 ` Arnd Bergmann
2022-02-15 9:18 ` Arnd Bergmann
2022-02-15 9:18 ` Arnd Bergmann
2022-02-15 9:18 ` Arnd Bergmann
2022-02-15 10:25 ` Greg KH
2022-02-15 10:25 ` Greg KH
2022-02-15 10:25 ` [OpenRISC] " Greg KH
2022-02-15 10:25 ` Greg KH
2022-02-15 10:25 ` Greg KH
2022-02-15 10:25 ` Greg KH
2022-02-15 10:25 ` Greg KH
2022-02-14 16:34 ` [PATCH 04/14] x86: use more conventional access_ok() definition Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` [OpenRISC] " Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 17:02 ` Christoph Hellwig
2022-02-14 17:02 ` Christoph Hellwig
2022-02-14 17:02 ` Christoph Hellwig
2022-02-14 17:02 ` [OpenRISC] " Christoph Hellwig
2022-02-14 17:02 ` Christoph Hellwig
2022-02-14 17:02 ` Christoph Hellwig
2022-02-14 17:02 ` Christoph Hellwig
2022-02-14 17:02 ` Christoph Hellwig
2022-02-14 17:02 ` Christoph Hellwig
2022-02-14 19:45 ` Arnd Bergmann
2022-02-14 19:45 ` Arnd Bergmann
2022-02-14 19:45 ` [OpenRISC] " Arnd Bergmann
2022-02-14 19:45 ` Arnd Bergmann
2022-02-14 19:45 ` Arnd Bergmann
2022-02-14 19:45 ` Arnd Bergmann
2022-02-14 19:45 ` Arnd Bergmann
2022-02-14 20:00 ` Christoph Hellwig
2022-02-14 20:00 ` Christoph Hellwig
2022-02-14 20:00 ` [OpenRISC] " Christoph Hellwig
2022-02-14 20:00 ` Christoph Hellwig
2022-02-14 20:00 ` Christoph Hellwig
2022-02-14 20:00 ` Christoph Hellwig
2022-02-14 20:00 ` Christoph Hellwig
2022-02-14 20:01 ` Linus Torvalds
2022-02-14 20:01 ` Linus Torvalds
2022-02-14 20:01 ` [OpenRISC] " Linus Torvalds
2022-02-14 20:01 ` Linus Torvalds
2022-02-14 20:01 ` Linus Torvalds
2022-02-14 20:01 ` Linus Torvalds
2022-02-14 20:01 ` Linus Torvalds
2022-02-14 20:17 ` Al Viro
2022-02-14 20:17 ` Al Viro
2022-02-14 20:17 ` [OpenRISC] " Al Viro
2022-02-14 20:17 ` Al Viro
2022-02-14 20:17 ` Al Viro
2022-02-14 20:17 ` Al Viro
2022-02-15 2:47 ` Al Viro
2022-02-15 2:47 ` Al Viro
2022-02-15 2:47 ` [OpenRISC] " Al Viro
2022-02-15 2:47 ` Al Viro
2022-02-15 2:47 ` Al Viro
2022-02-15 2:47 ` Al Viro
2022-02-14 20:24 ` Linus Torvalds
2022-02-14 20:24 ` Linus Torvalds
2022-02-14 20:24 ` [OpenRISC] " Linus Torvalds
2022-02-14 20:24 ` Linus Torvalds
2022-02-14 20:24 ` Linus Torvalds
2022-02-14 20:24 ` Linus Torvalds
2022-02-14 20:24 ` Linus Torvalds
2022-02-14 20:24 ` Linus Torvalds
[not found] ` <CAHk-=wgYu67OwP4LhcrPdDVxv2mOsx-Xsc2DKoVW6GZwKFtOYQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2022-02-14 22:13 ` David Laight
2022-02-14 22:13 ` David Laight
2022-02-14 22:13 ` [OpenRISC] " David Laight
2022-02-14 22:13 ` David Laight
2022-02-14 22:13 ` David Laight
2022-02-14 22:13 ` David Laight
2022-02-14 22:13 ` David Laight
2022-02-14 22:13 ` David Laight
2022-02-14 16:34 ` [PATCH 05/14] uaccess: add generic __{get,put}_kernel_nofault Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` [OpenRISC] [PATCH 05/14] uaccess: add generic __{get, put}_kernel_nofault Arnd Bergmann
2022-02-14 16:34 ` [PATCH 05/14] uaccess: add generic __{get,put}_kernel_nofault Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 17:02 ` Christoph Hellwig
2022-02-14 17:02 ` Christoph Hellwig
2022-02-14 17:02 ` Christoph Hellwig
2022-02-14 17:02 ` [OpenRISC] [PATCH 05/14] uaccess: add generic __{get, put}_kernel_nofault Christoph Hellwig
2022-02-14 17:02 ` [PATCH 05/14] uaccess: add generic __{get,put}_kernel_nofault Christoph Hellwig
2022-02-14 17:02 ` Christoph Hellwig
2022-02-14 17:02 ` Christoph Hellwig
2022-02-14 17:02 ` Christoph Hellwig
2022-02-14 17:02 ` Christoph Hellwig
2022-02-15 0:31 ` Al Viro
2022-02-15 0:31 ` Al Viro
2022-02-15 0:31 ` [OpenRISC] [PATCH 05/14] uaccess: add generic __{get, put}_kernel_nofault Al Viro
2022-02-15 0:31 ` [PATCH 05/14] uaccess: add generic __{get,put}_kernel_nofault Al Viro
2022-02-15 0:31 ` Al Viro
2022-02-15 0:31 ` Al Viro
2022-02-15 13:16 ` Arnd Bergmann
2022-02-15 13:16 ` Arnd Bergmann
2022-02-15 13:16 ` [OpenRISC] [PATCH 05/14] uaccess: add generic __{get, put}_kernel_nofault Arnd Bergmann
2022-02-15 13:16 ` [PATCH 05/14] uaccess: add generic __{get,put}_kernel_nofault Arnd Bergmann
2022-02-15 13:16 ` Arnd Bergmann
2022-02-15 13:16 ` Arnd Bergmann
2022-02-15 13:16 ` Arnd Bergmann
2022-02-14 16:34 ` [PATCH 06/14] mips: use simpler access_ok() Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` [OpenRISC] " Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` [PATCH 07/14] uaccess: generalize access_ok() Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` [OpenRISC] " Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 17:04 ` Christoph Hellwig
2022-02-14 17:04 ` Christoph Hellwig
2022-02-14 17:04 ` Christoph Hellwig
2022-02-14 17:04 ` [OpenRISC] " Christoph Hellwig
2022-02-14 17:04 ` Christoph Hellwig
2022-02-14 17:04 ` Christoph Hellwig
2022-02-14 17:04 ` Christoph Hellwig
2022-02-14 17:04 ` Christoph Hellwig
2022-02-14 17:04 ` Christoph Hellwig
[not found] ` <20220214163452.1568807-8-arnd-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2022-02-14 17:15 ` Al Viro
2022-02-14 17:15 ` Al Viro
2022-02-14 17:15 ` [OpenRISC] " Al Viro
2022-02-14 17:15 ` Al Viro
2022-02-14 17:15 ` Al Viro
2022-02-14 17:15 ` Al Viro
2022-02-14 19:25 ` Arnd Bergmann
2022-02-14 19:25 ` Arnd Bergmann
2022-02-14 19:25 ` [OpenRISC] " Arnd Bergmann
2022-02-14 19:25 ` Arnd Bergmann
2022-02-14 19:25 ` Arnd Bergmann
2022-02-14 19:25 ` Arnd Bergmann
2022-02-14 19:25 ` Arnd Bergmann
2022-02-15 10:58 ` Mark Rutland
2022-02-15 10:58 ` Mark Rutland
2022-02-15 10:58 ` Mark Rutland
2022-02-15 10:58 ` [OpenRISC] " Mark Rutland
2022-02-15 10:58 ` Mark Rutland
2022-02-15 10:58 ` Mark Rutland
2022-02-15 10:58 ` Mark Rutland
2022-02-15 10:58 ` Mark Rutland
2022-02-14 16:34 ` [PATCH 08/14] arm64: simplify access_ok() Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` [OpenRISC] " Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 21:06 ` Robin Murphy
2022-02-14 21:06 ` Robin Murphy
2022-02-14 21:06 ` [OpenRISC] " Robin Murphy
2022-02-14 21:06 ` Robin Murphy
2022-02-14 21:06 ` Robin Murphy
2022-02-14 21:06 ` Robin Murphy
2022-02-14 21:06 ` Robin Murphy
2022-02-15 8:17 ` Ard Biesheuvel
2022-02-15 8:17 ` Ard Biesheuvel
2022-02-15 8:17 ` [OpenRISC] " Ard Biesheuvel
2022-02-15 8:17 ` Ard Biesheuvel
2022-02-15 8:17 ` Ard Biesheuvel
2022-02-15 8:17 ` Ard Biesheuvel
2022-02-15 8:17 ` Ard Biesheuvel
2022-02-15 9:12 ` Arnd Bergmann
2022-02-15 9:12 ` Arnd Bergmann
2022-02-15 9:12 ` [OpenRISC] " Arnd Bergmann
2022-02-15 9:12 ` Arnd Bergmann
2022-02-15 9:12 ` Arnd Bergmann
2022-02-15 9:12 ` Arnd Bergmann
2022-02-15 9:12 ` Arnd Bergmann
2022-02-15 9:21 ` Ard Biesheuvel
2022-02-15 9:21 ` Ard Biesheuvel
2022-02-15 9:21 ` [OpenRISC] " Ard Biesheuvel
2022-02-15 9:21 ` Ard Biesheuvel
2022-02-15 9:21 ` Ard Biesheuvel
2022-02-15 9:21 ` Ard Biesheuvel
2022-02-15 9:21 ` Ard Biesheuvel
2022-02-15 9:39 ` Arnd Bergmann
2022-02-15 9:39 ` Arnd Bergmann
2022-02-15 9:39 ` [OpenRISC] " Arnd Bergmann
2022-02-15 9:39 ` Arnd Bergmann
2022-02-15 9:39 ` Arnd Bergmann
2022-02-15 9:39 ` Arnd Bergmann
2022-02-15 9:39 ` Arnd Bergmann
[not found] ` <CAK8P3a0NTqK_m7q909d8FN6is8k4_u3zeckC9XOrjEi7kqSvmg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2022-02-15 10:39 ` Mark Rutland
2022-02-15 10:39 ` Mark Rutland
2022-02-15 10:39 ` [OpenRISC] " Mark Rutland
2022-02-15 10:39 ` Mark Rutland
2022-02-15 10:39 ` Mark Rutland
2022-02-15 10:39 ` Mark Rutland
2022-02-15 10:37 ` Mark Rutland
2022-02-15 10:37 ` Mark Rutland
2022-02-15 10:37 ` [OpenRISC] " Mark Rutland
2022-02-15 10:37 ` Mark Rutland
2022-02-15 10:37 ` Mark Rutland
2022-02-15 10:37 ` Mark Rutland
[not found] ` <CAK8P3a2VfvDkueaJNTA9SiB+PFsi_Q17AX+aL46ueooW2ahmQw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2022-02-16 19:43 ` Christophe Leroy
2022-02-16 19:43 ` Christophe Leroy
2022-02-16 19:43 ` [OpenRISC] " Christophe Leroy
2022-02-16 19:43 ` Christophe Leroy
2022-02-16 19:43 ` Christophe Leroy
2022-02-16 19:43 ` Christophe Leroy
2022-02-16 19:43 ` Christophe Leroy
2022-02-16 19:43 ` Christophe Leroy
2022-02-15 9:30 ` David Laight [this message]
2022-02-15 9:30 ` David Laight
2022-02-15 9:30 ` [OpenRISC] " David Laight
2022-02-15 9:30 ` David Laight
2022-02-15 9:30 ` David Laight
2022-02-15 9:30 ` David Laight
2022-02-15 9:30 ` David Laight
2022-02-15 9:30 ` David Laight
2022-02-15 11:24 ` Mark Rutland
2022-02-15 11:24 ` Mark Rutland
2022-02-15 11:24 ` [OpenRISC] " Mark Rutland
2022-02-15 11:24 ` Mark Rutland
2022-02-15 11:24 ` Mark Rutland
2022-02-15 11:24 ` Mark Rutland
2022-02-15 11:24 ` Mark Rutland
2022-02-15 11:07 ` Mark Rutland
2022-02-15 11:07 ` Mark Rutland
2022-02-15 11:07 ` Mark Rutland
2022-02-15 11:07 ` [OpenRISC] " Mark Rutland
2022-02-15 11:07 ` Mark Rutland
2022-02-15 11:07 ` Mark Rutland
2022-02-15 11:07 ` Mark Rutland
2022-02-15 11:07 ` Mark Rutland
2022-02-14 16:34 ` [PATCH 09/14] m68k: drop custom __access_ok() Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` [OpenRISC] " Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-15 0:37 ` Al Viro
2022-02-15 0:37 ` Al Viro
2022-02-15 0:37 ` [OpenRISC] " Al Viro
2022-02-15 0:37 ` Al Viro
2022-02-15 0:37 ` Al Viro
2022-02-15 0:37 ` Al Viro
2022-02-15 6:29 ` Christoph Hellwig
2022-02-15 6:29 ` Christoph Hellwig
2022-02-15 6:29 ` [OpenRISC] " Christoph Hellwig
2022-02-15 6:29 ` Christoph Hellwig
2022-02-15 6:29 ` Christoph Hellwig
2022-02-15 6:29 ` Christoph Hellwig
2022-02-15 6:29 ` Christoph Hellwig
2022-02-15 7:13 ` Al Viro
2022-02-15 7:13 ` Al Viro
2022-02-15 7:13 ` [OpenRISC] " Al Viro
2022-02-15 7:13 ` Al Viro
2022-02-15 7:13 ` Al Viro
2022-02-15 7:13 ` Al Viro
2022-02-15 10:02 ` Arnd Bergmann
2022-02-15 10:02 ` Arnd Bergmann
2022-02-15 10:02 ` [OpenRISC] " Arnd Bergmann
2022-02-15 10:02 ` Arnd Bergmann
2022-02-15 10:02 ` Arnd Bergmann
2022-02-15 10:02 ` Arnd Bergmann
2022-02-15 10:02 ` Arnd Bergmann
2022-02-15 13:28 ` David Laight
2022-02-15 13:28 ` David Laight
2022-02-15 13:28 ` [OpenRISC] " David Laight
2022-02-15 13:28 ` David Laight
2022-02-15 13:28 ` David Laight
2022-02-15 13:28 ` David Laight
2022-02-15 13:28 ` David Laight
2022-02-15 13:28 ` David Laight
2022-02-14 16:34 ` [PATCH 10/14] uaccess: remove most CONFIG_SET_FS users Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` [OpenRISC] " Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 17:06 ` Christoph Hellwig
2022-02-14 17:06 ` Christoph Hellwig
2022-02-14 17:06 ` Christoph Hellwig
2022-02-14 17:06 ` [OpenRISC] " Christoph Hellwig
2022-02-14 17:06 ` Christoph Hellwig
2022-02-14 17:06 ` Christoph Hellwig
2022-02-14 17:06 ` Christoph Hellwig
2022-02-14 17:06 ` Christoph Hellwig
2022-02-14 19:40 ` Arnd Bergmann
2022-02-14 19:40 ` Arnd Bergmann
2022-02-14 19:40 ` Arnd Bergmann
2022-02-14 19:40 ` [OpenRISC] " Arnd Bergmann
2022-02-14 19:40 ` Arnd Bergmann
2022-02-14 19:40 ` Arnd Bergmann
2022-02-14 19:40 ` Arnd Bergmann
2022-02-14 19:40 ` Arnd Bergmann
2022-02-14 16:34 ` [PATCH 11/14] sparc64: remove CONFIG_SET_FS support Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` [OpenRISC] " Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 17:06 ` Christoph Hellwig
2022-02-14 17:06 ` Christoph Hellwig
2022-02-14 17:06 ` Christoph Hellwig
2022-02-14 17:06 ` [OpenRISC] " Christoph Hellwig
2022-02-14 17:06 ` Christoph Hellwig
2022-02-14 17:06 ` Christoph Hellwig
2022-02-14 17:06 ` Christoph Hellwig
2022-02-14 17:06 ` Christoph Hellwig
2022-02-14 17:06 ` Christoph Hellwig
2022-02-16 13:06 ` Arnd Bergmann
2022-02-16 13:06 ` Arnd Bergmann
2022-02-16 13:06 ` Arnd Bergmann
2022-02-16 13:06 ` [OpenRISC] " Arnd Bergmann
2022-02-16 13:06 ` Arnd Bergmann
2022-02-16 13:06 ` Arnd Bergmann
2022-02-16 13:06 ` Arnd Bergmann
2022-02-16 13:06 ` Arnd Bergmann
2022-02-15 0:48 ` Al Viro
2022-02-15 0:48 ` Al Viro
2022-02-15 0:48 ` [OpenRISC] " Al Viro
2022-02-15 0:48 ` Al Viro
2022-02-15 0:48 ` Al Viro
2022-02-15 0:48 ` Al Viro
2022-02-16 13:07 ` Arnd Bergmann
2022-02-16 13:07 ` Arnd Bergmann
2022-02-16 13:07 ` [OpenRISC] " Arnd Bergmann
2022-02-16 13:07 ` Arnd Bergmann
2022-02-16 13:07 ` Arnd Bergmann
2022-02-16 13:07 ` Arnd Bergmann
2022-02-16 13:07 ` Arnd Bergmann
2022-02-14 16:34 ` [PATCH 12/14] sh: " Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` [OpenRISC] " Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` [PATCH 13/14] ia64: " Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` [OpenRISC] " Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` [PATCH 14/14] uaccess: drop set_fs leftovers Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` [OpenRISC] " Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-14 16:34 ` Arnd Bergmann
2022-02-15 3:03 ` Al Viro
2022-02-15 3:03 ` Al Viro
2022-02-15 3:03 ` [OpenRISC] " Al Viro
2022-02-15 3:03 ` Al Viro
2022-02-15 3:03 ` Al Viro
2022-02-15 3:03 ` Al Viro
2022-02-15 7:46 ` Helge Deller
2022-02-15 7:46 ` Helge Deller
2022-02-15 7:46 ` [OpenRISC] " Helge Deller
2022-02-15 7:46 ` Helge Deller
2022-02-15 7:46 ` Helge Deller
2022-02-15 7:46 ` Helge Deller
2022-02-15 7:46 ` Helge Deller
2022-02-15 8:10 ` Arnd Bergmann
2022-02-15 8:10 ` Arnd Bergmann
2022-02-15 8:10 ` [OpenRISC] " Arnd Bergmann
2022-02-15 8:10 ` Arnd Bergmann
2022-02-15 8:10 ` Arnd Bergmann
2022-02-15 8:10 ` Arnd Bergmann
2022-02-15 8:10 ` Arnd Bergmann
[not found] ` <20220214163452.1568807-1-arnd-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2022-02-14 17:35 ` [PATCH 00/14] clean up asm/uaccess.h, kill set_fs for good Linus Torvalds
2022-02-14 17:35 ` Linus Torvalds
2022-02-14 17:35 ` Linus Torvalds
2022-02-14 17:35 ` [OpenRISC] " Linus Torvalds
2022-02-14 17:35 ` Linus Torvalds
2022-02-14 17:35 ` Linus Torvalds
2022-02-14 17:35 ` Linus Torvalds
2022-02-14 17:35 ` Linus Torvalds
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=153bb1887f484ed79ce8224845a4b2ea@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=ardb@kernel.org \
--cc=arnd@kernel.org \
--cc=bcain@codeaurora.org \
--cc=dalias@libc.org \
--cc=deller@gmx.de \
--cc=guoren@kernel.org \
--cc=hch@lst.de \
--cc=linux-arch@vger.kernel.org \
--cc=linux-hexagon@vger.kernel.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=peterz@infradead.org \
--cc=sparclinux@vger.kernel.org \
--cc=will@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.