1. 09 11月, 2010 2 次提交
  2. 08 11月, 2010 1 次提交
  3. 05 11月, 2010 1 次提交
  4. 04 11月, 2010 3 次提交
  5. 02 11月, 2010 2 次提交
    • A
      preempt: fix kernel build with !CONFIG_BKL · 7fe19da4
      Arnd Bergmann 提交于
      The preempt count logic tries to take the BKL into account, which breaks
      when CONFIG_BKL is not set.
      
      Use the same preempt_count offset that we use without CONFIG_PREEMPT
      when CONFIG_BKL is disabled.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Reported-and-tested-by: NKirill A. Shutemov <kirill@shutemov.name>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7fe19da4
    • C
      asm-generic/stat.h: support 64-bit file time_t for stat() · 2c7387ef
      Chris Metcalf 提交于
      The existing asm-generic/stat.h specifies st_mtime, etc., as a 32-value,
      and works well for 32-bit architectures (currently microblaze, score,
      and 32-bit tile).  However, for 64-bit architectures it isn't sufficient
      to return 32 bits of time_t; this isn't good insurance against the 2037
      rollover.  (It also makes glibc support less convenient, since we can't
      use glibc's handy STAT_IS_KERNEL_STAT mode.)
      
      This change extends the two "timespec" fields for each of the three atime,
      mtime, and ctime fields from "int" to "long".  As a result, on 32-bit
      platforms nothing changes, and 64-bit platforms will now work as expected.
      
      The only wrinkle is 32-bit userspace under 64-bit kernels taking advantage
      of COMPAT mode.  For these, we leave the "struct stat64" definitions with
      the "int" versions of the time_t and nsec fields, so that architectures
      can implement compat_sys_stat64() and friends with sys_stat64(), etc.,
      and get the expected 32-bit structure layout.  This requires a
      field-by-field copy in the kernel, implemented by the code guarded
      under __ARCH_WANT_STAT64.
      
      This does mean that the shape of the "struct stat" and "struct stat64"
      structures is different on a 64-bit kernel, but only one of the two
      structures should ever be used by any given process: "struct stat"
      is meant for 64-bit userspace only, and "struct stat64" for 32-bit
      userspace only.  (On a 32-bit kernel the two structures continue to have
      the same shape, since "long" is 32 bits.)
      
      The alternative is keeping the two structures the same shape on 64-bit
      kernels, which means a 64-bit time_t in "struct stat64" for 32-bit
      processes.  This is a little unnatural since 32-bit userspace can't
      do anything with 64 bits of time_t information, since time_t is just
      "long", not "int64_t"; and in any case 32-bit userspace might expect
      to be running under a 32-bit kernel, which can't provide the high 32
      bits anyway.  In the case of a 32-bit kernel we'd then be extending the
      kernel's 32-bit time_t to 64 bits, then truncating it back to 32 bits
      again in userspace, for no particular reason.  And, as mentioned above,
      if we have 64-bit time_t for 32-bit processes we can't easily use glibc's
      STAT_IS_KERNEL_STAT, since glibc's stat structure requires an embedded
      "struct timespec", which is a pair of "long" (32-bit) values in a 32-bit
      userspace.  "Inventive" solutions are possible, but are pretty hacky.
      Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      2c7387ef
  6. 01 11月, 2010 2 次提交
  7. 31 10月, 2010 4 次提交
  8. 30 10月, 2010 8 次提交
    • A
      audit mmap · 120a795d
      Al Viro 提交于
      Normal syscall audit doesn't catch 5th argument of syscall.  It also
      doesn't catch the contents of userland structures pointed to be
      syscall argument, so for both old and new mmap(2) ABI it doesn't
      record the descriptor we are mapping.  For old one it also misses
      flags.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      120a795d
    • A
      af295132
    • T
      audit: Call tty_audit_push_task() outside preempt disabled · 3c80fe4a
      Thomas Gleixner 提交于
      While auditing all tasklist_lock read_lock sites I stumbled over the
      following call chain:
      
      audit_prepare_user_tty()
        read_lock(&tasklist_lock);
        tty_audit_push_task();
           mutex_lock(&buf->mutex);
      
           --> buf->mutex is locked with preemption disabled.
      
      Solve this by acquiring a reference to the task struct under
      rcu_read_lock and call tty_audit_push_task outside of the preempt
      disabled region.
      
      Move all code which needs to be protected by sighand lock into
      tty_audit_push_task() and use lock/unlock_sighand as we do not hold
      tasklist_lock.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Eric Paris <eparis@redhat.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      3c80fe4a
    • T
      semaphore: Remove mutex emulation · 4882720b
      Thomas Gleixner 提交于
      Semaphores used as mutexes have been deprecated for years. Now that
      all users are either converted to real semaphores or to mutexes remove
      the cruft.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Christoph Hellwig <hch@infradead.org>
      LKML-Reference: <20100907125057.562399240@linutronix.de>
      4882720b
    • C
      phy/marvell: rename 88ec048 to 88e1318s and fix mscr1 addr · 337ac9d5
      Cyril Chemparathy 提交于
      The marvell 88ec048's official part number is 88e1318s.  This patch renames
      definitions in the driver to reflect this.
      
      In addition, a minor bug fix has been added to write back the MSCR1 register
      value properly.
      Signed-off-by: NCyril Chemparathy <cyril@ti.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      337ac9d5
    • S
      jump label: Add work around to i386 gcc asm goto bug · 45f81b1c
      Steven Rostedt 提交于
      On i386 (not x86_64) early implementations of gcc would have a bug
      with asm goto causing it to produce code like the following:
      
      (This was noticed by Peter Zijlstra)
      
         56 pushl 0
         67 nopl         jmp 0x6f
            popl
            jmp 0x8c
      
         6f              mov
                         test
                         je 0x8c
      
         8c mov
            call *(%esp)
      
      The jump added in the asm goto skipped over the popl that matched
      the pushl 0, which lead up to a quick crash of the system when
      the jump was enabled. The nopl is defined in the asm goto () statement
      and when tracepoints are enabled, the nop changes to a jump to the label
      that was specified by the asm goto. asm goto is suppose to tell gcc that
      the code in the asm might jump to an external label. Here gcc obviously
      fails to make that work.
      
      The bug report for gcc is here:
      
        http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46226
      
      The bug only appears on x86 when not compiled with
      -maccumulate-outgoing-args. This option is always set on x86_64 and it
      is also the work around for a function graph tracer i386 bug.
      (See commit: 746357d6)
      This explains why the bug only showed up on i386 when function graph
      tracer was not enabled.
      
      This patch now adds a CONFIG_JUMP_LABEL option that is default
      off instead of using jump labels by default. When jump labels are
      enabled, the -maccumulate-outgoing-args will be used (causing a
      slightly larger kernel image on i386). This option will exist
      until we have a way to detect if the gcc compiler in use is safe
      to use on all configurations without the work around.
      
      Note, there exists such a test, but for now we will keep the enabling
      of jump label as a manual option.
      
      Archs that know the compiler is safe with asm goto, may choose to
      select JUMP_LABEL and enable it by default.
      Reported-by: NIngo Molnar <mingo@elte.hu>
      Cause-discovered-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jason Baron <jbaron@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: David Daney <ddaney@caviumnetworks.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: David Miller <davem@davemloft.net>
      Cc: Richard Henderson <rth@redhat.com>
      LKML-Reference: <1288028746.3673.11.camel@laptop>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      45f81b1c
    • D
      debug_core,x86,blackfin: Clean up hw debug disable API · d7ba979d
      Dongdong Deng 提交于
      The kgdb_disable_hw_debug() was an architecture specific function for
      disabling all hardware breakpoints on a per cpu basis when entering
      the debug core.
      
      This patch will remove the weak function kdbg_disable_hw_debug() and
      change it into a call back which lives with the rest of hw breakpoint
      call backs in struct kgdb_arch.
      Signed-off-by: NDongdong Deng <dongdong.deng@windriver.com>
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      d7ba979d
    • L
      readv/writev: do the same MAX_RW_COUNT truncation that read/write does · 435f49a5
      Linus Torvalds 提交于
      We used to protect against overflow, but rather than return an error, do
      what read/write does, namely to limit the total size to MAX_RW_COUNT.
      This is not only more consistent, but it also means that any broken
      low-level read/write routine that still keeps counts in 'int' can't
      break.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      435f49a5
  9. 29 10月, 2010 17 次提交