Merge pull request #1 from torvalds/master #238
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Update from original
torvalds
pushed a commit
that referenced
this pull request
May 14, 2016
Original implementation commit e54bcde ("arm64: eBPF JIT compiler") had the relevant code paths, but due to an oversight always fail jiting. As a result, we had been falling back to BPF interpreter whenever a BPF program has JMP_JSET_{X,K} instructions. With this fix, we confirm that the corresponding tests in lib/test_bpf continue to pass, and also jited. ... [ 2.784553] test_bpf: #30 JSET jited:1 188 192 197 PASS [ 2.791373] test_bpf: #31 tcpdump port 22 jited:1 325 677 625 PASS [ 2.808800] test_bpf: #32 tcpdump complex jited:1 323 731 991 PASS ... [ 3.190759] test_bpf: #237 JMP_JSET_K: if (0x3 & 0x2) return 1 jited:1 110 PASS [ 3.192524] test_bpf: #238 JMP_JSET_K: if (0x3 & 0xffffffff) return 1 jited:1 98 PASS [ 3.211014] test_bpf: #249 JMP_JSET_X: if (0x3 & 0x2) return 1 jited:1 120 PASS [ 3.212973] test_bpf: #250 JMP_JSET_X: if (0x3 & 0xffffffff) return 1 jited:1 89 PASS ... Fixes: e54bcde ("arm64: eBPF JIT compiler") Signed-off-by: Zi Shen Lim <[email protected]> Acked-by: Will Deacon <[email protected]> Acked-by: Yang Shi <[email protected]> Signed-off-by: David S. Miller <[email protected]>
gamvrosi
pushed a commit
to gamvrosi/duet-kernel
that referenced
this pull request
Jul 25, 2016
Original implementation commit e54bcde ("arm64: eBPF JIT compiler") had the relevant code paths, but due to an oversight always fail jiting. As a result, we had been falling back to BPF interpreter whenever a BPF program has JMP_JSET_{X,K} instructions. With this fix, we confirm that the corresponding tests in lib/test_bpf continue to pass, and also jited. ... [ 2.784553] test_bpf: torvalds#30 JSET jited:1 188 192 197 PASS [ 2.791373] test_bpf: torvalds#31 tcpdump port 22 jited:1 325 677 625 PASS [ 2.808800] test_bpf: torvalds#32 tcpdump complex jited:1 323 731 991 PASS ... [ 3.190759] test_bpf: torvalds#237 JMP_JSET_K: if (0x3 & 0x2) return 1 jited:1 110 PASS [ 3.192524] test_bpf: torvalds#238 JMP_JSET_K: if (0x3 & 0xffffffff) return 1 jited:1 98 PASS [ 3.211014] test_bpf: torvalds#249 JMP_JSET_X: if (0x3 & 0x2) return 1 jited:1 120 PASS [ 3.212973] test_bpf: torvalds#250 JMP_JSET_X: if (0x3 & 0xffffffff) return 1 jited:1 89 PASS ... Fixes: e54bcde ("arm64: eBPF JIT compiler") Signed-off-by: Zi Shen Lim <[email protected]> Acked-by: Will Deacon <[email protected]> Acked-by: Yang Shi <[email protected]> Signed-off-by: David S. Miller <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Nov 16, 2016
Something I missed before sending off the partial series was that the non-scheduler guc reset path was broken (in the full series, this is pushed to the execlists reset handler). The issue is that after a reset, we have to refill the GuC workqueues, which we do by resubmitting the requests. However, if we already have submitted them, the fences within them have already been used and triggering them again is an error. Instead, just repopulate the guc workqueue. [ 115.858560] [IGT] gem_busy: starting subtest hang-render [ 135.839867] [drm] GPU HANG: ecode 9:0:0xe757fefe, in gem_busy [1716], reason: Hang on render ring, action: reset [ 135.839902] drm/i915: Resetting chip after gpu hang [ 135.839957] [drm] RC6 on [ 135.858351] ------------[ cut here ]------------ [ 135.858357] WARNING: CPU: 2 PID: 45 at drivers/gpu/drm/i915/i915_sw_fence.c:108 i915_sw_fence_complete+0x25/0x30 [ 135.858357] Modules linked in: rfcomm bnep binfmt_misc nls_iso8859_1 input_leds snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core btusb btrtl snd_hwdep snd_pcm 8250_dw snd_seq_midi hid_lenovo snd_seq_midi_event snd_rawmidi iwlwifi x86_pkg_temp_thermal coretemp snd_seq crct10dif_pclmul snd_seq_device hci_uart snd_timer crc32_pclmul ghash_clmulni_intel idma64 aesni_intel virt_dma btbcm snd btqca aes_x86_64 btintel lrw cfg80211 bluetooth gf128mul glue_helper ablk_helper cryptd soundcore intel_lpss_pci intel_pch_thermal intel_lpss_acpi intel_lpss acpi_als mfd_core kfifo_buf acpi_pad industrialio autofs4 hid_plantronics usbhid dm_mirror dm_region_hash dm_log sdhci_pci ahci sdhci libahci i2c_hid hid [ 135.858389] CPU: 2 PID: 45 Comm: kworker/2:1 Tainted: G W 4.9.0-rc4+ torvalds#238 [ 135.858389] Hardware name: /NUC6i3SYB, BIOS SYSKLi35.86A.0024.2015.1027.2142 10/27/2015 [ 135.858392] Workqueue: events_long i915_hangcheck_elapsed [ 135.858394] ffffc900001bf9b8 ffffffff812bb238 0000000000000000 0000000000000000 [ 135.858396] ffffc900001bf9f8 ffffffff8104f621 0000006c00000000 ffff8808296137f8 [ 135.858398] 0000000000000a00 ffff8808457a0000 ffff880845764e60 ffff880845760000 [ 135.858399] Call Trace: [ 135.858403] [<ffffffff812bb238>] dump_stack+0x4d/0x65 [ 135.858405] [<ffffffff8104f621>] __warn+0xc1/0xe0 [ 135.858406] [<ffffffff8104f748>] warn_slowpath_null+0x18/0x20 [ 135.858408] [<ffffffff813f8c15>] i915_sw_fence_complete+0x25/0x30 [ 135.858410] [<ffffffff813f8fad>] i915_sw_fence_commit+0xd/0x30 [ 135.858412] [<ffffffff8142e591>] __i915_gem_request_submit+0xe1/0xf0 [ 135.858413] [<ffffffff8142e5c8>] i915_gem_request_submit+0x28/0x40 [ 135.858415] [<ffffffff814433e7>] i915_guc_submit+0x47/0x210 [ 135.858417] [<ffffffff81443e98>] i915_guc_submission_enable+0x468/0x540 [ 135.858419] [<ffffffff81442495>] intel_guc_setup+0x715/0x810 [ 135.858421] [<ffffffff8142b6b4>] i915_gem_init_hw+0x114/0x2a0 [ 135.858423] [<ffffffff813eeaa8>] i915_reset+0xe8/0x120 [ 135.858424] [<ffffffff813f3937>] i915_reset_and_wakeup+0x157/0x180 [ 135.858426] [<ffffffff813f79db>] i915_handle_error+0x1ab/0x230 [ 135.858428] [<ffffffff812c760d>] ? scnprintf+0x4d/0x90 [ 135.858430] [<ffffffff81435985>] i915_hangcheck_elapsed+0x275/0x3d0 [ 135.858432] [<ffffffff810668cf>] process_one_work+0x12f/0x410 [ 135.858433] [<ffffffff81066bf3>] worker_thread+0x43/0x4d0 [ 135.858435] [<ffffffff81066bb0>] ? process_one_work+0x410/0x410 [ 135.858436] [<ffffffff81066bb0>] ? process_one_work+0x410/0x410 [ 135.858438] [<ffffffff8106bbb4>] kthread+0xd4/0xf0 [ 135.858440] [<ffffffff8106bae0>] ? kthread_park+0x60/0x60 Fixes: d55ac5b ("drm/i915: Defer transfer onto execution timeline to actual hw submission") Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Nov 16, 2016
Something I missed before sending off the partial series was that the non-scheduler guc reset path was broken (in the full series, this is pushed to the execlists reset handler). The issue is that after a reset, we have to refill the GuC workqueues, which we do by resubmitting the requests. However, if we already have submitted them, the fences within them have already been used and triggering them again is an error. Instead, just repopulate the guc workqueue. [ 115.858560] [IGT] gem_busy: starting subtest hang-render [ 135.839867] [drm] GPU HANG: ecode 9:0:0xe757fefe, in gem_busy [1716], reason: Hang on render ring, action: reset [ 135.839902] drm/i915: Resetting chip after gpu hang [ 135.839957] [drm] RC6 on [ 135.858351] ------------[ cut here ]------------ [ 135.858357] WARNING: CPU: 2 PID: 45 at drivers/gpu/drm/i915/i915_sw_fence.c:108 i915_sw_fence_complete+0x25/0x30 [ 135.858357] Modules linked in: rfcomm bnep binfmt_misc nls_iso8859_1 input_leds snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core btusb btrtl snd_hwdep snd_pcm 8250_dw snd_seq_midi hid_lenovo snd_seq_midi_event snd_rawmidi iwlwifi x86_pkg_temp_thermal coretemp snd_seq crct10dif_pclmul snd_seq_device hci_uart snd_timer crc32_pclmul ghash_clmulni_intel idma64 aesni_intel virt_dma btbcm snd btqca aes_x86_64 btintel lrw cfg80211 bluetooth gf128mul glue_helper ablk_helper cryptd soundcore intel_lpss_pci intel_pch_thermal intel_lpss_acpi intel_lpss acpi_als mfd_core kfifo_buf acpi_pad industrialio autofs4 hid_plantronics usbhid dm_mirror dm_region_hash dm_log sdhci_pci ahci sdhci libahci i2c_hid hid [ 135.858389] CPU: 2 PID: 45 Comm: kworker/2:1 Tainted: G W 4.9.0-rc4+ torvalds#238 [ 135.858389] Hardware name: /NUC6i3SYB, BIOS SYSKLi35.86A.0024.2015.1027.2142 10/27/2015 [ 135.858392] Workqueue: events_long i915_hangcheck_elapsed [ 135.858394] ffffc900001bf9b8 ffffffff812bb238 0000000000000000 0000000000000000 [ 135.858396] ffffc900001bf9f8 ffffffff8104f621 0000006c00000000 ffff8808296137f8 [ 135.858398] 0000000000000a00 ffff8808457a0000 ffff880845764e60 ffff880845760000 [ 135.858399] Call Trace: [ 135.858403] [<ffffffff812bb238>] dump_stack+0x4d/0x65 [ 135.858405] [<ffffffff8104f621>] __warn+0xc1/0xe0 [ 135.858406] [<ffffffff8104f748>] warn_slowpath_null+0x18/0x20 [ 135.858408] [<ffffffff813f8c15>] i915_sw_fence_complete+0x25/0x30 [ 135.858410] [<ffffffff813f8fad>] i915_sw_fence_commit+0xd/0x30 [ 135.858412] [<ffffffff8142e591>] __i915_gem_request_submit+0xe1/0xf0 [ 135.858413] [<ffffffff8142e5c8>] i915_gem_request_submit+0x28/0x40 [ 135.858415] [<ffffffff814433e7>] i915_guc_submit+0x47/0x210 [ 135.858417] [<ffffffff81443e98>] i915_guc_submission_enable+0x468/0x540 [ 135.858419] [<ffffffff81442495>] intel_guc_setup+0x715/0x810 [ 135.858421] [<ffffffff8142b6b4>] i915_gem_init_hw+0x114/0x2a0 [ 135.858423] [<ffffffff813eeaa8>] i915_reset+0xe8/0x120 [ 135.858424] [<ffffffff813f3937>] i915_reset_and_wakeup+0x157/0x180 [ 135.858426] [<ffffffff813f79db>] i915_handle_error+0x1ab/0x230 [ 135.858428] [<ffffffff812c760d>] ? scnprintf+0x4d/0x90 [ 135.858430] [<ffffffff81435985>] i915_hangcheck_elapsed+0x275/0x3d0 [ 135.858432] [<ffffffff810668cf>] process_one_work+0x12f/0x410 [ 135.858433] [<ffffffff81066bf3>] worker_thread+0x43/0x4d0 [ 135.858435] [<ffffffff81066bb0>] ? process_one_work+0x410/0x410 [ 135.858436] [<ffffffff81066bb0>] ? process_one_work+0x410/0x410 [ 135.858438] [<ffffffff8106bbb4>] kthread+0xd4/0xf0 [ 135.858440] [<ffffffff8106bae0>] ? kthread_park+0x60/0x60 v2: Only resubmit submitted requests Fixes: d55ac5b ("drm/i915: Defer transfer onto execution timeline to actual hw submission") Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Nov 16, 2016
Something I missed before sending off the partial series was that the non-scheduler guc reset path was broken (in the full series, this is pushed to the execlists reset handler). The issue is that after a reset, we have to refill the GuC workqueues, which we do by resubmitting the requests. However, if we already have submitted them, the fences within them have already been used and triggering them again is an error. Instead, just repopulate the guc workqueue. [ 115.858560] [IGT] gem_busy: starting subtest hang-render [ 135.839867] [drm] GPU HANG: ecode 9:0:0xe757fefe, in gem_busy [1716], reason: Hang on render ring, action: reset [ 135.839902] drm/i915: Resetting chip after gpu hang [ 135.839957] [drm] RC6 on [ 135.858351] ------------[ cut here ]------------ [ 135.858357] WARNING: CPU: 2 PID: 45 at drivers/gpu/drm/i915/i915_sw_fence.c:108 i915_sw_fence_complete+0x25/0x30 [ 135.858357] Modules linked in: rfcomm bnep binfmt_misc nls_iso8859_1 input_leds snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core btusb btrtl snd_hwdep snd_pcm 8250_dw snd_seq_midi hid_lenovo snd_seq_midi_event snd_rawmidi iwlwifi x86_pkg_temp_thermal coretemp snd_seq crct10dif_pclmul snd_seq_device hci_uart snd_timer crc32_pclmul ghash_clmulni_intel idma64 aesni_intel virt_dma btbcm snd btqca aes_x86_64 btintel lrw cfg80211 bluetooth gf128mul glue_helper ablk_helper cryptd soundcore intel_lpss_pci intel_pch_thermal intel_lpss_acpi intel_lpss acpi_als mfd_core kfifo_buf acpi_pad industrialio autofs4 hid_plantronics usbhid dm_mirror dm_region_hash dm_log sdhci_pci ahci sdhci libahci i2c_hid hid [ 135.858389] CPU: 2 PID: 45 Comm: kworker/2:1 Tainted: G W 4.9.0-rc4+ torvalds#238 [ 135.858389] Hardware name: /NUC6i3SYB, BIOS SYSKLi35.86A.0024.2015.1027.2142 10/27/2015 [ 135.858392] Workqueue: events_long i915_hangcheck_elapsed [ 135.858394] ffffc900001bf9b8 ffffffff812bb238 0000000000000000 0000000000000000 [ 135.858396] ffffc900001bf9f8 ffffffff8104f621 0000006c00000000 ffff8808296137f8 [ 135.858398] 0000000000000a00 ffff8808457a0000 ffff880845764e60 ffff880845760000 [ 135.858399] Call Trace: [ 135.858403] [<ffffffff812bb238>] dump_stack+0x4d/0x65 [ 135.858405] [<ffffffff8104f621>] __warn+0xc1/0xe0 [ 135.858406] [<ffffffff8104f748>] warn_slowpath_null+0x18/0x20 [ 135.858408] [<ffffffff813f8c15>] i915_sw_fence_complete+0x25/0x30 [ 135.858410] [<ffffffff813f8fad>] i915_sw_fence_commit+0xd/0x30 [ 135.858412] [<ffffffff8142e591>] __i915_gem_request_submit+0xe1/0xf0 [ 135.858413] [<ffffffff8142e5c8>] i915_gem_request_submit+0x28/0x40 [ 135.858415] [<ffffffff814433e7>] i915_guc_submit+0x47/0x210 [ 135.858417] [<ffffffff81443e98>] i915_guc_submission_enable+0x468/0x540 [ 135.858419] [<ffffffff81442495>] intel_guc_setup+0x715/0x810 [ 135.858421] [<ffffffff8142b6b4>] i915_gem_init_hw+0x114/0x2a0 [ 135.858423] [<ffffffff813eeaa8>] i915_reset+0xe8/0x120 [ 135.858424] [<ffffffff813f3937>] i915_reset_and_wakeup+0x157/0x180 [ 135.858426] [<ffffffff813f79db>] i915_handle_error+0x1ab/0x230 [ 135.858428] [<ffffffff812c760d>] ? scnprintf+0x4d/0x90 [ 135.858430] [<ffffffff81435985>] i915_hangcheck_elapsed+0x275/0x3d0 [ 135.858432] [<ffffffff810668cf>] process_one_work+0x12f/0x410 [ 135.858433] [<ffffffff81066bf3>] worker_thread+0x43/0x4d0 [ 135.858435] [<ffffffff81066bb0>] ? process_one_work+0x410/0x410 [ 135.858436] [<ffffffff81066bb0>] ? process_one_work+0x410/0x410 [ 135.858438] [<ffffffff8106bbb4>] kthread+0xd4/0xf0 [ 135.858440] [<ffffffff8106bae0>] ? kthread_park+0x60/0x60 v2: Only resubmit submitted requests v3: Don't forget the pending requests have reserved space. Fixes: d55ac5b ("drm/i915: Defer transfer onto execution timeline to actual hw submission") Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Nov 17, 2016
Something I missed before sending off the partial series was that the non-scheduler guc reset path was broken (in the full series, this is pushed to the execlists reset handler). The issue is that after a reset, we have to refill the GuC workqueues, which we do by resubmitting the requests. However, if we already have submitted them, the fences within them have already been used and triggering them again is an error. Instead, just repopulate the guc workqueue. [ 115.858560] [IGT] gem_busy: starting subtest hang-render [ 135.839867] [drm] GPU HANG: ecode 9:0:0xe757fefe, in gem_busy [1716], reason: Hang on render ring, action: reset [ 135.839902] drm/i915: Resetting chip after gpu hang [ 135.839957] [drm] RC6 on [ 135.858351] ------------[ cut here ]------------ [ 135.858357] WARNING: CPU: 2 PID: 45 at drivers/gpu/drm/i915/i915_sw_fence.c:108 i915_sw_fence_complete+0x25/0x30 [ 135.858357] Modules linked in: rfcomm bnep binfmt_misc nls_iso8859_1 input_leds snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core btusb btrtl snd_hwdep snd_pcm 8250_dw snd_seq_midi hid_lenovo snd_seq_midi_event snd_rawmidi iwlwifi x86_pkg_temp_thermal coretemp snd_seq crct10dif_pclmul snd_seq_device hci_uart snd_timer crc32_pclmul ghash_clmulni_intel idma64 aesni_intel virt_dma btbcm snd btqca aes_x86_64 btintel lrw cfg80211 bluetooth gf128mul glue_helper ablk_helper cryptd soundcore intel_lpss_pci intel_pch_thermal intel_lpss_acpi intel_lpss acpi_als mfd_core kfifo_buf acpi_pad industrialio autofs4 hid_plantronics usbhid dm_mirror dm_region_hash dm_log sdhci_pci ahci sdhci libahci i2c_hid hid [ 135.858389] CPU: 2 PID: 45 Comm: kworker/2:1 Tainted: G W 4.9.0-rc4+ torvalds#238 [ 135.858389] Hardware name: /NUC6i3SYB, BIOS SYSKLi35.86A.0024.2015.1027.2142 10/27/2015 [ 135.858392] Workqueue: events_long i915_hangcheck_elapsed [ 135.858394] ffffc900001bf9b8 ffffffff812bb238 0000000000000000 0000000000000000 [ 135.858396] ffffc900001bf9f8 ffffffff8104f621 0000006c00000000 ffff8808296137f8 [ 135.858398] 0000000000000a00 ffff8808457a0000 ffff880845764e60 ffff880845760000 [ 135.858399] Call Trace: [ 135.858403] [<ffffffff812bb238>] dump_stack+0x4d/0x65 [ 135.858405] [<ffffffff8104f621>] __warn+0xc1/0xe0 [ 135.858406] [<ffffffff8104f748>] warn_slowpath_null+0x18/0x20 [ 135.858408] [<ffffffff813f8c15>] i915_sw_fence_complete+0x25/0x30 [ 135.858410] [<ffffffff813f8fad>] i915_sw_fence_commit+0xd/0x30 [ 135.858412] [<ffffffff8142e591>] __i915_gem_request_submit+0xe1/0xf0 [ 135.858413] [<ffffffff8142e5c8>] i915_gem_request_submit+0x28/0x40 [ 135.858415] [<ffffffff814433e7>] i915_guc_submit+0x47/0x210 [ 135.858417] [<ffffffff81443e98>] i915_guc_submission_enable+0x468/0x540 [ 135.858419] [<ffffffff81442495>] intel_guc_setup+0x715/0x810 [ 135.858421] [<ffffffff8142b6b4>] i915_gem_init_hw+0x114/0x2a0 [ 135.858423] [<ffffffff813eeaa8>] i915_reset+0xe8/0x120 [ 135.858424] [<ffffffff813f3937>] i915_reset_and_wakeup+0x157/0x180 [ 135.858426] [<ffffffff813f79db>] i915_handle_error+0x1ab/0x230 [ 135.858428] [<ffffffff812c760d>] ? scnprintf+0x4d/0x90 [ 135.858430] [<ffffffff81435985>] i915_hangcheck_elapsed+0x275/0x3d0 [ 135.858432] [<ffffffff810668cf>] process_one_work+0x12f/0x410 [ 135.858433] [<ffffffff81066bf3>] worker_thread+0x43/0x4d0 [ 135.858435] [<ffffffff81066bb0>] ? process_one_work+0x410/0x410 [ 135.858436] [<ffffffff81066bb0>] ? process_one_work+0x410/0x410 [ 135.858438] [<ffffffff8106bbb4>] kthread+0xd4/0xf0 [ 135.858440] [<ffffffff8106bae0>] ? kthread_park+0x60/0x60 v2: Only resubmit submitted requests v3: Don't forget the pending requests have reserved space. Fixes: d55ac5b ("drm/i915: Defer transfer onto execution timeline to actual hw submission") Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]>
mkuoppal
pushed a commit
to mkuoppal/linux
that referenced
this pull request
Dec 5, 2016
Something I missed before sending off the partial series was that the non-scheduler guc reset path was broken (in the full series, this is pushed to the execlists reset handler). The issue is that after a reset, we have to refill the GuC workqueues, which we do by resubmitting the requests. However, if we already have submitted them, the fences within them have already been used and triggering them again is an error. Instead, just repopulate the guc workqueue. [ 115.858560] [IGT] gem_busy: starting subtest hang-render [ 135.839867] [drm] GPU HANG: ecode 9:0:0xe757fefe, in gem_busy [1716], reason: Hang on render ring, action: reset [ 135.839902] drm/i915: Resetting chip after gpu hang [ 135.839957] [drm] RC6 on [ 135.858351] ------------[ cut here ]------------ [ 135.858357] WARNING: CPU: 2 PID: 45 at drivers/gpu/drm/i915/i915_sw_fence.c:108 i915_sw_fence_complete+0x25/0x30 [ 135.858357] Modules linked in: rfcomm bnep binfmt_misc nls_iso8859_1 input_leds snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core btusb btrtl snd_hwdep snd_pcm 8250_dw snd_seq_midi hid_lenovo snd_seq_midi_event snd_rawmidi iwlwifi x86_pkg_temp_thermal coretemp snd_seq crct10dif_pclmul snd_seq_device hci_uart snd_timer crc32_pclmul ghash_clmulni_intel idma64 aesni_intel virt_dma btbcm snd btqca aes_x86_64 btintel lrw cfg80211 bluetooth gf128mul glue_helper ablk_helper cryptd soundcore intel_lpss_pci intel_pch_thermal intel_lpss_acpi intel_lpss acpi_als mfd_core kfifo_buf acpi_pad industrialio autofs4 hid_plantronics usbhid dm_mirror dm_region_hash dm_log sdhci_pci ahci sdhci libahci i2c_hid hid [ 135.858389] CPU: 2 PID: 45 Comm: kworker/2:1 Tainted: G W 4.9.0-rc4+ torvalds#238 [ 135.858389] Hardware name: /NUC6i3SYB, BIOS SYSKLi35.86A.0024.2015.1027.2142 10/27/2015 [ 135.858392] Workqueue: events_long i915_hangcheck_elapsed [ 135.858394] ffffc900001bf9b8 ffffffff812bb238 0000000000000000 0000000000000000 [ 135.858396] ffffc900001bf9f8 ffffffff8104f621 0000006c00000000 ffff8808296137f8 [ 135.858398] 0000000000000a00 ffff8808457a0000 ffff880845764e60 ffff880845760000 [ 135.858399] Call Trace: [ 135.858403] [<ffffffff812bb238>] dump_stack+0x4d/0x65 [ 135.858405] [<ffffffff8104f621>] __warn+0xc1/0xe0 [ 135.858406] [<ffffffff8104f748>] warn_slowpath_null+0x18/0x20 [ 135.858408] [<ffffffff813f8c15>] i915_sw_fence_complete+0x25/0x30 [ 135.858410] [<ffffffff813f8fad>] i915_sw_fence_commit+0xd/0x30 [ 135.858412] [<ffffffff8142e591>] __i915_gem_request_submit+0xe1/0xf0 [ 135.858413] [<ffffffff8142e5c8>] i915_gem_request_submit+0x28/0x40 [ 135.858415] [<ffffffff814433e7>] i915_guc_submit+0x47/0x210 [ 135.858417] [<ffffffff81443e98>] i915_guc_submission_enable+0x468/0x540 [ 135.858419] [<ffffffff81442495>] intel_guc_setup+0x715/0x810 [ 135.858421] [<ffffffff8142b6b4>] i915_gem_init_hw+0x114/0x2a0 [ 135.858423] [<ffffffff813eeaa8>] i915_reset+0xe8/0x120 [ 135.858424] [<ffffffff813f3937>] i915_reset_and_wakeup+0x157/0x180 [ 135.858426] [<ffffffff813f79db>] i915_handle_error+0x1ab/0x230 [ 135.858428] [<ffffffff812c760d>] ? scnprintf+0x4d/0x90 [ 135.858430] [<ffffffff81435985>] i915_hangcheck_elapsed+0x275/0x3d0 [ 135.858432] [<ffffffff810668cf>] process_one_work+0x12f/0x410 [ 135.858433] [<ffffffff81066bf3>] worker_thread+0x43/0x4d0 [ 135.858435] [<ffffffff81066bb0>] ? process_one_work+0x410/0x410 [ 135.858436] [<ffffffff81066bb0>] ? process_one_work+0x410/0x410 [ 135.858438] [<ffffffff8106bbb4>] kthread+0xd4/0xf0 [ 135.858440] [<ffffffff8106bae0>] ? kthread_park+0x60/0x60 v2: Only resubmit submitted requests v3: Don't forget the pending requests have reserved space. Fixes: d55ac5b ("drm/i915: Defer transfer onto execution timeline to actual hw submission") Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
laijs
pushed a commit
to laijs/linux
that referenced
this pull request
Feb 13, 2017
Fix block device capacity
tiwai
added a commit
to tiwai/sound
that referenced
this pull request
Oct 9, 2017
The error path in podhd_init() tries to clear the pending timer, while the timer object is initialized at the end of init sequence, thus it may hit the uninitialized object, as spotted by syzkaller: INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 1 PID: 1845 Comm: kworker/1:2 Not tainted 4.14.0-rc2-42613-g1488251d1a98 torvalds#238 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:16 dump_stack+0x292/0x395 lib/dump_stack.c:52 register_lock_class+0x6c4/0x1a00 kernel/locking/lockdep.c:769 __lock_acquire+0x27e/0x4550 kernel/locking/lockdep.c:3385 lock_acquire+0x259/0x620 kernel/locking/lockdep.c:4002 del_timer_sync+0x12c/0x280 kernel/time/timer.c:1237 podhd_disconnect+0x8c/0x160 sound/usb/line6/podhd.c:299 line6_probe+0x844/0x1310 sound/usb/line6/driver.c:783 podhd_probe+0x64/0x70 sound/usb/line6/podhd.c:474 .... For addressing it, assure the initializations of timer and work by moving them to the beginning of podhd_init(). Fixes: 790869d ("ALSA: line6: Add support for POD X3") Reported-by: Andrey Konovalov <[email protected]> Tested-by: Andrey Konovalov <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
tiwai
added a commit
to tiwai/sound
that referenced
this pull request
Oct 11, 2017
As syzkaller spotted, currently bcd2000 driver submits a URB with the fixed EP without checking whether it's actually available, which may result in a kernel warning like: usb 1-1: BOGUS urb xfer, pipe 1 != type 3 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1846 at drivers/usb/core/urb.c:449 usb_submit_urb+0xf8a/0x11d0 Modules linked in: CPU: 0 PID: 1846 Comm: kworker/0:2 Not tainted 4.14.0-rc2-42613-g1488251d1a98 torvalds#238 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: bcd2000_init_device sound/usb/bcd2000/bcd2000.c:289 bcd2000_init_midi sound/usb/bcd2000/bcd2000.c:345 bcd2000_probe+0xe64/0x19e0 sound/usb/bcd2000/bcd2000.c:406 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361 .... This patch adds a sanity check of validity of EPs at the device initialization phase for avoiding the call with an invalid EP. Reported-by: Andrey Konovalov <[email protected]> Tested-by: Andrey Konovalov <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
tiwai
added a commit
to tiwai/sound
that referenced
this pull request
Oct 11, 2017
As syzkaller spotted, currently line6 drivers submit a URB with the fixed EP without checking whether it's actually available, which may result in a kernel warning like: usb 1-1: BOGUS urb xfer, pipe 3 != type 1 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 24 at drivers/usb/core/urb.c:449 usb_submit_urb+0xf8a/0x11d0 Modules linked in: CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc2-42613-g1488251d1a98 torvalds#238 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: line6_start_listen+0x55f/0x9e0 sound/usb/line6/driver.c:82 line6_init_cap_control sound/usb/line6/driver.c:690 line6_probe+0x7c9/0x1310 sound/usb/line6/driver.c:764 podhd_probe+0x64/0x70 sound/usb/line6/podhd.c:474 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361 .... This patch adds a sanity check of validity of EPs at the device initialization phase for avoiding the call with an invalid EP. Reported-by: Andrey Konovalov <[email protected]> Tested-by: Andrey Konovalov <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
Noltari
pushed a commit
to Noltari/linux
that referenced
this pull request
Oct 18, 2017
commit cb02ffc upstream. The error path in podhd_init() tries to clear the pending timer, while the timer object is initialized at the end of init sequence, thus it may hit the uninitialized object, as spotted by syzkaller: INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 1 PID: 1845 Comm: kworker/1:2 Not tainted 4.14.0-rc2-42613-g1488251d1a98 torvalds#238 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:16 dump_stack+0x292/0x395 lib/dump_stack.c:52 register_lock_class+0x6c4/0x1a00 kernel/locking/lockdep.c:769 __lock_acquire+0x27e/0x4550 kernel/locking/lockdep.c:3385 lock_acquire+0x259/0x620 kernel/locking/lockdep.c:4002 del_timer_sync+0x12c/0x280 kernel/time/timer.c:1237 podhd_disconnect+0x8c/0x160 sound/usb/line6/podhd.c:299 line6_probe+0x844/0x1310 sound/usb/line6/driver.c:783 podhd_probe+0x64/0x70 sound/usb/line6/podhd.c:474 .... For addressing it, assure the initializations of timer and work by moving them to the beginning of podhd_init(). Fixes: 790869d ("ALSA: line6: Add support for POD X3") Reported-by: Andrey Konovalov <[email protected]> Tested-by: Andrey Konovalov <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
heftig
referenced
this pull request
in zen-kernel/zen-kernel
Oct 18, 2017
commit cb02ffc upstream. The error path in podhd_init() tries to clear the pending timer, while the timer object is initialized at the end of init sequence, thus it may hit the uninitialized object, as spotted by syzkaller: INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 1 PID: 1845 Comm: kworker/1:2 Not tainted 4.14.0-rc2-42613-g1488251d1a98 #238 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:16 dump_stack+0x292/0x395 lib/dump_stack.c:52 register_lock_class+0x6c4/0x1a00 kernel/locking/lockdep.c:769 __lock_acquire+0x27e/0x4550 kernel/locking/lockdep.c:3385 lock_acquire+0x259/0x620 kernel/locking/lockdep.c:4002 del_timer_sync+0x12c/0x280 kernel/time/timer.c:1237 podhd_disconnect+0x8c/0x160 sound/usb/line6/podhd.c:299 line6_probe+0x844/0x1310 sound/usb/line6/driver.c:783 podhd_probe+0x64/0x70 sound/usb/line6/podhd.c:474 .... For addressing it, assure the initializations of timer and work by moving them to the beginning of podhd_init(). Fixes: 790869d ("ALSA: line6: Add support for POD X3") Reported-by: Andrey Konovalov <[email protected]> Tested-by: Andrey Konovalov <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
dcui
pushed a commit
to dcui/linux
that referenced
this pull request
Dec 5, 2017
BugLink: http://bugs.launchpad.net/bugs/1724669 commit cb02ffc upstream. The error path in podhd_init() tries to clear the pending timer, while the timer object is initialized at the end of init sequence, thus it may hit the uninitialized object, as spotted by syzkaller: INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 1 PID: 1845 Comm: kworker/1:2 Not tainted 4.14.0-rc2-42613-g1488251d1a98 torvalds#238 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:16 dump_stack+0x292/0x395 lib/dump_stack.c:52 register_lock_class+0x6c4/0x1a00 kernel/locking/lockdep.c:769 __lock_acquire+0x27e/0x4550 kernel/locking/lockdep.c:3385 lock_acquire+0x259/0x620 kernel/locking/lockdep.c:4002 del_timer_sync+0x12c/0x280 kernel/time/timer.c:1237 podhd_disconnect+0x8c/0x160 sound/usb/line6/podhd.c:299 line6_probe+0x844/0x1310 sound/usb/line6/driver.c:783 podhd_probe+0x64/0x70 sound/usb/line6/podhd.c:474 .... For addressing it, assure the initializations of timer and work by moving them to the beginning of podhd_init(). Fixes: 790869d ("ALSA: line6: Add support for POD X3") Reported-by: Andrey Konovalov <[email protected]> Tested-by: Andrey Konovalov <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Seth Forshee <[email protected]>
damentz
referenced
this pull request
in zen-kernel/zen-kernel
Feb 24, 2018
commit 2a4340c upstream. As syzkaller spotted, currently line6 drivers submit a URB with the fixed EP without checking whether it's actually available, which may result in a kernel warning like: usb 1-1: BOGUS urb xfer, pipe 3 != type 1 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 24 at drivers/usb/core/urb.c:449 usb_submit_urb+0xf8a/0x11d0 Modules linked in: CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc2-42613-g1488251d1a98 #238 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: line6_start_listen+0x55f/0x9e0 sound/usb/line6/driver.c:82 line6_init_cap_control sound/usb/line6/driver.c:690 line6_probe+0x7c9/0x1310 sound/usb/line6/driver.c:764 podhd_probe+0x64/0x70 sound/usb/line6/podhd.c:474 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361 .... This patch adds a sanity check of validity of EPs at the device initialization phase for avoiding the call with an invalid EP. Reported-by: Andrey Konovalov <[email protected]> Tested-by: Andrey Konovalov <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
damentz
referenced
this pull request
in zen-kernel/zen-kernel
Feb 24, 2018
commit 6815a0b upstream. As syzkaller spotted, currently bcd2000 driver submits a URB with the fixed EP without checking whether it's actually available, which may result in a kernel warning like: usb 1-1: BOGUS urb xfer, pipe 1 != type 3 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1846 at drivers/usb/core/urb.c:449 usb_submit_urb+0xf8a/0x11d0 Modules linked in: CPU: 0 PID: 1846 Comm: kworker/0:2 Not tainted 4.14.0-rc2-42613-g1488251d1a98 #238 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: bcd2000_init_device sound/usb/bcd2000/bcd2000.c:289 bcd2000_init_midi sound/usb/bcd2000/bcd2000.c:345 bcd2000_probe+0xe64/0x19e0 sound/usb/bcd2000/bcd2000.c:406 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361 .... This patch adds a sanity check of validity of EPs at the device initialization phase for avoiding the call with an invalid EP. Reported-by: Andrey Konovalov <[email protected]> Tested-by: Andrey Konovalov <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
frank-w
referenced
this pull request
in frank-w/BPI-Router-Linux
Feb 25, 2018
commit 2a4340c upstream. As syzkaller spotted, currently line6 drivers submit a URB with the fixed EP without checking whether it's actually available, which may result in a kernel warning like: usb 1-1: BOGUS urb xfer, pipe 3 != type 1 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 24 at drivers/usb/core/urb.c:449 usb_submit_urb+0xf8a/0x11d0 Modules linked in: CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc2-42613-g1488251d1a98 #238 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: line6_start_listen+0x55f/0x9e0 sound/usb/line6/driver.c:82 line6_init_cap_control sound/usb/line6/driver.c:690 line6_probe+0x7c9/0x1310 sound/usb/line6/driver.c:764 podhd_probe+0x64/0x70 sound/usb/line6/podhd.c:474 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361 .... This patch adds a sanity check of validity of EPs at the device initialization phase for avoiding the call with an invalid EP. Reported-by: Andrey Konovalov <[email protected]> Tested-by: Andrey Konovalov <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
frank-w
referenced
this pull request
in frank-w/BPI-Router-Linux
Feb 25, 2018
commit 6815a0b upstream. As syzkaller spotted, currently bcd2000 driver submits a URB with the fixed EP without checking whether it's actually available, which may result in a kernel warning like: usb 1-1: BOGUS urb xfer, pipe 1 != type 3 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1846 at drivers/usb/core/urb.c:449 usb_submit_urb+0xf8a/0x11d0 Modules linked in: CPU: 0 PID: 1846 Comm: kworker/0:2 Not tainted 4.14.0-rc2-42613-g1488251d1a98 #238 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: bcd2000_init_device sound/usb/bcd2000/bcd2000.c:289 bcd2000_init_midi sound/usb/bcd2000/bcd2000.c:345 bcd2000_probe+0xe64/0x19e0 sound/usb/bcd2000/bcd2000.c:406 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361 .... This patch adds a sanity check of validity of EPs at the device initialization phase for avoiding the call with an invalid EP. Reported-by: Andrey Konovalov <[email protected]> Tested-by: Andrey Konovalov <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
torvalds
pushed a commit
that referenced
this pull request
Jun 9, 2018
We met NULL pointer BUG as follow: [ 151.760358] BUG: unable to handle kernel NULL pointer dereference at 0000000000000060 [ 151.761340] PGD 80000001011eb067 P4D 80000001011eb067 PUD 1011ea067 PMD 0 [ 151.762039] Oops: 0000 [#1] SMP PTI [ 151.762406] Modules linked in: [ 151.762723] CPU: 2 PID: 3561 Comm: mdadm-test Kdump: loaded Not tainted 4.17.0-rc1+ #238 [ 151.763542] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1.fc26 04/01/2014 [ 151.764432] RIP: 0010:remove_and_add_spares.part.56+0x13c/0x3a0 [ 151.765061] RSP: 0018:ffffc90001d7fcd8 EFLAGS: 00010246 [ 151.765590] RAX: 0000000000000000 RBX: ffff88013601d600 RCX: 0000000000000000 [ 151.766306] RDX: 0000000000000000 RSI: ffff88013601d600 RDI: ffff880136187000 [ 151.767014] RBP: ffff880136187018 R08: 0000000000000003 R09: 0000000000000051 [ 151.767728] R10: ffffc90001d7fed8 R11: 0000000000000000 R12: ffff88013601d600 [ 151.768447] R13: ffff8801298b1300 R14: ffff880136187000 R15: 0000000000000000 [ 151.769160] FS: 00007f2624276700(0000) GS:ffff88013ae80000(0000) knlGS:0000000000000000 [ 151.769971] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 151.770554] CR2: 0000000000000060 CR3: 0000000111aac000 CR4: 00000000000006e0 [ 151.771272] Call Trace: [ 151.771542] md_ioctl+0x1df2/0x1e10 [ 151.771906] ? __switch_to+0x129/0x440 [ 151.772295] ? __schedule+0x244/0x850 [ 151.772672] blkdev_ioctl+0x4bd/0x970 [ 151.773048] block_ioctl+0x39/0x40 [ 151.773402] do_vfs_ioctl+0xa4/0x610 [ 151.773770] ? dput.part.23+0x87/0x100 [ 151.774151] ksys_ioctl+0x70/0x80 [ 151.774493] __x64_sys_ioctl+0x16/0x20 [ 151.774877] do_syscall_64+0x5b/0x180 [ 151.775258] entry_SYSCALL_64_after_hwframe+0x44/0xa9 For raid6, when two disk of the array are offline, two spare disks can be added into the array. Before spare disks recovery completing, system reboot and mdadm thinks it is ok to restart the degraded array by md_ioctl(). Since disks in raid6 is not only_parity(), raid5_run() will abort, when there is no PPL feature or not setting 'start_dirty_degraded' parameter. Therefore, mddev->pers is NULL. But, mddev->raid_disks has been set and it will not be cleared when raid5_run abort. md_ioctl() can execute cmd 'HOT_REMOVE_DISK' to remove a disk by mdadm, which will cause NULL pointer dereference in remove_and_add_spares() finally. Signed-off-by: Yufen Yu <[email protected]> Signed-off-by: Shaohua Li <[email protected]>
Noltari
pushed a commit
to Noltari/linux
that referenced
this pull request
Aug 3, 2018
[ Upstream commit c42a0e2 ] We met NULL pointer BUG as follow: [ 151.760358] BUG: unable to handle kernel NULL pointer dereference at 0000000000000060 [ 151.761340] PGD 80000001011eb067 P4D 80000001011eb067 PUD 1011ea067 PMD 0 [ 151.762039] Oops: 0000 [#1] SMP PTI [ 151.762406] Modules linked in: [ 151.762723] CPU: 2 PID: 3561 Comm: mdadm-test Kdump: loaded Not tainted 4.17.0-rc1+ torvalds#238 [ 151.763542] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1.fc26 04/01/2014 [ 151.764432] RIP: 0010:remove_and_add_spares.part.56+0x13c/0x3a0 [ 151.765061] RSP: 0018:ffffc90001d7fcd8 EFLAGS: 00010246 [ 151.765590] RAX: 0000000000000000 RBX: ffff88013601d600 RCX: 0000000000000000 [ 151.766306] RDX: 0000000000000000 RSI: ffff88013601d600 RDI: ffff880136187000 [ 151.767014] RBP: ffff880136187018 R08: 0000000000000003 R09: 0000000000000051 [ 151.767728] R10: ffffc90001d7fed8 R11: 0000000000000000 R12: ffff88013601d600 [ 151.768447] R13: ffff8801298b1300 R14: ffff880136187000 R15: 0000000000000000 [ 151.769160] FS: 00007f2624276700(0000) GS:ffff88013ae80000(0000) knlGS:0000000000000000 [ 151.769971] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 151.770554] CR2: 0000000000000060 CR3: 0000000111aac000 CR4: 00000000000006e0 [ 151.771272] Call Trace: [ 151.771542] md_ioctl+0x1df2/0x1e10 [ 151.771906] ? __switch_to+0x129/0x440 [ 151.772295] ? __schedule+0x244/0x850 [ 151.772672] blkdev_ioctl+0x4bd/0x970 [ 151.773048] block_ioctl+0x39/0x40 [ 151.773402] do_vfs_ioctl+0xa4/0x610 [ 151.773770] ? dput.part.23+0x87/0x100 [ 151.774151] ksys_ioctl+0x70/0x80 [ 151.774493] __x64_sys_ioctl+0x16/0x20 [ 151.774877] do_syscall_64+0x5b/0x180 [ 151.775258] entry_SYSCALL_64_after_hwframe+0x44/0xa9 For raid6, when two disk of the array are offline, two spare disks can be added into the array. Before spare disks recovery completing, system reboot and mdadm thinks it is ok to restart the degraded array by md_ioctl(). Since disks in raid6 is not only_parity(), raid5_run() will abort, when there is no PPL feature or not setting 'start_dirty_degraded' parameter. Therefore, mddev->pers is NULL. But, mddev->raid_disks has been set and it will not be cleared when raid5_run abort. md_ioctl() can execute cmd 'HOT_REMOVE_DISK' to remove a disk by mdadm, which will cause NULL pointer dereference in remove_and_add_spares() finally. Signed-off-by: Yufen Yu <[email protected]> Signed-off-by: Shaohua Li <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
heftig
referenced
this pull request
in zen-kernel/zen-kernel
Aug 3, 2018
[ Upstream commit c42a0e2 ] We met NULL pointer BUG as follow: [ 151.760358] BUG: unable to handle kernel NULL pointer dereference at 0000000000000060 [ 151.761340] PGD 80000001011eb067 P4D 80000001011eb067 PUD 1011ea067 PMD 0 [ 151.762039] Oops: 0000 [#1] SMP PTI [ 151.762406] Modules linked in: [ 151.762723] CPU: 2 PID: 3561 Comm: mdadm-test Kdump: loaded Not tainted 4.17.0-rc1+ #238 [ 151.763542] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1.fc26 04/01/2014 [ 151.764432] RIP: 0010:remove_and_add_spares.part.56+0x13c/0x3a0 [ 151.765061] RSP: 0018:ffffc90001d7fcd8 EFLAGS: 00010246 [ 151.765590] RAX: 0000000000000000 RBX: ffff88013601d600 RCX: 0000000000000000 [ 151.766306] RDX: 0000000000000000 RSI: ffff88013601d600 RDI: ffff880136187000 [ 151.767014] RBP: ffff880136187018 R08: 0000000000000003 R09: 0000000000000051 [ 151.767728] R10: ffffc90001d7fed8 R11: 0000000000000000 R12: ffff88013601d600 [ 151.768447] R13: ffff8801298b1300 R14: ffff880136187000 R15: 0000000000000000 [ 151.769160] FS: 00007f2624276700(0000) GS:ffff88013ae80000(0000) knlGS:0000000000000000 [ 151.769971] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 151.770554] CR2: 0000000000000060 CR3: 0000000111aac000 CR4: 00000000000006e0 [ 151.771272] Call Trace: [ 151.771542] md_ioctl+0x1df2/0x1e10 [ 151.771906] ? __switch_to+0x129/0x440 [ 151.772295] ? __schedule+0x244/0x850 [ 151.772672] blkdev_ioctl+0x4bd/0x970 [ 151.773048] block_ioctl+0x39/0x40 [ 151.773402] do_vfs_ioctl+0xa4/0x610 [ 151.773770] ? dput.part.23+0x87/0x100 [ 151.774151] ksys_ioctl+0x70/0x80 [ 151.774493] __x64_sys_ioctl+0x16/0x20 [ 151.774877] do_syscall_64+0x5b/0x180 [ 151.775258] entry_SYSCALL_64_after_hwframe+0x44/0xa9 For raid6, when two disk of the array are offline, two spare disks can be added into the array. Before spare disks recovery completing, system reboot and mdadm thinks it is ok to restart the degraded array by md_ioctl(). Since disks in raid6 is not only_parity(), raid5_run() will abort, when there is no PPL feature or not setting 'start_dirty_degraded' parameter. Therefore, mddev->pers is NULL. But, mddev->raid_disks has been set and it will not be cleared when raid5_run abort. md_ioctl() can execute cmd 'HOT_REMOVE_DISK' to remove a disk by mdadm, which will cause NULL pointer dereference in remove_and_add_spares() finally. Signed-off-by: Yufen Yu <[email protected]> Signed-off-by: Shaohua Li <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
frank-w
referenced
this pull request
in frank-w/BPI-Router-Linux
Aug 3, 2018
[ Upstream commit c42a0e2 ] We met NULL pointer BUG as follow: [ 151.760358] BUG: unable to handle kernel NULL pointer dereference at 0000000000000060 [ 151.761340] PGD 80000001011eb067 P4D 80000001011eb067 PUD 1011ea067 PMD 0 [ 151.762039] Oops: 0000 [#1] SMP PTI [ 151.762406] Modules linked in: [ 151.762723] CPU: 2 PID: 3561 Comm: mdadm-test Kdump: loaded Not tainted 4.17.0-rc1+ #238 [ 151.763542] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1.fc26 04/01/2014 [ 151.764432] RIP: 0010:remove_and_add_spares.part.56+0x13c/0x3a0 [ 151.765061] RSP: 0018:ffffc90001d7fcd8 EFLAGS: 00010246 [ 151.765590] RAX: 0000000000000000 RBX: ffff88013601d600 RCX: 0000000000000000 [ 151.766306] RDX: 0000000000000000 RSI: ffff88013601d600 RDI: ffff880136187000 [ 151.767014] RBP: ffff880136187018 R08: 0000000000000003 R09: 0000000000000051 [ 151.767728] R10: ffffc90001d7fed8 R11: 0000000000000000 R12: ffff88013601d600 [ 151.768447] R13: ffff8801298b1300 R14: ffff880136187000 R15: 0000000000000000 [ 151.769160] FS: 00007f2624276700(0000) GS:ffff88013ae80000(0000) knlGS:0000000000000000 [ 151.769971] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 151.770554] CR2: 0000000000000060 CR3: 0000000111aac000 CR4: 00000000000006e0 [ 151.771272] Call Trace: [ 151.771542] md_ioctl+0x1df2/0x1e10 [ 151.771906] ? __switch_to+0x129/0x440 [ 151.772295] ? __schedule+0x244/0x850 [ 151.772672] blkdev_ioctl+0x4bd/0x970 [ 151.773048] block_ioctl+0x39/0x40 [ 151.773402] do_vfs_ioctl+0xa4/0x610 [ 151.773770] ? dput.part.23+0x87/0x100 [ 151.774151] ksys_ioctl+0x70/0x80 [ 151.774493] __x64_sys_ioctl+0x16/0x20 [ 151.774877] do_syscall_64+0x5b/0x180 [ 151.775258] entry_SYSCALL_64_after_hwframe+0x44/0xa9 For raid6, when two disk of the array are offline, two spare disks can be added into the array. Before spare disks recovery completing, system reboot and mdadm thinks it is ok to restart the degraded array by md_ioctl(). Since disks in raid6 is not only_parity(), raid5_run() will abort, when there is no PPL feature or not setting 'start_dirty_degraded' parameter. Therefore, mddev->pers is NULL. But, mddev->raid_disks has been set and it will not be cleared when raid5_run abort. md_ioctl() can execute cmd 'HOT_REMOVE_DISK' to remove a disk by mdadm, which will cause NULL pointer dereference in remove_and_add_spares() finally. Signed-off-by: Yufen Yu <[email protected]> Signed-off-by: Shaohua Li <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Noltari
pushed a commit
to Noltari/linux
that referenced
this pull request
Aug 6, 2018
[ Upstream commit c42a0e2 ] We met NULL pointer BUG as follow: [ 151.760358] BUG: unable to handle kernel NULL pointer dereference at 0000000000000060 [ 151.761340] PGD 80000001011eb067 P4D 80000001011eb067 PUD 1011ea067 PMD 0 [ 151.762039] Oops: 0000 [#1] SMP PTI [ 151.762406] Modules linked in: [ 151.762723] CPU: 2 PID: 3561 Comm: mdadm-test Kdump: loaded Not tainted 4.17.0-rc1+ torvalds#238 [ 151.763542] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1.fc26 04/01/2014 [ 151.764432] RIP: 0010:remove_and_add_spares.part.56+0x13c/0x3a0 [ 151.765061] RSP: 0018:ffffc90001d7fcd8 EFLAGS: 00010246 [ 151.765590] RAX: 0000000000000000 RBX: ffff88013601d600 RCX: 0000000000000000 [ 151.766306] RDX: 0000000000000000 RSI: ffff88013601d600 RDI: ffff880136187000 [ 151.767014] RBP: ffff880136187018 R08: 0000000000000003 R09: 0000000000000051 [ 151.767728] R10: ffffc90001d7fed8 R11: 0000000000000000 R12: ffff88013601d600 [ 151.768447] R13: ffff8801298b1300 R14: ffff880136187000 R15: 0000000000000000 [ 151.769160] FS: 00007f2624276700(0000) GS:ffff88013ae80000(0000) knlGS:0000000000000000 [ 151.769971] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 151.770554] CR2: 0000000000000060 CR3: 0000000111aac000 CR4: 00000000000006e0 [ 151.771272] Call Trace: [ 151.771542] md_ioctl+0x1df2/0x1e10 [ 151.771906] ? __switch_to+0x129/0x440 [ 151.772295] ? __schedule+0x244/0x850 [ 151.772672] blkdev_ioctl+0x4bd/0x970 [ 151.773048] block_ioctl+0x39/0x40 [ 151.773402] do_vfs_ioctl+0xa4/0x610 [ 151.773770] ? dput.part.23+0x87/0x100 [ 151.774151] ksys_ioctl+0x70/0x80 [ 151.774493] __x64_sys_ioctl+0x16/0x20 [ 151.774877] do_syscall_64+0x5b/0x180 [ 151.775258] entry_SYSCALL_64_after_hwframe+0x44/0xa9 For raid6, when two disk of the array are offline, two spare disks can be added into the array. Before spare disks recovery completing, system reboot and mdadm thinks it is ok to restart the degraded array by md_ioctl(). Since disks in raid6 is not only_parity(), raid5_run() will abort, when there is no PPL feature or not setting 'start_dirty_degraded' parameter. Therefore, mddev->pers is NULL. But, mddev->raid_disks has been set and it will not be cleared when raid5_run abort. md_ioctl() can execute cmd 'HOT_REMOVE_DISK' to remove a disk by mdadm, which will cause NULL pointer dereference in remove_and_add_spares() finally. Signed-off-by: Yufen Yu <[email protected]> Signed-off-by: Shaohua Li <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
gabrielesvelto
pushed a commit
to gabrielesvelto/CI20_linux
that referenced
this pull request
Aug 13, 2018
[ Upstream commit c42a0e2 ] We met NULL pointer BUG as follow: [ 151.760358] BUG: unable to handle kernel NULL pointer dereference at 0000000000000060 [ 151.761340] PGD 80000001011eb067 P4D 80000001011eb067 PUD 1011ea067 PMD 0 [ 151.762039] Oops: 0000 [MIPS#1] SMP PTI [ 151.762406] Modules linked in: [ 151.762723] CPU: 2 PID: 3561 Comm: mdadm-test Kdump: loaded Not tainted 4.17.0-rc1+ torvalds#238 [ 151.763542] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1.fc26 04/01/2014 [ 151.764432] RIP: 0010:remove_and_add_spares.part.56+0x13c/0x3a0 [ 151.765061] RSP: 0018:ffffc90001d7fcd8 EFLAGS: 00010246 [ 151.765590] RAX: 0000000000000000 RBX: ffff88013601d600 RCX: 0000000000000000 [ 151.766306] RDX: 0000000000000000 RSI: ffff88013601d600 RDI: ffff880136187000 [ 151.767014] RBP: ffff880136187018 R08: 0000000000000003 R09: 0000000000000051 [ 151.767728] R10: ffffc90001d7fed8 R11: 0000000000000000 R12: ffff88013601d600 [ 151.768447] R13: ffff8801298b1300 R14: ffff880136187000 R15: 0000000000000000 [ 151.769160] FS: 00007f2624276700(0000) GS:ffff88013ae80000(0000) knlGS:0000000000000000 [ 151.769971] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 151.770554] CR2: 0000000000000060 CR3: 0000000111aac000 CR4: 00000000000006e0 [ 151.771272] Call Trace: [ 151.771542] md_ioctl+0x1df2/0x1e10 [ 151.771906] ? __switch_to+0x129/0x440 [ 151.772295] ? __schedule+0x244/0x850 [ 151.772672] blkdev_ioctl+0x4bd/0x970 [ 151.773048] block_ioctl+0x39/0x40 [ 151.773402] do_vfs_ioctl+0xa4/0x610 [ 151.773770] ? dput.part.23+0x87/0x100 [ 151.774151] ksys_ioctl+0x70/0x80 [ 151.774493] __x64_sys_ioctl+0x16/0x20 [ 151.774877] do_syscall_64+0x5b/0x180 [ 151.775258] entry_SYSCALL_64_after_hwframe+0x44/0xa9 For raid6, when two disk of the array are offline, two spare disks can be added into the array. Before spare disks recovery completing, system reboot and mdadm thinks it is ok to restart the degraded array by md_ioctl(). Since disks in raid6 is not only_parity(), raid5_run() will abort, when there is no PPL feature or not setting 'start_dirty_degraded' parameter. Therefore, mddev->pers is NULL. But, mddev->raid_disks has been set and it will not be cleared when raid5_run abort. md_ioctl() can execute cmd 'HOT_REMOVE_DISK' to remove a disk by mdadm, which will cause NULL pointer dereference in remove_and_add_spares() finally. Signed-off-by: Yufen Yu <[email protected]> Signed-off-by: Shaohua Li <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
ddstreet
pushed a commit
to ddstreet/linux
that referenced
this pull request
May 31, 2019
BugLink: http://bugs.launchpad.net/bugs/1815234 [ Upstream commit c42a0e2 ] We met NULL pointer BUG as follow: [ 151.760358] BUG: unable to handle kernel NULL pointer dereference at 0000000000000060 [ 151.761340] PGD 80000001011eb067 P4D 80000001011eb067 PUD 1011ea067 PMD 0 [ 151.762039] Oops: 0000 [#1] SMP PTI [ 151.762406] Modules linked in: [ 151.762723] CPU: 2 PID: 3561 Comm: mdadm-test Kdump: loaded Not tainted 4.17.0-rc1+ torvalds#238 [ 151.763542] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1.fc26 04/01/2014 [ 151.764432] RIP: 0010:remove_and_add_spares.part.56+0x13c/0x3a0 [ 151.765061] RSP: 0018:ffffc90001d7fcd8 EFLAGS: 00010246 [ 151.765590] RAX: 0000000000000000 RBX: ffff88013601d600 RCX: 0000000000000000 [ 151.766306] RDX: 0000000000000000 RSI: ffff88013601d600 RDI: ffff880136187000 [ 151.767014] RBP: ffff880136187018 R08: 0000000000000003 R09: 0000000000000051 [ 151.767728] R10: ffffc90001d7fed8 R11: 0000000000000000 R12: ffff88013601d600 [ 151.768447] R13: ffff8801298b1300 R14: ffff880136187000 R15: 0000000000000000 [ 151.769160] FS: 00007f2624276700(0000) GS:ffff88013ae80000(0000) knlGS:0000000000000000 [ 151.769971] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 151.770554] CR2: 0000000000000060 CR3: 0000000111aac000 CR4: 00000000000006e0 [ 151.771272] Call Trace: [ 151.771542] md_ioctl+0x1df2/0x1e10 [ 151.771906] ? __switch_to+0x129/0x440 [ 151.772295] ? __schedule+0x244/0x850 [ 151.772672] blkdev_ioctl+0x4bd/0x970 [ 151.773048] block_ioctl+0x39/0x40 [ 151.773402] do_vfs_ioctl+0xa4/0x610 [ 151.773770] ? dput.part.23+0x87/0x100 [ 151.774151] ksys_ioctl+0x70/0x80 [ 151.774493] __x64_sys_ioctl+0x16/0x20 [ 151.774877] do_syscall_64+0x5b/0x180 [ 151.775258] entry_SYSCALL_64_after_hwframe+0x44/0xa9 For raid6, when two disk of the array are offline, two spare disks can be added into the array. Before spare disks recovery completing, system reboot and mdadm thinks it is ok to restart the degraded array by md_ioctl(). Since disks in raid6 is not only_parity(), raid5_run() will abort, when there is no PPL feature or not setting 'start_dirty_degraded' parameter. Therefore, mddev->pers is NULL. But, mddev->raid_disks has been set and it will not be cleared when raid5_run abort. md_ioctl() can execute cmd 'HOT_REMOVE_DISK' to remove a disk by mdadm, which will cause NULL pointer dereference in remove_and_add_spares() finally. Signed-off-by: Yufen Yu <[email protected]> Signed-off-by: Shaohua Li <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Kamal Mostafa <[email protected]> Signed-off-by: Stefan Bader <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Oct 2, 2019
Way back in 2017, fuzzing the 4.14-rc2 USB stack with syzkaller kicked up the following WARNING from the UVC chain scanning code: | list_add double add: new=ffff880069084010, prev=ffff880069084010, | next=ffff880067d22298. | ------------[ cut here ]------------ | WARNING: CPU: 1 PID: 1846 at lib/list_debug.c:31 __list_add_valid+0xbd/0xf0 | Modules linked in: | CPU: 1 PID: 1846 Comm: kworker/1:2 Not tainted | 4.14.0-rc2-42613-g1488251d1a98 torvalds#238 | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 | Workqueue: usb_hub_wq hub_event | task: ffff88006b01ca40 task.stack: ffff880064358000 | RIP: 0010:__list_add_valid+0xbd/0xf0 lib/list_debug.c:29 | RSP: 0018:ffff88006435ddd0 EFLAGS: 00010286 | RAX: 0000000000000058 RBX: ffff880067d22298 RCX: 0000000000000000 | RDX: 0000000000000058 RSI: ffffffff85a58800 RDI: ffffed000c86bbac | RBP: ffff88006435dde8 R08: 1ffff1000c86ba52 R09: 0000000000000000 | R10: 0000000000000002 R11: 0000000000000000 R12: ffff880069084010 | R13: ffff880067d22298 R14: ffff880069084010 R15: ffff880067d222a0 | FS: 0000000000000000(0000) GS:ffff88006c900000(0000) knlGS:0000000000000000 | CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 | CR2: 0000000020004ff2 CR3: 000000006b447000 CR4: 00000000000006e0 | Call Trace: | __list_add ./include/linux/list.h:59 | list_add_tail+0x8c/0x1b0 ./include/linux/list.h:92 | uvc_scan_chain_forward.isra.8+0x373/0x416 | drivers/media/usb/uvc/uvc_driver.c:1471 | uvc_scan_chain drivers/media/usb/uvc/uvc_driver.c:1585 | uvc_scan_device drivers/media/usb/uvc/uvc_driver.c:1769 | uvc_probe+0x77f2/0x8f00 drivers/media/usb/uvc/uvc_driver.c:2104 Looking into the output from usbmon, the interesting part is the following data packet: ffff880069c63e00 30710169 C Ci:1:002:0 0 143 = 09028f00 01030080 00090403 00000e01 00000924 03000103 7c003328 010204db If we drop the lead configuration and interface descriptors, we're left with an output terminal descriptor describing a generic display: /* Output terminal descriptor */ buf[0] 09 buf[1] 24 buf[2] 03 /* UVC_VC_OUTPUT_TERMINAL */ buf[3] 00 /* ID */ buf[4] 01 /* type == 0x0301 (UVC_OTT_DISPLAY) */ buf[5] 03 buf[6] 7c buf[7] 00 /* source ID refers to self! */ buf[8] 33 The problem with this descriptor is that it is self-referential: the source ID of 0 matches itself! This causes the 'struct uvc_entity' representing the display to be added to its chain list twice during 'uvc_scan_chain()': once via 'uvc_scan_chain_entity()' when it is processed directly from the 'dev->entities' list and then again immediately afterwards when trying to follow the source ID in 'uvc_scan_chain_forward()' Add a check before adding an entity to a chain list to ensure that the entity is not already part of a chain. Cc: Laurent Pinchart <[email protected]> Cc: Mauro Carvalho Chehab <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: Kostya Serebryany <[email protected]> Cc: <[email protected]> Fixes: c0efd23 ("V4L/DVB (8145a): USB Video Class driver") Reported-by: Andrey Konovalov <[email protected]> Link: https://lore.kernel.org/linux-media/CAAeHK+z+Si69jUR+N-SjN9q4O+o5KFiNManqEa-PjUta7EOb7A@mail.gmail.com/ Signed-off-by: Will Deacon <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Nov 9, 2019
Way back in 2017, fuzzing the 4.14-rc2 USB stack with syzkaller kicked up the following WARNING from the UVC chain scanning code: | list_add double add: new=ffff880069084010, prev=ffff880069084010, | next=ffff880067d22298. | ------------[ cut here ]------------ | WARNING: CPU: 1 PID: 1846 at lib/list_debug.c:31 __list_add_valid+0xbd/0xf0 | Modules linked in: | CPU: 1 PID: 1846 Comm: kworker/1:2 Not tainted | 4.14.0-rc2-42613-g1488251d1a98 torvalds#238 | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 | Workqueue: usb_hub_wq hub_event | task: ffff88006b01ca40 task.stack: ffff880064358000 | RIP: 0010:__list_add_valid+0xbd/0xf0 lib/list_debug.c:29 | RSP: 0018:ffff88006435ddd0 EFLAGS: 00010286 | RAX: 0000000000000058 RBX: ffff880067d22298 RCX: 0000000000000000 | RDX: 0000000000000058 RSI: ffffffff85a58800 RDI: ffffed000c86bbac | RBP: ffff88006435dde8 R08: 1ffff1000c86ba52 R09: 0000000000000000 | R10: 0000000000000002 R11: 0000000000000000 R12: ffff880069084010 | R13: ffff880067d22298 R14: ffff880069084010 R15: ffff880067d222a0 | FS: 0000000000000000(0000) GS:ffff88006c900000(0000) knlGS:0000000000000000 | CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 | CR2: 0000000020004ff2 CR3: 000000006b447000 CR4: 00000000000006e0 | Call Trace: | __list_add ./include/linux/list.h:59 | list_add_tail+0x8c/0x1b0 ./include/linux/list.h:92 | uvc_scan_chain_forward.isra.8+0x373/0x416 | drivers/media/usb/uvc/uvc_driver.c:1471 | uvc_scan_chain drivers/media/usb/uvc/uvc_driver.c:1585 | uvc_scan_device drivers/media/usb/uvc/uvc_driver.c:1769 | uvc_probe+0x77f2/0x8f00 drivers/media/usb/uvc/uvc_driver.c:2104 Looking into the output from usbmon, the interesting part is the following data packet: ffff880069c63e00 30710169 C Ci:1:002:0 0 143 = 09028f00 01030080 00090403 00000e01 00000924 03000103 7c003328 010204db If we drop the lead configuration and interface descriptors, we're left with an output terminal descriptor describing a generic display: /* Output terminal descriptor */ buf[0] 09 buf[1] 24 buf[2] 03 /* UVC_VC_OUTPUT_TERMINAL */ buf[3] 00 /* ID */ buf[4] 01 /* type == 0x0301 (UVC_OTT_DISPLAY) */ buf[5] 03 buf[6] 7c buf[7] 00 /* source ID refers to self! */ buf[8] 33 The problem with this descriptor is that it is self-referential: the source ID of 0 matches itself! This causes the 'struct uvc_entity' representing the display to be added to its chain list twice during 'uvc_scan_chain()': once via 'uvc_scan_chain_entity()' when it is processed directly from the 'dev->entities' list and then again immediately afterwards when trying to follow the source ID in 'uvc_scan_chain_forward()' Add a check before adding an entity to a chain list to ensure that the entity is not already part of a chain. Cc: Laurent Pinchart <[email protected]> Cc: Mauro Carvalho Chehab <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: Kostya Serebryany <[email protected]> Cc: <[email protected]> Fixes: c0efd23 ("V4L/DVB (8145a): USB Video Class driver") Reported-by: Andrey Konovalov <[email protected]> Link: https://lore.kernel.org/linux-media/CAAeHK+z+Si69jUR+N-SjN9q4O+o5KFiNManqEa-PjUta7EOb7A@mail.gmail.com/ Signed-off-by: Will Deacon <[email protected]>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Mar 31, 2025
WARNING: CPU: 0 PID: 6558 at net/core/sock_map.c:1703 sock_map_close+0x3c4/0x480 Modules linked in: CPU: 0 UID: 0 PID: 6558 Comm: syz-executor.14 Not tainted 6.14.0-rc5+ torvalds#238 RIP: 0010:sock_map_close+0x3c4/0x480 Call Trace: <TASK> inet_release+0x144/0x280 __sock_release+0xb8/0x270 sock_close+0x1e/0x30 __fput+0x3c6/0xb30 __fput_sync+0x7b/0x90 __x64_sys_close+0x90/0x120 do_syscall_64+0x5d/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is: bpf_prog_attach(BPF_SK_SKB_STREAM_VERDICT) tcp_set_ulp //set ulp after sockmap add icsk->icsk_ulp_ops = ulp_ops; sock_hash_update_common sock_map_unref sock_map_del_link psock->psock_update_sk_prot(sk, psock, false); sk->sk_prot->close = sock_map_close sk_psock_drop sk_psock_restore_proto tcp_bpf_update_proto tls_update //not redo sk_prot to tcp prot inet_release sk->sk_prot->close sock_map_close WARN(sk->sk_prot->close == sock_map_close) commit e34a07c ("sock: redo the psock vs ULP protection check") has moved ulp check from tcp_bpf_update_proto() to psock init. If sk sets ulp after being added to sockmap, it will reset sk_prot to BPF_BASE when removed from sockmap. After the psock is dropped, it will not reset sk_prot back to the tcp prot, only tls context update is performed. This can trigger a warning in sock_map_close() due to recursion of sk->sk_prot->close. To fix this issue, skip the sk_prot operations redo when deleting link from sockmap if ULP is set. Fixes: e34a07c ("sock: redo the psock vs ULP protection check") Fixes: c0d95d3 ("bpf, sockmap: Re-evaluate proto ops when psock is removed from sockmap") Suggested-by: Cong Wang <[email protected]> Signed-off-by: Dong Chenchen <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Mar 31, 2025
WARNING: CPU: 0 PID: 6558 at net/core/sock_map.c:1703 sock_map_close+0x3c4/0x480 Modules linked in: CPU: 0 UID: 0 PID: 6558 Comm: syz-executor.14 Not tainted 6.14.0-rc5+ torvalds#238 RIP: 0010:sock_map_close+0x3c4/0x480 Call Trace: <TASK> inet_release+0x144/0x280 __sock_release+0xb8/0x270 sock_close+0x1e/0x30 __fput+0x3c6/0xb30 __fput_sync+0x7b/0x90 __x64_sys_close+0x90/0x120 do_syscall_64+0x5d/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is: bpf_prog_attach(BPF_SK_SKB_STREAM_VERDICT) tcp_set_ulp //set ulp after sockmap add icsk->icsk_ulp_ops = ulp_ops; sock_hash_update_common sock_map_unref sock_map_del_link psock->psock_update_sk_prot(sk, psock, false); sk->sk_prot->close = sock_map_close sk_psock_drop sk_psock_restore_proto tcp_bpf_update_proto tls_update //not redo sk_prot to tcp prot inet_release sk->sk_prot->close sock_map_close WARN(sk->sk_prot->close == sock_map_close) commit e34a07c ("sock: redo the psock vs ULP protection check") has moved ulp check from tcp_bpf_update_proto() to psock init. If sk sets ulp after being added to sockmap, it will reset sk_prot to BPF_BASE when removed from sockmap. After the psock is dropped, it will not reset sk_prot back to the tcp prot, only tls context update is performed. This can trigger a warning in sock_map_close() due to recursion of sk->sk_prot->close. To fix this issue, skip the sk_prot operations redo when deleting link from sockmap if ULP is set. Fixes: e34a07c ("sock: redo the psock vs ULP protection check") Fixes: c0d95d3 ("bpf, sockmap: Re-evaluate proto ops when psock is removed from sockmap") Suggested-by: Cong Wang <[email protected]> Signed-off-by: Dong Chenchen <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Mar 31, 2025
WARNING: CPU: 0 PID: 6558 at net/core/sock_map.c:1703 sock_map_close+0x3c4/0x480 Modules linked in: CPU: 0 UID: 0 PID: 6558 Comm: syz-executor.14 Not tainted 6.14.0-rc5+ torvalds#238 RIP: 0010:sock_map_close+0x3c4/0x480 Call Trace: <TASK> inet_release+0x144/0x280 __sock_release+0xb8/0x270 sock_close+0x1e/0x30 __fput+0x3c6/0xb30 __fput_sync+0x7b/0x90 __x64_sys_close+0x90/0x120 do_syscall_64+0x5d/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is: bpf_prog_attach(BPF_SK_SKB_STREAM_VERDICT) tcp_set_ulp //set ulp after sockmap add icsk->icsk_ulp_ops = ulp_ops; sock_hash_update_common sock_map_unref sock_map_del_link psock->psock_update_sk_prot(sk, psock, false); sk->sk_prot->close = sock_map_close sk_psock_drop sk_psock_restore_proto tcp_bpf_update_proto tls_update //not redo sk_prot to tcp prot inet_release sk->sk_prot->close sock_map_close WARN(sk->sk_prot->close == sock_map_close) commit e34a07c ("sock: redo the psock vs ULP protection check") has moved ulp check from tcp_bpf_update_proto() to psock init. If sk sets ulp after being added to sockmap, it will reset sk_prot to BPF_BASE when removed from sockmap. After the psock is dropped, it will not reset sk_prot back to the tcp prot, only tls context update is performed. This can trigger a warning in sock_map_close() due to recursion of sk->sk_prot->close. To fix this issue, skip the sk_prot operations redo when deleting link from sockmap if ULP is set. Fixes: e34a07c ("sock: redo the psock vs ULP protection check") Fixes: c0d95d3 ("bpf, sockmap: Re-evaluate proto ops when psock is removed from sockmap") Suggested-by: Cong Wang <[email protected]> Signed-off-by: Dong Chenchen <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Mar 31, 2025
WARNING: CPU: 0 PID: 6558 at net/core/sock_map.c:1703 sock_map_close+0x3c4/0x480 Modules linked in: CPU: 0 UID: 0 PID: 6558 Comm: syz-executor.14 Not tainted 6.14.0-rc5+ torvalds#238 RIP: 0010:sock_map_close+0x3c4/0x480 Call Trace: <TASK> inet_release+0x144/0x280 __sock_release+0xb8/0x270 sock_close+0x1e/0x30 __fput+0x3c6/0xb30 __fput_sync+0x7b/0x90 __x64_sys_close+0x90/0x120 do_syscall_64+0x5d/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is: bpf_prog_attach(BPF_SK_SKB_STREAM_VERDICT) tcp_set_ulp //set ulp after sockmap add icsk->icsk_ulp_ops = ulp_ops; sock_hash_update_common sock_map_unref sock_map_del_link psock->psock_update_sk_prot(sk, psock, false); sk->sk_prot->close = sock_map_close sk_psock_drop sk_psock_restore_proto tcp_bpf_update_proto tls_update //not redo sk_prot to tcp prot inet_release sk->sk_prot->close sock_map_close WARN(sk->sk_prot->close == sock_map_close) commit e34a07c ("sock: redo the psock vs ULP protection check") has moved ulp check from tcp_bpf_update_proto() to psock init. If sk sets ulp after being added to sockmap, it will reset sk_prot to BPF_BASE when removed from sockmap. After the psock is dropped, it will not reset sk_prot back to the tcp prot, only tls context update is performed. This can trigger a warning in sock_map_close() due to recursion of sk->sk_prot->close. To fix this issue, skip the sk_prot operations redo when deleting link from sockmap if ULP is set. Fixes: e34a07c ("sock: redo the psock vs ULP protection check") Fixes: c0d95d3 ("bpf, sockmap: Re-evaluate proto ops when psock is removed from sockmap") Suggested-by: Cong Wang <[email protected]> Signed-off-by: Dong Chenchen <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Mar 31, 2025
WARNING: CPU: 0 PID: 6558 at net/core/sock_map.c:1703 sock_map_close+0x3c4/0x480 Modules linked in: CPU: 0 UID: 0 PID: 6558 Comm: syz-executor.14 Not tainted 6.14.0-rc5+ torvalds#238 RIP: 0010:sock_map_close+0x3c4/0x480 Call Trace: <TASK> inet_release+0x144/0x280 __sock_release+0xb8/0x270 sock_close+0x1e/0x30 __fput+0x3c6/0xb30 __fput_sync+0x7b/0x90 __x64_sys_close+0x90/0x120 do_syscall_64+0x5d/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is: bpf_prog_attach(BPF_SK_SKB_STREAM_VERDICT) tcp_set_ulp //set ulp after sockmap add icsk->icsk_ulp_ops = ulp_ops; sock_hash_update_common sock_map_unref sock_map_del_link psock->psock_update_sk_prot(sk, psock, false); sk->sk_prot->close = sock_map_close sk_psock_drop sk_psock_restore_proto tcp_bpf_update_proto tls_update //not redo sk_prot to tcp prot inet_release sk->sk_prot->close sock_map_close WARN(sk->sk_prot->close == sock_map_close) commit e34a07c ("sock: redo the psock vs ULP protection check") has moved ulp check from tcp_bpf_update_proto() to psock init. If sk sets ulp after being added to sockmap, it will reset sk_prot to BPF_BASE when removed from sockmap. After the psock is dropped, it will not reset sk_prot back to the tcp prot, only tls context update is performed. This can trigger a warning in sock_map_close() due to recursion of sk->sk_prot->close. To fix this issue, skip the sk_prot operations redo when deleting link from sockmap if ULP is set. Fixes: e34a07c ("sock: redo the psock vs ULP protection check") Fixes: c0d95d3 ("bpf, sockmap: Re-evaluate proto ops when psock is removed from sockmap") Suggested-by: Cong Wang <[email protected]> Signed-off-by: Dong Chenchen <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Mar 31, 2025
WARNING: CPU: 0 PID: 6558 at net/core/sock_map.c:1703 sock_map_close+0x3c4/0x480 Modules linked in: CPU: 0 UID: 0 PID: 6558 Comm: syz-executor.14 Not tainted 6.14.0-rc5+ torvalds#238 RIP: 0010:sock_map_close+0x3c4/0x480 Call Trace: <TASK> inet_release+0x144/0x280 __sock_release+0xb8/0x270 sock_close+0x1e/0x30 __fput+0x3c6/0xb30 __fput_sync+0x7b/0x90 __x64_sys_close+0x90/0x120 do_syscall_64+0x5d/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is: bpf_prog_attach(BPF_SK_SKB_STREAM_VERDICT) tcp_set_ulp //set ulp after sockmap add icsk->icsk_ulp_ops = ulp_ops; sock_hash_update_common sock_map_unref sock_map_del_link psock->psock_update_sk_prot(sk, psock, false); sk->sk_prot->close = sock_map_close sk_psock_drop sk_psock_restore_proto tcp_bpf_update_proto tls_update //not redo sk_prot to tcp prot inet_release sk->sk_prot->close sock_map_close WARN(sk->sk_prot->close == sock_map_close) commit e34a07c ("sock: redo the psock vs ULP protection check") has moved ulp check from tcp_bpf_update_proto() to psock init. If sk sets ulp after being added to sockmap, it will reset sk_prot to BPF_BASE when removed from sockmap. After the psock is dropped, it will not reset sk_prot back to the tcp prot, only tls context update is performed. This can trigger a warning in sock_map_close() due to recursion of sk->sk_prot->close. To fix this issue, skip the sk_prot operations redo when deleting link from sockmap if ULP is set. Fixes: e34a07c ("sock: redo the psock vs ULP protection check") Fixes: c0d95d3 ("bpf, sockmap: Re-evaluate proto ops when psock is removed from sockmap") Suggested-by: Cong Wang <[email protected]> Signed-off-by: Dong Chenchen <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Apr 1, 2025
WARNING: CPU: 0 PID: 6558 at net/core/sock_map.c:1703 sock_map_close+0x3c4/0x480 Modules linked in: CPU: 0 UID: 0 PID: 6558 Comm: syz-executor.14 Not tainted 6.14.0-rc5+ torvalds#238 RIP: 0010:sock_map_close+0x3c4/0x480 Call Trace: <TASK> inet_release+0x144/0x280 __sock_release+0xb8/0x270 sock_close+0x1e/0x30 __fput+0x3c6/0xb30 __fput_sync+0x7b/0x90 __x64_sys_close+0x90/0x120 do_syscall_64+0x5d/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is: bpf_prog_attach(BPF_SK_SKB_STREAM_VERDICT) tcp_set_ulp //set ulp after sockmap add icsk->icsk_ulp_ops = ulp_ops; sock_hash_update_common sock_map_unref sock_map_del_link psock->psock_update_sk_prot(sk, psock, false); sk->sk_prot->close = sock_map_close sk_psock_drop sk_psock_restore_proto tcp_bpf_update_proto tls_update //not redo sk_prot to tcp prot inet_release sk->sk_prot->close sock_map_close WARN(sk->sk_prot->close == sock_map_close) commit e34a07c ("sock: redo the psock vs ULP protection check") has moved ulp check from tcp_bpf_update_proto() to psock init. If sk sets ulp after being added to sockmap, it will reset sk_prot to BPF_BASE when removed from sockmap. After the psock is dropped, it will not reset sk_prot back to the tcp prot, only tls context update is performed. This can trigger a warning in sock_map_close() due to recursion of sk->sk_prot->close. To fix this issue, skip the sk_prot operations redo when deleting link from sockmap if ULP is set. Fixes: e34a07c ("sock: redo the psock vs ULP protection check") Fixes: c0d95d3 ("bpf, sockmap: Re-evaluate proto ops when psock is removed from sockmap") Suggested-by: Cong Wang <[email protected]> Signed-off-by: Dong Chenchen <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Apr 1, 2025
WARNING: CPU: 0 PID: 6558 at net/core/sock_map.c:1703 sock_map_close+0x3c4/0x480 Modules linked in: CPU: 0 UID: 0 PID: 6558 Comm: syz-executor.14 Not tainted 6.14.0-rc5+ torvalds#238 RIP: 0010:sock_map_close+0x3c4/0x480 Call Trace: <TASK> inet_release+0x144/0x280 __sock_release+0xb8/0x270 sock_close+0x1e/0x30 __fput+0x3c6/0xb30 __fput_sync+0x7b/0x90 __x64_sys_close+0x90/0x120 do_syscall_64+0x5d/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is: bpf_prog_attach(BPF_SK_SKB_STREAM_VERDICT) tcp_set_ulp //set ulp after sockmap add icsk->icsk_ulp_ops = ulp_ops; sock_hash_update_common sock_map_unref sock_map_del_link psock->psock_update_sk_prot(sk, psock, false); sk->sk_prot->close = sock_map_close sk_psock_drop sk_psock_restore_proto tcp_bpf_update_proto tls_update //not redo sk_prot to tcp prot inet_release sk->sk_prot->close sock_map_close WARN(sk->sk_prot->close == sock_map_close) commit e34a07c ("sock: redo the psock vs ULP protection check") has moved ulp check from tcp_bpf_update_proto() to psock init. If sk sets ulp after being added to sockmap, it will reset sk_prot to BPF_BASE when removed from sockmap. After the psock is dropped, it will not reset sk_prot back to the tcp prot, only tls context update is performed. This can trigger a warning in sock_map_close() due to recursion of sk->sk_prot->close. To fix this issue, skip the sk_prot operations redo when deleting link from sockmap if ULP is set. Fixes: e34a07c ("sock: redo the psock vs ULP protection check") Fixes: c0d95d3 ("bpf, sockmap: Re-evaluate proto ops when psock is removed from sockmap") Suggested-by: Cong Wang <[email protected]> Signed-off-by: Dong Chenchen <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Apr 1, 2025
WARNING: CPU: 0 PID: 6558 at net/core/sock_map.c:1703 sock_map_close+0x3c4/0x480 Modules linked in: CPU: 0 UID: 0 PID: 6558 Comm: syz-executor.14 Not tainted 6.14.0-rc5+ torvalds#238 RIP: 0010:sock_map_close+0x3c4/0x480 Call Trace: <TASK> inet_release+0x144/0x280 __sock_release+0xb8/0x270 sock_close+0x1e/0x30 __fput+0x3c6/0xb30 __fput_sync+0x7b/0x90 __x64_sys_close+0x90/0x120 do_syscall_64+0x5d/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is: bpf_prog_attach(BPF_SK_SKB_STREAM_VERDICT) tcp_set_ulp //set ulp after sockmap add icsk->icsk_ulp_ops = ulp_ops; sock_hash_update_common sock_map_unref sock_map_del_link psock->psock_update_sk_prot(sk, psock, false); sk->sk_prot->close = sock_map_close sk_psock_drop sk_psock_restore_proto tcp_bpf_update_proto tls_update //not redo sk_prot to tcp prot inet_release sk->sk_prot->close sock_map_close WARN(sk->sk_prot->close == sock_map_close) commit e34a07c ("sock: redo the psock vs ULP protection check") has moved ulp check from tcp_bpf_update_proto() to psock init. If sk sets ulp after being added to sockmap, it will reset sk_prot to BPF_BASE when removed from sockmap. After the psock is dropped, it will not reset sk_prot back to the tcp prot, only tls context update is performed. This can trigger a warning in sock_map_close() due to recursion of sk->sk_prot->close. To fix this issue, skip the sk_prot operations redo when deleting link from sockmap if ULP is set. Fixes: e34a07c ("sock: redo the psock vs ULP protection check") Fixes: c0d95d3 ("bpf, sockmap: Re-evaluate proto ops when psock is removed from sockmap") Suggested-by: Cong Wang <[email protected]> Signed-off-by: Dong Chenchen <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Apr 1, 2025
WARNING: CPU: 0 PID: 6558 at net/core/sock_map.c:1703 sock_map_close+0x3c4/0x480 Modules linked in: CPU: 0 UID: 0 PID: 6558 Comm: syz-executor.14 Not tainted 6.14.0-rc5+ torvalds#238 RIP: 0010:sock_map_close+0x3c4/0x480 Call Trace: <TASK> inet_release+0x144/0x280 __sock_release+0xb8/0x270 sock_close+0x1e/0x30 __fput+0x3c6/0xb30 __fput_sync+0x7b/0x90 __x64_sys_close+0x90/0x120 do_syscall_64+0x5d/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is: bpf_prog_attach(BPF_SK_SKB_STREAM_VERDICT) tcp_set_ulp //set ulp after sockmap add icsk->icsk_ulp_ops = ulp_ops; sock_hash_update_common sock_map_unref sock_map_del_link psock->psock_update_sk_prot(sk, psock, false); sk->sk_prot->close = sock_map_close sk_psock_drop sk_psock_restore_proto tcp_bpf_update_proto tls_update //not redo sk_prot to tcp prot inet_release sk->sk_prot->close sock_map_close WARN(sk->sk_prot->close == sock_map_close) commit e34a07c ("sock: redo the psock vs ULP protection check") has moved ulp check from tcp_bpf_update_proto() to psock init. If sk sets ulp after being added to sockmap, it will reset sk_prot to BPF_BASE when removed from sockmap. After the psock is dropped, it will not reset sk_prot back to the tcp prot, only tls context update is performed. This can trigger a warning in sock_map_close() due to recursion of sk->sk_prot->close. To fix this issue, skip the sk_prot operations redo when deleting link from sockmap if ULP is set. Fixes: e34a07c ("sock: redo the psock vs ULP protection check") Fixes: c0d95d3 ("bpf, sockmap: Re-evaluate proto ops when psock is removed from sockmap") Suggested-by: Cong Wang <[email protected]> Signed-off-by: Dong Chenchen <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Apr 1, 2025
WARNING: CPU: 0 PID: 6558 at net/core/sock_map.c:1703 sock_map_close+0x3c4/0x480 Modules linked in: CPU: 0 UID: 0 PID: 6558 Comm: syz-executor.14 Not tainted 6.14.0-rc5+ torvalds#238 RIP: 0010:sock_map_close+0x3c4/0x480 Call Trace: <TASK> inet_release+0x144/0x280 __sock_release+0xb8/0x270 sock_close+0x1e/0x30 __fput+0x3c6/0xb30 __fput_sync+0x7b/0x90 __x64_sys_close+0x90/0x120 do_syscall_64+0x5d/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is: bpf_prog_attach(BPF_SK_SKB_STREAM_VERDICT) tcp_set_ulp //set ulp after sockmap add icsk->icsk_ulp_ops = ulp_ops; sock_hash_update_common sock_map_unref sock_map_del_link psock->psock_update_sk_prot(sk, psock, false); sk->sk_prot->close = sock_map_close sk_psock_drop sk_psock_restore_proto tcp_bpf_update_proto tls_update //not redo sk_prot to tcp prot inet_release sk->sk_prot->close sock_map_close WARN(sk->sk_prot->close == sock_map_close) commit e34a07c ("sock: redo the psock vs ULP protection check") has moved ulp check from tcp_bpf_update_proto() to psock init. If sk sets ulp after being added to sockmap, it will reset sk_prot to BPF_BASE when removed from sockmap. After the psock is dropped, it will not reset sk_prot back to the tcp prot, only tls context update is performed. This can trigger a warning in sock_map_close() due to recursion of sk->sk_prot->close. To fix this issue, skip the sk_prot operations redo when deleting link from sockmap if ULP is set. Fixes: e34a07c ("sock: redo the psock vs ULP protection check") Fixes: c0d95d3 ("bpf, sockmap: Re-evaluate proto ops when psock is removed from sockmap") Suggested-by: Cong Wang <[email protected]> Signed-off-by: Dong Chenchen <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Apr 1, 2025
WARNING: CPU: 0 PID: 6558 at net/core/sock_map.c:1703 sock_map_close+0x3c4/0x480 Modules linked in: CPU: 0 UID: 0 PID: 6558 Comm: syz-executor.14 Not tainted 6.14.0-rc5+ torvalds#238 RIP: 0010:sock_map_close+0x3c4/0x480 Call Trace: <TASK> inet_release+0x144/0x280 __sock_release+0xb8/0x270 sock_close+0x1e/0x30 __fput+0x3c6/0xb30 __fput_sync+0x7b/0x90 __x64_sys_close+0x90/0x120 do_syscall_64+0x5d/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is: bpf_prog_attach(BPF_SK_SKB_STREAM_VERDICT) tcp_set_ulp //set ulp after sockmap add icsk->icsk_ulp_ops = ulp_ops; sock_hash_update_common sock_map_unref sock_map_del_link psock->psock_update_sk_prot(sk, psock, false); sk->sk_prot->close = sock_map_close sk_psock_drop sk_psock_restore_proto tcp_bpf_update_proto tls_update //not redo sk_prot to tcp prot inet_release sk->sk_prot->close sock_map_close WARN(sk->sk_prot->close == sock_map_close) commit e34a07c ("sock: redo the psock vs ULP protection check") has moved ulp check from tcp_bpf_update_proto() to psock init. If sk sets ulp after being added to sockmap, it will reset sk_prot to BPF_BASE when removed from sockmap. After the psock is dropped, it will not reset sk_prot back to the tcp prot, only tls context update is performed. This can trigger a warning in sock_map_close() due to recursion of sk->sk_prot->close. To fix this issue, skip the sk_prot operations redo when deleting link from sockmap if ULP is set. Fixes: e34a07c ("sock: redo the psock vs ULP protection check") Fixes: c0d95d3 ("bpf, sockmap: Re-evaluate proto ops when psock is removed from sockmap") Suggested-by: Cong Wang <[email protected]> Signed-off-by: Dong Chenchen <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Apr 1, 2025
WARNING: CPU: 0 PID: 6558 at net/core/sock_map.c:1703 sock_map_close+0x3c4/0x480 Modules linked in: CPU: 0 UID: 0 PID: 6558 Comm: syz-executor.14 Not tainted 6.14.0-rc5+ torvalds#238 RIP: 0010:sock_map_close+0x3c4/0x480 Call Trace: <TASK> inet_release+0x144/0x280 __sock_release+0xb8/0x270 sock_close+0x1e/0x30 __fput+0x3c6/0xb30 __fput_sync+0x7b/0x90 __x64_sys_close+0x90/0x120 do_syscall_64+0x5d/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is: bpf_prog_attach(BPF_SK_SKB_STREAM_VERDICT) tcp_set_ulp //set ulp after sockmap add icsk->icsk_ulp_ops = ulp_ops; sock_hash_update_common sock_map_unref sock_map_del_link psock->psock_update_sk_prot(sk, psock, false); sk->sk_prot->close = sock_map_close sk_psock_drop sk_psock_restore_proto tcp_bpf_update_proto tls_update //not redo sk_prot to tcp prot inet_release sk->sk_prot->close sock_map_close WARN(sk->sk_prot->close == sock_map_close) commit e34a07c ("sock: redo the psock vs ULP protection check") has moved ulp check from tcp_bpf_update_proto() to psock init. If sk sets ulp after being added to sockmap, it will reset sk_prot to BPF_BASE when removed from sockmap. After the psock is dropped, it will not reset sk_prot back to the tcp prot, only tls context update is performed. This can trigger a warning in sock_map_close() due to recursion of sk->sk_prot->close. To fix this issue, skip the sk_prot operations redo when deleting link from sockmap if ULP is set. Fixes: e34a07c ("sock: redo the psock vs ULP protection check") Fixes: c0d95d3 ("bpf, sockmap: Re-evaluate proto ops when psock is removed from sockmap") Suggested-by: Cong Wang <[email protected]> Signed-off-by: Dong Chenchen <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Apr 1, 2025
WARNING: CPU: 0 PID: 6558 at net/core/sock_map.c:1703 sock_map_close+0x3c4/0x480 Modules linked in: CPU: 0 UID: 0 PID: 6558 Comm: syz-executor.14 Not tainted 6.14.0-rc5+ torvalds#238 RIP: 0010:sock_map_close+0x3c4/0x480 Call Trace: <TASK> inet_release+0x144/0x280 __sock_release+0xb8/0x270 sock_close+0x1e/0x30 __fput+0x3c6/0xb30 __fput_sync+0x7b/0x90 __x64_sys_close+0x90/0x120 do_syscall_64+0x5d/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is: bpf_prog_attach(BPF_SK_SKB_STREAM_VERDICT) tcp_set_ulp //set ulp after sockmap add icsk->icsk_ulp_ops = ulp_ops; sock_hash_update_common sock_map_unref sock_map_del_link psock->psock_update_sk_prot(sk, psock, false); sk->sk_prot->close = sock_map_close sk_psock_drop sk_psock_restore_proto tcp_bpf_update_proto tls_update //not redo sk_prot to tcp prot inet_release sk->sk_prot->close sock_map_close WARN(sk->sk_prot->close == sock_map_close) commit e34a07c ("sock: redo the psock vs ULP protection check") has moved ulp check from tcp_bpf_update_proto() to psock init. If sk sets ulp after being added to sockmap, it will reset sk_prot to BPF_BASE when removed from sockmap. After the psock is dropped, it will not reset sk_prot back to the tcp prot, only tls context update is performed. This can trigger a warning in sock_map_close() due to recursion of sk->sk_prot->close. To fix this issue, skip the sk_prot operations redo when deleting link from sockmap if ULP is set. Fixes: e34a07c ("sock: redo the psock vs ULP protection check") Fixes: c0d95d3 ("bpf, sockmap: Re-evaluate proto ops when psock is removed from sockmap") Suggested-by: Cong Wang <[email protected]> Signed-off-by: Dong Chenchen <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Apr 1, 2025
WARNING: CPU: 0 PID: 6558 at net/core/sock_map.c:1703 sock_map_close+0x3c4/0x480 Modules linked in: CPU: 0 UID: 0 PID: 6558 Comm: syz-executor.14 Not tainted 6.14.0-rc5+ torvalds#238 RIP: 0010:sock_map_close+0x3c4/0x480 Call Trace: <TASK> inet_release+0x144/0x280 __sock_release+0xb8/0x270 sock_close+0x1e/0x30 __fput+0x3c6/0xb30 __fput_sync+0x7b/0x90 __x64_sys_close+0x90/0x120 do_syscall_64+0x5d/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is: bpf_prog_attach(BPF_SK_SKB_STREAM_VERDICT) tcp_set_ulp //set ulp after sockmap add icsk->icsk_ulp_ops = ulp_ops; sock_hash_update_common sock_map_unref sock_map_del_link psock->psock_update_sk_prot(sk, psock, false); sk->sk_prot->close = sock_map_close sk_psock_drop sk_psock_restore_proto tcp_bpf_update_proto tls_update //not redo sk_prot to tcp prot inet_release sk->sk_prot->close sock_map_close WARN(sk->sk_prot->close == sock_map_close) commit e34a07c ("sock: redo the psock vs ULP protection check") has moved ulp check from tcp_bpf_update_proto() to psock init. If sk sets ulp after being added to sockmap, it will reset sk_prot to BPF_BASE when removed from sockmap. After the psock is dropped, it will not reset sk_prot back to the tcp prot, only tls context update is performed. This can trigger a warning in sock_map_close() due to recursion of sk->sk_prot->close. To fix this issue, skip the sk_prot operations redo when deleting link from sockmap if ULP is set. Fixes: e34a07c ("sock: redo the psock vs ULP protection check") Fixes: c0d95d3 ("bpf, sockmap: Re-evaluate proto ops when psock is removed from sockmap") Suggested-by: Cong Wang <[email protected]> Signed-off-by: Dong Chenchen <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Apr 1, 2025
WARNING: CPU: 0 PID: 6558 at net/core/sock_map.c:1703 sock_map_close+0x3c4/0x480 Modules linked in: CPU: 0 UID: 0 PID: 6558 Comm: syz-executor.14 Not tainted 6.14.0-rc5+ torvalds#238 RIP: 0010:sock_map_close+0x3c4/0x480 Call Trace: <TASK> inet_release+0x144/0x280 __sock_release+0xb8/0x270 sock_close+0x1e/0x30 __fput+0x3c6/0xb30 __fput_sync+0x7b/0x90 __x64_sys_close+0x90/0x120 do_syscall_64+0x5d/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is: bpf_prog_attach(BPF_SK_SKB_STREAM_VERDICT) tcp_set_ulp //set ulp after sockmap add icsk->icsk_ulp_ops = ulp_ops; sock_hash_update_common sock_map_unref sock_map_del_link psock->psock_update_sk_prot(sk, psock, false); sk->sk_prot->close = sock_map_close sk_psock_drop sk_psock_restore_proto tcp_bpf_update_proto tls_update //not redo sk_prot to tcp prot inet_release sk->sk_prot->close sock_map_close WARN(sk->sk_prot->close == sock_map_close) commit e34a07c ("sock: redo the psock vs ULP protection check") has moved ulp check from tcp_bpf_update_proto() to psock init. If sk sets ulp after being added to sockmap, it will reset sk_prot to BPF_BASE when removed from sockmap. After the psock is dropped, it will not reset sk_prot back to the tcp prot, only tls context update is performed. This can trigger a warning in sock_map_close() due to recursion of sk->sk_prot->close. To fix this issue, skip the sk_prot operations redo when deleting link from sockmap if ULP is set. Fixes: e34a07c ("sock: redo the psock vs ULP protection check") Fixes: c0d95d3 ("bpf, sockmap: Re-evaluate proto ops when psock is removed from sockmap") Suggested-by: Cong Wang <[email protected]> Signed-off-by: Dong Chenchen <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Apr 1, 2025
WARNING: CPU: 0 PID: 6558 at net/core/sock_map.c:1703 sock_map_close+0x3c4/0x480 Modules linked in: CPU: 0 UID: 0 PID: 6558 Comm: syz-executor.14 Not tainted 6.14.0-rc5+ torvalds#238 RIP: 0010:sock_map_close+0x3c4/0x480 Call Trace: <TASK> inet_release+0x144/0x280 __sock_release+0xb8/0x270 sock_close+0x1e/0x30 __fput+0x3c6/0xb30 __fput_sync+0x7b/0x90 __x64_sys_close+0x90/0x120 do_syscall_64+0x5d/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is: bpf_prog_attach(BPF_SK_SKB_STREAM_VERDICT) tcp_set_ulp //set ulp after sockmap add icsk->icsk_ulp_ops = ulp_ops; sock_hash_update_common sock_map_unref sock_map_del_link psock->psock_update_sk_prot(sk, psock, false); sk->sk_prot->close = sock_map_close sk_psock_drop sk_psock_restore_proto tcp_bpf_update_proto tls_update //not redo sk_prot to tcp prot inet_release sk->sk_prot->close sock_map_close WARN(sk->sk_prot->close == sock_map_close) commit e34a07c ("sock: redo the psock vs ULP protection check") has moved ulp check from tcp_bpf_update_proto() to psock init. If sk sets ulp after being added to sockmap, it will reset sk_prot to BPF_BASE when removed from sockmap. After the psock is dropped, it will not reset sk_prot back to the tcp prot, only tls context update is performed. This can trigger a warning in sock_map_close() due to recursion of sk->sk_prot->close. To fix this issue, skip the sk_prot operations redo when deleting link from sockmap if ULP is set. Fixes: e34a07c ("sock: redo the psock vs ULP protection check") Fixes: c0d95d3 ("bpf, sockmap: Re-evaluate proto ops when psock is removed from sockmap") Suggested-by: Cong Wang <[email protected]> Signed-off-by: Dong Chenchen <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Apr 2, 2025
WARNING: CPU: 0 PID: 6558 at net/core/sock_map.c:1703 sock_map_close+0x3c4/0x480 Modules linked in: CPU: 0 UID: 0 PID: 6558 Comm: syz-executor.14 Not tainted 6.14.0-rc5+ torvalds#238 RIP: 0010:sock_map_close+0x3c4/0x480 Call Trace: <TASK> inet_release+0x144/0x280 __sock_release+0xb8/0x270 sock_close+0x1e/0x30 __fput+0x3c6/0xb30 __fput_sync+0x7b/0x90 __x64_sys_close+0x90/0x120 do_syscall_64+0x5d/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is: bpf_prog_attach(BPF_SK_SKB_STREAM_VERDICT) tcp_set_ulp //set ulp after sockmap add icsk->icsk_ulp_ops = ulp_ops; sock_hash_update_common sock_map_unref sock_map_del_link psock->psock_update_sk_prot(sk, psock, false); sk->sk_prot->close = sock_map_close sk_psock_drop sk_psock_restore_proto tcp_bpf_update_proto tls_update //not redo sk_prot to tcp prot inet_release sk->sk_prot->close sock_map_close WARN(sk->sk_prot->close == sock_map_close) commit e34a07c ("sock: redo the psock vs ULP protection check") has moved ulp check from tcp_bpf_update_proto() to psock init. If sk sets ulp after being added to sockmap, it will reset sk_prot to BPF_BASE when removed from sockmap. After the psock is dropped, it will not reset sk_prot back to the tcp prot, only tls context update is performed. This can trigger a warning in sock_map_close() due to recursion of sk->sk_prot->close. To fix this issue, skip the sk_prot operations redo when deleting link from sockmap if ULP is set. Fixes: e34a07c ("sock: redo the psock vs ULP protection check") Fixes: c0d95d3 ("bpf, sockmap: Re-evaluate proto ops when psock is removed from sockmap") Suggested-by: Cong Wang <[email protected]> Signed-off-by: Dong Chenchen <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Apr 2, 2025
WARNING: CPU: 0 PID: 6558 at net/core/sock_map.c:1703 sock_map_close+0x3c4/0x480 Modules linked in: CPU: 0 UID: 0 PID: 6558 Comm: syz-executor.14 Not tainted 6.14.0-rc5+ torvalds#238 RIP: 0010:sock_map_close+0x3c4/0x480 Call Trace: <TASK> inet_release+0x144/0x280 __sock_release+0xb8/0x270 sock_close+0x1e/0x30 __fput+0x3c6/0xb30 __fput_sync+0x7b/0x90 __x64_sys_close+0x90/0x120 do_syscall_64+0x5d/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is: bpf_prog_attach(BPF_SK_SKB_STREAM_VERDICT) tcp_set_ulp //set ulp after sockmap add icsk->icsk_ulp_ops = ulp_ops; sock_hash_update_common sock_map_unref sock_map_del_link psock->psock_update_sk_prot(sk, psock, false); sk->sk_prot->close = sock_map_close sk_psock_drop sk_psock_restore_proto tcp_bpf_update_proto tls_update //not redo sk_prot to tcp prot inet_release sk->sk_prot->close sock_map_close WARN(sk->sk_prot->close == sock_map_close) commit e34a07c ("sock: redo the psock vs ULP protection check") has moved ulp check from tcp_bpf_update_proto() to psock init. If sk sets ulp after being added to sockmap, it will reset sk_prot to BPF_BASE when removed from sockmap. After the psock is dropped, it will not reset sk_prot back to the tcp prot, only tls context update is performed. This can trigger a warning in sock_map_close() due to recursion of sk->sk_prot->close. To fix this issue, skip the sk_prot operations redo when deleting link from sockmap if ULP is set. Fixes: e34a07c ("sock: redo the psock vs ULP protection check") Fixes: c0d95d3 ("bpf, sockmap: Re-evaluate proto ops when psock is removed from sockmap") Suggested-by: Cong Wang <[email protected]> Signed-off-by: Dong Chenchen <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Apr 2, 2025
WARNING: CPU: 0 PID: 6558 at net/core/sock_map.c:1703 sock_map_close+0x3c4/0x480 Modules linked in: CPU: 0 UID: 0 PID: 6558 Comm: syz-executor.14 Not tainted 6.14.0-rc5+ torvalds#238 RIP: 0010:sock_map_close+0x3c4/0x480 Call Trace: <TASK> inet_release+0x144/0x280 __sock_release+0xb8/0x270 sock_close+0x1e/0x30 __fput+0x3c6/0xb30 __fput_sync+0x7b/0x90 __x64_sys_close+0x90/0x120 do_syscall_64+0x5d/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is: bpf_prog_attach(BPF_SK_SKB_STREAM_VERDICT) tcp_set_ulp //set ulp after sockmap add icsk->icsk_ulp_ops = ulp_ops; sock_hash_update_common sock_map_unref sock_map_del_link psock->psock_update_sk_prot(sk, psock, false); sk->sk_prot->close = sock_map_close sk_psock_drop sk_psock_restore_proto tcp_bpf_update_proto tls_update //not redo sk_prot to tcp prot inet_release sk->sk_prot->close sock_map_close WARN(sk->sk_prot->close == sock_map_close) commit e34a07c ("sock: redo the psock vs ULP protection check") has moved ulp check from tcp_bpf_update_proto() to psock init. If sk sets ulp after being added to sockmap, it will reset sk_prot to BPF_BASE when removed from sockmap. After the psock is dropped, it will not reset sk_prot back to the tcp prot, only tls context update is performed. This can trigger a warning in sock_map_close() due to recursion of sk->sk_prot->close. To fix this issue, skip the sk_prot operations redo when deleting link from sockmap if ULP is set. Fixes: e34a07c ("sock: redo the psock vs ULP protection check") Fixes: c0d95d3 ("bpf, sockmap: Re-evaluate proto ops when psock is removed from sockmap") Suggested-by: Cong Wang <[email protected]> Signed-off-by: Dong Chenchen <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Apr 2, 2025
WARNING: CPU: 0 PID: 6558 at net/core/sock_map.c:1703 sock_map_close+0x3c4/0x480 Modules linked in: CPU: 0 UID: 0 PID: 6558 Comm: syz-executor.14 Not tainted 6.14.0-rc5+ torvalds#238 RIP: 0010:sock_map_close+0x3c4/0x480 Call Trace: <TASK> inet_release+0x144/0x280 __sock_release+0xb8/0x270 sock_close+0x1e/0x30 __fput+0x3c6/0xb30 __fput_sync+0x7b/0x90 __x64_sys_close+0x90/0x120 do_syscall_64+0x5d/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is: bpf_prog_attach(BPF_SK_SKB_STREAM_VERDICT) tcp_set_ulp //set ulp after sockmap add icsk->icsk_ulp_ops = ulp_ops; sock_hash_update_common sock_map_unref sock_map_del_link psock->psock_update_sk_prot(sk, psock, false); sk->sk_prot->close = sock_map_close sk_psock_drop sk_psock_restore_proto tcp_bpf_update_proto tls_update //not redo sk_prot to tcp prot inet_release sk->sk_prot->close sock_map_close WARN(sk->sk_prot->close == sock_map_close) commit e34a07c ("sock: redo the psock vs ULP protection check") has moved ulp check from tcp_bpf_update_proto() to psock init. If sk sets ulp after being added to sockmap, it will reset sk_prot to BPF_BASE when removed from sockmap. After the psock is dropped, it will not reset sk_prot back to the tcp prot, only tls context update is performed. This can trigger a warning in sock_map_close() due to recursion of sk->sk_prot->close. To fix this issue, skip the sk_prot operations redo when deleting link from sockmap if ULP is set. Fixes: e34a07c ("sock: redo the psock vs ULP protection check") Fixes: c0d95d3 ("bpf, sockmap: Re-evaluate proto ops when psock is removed from sockmap") Suggested-by: Cong Wang <[email protected]> Signed-off-by: Dong Chenchen <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Apr 2, 2025
WARNING: CPU: 0 PID: 6558 at net/core/sock_map.c:1703 sock_map_close+0x3c4/0x480 Modules linked in: CPU: 0 UID: 0 PID: 6558 Comm: syz-executor.14 Not tainted 6.14.0-rc5+ torvalds#238 RIP: 0010:sock_map_close+0x3c4/0x480 Call Trace: <TASK> inet_release+0x144/0x280 __sock_release+0xb8/0x270 sock_close+0x1e/0x30 __fput+0x3c6/0xb30 __fput_sync+0x7b/0x90 __x64_sys_close+0x90/0x120 do_syscall_64+0x5d/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is: bpf_prog_attach(BPF_SK_SKB_STREAM_VERDICT) tcp_set_ulp //set ulp after sockmap add icsk->icsk_ulp_ops = ulp_ops; sock_hash_update_common sock_map_unref sock_map_del_link psock->psock_update_sk_prot(sk, psock, false); sk->sk_prot->close = sock_map_close sk_psock_drop sk_psock_restore_proto tcp_bpf_update_proto tls_update //not redo sk_prot to tcp prot inet_release sk->sk_prot->close sock_map_close WARN(sk->sk_prot->close == sock_map_close) commit e34a07c ("sock: redo the psock vs ULP protection check") has moved ulp check from tcp_bpf_update_proto() to psock init. If sk sets ulp after being added to sockmap, it will reset sk_prot to BPF_BASE when removed from sockmap. After the psock is dropped, it will not reset sk_prot back to the tcp prot, only tls context update is performed. This can trigger a warning in sock_map_close() due to recursion of sk->sk_prot->close. To fix this issue, skip the sk_prot operations redo when deleting link from sockmap if ULP is set. Fixes: e34a07c ("sock: redo the psock vs ULP protection check") Fixes: c0d95d3 ("bpf, sockmap: Re-evaluate proto ops when psock is removed from sockmap") Suggested-by: Cong Wang <[email protected]> Signed-off-by: Dong Chenchen <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Apr 2, 2025
WARNING: CPU: 0 PID: 6558 at net/core/sock_map.c:1703 sock_map_close+0x3c4/0x480 Modules linked in: CPU: 0 UID: 0 PID: 6558 Comm: syz-executor.14 Not tainted 6.14.0-rc5+ torvalds#238 RIP: 0010:sock_map_close+0x3c4/0x480 Call Trace: <TASK> inet_release+0x144/0x280 __sock_release+0xb8/0x270 sock_close+0x1e/0x30 __fput+0x3c6/0xb30 __fput_sync+0x7b/0x90 __x64_sys_close+0x90/0x120 do_syscall_64+0x5d/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is: bpf_prog_attach(BPF_SK_SKB_STREAM_VERDICT) tcp_set_ulp //set ulp after sockmap add icsk->icsk_ulp_ops = ulp_ops; sock_hash_update_common sock_map_unref sock_map_del_link psock->psock_update_sk_prot(sk, psock, false); sk->sk_prot->close = sock_map_close sk_psock_drop sk_psock_restore_proto tcp_bpf_update_proto tls_update //not redo sk_prot to tcp prot inet_release sk->sk_prot->close sock_map_close WARN(sk->sk_prot->close == sock_map_close) commit e34a07c ("sock: redo the psock vs ULP protection check") has moved ulp check from tcp_bpf_update_proto() to psock init. If sk sets ulp after being added to sockmap, it will reset sk_prot to BPF_BASE when removed from sockmap. After the psock is dropped, it will not reset sk_prot back to the tcp prot, only tls context update is performed. This can trigger a warning in sock_map_close() due to recursion of sk->sk_prot->close. To fix this issue, skip the sk_prot operations redo when deleting link from sockmap if ULP is set. Fixes: e34a07c ("sock: redo the psock vs ULP protection check") Fixes: c0d95d3 ("bpf, sockmap: Re-evaluate proto ops when psock is removed from sockmap") Suggested-by: Cong Wang <[email protected]> Signed-off-by: Dong Chenchen <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Apr 2, 2025
WARNING: CPU: 0 PID: 6558 at net/core/sock_map.c:1703 sock_map_close+0x3c4/0x480 Modules linked in: CPU: 0 UID: 0 PID: 6558 Comm: syz-executor.14 Not tainted 6.14.0-rc5+ torvalds#238 RIP: 0010:sock_map_close+0x3c4/0x480 Call Trace: <TASK> inet_release+0x144/0x280 __sock_release+0xb8/0x270 sock_close+0x1e/0x30 __fput+0x3c6/0xb30 __fput_sync+0x7b/0x90 __x64_sys_close+0x90/0x120 do_syscall_64+0x5d/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is: bpf_prog_attach(BPF_SK_SKB_STREAM_VERDICT) tcp_set_ulp //set ulp after sockmap add icsk->icsk_ulp_ops = ulp_ops; sock_hash_update_common sock_map_unref sock_map_del_link psock->psock_update_sk_prot(sk, psock, false); sk->sk_prot->close = sock_map_close sk_psock_drop sk_psock_restore_proto tcp_bpf_update_proto tls_update //not redo sk_prot to tcp prot inet_release sk->sk_prot->close sock_map_close WARN(sk->sk_prot->close == sock_map_close) commit e34a07c ("sock: redo the psock vs ULP protection check") has moved ulp check from tcp_bpf_update_proto() to psock init. If sk sets ulp after being added to sockmap, it will reset sk_prot to BPF_BASE when removed from sockmap. After the psock is dropped, it will not reset sk_prot back to the tcp prot, only tls context update is performed. This can trigger a warning in sock_map_close() due to recursion of sk->sk_prot->close. To fix this issue, skip the sk_prot operations redo when deleting link from sockmap if ULP is set. Fixes: e34a07c ("sock: redo the psock vs ULP protection check") Fixes: c0d95d3 ("bpf, sockmap: Re-evaluate proto ops when psock is removed from sockmap") Suggested-by: Cong Wang <[email protected]> Signed-off-by: Dong Chenchen <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Apr 2, 2025
WARNING: CPU: 0 PID: 6558 at net/core/sock_map.c:1703 sock_map_close+0x3c4/0x480 Modules linked in: CPU: 0 UID: 0 PID: 6558 Comm: syz-executor.14 Not tainted 6.14.0-rc5+ torvalds#238 RIP: 0010:sock_map_close+0x3c4/0x480 Call Trace: <TASK> inet_release+0x144/0x280 __sock_release+0xb8/0x270 sock_close+0x1e/0x30 __fput+0x3c6/0xb30 __fput_sync+0x7b/0x90 __x64_sys_close+0x90/0x120 do_syscall_64+0x5d/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is: bpf_prog_attach(BPF_SK_SKB_STREAM_VERDICT) tcp_set_ulp //set ulp after sockmap add icsk->icsk_ulp_ops = ulp_ops; sock_hash_update_common sock_map_unref sock_map_del_link psock->psock_update_sk_prot(sk, psock, false); sk->sk_prot->close = sock_map_close sk_psock_drop sk_psock_restore_proto tcp_bpf_update_proto tls_update //not redo sk_prot to tcp prot inet_release sk->sk_prot->close sock_map_close WARN(sk->sk_prot->close == sock_map_close) commit e34a07c ("sock: redo the psock vs ULP protection check") has moved ulp check from tcp_bpf_update_proto() to psock init. If sk sets ulp after being added to sockmap, it will reset sk_prot to BPF_BASE when removed from sockmap. After the psock is dropped, it will not reset sk_prot back to the tcp prot, only tls context update is performed. This can trigger a warning in sock_map_close() due to recursion of sk->sk_prot->close. To fix this issue, skip the sk_prot operations redo when deleting link from sockmap if ULP is set. Fixes: e34a07c ("sock: redo the psock vs ULP protection check") Fixes: c0d95d3 ("bpf, sockmap: Re-evaluate proto ops when psock is removed from sockmap") Suggested-by: Cong Wang <[email protected]> Signed-off-by: Dong Chenchen <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Apr 2, 2025
WARNING: CPU: 0 PID: 6558 at net/core/sock_map.c:1703 sock_map_close+0x3c4/0x480 Modules linked in: CPU: 0 UID: 0 PID: 6558 Comm: syz-executor.14 Not tainted 6.14.0-rc5+ torvalds#238 RIP: 0010:sock_map_close+0x3c4/0x480 Call Trace: <TASK> inet_release+0x144/0x280 __sock_release+0xb8/0x270 sock_close+0x1e/0x30 __fput+0x3c6/0xb30 __fput_sync+0x7b/0x90 __x64_sys_close+0x90/0x120 do_syscall_64+0x5d/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is: bpf_prog_attach(BPF_SK_SKB_STREAM_VERDICT) tcp_set_ulp //set ulp after sockmap add icsk->icsk_ulp_ops = ulp_ops; sock_hash_update_common sock_map_unref sock_map_del_link psock->psock_update_sk_prot(sk, psock, false); sk->sk_prot->close = sock_map_close sk_psock_drop sk_psock_restore_proto tcp_bpf_update_proto tls_update //not redo sk_prot to tcp prot inet_release sk->sk_prot->close sock_map_close WARN(sk->sk_prot->close == sock_map_close) commit e34a07c ("sock: redo the psock vs ULP protection check") has moved ulp check from tcp_bpf_update_proto() to psock init. If sk sets ulp after being added to sockmap, it will reset sk_prot to BPF_BASE when removed from sockmap. After the psock is dropped, it will not reset sk_prot back to the tcp prot, only tls context update is performed. This can trigger a warning in sock_map_close() due to recursion of sk->sk_prot->close. To fix this issue, skip the sk_prot operations redo when deleting link from sockmap if ULP is set. Fixes: e34a07c ("sock: redo the psock vs ULP protection check") Fixes: c0d95d3 ("bpf, sockmap: Re-evaluate proto ops when psock is removed from sockmap") Suggested-by: Cong Wang <[email protected]> Signed-off-by: Dong Chenchen <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Apr 2, 2025
WARNING: CPU: 0 PID: 6558 at net/core/sock_map.c:1703 sock_map_close+0x3c4/0x480 Modules linked in: CPU: 0 UID: 0 PID: 6558 Comm: syz-executor.14 Not tainted 6.14.0-rc5+ torvalds#238 RIP: 0010:sock_map_close+0x3c4/0x480 Call Trace: <TASK> inet_release+0x144/0x280 __sock_release+0xb8/0x270 sock_close+0x1e/0x30 __fput+0x3c6/0xb30 __fput_sync+0x7b/0x90 __x64_sys_close+0x90/0x120 do_syscall_64+0x5d/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is: bpf_prog_attach(BPF_SK_SKB_STREAM_VERDICT) tcp_set_ulp //set ulp after sockmap add icsk->icsk_ulp_ops = ulp_ops; sock_hash_update_common sock_map_unref sock_map_del_link psock->psock_update_sk_prot(sk, psock, false); sk->sk_prot->close = sock_map_close sk_psock_drop sk_psock_restore_proto tcp_bpf_update_proto tls_update //not redo sk_prot to tcp prot inet_release sk->sk_prot->close sock_map_close WARN(sk->sk_prot->close == sock_map_close) commit e34a07c ("sock: redo the psock vs ULP protection check") has moved ulp check from tcp_bpf_update_proto() to psock init. If sk sets ulp after being added to sockmap, it will reset sk_prot to BPF_BASE when removed from sockmap. After the psock is dropped, it will not reset sk_prot back to the tcp prot, only tls context update is performed. This can trigger a warning in sock_map_close() due to recursion of sk->sk_prot->close. To fix this issue, skip the sk_prot operations redo when deleting link from sockmap if ULP is set. Fixes: e34a07c ("sock: redo the psock vs ULP protection check") Fixes: c0d95d3 ("bpf, sockmap: Re-evaluate proto ops when psock is removed from sockmap") Suggested-by: Cong Wang <[email protected]> Signed-off-by: Dong Chenchen <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Apr 3, 2025
WARNING: CPU: 0 PID: 6558 at net/core/sock_map.c:1703 sock_map_close+0x3c4/0x480 Modules linked in: CPU: 0 UID: 0 PID: 6558 Comm: syz-executor.14 Not tainted 6.14.0-rc5+ torvalds#238 RIP: 0010:sock_map_close+0x3c4/0x480 Call Trace: <TASK> inet_release+0x144/0x280 __sock_release+0xb8/0x270 sock_close+0x1e/0x30 __fput+0x3c6/0xb30 __fput_sync+0x7b/0x90 __x64_sys_close+0x90/0x120 do_syscall_64+0x5d/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is: bpf_prog_attach(BPF_SK_SKB_STREAM_VERDICT) tcp_set_ulp //set ulp after sockmap add icsk->icsk_ulp_ops = ulp_ops; sock_hash_update_common sock_map_unref sock_map_del_link psock->psock_update_sk_prot(sk, psock, false); sk->sk_prot->close = sock_map_close sk_psock_drop sk_psock_restore_proto tcp_bpf_update_proto tls_update //not redo sk_prot to tcp prot inet_release sk->sk_prot->close sock_map_close WARN(sk->sk_prot->close == sock_map_close) commit e34a07c ("sock: redo the psock vs ULP protection check") has moved ulp check from tcp_bpf_update_proto() to psock init. If sk sets ulp after being added to sockmap, it will reset sk_prot to BPF_BASE when removed from sockmap. After the psock is dropped, it will not reset sk_prot back to the tcp prot, only tls context update is performed. This can trigger a warning in sock_map_close() due to recursion of sk->sk_prot->close. To fix this issue, skip the sk_prot operations redo when deleting link from sockmap if ULP is set. Fixes: e34a07c ("sock: redo the psock vs ULP protection check") Fixes: c0d95d3 ("bpf, sockmap: Re-evaluate proto ops when psock is removed from sockmap") Suggested-by: Cong Wang <[email protected]> Signed-off-by: Dong Chenchen <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this pull request
Apr 3, 2025
WARNING: CPU: 0 PID: 6558 at net/core/sock_map.c:1703 sock_map_close+0x3c4/0x480 Modules linked in: CPU: 0 UID: 0 PID: 6558 Comm: syz-executor.14 Not tainted 6.14.0-rc5+ torvalds#238 RIP: 0010:sock_map_close+0x3c4/0x480 Call Trace: <TASK> inet_release+0x144/0x280 __sock_release+0xb8/0x270 sock_close+0x1e/0x30 __fput+0x3c6/0xb30 __fput_sync+0x7b/0x90 __x64_sys_close+0x90/0x120 do_syscall_64+0x5d/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is: bpf_prog_attach(BPF_SK_SKB_STREAM_VERDICT) tcp_set_ulp //set ulp after sockmap add icsk->icsk_ulp_ops = ulp_ops; sock_hash_update_common sock_map_unref sock_map_del_link psock->psock_update_sk_prot(sk, psock, false); sk->sk_prot->close = sock_map_close sk_psock_drop sk_psock_restore_proto tcp_bpf_update_proto tls_update //not redo sk_prot to tcp prot inet_release sk->sk_prot->close sock_map_close WARN(sk->sk_prot->close == sock_map_close) commit e34a07c ("sock: redo the psock vs ULP protection check") has moved ulp check from tcp_bpf_update_proto() to psock init. If sk sets ulp after being added to sockmap, it will reset sk_prot to BPF_BASE when removed from sockmap. After the psock is dropped, it will not reset sk_prot back to the tcp prot, only tls context update is performed. This can trigger a warning in sock_map_close() due to recursion of sk->sk_prot->close. To fix this issue, skip the sk_prot operations redo when deleting link from sockmap if ULP is set. Fixes: e34a07c ("sock: redo the psock vs ULP protection check") Fixes: c0d95d3 ("bpf, sockmap: Re-evaluate proto ops when psock is removed from sockmap") Suggested-by: Cong Wang <[email protected]> Signed-off-by: Dong Chenchen <[email protected]> Signed-off-by: NipaLocal <nipa@local>
scpcom
pushed a commit
to scpcom/linux-archive
that referenced
this pull request
Apr 27, 2025
[ Upstream commit c42a0e2 ] We met NULL pointer BUG as follow: [ 151.760358] BUG: unable to handle kernel NULL pointer dereference at 0000000000000060 [ 151.761340] PGD 80000001011eb067 P4D 80000001011eb067 PUD 1011ea067 PMD 0 [ 151.762039] Oops: 0000 [#1] SMP PTI [ 151.762406] Modules linked in: [ 151.762723] CPU: 2 PID: 3561 Comm: mdadm-test Kdump: loaded Not tainted 4.17.0-rc1+ torvalds#238 [ 151.763542] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1.fc26 04/01/2014 [ 151.764432] RIP: 0010:remove_and_add_spares.part.56+0x13c/0x3a0 [ 151.765061] RSP: 0018:ffffc90001d7fcd8 EFLAGS: 00010246 [ 151.765590] RAX: 0000000000000000 RBX: ffff88013601d600 RCX: 0000000000000000 [ 151.766306] RDX: 0000000000000000 RSI: ffff88013601d600 RDI: ffff880136187000 [ 151.767014] RBP: ffff880136187018 R08: 0000000000000003 R09: 0000000000000051 [ 151.767728] R10: ffffc90001d7fed8 R11: 0000000000000000 R12: ffff88013601d600 [ 151.768447] R13: ffff8801298b1300 R14: ffff880136187000 R15: 0000000000000000 [ 151.769160] FS: 00007f2624276700(0000) GS:ffff88013ae80000(0000) knlGS:0000000000000000 [ 151.769971] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 151.770554] CR2: 0000000000000060 CR3: 0000000111aac000 CR4: 00000000000006e0 [ 151.771272] Call Trace: [ 151.771542] md_ioctl+0x1df2/0x1e10 [ 151.771906] ? __switch_to+0x129/0x440 [ 151.772295] ? __schedule+0x244/0x850 [ 151.772672] blkdev_ioctl+0x4bd/0x970 [ 151.773048] block_ioctl+0x39/0x40 [ 151.773402] do_vfs_ioctl+0xa4/0x610 [ 151.773770] ? dput.part.23+0x87/0x100 [ 151.774151] ksys_ioctl+0x70/0x80 [ 151.774493] __x64_sys_ioctl+0x16/0x20 [ 151.774877] do_syscall_64+0x5b/0x180 [ 151.775258] entry_SYSCALL_64_after_hwframe+0x44/0xa9 For raid6, when two disk of the array are offline, two spare disks can be added into the array. Before spare disks recovery completing, system reboot and mdadm thinks it is ok to restart the degraded array by md_ioctl(). Since disks in raid6 is not only_parity(), raid5_run() will abort, when there is no PPL feature or not setting 'start_dirty_degraded' parameter. Therefore, mddev->pers is NULL. But, mddev->raid_disks has been set and it will not be cleared when raid5_run abort. md_ioctl() can execute cmd 'HOT_REMOVE_DISK' to remove a disk by mdadm, which will cause NULL pointer dereference in remove_and_add_spares() finally. Signed-off-by: Yufen Yu <[email protected]> Signed-off-by: Shaohua Li <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Update from original