1. 28 4月, 2006 9 次提交
    • C
      [PATCH] s390: add read_mostly optimization · 58268b97
      Christian Borntraeger 提交于
      Add a read_mostly section and define __read_mostly to prevent cache line
      pollution due to writes for mostly read variables.  In addition fix the
      incorrect alignment of the cache_line_aligned data section.  s390 has a
      cacheline size of 256 bytes.
      Signed-off-by: NChristian Borntraeger <cborntra@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      58268b97
    • M
      [PATCH] s390: futex atomic operations · 3363fbdd
      Martin Schwidefsky 提交于
      Add support for atomic futex operations.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3363fbdd
    • A
      [PATCH] request_irq(): remove warnings from irq probing · 13e87ec6
      Andrew Morton 提交于
      - Add new SA_PROBEIRQ which suppresses the new sharing-mismatch warning.
        Some drivers like to use request_irq() to find an unused interrupt slot.
      
      - Use it in i82365.c
      
      - Kill unused SA_PROBE.
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      13e87ec6
    • C
      [IA64] enable dumps to capture second page of kernel stack · 1df57c0c
      Cliff Wickman 提交于
      In SLES10 (2.6.16) crash dumping (in my experience, LKCD) is unable to
      capture the second page of the 2-page task/stack allocation.
      This is particularly troublesome for dump analysis, as the stack traceback
      cannot be done.
        (A similar convention is probably needed throughout the kernel to make
         kernel multi-page allocations detectable for dumping)
      
      Multi-page kernel allocations are represented by the single page structure
      associated with the first page of the allocation.  The page structures
      associated with the other pages are unintialized.
      
      If the dumper is selecting only kernel pages it has no way to identify
      any but the first page of the allocation.
      
      The fix is to make the task/stack allocation a compound page.
      Signed-off-by: NCliff Wickman <cpw@sgi.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      1df57c0c
    • J
      [IA64-SGI] - Fix discover of nearest cpu node to IO node · f0fe253c
      Jack Steiner 提交于
      Fix a bug that causes discovery of the nearest node/cpu to
      a TIO (IO node) to fail.
      Signed-off-by: NJack Steiner <steiner@sgi.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      f0fe253c
    • A
      [PATCH] Kobject: possible cleanups · 5b3ef14e
      Adrian Bunk 提交于
      This patch contains the following possible cleanups:
      - #if 0 the following unused global function:
        - subsys_remove_file()
      - remove the following unused EXPORT_SYMBOL's:
        - kset_find_obj
        - subsystem_init
      - remove the following unused EXPORT_SYMBOL_GPL:
        - kobject_add_dir
      Signed-off-by: NAdrian Bunk <bunk@stusta.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      5b3ef14e
    • J
      [PATCH] Fix OCFS2 warning when DEBUG_FS is not enabled · bde11d79
      Jean Delvare 提交于
      Fix the following warning which happens when OCFS2_FS is enabled but
      DEBUG_FS isn't:
      
      fs/ocfs2/dlmglue.c: In function `ocfs2_dlm_init_debug':
      fs/ocfs2/dlmglue.c:2036: warning: passing arg 5 of `debugfs_create_file' discards qualifiers from pointer target type
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Cc: Joel Becker <Joel.Becker@oracle.com>
      Acked-by: NMark Fasheh <mark.fasheh@oracle.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      bde11d79
    • K
      [PATCH] Kobject: fix build error · 4d17ffda
      Kay Sievers 提交于
      This fixes a build error for various odd combinations of CONFIG_HOTPLUG
      and CONFIG_NET.
      Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
      Cc: Nigel Cunningham <ncunningham@cyclades.com>
      Cc: Andrew Morton <akpm@osdl.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      4d17ffda
    • Z
      [PATCH] x86/PAE: Fix pte_clear for the >4GB RAM case · 6e5882cf
      Zachary Amsden 提交于
      Proposed fix for ptep_get_and_clear_full PAE bug.  Pte_clear had the same bug,
      so use the same fix for both.  Turns out pmd_clear had it as well, but pgds
      are not affected.
      
      The problem is rather intricate.  Page table entries in PAE mode are 64-bits
      wide, but the only atomic 8-byte write operation available in 32-bit mode is
      cmpxchg8b, which is expensive (at least on P4), and thus avoided.  But it can
      happen that the processor may prefetch entries into the TLB in the middle of an
      operation which clears a page table entry.  So one must always clear the P-bit
      in the low word of the page table entry first when clearing it.
      
      Since the sequence *ptep = __pte(0) leaves the order of the write dependent on
      the compiler, it must be coded explicitly as a clear of the low word followed
      by a clear of the high word.  Further, there must be a write memory barrier
      here to enforce proper ordering by the compiler (and, in the future, by the
      processor as well).
      
      On > 4GB memory machines, the implementation of pte_clear for PAE was clearly
      deficient, as it could leave virtual mappings of physical memory above 4GB
      aliased to memory below 4GB in the TLB.  The implementation of
      ptep_get_and_clear_full has a similar bug, although not nearly as likely to
      occur, since the mappings being cleared are in the process of being destroyed,
      and should never be dereferenced again.
      
      But, as luck would have it, it is possible to trigger bugs even without ever
      dereferencing these bogus TLB mappings, even if the clear is followed fairly
      soon after with a TLB flush or invalidation.  The problem is that memory above
      4GB may now be aliased into the first 4GB of memory, and in fact, may hit a
      region of memory with non-memory semantics.  These regions include AGP and PCI
      space.  As such, these memory regions are not cached by the processor.  This
      introduces the bug.
      
      The processor can speculate memory operations, including memory writes, as long
      as they are committed with the proper ordering.  Speculating a memory write to
      a linear address that has a bogus TLB mapping is possible.  Normally, the
      speculation is harmless.  But for cached memory, it does leave the falsely
      speculated cacheline unmodified, but in a dirty state.  This cache line will be
      eventually written back.  If this cacheline happens to intersect a region of
      memory that is not protected by the cache coherency protocol, it can corrupt
      data in I/O memory, which is generally a very bad thing to do, and can cause
      total system failure or just plain undefined behavior.
      
      These bugs are extremely unlikely, but the severity is of such magnitude, and
      the fix so simple that I think fixing them immediately is justified.  Also,
      they are nearly impossible to debug.
      Signed-off-by: NZachary Amsden <zach@vmware.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      6e5882cf
  2. 27 4月, 2006 9 次提交
  3. 26 4月, 2006 4 次提交
  4. 25 4月, 2006 18 次提交