linux-kernel - Re: [GIT PULL] MIPS changes

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] [day] [month] [year] [list]

Message-ID: <CAHk-=wi4g0NgX9BLiTCqFYuM3H2AuhY+uCYfauOegz8OV2HjjA@mail.gmail.com>
Date:   Tue, 24 Sep 2019 08:32:04 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     David Howells <dhowells@...hat.com>
Cc:     Paul Burton <paul.burton@...s.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
        Florian Fainelli <f.fainelli@...il.com>
Subject: Re: [GIT PULL] MIPS changes

On Tue, Sep 24, 2019 at 5:40 AM David Howells <dhowells@...hat.com> wrote:
>
> Linus Torvalds <torvalds@...ux-foundation.org> wrote:
>
> > In honesty, I actually do have one warning in my tree:
> >
> >   samples/vfs/test-statx.c:24:15: warning: ‘struct foo’ declared
> > inside parameter list
>
> Were there any note lines from the compiler associated with this?  The warning
> message can't actually be taking place on this line.

That's the only thing that gcc says. I agree that it's not where the
problem occurs, but the gcc warning system tries to avoid warning
inside system header files, so it seems to have logic tracing it back
to the user.

But I have system header files that look like this:

  /* Fill *BUF with information about PATH in DIRFD.  */
  int statx (int __dirfd, const char *__restrict __path, int __flags,
             unsigned int __mask, struct statx *__restrict __buf)
    __THROW __nonnull ((2, 5));

and I think that's the one that triggers.

You must have hit *something* similar too, since the only reason for that

  #define statx foo
  #define statx_timestamp foo_timestamp
  #include <sys/stat.h>
  #undef statx
  #undef statx_timestamp

is that you're playing games with the kernel 'statx' clashing with
user 'statx' use.

And what I think happens is that you had the <sys/types.h> include
*without* that #define, so the 'struct statx' got declared there, and
then in <sys/stat.h> it gets used, but it gets used as 'struct foo',
so now the compiler complains (properly) that you're using this
undeclared 'struct foo' in the function declaration, and because of
namespace rules it's not the same thing as then a later 'struct foo'
would be.

              Linus

              Linus