-
Notifications
You must be signed in to change notification settings - Fork 54.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ath6kl Baytrail SDIO support #322
Open
guylamar2006
wants to merge
2
commits into
torvalds:master
Choose a base branch
from
guylamar2006:master
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Conversation
This file contains 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
Add baytrail wifi SDIO ID.
Added Baytrail SDIO ID.
laijs
pushed a commit
to laijs/linux
that referenced
this pull request
Feb 22, 2017
use host_task_stub() for host task
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Oct 10, 2017
…ch-fixes WARNING: Possible unwrapped commit description (prefer a maximum 75 chars per line) torvalds#21: A) page backing address is free before mmu_notifier_invalidate_range_end() ERROR: code indent should use tabs where possible torvalds#322: FILE: mm/hugetlb.c:3263: +^I ^I^I^I *$ WARNING: please, no space before tabs torvalds#322: FILE: mm/hugetlb.c:3263: +^I ^I^I^I *$ total: 1 errors, 2 warnings, 283 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. NOTE: Whitespace errors detected. You may wish to use scripts/cleanpatch or scripts/cleanfile ./patches/mm-mmu_notifier-avoid-double-notification-when-it-is-useless.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: Jérôme Glisse <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jul 16, 2018
WARNING: please, no spaces at the start of a line torvalds#250: FILE: kernel/cgroup/cgroup.c:4554: + {$ ERROR: code indent should use tabs where possible torvalds#251: FILE: kernel/cgroup/cgroup.c:4555: + .name = "cpu.pressure",$ WARNING: please, no spaces at the start of a line torvalds#251: FILE: kernel/cgroup/cgroup.c:4555: + .name = "cpu.pressure",$ ERROR: code indent should use tabs where possible torvalds#252: FILE: kernel/cgroup/cgroup.c:4556: + .flags = CFTYPE_NOT_ON_ROOT,$ WARNING: please, no spaces at the start of a line torvalds#252: FILE: kernel/cgroup/cgroup.c:4556: + .flags = CFTYPE_NOT_ON_ROOT,$ ERROR: code indent should use tabs where possible torvalds#253: FILE: kernel/cgroup/cgroup.c:4557: + .seq_show = cgroup_cpu_pressure_show,$ WARNING: please, no spaces at the start of a line torvalds#253: FILE: kernel/cgroup/cgroup.c:4557: + .seq_show = cgroup_cpu_pressure_show,$ WARNING: please, no spaces at the start of a line torvalds#254: FILE: kernel/cgroup/cgroup.c:4558: + },$ WARNING: please, no spaces at the start of a line torvalds#255: FILE: kernel/cgroup/cgroup.c:4559: + {$ ERROR: code indent should use tabs where possible torvalds#256: FILE: kernel/cgroup/cgroup.c:4560: + .name = "memory.pressure",$ WARNING: please, no spaces at the start of a line torvalds#256: FILE: kernel/cgroup/cgroup.c:4560: + .name = "memory.pressure",$ ERROR: code indent should use tabs where possible torvalds#257: FILE: kernel/cgroup/cgroup.c:4561: + .flags = CFTYPE_NOT_ON_ROOT,$ WARNING: please, no spaces at the start of a line torvalds#257: FILE: kernel/cgroup/cgroup.c:4561: + .flags = CFTYPE_NOT_ON_ROOT,$ ERROR: code indent should use tabs where possible torvalds#258: FILE: kernel/cgroup/cgroup.c:4562: + .seq_show = cgroup_memory_pressure_show,$ WARNING: please, no spaces at the start of a line torvalds#258: FILE: kernel/cgroup/cgroup.c:4562: + .seq_show = cgroup_memory_pressure_show,$ WARNING: please, no spaces at the start of a line torvalds#259: FILE: kernel/cgroup/cgroup.c:4563: + },$ WARNING: please, no spaces at the start of a line torvalds#260: FILE: kernel/cgroup/cgroup.c:4564: + {$ ERROR: code indent should use tabs where possible torvalds#261: FILE: kernel/cgroup/cgroup.c:4565: + .name = "io.pressure",$ WARNING: please, no spaces at the start of a line torvalds#261: FILE: kernel/cgroup/cgroup.c:4565: + .name = "io.pressure",$ ERROR: code indent should use tabs where possible torvalds#262: FILE: kernel/cgroup/cgroup.c:4566: + .flags = CFTYPE_NOT_ON_ROOT,$ WARNING: please, no spaces at the start of a line torvalds#262: FILE: kernel/cgroup/cgroup.c:4566: + .flags = CFTYPE_NOT_ON_ROOT,$ ERROR: code indent should use tabs where possible torvalds#263: FILE: kernel/cgroup/cgroup.c:4567: + .seq_show = cgroup_io_pressure_show,$ WARNING: please, no spaces at the start of a line torvalds#263: FILE: kernel/cgroup/cgroup.c:4567: + .seq_show = cgroup_io_pressure_show,$ WARNING: please, no spaces at the start of a line torvalds#264: FILE: kernel/cgroup/cgroup.c:4568: + },$ WARNING: please, no spaces at the start of a line torvalds#322: FILE: kernel/sched/psi.c:424: + cgroup = task->cgroups->dfl_cgrp;$ WARNING: please, no spaces at the start of a line torvalds#323: FILE: kernel/sched/psi.c:425: + while (cgroup && (parent = cgroup_parent(cgroup))) {$ WARNING: suspect code indent for conditional statements (7, 15) torvalds#323: FILE: kernel/sched/psi.c:425: + while (cgroup && (parent = cgroup_parent(cgroup))) { + struct psi_group *group; ERROR: code indent should use tabs where possible torvalds#324: FILE: kernel/sched/psi.c:426: + struct psi_group *group;$ WARNING: please, no spaces at the start of a line torvalds#324: FILE: kernel/sched/psi.c:426: + struct psi_group *group;$ ERROR: code indent should use tabs where possible torvalds#326: FILE: kernel/sched/psi.c:428: + group = cgroup_psi(cgroup);$ WARNING: please, no spaces at the start of a line torvalds#326: FILE: kernel/sched/psi.c:428: + group = cgroup_psi(cgroup);$ ERROR: code indent should use tabs where possible torvalds#327: FILE: kernel/sched/psi.c:429: + psi_group_change(group, cpu, now, clear, set);$ WARNING: please, no spaces at the start of a line torvalds#327: FILE: kernel/sched/psi.c:429: + psi_group_change(group, cpu, now, clear, set);$ ERROR: code indent should use tabs where possible torvalds#329: FILE: kernel/sched/psi.c:431: + cgroup = parent;$ WARNING: please, no spaces at the start of a line torvalds#329: FILE: kernel/sched/psi.c:431: + cgroup = parent;$ WARNING: please, no spaces at the start of a line torvalds#330: FILE: kernel/sched/psi.c:432: + }$ WARNING: braces {} are not necessary for any arm of this statement torvalds#378: FILE: kernel/sched/psi.c:537: + if (task_on_rq_queued(task)) { [...] + } else if (task->in_iowait) { [...] total: 13 errors, 24 warnings, 334 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. NOTE: Whitespace errors detected. You may wish to use scripts/cleanpatch or scripts/cleanfile ./patches/psi-cgroup-support.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: Johannes Weiner <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Sep 22, 2018
…inter In hibmc_drm_fb_create(), when the call to hibmc_framebuffer_init() fails with error, do not store the error code in the HiBMC device frame-buffer pointer, as this will be later checked for non-zero value in hibmc_fbdev_destroy() when our intention is to check for a valid function pointer. This fixes the following crash: [ 9.699791] Unable to handle kernel NULL pointer dereference at virtual address 000000000000001a [ 9.708672] Mem abort info: [ 9.711489] ESR = 0x96000004 [ 9.714570] Exception class = DABT (current EL), IL = 32 bits [ 9.720551] SET = 0, FnV = 0 [ 9.723631] EA = 0, S1PTW = 0 [ 9.726799] Data abort info: [ 9.729702] ISV = 0, ISS = 0x00000004 [ 9.733573] CM = 0, WnR = 0 [ 9.736566] [000000000000001a] user address but active_mm is swapper [ 9.742987] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 9.748614] Modules linked in: [ 9.751694] CPU: 16 PID: 293 Comm: kworker/16:1 Tainted: G W 4.19.0-rc4-next-20180920-00001-g9b0012c torvalds#322 [ 9.762681] Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05 IT21 Nemo 2.0 RC0 04/18/2018 [ 9.771915] Workqueue: events work_for_cpu_fn [ 9.776312] pstate: 60000005 (nZCv daif -PAN -UAO) [ 9.781150] pc : drm_mode_object_put+0x0/0x20 [ 9.785547] lr : hibmc_fbdev_fini+0x40/0x58 [ 9.789767] sp : ffff00000af1bcf0 [ 9.793108] x29: ffff00000af1bcf0 x28: 0000000000000000 [ 9.798473] x27: 0000000000000000 x26: ffff000008f66630 [ 9.803838] x25: 0000000000000000 x24: ffff0000095abb98 [ 9.809203] x23: ffff8017db92fe00 x22: ffff8017d2b13000 [ 9.814568] x21: ffffffffffffffea x20: ffff8017d2f80018 [ 9.819933] x19: ffff8017d28a0018 x18: ffffffffffffffff [ 9.825297] x17: 0000000000000000 x16: 0000000000000000 [ 9.830662] x15: ffff0000092296c8 x14: ffff00008939970f [ 9.836026] x13: ffff00000939971d x12: ffff000009229940 [ 9.841391] x11: ffff0000085f8fc0 x10: ffff00000af1b9a0 [ 9.846756] x9 : 000000000000000d x8 : 6620657a696c6169 [ 9.852121] x7 : ffff8017d3340580 x6 : ffff8017d4168000 [ 9.857486] x5 : 0000000000000000 x4 : ffff8017db92fb20 [ 9.862850] x3 : 0000000000002690 x2 : ffff8017d3340480 [ 9.868214] x1 : 0000000000000028 x0 : 0000000000000002 [ 9.873580] Process kworker/16:1 (pid: 293, stack limit = 0x(____ptrval____)) [ 9.880788] Call trace: [ 9.883252] drm_mode_object_put+0x0/0x20 [ 9.887297] hibmc_unload+0x1c/0x80 [ 9.890815] hibmc_pci_probe+0x170/0x3c8 [ 9.894773] local_pci_probe+0x3c/0xb0 [ 9.898555] work_for_cpu_fn+0x18/0x28 [ 9.902337] process_one_work+0x1e0/0x318 [ 9.906382] worker_thread+0x228/0x450 [ 9.910164] kthread+0x128/0x130 [ 9.913418] ret_from_fork+0x10/0x18 [ 9.917024] Code: a94153f3 a8c27bfd d65f03c0 d503201f (f9400c01) [ 9.923180] ---[ end trace 2695ffa0af5be375 ]--- Fixes: d1667b8 ("drm/hisilicon/hibmc: Add support for frame buffer") Signed-off-by: John Garry <[email protected]>
wens
pushed a commit
to linux-sunxi/linux-sunxi
that referenced
this pull request
Sep 27, 2018
…inter In hibmc_drm_fb_create(), when the call to hibmc_framebuffer_init() fails with error, do not store the error code in the HiBMC device frame-buffer pointer, as this will be later checked for non-zero value in hibmc_fbdev_destroy() when our intention is to check for a valid function pointer. This fixes the following crash: [ 9.699791] Unable to handle kernel NULL pointer dereference at virtual address 000000000000001a [ 9.708672] Mem abort info: [ 9.711489] ESR = 0x96000004 [ 9.714570] Exception class = DABT (current EL), IL = 32 bits [ 9.720551] SET = 0, FnV = 0 [ 9.723631] EA = 0, S1PTW = 0 [ 9.726799] Data abort info: [ 9.729702] ISV = 0, ISS = 0x00000004 [ 9.733573] CM = 0, WnR = 0 [ 9.736566] [000000000000001a] user address but active_mm is swapper [ 9.742987] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 9.748614] Modules linked in: [ 9.751694] CPU: 16 PID: 293 Comm: kworker/16:1 Tainted: G W 4.19.0-rc4-next-20180920-00001-g9b0012c torvalds#322 [ 9.762681] Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05 IT21 Nemo 2.0 RC0 04/18/2018 [ 9.771915] Workqueue: events work_for_cpu_fn [ 9.776312] pstate: 60000005 (nZCv daif -PAN -UAO) [ 9.781150] pc : drm_mode_object_put+0x0/0x20 [ 9.785547] lr : hibmc_fbdev_fini+0x40/0x58 [ 9.789767] sp : ffff00000af1bcf0 [ 9.793108] x29: ffff00000af1bcf0 x28: 0000000000000000 [ 9.798473] x27: 0000000000000000 x26: ffff000008f66630 [ 9.803838] x25: 0000000000000000 x24: ffff0000095abb98 [ 9.809203] x23: ffff8017db92fe00 x22: ffff8017d2b13000 [ 9.814568] x21: ffffffffffffffea x20: ffff8017d2f80018 [ 9.819933] x19: ffff8017d28a0018 x18: ffffffffffffffff [ 9.825297] x17: 0000000000000000 x16: 0000000000000000 [ 9.830662] x15: ffff0000092296c8 x14: ffff00008939970f [ 9.836026] x13: ffff00000939971d x12: ffff000009229940 [ 9.841391] x11: ffff0000085f8fc0 x10: ffff00000af1b9a0 [ 9.846756] x9 : 000000000000000d x8 : 6620657a696c6169 [ 9.852121] x7 : ffff8017d3340580 x6 : ffff8017d4168000 [ 9.857486] x5 : 0000000000000000 x4 : ffff8017db92fb20 [ 9.862850] x3 : 0000000000002690 x2 : ffff8017d3340480 [ 9.868214] x1 : 0000000000000028 x0 : 0000000000000002 [ 9.873580] Process kworker/16:1 (pid: 293, stack limit = 0x(____ptrval____)) [ 9.880788] Call trace: [ 9.883252] drm_mode_object_put+0x0/0x20 [ 9.887297] hibmc_unload+0x1c/0x80 [ 9.890815] hibmc_pci_probe+0x170/0x3c8 [ 9.894773] local_pci_probe+0x3c/0xb0 [ 9.898555] work_for_cpu_fn+0x18/0x28 [ 9.902337] process_one_work+0x1e0/0x318 [ 9.906382] worker_thread+0x228/0x450 [ 9.910164] kthread+0x128/0x130 [ 9.913418] ret_from_fork+0x10/0x18 [ 9.917024] Code: a94153f3 a8c27bfd d65f03c0 d503201f (f9400c01) [ 9.923180] ---[ end trace 2695ffa0af5be375 ]--- Fixes: d1667b8 ("drm/hisilicon/hibmc: Add support for frame buffer") Signed-off-by: John Garry <[email protected]> Reviewed-by: Xinliang Liu <[email protected]> Signed-off-by: Xinliang Liu <[email protected]>
damentz
referenced
this pull request
in zen-kernel/zen-kernel
Nov 21, 2018
…inter [ Upstream commit 331d880 ] In hibmc_drm_fb_create(), when the call to hibmc_framebuffer_init() fails with error, do not store the error code in the HiBMC device frame-buffer pointer, as this will be later checked for non-zero value in hibmc_fbdev_destroy() when our intention is to check for a valid function pointer. This fixes the following crash: [ 9.699791] Unable to handle kernel NULL pointer dereference at virtual address 000000000000001a [ 9.708672] Mem abort info: [ 9.711489] ESR = 0x96000004 [ 9.714570] Exception class = DABT (current EL), IL = 32 bits [ 9.720551] SET = 0, FnV = 0 [ 9.723631] EA = 0, S1PTW = 0 [ 9.726799] Data abort info: [ 9.729702] ISV = 0, ISS = 0x00000004 [ 9.733573] CM = 0, WnR = 0 [ 9.736566] [000000000000001a] user address but active_mm is swapper [ 9.742987] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 9.748614] Modules linked in: [ 9.751694] CPU: 16 PID: 293 Comm: kworker/16:1 Tainted: G W 4.19.0-rc4-next-20180920-00001-g9b0012c #322 [ 9.762681] Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05 IT21 Nemo 2.0 RC0 04/18/2018 [ 9.771915] Workqueue: events work_for_cpu_fn [ 9.776312] pstate: 60000005 (nZCv daif -PAN -UAO) [ 9.781150] pc : drm_mode_object_put+0x0/0x20 [ 9.785547] lr : hibmc_fbdev_fini+0x40/0x58 [ 9.789767] sp : ffff00000af1bcf0 [ 9.793108] x29: ffff00000af1bcf0 x28: 0000000000000000 [ 9.798473] x27: 0000000000000000 x26: ffff000008f66630 [ 9.803838] x25: 0000000000000000 x24: ffff0000095abb98 [ 9.809203] x23: ffff8017db92fe00 x22: ffff8017d2b13000 [ 9.814568] x21: ffffffffffffffea x20: ffff8017d2f80018 [ 9.819933] x19: ffff8017d28a0018 x18: ffffffffffffffff [ 9.825297] x17: 0000000000000000 x16: 0000000000000000 [ 9.830662] x15: ffff0000092296c8 x14: ffff00008939970f [ 9.836026] x13: ffff00000939971d x12: ffff000009229940 [ 9.841391] x11: ffff0000085f8fc0 x10: ffff00000af1b9a0 [ 9.846756] x9 : 000000000000000d x8 : 6620657a696c6169 [ 9.852121] x7 : ffff8017d3340580 x6 : ffff8017d4168000 [ 9.857486] x5 : 0000000000000000 x4 : ffff8017db92fb20 [ 9.862850] x3 : 0000000000002690 x2 : ffff8017d3340480 [ 9.868214] x1 : 0000000000000028 x0 : 0000000000000002 [ 9.873580] Process kworker/16:1 (pid: 293, stack limit = 0x(____ptrval____)) [ 9.880788] Call trace: [ 9.883252] drm_mode_object_put+0x0/0x20 [ 9.887297] hibmc_unload+0x1c/0x80 [ 9.890815] hibmc_pci_probe+0x170/0x3c8 [ 9.894773] local_pci_probe+0x3c/0xb0 [ 9.898555] work_for_cpu_fn+0x18/0x28 [ 9.902337] process_one_work+0x1e0/0x318 [ 9.906382] worker_thread+0x228/0x450 [ 9.910164] kthread+0x128/0x130 [ 9.913418] ret_from_fork+0x10/0x18 [ 9.917024] Code: a94153f3 a8c27bfd d65f03c0 d503201f (f9400c01) [ 9.923180] ---[ end trace 2695ffa0af5be375 ]--- Fixes: d1667b8 ("drm/hisilicon/hibmc: Add support for frame buffer") Signed-off-by: John Garry <[email protected]> Reviewed-by: Xinliang Liu <[email protected]> Signed-off-by: Xinliang Liu <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
ddstreet
pushed a commit
to ddstreet/linux
that referenced
this pull request
Feb 5, 2019
…inter BugLink: http://bugs.launchpad.net/bugs/1810821 [ Upstream commit 331d880 ] In hibmc_drm_fb_create(), when the call to hibmc_framebuffer_init() fails with error, do not store the error code in the HiBMC device frame-buffer pointer, as this will be later checked for non-zero value in hibmc_fbdev_destroy() when our intention is to check for a valid function pointer. This fixes the following crash: [ 9.699791] Unable to handle kernel NULL pointer dereference at virtual address 000000000000001a [ 9.708672] Mem abort info: [ 9.711489] ESR = 0x96000004 [ 9.714570] Exception class = DABT (current EL), IL = 32 bits [ 9.720551] SET = 0, FnV = 0 [ 9.723631] EA = 0, S1PTW = 0 [ 9.726799] Data abort info: [ 9.729702] ISV = 0, ISS = 0x00000004 [ 9.733573] CM = 0, WnR = 0 [ 9.736566] [000000000000001a] user address but active_mm is swapper [ 9.742987] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 9.748614] Modules linked in: [ 9.751694] CPU: 16 PID: 293 Comm: kworker/16:1 Tainted: G W 4.19.0-rc4-next-20180920-00001-g9b0012c torvalds#322 [ 9.762681] Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05 IT21 Nemo 2.0 RC0 04/18/2018 [ 9.771915] Workqueue: events work_for_cpu_fn [ 9.776312] pstate: 60000005 (nZCv daif -PAN -UAO) [ 9.781150] pc : drm_mode_object_put+0x0/0x20 [ 9.785547] lr : hibmc_fbdev_fini+0x40/0x58 [ 9.789767] sp : ffff00000af1bcf0 [ 9.793108] x29: ffff00000af1bcf0 x28: 0000000000000000 [ 9.798473] x27: 0000000000000000 x26: ffff000008f66630 [ 9.803838] x25: 0000000000000000 x24: ffff0000095abb98 [ 9.809203] x23: ffff8017db92fe00 x22: ffff8017d2b13000 [ 9.814568] x21: ffffffffffffffea x20: ffff8017d2f80018 [ 9.819933] x19: ffff8017d28a0018 x18: ffffffffffffffff [ 9.825297] x17: 0000000000000000 x16: 0000000000000000 [ 9.830662] x15: ffff0000092296c8 x14: ffff00008939970f [ 9.836026] x13: ffff00000939971d x12: ffff000009229940 [ 9.841391] x11: ffff0000085f8fc0 x10: ffff00000af1b9a0 [ 9.846756] x9 : 000000000000000d x8 : 6620657a696c6169 [ 9.852121] x7 : ffff8017d3340580 x6 : ffff8017d4168000 [ 9.857486] x5 : 0000000000000000 x4 : ffff8017db92fb20 [ 9.862850] x3 : 0000000000002690 x2 : ffff8017d3340480 [ 9.868214] x1 : 0000000000000028 x0 : 0000000000000002 [ 9.873580] Process kworker/16:1 (pid: 293, stack limit = 0x(____ptrval____)) [ 9.880788] Call trace: [ 9.883252] drm_mode_object_put+0x0/0x20 [ 9.887297] hibmc_unload+0x1c/0x80 [ 9.890815] hibmc_pci_probe+0x170/0x3c8 [ 9.894773] local_pci_probe+0x3c/0xb0 [ 9.898555] work_for_cpu_fn+0x18/0x28 [ 9.902337] process_one_work+0x1e0/0x318 [ 9.906382] worker_thread+0x228/0x450 [ 9.910164] kthread+0x128/0x130 [ 9.913418] ret_from_fork+0x10/0x18 [ 9.917024] Code: a94153f3 a8c27bfd d65f03c0 d503201f (f9400c01) [ 9.923180] ---[ end trace 2695ffa0af5be375 ]--- Fixes: d1667b8 ("drm/hisilicon/hibmc: Add support for frame buffer") Signed-off-by: John Garry <[email protected]> Reviewed-by: Xinliang Liu <[email protected]> Signed-off-by: Xinliang Liu <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Kamal Mostafa <[email protected]> Signed-off-by: Kleber Sacilotto de Souza <[email protected]>
metux
added a commit
to metux/linux
that referenced
this pull request
Apr 27, 2019
Fix checkpatch warnings: WARNING: line over 80 characters torvalds#9: FILE: drivers/tty/serial/apbuart.c:9: + * Copyright (C) 2006 Daniel Hellstrom <[email protected]>, Aeroflex Gaisler AB WARNING: line over 80 characters torvalds#11: FILE: drivers/tty/serial/apbuart.c:11: + * Copyright (C) 2009 Kristoffer Glembo <[email protected]>, Aeroflex Gaisler AB WARNING: line over 80 characters torvalds#16: FILE: drivers/tty/serial/apbuart.c:16: +#if defined(CONFIG_SERIAL_GRLIB_GAISLER_APBUART_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) WARNING: labels should not be indented torvalds#122: FILE: drivers/tty/serial/apbuart.c:122: + ignore_char: WARNING: Missing a blank line after declarations torvalds#186: FILE: drivers/tty/serial/apbuart.c:186: + unsigned int status = UART_GET_STATUS(port); + return status & UART_STATUS_THE ? TIOCSER_TEMT : 0; WARNING: Missing a blank line after declarations torvalds#322: FILE: drivers/tty/serial/apbuart.c:322: + int ret = 0; + if (ser->type != PORT_UNKNOWN && ser->type != PORT_APBUART) WARNING: Missing a blank line after declarations torvalds#427: FILE: drivers/tty/serial/apbuart.c:427: + unsigned int status; + do { WARNING: Missing a blank line after declarations torvalds#463: FILE: drivers/tty/serial/apbuart.c:463: + unsigned int quot, status; + status = UART_GET_STATUS(port); WARNING: line over 80 characters torvalds#627: FILE: drivers/tty/serial/apbuart.c:627: + port->membase = ioremap(addr, sizeof(struct grlib_apbuart_regs_map)); WARNING: line over 80 characters torvalds#634: FILE: drivers/tty/serial/apbuart.c:634: + port->fifosize = apbuart_scan_fifo_size((struct uart_port *) port, line); Signed-off-by: Enrico Weigelt <[email protected]>
metux
added a commit
to metux/linux
that referenced
this pull request
Apr 29, 2019
Fix checkpatch warnings: WARNING: line over 80 characters torvalds#9: FILE: drivers/tty/serial/apbuart.c:9: + * Copyright (C) 2006 Daniel Hellstrom <[email protected]>, Aeroflex Gaisler AB WARNING: line over 80 characters torvalds#11: FILE: drivers/tty/serial/apbuart.c:11: + * Copyright (C) 2009 Kristoffer Glembo <[email protected]>, Aeroflex Gaisler AB WARNING: line over 80 characters torvalds#16: FILE: drivers/tty/serial/apbuart.c:16: +#if defined(CONFIG_SERIAL_GRLIB_GAISLER_APBUART_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) WARNING: labels should not be indented torvalds#122: FILE: drivers/tty/serial/apbuart.c:122: + ignore_char: WARNING: Missing a blank line after declarations torvalds#186: FILE: drivers/tty/serial/apbuart.c:186: + unsigned int status = UART_GET_STATUS(port); + return status & UART_STATUS_THE ? TIOCSER_TEMT : 0; WARNING: Missing a blank line after declarations torvalds#322: FILE: drivers/tty/serial/apbuart.c:322: + int ret = 0; + if (ser->type != PORT_UNKNOWN && ser->type != PORT_APBUART) WARNING: Missing a blank line after declarations torvalds#427: FILE: drivers/tty/serial/apbuart.c:427: + unsigned int status; + do { WARNING: Missing a blank line after declarations torvalds#463: FILE: drivers/tty/serial/apbuart.c:463: + unsigned int quot, status; + status = UART_GET_STATUS(port); WARNING: line over 80 characters torvalds#627: FILE: drivers/tty/serial/apbuart.c:627: + port->membase = ioremap(addr, sizeof(struct grlib_apbuart_regs_map)); WARNING: line over 80 characters torvalds#634: FILE: drivers/tty/serial/apbuart.c:634: + port->fifosize = apbuart_scan_fifo_size((struct uart_port *) port, line); Signed-off-by: Enrico Weigelt <[email protected]>
metux
added a commit
to metux/linux
that referenced
this pull request
Apr 30, 2019
Fix checkpatch warnings: WARNING: line over 80 characters torvalds#9: FILE: drivers/tty/serial/apbuart.c:9: + * Copyright (C) 2006 Daniel Hellstrom <[email protected]>, Aeroflex Gaisler AB WARNING: line over 80 characters torvalds#11: FILE: drivers/tty/serial/apbuart.c:11: + * Copyright (C) 2009 Kristoffer Glembo <[email protected]>, Aeroflex Gaisler AB WARNING: line over 80 characters torvalds#16: FILE: drivers/tty/serial/apbuart.c:16: +#if defined(CONFIG_SERIAL_GRLIB_GAISLER_APBUART_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) WARNING: labels should not be indented torvalds#122: FILE: drivers/tty/serial/apbuart.c:122: + ignore_char: WARNING: Missing a blank line after declarations torvalds#186: FILE: drivers/tty/serial/apbuart.c:186: + unsigned int status = UART_GET_STATUS(port); + return status & UART_STATUS_THE ? TIOCSER_TEMT : 0; WARNING: Missing a blank line after declarations torvalds#322: FILE: drivers/tty/serial/apbuart.c:322: + int ret = 0; + if (ser->type != PORT_UNKNOWN && ser->type != PORT_APBUART) WARNING: Missing a blank line after declarations torvalds#427: FILE: drivers/tty/serial/apbuart.c:427: + unsigned int status; + do { WARNING: Missing a blank line after declarations torvalds#463: FILE: drivers/tty/serial/apbuart.c:463: + unsigned int quot, status; + status = UART_GET_STATUS(port); WARNING: line over 80 characters torvalds#627: FILE: drivers/tty/serial/apbuart.c:627: + port->membase = ioremap(addr, sizeof(struct grlib_apbuart_regs_map)); WARNING: line over 80 characters torvalds#634: FILE: drivers/tty/serial/apbuart.c:634: + port->fifosize = apbuart_scan_fifo_size((struct uart_port *) port, line); Signed-off-by: Enrico Weigelt <[email protected]>
metux
added a commit
to metux/linux
that referenced
this pull request
Apr 30, 2019
Fix checkpatch warnings: WARNING: line over 80 characters torvalds#9: FILE: drivers/tty/serial/apbuart.c:9: + * Copyright (C) 2006 Daniel Hellstrom <[email protected]>, Aeroflex Gaisler AB WARNING: line over 80 characters torvalds#11: FILE: drivers/tty/serial/apbuart.c:11: + * Copyright (C) 2009 Kristoffer Glembo <[email protected]>, Aeroflex Gaisler AB WARNING: line over 80 characters torvalds#16: FILE: drivers/tty/serial/apbuart.c:16: +#if defined(CONFIG_SERIAL_GRLIB_GAISLER_APBUART_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) WARNING: labels should not be indented torvalds#122: FILE: drivers/tty/serial/apbuart.c:122: + ignore_char: WARNING: Missing a blank line after declarations torvalds#186: FILE: drivers/tty/serial/apbuart.c:186: + unsigned int status = UART_GET_STATUS(port); + return status & UART_STATUS_THE ? TIOCSER_TEMT : 0; WARNING: Missing a blank line after declarations torvalds#322: FILE: drivers/tty/serial/apbuart.c:322: + int ret = 0; + if (ser->type != PORT_UNKNOWN && ser->type != PORT_APBUART) WARNING: Missing a blank line after declarations torvalds#427: FILE: drivers/tty/serial/apbuart.c:427: + unsigned int status; + do { WARNING: Missing a blank line after declarations torvalds#463: FILE: drivers/tty/serial/apbuart.c:463: + unsigned int quot, status; + status = UART_GET_STATUS(port); WARNING: line over 80 characters torvalds#627: FILE: drivers/tty/serial/apbuart.c:627: + port->membase = ioremap(addr, sizeof(struct grlib_apbuart_regs_map)); WARNING: line over 80 characters torvalds#634: FILE: drivers/tty/serial/apbuart.c:634: + port->fifosize = apbuart_scan_fifo_size((struct uart_port *) port, line); Signed-off-by: Enrico Weigelt <[email protected]>
metux
added a commit
to metux/linux
that referenced
this pull request
Jun 12, 2019
Fix checkpatch warnings: WARNING: line over 80 characters torvalds#9: FILE: drivers/tty/serial/apbuart.c:9: + * Copyright (C) 2006 Daniel Hellstrom <[email protected]>, Aeroflex Gaisler AB WARNING: line over 80 characters torvalds#11: FILE: drivers/tty/serial/apbuart.c:11: + * Copyright (C) 2009 Kristoffer Glembo <[email protected]>, Aeroflex Gaisler AB WARNING: line over 80 characters torvalds#16: FILE: drivers/tty/serial/apbuart.c:16: +#if defined(CONFIG_SERIAL_GRLIB_GAISLER_APBUART_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) WARNING: labels should not be indented torvalds#122: FILE: drivers/tty/serial/apbuart.c:122: + ignore_char: WARNING: Missing a blank line after declarations torvalds#186: FILE: drivers/tty/serial/apbuart.c:186: + unsigned int status = UART_GET_STATUS(port); + return status & UART_STATUS_THE ? TIOCSER_TEMT : 0; WARNING: Missing a blank line after declarations torvalds#322: FILE: drivers/tty/serial/apbuart.c:322: + int ret = 0; + if (ser->type != PORT_UNKNOWN && ser->type != PORT_APBUART) WARNING: Missing a blank line after declarations torvalds#427: FILE: drivers/tty/serial/apbuart.c:427: + unsigned int status; + do { WARNING: Missing a blank line after declarations torvalds#463: FILE: drivers/tty/serial/apbuart.c:463: + unsigned int quot, status; + status = UART_GET_STATUS(port); WARNING: line over 80 characters torvalds#627: FILE: drivers/tty/serial/apbuart.c:627: + port->membase = ioremap(addr, sizeof(struct grlib_apbuart_regs_map)); WARNING: line over 80 characters torvalds#634: FILE: drivers/tty/serial/apbuart.c:634: + port->fifosize = apbuart_scan_fifo_size((struct uart_port *) port, line); Signed-off-by: Enrico Weigelt <[email protected]>
metux
added a commit
to metux/linux
that referenced
this pull request
Jun 27, 2019
Fix checkpatch warnings: WARNING: line over 80 characters torvalds#9: FILE: drivers/tty/serial/apbuart.c:9: + * Copyright (C) 2006 Daniel Hellstrom <[email protected]>, Aeroflex Gaisler AB WARNING: line over 80 characters torvalds#11: FILE: drivers/tty/serial/apbuart.c:11: + * Copyright (C) 2009 Kristoffer Glembo <[email protected]>, Aeroflex Gaisler AB WARNING: line over 80 characters torvalds#16: FILE: drivers/tty/serial/apbuart.c:16: +#if defined(CONFIG_SERIAL_GRLIB_GAISLER_APBUART_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) WARNING: labels should not be indented torvalds#122: FILE: drivers/tty/serial/apbuart.c:122: + ignore_char: WARNING: Missing a blank line after declarations torvalds#186: FILE: drivers/tty/serial/apbuart.c:186: + unsigned int status = UART_GET_STATUS(port); + return status & UART_STATUS_THE ? TIOCSER_TEMT : 0; WARNING: Missing a blank line after declarations torvalds#322: FILE: drivers/tty/serial/apbuart.c:322: + int ret = 0; + if (ser->type != PORT_UNKNOWN && ser->type != PORT_APBUART) WARNING: Missing a blank line after declarations torvalds#427: FILE: drivers/tty/serial/apbuart.c:427: + unsigned int status; + do { WARNING: Missing a blank line after declarations torvalds#463: FILE: drivers/tty/serial/apbuart.c:463: + unsigned int quot, status; + status = UART_GET_STATUS(port); WARNING: line over 80 characters torvalds#627: FILE: drivers/tty/serial/apbuart.c:627: + port->membase = ioremap(addr, sizeof(struct grlib_apbuart_regs_map)); WARNING: line over 80 characters torvalds#634: FILE: drivers/tty/serial/apbuart.c:634: + port->fifosize = apbuart_scan_fifo_size((struct uart_port *) port, line); Signed-off-by: Enrico Weigelt <[email protected]>
metux
added a commit
to metux/linux
that referenced
this pull request
Jul 10, 2019
Fix checkpatch warnings: WARNING: line over 80 characters torvalds#9: FILE: drivers/tty/serial/apbuart.c:9: + * Copyright (C) 2006 Daniel Hellstrom <[email protected]>, Aeroflex Gaisler AB WARNING: line over 80 characters torvalds#11: FILE: drivers/tty/serial/apbuart.c:11: + * Copyright (C) 2009 Kristoffer Glembo <[email protected]>, Aeroflex Gaisler AB WARNING: line over 80 characters torvalds#16: FILE: drivers/tty/serial/apbuart.c:16: +#if defined(CONFIG_SERIAL_GRLIB_GAISLER_APBUART_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) WARNING: labels should not be indented torvalds#122: FILE: drivers/tty/serial/apbuart.c:122: + ignore_char: WARNING: Missing a blank line after declarations torvalds#186: FILE: drivers/tty/serial/apbuart.c:186: + unsigned int status = UART_GET_STATUS(port); + return status & UART_STATUS_THE ? TIOCSER_TEMT : 0; WARNING: Missing a blank line after declarations torvalds#322: FILE: drivers/tty/serial/apbuart.c:322: + int ret = 0; + if (ser->type != PORT_UNKNOWN && ser->type != PORT_APBUART) WARNING: Missing a blank line after declarations torvalds#427: FILE: drivers/tty/serial/apbuart.c:427: + unsigned int status; + do { WARNING: Missing a blank line after declarations torvalds#463: FILE: drivers/tty/serial/apbuart.c:463: + unsigned int quot, status; + status = UART_GET_STATUS(port); WARNING: line over 80 characters torvalds#627: FILE: drivers/tty/serial/apbuart.c:627: + port->membase = ioremap(addr, sizeof(struct grlib_apbuart_regs_map)); WARNING: line over 80 characters torvalds#634: FILE: drivers/tty/serial/apbuart.c:634: + port->fifosize = apbuart_scan_fifo_size((struct uart_port *) port, line); Signed-off-by: Enrico Weigelt <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Sep 6, 2019
Current code doesn't limit the number of nested devices. Nested devices would be handled recursively and this needs huge stack memory. So, unlimited nested devices could make stack overflow. This patch adds upper_level and lower_leve, they are common variables and represent maximum lower/upper depth. When upper/lower device is attached or dettached, {lower/upper}_level are updated. and if maximum depth is bigger than 8, attach routine fails and returns -EMLINK. Test commands: ip link add dummy0 type dummy ip link add link dummy0 name vlan1 type vlan id 1 ip link set vlan1 up for i in {2..100} do let A=$i-1 ip link add name vlan$i link vlan$A type vlan id $i done Splat looks like: [ 140.483124] BUG: looking up invalid subclass: 8 [ 140.483505] turning off the locking correctness validator. [ 140.483505] CPU: 0 PID: 1324 Comm: ip Not tainted 5.3.0-rc7+ torvalds#322 [ 140.483505] Hardware name: To be filled by O.E.M. To be filled by O.E.M./Aptio CRB, BIOS 5.6.5 07/08/2015 [ 140.483505] Call Trace: [ 140.483505] dump_stack+0x7c/0xbb [ 140.483505] register_lock_class+0x64d/0x14d0 [ 140.483505] ? is_dynamic_key+0x230/0x230 [ 140.483505] ? module_assert_mutex_or_preempt+0x41/0x70 [ 140.483505] ? __module_address+0x3f/0x3c0 [ 140.483505] lockdep_init_map+0x24e/0x630 [ 140.483505] vlan_dev_init+0x828/0xce0 [8021q] [ 140.483505] register_netdevice+0x24f/0xd70 [ 140.483505] ? netdev_change_features+0xa0/0xa0 [ 140.483505] ? dev_get_nest_level+0xe1/0x170 [ 140.483505] register_vlan_dev+0x29b/0x710 [8021q] [ 140.483505] __rtnl_newlink+0xb75/0x1180 [ ... ] [ 168.446539] WARNING: can't dereference registers at 00000000bef3d701 for ip apic_timer_interrupt+0xf/0x20 [ 168.466843] ================================================================== [ 168.469452] BUG: KASAN: slab-out-of-bounds in __unwind_start+0x71/0x850 [ 168.480707] Write of size 88 at addr ffff8880b8856d38 by task ip/1758 [ 168.480707] [ 168.480707] CPU: 1 PID: 1758 Comm: ip Not tainted 5.3.0-rc7+ torvalds#322 [ ... ] [ 168.794493] Rebooting in 5 seconds.. Signed-off-by: Taehee Yoo <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Sep 6, 2019
All VLAN device has same lockdep key and subclass is initialized with nest_level. But actual nest_level value can be changed when a lower device is attached. And at this moment, the subclass should be updated but it seems to be unsafe. So this patch makes VLAN use dynamic lockdep key instead of the subclass. Test commands: ip link add dummy0 type dummy ip link set dummy0 up ip link add bond0 type bond ip link add vlan_dummy1 link dummy0 type vlan id 1 ip link add vlan_bond1 link bond0 type vlan id 2 ip link set vlan_dummy1 master bond0 ip link set bond0 up ip link set vlan_dummy1 up ip link set vlan_bond1 up Both vlan_dummy1 and vlan_bond1 have the same subclass and it makes unnecessary deadlock warning message. Splat looks like: [ 149.244978] ============================================ [ 149.244978] WARNING: possible recursive locking detected [ 149.244978] 5.3.0-rc7+ torvalds#322 Not tainted [ 149.244978] -------------------------------------------- [ 149.244978] ip/1340 is trying to acquire lock: [ 149.244978] 000000001399b1a7 (&vlan_netdev_addr_lock_key/1){+...}, at: dev_uc_sync_multiple+0xfa/0x1a0 [ 149.279600] [ 149.279600] but task is already holding lock: [ 149.279600] 00000000b963d9b4 (&vlan_netdev_addr_lock_key/1){+...}, at: dev_set_rx_mode+0x19/0x30 [ 149.279600] [ 149.279600] other info that might help us debug this: [ 149.305981] Possible unsafe locking scenario: [ 149.305981] [ 149.305981] CPU0 [ 149.305981] ---- [ 149.305981] lock(&vlan_netdev_addr_lock_key/1); [ 149.305981] lock(&vlan_netdev_addr_lock_key/1); [ 149.326258] [ 149.326258] *** DEADLOCK *** [ 149.326258] [ 149.326258] May be due to missing lock nesting notation [ 149.326258] [ 149.326258] 4 locks held by ip/1340: [ 149.326258] #0: 00000000927f0698 (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x466/0x8a0 [ 149.326258] #1: 00000000b963d9b4 (&vlan_netdev_addr_lock_key/1){+...}, at: dev_set_rx_mode+0x19/0x30 [ 149.326258] #2: 0000000027395445 (&dev_addr_list_lock_key/3){+...}, at: dev_mc_sync+0xfa/0x1a0 [ 149.369961] #3: 00000000ce334932 (rcu_read_lock){....}, at: bond_set_rx_mode+0x5/0x3c0 [bonding] [ 149.369961] [ 149.369961] stack backtrace: [ 149.369961] CPU: 1 PID: 1340 Comm: ip Not tainted 5.3.0-rc7+ torvalds#322 [ 149.369961] Call Trace: [ 149.369961] dump_stack+0x7c/0xbb [ 149.369961] __lock_acquire+0x26a9/0x3de0 [ 149.369961] ? register_lock_class+0x14d0/0x14d0 [ 149.369961] ? register_lock_class+0x14d0/0x14d0 [ 149.369961] lock_acquire+0x164/0x3b0 [ 149.433970] ? dev_uc_sync_multiple+0xfa/0x1a0 [ 149.433970] _raw_spin_lock_nested+0x2e/0x60 [ 149.433970] ? dev_uc_sync_multiple+0xfa/0x1a0 [ 149.433970] dev_uc_sync_multiple+0xfa/0x1a0 [ 149.433970] bond_set_rx_mode+0x269/0x3c0 [bonding] [ 149.433970] ? bond_init+0x6f0/0x6f0 [bonding] [ 149.433970] dev_mc_sync+0x15a/0x1a0 [ 149.433970] vlan_dev_set_rx_mode+0x37/0x80 [8021q] [ 149.433970] dev_set_rx_mode+0x21/0x30 [ 149.433970] __dev_open+0x202/0x310 [ 149.433970] ? dev_set_rx_mode+0x30/0x30 [ 149.433970] ? mark_held_locks+0xa5/0xe0 [ 149.433970] ? __local_bh_enable_ip+0xe9/0x1b0 [ 149.433970] __dev_change_flags+0x3c3/0x500 [ ... ] Fixes: 0fe1e56 ("[VLAN]: nested VLAN: fix lockdep's recursive locking warning") Signed-off-by: Taehee Yoo <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Sep 6, 2019
The IFF_BONDING means bonding master or bonding slave device. ->ndo_add_slave() sets IFF_BONDING flag and ->ndo_del_slave() removes IFF_BONDING flag. This routine makes a problem in the nesting bonding structure. bond1<--bond2 Both bond0 and bond1 are bonding device and these should keep having IFF_BONDING flag until they are removed. But bond1 would lose IFF_BONDING at ->ndo_del_slave because that routine can not check whether the slave device is the bonding type or not. So that this patch splits the IFF_BONDING into theIFF_BONDING and the IFF_BONDING_SLAVE. The IFF_BONDING is bonding master flag and IFF_BONDING_SLAVE is bonding slave flag. Test commands: ip link add bond0 type bond ip link add bond1 type bond ip link set bond1 master bond0 ip link set bond1 nomaster ip link del bond1 type bond ip link add bond1 type bond Splat looks like: [ 149.201107] proc_dir_entry 'bonding/bond1' already registered [ 149.208013] WARNING: CPU: 1 PID: 1308 at fs/proc/generic.c:361 proc_register+0x2a9/0x3e0 [ 149.208866] Modules linked in: bonding veth openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv4 ip_tables6 [ 149.208866] CPU: 1 PID: 1308 Comm: ip Not tainted 5.3.0-rc7+ torvalds#322 [ 149.208866] RIP: 0010:proc_register+0x2a9/0x3e0 [ 149.208866] Code: 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 39 01 00 00 48 8b 04 24 48 89 ea 48 c7 c7 a0 a0 13 89 48 8b b0 0 [ 149.208866] RSP: 0018:ffff88810df9f098 EFLAGS: 00010286 [ 149.208866] RAX: dffffc0000000008 RBX: ffff8880b5d3aa50 RCX: ffffffff87cdec92 [ 149.208866] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff888116bf6a8c [ 149.208866] RBP: ffff8880b5d3acd3 R08: ffffed1022d7ff71 R09: ffffed1022d7ff71 [ 149.208866] R10: 0000000000000001 R11: ffffed1022d7ff70 R12: ffff8880b5d3abe8 [ 149.208866] R13: ffff8880b5d3acd2 R14: dffffc0000000000 R15: ffffed1016ba759a [ 149.208866] FS: 00007f4bd1f650c0(0000) GS:ffff888116a00000(0000) knlGS:0000000000000000 [ 149.208866] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 149.208866] CR2: 000055e7ca686118 CR3: 0000000106fd4000 CR4: 00000000001006e0 [ 149.208866] Call Trace: [ 149.208866] proc_create_seq_private+0xb3/0xf0 [ 149.208866] bond_create_proc_entry+0x1b3/0x3f0 [bonding] [ 149.208866] bond_netdev_event+0x433/0x970 [bonding] [ 149.208866] ? __module_text_address+0x13/0x140 [ 149.208866] notifier_call_chain+0x90/0x160 [ 149.208866] register_netdevice+0x9b3/0xd70 [ 149.208866] ? alloc_netdev_mqs+0x854/0xc10 [ 149.208866] ? netdev_change_features+0xa0/0xa0 [ 149.208866] ? rtnl_create_link+0x2ed/0xad0 [ 149.208866] bond_newlink+0x2a/0x60 [bonding] [ 149.208866] __rtnl_newlink+0xb75/0x1180 [ ... ] Fixes: 0b680e7 ("[PATCH] bonding: Add priv_flag to avoid event mishandling") Signed-off-by: Taehee Yoo <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Sep 6, 2019
All bonding device has same lockdep key and subclass is initialized with nest_level. But actual nest_level value can be changed when a lower device is attached. And at this moment, the subclass should be updated but it seems to be unsafe. So this patch makes bonding use dynamic lockdep key instead of the subclass. Test commands: ip link add bond0 type bond for i in {1..5} do let A=$i-1 ip link add bond$i type bond ip link set bond$i master bond$A done ip link set bond5 master bond0 Splat looks like: [ 327.477830] ============================================ [ 327.477830] WARNING: possible recursive locking detected [ 327.477830] 5.3.0-rc7+ torvalds#322 Not tainted [ 327.477830] -------------------------------------------- [ 327.477830] ip/1399 is trying to acquire lock: [ 327.477830] 00000000f604be63 (&(&bond->stats_lock)->rlock#2/2){+.+.}, at: bond_get_stats+0xb8/0x500 [bonding] [ 327.477830] [ 327.477830] but task is already holding lock: [ 327.477830] 00000000e9d31238 (&(&bond->stats_lock)->rlock#2/2){+.+.}, at: bond_get_stats+0xb8/0x500 [bonding] [ 327.477830] [ 327.477830] other info that might help us debug this: [ 327.477830] Possible unsafe locking scenario: [ 327.477830] [ 327.477830] CPU0 [ 327.477830] ---- [ 327.477830] lock(&(&bond->stats_lock)->rlock#2/2); [ 327.477830] lock(&(&bond->stats_lock)->rlock#2/2); [ 327.477830] [ 327.477830] *** DEADLOCK *** [ 327.477830] [ 327.477830] May be due to missing lock nesting notation [ 327.477830] [ 327.477830] 3 locks held by ip/1399: [ 327.477830] #0: 00000000a762c4e3 (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x466/0x8a0 [ 327.477830] #1: 00000000e9d31238 (&(&bond->stats_lock)->rlock#2/2){+.+.}, at: bond_get_stats+0xb8/0x500 [bonding] [ 327.477830] #2: 000000008f7ebff4 (rcu_read_lock){....}, at: bond_get_stats+0x9f/0x500 [bonding] [ 327.477830] [ 327.477830] stack backtrace: [ 327.477830] CPU: 0 PID: 1399 Comm: ip Not tainted 5.3.0-rc7+ torvalds#322 [ 327.477830] Call Trace: [ 327.477830] dump_stack+0x7c/0xbb [ 327.477830] __lock_acquire+0x26a9/0x3de0 [ 327.477830] ? __change_page_attr_set_clr+0x133b/0x1d20 [ 327.477830] ? register_lock_class+0x14d0/0x14d0 [ 327.477830] lock_acquire+0x164/0x3b0 [ 327.477830] ? bond_get_stats+0xb8/0x500 [bonding] [ 327.666914] _raw_spin_lock_nested+0x2e/0x60 [ 327.666914] ? bond_get_stats+0xb8/0x500 [bonding] [ 327.678302] bond_get_stats+0xb8/0x500 [bonding] [ 327.678302] ? bond_arp_rcv+0xf10/0xf10 [bonding] [ 327.678302] ? register_lock_class+0x14d0/0x14d0 [ 327.678302] ? bond_get_stats+0xb8/0x500 [bonding] [ 327.678302] dev_get_stats+0x1ec/0x270 [ 327.678302] bond_get_stats+0x1d1/0x500 [bonding] [ 327.678302] ? lock_acquire+0x164/0x3b0 [ 327.678302] ? bond_arp_rcv+0xf10/0xf10 [bonding] [ 327.678302] ? rtnl_is_locked+0x16/0x30 [ 327.678302] ? devlink_compat_switch_id_get+0x18/0x140 [ 327.678302] ? dev_get_alias+0xe2/0x190 [ 327.731145] ? dev_get_port_parent_id+0x12a/0x340 [ 327.731145] ? rtnl_phys_switch_id_fill+0x88/0xe0 [ 327.731145] dev_get_stats+0x1ec/0x270 [ 327.731145] rtnl_fill_stats+0x44/0xbe0 [ 327.731145] ? nla_put+0xc2/0x140 [ ... ] Fixes: d3fff6c ("net: add netdev_lockdep_set_classes() helper") Signed-off-by: Taehee Yoo <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Sep 6, 2019
In the current code, all team devices have same static lockdep key and team devices could be nested so that it makes unnecessary lockdep warning. Test commands: ip link add team0 type team for i in {1..7} do let A=$i-1 ip link add team$i type team ip link set team$i master team$A done ip link del team0 Splat looks like: [ 137.406730] ============================================ [ 137.412685] WARNING: possible recursive locking detected [ 137.418642] 5.3.0-rc7+ torvalds#322 Not tainted [ 137.422941] -------------------------------------------- [ 137.428886] ip/1383 is trying to acquire lock: [ 137.433869] 0000000089571080 (&dev_addr_list_lock_key/1){+...}, at: dev_uc_sync_multiple+0xfa/0x1a0 [ 137.444034] [ 137.444034] but task is already holding lock: [ 137.450572] 00000000d9597252 (&dev_addr_list_lock_key/1){+...}, at: dev_uc_unsync+0x10c/0x1b0 [ 137.460142] [ 137.460142] other info that might help us debug this: [ 137.467458] Possible unsafe locking scenario: [ 137.467458] [ 137.474096] CPU0 [ 137.476828] ---- [ 137.479569] lock(&dev_addr_list_lock_key/1); [ 137.484554] lock(&dev_addr_list_lock_key/1); [ 137.489539] [ 137.489539] *** DEADLOCK *** [ 137.489539] [ 137.496178] May be due to missing lock nesting notation [ 137.496178] [ 137.503789] 5 locks held by ip/1383: [ 137.507797] #0: 00000000d497f415 (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x466/0x8a0 [ 137.516786] #1: 000000008e4b4656 (&team->lock){+.+.}, at: team_uninit+0x3a/0x1a0 [team] [ 137.525882] #2: 000000005cf248d1 (&dev_addr_list_lock_key){+...}, at: dev_uc_unsync+0x98/0x1b0 [ 137.535649] #3: 00000000d9597252 (&dev_addr_list_lock_key/1){+...}, at: dev_uc_unsync+0x10c/0x1b0 [ 137.545709] #4: 00000000bec134c3 (rcu_read_lock){....}, at: team_set_rx_mode+0x5/0x1d0 [team] [ 137.555384] [ 137.555384] stack backtrace: [ 137.560277] CPU: 0 PID: 1383 Comm: ip Not tainted 5.3.0-rc7+ torvalds#322 [ 137.577826] Call Trace: [ 137.580586] dump_stack+0x7c/0xbb [ 137.584307] __lock_acquire+0x26a9/0x3de0 [ 137.588820] ? register_lock_class+0x14d0/0x14d0 [ 137.594008] ? register_lock_class+0x14d0/0x14d0 [ 137.599194] lock_acquire+0x164/0x3b0 [ 137.603310] ? dev_uc_sync_multiple+0xfa/0x1a0 [ 137.608307] _raw_spin_lock_nested+0x2e/0x60 [ 137.613105] ? dev_uc_sync_multiple+0xfa/0x1a0 [ 137.618095] dev_uc_sync_multiple+0xfa/0x1a0 [ 137.622900] team_set_rx_mode+0xa9/0x1d0 [team] [ 137.627993] dev_uc_unsync+0x151/0x1b0 [ 137.632205] team_port_del+0x304/0x790 [team] [ 137.637110] team_uninit+0xb0/0x1a0 [team] [ 137.641717] rollback_registered_many+0x728/0xda0 [ 137.647005] ? generic_xdp_install+0x310/0x310 [ 137.651994] ? __set_pages_p+0xf4/0x150 [ 137.656306] ? check_chain_key+0x236/0x5d0 [ 137.660914] ? __nla_validate_parse+0x98/0x1ad0 [ 137.666006] unregister_netdevice_many.part.120+0x13/0x1b0 [ 137.672167] rtnl_delete_link+0xbc/0x100 [ 137.676575] ? rtnl_af_register+0xc0/0xc0 [ 137.681084] rtnl_dellink+0x2e7/0x870 [ 137.685204] ? find_held_lock+0x39/0x1d0 [ ... ] Fixes: 3d249d4 ("net: introduce ethernet teaming device") Signed-off-by: Taehee Yoo <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Sep 6, 2019
All macsec device has same lockdep key and subclass is initialized with nest_level. But actual nest_level value can be changed when a lower device is attached. And at this moment, the subclass should be updated but it seems to be unsafe. So this patch makes macsec use dynamic lockdep key instead of the subclass. Test commands: ip link add bond0 type bond ip link add dummy0 type dummy ip link add macsec0 link bond0 type macsec ip link add macsec1 link dummy0 type macsec ip link set bond0 mtu 1000 ip link set macsec1 master bond0 ip link set bond0 up ip link set macsec0 up ip link set dummy0 up ip link set macsec1 up Splat looks like: [ 146.540123] ============================================ [ 146.540123] WARNING: possible recursive locking detected [ 146.540123] 5.3.0-rc7+ torvalds#322 Not tainted [ 146.540123] -------------------------------------------- [ 146.540123] ip/1340 is trying to acquire lock: [ 146.540123] 00000000446fd8bd (&macsec_netdev_addr_lock_key/1){+...}, at: dev_uc_sync_multiple+0xfa/0x1a0 [ 146.540123] [ 146.540123] but task is already holding lock: [ 146.540123] 00000000a9ab6378 (&macsec_netdev_addr_lock_key/1){+...}, at: dev_set_rx_mode+0x19/0x30 [ 146.540123] [ 146.540123] other info that might help us debug this: [ 146.540123] Possible unsafe locking scenario: [ 146.540123] [ 146.540123] CPU0 [ 146.540123] ---- [ 146.540123] lock(&macsec_netdev_addr_lock_key/1); [ 146.540123] lock(&macsec_netdev_addr_lock_key/1); [ 146.623155] [ 146.623155] *** DEADLOCK *** [ 146.623155] [ 146.623155] May be due to missing lock nesting notation [ 146.623155] [ 146.623155] 4 locks held by ip/1340: [ 146.623155] #0: 0000000026436ef0 (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x466/0x8a0 [ 146.623155] #1: 00000000a9ab6378 (&macsec_netdev_addr_lock_key/1){+...}, at: dev_set_rx_mode+0x19/0x30 [ 146.623155] #2: 00000000a8947dd0 (&dev_addr_list_lock_key/3){+...}, at: dev_mc_sync+0xfa/0x1a0 [ 146.623155] #3: 00000000b62011e9 (rcu_read_lock){....}, at: bond_set_rx_mode+0x5/0x3c0 [bonding] [ 146.674970] [ 146.674970] stack backtrace: [ 146.687145] CPU: 0 PID: 1340 Comm: ip Not tainted 5.3.0-rc7+ torvalds#322 [ 146.693024] Call Trace: [ 146.693024] dump_stack+0x7c/0xbb [ 146.693024] __lock_acquire+0x26a9/0x3de0 [ 146.693024] ? register_lock_class+0x14d0/0x14d0 [ 146.693024] ? register_lock_class+0x14d0/0x14d0 [ 146.693024] lock_acquire+0x164/0x3b0 [ 146.693024] ? dev_uc_sync_multiple+0xfa/0x1a0 [ 146.693024] _raw_spin_lock_nested+0x2e/0x60 [ 146.693024] ? dev_uc_sync_multiple+0xfa/0x1a0 [ 146.693024] dev_uc_sync_multiple+0xfa/0x1a0 [ 146.693024] bond_set_rx_mode+0x269/0x3c0 [bonding] [ 146.751163] ? bond_init+0x6f0/0x6f0 [bonding] [ 146.757006] ? do_raw_spin_trylock+0xa9/0x170 [ 146.757006] dev_mc_sync+0x15a/0x1a0 [ 146.757006] macsec_dev_set_rx_mode+0x3a/0x50 [macsec] [ 146.757006] dev_set_rx_mode+0x21/0x30 [ 146.757006] __dev_open+0x202/0x310 [ 146.757006] ? dev_set_rx_mode+0x30/0x30 [ 146.757006] ? mark_held_locks+0xa5/0xe0 [ 146.757006] ? __local_bh_enable_ip+0xe9/0x1b0 [ 146.757006] __dev_change_flags+0x3c3/0x500 [ 146.757006] ? dev_set_allmulti+0x10/0x10 [ 146.757006] ? sched_clock_local+0xd4/0x140 [ 146.757006] ? check_chain_key+0x236/0x5d0 [ 146.757006] dev_change_flags+0x7a/0x160 [ 146.757006] do_setlink+0xa26/0x2f20 [ 146.757006] ? sched_clock_local+0xd4/0x140 [ ... ] Fixes: e200387 ("macsec: fix lockdep splats when nesting devices") Signed-off-by: Taehee Yoo <[email protected]>
Noltari
pushed a commit
to Noltari/linux
that referenced
this pull request
Mar 5, 2020
[ Upstream commit 064ff66 ] After bond_release(), netdev_update_lockdep_key() should be called. But both ioctl path and attribute path don't call netdev_update_lockdep_key(). This patch adds missing netdev_update_lockdep_key(). Test commands: ip link add bond0 type bond ip link add bond1 type bond ifenslave bond0 bond1 ifenslave -d bond0 bond1 ifenslave bond1 bond0 Splat looks like: [ 29.501182][ T1046] WARNING: possible circular locking dependency detected [ 29.501945][ T1039] hardirqs last disabled at (1962): [<ffffffffac6c807f>] handle_mm_fault+0x13f/0x700 [ 29.503442][ T1046] 5.5.0+ torvalds#322 Not tainted [ 29.503447][ T1046] ------------------------------------------------------ [ 29.504277][ T1039] softirqs last enabled at (1180): [<ffffffffade00678>] __do_softirq+0x678/0x981 [ 29.505443][ T1046] ifenslave/1046 is trying to acquire lock: [ 29.505886][ T1039] softirqs last disabled at (1169): [<ffffffffac19c18a>] irq_exit+0x17a/0x1a0 [ 29.509997][ T1046] ffff88805d5da280 (&dev->addr_list_lock_key#3){+...}, at: dev_mc_sync_multiple+0x95/0x120 [ 29.511243][ T1046] [ 29.511243][ T1046] but task is already holding lock: [ 29.512192][ T1046] ffff8880460f2280 (&dev->addr_list_lock_key#4){+...}, at: bond_enslave+0x4482/0x47b0 [bonding] [ 29.514124][ T1046] [ 29.514124][ T1046] which lock already depends on the new lock. [ 29.514124][ T1046] [ 29.517297][ T1046] [ 29.517297][ T1046] the existing dependency chain (in reverse order) is: [ 29.518231][ T1046] [ 29.518231][ T1046] -> #1 (&dev->addr_list_lock_key#4){+...}: [ 29.519076][ T1046] _raw_spin_lock+0x30/0x70 [ 29.519588][ T1046] dev_mc_sync_multiple+0x95/0x120 [ 29.520208][ T1046] bond_enslave+0x448d/0x47b0 [bonding] [ 29.520862][ T1046] bond_option_slaves_set+0x1a3/0x370 [bonding] [ 29.521640][ T1046] __bond_opt_set+0x1ff/0xbb0 [bonding] [ 29.522438][ T1046] __bond_opt_set_notify+0x2b/0xf0 [bonding] [ 29.523251][ T1046] bond_opt_tryset_rtnl+0x92/0xf0 [bonding] [ 29.524082][ T1046] bonding_sysfs_store_option+0x8a/0xf0 [bonding] [ 29.524959][ T1046] kernfs_fop_write+0x276/0x410 [ 29.525620][ T1046] vfs_write+0x197/0x4a0 [ 29.526218][ T1046] ksys_write+0x141/0x1d0 [ 29.526818][ T1046] do_syscall_64+0x99/0x4f0 [ 29.527430][ T1046] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 29.528265][ T1046] [ 29.528265][ T1046] -> #0 (&dev->addr_list_lock_key#3){+...}: [ 29.529272][ T1046] __lock_acquire+0x2d8d/0x3de0 [ 29.529935][ T1046] lock_acquire+0x164/0x3b0 [ 29.530638][ T1046] _raw_spin_lock+0x30/0x70 [ 29.531187][ T1046] dev_mc_sync_multiple+0x95/0x120 [ 29.531790][ T1046] bond_enslave+0x448d/0x47b0 [bonding] [ 29.532451][ T1046] bond_option_slaves_set+0x1a3/0x370 [bonding] [ 29.533163][ T1046] __bond_opt_set+0x1ff/0xbb0 [bonding] [ 29.533789][ T1046] __bond_opt_set_notify+0x2b/0xf0 [bonding] [ 29.534595][ T1046] bond_opt_tryset_rtnl+0x92/0xf0 [bonding] [ 29.535500][ T1046] bonding_sysfs_store_option+0x8a/0xf0 [bonding] [ 29.536379][ T1046] kernfs_fop_write+0x276/0x410 [ 29.537057][ T1046] vfs_write+0x197/0x4a0 [ 29.537640][ T1046] ksys_write+0x141/0x1d0 [ 29.538251][ T1046] do_syscall_64+0x99/0x4f0 [ 29.538870][ T1046] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 29.539659][ T1046] [ 29.539659][ T1046] other info that might help us debug this: [ 29.539659][ T1046] [ 29.540953][ T1046] Possible unsafe locking scenario: [ 29.540953][ T1046] [ 29.541883][ T1046] CPU0 CPU1 [ 29.542540][ T1046] ---- ---- [ 29.543209][ T1046] lock(&dev->addr_list_lock_key#4); [ 29.543880][ T1046] lock(&dev->addr_list_lock_key#3); [ 29.544873][ T1046] lock(&dev->addr_list_lock_key#4); [ 29.545863][ T1046] lock(&dev->addr_list_lock_key#3); [ 29.546525][ T1046] [ 29.546525][ T1046] *** DEADLOCK *** [ 29.546525][ T1046] [ 29.547542][ T1046] 5 locks held by ifenslave/1046: [ 29.548196][ T1046] #0: ffff88806044c478 (sb_writers#5){.+.+}, at: vfs_write+0x3bb/0x4a0 [ 29.549248][ T1046] #1: ffff88805af00890 (&of->mutex){+.+.}, at: kernfs_fop_write+0x1cf/0x410 [ 29.550343][ T1046] #2: ffff88805b8b54b0 (kn->count#157){.+.+}, at: kernfs_fop_write+0x1f2/0x410 [ 29.551575][ T1046] #3: ffffffffaecf4cf0 (rtnl_mutex){+.+.}, at: bond_opt_tryset_rtnl+0x5f/0xf0 [bonding] [ 29.552819][ T1046] #4: ffff8880460f2280 (&dev->addr_list_lock_key#4){+...}, at: bond_enslave+0x4482/0x47b0 [bonding] [ 29.554175][ T1046] [ 29.554175][ T1046] stack backtrace: [ 29.554907][ T1046] CPU: 0 PID: 1046 Comm: ifenslave Not tainted 5.5.0+ torvalds#322 [ 29.555854][ T1046] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 29.557064][ T1046] Call Trace: [ 29.557504][ T1046] dump_stack+0x96/0xdb [ 29.558054][ T1046] check_noncircular+0x371/0x450 [ 29.558723][ T1046] ? print_circular_bug.isra.35+0x310/0x310 [ 29.559486][ T1046] ? hlock_class+0x130/0x130 [ 29.560100][ T1046] ? __lock_acquire+0x2d8d/0x3de0 [ 29.560761][ T1046] __lock_acquire+0x2d8d/0x3de0 [ 29.561366][ T1046] ? register_lock_class+0x14d0/0x14d0 [ 29.562045][ T1046] ? find_held_lock+0x39/0x1d0 [ 29.562641][ T1046] lock_acquire+0x164/0x3b0 [ 29.563199][ T1046] ? dev_mc_sync_multiple+0x95/0x120 [ 29.563872][ T1046] _raw_spin_lock+0x30/0x70 [ 29.564464][ T1046] ? dev_mc_sync_multiple+0x95/0x120 [ 29.565146][ T1046] dev_mc_sync_multiple+0x95/0x120 [ 29.565793][ T1046] bond_enslave+0x448d/0x47b0 [bonding] [ 29.566487][ T1046] ? bond_update_slave_arr+0x940/0x940 [bonding] [ 29.567279][ T1046] ? bstr_printf+0xc20/0xc20 [ 29.567857][ T1046] ? stack_trace_consume_entry+0x160/0x160 [ 29.568614][ T1046] ? deactivate_slab.isra.77+0x2c5/0x800 [ 29.569320][ T1046] ? check_chain_key+0x236/0x5d0 [ 29.569939][ T1046] ? sscanf+0x93/0xc0 [ 29.570442][ T1046] ? vsscanf+0x1e20/0x1e20 [ 29.571003][ T1046] bond_option_slaves_set+0x1a3/0x370 [bonding] [ ... ] Fixes: ab92d68 ("net: core: add generic lockdep keys") Signed-off-by: Taehee Yoo <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
damentz
referenced
this pull request
in zen-kernel/zen-kernel
Mar 5, 2020
[ Upstream commit 064ff66 ] After bond_release(), netdev_update_lockdep_key() should be called. But both ioctl path and attribute path don't call netdev_update_lockdep_key(). This patch adds missing netdev_update_lockdep_key(). Test commands: ip link add bond0 type bond ip link add bond1 type bond ifenslave bond0 bond1 ifenslave -d bond0 bond1 ifenslave bond1 bond0 Splat looks like: [ 29.501182][ T1046] WARNING: possible circular locking dependency detected [ 29.501945][ T1039] hardirqs last disabled at (1962): [<ffffffffac6c807f>] handle_mm_fault+0x13f/0x700 [ 29.503442][ T1046] 5.5.0+ #322 Not tainted [ 29.503447][ T1046] ------------------------------------------------------ [ 29.504277][ T1039] softirqs last enabled at (1180): [<ffffffffade00678>] __do_softirq+0x678/0x981 [ 29.505443][ T1046] ifenslave/1046 is trying to acquire lock: [ 29.505886][ T1039] softirqs last disabled at (1169): [<ffffffffac19c18a>] irq_exit+0x17a/0x1a0 [ 29.509997][ T1046] ffff88805d5da280 (&dev->addr_list_lock_key#3){+...}, at: dev_mc_sync_multiple+0x95/0x120 [ 29.511243][ T1046] [ 29.511243][ T1046] but task is already holding lock: [ 29.512192][ T1046] ffff8880460f2280 (&dev->addr_list_lock_key#4){+...}, at: bond_enslave+0x4482/0x47b0 [bonding] [ 29.514124][ T1046] [ 29.514124][ T1046] which lock already depends on the new lock. [ 29.514124][ T1046] [ 29.517297][ T1046] [ 29.517297][ T1046] the existing dependency chain (in reverse order) is: [ 29.518231][ T1046] [ 29.518231][ T1046] -> #1 (&dev->addr_list_lock_key#4){+...}: [ 29.519076][ T1046] _raw_spin_lock+0x30/0x70 [ 29.519588][ T1046] dev_mc_sync_multiple+0x95/0x120 [ 29.520208][ T1046] bond_enslave+0x448d/0x47b0 [bonding] [ 29.520862][ T1046] bond_option_slaves_set+0x1a3/0x370 [bonding] [ 29.521640][ T1046] __bond_opt_set+0x1ff/0xbb0 [bonding] [ 29.522438][ T1046] __bond_opt_set_notify+0x2b/0xf0 [bonding] [ 29.523251][ T1046] bond_opt_tryset_rtnl+0x92/0xf0 [bonding] [ 29.524082][ T1046] bonding_sysfs_store_option+0x8a/0xf0 [bonding] [ 29.524959][ T1046] kernfs_fop_write+0x276/0x410 [ 29.525620][ T1046] vfs_write+0x197/0x4a0 [ 29.526218][ T1046] ksys_write+0x141/0x1d0 [ 29.526818][ T1046] do_syscall_64+0x99/0x4f0 [ 29.527430][ T1046] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 29.528265][ T1046] [ 29.528265][ T1046] -> #0 (&dev->addr_list_lock_key#3){+...}: [ 29.529272][ T1046] __lock_acquire+0x2d8d/0x3de0 [ 29.529935][ T1046] lock_acquire+0x164/0x3b0 [ 29.530638][ T1046] _raw_spin_lock+0x30/0x70 [ 29.531187][ T1046] dev_mc_sync_multiple+0x95/0x120 [ 29.531790][ T1046] bond_enslave+0x448d/0x47b0 [bonding] [ 29.532451][ T1046] bond_option_slaves_set+0x1a3/0x370 [bonding] [ 29.533163][ T1046] __bond_opt_set+0x1ff/0xbb0 [bonding] [ 29.533789][ T1046] __bond_opt_set_notify+0x2b/0xf0 [bonding] [ 29.534595][ T1046] bond_opt_tryset_rtnl+0x92/0xf0 [bonding] [ 29.535500][ T1046] bonding_sysfs_store_option+0x8a/0xf0 [bonding] [ 29.536379][ T1046] kernfs_fop_write+0x276/0x410 [ 29.537057][ T1046] vfs_write+0x197/0x4a0 [ 29.537640][ T1046] ksys_write+0x141/0x1d0 [ 29.538251][ T1046] do_syscall_64+0x99/0x4f0 [ 29.538870][ T1046] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 29.539659][ T1046] [ 29.539659][ T1046] other info that might help us debug this: [ 29.539659][ T1046] [ 29.540953][ T1046] Possible unsafe locking scenario: [ 29.540953][ T1046] [ 29.541883][ T1046] CPU0 CPU1 [ 29.542540][ T1046] ---- ---- [ 29.543209][ T1046] lock(&dev->addr_list_lock_key#4); [ 29.543880][ T1046] lock(&dev->addr_list_lock_key#3); [ 29.544873][ T1046] lock(&dev->addr_list_lock_key#4); [ 29.545863][ T1046] lock(&dev->addr_list_lock_key#3); [ 29.546525][ T1046] [ 29.546525][ T1046] *** DEADLOCK *** [ 29.546525][ T1046] [ 29.547542][ T1046] 5 locks held by ifenslave/1046: [ 29.548196][ T1046] #0: ffff88806044c478 (sb_writers#5){.+.+}, at: vfs_write+0x3bb/0x4a0 [ 29.549248][ T1046] #1: ffff88805af00890 (&of->mutex){+.+.}, at: kernfs_fop_write+0x1cf/0x410 [ 29.550343][ T1046] #2: ffff88805b8b54b0 (kn->count#157){.+.+}, at: kernfs_fop_write+0x1f2/0x410 [ 29.551575][ T1046] #3: ffffffffaecf4cf0 (rtnl_mutex){+.+.}, at: bond_opt_tryset_rtnl+0x5f/0xf0 [bonding] [ 29.552819][ T1046] #4: ffff8880460f2280 (&dev->addr_list_lock_key#4){+...}, at: bond_enslave+0x4482/0x47b0 [bonding] [ 29.554175][ T1046] [ 29.554175][ T1046] stack backtrace: [ 29.554907][ T1046] CPU: 0 PID: 1046 Comm: ifenslave Not tainted 5.5.0+ #322 [ 29.555854][ T1046] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 29.557064][ T1046] Call Trace: [ 29.557504][ T1046] dump_stack+0x96/0xdb [ 29.558054][ T1046] check_noncircular+0x371/0x450 [ 29.558723][ T1046] ? print_circular_bug.isra.35+0x310/0x310 [ 29.559486][ T1046] ? hlock_class+0x130/0x130 [ 29.560100][ T1046] ? __lock_acquire+0x2d8d/0x3de0 [ 29.560761][ T1046] __lock_acquire+0x2d8d/0x3de0 [ 29.561366][ T1046] ? register_lock_class+0x14d0/0x14d0 [ 29.562045][ T1046] ? find_held_lock+0x39/0x1d0 [ 29.562641][ T1046] lock_acquire+0x164/0x3b0 [ 29.563199][ T1046] ? dev_mc_sync_multiple+0x95/0x120 [ 29.563872][ T1046] _raw_spin_lock+0x30/0x70 [ 29.564464][ T1046] ? dev_mc_sync_multiple+0x95/0x120 [ 29.565146][ T1046] dev_mc_sync_multiple+0x95/0x120 [ 29.565793][ T1046] bond_enslave+0x448d/0x47b0 [bonding] [ 29.566487][ T1046] ? bond_update_slave_arr+0x940/0x940 [bonding] [ 29.567279][ T1046] ? bstr_printf+0xc20/0xc20 [ 29.567857][ T1046] ? stack_trace_consume_entry+0x160/0x160 [ 29.568614][ T1046] ? deactivate_slab.isra.77+0x2c5/0x800 [ 29.569320][ T1046] ? check_chain_key+0x236/0x5d0 [ 29.569939][ T1046] ? sscanf+0x93/0xc0 [ 29.570442][ T1046] ? vsscanf+0x1e20/0x1e20 [ 29.571003][ T1046] bond_option_slaves_set+0x1a3/0x370 [bonding] [ ... ] Fixes: ab92d68 ("net: core: add generic lockdep keys") Signed-off-by: Taehee Yoo <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
jackpot51
referenced
this pull request
in pop-os/linux
Mar 16, 2020
BugLink: https://bugs.launchpad.net/bugs/1867051 [ Upstream commit 6fb8852 ] When netdevsim dev is being created, a debugfs directory is created. The variable "dev_ddir_name" is 16bytes device name pointer and device name is "netdevsim<dev id>". The maximum dev id length is 10. So, 16bytes for device name isn't enough. Test commands: modprobe netdevsim echo "1000000000 0" > /sys/bus/netdevsim/new_device Splat looks like: [ 249.622710][ T900] BUG: KASAN: stack-out-of-bounds in number+0x824/0x880 [ 249.623658][ T900] Write of size 1 at addr ffff88804c527988 by task bash/900 [ 249.624521][ T900] [ 249.624830][ T900] CPU: 1 PID: 900 Comm: bash Not tainted 5.5.0+ #322 [ 249.625691][ T900] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 249.626712][ T900] Call Trace: [ 249.627103][ T900] dump_stack+0x96/0xdb [ 249.627639][ T900] ? number+0x824/0x880 [ 249.628173][ T900] print_address_description.constprop.5+0x1be/0x360 [ 249.629022][ T900] ? number+0x824/0x880 [ 249.629569][ T900] ? number+0x824/0x880 [ 249.630105][ T900] __kasan_report+0x12a/0x170 [ 249.630717][ T900] ? number+0x824/0x880 [ 249.631201][ T900] kasan_report+0xe/0x20 [ 249.631723][ T900] number+0x824/0x880 [ 249.632235][ T900] ? put_dec+0xa0/0xa0 [ 249.632716][ T900] ? rcu_read_lock_sched_held+0x90/0xc0 [ 249.633392][ T900] vsnprintf+0x63c/0x10b0 [ 249.633983][ T900] ? pointer+0x5b0/0x5b0 [ 249.634543][ T900] ? mark_lock+0x11d/0xc40 [ 249.635200][ T900] sprintf+0x9b/0xd0 [ 249.635750][ T900] ? scnprintf+0xe0/0xe0 [ 249.636370][ T900] nsim_dev_probe+0x63c/0xbf0 [netdevsim] [ ... ] Reviewed-by: Jakub Kicinski <[email protected]> Fixes: ab1d0cc ("netdevsim: change debugfs tree topology") Signed-off-by: Taehee Yoo <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Kamal Mostafa <[email protected]> Signed-off-by: Khalid Elmously <[email protected]>
jackpot51
referenced
this pull request
in pop-os/linux
Apr 13, 2020
BugLink: https://bugs.launchpad.net/bugs/1867051 [ Upstream commit 6fb8852 ] When netdevsim dev is being created, a debugfs directory is created. The variable "dev_ddir_name" is 16bytes device name pointer and device name is "netdevsim<dev id>". The maximum dev id length is 10. So, 16bytes for device name isn't enough. Test commands: modprobe netdevsim echo "1000000000 0" > /sys/bus/netdevsim/new_device Splat looks like: [ 249.622710][ T900] BUG: KASAN: stack-out-of-bounds in number+0x824/0x880 [ 249.623658][ T900] Write of size 1 at addr ffff88804c527988 by task bash/900 [ 249.624521][ T900] [ 249.624830][ T900] CPU: 1 PID: 900 Comm: bash Not tainted 5.5.0+ #322 [ 249.625691][ T900] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 249.626712][ T900] Call Trace: [ 249.627103][ T900] dump_stack+0x96/0xdb [ 249.627639][ T900] ? number+0x824/0x880 [ 249.628173][ T900] print_address_description.constprop.5+0x1be/0x360 [ 249.629022][ T900] ? number+0x824/0x880 [ 249.629569][ T900] ? number+0x824/0x880 [ 249.630105][ T900] __kasan_report+0x12a/0x170 [ 249.630717][ T900] ? number+0x824/0x880 [ 249.631201][ T900] kasan_report+0xe/0x20 [ 249.631723][ T900] number+0x824/0x880 [ 249.632235][ T900] ? put_dec+0xa0/0xa0 [ 249.632716][ T900] ? rcu_read_lock_sched_held+0x90/0xc0 [ 249.633392][ T900] vsnprintf+0x63c/0x10b0 [ 249.633983][ T900] ? pointer+0x5b0/0x5b0 [ 249.634543][ T900] ? mark_lock+0x11d/0xc40 [ 249.635200][ T900] sprintf+0x9b/0xd0 [ 249.635750][ T900] ? scnprintf+0xe0/0xe0 [ 249.636370][ T900] nsim_dev_probe+0x63c/0xbf0 [netdevsim] [ ... ] Reviewed-by: Jakub Kicinski <[email protected]> Fixes: ab1d0cc ("netdevsim: change debugfs tree topology") Signed-off-by: Taehee Yoo <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Kamal Mostafa <[email protected]> Signed-off-by: Khalid Elmously <[email protected]>
metux
added a commit
to metux/linux
that referenced
this pull request
Feb 4, 2021
Fix checkpatch warnings: WARNING: line over 80 characters torvalds#9: FILE: drivers/tty/serial/apbuart.c:9: + * Copyright (C) 2006 Daniel Hellstrom <[email protected]>, Aeroflex Gaisler AB WARNING: line over 80 characters torvalds#11: FILE: drivers/tty/serial/apbuart.c:11: + * Copyright (C) 2009 Kristoffer Glembo <[email protected]>, Aeroflex Gaisler AB WARNING: line over 80 characters torvalds#16: FILE: drivers/tty/serial/apbuart.c:16: +#if defined(CONFIG_SERIAL_GRLIB_GAISLER_APBUART_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) WARNING: labels should not be indented torvalds#122: FILE: drivers/tty/serial/apbuart.c:122: + ignore_char: WARNING: Missing a blank line after declarations torvalds#186: FILE: drivers/tty/serial/apbuart.c:186: + unsigned int status = UART_GET_STATUS(port); + return status & UART_STATUS_THE ? TIOCSER_TEMT : 0; WARNING: Missing a blank line after declarations torvalds#322: FILE: drivers/tty/serial/apbuart.c:322: + int ret = 0; + if (ser->type != PORT_UNKNOWN && ser->type != PORT_APBUART) WARNING: Missing a blank line after declarations torvalds#427: FILE: drivers/tty/serial/apbuart.c:427: + unsigned int status; + do { WARNING: Missing a blank line after declarations torvalds#463: FILE: drivers/tty/serial/apbuart.c:463: + unsigned int quot, status; + status = UART_GET_STATUS(port); WARNING: line over 80 characters torvalds#627: FILE: drivers/tty/serial/apbuart.c:627: + port->membase = ioremap(addr, sizeof(struct grlib_apbuart_regs_map)); WARNING: line over 80 characters torvalds#634: FILE: drivers/tty/serial/apbuart.c:634: + port->fifosize = apbuart_scan_fifo_size((struct uart_port *) port, line); Signed-off-by: Enrico Weigelt <[email protected]>
metux
added a commit
to metux/linux
that referenced
this pull request
Feb 7, 2021
Fix checkpatch warnings: WARNING: line over 80 characters torvalds#9: FILE: drivers/tty/serial/apbuart.c:9: + * Copyright (C) 2006 Daniel Hellstrom <[email protected]>, Aeroflex Gaisler AB WARNING: line over 80 characters torvalds#11: FILE: drivers/tty/serial/apbuart.c:11: + * Copyright (C) 2009 Kristoffer Glembo <[email protected]>, Aeroflex Gaisler AB WARNING: line over 80 characters torvalds#16: FILE: drivers/tty/serial/apbuart.c:16: +#if defined(CONFIG_SERIAL_GRLIB_GAISLER_APBUART_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) WARNING: labels should not be indented torvalds#122: FILE: drivers/tty/serial/apbuart.c:122: + ignore_char: WARNING: Missing a blank line after declarations torvalds#186: FILE: drivers/tty/serial/apbuart.c:186: + unsigned int status = UART_GET_STATUS(port); + return status & UART_STATUS_THE ? TIOCSER_TEMT : 0; WARNING: Missing a blank line after declarations torvalds#322: FILE: drivers/tty/serial/apbuart.c:322: + int ret = 0; + if (ser->type != PORT_UNKNOWN && ser->type != PORT_APBUART) WARNING: Missing a blank line after declarations torvalds#427: FILE: drivers/tty/serial/apbuart.c:427: + unsigned int status; + do { WARNING: Missing a blank line after declarations torvalds#463: FILE: drivers/tty/serial/apbuart.c:463: + unsigned int quot, status; + status = UART_GET_STATUS(port); WARNING: line over 80 characters torvalds#627: FILE: drivers/tty/serial/apbuart.c:627: + port->membase = ioremap(addr, sizeof(struct grlib_apbuart_regs_map)); WARNING: line over 80 characters torvalds#634: FILE: drivers/tty/serial/apbuart.c:634: + port->fifosize = apbuart_scan_fifo_size((struct uart_port *) port, line); Signed-off-by: Enrico Weigelt <[email protected]>
metux
added a commit
to metux/linux
that referenced
this pull request
Feb 7, 2021
Fix checkpatch warnings: WARNING: line over 80 characters torvalds#9: FILE: drivers/tty/serial/apbuart.c:9: + * Copyright (C) 2006 Daniel Hellstrom <[email protected]>, Aeroflex Gaisler AB WARNING: line over 80 characters torvalds#11: FILE: drivers/tty/serial/apbuart.c:11: + * Copyright (C) 2009 Kristoffer Glembo <[email protected]>, Aeroflex Gaisler AB WARNING: line over 80 characters torvalds#16: FILE: drivers/tty/serial/apbuart.c:16: +#if defined(CONFIG_SERIAL_GRLIB_GAISLER_APBUART_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) WARNING: labels should not be indented torvalds#122: FILE: drivers/tty/serial/apbuart.c:122: + ignore_char: WARNING: Missing a blank line after declarations torvalds#186: FILE: drivers/tty/serial/apbuart.c:186: + unsigned int status = UART_GET_STATUS(port); + return status & UART_STATUS_THE ? TIOCSER_TEMT : 0; WARNING: Missing a blank line after declarations torvalds#322: FILE: drivers/tty/serial/apbuart.c:322: + int ret = 0; + if (ser->type != PORT_UNKNOWN && ser->type != PORT_APBUART) WARNING: Missing a blank line after declarations torvalds#427: FILE: drivers/tty/serial/apbuart.c:427: + unsigned int status; + do { WARNING: Missing a blank line after declarations torvalds#463: FILE: drivers/tty/serial/apbuart.c:463: + unsigned int quot, status; + status = UART_GET_STATUS(port); WARNING: line over 80 characters torvalds#627: FILE: drivers/tty/serial/apbuart.c:627: + port->membase = ioremap(addr, sizeof(struct grlib_apbuart_regs_map)); WARNING: line over 80 characters torvalds#634: FILE: drivers/tty/serial/apbuart.c:634: + port->fifosize = apbuart_scan_fifo_size((struct uart_port *) port, line); Signed-off-by: Enrico Weigelt <[email protected]>
metux
added a commit
to metux/linux
that referenced
this pull request
Feb 8, 2021
Fix checkpatch warnings: WARNING: line over 80 characters torvalds#9: FILE: drivers/tty/serial/apbuart.c:9: + * Copyright (C) 2006 Daniel Hellstrom <[email protected]>, Aeroflex Gaisler AB WARNING: line over 80 characters torvalds#11: FILE: drivers/tty/serial/apbuart.c:11: + * Copyright (C) 2009 Kristoffer Glembo <[email protected]>, Aeroflex Gaisler AB WARNING: line over 80 characters torvalds#16: FILE: drivers/tty/serial/apbuart.c:16: +#if defined(CONFIG_SERIAL_GRLIB_GAISLER_APBUART_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) WARNING: labels should not be indented torvalds#122: FILE: drivers/tty/serial/apbuart.c:122: + ignore_char: WARNING: Missing a blank line after declarations torvalds#186: FILE: drivers/tty/serial/apbuart.c:186: + unsigned int status = UART_GET_STATUS(port); + return status & UART_STATUS_THE ? TIOCSER_TEMT : 0; WARNING: Missing a blank line after declarations torvalds#322: FILE: drivers/tty/serial/apbuart.c:322: + int ret = 0; + if (ser->type != PORT_UNKNOWN && ser->type != PORT_APBUART) WARNING: Missing a blank line after declarations torvalds#427: FILE: drivers/tty/serial/apbuart.c:427: + unsigned int status; + do { WARNING: Missing a blank line after declarations torvalds#463: FILE: drivers/tty/serial/apbuart.c:463: + unsigned int quot, status; + status = UART_GET_STATUS(port); WARNING: line over 80 characters torvalds#627: FILE: drivers/tty/serial/apbuart.c:627: + port->membase = ioremap(addr, sizeof(struct grlib_apbuart_regs_map)); WARNING: line over 80 characters torvalds#634: FILE: drivers/tty/serial/apbuart.c:634: + port->fifosize = apbuart_scan_fifo_size((struct uart_port *) port, line); Signed-off-by: Enrico Weigelt <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Apr 8, 2021
…format For incoming SCO connection with transparent coding format, alt setting of CVSD is getting applied instead of Transparent. Before fix: < HCI Command: Accept Synchron.. (0x01|0x0029) plen 21 #2196 [hci0] 321.342548 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Transmit bandwidth: 8000 Receive bandwidth: 8000 Max latency: 13 Setting: 0x0003 Input Coding: Linear Input Data Format: 1's complement Input Sample Size: 8-bit # of bits padding at MSB: 0 Air Coding Format: Transparent Data Retransmission effort: Optimize for link quality (0x02) Packet type: 0x003f HV1 may be used HV2 may be used HV3 may be used EV3 may be used EV4 may be used EV5 may be used > HCI Event: Command Status (0x0f) plen 4 #2197 [hci0] 321.343585 Accept Synchronous Connection Request (0x01|0x0029) ncmd 1 Status: Success (0x00) > HCI Event: Synchronous Connect Comp.. (0x2c) plen 17 #2198 [hci0] 321.351666 Status: Success (0x00) Handle: 257 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Link type: eSCO (0x02) Transmission interval: 0x0c Retransmission window: 0x04 RX packet length: 60 TX packet length: 60 Air mode: Transparent (0x03) ........ > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2336 [hci0] 321.383655 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2337 [hci0] 321.389558 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2338 [hci0] 321.393615 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2339 [hci0] 321.393618 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2340 [hci0] 321.393618 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2341 [hci0] 321.397070 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2342 [hci0] 321.403622 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2343 [hci0] 321.403625 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2344 [hci0] 321.403625 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2345 [hci0] 321.403625 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2346 [hci0] 321.404569 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2347 [hci0] 321.412091 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2348 [hci0] 321.413626 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2349 [hci0] 321.413630 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2350 [hci0] 321.413630 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2351 [hci0] 321.419674 After fix: < HCI Command: Accept Synchronou.. (0x01|0x0029) plen 21 torvalds#309 [hci0] 49.439693 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Transmit bandwidth: 8000 Receive bandwidth: 8000 Max latency: 13 Setting: 0x0003 Input Coding: Linear Input Data Format: 1's complement Input Sample Size: 8-bit # of bits padding at MSB: 0 Air Coding Format: Transparent Data Retransmission effort: Optimize for link quality (0x02) Packet type: 0x003f HV1 may be used HV2 may be used HV3 may be used EV3 may be used EV4 may be used EV5 may be used > HCI Event: Command Status (0x0f) plen 4 torvalds#310 [hci0] 49.440308 Accept Synchronous Connection Request (0x01|0x0029) ncmd 1 Status: Success (0x00) > HCI Event: Synchronous Connect Complete (0x2c) plen 17 torvalds#311 [hci0] 49.449308 Status: Success (0x00) Handle: 257 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Link type: eSCO (0x02) Transmission interval: 0x0c Retransmission window: 0x04 RX packet length: 60 TX packet length: 60 Air mode: Transparent (0x03) < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#312 [hci0] 49.450421 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#313 [hci0] 49.457927 > HCI Event: Max Slots Change (0x1b) plen 3 torvalds#314 [hci0] 49.460345 Handle: 256 Max slots: 5 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#315 [hci0] 49.465453 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#316 [hci0] 49.470502 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#317 [hci0] 49.470519 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#318 [hci0] 49.472996 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#319 [hci0] 49.480412 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#320 [hci0] 49.480492 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#321 [hci0] 49.487989 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#322 [hci0] 49.490303 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#323 [hci0] 49.495496 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#324 [hci0] 49.500304 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#325 [hci0] 49.500311 Signed-off-by: Kiran K <[email protected]> Signed-off-by: Lokendra Singh <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
May 7, 2021
…format For incoming SCO connection with transparent coding format, alt setting of CVSD is getting applied instead of Transparent. Before fix: < HCI Command: Accept Synchron.. (0x01|0x0029) plen 21 #2196 [hci0] 321.342548 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Transmit bandwidth: 8000 Receive bandwidth: 8000 Max latency: 13 Setting: 0x0003 Input Coding: Linear Input Data Format: 1's complement Input Sample Size: 8-bit # of bits padding at MSB: 0 Air Coding Format: Transparent Data Retransmission effort: Optimize for link quality (0x02) Packet type: 0x003f HV1 may be used HV2 may be used HV3 may be used EV3 may be used EV4 may be used EV5 may be used > HCI Event: Command Status (0x0f) plen 4 #2197 [hci0] 321.343585 Accept Synchronous Connection Request (0x01|0x0029) ncmd 1 Status: Success (0x00) > HCI Event: Synchronous Connect Comp.. (0x2c) plen 17 #2198 [hci0] 321.351666 Status: Success (0x00) Handle: 257 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Link type: eSCO (0x02) Transmission interval: 0x0c Retransmission window: 0x04 RX packet length: 60 TX packet length: 60 Air mode: Transparent (0x03) ........ > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2336 [hci0] 321.383655 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2337 [hci0] 321.389558 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2338 [hci0] 321.393615 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2339 [hci0] 321.393618 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2340 [hci0] 321.393618 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2341 [hci0] 321.397070 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2342 [hci0] 321.403622 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2343 [hci0] 321.403625 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2344 [hci0] 321.403625 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2345 [hci0] 321.403625 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2346 [hci0] 321.404569 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2347 [hci0] 321.412091 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2348 [hci0] 321.413626 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2349 [hci0] 321.413630 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2350 [hci0] 321.413630 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2351 [hci0] 321.419674 After fix: < HCI Command: Accept Synchronou.. (0x01|0x0029) plen 21 torvalds#309 [hci0] 49.439693 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Transmit bandwidth: 8000 Receive bandwidth: 8000 Max latency: 13 Setting: 0x0003 Input Coding: Linear Input Data Format: 1's complement Input Sample Size: 8-bit # of bits padding at MSB: 0 Air Coding Format: Transparent Data Retransmission effort: Optimize for link quality (0x02) Packet type: 0x003f HV1 may be used HV2 may be used HV3 may be used EV3 may be used EV4 may be used EV5 may be used > HCI Event: Command Status (0x0f) plen 4 torvalds#310 [hci0] 49.440308 Accept Synchronous Connection Request (0x01|0x0029) ncmd 1 Status: Success (0x00) > HCI Event: Synchronous Connect Complete (0x2c) plen 17 torvalds#311 [hci0] 49.449308 Status: Success (0x00) Handle: 257 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Link type: eSCO (0x02) Transmission interval: 0x0c Retransmission window: 0x04 RX packet length: 60 TX packet length: 60 Air mode: Transparent (0x03) < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#312 [hci0] 49.450421 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#313 [hci0] 49.457927 > HCI Event: Max Slots Change (0x1b) plen 3 torvalds#314 [hci0] 49.460345 Handle: 256 Max slots: 5 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#315 [hci0] 49.465453 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#316 [hci0] 49.470502 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#317 [hci0] 49.470519 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#318 [hci0] 49.472996 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#319 [hci0] 49.480412 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#320 [hci0] 49.480492 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#321 [hci0] 49.487989 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#322 [hci0] 49.490303 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#323 [hci0] 49.495496 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#324 [hci0] 49.500304 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#325 [hci0] 49.500311 Signed-off-by: Kiran K <[email protected]> Signed-off-by: Lokendra Singh <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
roxell
pushed a commit
to roxell/linux
that referenced
this pull request
May 10, 2021
…format For incoming SCO connection with transparent coding format, alt setting of CVSD is getting applied instead of Transparent. Before fix: < HCI Command: Accept Synchron.. (0x01|0x0029) plen 21 #2196 [hci0] 321.342548 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Transmit bandwidth: 8000 Receive bandwidth: 8000 Max latency: 13 Setting: 0x0003 Input Coding: Linear Input Data Format: 1's complement Input Sample Size: 8-bit # of bits padding at MSB: 0 Air Coding Format: Transparent Data Retransmission effort: Optimize for link quality (0x02) Packet type: 0x003f HV1 may be used HV2 may be used HV3 may be used EV3 may be used EV4 may be used EV5 may be used > HCI Event: Command Status (0x0f) plen 4 #2197 [hci0] 321.343585 Accept Synchronous Connection Request (0x01|0x0029) ncmd 1 Status: Success (0x00) > HCI Event: Synchronous Connect Comp.. (0x2c) plen 17 #2198 [hci0] 321.351666 Status: Success (0x00) Handle: 257 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Link type: eSCO (0x02) Transmission interval: 0x0c Retransmission window: 0x04 RX packet length: 60 TX packet length: 60 Air mode: Transparent (0x03) ........ > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2336 [hci0] 321.383655 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2337 [hci0] 321.389558 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2338 [hci0] 321.393615 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2339 [hci0] 321.393618 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2340 [hci0] 321.393618 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2341 [hci0] 321.397070 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2342 [hci0] 321.403622 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2343 [hci0] 321.403625 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2344 [hci0] 321.403625 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2345 [hci0] 321.403625 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2346 [hci0] 321.404569 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2347 [hci0] 321.412091 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2348 [hci0] 321.413626 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2349 [hci0] 321.413630 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2350 [hci0] 321.413630 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2351 [hci0] 321.419674 After fix: < HCI Command: Accept Synchronou.. (0x01|0x0029) plen 21 torvalds#309 [hci0] 49.439693 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Transmit bandwidth: 8000 Receive bandwidth: 8000 Max latency: 13 Setting: 0x0003 Input Coding: Linear Input Data Format: 1's complement Input Sample Size: 8-bit # of bits padding at MSB: 0 Air Coding Format: Transparent Data Retransmission effort: Optimize for link quality (0x02) Packet type: 0x003f HV1 may be used HV2 may be used HV3 may be used EV3 may be used EV4 may be used EV5 may be used > HCI Event: Command Status (0x0f) plen 4 torvalds#310 [hci0] 49.440308 Accept Synchronous Connection Request (0x01|0x0029) ncmd 1 Status: Success (0x00) > HCI Event: Synchronous Connect Complete (0x2c) plen 17 torvalds#311 [hci0] 49.449308 Status: Success (0x00) Handle: 257 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Link type: eSCO (0x02) Transmission interval: 0x0c Retransmission window: 0x04 RX packet length: 60 TX packet length: 60 Air mode: Transparent (0x03) < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#312 [hci0] 49.450421 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#313 [hci0] 49.457927 > HCI Event: Max Slots Change (0x1b) plen 3 torvalds#314 [hci0] 49.460345 Handle: 256 Max slots: 5 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#315 [hci0] 49.465453 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#316 [hci0] 49.470502 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#317 [hci0] 49.470519 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#318 [hci0] 49.472996 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#319 [hci0] 49.480412 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#320 [hci0] 49.480492 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#321 [hci0] 49.487989 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#322 [hci0] 49.490303 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#323 [hci0] 49.495496 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#324 [hci0] 49.500304 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#325 [hci0] 49.500311 Signed-off-by: Kiran K <[email protected]> Signed-off-by: Lokendra Singh <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jun 28, 2021
…format For incoming SCO connection with transparent coding format, alt setting of CVSD is getting applied instead of Transparent. Before fix: < HCI Command: Accept Synchron.. (0x01|0x0029) plen 21 #2196 [hci0] 321.342548 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Transmit bandwidth: 8000 Receive bandwidth: 8000 Max latency: 13 Setting: 0x0003 Input Coding: Linear Input Data Format: 1's complement Input Sample Size: 8-bit # of bits padding at MSB: 0 Air Coding Format: Transparent Data Retransmission effort: Optimize for link quality (0x02) Packet type: 0x003f HV1 may be used HV2 may be used HV3 may be used EV3 may be used EV4 may be used EV5 may be used > HCI Event: Command Status (0x0f) plen 4 #2197 [hci0] 321.343585 Accept Synchronous Connection Request (0x01|0x0029) ncmd 1 Status: Success (0x00) > HCI Event: Synchronous Connect Comp.. (0x2c) plen 17 #2198 [hci0] 321.351666 Status: Success (0x00) Handle: 257 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Link type: eSCO (0x02) Transmission interval: 0x0c Retransmission window: 0x04 RX packet length: 60 TX packet length: 60 Air mode: Transparent (0x03) ........ > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2336 [hci0] 321.383655 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2337 [hci0] 321.389558 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2338 [hci0] 321.393615 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2339 [hci0] 321.393618 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2340 [hci0] 321.393618 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2341 [hci0] 321.397070 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2342 [hci0] 321.403622 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2343 [hci0] 321.403625 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2344 [hci0] 321.403625 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2345 [hci0] 321.403625 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2346 [hci0] 321.404569 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2347 [hci0] 321.412091 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2348 [hci0] 321.413626 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2349 [hci0] 321.413630 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2350 [hci0] 321.413630 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2351 [hci0] 321.419674 After fix: < HCI Command: Accept Synchronou.. (0x01|0x0029) plen 21 torvalds#309 [hci0] 49.439693 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Transmit bandwidth: 8000 Receive bandwidth: 8000 Max latency: 13 Setting: 0x0003 Input Coding: Linear Input Data Format: 1's complement Input Sample Size: 8-bit # of bits padding at MSB: 0 Air Coding Format: Transparent Data Retransmission effort: Optimize for link quality (0x02) Packet type: 0x003f HV1 may be used HV2 may be used HV3 may be used EV3 may be used EV4 may be used EV5 may be used > HCI Event: Command Status (0x0f) plen 4 torvalds#310 [hci0] 49.440308 Accept Synchronous Connection Request (0x01|0x0029) ncmd 1 Status: Success (0x00) > HCI Event: Synchronous Connect Complete (0x2c) plen 17 torvalds#311 [hci0] 49.449308 Status: Success (0x00) Handle: 257 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Link type: eSCO (0x02) Transmission interval: 0x0c Retransmission window: 0x04 RX packet length: 60 TX packet length: 60 Air mode: Transparent (0x03) < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#312 [hci0] 49.450421 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#313 [hci0] 49.457927 > HCI Event: Max Slots Change (0x1b) plen 3 torvalds#314 [hci0] 49.460345 Handle: 256 Max slots: 5 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#315 [hci0] 49.465453 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#316 [hci0] 49.470502 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#317 [hci0] 49.470519 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#318 [hci0] 49.472996 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#319 [hci0] 49.480412 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#320 [hci0] 49.480492 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#321 [hci0] 49.487989 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#322 [hci0] 49.490303 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#323 [hci0] 49.495496 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#324 [hci0] 49.500304 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#325 [hci0] 49.500311 Signed-off-by: Kiran K <[email protected]> Signed-off-by: Lokendra Singh <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
intersectRaven
pushed a commit
to intersectRaven/linux
that referenced
this pull request
Jul 19, 2021
…format [ Upstream commit 06d213d ] For incoming SCO connection with transparent coding format, alt setting of CVSD is getting applied instead of Transparent. Before fix: < HCI Command: Accept Synchron.. (0x01|0x0029) plen 21 #2196 [hci0] 321.342548 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Transmit bandwidth: 8000 Receive bandwidth: 8000 Max latency: 13 Setting: 0x0003 Input Coding: Linear Input Data Format: 1's complement Input Sample Size: 8-bit # of bits padding at MSB: 0 Air Coding Format: Transparent Data Retransmission effort: Optimize for link quality (0x02) Packet type: 0x003f HV1 may be used HV2 may be used HV3 may be used EV3 may be used EV4 may be used EV5 may be used > HCI Event: Command Status (0x0f) plen 4 #2197 [hci0] 321.343585 Accept Synchronous Connection Request (0x01|0x0029) ncmd 1 Status: Success (0x00) > HCI Event: Synchronous Connect Comp.. (0x2c) plen 17 #2198 [hci0] 321.351666 Status: Success (0x00) Handle: 257 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Link type: eSCO (0x02) Transmission interval: 0x0c Retransmission window: 0x04 RX packet length: 60 TX packet length: 60 Air mode: Transparent (0x03) ........ > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2336 [hci0] 321.383655 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2337 [hci0] 321.389558 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2338 [hci0] 321.393615 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2339 [hci0] 321.393618 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2340 [hci0] 321.393618 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2341 [hci0] 321.397070 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2342 [hci0] 321.403622 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2343 [hci0] 321.403625 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2344 [hci0] 321.403625 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2345 [hci0] 321.403625 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2346 [hci0] 321.404569 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2347 [hci0] 321.412091 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2348 [hci0] 321.413626 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2349 [hci0] 321.413630 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2350 [hci0] 321.413630 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2351 [hci0] 321.419674 After fix: < HCI Command: Accept Synchronou.. (0x01|0x0029) plen 21 torvalds#309 [hci0] 49.439693 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Transmit bandwidth: 8000 Receive bandwidth: 8000 Max latency: 13 Setting: 0x0003 Input Coding: Linear Input Data Format: 1's complement Input Sample Size: 8-bit # of bits padding at MSB: 0 Air Coding Format: Transparent Data Retransmission effort: Optimize for link quality (0x02) Packet type: 0x003f HV1 may be used HV2 may be used HV3 may be used EV3 may be used EV4 may be used EV5 may be used > HCI Event: Command Status (0x0f) plen 4 torvalds#310 [hci0] 49.440308 Accept Synchronous Connection Request (0x01|0x0029) ncmd 1 Status: Success (0x00) > HCI Event: Synchronous Connect Complete (0x2c) plen 17 torvalds#311 [hci0] 49.449308 Status: Success (0x00) Handle: 257 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Link type: eSCO (0x02) Transmission interval: 0x0c Retransmission window: 0x04 RX packet length: 60 TX packet length: 60 Air mode: Transparent (0x03) < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#312 [hci0] 49.450421 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#313 [hci0] 49.457927 > HCI Event: Max Slots Change (0x1b) plen 3 torvalds#314 [hci0] 49.460345 Handle: 256 Max slots: 5 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#315 [hci0] 49.465453 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#316 [hci0] 49.470502 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#317 [hci0] 49.470519 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#318 [hci0] 49.472996 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#319 [hci0] 49.480412 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#320 [hci0] 49.480492 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#321 [hci0] 49.487989 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#322 [hci0] 49.490303 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#323 [hci0] 49.495496 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#324 [hci0] 49.500304 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#325 [hci0] 49.500311 Signed-off-by: Kiran K <[email protected]> Signed-off-by: Lokendra Singh <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
damentz
referenced
this pull request
in zen-kernel/zen-kernel
Jul 19, 2021
…format [ Upstream commit 06d213d ] For incoming SCO connection with transparent coding format, alt setting of CVSD is getting applied instead of Transparent. Before fix: < HCI Command: Accept Synchron.. (0x01|0x0029) plen 21 #2196 [hci0] 321.342548 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Transmit bandwidth: 8000 Receive bandwidth: 8000 Max latency: 13 Setting: 0x0003 Input Coding: Linear Input Data Format: 1's complement Input Sample Size: 8-bit # of bits padding at MSB: 0 Air Coding Format: Transparent Data Retransmission effort: Optimize for link quality (0x02) Packet type: 0x003f HV1 may be used HV2 may be used HV3 may be used EV3 may be used EV4 may be used EV5 may be used > HCI Event: Command Status (0x0f) plen 4 #2197 [hci0] 321.343585 Accept Synchronous Connection Request (0x01|0x0029) ncmd 1 Status: Success (0x00) > HCI Event: Synchronous Connect Comp.. (0x2c) plen 17 #2198 [hci0] 321.351666 Status: Success (0x00) Handle: 257 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Link type: eSCO (0x02) Transmission interval: 0x0c Retransmission window: 0x04 RX packet length: 60 TX packet length: 60 Air mode: Transparent (0x03) ........ > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2336 [hci0] 321.383655 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2337 [hci0] 321.389558 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2338 [hci0] 321.393615 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2339 [hci0] 321.393618 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2340 [hci0] 321.393618 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2341 [hci0] 321.397070 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2342 [hci0] 321.403622 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2343 [hci0] 321.403625 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2344 [hci0] 321.403625 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2345 [hci0] 321.403625 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2346 [hci0] 321.404569 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2347 [hci0] 321.412091 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2348 [hci0] 321.413626 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2349 [hci0] 321.413630 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2350 [hci0] 321.413630 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2351 [hci0] 321.419674 After fix: < HCI Command: Accept Synchronou.. (0x01|0x0029) plen 21 #309 [hci0] 49.439693 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Transmit bandwidth: 8000 Receive bandwidth: 8000 Max latency: 13 Setting: 0x0003 Input Coding: Linear Input Data Format: 1's complement Input Sample Size: 8-bit # of bits padding at MSB: 0 Air Coding Format: Transparent Data Retransmission effort: Optimize for link quality (0x02) Packet type: 0x003f HV1 may be used HV2 may be used HV3 may be used EV3 may be used EV4 may be used EV5 may be used > HCI Event: Command Status (0x0f) plen 4 #310 [hci0] 49.440308 Accept Synchronous Connection Request (0x01|0x0029) ncmd 1 Status: Success (0x00) > HCI Event: Synchronous Connect Complete (0x2c) plen 17 #311 [hci0] 49.449308 Status: Success (0x00) Handle: 257 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Link type: eSCO (0x02) Transmission interval: 0x0c Retransmission window: 0x04 RX packet length: 60 TX packet length: 60 Air mode: Transparent (0x03) < SCO Data TX: Handle 257 flags 0x00 dlen 60 #312 [hci0] 49.450421 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #313 [hci0] 49.457927 > HCI Event: Max Slots Change (0x1b) plen 3 #314 [hci0] 49.460345 Handle: 256 Max slots: 5 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #315 [hci0] 49.465453 > SCO Data RX: Handle 257 flags 0x00 dlen 60 #316 [hci0] 49.470502 > SCO Data RX: Handle 257 flags 0x00 dlen 60 #317 [hci0] 49.470519 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #318 [hci0] 49.472996 > SCO Data RX: Handle 257 flags 0x00 dlen 60 #319 [hci0] 49.480412 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #320 [hci0] 49.480492 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #321 [hci0] 49.487989 > SCO Data RX: Handle 257 flags 0x00 dlen 60 #322 [hci0] 49.490303 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #323 [hci0] 49.495496 > SCO Data RX: Handle 257 flags 0x00 dlen 60 #324 [hci0] 49.500304 > SCO Data RX: Handle 257 flags 0x00 dlen 60 #325 [hci0] 49.500311 Signed-off-by: Kiran K <[email protected]> Signed-off-by: Lokendra Singh <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
repojohnray
pushed a commit
to repojohnray/linux-sunxi-4.7.y
that referenced
this pull request
Jul 19, 2021
…format [ Upstream commit 06d213d ] For incoming SCO connection with transparent coding format, alt setting of CVSD is getting applied instead of Transparent. Before fix: < HCI Command: Accept Synchron.. (0x01|0x0029) plen 21 #2196 [hci0] 321.342548 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Transmit bandwidth: 8000 Receive bandwidth: 8000 Max latency: 13 Setting: 0x0003 Input Coding: Linear Input Data Format: 1's complement Input Sample Size: 8-bit # of bits padding at MSB: 0 Air Coding Format: Transparent Data Retransmission effort: Optimize for link quality (0x02) Packet type: 0x003f HV1 may be used HV2 may be used HV3 may be used EV3 may be used EV4 may be used EV5 may be used > HCI Event: Command Status (0x0f) plen 4 #2197 [hci0] 321.343585 Accept Synchronous Connection Request (0x01|0x0029) ncmd 1 Status: Success (0x00) > HCI Event: Synchronous Connect Comp.. (0x2c) plen 17 #2198 [hci0] 321.351666 Status: Success (0x00) Handle: 257 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Link type: eSCO (0x02) Transmission interval: 0x0c Retransmission window: 0x04 RX packet length: 60 TX packet length: 60 Air mode: Transparent (0x03) ........ > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2336 [hci0] 321.383655 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2337 [hci0] 321.389558 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2338 [hci0] 321.393615 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2339 [hci0] 321.393618 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2340 [hci0] 321.393618 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2341 [hci0] 321.397070 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2342 [hci0] 321.403622 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2343 [hci0] 321.403625 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2344 [hci0] 321.403625 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2345 [hci0] 321.403625 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2346 [hci0] 321.404569 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2347 [hci0] 321.412091 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2348 [hci0] 321.413626 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2349 [hci0] 321.413630 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2350 [hci0] 321.413630 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2351 [hci0] 321.419674 After fix: < HCI Command: Accept Synchronou.. (0x01|0x0029) plen 21 linux-sunxi#309 [hci0] 49.439693 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Transmit bandwidth: 8000 Receive bandwidth: 8000 Max latency: 13 Setting: 0x0003 Input Coding: Linear Input Data Format: 1's complement Input Sample Size: 8-bit # of bits padding at MSB: 0 Air Coding Format: Transparent Data Retransmission effort: Optimize for link quality (0x02) Packet type: 0x003f HV1 may be used HV2 may be used HV3 may be used EV3 may be used EV4 may be used EV5 may be used > HCI Event: Command Status (0x0f) plen 4 torvalds#310 [hci0] 49.440308 Accept Synchronous Connection Request (0x01|0x0029) ncmd 1 Status: Success (0x00) > HCI Event: Synchronous Connect Complete (0x2c) plen 17 torvalds#311 [hci0] 49.449308 Status: Success (0x00) Handle: 257 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Link type: eSCO (0x02) Transmission interval: 0x0c Retransmission window: 0x04 RX packet length: 60 TX packet length: 60 Air mode: Transparent (0x03) < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#312 [hci0] 49.450421 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#313 [hci0] 49.457927 > HCI Event: Max Slots Change (0x1b) plen 3 torvalds#314 [hci0] 49.460345 Handle: 256 Max slots: 5 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#315 [hci0] 49.465453 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#316 [hci0] 49.470502 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#317 [hci0] 49.470519 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#318 [hci0] 49.472996 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#319 [hci0] 49.480412 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#320 [hci0] 49.480492 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#321 [hci0] 49.487989 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#322 [hci0] 49.490303 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#323 [hci0] 49.495496 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#324 [hci0] 49.500304 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#325 [hci0] 49.500311 Signed-off-by: Kiran K <[email protected]> Signed-off-by: Lokendra Singh <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
yestyle
pushed a commit
to yestyle/linux
that referenced
this pull request
Jul 10, 2022
Implement a `#[vtable]` macro
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Nov 4, 2022
The gadget may change over bind/unbind cycles, so set it each time during bind, not only the first time. Without it we get a use-after-free with the following example: cd /sys/kernel/config/usb_gadget/; mkdir -p mygadget; cd mygadget mkdir -p configs/c.1/strings/0x409 echo "C1:Composite Device" > configs/c.1/strings/0x409/configuration mkdir -p functions/ecm.usb0 ln -s functions/ecm.usb0 configs/c.1/ rmmod dummy_hcd modprobe dummy_hcd KASAN will complain shortly after the 'modprobe': usb 2-1: New USB device found, idVendor=0000, idProduct=0000, bcdDevice= 6.01 usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 ================================================================== BUG: KASAN: use-after-free in gether_connect+0xb8/0x30c Read of size 4 at addr cbef170c by task swapper/3/0 CPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.1.0-rc3-00014-g41ff012f50cb-dirty torvalds#322 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x58/0x70 dump_stack_lvl from print_report+0x134/0x4d4 print_report from kasan_report+0x78/0x10c kasan_report from gether_connect+0xb8/0x30c gether_connect from ecm_set_alt+0x124/0x254 ecm_set_alt from composite_setup+0xb98/0x2b18 composite_setup from configfs_composite_setup+0x80/0x98 configfs_composite_setup from dummy_timer+0x8f0/0x14a0 [dummy_hcd] ... Signed-off-by: Sascha Hauer <[email protected]>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Nov 9, 2022
The gadget may change over bind/unbind cycles, so set it each time during bind, not only the first time. Without it we get a use-after-free with the following example: cd /sys/kernel/config/usb_gadget/; mkdir -p mygadget; cd mygadget mkdir -p configs/c.1/strings/0x409 echo "C1:Composite Device" > configs/c.1/strings/0x409/configuration mkdir -p functions/ecm.usb0 ln -s functions/ecm.usb0 configs/c.1/ rmmod dummy_hcd modprobe dummy_hcd KASAN will complain shortly after the 'modprobe': usb 2-1: New USB device found, idVendor=0000, idProduct=0000, bcdDevice= 6.01 usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 ================================================================== BUG: KASAN: use-after-free in gether_connect+0xb8/0x30c Read of size 4 at addr cbef170c by task swapper/3/0 CPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.1.0-rc3-00014-g41ff012f50cb-dirty torvalds#322 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x58/0x70 dump_stack_lvl from print_report+0x134/0x4d4 print_report from kasan_report+0x78/0x10c kasan_report from gether_connect+0xb8/0x30c gether_connect from ecm_set_alt+0x124/0x254 ecm_set_alt from composite_setup+0xb98/0x2b18 composite_setup from configfs_composite_setup+0x80/0x98 configfs_composite_setup from dummy_timer+0x8f0/0x14a0 [dummy_hcd] ... Signed-off-by: Sascha Hauer <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Aug 28, 2023
With below mount option and testcase, it hangs kernel. 1. mount -t f2fs -o compress_log_size=5 /dev/vdb /mnt/f2fs 2. touch /mnt/f2fs/file 3. chattr +c /mnt/f2fs/file 4. dd if=/dev/zero of=/mnt/f2fs/file bs=1MB count=1 5. sync 6. dd if=/dev/zero of=/mnt/f2fs/file bs=111 count=11 conv=notrunc 7. sync INFO: task sync:4788 blocked for more than 120 seconds. Not tainted 6.5.0-rc1+ torvalds#322 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:sync state:D stack:0 pid:4788 ppid:509 flags:0x00000002 Call Trace: <TASK> __schedule+0x335/0xf80 schedule+0x6f/0xf0 wb_wait_for_completion+0x5e/0x90 sync_inodes_sb+0xd8/0x2a0 sync_inodes_one_sb+0x1d/0x30 iterate_supers+0x99/0xf0 ksys_sync+0x46/0xb0 __do_sys_sync+0x12/0x20 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 The reason is f2fs_all_cluster_page_ready() assumes that pages array should cover at least one cluster, otherwise, it will always return false, result in deadloop. By default, pages array size is 16, and it can cover the case cluster_size is equal or less than 16, for the case cluster_size is larger than 16, let's allocate memory of pages array dynamically. Fixes: 4c8ff70 ("f2fs: support data compression") Signed-off-by: Chao Yu <[email protected]>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Sep 4, 2023
With below mount option and testcase, it hangs kernel. 1. mount -t f2fs -o compress_log_size=5 /dev/vdb /mnt/f2fs 2. touch /mnt/f2fs/file 3. chattr +c /mnt/f2fs/file 4. dd if=/dev/zero of=/mnt/f2fs/file bs=1MB count=1 5. sync 6. dd if=/dev/zero of=/mnt/f2fs/file bs=111 count=11 conv=notrunc 7. sync INFO: task sync:4788 blocked for more than 120 seconds. Not tainted 6.5.0-rc1+ torvalds#322 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:sync state:D stack:0 pid:4788 ppid:509 flags:0x00000002 Call Trace: <TASK> __schedule+0x335/0xf80 schedule+0x6f/0xf0 wb_wait_for_completion+0x5e/0x90 sync_inodes_sb+0xd8/0x2a0 sync_inodes_one_sb+0x1d/0x30 iterate_supers+0x99/0xf0 ksys_sync+0x46/0xb0 __do_sys_sync+0x12/0x20 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 The reason is f2fs_all_cluster_page_ready() assumes that pages array should cover at least one cluster, otherwise, it will always return false, result in deadloop. By default, pages array size is 16, and it can cover the case cluster_size is equal or less than 16, for the case cluster_size is larger than 16, let's allocate memory of pages array dynamically. Fixes: 4c8ff70 ("f2fs: support data compression") Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Sep 20, 2023
With below mount option and testcase, it hangs kernel. 1. mount -t f2fs -o compress_log_size=5 /dev/vdb /mnt/f2fs 2. touch /mnt/f2fs/file 3. chattr +c /mnt/f2fs/file 4. dd if=/dev/zero of=/mnt/f2fs/file bs=1MB count=1 5. sync 6. dd if=/dev/zero of=/mnt/f2fs/file bs=111 count=11 conv=notrunc 7. sync INFO: task sync:4788 blocked for more than 120 seconds. Not tainted 6.5.0-rc1+ torvalds#322 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:sync state:D stack:0 pid:4788 ppid:509 flags:0x00000002 Call Trace: <TASK> __schedule+0x335/0xf80 schedule+0x6f/0xf0 wb_wait_for_completion+0x5e/0x90 sync_inodes_sb+0xd8/0x2a0 sync_inodes_one_sb+0x1d/0x30 iterate_supers+0x99/0xf0 ksys_sync+0x46/0xb0 __do_sys_sync+0x12/0x20 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 The reason is f2fs_all_cluster_page_ready() assumes that pages array should cover at least one cluster, otherwise, it will always return false, result in deadloop. By default, pages array size is 16, and it can cover the case cluster_size is equal or less than 16, for the case cluster_size is larger than 16, let's allocate memory of pages array dynamically. Fixes: 4c8ff70 ("f2fs: support data compression") Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]>
Kaz205
pushed a commit
to Kaz205/linux
that referenced
this pull request
Nov 15, 2023
[ Upstream commit c5d3f9b ] With below mount option and testcase, it hangs kernel. 1. mount -t f2fs -o compress_log_size=5 /dev/vdb /mnt/f2fs 2. touch /mnt/f2fs/file 3. chattr +c /mnt/f2fs/file 4. dd if=/dev/zero of=/mnt/f2fs/file bs=1MB count=1 5. sync 6. dd if=/dev/zero of=/mnt/f2fs/file bs=111 count=11 conv=notrunc 7. sync INFO: task sync:4788 blocked for more than 120 seconds. Not tainted 6.5.0-rc1+ torvalds#322 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:sync state:D stack:0 pid:4788 ppid:509 flags:0x00000002 Call Trace: <TASK> __schedule+0x335/0xf80 schedule+0x6f/0xf0 wb_wait_for_completion+0x5e/0x90 sync_inodes_sb+0xd8/0x2a0 sync_inodes_one_sb+0x1d/0x30 iterate_supers+0x99/0xf0 ksys_sync+0x46/0xb0 __do_sys_sync+0x12/0x20 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 The reason is f2fs_all_cluster_page_ready() assumes that pages array should cover at least one cluster, otherwise, it will always return false, result in deadloop. By default, pages array size is 16, and it can cover the case cluster_size is equal or less than 16, for the case cluster_size is larger than 16, let's allocate memory of pages array dynamically. Fixes: 4c8ff70 ("f2fs: support data compression") Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
mj22226
pushed a commit
to mj22226/linux
that referenced
this pull request
Nov 15, 2023
[ Upstream commit c5d3f9b ] With below mount option and testcase, it hangs kernel. 1. mount -t f2fs -o compress_log_size=5 /dev/vdb /mnt/f2fs 2. touch /mnt/f2fs/file 3. chattr +c /mnt/f2fs/file 4. dd if=/dev/zero of=/mnt/f2fs/file bs=1MB count=1 5. sync 6. dd if=/dev/zero of=/mnt/f2fs/file bs=111 count=11 conv=notrunc 7. sync INFO: task sync:4788 blocked for more than 120 seconds. Not tainted 6.5.0-rc1+ torvalds#322 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:sync state:D stack:0 pid:4788 ppid:509 flags:0x00000002 Call Trace: <TASK> __schedule+0x335/0xf80 schedule+0x6f/0xf0 wb_wait_for_completion+0x5e/0x90 sync_inodes_sb+0xd8/0x2a0 sync_inodes_one_sb+0x1d/0x30 iterate_supers+0x99/0xf0 ksys_sync+0x46/0xb0 __do_sys_sync+0x12/0x20 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 The reason is f2fs_all_cluster_page_ready() assumes that pages array should cover at least one cluster, otherwise, it will always return false, result in deadloop. By default, pages array size is 16, and it can cover the case cluster_size is equal or less than 16, for the case cluster_size is larger than 16, let's allocate memory of pages array dynamically. Fixes: 4c8ff70 ("f2fs: support data compression") Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Kaz205
pushed a commit
to Kaz205/linux
that referenced
this pull request
Nov 19, 2023
[ Upstream commit c5d3f9b ] With below mount option and testcase, it hangs kernel. 1. mount -t f2fs -o compress_log_size=5 /dev/vdb /mnt/f2fs 2. touch /mnt/f2fs/file 3. chattr +c /mnt/f2fs/file 4. dd if=/dev/zero of=/mnt/f2fs/file bs=1MB count=1 5. sync 6. dd if=/dev/zero of=/mnt/f2fs/file bs=111 count=11 conv=notrunc 7. sync INFO: task sync:4788 blocked for more than 120 seconds. Not tainted 6.5.0-rc1+ torvalds#322 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:sync state:D stack:0 pid:4788 ppid:509 flags:0x00000002 Call Trace: <TASK> __schedule+0x335/0xf80 schedule+0x6f/0xf0 wb_wait_for_completion+0x5e/0x90 sync_inodes_sb+0xd8/0x2a0 sync_inodes_one_sb+0x1d/0x30 iterate_supers+0x99/0xf0 ksys_sync+0x46/0xb0 __do_sys_sync+0x12/0x20 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 The reason is f2fs_all_cluster_page_ready() assumes that pages array should cover at least one cluster, otherwise, it will always return false, result in deadloop. By default, pages array size is 16, and it can cover the case cluster_size is equal or less than 16, for the case cluster_size is larger than 16, let's allocate memory of pages array dynamically. Fixes: 4c8ff70 ("f2fs: support data compression") Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
intersectRaven
pushed a commit
to intersectRaven/linux
that referenced
this pull request
Nov 20, 2023
[ Upstream commit c5d3f9b ] With below mount option and testcase, it hangs kernel. 1. mount -t f2fs -o compress_log_size=5 /dev/vdb /mnt/f2fs 2. touch /mnt/f2fs/file 3. chattr +c /mnt/f2fs/file 4. dd if=/dev/zero of=/mnt/f2fs/file bs=1MB count=1 5. sync 6. dd if=/dev/zero of=/mnt/f2fs/file bs=111 count=11 conv=notrunc 7. sync INFO: task sync:4788 blocked for more than 120 seconds. Not tainted 6.5.0-rc1+ torvalds#322 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:sync state:D stack:0 pid:4788 ppid:509 flags:0x00000002 Call Trace: <TASK> __schedule+0x335/0xf80 schedule+0x6f/0xf0 wb_wait_for_completion+0x5e/0x90 sync_inodes_sb+0xd8/0x2a0 sync_inodes_one_sb+0x1d/0x30 iterate_supers+0x99/0xf0 ksys_sync+0x46/0xb0 __do_sys_sync+0x12/0x20 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 The reason is f2fs_all_cluster_page_ready() assumes that pages array should cover at least one cluster, otherwise, it will always return false, result in deadloop. By default, pages array size is 16, and it can cover the case cluster_size is equal or less than 16, for the case cluster_size is larger than 16, let's allocate memory of pages array dynamically. Fixes: 4c8ff70 ("f2fs: support data compression") Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
1054009064
pushed a commit
to 1054009064/linux
that referenced
this pull request
Nov 20, 2023
[ Upstream commit c5d3f9b ] With below mount option and testcase, it hangs kernel. 1. mount -t f2fs -o compress_log_size=5 /dev/vdb /mnt/f2fs 2. touch /mnt/f2fs/file 3. chattr +c /mnt/f2fs/file 4. dd if=/dev/zero of=/mnt/f2fs/file bs=1MB count=1 5. sync 6. dd if=/dev/zero of=/mnt/f2fs/file bs=111 count=11 conv=notrunc 7. sync INFO: task sync:4788 blocked for more than 120 seconds. Not tainted 6.5.0-rc1+ torvalds#322 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:sync state:D stack:0 pid:4788 ppid:509 flags:0x00000002 Call Trace: <TASK> __schedule+0x335/0xf80 schedule+0x6f/0xf0 wb_wait_for_completion+0x5e/0x90 sync_inodes_sb+0xd8/0x2a0 sync_inodes_one_sb+0x1d/0x30 iterate_supers+0x99/0xf0 ksys_sync+0x46/0xb0 __do_sys_sync+0x12/0x20 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 The reason is f2fs_all_cluster_page_ready() assumes that pages array should cover at least one cluster, otherwise, it will always return false, result in deadloop. By default, pages array size is 16, and it can cover the case cluster_size is equal or less than 16, for the case cluster_size is larger than 16, let's allocate memory of pages array dynamically. Fixes: 4c8ff70 ("f2fs: support data compression") Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
charwliu
pushed a commit
to charwliu/linux
that referenced
this pull request
Nov 20, 2023
[ Upstream commit c5d3f9b ] With below mount option and testcase, it hangs kernel. 1. mount -t f2fs -o compress_log_size=5 /dev/vdb /mnt/f2fs 2. touch /mnt/f2fs/file 3. chattr +c /mnt/f2fs/file 4. dd if=/dev/zero of=/mnt/f2fs/file bs=1MB count=1 5. sync 6. dd if=/dev/zero of=/mnt/f2fs/file bs=111 count=11 conv=notrunc 7. sync INFO: task sync:4788 blocked for more than 120 seconds. Not tainted 6.5.0-rc1+ torvalds#322 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:sync state:D stack:0 pid:4788 ppid:509 flags:0x00000002 Call Trace: <TASK> __schedule+0x335/0xf80 schedule+0x6f/0xf0 wb_wait_for_completion+0x5e/0x90 sync_inodes_sb+0xd8/0x2a0 sync_inodes_one_sb+0x1d/0x30 iterate_supers+0x99/0xf0 ksys_sync+0x46/0xb0 __do_sys_sync+0x12/0x20 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 The reason is f2fs_all_cluster_page_ready() assumes that pages array should cover at least one cluster, otherwise, it will always return false, result in deadloop. By default, pages array size is 16, and it can cover the case cluster_size is equal or less than 16, for the case cluster_size is larger than 16, let's allocate memory of pages array dynamically. Fixes: 4c8ff70 ("f2fs: support data compression") Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
lategoodbye
added a commit
to lategoodbye/linux-dev
that referenced
this pull request
Nov 26, 2024
On Raspberry Pis without onboard USB hub frequent device reconnects can trigger a interrupt storm after DWC2 entered host clock gating. This is caused by a race between _dwc2_hcd_suspend() and the port interrupt, which sets port_connect_status. The issue occurs if port_connect_status is still 1, but there is no connection anymore: usb 1-1: USB disconnect, device number 25 dwc2 3f980000.usb: _dwc2_hcd_suspend: port_connect_status: 1 dwc2 3f980000.usb: Entering host clock gating. Disabling IRQ torvalds#66 irq 66: nobody cared (try booting with the "irqpoll" option) CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-gc1bb81b13202-dirty torvalds#322 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x50/0x64 dump_stack_lvl from __report_bad_irq+0x38/0xc0 __report_bad_irq from note_interrupt+0x2ac/0x2f4 note_interrupt from handle_irq_event+0x88/0x8c handle_irq_event from handle_level_irq+0xb4/0x1ac handle_level_irq from generic_handle_domain_irq+0x24/0x34 generic_handle_domain_irq from bcm2836_chained_handle_irq+0x24/0x28 bcm2836_chained_handle_irq from generic_handle_domain_irq+0x24/0x34 generic_handle_domain_irq from generic_handle_arch_irq+0x34/0x44 generic_handle_arch_irq from __irq_svc+0x88/0xb0 Exception stack(0xc1d01f20 to 0xc1d01f68) 1f20: 0004ef3c 00000001 00000000 00000000 c1d09780 c1f6bb5c c1d04e54 c1c60ca8 1f40: c1d04e94 00000000 00000000 c1d092a8 c1f6af20 c1d01f70 c1211b98 c1212f40 1f60: 60000013 ffffffff __irq_svc from default_idle_call+0x1c/0xb0 default_idle_call from do_idle+0x21c/0x284 do_idle from cpu_startup_entry+0x28/0x2c cpu_startup_entry from kernel_init+0x0/0x12c handlers: [<e3a25c00>] dwc2_handle_common_intr [<58bf98a3>] usb_hcd_irq Disabling IRQ torvalds#66 So avoid this by reading the connection status directly. Fixes: 113f86d ("usb: dwc2: Update partial power down entering by system suspend") Signed-off-by: Stefan Wahren <[email protected]>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Dec 2, 2024
On Raspberry Pis without onboard USB hub frequent device reconnects can trigger a interrupt storm after DWC2 entered host clock gating. This is caused by a race between _dwc2_hcd_suspend() and the port interrupt, which sets port_connect_status. The issue occurs if port_connect_status is still 1, but there is no connection anymore: usb 1-1: USB disconnect, device number 25 dwc2 3f980000.usb: _dwc2_hcd_suspend: port_connect_status: 1 dwc2 3f980000.usb: Entering host clock gating. Disabling IRQ torvalds#66 irq 66: nobody cared (try booting with the "irqpoll" option) CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-gc1bb81b13202-dirty torvalds#322 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x50/0x64 dump_stack_lvl from __report_bad_irq+0x38/0xc0 __report_bad_irq from note_interrupt+0x2ac/0x2f4 note_interrupt from handle_irq_event+0x88/0x8c handle_irq_event from handle_level_irq+0xb4/0x1ac handle_level_irq from generic_handle_domain_irq+0x24/0x34 generic_handle_domain_irq from bcm2836_chained_handle_irq+0x24/0x28 bcm2836_chained_handle_irq from generic_handle_domain_irq+0x24/0x34 generic_handle_domain_irq from generic_handle_arch_irq+0x34/0x44 generic_handle_arch_irq from __irq_svc+0x88/0xb0 Exception stack(0xc1d01f20 to 0xc1d01f68) 1f20: 0004ef3c 00000001 00000000 00000000 c1d09780 c1f6bb5c c1d04e54 c1c60ca8 1f40: c1d04e94 00000000 00000000 c1d092a8 c1f6af20 c1d01f70 c1211b98 c1212f40 1f60: 60000013 ffffffff __irq_svc from default_idle_call+0x1c/0xb0 default_idle_call from do_idle+0x21c/0x284 do_idle from cpu_startup_entry+0x28/0x2c cpu_startup_entry from kernel_init+0x0/0x12c handlers: [<e3a25c00>] dwc2_handle_common_intr [<58bf98a3>] usb_hcd_irq Disabling IRQ torvalds#66 So avoid this by reading the connection status directly. Fixes: 113f86d ("usb: dwc2: Update partial power down entering by system suspend") Signed-off-by: Stefan Wahren <[email protected]>
lategoodbye
added a commit
to lategoodbye/linux-dev
that referenced
this pull request
Dec 2, 2024
On Raspberry Pis without onboard USB hub frequent device reconnects can trigger a interrupt storm after DWC2 entered host clock gating. This is caused by a race between _dwc2_hcd_suspend() and the port interrupt, which sets port_connect_status. The issue occurs if port_connect_status is still 1, but there is no connection anymore: usb 1-1: USB disconnect, device number 25 dwc2 3f980000.usb: _dwc2_hcd_suspend: port_connect_status: 1 dwc2 3f980000.usb: Entering host clock gating. Disabling IRQ torvalds#66 irq 66: nobody cared (try booting with the "irqpoll" option) CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-gc1bb81b13202-dirty torvalds#322 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x50/0x64 dump_stack_lvl from __report_bad_irq+0x38/0xc0 __report_bad_irq from note_interrupt+0x2ac/0x2f4 note_interrupt from handle_irq_event+0x88/0x8c handle_irq_event from handle_level_irq+0xb4/0x1ac handle_level_irq from generic_handle_domain_irq+0x24/0x34 generic_handle_domain_irq from bcm2836_chained_handle_irq+0x24/0x28 bcm2836_chained_handle_irq from generic_handle_domain_irq+0x24/0x34 generic_handle_domain_irq from generic_handle_arch_irq+0x34/0x44 generic_handle_arch_irq from __irq_svc+0x88/0xb0 Exception stack(0xc1d01f20 to 0xc1d01f68) 1f20: 0004ef3c 00000001 00000000 00000000 c1d09780 c1f6bb5c c1d04e54 c1c60ca8 1f40: c1d04e94 00000000 00000000 c1d092a8 c1f6af20 c1d01f70 c1211b98 c1212f40 1f60: 60000013 ffffffff __irq_svc from default_idle_call+0x1c/0xb0 default_idle_call from do_idle+0x21c/0x284 do_idle from cpu_startup_entry+0x28/0x2c cpu_startup_entry from kernel_init+0x0/0x12c handlers: [<e3a25c00>] dwc2_handle_common_intr [<58bf98a3>] usb_hcd_irq Disabling IRQ torvalds#66 So avoid this by reading the connection status directly. Fixes: 113f86d ("usb: dwc2: Update partial power down entering by system suspend") Signed-off-by: Stefan Wahren <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Added baytrail ID to sdio.c