linux-stable.git/fs, branch linux-2.6.28.y

fs core fixes

2009-05-02T17:57:18+00:00

Please add the following 4 commits to 2.6.27-stable and 2.6.28-stable.
However, there has been a lot of change here between 2.6.28 and 2.6.29:
in particular, fs/exec.c's unsafe_exec() grew into the more complicated
check_unsafe_exec().  So applying the original patches gives too many
rejects: at the bottom is the diffstat and the combined patch required.

1
Commit: 53e9309e01277ec99c38e84e0ca16921287cf470
Author: Hugh Dickins 
Date: Sat, 28 Mar 2009 23:16:03 +0000 (+0000)
Subject: compat_do_execve should unshare_files

2
Commit: e426b64c412aaa3e9eb3e4b261dc5be0d5a83e78
Author: Hugh Dickins 
Date: Sat, 28 Mar 2009 23:20:19 +0000 (+0000)
Subject: fix setuid sometimes doesn't

3
Commit: 7c2c7d993044cddc5010f6f429b100c63bc7dffb
Author: Hugh Dickins 
Date: Sat, 28 Mar 2009 23:21:27 +0000 (+0000)
Subject: fix setuid sometimes wouldn't

4
Commit: f1191b50ec11c8e2ca766d6d99eb5bb9d2c084a3
Author: Al Viro 
Date: Mon, 30 Mar 2009 11:35:18 +0000 (-0400)
Subject: check_unsafe_exec() doesn't care about signal handlers sharing

Signed-off-by: Hugh Dickins 
Signed-off-by: Greg Kroah-Hartman

anon_inodes: use fops->owner for module refcount

2009-05-02T17:57:02+00:00

There is an imbalance for anonymous inodes. If the fops->owner field is set,
the module reference count of owner is decreases on release.
("filp_close" --> "__fput" ---> "fops_put")

On the other hand, anon_inode_getfd does not increase the module reference
count of owner. This causes two problems:

- if owner is set, the module refcount goes negative
- if owner is not set, the module can be unloaded while code is running

This patch changes anon_inode_getfd to be symmetric regarding fops->owner
handling.

I have checked all existing users of anon_inode_getfd. Noone sets fops->owner,
thats why nobody has seen the module refcount negative. The refcounting was
tested with a patched and unpatched KVM module.(see patch 2/2) I also did an
epoll_open/close test.

Signed-off-by: Christian Borntraeger 
Reviewed-by: Davide Libenzi 
Signed-off-by: Avi Kivity 
(cherry picked from commit e3a2a0d4e5ace731e60e2eff4fb7056ecb34adc1)
Signed-off-by: Greg Kroah-Hartman

block: revert part of 18ce3751ccd488c78d3827e9f6bf54e6322676fb

2009-05-02T17:57:00+00:00

commit 78f707bfc723552e8309b7c38a8d0cc51012e813 upstream.

The above commit added WRITE_SYNC and switched various places to using
that for committing writes that will be waited upon immediately after
submission. However, this causes a performance regression with AS and CFQ
for ext3 at least, since sync_dirty_buffer() will submit some writes with
WRITE_SYNC while ext3 has sumitted others dependent writes without the sync
flag set. This causes excessive anticipation/idling in the IO scheduler
because sync and async writes get interleaved, causing a big performance
regression for the below test case (which is meant to simulate sqlite
like behaviour).

---- test case ----

int main(int argc, char **argv)
{

	int fdes, i;
	FILE *fp;
	struct timeval start;
	struct timeval end;
	struct timeval res;

	gettimeofday(&start, NULL);
	for (i=0; i
Signed-off-by: Greg Kroah-Hartman

hugetlbfs: return negative error code for bad mount option

2009-05-02T17:57:00+00:00

upstream commit: c12ddba09394c60e1120e6997794fa6ed52da884

This fixes the following BUG:

  # mount -o size=MM -t hugetlbfs none /huge
  hugetlbfs: Bad value 'MM' for mount option 'size=MM'
  ------------[ cut here ]------------
  kernel BUG at fs/super.c:996!

Due to

	BUG_ON(!mnt->mnt_sb);

in vfs_kern_mount().

Also, remove unused #include 

Cc: William Irwin 
Signed-off-by: Akinobu Mita 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

splice: fix deadlock in splicing to file

2009-05-02T17:56:47+00:00

upstream commit: 7bfac9ecf0585962fe13584f5cf526d8c8e76f17

There's a possible deadlock in generic_file_splice_write(),
splice_from_pipe() and ocfs2_file_splice_write():

 - task A calls generic_file_splice_write()
 - this calls inode_double_lock(), which locks i_mutex on both
   pipe->inode and target inode
 - ordering depends on inode pointers, can happen that pipe->inode is
   locked first
 - __splice_from_pipe() needs more data, calls pipe_wait()
 - this releases lock on pipe->inode, goes to interruptible sleep
 - task B calls generic_file_splice_write(), similarly to the first
 - this locks pipe->inode, then tries to lock inode, but that is
   already held by task A
 - task A is interrupted, it tries to lock pipe->inode, but fails, as
   it is already held by task B
 - ABBA deadlock

Fix this by explicitly ordering locks: the outer lock must be on
target inode and the inner lock (which is later unlocked and relocked)
must be on pipe->inode.  This is OK, pipe inodes and target inodes
form two nonoverlapping sets, generic_file_splice_write() and friends
are not called with a target which is a pipe.

Signed-off-by: Miklos Szeredi 
Acked-by: Mark Fasheh 
Acked-by: Jens Axboe 
Signed-off-by: Linus Torvalds 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

vfs: skip I_CLEAR state inodes

2009-05-02T17:56:44+00:00

upstream commit: b6fac63cc1f52ec27f29fe6c6c8494a2ffac33fd

clear_inode() will switch inode state from I_FREEING to I_CLEAR, and do so
_outside_ of inode_lock.  So any I_FREEING testing is incomplete without a
coupled testing of I_CLEAR.

So add I_CLEAR tests to drop_pagecache_sb(), generic_sync_sb_inodes() and
add_dquot_ref().

Masayoshi MIZUMA discovered the bug in drop_pagecache_sb() and Jan Kara
reminds fixing the other two cases.

Masayoshi MIZUMA has a nice panic flow:

=====================================================================
            [process A]               |        [process B]
 |                                    |
 |    prune_icache()                  | drop_pagecache()
 |      spin_lock(&inode_lock)        |   drop_pagecache_sb()
 |      inode->i_state |= I_FREEING;  |       |
 |      spin_unlock(&inode_lock)      |       V
 |          |                         |     spin_lock(&inode_lock)
 |          V                         |         |
 |      dispose_list()                |         |
 |        list_del()                  |         |
 |        clear_inode()               |         |
 |          inode->i_state = I_CLEAR  |         |
 |            |                       |         V
 |            |                       |      if (inode->i_state & (I_FREEING|I_WILL_FREE))
 |            |                       |              continue;           <==== NOT MATCH
 |            |                       |
 |            |                       | (DANGER from here on! Accessing disposing inode!)
 |            |                       |
 |            |                       |      __iget()
 |            |                       |        list_move() <===== PANIC on poisoned list !!
 V            V                       |
(time)
=====================================================================

Reported-by: Masayoshi MIZUMA 
Reviewed-by: Jan Kara 
Signed-off-by: Wu Fengguang 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[chrisw: backport to 2.6.29]
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

CIFS: Fix memory overwrite when saving nativeFileSystem field during mount

2009-05-02T17:56:37+00:00

upstream commit: b363b3304bcf68c4541683b2eff70b29f0446a5b

CIFS can allocate a few bytes to little for the nativeFileSystem field
during tree connect response processing during mount.  This can result
in a "Redzone overwritten" message to be logged.

Signed-off-by: Sridhar Vinay 
Acked-by: Shirish Pargaonkar 
Signed-off-by: Steve French 
[chrisw: minor backport to CHANGES file]
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

cifs: fix buffer format byte on NT Rename/hardlink

2009-05-02T17:56:35+00:00

upstream commit: fcc7c09d94be7b75c9ea2beb22d0fae191c6b4b9

Discovered at Connnectathon 2009...

The buffer format byte and the pad are transposed in NT_RENAME calls
(which are used to set hardlinks). Most servers seem to ignore this
fact, but NetApp filers throw back an error due to this problem. This
patch fixes it.

Signed-off-by: Jeff Layton 
Signed-off-by: Steve French 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

eCryptfs: Allocate a variable number of pages for file headers

2009-03-23T21:55:32+00:00

commit 8faece5f906725c10e7a1f6caf84452abadbdc7b upstream.

When allocating the memory used to store the eCryptfs header contents, a
single, zeroed page was being allocated with get_zeroed_page().
However, the size of an eCryptfs header is either PAGE_CACHE_SIZE or
ECRYPTFS_MINIMUM_HEADER_EXTENT_SIZE (8192), whichever is larger, and is
stored in the file's private_data->crypt_stat->num_header_bytes_at_front
field.

ecryptfs_write_metadata_to_contents() was using
num_header_bytes_at_front to decide how many bytes should be written to
the lower filesystem for the file header.  Unfortunately, at least 8K
was being written from the page, despite the chance of the single,
zeroed page being smaller than 8K.  This resulted in random areas of
kernel memory being written between the 0x1000 and 0x1FFF bytes offsets
in the eCryptfs file headers if PAGE_SIZE was 4K.

This patch allocates a variable number of pages, calculated with
num_header_bytes_at_front, and passes the number of allocated pages
along to ecryptfs_write_metadata_to_contents().

Thanks to Florian Streibelt for reporting the data leak and working with
me to find the problem.  2.6.28 is the only kernel release with this
vulnerability.  Corresponds to CVE-2009-0787

Signed-off-by: Tyler Hicks 
Acked-by: Dustin Kirkland 
Reviewed-by: Eric Sandeen 
Reviewed-by: Eugene Teo 
Cc: dann frazier 
Cc: Serge E. Hallyn 
Cc: Florian Streibelt 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

NFSD: provide encode routine for OP_OPENATTR

2009-03-23T21:55:25+00:00

commit 84f09f46b4ee9e4e9b6381f8af31817516d2091b upstream.

Although this operation is unsupported by our implementation
we still need to provide an encode routine for it to
merely encode its (error) status back in the compound reply.

Thanks for Bill Baker at sun.com for testing with the Sun
OpenSolaris' client, finding, and reporting this bug at
Connectathon 2009.

This bug was introduced in 2.6.27

Signed-off-by: Benny Halevy 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman