1. 08 5月, 2007 18 次提交
  2. 26 4月, 2007 1 次提交
  3. 28 3月, 2007 1 次提交
    • J
      [PATCH] uml: use correct register file size everywhere · b92c4f92
      Jeff Dike 提交于
      This patch uses MAX_REG_NR consistently to refer to the register file size.
       FRAME_SIZE isn't sufficient because on x86_64, it is smaller than the
      ptrace register file size.  MAX_REG_NR was introduced as a consistent way
      to get the number of registers, but wasn't used everywhere it should be.
      
      When this causes a problem, it makes PTRACE_SETREGS fail on x86_64 because
      of a corrupted segment register value in the known-good register file.  The
      patch also adds a register dump at that point in case there are any future
      problems here.
      Signed-off-by: NJeff Dike <jdike@linux.intel.com>
      Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b92c4f92
  4. 08 3月, 2007 1 次提交
  5. 07 3月, 2007 2 次提交
  6. 02 3月, 2007 2 次提交
  7. 17 2月, 2007 1 次提交
    • J
      [PATCH] uml: fix 2.6.20 hang · 838e56a1
      Jeff Dike 提交于
      A previous cleanup misused need_poll, which had a fairly broken interface.
      It implemented a growable array, changing the used elements count itself,
      but leaving it up to the caller to fill in the actual elements, including
      the entire array if the array had to be reallocated.  This worked because
      the previous users were switching between two such structures, and the
      elements were copied from the inactive array to the active array after
      making sure the active array had enough room.
      
      maybe_sigio_broken was made to use need_poll, but it was operating on a
      single array, so when the buffer was reallocated, the previous contents
      were lost.
      
      This patch makes need_poll implement more sane semantics.  It merely
      assures that the array is of the proper size and that the contents are
      preserved.  It is up to the caller to adjust the used elements count and to
      ensure that the proper elements are resent.
      
      This manifested itself as a hang in 2.6.20 as the uninitialized buffer
      convinced UML that one of its own file descriptors didn't support SIGIO and
      needed to be watched by poll in a separate thread.  The result was an
      interrupt flood as control traffic over this descriptor sparked interrupts,
      which resulted in more control traffic, ad nauseum.
      Signed-off-by: NJeff Dike <jdike@addtoit.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      838e56a1
  8. 12 2月, 2007 12 次提交
  9. 08 12月, 2006 1 次提交
  10. 26 11月, 2006 1 次提交
    • P
      [PATCH] uml: make execvp safe for our usage · 5d48545e
      Paolo 'Blaisorblade' Giarrusso 提交于
      Reimplement execvp for our purposes - after we call fork() it is fundamentally
      unsafe to use the kernel allocator - current is not valid there.  So we simply
      pass to our modified execvp() a preallocated buffer.  This fixes a real bug
      and works very well in testing (I've seen indirectly warning messages from the
      forked thread - they went on the pipe connected to its stdout and where read
      as a number by UML, when calling read_output().  I verified the obtained
      number corresponded to "BUG:").
      
      The added use of __cant_sleep() is not a new bug since __cant_sleep() is
      already used in the same function - passing an atomicity parameter would be
      better but it would require huge change, stating that this function must not
      be called in atomic context and can sleep is a better idea (will make sure of
      this gradually).
      Signed-off-by: NPaolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Acked-by: NJeff Dike <jdike@addtoit.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5d48545e