Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20190921231022.kawfomtmka737arq@pburton-laptop>
 <CAHk-=wjmJbF3p9vZTW2nbeD4LkG-JZV+uqv8BnxzojJ5SZsLjw@mail.gmail.com>
 <20190923180728.flp6jx4jc2bh7cys@pburton-laptop> <CAHk-=wiC_B8R6th+83vKwGT1H-8vtFrmMg+1mK_P8n3VeWAWRg@mail.gmail.com>
 <14580.1569328815@warthog.procyon.org.uk>
In-Reply-To: <14580.1569328815@warthog.procyon.org.uk>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue, 24 Sep 2019 08:32:04 -0700
Message-ID: <CAHk-=wi4g0NgX9BLiTCqFYuM3H2AuhY+uCYfauOegz8OV2HjjA@mail.gmail.com>
Subject: Re: [GIT PULL] MIPS changes
To:     David Howells <dhowells@redhat.com>
Cc:     Paul Burton <paul.burton@mips.com>,
        Al Viro <viro@zeniv.linux.org.uk>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
        Florian Fainelli <f.fainelli@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Sep 24, 2019 at 5:40 AM David Howells <dhowells@redhat.com> wrote:
>
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> > In honesty, I actually do have one warning in my tree:
> >
> >   samples/vfs/test-statx.c:24:15: warning: =E2=80=98struct foo=E2=80=99=
 declared
> > inside parameter list
>
> Were there any note lines from the compiler associated with this?  The wa=
rning
> 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