Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 08 5月, 2007 10 次提交
  3. 26 4月, 2007 1 次提交
  5. 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
  7. 08 3月, 2007 1 次提交
  9. 07 3月, 2007 2 次提交
  11. 02 3月, 2007 2 次提交
  13. 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
  15. 12 2月, 2007 12 次提交
  17. 08 12月, 2006 1 次提交
  19. 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
  21. 04 11月, 2006 2 次提交
    • J
      [PATCH] uml: include tidying · 1f6f6164
      由 Jeff Dike 提交于 
      In order to get the __NR_* constants, we need sys/syscall.h.
linux/unistd.h works as well since it includes syscall.h, however syscall.h
is more parsimonious.  We were inconsistent in this, and this patch adds
syscall.h includes where necessary and removes linux/unistd.h includes
where they are not needed.

asm/unistd.h also includes the __NR_* constants, but these are not the
glibc-sanctioned ones, so this also removes one such inclusion.
Signed-off-by: NJeff Dike <jdike@addtoit.com>
Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      1f6f6164
    • J
      [PATCH] uml: fix I/O hang · 53b17332
      由 Jeff Dike 提交于 
      Fix a UML hang in which everything would just stop until some I/O happened
- a ping, someone whacking the keyboard - at which point everything would
start up again as though nothing had happened.

The cause was gcc reordering some code which absolutely needed to be
executed in the order in the source.  When unblock_signals switches signals
from off to on, it needs to see if any interrupts had happened in the
critical section.  The interrupt handlers check signals_enabled - if it is
zero, then the handler adds a bit to the "pending" bitmask and returns.
unblock_signals checks this mask to see if any signals need to be
delivered.

The crucial part is this:
	signals_enabled = 1;
	save_pending = pending;
	if(save_pending == 0)
		return;
	pending = 0;

In order to avoid an interrupt arriving between reading pending and setting
it to zero, in which case, the record of the interrupt would be erased,
signals are enabled.

What happened was that gcc reordered this so that 'save_pending = pending'
came before 'signals_enabled = 1', creating a one-instruction window within
which an interrupt could arrive, set its bit in pending, and have it be
immediately erased.

When the I/O workload is purely disk-based, the loss of a block device
interrupt stops the entire I/O system because the next block request will
wait for the current one to finish.  Thus the system hangs until something
else causes some I/O to arrive, such as a network packet or console input.

The fix to this particular problem is a memory barrier between enabling
signals and reading the pending signal mask.  An xchg would also probably
work.

Looking over this code for similar problems led me to do a few more
things:

- make signals_enabled and pending volatile so that they don't get cached
  in registers

- add an mb() to the return paths of block_signals and unblock_signals so
  that the modification of signals_enabled doesn't get shuffled into the
  caller in the event that these are inlined in the future.
Signed-off-by: NJeff Dike <jdike@addtoit.com>
Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      53b17332
  23. 31 10月, 2006 1 次提交
  25. 21 10月, 2006 4 次提交
  27. 12 10月, 2006 1 次提交