On Wed, Mar 10, 2021 at 8:23 AM Jiapeng Chong
wrote:
>
> Fix the following coccicheck warning:
>
> ./tools/testing/selftests/bpf/progs/test_global_func10.c:17:12-13:
> WARNING comparing pointer to 0.
but it's ok from the C standard point of view
>
> Reported-by: Abaci Robot
> Signed-off-by:
Hi, Jean-Philippe!
>>>>> On Wed, 16 Sep 2020 15:17:02 +0200, Jean-Philippe Brucker wrote:
> On Wed, Sep 16, 2020 at 03:39:37PM +0300, Yauheni Kaliuta wrote:
>> If you start to amend extables, could you consider a change like
>>
>> 05a68e892e89 ("
+0x40/0xdec
> [ 575.437822] bpf_dispatcher_xdp_func+0x10/0x1c
> [ 575.442265] bpf_test_run+0x80/0x240
> [ 575.445838] bpf_prog_test_run_xdp+0xe8/0x190
> [ 575.450196] __do_sys_bpf+0x8e8/0x1b00
> [ 575.453943] __arm64_sys_bpf+0x24/0x510
> [ 575.457780] el0_svc_common.constprop.0+0x6c/0x170
> [ 575.462570] do_el0_svc+0x24/0x90
> [ 575.465883] el0_sync_handler+0x90/0x19c
> [ 575.469802] el0_sync+0x158/0x180
> [ 575.473118] Code: d4202000 d4202000 d4202000 d4202000 (d4202000)
> [ 575.479211] ---[ end trace 8cd54c7d5c0ffda4 ]---
> Cheers
> /Ilias
--
WBR,
Yauheni Kaliuta
Hi, Shuah!
>>>>> On Fri, 10 Jul 2020 08:18:49 -0600, Shuah Khan wrote:
> On 7/10/20 12:02 AM, Yauheni Kaliuta wrote:
>> On Thu, Jul 9, 2020 at 6:36 PM Shuah Khan wrote:
>>>
>>> On 7/9/20 12:49 AM, kernel test robot wrote:
>>>> Greet
On Thu, Jul 9, 2020 at 6:36 PM Shuah Khan wrote:
>
> On 7/9/20 12:49 AM, kernel test robot wrote:
> > Greeting,
> >
> > FYI, we noticed the following commit (built with gcc-9):
> >
> > commit: 7cb32086e59b514a832a3e11f5370d37e7cfe022 ("selftests: simplify
> > run_tests")
> >
__builtin_memset(p, c, size);
| ^~~~
since gcc is aware of the field sizes of the structure.
Blind gcc treating the structure as a byte array and calculate
positions with offsetof().
Suggested-by: Ed Kellett
Signed-off-by: Yauheni Kaliuta
---
arch/x86/include/asm
Hi, Daniel,
On Tue, Jun 25, 2019 at 12:39 PM Daniel Borkmann wrote:
>
> On 06/25/2019 10:29 AM, Yauheni Kaliuta wrote:
> > Hi!
> >
> > I'm wondering, how the sanitaion tests (#903 5.2-rc6 for example)
> > are supposed to work on BE arches:
> >
> > {
Hi, Jiong!
>>>>> On Tue, 25 Jun 2019 11:20:07 +0100, Jiong Wang wrote:
> Yauheni Kaliuta writes:
>> Hi!
>>
>> Looks like the code:
>>
>> ALU_ARSH_X:
>> DST = (u64) (u32) ((*(s32 *) ) >> SRC);
>> CONT;
&
rts of 64bit registers.
See failure of test_verifier test 'arsh32 on imm 2' (#23 on
5.2-rc6).
--
WBR,
Yauheni Kaliuta
BPF_ALU64_REG(BPF_ADD, BPF_REG_2, BPF_REG_3),
BPF_MOV64_REG(BPF_REG_0, BPF_REG_2),
BPF_EXIT_INSN(),
},
.fixup_map_array_48b = { 1 },
.result = ACCEPT,
.retval = 0x10,
},
--
WBR,
Yauheni Kaliuta
Commit-ID: 0fcff1715bec7593a0ba86f3fef46cd89af37a8b
Gitweb: https://git.kernel.org/tip/0fcff1715bec7593a0ba86f3fef46cd89af37a8b
Author: Yauheni Kaliuta
AuthorDate: Mon, 16 Jul 2018 11:06:04 -0700
Committer: Ingo Molnar
CommitDate: Tue, 17 Jul 2018 09:30:35 +0200
tools/memory-model
Commit-ID: 0fcff1715bec7593a0ba86f3fef46cd89af37a8b
Gitweb: https://git.kernel.org/tip/0fcff1715bec7593a0ba86f3fef46cd89af37a8b
Author: Yauheni Kaliuta
AuthorDate: Mon, 16 Jul 2018 11:06:04 -0700
Committer: Ingo Molnar
CommitDate: Tue, 17 Jul 2018 09:30:35 +0200
tools/memory-model
task_group_account_field() uses __this_cpu_add() which will be
wrong for offloading.
For testing I used kcpustat_cpu(task_cpu(p)) in
task_group_account_field() and added call account_user_time(curr, delta)
to the sched_tick_remote() what fixes it for me, but what would be the
proper fix?
--
WBR,
Yauheni Kaliuta
task_group_account_field() uses __this_cpu_add() which will be
wrong for offloading.
For testing I used kcpustat_cpu(task_cpu(p)) in
task_group_account_field() and added call account_user_time(curr, delta)
to the sched_tick_remote() what fixes it for me, but what would be the
proper fix?
--
WBR,
Yauheni Kaliuta
Hi, Ard!
>>>>> On Wed, 19 Jul 2017 20:10:17 +0100, Ard Biesheuvel wrote:
> On 19 July 2017 at 20:04, Yauheni Kaliuta <yauheni.kali...@redhat.com> wrote:
>> Hi, Lucas!
>>
>>>>>>> On Wed, 19 Jul 2017 10:51:44 -0700, Lucas De Marc
Hi, Ard!
>>>>> On Wed, 19 Jul 2017 20:10:17 +0100, Ard Biesheuvel wrote:
> On 19 July 2017 at 20:04, Yauheni Kaliuta wrote:
>> Hi, Lucas!
>>
>>>>>>> On Wed, 19 Jul 2017 10:51:44 -0700, Lucas De Marchi wrote:
>> > O
Hi, Lucas!
>>>>> On Wed, 19 Jul 2017 10:51:44 -0700, Lucas De Marchi wrote:
> On Wed, Jul 19, 2017 at 7:56 AM, Yauheni Kaliuta
> <yauheni.kali...@redhat.com> wrote:
>> Normally exported symbol's crc is stored as absolute (SHN_ABS)
>> value of spe
Hi, Lucas!
>>>>> On Wed, 19 Jul 2017 10:51:44 -0700, Lucas De Marchi wrote:
> On Wed, Jul 19, 2017 at 7:56 AM, Yauheni Kaliuta
> wrote:
>> Normally exported symbol's crc is stored as absolute (SHN_ABS)
>> value of special named symbol __crc_.
>>
&
description of the commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=56067812d5b0e737ac2063e94a50f76b810d6ca3
Add kmod support of this configuration.
Signed-off-by: Yauheni Kaliuta <yauheni.kali...@redhat.com>
---
libkmod/libkmod-elf.
description of the commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=56067812d5b0e737ac2063e94a50f76b810d6ca3
Add kmod support of this configuration.
Signed-off-by: Yauheni Kaliuta
---
libkmod/libkmod-elf.c | 30 +-
1 file changed
> is going to barf on these symlink cycles, too.
depmod checks for special names "build" and "source" to skip them.
I wonder if it worth to implement full symlink loop check.
--
WBR,
Yauheni Kaliuta
> is going to barf on these symlink cycles, too.
depmod checks for special names "build" and "source" to skip them.
I wonder if it worth to implement full symlink loop check.
--
WBR,
Yauheni Kaliuta
c, then NCM?
--
WBR,
Yauheni Kaliuta
c, then NCM?
--
WBR,
Yauheni Kaliuta
The patch instrument different places of resource limits checks with
reporting using the infrastructure from the previous patch.
Signed-off-by: Yauheni Kaliuta <yauheni.kali...@redhat.com>
---
arch/ia64/kernel/perfmon.c | 4 +++-
arch/powerpc/kvm/book3s_64_vio.c
The patch instrument different places of resource limits checks with
reporting using the infrastructure from the previous patch.
Signed-off-by: Yauheni Kaliuta
---
arch/ia64/kernel/perfmon.c | 4 +++-
arch/powerpc/kvm/book3s_64_vio.c | 6 --
arch/powerpc/mm
http://marc.info/?l=linux-kernel=147211966914100=2 follow up.
More complete rlimits violations reporting RFC using tracing
infrastructure.
Yauheni Kaliuta (2):
rlimits: add infra to report violations
rlimits: report resource limits violations
arch/ia64/kernel/perfmon.c
The patch defines tracepoints for resource limits (rlimits) violations
reporting and adds a thin layer to be called from rlimits aware code
without direct dependency of the tracepoints.
Signed-off-by: Yauheni Kaliuta <yauheni.kali...@redhat.com>
---
include/linux/resource.h | 5 +++
http://marc.info/?l=linux-kernel=147211966914100=2 follow up.
More complete rlimits violations reporting RFC using tracing
infrastructure.
Yauheni Kaliuta (2):
rlimits: add infra to report violations
rlimits: report resource limits violations
arch/ia64/kernel/perfmon.c
The patch defines tracepoints for resource limits (rlimits) violations
reporting and adds a thin layer to be called from rlimits aware code
without direct dependency of the tracepoints.
Signed-off-by: Yauheni Kaliuta
---
include/linux/resource.h | 5 +++
kernel/Makefile | 4
erf/tools/perf/ex
> Missing separate debuginfos, use: dnf debuginfo-install
> glibc-2.21-13.fc22.x86_64
> Breakpoint 1, func (par=1) at ex.c:5
> 5 return par;
> I'm clearly missing something..
> thanks for help,
> jirka
> ---
> kernel version: 4.8.0-rc2
> perf version: latest Arnaldo's perf/core
--
WBR,
Yauheni Kaliuta
erf/tools/perf/ex
> Missing separate debuginfos, use: dnf debuginfo-install
> glibc-2.21-13.fc22.x86_64
> Breakpoint 1, func (par=1) at ex.c:5
> 5 return par;
> I'm clearly missing something..
> thanks for help,
> jirka
> ---
> kernel version: 4.8.0-rc2
> perf version: latest Arnaldo's perf/core
--
WBR,
Yauheni Kaliuta
Hi, Jiri!
>>>>> On Wed, 24 Aug 2016 13:24:28 +0200, Jiri Olsa wrote:
> On Fri, Aug 19, 2016 at 05:41:20PM +0300, Yauheni Kaliuta wrote:
>>
>> At the moment there is no clear indication if a process exceeds resource
>> limit. In some cases the problematic
Hi, Jiri!
>>>>> On Wed, 24 Aug 2016 13:24:28 +0200, Jiri Olsa wrote:
> On Fri, Aug 19, 2016 at 05:41:20PM +0300, Yauheni Kaliuta wrote:
>>
>> At the moment there is no clear indication if a process exceeds resource
>> limit. In some cases the problematic
> -has->covered_end_pfn = start_pfn;
> -
> -return true;
> -
> +return 1;
> }
> -return false;
> +return 0;
> }
[...]
--
WBR,
Yauheni Kaliuta
> -has->covered_end_pfn = start_pfn;
> -
> -return true;
> -
> +return 1;
> }
> -return false;
> +return 0;
> }
[...]
--
WBR,
Yauheni Kaliuta
_TYPE_RLIMIT with own events and own record.
All perf changes will require some special userspace and/or perf utility
changes.
4) Something else.
So, any input about upstreamable way of the feature would be appreciated.
--
WBR,
Yauheni Kaliuta
_TYPE_RLIMIT with own events and own record.
All perf changes will require some special userspace and/or perf utility
changes.
4) Something else.
So, any input about upstreamable way of the feature would be appreciated.
--
WBR,
Yauheni Kaliuta
38 matches
Mail list logo
