linux-kernel - Re: fs/notify/fanotify/fanotify.c:198:2: note: in expansion of macro 'pr_warn

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:   Thu, 14 Mar 2019 15:31:58 +0100
From:   Ralf Baechle <ralf@...ux-mips.org>
To:     Jan Kara <jack@...e.cz>
Cc:     Amir Goldstein <amir73il@...il.com>, kbuild-all@...org,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-mips@...r.kernel.org, Paul Burton <paul.burton@...s.com>,
        James Hogan <jhogan@...nel.org>
Subject: Re: fs/notify/fanotify/fanotify.c:198:2: note: in expansion of macro
 'pr_warn_ratelimited'

On Thu, Mar 14, 2019 at 01:38:11PM +0100, Jan Kara wrote:

> On Thu 14-03-19 14:01:18, Amir Goldstein wrote:
> > On Thu, Mar 14, 2019 at 10:37 AM Jan Kara <jack@...e.cz> wrote:
> > >
> > > AFAICS this is the known problem with weird mips definitions of
> > > __kernel_fsid_t which uses long whereas all other architectures use int,
> > > right? Seeing that mips can actually have 8-byte longs, I guess this
> > > bogosity is just wired in the kernel API and we cannot easily fix it in
> > > mips (mips guys, correct me if I'm wrong). So what if we just
> > > unconditionally typed printed values to unsigned int to silence the
> > > warning?
> > 
> > I don't understand why. To me that sounds like papering over a bug.
> > 
> > See this reply from mips developer Paul Burton:
> > https://marc.info/?l=linux-fsdevel&m=154783680019904&w=2
> > mips developers have not replied to the question why __kernel_fsid_t
> > should use long.
> 
> Ah, right. I've missed that mips defines __kernel_fsid_t only if
> sizeof(long) == 4. OK, than fixing MIPS headers is definitely what we ought
> to do. Mips guys, any reason why the patch from Ralf didn't get merged yet?

Paul's patch :-)

As for the reason why the definition is as it is - 32-bit MIPS was
born using long, then in 2000 64-bit MIPS started off as arch/mips64
using int.  Eventually the two ports were combined using:

ypedef struct {
#if (_MIPS_SZLONG == 32)
        long    val[2];
#endif
#if (_MIPS_SZLONG == 64)
        int     val[2];
#endif
} __kernel_fsid_t;

A desparate attempt to use asm-generic where ever possible then resulted
in the confusing definition we'e having today.

Normally APIs are cast into stone not to be changed.  But fsid is used in
struct statfs and the man page states "Nobody knows what f_fsid is supposed
to contain (but see below)." and f_fsid is supposed to be opaque anyway so
I'm wondering if something could break at all.  Researching that.

  Ralf