From: Linus Torvalds <torvalds@linux-foundation.org>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Sergey Klyaus <sergey.m.klyaus@gmail.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Li Wang <liwang@redhat.com>, Andreas Dilger <adilger@dilger.ca>,
Andi Kleen <andi.kleen@intel.com>
Subject: Re: [PATCH] vfs: fix statfs64() returning impossible EOVERFLOW for 64-bit f_files
Date: Mon, 6 Aug 2018 11:45:29 -0700 [thread overview]
Message-ID: <CA+55aFy0E1nm=YH_TMH9wUGuBHRit=_d+WQ_H88b_8Cp0fR+Rg@mail.gmail.com> (raw)
In-Reply-To: <20180806170634.GA2490@ZenIV.linux.org.uk>
On Mon, Aug 6, 2018 at 10:06 AM Al Viro <viro@zeniv.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
next prev parent reply other threads:[~2018-08-06 18:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-05 18:36 [PATCH] vfs: fix statfs64() returning impossible EOVERFLOW for 64-bit f_files Sergey Klyaus
2017-10-05 20:57 ` Al Viro
2017-10-05 22:31 ` Linus Torvalds
2017-10-05 23:06 ` Al Viro
2017-10-06 1:31 ` Linus Torvalds
2017-10-18 16:04 ` [PATCH v2] vfs: Improve overflow checking for stat*() compat fields Sergey Klyaus
2018-08-06 17:06 ` [PATCH] vfs: fix statfs64() returning impossible EOVERFLOW for 64-bit f_files Al Viro
2018-08-06 18:45 ` Linus Torvalds [this message]
2018-08-06 21:03 ` Al Viro
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='CA+55aFy0E1nm=YH_TMH9wUGuBHRit=_d+WQ_H88b_8Cp0fR+Rg@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=adilger@dilger.ca \
--cc=andi.kleen@intel.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liwang@redhat.com \
--cc=sergey.m.klyaus@gmail.com \
--cc=viro@zeniv.linux.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.