1. 25 Aug, 2013 1 commit
  2. 15 Aug, 2013 3 commits
  3. 13 Aug, 2013 15 commits
  4. 07 Jul, 2013 2 commits
  5. 03 Jul, 2013 2 commits
  6. 01 Jul, 2013 5 commits
  7. 28 Jun, 2013 2 commits
  8. 19 Jun, 2013 5 commits
  9. 13 Jun, 2013 1 commit
  10. 10 Jun, 2013 1 commit
    • David Herrmann's avatar
      Input: evdev - flush queues during EVIOCGKEY-like ioctls · 48318028
      David Herrmann authored
      If userspace requests current KEY-state, they very likely assume that no
      such events are pending in the output queue of the evdev device.
      Otherwise, they will parse events which they already handled via
      EVIOCGKEY(). For XKB applications this can cause irreversible keyboard
      states if a modifier is locked multiple times because a CTRL-DOWN event is
      handled once via EVIOCGKEY() and once from the queue via read(), even
      though it should handle it only once.
      
      Therefore, lets do the only logical thing and flush the evdev queue
      atomically during this ioctl. We only flush events that are affected by
      the given ioctl.
      
      This only affects boolean events like KEY, SND, SW and LED. ABS, REL and
      others are not affected as duplicate events can be handled gracefully by
      user-space.
      
      Note: This actually breaks semantics of the evdev ABI. However,
      investigations showed that userspace already expects the new semantics and
      we end up fixing at least all XKB applications.
      All applications that are aware of this race-condition mirror the KEY
      state for each open-file and detect/drop duplicate events. Hence, they do
      not care whether duplicates are posted or not and work fine with this fix.
      
      Also note that we need proper locking to guarantee atomicity and avoid
      dead-locks. event_lock must be locked before queue_lock (see input-core).
      However, we can safely release event_lock while flushing the queue. This
      allows the input-core to proceed with pending events and only stop if it
      needs our queue_lock to post new events.
      This should guarantee that we don't block event-dispatching for too long
      while flushing a single event queue.
      Signed-off-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
      Acked-by: default avatarPeter Hutterer <peter.hutterer@who-t.net>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      48318028
  11. 09 Jun, 2013 2 commits
    • Linus Torvalds's avatar
      Linux 3.10-rc5 · 317ddd25
      Linus Torvalds authored
      317ddd25
    • Mikulas Patocka's avatar
      hpfs: fix warnings when the filesystem fills up · bbd465df
      Mikulas Patocka authored
      This patch fixes warnings due to missing lock on write error path.
      
        WARNING: at fs/hpfs/hpfs_fn.h:353 hpfs_truncate+0x75/0x80 [hpfs]()
        Hardware name: empty
        Pid: 26563, comm: dd Tainted: P           O 3.9.4 #12
        Call Trace:
          hpfs_truncate+0x75/0x80 [hpfs]
          hpfs_write_begin+0x84/0x90 [hpfs]
          _hpfs_bmap+0x10/0x10 [hpfs]
          generic_file_buffered_write+0x121/0x2c0
          __generic_file_aio_write+0x1c7/0x3f0
          generic_file_aio_write+0x7c/0x100
          do_sync_write+0x98/0xd0
          hpfs_file_write+0xd/0x50 [hpfs]
          vfs_write+0xa2/0x160
          sys_write+0x51/0xa0
          page_fault+0x22/0x30
          system_call_fastpath+0x1a/0x1f
      Signed-off-by: default avatarMikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
      Cc: stable@kernel.org  # 2.6.39+
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      bbd465df
  12. 08 Jun, 2013 1 commit
    • Linus Torvalds's avatar
      Merge branch 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 81db4dbf
      Linus Torvalds authored
      Pull timer fixes from Thomas Gleixner:
      
       - Trivial: unused variable removal
      
       - Posix-timers: Add the clock ID to the new proc interface to make it
         useful.  The interface is new and should be functional when we reach
         the final 3.10 release.
      
       - Cure a false positive warning in the tick code introduced by the
         overhaul in 3.10
      
       - Fix for a persistent clock detection regression introduced in this
         cycle
      
      * 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        timekeeping: Correct run-time detection of persistent_clock.
        ntp: Remove unused variable flags in __hardpps
        posix-timers: Show clock ID in proc file
        tick: Cure broadcast false positive pending bit warning
      81db4dbf