linux.git/fs, branch v2.6.27-rc4

cramfs: fix named-pipe handling

2008-08-20T22:40:32+00:00

After commit a97c9bf33f4612e2aed6f000f6b1d268b6814f3c (fix cramfs
making duplicate entries in inode cache) in kernel 2.6.14, named-pipe
on cramfs does not work properly.

It seems the commit make all named-pipe on cramfs share their inode
(and named-pipe buffer).

Make ..._test() refuse to merge inodes with ->i_ino == 1, take inode setup
back to get_cramfs_inode() and make ->drop_inode() evict ones with ->i_ino
== 1 immediately.

Reported-by: Atsushi Nemoto 
Cc: Al Viro 
Cc: 		[2.6.14 and later]
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fix setpriority(PRIO_PGRP) thread iterator breakage

2008-08-20T22:40:32+00:00

When user calls sys_setpriority(PRIO_PGRP ...) on a NPTL style multi-LWP
process, only the task leader of the process is affected, all other
sibling LWP threads didn't receive the setting.  The problem was that the
iterator used in sys_setpriority() only iteartes over one task for each
process, ignoring all other sibling thread.

Introduce a new macro do_each_pid_thread / while_each_pid_thread to walk
each thread of a process.  Convert 4 call sites in {set/get}priority and
ioprio_{set/get}.

Signed-off-by: Ken Chen 
Cc: Oleg Nesterov 
Cc: Roland McGrath 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: Jens Axboe 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

binfmt_misc: fix false -ENOEXEC when coupled with other binary handlers

2008-08-20T22:40:31+00:00

In case the binfmt_misc binary handler is registered *before* the e.g.
script one (when for example being compiled as a module) the following
situation may occur:

1. user launches a script, whose interpreter is a misc binary;
2. the load_misc_binary sets the misc_bang and returns -ENOEVEC,
   since the binary is a script;
3. the load_script_binary loads one and calls for search_binary_hander
   to run the interpreter;
4. the load_misc_binary is called again, but refuses to load the
   binary due to misc_bang bit set.

The fix is to move the misc_bang setting lower - prior to the actual
call to the search_binary_handler.

Caused by the commit 3a2e7f47 (binfmt_misc.c: avoid potential kernel
stack overflow)

Signed-off-by: Pavel Emelyanov 
Reported-by: Kirill A. Shutemov 
Tested-by: Kirill A. Shutemov 
Cc: 		[2.6.26.x]
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

/proc/self/maps doesn't display the real file offset

2008-08-20T22:40:30+00:00

This addresses

	http://bugzilla.kernel.org/show_bug.cgi?id=11318

In function show_map (file: fs/proc/task_mmu.c), if vma->vm_pgoff > 2^20
than (vma->vm_pgoff << PAGE_SIZE) is greater than 2^32 (with PAGE_SIZE
equal to 4096 (i.e.  2^12).  The next seq_printf use an unsigned long for
the conversion of (vma->vm_pgoff << PAGE_SIZE), as a result the offset
value displayed in /proc/self/maps is truncated if the page offset is
greater than 2^20.

A test that shows this issue:

#define _GNU_SOURCE
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define PAGE_SIZE (getpagesize())

#if __i386__
#   define U64_STR "%llx"
#elif __x86_64
#   define U64_STR "%lx"
#else
#   error "Architecture Unsupported"
#endif

int main(int argc, char *argv[])
{
	int fd;
	char *addr;
	off64_t offset = 0x10000000;
	char *filename = "/dev/zero";

	fd = open(filename, O_RDONLY);
	if (fd < 0) {
		perror("open");
		return 1;
	}

	offset *= 0x10;
	printf("offset = " U64_STR "\n", offset);

	addr = (char*)mmap64(NULL, PAGE_SIZE, PROT_READ, MAP_PRIVATE, fd,
			     offset);
	if ((void*)addr == MAP_FAILED) {
		perror("mmap64");
		return 1;
	}

	{
		FILE *fmaps;
		char *line = NULL;
		size_t len = 0;
		ssize_t read;
		size_t filename_len = strlen(filename);

		fmaps = fopen("/proc/self/maps", "r");
		if (!fmaps) {
			perror("fopen");
			return 1;
		}
		while ((read = getline(&line, &len, fmaps)) != -1) {
			if ((read > filename_len + 1)
			    && (strncmp(&line[read - filename_len - 1], filename, filename_len) == 0))
				printf("%s", line);
		}

		if (line)
			free(line);

		fclose(fmaps);
	}

	close(fd);
	return 0;
}

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Clement Calmels 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Merge branch 'sh/for-2.6.27' of git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6

2008-08-20T15:46:11+00:00

* 'sh/for-2.6.27' of git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6:
  sh: Provide a FLAT_PLAT_INIT() definition.
  binfmt_flat: Stub in a FLAT_PLAT_INIT().
  video: export sh_mobile_lcdc panel size
  sh: select memchunk size using kernel cmdline
  sh: export sh7723 VEU as VEU2H
  input: migor_ts compile and detection fix
  sh: remove MSTPCR defines from Migo-R header file
  sh: Update sh7763rdp defconfig
  sh: Add support sh7760fb to sh7763rdp board
  sh: Add support sh_eth to sh7763rdp board
  sh: Disable 64kB hugetlbpage size when using 64kB PAGE_SIZE.
  sh: Don't export __{s,u}divsi3_i4i from SH-2 libgcc.
  fix SH7705_CACHE_32KB compilation
  sh: mach-x3proto: Fix up smc91x platform data.

vfat: fix 'sync' mount deadlock due to BKL->lock_super conversion

2008-08-20T15:31:19+00:00

There was another FAT BKL conversion deadlock reported by Bart
Trojanowski due to the BKL being used as a recursive lock by FAT, which
was missed because it only triggers with 'sync' (or 'dirsync') mounts.

The recursion worked for the BKL, but after the conversion to lock_super
(which uses a mutex), it just deadlocks.

Thanks to Bart for debugging this and testing the fix.  The lock
debugging information from the original report:

  =============================================
  [ INFO: possible recursive locking detected ]
  2.6.27-rc3-bisect-00448-ga7f5aaf #16
  ---------------------------------------------
  mv/4020 is trying to acquire lock:
   (&type->s_lock_key#9){--..}, at: [] lock_super+0x1e/0x20

  but task is already holding lock:
   (&type->s_lock_key#9){--..}, at: [] lock_super+0x1e/0x20

  other info that might help us debug this:
  3 locks held by mv/4020:
   #0:  (&sb->s_type->i_mutex_key#9/1){--..}, at: [] do_unlinkat+0x66/0x140
   #1:  (&sb->s_type->i_mutex_key#9){--..}, at: [] vfs_unlink+0x84/0x110
   #2:  (&type->s_lock_key#9){--..}, at: [] lock_super+0x1e/0x20

  stack backtrace:
  Pid: 4020, comm: mv Not tainted 2.6.27-rc3-bisect-00448-ga7f5aaf #16
   [] validate_chain+0x984/0xea0
   [] ? native_sched_clock+0x0/0xf0
   [] __lock_acquire+0x2ec/0x9b0
   [] lock_acquire+0x6f/0x90
   [] ? lock_super+0x1e/0x20
   [] mutex_lock_nested+0xad/0x300
   [] ? lock_super+0x1e/0x20
   [] ? lock_super+0x1e/0x20
   [] lock_super+0x1e/0x20
   [] fat_write_inode+0x60/0x2b0 [fat]
   [] ? _spin_unlock_irqrestore+0x48/0x80
   [] ? fat_sync_inode+0x3/0x20 [fat]
   [] fat_sync_inode+0x12/0x20 [fat]
   [] fat_remove_entries+0xbe/0x120 [fat]
   [] vfat_unlink+0x5f/0x90 [vfat]
   [] ? vfat_unlink+0x0/0x90 [vfat]
   [] vfs_unlink+0x98/0x110
   [] do_unlinkat+0x130/0x140
   [] ? audit_syscall_entry+0x105/0x150
   [] sys_unlinkat+0x3b/0x40
   [] sysenter_do_call+0x12/0x3f
   =======================

where the deadlock is due to the nesting of lock_super from vfat_unlink
to fat_write_inode:

 - do_unlinkat
   - vfs_unlink
     - vfat_unlink
       * lock_super
       - fat_remove_entries
         - fat_sync_inode
           - fat_write_inode
             * lock_super

and the fix is to simply remove the use of lock_super() in fat_write_inode.

The lock_super() there had been just an automatic conversion of the
kernel lock to the superblock lock, but no locking was actually needed
there, since the code in fat_write_inode already protected all relevant
accesses with a spinlock (sbi->inode_hash_lock to be exact).  The only
code inside the BKL (and thus the superblock lock) was accesses tp local
variables or calls to functions that have long been SMP-safe (i.e.
sb_bread, mark_buffe_dirty and brlese).

Bart reports:
 "Looks good.  I ran 10 parallel processes creating 1M files truncating
  them, writing to them again and then deleting them.  This patch fixes
  the issue I ran into.

  Signed-off-by: Bart Trojanowski "

Reported-and-tested-by: Bart Trojanowski 
Signed-off-by: Linus Torvalds

Merge git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6

2008-08-15T18:02:35+00:00

* git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6:
  [CIFS] mount of IPC$ breaks with iget patch
  [CIFS] remove trailing whitespace
  [CIFS] if get root inode fails during mount, cleanup tree connection

Merge branch 'linux-next' of git://git.infradead.org/~dedekind/ubifs-2.6

2008-08-15T17:33:07+00:00

* 'linux-next' of git://git.infradead.org/~dedekind/ubifs-2.6: (29 commits)
  UBIFS: xattr bugfixes
  UBIFS: remove unneeded check
  UBIFS: few commentary fixes
  UBIFS: fix budgeting request alignment in xattr code
  UBIFS: improve arguments checking in debugging messages
  UBIFS: always set i_generation to 0
  UBIFS: correct spelling of "thrice".
  UBIFS: support splice_write
  UBIFS: minor tweaks in commit
  UBIFS: reserve more space for index
  UBIFS: print pid in dump function
  UBIFS: align inode data to eight
  UBIFS: improve budgeting checks
  UBIFS: correct orphan deletion order
  UBIFS: fix typos in comments
  UBIFS: do not union creat_sqnum and del_cmtno
  UBIFS: optimize deletions
  UBIFS: increment commit number earlier
  UBIFS: remove another unneeded function parameter
  UBIFS: remove unneeded function parameter
  ...

omfs: fix oops when file metadata is corrupted

2008-08-15T15:35:44+00:00

A fuzzed fileystem image failed with OMFS when the extent count was
used in a loop without being checked against the max number of extents.
It also provoked a signed division for an array index that was checked
as if unsigned, leading to index by -1.

omfsck will be updated to fix these cases, in the meantime bail out
gracefully.

Reported-by: Eric Sesterhenn 
Signed-off-by: Bob Copeland 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

omfs: fix potential oops when directory size is corrupted

2008-08-15T15:35:44+00:00

Testing with a modified fsfuzzer reveals a couple of locations in omfs
where filesystem variables are ultimately used as loop counters with
insufficient sanity checking.  In this case, dir->i_size is used to
compute the number of buckets in the directory hash.  If too large,
readdir will overrun a buffer.

Since it's an invariant that dir->i_size is equal to the sysblock
size, and we already sanity check that, just use that value instead.
This fixes the following oops:

BUG: unable to handle kernel paging request at c978e004
IP: [] omfs_readdir+0x18e/0x32f
Oops: 0000 [#1] PREEMPT DEBUG_PAGEALLOC
Modules linked in:

Pid: 4796, comm: ls Not tainted (2.6.27-rc2 #12)
EIP: 0060:[] EFLAGS: 00010287 CPU: 0
EIP is at omfs_readdir+0x18e/0x32f
EAX: c978d000 EBX: 00000000 ECX: cbfcfaf8 EDX: cb2cf100
ESI: 00001000 EDI: 00000800 EBP: cb2d3f68 ESP: cb2d3f0c
 DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Process ls (pid: 4796, ti=cb2d3000 task=cb175f40 task.ti=cb2d3000)
Stack: 00000002 00000000 00000000 c018a820 cb2d3f94 cb2cf100 cbfb0000 ffffff10
       cbfb3b80 cbfcfaf8 000001c9 00000a09 00000000 00000000 00000000 cbfcfbc8
       c9697000 cbfb3b80 22222222 00001000 c08e6cd0 cb2cf100 cbfb3b80 cb2d3f88
Call Trace:
 [] ? filldir64+0x0/0xcd
 [] ? vfs_readdir+0x56/0x82
 [] ? filldir64+0x0/0xcd
 [] ? sys_getdents64+0x5e/0xa0
 [] ? sysenter_do_call+0x12/0x31
 =======================
Code: 00 89 f0 89 f3 0f ac f8 14 81 e3 ff ff 0f 00 48 8d
14 c5 b8 01 00 00 89 45 cc 89 55 f0 e9 8c 01 00 00 8b 4d c8 8b 75 f0 8b
41 18 <8b> 54 30 04 8b 04 30 31 f6 89 5d dc 89 d1 8b 55 b8 0f c8 0f c9

Reported-by: Eric Sesterhenn 
Signed-off-by: Bob Copeland 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds