1. 22 12月, 2008 4 次提交
  2. 20 12月, 2008 3 次提交
  3. 18 12月, 2008 1 次提交
  4. 17 12月, 2008 2 次提交
  5. 12 12月, 2008 1 次提交
  6. 11 12月, 2008 10 次提交
    • C
      [XFS] use inode_change_ok for setattr permission checking · c4cd747e
      Christoph Hellwig 提交于
      Instead of implementing our own checks use inode_change_ok to check for
      necessary permission in setattr.  There is a slight change in behaviour
      as inode_change_ok doesn't allow i_mode updates to add the suid or sgid
      without superuser privilegues while the old XFS code just stripped away
      those bits from the file mode.
      
      (First sent on Semptember 29th)
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NLachlan McIlroy <lachlan@sgi.com>
      c4cd747e
    • C
      [XFS] add a FMODE flag to make XFS invisible I/O less hacky · 4d4be482
      Christoph Hellwig 提交于
      XFS has a mode called invisble I/O that doesn't update any of the
      timestamps.  It's used for HSM-style applications and exposed through
      the nasty open by handle ioctl.
      
      Instead of doing directly assignment of file operations that set an
      internal flag for it add a new FMODE_NOCMTIME flag that we can check
      in the normal file operations.
      
      (addition of the generic VFS flag has been ACKed by Al as an interims
       solution)
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NLachlan McIlroy <lachlan@sgi.com>
      4d4be482
    • C
      [XFS] resync headers with libxfs · 6d73cf13
      Christoph Hellwig 提交于
       - xfs_sb.h add the XFS_SB_VERSION2_PARENTBIT features2 that has been
         around in userspace for some time
       - xfs_inode.h: move a few things out of __KERNEL__ that are needed by
         userspace
       - xfs_mount.h: only include xfs_sync.h under __KERNEL__
       - xfs_inode.c: minor whitespace fixup.  I accidentaly changes this when
         importing this file for use by userspace.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NLachlan McIlroy <lachlan@sgi.com>
      6d73cf13
    • C
      [XFS] simplify projid check in xfs_rename · 2175dd95
      Christoph Hellwig 提交于
      Check for the project ID after attaching all inodes to the transaction.
      That way the unlock in the error case is done by the transaction subsystem,
      which guaratees that is uses the right flags (which was wrong from day one
      of this check), and avoids having special code unlocking an array of inodes
      with potential duplicates.  Attaching the inode first is the method used
      by xfs_rename and the other namespace methods all other error that require
      multiple locked inodes.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NDave Chinner <david@fromorbit.com>
      Signed-off-by: NLachlan McIlroy <lachlan@sgi.com>
      2175dd95
    • C
      [XFS] replace b_fspriv with b_mount · 15ac08a8
      Christoph Hellwig 提交于
      Replace the b_fspriv pointer and it's ugly accessors with a properly types
      xfs_mount pointer.  Also switch log reocvery over to it instead of using
      b_fspriv for the mount pointer.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NDave Chinner <david@fromorbit.com>
      Signed-off-by: NLachlan McIlroy <lachlan@sgi.com>
      15ac08a8
    • H
      KSYM_SYMBOL_LEN fixes · 9c246247
      Hugh Dickins 提交于
      Miles Lane tailing /sys files hit a BUG which Pekka Enberg has tracked
      to my 966c8c12 sprint_symbol(): use
      less stack exposing a bug in slub's list_locations() -
      kallsyms_lookup() writes a 0 to namebuf[KSYM_NAME_LEN-1], but that was
      beyond the end of page provided.
      
      The 100 slop which list_locations() allows at end of page looks roughly
      enough for all the other stuff it might print after the symbol before
      it checks again: break out KSYM_SYMBOL_LEN earlier than before.
      
      Latencytop and ftrace and are using KSYM_NAME_LEN buffers where they
      need KSYM_SYMBOL_LEN buffers, and vmallocinfo a 2*KSYM_NAME_LEN buffer
      where it wants a KSYM_SYMBOL_LEN buffer: fix those before anyone copies
      them.
      
      [akpm@linux-foundation.org: ftrace.h needs module.h]
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Cc Miles Lane <miles.lane@gmail.com>
      Acked-by: NPekka Enberg <penberg@cs.helsinki.fi>
      Acked-by: NSteven Rostedt <srostedt@redhat.com>
      Acked-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9c246247
    • D
      inotify: fix IN_ONESHOT unmount event watcher · 6ee5a399
      Dmitri Monakhov 提交于
      On umount two event will be dispatched to watcher:
      
      1: inotify_dev_queue_event(.., IN_UNMOUNT,..)
      2: remove_watch(watch, dev)
          ->inotify_dev_queue_event(.., IN_IGNORED, ..)
      
      But if watcher has IN_ONESHOT bit set then the watcher will be released
      inside first event.  Which result in accessing invalid object later.  IMHO
      it is not pure regression.  This bug wasn't triggered while initial
      inotify interface testing phase because of another bug in IN_ONESHOT
      handling logic :)
      
        commit ac74c00e
        Author: Ulisses Furquim <ulissesf@gmail.com>
        Date:   Fri Feb 8 04:18:16 2008 -0800
          inotify: fix check for one-shot watches before destroying them
          As the IN_ONESHOT bit is never set when an event is sent we must check it
          in the watch's mask and not in the event's mask.
      
      TESTCASE:
      mkdir mnt
      mount -ttmpfs none mnt
      mkdir mnt/d
      ./inotify mnt/d&
      umount mnt ## << lockup or crash here
      
      TESTSOURCE:
      /* gcc -oinotify inotify.c */
      #include <stdio.h>
      #include <stdlib.h>
      #include <sys/inotify.h>
      
      int main(int argc, char **argv)
      {
              char buf[1024];
              struct inotify_event *ie;
              char *p;
              int i;
              ssize_t l;
      
              p = argv[1];
              i = inotify_init();
              inotify_add_watch(i, p, ~0);
      
              l = read(i, buf, sizeof(buf));
              printf("read %d bytes\n", l);
              ie = (struct inotify_event *) buf;
              printf("event mask: %d\n", ie->mask);
      	return 0;
      }
      Signed-off-by: NDmitri Monakhov <dmonakhov@openvz.org>
      Cc: John McCutchan <ttb@tentacle.dhs.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Robert Love <rlove@google.com>
      Cc: Ulisses Furquim <ulissesf@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6ee5a399
    • M
      pagemap: fix 32-bit pagemap regression · 49c50342
      Matt Mackall 提交于
      The large pages fix from bcf8039e broke 32-bit pagemap by pulling the
      pagemap entry code out into a function with the wrong return type.
      Pagemap entries are 64 bits on all systems and unsigned long is only 32
      bits on 32-bit systems.
      Signed-off-by: NMatt Mackall <mpm@selenic.com>
      Reported-by: NDoug Graham <dgraham@nortel.com>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Dave Hansen <dave@linux.vnet.ibm.com>
      Cc: <stable@kernel.org>		[2.6.26.x, 2.6.27.x]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      49c50342
    • A
      revert "percpu_counter: new function percpu_counter_sum_and_set" · 02d21168
      Andrew Morton 提交于
      Revert
      
          commit e8ced39d
          Author: Mingming Cao <cmm@us.ibm.com>
          Date:   Fri Jul 11 19:27:31 2008 -0400
      
              percpu_counter: new function percpu_counter_sum_and_set
      
      As described in
      
      	revert "percpu counter: clean up percpu_counter_sum_and_set()"
      
      the new percpu_counter_sum_and_set() is racy against updates to the
      cpu-local accumulators on other CPUs.  Revert that change.
      
      This means that ext4 will be slow again.  But correct.
      Reported-by: NEric Dumazet <dada1@cosmosbay.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Mingming Cao <cmm@us.ibm.com>
      Cc: <linux-ext4@vger.kernel.org>
      Cc: <stable@kernel.org>		[2.6.27.x]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      02d21168
    • A
      revert "percpu counter: clean up percpu_counter_sum_and_set()" · 71c5576f
      Andrew Morton 提交于
      Revert
      
          commit 1f7c14c6
          Author: Mingming Cao <cmm@us.ibm.com>
          Date:   Thu Oct 9 12:50:59 2008 -0400
      
              percpu counter: clean up percpu_counter_sum_and_set()
      
      Before this patch we had the following:
      
      percpu_counter_sum(): return the percpu_counter's value
      
      percpu_counter_sum_and_set(): return the percpu_counter's value, copying
      that value into the central value and zeroing the per-cpu counters before
      returning.
      
      After this patch, percpu_counter_sum_and_set() has gone, and
      percpu_counter_sum() gets the old percpu_counter_sum_and_set()
      functionality.
      
      Problem is, as Eric points out, the old percpu_counter_sum_and_set()
      functionality was racy and wrong.  It zeroes out counters on "other" cpus,
      without holding any locks which will prevent races agaist updates from
      those other CPUS.
      
      This patch reverts 1f7c14c6.  This means
      that percpu_counter_sum_and_set() still has the race, but
      percpu_counter_sum() does not.
      
      Note that this is not a simple revert - ext4 has since started using
      percpu_counter_sum() for its dirty_blocks counter as well.
      
      Note that this revert patch changes percpu_counter_sum() semantics.
      
      Before the patch, a call to percpu_counter_sum() will bring the counter's
      central counter mostly up-to-date, so a following percpu_counter_read()
      will return a close value.
      
      After this patch, a call to percpu_counter_sum() will leave the counter's
      central accumulator unaltered, so a subsequent call to
      percpu_counter_read() can now return a significantly inaccurate result.
      
      If there is any code in the tree which was introduced after
      e8ced39d was merged, and which depends
      upon the new percpu_counter_sum() semantics, that code will break.
      Reported-by: NEric Dumazet <dada1@cosmosbay.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Mingming Cao <cmm@us.ibm.com>
      Cc: <linux-ext4@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      71c5576f
  7. 10 12月, 2008 2 次提交
    • R
      tracehook: exec double-reporting fix · 85f33466
      Roland McGrath 提交于
      The patch 6341c393 "tracehook: exec" introduced a small regression in
      2.6.27 regarding binfmt_misc exec event reporting.  Since the reporting
      is now done in the common search_binary_handler() function, an exec
      of a misc binary will result in two (or possibly multiple) exec events
      being reported, instead of just a single one, because the misc handler
      contains a recursive call to search_binary_handler.
      
      To add to the confusion, if PTRACE_O_TRACEEXEC is not active, the multiple
      SIGTRAP signals will in fact cause only a single ptrace intercept, as the
      signals are not queued.  However, if PTRACE_O_TRACEEXEC is on, the debugger
      will actually see multiple ptrace intercepts (PTRACE_EVENT_EXEC).
      
      The test program included below demonstrates the problem.
      
      This change fixes the bug by calling tracehook_report_exec() only in the
      outermost search_binary_handler() call (bprm->recursion_depth == 0).
      
      The additional change to restore bprm->recursion_depth after each binfmt
      load_binary call is actually superfluous for this bug, since we test the
      value saved on entry to search_binary_handler().  But it keeps the use of
      of the depth count to its most obvious expected meaning.  Depending on what
      binfmt handlers do in certain cases, there could have been false-positive
      tests for recursion limits before this change.
      
          /* Test program using PTRACE_O_TRACEEXEC.
             This forks and exec's the first argument with the rest of the arguments,
             while ptrace'ing.  It expects to see one PTRACE_EVENT_EXEC stop and
             then a successful exit, with no other signals or events in between.
      
             Test for kernel doing two PTRACE_EVENT_EXEC stops for a binfmt_misc exec:
      
             $ gcc -g traceexec.c -o traceexec
             $ sudo sh -c 'echo :test:M::foobar::/bin/cat: > /proc/sys/fs/binfmt_misc/register'
             $ echo 'foobar test' > ./foobar
             $ chmod +x ./foobar
             $ ./traceexec ./foobar; echo $?
             ==> good <==
             foobar test
             0
             $
             ==> bad <==
             foobar test
             unexpected status 0x4057f != 0
             3
             $
      
          */
      
          #include <stdio.h>
          #include <sys/types.h>
          #include <sys/wait.h>
          #include <sys/ptrace.h>
          #include <unistd.h>
          #include <signal.h>
          #include <stdlib.h>
      
          static void
          wait_for (pid_t child, int expect)
          {
            int status;
            pid_t p = wait (&status);
            if (p != child)
      	{
      	  perror ("wait");
      	  exit (2);
      	}
            if (status != expect)
      	{
      	  fprintf (stderr, "unexpected status %#x != %#x\n", status, expect);
      	  exit (3);
      	}
          }
      
          int
          main (int argc, char **argv)
          {
            pid_t child = fork ();
      
            if (child < 0)
      	{
      	  perror ("fork");
      	  return 127;
      	}
            else if (child == 0)
      	{
      	  ptrace (PTRACE_TRACEME);
      	  raise (SIGUSR1);
      	  execv (argv[1], &argv[1]);
      	  perror ("execve");
      	  _exit (127);
      	}
      
            wait_for (child, W_STOPCODE (SIGUSR1));
      
            if (ptrace (PTRACE_SETOPTIONS, child,
      		  0L, (void *) (long) PTRACE_O_TRACEEXEC) != 0)
      	{
      	  perror ("PTRACE_SETOPTIONS");
      	  return 4;
      	}
      
            if (ptrace (PTRACE_CONT, child, 0L, 0L) != 0)
      	{
      	  perror ("PTRACE_CONT");
      	  return 5;
      	}
      
            wait_for (child, W_STOPCODE (SIGTRAP | (PTRACE_EVENT_EXEC << 8)));
      
            if (ptrace (PTRACE_CONT, child, 0L, 0L) != 0)
      	{
      	  perror ("PTRACE_CONT");
      	  return 6;
      	}
      
            wait_for (child, W_EXITCODE (0, 0));
      
            return 0;
          }
      Reported-by: NArnd Bergmann <arnd@arndb.de>
      CC: Ulrich Weigand <ulrich.weigand@de.ibm.com>
      Signed-off-by: NRoland McGrath <roland@redhat.com>
      85f33466
    • L
      [XFS] Remove unused tracing code · e055f13a
      Lachlan McIlroy 提交于
      None of this code appears to be used anywhere so remove it.
      Reviewed-by: NChristoph Hellwig <hch@infradead.org>
      Signed-off-by: NLachlan McIlroy <lachlan@sgi.com>
      e055f13a
  8. 09 12月, 2008 1 次提交
    • J
      EXPORTFS: handle NULL returns from fh_to_dentry()/fh_to_parent() · a4f4d6df
      J. Bruce Fields 提交于
      While 44003728 "[PATCH] switch all filesystems over to
      d_obtain_alias" removed some cases where fh_to_dentry() and
      fh_to_parent() could return NULL, there are still a few NULL returns
      left in individual filesystems.  Thus it was a mistake for that commit
      to remove the handling of NULL returns in the callers.
      
      Revert those parts of 44003728 which removed the NULL handling.
      
      (We could, alternatively, modify all implementations to return -ESTALE
      instead of NULL, but that proves to require fixing a number of
      filesystems, and in some cases it's arguably more natural to return
      NULL.)
      
      Thanks to David for original patch and Linus, Christoph, and Hugh for
      review.
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Hugh Dickins <hugh@veritas.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a4f4d6df
  9. 06 12月, 2008 1 次提交
  10. 05 12月, 2008 6 次提交
  11. 04 12月, 2008 9 次提交