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
On Thu, Feb 17, 2022 at 8:20 AM Christophe Leroy
wrote:
> Le 16/02/2022 à 14:13, Arnd Bergmann a écrit :
> >
> > 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
Le 16/02/2022 à 14:13, Arnd Bergmann a écrit :
> From: Arnd Bergmann
>
> 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
>
On Wed, Feb 16, 2022 at 7:44 PM Sam Ravnborg wrote:
>
> Hi Arnd,
>
> Fix spelling in $subject...
done
> sparc/Kconfig b/arch/sparc/Kconfig
> > index 9f6f9bce5292..9276f321b3e3 100644
> > --- a/arch/sparc/Kconfig
> > +++ b/arch/sparc/Kconfig
> > @@ -46,7 +46,6 @@ config SPARC
> > select
On Wed, Feb 16, 2022 at 7:41 PM Sam Ravnborg wrote:
> On Wed, Feb 16, 2022 at 07:34:59PM +0100, Sam Ravnborg wrote:
> >
> > I think you somehow missed the Kconfig change, and also the related
> > sparc32 change which continue to have set_fs() after this patch.
Right, thanks for pointing out the
Le 15/02/2022 à 10:12, Arnd Bergmann a écrit :
> On Tue, Feb 15, 2022 at 9:17 AM Ard Biesheuvel wrote:
>> On Mon, 14 Feb 2022 at 17:37, Arnd Bergmann wrote:
>>> From: Arnd Bergmann
>>>
>>
>> With set_fs() out of the picture, wouldn't it be sufficient to check
>> that bit #55 is clear? (the
Hi Arnd,
Fix spelling in $subject...
sparc/Kconfig b/arch/sparc/Kconfig
> index 9f6f9bce5292..9276f321b3e3 100644
> --- a/arch/sparc/Kconfig
> +++ b/arch/sparc/Kconfig
> @@ -46,7 +46,6 @@ config SPARC
> select LOCKDEP_SMALL if LOCKDEP
> select NEED_DMA_MAP_STATE
> select
Hi Arnd,
On Wed, Feb 16, 2022 at 07:34:59PM +0100, Sam Ravnborg wrote:
> Hi Arnd.
>
> On Wed, Feb 16, 2022 at 02:13:29PM +0100, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > sparc64 uses address space identifiers to differentiate between kernel
> > and user space, using ASI_P for kernel
Hi Arnd.
On Wed, Feb 16, 2022 at 02:13:29PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> sparc64 uses address space identifiers to differentiate between kernel
> and user space, using ASI_P for kernel threads but ASI_AIUS for normal
> user space, with the option of changing between
From: Arnd Bergmann
> Sent: 16 February 2022 13:13
>
> These two architectures implement 8-byte get_user() through
> a memcpy() into a four-byte variable, which won't fit.
>
> Use a temporary 64-bit variable instead here, and use a double
> cast the way that risc-v and openrisc do to avoid
From: Arnd Bergmann
There are no remaining callers of set_fs(), so CONFIG_SET_FS
can be removed globally, along with the thread_info field and
any references to it.
This turns access_ok() into a cheaper check against TASK_SIZE_MAX.
With CONFIG_SET_FS gone, so drop all remaining references to
From: Arnd Bergmann
ia64 only uses set_fs() in one file to handle unaligned access for
both user space and kernel instructions. Rewrite this to explicitly
pass around a flag about which one it is and drop the feature from
the architecture.
Signed-off-by: Arnd Bergmann
---
arch/ia64/Kconfig
From: Arnd Bergmann
sh uses set_fs/get_fs only in one file, to handle address
errors in both user and kernel memory.
It already has an abstraction to differentiate between I/O
and memory, so adding a third class for kernel memory fits
into the same scheme and lets us kill off CONFIG_SET_FS.
From: Arnd Bergmann
sparc64 uses address space identifiers to differentiate between kernel
and user space, using ASI_P for kernel threads but ASI_AIUS for normal
user space, with the option of changing between them.
As nothing really changes the ASI any more, just hardcode ASI_AIUS
everywhere.
From: Arnd Bergmann
test_kernel_ptr() uses access_ok() to figure out if a given address
points to user space instead of kernel space. However on architectures
that set CONFIG_ALTERNATE_USER_ADDRESS_SPACE, a pointer can be valid
for both, and the check always fails because access_ok() returns
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 architectures, checking
against TASK_SIZE_MAX for user
From: Arnd Bergmann
On some architectures, access_ok() does not do any argument type
checking, so replacing the definition with a generic one causes
a few warnings for harmless issues that were never caught before.
Fix the ones that I found either through my own test builds or
that were
From: Arnd Bergmann
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
From: Arnd Bergmann
While most m68k platforms use separate address spaces for user
and kernel space, at least coldfire does not, and the other
ones have a TASK_SIZE that is less than the entire 4GB address
range.
Using the default implementation of __access_ok() stops coldfire
user space from
From: Arnd Bergmann
Before unifying the mips version of __access_ok() with the generic
code, this converts it to the same algorithm. This is a change in
behavior on mips64, as now address in the user segment, the lower
2^62 bytes, is taken to be valid, relying on a page fault for
addresses that
From: Arnd Bergmann
Nine architectures are still missing __{get,put}_kernel_nofault:
alpha, ia64, microblaze, nds32, nios2, openrisc, sh, sparc32, xtensa.
Add a generic version that lets everything use the normal
copy_{from,to}_kernel_nofault() code based on these, removing the last
use of
From: Arnd Bergmann
Unlike other architectures, the nios2 version of __put_user() has an
extra check for access_ok(), preventing it from being used to implement
__put_kernel_nofault().
Split up put_user() along the same lines as __get_user()/get_user()
Signed-off-by: Arnd Bergmann
---
From: Arnd Bergmann
The way that access_ok() is defined on x86 is slightly different from
most other architectures, and a bit more complex.
The generic version tends to result in the best output on all
architectures, as it results in single comparison against a constant
limit for calls with a
From: Arnd Bergmann
The __range_not_ok() helper is an x86 (and sparc64) specific interface
that does roughly the same thing as __access_ok(), but with different
calling conventions.
Change this to use the normal interface in order for consistency as we
clean up all access_ok() implementations.
From: Arnd Bergmann
sparc64 is one of the architectures that uses separate address
spaces for kernel and user addresses, so __get_kernel_nofault()
can not just call into the normal __get_user() without the
access_ok() check.
Instead duplicate __get_user() and __put_user() into their
in-kernel
From: Arnd Bergmann
The get_user()/put_user() functions are meant to check for
access_ok(), while the __get_user()/__put_user() functions
don't.
This broke in 4.19 for nds32, when it gained an extraneous
check in __get_user(), but lost the check it needs in
__put_user().
Fixes: 487913ab18c2
From: Arnd Bergmann
These two architectures implement 8-byte get_user() through
a memcpy() into a four-byte variable, which won't fit.
Use a temporary 64-bit variable instead here, and use a double
cast the way that risc-v and openrisc do to avoid compile-time
warnings.
Fixes: 6a090e97972d
From: Arnd Bergmann
Three architectures check the end of a user access against the
address limit without taking a possible overflow into account.
Passing a negative length or another overflow in here returns
success when it should not.
Use the most common correct implementation here, which
From: Arnd Bergmann
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
On Tue, Feb 15, 2022 at 1:48 AM Al Viro wrote:
>
> On Mon, Feb 14, 2022 at 05:34:49PM +0100, Arnd Bergmann wrote:
>
> > -/*
> > - * Sparc64 is segmented, though more like the M68K than the I386.
> > - * We use the secondary ASI to address user memory, which references a
> > - * completely
On Mon, Feb 14, 2022 at 6:06 PM Christoph Hellwig wrote:
>
> > void prom_world(int enter)
> > {
> > - if (!enter)
> > - set_fs(get_fs());
> > -
> > __asm__ __volatile__("flushw");
> > }
>
> The enter argument is now unused.
Right, good point. I'll add a comment, but I
31 matches
Mail list logo
