Skip to content

K
Kernel

openeuler / Kernel
大约 1 年 前同步成功

通知 5
Star 0
Fork 0
K
Kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 16 7月, 2010 2 次提交
  3. 24 6月, 2010 3 次提交
  5. 09 3月, 2010 1 次提交
  7. 04 2月, 2010 1 次提交
  9. 06 1月, 2010 1 次提交
    • A
      Input: evdev - be less aggressive about sending SIGIO notifies · 30a589fd
      由 Adam Jackson 提交于 
      When using realtime signals, we'll enqueue one signal for every event.
This is unfortunate, because (for example) keyboard presses are three
events: key, msc scancode, and syn.  They'll be enqueued fast enough in
kernel space that all three events will be ready to read by the time
userspace runs, so the first invocation of the signal handler will read
all three events, but then the second two invocations still have to run
to do no work.

Instead, only send the SIGIO notification on syn events.  This is a
slight abuse of SIGIO semantics, in principle it ought to fire as soon
as any events are readable.  But it matches evdev semantics, which is
more important since SIGIO is rather vaguely defined to begin with.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      30a589fd
  11. 05 10月, 2009 1 次提交
  13. 14 7月, 2009 1 次提交
  15. 20 6月, 2009 1 次提交
  17. 11 5月, 2009 1 次提交
  19. 16 3月, 2009 1 次提交
    • J
      Rationalize fasync return values · 60aa4924
      由 Jonathan Corbet 提交于 
      Most fasync implementations do something like:

     return fasync_helper(...);

But fasync_helper() will return a positive value at times - a feature used
in at least one place.  Thus, a number of other drivers do:

     err = fasync_helper(...);
     if (err < 0)
             return err;
     return 0;

In the interests of consistency and more concise code, it makes sense to
map positive return values onto zero where ->fasync() is called.

Cc: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>
      60aa4924
  21. 02 11月, 2008 1 次提交
    • A
      saner FASYNC handling on file close · 233e70f4
      由 Al Viro 提交于 
      As it is, all instances of ->release() for files that have ->fasync()
need to remember to evict file from fasync lists; forgetting that
creates a hole and we actually have a bunch that *does* forget.

So let's keep our lives simple - let __fput() check FASYNC in
file->f_flags and call ->fasync() there if it's been set.  And lose that
crap in ->release() instances - leaving it there is still valid, but we
don't have to bother anymore.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      233e70f4
  23. 30 10月, 2008 1 次提交
  25. 28 10月, 2008 1 次提交
  27. 19 8月, 2008 1 次提交
  29. 09 8月, 2008 1 次提交
  31. 08 8月, 2008 1 次提交
  33. 30 6月, 2008 1 次提交
  35. 01 4月, 2008 1 次提交
  37. 31 3月, 2008 1 次提交
  39. 21 1月, 2008 1 次提交
  41. 20 10月, 2007 1 次提交
  43. 14 10月, 2007 1 次提交
  45. 13 10月, 2007 1 次提交
  47. 30 8月, 2007 1 次提交
  49. 01 8月, 2007 1 次提交
  51. 10 7月, 2007 1 次提交
  53. 04 6月, 2007 1 次提交
    • D
      Input: reduce raciness when input handlers disconnect · 1dfa2812
      由 Dmitry Torokhov 提交于 
      There is a race between input handler's release() and disconnect()
methods: when input handler disconnects it wakes up all regular
users and then process to walk user list to wake up async. users.
While disconnect() walks the list release() removes elements of
the same list causing oopses.

While this is not a substibute for proper locking we can reduce
odds of getting an oops if we wake up normal readers after walking
the list.
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
      1dfa2812
  55. 12 5月, 2007 1 次提交
  57. 09 5月, 2007 1 次提交
  59. 03 5月, 2007 2 次提交
  61. 12 4月, 2007 3 次提交
  63. 15 3月, 2007 1 次提交
  65. 14 9月, 2006 2 次提交