Re: remove the last set_fs() in common code, and remove it for x86 and powerpc v3
On Wed, Sep 09, 2020 at 02:33:36PM -0700, Linus Torvalds wrote:
> On Wed, Sep 9, 2020 at 11:42 AM Segher Boessenkool
> wrote:
> >
> > It will not work like this in GCC, no. The LLVM people know about that.
> > I do not know why they insist on pushing this, being incompatible and
> > everything.
>
> Umm. Since they'd be the ones supporting this, *gcc* would be the
> incompatible one, not clang.
This breaks the basic requirements of asm goto.
> So I'd phrase it differently. If gcc is planning on doing some
> different model for asm goto with outputs, that would be the
> incompatible case.
If we will do asm goto with outputs, the asm will still be a jump
instruction! (It is not in LLVM!)
We probably *can* make asm goto have outputs (jump instructions can have
outputs just fine! Just output reloads on jump instructions are hard,
because not always they are *possible*; but for asm goto it should be
fine).
Doing as LLVM does, and making the asm a "trapping" instruction, makes
it not a jump insn, and opens up whole new cans of worms (including
inferior code quality). Since it has very different semantics, and we
might want to keep the semantics of asm goto as well anyway, this should
be called something different ("asm break" or "asm __anything" for
example).
It would be nice if they talked to us about it, too. LLVM claims it
implements the GCC inline asm extension. It already only is compatible
for the simplest of cases, but this would be much worse still :-(
> and honestly, (b) is actually inferior for the error cases, even if to
> a compiler person it might feel like the "RightThing(tm)" to do.
> Because when an exception happens, the outputs simply won't be
> initialized.
Sure, that is fine, and quite possible useful, but it is not the same as
asm goto. asm goto is not some exception handling construct: it is a
jump instruction.
> Anyway, for either of those cases, the kernel won't care either way.
> We'll have to support the non-goto case for many years even if
> everybody were to magically implement it today, so it's not like this
> is a "you have to do it" thing.
Yes.
I'm just annoyed because of all the extra work created by people not
communicating.
Segher
Re: remove the last set_fs() in common code, and remove it for x86 and powerpc v3
On Thu, Sep 10, 2020 at 12:26:53PM +, David Laight wrote:
> Actually this is pretty sound:
> __label__ label;
> register int eax asm ("eax");
> // Ensure eax can't be reloaded from anywhere
> // In particular it can't be reloaded after the asm goto line
> asm volatile ("" : "=r" (eax));
This asm is fine. It says it writes the "eax" variable, which lives in
the eax register *in that asm* (so *not* guaranteed after it!).
> // Provided gcc doesn't save eax here...
> asm volatile goto ("x" ::: "eax" : label);
So this is incorrect.
> // ... and reload the saved value here.
> // The input value here will be that modified by the 'asm goto'.
> // Since this modifies eax it can't be moved before the 'asm goto'.
> asm volatile ("" : "+r" (eax));
> // So here eax must contain the value set by the "x" instructions.
No, the register eax will contain the value of the eax variable. In the
asm; it might well be there before or after the asm as well, but none of
that is guaranteed.
Segher
Re: remove the last set_fs() in common code, and remove it for x86 and powerpc v3
On Thu, Sep 10, 2020 at 03:31:53PM +, David Laight wrote:
> > > asm volatile ("" : "+r" (eax));
> > > // So here eax must contain the value set by the "x" instructions.
> >
> > No, the register eax will contain the value of the eax variable. In the
> > asm; it might well be there before or after the asm as well, but none of
> > that is guaranteed.
>
> Perhaps not 'guaranteed', but very unlikely to be wrong.
> It doesn't give gcc much scope for not generating the desired code.
Wanna bet? :-)
Correct is correct. Anything else is not.
Segher
Re: remove the last set_fs() in common code, and remove it for x86 and powerpc v3
On Thu, Sep 10, 2020 at 09:26:28AM +, David Laight wrote:
> From: Christophe Leroy
> > Sent: 10 September 2020 09:14
> >
> > Le 10/09/2020 à 10:04, David Laight a écrit :
> > > From: Linus Torvalds
> > >> Sent: 09 September 2020 22:34
> > >> On Wed, Sep 9, 2020 at 11:42 AM Segher Boessenkool
> > >> wrote:
> > >>>
> > >>> It will not work like this in GCC, no. The LLVM people know about that.
> > >>> I do not know why they insist on pushing this, being incompatible and
> > >>> everything.
> > >>
> > >> Umm. Since they'd be the ones supporting this, *gcc* would be the
> > >> incompatible one, not clang.
> > >
> > > I had an 'interesting' idea.
> > >
> > > Can you use a local asm register variable as an input and output to
> > > an 'asm volatile goto' statement?
> > >
> > > Well you can - but is it guaranteed to work :-)
> > >
> >
> > With gcc at least it should work according to
> > https://gcc.gnu.org/onlinedocs/gcc/Local-Register-Variables.html
> >
> > They even explicitely tell: "The only supported use for this feature is
> > to specify registers for input and output operands when calling Extended
> > asm "
>
> A quick test isn't good
>
> int bar(char *z)
> {
> __label__ label;
> register int eax asm ("eax") = 6;
> asm volatile goto (" mov $1, %%eax" ::: "eax" : label);
>
> label:
> return eax;
> }
It is neither input nor output operand here! Only *then* is a local
register asm guaranteed to be in the given reg: as input or output to an
inline asm.
Segher
RE: remove the last set_fs() in common code, and remove it for x86 and powerpc v3
> -Original Message-
> From: Segher Boessenkool
> Sent: 10 September 2020 16:21
> To: David Laight
> Cc: 'Christophe Leroy' ; 'Linus Torvalds'
> foundation.org>; linux-arch ; Kees Cook
> ; the
> arch/x86 maintainers ; Nick Desaulniers
> ; Linux Kernel
> Mailing List ; Alexey Dobriyan
> ; Luis Chamberlain
> ; Al Viro ; linux-fsdevel
> ;
> linuxppc-dev ; Christoph Hellwig
> Subject: Re: remove the last set_fs() in common code, and remove it for x86
> and powerpc v3
>
> On Thu, Sep 10, 2020 at 12:26:53PM +, David Laight wrote:
> > Actually this is pretty sound:
> > __label__ label;
> > register int eax asm ("eax");
> > // Ensure eax can't be reloaded from anywhere
> > // In particular it can't be reloaded after the asm goto line
> > asm volatile ("" : "=r" (eax));
>
> This asm is fine. It says it writes the "eax" variable, which lives in
> the eax register *in that asm* (so *not* guaranteed after it!).
>
> > // Provided gcc doesn't save eax here...
> > asm volatile goto ("x" ::: "eax" : label);
>
> So this is incorrect.
>From the other email:
> It is neither input nor output operand here! Only *then* is a local
> register asm guaranteed to be in the given reg: as input or output to an
> inline asm.
Ok, so adding '"r" (eax)' to the input section helps a bit.
> > // ... and reload the saved value here.
> > // The input value here will be that modified by the 'asm goto'.
> > // Since this modifies eax it can't be moved before the 'asm goto'.
> > asm volatile ("" : "+r" (eax));
> > // So here eax must contain the value set by the "x" instructions.
>
> No, the register eax will contain the value of the eax variable. In the
> asm; it might well be there before or after the asm as well, but none of
> that is guaranteed.
Perhaps not 'guaranteed', but very unlikely to be wrong.
It doesn't give gcc much scope for not generating the desired code.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
RE: remove the last set_fs() in common code, and remove it for x86 and powerpc v3
From: David Laight
> Sent: 10 September 2020 10:26
...
> > > I had an 'interesting' idea.
> > >
> > > Can you use a local asm register variable as an input and output to
> > > an 'asm volatile goto' statement?
> > >
> > > Well you can - but is it guaranteed to work :-)
> > >
> >
> > With gcc at least it should work according to
> > https://gcc.gnu.org/onlinedocs/gcc/Local-Register-Variables.html
> >
> > They even explicitely tell: "The only supported use for this feature is
> > to specify registers for input and output operands when calling Extended
> > asm "
>
> A quick test isn't good
>
> int bar(char *z)
> {
> __label__ label;
> register int eax asm ("eax") = 6;
> asm volatile goto (" mov $1, %%eax" ::: "eax" : label);
> label:
> return eax;
> }
>
> 0040 :
> 40: b8 01 00 00 00 mov$0x1,%eax
> 45: b8 06 00 00 00 mov$0x6,%eax
> 4a: c3 retq
>
> although adding:
> asm volatile ("" : "+r" (eax));
> either side of the 'asm volatile goto' does fix it.
Actually this is pretty sound:
__label__ label;
register int eax asm ("eax");
// Ensure eax can't be reloaded from anywhere
// In particular it can't be reloaded after the asm goto line
asm volatile ("" : "=r" (eax));
// Provided gcc doesn't save eax here...
asm volatile goto ("x" ::: "eax" : label);
// ... and reload the saved value here.
// The input value here will be that modified by the 'asm goto'.
// Since this modifies eax it can't be moved before the 'asm goto'.
asm volatile ("" : "+r" (eax));
// So here eax must contain the value set by the "x" instructions.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
RE: remove the last set_fs() in common code, and remove it for x86 and powerpc v3
From: Christophe Leroy
> Sent: 10 September 2020 09:14
>
> Le 10/09/2020 à 10:04, David Laight a écrit :
> > From: Linus Torvalds
> >> Sent: 09 September 2020 22:34
> >> On Wed, Sep 9, 2020 at 11:42 AM Segher Boessenkool
> >> wrote:
> >>>
> >>> It will not work like this in GCC, no. The LLVM people know about that.
> >>> I do not know why they insist on pushing this, being incompatible and
> >>> everything.
> >>
> >> Umm. Since they'd be the ones supporting this, *gcc* would be the
> >> incompatible one, not clang.
> >
> > I had an 'interesting' idea.
> >
> > Can you use a local asm register variable as an input and output to
> > an 'asm volatile goto' statement?
> >
> > Well you can - but is it guaranteed to work :-)
> >
>
> With gcc at least it should work according to
> https://gcc.gnu.org/onlinedocs/gcc/Local-Register-Variables.html
>
> They even explicitely tell: "The only supported use for this feature is
> to specify registers for input and output operands when calling Extended
> asm "
A quick test isn't good
int bar(char *z)
{
__label__ label;
register int eax asm ("eax") = 6;
asm volatile goto (" mov $1, %%eax" ::: "eax" : label);
label:
return eax;
}
0040 :
40: b8 01 00 00 00 mov$0x1,%eax
45: b8 06 00 00 00 mov$0x6,%eax
4a: c3 retq
although adding:
asm volatile ("" : "+r" (eax));
either side of the 'asm volatile goto' does fix it.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
Re: remove the last set_fs() in common code, and remove it for x86 and powerpc v3
Le 10/09/2020 à 10:04, David Laight a écrit : From: Linus Torvalds Sent: 09 September 2020 22:34 On Wed, Sep 9, 2020 at 11:42 AM Segher Boessenkool wrote: It will not work like this in GCC, no. The LLVM people know about that. I do not know why they insist on pushing this, being incompatible and everything. Umm. Since they'd be the ones supporting this, *gcc* would be the incompatible one, not clang. I had an 'interesting' idea. Can you use a local asm register variable as an input and output to an 'asm volatile goto' statement? Well you can - but is it guaranteed to work :-) With gcc at least it should work according to https://gcc.gnu.org/onlinedocs/gcc/Local-Register-Variables.html They even explicitely tell: "The only supported use for this feature is to specify registers for input and output operands when calling Extended asm " Christophe
RE: remove the last set_fs() in common code, and remove it for x86 and powerpc v3
From: Linus Torvalds > Sent: 09 September 2020 22:34 > On Wed, Sep 9, 2020 at 11:42 AM Segher Boessenkool > wrote: > > > > It will not work like this in GCC, no. The LLVM people know about that. > > I do not know why they insist on pushing this, being incompatible and > > everything. > > Umm. Since they'd be the ones supporting this, *gcc* would be the > incompatible one, not clang. I had an 'interesting' idea. Can you use a local asm register variable as an input and output to an 'asm volatile goto' statement? Well you can - but is it guaranteed to work :-) David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: remove the last set_fs() in common code, and remove it for x86 and powerpc v3
On Wed, Sep 9, 2020 at 11:42 AM Segher Boessenkool wrote: > > It will not work like this in GCC, no. The LLVM people know about that. > I do not know why they insist on pushing this, being incompatible and > everything. Umm. Since they'd be the ones supporting this, *gcc* would be the incompatible one, not clang. Like it or not, clang is becoming a major kernel compiler. It's already basically used for all android uses afaik. So I'd phrase it differently. If gcc is planning on doing some different model for asm goto with outputs, that would be the incompatible case. I'm not sure how gcc could do it differently. The only possible difference I see is (a) not doing it at all (b) doing the "all goto targets have the outputs" case and honestly, (b) is actually inferior for the error cases, even if to a compiler person it might feel like the "RightThing(tm)" to do. Because when an exception happens, the outputs simply won't be initialized. Anyway, for either of those cases, the kernel won't care either way. We'll have to support the non-goto case for many years even if everybody were to magically implement it today, so it's not like this is a "you have to do it" thing. Linus
Re: remove the last set_fs() in common code, and remove it for x86 and powerpc v3
On Wed, Sep 09, 2020 at 10:31:34AM -0700, Linus Torvalds wrote: > And apparently there are people working on this on the gcc side too, > so it won't just be clang-specific. Nor kernel-specific in that Nick > tells me some other projects are looking at using that asm goto with > outputs too. It will not work like this in GCC, no. The LLVM people know about that. I do not know why they insist on pushing this, being incompatible and everything. Segher
Re: remove the last set_fs() in common code, and remove it for x86 and powerpc v3
On Thu, Sep 3, 2020 at 7:28 AM Al Viro wrote:
>
> I can live with this series; do you want that in vfs.git#for-next?
Well, it's apparently there now (at least it's in your base.set_fs
branch, I didn't check actual -next).
So this is just a heads-up that I plan to merge the "asm goto" changes
on top of this during 5.10. Nick did the patch to make my patch-set
work either with or without the actual asm goto support, and I've been
running it privately now for several months.
And apparently there are people working on this on the gcc side too,
so it won't just be clang-specific. Nor kernel-specific in that Nick
tells me some other projects are looking at using that asm goto with
outputs too.
Anyway, the actual patch to use asm goto with outputs is fairly small
and not that interesting to people (since no released compiler
supports it), but part of the infrastructure to make it tiny is to
just get rid of the inlined "__get_user()" and "__put_user()" stuff.
I've ranted against those functions for a few years by now, so part of
this is to stop inlining them and make people think they are "good",
but part of it is also that those macros and inline functions are the
main remaining ones that mess with this all.
I'm attaching the two __get_user/__put_user patches here in case
anybody cares, but these are the pre-rebased ones, I'll make them work
with the new world order as it happens. The main change is:
(a) unify around a common special calling convention:
- %bx is clobbered
- %cx contains the user address on input, and the error value on output
- %ax/%dx contains the actual value (input for put, output for get,
of course)
(b) unify around using just a "call", using the model that
get/put_user already did.
- use "*_nocheck" for the double-underscore versions
- this still has to use inline asm because the calling convention is odd
- otherwise basically just a "call __{get,put}_user_[nocheck_]X"
where X is the size.
IOW, we unify around one single calling convention., and one single
model for actually getting things done.
I still want to remove the double-underscore versions entirely some
day - they have absolutely zero advantages compared to the full "do
address_ok as part of the operation" - but that's a separate thing. At
least they can be unified.
And the reason for this all is obviously that now *only* the
"unsafe_{get,put}_user()" cases with the error label output are the
"fast inlined" cases. They are the only ones that _can_ be done
quickly inline, since the slow clac/stac is not part of them. Plus
they already have that unified usage model of the error label, even if
unsafe_get_user() currently does it manually because "asm goto" with
outputs doesn't work in existing compilers.
Comments?
I suspect people won't care, but I thought I'd post these so that
there won't be any surprises during the next merge window when I apply
them after merging the set_fs() removal branch..
Linus
From 52c7574a0d15722df52158a3d766803662d9a6ff Mon Sep 17 00:00:00 2001
From: Linus Torvalds
Date: Wed, 8 Apr 2020 12:50:01 -0700
Subject: [PATCH 1/6] x86: Make __get_user() generate an out-of-line call
Instead of inlining the whole stac/lfence/mov/clac sequence (which also
requires individual exception table entries and several asm instruction
alternatives entries), just generate "call __get_user_nocheck_X" for the
__get_user() cases.
We can use all the same infrastructure that we already do for the
regular "get_user()", and the end result is simpler source code, and
much simpler code generation.
It also measn that when I introduce asm goto with input for
"unsafe_get_user()", there are no nasty interactions with the
__get_user() code.
Cc: Al Viro
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Peter Zijlstra
Signed-off-by: Linus Torvalds
---
arch/x86/include/asm/uaccess.h | 128 ++---
arch/x86/lib/getuser.S | 60
2 files changed, 114 insertions(+), 74 deletions(-)
diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index ecefaffd15d4..cf5a3f61db3b 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -96,25 +96,14 @@ static inline bool pagefault_disabled(void);
likely(!__range_not_ok(addr, size, user_addr_max())); \
})
-/*
- * These are the main single-value transfer routines. They automatically
- * use the right size if we just have the right pointer type.
- *
- * This gets kind of ugly. We want to return _two_ values in "get_user()"
- * and yet we don't want to do any pointers, because that is too much
- * of a performance impact. Thus we have a few rather ugly macros here,
- * and hide all the ugliness from the user.
- *
- * The "__xxx" versions of the user access functions are versions that
- * do not verify the address space, that must have been done previously
- * with a separate "access_ok()" call (this is used when we do multiple
- *
RE: remove the last set_fs() in common code, and remove it for x86 and powerpc v3
From: Christophe Leroy > Sent: 05 September 2020 08:16 > > Le 04/09/2020 à 23:01, David Laight a écrit : > > From: Alexey Dobriyan > >> Sent: 04 September 2020 18:58 ... > > What is this strange %fs register you are talking about. > > Figure 2-4 only has CS, DS, SS and ES. > > > > Intel added registers FS and GS in the i386 I know, I've got both the 'iAPX 286 Programmer's Reference Manual' and the '80386 Programmer's Reference Manual' on my shelf. I don't have the 8088 book though - which I used in 1982. The old books are a lot easier to read if, for instance, you are trying to work out how to back and forth to real mode to do bios calls. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: remove the last set_fs() in common code, and remove it for x86 and powerpc v3
Le 04/09/2020 à 23:01, David Laight a écrit :
From: Alexey Dobriyan
Sent: 04 September 2020 18:58
On Fri, Sep 04, 2020 at 08:00:24AM +0200, Ingo Molnar wrote:
* Christoph Hellwig wrote:
this series removes the last set_fs() used to force a kernel address
space for the uaccess code in the kernel read/write/splice code, and then
stops implementing the address space overrides entirely for x86 and
powerpc.
Cool! For the x86 bits:
Acked-by: Ingo Molnar
set_fs() is older than some kernel hackers!
$ cd linux-0.11/
$ find . -type f -name '*.h' | xargs grep -e set_fs -w -n -A3
./include/asm/segment.h:61:extern inline void set_fs(unsigned long val)
./include/asm/segment.h-62-{
./include/asm/segment.h-63- __asm__("mov %0,%%fs"::"a" ((unsigned
short) val));
./include/asm/segment.h-64-}
What is this strange %fs register you are talking about.
Figure 2-4 only has CS, DS, SS and ES.
Intel added registers FS and GS in the i386
Christophe
RE: remove the last set_fs() in common code, and remove it for x86 and powerpc v3
From: Alexey Dobriyan
> Sent: 04 September 2020 18:58
>
> On Fri, Sep 04, 2020 at 08:00:24AM +0200, Ingo Molnar wrote:
> > * Christoph Hellwig wrote:
> > > this series removes the last set_fs() used to force a kernel address
> > > space for the uaccess code in the kernel read/write/splice code, and then
> > > stops implementing the address space overrides entirely for x86 and
> > > powerpc.
> >
> > Cool! For the x86 bits:
> >
> > Acked-by: Ingo Molnar
>
> set_fs() is older than some kernel hackers!
>
> $ cd linux-0.11/
> $ find . -type f -name '*.h' | xargs grep -e set_fs -w -n -A3
> ./include/asm/segment.h:61:extern inline void set_fs(unsigned long val)
> ./include/asm/segment.h-62-{
> ./include/asm/segment.h-63- __asm__("mov %0,%%fs"::"a" ((unsigned
> short) val));
> ./include/asm/segment.h-64-}
What is this strange %fs register you are talking about.
Figure 2-4 only has CS, DS, SS and ES.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
Re: remove the last set_fs() in common code, and remove it for x86 and powerpc v3
On Fri, Sep 4, 2020 at 10:58 AM Alexey Dobriyan wrote:
>
> set_fs() is older than some kernel hackers!
>
> $ cd linux-0.11/
> $ find . -type f -name '*.h' | xargs grep -e set_fs -w -n -A3
Oh, it's older than that. It was there (as set_fs) in 0.10, and may
even predate that. But sadly, I don't have tar-balls for 0.02 and
0.03, so can't check.
The actual use of %fs as the user space segment is already there in
0.01, but there was no 'set_fs()'. That was a simpler and more direct
time, and "get_fs()" looked like this back then:
#define _fs() ({ \
register unsigned short __res; \
__asm__("mov %%fs,%%ax":"=a" (__res):); \
__res;})
and all the setting was basically part of the kernel entry asm and. Lovely.
Linus
Re: remove the last set_fs() in common code, and remove it for x86 and powerpc v3
On Fri, Sep 04, 2020 at 08:00:24AM +0200, Ingo Molnar wrote:
> * Christoph Hellwig wrote:
> > this series removes the last set_fs() used to force a kernel address
> > space for the uaccess code in the kernel read/write/splice code, and then
> > stops implementing the address space overrides entirely for x86 and
> > powerpc.
>
> Cool! For the x86 bits:
>
> Acked-by: Ingo Molnar
set_fs() is older than some kernel hackers!
$ cd linux-0.11/
$ find . -type f -name '*.h' | xargs grep -e set_fs -w -n -A3
./include/asm/segment.h:61:extern inline void set_fs(unsigned long val)
./include/asm/segment.h-62-{
./include/asm/segment.h-63- __asm__("mov %0,%%fs"::"a" ((unsigned
short) val));
./include/asm/segment.h-64-}
Re: remove the last set_fs() in common code, and remove it for x86 and powerpc v3
* Christoph Hellwig wrote: > Hi all, > > this series removes the last set_fs() used to force a kernel address > space for the uaccess code in the kernel read/write/splice code, and then > stops implementing the address space overrides entirely for x86 and > powerpc. Cool! For the x86 bits: Acked-by: Ingo Molnar Thanks, Ingo
Re: remove the last set_fs() in common code, and remove it for x86 and powerpc v3
On Thu, Sep 3, 2020 at 7:22 AM Christoph Hellwig wrote: > > [Note to Linus: I'd like to get this into linux-next rather earlier > than later. Do you think it is ok to add this tree to linux-next?] This whole series looks really good to me now, with each patch looking like a clear cleanup on its own. So ack on the whole series, and yes, please get this into linux-next and ready for 5.10. Whether through Al or something else. Thanks, Linus
Re: remove the last set_fs() in common code, and remove it for x86 and powerpc v3
On Thu, Sep 03, 2020 at 04:30:03PM +0200, Christoph Hellwig wrote: > On Thu, Sep 03, 2020 at 03:28:03PM +0100, Al Viro wrote: > > On Thu, Sep 03, 2020 at 04:22:28PM +0200, Christoph Hellwig wrote: > > > > > Besides x86 and powerpc I plan to eventually convert all other > > > architectures, although this will be a slow process, starting with the > > > easier ones once the infrastructure is merged. The process to convert > > > architectures is roughtly: > > > > > > (1) ensure there is no set_fs(KERNEL_DS) left in arch specific code > > > (2) implement __get_kernel_nofault and __put_kernel_nofault > > > (3) remove the arch specific address limitation functionality > > > > The one to really watch out for is sparc; I have something in that > > direction, will resurrect as soon as I'm done with eventpoll analysis... > > > > I can live with this series; do you want that in vfs.git#for-next? > > Either that or a separate tree is fine with me. It would be good to > eventually have a non-rebased stable tree so that other arch trees > can work from it, though. FWIW, vfs.git#for-next is always a merge of independent branches; I don't put stuff directly into #for-next - too easy to lose that way. IOW, that would be something like #base.set_fs, included into #for-next merge set. And I've no problem with never-rebased branches... Where in the mainline are the most recent prereqs of this series?
Re: remove the last set_fs() in common code, and remove it for x86 and powerpc v3
On Thu, Sep 03, 2020 at 03:36:29PM +0100, Al Viro wrote: > FWIW, vfs.git#for-next is always a merge of independent branches; I don't > put stuff directly into #for-next - too easy to lose that way. > > IOW, that would be something like #base.set_fs, included into #for-next > merge set. And I've no problem with never-rebased branches... > > Where in the mainline are the most recent prereqs of this series? I can't think of anything past -rc1, but I haven't actually checked.
Re: remove the last set_fs() in common code, and remove it for x86 and powerpc v3
On Thu, Sep 03, 2020 at 03:28:03PM +0100, Al Viro wrote: > On Thu, Sep 03, 2020 at 04:22:28PM +0200, Christoph Hellwig wrote: > > > Besides x86 and powerpc I plan to eventually convert all other > > architectures, although this will be a slow process, starting with the > > easier ones once the infrastructure is merged. The process to convert > > architectures is roughtly: > > > > (1) ensure there is no set_fs(KERNEL_DS) left in arch specific code > > (2) implement __get_kernel_nofault and __put_kernel_nofault > > (3) remove the arch specific address limitation functionality > > The one to really watch out for is sparc; I have something in that > direction, will resurrect as soon as I'm done with eventpoll analysis... > > I can live with this series; do you want that in vfs.git#for-next? Either that or a separate tree is fine with me. It would be good to eventually have a non-rebased stable tree so that other arch trees can work from it, though.
Re: remove the last set_fs() in common code, and remove it for x86 and powerpc v3
On Thu, Sep 03, 2020 at 04:22:28PM +0200, Christoph Hellwig wrote: > Besides x86 and powerpc I plan to eventually convert all other > architectures, although this will be a slow process, starting with the > easier ones once the infrastructure is merged. The process to convert > architectures is roughtly: > > (1) ensure there is no set_fs(KERNEL_DS) left in arch specific code > (2) implement __get_kernel_nofault and __put_kernel_nofault > (3) remove the arch specific address limitation functionality The one to really watch out for is sparc; I have something in that direction, will resurrect as soon as I'm done with eventpoll analysis... I can live with this series; do you want that in vfs.git#for-next?
