kernel.git/fs/ext2/super.c, branch linux-2.6.19.y

fix umask when noACL kernel meets extN tuned for ACLs

2007-03-03T00:32:45Z

Fix insecure default behaviour reported by Tigran Aivazian: if an ext2 or ext3 or ext4 filesystem is tuned to mount with "acl", but mounted by a kernel built without ACL support, then umask was ignored when creating inodes - though root or user has umask 022, touch creates files as 0666, and mkdir creates directories as 0777. This appears to have worked right until 2.6.11, when a fix to the default mode on symlinks (always 0777) assumed VFS applies umask: which it does, unless the mount is marked for ACLs; but ext[234] set MS_POSIXACL in s_flags according to s_mount_opt set according to def_mount_opts. We could revert to the 2.6.10 ext[234]_init_acl (adding an S_ISLNK test); but other filesystems only set MS_POSIXACL when ACLs are configured. We could fix this at another level; but it seems most robust to avoid setting the s_mount_opt flag in the first place (at the expense of more ifdefs). Likewise don't set the XATTR_USER flag when built without XATTR support. Signed-off-by: Hugh Dickins Acked-by: Andreas Gruenbacher Cc: Tigran Aivazian Signed-off-by: Greg Kroah-Hartman

[PATCH] ext2: errors behaviour fix

2006-10-11T18:14:21Z

Current error behaviour for ext2 and ext3 filesystems does not fully correspond to the documentation and should be fixed. According to man 8 mount, ext2 and ext3 file systems allow to set one of 3 different on-errors behaviours: ---- start of quote man 8 mount ---- errors=continue / errors=remount-ro / errors=panic Define the behaviour when an error is encountered. (Either ignore errors and just mark the file system erroneous and continue, or remount the file system read-only, or panic and halt the system.) The default is set in the filesystem superblock, and can be changed using tune2fs(8). ---- end of quote ---- However EXT3_ERRORS_CONTINUE is not read from the superblock, and thus ERRORS_CONT is not saved on the sbi->s_mount_opt. It leads to the incorrect handle of errors on ext3. Then we've checked corresponding code in ext2 and discovered that it is buggy as well: - EXT2_ERRORS_CONTINUE is not read from the superblock (the same); - parse_option() does not clean the alternative values and thus something like (ERRORS_CONT|ERRORS_RO) can be set; - if options are omitted, parse_option() does not set any of these options. Therefore it is possible to set any combination of these options on the ext2: - none of them may be set: EXT2_ERRORS_CONTINUE on superblock / empty mount options; - any of them may be set using mount options; - 2 any options may be set: by using EXT2_ERRORS_RO/EXT2_ERRORS_PANIC on the superblock and other value in mount options; - and finally all three options may be set by adding third option in remount. Currently ext2 uses these values only in ext2_error() and it is not leading to any noticeable troubles. However somebody may be discouraged when he will try to workaround EXT2_ERRORS_PANIC on the superblock by using errors=continue in mount options. This patch: EXT2_ERRORS_CONTINUE should be read from the superblock as default value for error behaviour. parse_option() should clean the alternative options and should not change default value taken from the superblock. Signed-off-by: Vasily Averin Acked-by: Kirill Korotaev Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] Really ignore kmem_cache_destroy return value

2006-09-27T15:26:10Z

* Rougly half of callers already do it by not checking return value * Code in drivers/acpi/osl.c does the following to be sure: (void)kmem_cache_destroy(cache); * Those who check it printk something, however, slab_error already printed the name of failed cache. * XFS BUGs on failed kmem_cache_destroy which is not the decision low-level filesystem driver should make. Converted to ignore. Signed-off-by: Alexey Dobriyan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] fs: Conversions from kmalloc+memset to k(z|c)alloc

2006-09-27T15:26:10Z

Conversions from kmalloc+memset to kzalloc. Signed-off-by: Panagiotis Issaris Jffs2-bit-acked-by: David Woodhouse Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] ext2: fix mounts at 16T

2006-09-27T15:26:09Z

Signed-off-by: Eric Sandeen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] EXT2: Remove superblock lock contention in ext2_statfs

2006-09-19T14:59:59Z

Fix a performance degradation introduced in 2.6.17. (30% degradation running dbench with 16 threads) Commit 21730eed11de42f22afcbd43f450a1872a0b5ea1, which claims to make EXT2_DEBUG work again, moves the taking of the kernel lock out of debug-only code in ext2_count_free_inodes and ext2_count_free_blocks and into ext2_statfs. The same problem was fixed in ext3 by removing the lock completely (commit 5b11687924e40790deb0d5f959247ade82196665) Signed-off-by: Dave Kleikamp Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] knfsd: Have ext2 reject file handles with bad inode numbers early

2006-09-16T19:54:30Z

This prevents bad inode numbers from triggering errors in ext2_get_inode. [akpm@osdl.org: speedup, cleanup] Signed-off-by: Neil Brown Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] ext2: prevent div-by-zero on corrupted fs

2006-08-27T18:01:30Z

Mounting an ext2 filesystem with zero s_inodes_per_group will cause a divide error. Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] lockdep: annotate the quota code

2006-07-03T22:27:08Z

The quota code plays interesting games with the lock ordering; to quote Jan: | i_mutex of inode containing quota file is acquired after all other | quota locks. i_mutex of all other inodes is acquired before quota | locks. Quota code makes sure (by resetting inode operations and | setting special flag on inode) that noone tries to enter quota code | while holding i_mutex on a quota file... The good news is that all of this special case i_mutex grabbing happens in the (per filesystem) low level quota write function. For this special case we need a new I_MUTEX_* nesting level, since this just entirely outside any of the regular VFS locking rules for i_mutex. I trust Jan on his blue eyes that this is not ever going to deadlock; and based on that the patch below is what it takes to inform lockdep of these very interesting new locking rules. The new locking rule for the I_MUTEX_QUOTA nesting level is that this is the deepest possible level of nesting for i_mutex, and that this only should be used in quota write (and possibly read) function of filesystems. This makes the lock ordering of the I_MUTEX_* levels: I_MUTEX_PARENT -> I_MUTEX_CHILD -> I_MUTEX_NORMAL -> I_MUTEX_QUOTA Has no effect on non-lockdep kernels. Signed-off-by: Arjan van de Ven Acked-by: Ingo Molnar Cc: Jan Kara Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Remove obsolete #include

2006-06-30T17:25:36Z

Signed-off-by: Jörn Engel Signed-off-by: Adrian Bunk