1. 15 2月, 2008 2 次提交
  2. 14 2月, 2008 3 次提交
  3. 13 2月, 2008 22 次提交
  4. 12 2月, 2008 13 次提交
    • L
      WMI: initialize wmi_blocks.list even if ACPI is disabled · 96b5a46e
      Linus Torvalds 提交于
      Even if we don't want to register the WMI driver, we should initialize
      the wmi_blocks list to be empty, since we don't want the wmi helper
      functions to oops just because that basic list has not even been set up.
      
      With this, "find_guid()" will happily return "not found" rather than
      oopsing all over the place, and the callers will then just automatically
      return false or AE_NOT_FOUND as appropriate.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      96b5a46e
    • R
      x86: vdso_install fix · 2c158269
      Roland McGrath 提交于
      The makefile magic for installing the 32-bit vdso images on disk had a
      little error.  A single-line change would fix that bug, but this does a
      little more to reduce the error-prone duplication of this bit of
      makefile variable magic.
      Signed-off-by: NRoland McGrath <roland@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2c158269
    • K
      mempolicy: silently restrict nodemask to allowed nodes · 31f1de46
      KOSAKI Motohiro 提交于
      Kosaki Motohito noted that "numactl --interleave=all ..." failed in the
      presence of memoryless nodes.  This patch attempts to fix that problem.
      
      Some background:
      
      numactl --interleave=all calls set_mempolicy(2) with a fully populated
      [out to MAXNUMNODES] nodemask.  set_mempolicy() [in do_set_mempolicy()]
      calls contextualize_policy() which requires that the nodemask be a
      subset of the current task's mems_allowed; else EINVAL will be returned.
      
      A task's mems_allowed will always be a subset of node_states[N_HIGH_MEMORY]
      i.e., nodes with memory.  So, a fully populated nodemask will be
      declared invalid if it includes memoryless nodes.
      
        NOTE:  the same thing will occur when running in a cpuset
               with restricted mem_allowed--for the same reason:
               node mask contains dis-allowed nodes.
      
      mbind(2), on the other hand, just masks off any nodes in the nodemask
      that are not included in the caller's mems_allowed.
      
      In each case [mbind() and set_mempolicy()], mpol_check_policy() will
      complain [again, resulting in EINVAL] if the nodemask contains any
      memoryless nodes.  This is somewhat redundant as mpol_new() will remove
      memoryless nodes for interleave policy, as will bind_zonelist()--called
      by mpol_new() for BIND policy.
      
      Proposed fix:
      
      1) modify contextualize_policy logic to:
         a) remember whether the incoming node mask is empty.
         b) if not, restrict the nodemask to allowed nodes, as is
            currently done in-line for mbind().  This guarantees
            that the resulting mask includes only nodes with memory.
      
            NOTE:  this is a [benign, IMO] change in behavior for
                   set_mempolicy().  Dis-allowed nodes will be
                   silently ignored, rather than returning an error.
      
         c) fold this code into mpol_check_policy(), replace 2 calls to
            contextualize_policy() to call mpol_check_policy() directly
            and remove contextualize_policy().
      
      2) In existing mpol_check_policy() logic, after "contextualization":
         a) MPOL_DEFAULT:  require that in coming mask "was_empty"
         b) MPOL_{BIND|INTERLEAVE}:  require that contextualized nodemask
            contains at least one node.
         c) add a case for MPOL_PREFERRED:  if in coming was not empty
            and resulting mask IS empty, user specified invalid nodes.
            Return EINVAL.
         c) remove the now redundant check for memoryless nodes
      
      3) remove the now redundant masking of policy nodes for interleave
         policy from mpol_new().
      
      4) Now that mpol_check_policy() contextualizes the nodemask, remove
         the in-line nodes_and() from sys_mbind().  I believe that this
         restores mbind() to the behavior before the memoryless-nodes
         patch series.  E.g., we'll no longer treat an invalid nodemask
         with MPOL_PREFERRED as local allocation.
      
      [ Patch history:
      
        v1 -> v2:
         - Communicate whether or not incoming node mask was empty to
           mpol_check_policy() for better error checking.
         - As suggested by David Rientjes, remove the now unused
           cpuset_nodes_subset_current_mems_allowed() from cpuset.h
      
        v2 -> v3:
         - As suggested by Kosaki Motohito, fold the "contextualization"
           of policy nodemask into mpol_check_policy().  Looks a little
           cleaner. ]
      Signed-off-by: NLee Schermerhorn <lee.schermerhorn@hp.com>
      Signed-off-by: NKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Tested-by: NKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Acked-by: NDavid Rientjes <rientjes@google.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      31f1de46
    • L
    • J
      Be more robust about bad arguments in get_user_pages() · 900cf086
      Jonathan Corbet 提交于
      So I spent a while pounding my head against my monitor trying to figure
      out the vmsplice() vulnerability - how could a failure to check for
      *read* access turn into a root exploit? It turns out that it's a buffer
      overflow problem which is made easy by the way get_user_pages() is
      coded.
      
      In particular, "len" is a signed int, and it is only checked at the
      *end* of a do {} while() loop.  So, if it is passed in as zero, the loop
      will execute once and decrement len to -1.  At that point, the loop will
      proceed until the next invalid address is found; in the process, it will
      likely overflow the pages array passed in to get_user_pages().
      
      I think that, if get_user_pages() has been asked to grab zero pages,
      that's what it should do.  Thus this patch; it is, among other things,
      enough to block the (already fixed) root exploit and any others which
      might be lurking in similar code.  I also think that the number of pages
      should be unsigned, but changing the prototype of this function probably
      requires some more careful review.
      Signed-off-by: NJonathan Corbet <corbet@lwn.net>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      900cf086
    • L
      b1292b17
    • P
      Add Matt to MAINTAINERS as a SLAB allocator maintainer · c76d118e
      Pekka Enberg 提交于
      Matt is already the maintainer of SLOB which is one of the "SLAB" allocators in
      the kernel so add him to MAINTAINERS.
      Signed-off-by: NPekka Enberg <penberg@cs.helsinki.fi>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c76d118e
    • L
      Merge branch 'upstream-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev · a17b7a39
      Linus Torvalds 提交于
      * 'upstream-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev:
        sata_mv: platform driver allocs dma without create
        pata_ninja32: setup changes
        pata_legacy: typo fix
        pata_amd: Note in the module description it handles Nvidia
        sata_mv: fix loop with last port
        libata: ignore deverr on SETXFER if mode is configured
        pata_via: fix SATA cable detection on cx700
      a17b7a39
    • A
      Make topology fallback macros reference their arguments. · 271cad6d
      Andi Kleen 提交于
      This avoids warnings with unreferenced variables in the !NUMA case.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      271cad6d
    • O
      mlx4_core: Fix build break (missing include) · 29c27112
      Olof Johansson 提交于
      Commit 313abe55 ("mlx4_core: For 64-bit systems, vmap() kernel queue
      buffers") caused this to pop up on powerpc allyesconfig, looks like a
      missing include file:
      
          drivers/net/mlx4/alloc.c: In function 'mlx4_buf_alloc':
          drivers/net/mlx4/alloc.c:162: error: implicit declaration of function 'vmap'
          drivers/net/mlx4/alloc.c:162: error: 'VM_MAP' undeclared (first use in this function)
          drivers/net/mlx4/alloc.c:162: error: (Each undeclared identifier is reported only once
          drivers/net/mlx4/alloc.c:162: error: for each function it appears in.)
          drivers/net/mlx4/alloc.c:162: warning: assignment makes pointer from integer without a cast
          drivers/net/mlx4/alloc.c: In function 'mlx4_buf_free':
          drivers/net/mlx4/alloc.c:187: error: implicit declaration of function 'vunmap'
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      29c27112
    • T
      [IA64] Fix build for sim_defconfig · 10d0aa3c
      Tony Luck 提交于
      Commit bdc80787 broke the build
      for this config because the sim_defconfig selects CONFIG_HZ=250
      but include/asm-ia64/param.h has an ifdef for the simulator to
      force HZ to 32.  So we ended up with a kernel/timeconst.h set
      for HZ=250 ... which then failed the check for the right HZ
      value and died with:
      
      Drop the #ifdef magic from param.h and make force CONFIG_HZ=32
      directly for the simulator.
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      10d0aa3c
    • B
      sata_mv: platform driver allocs dma without create · fbf14e2f
      Byron Bradley 提交于
      When the sata_mv driver is used as a platform driver,
      mv_create_dma_pools() is never called so it fails when trying
      to alloc in mv_pool_start().
      Signed-off-by: NByron Bradley <byron.bbradley@gmail.com>
      Acked-by: NMark Lord <mlord@pobox.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      fbf14e2f
    • A
      pata_ninja32: setup changes · 41946450
      Alan Cox 提交于
      Forcibly set more of the configuration at init time. This seems to fix at
      least one problem reported. We don't know what most of these bits do, but
      we do know what windows stuffs there.
      Signed-off-by: NAlan Cox <alan@redhat.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      41946450