Amit K. Arora | 1 May 09:04 2010
Picon

Re: [PATCH] Prevent creation of files larger than RLIMIT_FSIZE using fallocate

On Fri, Apr 30, 2010 at 02:33:19PM -0700, Andrew Morton wrote:
> 
> (Amit Arora <aarora <at> 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 <at> 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;
(Continue reading)

Christoph Hellwig | 1 May 12:18 2010

Re: [PATCH] Prevent creation of files larger than RLIMIT_FSIZE using fallocate

On Sat, May 01, 2010 at 12:34:26PM +0530, Amit K. Arora wrote:
> Agreed. How about doing this check in the filesystem specific fallocate
> inode routines instead ? For example, in ext4 we could do :

That looks okay - in fact XFS should already have this check because
it re-uses the setattr implementation to set the size.

Can you submit an xfstests testcase to verify this behaviour on all
filesystems?

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Oren Laadan | 1 May 16:15 2010

[PATCH v21 042/100] c/r: add generic '->checkpoint' f_op to ext fses

From: Dave Hansen <dave <at> linux.vnet.ibm.com>

This marks ext[234] as being checkpointable.  There will be many
more to do this to, but this is a start.

Changelog[ckpt-v21]:
  - Put file_ops->checkpoint under CONFIG_CHECKPOINT
Changelog[ckpt-v19-rc3]:
  - Rebase to kernel 2.6.33 (ext2)
Changelog[v1]:
  - [Serge Hallyn] Use filemap_checkpoint() in ext4_file_vm_ops

Cc: linux-ext4 <at> vger.kernel.org
Cc: linux-fsdevel <at> vger.kernel.org
Signed-off-by: Dave Hansen <dave <at> linux.vnet.ibm.com>
Signed-off-by: Oren Laadan <orenl <at> cs.columbia.edu>
Acked-by: Serge E. Hallyn <serue <at> us.ibm.com>
Tested-by: Serge E. Hallyn <serue <at> us.ibm.com>
---
 fs/ext2/dir.c  |    3 +++
 fs/ext2/file.c |    6 ++++++
 fs/ext3/dir.c  |    3 +++
 fs/ext3/file.c |    3 +++
 fs/ext4/dir.c  |    3 +++
 fs/ext4/file.c |    6 ++++++
 6 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/fs/ext2/dir.c b/fs/ext2/dir.c
index 7516957..cdcb065 100644
--- a/fs/ext2/dir.c
(Continue reading)

Nikanth Karthikesan | 3 May 06:23 2010
Picon

Re: [PATCH] Prevent creation of files larger than RLIMIT_FSIZE using fallocate

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 <at> 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 <at> 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;
(Continue reading)

Amit K. Arora | 3 May 08:59 2010
Picon

Re: [PATCH] Prevent creation of files larger than RLIMIT_FSIZE using fallocate

On Mon, May 03, 2010 at 09:53:44AM +0530, Nikanth Karthikesan wrote:
> 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:
> > > 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.

Hmm.. I never said to call the filesystem specific fallocate with
i_mutex held. What I suggested was that each filesystem at some point
anyhow takes the i_mutex to preallocate. Thats where the check should
(Continue reading)

Amit K. Arora | 3 May 09:01 2010
Picon

Re: [PATCH] Prevent creation of files larger than RLIMIT_FSIZE using fallocate

On Sat, May 01, 2010 at 06:18:46AM -0400, Christoph Hellwig wrote:
> On Sat, May 01, 2010 at 12:34:26PM +0530, Amit K. Arora wrote:
> > Agreed. How about doing this check in the filesystem specific fallocate
> > inode routines instead ? For example, in ext4 we could do :
> 
> That looks okay - in fact XFS should already have this check because
> it re-uses the setattr implementation to set the size.

You are right. I have written a test and it passes on XFS, but fails on
ext4. 

> Can you submit an xfstests testcase to verify this behaviour on all
> filesystems?

Sure. Its ready and is under test. Will post shortly..

--
Regards,
Amit Arora
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Nikanth Karthikesan | 3 May 09:49 2010
Picon

Re: [PATCH] Prevent creation of files larger than RLIMIT_FSIZE using fallocate

On Monday 03 May 2010 12:29:45 Amit K. Arora wrote:
> On Mon, May 03, 2010 at 09:53:44AM +0530, Nikanth Karthikesan wrote:
> > 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:
> > > > 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.
> 
> Hmm.. I never said to call the filesystem specific fallocate with
> i_mutex held. What I suggested was that each filesystem at some point
(Continue reading)

Amit K. Arora | 3 May 10:31 2010
Picon

[PATCH] New testcase to check if fallocate respects RLIMIT_FSIZE or not

On Sat, May 01, 2010 at 06:18:46AM -0400, Christoph Hellwig wrote:
> On Sat, May 01, 2010 at 12:34:26PM +0530, Amit K. Arora wrote:
> > Agreed. How about doing this check in the filesystem specific fallocate
> > inode routines instead ? For example, in ext4 we could do :
> 
> That looks okay - in fact XFS should already have this check because
> it re-uses the setattr implementation to set the size.
> 
> Can you submit an xfstests testcase to verify this behaviour on all
> filesystems?

Here is the new testcase.

I have run this test on a x86_64 box on XFS and ext4 on 2.6.34-rc6. It
passes on XFS, but fails on ext4. Below is the snapshot of results
followed by the testcase itself.

--
Regards,
Amit Arora

Test results:
------------
# ./check 228
FSTYP         -- xfs (non-debug)
PLATFORM      -- Linux/x86_64 elm9m93 2.6.34-rc6

228 0s ...
Ran: 228
Passed all 1 tests
(Continue reading)

Amir G. | 3 May 11:47 2010
Picon
Picon

Re: Introducing Next3 - built-in snapshots support for Ext3

On Sun, Apr 18, 2010 at 6:41 PM, Amir G. wrote:
> Hi All,
>
> For over a year, Next3 has been developed in-house by CTERA networks,
> as part of its NAS appliances.
> Now that the appliances are out in the market, Next3 project can
> finally be shared with the world.
>
> Main Next3 features:
> - Backward and forward compatible with Ext3
> - Incremental, volume level, read-only snapshots
> - Snapshots use available file system disk space
> - Snapshot deletion frees up disk space
> - Retains Ext3 stability including journaling and fsck
> - Minimal performance overhead (in average usage scenarios)
> - No upper limit on number or size of snapshots
>
> Please visit Next3 wiki page:
> http://sourceforge.net/apps/mediawiki/next3/
>
> Next3 project is looking for code reviewers, beta testers and public attention.
>
> Would love to read your comments on Next3-users mailing list:
> https://lists.sourceforge.net/lists/listinfo/next3-users
>
> Amir.
>

Hi Ted,

(Continue reading)

Jan Kara | 3 May 12:15 2010
Picon

[PATCH RESEND] ext4: Show journal_checksum option

We failed to show journal_checksum option in /proc/mounts. Fix it.

Signed-off-by: Jan Kara <jack <at> suse.cz>
---
 fs/ext4/super.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 8f4f079..04fdaf1 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
 <at>  <at>  -846,6 +846,8  <at>  <at>  static int ext4_show_options(struct seq_file *seq, struct vfsmount *vfs)
 	seq_puts(seq, test_opt(sb, BARRIER) ? "1" : "0");
 	if (test_opt(sb, JOURNAL_ASYNC_COMMIT))
 		seq_puts(seq, ",journal_async_commit");
+	else if (test_opt(sb, JOURNAL_CHECKSUM))
+		seq_puts(seq, ",journal_checksum");
 	if (test_opt(sb, NOBH))
 		seq_puts(seq, ",nobh");
 	if (test_opt(sb, I_VERSION))
--

-- 
1.6.0.2

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Gmane