Hi Joerg,
On Mon, 12 Mar 2007, Joerg Roedel wrote:
+#define RDTSCP .byte 0x0f, 0x01, 0xf9
+ alternative_io_two(cpuid\nrdtsc,
+ rdtsc, X86_FEATURE_SYNC_RDTSC,
+ .byte 0x0f, 0x01, 0xf9, X86_FEATURE_RDTSCP,
why not use the RDTSCP macro
Hi,
On Tue, 28 Aug 2007, Sam Ravnborg wrote:
Googeling I did not find a good description of where __extension__ can
be used so I fail to see where in the parse.y file I shal add the
keyword. I think __extension__ may be used both as a part of an
expression AND as part of a typedef (as in
Hi,
On Mon, 6 Aug 2007, Mike Frysinger wrote:
On 8/6/07, H. Peter Anvin [EMAIL PROTECTED] wrote:
Olaf Hering wrote:
Remove the __STRICT_ANSI__ check from the __u64/__s64 declaration on
32bit targets.
Here is the reason why we think the check should be relaxed:
I think the
Hi,
On Fri, 2 Sep 2005, Adrian Bunk wrote:
extern inline doesn't make much sense.
It does. It's a GCC extension which says never ever emit an out-of-line
version of this function, not even if its address is taken, i.e. it's
implicitely assumed, that if there is a need for such out-of-line
Hi,
On Tue, 6 Sep 2005, Terrence Miller wrote:
Andi Kleen wrote:
I don't think the functionality of having single copies in case
an out of line version was needed was ever required by the Linux kernel.
But shouldn't the compiler that compiles Linux be C99 compliant?
As extern inline is
Hi,
On Fri, 21 Feb 2014, Paul E. McKenney wrote:
And with conservative I mean everything is a source of a dependency, and
hence can't be removed, reordered or otherwise fiddled with, and that
includes code sequences where no atomic objects are anywhere in sight [1].
In the light of
Hi,
On Mon, 24 Feb 2014, Linus Torvalds wrote:
To me that reads like
int i;
int *q = i;
int **p = q;
atomic_XXX (p, CONSUME);
orders against accesses '*p', '**p', '*q' and 'i'. Thus it seems they
want to say that it orders against aliased storage - but then go
Hi,
On Thu, 20 Feb 2014, Linus Torvalds wrote:
But I'm pretty sure that any compiler guy must *hate* that current odd
dependency-generation part, and if I was a gcc person, seeing that
bugzilla entry Torvald pointed at, I would personally want to
dismember somebody with a rusty spoon..
Yes.
Hi,
On Fri, 9 May 2014, Pavel Machek wrote:
Ok, one big question: you are replacing single functions, and assume
that's ok, right?
But ... is it ok? gcc is allowed to do optimalization on whole source
file (and whole source tree with LTO). How do you prevent situation
where changing
Hi,
On Fri, 5 Dec 2014, Alexander Graf wrote:
I don't have a full distribution for you yet, but we'll start to switch
to the 2.25 branch soon.
Michael, what are you plans on when a first armv7 Factory build based on
2.25 would be available?
2.25 isn't released yet, but I just submitted
Hi,
On Fri, 1 May 2015, Peter Hurley wrote:
I don't think this a real bug, in the sense that pty i/o is not
synchronous, in the same way that tty i/o is not synchronous.
Here's what I wrote internally about my speculations about this being a
bug or not:
I also never hit it with pipes
Hi,
On Mon, 4 May 2015, Peter Hurley wrote:
I think it would be a shame if ptrace() usage forced a whole class of
i/o to be synchronous.
I think Neils patch doesn't do that, does it? If it has an indication
that in fact some data must be there but isn't it pulls it, otherwise it's
the
Hi,
On Tue, 16 Jun 2015, Enrico Mioso wrote:
Hi guys.
First of all - thank you for the discussion, and everything.
I am on arch linux, regularly upgraded.
$ as --version
This assembler was configured for a target of `i686-pc-linux-gnu'.
I attach you the PKGBUILD file - the brilliant
Hello,
On Mon, 15 Jun 2015, Borislav Petkov wrote:
Hmm, so I did start my oS13.2 i386 guest:
$ as --version
GNU assembler (GNU Binutils; openSUSE 13.2) 2.24.0.20140403-6.1
That won't show the issue. Our binutils are compiled with support for
multiple targets, among them 64bit ones, and
Hi,
On Sun, 14 Jun 2015, Borislav Petkov wrote:
arch/x86/kernel/head_32.S:66: Warning: shift count out of range (32 is not
between 0 and 31)
That's
LOWMEM_PAGES = (((132) - __PAGE_OFFSET) PAGE_SHIFT)
and a 32-bit build. So gas hasn't been complaning so far about this.
This
Hi,
On Wed, 20 May 2015, Paul E. McKenney wrote:
I'm not sure... you'd require the compiler to perform static analysis of
loops to determine the state of the machine when they exit (if they exit!)
in order to show whether or not a dependency is carried to subsequent
operations. If it
Hi,
On Thu, 21 May 2015, Paul E. McKenney wrote:
The point is -exactly- to codify the current state of affairs.
Ah, I see, so it's not yet about creating a more useful (for compilers,
that is) model.
char * fancy_assign (char *in) { return in; }
...
char *x, *y;
x =
Hi,
On Wed, 10 Feb 2016, Borislav Petkov wrote:
> --- a/arch/x86/include/asm/tlbflush.h
> +++ b/arch/x86/include/asm/tlbflush.h
> @@ -23,7 +23,7 @@ static inline void __invpcid(unsigned long pcid, unsigned
> long addr,
>* invpcid (%rcx), %rax in long mode.
>*/
> asm
Hi,
On Sat, 27 Feb 2016, Paul E. McKenney wrote:
> But we do already have something very similar with signed integer
> overflow. If the compiler can see a way to generate faster code that
> does not handle the overflow case, then the semantics suddenly change
> from twos-complement arithmetic
Hi,
On Sun, 28 Feb 2016, Linus Torvalds wrote:
> > So the kernel obviously is already using its own C dialect, that is
> > pretty far from standard C. All these options also have a negative
> > impact on the performance of the generated code.
>
> They really don't.
They do.
> Have you ever
Hi,
On Thu, 21 Jan 2016, H. Peter Anvin wrote:
> Something that confuses me is that gcc seems to give these sections the
> "aw" attributes which makes as complain. This might be a gcc bug.
Workaround: use an (possibly empty) intializer:
struct foo {int i;};
const struct foo
Hi,
On Thu, 5 Oct 2017, Borislav Petkov wrote:
> On Thu, Oct 05, 2017 at 02:35:33PM +0200, Mathias Krause wrote:
> > Note the "<"! ...comment is wrong, though the implementation works!
>
> I know, I realized that when I looked at alternative-asm.h. Wanted to
> double-check it with Micha first.
Hi,
On Thu, 8 Nov 2018, Borislav Petkov wrote:
> And frankly, I don't see why we should be fixing all those. So what if a
> global function does't have a previous prototype declaration?!
>
> Micha, is there anything "useful" that warning bitches about or should
> we disable it?
What tglx
Hi,
On Fri, 2 Sep 2005, Adrian Bunk wrote:
> "extern inline" doesn't make much sense.
It does. It's a GCC extension which says "never ever emit an out-of-line
version of this function, not even if its address is taken", i.e. it's
implicitely assumed, that if there is a need for such
Hi,
On Tue, 6 Sep 2005, Terrence Miller wrote:
> Andi Kleen wrote:
> > I don't think the functionality of having single copies in case
> > an out of line version was needed was ever required by the Linux kernel.
>
> But shouldn't the compiler that compiles Linux be C99 compliant?
As "extern
Hi Joerg,
On Mon, 12 Mar 2007, Joerg Roedel wrote:
> > >+#define RDTSCP ".byte 0x0f, 0x01, 0xf9"
> > >+ alternative_io_two("cpuid\nrdtsc",
> > >+ "rdtsc", X86_FEATURE_SYNC_RDTSC,
> > >+ ".byte 0x0f, 0x01, 0xf9", X86_FEATURE_RDTSCP,
> > >
> >
> > why
Hi,
On Tue, 28 Aug 2007, Sam Ravnborg wrote:
> Googeling I did not find a good description of where __extension__ can
> be used so I fail to see where in the parse.y file I shal add the
> keyword. I think __extension__ may be used both as a part of an
> expression AND as part of a typedef (as
Hi,
On Mon, 6 Aug 2007, Mike Frysinger wrote:
> On 8/6/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> > Olaf Hering wrote:
> > >
> > > Remove the __STRICT_ANSI__ check from the __u64/__s64 declaration on
> > > 32bit targets.
> > >
> > > Here is the reason why we think the check should be
Hi,
On Thu, 20 Feb 2014, Linus Torvalds wrote:
> But I'm pretty sure that any compiler guy must *hate* that current odd
> dependency-generation part, and if I was a gcc person, seeing that
> bugzilla entry Torvald pointed at, I would personally want to
> dismember somebody with a rusty spoon..
Hi,
On Fri, 21 Feb 2014, Paul E. McKenney wrote:
> > And with conservative I mean "everything is a source of a dependency, and
> > hence can't be removed, reordered or otherwise fiddled with", and that
> > includes code sequences where no atomic objects are anywhere in sight [1].
> > In the
Hi,
On Mon, 24 Feb 2014, Linus Torvalds wrote:
> > To me that reads like
> >
> > int i;
> > int *q =
> > int **p =
> >
> > atomic_XXX (p, CONSUME);
> >
> > orders against accesses '*p', '**p', '*q' and 'i'. Thus it seems they
> > want to say that it orders against aliased storage -
Hi,
On Fri, 9 May 2014, Pavel Machek wrote:
> Ok, one big question: you are replacing single functions, and assume
> that's ok, right?
>
> But ... is it ok? gcc is allowed to do optimalization on whole source
> file (and whole source tree with LTO). How do you prevent situation
> where
Hi,
On Thu, 5 Oct 2017, Borislav Petkov wrote:
> On Thu, Oct 05, 2017 at 02:35:33PM +0200, Mathias Krause wrote:
> > Note the "<"! ...comment is wrong, though the implementation works!
>
> I know, I realized that when I looked at alternative-asm.h. Wanted to
> double-check it with Micha first.
Hello,
even though we hashed it out downthread, let me make some additional
remarks:
On Thu, 24 Sep 2020, Borislav Petkov wrote:
> > /* MOVDIR64B [rdx], rax */
This comment is confusing as it uses Intel syntax for the operand forms,
but AT order (dest last).
> volatile struct {
Hi,
On Wed, 17 Apr 2019, Linus Torvalds wrote:
> So I see no upside to changing it.
As long as the memory clobber stays (and it can't be removed in the
general case, as you say) the change has no practical effect.
It does have a psychological upside, though: people won't continue to
wonder
Hi,
On Thu, 8 Nov 2018, Borislav Petkov wrote:
> And frankly, I don't see why we should be fixing all those. So what if a
> global function does't have a previous prototype declaration?!
>
> Micha, is there anything "useful" that warning bitches about or should
> we disable it?
What tglx
Hi,
On Wed, 20 May 2015, Paul E. McKenney wrote:
> > > I'm not sure... you'd require the compiler to perform static analysis of
> > > loops to determine the state of the machine when they exit (if they exit!)
> > > in order to show whether or not a dependency is carried to subsequent
> > >
Hi,
On Thu, 21 May 2015, Paul E. McKenney wrote:
> The point is -exactly- to codify the current state of affairs.
Ah, I see, so it's not yet about creating a more useful (for compilers,
that is) model.
> > char * fancy_assign (char *in) { return in; }
> > ...
> > char *x, *y;
> >
> >
Hi,
On Fri, 1 May 2015, Peter Hurley wrote:
> I don't think this a real bug, in the sense that pty i/o is not
> synchronous, in the same way that tty i/o is not synchronous.
Here's what I wrote internally about my speculations about this being a
bug or not:
> > I also never hit it with pipes
Hi,
On Mon, 4 May 2015, Peter Hurley wrote:
> I think it would be a shame if ptrace() usage forced a whole class of
> i/o to be synchronous.
I think Neils patch doesn't do that, does it? If it has an indication
that in fact some data must be there but isn't it pulls it, otherwise it's
the
Hi,
On Sun, 14 Jun 2015, Borislav Petkov wrote:
> > arch/x86/kernel/head_32.S:66: Warning: shift count out of range (32 is not
> > between 0 and 31)
>
> That's
>
> LOWMEM_PAGES = (((1<<32) - __PAGE_OFFSET) >> PAGE_SHIFT)
>
> and a 32-bit build. So gas hasn't been complaning so far about
Hello,
On Mon, 15 Jun 2015, Borislav Petkov wrote:
> Hmm, so I did start my oS13.2 i386 guest:
>
> $ as --version
> GNU assembler (GNU Binutils; openSUSE 13.2) 2.24.0.20140403-6.1
That won't show the issue. Our binutils are compiled with support for
multiple targets, among them 64bit ones,
Hi,
On Tue, 16 Jun 2015, Enrico Mioso wrote:
> Hi guys.
> First of all - thank you for the discussion, and everything.
>
> I am on arch linux, regularly upgraded.
> $ as --version
> This assembler was configured for a target of `i686-pc-linux-gnu'.
>
> I attach you the PKGBUILD file - the
Hi,
On Fri, 5 Dec 2014, Alexander Graf wrote:
> I don't have a full distribution for you yet, but we'll start to switch
> to the 2.25 branch soon.
>
> Michael, what are you plans on when a first armv7 Factory build based on
> 2.25 would be available?
2.25 isn't released yet, but I just
Hi,
On Sun, 28 Feb 2016, Linus Torvalds wrote:
> > So the kernel obviously is already using its own C dialect, that is
> > pretty far from standard C. All these options also have a negative
> > impact on the performance of the generated code.
>
> They really don't.
They do.
> Have you ever
Hi,
On Sat, 27 Feb 2016, Paul E. McKenney wrote:
> But we do already have something very similar with signed integer
> overflow. If the compiler can see a way to generate faster code that
> does not handle the overflow case, then the semantics suddenly change
> from twos-complement arithmetic
Hi,
On Wed, 10 Feb 2016, Borislav Petkov wrote:
> --- a/arch/x86/include/asm/tlbflush.h
> +++ b/arch/x86/include/asm/tlbflush.h
> @@ -23,7 +23,7 @@ static inline void __invpcid(unsigned long pcid, unsigned
> long addr,
>* invpcid (%rcx), %rax in long mode.
>*/
> asm
Hi,
On Thu, 21 Jan 2016, H. Peter Anvin wrote:
> Something that confuses me is that gcc seems to give these sections the
> "aw" attributes which makes as complain. This might be a gcc bug.
Workaround: use an (possibly empty) intializer:
struct foo {int i;};
const struct foo
Hello,
On Tue, 2 Feb 2021, Borislav Petkov wrote:
> + Micha.
Huh, someone found my video ;-)
> > > > > > attributes for example), but is far from being able to compile
> > > > > > a kernel
A _current_ kernel maybe :) Some 4.6 x86-64 kernel in qemu in a certain
config plus a little patches
49 matches
Mail list logo
