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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 4 Dec 2018 08:55:55 +0100
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     firoz.khan@...aro.org
Cc:     linux-m68k <linux-m68k@...ts.linux-m68k.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Philippe Ombredanne <pombredanne@...b.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Kate Stewart <kstewart@...uxfoundation.org>,
        y2038 Mailman List <y2038@...ts.linaro.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux-Arch <linux-arch@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Deepa Dinamani <deepa.kernel@...il.com>,
        marcin.juszkiewicz@...aro.org
Subject: Re: [PATCH v5 2/3] m68k: add system call table generation support

Hi Firoz,

On Tue, Dec 4, 2018 at 4:22 AM Firoz Khan <firoz.khan@...aro.org> wrote:
> On Sun, 2 Dec 2018 at 19:27, Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> > On Tue, Nov 13, 2018 at 7:01 AM Firoz Khan <firoz.khan@...aro.org> wrote:
> > > The system call tables are in different format in all
> > > architecture and it will be difficult to manually add,
> > > modify or delete the syscall table entries in the res-
> > > pective files. To make it easy by keeping a script and
> > > which will generate the uapi header and syscall table
> > > file. This change will also help to unify the implemen-
> > > tation across all architectures.
> > >
> > > The system call table generation script is added in
> > > kernel/syscalls directory which contain the scripts to
> > > generate both uapi header file and system call table
> > > files. The syscall.tbl will be input for the scripts.
> > >
> > > syscall.tbl contains the list of available system calls
> > > along with system call number and corresponding entry
> > > point. Add a new system call in this architecture will
> > > be possible by adding new entry in the syscall.tbl file.
> > >
> > > Adding a new table entry consisting of:
> > >         - System call number.
> > >         - ABI.
> > >         - System call name.
> > >         - Entry point name.
> > >
> > > syscallhdr.sh and syscalltbl.sh will generate uapi header
> > > unistd_32.h and syscall_table.h files respectively. Both
> > > .sh files will parse the content syscall.tbl to generate
> > > the header and table files. unistd_32.h will be included
> > > by uapi/asm/unistd.h and syscall_table.h is included by
> > > kernel/syscall_table.S - the real system call table.
> > >
> > > ARM, s390 and x86 architecuture does have similar support.
> > > I leverage their implementation to come up with a generic
> > > solution.
> > >
> > > Signed-off-by: Firoz Khan <firoz.khan@...aro.org>
> >
> > Thanks for your patch!
> >
> > > --- /dev/null
> > > +++ b/arch/m68k/kernel/syscalls/syscallhdr.sh

> > > +       printf "#endif\n"
> > > +       printf "\n"
> > > +       printf "#endif /* %s */" "${fileguard}"
> >
> > The above line is lacking a "\n", causing:
> >
> >     ./arch/m68k/include/generated/uapi/asm/unistd_32.h:370:42:
> > warning: no newline at end of file
>
> I was wondering, I haven't seen this warning when I compiled it.

It seems to depend on the compiler version.
One more thing found by my good old gcc-4.1 ;-)
(which I plan to retire soon, as I need to revert too many "drop support
 for old gcc" patches to keep it working :-(.

> > Changing it to:
> >
> >     printf "#endif /* %s */\n" "${fileguard}"
> >
> > fixes this.
>
> Yes.
>
> > Interestingly, this issue seems to be present on powerpc, parisc, sparc,
> > sh, xtensa (and probably more, I gave up looking), too?
>
> I kept the script to generate files *almost* identical. so this will be present
> all 10 architecture.
>
> > Apart from that, it seems to work fine on m68k.
>
> I have three options here to fix this;
> 1. I can send v6 by fixing this one.
> 2. I can post a single patch which add \n in the script.
> 3. Could you able to add \n in the script.
>
> Please choose one, I can act accordingly.

So your plan is for me to apply your series to the m68k tree?
In that case there's no need to send a v6, I can incorporate the fix myself.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ