Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Merge pull request #1 from torvalds/master #130

Closed
wants to merge 1 commit into from
Closed

Merge pull request #1 from torvalds/master #130

wants to merge 1 commit into from

Conversation

dabrace
Copy link

@dabrace dabrace commented Oct 29, 2014

Sync as of 10272014

@dabrace dabrace closed this Oct 29, 2014
0day-ci pushed a commit to 0day-ci/linux that referenced this pull request Nov 19, 2015
@akpm00 @sfrothwell
account-certain-kmem-allocations-to-memcg-checkpatch-fixes
726e2a1 
CHECK: spaces preferred around that '|' (ctx:VxV)
torvalds#130: FILE: drivers/staging/lustre/lustre/llite/super25.c:109:
+					    0, SLAB_HWCACHE_ALIGN|SLAB_ACCOUNT,
 					                         ^

ERROR: code indent should use tabs where possible
torvalds#456: FILE: fs/gfs2/main.c:115:
+^I^I^I^I^I          SLAB_MEM_SPREAD|$

CHECK: spaces preferred around that '|' (ctx:VxV)
torvalds#1012: FILE: net/sunrpc/rpc_pipe.c:1503:
+						SLAB_MEM_SPREAD|SLAB_ACCOUNT),
 						               ^

total: 1 errors, 0 warnings, 2 checks, 640 lines checked

NOTE: Whitespace errors detected.
      You may wish to use scripts/cleanpatch or scripts/cleanfile

./patches/account-certain-kmem-allocations-to-memcg.patch has style problems, please review.

NOTE: If any of the errors are false positives, please report
      them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Vladimir Davydov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
0day-ci pushed a commit to 0day-ci/linux that referenced this pull request Nov 26, 2015
@akpm00 @sfrothwell
account-certain-kmem-allocations-to-memcg-checkpatch-fixes
79f80ac 
CHECK: spaces preferred around that '|' (ctx:VxV)
torvalds#130: FILE: drivers/staging/lustre/lustre/llite/super25.c:109:
+					    0, SLAB_HWCACHE_ALIGN|SLAB_ACCOUNT,
 					                         ^

ERROR: code indent should use tabs where possible
torvalds#456: FILE: fs/gfs2/main.c:115:
+^I^I^I^I^I          SLAB_MEM_SPREAD|$

CHECK: spaces preferred around that '|' (ctx:VxV)
torvalds#1012: FILE: net/sunrpc/rpc_pipe.c:1503:
+						SLAB_MEM_SPREAD|SLAB_ACCOUNT),
 						               ^

total: 1 errors, 0 warnings, 2 checks, 640 lines checked

NOTE: Whitespace errors detected.
      You may wish to use scripts/cleanpatch or scripts/cleanfile

./patches/account-certain-kmem-allocations-to-memcg.patch has style problems, please review.

NOTE: If any of the errors are false positives, please report
      them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Vladimir Davydov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
0day-ci pushed a commit to 0day-ci/linux that referenced this pull request Dec 4, 2015
@akpm00 @broonie
account-certain-kmem-allocations-to-memcg-checkpatch-fixes
9565b94 
CHECK: spaces preferred around that '|' (ctx:VxV)
torvalds#130: FILE: drivers/staging/lustre/lustre/llite/super25.c:109:
+					    0, SLAB_HWCACHE_ALIGN|SLAB_ACCOUNT,
 					                         ^

ERROR: code indent should use tabs where possible
torvalds#456: FILE: fs/gfs2/main.c:115:
+^I^I^I^I^I          SLAB_MEM_SPREAD|$

CHECK: spaces preferred around that '|' (ctx:VxV)
torvalds#1012: FILE: net/sunrpc/rpc_pipe.c:1503:
+						SLAB_MEM_SPREAD|SLAB_ACCOUNT),
 						               ^

total: 1 errors, 0 warnings, 2 checks, 640 lines checked

NOTE: Whitespace errors detected.
      You may wish to use scripts/cleanpatch or scripts/cleanfile

./patches/account-certain-kmem-allocations-to-memcg.patch has style problems, please review.

NOTE: If any of the errors are false positives, please report
      them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Vladimir Davydov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
0day-ci pushed a commit to 0day-ci/linux that referenced this pull request Dec 7, 2015
@akpm00 @sfrothwell
account-certain-kmem-allocations-to-memcg-checkpatch-fixes
8d06d91 
CHECK: spaces preferred around that '|' (ctx:VxV)
torvalds#130: FILE: drivers/staging/lustre/lustre/llite/super25.c:109:
+					    0, SLAB_HWCACHE_ALIGN|SLAB_ACCOUNT,
 					                         ^

ERROR: code indent should use tabs where possible
torvalds#456: FILE: fs/gfs2/main.c:115:
+^I^I^I^I^I          SLAB_MEM_SPREAD|$

CHECK: spaces preferred around that '|' (ctx:VxV)
torvalds#1012: FILE: net/sunrpc/rpc_pipe.c:1503:
+						SLAB_MEM_SPREAD|SLAB_ACCOUNT),
 						               ^

total: 1 errors, 0 warnings, 2 checks, 640 lines checked

NOTE: Whitespace errors detected.
      You may wish to use scripts/cleanpatch or scripts/cleanfile

./patches/account-certain-kmem-allocations-to-memcg.patch has style problems, please review.

NOTE: If any of the errors are false positives, please report
      them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Vladimir Davydov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
0day-ci pushed a commit to 0day-ci/linux that referenced this pull request Dec 9, 2015
@akpm00 @sfrothwell
account-certain-kmem-allocations-to-memcg-checkpatch-fixes
2f5d91f 
CHECK: spaces preferred around that '|' (ctx:VxV)
torvalds#130: FILE: drivers/staging/lustre/lustre/llite/super25.c:109:
+					    0, SLAB_HWCACHE_ALIGN|SLAB_ACCOUNT,
 					                         ^

ERROR: code indent should use tabs where possible
torvalds#456: FILE: fs/gfs2/main.c:115:
+^I^I^I^I^I          SLAB_MEM_SPREAD|$

CHECK: spaces preferred around that '|' (ctx:VxV)
torvalds#1012: FILE: net/sunrpc/rpc_pipe.c:1503:
+						SLAB_MEM_SPREAD|SLAB_ACCOUNT),
 						               ^

total: 1 errors, 0 warnings, 2 checks, 640 lines checked

NOTE: Whitespace errors detected.
      You may wish to use scripts/cleanpatch or scripts/cleanfile

./patches/account-certain-kmem-allocations-to-memcg.patch has style problems, please review.

NOTE: If any of the errors are false positives, please report
      them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Vladimir Davydov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
ddstreet pushed a commit to ddstreet/linux that referenced this pull request Dec 10, 2015
@akpm00 @hnaz
account-certain-kmem-allocations-to-memcg-checkpatch-fixes
9603cf6 
CHECK: spaces preferred around that '|' (ctx:VxV)
torvalds#130: FILE: drivers/staging/lustre/lustre/llite/super25.c:109:
+					    0, SLAB_HWCACHE_ALIGN|SLAB_ACCOUNT,
 					                         ^

ERROR: code indent should use tabs where possible
torvalds#456: FILE: fs/gfs2/main.c:115:
+^I^I^I^I^I          SLAB_MEM_SPREAD|$

CHECK: spaces preferred around that '|' (ctx:VxV)
torvalds#1012: FILE: net/sunrpc/rpc_pipe.c:1503:
+						SLAB_MEM_SPREAD|SLAB_ACCOUNT),
 						               ^

total: 1 errors, 0 warnings, 2 checks, 640 lines checked

NOTE: Whitespace errors detected.
      You may wish to use scripts/cleanpatch or scripts/cleanfile

./patches/account-certain-kmem-allocations-to-memcg.patch has style problems, please review.

NOTE: If any of the errors are false positives, please report
      them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Vladimir Davydov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
0day-ci pushed a commit to 0day-ci/linux that referenced this pull request Dec 11, 2015
@akpm00 @sfrothwell
account-certain-kmem-allocations-to-memcg-checkpatch-fixes
2961772 
CHECK: spaces preferred around that '|' (ctx:VxV)
torvalds#130: FILE: drivers/staging/lustre/lustre/llite/super25.c:109:
+					    0, SLAB_HWCACHE_ALIGN|SLAB_ACCOUNT,
 					                         ^

ERROR: code indent should use tabs where possible
torvalds#456: FILE: fs/gfs2/main.c:115:
+^I^I^I^I^I          SLAB_MEM_SPREAD|$

CHECK: spaces preferred around that '|' (ctx:VxV)
torvalds#1012: FILE: net/sunrpc/rpc_pipe.c:1503:
+						SLAB_MEM_SPREAD|SLAB_ACCOUNT),
 						               ^

total: 1 errors, 0 warnings, 2 checks, 640 lines checked

NOTE: Whitespace errors detected.
      You may wish to use scripts/cleanpatch or scripts/cleanfile

./patches/account-certain-kmem-allocations-to-memcg.patch has style problems, please review.

NOTE: If any of the errors are false positives, please report
      them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Vladimir Davydov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
ddstreet pushed a commit to ddstreet/linux that referenced this pull request Dec 11, 2015
@akpm00 @hnaz
account-certain-kmem-allocations-to-memcg-checkpatch-fixes
349ddd2 
CHECK: spaces preferred around that '|' (ctx:VxV)
torvalds#130: FILE: drivers/staging/lustre/lustre/llite/super25.c:109:
+					    0, SLAB_HWCACHE_ALIGN|SLAB_ACCOUNT,
 					                         ^

ERROR: code indent should use tabs where possible
torvalds#456: FILE: fs/gfs2/main.c:115:
+^I^I^I^I^I          SLAB_MEM_SPREAD|$

CHECK: spaces preferred around that '|' (ctx:VxV)
torvalds#1012: FILE: net/sunrpc/rpc_pipe.c:1503:
+						SLAB_MEM_SPREAD|SLAB_ACCOUNT),
 						               ^

total: 1 errors, 0 warnings, 2 checks, 640 lines checked

NOTE: Whitespace errors detected.
      You may wish to use scripts/cleanpatch or scripts/cleanfile

./patches/account-certain-kmem-allocations-to-memcg.patch has style problems, please review.

NOTE: If any of the errors are false positives, please report
      them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Vladimir Davydov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
0day-ci pushed a commit to 0day-ci/linux that referenced this pull request Dec 18, 2015
@akpm00 @sfrothwell
account-certain-kmem-allocations-to-memcg-checkpatch-fixes
0c0b379 
CHECK: spaces preferred around that '|' (ctx:VxV)
torvalds#130: FILE: drivers/staging/lustre/lustre/llite/super25.c:109:
+					    0, SLAB_HWCACHE_ALIGN|SLAB_ACCOUNT,
 					                         ^

ERROR: code indent should use tabs where possible
torvalds#456: FILE: fs/gfs2/main.c:115:
+^I^I^I^I^I          SLAB_MEM_SPREAD|$

CHECK: spaces preferred around that '|' (ctx:VxV)
torvalds#1012: FILE: net/sunrpc/rpc_pipe.c:1503:
+						SLAB_MEM_SPREAD|SLAB_ACCOUNT),
 						               ^

total: 1 errors, 0 warnings, 2 checks, 640 lines checked

NOTE: Whitespace errors detected.
      You may wish to use scripts/cleanpatch or scripts/cleanfile

./patches/account-certain-kmem-allocations-to-memcg.patch has style problems, please review.

NOTE: If any of the errors are false positives, please report
      them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Vladimir Davydov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
0day-ci pushed a commit to 0day-ci/linux that referenced this pull request Jan 1, 2016
@akpm00 @sfrothwell
account-certain-kmem-allocations-to-memcg-checkpatch-fixes
c12f107 
CHECK: spaces preferred around that '|' (ctx:VxV)
torvalds#130: FILE: drivers/staging/lustre/lustre/llite/super25.c:109:
+					    0, SLAB_HWCACHE_ALIGN|SLAB_ACCOUNT,
 					                         ^

ERROR: code indent should use tabs where possible
torvalds#456: FILE: fs/gfs2/main.c:115:
+^I^I^I^I^I          SLAB_MEM_SPREAD|$

CHECK: spaces preferred around that '|' (ctx:VxV)
torvalds#1012: FILE: net/sunrpc/rpc_pipe.c:1503:
+						SLAB_MEM_SPREAD|SLAB_ACCOUNT),
 						               ^

total: 1 errors, 0 warnings, 2 checks, 640 lines checked

NOTE: Whitespace errors detected.
      You may wish to use scripts/cleanpatch or scripts/cleanfile

./patches/account-certain-kmem-allocations-to-memcg.patch has style problems, please review.

NOTE: If any of the errors are false positives, please report
      them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Vladimir Davydov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
0day-ci pushed a commit to 0day-ci/linux that referenced this pull request Jan 6, 2016
@akpm00 @sfrothwell
account-certain-kmem-allocations-to-memcg-checkpatch-fixes
748a8cc 
CHECK: spaces preferred around that '|' (ctx:VxV)
torvalds#130: FILE: drivers/staging/lustre/lustre/llite/super25.c:109:
+					    0, SLAB_HWCACHE_ALIGN|SLAB_ACCOUNT,
 					                         ^

ERROR: code indent should use tabs where possible
torvalds#456: FILE: fs/gfs2/main.c:115:
+^I^I^I^I^I          SLAB_MEM_SPREAD|$

CHECK: spaces preferred around that '|' (ctx:VxV)
torvalds#1012: FILE: net/sunrpc/rpc_pipe.c:1503:
+						SLAB_MEM_SPREAD|SLAB_ACCOUNT),
 						               ^

total: 1 errors, 0 warnings, 2 checks, 640 lines checked

NOTE: Whitespace errors detected.
      You may wish to use scripts/cleanpatch or scripts/cleanfile

./patches/account-certain-kmem-allocations-to-memcg.patch has style problems, please review.

NOTE: If any of the errors are false positives, please report
      them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Vladimir Davydov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
0day-ci pushed a commit to 0day-ci/linux that referenced this pull request Jan 13, 2016
@akpm00 @sfrothwell
account-certain-kmem-allocations-to-memcg-checkpatch-fixes
6419719 
CHECK: spaces preferred around that '|' (ctx:VxV)
torvalds#130: FILE: drivers/staging/lustre/lustre/llite/super25.c:109:
+					    0, SLAB_HWCACHE_ALIGN|SLAB_ACCOUNT,
 					                         ^

ERROR: code indent should use tabs where possible
torvalds#456: FILE: fs/gfs2/main.c:115:
+^I^I^I^I^I          SLAB_MEM_SPREAD|$

CHECK: spaces preferred around that '|' (ctx:VxV)
torvalds#1012: FILE: net/sunrpc/rpc_pipe.c:1503:
+						SLAB_MEM_SPREAD|SLAB_ACCOUNT),
 						               ^

total: 1 errors, 0 warnings, 2 checks, 640 lines checked

NOTE: Whitespace errors detected.
      You may wish to use scripts/cleanpatch or scripts/cleanfile

./patches/account-certain-kmem-allocations-to-memcg.patch has style problems, please review.

NOTE: If any of the errors are false positives, please report
      them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Vladimir Davydov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
0day-ci pushed a commit to 0day-ci/linux that referenced this pull request Sep 21, 2016
@ickle
drm/i915: Only shrink the unbound objects during freeze
3bc78c5 
At the point of creating the hibernation image, the runtime power manage
core is disabled - and using the rpm functions triggers a warn.
i915_gem_shrink_all() tries to unbind objects, which requires device
access and so tries to how an rpm reference triggering a warning:

[   44.235420] ------------[ cut here ]------------
[   44.235424] WARNING: CPU: 2 PID: 2199 at drivers/gpu/drm/i915/intel_runtime_pm.c:2688 intel_runtime_pm_get_if_in_use+0xe6/0xf0
[   44.235426] WARN_ON_ONCE(ret < 0)
[   44.235445] Modules linked in: ctr ccm arc4 rt2800usb rt2x00usb rt2800lib rt2x00lib crc_ccitt mac80211 cmac cfg80211 btusb rfcomm bnep btrtl btbcm btintel bluetooth dcdbas x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_codec_realtek crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_generic aesni_intel snd_hda_codec_hdmi aes_x86_64 lrw gf128mul snd_hda_intel glue_helper ablk_helper cryptd snd_hda_codec hid_multitouch joydev snd_hda_core binfmt_misc i2c_hid serio_raw snd_pcm acpi_pad snd_timer snd i2c_designware_platform 8250_dw nls_iso8859_1 i2c_designware_core lpc_ich mfd_core soundcore usbhid hid psmouse ahci libahci
[   44.235447] CPU: 2 PID: 2199 Comm: kworker/u8:8 Not tainted 4.8.0-rc5+ torvalds#130
[   44.235447] Hardware name: Dell Inc. XPS 13 9343/0310JH, BIOS A07 11/11/2015
[   44.235450] Workqueue: events_unbound async_run_entry_fn
[   44.235453]  0000000000000000 ffff8801b2f7fb98 ffffffff81306c2f ffff8801b2f7fbe8
[   44.235454]  0000000000000000 ffff8801b2f7fbd8 ffffffff81056c01 00000a801f50ecc0
[   44.235456]  ffff88020ce50000 ffff88020ce59b60 ffffffff81a60b5c ffffffff81414840
[   44.235456] Call Trace:
[   44.235459]  [<ffffffff81306c2f>] dump_stack+0x4d/0x6e
[   44.235461]  [<ffffffff81056c01>] __warn+0xd1/0xf0
[   44.235464]  [<ffffffff81414840>] ? i915_pm_suspend_late+0x30/0x30
[   44.235465]  [<ffffffff81056c6f>] warn_slowpath_fmt+0x4f/0x60
[   44.235468]  [<ffffffff814e73ce>] ? pm_runtime_get_if_in_use+0x6e/0xa0
[   44.235469]  [<ffffffff81433526>] intel_runtime_pm_get_if_in_use+0xe6/0xf0
[   44.235471]  [<ffffffff81458a26>] i915_gem_shrink+0x306/0x360
[   44.235473]  [<ffffffff81343fd4>] ? pci_platform_power_transition+0x24/0x90
[   44.235475]  [<ffffffff81414840>] ? i915_pm_suspend_late+0x30/0x30
[   44.235476]  [<ffffffff81458dfb>] i915_gem_shrink_all+0x1b/0x30
[   44.235478]  [<ffffffff814560b3>] i915_gem_freeze_late+0x33/0x90
[   44.235479]  [<ffffffff81414877>] i915_pm_freeze_late+0x37/0x40
[   44.235481]  [<ffffffff814e9b8e>] dpm_run_callback+0x4e/0x130
[   44.235483]  [<ffffffff814ea5db>] __device_suspend_late+0xdb/0x1f0
[   44.235484]  [<ffffffff814ea70f>] async_suspend_late+0x1f/0xa0
[   44.235486]  [<ffffffff81077557>] async_run_entry_fn+0x37/0x150
[   44.235488]  [<ffffffff8106f518>] process_one_work+0x148/0x3f0
[   44.235490]  [<ffffffff8106f8eb>] worker_thread+0x12b/0x490
[   44.235491]  [<ffffffff8106f7c0>] ? process_one_work+0x3f0/0x3f0
[   44.235492]  [<ffffffff81074d09>] kthread+0xc9/0xe0
[   44.235495]  [<ffffffff816e257f>] ret_from_fork+0x1f/0x40
[   44.235496]  [<ffffffff81074c40>] ? kthread_park+0x60/0x60
[   44.235497] ---[ end trace e438706b97c7f132 ]---

Alternatively, to actually shrink everything we have to do so slightly
earlier in the hibernation process.

To keep lockdep silent, we need to take struct_mutex for the shrinker
even though we know that we are the only user during the freeze.

Fixes: 7aab2d5 ("drm/i915: Shrink objects prior to hibernation")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Reviewed-by: Joonas Lahtinen <[email protected]>
0day-ci pushed a commit to 0day-ci/linux that referenced this pull request Sep 21, 2016
@ickle
drm/i915: Only shrink the unbound objects during freeze
6a800ea 
At the point of creating the hibernation image, the runtime power manage
core is disabled - and using the rpm functions triggers a warn.
i915_gem_shrink_all() tries to unbind objects, which requires device
access and so tries to how an rpm reference triggering a warning:

[   44.235420] ------------[ cut here ]------------
[   44.235424] WARNING: CPU: 2 PID: 2199 at drivers/gpu/drm/i915/intel_runtime_pm.c:2688 intel_runtime_pm_get_if_in_use+0xe6/0xf0
[   44.235426] WARN_ON_ONCE(ret < 0)
[   44.235445] Modules linked in: ctr ccm arc4 rt2800usb rt2x00usb rt2800lib rt2x00lib crc_ccitt mac80211 cmac cfg80211 btusb rfcomm bnep btrtl btbcm btintel bluetooth dcdbas x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_codec_realtek crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_generic aesni_intel snd_hda_codec_hdmi aes_x86_64 lrw gf128mul snd_hda_intel glue_helper ablk_helper cryptd snd_hda_codec hid_multitouch joydev snd_hda_core binfmt_misc i2c_hid serio_raw snd_pcm acpi_pad snd_timer snd i2c_designware_platform 8250_dw nls_iso8859_1 i2c_designware_core lpc_ich mfd_core soundcore usbhid hid psmouse ahci libahci
[   44.235447] CPU: 2 PID: 2199 Comm: kworker/u8:8 Not tainted 4.8.0-rc5+ torvalds#130
[   44.235447] Hardware name: Dell Inc. XPS 13 9343/0310JH, BIOS A07 11/11/2015
[   44.235450] Workqueue: events_unbound async_run_entry_fn
[   44.235453]  0000000000000000 ffff8801b2f7fb98 ffffffff81306c2f ffff8801b2f7fbe8
[   44.235454]  0000000000000000 ffff8801b2f7fbd8 ffffffff81056c01 00000a801f50ecc0
[   44.235456]  ffff88020ce50000 ffff88020ce59b60 ffffffff81a60b5c ffffffff81414840
[   44.235456] Call Trace:
[   44.235459]  [<ffffffff81306c2f>] dump_stack+0x4d/0x6e
[   44.235461]  [<ffffffff81056c01>] __warn+0xd1/0xf0
[   44.235464]  [<ffffffff81414840>] ? i915_pm_suspend_late+0x30/0x30
[   44.235465]  [<ffffffff81056c6f>] warn_slowpath_fmt+0x4f/0x60
[   44.235468]  [<ffffffff814e73ce>] ? pm_runtime_get_if_in_use+0x6e/0xa0
[   44.235469]  [<ffffffff81433526>] intel_runtime_pm_get_if_in_use+0xe6/0xf0
[   44.235471]  [<ffffffff81458a26>] i915_gem_shrink+0x306/0x360
[   44.235473]  [<ffffffff81343fd4>] ? pci_platform_power_transition+0x24/0x90
[   44.235475]  [<ffffffff81414840>] ? i915_pm_suspend_late+0x30/0x30
[   44.235476]  [<ffffffff81458dfb>] i915_gem_shrink_all+0x1b/0x30
[   44.235478]  [<ffffffff814560b3>] i915_gem_freeze_late+0x33/0x90
[   44.235479]  [<ffffffff81414877>] i915_pm_freeze_late+0x37/0x40
[   44.235481]  [<ffffffff814e9b8e>] dpm_run_callback+0x4e/0x130
[   44.235483]  [<ffffffff814ea5db>] __device_suspend_late+0xdb/0x1f0
[   44.235484]  [<ffffffff814ea70f>] async_suspend_late+0x1f/0xa0
[   44.235486]  [<ffffffff81077557>] async_run_entry_fn+0x37/0x150
[   44.235488]  [<ffffffff8106f518>] process_one_work+0x148/0x3f0
[   44.235490]  [<ffffffff8106f8eb>] worker_thread+0x12b/0x490
[   44.235491]  [<ffffffff8106f7c0>] ? process_one_work+0x3f0/0x3f0
[   44.235492]  [<ffffffff81074d09>] kthread+0xc9/0xe0
[   44.235495]  [<ffffffff816e257f>] ret_from_fork+0x1f/0x40
[   44.235496]  [<ffffffff81074c40>] ? kthread_park+0x60/0x60
[   44.235497] ---[ end trace e438706b97c7f132 ]---

Alternatively, to actually shrink everything we have to do so slightly
earlier in the hibernation process.

To keep lockdep silent, we need to take struct_mutex for the shrinker
even though we know that we are the only user during the freeze.

Fixes: 7aab2d5 ("drm/i915: Shrink objects prior to hibernation")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Reviewed-by: Joonas Lahtinen <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Oct 10, 2016
@ickle @jnikula
drm/i915: Only shrink the unbound objects during freeze
d12f580 
At the point of creating the hibernation image, the runtime power manage
core is disabled - and using the rpm functions triggers a warn.
i915_gem_shrink_all() tries to unbind objects, which requires device
access and so tries to how an rpm reference triggering a warning:

[   44.235420] ------------[ cut here ]------------
[   44.235424] WARNING: CPU: 2 PID: 2199 at drivers/gpu/drm/i915/intel_runtime_pm.c:2688 intel_runtime_pm_get_if_in_use+0xe6/0xf0
[   44.235426] WARN_ON_ONCE(ret < 0)
[   44.235445] Modules linked in: ctr ccm arc4 rt2800usb rt2x00usb rt2800lib rt2x00lib crc_ccitt mac80211 cmac cfg80211 btusb rfcomm bnep btrtl btbcm btintel bluetooth dcdbas x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_codec_realtek crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_generic aesni_intel snd_hda_codec_hdmi aes_x86_64 lrw gf128mul snd_hda_intel glue_helper ablk_helper cryptd snd_hda_codec hid_multitouch joydev snd_hda_core binfmt_misc i2c_hid serio_raw snd_pcm acpi_pad snd_timer snd i2c_designware_platform 8250_dw nls_iso8859_1 i2c_designware_core lpc_ich mfd_core soundcore usbhid hid psmouse ahci libahci
[   44.235447] CPU: 2 PID: 2199 Comm: kworker/u8:8 Not tainted 4.8.0-rc5+ torvalds#130
[   44.235447] Hardware name: Dell Inc. XPS 13 9343/0310JH, BIOS A07 11/11/2015
[   44.235450] Workqueue: events_unbound async_run_entry_fn
[   44.235453]  0000000000000000 ffff8801b2f7fb98 ffffffff81306c2f ffff8801b2f7fbe8
[   44.235454]  0000000000000000 ffff8801b2f7fbd8 ffffffff81056c01 00000a801f50ecc0
[   44.235456]  ffff88020ce50000 ffff88020ce59b60 ffffffff81a60b5c ffffffff81414840
[   44.235456] Call Trace:
[   44.235459]  [<ffffffff81306c2f>] dump_stack+0x4d/0x6e
[   44.235461]  [<ffffffff81056c01>] __warn+0xd1/0xf0
[   44.235464]  [<ffffffff81414840>] ? i915_pm_suspend_late+0x30/0x30
[   44.235465]  [<ffffffff81056c6f>] warn_slowpath_fmt+0x4f/0x60
[   44.235468]  [<ffffffff814e73ce>] ? pm_runtime_get_if_in_use+0x6e/0xa0
[   44.235469]  [<ffffffff81433526>] intel_runtime_pm_get_if_in_use+0xe6/0xf0
[   44.235471]  [<ffffffff81458a26>] i915_gem_shrink+0x306/0x360
[   44.235473]  [<ffffffff81343fd4>] ? pci_platform_power_transition+0x24/0x90
[   44.235475]  [<ffffffff81414840>] ? i915_pm_suspend_late+0x30/0x30
[   44.235476]  [<ffffffff81458dfb>] i915_gem_shrink_all+0x1b/0x30
[   44.235478]  [<ffffffff814560b3>] i915_gem_freeze_late+0x33/0x90
[   44.235479]  [<ffffffff81414877>] i915_pm_freeze_late+0x37/0x40
[   44.235481]  [<ffffffff814e9b8e>] dpm_run_callback+0x4e/0x130
[   44.235483]  [<ffffffff814ea5db>] __device_suspend_late+0xdb/0x1f0
[   44.235484]  [<ffffffff814ea70f>] async_suspend_late+0x1f/0xa0
[   44.235486]  [<ffffffff81077557>] async_run_entry_fn+0x37/0x150
[   44.235488]  [<ffffffff8106f518>] process_one_work+0x148/0x3f0
[   44.235490]  [<ffffffff8106f8eb>] worker_thread+0x12b/0x490
[   44.235491]  [<ffffffff8106f7c0>] ? process_one_work+0x3f0/0x3f0
[   44.235492]  [<ffffffff81074d09>] kthread+0xc9/0xe0
[   44.235495]  [<ffffffff816e257f>] ret_from_fork+0x1f/0x40
[   44.235496]  [<ffffffff81074c40>] ? kthread_park+0x60/0x60
[   44.235497] ---[ end trace e438706b97c7f132 ]---

Alternatively, to actually shrink everything we have to do so slightly
earlier in the hibernation process.

To keep lockdep silent, we need to take struct_mutex for the shrinker
even though we know that we are the only user during the freeze.

Fixes: 7aab2d5 ("drm/i915: Shrink objects prior to hibernation")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Reviewed-by: Joonas Lahtinen <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit 6a800ea)
Signed-off-by: Jani Nikula <[email protected]>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Oct 10, 2016
@ickle @jnikula
drm/i915: Only shrink the unbound objects during freeze
ec7ce65 
At the point of creating the hibernation image, the runtime power manage
core is disabled - and using the rpm functions triggers a warn.
i915_gem_shrink_all() tries to unbind objects, which requires device
access and so tries to how an rpm reference triggering a warning:

[   44.235420] ------------[ cut here ]------------
[   44.235424] WARNING: CPU: 2 PID: 2199 at drivers/gpu/drm/i915/intel_runtime_pm.c:2688 intel_runtime_pm_get_if_in_use+0xe6/0xf0
[   44.235426] WARN_ON_ONCE(ret < 0)
[   44.235445] Modules linked in: ctr ccm arc4 rt2800usb rt2x00usb rt2800lib rt2x00lib crc_ccitt mac80211 cmac cfg80211 btusb rfcomm bnep btrtl btbcm btintel bluetooth dcdbas x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_codec_realtek crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_generic aesni_intel snd_hda_codec_hdmi aes_x86_64 lrw gf128mul snd_hda_intel glue_helper ablk_helper cryptd snd_hda_codec hid_multitouch joydev snd_hda_core binfmt_misc i2c_hid serio_raw snd_pcm acpi_pad snd_timer snd i2c_designware_platform 8250_dw nls_iso8859_1 i2c_designware_core lpc_ich mfd_core soundcore usbhid hid psmouse ahci libahci
[   44.235447] CPU: 2 PID: 2199 Comm: kworker/u8:8 Not tainted 4.8.0-rc5+ torvalds#130
[   44.235447] Hardware name: Dell Inc. XPS 13 9343/0310JH, BIOS A07 11/11/2015
[   44.235450] Workqueue: events_unbound async_run_entry_fn
[   44.235453]  0000000000000000 ffff8801b2f7fb98 ffffffff81306c2f ffff8801b2f7fbe8
[   44.235454]  0000000000000000 ffff8801b2f7fbd8 ffffffff81056c01 00000a801f50ecc0
[   44.235456]  ffff88020ce50000 ffff88020ce59b60 ffffffff81a60b5c ffffffff81414840
[   44.235456] Call Trace:
[   44.235459]  [<ffffffff81306c2f>] dump_stack+0x4d/0x6e
[   44.235461]  [<ffffffff81056c01>] __warn+0xd1/0xf0
[   44.235464]  [<ffffffff81414840>] ? i915_pm_suspend_late+0x30/0x30
[   44.235465]  [<ffffffff81056c6f>] warn_slowpath_fmt+0x4f/0x60
[   44.235468]  [<ffffffff814e73ce>] ? pm_runtime_get_if_in_use+0x6e/0xa0
[   44.235469]  [<ffffffff81433526>] intel_runtime_pm_get_if_in_use+0xe6/0xf0
[   44.235471]  [<ffffffff81458a26>] i915_gem_shrink+0x306/0x360
[   44.235473]  [<ffffffff81343fd4>] ? pci_platform_power_transition+0x24/0x90
[   44.235475]  [<ffffffff81414840>] ? i915_pm_suspend_late+0x30/0x30
[   44.235476]  [<ffffffff81458dfb>] i915_gem_shrink_all+0x1b/0x30
[   44.235478]  [<ffffffff814560b3>] i915_gem_freeze_late+0x33/0x90
[   44.235479]  [<ffffffff81414877>] i915_pm_freeze_late+0x37/0x40
[   44.235481]  [<ffffffff814e9b8e>] dpm_run_callback+0x4e/0x130
[   44.235483]  [<ffffffff814ea5db>] __device_suspend_late+0xdb/0x1f0
[   44.235484]  [<ffffffff814ea70f>] async_suspend_late+0x1f/0xa0
[   44.235486]  [<ffffffff81077557>] async_run_entry_fn+0x37/0x150
[   44.235488]  [<ffffffff8106f518>] process_one_work+0x148/0x3f0
[   44.235490]  [<ffffffff8106f8eb>] worker_thread+0x12b/0x490
[   44.235491]  [<ffffffff8106f7c0>] ? process_one_work+0x3f0/0x3f0
[   44.235492]  [<ffffffff81074d09>] kthread+0xc9/0xe0
[   44.235495]  [<ffffffff816e257f>] ret_from_fork+0x1f/0x40
[   44.235496]  [<ffffffff81074c40>] ? kthread_park+0x60/0x60
[   44.235497] ---[ end trace e438706b97c7f132 ]---

Alternatively, to actually shrink everything we have to do so slightly
earlier in the hibernation process.

To keep lockdep silent, we need to take struct_mutex for the shrinker
even though we know that we are the only user during the freeze.

Fixes: 7aab2d5 ("drm/i915: Shrink objects prior to hibernation")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Reviewed-by: Joonas Lahtinen <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit 6a800ea)
Signed-off-by: Jani Nikula <[email protected]>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Oct 12, 2016
@hnaz
linux-next
e1639df 
GIT c30b6803063a44ea20460f13d7c3689a66b00eea

commit daeb20167ddb934d4d604b361406dda858dfa0aa
Author: Lorenzo Pieralisi <[email protected]>
Date:   Wed Oct 5 12:25:40 2016 +0100

    MAINTAINERS: Add ARM64-specific ACPI maintainers entry
    
    The ARM64 architecture defines ARM64 specific ACPI bindings to
    configure and set-up arch specific components. To simplify
    code reviews/updates and streamline the maintainership structure
    supporting the arch specific code, a new arm64 directory was created in
    /drivers/acpi, to contain ACPI code that is specific to ARM64
    architecture.
    
    Add the ARM64-specific ACPI maintainers entry in MAINTAINERS for
    the newly created subdirectory and respective code content.
    
    Lorenzo Pieralisi will be in charge of submitting and managing
    the pull requests on behalf of all maintainers listed.
    
    Link: http://lkml.kernel.org/r/[email protected]
    Signed-off-by: Lorenzo Pieralisi <[email protected]>
    Acked-by: Hanjun Guo <[email protected]>
    Acked-by: Will Deacon <[email protected]>
    Acked-by: Sudeep Holla <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>

commit be280b25c3288824ed4c201b452c3e87a7074d7c
Author: Rasmus Villemoes <[email protected]>
Date:   Wed Sep 21 01:17:24 2016 +0200

    ecryptfs: remove private bin2hex implementation
    
    Calling sprintf in a loop is not very efficient, and in any case, we
    already have an implementation of bin-to-hex conversion in lib/ which
    we might as well use.
    
    Note that ecryptfs_to_hex used to nul-terminate the destination (and
    the kernel doc was wrong about the required output size), while
    bin2hex doesn't. [All but one user of ecryptfs_to_hex explicitly
    nul-terminates the result anyway.]
    
    Signed-off-by: Rasmus Villemoes <[email protected]>
    [tyhicks: Include <linux/kernel.h> in ecryptfs_kernel.h]
    Signed-off-by: Tyler Hicks <[email protected]>

commit 8326633b6fe8fc96e53e51351dc41d3314ce2e69
Author: Colin Ian King <[email protected]>
Date:   Tue Sep 27 05:18:02 2016 -0700

    ecryptfs: add missing \n to end of various error messages
    
    Trival fix, some error messages are missing a \n, so add it.
    
    Signed-off-by: Colin Ian King <[email protected]>
    Signed-off-by: Tyler Hicks <[email protected]>

commit a5bd451b6e6ece69be07a425381c4f3438eadba0
Author: Jani Nikula <[email protected]>
Date:   Mon Oct 10 18:26:10 2016 +0300

    drm/crtc: constify drm_crtc_index parameter
    
    Signed-off-by: Jani Nikula <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>
    Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]

commit 105f1a65b04a8f4f7abec11b200b1fb54f3d4b46
Author: Chris Wilson <[email protected]>
Date:   Mon Oct 10 13:50:17 2016 +0100

    drm/i915: Fix conflict resolution from backmerge of v4.8-rc8 to drm-next
    
    The conflict resolution of v4.8-rc8 backmerge to drm-next pulled back in
    a few lines of dead code due to the code movement around
    i915_gem_reset(), fix that up.
    
    Fixes: ca09fb9f60b5 ("Merge tag 'v4.8-rc8' into drm-next")
    Signed-off-by: Chris Wilson <[email protected]>
    Cc: Jani Nikula <[email protected]>
    Cc: Daniel Vetter <[email protected]>
    Cc: Dave Airlie <[email protected]>
    Signed-off-by: Jani Nikula <[email protected]>
    Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]

commit f59c668c0b898bbeba7179cd34e38a53e2f86c42
Author: Shuah Khan <[email protected]>
Date:   Thu Oct 6 16:12:29 2016 -0600

    Doc: update 00-INDEX files to reflect the runnable code move
    
    Update 00-INDEX files with the current file list to reflect the runnable
    code move.
    
    Acked-by: Michal Marek <[email protected]>
    Acked-by: Jonathan Corbet <[email protected]>
    Reviewed-by: Kees Cook <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>

commit 184892925118d924aa9304b466946ae18c029932
Author: Shuah Khan <[email protected]>
Date:   Thu Oct 6 16:00:50 2016 -0600

    samples: move blackfin gptimers-example from Documentation
    
    Move blackfin gptimers-example to samples and remove it from Documentation
    Makefile. Update samples Kconfig and Makefile to build gptimers-example.
    
    blackfin is the last CONFIG_BUILD_DOCSRC target in Documentation/Makefile.
    Hence this patch also includes changes to remove CONFIG_BUILD_DOCSRC from
    Makefile and lib/Kconfig.debug and updates VIDEO_PCI_SKELETON dependency
    on BUILD_DOCSRC.
    
    Documentation/Makefile is not deleted to avoid braking make htmldocs and
    make distclean.
    
    Acked-by: Michal Marek <[email protected]>
    Acked-by: Jonathan Corbet <[email protected]>
    Reviewed-by: Kees Cook <[email protected]>
    Reported-by: Valentin Rothberg <[email protected]>
    Reported-by: Paul Gortmaker <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>

commit 449f6615473db3a0d16cbafcbe0572ef81872db0
Author: Chris Wilson <[email protected]>
Date:   Fri Oct 7 07:53:27 2016 +0100

    drm/i915/guc: Unwind GuC workqueue reservation if request construction fails
    
    We reserve space in the GuC workqueue for submitting the request in the
    future. However, if we fail to construct the request, we need to give
    that reserved space back to the system.
    
    Fixes: dadd481bfe55 ("drm/i915/guc: Prepare for nonblocking execbuf submission")
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97978
    Signed-off-by: Chris Wilson <[email protected]>
    Cc: Michał Winiarski <[email protected]>
    Reviewed-by: Michał Winiarski <[email protected]>
    Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit 5ba899082cbffb779ccb39420fe1718850daf857)
    Signed-off-by: Jani Nikula <[email protected]>

commit 61a05870b939b9c5551817ad65b74194ea84140c
Author: Chris Wilson <[email protected]>
Date:   Fri Oct 7 07:53:26 2016 +0100

    drm/i915: Reset the breadcrumbs IRQ more carefully
    
    Along with the interrupt, we want to restore the fake-irq and
    wait-timeout detection. If we use the breadcrumbs interface to setup the
    interrupt as it wants, the auxiliary timers will also be restored.
    
    v2: Cancel both timers as well, sanitize the IMR.
    
    Fixes: 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete requests")
    Signed-off-by: Chris Wilson <[email protected]>
    Cc: Mika Kuoppala <[email protected]>
    Reviewed-by: Mika Kuoppala <[email protected]>
    Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit ad07dfcddf1394e6fed094e7fb426b4242a6814e)
    Signed-off-by: Jani Nikula <[email protected]>

commit c92fa4fe90256a73975bd1e1c47b60a566b2d037
Author: Chris Wilson <[email protected]>
Date:   Fri Oct 7 07:53:25 2016 +0100

    drm/i915: Force relocations via cpu if we run out of idle aperture
    
    If we run out of enough aperture space to fit the entire object, we
    fallback to trying to insert a single page. However, if that also fails,
    we currently fail to userspace with an unexpected ENOSPC. (ENOSPC means
    to userspace that their batch could not be fitted within the GTT.) Prior
    to commit e8cb909ac3ab ("drm/i915: Fallback to single page GTT
    mmappings for relocations") the approach is to fallback to using the
    slow CPU relocation path in case of iomapping failure, and that is the
    behaviour we need to restore.
    
    Fixes: e8cb909ac3ab ("drm/i915: Fallback to single page GTT mmappings...")
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98101
    Signed-off-by: Chris Wilson <[email protected]>
    Cc: Joonas Lahtinen <[email protected]>
    Reviewed-by: Joonas Lahtinen <[email protected]>
    Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit d7f7633557503bd231347d8896b9a6fb08f84e00)
    Signed-off-by: Jani Nikula <[email protected]>

commit 9b05a6099ed67c2a92e7e5d9032536f1c08169a6
Author: Chris Wilson <[email protected]>
Date:   Fri Oct 7 07:53:24 2016 +0100

    drm/i915: Distinguish last emitted request from last submitted request
    
    In order not to trigger hangcheck on a idle-but-waiting engine, we need
    to distinguish between the pending request queue and the actual
    execution queue. This is done later in "drm/i915: Enable multiple
    timelines" but for now we need a temporary fix to prevent blaming the
    wrong engine for a GPU hang.
    
    (Note that this causes a temporary subtle change in how we decide when
    to allow a waitboost to be re-awarded back to the waiter, the temporary
    effect is that if the wait is upon the most current execution the wait
    is given for free, instead of checking to see if the client stalled
    itself. This will be repaired in "drm/i915: Enable multiple timelines".)
    
    Fixes: 0a046a0e93d2 ("drm/i915: Nonblocking request submission")
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98104
    Signed-off-by: Chris Wilson <[email protected]>
    Cc: Joonas Lahtinen <[email protected]>
    Cc: Mika Kuoppala <[email protected]>
    Reviewed-by: Joonas Lahtinen <[email protected]>
    Reviewed-by: Mika Kuoppala <[email protected]>
    Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit 8687b3ec852e89630bac650f15136811c7b4c1dc)
    Signed-off-by: Jani Nikula <[email protected]>

commit 16c83fad79ca912b8b5bbdcb5272794a2be41262
Author: Ville Syrjälä <[email protected]>
Date:   Mon Oct 3 10:55:16 2016 +0300

    drm/i915: Allow DP to work w/o EDID
    
    Allow returning "connected" or "unknown" connector status for DP branch
    devices that don't have an EDID. Currently we'd claim the thing as
    "disconnected" if there is no EDID.
    
    This stuff used to broken already, I think, but it got more broken by
    commit f21a21983ef1 ("drm/i915: Splitting intel_dp_detect")
    
    Cc: Damien Cassou <[email protected]>
    Cc: [email protected]
    Cc: Arno <[email protected]>
    Cc: Shubhangi Shrivastava <[email protected]>
    Cc: Sivakumar Thulasimani <[email protected]>
    Cc: Ander Conselvan de Oliveira <[email protected]>
    Cc: [email protected]
    Tested-by: Arno <[email protected]>
    Fixes: f21a21983ef1 ("drm/i915: Splitting intel_dp_detect")
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83348
    Signed-off-by: Ville Syrjälä <[email protected]>
    Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
    Reviewed-by: Ander Conselvan de Oliveira <[email protected]>
    (cherry picked from commit 5cb651a7959310ef4dbb0b93f005b10286789656)
    Signed-off-by: Jani Nikula <[email protected]>

commit 1015811609c0328b5ed670d07748591b837e74eb
Author: Ville Syrjälä <[email protected]>
Date:   Mon Oct 3 10:55:15 2016 +0300

    drm/i915: Move long hpd handling into the hotplug work
    
    We can't rely on connector->status in the detect() hook if the long hpd
    was already handled by the dig_port_work as that won't update
    connector->status. Thus we have to defer the long hpd handling entirely
    until the hotplug work runs to avoid the double long hpd handling
    the "detect_done" flag is trying to prevent.
    
    We'll start to depend on connector->status being up to date in a
    following patch.
    
    Cc: Damien Cassou <[email protected]>
    Cc: [email protected]
    Cc: Arno <[email protected]>
    Cc: Shubhangi Shrivastava <[email protected]>
    Cc: Sivakumar Thulasimani <[email protected]>
    Cc: Ander Conselvan de Oliveira <[email protected]>
    Cc: [email protected]
    Tested-by: Arno <[email protected]>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83348
    Signed-off-by: Ville Syrjälä <[email protected]>
    Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
    Reviewed-by: Ander Conselvan de Oliveira <[email protected]>
    (cherry picked from commit 27d4efc5591a5853de54713bc717de73c8951e17)
    Signed-off-by: Jani Nikula <[email protected]>

commit c79d7303e1ddc8260b0f385212b26cad297ff890
Author: Chris Wilson <[email protected]>
Date:   Tue Oct 4 21:11:26 2016 +0100

    drm/i915/execlists: Reinitialise context image after GPU hang
    
    On Braswell, at least, we observe that the context image is written in
    multiple phases. The first phase is to clear the register state, and
    subsequently rewrite it. A GPU reset at the right moment can interrupt
    the context update leaving it corrupt, and our update of the RING_HEAD
    is not sufficient to restart the engine afterwards. To recover, we need
    to reset the registers back to their original values. The context state
    is lost. What we need is a better mechanism to serialise the reset with
    pending flushes from the GPU.
    
    Fixes: 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete requests")
    Signed-off-by: Chris Wilson <[email protected]>
    Cc: Mika Kuoppala <[email protected]>
    Reviewed-by: Mika Kuoppala <[email protected]>
    Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit a3aabe86a3406b9946a4f7707762a833a58dfe9c)
    Signed-off-by: Jani Nikula <[email protected]>

commit 27399eeec28ff33a0c5216a80cf57cbc6ba3c15e
Author: Chris Wilson <[email protected]>
Date:   Mon Oct 3 13:45:16 2016 +0100

    drm/i915: Use correct index for backtracking HUNG semaphores
    
    When decoding the semaphores inside hangcheck, we need to use the hw-id
    and not the local array index.
    
    Fixes: de1add360522 ("drm/i915: Decouple execbuf uAPI ...")
    Testcase: igt/gem_exec_whisper/hang # gen6-7
    Signed-off-by: Chris Wilson <[email protected]>
    Cc: Mika Kuoppala <[email protected]>
    Cc: Tvrtko Ursulin <[email protected]>
    Cc: Daniel Vetter <[email protected]>
    Cc: [email protected]
    Reviewed-by: Joonas Lahtinen <[email protected]>
    Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit 348b9b1192144e13b779f8f9be301d492bebaff2)
    Signed-off-by: Jani Nikula <[email protected]>

commit ca5732c53bf66ad755284786897e0dd10330de87
Author: Chris Wilson <[email protected]>
Date:   Mon Oct 3 13:45:15 2016 +0100

    drm/i915: Unalias obj->phys_handle and obj->userptr
    
    We use obj->phys_handle to choose the pread/pwrite path, but as
    obj->phys_handle is a union with obj->userptr, we then mistakenly use
    the phys_handle path for userptr objects within pread/pwrite.
    
    Testcase: igt/gem_userptr_blits/forbidden-operations
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97519
    Signed-off-by: Chris Wilson <[email protected]>
    Cc: [email protected]
    Reviewed-by: Joonas Lahtinen <[email protected]>
    Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit 5f12b80a0b42da253691ca03828033014bb786eb)
    Signed-off-by: Jani Nikula <[email protected]>

commit f856f847b22c52be82f712ea6ada946c6db884d7
Author: Chris Wilson <[email protected]>
Date:   Mon Oct 3 13:45:14 2016 +0100

    drm/i915: Just clear the mmiodebug before a register access
    
    When we enable the per-register access mmiodebug, it is to detect which
    access is illegal. Reporting on earlier untraced access outside of the
    mmiodebug does not help debugging (as the suspicion is immediately put
    upon the current register which is not at fault)!
    
    References: https://bugs.freedesktop.org/show_bug.cgi?id=97985
    Signed-off-by: Chris Wilson <[email protected]>
    Cc: Mika Kuoppala <[email protected]>
    Reviewed-by: Mika Kuoppala <[email protected]>
    Cc: [email protected]
    Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit dda960335e020835f7f1c12760e7f0b525b451e2)
    Signed-off-by: Jani Nikula <[email protected]>

commit be5c571b2ff3a164d2e14ccc100cb5b2b3d3fb7c
Author: Paulo Zanoni <[email protected]>
Date:   Thu Sep 29 16:36:48 2016 -0300

    drm/i915/gen9: only add the planes actually affected by ddb changes
    
    We were previously adding all the planes owned by the CRTC even when
    the ddb partitioning didn't change for them. As a consequence, a lot
    of functions were being called when we were just moving the cursor
    around the screen, such as skylake_update_primary_plane().
    
    This was causing flickering on the primary plane when moving the
    cursor. I'm not 100% sure which operation caused the flickering, but
    we were writing to a lot of registers, so it could be any of these
    writes. With this patch, just moving the mouse won't add the primary
    plane to the commit since it won't trigger a change in DDB
    partitioning.
    
    v2: Use skl_ddb_entry_equal() (Lyude).
    v3: Change Reported-and-bisected-by: to Reported-by: for checkpatch
    
    Fixes: 05a76d3d6ad1 ("drm/i915/skl: Ensure pipes with changed wms get added to the state")
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97888
    Cc: Mike Lothian <[email protected]>
    Cc: [email protected]
    Reported-by: Mike Lothian <[email protected]>
    Signed-off-by: Paulo Zanoni <[email protected]>
    Signed-off-by: Lyude <[email protected]>
    Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit 7f60e200e254cd53ad1bd74a56bdd23e813ac4b7)
    Signed-off-by: Jani Nikula <[email protected]>

commit a3fd4c67af3d8a81d241b3d51b3525f36f1d68bb
Author: Ville Syrjälä <[email protected]>
Date:   Mon Sep 26 11:30:46 2016 +0300

    drm/i915: Allow PCH DPLL sharing regardless of DPLL_SDVO_HIGH_SPEED
    
    DPLL_SDVO_HIGH_SPEED must be set for SDVO/HDMI/DP, but nowhere is it
    forbidden to set it for LVDS/CRT as well. So let's also set it on
    CRT to make it possible to share the DPLL between HDMI and CRT.
    
    What that bit apparently does is enable the x5 clock to the port,
    which then pumps out the bits on both edges of the clock. The DAC
    doesn't need that clock since it's not pumping out bits, but I don't
    think it hurts to have the DPLL output that clock anyway.
    
    This is fairly important on IVB since it has only two DPLLs with three
    pipes. So trying to drive three or more PCH ports with three pipes
    is only possible when at least one of the DPLLs gets shared between
    two of the pipes.
    
    SNB doesn't really need to do this since it has only two pipes. It could
    be done to avoid enabling the second DPLL at all in certain cases, but
    I'm not sure that's such a huge win. So let's not do it for SNB, at
    least for now. On ILK it never makes sense as the DPLLs can't be shared.
    
    v2: Just always enable the high speed clock to keep things simple (Daniel)
        Beef up the commit message a bit (Daniel)
    
    Cc: Nick Yamane <[email protected]>
    Cc: Daniel Vetter <[email protected]>
    Cc: [email protected]
    Tested-by: Nick Yamane <[email protected]>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97204
    Signed-off-by: Ville Syrjälä <[email protected]>
    Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
    Reviewed-by: Ander Conselvan de Oliveira <[email protected]>
    (cherry picked from commit 7d7f8633a82763577727762ff3ac1df3017cb8fe)
    Signed-off-by: Jani Nikula <[email protected]>

commit 9bf9675cafde2cbc6f7b56c120d804c4e7111981
Author: Imre Deak <[email protected]>
Date:   Mon Sep 26 17:54:31 2016 +0300

    drm/i915/bxt: Fix HDMI DPLL configuration
    
    a277ca7dc01d should've been a no-functional-change commit, but it
    removed the initialization of the dpll_hw_state for HDMI outputs,
    resulting in state mismatches and a failed modeset with blank
    screen. Fix this by reinstating the dpll_hw_state initialization.
    
    v2:
    - Make bxt_ddi_hdmi_set_dpll_hw_state() static.
    
    Cc: Manasi Navare <[email protected]>
    Cc: Ander Conselvan de Oliveira <[email protected]>
    Cc: Durgadoss R <[email protected]>
    Cc: Rodrigo Vivi <[email protected]>
    Fixes: a277ca7dc01d ("drm/i915: Split bxt_ddi_pll_select()")
    Signed-off-by: Imre Deak <[email protected]>
    Reviewed-by: Ander Conselvan de Oliveira <[email protected]>
    Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit a04139c4cf289119cdfb6081af602f7a452fb7c2)
    Signed-off-by: Jani Nikula <[email protected]>

commit 73fed0ef8567f1e1cba079994353e60208ded964
Author: Paulo Zanoni <[email protected]>
Date:   Thu Sep 22 18:00:33 2016 -0300

    drm/i915/gen9: fix the watermark res_blocks value
    
    We forgot the "res_blocks += y_tile_minimum" that's described on step
    V of our documentation.
    
    Again, this should only affect the Y tiling cases.
    
    It looks like the relevant code was introduced in 0fda65680e92, but
    there's always the possibility that it matched our specification when
    it was introduced, and then the specification changed while the code
    stayed the same. So we can't really say this was a regression, but
    let's try to add a "Fixes" tag anyway to help backporting.
    
    v2: Try to add a "Fixes" tag (Maarten).
    
    Fixes: 0fda65680e92 ("drm/i915/skl: Update watermarks for Y tiling")
    Cc: [email protected]
    Cc: Tvrtko Ursulin <[email protected]>
    Reviewed-by: Lyude <[email protected]>
    Reviewed-by: Maarten Lankhorst <[email protected]>
    Signed-off-by: Paulo Zanoni <[email protected]>
    Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit 75676ed423a6acf9e2b1df52fbc036a51e11fb7a)
    Signed-off-by: Jani Nikula <[email protected]>

commit cf6c525a31fac11b0775b8c06c00a508c6356d9b
Author: Paulo Zanoni <[email protected]>
Date:   Thu Sep 22 18:00:32 2016 -0300

    drm/i915/gen9: fix plane_blocks_per_line on watermarks calculations
    
    The confusing thing is that plane_blocks_per_line is listed as part of
    the method 2 calculation but is also used for other things. We
    calculated it in two different places and different ways: one inside
    skl_wm_method2() and the other inside skl_compute_plane_wm(). The
    skl_wm_method2() implementation is the one that matches the
    specification.
    
    With this patch we fix the skl_compute_plane_wm() calculation and just
    pass it as a parameter to skl_wm_method2(). We also take care to not
    modify the value of plane_bytes_per_line since we're going to rely on
    it having a correct value in later patches.
    
    This should affect the watermarks for Linear and Y-tiled.
    
    From my analysis, it looks like the two plane_blocks_per_line
    variables got out of sync on 0fda65680e92, but we can't really say
    that commit was a regression, it looks like just an incomplete fix.
    There's always the possibility that 0fda65680e92 matched our
    specification at that time, and then later the specification changed.
    
    v2: Try to add a "Fixes" tag (Maarten).
    
    Fixes: 0fda65680e92 ("drm/i915/skl: Update watermarks for Y tiling")
    Cc: [email protected]
    Cc: Tvrtko Ursulin <[email protected]>
    Reviewed-by: Lyude <[email protected]>
    Reviewed-by: Maarten Lankhorst <[email protected]>
    Signed-off-by: Paulo Zanoni <[email protected]>
    Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit 7a1a8aed67e0a60772defe3f6499eb340da48634)
    Signed-off-by: Jani Nikula <[email protected]>

commit ccc1057477bc99678896b51adce6b6ee4019dc37
Author: Paulo Zanoni <[email protected]>
Date:   Thu Sep 22 18:00:31 2016 -0300

    drm/i915/gen9: minimum scanlines for Y tile is not always 4
    
    During watermarks calculations, this value is used in 3 different
    places. Only one of them was not using a hardcoded 4. Move the code up
    so everybody can benefit from the actual value.
    
    This should only help on situations with Y tiling + 90/270 rotation +
    1 or 2 bpp or NV12.
    
    Cc: [email protected]
    Reviewed-by: Maarten Lankhorst <[email protected]>
    Signed-off-by: Paulo Zanoni <[email protected]>
    Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit 1186fa85eb9b3cc0589990fbc39617e50e38759a)
    Signed-off-by: Jani Nikula <[email protected]>

commit 4e4d3814a9bb4d71cd3ff0701d8d7041edefd8f0
Author: Paulo Zanoni <[email protected]>
Date:   Thu Sep 22 18:00:30 2016 -0300

    drm/i915/gen9: fix the WaWmMemoryReadLatency implementation
    
    Bspec says:
      "The mailbox response data may not account for memory read latency.
       If the mailbox response data for level 0 is 0us, add 2 microseconds
       to the result for each valid level."
    
    This means we should only do the +2 in case wm[0] == 0, not always.
    
    So split the sanitizing implementation from the WA implementation and
    fix the WA implementation.
    
    v2: Add Fixes tag (Maarten).
    
    Fixes: 367294be7c25 ("drm/i915/gen9: Add 2us read latency to WM level")
    Cc: [email protected]
    Cc: Vandana Kannan <[email protected]>
    Reviewed-by: Maarten Lankhorst <[email protected]>
    Signed-off-by: Paulo Zanoni <[email protected]>
    Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit 0727e40a48a1d08cf54ce2c01e120864b92e59bf)
    Signed-off-by: Jani Nikula <[email protected]>

commit 17777d61f4a87d7b6d5585e8fdffa83773c594e7
Author: Paulo Zanoni <[email protected]>
Date:   Thu Sep 22 18:00:29 2016 -0300

    drm/i915/kbl: KBL also needs to run the SAGV code
    
    According to BSpec, it's the "core CPUs" that need the code, which
    means SKL and KBL, but not BXT.
    
    I don't have a KBL to test this patch on it.
    
    v2: Only SKL should have I915_SAGV_NOT_CONTROLLED.
    
    Cc: [email protected]
    Reviewed-by: Maarten Lankhorst <[email protected]>
    Signed-off-by: Paulo Zanoni <[email protected]>
    Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit 6e3100ec21e7c774a0fc01e36a1e0739530c2f71)
    Signed-off-by: Jani Nikula <[email protected]>

commit 6e7fdb873d6255ca3c999dd5c6c18962a769ed3e
Author: Paulo Zanoni <[email protected]>
Date:   Thu Sep 22 18:00:28 2016 -0300

    drm/i915: introduce intel_has_sagv()
    
    And use it to move knowledge about the SAGV-supporting platforms from
    the callers to the SAGV code.
    
    We'll add more platforms to intel_has_sagv(), so IMHO it makes more
    sense to move all this to a single function instead of patching all
    the callers every time we add SAGV support to a new platform.
    
    v2: Move I915_SAGV_NOT_CONTROLLED to the new function (Lyude).
    
    Cc: [email protected]
    Reviewed-by: Maarten Lankhorst <[email protected]>
    Signed-off-by: Paulo Zanoni <[email protected]>
    Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit 56feca91973459d0b62cbb2610b62d341025ed89)
    Signed-off-by: Jani Nikula <[email protected]>

commit 674f823b455cdb94d5773406c1caac170f87e1c4
Author: Paulo Zanoni <[email protected]>
Date:   Thu Sep 22 18:00:27 2016 -0300

    drm/i915: SAGV is not SKL-only, so rename a few things
    
    The plan is to introduce intel_has_sagv() and then use it to discover
    which platforms actually support it.
    
    I thought about keeping the functions with their current skl names,
    but found two problems: (i) skl_has_sagv() would become a very
    confusing name, and (ii) intel_atomic_commit_tail() doesn't seem to be
    calling any functions whose name start with a platform name, so the
    "intel_" naming scheme seems make more sense than the "firstplatorm_"
    naming scheme here.
    
    Cc: [email protected]
    Reviewed-by: Lyude <[email protected]>
    Reviewed-by: Maarten Lankhorst <[email protected]>
    Signed-off-by: Paulo Zanoni <[email protected]>
    Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit 16dcdc4edbcf5cb130004737f2548401776170f1)
    Signed-off-by: Jani Nikula <[email protected]>

commit 9700f8b28f9ba97f5d1b443658d94f09a9d1b6fb
Author: Paulo Zanoni <[email protected]>
Date:   Fri Aug 19 19:03:23 2016 -0300

    drm/i915: don't forget to set intel_crtc->dspaddr_offset on SKL+
    
    We never remembered to set it (so it was zero), but this was not a
    problem in the past due to the way handled the hardware registers.
    Unfortunately we changed how we set the hardware and forgot to set
    intel_crtc->dspaddr_offset.
    
    This started to reflect on a few kms_frontbuffer_tracking subtests
    that relied on page flips with CRTCs that don't point to the x:0,y:0
    coordinates of the frontbuffer. After the page flip the CRTC was
    showing the x:0,y:0 coordinate of the frontbuffer instead of
    x:500,y:500. This problem is present even if we don't enable FBC or
    PSR.
    
    While trying to bisect it I realized that the first bad commit
    actually just gives me a black screen for the mentioned tests instead
    of showing the wrong x:0,y:0 offsets. A few commits later the black
    screen problem goes away and we get to the point where the code is
    today, but I'll consider the black screen as the first bad commit
    since it's the point where the IGT subtests start to fail.
    
    Fixes: 6687c9062c46 ("drm/i915: Rewrite fb rotation GTT handling")
    Testcase: kms_frontbuffer_tracking/fbc-1p-primscrn-shrfb-pgflip-blt
    Testcase: kms_frontbuffer_tracking/fbc-1p-primscrn-shrfb-evflip-blt
    Testcase: kms_frontbuffer_tracking/fbc-1p-shrfb-fliptrack
    Cc: Ville Syrjälä <[email protected]>
    Cc: Sivakumar Thulasimani <[email protected]>
    Cc: [email protected]
    
    Signed-off-by: Paulo Zanoni <[email protected]>
    Reviewed-by: Ville Syrjälä <[email protected]>
    Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit 4c0b8a8bc49c477be9467f614b6b4ec479736019)
    Signed-off-by: Jani Nikula <[email protected]>

commit ec7ce653d9f6eb22404dee468bf63d8fcaff9c42
Author: Chris Wilson <[email protected]>
Date:   Wed Sep 21 14:51:07 2016 +0100

    drm/i915: Only shrink the unbound objects during freeze
    
    At the point of creating the hibernation image, the runtime power manage
    core is disabled - and using the rpm functions triggers a warn.
    i915_gem_shrink_all() tries to unbind objects, which requires device
    access and so tries to how an rpm reference triggering a warning:
    
    [   44.235420] ------------[ cut here ]------------
    [   44.235424] WARNING: CPU: 2 PID: 2199 at drivers/gpu/drm/i915/intel_runtime_pm.c:2688 intel_runtime_pm_get_if_in_use+0xe6/0xf0
    [   44.235426] WARN_ON_ONCE(ret < 0)
    [   44.235445] Modules linked in: ctr ccm arc4 rt2800usb rt2x00usb rt2800lib rt2x00lib crc_ccitt mac80211 cmac cfg80211 btusb rfcomm bnep btrtl btbcm btintel bluetooth dcdbas x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_codec_realtek crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_generic aesni_intel snd_hda_codec_hdmi aes_x86_64 lrw gf128mul snd_hda_intel glue_helper ablk_helper cryptd snd_hda_codec hid_multitouch joydev snd_hda_core binfmt_misc i2c_hid serio_raw snd_pcm acpi_pad snd_timer snd i2c_designware_platform 8250_dw nls_iso8859_1 i2c_designware_core lpc_ich mfd_core soundcore usbhid hid psmouse ahci libahci
    [   44.235447] CPU: 2 PID: 2199 Comm: kworker/u8:8 Not tainted 4.8.0-rc5+ #130
    [   44.235447] Hardware name: Dell Inc. XPS 13 9343/0310JH, BIOS A07 11/11/2015
    [   44.235450] Workqueue: events_unbound async_run_entry_fn
    [   44.235453]  0000000000000000 ffff8801b2f7fb98 ffffffff81306c2f ffff8801b2f7fbe8
    [   44.235454]  0000000000000000 ffff8801b2f7fbd8 ffffffff81056c01 00000a801f50ecc0
    [   44.235456]  ffff88020ce50000 ffff88020ce59b60 ffffffff81a60b5c ffffffff81414840
    [   44.235456] Call Trace:
    [   44.235459]  [<ffffffff81306c2f>] dump_stack+0x4d/0x6e
    [   44.235461]  [<ffffffff81056c01>] __warn+0xd1/0xf0
    [   44.235464]  [<ffffffff81414840>] ? i915_pm_suspend_late+0x30/0x30
    [   44.235465]  [<ffffffff81056c6f>] warn_slowpath_fmt+0x4f/0x60
    [   44.235468]  [<ffffffff814e73ce>] ? pm_runtime_get_if_in_use+0x6e/0xa0
    [   44.235469]  [<ffffffff81433526>] intel_runtime_pm_get_if_in_use+0xe6/0xf0
    [   44.235471]  [<ffffffff81458a26>] i915_gem_shrink+0x306/0x360
    [   44.235473]  [<ffffffff81343fd4>] ? pci_platform_power_transition+0x24/0x90
    [   44.235475]  [<ffffffff81414840>] ? i915_pm_suspend_late+0x30/0x30
    [   44.235476]  [<ffffffff81458dfb>] i915_gem_shrink_all+0x1b/0x30
    [   44.235478]  [<ffffffff814560b3>] i915_gem_freeze_late+0x33/0x90
    [   44.235479]  [<ffffffff81414877>] i915_pm_freeze_late+0x37/0x40
    [   44.235481]  [<ffffffff814e9b8e>] dpm_run_callback+0x4e/0x130
    [   44.235483]  [<ffffffff814ea5db>] __device_suspend_late+0xdb/0x1f0
    [   44.235484]  [<ffffffff814ea70f>] async_suspend_late+0x1f/0xa0
    [   44.235486]  [<ffffffff81077557>] async_run_entry_fn+0x37/0x150
    [   44.235488]  [<ffffffff8106f518>] process_one_work+0x148/0x3f0
    [   44.235490]  [<ffffffff8106f8eb>] worker_thread+0x12b/0x490
    [   44.235491]  [<ffffffff8106f7c0>] ? process_one_work+0x3f0/0x3f0
    [   44.235492]  [<ffffffff81074d09>] kthread+0xc9/0xe0
    [   44.235495]  [<ffffffff816e257f>] ret_from_fork+0x1f/0x40
    [   44.235496]  [<ffffffff81074c40>] ? kthread_park+0x60/0x60
    [   44.235497] ---[ end trace e438706b97c7f132 ]---
    
    Alternatively, to actually shrink everything we have to do so slightly
    earlier in the hibernation process.
    
    To keep lockdep silent, we need to take struct_mutex for the shrinker
    even though we know that we are the only user during the freeze.
    
    Fixes: 7aab2d534e35 ("drm/i915: Shrink objects prior to hibernation")
    Signed-off-by: Chris Wilson <[email protected]>
    Cc: Joonas Lahtinen <[email protected]>
    Reviewed-by: Joonas Lahtinen <[email protected]>
    Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit 6a800eabba34945c2986d70114b41d564bad52a8)
    Signed-off-by: Jani Nikula <[email protected]>

commit ac75694125f12f3ce92c30584b49533ed710da8e
Author: Chris Wilson <[email protected]>
Date:   Wed Sep 21 14:51:06 2016 +0100

    drm/i915: Restore current RPS state after reset
    
    Following commit 821ed7df6e2a ("drm/i915: Update reset path to fix
    incomplete requests") we no longer mark the context as lost on reset as
    we keep the requests (and contexts) alive. However, RPS remains reset
    and we need to restore the current state to match the in-flight
    requests.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97824
    Fixes: 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete requests")
    Signed-off-by: Chris Wilson <[email protected]>
    Cc: Mika Kuoppala <[email protected]>
    Cc: Tvrtko Ursulin <[email protected]>
    Cc: Arun Siluvery <[email protected]>
    Reviewed-by: Mika Kuoppala <[email protected]>
    Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit f2a91d1a6f5960c08f1ca60bd076f4dc020c50c6)
    Signed-off-by: Jani Nikula <[email protected]>

commit 11dec6a2940c8c8b0791aecdab87f9c9b1371d11
Author: Imre Deak <[email protected]>
Date:   Wed Sep 14 13:04:13 2016 +0300

    drm/i915: Unlock PPS registers after GPU reset
    
    Reapply the PPS register unlock workaround after GPU reset on platforms
    where the reset clobbers the display HW state. This at least gets rid of
    the related WARN during LVDS encoder enabling on PNV.
    
    Fixes: ed6143b8f75 ("drm/i915/lvds: Restore initial HW state during encoder enabling")
    Reported-by: Ville Syrjälä <[email protected]>
    Signed-off-by: Imre Deak <[email protected]>
    Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
    Reviewed-by: Ville Syrjälä <[email protected]>
    (cherry picked from commit 51f592050a523fc5882f9b8b4e9259422e41e848)
    Signed-off-by: Jani Nikula <[email protected]>

commit 915b417946030e1f365c63728875cffd8db8e880
Author: Shawn Lee <[email protected]>
Date:   Mon Sep 19 13:35:26 2016 +0300

    drm/i915/backlight: setup backlight pwm alternate increment on backlight enable
    
    Backlight enable is supposed to do a full setup of the backlight. We
    were missing the PWM alternate increment bit in the south chicken
    registers on lpt+ pch. This potentially caused a PWM frequency change
    when the chicken register value was lost e.g. on suspend.
    
    v2 by Jani, rebase on the patch caching alt increment
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97486
    References: https://bugs.freedesktop.org/show_bug.cgi?id=67454
    Cc: Cooper Chiou <[email protected]>
    Cc: Wei Shun Chen <[email protected]>
    Cc: Gary C Wang <[email protected]>
    Cc: [email protected] # v4.4+ 16e1203db8ab drm/i915/backlight: setup and cache...
    Cc: [email protected] # v4.4+
    Reviewed-by: Ville Syrjälä <[email protected]>
    Signed-off-by: Shawn Lee <[email protected]>
    Signed-off-by: Jani Nikula <[email protected]>
    Link: http://patchwork.freedesktop.org/patch/msgid/8265f5935bd31c039ddfc82819d26c2ca1ae9cba.1474281249.git.jani.nikula@intel.com
    (cherry picked from commit e29aff05f239f8dd24e9ee7816fd96726e20105a)
    Signed-off-by: Jani Nikula <[email protected]>

commit 16e1203db8ab740c912ea62761fdf27d7811b886
Author: Jani Nikula <[email protected]>
Date:   Mon Sep 19 13:35:25 2016 +0300

    drm/i915/backlight: setup and cache pwm alternate increment value
    
    This will also be needed later on when setting up the alternate
    increment in backlight enable.
    
    Cc: Shawn Lee <[email protected]>
    Cc: <[email protected]>
    Reviewed-by: Ville Syrjälä <[email protected]>
    Signed-off-by: Jani Nikula <[email protected]>
    Link: http://patchwork.freedesktop.org/patch/msgid/9984b20bc59aee90b83caf59ce91f3fb122c9627.1474281249.git.jani.nikula@intel.com
    (cherry picked from commit 32b421e79e6b546da1d469f1229403ac9142d695)
    Signed-off-by: Jani Nikula <[email protected]>

commit fee686b74a9c115d3c4c851eb6613d1378ad0e0c
Author: Adrian Hunter <[email protected]>
Date:   Wed Oct 5 12:11:24 2016 +0300

    mmc: sdhci-pci: Fix bus power failing to enable for some Intel controllers
    
    Some Intel controllers (e.g. BXT) might fail to set bus power after a
    D3 -> D0 transition due to the present state not yet having propagated.
    Retry for up to 2 milliseconds.
    
    Signed-off-by: Adrian Hunter <[email protected]>
    Signed-off-by: Ulf Hansson <[email protected]>

commit 6bc090631dfc3394da0619e920662e6636dbe89c
Author: Adrian Hunter <[email protected]>
Date:   Wed Oct 5 12:11:23 2016 +0300

    mmc: sdhci-pci: Let devices define their own sdhci_ops
    
    Let devices define their own sdhci_ops so that device-specific variations
    can be implemented without adding quirks.
    
    Signed-off-by: Adrian Hunter <[email protected]>
    Signed-off-by: Ulf Hansson <[email protected]>

commit 606d313124094d87050896a10894200cdd2b0514
Author: Adrian Hunter <[email protected]>
Date:   Wed Oct 5 12:11:22 2016 +0300

    mmc: sdhci: Rename sdhci_set_power() to sdhci_set_power_noreg()
    
    Unlike other cases, sdhci_set_power() does not reflect the default
    implementation of the ->set_power() callback. Rename it and create
    sdhci_set_power() that is the default implementation.
    
    Signed-off-by: Adrian Hunter <[email protected]>
    Cc: Jisheng Zhang <[email protected]>
    Signed-off-by: Ulf Hansson <[email protected]>

commit fc605f1d8060133596bb6083fc4b7b306d1d5931
Author: Adrian Hunter <[email protected]>
Date:   Wed Oct 5 12:11:21 2016 +0300

    mmc: sdhci: Fix SDHCI_QUIRK2_STOP_WITH_TC
    
    Multi-block data transfers can specify the number of blocks either using a
    Set Block Count command (CMD23) or by sending a STOP command (CMD12) after
    the required number of blocks has transferred. CMD23 is preferred, but some
    cards don't support it. CMD12 with R1b response is used for writes, and
    R1 response for reads.
    
    Some SDHCI host controllers give a Transfer Complete (TC) interrupt for the
    STOP command (CMD12) whether or not a R1b response has been specified. The
    quirk SDHCI_QUIRK2_STOP_WITH_TC identifies those host controllers, but the
    implementation only considers the case where the TC interrupt arrives at
    the same time as the Command Complete (CC) interrupt. However,
    occasionally TC arrives before CC. That is harmless, but does generate an
    error message "Got data interrupt 0x00000002 even though no data operation
    was in progress".
    
    A simpler approach is to force R1b response onto all STOP commands, because
    SDHCI will handle TC before CC in the general case, so do that.
    
    Signed-off-by: Adrian Hunter <[email protected]>
    Cc: Giuseppe Cavallaro <[email protected]>
    Signed-off-by: Ulf Hansson <[email protected]>

commit 3f2d26643595973e835e8356ea90c7c15cb1b0f1
Author: Jiri Slaby <[email protected]>
Date:   Mon Oct 3 10:58:28 2016 +0200

    mmc: core: Annotate cmd_hdr as __le32
    
    Commit f68381a70bb2 (mmc: block: fix packed command header endianness)
    correctly fixed endianness handling of packed_cmd_hdr in
    mmc_blk_packed_hdr_wrq_prep.
    
    But now, sparse complains about incorrect types:
    drivers/mmc/card/block.c:1613:27: sparse: incorrect type in assignment (different base types)
    drivers/mmc/card/block.c:1613:27:    expected unsigned int [unsigned] [usertype] <noident>
    drivers/mmc/card/block.c:1613:27:    got restricted __le32 [usertype] <noident>
    ...
    
    So annotate cmd_hdr properly using __le32 to make everyone happy.
    
    Signed-off-by: Jiri Slaby <[email protected]>
    Fixes: f68381a70bb2 (mmc: block: fix packed command header endianness)
    Cc: [email protected]
    Signed-off-by: Ulf Hansson <[email protected]>

commit 8a3bee9b13824147dd15efb2993fb1b19c0e5555
Author: Shawn Lin <[email protected]>
Date:   Fri Sep 30 14:19:00 2016 +0800

    mmc: sdhci-of-arasan: add sdhci_arasan_voltage_switch for arasan, 5.1
    
    Per the vendor's requirement, we shouldn't do any setting for
    1.8V Signaling Enable, otherwise the interaction/behaviour between
    phy and controller will be undefined. Mostly it works fine if we do
    that, but we still see failures. Anyway, let's fix it to meet the
    vendor's requirement. The error log looks like:
    
     [   93.405085] mmc1: unexpected status 0x800900 after switch
     [   93.408474] mmc1: switch to bus width 1 failed
     [   93.408482] mmc1: mmc_select_hs200 failed, error -110
     [   93.408492] mmc1: error -110 during resume (card was removed?)
     [   93.408705] PM: resume of devices complete after 213.453 msecs
    
    Signed-off-by: Shawn Lin <[email protected]>
    Acked-by: Adrian Hunter <[email protected]>
    Reviewed-by: Douglas Anderson <[email protected]>
    Signed-off-by: Ulf Hansson <[email protected]>

commit 4f25580fb84d934d7ecffa3c0aa8f10f7e23af92
Author: Shawn Lin <[email protected]>
Date:   Fri Sep 30 14:18:59 2016 +0800

    mmc: core: changes frequency to hs_max_dtr when selecting hs400es
    
    Per JESD84-B51 P49, Host need to change frequency to <=52MHz
    after setting HS_TIMING to 0x1, and host may changes frequency
    to <= 200MHz after setting HS_TIMING to 0x3. That means the card
    expects the clock rate to increase from the current used f_init
    (which is less than 400KHz, but still being less than 52MHz) to
    52MHz, otherwise we find some eMMC devices significantly report
    failure when sending status.
    
    Reported-by: Xiao Yao <[email protected]>
    Signed-off-by: Shawn Lin <[email protected]>
    Reviewed-by: Douglas Anderson <[email protected]>
    Signed-off-by: Ulf Hansson <[email protected]>

commit 1720d3545b772c49b2975eeb3b8f4d3f56dc2085
Author: Shawn Lin <[email protected]>
Date:   Fri Sep 30 14:18:58 2016 +0800

    mmc: core: switch to 1V8 or 1V2 for hs400es mode
    
    When introducing hs400es, I didn't notice that we haven't
    switched voltage to 1V2 or 1V8 for it. That happens to work
    as the first controller claiming to support hs400es, arasan(5.1),
    which is designed to only support 1V8. So the voltage is fixed to 1V8.
    But it actually is wrong, and will not fit for other host controllers.
    Let's fix it.
    
    Fixes: commit 81ac2af65793ecf ("mmc: core: implement enhanced strobe support")
    Cc: <[email protected]>
    Signed-off-by: Shawn Lin <[email protected]>
    Reviewed-by: Douglas Anderson <[email protected]>
    Signed-off-by: Ulf Hansson <[email protected]>

commit 48ab086d262e705c4d042228479aaf0b2daffcf9
Author: Baoyou Xie <[email protected]>
Date:   Fri Sep 30 09:37:38 2016 +0800

    mmc: block: add missing header dependencies
    
    We get 1 warning when building kernel with W=1:
    drivers/mmc/card/block.c:2147:5: warning: no previous prototype for
    'mmc_blk_issue_rq' [-Wmissing-prototypes]
    
    In fact, this function is declared in drivers/mmc/card/block.h, so this
    patch adds missing header dependencies.
    
    Signed-off-by: Baoyou Xie <[email protected]>
    Signed-off-by: Ulf Hansson <[email protected]>

commit 13d62fd26924b30593ffd970be17c7344149b188
Author: Wei Yongjun <[email protected]>
Date:   Sun Sep 25 15:44:03 2016 +0000

    mmc: sdhci-of-arasan: Fix non static symbol warning
    
    Fixes the following sparse warning:
    
    drivers/mmc/host/sdhci-of-arasan.c:253:6: warning:
     symbol 'sdhci_arasan_reset' was not declared. Should it be static?
    
    Signed-off-by: Wei Yongjun <[email protected]>
    Acked-by: Sören Brinkmann <[email protected]>
    Acked-by: Adrian Hunter <[email protected]>
    Signed-off-by: Ulf Hansson <[email protected]>

commit b907900ec4065e1d9b65fafa05fd6601b6a2ffc7
Author: Andrej Krutak <[email protected]>
Date:   Wed Oct 5 17:46:09 2016 +0200

    ALSA: line6: Fix POD X3 Live audio input
    
    The commit c039aaa77a7d1d9375665a8b59ec16dc7d23e259 was incomplete,
    missing part of the setup for Live. This makes also audio input work,
    in addition to audio output.
    
    Fixes: c039aaa77a7d1d9375665a8b59ec16dc7d23e259
    Reported-by: Eddi De Pieri <[email protected]>
    Signed-off-by: Andrej Krutak <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>

commit 621a99933c5cb509d832bb98e6118761461a1f8a
Author: Grazvydas Ignotas <[email protected]>
Date:   Sun Oct 9 20:07:00 2016 +0300

    drm: use the right function name in documentation
    
    There is no late_unregister(), it looks like the comment meant
    late_register(). Also fix a typo while at it.
    
    Signed-off-by: Grazvydas Ignotas <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>
    Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]

commit 9a47dba1f93148acb4e74f07716df7fad989c2e0
Author: Christophe JAILLET <[email protected]>
Date:   Fri Oct 7 09:27:41 2016 +0200

    drm: Release resources with a safer function
    
    We should use 'ida_simple_remove()' instead of 'ida_remove()' when freeing
    resources allocated with 'ida_simple_get()'.
    
    Signed-off-by: Christophe JAILLET <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>
    Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]

commit 67c8f116f5d59df46c2be99674542b43195b21d7
Author: Chris Wilson <[email protected]>
Date:   Wed Oct 5 18:40:56 2016 +0100

    drm: Fix up kerneldoc for new drm_gem_dmabuf_export()
    
    I hit send before completing a make htmldoc, and lo I forgot to fix up
    the cut'n'paste.
    
    Fixes: a4fce9cb782a ("drm/prime: Take a ref on the drm_dev when exporting...")
    Reported-by: kbuild test robot <[email protected]>
    Signed-off-by: Chris Wilson <[email protected]>
    Cc: Daniel Vetter <[email protected]>
    Cc: [email protected]
    Signed-off-by: Daniel Vetter <[email protected]>
    Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]

commit fdd8326a016a70f0ec96f5bb3011a5183961df2e
Author: Marek Vasut <[email protected]>
Date:   Wed Oct 5 16:31:33 2016 +0200

    drm/bridge: Drop drm_connector_unregister and call drm_connector_cleanup directly
    
    Drop unneeded drm_connector_unregister() and remove the unnecessary
    wrapper functions around drm_connector_cleanup().
    
    Signed-off-by: Marek Vasut <[email protected]>
    Cc: Daniel Vetter <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>
    Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]

commit 21bf75eca03c9da000cd7368c6e8eec7559debe5
Author: Stefan Christ <[email protected]>
Date:   Wed Oct 5 20:34:14 2016 +0200

    drm/fb-helper: fix sphinx markup for DRM_FB_HELPER_DEFAULT_OPS
    
    Fix invalid sphinx markup in the comment for the newly added
    DRM_FB_HELPER_DEFAULT_OPS.
    
    Signed-off-by: Stefan Christ <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>
    Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]

commit a5ea9f982d2b70de3bd73a666bc8d57e4d93cae3
Author: Arvind Yadav <[email protected]>
Date:   Wed Oct 5 15:08:36 2016 +0530

    gpio: mxs: Unmap region obtained by of_iomap
    
    Free memory mapping, if mxs_gpio_probe is not successful.
    
    Signed-off-by: Arvind Yadav <[email protected]>
    Signed-off-by: Linus Walleij <[email protected]>

commit 6d475e0b39801a000f6e0f174f2b816c70ff869d
Author: Ville Syrjälä <[email protected]>
Date:   Mon Oct 3 17:56:55 2016 +0300

    pinctrl: baytrail: Fix lockdep
    
    Initialize the spinlock before using it.
    
    INFO: trying to register non-static key.
    the code is fine but needs lockdep annotation.
    turning off the locking correctness validator.
    CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.8.0-dwc-bisect #4
    Hardware name: Intel Corp. VALLEYVIEW C0 PLATFORM/BYT-T FFD8, BIOS BLAKFF81.X64.0088.R10.1403240443 FFD8_X64_R_2014_13_1_00 03/24/2014
     0000000000000000 ffff8800788ff770 ffffffff8133d597 0000000000000000
     0000000000000000 ffff8800788ff7e0 ffffffff810cfb9e 0000000000000002
     ffff8800788ff7d0 ffffffff8205b600 0000000000000002 ffff8800788ff7f0
    Call Trace:
     [<ffffffff8133d597>] dump_stack+0x67/0x90
     [<ffffffff810cfb9e>] register_lock_class+0x52e/0x540
     [<ffffffff810d2081>] __lock_acquire+0x81/0x16b0
     [<ffffffff810cede1>] ? save_trace+0x41/0xd0
     [<ffffffff810d33b2>] ? __lock_acquire+0x13b2/0x16b0
     [<ffffffff810cf05a>] ? __lock_is_held+0x4a/0x70
     [<ffffffff810d3b1a>] lock_acquire+0xba/0x220
     [<ffffffff8136f1fe>] ? byt_gpio_get_direction+0x3e/0x80
     [<ffffffff81631567>] _raw_spin_lock_irqsave+0x47/0x60
     [<ffffffff8136f1fe>] ? byt_gpio_get_direction+0x3e/0x80
     [<ffffffff8136f1fe>] byt_gpio_get_direction+0x3e/0x80
     [<ffffffff813740a9>] gpiochip_add_data+0x319/0x7d0
     [<ffffffff81631723>] ? _raw_spin_unlock_irqrestore+0x43/0x70
     [<ffffffff8136fe3b>] byt_pinctrl_probe+0x2fb/0x620
     [<ffffffff8142fb0c>] platform_drv_probe+0x3c/0xa0
    ...
    
    Based on the diff it looks like the problem was introduced in
    commit 71e6ca61e826 ("pinctrl: baytrail: Register pin control handling")
    but I wasn't able to verify that empirically as the parent commit
    just oopsed when I tried to boot it.
    
    Cc: Cristina Ciocan <[email protected]>
    Cc: [email protected]
    Fixes: 71e6ca61e826 ("pinctrl: baytrail: Register pin control handling")
    Signed-off-by: Ville Syrjälä <[email protected]>
    Acked-by: Mika Westerberg <[email protected]>
    Signed-off-by: Linus Walleij <[email protected]>

commit c1da353472658aba6fc4d0c4c178d65d0aa843ce
Author: Pavel Machek <[email protected]>
Date:   Mon Oct 3 10:43:46 2016 +0200

    gpio/board.txt: point to gpiod_set_value
    
    gpiod_set_value() is preffered interface these days, so add a
    pointer. Also fix a missing ).
    
    Signed-off-by: Pavel Machek <[email protected]>
    [Fixed some grammar and reworded]
    Signed-off-by: Linus Walleij <[email protected]>

commit 0ef6e81d035563d7f16dfecfc7110abe3662568a
Author: Johannes Thumshirn <[email protected]>
Date:   Fri Sep 30 14:14:13 2016 +0200

    pinctrl: sunxi: Don't leak memory in case krealloc() failes
    
    If krealloc() fails there's no way of freeing the memory previously allocated
    for pctl->functions as it is overwritten by krealloc()'s return value. Fix
    this by assigning the return value to a temporary variable first so we can do
    error handling (which we didn't do at all before).
    
    Signed-off-by: Johannes Thumshirn <[email protected]>
    Signed-off-by: Linus Walleij <[email protected]>

commit e1547af8c0598ba257a0d08c88b5c42dbbc75f5a
Author: Johannes Thumshirn <[email protected]>
Date:   Fri Sep 30 14:13:56 2016 +0200

    pinctrl: berlin: Don't leak memory if krealloc() fails
    
    We're directly assigning krealoc()'s return value to pctrl->functions instead
    of using a temporary value to handle error checking. This leaks memory in case
    krealloc() failes. While we're at it, implement error handling for failed
    allocations at all.
    
    Signed-off-by: Johannes Thumshirn <[email protected]>
    Signed-off-by: Linus Walleij <[email protected]>

commit d26d8ca4ecd1ae5c84dd4d9eb3f090d108a6b90b
Author: Andrew Jeffery <[email protected]>
Date:   Wed Sep 28 00:20:16 2016 +0930

    pinctrl: aspeed-g5: Fix pin association of SPI1 function
    
    The SPI1 function was associated with the wrong pins: The functions that
    those pins provide is either an SPI debug or passthrough function
    coupled to SPI1. Make the SPI1 mux function configure the relevant pins
    and associate new SPI1DEBUG and SPI1PASSTHRU functions with the pins
    that were already defined.
    
    The notation used in the datasheet's multi-function pin table for the SoC is
    often creative: in this case the SYS* signals are enabled by a single bit,
    which is nothing unusual on its own, but in this case the bit was also
    participating in a multi-bit bitfield and therefore represented multiple
    functions. This fact was overlooked in the original patch.
    
    Fixes: 56e57cb6c07f (pinctrl: Add pinctrl-aspeed-g5 driver)
    Signed-off-by: Andrew Jeffery <[email protected]>
    Reviewed-by: Joel Stanley <[email protected]>
    Acked-by: Rob Herring <[email protected]>
    Signed-off-by: Linus Walleij <[email protected]>

commit d125b9695f1169697a975f7348048319087916f5
Author: Andrew Jeffery <[email protected]>
Date:   Wed Sep 28 00:20:15 2016 +0930

    pinctrl: aspeed-g5: Fix GPIOE1 typo
    
    This prevented C20 from successfully being muxed as GPIO.
    
    Fixes: 56e57cb6c07f (pinctrl: Add pinctrl-aspeed-g5 driver)
    Signed-off-by: Andrew Jeffery <[email protected]>
    Reviewed-by: Joel Stanley <[email protected]>
    Signed-off-by: Linus Walleij <[email protected]>

commit 9b3c54518669e1ac87fb3262e78a8cd78e9c07e4
Author: Andrew Jeffery <[email protected]>
Date:   Wed Sep 28 00:20:14 2016 +0930

    pinctrl: aspeed-g5: Fix names of GPID2 pins
    
    Fixes simple typos in the initial commit. There is no behavioural
    change.
    
    Fixes: 56e57cb6c07f (pinctrl: Add pinctrl-aspeed-g5 driver)
    Reported-by: Xo Wang <[email protected]>
    Signed-off-by: Andrew Jeffery <[email protected]>
    Reviewed-by: Joel Stanley <[email protected]>
    Signed-off-by: Linus Walleij <[email protected]>

commit 2dd1fb71b8a78a37bb3916dec64ffa71d4e28ff1
Author: Andrew Jeffery <[email protected]>
Date:   Wed Sep 28 00:20:13 2016 +0930

    pinctrl: aspeed: "Not enabled" is a significant mux state
    
    Consider a scenario with one pin P that has two signals A and B, where A
    is defined to be higher priority than B: That is, if the mux IP is in a
    state that would consider both A and B to be active on P, then A will be
    the active signal.
    
    To instead configure B as the active signal we must configure the mux so
    that A is inactive. The mux state for signals can be described by
    logical operations on one or more bits from one or more registers (a
    "signal expression"), which in some cases leads to aliased mux states for
    a particular signal. Further, signals described by multi-bit bitfields
    often do not only need to record the states that would make them active
    (the "enable" expressions), but also the states that makes them inactive
    (the "disable" expressions). All of this combined leads to four possible
    states for a signal:
    
             1. A signal is active with respect to an "enable" expression
             2. A signal is not active with respect to an "enable" expression
             3. A signal is inactive with respect to a "disable" expression
             4. A signal is not inactive with respect to a "disable" expression
    
    In the case of P, if we are looking to activate B without explicitly
    having configured A it's enough to consider A inactive if all of A's
    "enable" signal expressions evaluate to "not active". If any evaluate to
    "active" then the corresponding "disable" states must be applied so it
    becomes inactive.
    
    For example, on the AST2400 the pins composing GPIO bank H provide
    signals ROMD8 through ROMD15 (high priority) and those for UART6 (low
    priority). The mux states for ROMD8 through ROMD15 are aliased, i.e.
    there are two mux states that result in the respective signals being
    configured:
    
             A. SCU90[6]=1
             B. Strap[4,1:0]=100
    
    Further, the second mux state is a 3-bit bitfield that explicitly
    defines the enabled state but the disabled state is implicit, i.e. if
    Strap[4,1:0] is not exactly "100" then ROMD8 through ROMD15 are not
    considered active. This requires the mux function evaluation logic to
    use approach 2. above, however the existing code was using approach 3.
    The problem was brought to light on the Palmetto machines where the
    strap register value is 0x120ce416, and prevented GPIO requests in bank
    H from succeeding despite the hardware being in a position to allow
    them.
    
    Fixes: 318398c09a8d ("pinctrl: Add core pinctrl support for Aspeed SoCs")
    Signed-off-by: Andrew Jeffery <[email protected]>
    Reviewed-by: Joel Stanley <[email protected]>
    Signed-off-by: Linus Walleij <[email protected]>

commit 6f97077ff6ef28e0f3b361b6ba9c95a222ef384b
Author: Darrick J. Wong <[email protected]>
Date:   Mon Oct 10 17:23:07 2016 +1100

    xfs: rework refcount cow recovery error handling
    
    The error handling in xfs_refcount_recover_cow_leftovers is confused
    and can potentially leak memory, so rework it to release resources
    correctly on error.
    
    Signed-off-by: Darrick J. Wong <[email protected]>
    Reported-by: Brian Foster <[email protected]>
    Reviewed-by: Dave Chinner <[email protected]>
    Signed-off-by: Dave Chinner <[email protected]>

commit 1987fd743415564e8c67f2f7ec0ae3c18a6b11cd
Author: Darrick J. Wong <[email protected]>
Date:   Mon Oct 10 16:49:29 2016 +1100

    xfs: clear reflink flag if setting realtime flag
    
    Since we can only turn on the rt flag if there are no data extents,
    we can safely turn off the reflink flag if the rt flag is being
    turned on.
    
    Signed-off-by: Darrick J. Wong <[email protected]>
    Reported-by: Brian Foster <[email protected]>
    Reviewed-by: Dave Chinner <[email protected]>
    Signed-off-by: Dave Chinner <[email protected]>

commit 9780643cde26406d324413ae5c51e772144533bc
Author: Darrick J. Wong <[email protected]>
Date:   Mon Oct 10 16:49:18 2016 +1100

    xfs: fix error initialization
    
    Eric Sandeen reported a gcc complaint about uninitialized error
    variables, so fix that.
    
    Signed-off-by: Darrick J. Wong <[email protected]>
    Reported-by: Eric Sandeen <[email protected]>
    Reviewed-by: Dave Chinner <[email protected]>
    Signed-off-by: Dave Chinner <[email protected]>

commit 93fed47013b3c17318968cad0e81bd74196798c4
Author: Darrick J. Wong <[email protected]>
Date:   Mon Oct 10 16:49:10 2016 +1100

    xfs: fix label inaccuracies
    
    Since we don't unlock anything on the way out, change the label.
    
    Signed-off-by: Darrick J. Wong <[email protected]>
    Reported-by: Brian Foster <[email protected]>
    Reviewed-by: Dave Chinner <[email protected]>
    Signed-off-by: Dave Chinner <[email protected]>

commit 97a1b87ea7b2884fa9516c646385ca25475c4760
Author: Darrick J. Wong <[email protected]>
Date:   Mon Oct 10 16:49:01 2016 +1100

    xfs: remove isize check from unshare operation
    
    Now that fallocate has an explicit unshare flag again, let's try
    to remove the inode reflink flag whenever the user unshares any
    part of a file since checking is cheap compared to the CoW.
    
    Signed-off-by: Darrick J. Wong <[email protected]>
    Reported-by: Brian Foster <[email protected]>
    Reviewed-by: Dave Chinner <[email protected]>
    Signed-off-by: Dave Chinner <[email protected]>

commit 024adf48702212b0af15c682a7ff9773e1e092d6
Author: Darrick J. Wong <[email protected]>
Date:   Mon Oct 10 16:47:40 2016 +1100

    xfs: reduce stack usage of _reflink_clear_inode_flag
    
    The loop in _reflink_clear_inode_flag isn't necessary since we
    jump out if any part of any extent is shared.  Remove the loop
    and we no longer need two maps, so we can save some stack use.
    
    Signed-off-by: Darrick J. Wong <[email protected]>
    Reported-by: Brian Foster <[email protected]>
    Reviewed-by: Dave Chinner <[email protected]>
    Signed-off-by: Dave Chinner <[email protected]>

commit 63646fc58d666f149b85ccf470bfc1576a779d4c
Author: Darrick J. Wong <[email protected]>
Date:   Mon Oct 10 16:47:32 2016 +1100

    xfs: check inode reflink flag before calling reflink functions
    
    There are a couple of places where we don't check the inode's
    reflink flag before calling into the reflink code.  Fix those,
    and add some asserts so we don't make this mistake again.
    
    Signed-off-by: Darrick J. Wong <[email protected]>
    Reported-by: Brian Foster <[email protected]>
    Reviewed-by: Dave Chinner <[email protected]>
    Si…
laijs pushed a commit to laijs/linux that referenced this pull request Feb 13, 2017
Merge pull request torvalds#130 from pscollins/free-all-mem
21089ed 
Free all memory allocated by LKL (except for undetached pthreads)
iaguis pushed a commit to kinvolk/linux that referenced this pull request Feb 6, 2018
@dm0-
Merge pull request torvalds#130 from coreosbot/v4.14.12-coreos
56e1b19 
Rebase patches onto 4.14.12
jglathe pushed a commit to jglathe/linux_ms_dev_kit that referenced this pull request Aug 11, 2023
@qzed @jglathe
Merge pull request torvalds#130 from nickdepinet/wdk2023-acpi-smmu
169f5f3 
add wdk2023 acpi to smmu platlist
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Aug 11, 2023
@pv @Vudentz
Bluetooth: ISO: do not emit new LE Create CIS if previous is pending
7f74563 
LE Create CIS command shall not be sent before all CIS Established
events from its previous invocation have been processed. Currently it is
sent via hci_sync but that only waits for the first event, but there can
be multiple.

Make it wait for all events, and simplify the CIS creation as follows:

Add new flag HCI_CONN_CREATE_CIS, which is set if Create CIS has been
sent for the connection but it is not yet completed.

Make BT_CONNECT state to mean the connection wants Create CIS.

On events after which new Create CIS may need to be sent, send it if
possible and some connections need it. These events are:
hci_connect_cis, iso_connect_cfm, hci_cs_le_create_cis,
hci_le_cis_estabilished_evt.

The Create CIS status/completion events shall queue new Create CIS only
if at least one of the connections transitions away from BT_CONNECT, so
that we don't loop if controller is sending bogus events.

This fixes sending multiple CIS Create for the same CIS in the
"ISO AC 6(i) - Success" BlueZ test case:

< HCI Command: LE Create Co.. (0x08|0x0064) plen 9  torvalds#129 [hci0]
        Number of CIS: 2
        CIS Handle: 257
        ACL Handle: 42
        CIS Handle: 258
        ACL Handle: 42
> HCI Event: Command Status (0x0f) plen 4           torvalds#130 [hci0]
      LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1
        Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 29           torvalds#131 [hci0]
      LE Connected Isochronous Stream Established (0x19)
        Status: Success (0x00)
        Connection Handle: 257
        ...
< HCI Command: LE Setup Is.. (0x08|0x006e) plen 13  torvalds#132 [hci0]
        ...
> HCI Event: Command Complete (0x0e) plen 6         torvalds#133 [hci0]
      LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1
        ...
< HCI Command: LE Create Co.. (0x08|0x0064) plen 5  torvalds#134 [hci0]
        Number of CIS: 1
        CIS Handle: 258
        ACL Handle: 42
> HCI Event: Command Status (0x0f) plen 4           torvalds#135 [hci0]
      LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1
        Status: ACL Connection Already Exists (0x0b)
> HCI Event: LE Meta Event (0x3e) plen 29           torvalds#136 [hci0]
      LE Connected Isochronous Stream Established (0x19)
        Status: Success (0x00)
        Connection Handle: 258
        ...

Fixes: c09b80b ("Bluetooth: hci_conn: Fix not waiting for HCI_EVT_LE_CIS_ESTABLISHED")
Signed-off-by: Pauli Virtanen <[email protected]>
Signed-off-by: Luiz Augusto von Dentz <[email protected]>
Kaz205 pushed a commit to Kaz205/linux that referenced this pull request Sep 11, 2023
@pv @gregkh
Bluetooth: ISO: do not emit new LE Create CIS if previous is pending
e5931e6 
[ Upstream commit 7f74563 ]

LE Create CIS command shall not be sent before all CIS Established
events from its previous invocation have been processed. Currently it is
sent via hci_sync but that only waits for the first event, but there can
be multiple.

Make it wait for all events, and simplify the CIS creation as follows:

Add new flag HCI_CONN_CREATE_CIS, which is set if Create CIS has been
sent for the connection but it is not yet completed.

Make BT_CONNECT state to mean the connection wants Create CIS.

On events after which new Create CIS may need to be sent, send it if
possible and some connections need it. These events are:
hci_connect_cis, iso_connect_cfm, hci_cs_le_create_cis,
hci_le_cis_estabilished_evt.

The Create CIS status/completion events shall queue new Create CIS only
if at least one of the connections transitions away from BT_CONNECT, so
that we don't loop if controller is sending bogus events.

This fixes sending multiple CIS Create for the same CIS in the
"ISO AC 6(i) - Success" BlueZ test case:

< HCI Command: LE Create Co.. (0x08|0x0064) plen 9  torvalds#129 [hci0]
        Number of CIS: 2
        CIS Handle: 257
        ACL Handle: 42
        CIS Handle: 258
        ACL Handle: 42
> HCI Event: Command Status (0x0f) plen 4           torvalds#130 [hci0]
      LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1
        Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 29           torvalds#131 [hci0]
      LE Connected Isochronous Stream Established (0x19)
        Status: Success (0x00)
        Connection Handle: 257
        ...
< HCI Command: LE Setup Is.. (0x08|0x006e) plen 13  torvalds#132 [hci0]
        ...
> HCI Event: Command Complete (0x0e) plen 6         torvalds#133 [hci0]
      LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1
        ...
< HCI Command: LE Create Co.. (0x08|0x0064) plen 5  torvalds#134 [hci0]
        Number of CIS: 1
        CIS Handle: 258
        ACL Handle: 42
> HCI Event: Command Status (0x0f) plen 4           torvalds#135 [hci0]
      LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1
        Status: ACL Connection Already Exists (0x0b)
> HCI Event: LE Meta Event (0x3e) plen 29           torvalds#136 [hci0]
      LE Connected Isochronous Stream Established (0x19)
        Status: Success (0x00)
        Connection Handle: 258
        ...

Fixes: c09b80b ("Bluetooth: hci_conn: Fix not waiting for HCI_EVT_LE_CIS_ESTABLISHED")
Signed-off-by: Pauli Virtanen <[email protected]>
Signed-off-by: Luiz Augusto von Dentz <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
mj22226 pushed a commit to mj22226/linux that referenced this pull request Sep 11, 2023
@pv @gregkh
Bluetooth: ISO: do not emit new LE Create CIS if previous is pending
153e58a 
[ Upstream commit 7f74563 ]

LE Create CIS command shall not be sent before all CIS Established
events from its previous invocation have been processed. Currently it is
sent via hci_sync but that only waits for the first event, but there can
be multiple.

Make it wait for all events, and simplify the CIS creation as follows:

Add new flag HCI_CONN_CREATE_CIS, which is set if Create CIS has been
sent for the connection but it is not yet completed.

Make BT_CONNECT state to mean the connection wants Create CIS.

On events after which new Create CIS may need to be sent, send it if
possible and some connections need it. These events are:
hci_connect_cis, iso_connect_cfm, hci_cs_le_create_cis,
hci_le_cis_estabilished_evt.

The Create CIS status/completion events shall queue new Create CIS only
if at least one of the connections transitions away from BT_CONNECT, so
that we don't loop if controller is sending bogus events.

This fixes sending multiple CIS Create for the same CIS in the
"ISO AC 6(i) - Success" BlueZ test case:

< HCI Command: LE Create Co.. (0x08|0x0064) plen 9  torvalds#129 [hci0]
        Number of CIS: 2
        CIS Handle: 257
        ACL Handle: 42
        CIS Handle: 258
        ACL Handle: 42
> HCI Event: Command Status (0x0f) plen 4           torvalds#130 [hci0]
      LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1
        Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 29           torvalds#131 [hci0]
      LE Connected Isochronous Stream Established (0x19)
        Status: Success (0x00)
        Connection Handle: 257
        ...
< HCI Command: LE Setup Is.. (0x08|0x006e) plen 13  torvalds#132 [hci0]
        ...
> HCI Event: Command Complete (0x0e) plen 6         torvalds#133 [hci0]
      LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1
        ...
< HCI Command: LE Create Co.. (0x08|0x0064) plen 5  torvalds#134 [hci0]
        Number of CIS: 1
        CIS Handle: 258
        ACL Handle: 42
> HCI Event: Command Status (0x0f) plen 4           torvalds#135 [hci0]
      LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1
        Status: ACL Connection Already Exists (0x0b)
> HCI Event: LE Meta Event (0x3e) plen 29           torvalds#136 [hci0]
      LE Connected Isochronous Stream Established (0x19)
        Status: Success (0x00)
        Connection Handle: 258
        ...

Fixes: c09b80b ("Bluetooth: hci_conn: Fix not waiting for HCI_EVT_LE_CIS_ESTABLISHED")
Signed-off-by: Pauli Virtanen <[email protected]>
Signed-off-by: Luiz Augusto von Dentz <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
intersectRaven pushed a commit to intersectRaven/linux that referenced this pull request Sep 13, 2023
@pv @gregkh
Bluetooth: ISO: do not emit new LE Create CIS if previous is pending
722b0fb 
[ Upstream commit 7f74563 ]

LE Create CIS command shall not be sent before all CIS Established
events from its previous invocation have been processed. Currently it is
sent via hci_sync but that only waits for the first event, but there can
be multiple.

Make it wait for all events, and simplify the CIS creation as follows:

Add new flag HCI_CONN_CREATE_CIS, which is set if Create CIS has been
sent for the connection but it is not yet completed.

Make BT_CONNECT state to mean the connection wants Create CIS.

On events after which new Create CIS may need to be sent, send it if
possible and some connections need it. These events are:
hci_connect_cis, iso_connect_cfm, hci_cs_le_create_cis,
hci_le_cis_estabilished_evt.

The Create CIS status/completion events shall queue new Create CIS only
if at least one of the connections transitions away from BT_CONNECT, so
that we don't loop if controller is sending bogus events.

This fixes sending multiple CIS Create for the same CIS in the
"ISO AC 6(i) - Success" BlueZ test case:

< HCI Command: LE Create Co.. (0x08|0x0064) plen 9  torvalds#129 [hci0]
        Number of CIS: 2
        CIS Handle: 257
        ACL Handle: 42
        CIS Handle: 258
        ACL Handle: 42
> HCI Event: Command Status (0x0f) plen 4           torvalds#130 [hci0]
      LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1
        Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 29           torvalds#131 [hci0]
      LE Connected Isochronous Stream Established (0x19)
        Status: Success (0x00)
        Connection Handle: 257
        ...
< HCI Command: LE Setup Is.. (0x08|0x006e) plen 13  torvalds#132 [hci0]
        ...
> HCI Event: Command Complete (0x0e) plen 6         torvalds#133 [hci0]
      LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1
        ...
< HCI Command: LE Create Co.. (0x08|0x0064) plen 5  torvalds#134 [hci0]
        Number of CIS: 1
        CIS Handle: 258
        ACL Handle: 42
> HCI Event: Command Status (0x0f) plen 4           torvalds#135 [hci0]
      LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1
        Status: ACL Connection Already Exists (0x0b)
> HCI Event: LE Meta Event (0x3e) plen 29           torvalds#136 [hci0]
      LE Connected Isochronous Stream Established (0x19)
        Status: Success (0x00)
        Connection Handle: 258
        ...

Fixes: c09b80b ("Bluetooth: hci_conn: Fix not waiting for HCI_EVT_LE_CIS_ESTABLISHED")
Signed-off-by: Pauli Virtanen <[email protected]>
Signed-off-by: Luiz Augusto von Dentz <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
hjl-tools pushed a commit to hjl-tools/linux that referenced this pull request Sep 13, 2023
@pv @gregkh
Bluetooth: ISO: do not emit new LE Create CIS if previous is pending
2bc7129 
[ Upstream commit 7f74563 ]

LE Create CIS command shall not be sent before all CIS Established
events from its previous invocation have been processed. Currently it is
sent via hci_sync but that only waits for the first event, but there can
be multiple.

Make it wait for all events, and simplify the CIS creation as follows:

Add new flag HCI_CONN_CREATE_CIS, which is set if Create CIS has been
sent for the connection but it is not yet completed.

Make BT_CONNECT state to mean the connection wants Create CIS.

On events after which new Create CIS may need to be sent, send it if
possible and some connections need it. These events are:
hci_connect_cis, iso_connect_cfm, hci_cs_le_create_cis,
hci_le_cis_estabilished_evt.

The Create CIS status/completion events shall queue new Create CIS only
if at least one of the connections transitions away from BT_CONNECT, so
that we don't loop if controller is sending bogus events.

This fixes sending multiple CIS Create for the same CIS in the
"ISO AC 6(i) - Success" BlueZ test case:

< HCI Command: LE Create Co.. (0x08|0x0064) plen 9  torvalds#129 [hci0]
        Number of CIS: 2
        CIS Handle: 257
        ACL Handle: 42
        CIS Handle: 258
        ACL Handle: 42
> HCI Event: Command Status (0x0f) plen 4           torvalds#130 [hci0]
      LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1
        Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 29           torvalds#131 [hci0]
      LE Connected Isochronous Stream Established (0x19)
        Status: Success (0x00)
        Connection Handle: 257
        ...
< HCI Command: LE Setup Is.. (0x08|0x006e) plen 13  torvalds#132 [hci0]
        ...
> HCI Event: Command Complete (0x0e) plen 6         torvalds#133 [hci0]
      LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1
        ...
< HCI Command: LE Create Co.. (0x08|0x0064) plen 5  torvalds#134 [hci0]
        Number of CIS: 1
        CIS Handle: 258
        ACL Handle: 42
> HCI Event: Command Status (0x0f) plen 4           torvalds#135 [hci0]
      LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1
        Status: ACL Connection Already Exists (0x0b)
> HCI Event: LE Meta Event (0x3e) plen 29           torvalds#136 [hci0]
      LE Connected Isochronous Stream Established (0x19)
        Status: Success (0x00)
        Connection Handle: 258
        ...

Fixes: c09b80b ("Bluetooth: hci_conn: Fix not waiting for HCI_EVT_LE_CIS_ESTABLISHED")
Signed-off-by: Pauli Virtanen <[email protected]>
Signed-off-by: Luiz Augusto von Dentz <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Joshua-Riek pushed a commit to Joshua-Riek/linux that referenced this pull request Oct 24, 2023
@pv
Bluetooth: ISO: do not emit new LE Create CIS if previous is pending
21319d2 
BugLink: https://bugs.launchpad.net/bugs/2035588

[ Upstream commit 7f74563 ]

LE Create CIS command shall not be sent before all CIS Established
events from its previous invocation have been processed. Currently it is
sent via hci_sync but that only waits for the first event, but there can
be multiple.

Make it wait for all events, and simplify the CIS creation as follows:

Add new flag HCI_CONN_CREATE_CIS, which is set if Create CIS has been
sent for the connection but it is not yet completed.

Make BT_CONNECT state to mean the connection wants Create CIS.

On events after which new Create CIS may need to be sent, send it if
possible and some connections need it. These events are:
hci_connect_cis, iso_connect_cfm, hci_cs_le_create_cis,
hci_le_cis_estabilished_evt.

The Create CIS status/completion events shall queue new Create CIS only
if at least one of the connections transitions away from BT_CONNECT, so
that we don't loop if controller is sending bogus events.

This fixes sending multiple CIS Create for the same CIS in the
"ISO AC 6(i) - Success" BlueZ test case:

< HCI Command: LE Create Co.. (0x08|0x0064) plen 9  torvalds#129 [hci0]
        Number of CIS: 2
        CIS Handle: 257
        ACL Handle: 42
        CIS Handle: 258
        ACL Handle: 42
> HCI Event: Command Status (0x0f) plen 4           torvalds#130 [hci0]
      LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1
        Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 29           torvalds#131 [hci0]
      LE Connected Isochronous Stream Established (0x19)
        Status: Success (0x00)
        Connection Handle: 257
        ...
< HCI Command: LE Setup Is.. (0x08|0x006e) plen 13  torvalds#132 [hci0]
        ...
> HCI Event: Command Complete (0x0e) plen 6         torvalds#133 [hci0]
      LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1
        ...
< HCI Command: LE Create Co.. (0x08|0x0064) plen 5  torvalds#134 [hci0]
        Number of CIS: 1
        CIS Handle: 258
        ACL Handle: 42
> HCI Event: Command Status (0x0f) plen 4           torvalds#135 [hci0]
      LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1
        Status: ACL Connection Already Exists (0x0b)
> HCI Event: LE Meta Event (0x3e) plen 29           torvalds#136 [hci0]
      LE Connected Isochronous Stream Established (0x19)
        Status: Success (0x00)
        Connection Handle: 258
        ...

Fixes: c09b80b ("Bluetooth: hci_conn: Fix not waiting for HCI_EVT_LE_CIS_ESTABLISHED")
Signed-off-by: Pauli Virtanen <[email protected]>
Signed-off-by: Luiz Augusto von Dentz <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Andrea Righi <[email protected]>
MingcongBai pushed a commit to AOSC-Tracking/linux that referenced this pull request Dec 24, 2023
@chenhengqi @MingcongBai
LoongArch: BPF: Support 64-bit pointers to kfuncs
dbbb061 
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs")
for s390x, add support for 64-bit pointers to kfuncs for LoongArch.
Since the infrastructure is already implemented in BPF core, the only
thing need to be done is to override bpf_jit_supports_far_kfunc_call().

Before this change, several test_verifier tests failed:

  # ./test_verifier | grep # | grep FAIL
  torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL
  torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL
  torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL
  torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL
  torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL
  torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL
  torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL
  torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL
  torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL
  torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL
  torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL

This is because the kfuncs in the loaded module are far away from
__bpf_call_base:

  ffff800002009440 t bpf_kfunc_call_test_fail1    [bpf_testmod]
  9000000002e128d8 T __bpf_call_base

The offset relative to __bpf_call_base does NOT fit in s32, which breaks
the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts
this limit.

Note that to reproduce the above result, tools/testing/selftests/bpf/config
should be applied, and run the test with JIT enabled, unpriv BPF enabled.

With this change, the test_verifier tests now all passed:

  # ./test_verifier
  ...
  Summary: 777 PASSED, 0 SKIPPED, 0 FAILED

Tested-by: Tiezhu Yang <[email protected]>
Signed-off-by: Hengqi Chen <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>
shikongzhineng pushed a commit to shikongzhineng/linux that referenced this pull request Dec 28, 2023
@chenhengqi @chenhuacai
LoongArch: BPF: Support 64-bit pointers to kfuncs
f96f76f 
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs")
for s390x, add support for 64-bit pointers to kfuncs for LoongArch.
Since the infrastructure is already implemented in BPF core, the only
thing need to be done is to override bpf_jit_supports_far_kfunc_call().

Before this change, several test_verifier tests failed:

  # ./test_verifier | grep # | grep FAIL
  torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL
  torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL
  torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL
  torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL
  torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL
  torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL
  torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL
  torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL
  torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL
  torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL
  torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL

This is because the kfuncs in the loaded module are far away from
__bpf_call_base:

  ffff800002009440 t bpf_kfunc_call_test_fail1    [bpf_testmod]
  9000000002e128d8 T __bpf_call_base

The offset relative to __bpf_call_base does NOT fit in s32, which breaks
the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts
this limit.

Note that to reproduce the above result, tools/testing/selftests/bpf/config
should be applied, and run the test with JIT enabled, unpriv BPF enabled.

With this change, the test_verifier tests now all passed:

  # ./test_verifier
  ...
  Summary: 777 PASSED, 0 SKIPPED, 0 FAILED

Tested-by: Tiezhu Yang <[email protected]>
Signed-off-by: Hengqi Chen <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>
yetist pushed a commit to loongarchlinux/linux that referenced this pull request Jan 9, 2024
@chenhengqi @chenhuacai
LoongArch: BPF: Support 64-bit pointers to kfuncs
9ee9b61 
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs")
for s390x, add support for 64-bit pointers to kfuncs for LoongArch.
Since the infrastructure is already implemented in BPF core, the only
thing need to be done is to override bpf_jit_supports_far_kfunc_call().

Before this change, several test_verifier tests failed:

  # ./test_verifier | grep # | grep FAIL
  torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL
  torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL
  torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL
  torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL
  torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL
  torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL
  torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL
  torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL
  torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL
  torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL
  torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL

This is because the kfuncs in the loaded module are far away from
__bpf_call_base:

  ffff800002009440 t bpf_kfunc_call_test_fail1    [bpf_testmod]
  9000000002e128d8 T __bpf_call_base

The offset relative to __bpf_call_base does NOT fit in s32, which breaks
the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts
this limit.

Note that to reproduce the above result, tools/testing/selftests/bpf/config
should be applied, and run the test with JIT enabled, unpriv BPF enabled.

With this change, the test_verifier tests now all passed:

  # ./test_verifier
  ...
  Summary: 777 PASSED, 0 SKIPPED, 0 FAILED

Tested-by: Tiezhu Yang <[email protected]>
Signed-off-by: Hengqi Chen <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Jan 9, 2024
@chenhengqi @chenhuacai
LoongArch: BPF: Support 64-bit pointers to kfuncs
a812460 
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs")
for s390x, add support for 64-bit pointers to kfuncs for LoongArch.
Since the infrastructure is already implemented in BPF core, the only
thing need to be done is to override bpf_jit_supports_far_kfunc_call().

Before this change, several test_verifier tests failed:

  # ./test_verifier | grep # | grep FAIL
  torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL
  torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL
  torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL
  torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL
  torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL
  torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL
  torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL
  torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL
  torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL
  torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL
  torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL

This is because the kfuncs in the loaded module are far away from
__bpf_call_base:

  ffff800002009440 t bpf_kfunc_call_test_fail1    [bpf_testmod]
  9000000002e128d8 T __bpf_call_base

The offset relative to __bpf_call_base does NOT fit in s32, which breaks
the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts
this limit.

Note that to reproduce the above result, tools/testing/selftests/bpf/config
should be applied, and run the test with JIT enabled, unpriv BPF enabled.

With this change, the test_verifier tests now all passed:

  # ./test_verifier
  ...
  Summary: 777 PASSED, 0 SKIPPED, 0 FAILED

Tested-by: Tiezhu Yang <[email protected]>
Signed-off-by: Hengqi Chen <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>
arinc9 pushed a commit to arinc9/linux that referenced this pull request Jan 10, 2024
@chenhengqi @chenhuacai
LoongArch: BPF: Support 64-bit pointers to kfuncs
f107866 
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs")
for s390x, add support for 64-bit pointers to kfuncs for LoongArch.
Since the infrastructure is already implemented in BPF core, the only
thing need to be done is to override bpf_jit_supports_far_kfunc_call().

Before this change, several test_verifier tests failed:

  # ./test_verifier | grep # | grep FAIL
  torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL
  torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL
  torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL
  torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL
  torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL
  torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL
  torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL
  torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL
  torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL
  torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL
  torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL

This is because the kfuncs in the loaded module are far away from
__bpf_call_base:

  ffff800002009440 t bpf_kfunc_call_test_fail1    [bpf_testmod]
  9000000002e128d8 T __bpf_call_base

The offset relative to __bpf_call_base does NOT fit in s32, which breaks
the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts
this limit.

Note that to reproduce the above result, tools/testing/selftests/bpf/config
should be applied, and run the test with JIT enabled, unpriv BPF enabled.

With this change, the test_verifier tests now all passed:

  # ./test_verifier
  ...
  Summary: 777 PASSED, 0 SKIPPED, 0 FAILED

Tested-by: Tiezhu Yang <[email protected]>
Signed-off-by: Hengqi Chen <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>
shikongzhineng pushed a commit to shikongzhineng/linux that referenced this pull request Jan 10, 2024
@chenhengqi
LoongArch: BPF: Support 64-bit pointers to kfuncs
84aa5fa 
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs")
for s390x, add support for 64-bit pointers to kfuncs for LoongArch.
Since the infrastructure is already implemented in BPF core, the only
thing need to be done is to override bpf_jit_supports_far_kfunc_call().

Before this change, several test_verifier tests failed:

  # ./test_verifier | grep # | grep FAIL
  torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL
  torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL
  torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL
  torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL
  torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL
  torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL
  torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL
  torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL
  torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL
  torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL
  torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL

This is because the kfuncs in the loaded module are far away from
__bpf_call_base:

  ffff800002009440 t bpf_kfunc_call_test_fail1    [bpf_testmod]
  9000000002e128d8 T __bpf_call_base

The offset relative to __bpf_call_base does NOT fit in s32, which breaks
the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts
this limit.

Note that to reproduce the above result, tools/testing/selftests/bpf/config
should be applied, and run the test with JIT enabled, unpriv BPF enabled.

With this change, the test_verifier tests now all passed:

  # ./test_verifier
  ...
  Summary: 777 PASSED, 0 SKIPPED, 0 FAILED

Tested-by: Tiezhu Yang <[email protected]>
Signed-off-by: Hengqi Chen <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>
Gelbpunkt pushed a commit to sm8450-mainline/linux that referenced this pull request Jan 11, 2024
@chenhengqi @chenhuacai
LoongArch: BPF: Support 64-bit pointers to kfuncs
1800726 
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs")
for s390x, add support for 64-bit pointers to kfuncs for LoongArch.
Since the infrastructure is already implemented in BPF core, the only
thing need to be done is to override bpf_jit_supports_far_kfunc_call().

Before this change, several test_verifier tests failed:

  # ./test_verifier | grep # | grep FAIL
  torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL
  torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL
  torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL
  torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL
  torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL
  torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL
  torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL
  torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL
  torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL
  torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL
  torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL

This is because the kfuncs in the loaded module are far away from
__bpf_call_base:

  ffff800002009440 t bpf_kfunc_call_test_fail1    [bpf_testmod]
  9000000002e128d8 T __bpf_call_base

The offset relative to __bpf_call_base does NOT fit in s32, which breaks
the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts
this limit.

Note that to reproduce the above result, tools/testing/selftests/bpf/config
should be applied, and run the test with JIT enabled, unpriv BPF enabled.

With this change, the test_verifier tests now all passed:

  # ./test_verifier
  ...
  Summary: 777 PASSED, 0 SKIPPED, 0 FAILED

Tested-by: Tiezhu Yang <[email protected]>
Signed-off-by: Hengqi Chen <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Jan 12, 2024
@chenhengqi @chenhuacai
LoongArch: BPF: Support 64-bit pointers to kfuncs
3fcd196 
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs")
for s390x, add support for 64-bit pointers to kfuncs for LoongArch.
Since the infrastructure is already implemented in BPF core, the only
thing need to be done is to override bpf_jit_supports_far_kfunc_call().

Before this change, several test_verifier tests failed:

  # ./test_verifier | grep # | grep FAIL
  torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL
  torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL
  torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL
  torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL
  torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL
  torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL
  torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL
  torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL
  torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL
  torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL
  torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL

This is because the kfuncs in the loaded module are far away from
__bpf_call_base:

  ffff800002009440 t bpf_kfunc_call_test_fail1    [bpf_testmod]
  9000000002e128d8 T __bpf_call_base

The offset relative to __bpf_call_base does NOT fit in s32, which breaks
the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts
this limit.

Note that to reproduce the above result, tools/testing/selftests/bpf/config
should be applied, and run the test with JIT enabled, unpriv BPF enabled.

With this change, the test_verifier tests now all passed:

  # ./test_verifier
  ...
  Summary: 777 PASSED, 0 SKIPPED, 0 FAILED

Tested-by: Tiezhu Yang <[email protected]>
Signed-off-by: Hengqi Chen <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>
cthbleachbit pushed a commit to AOSC-Tracking/linux that referenced this pull request Jan 17, 2024
@chenhengqi @cthbleachbit
LoongArch: BPF: Support 64-bit pointers to kfuncs
464bc70 
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs")
for s390x, add support for 64-bit pointers to kfuncs for LoongArch.
Since the infrastructure is already implemented in BPF core, the only
thing need to be done is to override bpf_jit_supports_far_kfunc_call().

Before this change, several test_verifier tests failed:

  # ./test_verifier | grep # | grep FAIL
  torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL
  torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL
  torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL
  torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL
  torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL
  torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL
  torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL
  torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL
  torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL
  torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL
  torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL

This is because the kfuncs in the loaded module are far away from
__bpf_call_base:

  ffff800002009440 t bpf_kfunc_call_test_fail1    [bpf_testmod]
  9000000002e128d8 T __bpf_call_base

The offset relative to __bpf_call_base does NOT fit in s32, which breaks
the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts
this limit.

Note that to reproduce the above result, tools/testing/selftests/bpf/config
should be applied, and run the test with JIT enabled, unpriv BPF enabled.

With this change, the test_verifier tests now all passed:

  # ./test_verifier
  ...
  Summary: 777 PASSED, 0 SKIPPED, 0 FAILED

Tested-by: Tiezhu Yang <[email protected]>
Signed-off-by: Hengqi Chen <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>
cthbleachbit pushed a commit to AOSC-Tracking/linux that referenced this pull request Jan 17, 2024
@chenhengqi @cthbleachbit
LoongArch: BPF: Support 64-bit pointers to kfuncs
dc75a1e 
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs")
for s390x, add support for 64-bit pointers to kfuncs for LoongArch.
Since the infrastructure is already implemented in BPF core, the only
thing need to be done is to override bpf_jit_supports_far_kfunc_call().

Before this change, several test_verifier tests failed:

  # ./test_verifier | grep # | grep FAIL
  torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL
  torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL
  torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL
  torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL
  torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL
  torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL
  torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL
  torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL
  torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL
  torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL
  torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL

This is because the kfuncs in the loaded module are far away from
__bpf_call_base:

  ffff800002009440 t bpf_kfunc_call_test_fail1    [bpf_testmod]
  9000000002e128d8 T __bpf_call_base

The offset relative to __bpf_call_base does NOT fit in s32, which breaks
the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts
this limit.

Note that to reproduce the above result, tools/testing/selftests/bpf/config
should be applied, and run the test with JIT enabled, unpriv BPF enabled.

With this change, the test_verifier tests now all passed:

  # ./test_verifier
  ...
  Summary: 777 PASSED, 0 SKIPPED, 0 FAILED

Tested-by: Tiezhu Yang <[email protected]>
Signed-off-by: Hengqi Chen <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>
roxell pushed a commit to roxell/linux that referenced this pull request Jan 17, 2024
@chenhengqi @chenhuacai
LoongArch: BPF: Support 64-bit pointers to kfuncs
89c2f83 
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs")
for s390x, add support for 64-bit pointers to kfuncs for LoongArch.
Since the infrastructure is already implemented in BPF core, the only
thing need to be done is to override bpf_jit_supports_far_kfunc_call().

Before this change, several test_verifier tests failed:

  # ./test_verifier | grep # | grep FAIL
  torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL
  torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL
  torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL
  torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL
  torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL
  torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL
  torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL
  torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL
  torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL
  torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL
  torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL

This is because the kfuncs in the loaded module are far away from
__bpf_call_base:

  ffff800002009440 t bpf_kfunc_call_test_fail1    [bpf_testmod]
  9000000002e128d8 T __bpf_call_base

The offset relative to __bpf_call_base does NOT fit in s32, which breaks
the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts
this limit.

Note that to reproduce the above result, tools/testing/selftests/bpf/config
should be applied, and run the test with JIT enabled, unpriv BPF enabled.

With this change, the test_verifier tests now all passed:

  # ./test_verifier
  ...
  Summary: 777 PASSED, 0 SKIPPED, 0 FAILED

Tested-by: Tiezhu Yang <[email protected]>
Signed-off-by: Hengqi Chen <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>
cthbleachbit pushed a commit to AOSC-Tracking/linux that referenced this pull request Jan 17, 2024
@chenhengqi @cthbleachbit
LoongArch: BPF: Support 64-bit pointers to kfuncs
0e4c338 
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs")
for s390x, add support for 64-bit pointers to kfuncs for LoongArch.
Since the infrastructure is already implemented in BPF core, the only
thing need to be done is to override bpf_jit_supports_far_kfunc_call().

Before this change, several test_verifier tests failed:

  # ./test_verifier | grep # | grep FAIL
  torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL
  torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL
  torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL
  torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL
  torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL
  torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL
  torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL
  torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL
  torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL
  torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL
  torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL

This is because the kfuncs in the loaded module are far away from
__bpf_call_base:

  ffff800002009440 t bpf_kfunc_call_test_fail1    [bpf_testmod]
  9000000002e128d8 T __bpf_call_base

The offset relative to __bpf_call_base does NOT fit in s32, which breaks
the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts
this limit.

Note that to reproduce the above result, tools/testing/selftests/bpf/config
should be applied, and run the test with JIT enabled, unpriv BPF enabled.

With this change, the test_verifier tests now all passed:

  # ./test_verifier
  ...
  Summary: 777 PASSED, 0 SKIPPED, 0 FAILED

Tested-by: Tiezhu Yang <[email protected]>
Signed-off-by: Hengqi Chen <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Jan 18, 2024
@chenhengqi @chenhuacai
LoongArch: BPF: Support 64-bit pointers to kfuncs
21c5ae5 
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs")
for s390x, add support for 64-bit pointers to kfuncs for LoongArch.
Since the infrastructure is already implemented in BPF core, the only
thing need to be done is to override bpf_jit_supports_far_kfunc_call().

Before this change, several test_verifier tests failed:

  # ./test_verifier | grep # | grep FAIL
  torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL
  torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL
  torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL
  torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL
  torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL
  torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL
  torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL
  torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL
  torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL
  torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL
  torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL

This is because the kfuncs in the loaded module are far away from
__bpf_call_base:

  ffff800002009440 t bpf_kfunc_call_test_fail1    [bpf_testmod]
  9000000002e128d8 T __bpf_call_base

The offset relative to __bpf_call_base does NOT fit in s32, which breaks
the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts
this limit.

Note that to reproduce the above result, tools/testing/selftests/bpf/config
should be applied, and run the test with JIT enabled, unpriv BPF enabled.

With this change, the test_verifier tests now all passed:

  # ./test_verifier
  ...
  Summary: 777 PASSED, 0 SKIPPED, 0 FAILED

Tested-by: Tiezhu Yang <[email protected]>
Signed-off-by: Hengqi Chen <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>
cthbleachbit pushed a commit to AOSC-Tracking/linux that referenced this pull request Jan 28, 2024
@chenhengqi @cthbleachbit
LoongArch: BPF: Support 64-bit pointers to kfuncs
24b264e 
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs")
for s390x, add support for 64-bit pointers to kfuncs for LoongArch.
Since the infrastructure is already implemented in BPF core, the only
thing need to be done is to override bpf_jit_supports_far_kfunc_call().

Before this change, several test_verifier tests failed:

  # ./test_verifier | grep # | grep FAIL
  torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL
  torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL
  torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL
  torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL
  torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL
  torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL
  torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL
  torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL
  torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL
  torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL
  torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL

This is because the kfuncs in the loaded module are far away from
__bpf_call_base:

  ffff800002009440 t bpf_kfunc_call_test_fail1    [bpf_testmod]
  9000000002e128d8 T __bpf_call_base

The offset relative to __bpf_call_base does NOT fit in s32, which breaks
the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts
this limit.

Note that to reproduce the above result, tools/testing/selftests/bpf/config
should be applied, and run the test with JIT enabled, unpriv BPF enabled.

With this change, the test_verifier tests now all passed:

  # ./test_verifier
  ...
  Summary: 777 PASSED, 0 SKIPPED, 0 FAILED

Tested-by: Tiezhu Yang <[email protected]>
Signed-off-by: Hengqi Chen <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>
shikongzhineng pushed a commit to shikongzhineng/linux that referenced this pull request Feb 7, 2024
@chenhengqi
LoongArch: BPF: Support 64-bit pointers to kfuncs
9b079e5 
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs")
for s390x, add support for 64-bit pointers to kfuncs for LoongArch.
Since the infrastructure is already implemented in BPF core, the only
thing need to be done is to override bpf_jit_supports_far_kfunc_call().

Before this change, several test_verifier tests failed:

  # ./test_verifier | grep # | grep FAIL
  torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL
  torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL
  torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL
  torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL
  torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL
  torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL
  torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL
  torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL
  torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL
  torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL
  torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL

This is because the kfuncs in the loaded module are far away from
__bpf_call_base:

  ffff800002009440 t bpf_kfunc_call_test_fail1    [bpf_testmod]
  9000000002e128d8 T __bpf_call_base

The offset relative to __bpf_call_base does NOT fit in s32, which breaks
the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts
this limit.

Note that to reproduce the above result, tools/testing/selftests/bpf/config
should be applied, and run the test with JIT enabled, unpriv BPF enabled.

With this change, the test_verifier tests now all passed:

  # ./test_verifier
  ...
  Summary: 777 PASSED, 0 SKIPPED, 0 FAILED

Tested-by: Tiezhu Yang <[email protected]>
Signed-off-by: Hengqi Chen <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>
cthbleachbit pushed a commit to AOSC-Tracking/linux that referenced this pull request Feb 17, 2024
@chenhengqi @cthbleachbit
LoongArch: BPF: Support 64-bit pointers to kfuncs
92c8086 
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs")
for s390x, add support for 64-bit pointers to kfuncs for LoongArch.
Since the infrastructure is already implemented in BPF core, the only
thing need to be done is to override bpf_jit_supports_far_kfunc_call().

Before this change, several test_verifier tests failed:

  # ./test_verifier | grep # | grep FAIL
  torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL
  torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL
  torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL
  torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL
  torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL
  torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL
  torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL
  torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL
  torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL
  torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL
  torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL

This is because the kfuncs in the loaded module are far away from
__bpf_call_base:

  ffff800002009440 t bpf_kfunc_call_test_fail1    [bpf_testmod]
  9000000002e128d8 T __bpf_call_base

The offset relative to __bpf_call_base does NOT fit in s32, which breaks
the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts
this limit.

Note that to reproduce the above result, tools/testing/selftests/bpf/config
should be applied, and run the test with JIT enabled, unpriv BPF enabled.

With this change, the test_verifier tests now all passed:

  # ./test_verifier
  ...
  Summary: 777 PASSED, 0 SKIPPED, 0 FAILED

Tested-by: Tiezhu Yang <[email protected]>
Signed-off-by: Hengqi Chen <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>
yetist pushed a commit to loongarchlinux/linux that referenced this pull request Feb 29, 2024
@chenhengqi @yetist
LoongArch: BPF: Support 64-bit pointers to kfuncs
18598aa 
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs")
for s390x, add support for 64-bit pointers to kfuncs for LoongArch.
Since the infrastructure is already implemented in BPF core, the only
thing need to be done is to override bpf_jit_supports_far_kfunc_call().

Before this change, several test_verifier tests failed:

  # ./test_verifier | grep # | grep FAIL
  torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL
  torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL
  torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL
  torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL
  torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL
  torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL
  torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL
  torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL
  torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL
  torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL
  torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL

This is because the kfuncs in the loaded module are far away from
__bpf_call_base:

  ffff800002009440 t bpf_kfunc_call_test_fail1    [bpf_testmod]
  9000000002e128d8 T __bpf_call_base

The offset relative to __bpf_call_base does NOT fit in s32, which breaks
the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts
this limit.

Note that to reproduce the above result, tools/testing/selftests/bpf/config
should be applied, and run the test with JIT enabled, unpriv BPF enabled.

With this change, the test_verifier tests now all passed:

  # ./test_verifier
  ...
  Summary: 777 PASSED, 0 SKIPPED, 0 FAILED

Tested-by: Tiezhu Yang <[email protected]>
Signed-off-by: Hengqi Chen <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>
shikongzhineng pushed a commit to shikongzhineng/linux that referenced this pull request Mar 17, 2024
@chenhengqi
LoongArch: BPF: Support 64-bit pointers to kfuncs
26c030b 
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs")
for s390x, add support for 64-bit pointers to kfuncs for LoongArch.
Since the infrastructure is already implemented in BPF core, the only
thing need to be done is to override bpf_jit_supports_far_kfunc_call().

Before this change, several test_verifier tests failed:

  # ./test_verifier | grep # | grep FAIL
  torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL
  torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL
  torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL
  torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL
  torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL
  torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL
  torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL
  torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL
  torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL
  torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL
  torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL

This is because the kfuncs in the loaded module are far away from
__bpf_call_base:

  ffff800002009440 t bpf_kfunc_call_test_fail1    [bpf_testmod]
  9000000002e128d8 T __bpf_call_base

The offset relative to __bpf_call_base does NOT fit in s32, which breaks
the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts
this limit.

Note that to reproduce the above result, tools/testing/selftests/bpf/config
should be applied, and run the test with JIT enabled, unpriv BPF enabled.

With this change, the test_verifier tests now all passed:

  # ./test_verifier
  ...
  Summary: 777 PASSED, 0 SKIPPED, 0 FAILED

Tested-by: Tiezhu Yang <[email protected]>
Signed-off-by: Hengqi Chen <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>
shipujin pushed a commit to shipujin/linux that referenced this pull request Jul 24, 2024
@chenhengqi @chenhuacai
LoongArch: BPF: Support 64-bit pointers to kfuncs
87d1375 
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs")
for s390x, add support for 64-bit pointers to kfuncs for LoongArch.
Since the infrastructure is already implemented in BPF core, the only
thing need to be done is to override bpf_jit_supports_far_kfunc_call().

Before this change, several test_verifier tests failed:

  # ./test_verifier | grep # | grep FAIL
  torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL
  torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL
  torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL
  torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL
  torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL
  torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL
  torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL
  torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL
  torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL
  torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL
  torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL

This is because the kfuncs in the loaded module are far away from
__bpf_call_base:

  ffff800002009440 t bpf_kfunc_call_test_fail1    [bpf_testmod]
  9000000002e128d8 T __bpf_call_base

The offset relative to __bpf_call_base does NOT fit in s32, which breaks
the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts
this limit.

Note that to reproduce the above result, tools/testing/selftests/bpf/config
should be applied, and run the test with JIT enabled, unpriv BPF enabled.

With this change, the test_verifier tests now all passed:

  # ./test_verifier
  ...
  Summary: 777 PASSED, 0 SKIPPED, 0 FAILED

Tested-by: Tiezhu Yang <[email protected]>
Signed-off-by: Hengqi Chen <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Oct 17, 2024
@namhyung @intel-lab-lkp
selftests/bpf: Add a test for open coded kmem_cache iter
5ff2669 
The new subtest is attached to sleepable fentry of syncfs() syscall.
It iterates the kmem_cache using bpf_for_each loop and count the number
of entries.  Finally it checks it with the number of entries from the
regular iterator.

  $ ./vmtest.sh -- ./test_progs -t kmem_cache_iter
  ...
  torvalds#130/1   kmem_cache_iter/check_task_struct:OK
  torvalds#130/2   kmem_cache_iter/check_slabinfo:OK
  torvalds#130/3   kmem_cache_iter/open_coded_iter:OK
  torvalds#130     kmem_cache_iter:OK
  Summary: 1/3 PASSED, 0 SKIPPED, 0 FAILED

Also simplify the code by using attach routine of the skeleton.

Signed-off-by: Namhyung Kim <[email protected]>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Oct 24, 2024
@namhyung @intel-lab-lkp
selftests/bpf: Add a test for open coded kmem_cache iter
d87d222 
The new subtest is attached to sleepable fentry of syncfs() syscall.
It iterates the kmem_cache using bpf_for_each loop and count the number
of entries.  Finally it checks it with the number of entries from the
regular iterator.

  $ ./vmtest.sh -- ./test_progs -t kmem_cache_iter
  ...
  torvalds#130/1   kmem_cache_iter/check_task_struct:OK
  torvalds#130/2   kmem_cache_iter/check_slabinfo:OK
  torvalds#130/3   kmem_cache_iter/open_coded_iter:OK
  torvalds#130     kmem_cache_iter:OK
  Summary: 1/3 PASSED, 0 SKIPPED, 0 FAILED

Also simplify the code by using attach routine of the skeleton.

Signed-off-by: Namhyung Kim <[email protected]>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Oct 30, 2024
@namhyung @intel-lab-lkp
selftests/bpf: Add a test for open coded kmem_cache iter
5c46462 
The new subtest runs with bpf_prog_test_run_opts() as a syscall prog.
It iterates the kmem_cache using bpf_for_each loop and count the number
of entries.  Finally it checks it with the number of entries from the
regular iterator.

  $ ./vmtest.sh -- ./test_progs -t kmem_cache_iter
  ...
  torvalds#130/1   kmem_cache_iter/check_task_struct:OK
  torvalds#130/2   kmem_cache_iter/check_slabinfo:OK
  torvalds#130/3   kmem_cache_iter/open_coded_iter:OK
  torvalds#130     kmem_cache_iter:OK
  Summary: 1/3 PASSED, 0 SKIPPED, 0 FAILED

Also simplify the code by using attach routine of the skeleton.

Signed-off-by: Namhyung Kim <[email protected]>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Nov 1, 2024
@namhyung
selftests/bpf: Add a test for open coded kmem_cache iter
e5e4799 
The new subtest runs with bpf_prog_test_run_opts() as a syscall prog.
It iterates the kmem_cache using bpf_for_each loop and count the number
of entries.  Finally it checks it with the number of entries from the
regular iterator.

  $ ./vmtest.sh -- ./test_progs -t kmem_cache_iter
  ...
  torvalds#130/1   kmem_cache_iter/check_task_struct:OK
  torvalds#130/2   kmem_cache_iter/check_slabinfo:OK
  torvalds#130/3   kmem_cache_iter/open_coded_iter:OK
  torvalds#130     kmem_cache_iter:OK
  Summary: 1/3 PASSED, 0 SKIPPED, 0 FAILED

Also simplify the code by using attach routine of the skeleton.

Signed-off-by: Namhyung Kim <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexei Starovoitov <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
1 participant
@dabrace