fixed typos and grammar errors #183
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
fixed typos and grammar errors of both Korean and English 안녕하세요! 오늘 학교에서 진행한 미니콘서트에서 배운 대로 코드 구경을 하다가 몇 가지 오타랑 띄어쓰기 오류가 보여서 수정해보았습니다... 이렇게 해도 되는 건 진 아직 잘 모르겠지만.. ;; 맞는다면 이게 제 첫 contribution이 되겠네요!! 그럼 수고하세요~~
|
Please read the documentation: https://github.com/torvalds/linux/blob/master/Documentation/SubmittingPatches Linus doesn't accept pull requests from GitHub: #17 (comment) |
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Oct 18, 2015
WARNING: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() torvalds#46: FILE: drivers/gpu/drm/drm_gem.c:494: + BUG_ON(mapping_gfp_constraint(mapping, __GFP_DMA32) && WARNING: line over 80 characters torvalds#73: FILE: fs/btrfs/compression.c:485: + page = __page_cache_alloc(mapping_gfp_constraint(mapping, ~__GFP_FS)); WARNING: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() torvalds#183: FILE: fs/logfs/segment.c:60: + BUG_ON(mapping_gfp_constraint(mapping, __GFP_FS)); WARNING: line over 80 characters torvalds#228: FILE: fs/nilfs2/inode.c:359: + mapping_gfp_constraint(inode->i_mapping, ~__GFP_FS)); WARNING: line over 80 characters torvalds#237: FILE: fs/nilfs2/inode.c:525: + mapping_gfp_constraint(inode->i_mapping, ~__GFP_FS)); WARNING: line over 80 characters torvalds#249: FILE: fs/ntfs/file.c:529: + mapping_gfp_constraint(mapping, GFP_KERNEL)); WARNING: line over 80 characters torvalds#261: FILE: fs/splice.c:363: + mapping_gfp_constraint(mapping, GFP_KERNEL)); WARNING: line over 80 characters torvalds#290: FILE: mm/filemap.c:1725: + mapping_gfp_constraint(mapping, GFP_KERNEL)); total: 0 errors, 8 warnings, 205 lines checked ./patches/mm-fs-introduce-mapping_gfp_constraint.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Michal Hocko <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Oct 21, 2015
WARNING: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() torvalds#46: FILE: drivers/gpu/drm/drm_gem.c:494: + BUG_ON(mapping_gfp_constraint(mapping, __GFP_DMA32) && WARNING: line over 80 characters torvalds#73: FILE: fs/btrfs/compression.c:485: + page = __page_cache_alloc(mapping_gfp_constraint(mapping, ~__GFP_FS)); WARNING: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() torvalds#183: FILE: fs/logfs/segment.c:60: + BUG_ON(mapping_gfp_constraint(mapping, __GFP_FS)); WARNING: line over 80 characters torvalds#228: FILE: fs/nilfs2/inode.c:359: + mapping_gfp_constraint(inode->i_mapping, ~__GFP_FS)); WARNING: line over 80 characters torvalds#237: FILE: fs/nilfs2/inode.c:525: + mapping_gfp_constraint(inode->i_mapping, ~__GFP_FS)); WARNING: line over 80 characters torvalds#249: FILE: fs/ntfs/file.c:529: + mapping_gfp_constraint(mapping, GFP_KERNEL)); WARNING: line over 80 characters torvalds#261: FILE: fs/splice.c:363: + mapping_gfp_constraint(mapping, GFP_KERNEL)); WARNING: line over 80 characters torvalds#290: FILE: mm/filemap.c:1725: + mapping_gfp_constraint(mapping, GFP_KERNEL)); total: 0 errors, 8 warnings, 205 lines checked ./patches/mm-fs-introduce-mapping_gfp_constraint.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Michal Hocko <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Oct 22, 2015
WARNING: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() torvalds#46: FILE: drivers/gpu/drm/drm_gem.c:494: + BUG_ON(mapping_gfp_constraint(mapping, __GFP_DMA32) && WARNING: line over 80 characters torvalds#73: FILE: fs/btrfs/compression.c:485: + page = __page_cache_alloc(mapping_gfp_constraint(mapping, ~__GFP_FS)); WARNING: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() torvalds#183: FILE: fs/logfs/segment.c:60: + BUG_ON(mapping_gfp_constraint(mapping, __GFP_FS)); WARNING: line over 80 characters torvalds#228: FILE: fs/nilfs2/inode.c:359: + mapping_gfp_constraint(inode->i_mapping, ~__GFP_FS)); WARNING: line over 80 characters torvalds#237: FILE: fs/nilfs2/inode.c:525: + mapping_gfp_constraint(inode->i_mapping, ~__GFP_FS)); WARNING: line over 80 characters torvalds#249: FILE: fs/ntfs/file.c:529: + mapping_gfp_constraint(mapping, GFP_KERNEL)); WARNING: line over 80 characters torvalds#261: FILE: fs/splice.c:363: + mapping_gfp_constraint(mapping, GFP_KERNEL)); WARNING: line over 80 characters torvalds#290: FILE: mm/filemap.c:1725: + mapping_gfp_constraint(mapping, GFP_KERNEL)); total: 0 errors, 8 warnings, 205 lines checked ./patches/mm-fs-introduce-mapping_gfp_constraint.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Michal Hocko <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
nhoriguchi
pushed a commit
to nhoriguchi/linux
that referenced
this pull request
Oct 30, 2015
WARNING: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() torvalds#46: FILE: drivers/gpu/drm/drm_gem.c:494: + BUG_ON(mapping_gfp_constraint(mapping, __GFP_DMA32) && WARNING: line over 80 characters torvalds#73: FILE: fs/btrfs/compression.c:485: + page = __page_cache_alloc(mapping_gfp_constraint(mapping, ~__GFP_FS)); WARNING: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() torvalds#183: FILE: fs/logfs/segment.c:60: + BUG_ON(mapping_gfp_constraint(mapping, __GFP_FS)); WARNING: line over 80 characters torvalds#228: FILE: fs/nilfs2/inode.c:359: + mapping_gfp_constraint(inode->i_mapping, ~__GFP_FS)); WARNING: line over 80 characters torvalds#237: FILE: fs/nilfs2/inode.c:525: + mapping_gfp_constraint(inode->i_mapping, ~__GFP_FS)); WARNING: line over 80 characters torvalds#249: FILE: fs/ntfs/file.c:529: + mapping_gfp_constraint(mapping, GFP_KERNEL)); WARNING: line over 80 characters torvalds#261: FILE: fs/splice.c:363: + mapping_gfp_constraint(mapping, GFP_KERNEL)); WARNING: line over 80 characters torvalds#290: FILE: mm/filemap.c:1725: + mapping_gfp_constraint(mapping, GFP_KERNEL)); total: 0 errors, 8 warnings, 205 lines checked ./patches/mm-fs-introduce-mapping_gfp_constraint.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Michal Hocko <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Apr 4, 2016
Doing a lot of work in the interrupt handler introduces huge latencies to the system as a whole. Most dramatic effect can be seen by running an all engine stress test like igt/gem_exec_nop/all where, when the kernel config is lean enough, the whole system can be brought into multi-second periods of complete non-interactivty. That can look for example like this: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/u8:3:143] Modules linked in: [redacted for brevity] CPU: 0 PID: 143 Comm: kworker/u8:3 Tainted: G U L 4.5.0-160321+ torvalds#183 Hardware name: Intel Corporation Broadwell Client platform/WhiteTip Mountain 1 Workqueue: i915 gen6_pm_rps_work [i915] task: ffff8800aae88000 ti: ffff8800aae90000 task.ti: ffff8800aae90000 RIP: 0010:[<ffffffff8104a3c2>] [<ffffffff8104a3c2>] __do_softirq+0x72/0x1d0 RSP: 0000:ffff88014f403f38 EFLAGS: 00000206 RAX: ffff8800aae94000 RBX: 0000000000000000 RCX: 00000000000006e0 RDX: 0000000000000020 RSI: 0000000004208060 RDI: 0000000000215d80 RBP: ffff88014f403f80 R08: 0000000b1b42c180 R09: 0000000000000022 R10: 0000000000000004 R11: 00000000ffffffff R12: 000000000000a030 R13: 0000000000000082 R14: ffff8800aa4d0080 R15: 0000000000000082 FS: 0000000000000000(0000) GS:ffff88014f400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa53b90c000 CR3: 0000000001a0a000 CR4: 00000000001406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Stack: 042080601b33869f ffff8800aae94000 00000000fffc2678 ffff88010000000a 0000000000000000 000000000000a030 0000000000005302 ffff8800aa4d0080 0000000000000206 ffff88014f403f90 ffffffff8104a716 ffff88014f403fa8 Call Trace: <IRQ> [<ffffffff8104a716>] irq_exit+0x86/0x90 [<ffffffff81031e7d>] smp_apic_timer_interrupt+0x3d/0x50 [<ffffffff814f3eac>] apic_timer_interrupt+0x7c/0x90 <EOI> [<ffffffffa01c5b40>] ? gen8_write64+0x1a0/0x1a0 [i915] [<ffffffff814f2b39>] ? _raw_spin_unlock_irqrestore+0x9/0x20 [<ffffffffa01c5c44>] gen8_write32+0x104/0x1a0 [i915] [<ffffffff8132c6a2>] ? n_tty_receive_buf_common+0x372/0xae0 [<ffffffffa017cc9e>] gen6_set_rps_thresholds+0x1be/0x330 [i915] [<ffffffffa017eaf0>] gen6_set_rps+0x70/0x200 [i915] [<ffffffffa0185375>] intel_set_rps+0x25/0x30 [i915] [<ffffffffa01768fd>] gen6_pm_rps_work+0x10d/0x2e0 [i915] [<ffffffff81063852>] ? finish_task_switch+0x72/0x1c0 [<ffffffff8105ab29>] process_one_work+0x139/0x350 [<ffffffff8105b186>] worker_thread+0x126/0x490 [<ffffffff8105b060>] ? rescuer_thread+0x320/0x320 [<ffffffff8105fa64>] kthread+0xc4/0xe0 [<ffffffff8105f9a0>] ? kthread_create_on_node+0x170/0x170 [<ffffffff814f351f>] ret_from_fork+0x3f/0x70 [<ffffffff8105f9a0>] ? kthread_create_on_node+0x170/0x170 I could not explain, or find a code path, which would explain a +20 second lockup, but from some instrumentation it was apparent the interrupts off proportion of time was between 10-25% under heavy load which is quite bad. When a interrupt "cliff" is reached, which was >~320k irq/s on my machine, the whole system goes into a terrible state of the above described multi-second lockups. By moving the GT interrupt handling to a tasklet in a most simple way, the problem above disappears completely. Testing the effect on sytem-wide latencies using igt/gem_syslatency shows the following before this patch: gem_syslatency: cycles=1532739, latency mean=416531.829us max=2499237us gem_syslatency: cycles=1839434, latency mean=1458099.157us max=4998944us gem_syslatency: cycles=1432570, latency mean=2688.451us max=1201185us gem_syslatency: cycles=1533543, latency mean=416520.499us max=2498886us This shows that the unrelated process is experiencing huge delays in its wake-up latency. After the patch the results look like this: gem_syslatency: cycles=808907, latency mean=53.133us max=1640us gem_syslatency: cycles=862154, latency mean=62.778us max=2117us gem_syslatency: cycles=856039, latency mean=58.079us max=2123us gem_syslatency: cycles=841683, latency mean=56.914us max=1667us Showing a huge improvement in the unrelated process wake-up latency. It also shows an approximate halving in the number of total empty batches submitted during the test. This may not be worrying since the test puts the driver under a very unrealistic load with ncpu threads doing empty batch submission to all GPU engines each. Another benefit compared to the hard-irq handling is that now work on all engines can be dispatched in parallel since we can have up to number of CPUs active tasklets. (While previously a single hard-irq would serially dispatch on one engine after another.) More interesting scenario with regards to throughput is "gem_latency -n 100" which shows 25% better throughput and CPU usage, and 14% better dispatch latencies. I did not find any gains or regressions with Synmark2 or GLbench under light testing. More benchmarking is certainly required. v2: * execlists_lock should be taken as spin_lock_bh when queuing work from userspace now. (Chris Wilson) * uncore.lock must be taken with spin_lock_irq when submitting requests since that now runs from either softirq or process context. v3: * Expanded commit message with more testing data; * converted missed locking sites to _bh; * added execlist_lock comment. (Chris Wilson) v4: * Mention dispatch parallelism in commit. (Chris Wilson) * Do not hold uncore.lock over MMIO reads since the block is already serialised per-engine via the tasklet itself. (Chris Wilson) * intel_lrc_irq_handler should be static. (Chris Wilson) * Cancel/sync the tasklet on GPU reset. (Chris Wilson) * Document and WARN that tasklet cannot be active/pending on engine cleanup. (Chris Wilson/Imre Deak) Signed-off-by: Tvrtko Ursulin <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Imre Deak <[email protected]> Testcase: igt/gem_exec_nop/all Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94350 Reviewed-by: Chris Wilson <[email protected]>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Apr 4, 2016
Doing a lot of work in the interrupt handler introduces huge latencies to the system as a whole. Most dramatic effect can be seen by running an all engine stress test like igt/gem_exec_nop/all where, when the kernel config is lean enough, the whole system can be brought into multi-second periods of complete non-interactivty. That can look for example like this: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/u8:3:143] Modules linked in: [redacted for brevity] CPU: 0 PID: 143 Comm: kworker/u8:3 Tainted: G U L 4.5.0-160321+ torvalds#183 Hardware name: Intel Corporation Broadwell Client platform/WhiteTip Mountain 1 Workqueue: i915 gen6_pm_rps_work [i915] task: ffff8800aae88000 ti: ffff8800aae90000 task.ti: ffff8800aae90000 RIP: 0010:[<ffffffff8104a3c2>] [<ffffffff8104a3c2>] __do_softirq+0x72/0x1d0 RSP: 0000:ffff88014f403f38 EFLAGS: 00000206 RAX: ffff8800aae94000 RBX: 0000000000000000 RCX: 00000000000006e0 RDX: 0000000000000020 RSI: 0000000004208060 RDI: 0000000000215d80 RBP: ffff88014f403f80 R08: 0000000b1b42c180 R09: 0000000000000022 R10: 0000000000000004 R11: 00000000ffffffff R12: 000000000000a030 R13: 0000000000000082 R14: ffff8800aa4d0080 R15: 0000000000000082 FS: 0000000000000000(0000) GS:ffff88014f400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa53b90c000 CR3: 0000000001a0a000 CR4: 00000000001406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Stack: 042080601b33869f ffff8800aae94000 00000000fffc2678 ffff88010000000a 0000000000000000 000000000000a030 0000000000005302 ffff8800aa4d0080 0000000000000206 ffff88014f403f90 ffffffff8104a716 ffff88014f403fa8 Call Trace: <IRQ> [<ffffffff8104a716>] irq_exit+0x86/0x90 [<ffffffff81031e7d>] smp_apic_timer_interrupt+0x3d/0x50 [<ffffffff814f3eac>] apic_timer_interrupt+0x7c/0x90 <EOI> [<ffffffffa01c5b40>] ? gen8_write64+0x1a0/0x1a0 [i915] [<ffffffff814f2b39>] ? _raw_spin_unlock_irqrestore+0x9/0x20 [<ffffffffa01c5c44>] gen8_write32+0x104/0x1a0 [i915] [<ffffffff8132c6a2>] ? n_tty_receive_buf_common+0x372/0xae0 [<ffffffffa017cc9e>] gen6_set_rps_thresholds+0x1be/0x330 [i915] [<ffffffffa017eaf0>] gen6_set_rps+0x70/0x200 [i915] [<ffffffffa0185375>] intel_set_rps+0x25/0x30 [i915] [<ffffffffa01768fd>] gen6_pm_rps_work+0x10d/0x2e0 [i915] [<ffffffff81063852>] ? finish_task_switch+0x72/0x1c0 [<ffffffff8105ab29>] process_one_work+0x139/0x350 [<ffffffff8105b186>] worker_thread+0x126/0x490 [<ffffffff8105b060>] ? rescuer_thread+0x320/0x320 [<ffffffff8105fa64>] kthread+0xc4/0xe0 [<ffffffff8105f9a0>] ? kthread_create_on_node+0x170/0x170 [<ffffffff814f351f>] ret_from_fork+0x3f/0x70 [<ffffffff8105f9a0>] ? kthread_create_on_node+0x170/0x170 I could not explain, or find a code path, which would explain a +20 second lockup, but from some instrumentation it was apparent the interrupts off proportion of time was between 10-25% under heavy load which is quite bad. When a interrupt "cliff" is reached, which was >~320k irq/s on my machine, the whole system goes into a terrible state of the above described multi-second lockups. By moving the GT interrupt handling to a tasklet in a most simple way, the problem above disappears completely. Testing the effect on sytem-wide latencies using igt/gem_syslatency shows the following before this patch: gem_syslatency: cycles=1532739, latency mean=416531.829us max=2499237us gem_syslatency: cycles=1839434, latency mean=1458099.157us max=4998944us gem_syslatency: cycles=1432570, latency mean=2688.451us max=1201185us gem_syslatency: cycles=1533543, latency mean=416520.499us max=2498886us This shows that the unrelated process is experiencing huge delays in its wake-up latency. After the patch the results look like this: gem_syslatency: cycles=808907, latency mean=53.133us max=1640us gem_syslatency: cycles=862154, latency mean=62.778us max=2117us gem_syslatency: cycles=856039, latency mean=58.079us max=2123us gem_syslatency: cycles=841683, latency mean=56.914us max=1667us Showing a huge improvement in the unrelated process wake-up latency. It also shows an approximate halving in the number of total empty batches submitted during the test. This may not be worrying since the test puts the driver under a very unrealistic load with ncpu threads doing empty batch submission to all GPU engines each. Another benefit compared to the hard-irq handling is that now work on all engines can be dispatched in parallel since we can have up to number of CPUs active tasklets. (While previously a single hard-irq would serially dispatch on one engine after another.) More interesting scenario with regards to throughput is "gem_latency -n 100" which shows 25% better throughput and CPU usage, and 14% better dispatch latencies. I did not find any gains or regressions with Synmark2 or GLbench under light testing. More benchmarking is certainly required. v2: * execlists_lock should be taken as spin_lock_bh when queuing work from userspace now. (Chris Wilson) * uncore.lock must be taken with spin_lock_irq when submitting requests since that now runs from either softirq or process context. v3: * Expanded commit message with more testing data; * converted missed locking sites to _bh; * added execlist_lock comment. (Chris Wilson) v4: * Mention dispatch parallelism in commit. (Chris Wilson) * Do not hold uncore.lock over MMIO reads since the block is already serialised per-engine via the tasklet itself. (Chris Wilson) * intel_lrc_irq_handler should be static. (Chris Wilson) * Cancel/sync the tasklet on GPU reset. (Chris Wilson) * Document and WARN that tasklet cannot be active/pending on engine cleanup. (Chris Wilson/Imre Deak) Signed-off-by: Tvrtko Ursulin <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Imre Deak <[email protected]> Testcase: igt/gem_exec_nop/all Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94350 Reviewed-by: Chris Wilson <[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
lkl: Add offload (TSO4, CSUM) support to LKL device code
alaahl
pushed a commit
to alaahl/linux
that referenced
this pull request
Mar 6, 2018
The failure in rereg_mr flow caused to set garbage value (error value) into mr->umem pointer. This pointer is accessed at the release stage and it causes to the following crash. There is not enough to simply change umem to point to NULL, because the MR struct is needed to be accessed during MR deregistration phase, so delay kfree too. [ 6.237617] BUG: unable to handle kernel NULL pointer dereference a 0000000000000228 [ 6.238756] IP: ib_dereg_mr+0xd/0x30 [ 6.239264] PGD 80000000167eb067 P4D 80000000167eb067 PUD 167f9067 PMD 0 [ 6.240320] Oops: 0000 [#1] SMP PTI [ 6.240782] CPU: 0 PID: 367 Comm: dereg Not tainted 4.16.0-rc1-00029-gc198fafe0453 torvalds#183 [ 6.242120] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 [ 6.244504] RIP: 0010:ib_dereg_mr+0xd/0x30 [ 6.245253] RSP: 0018:ffffaf5d001d7d68 EFLAGS: 00010246 [ 6.246100] RAX: 0000000000000000 RBX: ffff95d4172daf00 RCX: 0000000000000000 [ 6.247414] RDX: 00000000ffffffff RSI: 0000000000000001 RDI: ffff95d41a317600 [ 6.248591] RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 [ 6.249810] R10: ffff95d417033c10 R11: 0000000000000000 R12: ffff95d4172c3a80 [ 6.251121] R13: ffff95d4172c3720 R14: ffff95d4172c3a98 R15: 00000000ffffffff [ 6.252437] FS: 0000000000000000(0000) GS:ffff95d41fc00000(0000) knlGS:0000000000000000 [ 6.253887] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6.254814] CR2: 0000000000000228 CR3: 00000000172b4000 CR4: 00000000000006b0 [ 6.255943] Call Trace: [ 6.256368] remove_commit_idr_uobject+0x1b/0x80 [ 6.257118] uverbs_cleanup_ucontext+0xe4/0x190 [ 6.257855] ib_uverbs_cleanup_ucontext.constprop.14+0x19/0x40 [ 6.258857] ib_uverbs_close+0x2a/0x100 [ 6.259494] __fput+0xca/0x1c0 [ 6.259938] task_work_run+0x84/0xa0 [ 6.260519] do_exit+0x312/0xb40 [ 6.261023] ? __do_page_fault+0x24d/0x490 [ 6.261707] do_group_exit+0x3a/0xa0 [ 6.262267] SyS_exit_group+0x10/0x10 [ 6.262802] do_syscall_64+0x75/0x180 [ 6.263391] entry_SYSCALL_64_after_hwframe+0x21/0x86 [ 6.264253] RIP: 0033:0x7f1b39c49488 [ 6.264827] RSP: 002b:00007ffe2de05b68 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 [ 6.266049] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1b39c49488 [ 6.267187] RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000 [ 6.268377] RBP: 00007f1b39f258e0 R08: 00000000000000e7 R09: ffffffffffffff98 [ 6.269640] R10: 00007f1b3a147260 R11: 0000000000000246 R12: 00007f1b39f258e0 [ 6.270783] R13: 00007f1b39f2ac20 R14: 0000000000000000 R15: 0000000000000000 [ 6.271943] Code: 74 07 31 d2 e9 25 d8 6c 00 b8 da ff ff ff c3 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 07 53 48 8b 5f 08 <48> 8b 80 28 02 00 00 e8 f7 d7 6c 00 85 c0 75 04 3e ff 4b 18 5b [ 6.274927] RIP: ib_dereg_mr+0xd/0x30 RSP: ffffaf5d001d7d68 [ 6.275760] CR2: 0000000000000228 [ 6.276200] ---[ end trace a35641f1c474bd20 ]--- Fixes: e126ba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") Cc: syzkaller <[email protected]> Cc: <[email protected]> Reported-by: Noa Osherovich <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]>
alaahl
pushed a commit
to alaahl/linux
that referenced
this pull request
Mar 8, 2018
The failure in rereg_mr flow caused to set garbage value (error value) into mr->umem pointer. This pointer is accessed at the release stage and it causes to the following crash. There is not enough to simply change umem to point to NULL, because the MR struct is needed to be accessed during MR deregistration phase, so delay kfree too. [ 6.237617] BUG: unable to handle kernel NULL pointer dereference a 0000000000000228 [ 6.238756] IP: ib_dereg_mr+0xd/0x30 [ 6.239264] PGD 80000000167eb067 P4D 80000000167eb067 PUD 167f9067 PMD 0 [ 6.240320] Oops: 0000 [#1] SMP PTI [ 6.240782] CPU: 0 PID: 367 Comm: dereg Not tainted 4.16.0-rc1-00029-gc198fafe0453 torvalds#183 [ 6.242120] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 [ 6.244504] RIP: 0010:ib_dereg_mr+0xd/0x30 [ 6.245253] RSP: 0018:ffffaf5d001d7d68 EFLAGS: 00010246 [ 6.246100] RAX: 0000000000000000 RBX: ffff95d4172daf00 RCX: 0000000000000000 [ 6.247414] RDX: 00000000ffffffff RSI: 0000000000000001 RDI: ffff95d41a317600 [ 6.248591] RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 [ 6.249810] R10: ffff95d417033c10 R11: 0000000000000000 R12: ffff95d4172c3a80 [ 6.251121] R13: ffff95d4172c3720 R14: ffff95d4172c3a98 R15: 00000000ffffffff [ 6.252437] FS: 0000000000000000(0000) GS:ffff95d41fc00000(0000) knlGS:0000000000000000 [ 6.253887] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6.254814] CR2: 0000000000000228 CR3: 00000000172b4000 CR4: 00000000000006b0 [ 6.255943] Call Trace: [ 6.256368] remove_commit_idr_uobject+0x1b/0x80 [ 6.257118] uverbs_cleanup_ucontext+0xe4/0x190 [ 6.257855] ib_uverbs_cleanup_ucontext.constprop.14+0x19/0x40 [ 6.258857] ib_uverbs_close+0x2a/0x100 [ 6.259494] __fput+0xca/0x1c0 [ 6.259938] task_work_run+0x84/0xa0 [ 6.260519] do_exit+0x312/0xb40 [ 6.261023] ? __do_page_fault+0x24d/0x490 [ 6.261707] do_group_exit+0x3a/0xa0 [ 6.262267] SyS_exit_group+0x10/0x10 [ 6.262802] do_syscall_64+0x75/0x180 [ 6.263391] entry_SYSCALL_64_after_hwframe+0x21/0x86 [ 6.264253] RIP: 0033:0x7f1b39c49488 [ 6.264827] RSP: 002b:00007ffe2de05b68 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 [ 6.266049] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1b39c49488 [ 6.267187] RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000 [ 6.268377] RBP: 00007f1b39f258e0 R08: 00000000000000e7 R09: ffffffffffffff98 [ 6.269640] R10: 00007f1b3a147260 R11: 0000000000000246 R12: 00007f1b39f258e0 [ 6.270783] R13: 00007f1b39f2ac20 R14: 0000000000000000 R15: 0000000000000000 [ 6.271943] Code: 74 07 31 d2 e9 25 d8 6c 00 b8 da ff ff ff c3 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 07 53 48 8b 5f 08 <48> 8b 80 28 02 00 00 e8 f7 d7 6c 00 85 c0 75 04 3e ff 4b 18 5b [ 6.274927] RIP: ib_dereg_mr+0xd/0x30 RSP: ffffaf5d001d7d68 [ 6.275760] CR2: 0000000000000228 [ 6.276200] ---[ end trace a35641f1c474bd20 ]--- Fixes: e126ba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") Cc: syzkaller <[email protected]> Cc: <[email protected]> Reported-by: Noa Osherovich <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]>
alaahl
pushed a commit
to alaahl/linux
that referenced
this pull request
Mar 8, 2018
The failure in rereg_mr flow caused to set garbage value (error value) into mr->umem pointer. This pointer is accessed at the release stage and it causes to the following crash. There is not enough to simply change umem to point to NULL, because the MR struct is needed to be accessed during MR deregistration phase, so delay kfree too. [ 6.237617] BUG: unable to handle kernel NULL pointer dereference a 0000000000000228 [ 6.238756] IP: ib_dereg_mr+0xd/0x30 [ 6.239264] PGD 80000000167eb067 P4D 80000000167eb067 PUD 167f9067 PMD 0 [ 6.240320] Oops: 0000 [#1] SMP PTI [ 6.240782] CPU: 0 PID: 367 Comm: dereg Not tainted 4.16.0-rc1-00029-gc198fafe0453 torvalds#183 [ 6.242120] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 [ 6.244504] RIP: 0010:ib_dereg_mr+0xd/0x30 [ 6.245253] RSP: 0018:ffffaf5d001d7d68 EFLAGS: 00010246 [ 6.246100] RAX: 0000000000000000 RBX: ffff95d4172daf00 RCX: 0000000000000000 [ 6.247414] RDX: 00000000ffffffff RSI: 0000000000000001 RDI: ffff95d41a317600 [ 6.248591] RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 [ 6.249810] R10: ffff95d417033c10 R11: 0000000000000000 R12: ffff95d4172c3a80 [ 6.251121] R13: ffff95d4172c3720 R14: ffff95d4172c3a98 R15: 00000000ffffffff [ 6.252437] FS: 0000000000000000(0000) GS:ffff95d41fc00000(0000) knlGS:0000000000000000 [ 6.253887] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6.254814] CR2: 0000000000000228 CR3: 00000000172b4000 CR4: 00000000000006b0 [ 6.255943] Call Trace: [ 6.256368] remove_commit_idr_uobject+0x1b/0x80 [ 6.257118] uverbs_cleanup_ucontext+0xe4/0x190 [ 6.257855] ib_uverbs_cleanup_ucontext.constprop.14+0x19/0x40 [ 6.258857] ib_uverbs_close+0x2a/0x100 [ 6.259494] __fput+0xca/0x1c0 [ 6.259938] task_work_run+0x84/0xa0 [ 6.260519] do_exit+0x312/0xb40 [ 6.261023] ? __do_page_fault+0x24d/0x490 [ 6.261707] do_group_exit+0x3a/0xa0 [ 6.262267] SyS_exit_group+0x10/0x10 [ 6.262802] do_syscall_64+0x75/0x180 [ 6.263391] entry_SYSCALL_64_after_hwframe+0x21/0x86 [ 6.264253] RIP: 0033:0x7f1b39c49488 [ 6.264827] RSP: 002b:00007ffe2de05b68 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 [ 6.266049] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1b39c49488 [ 6.267187] RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000 [ 6.268377] RBP: 00007f1b39f258e0 R08: 00000000000000e7 R09: ffffffffffffff98 [ 6.269640] R10: 00007f1b3a147260 R11: 0000000000000246 R12: 00007f1b39f258e0 [ 6.270783] R13: 00007f1b39f2ac20 R14: 0000000000000000 R15: 0000000000000000 [ 6.271943] Code: 74 07 31 d2 e9 25 d8 6c 00 b8 da ff ff ff c3 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 07 53 48 8b 5f 08 <48> 8b 80 28 02 00 00 e8 f7 d7 6c 00 85 c0 75 04 3e ff 4b 18 5b [ 6.274927] RIP: ib_dereg_mr+0xd/0x30 RSP: ffffaf5d001d7d68 [ 6.275760] CR2: 0000000000000228 [ 6.276200] ---[ end trace a35641f1c474bd20 ]--- Fixes: e126ba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") Cc: syzkaller <[email protected]> Cc: <[email protected]> Reported-by: Noa Osherovich <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]>
alaahl
pushed a commit
to alaahl/linux
that referenced
this pull request
Mar 12, 2018
The failure in rereg_mr flow caused to set garbage value (error value) into mr->umem pointer. This pointer is accessed at the release stage and it causes to the following crash. There is not enough to simply change umem to point to NULL, because the MR struct is needed to be accessed during MR deregistration phase, so delay kfree too. [ 6.237617] BUG: unable to handle kernel NULL pointer dereference a 0000000000000228 [ 6.238756] IP: ib_dereg_mr+0xd/0x30 [ 6.239264] PGD 80000000167eb067 P4D 80000000167eb067 PUD 167f9067 PMD 0 [ 6.240320] Oops: 0000 [#1] SMP PTI [ 6.240782] CPU: 0 PID: 367 Comm: dereg Not tainted 4.16.0-rc1-00029-gc198fafe0453 torvalds#183 [ 6.242120] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 [ 6.244504] RIP: 0010:ib_dereg_mr+0xd/0x30 [ 6.245253] RSP: 0018:ffffaf5d001d7d68 EFLAGS: 00010246 [ 6.246100] RAX: 0000000000000000 RBX: ffff95d4172daf00 RCX: 0000000000000000 [ 6.247414] RDX: 00000000ffffffff RSI: 0000000000000001 RDI: ffff95d41a317600 [ 6.248591] RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 [ 6.249810] R10: ffff95d417033c10 R11: 0000000000000000 R12: ffff95d4172c3a80 [ 6.251121] R13: ffff95d4172c3720 R14: ffff95d4172c3a98 R15: 00000000ffffffff [ 6.252437] FS: 0000000000000000(0000) GS:ffff95d41fc00000(0000) knlGS:0000000000000000 [ 6.253887] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6.254814] CR2: 0000000000000228 CR3: 00000000172b4000 CR4: 00000000000006b0 [ 6.255943] Call Trace: [ 6.256368] remove_commit_idr_uobject+0x1b/0x80 [ 6.257118] uverbs_cleanup_ucontext+0xe4/0x190 [ 6.257855] ib_uverbs_cleanup_ucontext.constprop.14+0x19/0x40 [ 6.258857] ib_uverbs_close+0x2a/0x100 [ 6.259494] __fput+0xca/0x1c0 [ 6.259938] task_work_run+0x84/0xa0 [ 6.260519] do_exit+0x312/0xb40 [ 6.261023] ? __do_page_fault+0x24d/0x490 [ 6.261707] do_group_exit+0x3a/0xa0 [ 6.262267] SyS_exit_group+0x10/0x10 [ 6.262802] do_syscall_64+0x75/0x180 [ 6.263391] entry_SYSCALL_64_after_hwframe+0x21/0x86 [ 6.264253] RIP: 0033:0x7f1b39c49488 [ 6.264827] RSP: 002b:00007ffe2de05b68 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 [ 6.266049] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1b39c49488 [ 6.267187] RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000 [ 6.268377] RBP: 00007f1b39f258e0 R08: 00000000000000e7 R09: ffffffffffffff98 [ 6.269640] R10: 00007f1b3a147260 R11: 0000000000000246 R12: 00007f1b39f258e0 [ 6.270783] R13: 00007f1b39f2ac20 R14: 0000000000000000 R15: 0000000000000000 [ 6.271943] Code: 74 07 31 d2 e9 25 d8 6c 00 b8 da ff ff ff c3 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 07 53 48 8b 5f 08 <48> 8b 80 28 02 00 00 e8 f7 d7 6c 00 85 c0 75 04 3e ff 4b 18 5b [ 6.274927] RIP: ib_dereg_mr+0xd/0x30 RSP: ffffaf5d001d7d68 [ 6.275760] CR2: 0000000000000228 [ 6.276200] ---[ end trace a35641f1c474bd20 ]--- Fixes: e126ba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") Cc: syzkaller <[email protected]> Cc: <[email protected]> Reported-by: Noa Osherovich <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]>
alaahl
pushed a commit
to alaahl/linux
that referenced
this pull request
Mar 14, 2018
The failure in rereg_mr flow caused to set garbage value (error value) into mr->umem pointer. This pointer is accessed at the release stage and it causes to the following crash. There is not enough to simply change umem to point to NULL, because the MR struct is needed to be accessed during MR deregistration phase, so delay kfree too. [ 6.237617] BUG: unable to handle kernel NULL pointer dereference a 0000000000000228 [ 6.238756] IP: ib_dereg_mr+0xd/0x30 [ 6.239264] PGD 80000000167eb067 P4D 80000000167eb067 PUD 167f9067 PMD 0 [ 6.240320] Oops: 0000 [#1] SMP PTI [ 6.240782] CPU: 0 PID: 367 Comm: dereg Not tainted 4.16.0-rc1-00029-gc198fafe0453 torvalds#183 [ 6.242120] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 [ 6.244504] RIP: 0010:ib_dereg_mr+0xd/0x30 [ 6.245253] RSP: 0018:ffffaf5d001d7d68 EFLAGS: 00010246 [ 6.246100] RAX: 0000000000000000 RBX: ffff95d4172daf00 RCX: 0000000000000000 [ 6.247414] RDX: 00000000ffffffff RSI: 0000000000000001 RDI: ffff95d41a317600 [ 6.248591] RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 [ 6.249810] R10: ffff95d417033c10 R11: 0000000000000000 R12: ffff95d4172c3a80 [ 6.251121] R13: ffff95d4172c3720 R14: ffff95d4172c3a98 R15: 00000000ffffffff [ 6.252437] FS: 0000000000000000(0000) GS:ffff95d41fc00000(0000) knlGS:0000000000000000 [ 6.253887] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6.254814] CR2: 0000000000000228 CR3: 00000000172b4000 CR4: 00000000000006b0 [ 6.255943] Call Trace: [ 6.256368] remove_commit_idr_uobject+0x1b/0x80 [ 6.257118] uverbs_cleanup_ucontext+0xe4/0x190 [ 6.257855] ib_uverbs_cleanup_ucontext.constprop.14+0x19/0x40 [ 6.258857] ib_uverbs_close+0x2a/0x100 [ 6.259494] __fput+0xca/0x1c0 [ 6.259938] task_work_run+0x84/0xa0 [ 6.260519] do_exit+0x312/0xb40 [ 6.261023] ? __do_page_fault+0x24d/0x490 [ 6.261707] do_group_exit+0x3a/0xa0 [ 6.262267] SyS_exit_group+0x10/0x10 [ 6.262802] do_syscall_64+0x75/0x180 [ 6.263391] entry_SYSCALL_64_after_hwframe+0x21/0x86 [ 6.264253] RIP: 0033:0x7f1b39c49488 [ 6.264827] RSP: 002b:00007ffe2de05b68 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 [ 6.266049] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1b39c49488 [ 6.267187] RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000 [ 6.268377] RBP: 00007f1b39f258e0 R08: 00000000000000e7 R09: ffffffffffffff98 [ 6.269640] R10: 00007f1b3a147260 R11: 0000000000000246 R12: 00007f1b39f258e0 [ 6.270783] R13: 00007f1b39f2ac20 R14: 0000000000000000 R15: 0000000000000000 [ 6.271943] Code: 74 07 31 d2 e9 25 d8 6c 00 b8 da ff ff ff c3 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 07 53 48 8b 5f 08 <48> 8b 80 28 02 00 00 e8 f7 d7 6c 00 85 c0 75 04 3e ff 4b 18 5b [ 6.274927] RIP: ib_dereg_mr+0xd/0x30 RSP: ffffaf5d001d7d68 [ 6.275760] CR2: 0000000000000228 [ 6.276200] ---[ end trace a35641f1c474bd20 ]--- Fixes: e126ba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") Cc: syzkaller <[email protected]> Cc: <[email protected]> Reported-by: Noa Osherovich <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]>
alaahl
pushed a commit
to alaahl/linux
that referenced
this pull request
Mar 15, 2018
The failure in rereg_mr flow caused to set garbage value (error value) into mr->umem pointer. This pointer is accessed at the release stage and it causes to the following crash. There is not enough to simply change umem to point to NULL, because the MR struct is needed to be accessed during MR deregistration phase, so delay kfree too. [ 6.237617] BUG: unable to handle kernel NULL pointer dereference a 0000000000000228 [ 6.238756] IP: ib_dereg_mr+0xd/0x30 [ 6.239264] PGD 80000000167eb067 P4D 80000000167eb067 PUD 167f9067 PMD 0 [ 6.240320] Oops: 0000 [#1] SMP PTI [ 6.240782] CPU: 0 PID: 367 Comm: dereg Not tainted 4.16.0-rc1-00029-gc198fafe0453 torvalds#183 [ 6.242120] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 [ 6.244504] RIP: 0010:ib_dereg_mr+0xd/0x30 [ 6.245253] RSP: 0018:ffffaf5d001d7d68 EFLAGS: 00010246 [ 6.246100] RAX: 0000000000000000 RBX: ffff95d4172daf00 RCX: 0000000000000000 [ 6.247414] RDX: 00000000ffffffff RSI: 0000000000000001 RDI: ffff95d41a317600 [ 6.248591] RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 [ 6.249810] R10: ffff95d417033c10 R11: 0000000000000000 R12: ffff95d4172c3a80 [ 6.251121] R13: ffff95d4172c3720 R14: ffff95d4172c3a98 R15: 00000000ffffffff [ 6.252437] FS: 0000000000000000(0000) GS:ffff95d41fc00000(0000) knlGS:0000000000000000 [ 6.253887] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6.254814] CR2: 0000000000000228 CR3: 00000000172b4000 CR4: 00000000000006b0 [ 6.255943] Call Trace: [ 6.256368] remove_commit_idr_uobject+0x1b/0x80 [ 6.257118] uverbs_cleanup_ucontext+0xe4/0x190 [ 6.257855] ib_uverbs_cleanup_ucontext.constprop.14+0x19/0x40 [ 6.258857] ib_uverbs_close+0x2a/0x100 [ 6.259494] __fput+0xca/0x1c0 [ 6.259938] task_work_run+0x84/0xa0 [ 6.260519] do_exit+0x312/0xb40 [ 6.261023] ? __do_page_fault+0x24d/0x490 [ 6.261707] do_group_exit+0x3a/0xa0 [ 6.262267] SyS_exit_group+0x10/0x10 [ 6.262802] do_syscall_64+0x75/0x180 [ 6.263391] entry_SYSCALL_64_after_hwframe+0x21/0x86 [ 6.264253] RIP: 0033:0x7f1b39c49488 [ 6.264827] RSP: 002b:00007ffe2de05b68 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 [ 6.266049] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1b39c49488 [ 6.267187] RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000 [ 6.268377] RBP: 00007f1b39f258e0 R08: 00000000000000e7 R09: ffffffffffffff98 [ 6.269640] R10: 00007f1b3a147260 R11: 0000000000000246 R12: 00007f1b39f258e0 [ 6.270783] R13: 00007f1b39f2ac20 R14: 0000000000000000 R15: 0000000000000000 [ 6.271943] Code: 74 07 31 d2 e9 25 d8 6c 00 b8 da ff ff ff c3 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 07 53 48 8b 5f 08 <48> 8b 80 28 02 00 00 e8 f7 d7 6c 00 85 c0 75 04 3e ff 4b 18 5b [ 6.274927] RIP: ib_dereg_mr+0xd/0x30 RSP: ffffaf5d001d7d68 [ 6.275760] CR2: 0000000000000228 [ 6.276200] ---[ end trace a35641f1c474bd20 ]--- Fixes: e126ba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") Cc: syzkaller <[email protected]> Cc: <[email protected]> Reported-by: Noa Osherovich <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]>
heftig
referenced
this pull request
in zen-kernel/zen-kernel
Mar 28, 2018
commit f3f134f upstream. The failure in rereg_mr flow caused to set garbage value (error value) into mr->umem pointer. This pointer is accessed at the release stage and it causes to the following crash. There is not enough to simply change umem to point to NULL, because the MR struct is needed to be accessed during MR deregistration phase, so delay kfree too. [ 6.237617] BUG: unable to handle kernel NULL pointer dereference a 0000000000000228 [ 6.238756] IP: ib_dereg_mr+0xd/0x30 [ 6.239264] PGD 80000000167eb067 P4D 80000000167eb067 PUD 167f9067 PMD 0 [ 6.240320] Oops: 0000 [#1] SMP PTI [ 6.240782] CPU: 0 PID: 367 Comm: dereg Not tainted 4.16.0-rc1-00029-gc198fafe0453 #183 [ 6.242120] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 [ 6.244504] RIP: 0010:ib_dereg_mr+0xd/0x30 [ 6.245253] RSP: 0018:ffffaf5d001d7d68 EFLAGS: 00010246 [ 6.246100] RAX: 0000000000000000 RBX: ffff95d4172daf00 RCX: 0000000000000000 [ 6.247414] RDX: 00000000ffffffff RSI: 0000000000000001 RDI: ffff95d41a317600 [ 6.248591] RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 [ 6.249810] R10: ffff95d417033c10 R11: 0000000000000000 R12: ffff95d4172c3a80 [ 6.251121] R13: ffff95d4172c3720 R14: ffff95d4172c3a98 R15: 00000000ffffffff [ 6.252437] FS: 0000000000000000(0000) GS:ffff95d41fc00000(0000) knlGS:0000000000000000 [ 6.253887] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6.254814] CR2: 0000000000000228 CR3: 00000000172b4000 CR4: 00000000000006b0 [ 6.255943] Call Trace: [ 6.256368] remove_commit_idr_uobject+0x1b/0x80 [ 6.257118] uverbs_cleanup_ucontext+0xe4/0x190 [ 6.257855] ib_uverbs_cleanup_ucontext.constprop.14+0x19/0x40 [ 6.258857] ib_uverbs_close+0x2a/0x100 [ 6.259494] __fput+0xca/0x1c0 [ 6.259938] task_work_run+0x84/0xa0 [ 6.260519] do_exit+0x312/0xb40 [ 6.261023] ? __do_page_fault+0x24d/0x490 [ 6.261707] do_group_exit+0x3a/0xa0 [ 6.262267] SyS_exit_group+0x10/0x10 [ 6.262802] do_syscall_64+0x75/0x180 [ 6.263391] entry_SYSCALL_64_after_hwframe+0x21/0x86 [ 6.264253] RIP: 0033:0x7f1b39c49488 [ 6.264827] RSP: 002b:00007ffe2de05b68 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 [ 6.266049] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1b39c49488 [ 6.267187] RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000 [ 6.268377] RBP: 00007f1b39f258e0 R08: 00000000000000e7 R09: ffffffffffffff98 [ 6.269640] R10: 00007f1b3a147260 R11: 0000000000000246 R12: 00007f1b39f258e0 [ 6.270783] R13: 00007f1b39f2ac20 R14: 0000000000000000 R15: 0000000000000000 [ 6.271943] Code: 74 07 31 d2 e9 25 d8 6c 00 b8 da ff ff ff c3 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 07 53 48 8b 5f 08 <48> 8b 80 28 02 00 00 e8 f7 d7 6c 00 85 c0 75 04 3e ff 4b 18 5b [ 6.274927] RIP: ib_dereg_mr+0xd/0x30 RSP: ffffaf5d001d7d68 [ 6.275760] CR2: 0000000000000228 [ 6.276200] ---[ end trace a35641f1c474bd20 ]--- Fixes: e126ba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") Cc: syzkaller <[email protected]> Cc: <[email protected]> Reported-by: Noa Osherovich <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Doug Ledford <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
frank-w
referenced
this pull request
in frank-w/BPI-Router-Linux
Mar 29, 2018
commit f3f134f upstream. The failure in rereg_mr flow caused to set garbage value (error value) into mr->umem pointer. This pointer is accessed at the release stage and it causes to the following crash. There is not enough to simply change umem to point to NULL, because the MR struct is needed to be accessed during MR deregistration phase, so delay kfree too. [ 6.237617] BUG: unable to handle kernel NULL pointer dereference a 0000000000000228 [ 6.238756] IP: ib_dereg_mr+0xd/0x30 [ 6.239264] PGD 80000000167eb067 P4D 80000000167eb067 PUD 167f9067 PMD 0 [ 6.240320] Oops: 0000 [#1] SMP PTI [ 6.240782] CPU: 0 PID: 367 Comm: dereg Not tainted 4.16.0-rc1-00029-gc198fafe0453 #183 [ 6.242120] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 [ 6.244504] RIP: 0010:ib_dereg_mr+0xd/0x30 [ 6.245253] RSP: 0018:ffffaf5d001d7d68 EFLAGS: 00010246 [ 6.246100] RAX: 0000000000000000 RBX: ffff95d4172daf00 RCX: 0000000000000000 [ 6.247414] RDX: 00000000ffffffff RSI: 0000000000000001 RDI: ffff95d41a317600 [ 6.248591] RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 [ 6.249810] R10: ffff95d417033c10 R11: 0000000000000000 R12: ffff95d4172c3a80 [ 6.251121] R13: ffff95d4172c3720 R14: ffff95d4172c3a98 R15: 00000000ffffffff [ 6.252437] FS: 0000000000000000(0000) GS:ffff95d41fc00000(0000) knlGS:0000000000000000 [ 6.253887] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6.254814] CR2: 0000000000000228 CR3: 00000000172b4000 CR4: 00000000000006b0 [ 6.255943] Call Trace: [ 6.256368] remove_commit_idr_uobject+0x1b/0x80 [ 6.257118] uverbs_cleanup_ucontext+0xe4/0x190 [ 6.257855] ib_uverbs_cleanup_ucontext.constprop.14+0x19/0x40 [ 6.258857] ib_uverbs_close+0x2a/0x100 [ 6.259494] __fput+0xca/0x1c0 [ 6.259938] task_work_run+0x84/0xa0 [ 6.260519] do_exit+0x312/0xb40 [ 6.261023] ? __do_page_fault+0x24d/0x490 [ 6.261707] do_group_exit+0x3a/0xa0 [ 6.262267] SyS_exit_group+0x10/0x10 [ 6.262802] do_syscall_64+0x75/0x180 [ 6.263391] entry_SYSCALL_64_after_hwframe+0x21/0x86 [ 6.264253] RIP: 0033:0x7f1b39c49488 [ 6.264827] RSP: 002b:00007ffe2de05b68 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 [ 6.266049] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1b39c49488 [ 6.267187] RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000 [ 6.268377] RBP: 00007f1b39f258e0 R08: 00000000000000e7 R09: ffffffffffffff98 [ 6.269640] R10: 00007f1b3a147260 R11: 0000000000000246 R12: 00007f1b39f258e0 [ 6.270783] R13: 00007f1b39f2ac20 R14: 0000000000000000 R15: 0000000000000000 [ 6.271943] Code: 74 07 31 d2 e9 25 d8 6c 00 b8 da ff ff ff c3 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 07 53 48 8b 5f 08 <48> 8b 80 28 02 00 00 e8 f7 d7 6c 00 85 c0 75 04 3e ff 4b 18 5b [ 6.274927] RIP: ib_dereg_mr+0xd/0x30 RSP: ffffaf5d001d7d68 [ 6.275760] CR2: 0000000000000228 [ 6.276200] ---[ end trace a35641f1c474bd20 ]--- Fixes: e126ba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") Cc: syzkaller <[email protected]> Cc: <[email protected]> Reported-by: Noa Osherovich <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Doug Ledford <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
torvalds
pushed a commit
that referenced
this pull request
Jul 25, 2018
If the registration fails then mdio_unregister is called. However at unbind the unregister ia attempted again resulting in the below crash [ 73.544038] kernel BUG at drivers/net/phy/mdio_bus.c:415! [ 73.549362] Internal error: Oops - BUG: 0 [#1] SMP [ 73.554127] Modules linked in: [ 73.557168] CPU: 0 PID: 2249 Comm: sh Not tainted 4.14.0 #183 [ 73.562895] Hardware name: xlnx,zynqmp (DT) [ 73.567062] task: ffffffc879e41180 task.stack: ffffff800cbe0000 [ 73.572973] PC is at mdiobus_unregister+0x84/0x88 [ 73.577656] LR is at axienet_mdio_teardown+0x18/0x30 [ 73.582601] pc : [<ffffff80085fa4cc>] lr : [<ffffff8008616858>] pstate: 20000145 [ 73.589981] sp : ffffff800cbe3c30 [ 73.593277] x29: ffffff800cbe3c30 x28: ffffffc879e41180 [ 73.598573] x27: ffffff8008a21000 x26: 0000000000000040 [ 73.603868] x25: 0000000000000124 x24: ffffffc879efe920 [ 73.609164] x23: 0000000000000060 x22: ffffffc879e02000 [ 73.614459] x21: ffffffc879e02800 x20: ffffffc87b0b8870 [ 73.619754] x19: ffffffc879e02800 x18: 000000000000025d [ 73.625050] x17: 0000007f9a719ad0 x16: ffffff8008195bd8 [ 73.630345] x15: 0000007f9a6b3d00 x14: 0000000000000010 [ 73.635640] x13: 74656e7265687465 x12: 0000000000000030 [ 73.640935] x11: 0000000000000030 x10: 0101010101010101 [ 73.646231] x9 : 241f394f42533300 x8 : ffffffc8799f6e98 [ 73.651526] x7 : ffffffc8799f6f18 x6 : ffffffc87b0ba318 [ 73.656822] x5 : ffffffc87b0ba498 x4 : 0000000000000000 [ 73.662117] x3 : 0000000000000000 x2 : 0000000000000008 [ 73.667412] x1 : 0000000000000004 x0 : ffffffc8799f4000 [ 73.672708] Process sh (pid: 2249, stack limit = 0xffffff800cbe0000) Fix the same by making the bus NULL on unregister. Signed-off-by: Shubhrajyoti Datta <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Noltari
pushed a commit
to Noltari/linux
that referenced
this pull request
Sep 5, 2018
[ Upstream commit 03bc7ca ] If the registration fails then mdio_unregister is called. However at unbind the unregister ia attempted again resulting in the below crash [ 73.544038] kernel BUG at drivers/net/phy/mdio_bus.c:415! [ 73.549362] Internal error: Oops - BUG: 0 [#1] SMP [ 73.554127] Modules linked in: [ 73.557168] CPU: 0 PID: 2249 Comm: sh Not tainted 4.14.0 torvalds#183 [ 73.562895] Hardware name: xlnx,zynqmp (DT) [ 73.567062] task: ffffffc879e41180 task.stack: ffffff800cbe0000 [ 73.572973] PC is at mdiobus_unregister+0x84/0x88 [ 73.577656] LR is at axienet_mdio_teardown+0x18/0x30 [ 73.582601] pc : [<ffffff80085fa4cc>] lr : [<ffffff8008616858>] pstate: 20000145 [ 73.589981] sp : ffffff800cbe3c30 [ 73.593277] x29: ffffff800cbe3c30 x28: ffffffc879e41180 [ 73.598573] x27: ffffff8008a21000 x26: 0000000000000040 [ 73.603868] x25: 0000000000000124 x24: ffffffc879efe920 [ 73.609164] x23: 0000000000000060 x22: ffffffc879e02000 [ 73.614459] x21: ffffffc879e02800 x20: ffffffc87b0b8870 [ 73.619754] x19: ffffffc879e02800 x18: 000000000000025d [ 73.625050] x17: 0000007f9a719ad0 x16: ffffff8008195bd8 [ 73.630345] x15: 0000007f9a6b3d00 x14: 0000000000000010 [ 73.635640] x13: 74656e7265687465 x12: 0000000000000030 [ 73.640935] x11: 0000000000000030 x10: 0101010101010101 [ 73.646231] x9 : 241f394f42533300 x8 : ffffffc8799f6e98 [ 73.651526] x7 : ffffffc8799f6f18 x6 : ffffffc87b0ba318 [ 73.656822] x5 : ffffffc87b0ba498 x4 : 0000000000000000 [ 73.662117] x3 : 0000000000000000 x2 : 0000000000000008 [ 73.667412] x1 : 0000000000000004 x0 : ffffffc8799f4000 [ 73.672708] Process sh (pid: 2249, stack limit = 0xffffff800cbe0000) Fix the same by making the bus NULL on unregister. Signed-off-by: Shubhrajyoti Datta <[email protected]> Signed-off-by: David S. Miller <[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
Sep 5, 2018
[ Upstream commit 03bc7ca ] If the registration fails then mdio_unregister is called. However at unbind the unregister ia attempted again resulting in the below crash [ 73.544038] kernel BUG at drivers/net/phy/mdio_bus.c:415! [ 73.549362] Internal error: Oops - BUG: 0 [#1] SMP [ 73.554127] Modules linked in: [ 73.557168] CPU: 0 PID: 2249 Comm: sh Not tainted 4.14.0 torvalds#183 [ 73.562895] Hardware name: xlnx,zynqmp (DT) [ 73.567062] task: ffffffc879e41180 task.stack: ffffff800cbe0000 [ 73.572973] PC is at mdiobus_unregister+0x84/0x88 [ 73.577656] LR is at axienet_mdio_teardown+0x18/0x30 [ 73.582601] pc : [<ffffff80085fa4cc>] lr : [<ffffff8008616858>] pstate: 20000145 [ 73.589981] sp : ffffff800cbe3c30 [ 73.593277] x29: ffffff800cbe3c30 x28: ffffffc879e41180 [ 73.598573] x27: ffffff8008a21000 x26: 0000000000000040 [ 73.603868] x25: 0000000000000124 x24: ffffffc879efe920 [ 73.609164] x23: 0000000000000060 x22: ffffffc879e02000 [ 73.614459] x21: ffffffc879e02800 x20: ffffffc87b0b8870 [ 73.619754] x19: ffffffc879e02800 x18: 000000000000025d [ 73.625050] x17: 0000007f9a719ad0 x16: ffffff8008195bd8 [ 73.630345] x15: 0000007f9a6b3d00 x14: 0000000000000010 [ 73.635640] x13: 74656e7265687465 x12: 0000000000000030 [ 73.640935] x11: 0000000000000030 x10: 0101010101010101 [ 73.646231] x9 : 241f394f42533300 x8 : ffffffc8799f6e98 [ 73.651526] x7 : ffffffc8799f6f18 x6 : ffffffc87b0ba318 [ 73.656822] x5 : ffffffc87b0ba498 x4 : 0000000000000000 [ 73.662117] x3 : 0000000000000000 x2 : 0000000000000008 [ 73.667412] x1 : 0000000000000004 x0 : ffffffc8799f4000 [ 73.672708] Process sh (pid: 2249, stack limit = 0xffffff800cbe0000) Fix the same by making the bus NULL on unregister. Signed-off-by: Shubhrajyoti Datta <[email protected]> Signed-off-by: David S. Miller <[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
Sep 5, 2018
[ Upstream commit 03bc7ca ] If the registration fails then mdio_unregister is called. However at unbind the unregister ia attempted again resulting in the below crash [ 73.544038] kernel BUG at drivers/net/phy/mdio_bus.c:415! [ 73.549362] Internal error: Oops - BUG: 0 [MIPS#1] SMP [ 73.554127] Modules linked in: [ 73.557168] CPU: 0 PID: 2249 Comm: sh Not tainted 4.14.0 torvalds#183 [ 73.562895] Hardware name: xlnx,zynqmp (DT) [ 73.567062] task: ffffffc879e41180 task.stack: ffffff800cbe0000 [ 73.572973] PC is at mdiobus_unregister+0x84/0x88 [ 73.577656] LR is at axienet_mdio_teardown+0x18/0x30 [ 73.582601] pc : [<ffffff80085fa4cc>] lr : [<ffffff8008616858>] pstate: 20000145 [ 73.589981] sp : ffffff800cbe3c30 [ 73.593277] x29: ffffff800cbe3c30 x28: ffffffc879e41180 [ 73.598573] x27: ffffff8008a21000 x26: 0000000000000040 [ 73.603868] x25: 0000000000000124 x24: ffffffc879efe920 [ 73.609164] x23: 0000000000000060 x22: ffffffc879e02000 [ 73.614459] x21: ffffffc879e02800 x20: ffffffc87b0b8870 [ 73.619754] x19: ffffffc879e02800 x18: 000000000000025d [ 73.625050] x17: 0000007f9a719ad0 x16: ffffff8008195bd8 [ 73.630345] x15: 0000007f9a6b3d00 x14: 0000000000000010 [ 73.635640] x13: 74656e7265687465 x12: 0000000000000030 [ 73.640935] x11: 0000000000000030 x10: 0101010101010101 [ 73.646231] x9 : 241f394f42533300 x8 : ffffffc8799f6e98 [ 73.651526] x7 : ffffffc8799f6f18 x6 : ffffffc87b0ba318 [ 73.656822] x5 : ffffffc87b0ba498 x4 : 0000000000000000 [ 73.662117] x3 : 0000000000000000 x2 : 0000000000000008 [ 73.667412] x1 : 0000000000000004 x0 : ffffffc8799f4000 [ 73.672708] Process sh (pid: 2249, stack limit = 0xffffff800cbe0000) Fix the same by making the bus NULL on unregister. Signed-off-by: Shubhrajyoti Datta <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Mar 6, 2019
Currently, when device tree specifies fsl,qe-num-snums = 28 (which a number of in-tree .dts files do, and which is the default when that property is missing), qe_snums_init() ends up using the first 28 elements of the snum_init_46[] array. The situation is quite messy. This patch may break existing setups that for some reason work with specifying fsl,qe-num-snums = 28 and using the existing snum_init_46 array. OTOH, the current code certainly does not work for the MPC8309-based board we're working on, since the first 14 of the elements in snum_init_46 are "Not available on MPC8306/MPC8306S/MPC8309" according to the QUICC Engine Reference Manual (Table 4-30) - and indeed, without this patch (or something to the same effect), we get [ 8.895758] ------------[ cut here ]------------ [ 8.895778] NETDEV WATCHDOG: eth0 (ucc_geth): transmit queue 0 timed out [ 8.895971] WARNING: CPU: 0 PID: 8 at net/sched/sch_generic.c:461 dev_watchdog+0x23c/0x244 [ 8.895977] Modules linked in: [ 8.895998] CPU: 0 PID: 8 Comm: kworker/u2:1 Not tainted 4.19.18-00012-gd47efbb0119d torvalds#183 [ 8.896017] Workqueue: events_unbound call_usermodehelper_exec_work [ 8.896030] NIP: c037b18c LR: c037b18c CTR: 00000000 [ 8.896042] REGS: cf853b00 TRAP: 0700 Not tainted (4.19.18-00012-gd47efbb0119d) [ 8.896047] MSR: 00029032 <EE,ME,IR,DR,RI> CR: 42022428 XER: 00000000 [ 8.896080] [ 8.896080] GPR00: c037b18c cf853bb0 cf82e4c0 0000003c c05f7bc4 000000c4 0000004c 000038dc [ 8.896080] GPR08: 00000007 00000007 00000001 00000000 22022424 00000000 00000100 c05f3d78 [ 8.896080] GPR16: c05f3d7c 00000001 00000004 cf852000 00000000 c05e0000 fffee3a9 c0496618 [ 8.896080] GPR24: c05241c8 0000000a c05c0000 c05db0f4 cf82b800 c05e0000 00000000 cf82ba74 [ 8.896229] NIP [c037b18c] dev_watchdog+0x23c/0x244 [ 8.896240] LR [c037b18c] dev_watchdog+0x23c/0x244 [ 8.896244] Call Trace: [ 8.896257] [cf853bb0] [c037b18c] dev_watchdog+0x23c/0x244 (unreliable) [ 8.896285] [cf853bd0] [c0054eb0] call_timer_fn+0x24/0x84 [ 8.896304] [cf853bf0] [c0055228] expire_timers.isra.4+0x98/0xa8 [ 8.896322] [cf853c10] [c00552cc] run_timer_softirq+0x94/0x190 [ 8.896341] [cf853c60] [c0494738] __do_softirq+0xe0/0x258 [ 8.896357] [cf853cc0] [c001db68] irq_exit+0xfc/0x100 [ 8.896375] [cf853cd0] [c000a2e8] timer_interrupt+0xdc/0x1c0 [ 8.896399] [cf853cf0] [c000f460] ret_from_except+0x0/0x14 [ 8.896432] --- interrupt: 901 at copy_process.isra.8.part.9+0x60c/0x1334 [ 8.896432] LR = copy_process.isra.8.part.9+0x864/0x1334 [ 8.896446] [cf853db0] [c0018fc8] copy_process.isra.8.part.9+0x7d0/0x1334 (unreliable) [ 8.896466] [cf853e40] [c0019fc0] _do_fork+0xa8/0x2ac [ 8.896486] [cf853e80] [c002b7e0] call_usermodehelper_exec_work+0x74/0xec [ 8.896506] [cf853ea0] [c002e520] process_one_work+0x168/0x38c [ 8.896523] [cf853ec0] [c002e87c] worker_thread+0x138/0x488 [ 8.896541] [cf853f10] [c0033824] kthread+0xe0/0x10c [ 8.896560] [cf853f40] [c000f1c4] ret_from_kernel_thread+0x14/0x1c [ 8.896568] Instruction dump: [ 8.896577] 811ffffc 4bffff70 39200001 7f83e378 9928af9f 4bfd82d5 7fc6f378 7f84e37 [ 8.896615] 7c651b78 3c60c056 3863be98 4bc9f681 <0fe00000> 4bffffb8 9421ffe0 7d800026 [ 8.896655] ---[ end trace cfd3ddfe80d72be2 ]--- along with an endless sequence of [ 115.716012] ucc_geth e0102000.ethernet eth1: Link is Up - 100Mbps/Full - flow control off [ 117.744010] ucc_geth e0103000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off [ 119.295955] ucc_geth e0102000.ethernet eth1: Link is Down [ 119.712177] ucc_geth e0102000.ethernet eth1: Link is Up - 100Mbps/Full - flow control off [ 123.295801] ucc_geth e0102000.ethernet eth1: Link is Down [ 123.295843] ucc_geth e0103000.ethernet eth0: Link is Down [ 123.712022] ucc_geth e0102000.ethernet eth1: Link is Up - 100Mbps/Full - flow control off [ 125.744167] ucc_geth e0103000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off It would seem to make much more sense of the table of snums was either decided based on some compatible string, or alternatively, if the array of snums was simply a byte array read directly from DT. Signed-off-by: Rasmus Villemoes <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Mar 6, 2019
Currently, when device tree specifies fsl,qe-num-snums = 28 (which a number of in-tree .dts files do, and which is the default when that property is missing), qe_snums_init() ends up using the first 28 elements of the snum_init_46[] array. The situation is quite messy. This patch may break existing setups that for some reason work with specifying fsl,qe-num-snums = 28 and using the existing snum_init_46 array. OTOH, the current code certainly does not work for the MPC8309-based board we're working on, since the first 14 of the elements in snum_init_46 are "Not available on MPC8306/MPC8306S/MPC8309" according to the QUICC Engine Reference Manual (Table 4-30) - and indeed, without this patch (or something to the same effect), we get [ 8.895758] ------------[ cut here ]------------ [ 8.895778] NETDEV WATCHDOG: eth0 (ucc_geth): transmit queue 0 timed out [ 8.895971] WARNING: CPU: 0 PID: 8 at net/sched/sch_generic.c:461 dev_watchdog+0x23c/0x244 [ 8.895977] Modules linked in: [ 8.895998] CPU: 0 PID: 8 Comm: kworker/u2:1 Not tainted 4.19.18-00012-gd47efbb0119d torvalds#183 [ 8.896017] Workqueue: events_unbound call_usermodehelper_exec_work [ 8.896030] NIP: c037b18c LR: c037b18c CTR: 00000000 [ 8.896042] REGS: cf853b00 TRAP: 0700 Not tainted (4.19.18-00012-gd47efbb0119d) [ 8.896047] MSR: 00029032 <EE,ME,IR,DR,RI> CR: 42022428 XER: 00000000 [ 8.896080] [ 8.896080] GPR00: c037b18c cf853bb0 cf82e4c0 0000003c c05f7bc4 000000c4 0000004c 000038dc [ 8.896080] GPR08: 00000007 00000007 00000001 00000000 22022424 00000000 00000100 c05f3d78 [ 8.896080] GPR16: c05f3d7c 00000001 00000004 cf852000 00000000 c05e0000 fffee3a9 c0496618 [ 8.896080] GPR24: c05241c8 0000000a c05c0000 c05db0f4 cf82b800 c05e0000 00000000 cf82ba74 [ 8.896229] NIP [c037b18c] dev_watchdog+0x23c/0x244 [ 8.896240] LR [c037b18c] dev_watchdog+0x23c/0x244 [ 8.896244] Call Trace: [ 8.896257] [cf853bb0] [c037b18c] dev_watchdog+0x23c/0x244 (unreliable) [ 8.896285] [cf853bd0] [c0054eb0] call_timer_fn+0x24/0x84 [ 8.896304] [cf853bf0] [c0055228] expire_timers.isra.4+0x98/0xa8 [ 8.896322] [cf853c10] [c00552cc] run_timer_softirq+0x94/0x190 [ 8.896341] [cf853c60] [c0494738] __do_softirq+0xe0/0x258 [ 8.896357] [cf853cc0] [c001db68] irq_exit+0xfc/0x100 [ 8.896375] [cf853cd0] [c000a2e8] timer_interrupt+0xdc/0x1c0 [ 8.896399] [cf853cf0] [c000f460] ret_from_except+0x0/0x14 [ 8.896432] --- interrupt: 901 at copy_process.isra.8.part.9+0x60c/0x1334 [ 8.896432] LR = copy_process.isra.8.part.9+0x864/0x1334 [ 8.896446] [cf853db0] [c0018fc8] copy_process.isra.8.part.9+0x7d0/0x1334 (unreliable) [ 8.896466] [cf853e40] [c0019fc0] _do_fork+0xa8/0x2ac [ 8.896486] [cf853e80] [c002b7e0] call_usermodehelper_exec_work+0x74/0xec [ 8.896506] [cf853ea0] [c002e520] process_one_work+0x168/0x38c [ 8.896523] [cf853ec0] [c002e87c] worker_thread+0x138/0x488 [ 8.896541] [cf853f10] [c0033824] kthread+0xe0/0x10c [ 8.896560] [cf853f40] [c000f1c4] ret_from_kernel_thread+0x14/0x1c [ 8.896568] Instruction dump: [ 8.896577] 811ffffc 4bffff70 39200001 7f83e378 9928af9f 4bfd82d5 7fc6f378 7f84e37 [ 8.896615] 7c651b78 3c60c056 3863be98 4bc9f681 <0fe00000> 4bffffb8 9421ffe0 7d800026 [ 8.896655] ---[ end trace cfd3ddfe80d72be2 ]--- along with an endless sequence of [ 115.716012] ucc_geth e0102000.ethernet eth1: Link is Up - 100Mbps/Full - flow control off [ 117.744010] ucc_geth e0103000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off [ 119.295955] ucc_geth e0102000.ethernet eth1: Link is Down [ 119.712177] ucc_geth e0102000.ethernet eth1: Link is Up - 100Mbps/Full - flow control off [ 123.295801] ucc_geth e0102000.ethernet eth1: Link is Down [ 123.295843] ucc_geth e0103000.ethernet eth0: Link is Down [ 123.712022] ucc_geth e0102000.ethernet eth1: Link is Up - 100Mbps/Full - flow control off [ 125.744167] ucc_geth e0103000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off It would seem to make much more sense of the table of snums was either decided based on some compatible string, or alternatively, if the array of snums was simply a byte array read directly from DT. Signed-off-by: Rasmus Villemoes <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Apr 29, 2019
We had many syzbot reports that seem to be caused by use-after-free of struct fib6_info. ip6_dst_destroy(), fib6_drop_pcpu_from() and rt6_remove_exception() are writers vs rt->from, and use non consistent synchronization among themselves. Switching to xchg() will solve the issues with no possible lockdep issues. BUG: KASAN: user-memory-access in atomic_dec_and_test include/asm-generic/atomic-instrumented.h:747 [inline] BUG: KASAN: user-memory-access in fib6_info_release include/net/ip6_fib.h:294 [inline] BUG: KASAN: user-memory-access in fib6_info_release include/net/ip6_fib.h:292 [inline] BUG: KASAN: user-memory-access in fib6_drop_pcpu_from net/ipv6/ip6_fib.c:927 [inline] BUG: KASAN: user-memory-access in fib6_purge_rt+0x4f6/0x670 net/ipv6/ip6_fib.c:960 Write of size 4 at addr 0000000000ffffb4 by task syz-executor.1/7649 CPU: 0 PID: 7649 Comm: syz-executor.1 Not tainted 5.1.0-rc6+ torvalds#183 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x172/0x1f0 lib/dump_stack.c:113 kasan_report.cold+0x5/0x40 mm/kasan/report.c:321 check_memory_region_inline mm/kasan/generic.c:185 [inline] check_memory_region+0x123/0x190 mm/kasan/generic.c:191 kasan_check_write+0x14/0x20 mm/kasan/common.c:108 atomic_dec_and_test include/asm-generic/atomic-instrumented.h:747 [inline] fib6_info_release include/net/ip6_fib.h:294 [inline] fib6_info_release include/net/ip6_fib.h:292 [inline] fib6_drop_pcpu_from net/ipv6/ip6_fib.c:927 [inline] fib6_purge_rt+0x4f6/0x670 net/ipv6/ip6_fib.c:960 fib6_del_route net/ipv6/ip6_fib.c:1813 [inline] fib6_del+0xac2/0x10a0 net/ipv6/ip6_fib.c:1844 fib6_clean_node+0x3a8/0x590 net/ipv6/ip6_fib.c:2006 fib6_walk_continue+0x495/0x900 net/ipv6/ip6_fib.c:1928 fib6_walk+0x9d/0x100 net/ipv6/ip6_fib.c:1976 fib6_clean_tree+0xe0/0x120 net/ipv6/ip6_fib.c:2055 __fib6_clean_all+0x118/0x2a0 net/ipv6/ip6_fib.c:2071 fib6_clean_all+0x2b/0x40 net/ipv6/ip6_fib.c:2082 rt6_sync_down_dev+0x134/0x150 net/ipv6/route.c:4057 rt6_disable_ip+0x27/0x5f0 net/ipv6/route.c:4062 addrconf_ifdown+0xa2/0x1220 net/ipv6/addrconf.c:3705 addrconf_notify+0x19a/0x2260 net/ipv6/addrconf.c:3630 notifier_call_chain+0xc7/0x240 kernel/notifier.c:93 __raw_notifier_call_chain kernel/notifier.c:394 [inline] raw_notifier_call_chain+0x2e/0x40 kernel/notifier.c:401 call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1753 call_netdevice_notifiers_extack net/core/dev.c:1765 [inline] call_netdevice_notifiers net/core/dev.c:1779 [inline] dev_close_many+0x33f/0x6f0 net/core/dev.c:1522 rollback_registered_many+0x43b/0xfd0 net/core/dev.c:8177 rollback_registered+0x109/0x1d0 net/core/dev.c:8242 unregister_netdevice_queue net/core/dev.c:9289 [inline] unregister_netdevice_queue+0x1ee/0x2c0 net/core/dev.c:9282 unregister_netdevice include/linux/netdevice.h:2658 [inline] __tun_detach+0xd5b/0x1000 drivers/net/tun.c:727 tun_detach drivers/net/tun.c:744 [inline] tun_chr_close+0xe0/0x180 drivers/net/tun.c:3443 __fput+0x2e5/0x8d0 fs/file_table.c:278 ____fput+0x16/0x20 fs/file_table.c:309 task_work_run+0x14a/0x1c0 kernel/task_work.c:113 exit_task_work include/linux/task_work.h:22 [inline] do_exit+0x90a/0x2fa0 kernel/exit.c:876 do_group_exit+0x135/0x370 kernel/exit.c:980 __do_sys_exit_group kernel/exit.c:991 [inline] __se_sys_exit_group kernel/exit.c:989 [inline] __x64_sys_exit_group+0x44/0x50 kernel/exit.c:989 do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x458da9 Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007ffeafc2a6a8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 000000000000001c RCX: 0000000000458da9 RDX: 0000000000412a80 RSI: 0000000000a54ef0 RDI: 0000000000000043 RBP: 00000000004be552 R08: 000000000000000c R09: 000000000004c0d1 R10: 0000000002341940 R11: 0000000000000246 R12: 00000000ffffffff R13: 00007ffeafc2a7f0 R14: 000000000004c065 R15: 00007ffeafc2a800 Fixes: a68886a ("net/ipv6: Make from in rt6_info rcu protected") Signed-off-by: Eric Dumazet <[email protected]> Reported-by: syzbot <[email protected]> Cc: David Ahern <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
May 1, 2019
We had many syzbot reports that seem to be caused by use-after-free of struct fib6_info. ip6_dst_destroy(), fib6_drop_pcpu_from() and rt6_remove_exception() are writers vs rt->from, and use non consistent synchronization among themselves. Switching to xchg() will solve the issues with no possible lockdep issues. BUG: KASAN: user-memory-access in atomic_dec_and_test include/asm-generic/atomic-instrumented.h:747 [inline] BUG: KASAN: user-memory-access in fib6_info_release include/net/ip6_fib.h:294 [inline] BUG: KASAN: user-memory-access in fib6_info_release include/net/ip6_fib.h:292 [inline] BUG: KASAN: user-memory-access in fib6_drop_pcpu_from net/ipv6/ip6_fib.c:927 [inline] BUG: KASAN: user-memory-access in fib6_purge_rt+0x4f6/0x670 net/ipv6/ip6_fib.c:960 Write of size 4 at addr 0000000000ffffb4 by task syz-executor.1/7649 CPU: 0 PID: 7649 Comm: syz-executor.1 Not tainted 5.1.0-rc6+ torvalds#183 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x172/0x1f0 lib/dump_stack.c:113 kasan_report.cold+0x5/0x40 mm/kasan/report.c:321 check_memory_region_inline mm/kasan/generic.c:185 [inline] check_memory_region+0x123/0x190 mm/kasan/generic.c:191 kasan_check_write+0x14/0x20 mm/kasan/common.c:108 atomic_dec_and_test include/asm-generic/atomic-instrumented.h:747 [inline] fib6_info_release include/net/ip6_fib.h:294 [inline] fib6_info_release include/net/ip6_fib.h:292 [inline] fib6_drop_pcpu_from net/ipv6/ip6_fib.c:927 [inline] fib6_purge_rt+0x4f6/0x670 net/ipv6/ip6_fib.c:960 fib6_del_route net/ipv6/ip6_fib.c:1813 [inline] fib6_del+0xac2/0x10a0 net/ipv6/ip6_fib.c:1844 fib6_clean_node+0x3a8/0x590 net/ipv6/ip6_fib.c:2006 fib6_walk_continue+0x495/0x900 net/ipv6/ip6_fib.c:1928 fib6_walk+0x9d/0x100 net/ipv6/ip6_fib.c:1976 fib6_clean_tree+0xe0/0x120 net/ipv6/ip6_fib.c:2055 __fib6_clean_all+0x118/0x2a0 net/ipv6/ip6_fib.c:2071 fib6_clean_all+0x2b/0x40 net/ipv6/ip6_fib.c:2082 rt6_sync_down_dev+0x134/0x150 net/ipv6/route.c:4057 rt6_disable_ip+0x27/0x5f0 net/ipv6/route.c:4062 addrconf_ifdown+0xa2/0x1220 net/ipv6/addrconf.c:3705 addrconf_notify+0x19a/0x2260 net/ipv6/addrconf.c:3630 notifier_call_chain+0xc7/0x240 kernel/notifier.c:93 __raw_notifier_call_chain kernel/notifier.c:394 [inline] raw_notifier_call_chain+0x2e/0x40 kernel/notifier.c:401 call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1753 call_netdevice_notifiers_extack net/core/dev.c:1765 [inline] call_netdevice_notifiers net/core/dev.c:1779 [inline] dev_close_many+0x33f/0x6f0 net/core/dev.c:1522 rollback_registered_many+0x43b/0xfd0 net/core/dev.c:8177 rollback_registered+0x109/0x1d0 net/core/dev.c:8242 unregister_netdevice_queue net/core/dev.c:9289 [inline] unregister_netdevice_queue+0x1ee/0x2c0 net/core/dev.c:9282 unregister_netdevice include/linux/netdevice.h:2658 [inline] __tun_detach+0xd5b/0x1000 drivers/net/tun.c:727 tun_detach drivers/net/tun.c:744 [inline] tun_chr_close+0xe0/0x180 drivers/net/tun.c:3443 __fput+0x2e5/0x8d0 fs/file_table.c:278 ____fput+0x16/0x20 fs/file_table.c:309 task_work_run+0x14a/0x1c0 kernel/task_work.c:113 exit_task_work include/linux/task_work.h:22 [inline] do_exit+0x90a/0x2fa0 kernel/exit.c:876 do_group_exit+0x135/0x370 kernel/exit.c:980 __do_sys_exit_group kernel/exit.c:991 [inline] __se_sys_exit_group kernel/exit.c:989 [inline] __x64_sys_exit_group+0x44/0x50 kernel/exit.c:989 do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x458da9 Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007ffeafc2a6a8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 000000000000001c RCX: 0000000000458da9 RDX: 0000000000412a80 RSI: 0000000000a54ef0 RDI: 0000000000000043 RBP: 00000000004be552 R08: 000000000000000c R09: 000000000004c0d1 R10: 0000000002341940 R11: 0000000000000246 R12: 00000000ffffffff R13: 00007ffeafc2a7f0 R14: 000000000004c065 R15: 00007ffeafc2a800 Fixes: a68886a ("net/ipv6: Make from in rt6_info rcu protected") Signed-off-by: Eric Dumazet <[email protected]> Reported-by: syzbot <[email protected]> Cc: David Ahern <[email protected]> Reviewed-by: David Ahern <[email protected]> Acked-by: Martin KaFai Lau <[email protected]> Acked-by: Wei Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
heftig
referenced
this pull request
in zen-kernel/zen-kernel
May 5, 2019
[ Upstream commit 0e23387 ] We had many syzbot reports that seem to be caused by use-after-free of struct fib6_info. ip6_dst_destroy(), fib6_drop_pcpu_from() and rt6_remove_exception() are writers vs rt->from, and use non consistent synchronization among themselves. Switching to xchg() will solve the issues with no possible lockdep issues. BUG: KASAN: user-memory-access in atomic_dec_and_test include/asm-generic/atomic-instrumented.h:747 [inline] BUG: KASAN: user-memory-access in fib6_info_release include/net/ip6_fib.h:294 [inline] BUG: KASAN: user-memory-access in fib6_info_release include/net/ip6_fib.h:292 [inline] BUG: KASAN: user-memory-access in fib6_drop_pcpu_from net/ipv6/ip6_fib.c:927 [inline] BUG: KASAN: user-memory-access in fib6_purge_rt+0x4f6/0x670 net/ipv6/ip6_fib.c:960 Write of size 4 at addr 0000000000ffffb4 by task syz-executor.1/7649 CPU: 0 PID: 7649 Comm: syz-executor.1 Not tainted 5.1.0-rc6+ #183 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x172/0x1f0 lib/dump_stack.c:113 kasan_report.cold+0x5/0x40 mm/kasan/report.c:321 check_memory_region_inline mm/kasan/generic.c:185 [inline] check_memory_region+0x123/0x190 mm/kasan/generic.c:191 kasan_check_write+0x14/0x20 mm/kasan/common.c:108 atomic_dec_and_test include/asm-generic/atomic-instrumented.h:747 [inline] fib6_info_release include/net/ip6_fib.h:294 [inline] fib6_info_release include/net/ip6_fib.h:292 [inline] fib6_drop_pcpu_from net/ipv6/ip6_fib.c:927 [inline] fib6_purge_rt+0x4f6/0x670 net/ipv6/ip6_fib.c:960 fib6_del_route net/ipv6/ip6_fib.c:1813 [inline] fib6_del+0xac2/0x10a0 net/ipv6/ip6_fib.c:1844 fib6_clean_node+0x3a8/0x590 net/ipv6/ip6_fib.c:2006 fib6_walk_continue+0x495/0x900 net/ipv6/ip6_fib.c:1928 fib6_walk+0x9d/0x100 net/ipv6/ip6_fib.c:1976 fib6_clean_tree+0xe0/0x120 net/ipv6/ip6_fib.c:2055 __fib6_clean_all+0x118/0x2a0 net/ipv6/ip6_fib.c:2071 fib6_clean_all+0x2b/0x40 net/ipv6/ip6_fib.c:2082 rt6_sync_down_dev+0x134/0x150 net/ipv6/route.c:4057 rt6_disable_ip+0x27/0x5f0 net/ipv6/route.c:4062 addrconf_ifdown+0xa2/0x1220 net/ipv6/addrconf.c:3705 addrconf_notify+0x19a/0x2260 net/ipv6/addrconf.c:3630 notifier_call_chain+0xc7/0x240 kernel/notifier.c:93 __raw_notifier_call_chain kernel/notifier.c:394 [inline] raw_notifier_call_chain+0x2e/0x40 kernel/notifier.c:401 call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1753 call_netdevice_notifiers_extack net/core/dev.c:1765 [inline] call_netdevice_notifiers net/core/dev.c:1779 [inline] dev_close_many+0x33f/0x6f0 net/core/dev.c:1522 rollback_registered_many+0x43b/0xfd0 net/core/dev.c:8177 rollback_registered+0x109/0x1d0 net/core/dev.c:8242 unregister_netdevice_queue net/core/dev.c:9289 [inline] unregister_netdevice_queue+0x1ee/0x2c0 net/core/dev.c:9282 unregister_netdevice include/linux/netdevice.h:2658 [inline] __tun_detach+0xd5b/0x1000 drivers/net/tun.c:727 tun_detach drivers/net/tun.c:744 [inline] tun_chr_close+0xe0/0x180 drivers/net/tun.c:3443 __fput+0x2e5/0x8d0 fs/file_table.c:278 ____fput+0x16/0x20 fs/file_table.c:309 task_work_run+0x14a/0x1c0 kernel/task_work.c:113 exit_task_work include/linux/task_work.h:22 [inline] do_exit+0x90a/0x2fa0 kernel/exit.c:876 do_group_exit+0x135/0x370 kernel/exit.c:980 __do_sys_exit_group kernel/exit.c:991 [inline] __se_sys_exit_group kernel/exit.c:989 [inline] __x64_sys_exit_group+0x44/0x50 kernel/exit.c:989 do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x458da9 Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007ffeafc2a6a8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 000000000000001c RCX: 0000000000458da9 RDX: 0000000000412a80 RSI: 0000000000a54ef0 RDI: 0000000000000043 RBP: 00000000004be552 R08: 000000000000000c R09: 000000000004c0d1 R10: 0000000002341940 R11: 0000000000000246 R12: 00000000ffffffff R13: 00007ffeafc2a7f0 R14: 000000000004c065 R15: 00007ffeafc2a800 Fixes: a68886a ("net/ipv6: Make from in rt6_info rcu protected") Signed-off-by: Eric Dumazet <[email protected]> Reported-by: syzbot <[email protected]> Cc: David Ahern <[email protected]> Reviewed-by: David Ahern <[email protected]> Acked-by: Martin KaFai Lau <[email protected]> Acked-by: Wei Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 23, 2025
This test_progs test fails on 32-bit armhf: root@qemu-armhf:/usr/libexec/kselftests-bpf# test_progs -a lwt_seg6local [...] test_lwt_seg6local:PASS:setup 0 nsec test_lwt_seg6local:PASS:open ns6 0 nsec test_lwt_seg6local:PASS:start server 0 nsec test_lwt_seg6local:PASS:open ns1 0 nsec test_lwt_seg6local:PASS:start client 0 nsec test_lwt_seg6local:PASS:build target addr 0 nsec test_lwt_seg6local:PASS:send packet 0 nsec test_lwt_seg6local:FAIL:receive packet unexpected receive packet: actual 4 != expected 7 torvalds#183 lwt_seg6local:FAIL This happens because a sendto() call mistakenly uses 'sizeof(char *)' as message length rather than the actual string ("foobar\0") size. e.g. bytes = sendto(cfd, foobar, sizeof(foobar), 0, ... This likely passed by accident till now because BPF CI only tests 64-bit targets. Fix by using strlen() to determine the message length. Fixes: 1041b8b ("selftests/bpf: lwt_seg6local: Move test to test_progs") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 23, 2025
This test_progs test fails on 32-bit armhf: root@qemu-armhf:/usr/libexec/kselftests-bpf# test_progs -a lwt_seg6local [...] test_lwt_seg6local:PASS:setup 0 nsec test_lwt_seg6local:PASS:open ns6 0 nsec test_lwt_seg6local:PASS:start server 0 nsec test_lwt_seg6local:PASS:open ns1 0 nsec test_lwt_seg6local:PASS:start client 0 nsec test_lwt_seg6local:PASS:build target addr 0 nsec test_lwt_seg6local:PASS:send packet 0 nsec test_lwt_seg6local:FAIL:receive packet unexpected receive packet: actual 4 != expected 7 torvalds#183 lwt_seg6local:FAIL This happens because a sendto() call mistakenly uses 'sizeof(char *)' as message length rather than the actual string ("foobar\0") size. e.g. bytes = sendto(cfd, foobar, sizeof(foobar), 0, ... This likely passed by accident till now because BPF CI only tests 64-bit targets. Fix by using strlen() to determine the message length. Fixes: 1041b8b ("selftests/bpf: lwt_seg6local: Move test to test_progs") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 23, 2025
This test_progs test fails on 32-bit armhf: root@qemu-armhf:/usr/libexec/kselftests-bpf# test_progs -a lwt_seg6local [...] test_lwt_seg6local:PASS:setup 0 nsec test_lwt_seg6local:PASS:open ns6 0 nsec test_lwt_seg6local:PASS:start server 0 nsec test_lwt_seg6local:PASS:open ns1 0 nsec test_lwt_seg6local:PASS:start client 0 nsec test_lwt_seg6local:PASS:build target addr 0 nsec test_lwt_seg6local:PASS:send packet 0 nsec test_lwt_seg6local:FAIL:receive packet unexpected receive packet: actual 4 != expected 7 torvalds#183 lwt_seg6local:FAIL This happens because a sendto() call mistakenly uses 'sizeof(char *)' as message length rather than the actual string ("foobar\0") size. e.g. bytes = sendto(cfd, foobar, sizeof(foobar), 0, ... This likely passed by accident till now because BPF CI only tests 64-bit targets. Fix by using strlen() to determine the message length. Fixes: 1041b8b ("selftests/bpf: lwt_seg6local: Move test to test_progs") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 23, 2025
This test_progs test fails on 32-bit armhf: root@qemu-armhf:/usr/libexec/kselftests-bpf# test_progs -a lwt_seg6local [...] test_lwt_seg6local:PASS:setup 0 nsec test_lwt_seg6local:PASS:open ns6 0 nsec test_lwt_seg6local:PASS:start server 0 nsec test_lwt_seg6local:PASS:open ns1 0 nsec test_lwt_seg6local:PASS:start client 0 nsec test_lwt_seg6local:PASS:build target addr 0 nsec test_lwt_seg6local:PASS:send packet 0 nsec test_lwt_seg6local:FAIL:receive packet unexpected receive packet: actual 4 != expected 7 torvalds#183 lwt_seg6local:FAIL This happens because a sendto() call mistakenly uses 'sizeof(char *)' as message length rather than the actual string ("foobar\0") size. e.g. bytes = sendto(cfd, foobar, sizeof(foobar), 0, ... This likely passed by accident till now because BPF CI only tests 64-bit targets. Fix by using strlen() to determine the message length. Fixes: 1041b8b ("selftests/bpf: lwt_seg6local: Move test to test_progs") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 24, 2025
This test_progs test fails on 32-bit armhf: root@qemu-armhf:/usr/libexec/kselftests-bpf# test_progs -a lwt_seg6local [...] test_lwt_seg6local:PASS:setup 0 nsec test_lwt_seg6local:PASS:open ns6 0 nsec test_lwt_seg6local:PASS:start server 0 nsec test_lwt_seg6local:PASS:open ns1 0 nsec test_lwt_seg6local:PASS:start client 0 nsec test_lwt_seg6local:PASS:build target addr 0 nsec test_lwt_seg6local:PASS:send packet 0 nsec test_lwt_seg6local:FAIL:receive packet unexpected receive packet: actual 4 != expected 7 torvalds#183 lwt_seg6local:FAIL This happens because a sendto() call mistakenly uses 'sizeof(char *)' as message length rather than the actual string ("foobar\0") size. e.g. bytes = sendto(cfd, foobar, sizeof(foobar), 0, ... This likely passed by accident till now because BPF CI only tests 64-bit targets. Fix by using strlen() to determine the message length. Fixes: 1041b8b ("selftests/bpf: lwt_seg6local: Move test to test_progs") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 24, 2025
This test_progs test fails on 32-bit armhf: root@qemu-armhf:/usr/libexec/kselftests-bpf# test_progs -a lwt_seg6local [...] test_lwt_seg6local:PASS:setup 0 nsec test_lwt_seg6local:PASS:open ns6 0 nsec test_lwt_seg6local:PASS:start server 0 nsec test_lwt_seg6local:PASS:open ns1 0 nsec test_lwt_seg6local:PASS:start client 0 nsec test_lwt_seg6local:PASS:build target addr 0 nsec test_lwt_seg6local:PASS:send packet 0 nsec test_lwt_seg6local:FAIL:receive packet unexpected receive packet: actual 4 != expected 7 torvalds#183 lwt_seg6local:FAIL This happens because a sendto() call mistakenly uses 'sizeof(char *)' as message length rather than the actual string ("foobar\0") size. e.g. bytes = sendto(cfd, foobar, sizeof(foobar), 0, ... This likely passed by accident till now because BPF CI only tests 64-bit targets. Fix by using strlen() to determine the message length. Fixes: 1041b8b ("selftests/bpf: lwt_seg6local: Move test to test_progs") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 25, 2025
This test_progs test fails on 32-bit armhf: root@qemu-armhf:/usr/libexec/kselftests-bpf# test_progs -a lwt_seg6local [...] test_lwt_seg6local:PASS:setup 0 nsec test_lwt_seg6local:PASS:open ns6 0 nsec test_lwt_seg6local:PASS:start server 0 nsec test_lwt_seg6local:PASS:open ns1 0 nsec test_lwt_seg6local:PASS:start client 0 nsec test_lwt_seg6local:PASS:build target addr 0 nsec test_lwt_seg6local:PASS:send packet 0 nsec test_lwt_seg6local:FAIL:receive packet unexpected receive packet: actual 4 != expected 7 torvalds#183 lwt_seg6local:FAIL This happens because a sendto() call mistakenly uses 'sizeof(char *)' as message length rather than the actual string ("foobar\0") size. e.g. bytes = sendto(cfd, foobar, sizeof(foobar), 0, ... This likely passed by accident till now because BPF CI only tests 64-bit targets. Fix by using strlen() to determine the message length. Fixes: 1041b8b ("selftests/bpf: lwt_seg6local: Move test to test_progs") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 27, 2025
This test_progs test fails on 32-bit armhf: root@qemu-armhf:/usr/libexec/kselftests-bpf# test_progs -a lwt_seg6local [...] test_lwt_seg6local:PASS:setup 0 nsec test_lwt_seg6local:PASS:open ns6 0 nsec test_lwt_seg6local:PASS:start server 0 nsec test_lwt_seg6local:PASS:open ns1 0 nsec test_lwt_seg6local:PASS:start client 0 nsec test_lwt_seg6local:PASS:build target addr 0 nsec test_lwt_seg6local:PASS:send packet 0 nsec test_lwt_seg6local:FAIL:receive packet unexpected receive packet: actual 4 != expected 7 torvalds#183 lwt_seg6local:FAIL This happens because a sendto() call mistakenly uses 'sizeof(char *)' as message length rather than the actual string ("foobar\0") size. e.g. bytes = sendto(cfd, foobar, sizeof(foobar), 0, ... This likely passed by accident till now because BPF CI only tests 64-bit targets. Fix by using strlen() to determine the message length. Fixes: 1041b8b ("selftests/bpf: lwt_seg6local: Move test to test_progs") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 27, 2025
This test_progs test fails on 32-bit armhf: root@qemu-armhf:/usr/libexec/kselftests-bpf# test_progs -a lwt_seg6local [...] test_lwt_seg6local:PASS:setup 0 nsec test_lwt_seg6local:PASS:open ns6 0 nsec test_lwt_seg6local:PASS:start server 0 nsec test_lwt_seg6local:PASS:open ns1 0 nsec test_lwt_seg6local:PASS:start client 0 nsec test_lwt_seg6local:PASS:build target addr 0 nsec test_lwt_seg6local:PASS:send packet 0 nsec test_lwt_seg6local:FAIL:receive packet unexpected receive packet: actual 4 != expected 7 torvalds#183 lwt_seg6local:FAIL This happens because a sendto() call mistakenly uses 'sizeof(char *)' as message length rather than the actual string ("foobar\0") size. e.g. bytes = sendto(cfd, foobar, sizeof(foobar), 0, ... This likely passed by accident till now because BPF CI only tests 64-bit targets. Fix by using strlen() to determine the message length. Fixes: 1041b8b ("selftests/bpf: lwt_seg6local: Move test to test_progs") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 1, 2025
This test_progs test fails on 32-bit armhf: root@qemu-armhf:/usr/libexec/kselftests-bpf# test_progs -a lwt_seg6local [...] test_lwt_seg6local:PASS:setup 0 nsec test_lwt_seg6local:PASS:open ns6 0 nsec test_lwt_seg6local:PASS:start server 0 nsec test_lwt_seg6local:PASS:open ns1 0 nsec test_lwt_seg6local:PASS:start client 0 nsec test_lwt_seg6local:PASS:build target addr 0 nsec test_lwt_seg6local:PASS:send packet 0 nsec test_lwt_seg6local:FAIL:receive packet unexpected receive packet: actual 4 != expected 7 torvalds#183 lwt_seg6local:FAIL This happens because a sendto() call mistakenly uses 'sizeof(char *)' as message length rather than the actual string ("foobar\0") size. e.g. bytes = sendto(cfd, foobar, sizeof(foobar), 0, ... This likely passed by accident till now because BPF CI only tests 64-bit targets. Fix by using strlen() to determine the message length. Fixes: 1041b8b ("selftests/bpf: lwt_seg6local: Move test to test_progs") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 10, 2025
This test_progs test fails on 32-bit armhf: root@qemu-armhf:/usr/libexec/kselftests-bpf# test_progs -a lwt_seg6local [...] test_lwt_seg6local:PASS:setup 0 nsec test_lwt_seg6local:PASS:open ns6 0 nsec test_lwt_seg6local:PASS:start server 0 nsec test_lwt_seg6local:PASS:open ns1 0 nsec test_lwt_seg6local:PASS:start client 0 nsec test_lwt_seg6local:PASS:build target addr 0 nsec test_lwt_seg6local:PASS:send packet 0 nsec test_lwt_seg6local:FAIL:receive packet unexpected receive packet: actual 4 != expected 7 torvalds#183 lwt_seg6local:FAIL This happens because a sendto() call mistakenly uses 'sizeof(char *)' as message length rather than the actual string ("foobar\0") size. e.g. bytes = sendto(cfd, foobar, sizeof(foobar), 0, ... This likely passed by accident till now because BPF CI only tests 64-bit targets. Fix by using strlen() to determine the message length. Fixes: 1041b8b ("selftests/bpf: lwt_seg6local: Move test to test_progs") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 11, 2025
This test_progs test fails on 32-bit armhf: root@qemu-armhf:/usr/libexec/kselftests-bpf# test_progs -a lwt_seg6local [...] test_lwt_seg6local:PASS:setup 0 nsec test_lwt_seg6local:PASS:open ns6 0 nsec test_lwt_seg6local:PASS:start server 0 nsec test_lwt_seg6local:PASS:open ns1 0 nsec test_lwt_seg6local:PASS:start client 0 nsec test_lwt_seg6local:PASS:build target addr 0 nsec test_lwt_seg6local:PASS:send packet 0 nsec test_lwt_seg6local:FAIL:receive packet unexpected receive packet: actual 4 != expected 7 torvalds#183 lwt_seg6local:FAIL This happens because a sendto() call mistakenly uses 'sizeof(char *)' as message length rather than the actual string ("foobar\0") size. e.g. bytes = sendto(cfd, foobar, sizeof(foobar), 0, ... This likely passed by accident till now because BPF CI only tests 64-bit targets. Fix by using strlen() to determine the message length. Fixes: 1041b8b ("selftests/bpf: lwt_seg6local: Move test to test_progs") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 15, 2025
This test_progs test fails on 32-bit armhf: root@qemu-armhf:/usr/libexec/kselftests-bpf# test_progs -a lwt_seg6local [...] test_lwt_seg6local:PASS:setup 0 nsec test_lwt_seg6local:PASS:open ns6 0 nsec test_lwt_seg6local:PASS:start server 0 nsec test_lwt_seg6local:PASS:open ns1 0 nsec test_lwt_seg6local:PASS:start client 0 nsec test_lwt_seg6local:PASS:build target addr 0 nsec test_lwt_seg6local:PASS:send packet 0 nsec test_lwt_seg6local:FAIL:receive packet unexpected receive packet: actual 4 != expected 7 torvalds#183 lwt_seg6local:FAIL This happens because a sendto() call mistakenly uses 'sizeof(char *)' as message length rather than the actual string ("foobar\0") size. e.g. bytes = sendto(cfd, foobar, sizeof(foobar), 0, ... This likely passed by accident till now because BPF CI only tests 64-bit targets. Fix by using strlen() to determine the message length. Fixes: 1041b8b ("selftests/bpf: lwt_seg6local: Move test to test_progs") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 20, 2025
This test_progs test fails on 32-bit armhf: root@qemu-armhf:/usr/libexec/kselftests-bpf# test_progs -a lwt_seg6local [...] test_lwt_seg6local:PASS:setup 0 nsec test_lwt_seg6local:PASS:open ns6 0 nsec test_lwt_seg6local:PASS:start server 0 nsec test_lwt_seg6local:PASS:open ns1 0 nsec test_lwt_seg6local:PASS:start client 0 nsec test_lwt_seg6local:PASS:build target addr 0 nsec test_lwt_seg6local:PASS:send packet 0 nsec test_lwt_seg6local:FAIL:receive packet unexpected receive packet: actual 4 != expected 7 torvalds#183 lwt_seg6local:FAIL This happens because a sendto() call mistakenly uses 'sizeof(char *)' as message length rather than the actual string ("foobar\0") size. e.g. bytes = sendto(cfd, foobar, sizeof(foobar), 0, ... This likely passed by accident till now because BPF CI only tests 64-bit targets. Fix by using strlen() to determine the message length. Fixes: 1041b8b ("selftests/bpf: lwt_seg6local: Move test to test_progs") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 21, 2025
This test_progs test fails on 32-bit armhf: root@qemu-armhf:/usr/libexec/kselftests-bpf# test_progs -a lwt_seg6local [...] test_lwt_seg6local:PASS:setup 0 nsec test_lwt_seg6local:PASS:open ns6 0 nsec test_lwt_seg6local:PASS:start server 0 nsec test_lwt_seg6local:PASS:open ns1 0 nsec test_lwt_seg6local:PASS:start client 0 nsec test_lwt_seg6local:PASS:build target addr 0 nsec test_lwt_seg6local:PASS:send packet 0 nsec test_lwt_seg6local:FAIL:receive packet unexpected receive packet: actual 4 != expected 7 torvalds#183 lwt_seg6local:FAIL This happens because a sendto() call mistakenly uses 'sizeof(char *)' as message length rather than the actual string ("foobar\0") size. e.g. bytes = sendto(cfd, foobar, sizeof(foobar), 0, ... This likely passed by accident till now because BPF CI only tests 64-bit targets. Fix by using strlen() to determine the message length. Fixes: 1041b8b ("selftests/bpf: lwt_seg6local: Move test to test_progs") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 21, 2025
This test_progs test fails on 32-bit armhf: root@qemu-armhf:/usr/libexec/kselftests-bpf# test_progs -a lwt_seg6local [...] test_lwt_seg6local:PASS:setup 0 nsec test_lwt_seg6local:PASS:open ns6 0 nsec test_lwt_seg6local:PASS:start server 0 nsec test_lwt_seg6local:PASS:open ns1 0 nsec test_lwt_seg6local:PASS:start client 0 nsec test_lwt_seg6local:PASS:build target addr 0 nsec test_lwt_seg6local:PASS:send packet 0 nsec test_lwt_seg6local:FAIL:receive packet unexpected receive packet: actual 4 != expected 7 torvalds#183 lwt_seg6local:FAIL This happens because a sendto() call mistakenly uses 'sizeof(char *)' as message length rather than the actual string ("foobar\0") size. e.g. bytes = sendto(cfd, foobar, sizeof(foobar), 0, ... This likely passed by accident till now because BPF CI only tests 64-bit targets. Fix by using strlen() to determine the message length. Fixes: 1041b8b ("selftests/bpf: lwt_seg6local: Move test to test_progs") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 21, 2025
This test_progs test fails on 32-bit armhf: root@qemu-armhf:/usr/libexec/kselftests-bpf# test_progs -a lwt_seg6local [...] test_lwt_seg6local:PASS:setup 0 nsec test_lwt_seg6local:PASS:open ns6 0 nsec test_lwt_seg6local:PASS:start server 0 nsec test_lwt_seg6local:PASS:open ns1 0 nsec test_lwt_seg6local:PASS:start client 0 nsec test_lwt_seg6local:PASS:build target addr 0 nsec test_lwt_seg6local:PASS:send packet 0 nsec test_lwt_seg6local:FAIL:receive packet unexpected receive packet: actual 4 != expected 7 torvalds#183 lwt_seg6local:FAIL This happens because a sendto() call mistakenly uses 'sizeof(char *)' as message length rather than the actual string ("foobar\0") size. e.g. bytes = sendto(cfd, foobar, sizeof(foobar), 0, ... This likely passed by accident till now because BPF CI only tests 64-bit targets. Fix by using strlen() to determine the message length. Fixes: 1041b8b ("selftests/bpf: lwt_seg6local: Move test to test_progs") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 27, 2025
This test_progs test fails on 32-bit armhf: root@qemu-armhf:/usr/libexec/kselftests-bpf# test_progs -a lwt_seg6local [...] test_lwt_seg6local:PASS:setup 0 nsec test_lwt_seg6local:PASS:open ns6 0 nsec test_lwt_seg6local:PASS:start server 0 nsec test_lwt_seg6local:PASS:open ns1 0 nsec test_lwt_seg6local:PASS:start client 0 nsec test_lwt_seg6local:PASS:build target addr 0 nsec test_lwt_seg6local:PASS:send packet 0 nsec test_lwt_seg6local:FAIL:receive packet unexpected receive packet: actual 4 != expected 7 torvalds#183 lwt_seg6local:FAIL This happens because a sendto() call mistakenly uses 'sizeof(char *)' as message length rather than the actual string ("foobar\0") size. e.g. bytes = sendto(cfd, foobar, sizeof(foobar), 0, ... This likely passed by accident till now because BPF CI only tests 64-bit targets. Fix by using strlen() to determine the message length. Fixes: 1041b8b ("selftests/bpf: lwt_seg6local: Move test to test_progs") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 27, 2025
This test_progs test fails on 32-bit armhf: root@qemu-armhf:/usr/libexec/kselftests-bpf# test_progs -a lwt_seg6local [...] test_lwt_seg6local:PASS:setup 0 nsec test_lwt_seg6local:PASS:open ns6 0 nsec test_lwt_seg6local:PASS:start server 0 nsec test_lwt_seg6local:PASS:open ns1 0 nsec test_lwt_seg6local:PASS:start client 0 nsec test_lwt_seg6local:PASS:build target addr 0 nsec test_lwt_seg6local:PASS:send packet 0 nsec test_lwt_seg6local:FAIL:receive packet unexpected receive packet: actual 4 != expected 7 torvalds#183 lwt_seg6local:FAIL This happens because a sendto() call mistakenly uses 'sizeof(char *)' as message length rather than the actual string ("foobar\0") size. e.g. bytes = sendto(cfd, foobar, sizeof(foobar), 0, ... This likely passed by accident till now because BPF CI only tests 64-bit targets. Fix by using strlen() to determine the message length. Fixes: 1041b8b ("selftests/bpf: lwt_seg6local: Move test to test_progs") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 27, 2025
This test_progs test fails on 32-bit armhf: root@qemu-armhf:/usr/libexec/kselftests-bpf# test_progs -a lwt_seg6local [...] test_lwt_seg6local:PASS:setup 0 nsec test_lwt_seg6local:PASS:open ns6 0 nsec test_lwt_seg6local:PASS:start server 0 nsec test_lwt_seg6local:PASS:open ns1 0 nsec test_lwt_seg6local:PASS:start client 0 nsec test_lwt_seg6local:PASS:build target addr 0 nsec test_lwt_seg6local:PASS:send packet 0 nsec test_lwt_seg6local:FAIL:receive packet unexpected receive packet: actual 4 != expected 7 torvalds#183 lwt_seg6local:FAIL This happens because a sendto() call mistakenly uses 'sizeof(char *)' as message length rather than the actual string ("foobar\0") size. e.g. bytes = sendto(cfd, foobar, sizeof(foobar), 0, ... This likely passed by accident till now because BPF CI only tests 64-bit targets. Fix by using strlen() to determine the message length. Fixes: 1041b8b ("selftests/bpf: lwt_seg6local: Move test to test_progs") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 27, 2025
This test_progs test fails on 32-bit armhf: root@qemu-armhf:/usr/libexec/kselftests-bpf# test_progs -a lwt_seg6local [...] test_lwt_seg6local:PASS:setup 0 nsec test_lwt_seg6local:PASS:open ns6 0 nsec test_lwt_seg6local:PASS:start server 0 nsec test_lwt_seg6local:PASS:open ns1 0 nsec test_lwt_seg6local:PASS:start client 0 nsec test_lwt_seg6local:PASS:build target addr 0 nsec test_lwt_seg6local:PASS:send packet 0 nsec test_lwt_seg6local:FAIL:receive packet unexpected receive packet: actual 4 != expected 7 torvalds#183 lwt_seg6local:FAIL This happens because a sendto() call mistakenly uses 'sizeof(char *)' as message length rather than the actual string ("foobar\0") size. e.g. bytes = sendto(cfd, foobar, sizeof(foobar), 0, ... This likely passed by accident till now because BPF CI only tests 64-bit targets. Fix by using strlen() to determine the message length. Fixes: 1041b8b ("selftests/bpf: lwt_seg6local: Move test to test_progs") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 27, 2025
This test_progs test fails on 32-bit armhf: root@qemu-armhf:/usr/libexec/kselftests-bpf# test_progs -a lwt_seg6local [...] test_lwt_seg6local:PASS:setup 0 nsec test_lwt_seg6local:PASS:open ns6 0 nsec test_lwt_seg6local:PASS:start server 0 nsec test_lwt_seg6local:PASS:open ns1 0 nsec test_lwt_seg6local:PASS:start client 0 nsec test_lwt_seg6local:PASS:build target addr 0 nsec test_lwt_seg6local:PASS:send packet 0 nsec test_lwt_seg6local:FAIL:receive packet unexpected receive packet: actual 4 != expected 7 torvalds#183 lwt_seg6local:FAIL This happens because a sendto() call mistakenly uses 'sizeof(char *)' as message length rather than the actual string ("foobar\0") size. e.g. bytes = sendto(cfd, foobar, sizeof(foobar), 0, ... This likely passed by accident till now because BPF CI only tests 64-bit targets. Fix by using strlen() to determine the message length. Fixes: 1041b8b ("selftests/bpf: lwt_seg6local: Move test to test_progs") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 28, 2025
This test_progs test fails on 32-bit armhf: root@qemu-armhf:/usr/libexec/kselftests-bpf# test_progs -a lwt_seg6local [...] test_lwt_seg6local:PASS:setup 0 nsec test_lwt_seg6local:PASS:open ns6 0 nsec test_lwt_seg6local:PASS:start server 0 nsec test_lwt_seg6local:PASS:open ns1 0 nsec test_lwt_seg6local:PASS:start client 0 nsec test_lwt_seg6local:PASS:build target addr 0 nsec test_lwt_seg6local:PASS:send packet 0 nsec test_lwt_seg6local:FAIL:receive packet unexpected receive packet: actual 4 != expected 7 torvalds#183 lwt_seg6local:FAIL This happens because a sendto() call mistakenly uses 'sizeof(char *)' as message length rather than the actual string ("foobar\0") size. e.g. bytes = sendto(cfd, foobar, sizeof(foobar), 0, ... This likely passed by accident till now because BPF CI only tests 64-bit targets. Fix by using strlen() to determine the message length. Fixes: 1041b8b ("selftests/bpf: lwt_seg6local: Move test to test_progs") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 30, 2025
This test_progs test fails on 32-bit armhf: root@qemu-armhf:/usr/libexec/kselftests-bpf# test_progs -a lwt_seg6local [...] test_lwt_seg6local:PASS:setup 0 nsec test_lwt_seg6local:PASS:open ns6 0 nsec test_lwt_seg6local:PASS:start server 0 nsec test_lwt_seg6local:PASS:open ns1 0 nsec test_lwt_seg6local:PASS:start client 0 nsec test_lwt_seg6local:PASS:build target addr 0 nsec test_lwt_seg6local:PASS:send packet 0 nsec test_lwt_seg6local:FAIL:receive packet unexpected receive packet: actual 4 != expected 7 torvalds#183 lwt_seg6local:FAIL This happens because a sendto() call mistakenly uses 'sizeof(char *)' as message length rather than the actual string ("foobar\0") size. e.g. bytes = sendto(cfd, foobar, sizeof(foobar), 0, ... This likely passed by accident till now because BPF CI only tests 64-bit targets. Fix by using strlen() to determine the message length. Fixes: 1041b8b ("selftests/bpf: lwt_seg6local: Move test to test_progs") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Nov 3, 2025
This test_progs test fails on 32-bit armhf: root@qemu-armhf:/usr/libexec/kselftests-bpf# test_progs -a lwt_seg6local [...] test_lwt_seg6local:PASS:setup 0 nsec test_lwt_seg6local:PASS:open ns6 0 nsec test_lwt_seg6local:PASS:start server 0 nsec test_lwt_seg6local:PASS:open ns1 0 nsec test_lwt_seg6local:PASS:start client 0 nsec test_lwt_seg6local:PASS:build target addr 0 nsec test_lwt_seg6local:PASS:send packet 0 nsec test_lwt_seg6local:FAIL:receive packet unexpected receive packet: actual 4 != expected 7 torvalds#183 lwt_seg6local:FAIL This happens because a sendto() call mistakenly uses 'sizeof(char *)' as message length rather than the actual string ("foobar\0") size. e.g. bytes = sendto(cfd, foobar, sizeof(foobar), 0, ... This likely passed by accident till now because BPF CI only tests 64-bit targets. Fix by using strlen() to determine the message length. Fixes: 1041b8b ("selftests/bpf: lwt_seg6local: Move test to test_progs") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Nov 5, 2025
This test_progs test fails on 32-bit armhf: root@qemu-armhf:/usr/libexec/kselftests-bpf# test_progs -a lwt_seg6local [...] test_lwt_seg6local:PASS:setup 0 nsec test_lwt_seg6local:PASS:open ns6 0 nsec test_lwt_seg6local:PASS:start server 0 nsec test_lwt_seg6local:PASS:open ns1 0 nsec test_lwt_seg6local:PASS:start client 0 nsec test_lwt_seg6local:PASS:build target addr 0 nsec test_lwt_seg6local:PASS:send packet 0 nsec test_lwt_seg6local:FAIL:receive packet unexpected receive packet: actual 4 != expected 7 torvalds#183 lwt_seg6local:FAIL This happens because a sendto() call mistakenly uses 'sizeof(char *)' as message length rather than the actual string ("foobar\0") size. e.g. bytes = sendto(cfd, foobar, sizeof(foobar), 0, ... This likely passed by accident till now because BPF CI only tests 64-bit targets. Fix by using strlen() to determine the message length. Fixes: 1041b8b ("selftests/bpf: lwt_seg6local: Move test to test_progs") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Nov 5, 2025
This test_progs test fails on 32-bit armhf: root@qemu-armhf:/usr/libexec/kselftests-bpf# test_progs -a lwt_seg6local [...] test_lwt_seg6local:PASS:setup 0 nsec test_lwt_seg6local:PASS:open ns6 0 nsec test_lwt_seg6local:PASS:start server 0 nsec test_lwt_seg6local:PASS:open ns1 0 nsec test_lwt_seg6local:PASS:start client 0 nsec test_lwt_seg6local:PASS:build target addr 0 nsec test_lwt_seg6local:PASS:send packet 0 nsec test_lwt_seg6local:FAIL:receive packet unexpected receive packet: actual 4 != expected 7 torvalds#183 lwt_seg6local:FAIL This happens because a sendto() call mistakenly uses 'sizeof(char *)' as message length rather than the actual string ("foobar\0") size. e.g. bytes = sendto(cfd, foobar, sizeof(foobar), 0, ... This likely passed by accident till now because BPF CI only tests 64-bit targets. Fix by using strlen() to determine the message length. Fixes: 1041b8b ("selftests/bpf: lwt_seg6local: Move test to test_progs") Signed-off-by: Tony Ambardar <[email protected]>
bsbernd
pushed a commit
to DDNStorage/linux
that referenced
this pull request
Nov 7, 2025
jira LE-1907 cve CVE-2024-26886 Rebuild_History Non-Buildable kernel-5.14.0-427.35.1.el9_4 commit-author Luiz Augusto von Dentz <[email protected]> commit f7b94bd Attemting to do sock_lock on .recvmsg may cause a deadlock as shown bellow, so instead of using sock_sock this uses sk_receive_queue.lock on bt_sock_ioctl to avoid the UAF: INFO: task kworker/u9:1:121 blocked for more than 30 seconds. Not tainted 6.7.6-lemon torvalds#183 Workqueue: hci0 hci_rx_work Call Trace: <TASK> __schedule+0x37d/0xa00 schedule+0x32/0xe0 __lock_sock+0x68/0xa0 ? __pfx_autoremove_wake_function+0x10/0x10 lock_sock_nested+0x43/0x50 l2cap_sock_recv_cb+0x21/0xa0 l2cap_recv_frame+0x55b/0x30a0 ? psi_task_switch+0xeb/0x270 ? finish_task_switch.isra.0+0x93/0x2a0 hci_rx_work+0x33a/0x3f0 process_one_work+0x13a/0x2f0 worker_thread+0x2f0/0x410 ? __pfx_worker_thread+0x10/0x10 kthread+0xe0/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> Fixes: 2e07e83 ("Bluetooth: af_bluetooth: Fix Use-After-Free in bt_sock_recvmsg") Signed-off-by: Luiz Augusto von Dentz <[email protected]> (cherry picked from commit f7b94bd) Signed-off-by: Jonathan Maple <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Nov 7, 2025
This test_progs test fails on 32-bit armhf: root@qemu-armhf:/usr/libexec/kselftests-bpf# test_progs -a lwt_seg6local [...] test_lwt_seg6local:PASS:setup 0 nsec test_lwt_seg6local:PASS:open ns6 0 nsec test_lwt_seg6local:PASS:start server 0 nsec test_lwt_seg6local:PASS:open ns1 0 nsec test_lwt_seg6local:PASS:start client 0 nsec test_lwt_seg6local:PASS:build target addr 0 nsec test_lwt_seg6local:PASS:send packet 0 nsec test_lwt_seg6local:FAIL:receive packet unexpected receive packet: actual 4 != expected 7 torvalds#183 lwt_seg6local:FAIL This happens because a sendto() call mistakenly uses 'sizeof(char *)' as message length rather than the actual string ("foobar\0") size. e.g. bytes = sendto(cfd, foobar, sizeof(foobar), 0, ... This likely passed by accident till now because BPF CI only tests 64-bit targets. Fix by using strlen() to determine the message length. Fixes: 1041b8b ("selftests/bpf: lwt_seg6local: Move test to test_progs") Signed-off-by: Tony Ambardar <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
fixed typos and grammar errors of both Korean and English
I tried to fix few errors via github based on what I have learned from the mini concert held at school today.
If I am doing correct, it might be the first contribution in my life :).
Have nice day :)
안녕하세요! 오늘 학교에서 진행한 미니콘서트에서 배운 대로 코드 구경을 하다가 몇 가지 오타랑 띄어쓰기 오류가 보여서 수정해보았습니다...
이렇게 해도 되는 건 진 아직 잘 모르겠지만.. ;; 맞는다면 이게 제 첫 contribution이 되겠네요!! 그럼 수고하세요~~