Skip to content

L
linux
Switch branch/tag
  1. 22 Aug, 2016 3 commits
    • Javier Martinez Canillas's avatar
      s5p-mfc: Set device name for reserved memory region devs · 7cc9ce02
      Javier Martinez Canillas authored 
      [ Upstream commit 29debab0 ]

The devices don't have a name set, so makes dev_name() returns NULL which
makes harder to identify the devices that are causing issues, for example:

WARNING: CPU: 2 PID: 616 at drivers/base/core.c:251 device_release+0x8c/0x90
Device '(null)' does not have a release() function, it is broken and must be fixed.

And after setting the device name:

WARNING: CPU: 0 PID: 591 at drivers/base/core.c:251 device_release+0x8c/0x90
Device 's5p-mfc-l' does not have a release() function, it is broken and must be fixed.

Cc: <stable@vger.kernel.org>
Fixes: 6e83e6e2 ("[media] s5p-mfc: Fix kernel warning on memory init")
Signed-off-by: default avatarJavier Martinez Canillas <javier@osg.samsung.com>
Tested-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: default avatarSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      7cc9ce02
    • Roderick Colenbrander's avatar
      HID: uhid: fix timeout when probe races with IO · 8f8b0fea
      Roderick Colenbrander authored 
      [ Upstream commit 67f8ecc5 ]

Many devices use userspace bluetooth stacks like BlueZ or Bluedroid in combination
with uhid. If any of these stacks is used with a HID device for which the driver
performs a HID request as part .probe (or technically another HID operation),
this results in a deadlock situation. The deadlock results in a 5 second timeout
for I/O operations in HID drivers, so isn't fatal, but none of the I/O operations
have a chance of succeeding.

The root cause for the problem is that uhid only allows for one request to be
processed at a time per uhid instance and locks out other operations. This means
that if a user space is creating a new HID device through 'UHID_CREATE', which
ultimately triggers '.probe' through the HID layer. Then any HID request e.g. a
read for calibration data would trigger a HID operation on uhid again, but it
won't go out to userspace, because it is still stuck in UHID_CREATE.
In addition bluetooth stacks are typically single threaded, so they wouldn't be
able to handle any requests while waiting on uhid.

Lucikly the UHID spec is somewhat flexible and allows for fixing the issue,
without breaking user space. The idea which the patch implements as discussed
with David Herrmann is to decouple adding of a hid device (which triggers .probe)
from UHID_CREATE. The work will kick off roughly once UHID_CREATE completed (or
else will wait a tiny bit of time in .probe for a lock). A HID driver has to call
HID to call 'hid_hw_start()' as part of .probe once it is ready for I/O, which
triggers UHID_START to user space. Any HID operations should function now within
.probe and won't deadlock because userspace is stuck on UHID_CREATE.

We verified this patch on Bluedroid with Android 6.0 and on desktop Linux with
BlueZ stacks. Prior to the patch they had the deadlock issue.

[jkosina@suse.cz: reword subject]
Signed-off-by: default avatarRoderick Colenbrander <roderick.colenbrander@sony.com>
Cc: stable@vger.kernel.org
Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      8f8b0fea
    • Sasha Levin's avatar
      Revert "drm/i915/ilk: Don't disable SSC source if it's in use" · 43ba1649
      Sasha Levin authored 
      This reverts commit bcb66592.
Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      43ba1649
  3. 09 Aug, 2016 1 commit
  5. 08 Aug, 2016 23 commits
  7. 03 Aug, 2016 1 commit
    • Florian Westphal's avatar
      netfilter: x_tables: speed up jump target validation · f5bba514
      Florian Westphal authored 
      [ Upstream commit f4dc7771 ]

The dummy ruleset I used to test the original validation change was broken,
most rules were unreachable and were not tested by mark_source_chains().

In some cases rulesets that used to load in a few seconds now require
several minutes.

sample ruleset that shows the behaviour:

echo "*filter"
for i in $(seq 0 100000);do
        printf ":chain_%06x - [0:0]\n" $i
done
for i in $(seq 0 100000);do
   printf -- "-A INPUT -j chain_%06x\n" $i
   printf -- "-A INPUT -j chain_%06x\n" $i
   printf -- "-A INPUT -j chain_%06x\n" $i
done
echo COMMIT

[ pipe result into iptables-restore ]

This ruleset will be about 74mbyte in size, with ~500k searches
though all 500k[1] rule entries. iptables-restore will take forever
(gave up after 10 minutes)

Instead of always searching the entire blob for a match, fill an
array with the start offsets of every single ipt_entry struct,
then do a binary search to check if the jump target is present or not.

After this change ruleset restore times get again close to what one
gets when reverting 36472341 (~3 seconds on my workstation).

[1] every user-defined rule gets an implicit RETURN, so we get
300k jumps + 100k userchains + 100k returns -> 500k rule entries

Fixes: 36472341 ("netfilter: x_tables: validate targets of jumps")
Reported-by: default avatarJeff Wu <wujiafu@gmail.com>
Tested-by: default avatarJeff Wu <wujiafu@gmail.com>
Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      f5bba514
  9. 01 Aug, 2016 2 commits
  11. 30 Jul, 2016 1 commit
  13. 20 Jul, 2016 9 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7