[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFy0E1nm=YH_TMH9wUGuBHRit=_d+WQ_H88b_8Cp0fR+Rg@mail.gmail.com>
Date: Mon, 6 Aug 2018 11:45:29 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: Sergey Klyaus <sergey.m.klyaus@...il.com>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Li Wang <liwang@...hat.com>,
Andreas Dilger <adilger@...ger.ca>,
Andi Kleen <andi.kleen@...el.com>
Subject: Re: [PATCH] vfs: fix statfs64() returning impossible EOVERFLOW for
64-bit f_files
On Mon, Aug 6, 2018 at 10:06 AM Al Viro <viro@...iv.linux.org.uk> wrote:
>
> That leaves us with f_bsize and f_frsize (the latter defaulting to the former).
> Hugetlbfs can put greater than 4Gb values in there, for really huge pages.
> And that's the only thing worth checking in there.
>
> So the whole put_compat_statfs64() thing should be
Ack, I'm ok with this simplification.
> I'm somewhat tempted to get rid of those 'long' in struct kstatfs,
I'm ok with this one too.
> with
>
> #define STATFS_COPYOUT(type) \
> static int put##type(struct kstatfs *st, struct type __user *p) \
No. Don't do this.
I'm ok with the #define to avoid duplication, but don't bother with
the FIT_IN() after you've above successfully argued that it's
pointless for anything but f_bsize/frsize.
So if you do the macro to generate the different copyout versions,
just use your simplified code for that macro instead. With FIT_IN()
just for f_bsize/frsize.
Linus
Powered by blists - more mailing lists