1. 21 Feb, 2006 10 commits
    • Juergen Kreileder's avatar
      [PATCH] Fix snd-usb-audio in 32-bit compat environment · aa657ca9
      Juergen Kreileder authored
      I'm getting oopses with snd-usb-audio in 32-bit compat environments:
      control_compat.c:get_ctl_type() doesn't initialize 'info', so
      'itemlist[uinfo->value.enumerated.item]' in
      usbmixer.c:mixer_ctl_selector_info() might access random memory (The 'if
      ((int)uinfo->value.enumerated.item >= cval->max)' doesn't fix all problems
      because of the unsigned -> signed conversion.)
      Signed-off-by: default avatarJuergen Kreileder <jk@blackdown.de>
      Cc: Jaroslav Kysela <perex@suse.cz>
      Acked-by: default avatarTakashi Iwai <tiwai@suse.de>
      Cc: Greg KH <greg@kroah.com>
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      aa657ca9
    • Andi Kleen's avatar
      [PATCH] Fix units in mbind check · a9c930ba
      Andi Kleen authored
      maxnode is a bit index and can't be directly compared against a byte length
      like PAGE_SIZE
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Cc: Chris Wright <chrisw@sous-sol.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      a9c930ba
    • Pavel Machek's avatar
      [PATCH] suspend-to-ram: allow video options to be set at runtime · c255d844
      Pavel Machek authored
      Currently, acpi video options can only be set on kernel command line.  That's
      little inflexible; I'd like userland s2ram application that just works, and
      modifying kernel command line according to whitelist is not fun.  It is better
      to just allow s2ram application to set video options just before suspend
      (according to the whitelist).
      
      This implements sysctl to allow setting suspend video options without reboot.
      
      (akpm: Documentation updates for this new sysctl are pending..)
      Signed-off-by: default avatarPavel Machek <pavel@suse.cz>
      Cc: "Brown, Len" <len.brown@intel.com>
      Cc: "Antonino A. Daplas" <adaplas@pol.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      c255d844
    • Heiko Carstens's avatar
      [PATCH] cpu hotplug documentation fix · 6303dbf5
      Heiko Carstens authored
      Looks like there was a merge conflict when patches
      8f8b1138 and
      255acee7 were applied which wasn't properly
      resolved. Fix this and add some additional description.
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Ashok Raj <ashok.raj@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      6303dbf5
    • Andi Kleen's avatar
      [PATCH] x86_64: Don't set CONFIG_DEBUG_INFO in defconfig · 2e2b4263
      Andi Kleen authored
      Undo setting of CONFIG_DEBUG_INFO in the previous defconfig update.  It
      will make every build much slower and need more disk space and isn't a good
      default.
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      2e2b4263
    • Stephen Street's avatar
      [PATCH] spi: Fix modular master driver remove and device suspend/remove · d2799f08
      Stephen Street authored
      Fix two problems in the spi subsystem:
      
      1) spi subsystem core dumps when modular spi master is unloaded.
      2) spi subsystem core dumps when spi slave device is suspended/resumed and
         module slave driver is not loaded.
      Signed-off-by: default avatarStephen Street <stephen@streetfiresound.com>
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      d2799f08
    • Alexey Korolev's avatar
      [PATCH] cfi_cmdset_0001: fix range for cache invalidation · d86d4370
      Alexey Korolev authored
      I found an issue in cfi_cmdset0001.c.  It is related to cache region
      invalidation in the buffered write procedure.
      
      The code performs cache invalidation from "cmd_addr" to "cmd_adr + len" in
      do_write_buffer() while we modify region from "adr" to "adr+len".
      
      This issue affects writes + reads of data by small chunks.
      Signed-off-by: default avatarNicolas Pitre <nico@cam.org>
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      d86d4370
    • Daniel Yeisley's avatar
      [PATCH] i386: need to pass virtual address to smp_read_mpc() · 7d4c8e56
      Daniel Yeisley authored
      I'm seeing a kernel panic on an ES7000-600 when booting in virtual wire
      mode.  The panic happens because smp_read_mpc() is passed a physical
      address, and it should be virtual.  I tested the attached patch on the
      ES7000-600 and on a 2 cpu Dell box, and saw no problems on either.
      Signed-off-by: default avatarDan Yeisley <dan.yeisley@unisys.com>
      Acked-by: default avatarAndi Kleen <ak@muc.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      7d4c8e56
    • Christoph Lameter's avatar
      [PATCH] Terminate process that fails on a constrained allocation · 9b0f8b04
      Christoph Lameter authored
      Some allocations are restricted to a limited set of nodes (due to memory
      policies or cpuset constraints).  If the page allocator is not able to find
      enough memory then that does not mean that overall system memory is low.
      
      In particular going postal and more or less randomly shooting at processes
      is not likely going to help the situation but may just lead to suicide (the
      whole system coming down).
      
      It is better to signal to the process that no memory exists given the
      constraints that the process (or the configuration of the process) has
      placed on the allocation behavior.  The process may be killed but then the
      sysadmin or developer can investigate the situation.  The solution is
      similar to what we do when running out of hugepages.
      
      This patch adds a check before we kill processes.  At that point
      performance considerations do not matter much so we just scan the zonelist
      and reconstruct a list of nodes.  If the list of nodes does not contain all
      online nodes then this is a constrained allocation and we should kill the
      current process.
      Signed-off-by: default avatarChristoph Lameter <clameter@sgi.com>
      Cc: Nick Piggin <nickpiggin@yahoo.com.au>
      Cc: Andi Kleen <ak@muc.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      9b0f8b04
    • Kurt Garloff's avatar
      [PATCH] OOM kill: children accounting · 9827b781
      Kurt Garloff authored
      In the badness() calculation, there's currently this piece of code:
      
              /*
               * Processes which fork a lot of child processes are likely
               * a good choice. We add the vmsize of the children if they
               * have an own mm. This prevents forking servers to flood the
               * machine with an endless amount of children
               */
              list_for_each(tsk, &p->children) {
                      struct task_struct *chld;
                      chld = list_entry(tsk, struct task_struct, sibling);
                      if (chld->mm = p->mm && chld->mm)
                              points += chld->mm->total_vm;
              }
      
      The intention is clear: If some server (apache) keeps spawning new children
      and we run OOM, we want to kill the father rather than picking a child.
      
      This -- to some degree -- also helps a bit with getting fork bombs under
      control, though I'd consider this a desirable side-effect rather than a
      feature.
      
      There's one problem with this: No matter how many or few children there are,
      if just one of them misbehaves, and all others (including the father) do
      everything right, we still always kill the whole family.  This hits in real
      life; whether it's javascript in konqueror resulting in kdeinit (and thus the
      whole KDE session) being hit or just a classical server that spawns children.
      
      Sidenote: The killer does kill all direct children as well, not only the
      selected father, see oom_kill_process().
      
      The idea in attached patch is that we do want to account the memory
      consumption of the (direct) children to the father -- however not fully.
      This maintains the property that fathers with too many children will still
      very likely be picked, whereas a single misbehaving child has the chance to
      be picked by the OOM killer.
      
      In the patch I account only half (rounded up) of the children's vm_size to
      the parent.  This means that if one child eats more mem than the rest of
      the family, it will be picked, otherwise it's still the father and thus the
      whole family that gets selected.
      
      This is heuristics -- we could debate whether accounting for a fourth would
      be better than for half of it.  Or -- if people would consider it worth the
      trouble -- make it a sysctl.  For now I sticked to accounting for half,
      which should IMHO be a significant improvement.
      
      The patch does one more thing: As users tend to be irritated by the choice
      of killed processes (mainly because the children are killed first, despite
      some of them having a very low OOM score), I added some more output: The
      selected (father) process will be reported first and it's oom_score printed
      to syslog.
      
      Description:
      
      Only account for half of children's vm size in oom score calculation
      
      This should still give the parent enough point in case of fork bombs.  If
      any child however has more than 50% of the vm size of all children
      together, it'll get a higher score and be elected.
      
      This patch also makes the kernel display the oom_score.
      Signed-off-by: default avatarKurt Garloff <garloff@suse.de>
      Cc: Rik van Riel <riel@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      9827b781
  2. 17 Feb, 2006 30 commits