Re: [git pull] m68k updates for 5.1
The pull request you sent on Fri, 1 Mar 2019 14:50:01 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git > tags/m68k-for-v5.1-tag1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/45f5532a2f65afeda9e8a02bf1aca15c2b4c9be8 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH] x86: Deprecate a.out support
On Tue, Mar 05, 2019 at 07:11:38PM +0100, Borislav Petkov wrote: > I guess you could Cc arch maintainers with the a.out-core.h removal > patch to see if anyone screams. And they're like two for which we need confirmation: $ git ls-files | grep a.out-core.h arch/alpha/include/asm/a.out-core.h arch/m68k/include/asm/a.out-core.h arch/um/include/asm/a.out-core.h arch/x86/include/asm/a.out-core.h um and x86 are clear. Adding alpha and m68k MLs to Cc. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH v4 00/14] m68k: Drop arch_gettimeoffset and adopt clocksource API
On Tue, Mar 5, 2019 at 10:55 AM Finn Thain wrote: > That leaves bvme6000, hp300, mvme147 and mvme16x. Those have not been > tested. Here are some options for those platforms: > > 1) Apply the patches untested (gaining new clocksources and some API > modernization for m68k, while fixing old bugs and potentially introducing > new bugs). This is what I usually do with ARM machines when I don't get any tests or reviews after a reasonable time lap, > month for sure is a reasonable time for users to have all opportunity in the world to test patches. If things break, users will report it as is custom and the author will be expected to work with them to fix them then, we do this all the time. Those users who want everything tested before it gets merged should provide resources or time for testing. Just my €0.01 Linus Walleij
Re: [PATCH v4 00/14] m68k: Drop arch_gettimeoffset and adopt clocksource API
On Tue, 5 Mar 2019, Geert Uytterhoeven wrote:
> On Tue, Mar 5, 2019 at 7:13 AM Finn Thain wrote:
> > On Sat, 1 Dec 2018, Finn Thain wrote:
> > > This series removes "select ARCH_USES_GETTIMEOFFSET" from arch/m68k
> > > and converts users of arch_gettimeoffset to the clocksource API.
> > > Various bugs are fixed along the way.
> >
> > Are there any plans to merge this series, Geert?
>
> Has this been tested on all/most platforms? Or do you think is it safe to
> apply regardless?
>
The amiga, atari and mac patches have been tested.
The apollo, q40, sun3 and sun3x patches are safe though untested, AFAIK. I
confirmed that, in qemu at least, the default jiffies clocksource will
work, and the patch is trivial.
That leaves bvme6000, hp300, mvme147 and mvme16x. Those have not been
tested. Here are some options for those platforms:
1) Apply the patches untested (gaining new clocksources and some API
modernization for m68k, while fixing old bugs and potentially introducing
new bugs).
2) Do nothing until someone tests the patch series on those 4 platforms.
3) Rewrite patches such that those 4 platforms get the same treatment as
apollo, q40, sun3 and sun3x (this plan was already nak'd in the hp300
case).
4) Keep using the gettimeoffset API. Redo the patch series to keep the bug
fixes for the 3 platforms that can be readily tested. When the API change
becomes unavoidable, remove difficult platforms.
Maybe there are other possibilities?
--
> Thanks!
>
> Gr{oetje,eeting}s,
>
> Geert
>
>
Re: [m68k:master 1174/1174] arch/m68k/include/asm/string.h:72:25: warning: '__builtin_memcpy' forming offset 8 is out of the bounds [0, 7]
On Mär 05 2019, Finn Thain wrote: > interesting that the kernel's strlen implementation in > include/linux/string.h can't achieve this. This implementation is only available if ARCH_HAS_FORTIFY_SOURCE. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [m68k:master 1174/1174] arch/m68k/include/asm/string.h:72:25: warning: '__builtin_memcpy' forming offset 8 is out of the bounds [0, 7]
Hi Finn,
On Tue, Mar 5, 2019 at 9:58 AM Finn Thain wrote:
> On Tue, 5 Mar 2019, Geert Uytterhoeven wrote:
> > On Tue, Mar 5, 2019 at 3:58 AM Finn Thain
> > wrote:
> > > On Tue, 5 Mar 2019, Finn Thain wrote:
> > > > Looks bogus to me.
> > > >
> > > > If you change memcpy to __builtin_memcpy, then we avoid the macro and
> > > > the
> > > > warning changes to,
> > > >
> > > > ./include/linux/string.h:456:3: warning: '__builtin_memcpy' forming
> > > > offset [7, 8] is out of the bounds [0, 6] [-Warray-bounds]
> > > >__builtin_memcpy(dest, src, dest_len);
> > > >
> > > > The compiler has nothing to complain about here. dest is known to be
> > > > id->fr and dest_len is known to be sizeof(id->fr).
> > > >
> > > > The error message indicates that gcc has applied the bounds [0, 6] to
> > > > dest
> > > > when in fact those are the bounds for src.
> > > >
> > >
> > > My mistake. GCC is right, it seems memcpy will read past the end of
> > > "5.0.0+".
> >
> > But only if the else branch is taken, which is not the case.
> >
>
> You and I know that, because we can see what values get passed to
> memcpy_and_pad(). But how is gcc to know that?
Gcc also sees (partly) what values get passed, else it would not give that
warning.
Still, should gcc give warnings based on branches that may or may not be
taken? I guess there are lots of cases in the kernel where this could lead
to false positives.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [m68k:master 1174/1174] arch/m68k/include/asm/string.h:72:25: warning: '__builtin_memcpy' forming offset 8 is out of the bounds [0, 7]
On Tue, 5 Mar 2019, Geert Uytterhoeven wrote:
> On Tue, Mar 5, 2019 at 3:58 AM Finn Thain wrote:
> > On Tue, 5 Mar 2019, Finn Thain wrote:
> > > Looks bogus to me.
> > >
> > > If you change memcpy to __builtin_memcpy, then we avoid the macro and the
> > > warning changes to,
> > >
> > > ./include/linux/string.h:456:3: warning: '__builtin_memcpy' forming
> > > offset [7, 8] is out of the bounds [0, 6] [-Warray-bounds]
> > >__builtin_memcpy(dest, src, dest_len);
> > >
> > > The compiler has nothing to complain about here. dest is known to be
> > > id->fr and dest_len is known to be sizeof(id->fr).
> > >
> > > The error message indicates that gcc has applied the bounds [0, 6] to dest
> > > when in fact those are the bounds for src.
> > >
> >
> > My mistake. GCC is right, it seems memcpy will read past the end of
> > "5.0.0+".
>
> But only if the else branch is taken, which is not the case.
>
You and I know that, because we can see what values get passed to
memcpy_and_pad(). But how is gcc to know that?
If we replace strlen with __builtin_strlen, this problem goes away. It's
interesting that the kernel's strlen implementation in
include/linux/string.h can't achieve this.
--
> Gr{oetje,eeting}s,
>
> Geert
>
>
