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 befo
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.
>
niers
> ; 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, 20
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 volat
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
>
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 lea
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 peo
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 incompati
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. Si
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
incompatib
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 wil
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
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 reg
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
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, a
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 sa
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 entire
* 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:
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
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 n
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, althoug
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 inf
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 r
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.
[Note to Linus: I'd like to get this into linux-next rather earlier
t
On Tue, Sep 01, 2020 at 06:25:12PM +0100, Al Viro wrote:
> On Tue, Sep 01, 2020 at 07:13:00PM +0200, Christophe Leroy wrote:
>
> > 10.92% dd [kernel.kallsyms] [k] iov_iter_zero
>
> Interesting... Could you get an instruction-level profile inside
> iov_iter_zero(),
> along with the d
Le 01/09/2020 à 19:25, Al Viro a écrit :
On Tue, Sep 01, 2020 at 07:13:00PM +0200, Christophe Leroy wrote:
10.92% dd [kernel.kallsyms] [k] iov_iter_zero
Interesting... Could you get an instruction-level profile inside
iov_iter_zero(),
along with the disassembly of that sucke
Le 01/09/2020 à 19:25, Al Viro a écrit :
On Tue, Sep 01, 2020 at 07:13:00PM +0200, Christophe Leroy wrote:
10.92% dd [kernel.kallsyms] [k] iov_iter_zero
Interesting... Could you get an instruction-level profile inside
iov_iter_zero(),
along with the disassembly of that sucke
On Tue, Sep 01, 2020 at 06:25:12PM +0100, Al Viro wrote:
> On Tue, Sep 01, 2020 at 07:13:00PM +0200, Christophe Leroy wrote:
>
> > 10.92% dd [kernel.kallsyms] [k] iov_iter_zero
>
> Interesting... Could you get an instruction-level profile inside
> iov_iter_zero(),
> along with the d
On Tue, Sep 01, 2020 at 07:13:00PM +0200, Christophe Leroy wrote:
> 10.92% dd [kernel.kallsyms] [k] iov_iter_zero
Interesting... Could you get an instruction-level profile inside
iov_iter_zero(),
along with the disassembly of that sucker?
Hi Christoph,
Le 27/08/2020 à 17:00, Christoph Hellwig a écrit :
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.
T
> Diffstat:
Actually no diffstat here as David Howells pointed out. Here we go:
arch/Kconfig |3
arch/alpha/Kconfig |1
arch/arc/Kconfig |1
arch/arm/Kconfig |1
arch/arm64/Kconfig
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.
The file system part has been posted a few times, and the read/write
On Wed, Aug 19, 2020 at 09:16:59AM +0200, Christophe Leroy wrote:
> I made a test with only the first patch of your series: That's definitely
> the culprit. With only that patch applies, the duration is 6.64 seconds,
> that's a 25% degradation.
For the record: the first patch is:
mem: remo
Le 18/08/2020 à 20:23, Christophe Leroy a écrit :
Le 18/08/2020 à 20:05, Christoph Hellwig a écrit :
On Tue, Aug 18, 2020 at 07:46:22PM +0200, Christophe Leroy wrote:
I gave it a go on my powerpc mpc832x. I tested it on top of my newest
series that reworks the 32 bits signal handlers (see
Le 18/08/2020 à 20:05, Christoph Hellwig a écrit :
On Tue, Aug 18, 2020 at 07:46:22PM +0200, Christophe Leroy wrote:
I gave it a go on my powerpc mpc832x. I tested it on top of my newest
series that reworks the 32 bits signal handlers (see
https://patchwork.ozlabs.org/project/linuxppc-dev/lis
On Tue, Aug 18, 2020 at 07:46:22PM +0200, Christophe Leroy wrote:
> I gave it a go on my powerpc mpc832x. I tested it on top of my newest
> series that reworks the 32 bits signal handlers (see
> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=196278) with
> the microbenchmark test
Le 17/08/2020 à 09:32, Christoph Hellwig a écrit :
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.
The file syst
Adding Linus as I forgot to add him to the patch bomb, sorry..
On Mon, Aug 17, 2020 at 09:32:01AM +0200, 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
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.
The file system part has been posted a few times, and the read/write
39 matches
Mail list logo
