1. 11 5月, 2011 2 次提交
  2. 10 5月, 2011 1 次提交
    • M
      Don't lock guardpage if the stack is growing up · a09a79f6
      Mikulas Patocka 提交于
      Linux kernel excludes guard page when performing mlock on a VMA with
      down-growing stack. However, some architectures have up-growing stack
      and locking the guard page should be excluded in this case too.
      
      This patch fixes lvm2 on PA-RISC (and possibly other architectures with
      up-growing stack). lvm2 calculates number of used pages when locking and
      when unlocking and reports an internal error if the numbers mismatch.
      
      [ Patch changed fairly extensively to also fix /proc/<pid>/maps for the
        grows-up case, and to move things around a bit to clean it all up and
        share the infrstructure with the /proc bits.
      
        Tested on ia64 that has both grow-up and grow-down segments  - Linus ]
      Signed-off-by: NMikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
      Tested-by: NTony Luck <tony.luck@gmail.com>
      Cc: stable@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a09a79f6
  3. 09 5月, 2011 1 次提交
  4. 07 5月, 2011 1 次提交
  5. 05 5月, 2011 1 次提交
    • T
      slub: Fix the lockless code on 32-bit platforms with no 64-bit cmpxchg · 30106b8c
      Thomas Gleixner 提交于
      The SLUB allocator use of the cmpxchg_double logic was wrong: it
      actually needs the irq-safe one.
      
      That happens automatically when we use the native unlocked 'cmpxchg8b'
      instruction, but when compiling the kernel for older x86 CPUs that do
      not support that instruction, we fall back to the generic emulation
      code.
      
      And if you don't specify that you want the irq-safe version, the generic
      code ends up just open-coding the cmpxchg8b equivalent without any
      protection against interrupts or preemption.  Which definitely doesn't
      work for SLUB.
      
      This was reported by Werner Landgraf <w.landgraf@ru.ru>, who saw
      instability with his distro-kernel that was compiled to support pretty
      much everything under the sun.  Most big Linux distributions tend to
      compile for PPro and later, and would never have noticed this problem.
      
      This also fixes the prototypes for the irqsafe cmpxchg_double functions
      to use 'bool' like they should.
      
      [ Btw, that whole "generic code defaults to no protection" design just
        sounds stupid - if the code needs no protection, there is no reason to
        use "cmpxchg_double" to begin with.  So we should probably just remove
        the unprotected version entirely as pointless.   - Linus ]
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Reported-and-tested-by: Nwerner <w.landgraf@ru.ru>
      Acked-and-tested-by: NIngo Molnar <mingo@elte.hu>
      Acked-by: NChristoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Tejun Heo <tj@kernel.org>
      Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1105041539050.3005@ionosSigned-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      30106b8c
  6. 04 5月, 2011 2 次提交
  7. 02 5月, 2011 1 次提交
    • J
      i2c-i801: Move device ID definitions to driver · a6e5e2be
      Jean Delvare 提交于
      Move the SMBus device ID definitions of recent devices from pci_ids.h
      to the i2c-i801.c driver file. They don't have to be shared, as they
      are clearly identified and only used in this driver. In the future,
      such IDs will go to i2c-i801 directly. This will make adding support
      for new devices much faster and easier, as it will avoid cross-
      subsystem patch sets and merge conflicts.
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Cc: Seth Heasley <seth.heasley@intel.com>
      Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      a6e5e2be
  8. 29 4月, 2011 3 次提交
  9. 28 4月, 2011 3 次提交
  10. 27 4月, 2011 2 次提交
  11. 26 4月, 2011 2 次提交
  12. 25 4月, 2011 3 次提交
  13. 24 4月, 2011 3 次提交
    • T
      libata: Implement ATA_FLAG_NO_DIPM and apply it to mcp65 · ae01b249
      Tejun Heo 提交于
      NVIDIA mcp65 familiy of controllers cause command timeouts when DIPM
      is used.  Implement ATA_FLAG_NO_DIPM and apply it.
      
      This problem was reported by Stefan Bader in the following thread.
      
       http://thread.gmane.org/gmane.linux.ide/48841
      
      stable: applicable to 2.6.37 and 38.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Reported-by: NStefan Bader <stefan.bader@canonical.com>
      Cc: stable@kernel.org
      Signed-off-by: NJeff Garzik <jgarzik@pobox.com>
      ae01b249
    • T
      libata: Kill unused ATA_DFLAG_{H|D}IPM flags · 3f7ac1d6
      Tejun Heo 提交于
      ATA_DFLAG_{H|D}IPM flags are no longer used.  Kill them.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NJeff Garzik <jgarzik@pobox.com>
      3f7ac1d6
    • L
      vfs: get rid of insane dentry hashing rules · dea3667b
      Linus Torvalds 提交于
      The dentry hashing rules have been really quite complicated for a long
      while, in odd ways.  That made functions like __d_drop() very fragile
      and non-obvious.
      
      In particular, whether a dentry was hashed or not was indicated with an
      explicit DCACHE_UNHASHED bit.  That's despite the fact that the hash
      abstraction that the dentries use actually have a 'is this entry hashed
      or not' model (which is a simple test of the 'pprev' pointer).
      
      The reason that was done is because we used the normal 'is this entry
      unhashed' model to mark whether the dentry had _ever_ been hashed in the
      dentry hash tables, and that logic goes back many years (commit
      b3423415: "dcache: avoid RCU for never-hashed dentries").
      
      That, in turn, meant that __d_drop had totally different unhashing logic
      for the dentry hash table case and for the anonymous dcache case,
      because in order to use the "is this dentry hashed" logic as a flag for
      whether it had ever been on the RCU hash table, we had to unhash such a
      dentry differently so that we'd never think that it wasn't 'unhashed'
      and wouldn't be free'd correctly.
      
      That's just insane.  It made the logic really hard to follow, when there
      were two different kinds of "unhashed" states, and one of them (the one
      that used "list_bl_unhashed()") really had nothing at all to do with
      being unhashed per se, but with a very subtle lifetime rule instead.
      
      So turn all of it around, and make it logical.
      
      Instead of having a DENTRY_UNHASHED bit in d_flags to indicate whether
      the dentry is on the hash chains or not, use the hash chain unhashed
      logic for that.  Suddenly "d_unhashed()" just uses "list_bl_unhashed()",
      and everything makes sense.
      
      And for the lifetime rule, just use an explicit DENTRY_RCUACCEES bit.
      If we ever insert the dentry into the dentry hash table so that it is
      visible to RCU lookup, we mark it DENTRY_RCUACCESS to show that it now
      needs the RCU lifetime rules.  Now suddently that test at dentry free
      time makes sense too.
      
      And because unhashing now is sane and doesn't depend on where the dentry
      got unhashed from (because the dentry hash chain details doesn't have
      some subtle side effects), we can re-unify the __d_drop() logic and use
      common code for the unhashing.
      
      Also fix one more open-coded hash chain bit_spin_lock() that I missed in
      the previous chain locking cleanup commit.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dea3667b
  14. 23 4月, 2011 1 次提交
  15. 19 4月, 2011 6 次提交
  16. 18 4月, 2011 5 次提交
  17. 16 4月, 2011 3 次提交