From: Nick Piggin <npiggin@suse.de>
To: Andreas Dilger <adilger@sun.com>
Cc: Jon Tollefson <kniht@linux.vnet.ibm.com>,
Nishanth Aravamudan <nacc@us.ibm.com>,
linux-mm@kvack.org, andi@firstfloor.org, agl@us.ibm.com,
abh@cray.com, joachim.deguara@amd.com,
linux-fsdevel@vger.kernel.org
Subject: Re: [patch 22/23] fs: check for statfs overflow
Date: Tue, 3 Jun 2008 05:27:15 +0200 [thread overview]
Message-ID: <20080603032715.GB17089@wotan.suse.de> (raw)
In-Reply-To: <20080602031602.GA2961@webber.adilger.int>
On Sun, Jun 01, 2008 at 09:16:02PM -0600, Andreas Dilger wrote:
> On May 30, 2008 03:14 +0200, Nick Piggin wrote:
> > On Thu, May 29, 2008 at 05:56:07PM -0600, Andreas Dilger wrote:
> > > On May 28, 2008 11:02 +0200, Nick Piggin wrote:
> > > > @@ -197,8 +197,8 @@ static int put_compat_statfs(struct comp
> > > > if (sizeof ubuf->f_blocks == 4) {
> > > > + if ((kbuf->f_blocks | kbuf->f_bfree | kbuf->f_bavail |
> > > > + kbuf->f_bsize | kbuf->f_frsize) & 0xffffffff00000000ULL)
> > > > return -EOVERFLOW;
> > >
> > > Hmm, doesn't this check break every filesystem > 16TB on 4kB PAGE_SIZE
> > > nodes? It would be better, IMHO, to scale down f_blocks, f_bfree, and
> > > f_bavail and correspondingly scale up f_bsize to fit into the 32-bit
> > > statfs structure.
> >
> > Oh? Hmm, from my reading, such filesystems will already overflow f_blocks
> > check which is already there. Jon's patch only adds checks for f_bsize
> > and f_frsize.
>
> Sorry, you are right - I meant that the whole f_blocks check is broken
> for filesystems > 16TB. Scaling f_bsize is easy, and prevents gratuitous
> breakage of old applications for a few kB of accuracy.
Oh... hmm OK but they do have stat64 I guess, although maybe they aren't
coded for it.
Anyway, point is noted, but I'm not the person (nor is this the patchset)
to make such changes.
Do you agree that if we have these checks in coimpat_statfs, then we
should put the same ones in the non-compat as well as the 64 bit
versions?
Thanks,
Nick
next prev parent reply other threads:[~2008-06-03 3:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20080525142317.965503000@nick.local0.net>
[not found] ` <20080525143454.453947000@nick.local0.net>
[not found] ` <20080527171452.GJ20709@us.ibm.com>
[not found] ` <483C42B9.7090102@linux.vnet.ibm.com>
2008-05-28 9:02 ` [patch 22/23] fs: check for statfs overflow Nick Piggin
2008-05-29 23:56 ` Andreas Dilger
2008-05-30 0:12 ` Nishanth Aravamudan
2008-05-30 1:14 ` Nick Piggin
2008-06-02 3:16 ` Andreas Dilger
2008-06-03 3:27 ` Nick Piggin [this message]
2008-06-03 17:17 ` Andreas Dilger
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=20080603032715.GB17089@wotan.suse.de \
--to=npiggin@suse.de \
--cc=abh@cray.com \
--cc=adilger@sun.com \
--cc=agl@us.ibm.com \
--cc=andi@firstfloor.org \
--cc=joachim.deguara@amd.com \
--cc=kniht@linux.vnet.ibm.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nacc@us.ibm.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;
as well as URLs for NNTP newsgroup(s).