Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 4 年多

通知 15
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 10 10月, 2012 1 次提交
  3. 02 11月, 2011 2 次提交
  5. 25 7月, 2008 1 次提交
  7. 13 5月, 2008 2 次提交
    • J
      uml: random driver fixes · 5d33e4d7
      由 Jeff Dike 提交于 
      The random driver would essentially hang if the host's /dev/random returned
-EAGAIN.  There was a test of need_resched followed by a schedule inside the
loop, but that didn't help and it's the wrong way to work anyway.

The right way is to ask for an interrupt when there is input available from
the host and handle it then rather than polling.

Now, when the host's /dev/random returns -EAGAIN, the driver asks for a wakeup
when there's randomness available again and sleeps.  The interrupt routine
just wakes up whatever processes are sleeping on host_read_wait.

There is an atomic_t, host_sleep_count, which counts the number of processes
waiting for randomness.  When this reaches zero, the interrupt is disabled.

An added complication is that async I/O notification was only recently added
to /dev/random (by me), so essentially all hosts will lack it.  So, we use the
sigio workaround here, which is to have a separate thread poll on the
descriptor and send an interrupt when there is input on it.  This mechanism is
activated when a process gets -EAGAIN (activating this multiple times is
harmless, if a bit wasteful) and deactivated by the last process still
waiting.

The module name was changed from "random" to "hw_random" in order for udev to
recognize it.

The sigio workaround needed some changes.  sigio_broken was added for cases
when we know that async notification doesn't work.  This is now called from
maybe_sigio_broken, which deals with pts devices.
Signed-off-by: NJeff Dike <jdike@linux.intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5d33e4d7
    • J
      uml: fix build when SLOB is enabled · 43f5b308
      由 Jeff Dike 提交于 
      Reintroduce uml_kmalloc for the benefit of UML libc code.  The
previous tactic of declaring __kmalloc so it could be called directly
from the libc side of the house turned out to be getting too intimate
with slab, and it doesn't work with slob.

So, the uml_kmalloc wrapper is back.  It calls kmalloc or whatever
that translates into, and libc code calls it.

kfree is left alone since that still works, leaving a somewhat
inconsistent API.
Signed-off-by: NJeff Dike <jdike@linux.intel.com>
Cc: WANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      43f5b308
  9. 06 2月, 2008 3 次提交
  11. 17 7月, 2007 2 次提交
  13. 08 5月, 2007 4 次提交
  15. 02 3月, 2007 1 次提交
  17. 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
  19. 21 10月, 2006 1 次提交
  21. 26 9月, 2006 1 次提交
    • J
      [PATCH] uml: SIGIO cleanups · 19bdf040
      由 Jeff Dike 提交于 
      - Various cleanups in the sigio code.

- Removed explicit zero-initializations of a few structures.

- Improved some error messages.

- An API change - there was an asymmetry between reactivate_fd calling
  maybe_sigio_broken, which goes through all the machinery of figuring out if
  a file descriptor supports SIGIO and applying the workaround to it if not,
  and deactivate_fd, which just turns off the descriptor.

  This is changed so that only activate_fd calls maybe_sigio_broken, when
  the descriptor is first seen.  reactivate_fd now calls add_sigio_fd, which
  is symmetric with ignore_sigio_fd.

  This removes a recursion which makes a critical section look more critical
  than it really was, obsoleting a big comment to that effect.  This requires
  keeping track of all descriptors which are getting the SIGIO treatment, not
  just the ones being polled at any given moment, so that reactivate_fd,
  through add_sigio_fd, doesn't try to tell the SIGIO thread about descriptors
  it doesn't care about.
Signed-off-by: NJeff Dike <jdike@addtoit.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      19bdf040
  23. 11 7月, 2006 3 次提交
  25. 11 4月, 2006 1 次提交
  27. 28 3月, 2006 3 次提交
  29. 19 1月, 2006 1 次提交
  31. 07 1月, 2006 1 次提交
  33. 07 11月, 2005 2 次提交
  35. 23 9月, 2005 1 次提交
  37. 06 5月, 2005 1 次提交
  39. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      由 Linus Torvalds 提交于 
      Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
      1da177e4