1. 02 Sep, 2013 4 commits
  2. 26 Aug, 2013 4 commits
  3. 20 Aug, 2013 2 commits
  4. 09 Aug, 2013 1 commit
  5. 05 Aug, 2013 2 commits
  6. 31 Jul, 2013 1 commit
    • Peter Hurley's avatar
      HID: logitech-dj: Fix non-atomic kmalloc in logi_dj_ll_input_event() · ce737368
      Peter Hurley authored
      The ll_driver's .hidinput_input_event() method is called from
      atomic context [1]. Use GFP_ATOMIC for allocation of the
      synthesized hid report.
      
      BUG: sleeping function called from invalid context at /home/peter/src/kernels/next/mm/slub.c:941
      in_atomic(): 1, irqs_disabled(): 1, pid: 2095, name: Xorg
      INFO: lockdep is turned off.
      irq event stamp: 1502178
      hardirqs last  enabled at (1502177): [<ffffffff81785e55>] _raw_spin_unlock_irqrestore+0x65/0x80
      hardirqs last disabled at (1502178): [<ffffffff8178632a>] common_interrupt+0x6a/0x6f
      softirqs last  enabled at (1501802): [<ffffffff81051ed3>] __do_softirq+0x183/0x420
      softirqs last disabled at (1501799): [<ffffffff81052315>] irq_exit+0xb5/0xc0
      CPU: 3 PID: 2095 Comm: Xorg Not tainted 3.11-next-20130725-xeon+lockdep #20130725
      Hardware name: Dell Inc. Precision WorkStation T5400  /0RW203, BIOS A11 04/30/2012
       ffffffff81a662e0 ffff8802adcf9ca8 ffffffff8177c330 0000000000000000
       ffff8802a76d2440 ffff8802adcf9cd8 ffffffff810867d0 ffff8802a7ac8000
       0000000000000010 00000000ffffffff 00000000000000d0 ffff8802adcf9d38
      Call Trace:
       [<ffffffff8177c330>] dump_stack+0x4f/0x84
       [<ffffffff810867d0>] __might_sleep+0x140/0x1f0
       [<ffffffff811ad93b>] __kmalloc+0x6b/0x2e0
       [<ffffffffa026cb08>] ? hid_alloc_report_buf+0x28/0x30 [hid]
       [<ffffffffa026cb08>] hid_alloc_report_buf+0x28/0x30 [hid]
       [<ffffffffa00700b0>] logi_dj_ll_input_event+0xb0/0x1b0 [hid_logitech_dj]
       [<ffffffff815a559e>] input_handle_event+0x8e/0x540
       [<ffffffff815a5aad>] ? input_inject_event+0x5d/0x220
       [<ffffffff815a5c10>] input_inject_event+0x1c0/0x220
       [<ffffffff815a5a94>] ? input_inject_event+0x44/0x220
       [<ffffffff81181660>] ? might_fault+0xa0/0xb0
       [<ffffffff81181617>] ? might_fault+0x57/0xb0
       [<ffffffff815a909e>] evdev_write+0xde/0x160
       [<ffffffff811c0ad8>] vfs_write+0xc8/0x1f0
       [<ffffffff811c0fe5>] SyS_write+0x55/0xa0
       [<ffffffff8178e682>] system_call_fastpath+0x16/0x1b
      Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      ce737368
  7. 29 Jul, 2013 1 commit
  8. 23 Jul, 2013 1 commit
  9. 22 Jul, 2013 2 commits
    • Jiri Kosina's avatar
      HID: fix unused rsize usage · bc197eed
      Jiri Kosina authored
      27ce4050 ("HID: fix data access in implement()") by mistake removed
      a setting of buffer size in hidp. Fix that by putting it back.
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      bc197eed
    • Jiri Kosina's avatar
      HID: fix data access in implement() · 27ce4050
      Jiri Kosina authored
      implement() is setting bytes in LE data stream. In case the data is not
      aligned to 64bits, it reads past the allocated buffer. It doesn't really
      change any value there (it's properly bitmasked), but in case that this
      read past the boundary hits a page boundary, pagefault happens when
      accessing 64bits of 'x' in implement(), and kernel oopses.
      
      This happens much more often when numbered reports are in use, as the
      initial 8bit skip in the buffer makes the whole process work on values
      which are not aligned to 64bits.
      
      This problem dates back to attempts in 2005 and 2006 to make implement()
      and extract() as generic as possible, and even back then the problem
      was realized by Adam Kroperlin, but falsely assumed to be impossible
      to cause any harm:
      
        http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg47690.html
      
      I have made several attempts at fixing it "on the spot" directly in
      implement(), but the results were horrible; the special casing for processing
      last 64bit chunk and switching to different math makes it unreadable mess.
      
      I therefore took a path to allocate a few bytes more which will never make
      it into final report, but are there as a cushion for all the 64bit math
      operations happening in implement() and extract().
      
      All callers of hid_output_report() are converted at the same time to allocate
      the buffer by newly introduced hid_alloc_report_buf() helper.
      
      Bruno noticed that the whole raw_size test can be dropped as well, as
      hid_alloc_report_buf() makes sure that the buffer is always of a proper
      size.
      Reviewed-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Acked-by: default avatarGustavo Padovan <gustavo.padovan@collabora.co.uk>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      27ce4050
  10. 15 Jul, 2013 1 commit
  11. 12 Jul, 2013 1 commit
  12. 04 Jul, 2013 20 commits