All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Nikanth Karthikesan <knikanth@suse.de>
Cc: 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>
Subject: Re: [PATCH] Prevent creation of files larger than RLIMIT_FSIZE using fallocate
Date: Fri, 30 Apr 2010 14:33:19 -0700	[thread overview]
Message-ID: <20100430143319.d51d6d77.akpm@linux-foundation.org> (raw)
In-Reply-To: <201004291014.07194.knikanth@suse.de>


(Amit Arora <aarora@in.ibm.com> wrote fallocate.  cc added)

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
> 
> Prevent creation of files larger than RLIMIT_FSIZE using fallocate.
> 
> Currently using posix_fallocate one can bypass an RLIMIT_FSIZE limit
> and create a file larger than the limit. Add a check for new size in
> the fallocate system call.
> 
> File-systems supporting fallocate such as ext4 are affected by this
> bug.
> 
> Signed-off-by: Nikanth Karthikesan <knikanth@suse.de>
> Reported-by: Eelis - <opensuse.org@contacts.eelis.net>
> 
> ---
> 
> diff --git a/fs/open.c b/fs/open.c
> index 74e5cd9..4ca57c9 100644
> --- a/fs/open.c
> +++ b/fs/open.c
> @@ -405,17 +405,26 @@ int do_fallocate(struct file *file, int mode, loff_t offset, loff_t len)
>  	if (S_ISFIFO(inode->i_mode))
>  		return -ESPIPE;
>  
> -	/*
> -	 * Let individual file system decide if it supports preallocation
> -	 * for directories or not.
> -	 */
> -	if (!S_ISREG(inode->i_mode) && !S_ISDIR(inode->i_mode))
> -		return -ENODEV;
> -
> -	/* Check for wrap through zero too */
> -	if (((offset + len) > inode->i_sb->s_maxbytes) || ((offset + len) < 0))
> +	/* Check for wrap through zero */
> +	if (offset+len < 0)
>  		return -EFBIG;

I suggest that this test be moved up to where the function tests `if
(offset < 0 || len <= 0)' - it seems more logical.

Also,

-	if (offset+len < 0)
+	if (offset + len < 0)

for consistency with most other kernel code, please.

> +	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.

  parent reply	other threads:[~2010-04-30 21:34 UTC|newest]

Thread overview: 23+ 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 [this message]
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-03  8:31             ` Amit K. Arora
2010-05-04 20:44             ` Eric Sandeen
2010-05-04 20:44               ` Eric Sandeen
2010-05-05  7:55               ` [PATCH v2] " Amit K. Arora
2010-05-05  7:55                 ` Amit K. Arora
2010-05-05 15:50                 ` Eric Sandeen
2010-05-05 15:50                   ` Eric Sandeen
2010-05-03  4:23         ` [PATCH] Prevent creation of files larger than RLIMIT_FSIZE using fallocate Nikanth Karthikesan
2010-05-03  6:59           ` 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=20100430143319.d51d6d77.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=aarora@in.ibm.com \
    --cc=adilger@sun.com \
    --cc=coly.li@suse.de \
    --cc=knikanth@suse.de \
    --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 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.