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

Date:   Tue, 24 Sep 2019 13:40:15 +0100
From:   David Howells <dhowells@...hat.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     dhowells@...hat.com, Paul Burton <paul.burton@...s.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        "linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mips\@vger.kernel.org" <linux-mips@...r.kernel.org>,
        Florian Fainelli <f.fainelli@...il.com>
Subject: Re: [GIT PULL] MIPS changes

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 will not be visible outside of this definition
> or declaration
>      24 | #define statx foo
>         |               ^~~

Were there any note lines from the compiler associated with this?  The warning
message can't actually be taking place on this line.

Another thing I'm wondering is why your compiler shows this warning - and mine
does not.  I've seen this before with uninitialised variables too where you
get a warning and I don't.

> but because it's in the sample code, it pretty much never gets rebuilt
> for me unless I basically do a "git clean" to get rid of everything,
> so I don't normally see it for any normal pull.
> 
> So I've ignored that one warning, although I've actually been tempted
> to just remove the sample because of it.
> 
> Adding David and Al to the cc just in case they have some simple fixup
> for it that is likely to work across different user headers.
> 
> I considered just adding a
> 
>      struct foo;
> 
> declaration, but the whole thing is incredibly ugly.

Yeah - I'm not sure the best way to deal with this.  The problem being that
userspace may have a conflicting definition - or no definition at all - and I
need to use the one from the kernel in preference as that may have changes in
it that aren't yet reflected in userspace.

I'd rather not remove the sample if I can avoid it as I use it occasionally,
but maybe I should switch to relying on glibc.

David