Re: fs/notify/fanotify/fanotify.c:198:2: note: in expansion of macro 'pr_warn_ratelimited'

[Ralf Baechle]

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@xxxxxxx> 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