From: Ralf Baechle <ralf@linux-mips.org>
To: Jan Kara <jack@suse.cz>
Cc: Amir Goldstein <amir73il@gmail.com>,
kbuild-all@01.org, linux-kernel <linux-kernel@vger.kernel.org>,
linux-mips@vger.kernel.org, Paul Burton <paul.burton@mips.com>,
James Hogan <jhogan@kernel.org>
Subject: Re: fs/notify/fanotify/fanotify.c:198:2: note: in expansion of macro 'pr_warn_ratelimited'
Date: Thu, 14 Mar 2019 15:31:58 +0100 [thread overview]
Message-ID: <20190314143158.GC27249@linux-mips.org> (raw)
In-Reply-To: <20190314123811.GH16658@quack2.suse.cz>
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@suse.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
next prev parent reply other threads:[~2019-03-14 14:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <201903140234.4FpTWdW3%lkp@intel.com>
2019-03-14 8:37 ` fs/notify/fanotify/fanotify.c:198:2: note: in expansion of macro 'pr_warn_ratelimited' Jan Kara
2019-03-14 12:01 ` Amir Goldstein
2019-03-14 12:38 ` Jan Kara
2019-03-14 14:31 ` Ralf Baechle [this message]
2019-03-14 16:16 ` Amir Goldstein
2019-03-14 17:45 ` Paul Burton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190314143158.GC27249@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=amir73il@gmail.com \
--cc=jack@suse.cz \
--cc=jhogan@kernel.org \
--cc=kbuild-all@01.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=paul.burton@mips.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox