From: Nikanth Karthikesan <knikanth@suse.de>
To: "Amit K. Arora" <aarora@linux.vnet.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
coly.li@suse.de, Nick Piggin <npiggin@suse.de>,
Alexander Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org, "Theodore Ts'o" <tytso@mit.edu>,
Andreas Dilger <adilger@sun.com>,
linux-ext4@vger.kernel.org,
Eelis <opensuse.org@contacts.eelis.net>,
Amit Arora <aarora@in.ibm.com>,
Christoph Hellwig <hch@infradead.org>
Subject: Re: [PATCH] Prevent creation of files larger than RLIMIT_FSIZE using fallocate
Date: Mon, 3 May 2010 09:53:44 +0530 [thread overview]
Message-ID: <201005030953.45157.knikanth@suse.de> (raw)
In-Reply-To: <20100501070426.GA9562@amitarora.in.ibm.com>
On Saturday 01 May 2010 12:34:26 Amit K. Arora wrote:
> On Fri, Apr 30, 2010 at 02:33:19PM -0700, Andrew Morton wrote:
> > (Amit Arora <aarora@in.ibm.com> wrote fallocate. cc added)
>
> Thanks for adding me to CC.
>
> > On Thu, 29 Apr 2010 10:14:06 +0530
> >
> > Nikanth Karthikesan <knikanth@suse.de> wrote:
> > > Here is an updated patch that takes the i_mutex and calls
> > > inode_newsize_ok() only for regular files.
> >
> > err, no. It's taking i_lock where it meant to take i_mutex.
> >
> > > Thanks
> > > Nikanth
> > >
> > > + if (S_ISREG(inode->i_mode)) {
> > > + spin_lock(&inode->i_lock);
> > > + ret = inode_newsize_ok(inode, (offset + len));
> > > + spin_unlock(&inode->i_lock);
> > > + if (ret)
> > > + return ret;
> > > + } else if (S_ISDIR(inode->i_mode)) {
> > > + /*
> > > + * Let individual file system decide if it supports
> > > + * preallocation for directories or not.
> > > + */
> > > + if (offset > inode->i_sb->s_maxbytes)
> > > + return -EFBIG;
> > > + } else
> > > + return -ENODEV;
> > > +
> > > if (!inode->i_op->fallocate)
> > > return -EOPNOTSUPP;
> >
> > Also, there doesn't seem to be much point in doing
> >
> > mutex_lock(i_mutex);
> > if (some_condition)
> > bale out
> > mutex_unlock(i_mutex);
> >
> > <stuff>
> >
> > because `some_condition' can now become true before or during the
> > execution of `stuff'.
> >
> > IOW, it's racy.
>
oh, yes. :(
> Agreed. How about doing this check in the filesystem specific fallocate
> inode routines instead ? For example, in ext4 we could do :
>
I guess, calling the filesystem specific fallocate with the lock held would
create lock ordering problems? If so, this might be the only way. But it would
be better to document at the call site, that the callee should check for
RLIMIT_FSIZE.
Thanks
Nikanth
> diff -Nuarp linux-2.6.org/fs/ext4/extents.c linux-2.6.new/fs/ext4/extents.c
> --- linux-2.6.org/fs/ext4/extents.c 2010-05-01 12:16:07.000000000 +0530
> +++ linux-2.6.new/fs/ext4/extents.c 2010-05-01 12:17:37.000000000 +0530
> @@ -3672,6 +3672,11 @@ long ext4_fallocate(struct inode *inode,
> */
> credits = ext4_chunk_trans_blocks(inode, max_blocks);
> mutex_lock(&inode->i_mutex);
> + ret = inode_newsize_ok(inode, (offset + len));
> + if (ret) {
> + mutex_unlock(&inode->i_mutex);
> + return ret;
> + }
> retry:
> while (ret >= 0 && ret < max_blocks) {
> block = block + ret;
>
>
> Similarly for ocfs2, btrfs and xfs..
>
> --
> Regards,
> Amit Arora
>
next prev parent reply other threads:[~2010-05-03 4:22 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-28 13:24 [PATCH] Prevent creation of files larger than RLIMIT_FSIZE using fallocate Nikanth Karthikesan
2010-04-28 16:15 ` Coly Li
[not found] ` <201004291014.07194.knikanth@suse.de>
[not found] ` <4BD9239D.6060907@suse.de>
2010-04-29 9:23 ` Andreas Dilger
2010-04-30 21:33 ` Andrew Morton
2010-04-30 21:40 ` Andreas Dilger
2010-05-01 7:04 ` Amit K. Arora
2010-05-01 10:18 ` Christoph Hellwig
2010-05-03 7:01 ` Amit K. Arora
2010-05-03 8:31 ` [PATCH] New testcase to check if fallocate respects RLIMIT_FSIZE or not Amit K. Arora
2010-05-04 20:44 ` Eric Sandeen
2010-05-05 7:55 ` [PATCH v2] " Amit K. Arora
2010-05-05 15:50 ` Eric Sandeen
2010-05-03 4:23 ` Nikanth Karthikesan [this message]
2010-05-03 6:59 ` [PATCH] Prevent creation of files larger than RLIMIT_FSIZE using fallocate Amit K. Arora
2010-05-03 7:49 ` Nikanth Karthikesan
2010-05-04 5:44 ` [PATCH] btrfs: " Nikanth Karthikesan
2010-05-04 5:45 ` [PATCH] ext4: " Nikanth Karthikesan
2010-05-04 6:28 ` Amit K. Arora
2010-05-21 1:11 ` tytso
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=201005030953.45157.knikanth@suse.de \
--to=knikanth@suse.de \
--cc=aarora@in.ibm.com \
--cc=aarora@linux.vnet.ibm.com \
--cc=adilger@sun.com \
--cc=akpm@linux-foundation.org \
--cc=coly.li@suse.de \
--cc=hch@infradead.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=npiggin@suse.de \
--cc=opensuse.org@contacts.eelis.net \
--cc=tytso@mit.edu \
--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 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).