On Sat, Oct 12, 2019 at 12:15:42PM +0200, Stefan Wahren wrote:
> Hi,
>
> Am 03.10.19 um 18:36 schrieb Will Deacon:
> > On Wed, Oct 02, 2019 at 01:39:40PM -0700, Linus Torvalds wrote:
> >> On Wed, Oct 2, 2019 at 5:56 AM Geert Uytterhoeven
> >> wrote:
> Then use the C preprocessor to force th
On Sat, Oct 12, 2019 at 7:21 PM Stefan Wahren wrote:
>
> Hi,
>
> Am 03.10.19 um 18:36 schrieb Will Deacon:
> > On Wed, Oct 02, 2019 at 01:39:40PM -0700, Linus Torvalds wrote:
> >> On Wed, Oct 2, 2019 at 5:56 AM Geert Uytterhoeven
> >> wrote:
> Then use the C preprocessor to force the inlini
Hi,
Am 03.10.19 um 18:36 schrieb Will Deacon:
> On Wed, Oct 02, 2019 at 01:39:40PM -0700, Linus Torvalds wrote:
>> On Wed, Oct 2, 2019 at 5:56 AM Geert Uytterhoeven
>> wrote:
Then use the C preprocessor to force the inlining. I'm sorry it's not
as pretty as static inline functions.
>>
Hi Miguel,
On Thu, Oct 3, 2019 at 10:21 PM Miguel Ojeda
wrote:
> On Thu, Oct 3, 2019 at 7:29 PM Linus Torvalds
> wrote:
> > On Thu, Oct 3, 2019 at 10:24 AM Masahiro Yamada
> > wrote:
> > >
> > > I just want to annotate __always_inline for the case
> > > "2. code that if not inlined is somehow n
On Thu, Oct 3, 2019 at 7:29 PM Linus Torvalds
wrote:
>
> On Thu, Oct 3, 2019 at 10:24 AM Masahiro Yamada
> wrote:
> >
> > I just want to annotate __always_inline for the case
> > "2. code that if not inlined is somehow not correct."
>
> Oh, I support that entirely - if only for documentation.
>
>
On Thu, Oct 3, 2019 at 10:24 AM Masahiro Yamada
wrote:
>
> I just want to annotate __always_inline for the case
> "2. code that if not inlined is somehow not correct."
Oh, I support that entirely - if only for documentation.
But I do *not* support the dismissal of the architecture maintainers
co
On Fri, Oct 4, 2019 at 2:02 AM Linus Torvalds
wrote:
>
> On Wed, Oct 2, 2019 at 7:11 PM Masahiro Yamada
> wrote:
> >
> > Macrofying the 'inline' is a horrid mistake that makes incorrect code work.
> > It would eternally prevent people from writing portable, correct code.
> > Please do not encoura
On Thu, Oct 3, 2019 at 10:01 AM Linus Torvalds
wrote:
>
> If this is purely about the fact that x86 is different from other
> architectures, then let's remove the "compiler can do stupid things"
> option on x86 too. It was never clear that it was a huge advantage.
Side note: what might be an actu
On Wed, Oct 02, 2019 at 01:39:40PM -0700, Linus Torvalds wrote:
> On Wed, Oct 2, 2019 at 5:56 AM Geert Uytterhoeven
> wrote:
> >
> > >
> > > Then use the C preprocessor to force the inlining. I'm sorry it's not
> > > as pretty as static inline functions.
> >
> > Which makes us lose the baby^H^H^
On Wed, Oct 2, 2019 at 7:11 PM Masahiro Yamada
wrote:
>
> Macrofying the 'inline' is a horrid mistake that makes incorrect code work.
> It would eternally prevent people from writing portable, correct code.
> Please do not encourage to hide problems.
Honestly, if the alternative to hiding problem
On Thu, Oct 3, 2019 at 5:46 AM Linus Torvalds
wrote:
>
> On Wed, Oct 2, 2019 at 5:56 AM Geert Uytterhoeven
> wrote:
> >
> > >
> > > Then use the C preprocessor to force the inlining. I'm sorry it's not
> > > as pretty as static inline functions.
> >
> > Which makes us lose the baby^H^H^H^Htype
On Wed, Oct 2, 2019 at 5:56 AM Geert Uytterhoeven wrote:
>
> >
> > Then use the C preprocessor to force the inlining. I'm sorry it's not
> > as pretty as static inline functions.
>
> Which makes us lose the baby^H^H^H^Htype checking performed
> on function parameters, requiring to add more ugly c
On Wed, Oct 02, 2019 at 02:55:50PM +0200, Geert Uytterhoeven wrote:
> On Wed, Oct 2, 2019 at 6:33 AM Nick Desaulniers
> wrote:
> > On Tue, Oct 1, 2019 at 11:14 AM Russell King - ARM Linux admin
> > wrote:
> > > On Tue, Oct 01, 2019 at 11:00:11AM -0700, Nick Desaulniers wrote:
> > > > On Tue, Oct
Hi Nick,
On Wed, Oct 2, 2019 at 6:33 AM Nick Desaulniers wrote:
> On Tue, Oct 1, 2019 at 11:14 AM Russell King - ARM Linux admin
> wrote:
> > On Tue, Oct 01, 2019 at 11:00:11AM -0700, Nick Desaulniers wrote:
> > > On Tue, Oct 1, 2019 at 10:55 AM Russell King - ARM Linux admin
> > > wrote:
> > >
On Tue, Oct 01, 2019 at 02:32:54PM -0700, Nick Desaulniers wrote:
> On Tue, Oct 1, 2019 at 2:26 PM Russell King - ARM Linux admin
> wrote:
> >
> > On Tue, Oct 01, 2019 at 09:59:38PM +0100, Russell King - ARM Linux admin
> > wrote:
> > > On Tue, Oct 01, 2019 at 01:21:44PM -0700, Nick Desaulniers w
On Tue, Oct 1, 2019 at 2:26 PM Russell King - ARM Linux admin
wrote:
>
> On Tue, Oct 01, 2019 at 09:59:38PM +0100, Russell King - ARM Linux admin
> wrote:
> > On Tue, Oct 01, 2019 at 01:21:44PM -0700, Nick Desaulniers wrote:
> > > On Tue, Oct 1, 2019 at 11:14 AM Russell King - ARM Linux admin
> >
On Tue, Oct 01, 2019 at 09:59:38PM +0100, Russell King - ARM Linux admin wrote:
> On Tue, Oct 01, 2019 at 01:21:44PM -0700, Nick Desaulniers wrote:
> > On Tue, Oct 1, 2019 at 11:14 AM Russell King - ARM Linux admin
> > wrote:
> > >
> > > On Tue, Oct 01, 2019 at 11:00:11AM -0700, Nick Desaulniers w
On Tue, Oct 1, 2019 at 2:06 PM Miguel Ojeda
wrote:
>
> On Tue, Oct 1, 2019 at 10:53 PM Arnd Bergmann wrote:
> >
> > 1. is clearly the most common case, but there is also
> >
> > 4. Some compiler version (possibly long gone, possibly still current)
> > makes bad inlining decisions that result in h
On Tue, Oct 1, 2019 at 10:53 PM Arnd Bergmann wrote:
>
> 1. is clearly the most common case, but there is also
>
> 4. Some compiler version (possibly long gone, possibly still current)
> makes bad inlining decisions that result in horrible but functionally
> correct object code for a particular fu
On Tue, Oct 01, 2019 at 01:21:44PM -0700, Nick Desaulniers wrote:
> On Tue, Oct 1, 2019 at 11:14 AM Russell King - ARM Linux admin
> wrote:
> >
> > On Tue, Oct 01, 2019 at 11:00:11AM -0700, Nick Desaulniers wrote:
> > > On Tue, Oct 1, 2019 at 10:55 AM Russell King - ARM Linux admin
> > > wrote:
>
On Tue, Oct 1, 2019 at 10:21 PM 'Nick Desaulniers' via Clang Built
Linux wrote:
> On Tue, Oct 1, 2019 at 11:14 AM Russell King - ARM Linux admin
> wrote:
> >
> > On Tue, Oct 01, 2019 at 11:00:11AM -0700, Nick Desaulniers wrote:
> > > On Tue, Oct 1, 2019 at 10:55 AM Russell King - ARM Linux admin
On Tue, Oct 1, 2019 at 11:14 AM Russell King - ARM Linux admin
wrote:
>
> On Tue, Oct 01, 2019 at 11:00:11AM -0700, Nick Desaulniers wrote:
> > On Tue, Oct 1, 2019 at 10:55 AM Russell King - ARM Linux admin
> > wrote:
> > >
> > > On Tue, Oct 01, 2019 at 10:44:43AM -0700, Nick Desaulniers wrote:
>
On Tue, Oct 01, 2019 at 11:00:11AM -0700, Nick Desaulniers wrote:
> On Tue, Oct 1, 2019 at 10:55 AM Russell King - ARM Linux admin
> wrote:
> >
> > On Tue, Oct 01, 2019 at 10:44:43AM -0700, Nick Desaulniers wrote:
> > > I apologize; I don't mean to be difficult. I would just like to avoid
> > > s
On Tue, Oct 1, 2019 at 10:55 AM Russell King - ARM Linux admin
wrote:
>
> On Tue, Oct 01, 2019 at 10:44:43AM -0700, Nick Desaulniers wrote:
> > I apologize; I don't mean to be difficult. I would just like to avoid
> > surprises when code written with the assumption that it will be
> > inlined is
On Tue, Oct 01, 2019 at 10:44:43AM -0700, Nick Desaulniers wrote:
> I apologize; I don't mean to be difficult. I would just like to avoid
> surprises when code written with the assumption that it will be
> inlined is not. It sounds like we found one issue in arm32 and one in
> arm64 related to ou
On Tue, Oct 1, 2019 at 10:01 AM Will Deacon wrote:
>
> On Tue, Oct 01, 2019 at 09:32:25AM -0700, Nick Desaulniers wrote:
> > On Tue, Oct 1, 2019 at 2:28 AM Will Deacon wrote:
> > > On Mon, Sep 30, 2019 at 02:50:10PM -0700, Nick Desaulniers wrote:
> > > > In this case, if there's a known codegen b
On Tue, Oct 01, 2019 at 09:32:25AM -0700, Nick Desaulniers wrote:
> On Tue, Oct 1, 2019 at 2:28 AM Will Deacon wrote:
> > On Mon, Sep 30, 2019 at 02:50:10PM -0700, Nick Desaulniers wrote:
> > > In this case, if there's a known codegen bug in a particular compiler
> > > or certain versions of it, I
On Tue, Oct 1, 2019 at 2:28 AM Will Deacon wrote:
>
> Hi Nick,
>
> On Mon, Sep 30, 2019 at 02:50:10PM -0700, Nick Desaulniers wrote:
> > So __attribute__((always_inline)) doesn't guarantee that code will be
> > inlined. For instance in LLVM's inliner, it asks/answers "should I
> > inline" and "ca
On Tue, Oct 01, 2019 at 06:39:34PM +0900, Masahiro Yamada wrote:
> On Mon, Sep 30, 2019 at 9:18 PM Will Deacon wrote:
> > I agree that the ARM code looks dodgy with
> > that call to uaccess_save_and_enable(), but there are __asmeq macros
> > in there to try to catch that, so it's still very fishy.
Hi Will,
On Mon, Sep 30, 2019 at 9:18 PM Will Deacon wrote:
>
> On Mon, Sep 30, 2019 at 09:05:11PM +0900, Masahiro Yamada wrote:
> > On Mon, Sep 30, 2019 at 8:26 PM Will Deacon wrote:
> > > On Fri, Sep 27, 2019 at 03:38:44PM -0700, Linus Torvalds wrote:
> > > > Soem of that code is pretty subtle
Hi Nick,
On Mon, Sep 30, 2019 at 02:50:10PM -0700, Nick Desaulniers wrote:
> On Mon, Sep 30, 2019 at 5:18 AM Will Deacon wrote:
> > On Mon, Sep 30, 2019 at 09:05:11PM +0900, Masahiro Yamada wrote:
> > > On Mon, Sep 30, 2019 at 8:26 PM Will Deacon wrote:
> > > > FWIW, we've run into issues with C
On Mon, Sep 30, 2019 at 3:08 PM Miguel Ojeda
wrote:
>
> On Mon, Sep 30, 2019 at 11:50 PM Nick Desaulniers
> wrote:
> >
> > So __attribute__((always_inline)) doesn't guarantee that code will be
> > inlined. [...] inline and __attribute__((always_inline))
> > are a heuristic laden mess and should
On Mon, Sep 30, 2019 at 11:50 PM Nick Desaulniers
wrote:
>
> So __attribute__((always_inline)) doesn't guarantee that code will be
> inlined. [...] inline and __attribute__((always_inline))
> are a heuristic laden mess and should not be relied upon.
Small note: in GCC, __attribute__((always_inli
On Mon, Sep 30, 2019 at 5:18 AM Will Deacon wrote:
>
> On Mon, Sep 30, 2019 at 09:05:11PM +0900, Masahiro Yamada wrote:
> > On Mon, Sep 30, 2019 at 8:26 PM Will Deacon wrote:
> > > On Fri, Sep 27, 2019 at 03:38:44PM -0700, Linus Torvalds wrote:
> > > > Soem of that code is pretty subtle. They hav
On Mon, Sep 30, 2019 at 09:05:11PM +0900, Masahiro Yamada wrote:
> On Mon, Sep 30, 2019 at 8:26 PM Will Deacon wrote:
> > On Fri, Sep 27, 2019 at 03:38:44PM -0700, Linus Torvalds wrote:
> > > Soem of that code is pretty subtle. They have fixed register usage
> > > (but the asm macros actually chec
On Mon, Sep 30, 2019 at 8:26 PM Will Deacon wrote:
>
> On Fri, Sep 27, 2019 at 03:38:44PM -0700, Linus Torvalds wrote:
> > On Fri, Sep 27, 2019 at 3:08 PM Nick Desaulniers
> > wrote:
> > >
> > > So get_user() was passed a bad value/pointer from userspace? Do you
> > > know which of the tree calls
On Fri, Sep 27, 2019 at 03:38:44PM -0700, Linus Torvalds wrote:
> On Fri, Sep 27, 2019 at 3:08 PM Nick Desaulniers
> wrote:
> >
> > So get_user() was passed a bad value/pointer from userspace? Do you
> > know which of the tree calls to get_user() from sock_setsockopt() is
> > failing? (It's not i
Hi.
On Fri, Sep 27, 2019 at 7:58 PM Nicolas Saenz Julienne
wrote:
>
> On Fri, 2019-08-30 at 12:43 +0900, Masahiro Yamada wrote:
> > Commit 9012d011660e ("compiler: allow all arches to enable
> > CONFIG_OPTIMIZE_INLINING") allowed all architectures to enable
> > this option. A couple of build erro
On Fri, Sep 27, 2019 at 3:08 PM Nick Desaulniers
wrote:
>
> So get_user() was passed a bad value/pointer from userspace? Do you
> know which of the tree calls to get_user() from sock_setsockopt() is
> failing? (It's not immediately clear to me how this patch is at
> fault, vs there just being a b
On Fri, Sep 27, 2019 at 3:43 AM Nicolas Saenz Julienne
wrote:
>
> On Fri, 2019-08-30 at 12:43 +0900, Masahiro Yamada wrote:
> > Commit 9012d011660e ("compiler: allow all arches to enable
> > CONFIG_OPTIMIZE_INLINING") allowed all architectures to enable
> > this option. A couple of build errors we
On Fri, Sep 27, 2019 at 12:43:33PM +0200, Nicolas Saenz Julienne wrote:
> On Fri, 2019-08-30 at 12:43 +0900, Masahiro Yamada wrote:
> > Commit 9012d011660e ("compiler: allow all arches to enable
> > CONFIG_OPTIMIZE_INLINING") allowed all architectures to enable
> > this option. A couple of build er
On Fri, 2019-08-30 at 12:43 +0900, Masahiro Yamada wrote:
> Commit 9012d011660e ("compiler: allow all arches to enable
> CONFIG_OPTIMIZE_INLINING") allowed all architectures to enable
> this option. A couple of build errors were reported by randconfig,
> but all of them have been ironed out.
>
> T
On Fri, 2019-08-30 at 12:43 +0900, Masahiro Yamada wrote:
> Commit 9012d011660e ("compiler: allow all arches to enable
> CONFIG_OPTIMIZE_INLINING") allowed all architectures to enable
> this option. A couple of build errors were reported by randconfig,
> but all of them have been ironed out.
>
> T
Hi Geert,
On Thu, Sep 26, 2019 at 6:26 PM Geert Uytterhoeven wrote:
>
> Hi Yamada-san,
>
> On Thu, Sep 26, 2019 at 11:03 AM Masahiro Yamada
> wrote:
> > On Thu, Sep 26, 2019 at 5:54 PM Geert Uytterhoeven
> > wrote:
> > > On Fri, Aug 30, 2019 at 5:44 AM Masahiro Yamada
> > > wrote:
> > > > Com
Hi Yamada-san,
On Thu, Sep 26, 2019 at 11:03 AM Masahiro Yamada
wrote:
> On Thu, Sep 26, 2019 at 5:54 PM Geert Uytterhoeven
> wrote:
> > On Fri, Aug 30, 2019 at 5:44 AM Masahiro Yamada
> > wrote:
> > > Commit 9012d011660e ("compiler: allow all arches to enable
> > > CONFIG_OPTIMIZE_INLINING")
Hi Geert,
On Thu, Sep 26, 2019 at 5:54 PM Geert Uytterhoeven wrote:
>
> Hi Yamada-san,
>
> On Fri, Aug 30, 2019 at 5:44 AM Masahiro Yamada
> wrote:
> > Commit 9012d011660e ("compiler: allow all arches to enable
> > CONFIG_OPTIMIZE_INLINING") allowed all architectures to enable
> > this option. A
Hi Yamada-san,
On Fri, Aug 30, 2019 at 5:44 AM Masahiro Yamada
wrote:
> Commit 9012d011660e ("compiler: allow all arches to enable
> CONFIG_OPTIMIZE_INLINING") allowed all architectures to enable
> this option. A couple of build errors were reported by randconfig,
> but all of them have been iron
On Thu, Aug 29, 2019 at 8:43 PM Masahiro Yamada
wrote:
>
> Commit 9012d011660e ("compiler: allow all arches to enable
> CONFIG_OPTIMIZE_INLINING") allowed all architectures to enable
> this option. A couple of build errors were reported by randconfig,
> but all of them have been ironed out.
>
> To
48 matches
Mail list logo
