* Re: [PATCH 2/5 v16] ARM: Replace string mem* functions for KASan
2020-11-06 15:15 ` Russell King - ARM Linux admin
@ 2020-11-06 15:18 ` Ard Biesheuvel
2020-11-06 18:09 ` Nathan Chancellor
2020-11-09 16:02 ` Linus Walleij
2 siblings, 0 replies; 16+ messages in thread
From: Ard Biesheuvel @ 2020-11-06 15:18 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Linus Walleij, Nathan Chancellor, Stephen Rothwell,
Florian Fainelli, Ahmad Fatoum, Arnd Bergmann, Abbott Liu,
Naresh Kamboju, kasan-dev, Mike Rapoport, Linux-Next Mailing List,
Alexander Potapenko, Dmitry Vyukov, Andrey Ryabinin, Linux ARM
On Fri, 6 Nov 2020 at 16:16, Russell King - ARM Linux admin
<linux@armlinux•org.uk> wrote:
>
> On Fri, Nov 06, 2020 at 02:37:21PM +0100, Linus Walleij wrote:
> > On Fri, Nov 6, 2020 at 10:44 AM Nathan Chancellor
> > <natechancellor@gmail•com> wrote:
> > > On Fri, Nov 06, 2020 at 09:28:09AM +0100, Ard Biesheuvel wrote:
> >
> > > > AFAIK there is an incompatible change in -next to change the
> > > > definition of the __alias() macro
> > >
> > > Indeed. The following diff needs to be applied as a fixup to
> > > treewide-remove-stringification-from-__alias-macro-definition.patch in
> > > mmotm.
> > >
> > > Cheers,
> > > Nathan
> > >
> > > diff --git a/arch/arm/boot/compressed/string.c b/arch/arm/boot/compressed/string.c
> > > index 8c0fa276d994..cc6198f8a348 100644
> > > --- a/arch/arm/boot/compressed/string.c
> > > +++ b/arch/arm/boot/compressed/string.c
> > > @@ -21,9 +21,9 @@
> > > #undef memcpy
> > > #undef memmove
> > > #undef memset
> > > -void *__memcpy(void *__dest, __const void *__src, size_t __n) __alias(memcpy);
> > > -void *__memmove(void *__dest, __const void *__src, size_t count) __alias(memmove);
> > > -void *__memset(void *s, int c, size_t count) __alias(memset);
> > > +void *__memcpy(void *__dest, __const void *__src, size_t __n) __alias("memcpy");
> > > +void *__memmove(void *__dest, __const void *__src, size_t count) __alias("memmove");
> > > +void *__memset(void *s, int c, size_t count) __alias("memset");
> > > #endif
> > >
> > > void *memcpy(void *__dest, __const void *__src, size_t __n)
> >
> > Aha. So shall we submit this to Russell? I figure that his git will not
> > build *without* the changes from mmotm?
> >
> > That tree isn't using git either is it?
> >
> > Is this one of those cases where we should ask Stephen R
> > to carry this patch on top of -next until the merge window?
>
> Another solution would be to drop 9017/2 ("Enable KASan for ARM")
> until the following merge window, and queue up the non-conflicing
> ARM KASan fixes in my "misc" branch along with the rest of KASan,
> and the conflicting patches along with 9017/2 in the following
> merge window.
>
> That means delaying KASan enablement another three months or so,
> but should result in less headaches about how to avoid build
> breakage with different bits going through different trees.
>
> Comments?
>
Alternatively, we could simply switch these to the bare
__attribute__((alias(".."))) syntax now, and revert that change again
one cycle later.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [PATCH 2/5 v16] ARM: Replace string mem* functions for KASan
2020-11-06 15:15 ` Russell King - ARM Linux admin
2020-11-06 15:18 ` Ard Biesheuvel
@ 2020-11-06 18:09 ` Nathan Chancellor
2020-11-09 16:02 ` Linus Walleij
2 siblings, 0 replies; 16+ messages in thread
From: Nathan Chancellor @ 2020-11-06 18:09 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Linus Walleij, Stephen Rothwell, Florian Fainelli, Ahmad Fatoum,
Arnd Bergmann, Abbott Liu, Naresh Kamboju, kasan-dev,
Mike Rapoport, Linux-Next Mailing List, Alexander Potapenko,
Dmitry Vyukov, Andrey Ryabinin, Ard Biesheuvel, Linux ARM
On Fri, Nov 06, 2020 at 03:15:54PM +0000, Russell King - ARM Linux admin wrote:
> On Fri, Nov 06, 2020 at 02:37:21PM +0100, Linus Walleij wrote:
> > On Fri, Nov 6, 2020 at 10:44 AM Nathan Chancellor
> > <natechancellor@gmail•com> wrote:
> > > On Fri, Nov 06, 2020 at 09:28:09AM +0100, Ard Biesheuvel wrote:
> >
> > > > AFAIK there is an incompatible change in -next to change the
> > > > definition of the __alias() macro
> > >
> > > Indeed. The following diff needs to be applied as a fixup to
> > > treewide-remove-stringification-from-__alias-macro-definition.patch in
> > > mmotm.
> > >
> > > Cheers,
> > > Nathan
> > >
> > > diff --git a/arch/arm/boot/compressed/string.c b/arch/arm/boot/compressed/string.c
> > > index 8c0fa276d994..cc6198f8a348 100644
> > > --- a/arch/arm/boot/compressed/string.c
> > > +++ b/arch/arm/boot/compressed/string.c
> > > @@ -21,9 +21,9 @@
> > > #undef memcpy
> > > #undef memmove
> > > #undef memset
> > > -void *__memcpy(void *__dest, __const void *__src, size_t __n) __alias(memcpy);
> > > -void *__memmove(void *__dest, __const void *__src, size_t count) __alias(memmove);
> > > -void *__memset(void *s, int c, size_t count) __alias(memset);
> > > +void *__memcpy(void *__dest, __const void *__src, size_t __n) __alias("memcpy");
> > > +void *__memmove(void *__dest, __const void *__src, size_t count) __alias("memmove");
> > > +void *__memset(void *s, int c, size_t count) __alias("memset");
> > > #endif
> > >
> > > void *memcpy(void *__dest, __const void *__src, size_t __n)
> >
> > Aha. So shall we submit this to Russell? I figure that his git will not
> > build *without* the changes from mmotm?
Yeah, I do not think that you can apply that diff to Russell's tree
without the patch from -mm.
> > That tree isn't using git either is it?
> >
> > Is this one of those cases where we should ask Stephen R
> > to carry this patch on top of -next until the merge window?
I believe so, I do not think Stephen has any issues with carrying that
diff to keep everything building properly (although I won't speak for
him heh).
> Another solution would be to drop 9017/2 ("Enable KASan for ARM")
> until the following merge window, and queue up the non-conflicing
> ARM KASan fixes in my "misc" branch along with the rest of KASan,
> and the conflicting patches along with 9017/2 in the following
> merge window.
>
> That means delaying KASan enablement another three months or so,
> but should result in less headaches about how to avoid build
> breakage with different bits going through different trees.
>
> Comments?
That could certainly work but as far as I am aware, that is really the
only breakage. In theory, Andrew could just hold off on sending that
patch until after yours is merged into Linus' tree so that it could be
added to that patch and everything stays building properly. Requires a
minor amount of coordination but that would avoid delaying KASAN
enablement for three months. I do not have any preference since this is
not my code.
Cheers,
Nathan
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [PATCH 2/5 v16] ARM: Replace string mem* functions for KASan
2020-11-06 15:15 ` Russell King - ARM Linux admin
2020-11-06 15:18 ` Ard Biesheuvel
2020-11-06 18:09 ` Nathan Chancellor
@ 2020-11-09 16:02 ` Linus Walleij
2020-11-09 16:06 ` Russell King - ARM Linux admin
2 siblings, 1 reply; 16+ messages in thread
From: Linus Walleij @ 2020-11-09 16:02 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Nathan Chancellor, Stephen Rothwell, Florian Fainelli,
Ahmad Fatoum, Arnd Bergmann, Abbott Liu, Naresh Kamboju,
kasan-dev, Mike Rapoport, Linux-Next Mailing List,
Alexander Potapenko, Dmitry Vyukov, Andrey Ryabinin,
Ard Biesheuvel, Linux ARM
On Fri, Nov 6, 2020 at 4:16 PM Russell King - ARM Linux admin
<linux@armlinux•org.uk> wrote:
> On Fri, Nov 06, 2020 at 02:37:21PM +0100, Linus Walleij wrote:
> > Aha. So shall we submit this to Russell? I figure that his git will not
> > build *without* the changes from mmotm?
> >
> > That tree isn't using git either is it?
> >
> > Is this one of those cases where we should ask Stephen R
> > to carry this patch on top of -next until the merge window?
>
> Another solution would be to drop 9017/2 ("Enable KASan for ARM")
> until the following merge window, and queue up the non-conflicing
> ARM KASan fixes in my "misc" branch along with the rest of KASan,
> and the conflicting patches along with 9017/2 in the following
> merge window.
>
> That means delaying KASan enablement another three months or so,
> but should result in less headaches about how to avoid build
> breakage with different bits going through different trees.
>
> Comments?
I suppose I would survive deferring it. Or we could merge the
smaller enablement patch towards the end of the merge
window once the MM changes are in.
If it is just *one* patch in the MM tree I suppose we could also
just apply that one patch also to the ARM tree, and then this
fixup on top. It does look a bit convoluted in the git history with
two hashes and the same patch twice, but it's what I've done
at times when there was no other choice that doing that or
deferring development. It works as long as the patches are
textually identical: git will cope.
If there is a risk that the patch in MM changes this latter
approach is a no-go.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [PATCH 2/5 v16] ARM: Replace string mem* functions for KASan
2020-11-09 16:02 ` Linus Walleij
@ 2020-11-09 16:06 ` Russell King - ARM Linux admin
2020-11-10 12:04 ` Ard Biesheuvel
0 siblings, 1 reply; 16+ messages in thread
From: Russell King - ARM Linux admin @ 2020-11-09 16:06 UTC (permalink / raw)
To: Linus Walleij
Cc: Nathan Chancellor, Stephen Rothwell, Florian Fainelli,
Ahmad Fatoum, Arnd Bergmann, Abbott Liu, Naresh Kamboju,
kasan-dev, Mike Rapoport, Linux-Next Mailing List,
Alexander Potapenko, Dmitry Vyukov, Andrey Ryabinin,
Ard Biesheuvel, Linux ARM
On Mon, Nov 09, 2020 at 05:02:09PM +0100, Linus Walleij wrote:
> On Fri, Nov 6, 2020 at 4:16 PM Russell King - ARM Linux admin
> <linux@armlinux•org.uk> wrote:
> > On Fri, Nov 06, 2020 at 02:37:21PM +0100, Linus Walleij wrote:
>
> > > Aha. So shall we submit this to Russell? I figure that his git will not
> > > build *without* the changes from mmotm?
> > >
> > > That tree isn't using git either is it?
> > >
> > > Is this one of those cases where we should ask Stephen R
> > > to carry this patch on top of -next until the merge window?
> >
> > Another solution would be to drop 9017/2 ("Enable KASan for ARM")
> > until the following merge window, and queue up the non-conflicing
> > ARM KASan fixes in my "misc" branch along with the rest of KASan,
> > and the conflicting patches along with 9017/2 in the following
> > merge window.
> >
> > That means delaying KASan enablement another three months or so,
> > but should result in less headaches about how to avoid build
> > breakage with different bits going through different trees.
> >
> > Comments?
>
> I suppose I would survive deferring it. Or we could merge the
> smaller enablement patch towards the end of the merge
> window once the MM changes are in.
>
> If it is just *one* patch in the MM tree I suppose we could also
> just apply that one patch also to the ARM tree, and then this
> fixup on top. It does look a bit convoluted in the git history with
> two hashes and the same patch twice, but it's what I've done
> at times when there was no other choice that doing that or
> deferring development. It works as long as the patches are
> textually identical: git will cope.
I thought there was a problem that if I applied the fix then my tree
no longer builds without the changes in -mm?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [PATCH 2/5 v16] ARM: Replace string mem* functions for KASan
2020-11-09 16:06 ` Russell King - ARM Linux admin
@ 2020-11-10 12:04 ` Ard Biesheuvel
2020-11-12 13:51 ` Linus Walleij
0 siblings, 1 reply; 16+ messages in thread
From: Ard Biesheuvel @ 2020-11-10 12:04 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Linus Walleij, Nathan Chancellor, Stephen Rothwell,
Florian Fainelli, Ahmad Fatoum, Arnd Bergmann, Abbott Liu,
Naresh Kamboju, kasan-dev, Mike Rapoport, Linux-Next Mailing List,
Alexander Potapenko, Dmitry Vyukov, Andrey Ryabinin, Linux ARM
On Mon, 9 Nov 2020 at 17:07, Russell King - ARM Linux admin
<linux@armlinux•org.uk> wrote:
>
> On Mon, Nov 09, 2020 at 05:02:09PM +0100, Linus Walleij wrote:
> > On Fri, Nov 6, 2020 at 4:16 PM Russell King - ARM Linux admin
> > <linux@armlinux•org.uk> wrote:
> > > On Fri, Nov 06, 2020 at 02:37:21PM +0100, Linus Walleij wrote:
> >
> > > > Aha. So shall we submit this to Russell? I figure that his git will not
> > > > build *without* the changes from mmotm?
> > > >
> > > > That tree isn't using git either is it?
> > > >
> > > > Is this one of those cases where we should ask Stephen R
> > > > to carry this patch on top of -next until the merge window?
> > >
> > > Another solution would be to drop 9017/2 ("Enable KASan for ARM")
> > > until the following merge window, and queue up the non-conflicing
> > > ARM KASan fixes in my "misc" branch along with the rest of KASan,
> > > and the conflicting patches along with 9017/2 in the following
> > > merge window.
> > >
> > > That means delaying KASan enablement another three months or so,
> > > but should result in less headaches about how to avoid build
> > > breakage with different bits going through different trees.
> > >
> > > Comments?
> >
> > I suppose I would survive deferring it. Or we could merge the
> > smaller enablement patch towards the end of the merge
> > window once the MM changes are in.
> >
> > If it is just *one* patch in the MM tree I suppose we could also
> > just apply that one patch also to the ARM tree, and then this
> > fixup on top. It does look a bit convoluted in the git history with
> > two hashes and the same patch twice, but it's what I've done
> > at times when there was no other choice that doing that or
> > deferring development. It works as long as the patches are
> > textually identical: git will cope.
>
> I thought there was a problem that if I applied the fix then my tree
> no longer builds without the changes in -mm?
>
Indeed. Someone is changing the __alias() wrappers [for no good reason
afaict] in a way that does not allow for new users of those wrappers
to come in concurrently.
Hency my suggestion to switch to the raw __attribute__((alias("..")))
notation for the time being, and switch back to __alias() somewhere
after v5.11-rc1.
Or we might add this to the file in question
#undef __alias
#define __alias(symbol) __attribute__((__alias__(symbol)))
and switch to the quoted versions of the identifier. Then we can just
drop these two lines again later, after v5.11-rc1
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [PATCH 2/5 v16] ARM: Replace string mem* functions for KASan
2020-11-10 12:04 ` Ard Biesheuvel
@ 2020-11-12 13:51 ` Linus Walleij
2020-11-12 15:05 ` Ard Biesheuvel
0 siblings, 1 reply; 16+ messages in thread
From: Linus Walleij @ 2020-11-12 13:51 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Russell King - ARM Linux admin, Nathan Chancellor,
Stephen Rothwell, Florian Fainelli, Ahmad Fatoum, Arnd Bergmann,
Abbott Liu, Naresh Kamboju, kasan-dev, Mike Rapoport,
Linux-Next Mailing List, Alexander Potapenko, Dmitry Vyukov,
Andrey Ryabinin, Linux ARM
On Tue, Nov 10, 2020 at 1:05 PM Ard Biesheuvel <ardb@kernel•org> wrote:
> On Mon, 9 Nov 2020 at 17:07, Russell King - ARM Linux admin
> <linux@armlinux•org.uk> wrote:
> >
> > On Mon, Nov 09, 2020 at 05:02:09PM +0100, Linus Walleij wrote:
> > > On Fri, Nov 6, 2020 at 4:16 PM Russell King - ARM Linux admin
> > > <linux@armlinux•org.uk> wrote:
> > > > On Fri, Nov 06, 2020 at 02:37:21PM +0100, Linus Walleij wrote:
> > >
> > > > > Aha. So shall we submit this to Russell? I figure that his git will not
> > > > > build *without* the changes from mmotm?
> > > > >
> > > > > That tree isn't using git either is it?
> > > > >
> > > > > Is this one of those cases where we should ask Stephen R
> > > > > to carry this patch on top of -next until the merge window?
> > > >
> > > > Another solution would be to drop 9017/2 ("Enable KASan for ARM")
> > > > until the following merge window, and queue up the non-conflicing
> > > > ARM KASan fixes in my "misc" branch along with the rest of KASan,
> > > > and the conflicting patches along with 9017/2 in the following
> > > > merge window.
> > > >
> > > > That means delaying KASan enablement another three months or so,
> > > > but should result in less headaches about how to avoid build
> > > > breakage with different bits going through different trees.
> > > >
> > > > Comments?
> > >
> > > I suppose I would survive deferring it. Or we could merge the
> > > smaller enablement patch towards the end of the merge
> > > window once the MM changes are in.
> > >
> > > If it is just *one* patch in the MM tree I suppose we could also
> > > just apply that one patch also to the ARM tree, and then this
> > > fixup on top. It does look a bit convoluted in the git history with
> > > two hashes and the same patch twice, but it's what I've done
> > > at times when there was no other choice that doing that or
> > > deferring development. It works as long as the patches are
> > > textually identical: git will cope.
> >
> > I thought there was a problem that if I applied the fix then my tree
> > no longer builds without the changes in -mm?
> >
>
> Indeed. Someone is changing the __alias() wrappers [for no good reason
> afaict] in a way that does not allow for new users of those wrappers
> to come in concurrently.
>
> Hency my suggestion to switch to the raw __attribute__((alias("..")))
> notation for the time being, and switch back to __alias() somewhere
> after v5.11-rc1.
>
> Or we might add this to the file in question
>
> #undef __alias
> #define __alias(symbol) __attribute__((__alias__(symbol)))
>
> and switch to the quoted versions of the identifier. Then we can just
> drop these two lines again later, after v5.11-rc1
I was under the impression that there was some "post-next"
trick that mmot apply this patch after -next has been merged
so it's solved now?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [PATCH 2/5 v16] ARM: Replace string mem* functions for KASan
2020-11-12 13:51 ` Linus Walleij
@ 2020-11-12 15:05 ` Ard Biesheuvel
2020-11-12 17:52 ` Nathan Chancellor
0 siblings, 1 reply; 16+ messages in thread
From: Ard Biesheuvel @ 2020-11-12 15:05 UTC (permalink / raw)
To: Linus Walleij
Cc: Russell King - ARM Linux admin, Nathan Chancellor,
Stephen Rothwell, Florian Fainelli, Ahmad Fatoum, Arnd Bergmann,
Abbott Liu, Naresh Kamboju, kasan-dev, Mike Rapoport,
Linux-Next Mailing List, Alexander Potapenko, Dmitry Vyukov,
Andrey Ryabinin, Linux ARM
On Thu, 12 Nov 2020 at 14:51, Linus Walleij <linus.walleij@linaro•org> wrote:
>
> On Tue, Nov 10, 2020 at 1:05 PM Ard Biesheuvel <ardb@kernel•org> wrote:
> > On Mon, 9 Nov 2020 at 17:07, Russell King - ARM Linux admin
> > <linux@armlinux•org.uk> wrote:
> > >
> > > On Mon, Nov 09, 2020 at 05:02:09PM +0100, Linus Walleij wrote:
> > > > On Fri, Nov 6, 2020 at 4:16 PM Russell King - ARM Linux admin
> > > > <linux@armlinux•org.uk> wrote:
> > > > > On Fri, Nov 06, 2020 at 02:37:21PM +0100, Linus Walleij wrote:
> > > >
> > > > > > Aha. So shall we submit this to Russell? I figure that his git will not
> > > > > > build *without* the changes from mmotm?
> > > > > >
> > > > > > That tree isn't using git either is it?
> > > > > >
> > > > > > Is this one of those cases where we should ask Stephen R
> > > > > > to carry this patch on top of -next until the merge window?
> > > > >
> > > > > Another solution would be to drop 9017/2 ("Enable KASan for ARM")
> > > > > until the following merge window, and queue up the non-conflicing
> > > > > ARM KASan fixes in my "misc" branch along with the rest of KASan,
> > > > > and the conflicting patches along with 9017/2 in the following
> > > > > merge window.
> > > > >
> > > > > That means delaying KASan enablement another three months or so,
> > > > > but should result in less headaches about how to avoid build
> > > > > breakage with different bits going through different trees.
> > > > >
> > > > > Comments?
> > > >
> > > > I suppose I would survive deferring it. Or we could merge the
> > > > smaller enablement patch towards the end of the merge
> > > > window once the MM changes are in.
> > > >
> > > > If it is just *one* patch in the MM tree I suppose we could also
> > > > just apply that one patch also to the ARM tree, and then this
> > > > fixup on top. It does look a bit convoluted in the git history with
> > > > two hashes and the same patch twice, but it's what I've done
> > > > at times when there was no other choice that doing that or
> > > > deferring development. It works as long as the patches are
> > > > textually identical: git will cope.
> > >
> > > I thought there was a problem that if I applied the fix then my tree
> > > no longer builds without the changes in -mm?
> > >
> >
> > Indeed. Someone is changing the __alias() wrappers [for no good reason
> > afaict] in a way that does not allow for new users of those wrappers
> > to come in concurrently.
> >
> > Hency my suggestion to switch to the raw __attribute__((alias("..")))
> > notation for the time being, and switch back to __alias() somewhere
> > after v5.11-rc1.
> >
> > Or we might add this to the file in question
> >
> > #undef __alias
> > #define __alias(symbol) __attribute__((__alias__(symbol)))
> >
> > and switch to the quoted versions of the identifier. Then we can just
> > drop these two lines again later, after v5.11-rc1
>
> I was under the impression that there was some "post-next"
> trick that mmot apply this patch after -next has been merged
> so it's solved now?
>
Yes, it appears that [0] has been picked up, I guess we weren't cc'ed
on the version that was sent to akpm [which is fine btw, although a
followup reply here that things are all good now would have been
appreciated]
https://lore.kernel.org/linux-arm-kernel/20201109001712.3384097-1-natechancellor@gmail.com/
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [PATCH 2/5 v16] ARM: Replace string mem* functions for KASan
2020-11-12 15:05 ` Ard Biesheuvel
@ 2020-11-12 17:52 ` Nathan Chancellor
2020-11-16 15:16 ` Ard Biesheuvel
0 siblings, 1 reply; 16+ messages in thread
From: Nathan Chancellor @ 2020-11-12 17:52 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Linus Walleij, Russell King - ARM Linux admin, Stephen Rothwell,
Florian Fainelli, Ahmad Fatoum, Arnd Bergmann, Abbott Liu,
Naresh Kamboju, kasan-dev, Mike Rapoport, Linux-Next Mailing List,
Alexander Potapenko, Dmitry Vyukov, Andrey Ryabinin, Linux ARM
On Thu, Nov 12, 2020 at 04:05:52PM +0100, Ard Biesheuvel wrote:
> On Thu, 12 Nov 2020 at 14:51, Linus Walleij <linus.walleij@linaro•org> wrote:
> >
> > On Tue, Nov 10, 2020 at 1:05 PM Ard Biesheuvel <ardb@kernel•org> wrote:
> > > On Mon, 9 Nov 2020 at 17:07, Russell King - ARM Linux admin
> > > <linux@armlinux•org.uk> wrote:
> > > >
> > > > On Mon, Nov 09, 2020 at 05:02:09PM +0100, Linus Walleij wrote:
> > > > > On Fri, Nov 6, 2020 at 4:16 PM Russell King - ARM Linux admin
> > > > > <linux@armlinux•org.uk> wrote:
> > > > > > On Fri, Nov 06, 2020 at 02:37:21PM +0100, Linus Walleij wrote:
> > > > >
> > > > > > > Aha. So shall we submit this to Russell? I figure that his git will not
> > > > > > > build *without* the changes from mmotm?
> > > > > > >
> > > > > > > That tree isn't using git either is it?
> > > > > > >
> > > > > > > Is this one of those cases where we should ask Stephen R
> > > > > > > to carry this patch on top of -next until the merge window?
> > > > > >
> > > > > > Another solution would be to drop 9017/2 ("Enable KASan for ARM")
> > > > > > until the following merge window, and queue up the non-conflicing
> > > > > > ARM KASan fixes in my "misc" branch along with the rest of KASan,
> > > > > > and the conflicting patches along with 9017/2 in the following
> > > > > > merge window.
> > > > > >
> > > > > > That means delaying KASan enablement another three months or so,
> > > > > > but should result in less headaches about how to avoid build
> > > > > > breakage with different bits going through different trees.
> > > > > >
> > > > > > Comments?
> > > > >
> > > > > I suppose I would survive deferring it. Or we could merge the
> > > > > smaller enablement patch towards the end of the merge
> > > > > window once the MM changes are in.
> > > > >
> > > > > If it is just *one* patch in the MM tree I suppose we could also
> > > > > just apply that one patch also to the ARM tree, and then this
> > > > > fixup on top. It does look a bit convoluted in the git history with
> > > > > two hashes and the same patch twice, but it's what I've done
> > > > > at times when there was no other choice that doing that or
> > > > > deferring development. It works as long as the patches are
> > > > > textually identical: git will cope.
> > > >
> > > > I thought there was a problem that if I applied the fix then my tree
> > > > no longer builds without the changes in -mm?
> > > >
> > >
> > > Indeed. Someone is changing the __alias() wrappers [for no good reason
> > > afaict] in a way that does not allow for new users of those wrappers
> > > to come in concurrently.
> > >
> > > Hency my suggestion to switch to the raw __attribute__((alias("..")))
> > > notation for the time being, and switch back to __alias() somewhere
> > > after v5.11-rc1.
> > >
> > > Or we might add this to the file in question
> > >
> > > #undef __alias
> > > #define __alias(symbol) __attribute__((__alias__(symbol)))
> > >
> > > and switch to the quoted versions of the identifier. Then we can just
> > > drop these two lines again later, after v5.11-rc1
> >
> > I was under the impression that there was some "post-next"
> > trick that mmot apply this patch after -next has been merged
> > so it's solved now?
> >
>
> Yes, it appears that [0] has been picked up, I guess we weren't cc'ed
> on the version that was sent to akpm [which is fine btw, although a
> followup reply here that things are all good now would have been
> appreciated]
>
>
> https://lore.kernel.org/linux-arm-kernel/20201109001712.3384097-1-natechancellor@gmail.com/
Hi Ard,
Odd, you were on the list of people to receive that patch and you acked
it but it seems that Andrew did not CC you when he actually applied the
patch:
https://lore.kernel.org/mm-commits/20201110212436.yGYhesom8%25akpm@linux-foundation.org/
My apologies for not following up, we appear to be all good now for the
time being (aside from the futex issue that I reported earlier).
Cheers,
Nathan
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [PATCH 2/5 v16] ARM: Replace string mem* functions for KASan
2020-11-12 17:52 ` Nathan Chancellor
@ 2020-11-16 15:16 ` Ard Biesheuvel
0 siblings, 0 replies; 16+ messages in thread
From: Ard Biesheuvel @ 2020-11-16 15:16 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Linus Walleij, Russell King - ARM Linux admin, Stephen Rothwell,
Florian Fainelli, Ahmad Fatoum, Arnd Bergmann, Abbott Liu,
Naresh Kamboju, kasan-dev, Mike Rapoport, Linux-Next Mailing List,
Alexander Potapenko, Dmitry Vyukov, Andrey Ryabinin, Linux ARM
On Thu, 12 Nov 2020 at 18:52, Nathan Chancellor
<natechancellor@gmail•com> wrote:
>
> On Thu, Nov 12, 2020 at 04:05:52PM +0100, Ard Biesheuvel wrote:
> > On Thu, 12 Nov 2020 at 14:51, Linus Walleij <linus.walleij@linaro•org> wrote:
> > >
> > > On Tue, Nov 10, 2020 at 1:05 PM Ard Biesheuvel <ardb@kernel•org> wrote:
> > > > On Mon, 9 Nov 2020 at 17:07, Russell King - ARM Linux admin
> > > > <linux@armlinux•org.uk> wrote:
> > > > >
> > > > > On Mon, Nov 09, 2020 at 05:02:09PM +0100, Linus Walleij wrote:
> > > > > > On Fri, Nov 6, 2020 at 4:16 PM Russell King - ARM Linux admin
> > > > > > <linux@armlinux•org.uk> wrote:
> > > > > > > On Fri, Nov 06, 2020 at 02:37:21PM +0100, Linus Walleij wrote:
> > > > > >
> > > > > > > > Aha. So shall we submit this to Russell? I figure that his git will not
> > > > > > > > build *without* the changes from mmotm?
> > > > > > > >
> > > > > > > > That tree isn't using git either is it?
> > > > > > > >
> > > > > > > > Is this one of those cases where we should ask Stephen R
> > > > > > > > to carry this patch on top of -next until the merge window?
> > > > > > >
> > > > > > > Another solution would be to drop 9017/2 ("Enable KASan for ARM")
> > > > > > > until the following merge window, and queue up the non-conflicing
> > > > > > > ARM KASan fixes in my "misc" branch along with the rest of KASan,
> > > > > > > and the conflicting patches along with 9017/2 in the following
> > > > > > > merge window.
> > > > > > >
> > > > > > > That means delaying KASan enablement another three months or so,
> > > > > > > but should result in less headaches about how to avoid build
> > > > > > > breakage with different bits going through different trees.
> > > > > > >
> > > > > > > Comments?
> > > > > >
> > > > > > I suppose I would survive deferring it. Or we could merge the
> > > > > > smaller enablement patch towards the end of the merge
> > > > > > window once the MM changes are in.
> > > > > >
> > > > > > If it is just *one* patch in the MM tree I suppose we could also
> > > > > > just apply that one patch also to the ARM tree, and then this
> > > > > > fixup on top. It does look a bit convoluted in the git history with
> > > > > > two hashes and the same patch twice, but it's what I've done
> > > > > > at times when there was no other choice that doing that or
> > > > > > deferring development. It works as long as the patches are
> > > > > > textually identical: git will cope.
> > > > >
> > > > > I thought there was a problem that if I applied the fix then my tree
> > > > > no longer builds without the changes in -mm?
> > > > >
> > > >
> > > > Indeed. Someone is changing the __alias() wrappers [for no good reason
> > > > afaict] in a way that does not allow for new users of those wrappers
> > > > to come in concurrently.
> > > >
> > > > Hency my suggestion to switch to the raw __attribute__((alias("..")))
> > > > notation for the time being, and switch back to __alias() somewhere
> > > > after v5.11-rc1.
> > > >
> > > > Or we might add this to the file in question
> > > >
> > > > #undef __alias
> > > > #define __alias(symbol) __attribute__((__alias__(symbol)))
> > > >
> > > > and switch to the quoted versions of the identifier. Then we can just
> > > > drop these two lines again later, after v5.11-rc1
> > >
> > > I was under the impression that there was some "post-next"
> > > trick that mmot apply this patch after -next has been merged
> > > so it's solved now?
> > >
> >
> > Yes, it appears that [0] has been picked up, I guess we weren't cc'ed
> > on the version that was sent to akpm [which is fine btw, although a
> > followup reply here that things are all good now would have been
> > appreciated]
> >
> >
> > https://lore.kernel.org/linux-arm-kernel/20201109001712.3384097-1-natechancellor@gmail.com/
>
> Hi Ard,
>
> Odd, you were on the list of people to receive that patch and you acked
> it but it seems that Andrew did not CC you when he actually applied the
> patch:
>
> https://lore.kernel.org/mm-commits/20201110212436.yGYhesom8%25akpm@linux-foundation.org/
>
> My apologies for not following up, we appear to be all good now for the
> time being (aside from the futex issue that I reported earlier).
>
No worries - at least it is fixed now. And KASAN is already shaking
out bugs, so it is great that we finally managed to enable this for
ARM.
^ permalink raw reply [flat|nested] 16+ messages in thread