linux-kernel - Re: [PATCH v2] asm-generic: Fix unistd

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAMuHMdXQqEYsL4KfDb4EkS+P+6qW=E4m3wunx_LXZddXVZMd4g@mail.gmail.com>
Date:   Wed, 12 Feb 2020 10:57:39 +0100
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Michal Simek <michal.simek@...inx.com>
Cc:     Max Filippov <jcmvbkbc@...il.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Michal Simek <monstr@...str.eu>, git@...inx.com,
        Arnd Bergmann <arnd@...db.de>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Stefan Asserhall <stefan.asserhall@...inx.com>,
        Chris Zankel <chris@...kel.net>,
        "David S. Miller" <davem@...emloft.net>,
        Fenghua Yu <fenghua.yu@...el.com>,
        Helge Deller <deller@....de>,
        Ivan Kokshaysky <ink@...assic.park.msu.ru>,
        "James E.J. Bottomley" <James.Bottomley@...senpartnership.com>,
        Matt Turner <mattst88@...il.com>,
        Rich Felker <dalias@...c.org>,
        Richard Henderson <rth@...ddle.net>,
        Tony Luck <tony.luck@...el.com>,
        Yoshinori Sato <ysato@...rs.sourceforge.jp>,
        "open list:ALPHA PORT" <linux-alpha@...r.kernel.org>,
        "open list:IA64 (Itanium) PL..." <linux-ia64@...r.kernel.org>,
        "open list:M68K ARCHITECTURE" <linux-m68k@...ts.linux-m68k.org>,
        "open list:PARISC ARCHITECTURE" <linux-parisc@...r.kernel.org>,
        "open list:SUPERH" <linux-sh@...r.kernel.org>,
        "open list:TENSILICA XTENSA PORT (xtensa)" 
        <linux-xtensa@...ux-xtensa.org>,
        "open list:SPARC + UltraSPAR..." <sparclinux@...r.kernel.org>
Subject: Re: [PATCH v2] asm-generic: Fix unistd_32.h generation format

Hi Michal,

On Wed, Feb 12, 2020 at 10:42 AM Michal Simek <michal.simek@...inx.com> wrote:
> On 12. 02. 20 10:40, Geert Uytterhoeven wrote:
> > On Wed, Feb 12, 2020 at 10:38 AM Michal Simek <michal.simek@...inx.com> wrote:
> >> On 12. 02. 20 10:32, Geert Uytterhoeven wrote:
> >>> On Wed, Feb 12, 2020 at 10:27 AM Michal Simek <michal.simek@...inx.com> wrote:
> >>>> On 12. 02. 20 10:25, Geert Uytterhoeven wrote:
> >>>>> On Wed, Feb 12, 2020 at 10:23 AM Max Filippov <jcmvbkbc@...il.com> wrote:
> >>>>>> On Wed, Feb 12, 2020 at 1:16 AM Michal Simek <michal.simek@...inx.com> wrote:
> >>>>>>>
> >>>>>>> Generated files are also checked by sparse that's why add newline
> >>>>>>> to remove sparse (C=1) warning.
> >>>>>>>
> >>>>>>> The issue was found on Microblaze and reported like this:
> >>>>>>> ./arch/microblaze/include/generated/uapi/asm/unistd_32.h:438:45:
> >>>>>>> warning: no newline at end of file
> >>>>>>>
> >>>>>>> Signed-off-by: Michal Simek <michal.simek@...inx.com>
> >>>>>>> Reviewed-by: Stefan Asserhall <stefan.asserhall@...inx.com>
> >>>>>
> >>>>>>> --- a/arch/m68k/kernel/syscalls/syscallhdr.sh
> >>>>>>> +++ b/arch/m68k/kernel/syscalls/syscallhdr.sh
> >>>>>>> @@ -33,4 +33,5 @@ grep -E "^[0-9A-Fa-fXx]+[[:space:]]+${my_abis}" "$in" | sort -n | (
> >>>>>>>         printf "#endif\n"
> >>>>>>>         printf "\n"
> >>>>>>>         printf "#endif /* %s */\n" "${fileguard}"
> >>>>>>
> >>>>>> Here there's already \n at the end, so no need for another one?
> >>>>>
> >>>>> Thanks! I completely missed that.
> >>>>> So I did fix the original while applying ;-)
> >>>>
> >>>> I can drop m68k or align with with others. I would prefer to have the
> >>>> same solution in all these scripts.
> >>>
> >>> Yeah, it makes sense to align as much as possible.
> >>> IIRC, the original plan was to consolidate more later.
> >>>
> >>> Note that all other lines are terminated with a "\n" at the end.
> >>> The separate 'printf "\n"' is an extra blank line, not the terminator for the
> >>> previous line.
> >>
> >> Should we also get rid of 'printf "\n"' lines or just keep them as they
> >> are today?
> >
> > Usually there is a blank line above the include guard terminator, so IMHO
> > it makes sense to have that in generated files, too.
>
> I meant more not to get rid of \n just include them in current prints.
> It means like this 'printf "\n#endif /* %s */\n" "${fileguard}"'

I think having a "\n" at the start of a string makes the code harder to read.

You could move it to the end of the previous string, but that is not always
possible (e.g. after the loop), so I'd keep the separate prints for blank
lines.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-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