1. 05 2月, 2010 1 次提交
  2. 30 1月, 2010 1 次提交
    • L
      Split 'flush_old_exec' into two functions · 221af7f8
      Linus Torvalds 提交于
      'flush_old_exec()' is the point of no return when doing an execve(), and
      it is pretty badly misnamed.  It doesn't just flush the old executable
      environment, it also starts up the new one.
      
      Which is very inconvenient for things like setting up the new
      personality, because we want the new personality to affect the starting
      of the new environment, but at the same time we do _not_ want the new
      personality to take effect if flushing the old one fails.
      
      As a result, the x86-64 '32-bit' personality is actually done using this
      insane "I'm going to change the ABI, but I haven't done it yet" bit
      (TIF_ABI_PENDING), with SET_PERSONALITY() not actually setting the
      personality, but just the "pending" bit, so that "flush_thread()" can do
      the actual personality magic.
      
      This patch in no way changes any of that insanity, but it does split the
      'flush_old_exec()' function up into a preparatory part that can fail
      (still called flush_old_exec()), and a new part that will actually set
      up the new exec environment (setup_new_exec()).  All callers are changed
      to trivially comply with the new world order.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      Cc: stable@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      221af7f8
  3. 29 1月, 2010 8 次提交
  4. 27 1月, 2010 8 次提交
  5. 25 1月, 2010 1 次提交
  6. 21 1月, 2010 1 次提交
    • A
      compat_ioctl: Supress "unknown cmd" message on serial /dev/console · 3f001711
      Atsushi Nemoto 提交于
      After the commit fb07a5f8 ("compat_ioctl: remove all VT ioctl
      handling"), I got this error message on 64-bit mips kernel with 32-bit
      busybox userland:
      
      ioctl32(init:1): Unknown cmd fd(0) cmd(00005600){t:'V';sz:0} arg(7fd76480) on /dev/console
      
      The cmd 5600 is VT_OPENQRY.  The busybox's init issues this ioctl to
      know vt-console or serial-console.  If the console was serial console,
      VT ioctls are not handled by the serial driver.
      
      And by quick search, I found some programs using VT_GETMODE to check
      vt-console is available or not.
      Signed-off-by: NAtsushi Nemoto <anemo@mba.ocn.ne.jp>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      3f001711
  7. 20 1月, 2010 10 次提交
  8. 19 1月, 2010 1 次提交
  9. 18 1月, 2010 7 次提交
    • J
      Btrfs: fix possible panic on unmount · 11dfe35a
      Josef Bacik 提交于
      We can race with the unmount of an fs and the stopping of a kthread where we
      will free the block group before we're done using it.  The reason for this is
      because we do not hold a reference on the block group while its caching, since
      the allocator drops its reference once it exits or moves on to the next block
      group.  This patch fixes the problem by taking a reference to the block group
      before we start caching and dropping it when we're done to make sure all
      accesses to the block group are safe.  Thanks,
      Signed-off-by: NJosef Bacik <josef@redhat.com>
      Signed-off-by: NChris Mason <chris.mason@oracle.com>
      11dfe35a
    • C
      Btrfs: deal with NULL acl sent to btrfs_set_acl · a9cc71a6
      Chris Mason 提交于
      It is legal for btrfs_set_acl to be sent a NULL acl.  This
      makes sure we don't dereference it.  A similar patch was sent by
      Johannes Hirte <johannes.hirte@fem.tu-ilmenau.de>
      Signed-off-by: NChris Mason <chris.mason@oracle.com>
      a9cc71a6
    • J
      Btrfs: fix regression in orphan cleanup · 6c090a11
      Josef Bacik 提交于
      Currently orphan cleanup only ever gets triggered if we cross subvolumes during
      a lookup, which means that if we just mount a plain jane fs that has orphans in
      it, they will never get cleaned up.  This results in panic's like these
      
      http://www.kerneloops.org/oops.php?number=1109085
      
      where adding an orphan entry results in -EEXIST being returned and we panic.  In
      order to fix this, we check to see on lookup if our root has had the orphan
      cleanup done, and if not go ahead and do it.  This is easily reproduceable by
      running this testcase
      
      #include <sys/types.h>
      #include <sys/stat.h>
      #include <fcntl.h>
      #include <string.h>
      #include <unistd.h>
      #include <stdio.h>
      
      int main(int argc, char **argv)
      {
      	char data[4096];
      	char newdata[4096];
      	int fd1, fd2;
      
      	memset(data, 'a', 4096);
      	memset(newdata, 'b', 4096);
      
      	while (1) {
      		int i;
      
      		fd1 = creat("file1", 0666);
      		if (fd1 < 0)
      			break;
      
      		for (i = 0; i < 512; i++)
      			write(fd1, data, 4096);
      
      		fsync(fd1);
      		close(fd1);
      
      		fd2 = creat("file2", 0666);
      		if (fd2 < 0)
      			break;
      
      		ftruncate(fd2, 4096 * 512);
      
      		for (i = 0; i < 512; i++)
      			write(fd2, newdata, 4096);
      		close(fd2);
      
      		i = rename("file2", "file1");
      		unlink("file1");
      	}
      
      	return 0;
      }
      
      and then pulling the power on the box, and then trying to run that test again
      when the box comes back up.  I've tested this locally and it fixes the problem.
      Thanks to Tomas Carnecky for helping me track this down initially.
      Signed-off-by: NJosef Bacik <josef@redhat.com>
      Signed-off-by: NChris Mason <chris.mason@oracle.com>
      6c090a11
    • Y
      Btrfs: Fix race in btrfs_mark_extent_written · 6c7d54ac
      Yan, Zheng 提交于
      Fix bug reported by Johannes Hirte. The reason of that bug
      is btrfs_del_items is called after btrfs_duplicate_item and
      btrfs_del_items triggers tree balance. The fix is check that
      case and call btrfs_search_slot when needed.
      Signed-off-by: NYan Zheng <zheng.yan@oracle.com>
      Signed-off-by: NChris Mason <chris.mason@oracle.com>
      6c7d54ac
    • J
      Btrfs, fix memory leaks in error paths · 2423fdfb
      Jiri Slaby 提交于
      Stanse found 2 memory leaks in relocate_block_group and
      __btrfs_map_block. cluster and multi are not freed/assigned on all
      paths. Fix that.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Cc: linux-btrfs@vger.kernel.org
      Signed-off-by: NChris Mason <chris.mason@oracle.com>
      2423fdfb
    • Y
      Btrfs: align offsets for btrfs_ordered_update_i_size · a038fab0
      Yan, Zheng 提交于
      Some callers of btrfs_ordered_update_i_size can now pass in
      a NULL for the ordered extent to update against.  This makes
      sure we properly align the offset they pass in when deciding
      how much to bump the on disk i_size.
      Signed-off-by: NChris Mason <chris.mason@oracle.com>
      a038fab0
    • J
      btrfs: fix missing last-entry in readdir(3) · 406266ab
      Jan Engelhardt 提交于
      parent 49313cdac7b34c9f7ecbb1780cfc648b1c082cd7 (v2.6.32-1-g49313cd)
      commit ff48c08e1c05c67e8348ab6f8a24de8034e0e34d
      Author: Jan Engelhardt <jengelh@medozas.de>
      Date:   Wed Dec 9 22:57:36 2009 +0100
      
      Btrfs: fix missing last-entry in readdir(3)
      
      When one does a 32-bit readdir(3), the last entry of a directory is
      missing. This is however not due to passing a large value to filldir,
      but it seems to have to do with glibc doing telldir or something
      quirky. In any case, this patch fixes it in practice.
      Signed-off-by: NJan Engelhardt <jengelh@medozas.de>
      Signed-off-by: NChris Mason <chris.mason@oracle.com>
      406266ab
  10. 17 1月, 2010 2 次提交
    • D
      nommu: fix shared mmap after truncate shrinkage problems · 7e660872
      David Howells 提交于
      Fix a problem in NOMMU mmap with ramfs whereby a shared mmap can happen
      over the end of a truncation.  The problem is that
      ramfs_nommu_check_mappings() checks that the reduced file size against the
      VMA tree, but not the vm_region tree.
      
      The following sequence of events can cause the problem:
      
      	fd = open("/tmp/x", O_RDWR|O_TRUNC|O_CREAT, 0600);
      	ftruncate(fd, 32 * 1024);
      	a = mmap(NULL, 32 * 1024, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
      	b = mmap(NULL, 16 * 1024, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
      	munmap(a, 32 * 1024);
      	ftruncate(fd, 16 * 1024);
      	c = mmap(NULL, 32 * 1024, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
      
      Mapping 'a' creates a vm_region covering 32KB of the file.  Mapping 'b'
      sees that the vm_region from 'a' is covering the region it wants and so
      shares it, pinning it in memory.
      
      Mapping 'a' then goes away and the file is truncated to the end of VMA
      'b'.  However, the region allocated by 'a' is still in effect, and has
      _not_ been reduced.
      
      Mapping 'c' is then created, and because there's a vm_region covering the
      desired region, get_unmapped_area() is _not_ called to repeat the check,
      and the mapping is granted, even though the pages from the latter half of
      the mapping have been discarded.
      
      However:
      
      	d = mmap(NULL, 16 * 1024, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
      
      Mapping 'd' should work, and should end up sharing the region allocated by
      'a'.
      
      To deal with this, we shrink the vm_region struct during the truncation,
      lest do_mmap_pgoff() take it as licence to share the full region
      automatically without calling the get_unmapped_area() file op again.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Acked-by: NAl Viro <viro@zeniv.linux.org.uk>
      Cc: Greg Ungerer <gerg@snapgear.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7e660872
    • D
      nommu: fix race between ramfs truncation and shared mmap · 81759b5b
      David Howells 提交于
      Fix the race between the truncation of a ramfs file and an attempt to make
      a shared mmap of region of that file.
      
      The problem is that do_mmap_pgoff() calls f_op->get_unmapped_area() to
      verify that the file region is made of contiguous pages and to find its
      base address - but there isn't any locking to guarantee this region until
      vma_prio_tree_insert() is called by add_vma_to_mm().
      
      Note that moving the functionality into f_op->mmap() doesn't help as that
      is also called before vma_prio_tree_insert().
      
      Instead make ramfs_nommu_check_mappings() grab nommu_region_sem whilst it
      does its checks.  This means that this function will wait whilst mmaps
      take place.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Acked-by: NAl Viro <viro@zeniv.linux.org.uk>
      Cc: Greg Ungerer <gerg@snapgear.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      81759b5b