Surface Pro 3 Type Cover from Ubuntu Forums #129
Closed
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
|
Worked for me as well, thank you @chemelnucfin |
|
Not surprised that your PR is numbered only 129? For more information, please refer to https://github.com/torvalds/linux/blob/master/Documentation/HOWTO Also you should address to the subsystem mailing list. |
krzk
pushed a commit
to krzk/linux
that referenced
this pull request
May 2, 2015
…heckpatch-fixes ERROR: code indent should use tabs where possible torvalds#120: FILE: include/linux/capability.h:220: + return true;$ WARNING: please, no spaces at the start of a line torvalds#120: FILE: include/linux/capability.h:220: + return true;$ ERROR: code indent should use tabs where possible torvalds#125: FILE: include/linux/capability.h:225: + return true;$ WARNING: please, no spaces at the start of a line torvalds#125: FILE: include/linux/capability.h:225: + return true;$ ERROR: code indent should use tabs where possible torvalds#129: FILE: include/linux/capability.h:229: + return true;$ WARNING: please, no spaces at the start of a line torvalds#129: FILE: include/linux/capability.h:229: + return true;$ ERROR: code indent should use tabs where possible torvalds#134: FILE: include/linux/capability.h:234: + return true;$ WARNING: please, no spaces at the start of a line torvalds#134: FILE: include/linux/capability.h:234: + return true;$ ERROR: code indent should use tabs where possible torvalds#170: FILE: include/linux/cred.h:79: + return 1;$ WARNING: please, no spaces at the start of a line torvalds#170: FILE: include/linux/cred.h:79: + return 1;$ ERROR: code indent should use tabs where possible torvalds#174: FILE: include/linux/cred.h:83: + return 1;$ WARNING: please, no spaces at the start of a line torvalds#174: FILE: include/linux/cred.h:83: + return 1;$ total: 6 errors, 6 warnings, 310 lines checked NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or scripts/cleanfile ./patches/kernel-conditionally-support-non-root-users-groups-and-capabilities.patch has style problems, please review. If any of these errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Iulia Manda <iulia.manda21@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Nov 30, 2015
On Mon, Nov 30, 2015 at 10:20:49AM +0100, Dmitry Vyukov wrote: > ============================================= > [ INFO: possible recursive locking detected ] > 4.4.0-rc1+ torvalds#129 Not tainted > --------------------------------------------- > a.out/6283 is trying to acquire lock: > (&ctx->lock){-.....}, at: [<ffffffff815072ce>] > __perf_event_period+0x8e/0x4b0 kernel/events/core.c:4156 > > but task is already holding lock: > (&ctx->lock){-.....}, at: [< inline >] perf_event_period > kernel/events/core.c:4212 > (&ctx->lock){-.....}, at: [< inline >] _perf_ioctl > kernel/events/core.c:4266 > (&ctx->lock){-.....}, at: [<ffffffff8152331c>] perf_ioctl+0x7bc/0xcc0 > kernel/events/core.c:4320 > Indeed so. I suppose the below should fix this, I'll go try in a bit.
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Dec 18, 2015
Cc: David Rientjes <rientjes@google.com> WARNING: line over 80 characters torvalds#99: FILE: mm/page_alloc.c:2965: + * zone list (with a backoff mechanism which is a function of no_progress_loops). WARNING: line over 80 characters torvalds#129: FILE: mm/page_alloc.c:2995: + * Keep reclaiming pages while there is a chance this will lead somewhere. WARNING: line over 80 characters torvalds#134: FILE: mm/page_alloc.c:3000: + for_each_zone_zonelist_nodemask(zone, z, ac->zonelist, ac->high_zoneidx, ac->nodemask) { WARNING: line over 80 characters torvalds#138: FILE: mm/page_alloc.c:3004: + available -= DIV_ROUND_UP(no_progress_loops * available, MAX_RECLAIM_RETRIES); WARNING: line over 80 characters torvalds#142: FILE: mm/page_alloc.c:3008: + * Would the allocation succeed if we reclaimed the whole available? WARNING: line over 80 characters torvalds#146: FILE: mm/page_alloc.c:3012: + /* Wait for some write requests to complete then retry */ total: 0 errors, 6 warnings, 202 lines checked ./patches/mm-oom-rework-oom-detection.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: David Rientjes <rientjes@google.com> Cc: Hillf Danton <hillf.zj@alibaba-inc.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Michal Hocko <mhocko@suse.com> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 1, 2016
Cc: David Rientjes <rientjes@google.com> WARNING: line over 80 characters torvalds#99: FILE: mm/page_alloc.c:2965: + * zone list (with a backoff mechanism which is a function of no_progress_loops). WARNING: line over 80 characters torvalds#129: FILE: mm/page_alloc.c:2995: + * Keep reclaiming pages while there is a chance this will lead somewhere. WARNING: line over 80 characters torvalds#134: FILE: mm/page_alloc.c:3000: + for_each_zone_zonelist_nodemask(zone, z, ac->zonelist, ac->high_zoneidx, ac->nodemask) { WARNING: line over 80 characters torvalds#138: FILE: mm/page_alloc.c:3004: + available -= DIV_ROUND_UP(no_progress_loops * available, MAX_RECLAIM_RETRIES); WARNING: line over 80 characters torvalds#142: FILE: mm/page_alloc.c:3008: + * Would the allocation succeed if we reclaimed the whole available? WARNING: line over 80 characters torvalds#146: FILE: mm/page_alloc.c:3012: + /* Wait for some write requests to complete then retry */ total: 0 errors, 6 warnings, 202 lines checked ./patches/mm-oom-rework-oom-detection.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: David Rientjes <rientjes@google.com> Cc: Hillf Danton <hillf.zj@alibaba-inc.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Michal Hocko <mhocko@suse.com> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 6, 2016
Cc: David Rientjes <rientjes@google.com> WARNING: line over 80 characters torvalds#99: FILE: mm/page_alloc.c:2965: + * zone list (with a backoff mechanism which is a function of no_progress_loops). WARNING: line over 80 characters torvalds#129: FILE: mm/page_alloc.c:2995: + * Keep reclaiming pages while there is a chance this will lead somewhere. WARNING: line over 80 characters torvalds#134: FILE: mm/page_alloc.c:3000: + for_each_zone_zonelist_nodemask(zone, z, ac->zonelist, ac->high_zoneidx, ac->nodemask) { WARNING: line over 80 characters torvalds#138: FILE: mm/page_alloc.c:3004: + available -= DIV_ROUND_UP(no_progress_loops * available, MAX_RECLAIM_RETRIES); WARNING: line over 80 characters torvalds#142: FILE: mm/page_alloc.c:3008: + * Would the allocation succeed if we reclaimed the whole available? WARNING: line over 80 characters torvalds#146: FILE: mm/page_alloc.c:3012: + /* Wait for some write requests to complete then retry */ total: 0 errors, 6 warnings, 202 lines checked ./patches/mm-oom-rework-oom-detection.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: David Rientjes <rientjes@google.com> Cc: Hillf Danton <hillf.zj@alibaba-inc.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Michal Hocko <mhocko@suse.com> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 13, 2016
Cc: David Rientjes <rientjes@google.com> WARNING: line over 80 characters torvalds#99: FILE: mm/page_alloc.c:2965: + * zone list (with a backoff mechanism which is a function of no_progress_loops). WARNING: line over 80 characters torvalds#129: FILE: mm/page_alloc.c:2995: + * Keep reclaiming pages while there is a chance this will lead somewhere. WARNING: line over 80 characters torvalds#134: FILE: mm/page_alloc.c:3000: + for_each_zone_zonelist_nodemask(zone, z, ac->zonelist, ac->high_zoneidx, ac->nodemask) { WARNING: line over 80 characters torvalds#138: FILE: mm/page_alloc.c:3004: + available -= DIV_ROUND_UP(no_progress_loops * available, MAX_RECLAIM_RETRIES); WARNING: line over 80 characters torvalds#142: FILE: mm/page_alloc.c:3008: + * Would the allocation succeed if we reclaimed the whole available? WARNING: line over 80 characters torvalds#146: FILE: mm/page_alloc.c:3012: + /* Wait for some write requests to complete then retry */ total: 0 errors, 6 warnings, 202 lines checked ./patches/mm-oom-rework-oom-detection.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: David Rientjes <rientjes@google.com> Cc: Hillf Danton <hillf.zj@alibaba-inc.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Michal Hocko <mhocko@suse.com> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 14, 2016
Cc: David Rientjes <rientjes@google.com> WARNING: line over 80 characters torvalds#99: FILE: mm/page_alloc.c:2965: + * zone list (with a backoff mechanism which is a function of no_progress_loops). WARNING: line over 80 characters torvalds#129: FILE: mm/page_alloc.c:2995: + * Keep reclaiming pages while there is a chance this will lead somewhere. WARNING: line over 80 characters torvalds#134: FILE: mm/page_alloc.c:3000: + for_each_zone_zonelist_nodemask(zone, z, ac->zonelist, ac->high_zoneidx, ac->nodemask) { WARNING: line over 80 characters torvalds#138: FILE: mm/page_alloc.c:3004: + available -= DIV_ROUND_UP(no_progress_loops * available, MAX_RECLAIM_RETRIES); WARNING: line over 80 characters torvalds#142: FILE: mm/page_alloc.c:3008: + * Would the allocation succeed if we reclaimed the whole available? WARNING: line over 80 characters torvalds#146: FILE: mm/page_alloc.c:3012: + /* Wait for some write requests to complete then retry */ total: 0 errors, 6 warnings, 202 lines checked ./patches/mm-oom-rework-oom-detection.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: David Rientjes <rientjes@google.com> Cc: Hillf Danton <hillf.zj@alibaba-inc.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Michal Hocko <mhocko@suse.com> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 15, 2016
Cc: David Rientjes <rientjes@google.com> WARNING: line over 80 characters torvalds#99: FILE: mm/page_alloc.c:2965: + * zone list (with a backoff mechanism which is a function of no_progress_loops). WARNING: line over 80 characters torvalds#129: FILE: mm/page_alloc.c:2995: + * Keep reclaiming pages while there is a chance this will lead somewhere. WARNING: line over 80 characters torvalds#134: FILE: mm/page_alloc.c:3000: + for_each_zone_zonelist_nodemask(zone, z, ac->zonelist, ac->high_zoneidx, ac->nodemask) { WARNING: line over 80 characters torvalds#138: FILE: mm/page_alloc.c:3004: + available -= DIV_ROUND_UP(no_progress_loops * available, MAX_RECLAIM_RETRIES); WARNING: line over 80 characters torvalds#142: FILE: mm/page_alloc.c:3008: + * Would the allocation succeed if we reclaimed the whole available? WARNING: line over 80 characters torvalds#146: FILE: mm/page_alloc.c:3012: + /* Wait for some write requests to complete then retry */ total: 0 errors, 6 warnings, 202 lines checked ./patches/mm-oom-rework-oom-detection.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: David Rientjes <rientjes@google.com> Cc: Hillf Danton <hillf.zj@alibaba-inc.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Michal Hocko <mhocko@suse.com> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 21, 2016
Cc: David Rientjes <rientjes@google.com> WARNING: line over 80 characters torvalds#99: FILE: mm/page_alloc.c:2965: + * zone list (with a backoff mechanism which is a function of no_progress_loops). WARNING: line over 80 characters torvalds#129: FILE: mm/page_alloc.c:2995: + * Keep reclaiming pages while there is a chance this will lead somewhere. WARNING: line over 80 characters torvalds#134: FILE: mm/page_alloc.c:3000: + for_each_zone_zonelist_nodemask(zone, z, ac->zonelist, ac->high_zoneidx, ac->nodemask) { WARNING: line over 80 characters torvalds#138: FILE: mm/page_alloc.c:3004: + available -= DIV_ROUND_UP(no_progress_loops * available, MAX_RECLAIM_RETRIES); WARNING: line over 80 characters torvalds#142: FILE: mm/page_alloc.c:3008: + * Would the allocation succeed if we reclaimed the whole available? WARNING: line over 80 characters torvalds#146: FILE: mm/page_alloc.c:3012: + /* Wait for some write requests to complete then retry */ total: 0 errors, 6 warnings, 202 lines checked ./patches/mm-oom-rework-oom-detection.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: David Rientjes <rientjes@google.com> Cc: Hillf Danton <hillf.zj@alibaba-inc.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Michal Hocko <mhocko@suse.com> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 22, 2016
Cc: David Rientjes <rientjes@google.com> WARNING: line over 80 characters torvalds#99: FILE: mm/page_alloc.c:2965: + * zone list (with a backoff mechanism which is a function of no_progress_loops). WARNING: line over 80 characters torvalds#129: FILE: mm/page_alloc.c:2995: + * Keep reclaiming pages while there is a chance this will lead somewhere. WARNING: line over 80 characters torvalds#134: FILE: mm/page_alloc.c:3000: + for_each_zone_zonelist_nodemask(zone, z, ac->zonelist, ac->high_zoneidx, ac->nodemask) { WARNING: line over 80 characters torvalds#138: FILE: mm/page_alloc.c:3004: + available -= DIV_ROUND_UP(no_progress_loops * available, MAX_RECLAIM_RETRIES); WARNING: line over 80 characters torvalds#142: FILE: mm/page_alloc.c:3008: + * Would the allocation succeed if we reclaimed the whole available? WARNING: line over 80 characters torvalds#146: FILE: mm/page_alloc.c:3012: + /* Wait for some write requests to complete then retry */ total: 0 errors, 6 warnings, 202 lines checked ./patches/mm-oom-rework-oom-detection.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: David Rientjes <rientjes@google.com> Cc: Hillf Danton <hillf.zj@alibaba-inc.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Michal Hocko <mhocko@suse.com> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 28, 2016
Cc: David Rientjes <rientjes@google.com> WARNING: line over 80 characters torvalds#99: FILE: mm/page_alloc.c:2965: + * zone list (with a backoff mechanism which is a function of no_progress_loops). WARNING: line over 80 characters torvalds#129: FILE: mm/page_alloc.c:2995: + * Keep reclaiming pages while there is a chance this will lead somewhere. WARNING: line over 80 characters torvalds#134: FILE: mm/page_alloc.c:3000: + for_each_zone_zonelist_nodemask(zone, z, ac->zonelist, ac->high_zoneidx, ac->nodemask) { WARNING: line over 80 characters torvalds#138: FILE: mm/page_alloc.c:3004: + available -= DIV_ROUND_UP(no_progress_loops * available, MAX_RECLAIM_RETRIES); WARNING: line over 80 characters torvalds#142: FILE: mm/page_alloc.c:3008: + * Would the allocation succeed if we reclaimed the whole available? WARNING: line over 80 characters torvalds#146: FILE: mm/page_alloc.c:3012: + /* Wait for some write requests to complete then retry */ total: 0 errors, 6 warnings, 202 lines checked ./patches/mm-oom-rework-oom-detection.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: David Rientjes <rientjes@google.com> Cc: Hillf Danton <hillf.zj@alibaba-inc.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Michal Hocko <mhocko@suse.com> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Feb 1, 2016
Cc: David Rientjes <rientjes@google.com> WARNING: line over 80 characters torvalds#99: FILE: mm/page_alloc.c:2965: + * zone list (with a backoff mechanism which is a function of no_progress_loops). WARNING: line over 80 characters torvalds#129: FILE: mm/page_alloc.c:2995: + * Keep reclaiming pages while there is a chance this will lead somewhere. WARNING: line over 80 characters torvalds#134: FILE: mm/page_alloc.c:3000: + for_each_zone_zonelist_nodemask(zone, z, ac->zonelist, ac->high_zoneidx, ac->nodemask) { WARNING: line over 80 characters torvalds#138: FILE: mm/page_alloc.c:3004: + available -= DIV_ROUND_UP(no_progress_loops * available, MAX_RECLAIM_RETRIES); WARNING: line over 80 characters torvalds#142: FILE: mm/page_alloc.c:3008: + * Would the allocation succeed if we reclaimed the whole available? WARNING: line over 80 characters torvalds#146: FILE: mm/page_alloc.c:3012: + /* Wait for some write requests to complete then retry */ total: 0 errors, 6 warnings, 202 lines checked ./patches/mm-oom-rework-oom-detection.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: David Rientjes <rientjes@google.com> Cc: Hillf Danton <hillf.zj@alibaba-inc.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Michal Hocko <mhocko@suse.com> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Feb 4, 2016
Cc: David Rientjes <rientjes@google.com> WARNING: line over 80 characters torvalds#99: FILE: mm/page_alloc.c:2965: + * zone list (with a backoff mechanism which is a function of no_progress_loops). WARNING: line over 80 characters torvalds#129: FILE: mm/page_alloc.c:2995: + * Keep reclaiming pages while there is a chance this will lead somewhere. WARNING: line over 80 characters torvalds#134: FILE: mm/page_alloc.c:3000: + for_each_zone_zonelist_nodemask(zone, z, ac->zonelist, ac->high_zoneidx, ac->nodemask) { WARNING: line over 80 characters torvalds#138: FILE: mm/page_alloc.c:3004: + available -= DIV_ROUND_UP(no_progress_loops * available, MAX_RECLAIM_RETRIES); WARNING: line over 80 characters torvalds#142: FILE: mm/page_alloc.c:3008: + * Would the allocation succeed if we reclaimed the whole available? WARNING: line over 80 characters torvalds#146: FILE: mm/page_alloc.c:3012: + /* Wait for some write requests to complete then retry */ total: 0 errors, 6 warnings, 202 lines checked ./patches/mm-oom-rework-oom-detection.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: David Rientjes <rientjes@google.com> Cc: Hillf Danton <hillf.zj@alibaba-inc.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Michal Hocko <mhocko@suse.com> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Feb 8, 2016
When enabling stack trace via "echo 1 > /proc/sys/kernel/stack_tracer_enabled", the below KASAN warning is triggered: BUG: KASAN: stack-out-of-bounds in check_stack+0x344/0x848 at addr ffffffc0689ebab8 Read of size 8 by task ksoftirqd/4/29 page:ffffffbdc3a27ac0 count:0 mapcount:0 mapping: (null) index:0x0 flags: 0x0() page dumped because: kasan: bad access detected CPU: 4 PID: 29 Comm: ksoftirqd/4 Not tainted 4.5.0-rc1 torvalds#129 Hardware name: Freescale Layerscape 2085a RDB Board (DT) Call trace: [<ffffffc000091300>] dump_backtrace+0x0/0x3a0 [<ffffffc0000916c4>] show_stack+0x24/0x30 [<ffffffc0009bbd78>] dump_stack+0xd8/0x168 [<ffffffc000420bb0>] kasan_report_error+0x6a0/0x920 [<ffffffc000421688>] kasan_report+0x70/0xb8 [<ffffffc00041f7f0>] __asan_load8+0x60/0x78 [<ffffffc0002e05c4>] check_stack+0x344/0x848 [<ffffffc0002e0c8c>] stack_trace_call+0x1c4/0x370 [<ffffffc0002af558>] ftrace_ops_no_ops+0x2c0/0x590 [<ffffffc00009f25c>] ftrace_graph_call+0x0/0x14 [<ffffffc0000881bc>] fpsimd_thread_switch+0x24/0x1e8 [<ffffffc000089864>] __switch_to+0x34/0x218 [<ffffffc0011e089c>] __schedule+0x3ac/0x15b8 [<ffffffc0011e1f6c>] schedule+0x5c/0x178 [<ffffffc0001632a8>] smpboot_thread_fn+0x350/0x960 [<ffffffc00015b518>] kthread+0x1d8/0x2b0 [<ffffffc0000874d0>] ret_from_fork+0x10/0x40 Memory state around the buggy address: ffffffc0689eb980: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 f4 f4 f4 ffffffc0689eba00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 >ffffffc0689eba80: 00 00 f1 f1 f1 f1 00 f4 f4 f4 f3 f3 f3 f3 00 00 ^ ffffffc0689ebb00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffc0689ebb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 The stacker tracer traverses the whole kernel stack when saving the max stack trace. It may touch the stack red zones to cause the warning. So, just disable the instrumentation to silence the warning. Signed-off-by: Yang Shi <yang.shi@linaro.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Feb 12, 2016
When enabling stack trace via "echo 1 > /proc/sys/kernel/stack_tracer_enabled", the below KASAN warning is triggered: BUG: KASAN: stack-out-of-bounds in check_stack+0x344/0x848 at addr ffffffc0689ebab8 Read of size 8 by task ksoftirqd/4/29 page:ffffffbdc3a27ac0 count:0 mapcount:0 mapping: (null) index:0x0 flags: 0x0() page dumped because: kasan: bad access detected CPU: 4 PID: 29 Comm: ksoftirqd/4 Not tainted 4.5.0-rc1 torvalds#129 Hardware name: Freescale Layerscape 2085a RDB Board (DT) Call trace: [<ffffffc000091300>] dump_backtrace+0x0/0x3a0 [<ffffffc0000916c4>] show_stack+0x24/0x30 [<ffffffc0009bbd78>] dump_stack+0xd8/0x168 [<ffffffc000420bb0>] kasan_report_error+0x6a0/0x920 [<ffffffc000421688>] kasan_report+0x70/0xb8 [<ffffffc00041f7f0>] __asan_load8+0x60/0x78 [<ffffffc0002e05c4>] check_stack+0x344/0x848 [<ffffffc0002e0c8c>] stack_trace_call+0x1c4/0x370 [<ffffffc0002af558>] ftrace_ops_no_ops+0x2c0/0x590 [<ffffffc00009f25c>] ftrace_graph_call+0x0/0x14 [<ffffffc0000881bc>] fpsimd_thread_switch+0x24/0x1e8 [<ffffffc000089864>] __switch_to+0x34/0x218 [<ffffffc0011e089c>] __schedule+0x3ac/0x15b8 [<ffffffc0011e1f6c>] schedule+0x5c/0x178 [<ffffffc0001632a8>] smpboot_thread_fn+0x350/0x960 [<ffffffc00015b518>] kthread+0x1d8/0x2b0 [<ffffffc0000874d0>] ret_from_fork+0x10/0x40 Memory state around the buggy address: ffffffc0689eb980: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 f4 f4 f4 ffffffc0689eba00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 >ffffffc0689eba80: 00 00 f1 f1 f1 f1 00 f4 f4 f4 f3 f3 f3 f3 00 00 ^ ffffffc0689ebb00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffc0689ebb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 The stacker tracer traverses the whole kernel stack when saving the max stack trace. It may touch the stack red zones to cause the warning. So, just disable the instrumentation to silence the warning. Signed-off-by: Yang Shi <yang.shi@linaro.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Feb 22, 2016
Cc: David Rientjes <rientjes@google.com> WARNING: line over 80 characters torvalds#99: FILE: mm/page_alloc.c:2965: + * zone list (with a backoff mechanism which is a function of no_progress_loops). WARNING: line over 80 characters torvalds#129: FILE: mm/page_alloc.c:2995: + * Keep reclaiming pages while there is a chance this will lead somewhere. WARNING: line over 80 characters torvalds#134: FILE: mm/page_alloc.c:3000: + for_each_zone_zonelist_nodemask(zone, z, ac->zonelist, ac->high_zoneidx, ac->nodemask) { WARNING: line over 80 characters torvalds#138: FILE: mm/page_alloc.c:3004: + available -= DIV_ROUND_UP(no_progress_loops * available, MAX_RECLAIM_RETRIES); WARNING: line over 80 characters torvalds#142: FILE: mm/page_alloc.c:3008: + * Would the allocation succeed if we reclaimed the whole available? WARNING: line over 80 characters torvalds#146: FILE: mm/page_alloc.c:3012: + /* Wait for some write requests to complete then retry */ total: 0 errors, 6 warnings, 202 lines checked ./patches/mm-oom-rework-oom-detection.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: David Rientjes <rientjes@google.com> Cc: Hillf Danton <hillf.zj@alibaba-inc.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Michal Hocko <mhocko@suse.com> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
torvalds
pushed a commit
that referenced
this pull request
Feb 22, 2016
When enabling stack trace via "echo 1 > /proc/sys/kernel/stack_tracer_enabled", the below KASAN warning is triggered: BUG: KASAN: stack-out-of-bounds in check_stack+0x344/0x848 at addr ffffffc0689ebab8 Read of size 8 by task ksoftirqd/4/29 page:ffffffbdc3a27ac0 count:0 mapcount:0 mapping: (null) index:0x0 flags: 0x0() page dumped because: kasan: bad access detected CPU: 4 PID: 29 Comm: ksoftirqd/4 Not tainted 4.5.0-rc1 #129 Hardware name: Freescale Layerscape 2085a RDB Board (DT) Call trace: [<ffffffc000091300>] dump_backtrace+0x0/0x3a0 [<ffffffc0000916c4>] show_stack+0x24/0x30 [<ffffffc0009bbd78>] dump_stack+0xd8/0x168 [<ffffffc000420bb0>] kasan_report_error+0x6a0/0x920 [<ffffffc000421688>] kasan_report+0x70/0xb8 [<ffffffc00041f7f0>] __asan_load8+0x60/0x78 [<ffffffc0002e05c4>] check_stack+0x344/0x848 [<ffffffc0002e0c8c>] stack_trace_call+0x1c4/0x370 [<ffffffc0002af558>] ftrace_ops_no_ops+0x2c0/0x590 [<ffffffc00009f25c>] ftrace_graph_call+0x0/0x14 [<ffffffc0000881bc>] fpsimd_thread_switch+0x24/0x1e8 [<ffffffc000089864>] __switch_to+0x34/0x218 [<ffffffc0011e089c>] __schedule+0x3ac/0x15b8 [<ffffffc0011e1f6c>] schedule+0x5c/0x178 [<ffffffc0001632a8>] smpboot_thread_fn+0x350/0x960 [<ffffffc00015b518>] kthread+0x1d8/0x2b0 [<ffffffc0000874d0>] ret_from_fork+0x10/0x40 Memory state around the buggy address: ffffffc0689eb980: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 f4 f4 f4 ffffffc0689eba00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 >ffffffc0689eba80: 00 00 f1 f1 f1 f1 00 f4 f4 f4 f3 f3 f3 f3 00 00 ^ ffffffc0689ebb00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffc0689ebb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 The stacker tracer traverses the whole kernel stack when saving the max stack trace. It may touch the stack red zones to cause the warning. So, just disable the instrumentation to silence the warning. Link: http://lkml.kernel.org/r/1455309960-18930-1-git-send-email-yang.shi@linaro.org Signed-off-by: Yang Shi <yang.shi@linaro.org> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Feb 29, 2016
Cc: David Rientjes <rientjes@google.com> WARNING: line over 80 characters torvalds#99: FILE: mm/page_alloc.c:2965: + * zone list (with a backoff mechanism which is a function of no_progress_loops). WARNING: line over 80 characters torvalds#129: FILE: mm/page_alloc.c:2995: + * Keep reclaiming pages while there is a chance this will lead somewhere. WARNING: line over 80 characters torvalds#134: FILE: mm/page_alloc.c:3000: + for_each_zone_zonelist_nodemask(zone, z, ac->zonelist, ac->high_zoneidx, ac->nodemask) { WARNING: line over 80 characters torvalds#138: FILE: mm/page_alloc.c:3004: + available -= DIV_ROUND_UP(no_progress_loops * available, MAX_RECLAIM_RETRIES); WARNING: line over 80 characters torvalds#142: FILE: mm/page_alloc.c:3008: + * Would the allocation succeed if we reclaimed the whole available? WARNING: line over 80 characters torvalds#146: FILE: mm/page_alloc.c:3012: + /* Wait for some write requests to complete then retry */ total: 0 errors, 6 warnings, 202 lines checked ./patches/mm-oom-rework-oom-detection.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: David Rientjes <rientjes@google.com> Cc: Hillf Danton <hillf.zj@alibaba-inc.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Michal Hocko <mhocko@suse.com> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Feb 29, 2016
Cc: David Rientjes <rientjes@google.com> WARNING: line over 80 characters torvalds#99: FILE: mm/page_alloc.c:2965: + * zone list (with a backoff mechanism which is a function of no_progress_loops). WARNING: line over 80 characters torvalds#129: FILE: mm/page_alloc.c:2995: + * Keep reclaiming pages while there is a chance this will lead somewhere. WARNING: line over 80 characters torvalds#134: FILE: mm/page_alloc.c:3000: + for_each_zone_zonelist_nodemask(zone, z, ac->zonelist, ac->high_zoneidx, ac->nodemask) { WARNING: line over 80 characters torvalds#138: FILE: mm/page_alloc.c:3004: + available -= DIV_ROUND_UP(no_progress_loops * available, MAX_RECLAIM_RETRIES); WARNING: line over 80 characters torvalds#142: FILE: mm/page_alloc.c:3008: + * Would the allocation succeed if we reclaimed the whole available? WARNING: line over 80 characters torvalds#146: FILE: mm/page_alloc.c:3012: + /* Wait for some write requests to complete then retry */ total: 0 errors, 6 warnings, 202 lines checked ./patches/mm-oom-rework-oom-detection.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: David Rientjes <rientjes@google.com> Cc: Hillf Danton <hillf.zj@alibaba-inc.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Michal Hocko <mhocko@suse.com> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Mar 9, 2016
Cc: David Rientjes <rientjes@google.com> WARNING: line over 80 characters torvalds#99: FILE: mm/page_alloc.c:2965: + * zone list (with a backoff mechanism which is a function of no_progress_loops). WARNING: line over 80 characters torvalds#129: FILE: mm/page_alloc.c:2995: + * Keep reclaiming pages while there is a chance this will lead somewhere. WARNING: line over 80 characters torvalds#134: FILE: mm/page_alloc.c:3000: + for_each_zone_zonelist_nodemask(zone, z, ac->zonelist, ac->high_zoneidx, ac->nodemask) { WARNING: line over 80 characters torvalds#138: FILE: mm/page_alloc.c:3004: + available -= DIV_ROUND_UP(no_progress_loops * available, MAX_RECLAIM_RETRIES); WARNING: line over 80 characters torvalds#142: FILE: mm/page_alloc.c:3008: + * Would the allocation succeed if we reclaimed the whole available? WARNING: line over 80 characters torvalds#146: FILE: mm/page_alloc.c:3012: + /* Wait for some write requests to complete then retry */ total: 0 errors, 6 warnings, 202 lines checked ./patches/mm-oom-rework-oom-detection.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: David Rientjes <rientjes@google.com> Cc: Hillf Danton <hillf.zj@alibaba-inc.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Michal Hocko <mhocko@suse.com> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Mar 11, 2016
Cc: David Rientjes <rientjes@google.com> WARNING: line over 80 characters torvalds#99: FILE: mm/page_alloc.c:2965: + * zone list (with a backoff mechanism which is a function of no_progress_loops). WARNING: line over 80 characters torvalds#129: FILE: mm/page_alloc.c:2995: + * Keep reclaiming pages while there is a chance this will lead somewhere. WARNING: line over 80 characters torvalds#134: FILE: mm/page_alloc.c:3000: + for_each_zone_zonelist_nodemask(zone, z, ac->zonelist, ac->high_zoneidx, ac->nodemask) { WARNING: line over 80 characters torvalds#138: FILE: mm/page_alloc.c:3004: + available -= DIV_ROUND_UP(no_progress_loops * available, MAX_RECLAIM_RETRIES); WARNING: line over 80 characters torvalds#142: FILE: mm/page_alloc.c:3008: + * Would the allocation succeed if we reclaimed the whole available? WARNING: line over 80 characters torvalds#146: FILE: mm/page_alloc.c:3012: + /* Wait for some write requests to complete then retry */ total: 0 errors, 6 warnings, 202 lines checked ./patches/mm-oom-rework-oom-detection.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: David Rientjes <rientjes@google.com> Cc: Hillf Danton <hillf.zj@alibaba-inc.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Michal Hocko <mhocko@suse.com> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Mar 16, 2016
Cc: David Rientjes <rientjes@google.com> WARNING: line over 80 characters torvalds#99: FILE: mm/page_alloc.c:2965: + * zone list (with a backoff mechanism which is a function of no_progress_loops). WARNING: line over 80 characters torvalds#129: FILE: mm/page_alloc.c:2995: + * Keep reclaiming pages while there is a chance this will lead somewhere. WARNING: line over 80 characters torvalds#134: FILE: mm/page_alloc.c:3000: + for_each_zone_zonelist_nodemask(zone, z, ac->zonelist, ac->high_zoneidx, ac->nodemask) { WARNING: line over 80 characters torvalds#138: FILE: mm/page_alloc.c:3004: + available -= DIV_ROUND_UP(no_progress_loops * available, MAX_RECLAIM_RETRIES); WARNING: line over 80 characters torvalds#142: FILE: mm/page_alloc.c:3008: + * Would the allocation succeed if we reclaimed the whole available? WARNING: line over 80 characters torvalds#146: FILE: mm/page_alloc.c:3012: + /* Wait for some write requests to complete then retry */ total: 0 errors, 6 warnings, 202 lines checked ./patches/mm-oom-rework-oom-detection.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: David Rientjes <rientjes@google.com> Cc: Hillf Danton <hillf.zj@alibaba-inc.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Michal Hocko <mhocko@suse.com> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Mar 17, 2016
Cc: David Rientjes <rientjes@google.com> WARNING: line over 80 characters torvalds#99: FILE: mm/page_alloc.c:2965: + * zone list (with a backoff mechanism which is a function of no_progress_loops). WARNING: line over 80 characters torvalds#129: FILE: mm/page_alloc.c:2995: + * Keep reclaiming pages while there is a chance this will lead somewhere. WARNING: line over 80 characters torvalds#134: FILE: mm/page_alloc.c:3000: + for_each_zone_zonelist_nodemask(zone, z, ac->zonelist, ac->high_zoneidx, ac->nodemask) { WARNING: line over 80 characters torvalds#138: FILE: mm/page_alloc.c:3004: + available -= DIV_ROUND_UP(no_progress_loops * available, MAX_RECLAIM_RETRIES); WARNING: line over 80 characters torvalds#142: FILE: mm/page_alloc.c:3008: + * Would the allocation succeed if we reclaimed the whole available? WARNING: line over 80 characters torvalds#146: FILE: mm/page_alloc.c:3012: + /* Wait for some write requests to complete then retry */ total: 0 errors, 6 warnings, 202 lines checked ./patches/mm-oom-rework-oom-detection.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: David Rientjes <rientjes@google.com> Cc: Hillf Danton <hillf.zj@alibaba-inc.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Michal Hocko <mhocko@suse.com> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Mar 18, 2016
Cc: David Rientjes <rientjes@google.com> WARNING: line over 80 characters torvalds#99: FILE: mm/page_alloc.c:2965: + * zone list (with a backoff mechanism which is a function of no_progress_loops). WARNING: line over 80 characters torvalds#129: FILE: mm/page_alloc.c:2995: + * Keep reclaiming pages while there is a chance this will lead somewhere. WARNING: line over 80 characters torvalds#134: FILE: mm/page_alloc.c:3000: + for_each_zone_zonelist_nodemask(zone, z, ac->zonelist, ac->high_zoneidx, ac->nodemask) { WARNING: line over 80 characters torvalds#138: FILE: mm/page_alloc.c:3004: + available -= DIV_ROUND_UP(no_progress_loops * available, MAX_RECLAIM_RETRIES); WARNING: line over 80 characters torvalds#142: FILE: mm/page_alloc.c:3008: + * Would the allocation succeed if we reclaimed the whole available? WARNING: line over 80 characters torvalds#146: FILE: mm/page_alloc.c:3012: + /* Wait for some write requests to complete then retry */ total: 0 errors, 6 warnings, 202 lines checked ./patches/mm-oom-rework-oom-detection.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: David Rientjes <rientjes@google.com> Cc: Hillf Danton <hillf.zj@alibaba-inc.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Michal Hocko <mhocko@suse.com> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
pv
added a commit
to pv/linux
that referenced
this pull request
Jul 15, 2023
LE Create CIS command shall not be sent before all CIS Established events from its previous invocation have been processed. Currently it is sent via hci_sync but that only waits for the first event, but there can be multiple. Make it wait for all events, and simplify the CIS creation as follows: Add new flag HCI_CONN_CREATE_CIS, which is set if Create CIS has been sent for the connection but it is not yet completed. Make BT_CONNECT state to mean the connection wants Create CIS. On events after which new Create CIS may need to be sent, send it if possible and some connections need it. These events are: hci_connect_cis, iso_connect_cfm, hci_cs_le_create_cis, hci_le_cis_estabilished_evt. The Create CIS status/completion events shall queue new Create CIS only if at least one of the connections transitions away from BT_CONNECT, so that we don't loop if controller is sending bogus events. This fixes sending multiple CIS Create for the same CIS in the "ISO AC 6(i) - Success" BlueZ test case: < HCI Command: LE Create Co.. (0x08|0x0064) plen 9 torvalds#129 [hci0] Number of CIS: 2 CIS Handle: 257 ACL Handle: 42 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 torvalds#130 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 29 torvalds#131 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 257 ... < HCI Command: LE Setup Is.. (0x08|0x006e) plen 13 torvalds#132 [hci0] ... > HCI Event: Command Complete (0x0e) plen 6 torvalds#133 [hci0] LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1 ... < HCI Command: LE Create Co.. (0x08|0x0064) plen 5 torvalds#134 [hci0] Number of CIS: 1 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 torvalds#135 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: ACL Connection Already Exists (0x0b) > HCI Event: LE Meta Event (0x3e) plen 29 torvalds#136 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 258 ... Fixes: c09b80b ("Bluetooth: hci_conn: Fix not waiting for HCI_EVT_LE_CIS_ESTABLISHED") Signed-off-by: Pauli Virtanen <pav@iki.fi>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Jul 24, 2023
LE Create CIS command shall not be sent before all CIS Established events from its previous invocation have been processed. Currently it is sent via hci_sync but that only waits for the first event, but there can be multiple. Make it wait for all events, and simplify the CIS creation as follows: Add new flag HCI_CONN_CREATE_CIS, which is set if Create CIS has been sent for the connection but it is not yet completed. Make BT_CONNECT state to mean the connection wants Create CIS. On events after which new Create CIS may need to be sent, send it if possible and some connections need it. These events are: hci_connect_cis, iso_connect_cfm, hci_cs_le_create_cis, hci_le_cis_estabilished_evt. The Create CIS status/completion events shall queue new Create CIS only if at least one of the connections transitions away from BT_CONNECT, so that we don't loop if controller is sending bogus events. This fixes sending multiple CIS Create for the same CIS in the "ISO AC 6(i) - Success" BlueZ test case: < HCI Command: LE Create Co.. (0x08|0x0064) plen 9 torvalds#129 [hci0] Number of CIS: 2 CIS Handle: 257 ACL Handle: 42 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 torvalds#130 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 29 torvalds#131 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 257 ... < HCI Command: LE Setup Is.. (0x08|0x006e) plen 13 torvalds#132 [hci0] ... > HCI Event: Command Complete (0x0e) plen 6 torvalds#133 [hci0] LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1 ... < HCI Command: LE Create Co.. (0x08|0x0064) plen 5 torvalds#134 [hci0] Number of CIS: 1 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 torvalds#135 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: ACL Connection Already Exists (0x0b) > HCI Event: LE Meta Event (0x3e) plen 29 torvalds#136 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 258 ... Fixes: c09b80b ("Bluetooth: hci_conn: Fix not waiting for HCI_EVT_LE_CIS_ESTABLISHED") Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Aug 11, 2023
LE Create CIS command shall not be sent before all CIS Established events from its previous invocation have been processed. Currently it is sent via hci_sync but that only waits for the first event, but there can be multiple. Make it wait for all events, and simplify the CIS creation as follows: Add new flag HCI_CONN_CREATE_CIS, which is set if Create CIS has been sent for the connection but it is not yet completed. Make BT_CONNECT state to mean the connection wants Create CIS. On events after which new Create CIS may need to be sent, send it if possible and some connections need it. These events are: hci_connect_cis, iso_connect_cfm, hci_cs_le_create_cis, hci_le_cis_estabilished_evt. The Create CIS status/completion events shall queue new Create CIS only if at least one of the connections transitions away from BT_CONNECT, so that we don't loop if controller is sending bogus events. This fixes sending multiple CIS Create for the same CIS in the "ISO AC 6(i) - Success" BlueZ test case: < HCI Command: LE Create Co.. (0x08|0x0064) plen 9 torvalds#129 [hci0] Number of CIS: 2 CIS Handle: 257 ACL Handle: 42 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 torvalds#130 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 29 torvalds#131 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 257 ... < HCI Command: LE Setup Is.. (0x08|0x006e) plen 13 torvalds#132 [hci0] ... > HCI Event: Command Complete (0x0e) plen 6 torvalds#133 [hci0] LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1 ... < HCI Command: LE Create Co.. (0x08|0x0064) plen 5 torvalds#134 [hci0] Number of CIS: 1 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 torvalds#135 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: ACL Connection Already Exists (0x0b) > HCI Event: LE Meta Event (0x3e) plen 29 torvalds#136 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 258 ... Fixes: c09b80b ("Bluetooth: hci_conn: Fix not waiting for HCI_EVT_LE_CIS_ESTABLISHED") Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Kaz205
pushed a commit
to Kaz205/linux
that referenced
this pull request
Sep 11, 2023
[ Upstream commit 7f74563 ] LE Create CIS command shall not be sent before all CIS Established events from its previous invocation have been processed. Currently it is sent via hci_sync but that only waits for the first event, but there can be multiple. Make it wait for all events, and simplify the CIS creation as follows: Add new flag HCI_CONN_CREATE_CIS, which is set if Create CIS has been sent for the connection but it is not yet completed. Make BT_CONNECT state to mean the connection wants Create CIS. On events after which new Create CIS may need to be sent, send it if possible and some connections need it. These events are: hci_connect_cis, iso_connect_cfm, hci_cs_le_create_cis, hci_le_cis_estabilished_evt. The Create CIS status/completion events shall queue new Create CIS only if at least one of the connections transitions away from BT_CONNECT, so that we don't loop if controller is sending bogus events. This fixes sending multiple CIS Create for the same CIS in the "ISO AC 6(i) - Success" BlueZ test case: < HCI Command: LE Create Co.. (0x08|0x0064) plen 9 torvalds#129 [hci0] Number of CIS: 2 CIS Handle: 257 ACL Handle: 42 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 torvalds#130 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 29 torvalds#131 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 257 ... < HCI Command: LE Setup Is.. (0x08|0x006e) plen 13 torvalds#132 [hci0] ... > HCI Event: Command Complete (0x0e) plen 6 torvalds#133 [hci0] LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1 ... < HCI Command: LE Create Co.. (0x08|0x0064) plen 5 torvalds#134 [hci0] Number of CIS: 1 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 torvalds#135 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: ACL Connection Already Exists (0x0b) > HCI Event: LE Meta Event (0x3e) plen 29 torvalds#136 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 258 ... Fixes: c09b80b ("Bluetooth: hci_conn: Fix not waiting for HCI_EVT_LE_CIS_ESTABLISHED") Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
mj22226
pushed a commit
to mj22226/linux
that referenced
this pull request
Sep 11, 2023
[ Upstream commit 7f74563 ] LE Create CIS command shall not be sent before all CIS Established events from its previous invocation have been processed. Currently it is sent via hci_sync but that only waits for the first event, but there can be multiple. Make it wait for all events, and simplify the CIS creation as follows: Add new flag HCI_CONN_CREATE_CIS, which is set if Create CIS has been sent for the connection but it is not yet completed. Make BT_CONNECT state to mean the connection wants Create CIS. On events after which new Create CIS may need to be sent, send it if possible and some connections need it. These events are: hci_connect_cis, iso_connect_cfm, hci_cs_le_create_cis, hci_le_cis_estabilished_evt. The Create CIS status/completion events shall queue new Create CIS only if at least one of the connections transitions away from BT_CONNECT, so that we don't loop if controller is sending bogus events. This fixes sending multiple CIS Create for the same CIS in the "ISO AC 6(i) - Success" BlueZ test case: < HCI Command: LE Create Co.. (0x08|0x0064) plen 9 torvalds#129 [hci0] Number of CIS: 2 CIS Handle: 257 ACL Handle: 42 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 torvalds#130 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 29 torvalds#131 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 257 ... < HCI Command: LE Setup Is.. (0x08|0x006e) plen 13 torvalds#132 [hci0] ... > HCI Event: Command Complete (0x0e) plen 6 torvalds#133 [hci0] LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1 ... < HCI Command: LE Create Co.. (0x08|0x0064) plen 5 torvalds#134 [hci0] Number of CIS: 1 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 torvalds#135 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: ACL Connection Already Exists (0x0b) > HCI Event: LE Meta Event (0x3e) plen 29 torvalds#136 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 258 ... Fixes: c09b80b ("Bluetooth: hci_conn: Fix not waiting for HCI_EVT_LE_CIS_ESTABLISHED") Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
intersectRaven
pushed a commit
to intersectRaven/linux
that referenced
this pull request
Sep 13, 2023
[ Upstream commit 7f74563 ] LE Create CIS command shall not be sent before all CIS Established events from its previous invocation have been processed. Currently it is sent via hci_sync but that only waits for the first event, but there can be multiple. Make it wait for all events, and simplify the CIS creation as follows: Add new flag HCI_CONN_CREATE_CIS, which is set if Create CIS has been sent for the connection but it is not yet completed. Make BT_CONNECT state to mean the connection wants Create CIS. On events after which new Create CIS may need to be sent, send it if possible and some connections need it. These events are: hci_connect_cis, iso_connect_cfm, hci_cs_le_create_cis, hci_le_cis_estabilished_evt. The Create CIS status/completion events shall queue new Create CIS only if at least one of the connections transitions away from BT_CONNECT, so that we don't loop if controller is sending bogus events. This fixes sending multiple CIS Create for the same CIS in the "ISO AC 6(i) - Success" BlueZ test case: < HCI Command: LE Create Co.. (0x08|0x0064) plen 9 torvalds#129 [hci0] Number of CIS: 2 CIS Handle: 257 ACL Handle: 42 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 torvalds#130 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 29 torvalds#131 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 257 ... < HCI Command: LE Setup Is.. (0x08|0x006e) plen 13 torvalds#132 [hci0] ... > HCI Event: Command Complete (0x0e) plen 6 torvalds#133 [hci0] LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1 ... < HCI Command: LE Create Co.. (0x08|0x0064) plen 5 torvalds#134 [hci0] Number of CIS: 1 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 torvalds#135 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: ACL Connection Already Exists (0x0b) > HCI Event: LE Meta Event (0x3e) plen 29 torvalds#136 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 258 ... Fixes: c09b80b ("Bluetooth: hci_conn: Fix not waiting for HCI_EVT_LE_CIS_ESTABLISHED") Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
hjl-tools
pushed a commit
to hjl-tools/linux
that referenced
this pull request
Sep 13, 2023
[ Upstream commit 7f74563 ] LE Create CIS command shall not be sent before all CIS Established events from its previous invocation have been processed. Currently it is sent via hci_sync but that only waits for the first event, but there can be multiple. Make it wait for all events, and simplify the CIS creation as follows: Add new flag HCI_CONN_CREATE_CIS, which is set if Create CIS has been sent for the connection but it is not yet completed. Make BT_CONNECT state to mean the connection wants Create CIS. On events after which new Create CIS may need to be sent, send it if possible and some connections need it. These events are: hci_connect_cis, iso_connect_cfm, hci_cs_le_create_cis, hci_le_cis_estabilished_evt. The Create CIS status/completion events shall queue new Create CIS only if at least one of the connections transitions away from BT_CONNECT, so that we don't loop if controller is sending bogus events. This fixes sending multiple CIS Create for the same CIS in the "ISO AC 6(i) - Success" BlueZ test case: < HCI Command: LE Create Co.. (0x08|0x0064) plen 9 torvalds#129 [hci0] Number of CIS: 2 CIS Handle: 257 ACL Handle: 42 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 torvalds#130 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 29 torvalds#131 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 257 ... < HCI Command: LE Setup Is.. (0x08|0x006e) plen 13 torvalds#132 [hci0] ... > HCI Event: Command Complete (0x0e) plen 6 torvalds#133 [hci0] LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1 ... < HCI Command: LE Create Co.. (0x08|0x0064) plen 5 torvalds#134 [hci0] Number of CIS: 1 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 torvalds#135 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: ACL Connection Already Exists (0x0b) > HCI Event: LE Meta Event (0x3e) plen 29 torvalds#136 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 258 ... Fixes: c09b80b ("Bluetooth: hci_conn: Fix not waiting for HCI_EVT_LE_CIS_ESTABLISHED") Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
Joshua-Riek
pushed a commit
to Joshua-Riek/linux
that referenced
this pull request
Oct 24, 2023
BugLink: https://bugs.launchpad.net/bugs/2035588 [ Upstream commit 7f74563 ] LE Create CIS command shall not be sent before all CIS Established events from its previous invocation have been processed. Currently it is sent via hci_sync but that only waits for the first event, but there can be multiple. Make it wait for all events, and simplify the CIS creation as follows: Add new flag HCI_CONN_CREATE_CIS, which is set if Create CIS has been sent for the connection but it is not yet completed. Make BT_CONNECT state to mean the connection wants Create CIS. On events after which new Create CIS may need to be sent, send it if possible and some connections need it. These events are: hci_connect_cis, iso_connect_cfm, hci_cs_le_create_cis, hci_le_cis_estabilished_evt. The Create CIS status/completion events shall queue new Create CIS only if at least one of the connections transitions away from BT_CONNECT, so that we don't loop if controller is sending bogus events. This fixes sending multiple CIS Create for the same CIS in the "ISO AC 6(i) - Success" BlueZ test case: < HCI Command: LE Create Co.. (0x08|0x0064) plen 9 torvalds#129 [hci0] Number of CIS: 2 CIS Handle: 257 ACL Handle: 42 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 torvalds#130 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 29 torvalds#131 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 257 ... < HCI Command: LE Setup Is.. (0x08|0x006e) plen 13 torvalds#132 [hci0] ... > HCI Event: Command Complete (0x0e) plen 6 torvalds#133 [hci0] LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1 ... < HCI Command: LE Create Co.. (0x08|0x0064) plen 5 torvalds#134 [hci0] Number of CIS: 1 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 torvalds#135 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: ACL Connection Already Exists (0x0b) > HCI Event: LE Meta Event (0x3e) plen 29 torvalds#136 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 258 ... Fixes: c09b80b ("Bluetooth: hci_conn: Fix not waiting for HCI_EVT_LE_CIS_ESTABLISHED") Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
nathanlynch
added a commit
to nathanlynch/linux
that referenced
this pull request
Oct 27, 2023
This reverts commit 0298609 due to a boot-time oops: BUG: Kernel NULL pointer dereference on read at 0x00000018 Faulting instruction address: 0xc00000000004223c Oops: Kernel access of bad area, sig: 7 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries Modules linked in: CPU: 0 PID: 0 Comm: swapper Tainted: G W 6.6.0-rc2+ torvalds#129 NIP: c00000000004223c LR: c000000000042238 CTR: 0000000000000000 REGS: c000000002c579d0 TRAP: 0300 Tainted: G W (6.6.0-rc2+) MSR: 8000000000001033 <SF,ME,IR,DR,RI,LE> CR: 28000284 XER: 00000000 CFAR: c000000000042008 DAR: 0000000000000018 DSISR: 00080000 IRQMASK: 3 GPR00: c000000000042238 c000000002c57c70 c000000001f5eb00 0000000000000000 GPR04: c00000000294cd08 0000000000000002 c000000002c579b4 0000000000000000 GPR08: 0000000000000000 0000000000000002 c000000002c0da80 0000000000000000 GPR12: 0000000000000000 c000000005e40000 0000000000000000 0000000002097728 GPR16: 0000000000001111 0000000000000001 0000000002097b80 00000000020975b8 GPR20: 00000000020976f0 00000000020974e8 00000000030feb00 00000000030feb00 GPR24: 0000000000002008 0000000000000000 0000000000000001 c0000000028f3d70 GPR28: 0000000002d31020 c000000002cac268 c000000002d31020 0000000000000000 NIP [c00000000004223c] do_enter_rtas+0xcc/0x460 LR [c000000000042238] do_enter_rtas+0xc8/0x460 Call Trace: [c000000002c57c70] [c000000000042238] do_enter_rtas+0xc8/0x460 (unreliable) [c000000002c57cc0] [c000000000042e34] rtas_call+0x434/0x490 [c000000002c57d20] [c0000000000fd584] papr_sysparm_get+0xe4/0x230 [c000000002c57db0] [c0000000020267d0] pSeries_probe+0x2f0/0x5fc [c000000002c57e80] [c00000000200a318] setup_arch+0x11c/0x524 [c000000002c57f10] [c00000000200418c] start_kernel+0xcc/0xc1c [c000000002c57fe0] [c00000000000e788] start_here_common+0x1c/0x20
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Dec 17, 2023
…egdef.h The script checkpatch.pl reported spelling error in rtl871x_mp_phy_regdef.h as below: ''' WARNING: 'Tranceiver' may be misspelled - perhaps 'Transceiver'? torvalds#129: #define rFPGA0_XA_LSSIReadBack 0x8a0 /* Tranceiver LSSI Readback */ ^^^^^^^^^^ ''' This patch corrects a spelling error, changing "Tranceiver" to "Transceiver." Signed-off-by: Dipendra Khadka <kdipendra88@gmail.com>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Dec 18, 2023
…egdef.h The script checkpatch.pl reported spelling error in rtl871x_mp_phy_regdef.h as below: ''' WARNING: 'Tranceiver' may be misspelled - perhaps 'Transceiver'? torvalds#129: #define rFPGA0_XA_LSSIReadBack 0x8a0 /* Tranceiver LSSI Readback */ ^^^^^^^^^^ ''' This patch corrects a spelling error, changing "Tranceiver" to "Transceiver." Signed-off-by: Dipendra Khadka <kdipendra88@gmail.com> Link: https://lore.kernel.org/r/20231217165444.448133-1-kdipendra88@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
MingcongBai
pushed a commit
to AOSC-Tracking/linux
that referenced
this pull request
Dec 24, 2023
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs") for s390x, add support for 64-bit pointers to kfuncs for LoongArch. Since the infrastructure is already implemented in BPF core, the only thing need to be done is to override bpf_jit_supports_far_kfunc_call(). Before this change, several test_verifier tests failed: # ./test_verifier | grep # | grep FAIL torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL This is because the kfuncs in the loaded module are far away from __bpf_call_base: ffff800002009440 t bpf_kfunc_call_test_fail1 [bpf_testmod] 9000000002e128d8 T __bpf_call_base The offset relative to __bpf_call_base does NOT fit in s32, which breaks the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts this limit. Note that to reproduce the above result, tools/testing/selftests/bpf/config should be applied, and run the test with JIT enabled, unpriv BPF enabled. With this change, the test_verifier tests now all passed: # ./test_verifier ... Summary: 777 PASSED, 0 SKIPPED, 0 FAILED Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
shikongzhineng
pushed a commit
to shikongzhineng/linux
that referenced
this pull request
Dec 28, 2023
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs") for s390x, add support for 64-bit pointers to kfuncs for LoongArch. Since the infrastructure is already implemented in BPF core, the only thing need to be done is to override bpf_jit_supports_far_kfunc_call(). Before this change, several test_verifier tests failed: # ./test_verifier | grep # | grep FAIL torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL This is because the kfuncs in the loaded module are far away from __bpf_call_base: ffff800002009440 t bpf_kfunc_call_test_fail1 [bpf_testmod] 9000000002e128d8 T __bpf_call_base The offset relative to __bpf_call_base does NOT fit in s32, which breaks the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts this limit. Note that to reproduce the above result, tools/testing/selftests/bpf/config should be applied, and run the test with JIT enabled, unpriv BPF enabled. With this change, the test_verifier tests now all passed: # ./test_verifier ... Summary: 777 PASSED, 0 SKIPPED, 0 FAILED Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
yetist
pushed a commit
to loongarchlinux/linux
that referenced
this pull request
Jan 9, 2024
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs") for s390x, add support for 64-bit pointers to kfuncs for LoongArch. Since the infrastructure is already implemented in BPF core, the only thing need to be done is to override bpf_jit_supports_far_kfunc_call(). Before this change, several test_verifier tests failed: # ./test_verifier | grep # | grep FAIL torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL This is because the kfuncs in the loaded module are far away from __bpf_call_base: ffff800002009440 t bpf_kfunc_call_test_fail1 [bpf_testmod] 9000000002e128d8 T __bpf_call_base The offset relative to __bpf_call_base does NOT fit in s32, which breaks the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts this limit. Note that to reproduce the above result, tools/testing/selftests/bpf/config should be applied, and run the test with JIT enabled, unpriv BPF enabled. With this change, the test_verifier tests now all passed: # ./test_verifier ... Summary: 777 PASSED, 0 SKIPPED, 0 FAILED Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Jan 9, 2024
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs") for s390x, add support for 64-bit pointers to kfuncs for LoongArch. Since the infrastructure is already implemented in BPF core, the only thing need to be done is to override bpf_jit_supports_far_kfunc_call(). Before this change, several test_verifier tests failed: # ./test_verifier | grep # | grep FAIL torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL This is because the kfuncs in the loaded module are far away from __bpf_call_base: ffff800002009440 t bpf_kfunc_call_test_fail1 [bpf_testmod] 9000000002e128d8 T __bpf_call_base The offset relative to __bpf_call_base does NOT fit in s32, which breaks the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts this limit. Note that to reproduce the above result, tools/testing/selftests/bpf/config should be applied, and run the test with JIT enabled, unpriv BPF enabled. With this change, the test_verifier tests now all passed: # ./test_verifier ... Summary: 777 PASSED, 0 SKIPPED, 0 FAILED Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
arinc9
pushed a commit
to arinc9/linux
that referenced
this pull request
Jan 10, 2024
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs") for s390x, add support for 64-bit pointers to kfuncs for LoongArch. Since the infrastructure is already implemented in BPF core, the only thing need to be done is to override bpf_jit_supports_far_kfunc_call(). Before this change, several test_verifier tests failed: # ./test_verifier | grep # | grep FAIL torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL This is because the kfuncs in the loaded module are far away from __bpf_call_base: ffff800002009440 t bpf_kfunc_call_test_fail1 [bpf_testmod] 9000000002e128d8 T __bpf_call_base The offset relative to __bpf_call_base does NOT fit in s32, which breaks the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts this limit. Note that to reproduce the above result, tools/testing/selftests/bpf/config should be applied, and run the test with JIT enabled, unpriv BPF enabled. With this change, the test_verifier tests now all passed: # ./test_verifier ... Summary: 777 PASSED, 0 SKIPPED, 0 FAILED Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
shikongzhineng
pushed a commit
to shikongzhineng/linux
that referenced
this pull request
Jan 10, 2024
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs") for s390x, add support for 64-bit pointers to kfuncs for LoongArch. Since the infrastructure is already implemented in BPF core, the only thing need to be done is to override bpf_jit_supports_far_kfunc_call(). Before this change, several test_verifier tests failed: # ./test_verifier | grep # | grep FAIL torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL This is because the kfuncs in the loaded module are far away from __bpf_call_base: ffff800002009440 t bpf_kfunc_call_test_fail1 [bpf_testmod] 9000000002e128d8 T __bpf_call_base The offset relative to __bpf_call_base does NOT fit in s32, which breaks the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts this limit. Note that to reproduce the above result, tools/testing/selftests/bpf/config should be applied, and run the test with JIT enabled, unpriv BPF enabled. With this change, the test_verifier tests now all passed: # ./test_verifier ... Summary: 777 PASSED, 0 SKIPPED, 0 FAILED Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Gelbpunkt
pushed a commit
to sm8450-mainline/linux
that referenced
this pull request
Jan 11, 2024
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs") for s390x, add support for 64-bit pointers to kfuncs for LoongArch. Since the infrastructure is already implemented in BPF core, the only thing need to be done is to override bpf_jit_supports_far_kfunc_call(). Before this change, several test_verifier tests failed: # ./test_verifier | grep # | grep FAIL torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL This is because the kfuncs in the loaded module are far away from __bpf_call_base: ffff800002009440 t bpf_kfunc_call_test_fail1 [bpf_testmod] 9000000002e128d8 T __bpf_call_base The offset relative to __bpf_call_base does NOT fit in s32, which breaks the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts this limit. Note that to reproduce the above result, tools/testing/selftests/bpf/config should be applied, and run the test with JIT enabled, unpriv BPF enabled. With this change, the test_verifier tests now all passed: # ./test_verifier ... Summary: 777 PASSED, 0 SKIPPED, 0 FAILED Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Jan 12, 2024
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs") for s390x, add support for 64-bit pointers to kfuncs for LoongArch. Since the infrastructure is already implemented in BPF core, the only thing need to be done is to override bpf_jit_supports_far_kfunc_call(). Before this change, several test_verifier tests failed: # ./test_verifier | grep # | grep FAIL torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL This is because the kfuncs in the loaded module are far away from __bpf_call_base: ffff800002009440 t bpf_kfunc_call_test_fail1 [bpf_testmod] 9000000002e128d8 T __bpf_call_base The offset relative to __bpf_call_base does NOT fit in s32, which breaks the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts this limit. Note that to reproduce the above result, tools/testing/selftests/bpf/config should be applied, and run the test with JIT enabled, unpriv BPF enabled. With this change, the test_verifier tests now all passed: # ./test_verifier ... Summary: 777 PASSED, 0 SKIPPED, 0 FAILED Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
cthbleachbit
pushed a commit
to AOSC-Tracking/linux
that referenced
this pull request
Jan 17, 2024
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs") for s390x, add support for 64-bit pointers to kfuncs for LoongArch. Since the infrastructure is already implemented in BPF core, the only thing need to be done is to override bpf_jit_supports_far_kfunc_call(). Before this change, several test_verifier tests failed: # ./test_verifier | grep # | grep FAIL torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL This is because the kfuncs in the loaded module are far away from __bpf_call_base: ffff800002009440 t bpf_kfunc_call_test_fail1 [bpf_testmod] 9000000002e128d8 T __bpf_call_base The offset relative to __bpf_call_base does NOT fit in s32, which breaks the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts this limit. Note that to reproduce the above result, tools/testing/selftests/bpf/config should be applied, and run the test with JIT enabled, unpriv BPF enabled. With this change, the test_verifier tests now all passed: # ./test_verifier ... Summary: 777 PASSED, 0 SKIPPED, 0 FAILED Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
cthbleachbit
pushed a commit
to AOSC-Tracking/linux
that referenced
this pull request
Jan 17, 2024
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs") for s390x, add support for 64-bit pointers to kfuncs for LoongArch. Since the infrastructure is already implemented in BPF core, the only thing need to be done is to override bpf_jit_supports_far_kfunc_call(). Before this change, several test_verifier tests failed: # ./test_verifier | grep # | grep FAIL torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL This is because the kfuncs in the loaded module are far away from __bpf_call_base: ffff800002009440 t bpf_kfunc_call_test_fail1 [bpf_testmod] 9000000002e128d8 T __bpf_call_base The offset relative to __bpf_call_base does NOT fit in s32, which breaks the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts this limit. Note that to reproduce the above result, tools/testing/selftests/bpf/config should be applied, and run the test with JIT enabled, unpriv BPF enabled. With this change, the test_verifier tests now all passed: # ./test_verifier ... Summary: 777 PASSED, 0 SKIPPED, 0 FAILED Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
roxell
pushed a commit
to roxell/linux
that referenced
this pull request
Jan 17, 2024
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs") for s390x, add support for 64-bit pointers to kfuncs for LoongArch. Since the infrastructure is already implemented in BPF core, the only thing need to be done is to override bpf_jit_supports_far_kfunc_call(). Before this change, several test_verifier tests failed: # ./test_verifier | grep # | grep FAIL torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL This is because the kfuncs in the loaded module are far away from __bpf_call_base: ffff800002009440 t bpf_kfunc_call_test_fail1 [bpf_testmod] 9000000002e128d8 T __bpf_call_base The offset relative to __bpf_call_base does NOT fit in s32, which breaks the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts this limit. Note that to reproduce the above result, tools/testing/selftests/bpf/config should be applied, and run the test with JIT enabled, unpriv BPF enabled. With this change, the test_verifier tests now all passed: # ./test_verifier ... Summary: 777 PASSED, 0 SKIPPED, 0 FAILED Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
cthbleachbit
pushed a commit
to AOSC-Tracking/linux
that referenced
this pull request
Jan 17, 2024
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs") for s390x, add support for 64-bit pointers to kfuncs for LoongArch. Since the infrastructure is already implemented in BPF core, the only thing need to be done is to override bpf_jit_supports_far_kfunc_call(). Before this change, several test_verifier tests failed: # ./test_verifier | grep # | grep FAIL torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL This is because the kfuncs in the loaded module are far away from __bpf_call_base: ffff800002009440 t bpf_kfunc_call_test_fail1 [bpf_testmod] 9000000002e128d8 T __bpf_call_base The offset relative to __bpf_call_base does NOT fit in s32, which breaks the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts this limit. Note that to reproduce the above result, tools/testing/selftests/bpf/config should be applied, and run the test with JIT enabled, unpriv BPF enabled. With this change, the test_verifier tests now all passed: # ./test_verifier ... Summary: 777 PASSED, 0 SKIPPED, 0 FAILED Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Jan 18, 2024
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs") for s390x, add support for 64-bit pointers to kfuncs for LoongArch. Since the infrastructure is already implemented in BPF core, the only thing need to be done is to override bpf_jit_supports_far_kfunc_call(). Before this change, several test_verifier tests failed: # ./test_verifier | grep # | grep FAIL torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL This is because the kfuncs in the loaded module are far away from __bpf_call_base: ffff800002009440 t bpf_kfunc_call_test_fail1 [bpf_testmod] 9000000002e128d8 T __bpf_call_base The offset relative to __bpf_call_base does NOT fit in s32, which breaks the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts this limit. Note that to reproduce the above result, tools/testing/selftests/bpf/config should be applied, and run the test with JIT enabled, unpriv BPF enabled. With this change, the test_verifier tests now all passed: # ./test_verifier ... Summary: 777 PASSED, 0 SKIPPED, 0 FAILED Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
cthbleachbit
pushed a commit
to AOSC-Tracking/linux
that referenced
this pull request
Jan 28, 2024
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs") for s390x, add support for 64-bit pointers to kfuncs for LoongArch. Since the infrastructure is already implemented in BPF core, the only thing need to be done is to override bpf_jit_supports_far_kfunc_call(). Before this change, several test_verifier tests failed: # ./test_verifier | grep # | grep FAIL torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL This is because the kfuncs in the loaded module are far away from __bpf_call_base: ffff800002009440 t bpf_kfunc_call_test_fail1 [bpf_testmod] 9000000002e128d8 T __bpf_call_base The offset relative to __bpf_call_base does NOT fit in s32, which breaks the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts this limit. Note that to reproduce the above result, tools/testing/selftests/bpf/config should be applied, and run the test with JIT enabled, unpriv BPF enabled. With this change, the test_verifier tests now all passed: # ./test_verifier ... Summary: 777 PASSED, 0 SKIPPED, 0 FAILED Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
shikongzhineng
pushed a commit
to shikongzhineng/linux
that referenced
this pull request
Feb 7, 2024
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs") for s390x, add support for 64-bit pointers to kfuncs for LoongArch. Since the infrastructure is already implemented in BPF core, the only thing need to be done is to override bpf_jit_supports_far_kfunc_call(). Before this change, several test_verifier tests failed: # ./test_verifier | grep # | grep FAIL torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL This is because the kfuncs in the loaded module are far away from __bpf_call_base: ffff800002009440 t bpf_kfunc_call_test_fail1 [bpf_testmod] 9000000002e128d8 T __bpf_call_base The offset relative to __bpf_call_base does NOT fit in s32, which breaks the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts this limit. Note that to reproduce the above result, tools/testing/selftests/bpf/config should be applied, and run the test with JIT enabled, unpriv BPF enabled. With this change, the test_verifier tests now all passed: # ./test_verifier ... Summary: 777 PASSED, 0 SKIPPED, 0 FAILED Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
cthbleachbit
pushed a commit
to AOSC-Tracking/linux
that referenced
this pull request
Feb 17, 2024
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs") for s390x, add support for 64-bit pointers to kfuncs for LoongArch. Since the infrastructure is already implemented in BPF core, the only thing need to be done is to override bpf_jit_supports_far_kfunc_call(). Before this change, several test_verifier tests failed: # ./test_verifier | grep # | grep FAIL torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL This is because the kfuncs in the loaded module are far away from __bpf_call_base: ffff800002009440 t bpf_kfunc_call_test_fail1 [bpf_testmod] 9000000002e128d8 T __bpf_call_base The offset relative to __bpf_call_base does NOT fit in s32, which breaks the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts this limit. Note that to reproduce the above result, tools/testing/selftests/bpf/config should be applied, and run the test with JIT enabled, unpriv BPF enabled. With this change, the test_verifier tests now all passed: # ./test_verifier ... Summary: 777 PASSED, 0 SKIPPED, 0 FAILED Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
yetist
pushed a commit
to loongarchlinux/linux
that referenced
this pull request
Feb 29, 2024
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs") for s390x, add support for 64-bit pointers to kfuncs for LoongArch. Since the infrastructure is already implemented in BPF core, the only thing need to be done is to override bpf_jit_supports_far_kfunc_call(). Before this change, several test_verifier tests failed: # ./test_verifier | grep # | grep FAIL torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL This is because the kfuncs in the loaded module are far away from __bpf_call_base: ffff800002009440 t bpf_kfunc_call_test_fail1 [bpf_testmod] 9000000002e128d8 T __bpf_call_base The offset relative to __bpf_call_base does NOT fit in s32, which breaks the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts this limit. Note that to reproduce the above result, tools/testing/selftests/bpf/config should be applied, and run the test with JIT enabled, unpriv BPF enabled. With this change, the test_verifier tests now all passed: # ./test_verifier ... Summary: 777 PASSED, 0 SKIPPED, 0 FAILED Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
shikongzhineng
pushed a commit
to shikongzhineng/linux
that referenced
this pull request
Mar 17, 2024
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs") for s390x, add support for 64-bit pointers to kfuncs for LoongArch. Since the infrastructure is already implemented in BPF core, the only thing need to be done is to override bpf_jit_supports_far_kfunc_call(). Before this change, several test_verifier tests failed: # ./test_verifier | grep # | grep FAIL torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL This is because the kfuncs in the loaded module are far away from __bpf_call_base: ffff800002009440 t bpf_kfunc_call_test_fail1 [bpf_testmod] 9000000002e128d8 T __bpf_call_base The offset relative to __bpf_call_base does NOT fit in s32, which breaks the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts this limit. Note that to reproduce the above result, tools/testing/selftests/bpf/config should be applied, and run the test with JIT enabled, unpriv BPF enabled. With this change, the test_verifier tests now all passed: # ./test_verifier ... Summary: 777 PASSED, 0 SKIPPED, 0 FAILED Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
shipujin
pushed a commit
to shipujin/linux
that referenced
this pull request
Jul 24, 2024
Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs") for s390x, add support for 64-bit pointers to kfuncs for LoongArch. Since the infrastructure is already implemented in BPF core, the only thing need to be done is to override bpf_jit_supports_far_kfunc_call(). Before this change, several test_verifier tests failed: # ./test_verifier | grep # | grep FAIL torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL This is because the kfuncs in the loaded module are far away from __bpf_call_base: ffff800002009440 t bpf_kfunc_call_test_fail1 [bpf_testmod] 9000000002e128d8 T __bpf_call_base The offset relative to __bpf_call_base does NOT fit in s32, which breaks the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts this limit. Note that to reproduce the above result, tools/testing/selftests/bpf/config should be applied, and run the test with JIT enabled, unpriv BPF enabled. With this change, the test_verifier tests now all passed: # ./test_verifier ... Summary: 777 PASSED, 0 SKIPPED, 0 FAILED Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
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.
Surface Pro 3 Type Cover that works with Ubuntu (and possibly Arch) from this thread. Both trackpad and keyboard work after compiling my own kernel.
http://ubuntuforums.org/showthread.php?t=2231207&page=2&s=44910e0c56047e4f93dfd9fea58121ef
This is the first time I'm submitting a pull request to the linux kernel, please point out any mistakes if I made any.