1. 24 Apr, 2008 6 commits
  2. 15 Apr, 2008 8 commits
  3. 04 Apr, 2008 2 commits
  4. 03 Apr, 2008 9 commits
  5. 02 Apr, 2008 11 commits
  6. 01 Apr, 2008 2 commits
  7. 30 Mar, 2008 2 commits
    • Mark Lord's avatar
      fix uevent action-string regression · a9edadbf
      Mark Lord authored
      Mark Lord wrote:
      >
      > On boot, syslog is flooded with "uevent: unsupported action-string;" messages.
      ..
      > Mar 28 14:43:29 shrimp kernel: tty ptyqd: uevent: unsupported
      > action-string; this will be ignored in a future kernel version
      > Mar 28 14:43:29 shrimp kernel: tty ptyqe: uevent: unsupported
      > action-string; this will be ignored in a future kernel version
      > Mar 28 14:43:29 shrimp kernel: tty ptyqf: uevent: unsupported
      > action-string; this will be ignored in a future kernel version
      > Mar 28 14:43:29 shrimp kernel: tty ptyr0: uevent: unsupported
      > action-string; this will be ignored in a future kernel version
      ..
      
      These messages are a regression compared with 2.6.24, which did not
      flood the syslog with them.
      
      The actual underlying problem was introduced in 2.6.23, when somebody
      made the string parsing no longer accept nul-terminated strings as a
      valid input to store_uevent().
      
      Eg.  "add\0" was valid prior to 2.6.23, where the code regressed to
      require "add" without the '\0'.
      
      This patch fixes the 2.6.23 / 2.6.24 regressions, by having the code
      once again tolerate the trailing '\0', if present.
      
      According to GregKH, this mainly affects older Ubuntu systems, such as
      the one I have here that requires this fix.
      Signed-off-by: default avatarMark Lord <mlord@pobox.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a9edadbf
    • Björn Steinbrink's avatar
      evdev: Release eventual input device grabs when getting disconnected · eb08b6b9
      Björn Steinbrink authored
      When getting disconnected we need to release eventual grabs on the
      underlying input device as we also release the input device itself.
      Otherwise, we would try to release the grab when the client that
      requested it closes its handle, accessing the input device which
      might already be freed.
      Signed-off-by: default avatarBjörn Steinbrink <B.Steinbrink@gmx.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      eb08b6b9