1. 28 8月, 2008 3 次提交
    • J
      cifs: fix O_APPEND on directio mounts · 838726c4
      Jeff Layton 提交于
      The direct I/O write codepath for CIFS is done through
      cifs_user_write(). That function does not currently call
      generic_write_checks() so the file position isn't being properly set
      when the file is opened with O_APPEND.  It's also not doing the other
      "normal" checks that should be done for a write call.
      
      The problem is currently that when you open a file with O_APPEND on a
      mount with the directio mount option, the file position is set to the
      beginning of the file. This makes any subsequent writes clobber the data
      in the file starting at the beginning.
      
      This seems to fix the problem in cursory testing. It is, however
      important to note that NFS disallows the combination of
      (O_DIRECT|O_APPEND). If my understanding is correct, the concern is
      races with multiple clients appending to a file clobbering each others'
      data. Since the write model for CIFS and NFS is pretty similar in this
      regard, CIFS is probably subject to the same sort of races. What's
      unclear to me is why this is a particular problem with O_DIRECT and not
      with buffered writes...
      
      Regardless, disallowing O_APPEND on an entire mount is probably not
      reasonable, so we'll probably just have to deal with it and reevaluate
      this flag combination when we get proper support for O_DIRECT. In the
      meantime this patch at least fixes the existing problem.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Cc: Stable Tree <stable@kernel.org>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      838726c4
    • S
      [CIFS] Fix plaintext authentication · bcc55c66
      Steve French 提交于
      The last eight bytes of the password field were not cleared when doing lanman plaintext password authentication. This patch fixes that.
      
      I tested it with Samba by setting password
      encryption to no in the server's smb.conf.  Other servers also can be
      configured to force plaintext authentication.    Note that plaintexti
      authentication requires setting /proc/fs/cifs/SecurityFlags to 0x30030
      on the client (enabling both LANMAN and also plaintext password support).
      Also note that LANMAN support (and thus plaintext password support) requires
      CONFIG_CIFS_WEAK_PW_HASH to be enabled in menuconfig.
      
      CC: Jeff Layton <jlayton@redhat.com>
      CC: Stable Kernel <stable@vger.kernel.org>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      bcc55c66
    • J
      [CIFS] Add destroy routine for dns_resolver · 87ed1d65
      Jeff Layton 提交于
      Otherwise, we're leaking the payload memory.
      
      CC: Stable Kernel <stable@vger.kernel.org>
      Acked-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      87ed1d65
  2. 27 8月, 2008 5 次提交
  3. 26 8月, 2008 1 次提交
  4. 25 8月, 2008 8 次提交
  5. 24 8月, 2008 1 次提交
  6. 23 8月, 2008 6 次提交
  7. 21 8月, 2008 4 次提交
    • A
      cramfs: fix named-pipe handling · 82d63fc9
      Al Viro 提交于
      After commit a97c9bf3 (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: NAtsushi Nemoto <anemo@mba.ocn.ne.jp>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: <stable@kernel.org>		[2.6.14 and later]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      82d63fc9
    • K
      fix setpriority(PRIO_PGRP) thread iterator breakage · 2d70b68d
      Ken Chen 提交于
      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: NKen Chen <kenchen@google.com>
      Cc: Oleg Nesterov <oleg@tv-sign.ru>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jens Axboe <jens.axboe@oracle.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2d70b68d
    • P
      binfmt_misc: fix false -ENOEXEC when coupled with other binary handlers · ff9bc512
      Pavel Emelyanov 提交于
      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: NPavel Emelyanov <xemul@openvz.org>
      Reported-by: NKirill A. Shutemov <kirill@shutemov.name>
      Tested-by: NKirill A. Shutemov <kirill@shutemov.name>
      Cc: <stable@kernel.org>		[2.6.26.x]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ff9bc512
    • C
      /proc/self/maps doesn't display the real file offset · 1804dc6e
      Clement Calmels 提交于
      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 <sys/types.h>
      #include <sys/stat.h>
      #include <sys/mman.h>
      #include <stdlib.h>
      #include <stdio.h>
      #include <fcntl.h>
      #include <unistd.h>
      #include <string.h>
      
      #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: NClement Calmels <cboulte@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1804dc6e
  8. 20 8月, 2008 4 次提交
    • L
      vfat: fix 'sync' mount deadlock due to BKL->lock_super conversion · 5f22ca9b
      Linus Torvalds 提交于
      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-ga7f5aaf3 #16
        ---------------------------------------------
        mv/4020 is trying to acquire lock:
         (&type->s_lock_key#9){--..}, at: [<c01a90fe>] lock_super+0x1e/0x20
      
        but task is already holding lock:
         (&type->s_lock_key#9){--..}, at: [<c01a90fe>] 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: [<c01b2336>] do_unlinkat+0x66/0x140
         #1:  (&sb->s_type->i_mutex_key#9){--..}, at: [<c01b0954>] vfs_unlink+0x84/0x110
         #2:  (&type->s_lock_key#9){--..}, at: [<c01a90fe>] lock_super+0x1e/0x20
      
        stack backtrace:
        Pid: 4020, comm: mv Not tainted 2.6.27-rc3-bisect-00448-ga7f5aaf3 #16
         [<c014e694>] validate_chain+0x984/0xea0
         [<c0108d70>] ? native_sched_clock+0x0/0xf0
         [<c014ee9c>] __lock_acquire+0x2ec/0x9b0
         [<c014f5cf>] lock_acquire+0x6f/0x90
         [<c01a90fe>] ? lock_super+0x1e/0x20
         [<c044e5fd>] mutex_lock_nested+0xad/0x300
         [<c01a90fe>] ? lock_super+0x1e/0x20
         [<c01a90fe>] ? lock_super+0x1e/0x20
         [<c01a90fe>] lock_super+0x1e/0x20
         [<f8b3a700>] fat_write_inode+0x60/0x2b0 [fat]
         [<c0450878>] ? _spin_unlock_irqrestore+0x48/0x80
         [<f8b3a953>] ? fat_sync_inode+0x3/0x20 [fat]
         [<f8b3a962>] fat_sync_inode+0x12/0x20 [fat]
         [<f8b37c7e>] fat_remove_entries+0xbe/0x120 [fat]
         [<f8b422ef>] vfat_unlink+0x5f/0x90 [vfat]
         [<f8b42290>] ? vfat_unlink+0x0/0x90 [vfat]
         [<c01b0968>] vfs_unlink+0x98/0x110
         [<c01b2400>] do_unlinkat+0x130/0x140
         [<c016a8f5>] ? audit_syscall_entry+0x105/0x150
         [<c01b253b>] sys_unlinkat+0x3b/0x40
         [<c01040d3>] 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 <bart@jukie.net>"
      Reported-and-tested-by: NBart Trojanowski <bart@jukie.net>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5f22ca9b
    • S
    • S
      [CIFS] distinguish between Kerberos and MSKerberos in upcall · c16fefa5
      Steve French 提交于
      Properly handle MSKRB5 by passing sec=mskrb5 to the upcall so that the
      spengo blob can be generated appropriately. Also, make
      decode_negTokenInit prefer whichever mechanism is first in the list.
      
      Needed for some NetApp servers, and possibly some older
      versions of Windows which treat the two KRB5 mechanisms differently.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      c16fefa5
    • J
      cifs: add local server pointer to cifs_setup_session · cb7691b6
      Jeff Layton 提交于
      cifs_setup_session references pSesInfo->server several times. That
      pointer shouldn't change during the life of the function so grab it
      once and store it in a local var. This makes the code look a little
      cleaner too.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      cb7691b6
  9. 19 8月, 2008 1 次提交
  10. 15 8月, 2008 3 次提交
    • B
      omfs: fix oops when file metadata is corrupted · 9419fc1c
      Bob Copeland 提交于
      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: NEric Sesterhenn <snakebyte@gmx.de>
      Signed-off-by: NBob Copeland <me@bobcopeland.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9419fc1c
    • B
      omfs: fix potential oops when directory size is corrupted · c963343a
      Bob Copeland 提交于
      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: [<c032298e>] 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:[<c032298e>] 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:
       [<c018a820>] ? filldir64+0x0/0xcd
       [<c018a9f2>] ? vfs_readdir+0x56/0x82
       [<c018a820>] ? filldir64+0x0/0xcd
       [<c018aa7c>] ? sys_getdents64+0x5e/0xa0
       [<c01038bd>] ? 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: NEric Sesterhenn <snakebyte@gmx.de>
      Signed-off-by: NBob Copeland <me@bobcopeland.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c963343a
    • C
      fs/inode.c: properly init address_space->writeback_index · 7d455e00
      Chris Mason 提交于
      write_cache_pages() uses i_mapping->writeback_index to pick up where it
      left off the last time a given inode was found by pdflush or
      balance_dirty_pages (or anyone else who sets wbc->range_cyclic)
      
      alloc_inode() should set it to a sane value so that writeback doesn't
      start in the middle of a file.  It is somewhat difficult to notice the bug
      since write_cache_pages will loop around to the start of the file and the
      elevator helps hide the resulting seeks.
      
      For whatever reason, Btrfs hits this often.  Unpatched, untarring 30
      copies of the linux kernel in series runs at 47MB/s on a single sata
      drive.  With this fix, it jumps to 62MB/s.
      Signed-off-by: NChris Mason <chris.mason@oracle.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7d455e00
  11. 14 8月, 2008 4 次提交
    • A
      UBIFS: xattr bugfixes · c78c7e35
      Artem Bityutskiy 提交于
      Xattr code has not been tested for a while and there were
      serveral bugs. One of them is using wrong inode in
      'ubifs_jnl_change_xattr()'. The other is a deadlock in
      'ubifs_setxattr()': the i_mutex is locked in
      'cap_inode_need_killpriv()' path, so deadlock happens when
      'ubifs_setxattr()' tries to lock it again.
      
      Thanks to Zoltan Sogor for finding these bugs.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      c78c7e35
    • S
      [CIFS] mount of IPC$ breaks with iget patch · ad661334
      Steve French 提交于
      In looking at network named pipe support on cifs, I noticed that
      Dave Howell's iget patch:
      
          iget: stop CIFS from using iget() and read_inode()
      
      broke mounts to IPC$ (the interprocess communication share), and don't
      handle the error case (when getting info on the root inode fails).
      
      Thanks to Gunter who noted a typo in a debug line in the original
      version of this patch.
      
      CC: David Howells <dhowells@redhat.com>
      CC: Gunter Kukkukk <linux@kukkukk.com>
      CC: Stable Kernel <stable@kernel.org>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      ad661334
    • D
      CRED: Introduce credential access wrappers · 9e2b2dc4
      David Howells 提交于
      The patches that are intended to introduce copy-on-write credentials for 2.6.28
      require abstraction of access to some fields of the task structure,
      particularly for the case of one task accessing another's credentials where RCU
      will have to be observed.
      
      Introduced here are trivial no-op versions of the desired accessors for current
      and other tasks so that other subsystems can start to be converted over more
      easily.
      
      Wrappers are introduced into a new header (linux/cred.h) for UID/GID,
      EUID/EGID, SUID/SGID, FSUID/FSGID, cap_effective and current's subscribed
      user_struct.  These wrappers are macros because the ordering between header
      files mitigates against making them inline functions.
      
      linux/cred.h is #included from linux/sched.h.
      
      Further, XFS is modified such that it no longer defines and uses parameterised
      versions of current_fs[ug]id(), thus getting rid of the namespace collision
      otherwise incurred.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      9e2b2dc4
    • D
      dlm: rename structs · 51409340
      David Teigland 提交于
      Add a dlm_ prefix to the struct names in config.c.  This resolves a
      conflict with struct node in particular, when include/linux/node.h
      happens to be included.
      Reported-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NDavid Teigland <teigland@redhat.com>
      51409340