On Sat 2020-08-22 11:51:56, Sedat Dilek wrote:
> On Sat, Aug 22, 2020 at 11:23 AM Sedat Dilek wrote:
> >
> > On Sat, Aug 22, 2020 at 10:42 AM Segher Boessenkool
> > wrote:
> > >
> > > Hi Arvind,
> > >
> > > On Fri, Aug 21, 2020 at 11:55:52PM -0400, Arvind Sankar wrote:
> > > > Cc Segher.
> > > >
From: Arvind Sankar
> Sent: 22 August 2020 22:17
...
> Assuming we don't want to risk removing force_order, I'd suggest
> - make it an input/output operand, so it enforces ordering fully.
> - either restrict it to gcc < 8, or just provide a proper definition in
> some file (maybe arch/x86/kernel/
On Sat, Aug 22, 2020 at 05:10:21PM -0700, Linus Torvalds wrote:
> On Sat, Aug 22, 2020 at 4:11 PM Arvind Sankar wrote:
> >
> > Actually, is a memory clobber required for correctness? Memory accesses
> > probably shouldn't be reordered across a CRn write. Is asm volatile
> > enough to stop that or
On Sat, Aug 22, 2020 at 4:11 PM Arvind Sankar wrote:
>
> Actually, is a memory clobber required for correctness? Memory accesses
> probably shouldn't be reordered across a CRn write. Is asm volatile
> enough to stop that or do you need a memory clobber?
You do need a memory clobber if you really
On Sat, Aug 22, 2020 at 02:08:27PM -0700, Linus Torvalds wrote:
> However, in this case, can we just leave that old "__force_order" hack
> alone, and to work around the clang thing, just make a dummy
> definition of it anyway.
>
> Alternatively, just use the memory clobber. We use memory clobbers
On Sat, Aug 22, 2020 at 08:17:32PM +0200, Miguel Ojeda wrote:
> On Sat, Aug 22, 2020 at 11:52 AM Sedat Dilek wrote:
> >
> > I am asking myself who is using such ancient compilers?
>
> There are many users/companies using older versions of compilers,
> kernels and everything. GCC <= 4.9 will still
On Sat, Aug 22, 2020 at 11:17 AM Miguel Ojeda
wrote:
>
> However, the important question is whether those users/companies care
> about running the latest kernels. Many of those definitely do not want
> to touch their kernel either. For those that do, there are several
> longterms to pick from that
On Sat, Aug 22, 2020 at 11:52 AM Sedat Dilek wrote:
>
> I am asking myself who is using such ancient compilers?
There are many users/companies using older versions of compilers,
kernels and everything. GCC <= 4.9 will still be used/supported (by
third parties) for a handful of years at least.
Ho
On Sat, Aug 22, 2020 at 12:26 PM Segher Boessenkool
wrote:
> [ There is GCC 4.9.4, no one should use an older 4.9. ]
>
> I mentioned 5 for a reason: the whole function this patch is to did not
> exist before then! That does not mean the bug existed or did not exist
> before GCC 5, but it does for
On Sat, Aug 22, 2020 at 11:51:56AM +0200, Sedat Dilek wrote:
> On Sat, Aug 22, 2020 at 11:23 AM Sedat Dilek wrote:
> >
> > On Sat, Aug 22, 2020 at 10:42 AM Segher Boessenkool
> > wrote:
> > >
> > > Hi Arvind,
> > >
> > > On Fri, Aug 21, 2020 at 11:55:52PM -0400, Arvind Sankar wrote:
> > > > Cc Se
On Sat, Aug 22, 2020 at 11:23 AM Sedat Dilek wrote:
>
> On Sat, Aug 22, 2020 at 10:42 AM Segher Boessenkool
> wrote:
> >
> > Hi Arvind,
> >
> > On Fri, Aug 21, 2020 at 11:55:52PM -0400, Arvind Sankar wrote:
> > > Cc Segher.
> > >
> > > Segher, we were looking at gcc PR82602, where IRA could reord
On Sat, Aug 22, 2020 at 10:42 AM Segher Boessenkool
wrote:
>
> Hi Arvind,
>
> On Fri, Aug 21, 2020 at 11:55:52PM -0400, Arvind Sankar wrote:
> > Cc Segher.
> >
> > Segher, we were looking at gcc PR82602, where IRA could reorder volatile
> > asm's (reported on ARM). The fix was backported to gcc-6.
Hi Arvind,
On Fri, Aug 21, 2020 at 11:55:52PM -0400, Arvind Sankar wrote:
> Cc Segher.
>
> Segher, we were looking at gcc PR82602, where IRA could reorder volatile
> asm's (reported on ARM). The fix was backported to gcc-6.
I know ;-)
> Do you know if
> there is any reason the problem couldn't
On Sat, Aug 22, 2020 at 02:43:08AM +0200, Thomas Gleixner wrote:
> On Fri, Aug 21 2020 at 16:16, Nick Desaulniers wrote:
> > On Fri, Aug 21, 2020 at 4:04 PM Arvind Sankar wrote:
> >> On Fri, Aug 21, 2020 at 02:37:48AM +0200, Thomas Gleixner wrote:
> >> The gcc bug I linked to earlier is only fixed
On Fri, Aug 21 2020 at 16:16, Nick Desaulniers wrote:
> On Fri, Aug 21, 2020 at 4:04 PM Arvind Sankar wrote:
>> On Fri, Aug 21, 2020 at 02:37:48AM +0200, Thomas Gleixner wrote:
>> The gcc bug I linked to earlier is only fixed in gcc-6 onwards. Is that
>
> (based on https://gcc.gnu.org/bugzilla/sho
On Fri, Aug 21, 2020 at 04:16:56PM -0700, Nick Desaulniers wrote:
> On Fri, Aug 21, 2020 at 4:04 PM Arvind Sankar wrote:
> >
> > On Fri, Aug 21, 2020 at 02:37:48AM +0200, Thomas Gleixner wrote:
> > > On Thu, Aug 20 2020 at 09:06, Arvind Sankar wrote:
> > > > I don't think that's an issue, or at le
On Fri, Aug 21, 2020 at 4:04 PM Arvind Sankar wrote:
>
> On Fri, Aug 21, 2020 at 02:37:48AM +0200, Thomas Gleixner wrote:
> > On Thu, Aug 20 2020 at 09:06, Arvind Sankar wrote:
> > > I don't think that's an issue, or at least, not one where force_order
> > > helps.
> > >
> > > If the source for fo
On Fri, Aug 21, 2020 at 02:37:48AM +0200, Thomas Gleixner wrote:
> On Thu, Aug 20 2020 at 09:06, Arvind Sankar wrote:
> > I don't think that's an issue, or at least, not one where force_order
> > helps.
> >
> > If the source for foo() is not visible to the compiler, the only reason
> > force_order
On Thu, Aug 20 2020 at 09:06, Arvind Sankar wrote:
> I don't think that's an issue, or at least, not one where force_order
> helps.
>
> If the source for foo() is not visible to the compiler, the only reason
> force_order prevents the reordering is because foo() might have
> references to it, but e
On Thu, Aug 20, 2020 at 12:44:06PM +0200, Thomas Gleixner wrote:
> On Thu, Aug 13 2020 at 14:09, Arvind Sankar wrote:
> > On Thu, Aug 13, 2020 at 10:37:01AM -0700, Paul E. McKenney wrote:
> >> > Let me ask (hopefully) useful questions this time:
> >> >
> >> > Is a compiler allowed to reorder two
On Thu, Aug 13 2020 at 14:09, Arvind Sankar wrote:
> On Thu, Aug 13, 2020 at 10:37:01AM -0700, Paul E. McKenney wrote:
>> > Let me ask (hopefully) useful questions this time:
>> >
>> > Is a compiler allowed to reorder two 'asm volatile()'?
>> >
>> > Are there compilers (gcc >= 4.9 or other su
GCC toolchain simply ignores if kaslr_64.o has __force_order means the
build ends up successfully whereas LLVM toolchain and IAS breaks and
the build stops and needs explicitly commit
df6d4f9db79c1a5d6f48b59db35ccd1e9ff9adfc ("x86/boot/compressed: Don't
declare __force_order in kaslr_64.c") reverte
On Sat, Aug 15, 2020 at 10:23 AM Sedat Dilek wrote:
>
> On Sat, Aug 15, 2020 at 5:28 AM Sedat Dilek wrote:
> >
> > On Sat, Aug 15, 2020 at 2:27 AM Nick Desaulniers
> > wrote:
> > >
> > > On Fri, Aug 14, 2020 at 3:57 PM Nick Desaulniers
> > > wrote:
> > > >
> > > > On Fri, Aug 14, 2020 at 2:19 P
On Sat, Aug 15, 2020 at 5:28 AM Sedat Dilek wrote:
>
> On Sat, Aug 15, 2020 at 2:27 AM Nick Desaulniers
> wrote:
> >
> > On Fri, Aug 14, 2020 at 3:57 PM Nick Desaulniers
> > wrote:
> > >
> > > On Fri, Aug 14, 2020 at 2:19 PM Sedat Dilek wrote:
> > > >
> > > > On Fri, Aug 14, 2020 at 7:29 PM Sed
On Sat, Aug 15, 2020 at 12:46 PM Sedat Dilek wrote:
>
> On Sat, Aug 15, 2020 at 10:23 AM Sedat Dilek wrote:
> >
> > On Sat, Aug 15, 2020 at 5:28 AM Sedat Dilek wrote:
> > >
> > > On Sat, Aug 15, 2020 at 2:27 AM Nick Desaulniers
> > > wrote:
> > > >
> > > > On Fri, Aug 14, 2020 at 3:57 PM Nick D
On Fri, Aug 14, 2020 at 3:57 PM Nick Desaulniers
wrote:
>
> On Fri, Aug 14, 2020 at 2:19 PM Sedat Dilek wrote:
> >
> > On Fri, Aug 14, 2020 at 7:29 PM Sedat Dilek wrote:
> > >
> > > Thanks for the proposal.
> > >
> > > I have adapted it to fit my patchset against Linux v5.8.
> > >
> > > Both Deb
On Fri, Aug 14, 2020 at 2:19 PM Sedat Dilek wrote:
>
> On Fri, Aug 14, 2020 at 7:29 PM Sedat Dilek wrote:
> >
> > Thanks for the proposal.
> >
> > I have adapted it to fit my patchset against Linux v5.8.
> >
> > Both Debian's GCC-10 and a snapshot version of LLVM toolchain
> > v11.0.0-rc1+ seems
On Tue, Aug 4, 2020 at 2:09 AM 'Nick Desaulniers' via Clang Built
Linux wrote:
>
> On Wed, May 27, 2020 at 6:53 AM Arnd Bergmann wrote:
> >
> > When using the clang integrated assembler, we get a reference
> > to __force_order that should normally get ignored in a few
> > rare cases:
> >
> > ERRO
On Thu, Aug 13, 2020 at 02:09:33PM -0400, Arvind Sankar wrote:
> On Thu, Aug 13, 2020 at 10:37:01AM -0700, Paul E. McKenney wrote:
> > On Thu, Aug 13, 2020 at 07:28:57PM +0200, Thomas Gleixner wrote:
> > > Nick Desaulniers writes:
> > > > On Thu, Aug 6, 2020 at 3:11 PM Thomas Gleixner
> > > > wr
On Thu, Aug 13, 2020 at 10:37:01AM -0700, Paul E. McKenney wrote:
> On Thu, Aug 13, 2020 at 07:28:57PM +0200, Thomas Gleixner wrote:
> > Nick Desaulniers writes:
> > > On Thu, Aug 6, 2020 at 3:11 PM Thomas Gleixner wrote:
> > >> > + *
> > >> > + * Clang sometimes fails to kill the reference to th
On Thu, Aug 13, 2020 at 07:28:57PM +0200, Thomas Gleixner wrote:
> Nick Desaulniers writes:
> > On Thu, Aug 6, 2020 at 3:11 PM Thomas Gleixner wrote:
> >> > + *
> >> > + * Clang sometimes fails to kill the reference to the dummy variable, so
> >> > + * provide an actual copy.
> >>
> >> Can that c
Nick Desaulniers writes:
> On Thu, Aug 6, 2020 at 3:11 PM Thomas Gleixner wrote:
>> > + *
>> > + * Clang sometimes fails to kill the reference to the dummy variable, so
>> > + * provide an actual copy.
>>
>> Can that compiler be fixed instead?
>
> I don't think so. The logic in the compiler wheth
On Wed, Aug 12, 2020 at 05:12:34PM -0700, Nick Desaulniers wrote:
> On Thu, Aug 6, 2020 at 3:11 PM Thomas Gleixner wrote:
> >
> > Arnd Bergmann writes:
> > > When using the clang integrated assembler, we get a reference
> > > to __force_order that should normally get ignored in a few
> > > rare c
From: Nick Desaulniers
> Sent: 13 August 2020 01:13
>
> On Thu, Aug 6, 2020 at 3:11 PM Thomas Gleixner wrote:
> >
> > Arnd Bergmann writes:
> > > When using the clang integrated assembler, we get a reference
> > > to __force_order that should normally get ignored in a few
> > > rare cases:
> > >
On Thu, Aug 6, 2020 at 3:11 PM Thomas Gleixner wrote:
>
> Arnd Bergmann writes:
> > When using the clang integrated assembler, we get a reference
> > to __force_order that should normally get ignored in a few
> > rare cases:
> >
> > ERROR: modpost: "__force_order" [drivers/cpufreq/powernow-k6.ko]
On Fri, Aug 7, 2020 at 12:13 AM Thomas Gleixner wrote:
>
> Sedat Dilek writes:
> > what is the status of this patch?
>
> Just looked at it.
>
> > I needed this one to be able to build VirtualBox via DKMS as an
> > out-of-tree kernel-module.
>
> Not being able to build the vbox rootkit is a featur
Sedat Dilek writes:
> what is the status of this patch?
Just looked at it.
> I needed this one to be able to build VirtualBox via DKMS as an
> out-of-tree kernel-module.
Not being able to build the vbox rootkit is a feature, not a bug.
Thanks,
tglx
Arnd Bergmann writes:
> When using the clang integrated assembler, we get a reference
> to __force_order that should normally get ignored in a few
> rare cases:
>
> ERROR: modpost: "__force_order" [drivers/cpufreq/powernow-k6.ko] undefined!
>
> Add a 'static' definition so any file in which this h
On Wed, May 27, 2020 at 6:53 AM Arnd Bergmann wrote:
>
> When using the clang integrated assembler, we get a reference
> to __force_order that should normally get ignored in a few
> rare cases:
>
> ERROR: modpost: "__force_order" [drivers/cpufreq/powernow-k6.ko] undefined!
>
> Add a 'static' defin
On Wed, May 27, 2020 at 3:53 PM Arnd Bergmann wrote:
>
> When using the clang integrated assembler, we get a reference
> to __force_order that should normally get ignored in a few
> rare cases:
>
> ERROR: modpost: "__force_order" [drivers/cpufreq/powernow-k6.ko] undefined!
>
> Add a 'static' defin
40 matches
Mail list logo
