Re: [PATCH v2 13/18] uaccess: generalize access_ok()

2022-02-24 Thread Dinh Nguyen
On 2/16/22 07:13, Arnd Bergmann wrote: From: Arnd Bergmann There are many different ways that access_ok() is defined across architectures, but in the end, they all just compare against the user_addr_max() value or they accept anything. Provide one definition that works for most

Re: [PATCH v2 13/18] uaccess: generalize access_ok()

2022-02-24 Thread Arnd Bergmann
On Thu, Feb 24, 2022 at 9:29 AM Stafford Horne wrote: > > - > > -#define access_ok(addr, size) > > \ > > -({ \ > > - __chk_user_ptr(addr);

Re: [PATCH v2 13/18] uaccess: generalize access_ok()

2022-02-18 Thread Andy Lutomirski
On Fri, Feb 18, 2022 at 1:30 AM David Laight wrote: > > From: Andy Lutomirski > > Sent: 17 February 2022 19:15 > ... > > This isn't actually optimal. On x86, TASK_SIZE_MAX is a bizarre > > constant that has a very specific value to work around a bug^Wdesign > > error^Wfeature of Intel CPUs.

RE: [PATCH v2 13/18] uaccess: generalize access_ok()

2022-02-18 Thread David Laight
From: Andy Lutomirski > Sent: 17 February 2022 19:15 ... > This isn't actually optimal. On x86, TASK_SIZE_MAX is a bizarre > constant that has a very specific value to work around a bug^Wdesign > error^Wfeature of Intel CPUs. TASK_SIZE_MAX is the maximum address at > which userspace is permitted

Re: [PATCH v2 13/18] uaccess: generalize access_ok()

2022-02-18 Thread Geert Uytterhoeven
On Wed, Feb 16, 2022 at 2:17 PM Arnd Bergmann wrote: > From: Arnd Bergmann > > There are many different ways that access_ok() is defined across > architectures, but in the end, they all just compare against the > user_addr_max() value or they accept anything. > > Provide one definition that

Re: [PATCH v2 13/18] uaccess: generalize access_ok()

2022-02-17 Thread Arnd Bergmann
On Fri, Feb 18, 2022 at 7:34 AM Christoph Hellwig wrote: > > > +#include > > Instead of the asm-generic games, shouldn't we just define access_ok in > if not already defined by the architecture? I tried, but couldn't actually make it work because asm/uaccess.h tends to contain inline functions

Re: [PATCH v2 13/18] uaccess: generalize access_ok()

2022-02-17 Thread Arnd Bergmann
On Thu, Feb 17, 2022 at 8:15 PM Andy Lutomirski wrote: > > On Wed, Feb 16, 2022 at 5:19 AM Arnd Bergmann wrote: > > > > From: Arnd Bergmann > > > > There are many different ways that access_ok() is defined across > > architectures, but in the end, they all just compare against the > >

Re: [PATCH v2 13/18] uaccess: generalize access_ok()

2022-02-17 Thread Christoph Hellwig
> +#include Instead of the asm-generic games, shouldn't we just define access_ok in if not already defined by the architecture? ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org

Re: [PATCH v2 13/18] uaccess: generalize access_ok()

2022-02-17 Thread Andy Lutomirski
On Wed, Feb 16, 2022 at 5:19 AM Arnd Bergmann wrote: > > From: Arnd Bergmann > > There are many different ways that access_ok() is defined across > architectures, but in the end, they all just compare against the > user_addr_max() value or they accept anything. > > Provide one definition that

Re: [PATCH v2 13/18] uaccess: generalize access_ok()

2022-02-16 Thread Arnd Bergmann
On Wed, Feb 16, 2022 at 2:13 PM Arnd Bergmann wrote: > + * limit and catch all possible overflows. > + * On architectures with separate user address space (m68k, s390, parisc, > + * sparc64) or those without an MMU, this should always return true. ... > +static inline int __access_ok(const void