The config fragment doesn't follow the correct format to enable those
config options which make the config options getting missed while
merging with other configs.
➜ merge_config.sh -m .config tools/testing/selftests/iommu/config
Using .config as base
Merging tools/testing/selftests/iommu/config
➜
On Thu, 22 Feb 2024 at 04:10, 'Justin Stitt' via KUnit Development
wrote:
>
> Hi,
>
> On Wed, Feb 21, 2024 at 05:27:15PM +0800, David Gow wrote:
> > The correct format specifier for p - n (both p and n are pointers) is
> > %td, as the type should be ptrdiff_t.
>
> I think %tu is better. d specifie
On Wed, 21 Feb 2024 at 21:05, Lucas De Marchi wrote:
>
> this has a potential to cause conflicts with upcoming work, so I think
> it's better to apply this through drm-xe-next. Let me know if you agree.
I disagree. Violently.
For this to be fixed, we need to have the printf format checking enabl
On Wed, Feb 21, 2024 at 05:27:21PM +0800, David Gow wrote:
KUNIT_FAIL() is used to fail the xe_migrate test when an error occurs.
However, there's a mismatch in the format specifier: '%li' is used to
log 'err', which is an 'int'.
Use '%i' instead of '%li', and for the case where we're printing a
Remove redundant "set up" comment and add check to ensure enough data is
swapped out (in swapin test) and zswapped-in.
Suggested-by: Yosry Ahmed
Signed-off-by: Nhat Pham
---
tools/testing/selftests/cgroup/test_zswap.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --gi
/lib/modules/?
> > > >>>
> > > >>
> > > >> This would be a regression to automated test rings. Do you have any
> > > >> other
> > > >> solutions?
> > > >
> > > > I would say that we could skip the t
les/?
> > >>>
> > >>
> > >> This would be a regression to automated test rings. Do you have any other
> > >> solutions?
> > >
> > > I would say that we could skip the these tests if kernel-devel package is
> > > not
> > > installed. Would it be acceptable? At least we would avoid such issues
> > > like this
> > > in the future as well.
> > >
> >
> > We have to check and skip build. Something we could do in the livepatch
> > Makefile. Can you send patch for this - I will oull this in for next
> > so we don't break test rings.
>
> I added a new patch in the same patchset that would cover this, skipping the
> build and test if kernel-devel is not installed. The patchset was sent earlier
> today. Please check if the new patch fixes things on the build robot.
Hi Shuah, Hi Marcos,
Sorry for this wrong report. The files are organized in a different way
in the bot and cause this issue. We have fixed the bot to explicitly
set KDIR to the correct path before building the selftests. The patch
[1] can also work well in bot's environment.
[1]
https://lore.kernel.org/all/20240221-lp-selftests-fixes-v2-2-a19be1e02...@suse.com/
Best Regards,
Yujie
On Tue, Feb 13, 2024 at 11:34:59AM +0100, David Hildenbrand wrote:
On 25.01.24 18:07, Deepak Gupta wrote:
On Thu, Jan 25, 2024 at 09:18:07AM +0100, David Hildenbrand wrote:
On 25.01.24 07:21, de...@rivosinc.com wrote:
From: Deepak Gupta
x86 has used VM_SHADOW_STACK (alias to VM_HIGH_ARCH_5)
On Fri, Feb 09, 2024 at 08:44:53PM +, Edgecombe, Rick P wrote:
On Wed, 2024-01-24 at 22:21 -0800, de...@rivosinc.com wrote:
From: Deepak Gupta
As discussed extensively in the changelog for the addition of this
syscall on x86 ("x86/shstk: Introduce map_shadow_stack syscall") the
existing mm
On Tuesday, 20 February 2024 01:01:59 CST Arnd Bergmann wrote:
> On Mon, Feb 19, 2024, at 23:38, Elizabeth Figura wrote:
> > NtWaitForMultipleObjects() can receive a timeout in two forms, relative or
> > absolute. Relative timeouts are unaffected by changes to the system time
> > and do
> > not co
On Tue, Feb 06, 2024 at 04:01:28PM +, Mark Brown wrote:
On Wed, Jan 24, 2024 at 10:21:40PM -0800, de...@rivosinc.com wrote:
As discussed extensively in the changelog for the addition of this
syscall on x86 ("x86/shstk: Introduce map_shadow_stack syscall") the
existing mmap() and madvise() s
On Tue, Feb 06, 2024 at 04:13:39PM +, Mark Brown wrote:
On Wed, Jan 24, 2024 at 10:21:43PM -0800, de...@rivosinc.com wrote:
To allow userspace to enable this feature for itself, following prtcls are
defined:
- PR_GET_INDIR_BR_LP_STATUS: Gets current configured status for indirect branch
On Fri, Feb 09, 2024 at 08:44:35PM +, Edgecombe, Rick P wrote:
On Wed, 2024-01-24 at 22:21 -0800, de...@rivosinc.com wrote:
+ /*
+ * PROT_SHADOWSTACK is a kernel only protection flag on risc-
v.
+ * mmap doesn't expect PROT_SHADOWSTACK to be set by user
space.
+ *
---
on arm64 KVM_CAP_GUEST_MEMDF capability is not enabled, but
guest_memfd_test can build on arm64, let's build it on arm64 as well.
Signed-off-by: Itaru Kitayama
---
tools/testing/selftests/kvm/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/testing/selftests/kvm/Makefile
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski :
On Thu, 15 Feb 2024 17:17:28 +0100 you wrote:
> There are multiple bugs in tls_sw_recvmsg's handling of record types
> when MSG_PEEK flag is used, which can lead to incorrectly merging two
> records:
> - consecutive non-
Replace deprecated 0-length array in struct bpf_lpm_trie_key with
flexible array. Found with GCC 13:
../kernel/bpf/lpm_trie.c:207:51: warning: array subscript i is outside array
bounds of 'const __u8[0]' {aka 'const unsigned char[]'} [-Warray-bounds=]
207 |
On Wed, 21 Feb 2024 14:12:00 -0700 Shuah Khan wrote:
> On 2/21/24 05:26, Marcos Paulo de Souza wrote:
> > On Tue, 20 Feb 2024 17:19:54 -0700 Shuah Khan
> > wrote:
> >
> >> On 2/19/24 06:53, Marcos Paulo de Souza wrote:
> >>> On Mon, 19 Feb 2024 09:15:15 -0300 Marcos Paulo de Souza
> >>> wrot
On Wed, Feb 21, 2024 at 05:39:55PM +0100, Daniel Borkmann wrote:
> The build in BPF CI is still broken, did you try to build selftests?
Okay, I give up. How is a mortal supposed to build these?
If I try to follow what I see in
https://github.com/libbpf/ci/blob/main/build-selftests/build_selftests
On Wed, Feb 21, 2024 at 05:39:55PM +0100, Daniel Borkmann wrote:
> On 2/20/24 7:54 PM, Kees Cook wrote:
> > Replace deprecated 0-length array in struct bpf_lpm_trie_key with
> > flexible array. Found with GCC 13:
> >
> > ../kernel/bpf/lpm_trie.c:207:51: warning: array subscript i is outside
> > a
Hi,
On Wed, Feb 21, 2024 at 05:27:20PM +0800, David Gow wrote:
> The drm_buddy_test's alloc_contiguous test used a u64 for the page size,
> which was then updated to be an 'unsigned long' to avoid 64-bit
> multiplication division helpers.
>
> However, the variable is logged by some KUNIT_ASSERT_EQ
Hi,
On Wed, Feb 21, 2024 at 05:27:19PM +0800, David Gow wrote:
> KUNIT_FAIL() accepts a printf-style format string, but previously did
> not let gcc validate it with the __printf() attribute. The use of %lld
> for the result of PTR_ERR() is not correct.
>
> Instead, use %pe and pass the actual err
On Wed, Feb 21, 2024 at 12:25 PM H.J. Lu wrote:
>
> On Wed, Feb 21, 2024 at 12:18 PM H.J. Lu wrote:
> >
> > On Wed, Feb 21, 2024 at 11:22 AM Edgecombe, Rick P
> > wrote:
> > >
> > > On Wed, 2024-02-21 at 14:06 -0500, dal...@libc.org wrote:
> > > > Due to arbitrarily nestable signal frames, no, t
From: Javier Carrasco
This binary is missing in the .gitignore and stays as an untracked file.
Link:
https://lore.kernel.org/r/20240214-damon_selftest_gitignore-v1-1-f517d0f9f...@gmail.com
Reported-by: Bernd Edlinger
Closes:
https://lore.kernel.org/all/as8p193mb1285c963658008f1b2702af7e4...@a
From: Vincenzo Mezzela
This patch resolves a spelling error in the test log, preventing potential
confusion.
It is submitted as part of my application to the "Linux Kernel
Bug Fixing Spring Unpaid 2024" mentorship program of the Linux
Foundation.
Link:
https://lore.kernel.org/r/20240204122523.
Resending misc fixes for DAMON selftets on behalf of the original
authors for more visibility and inclusion on mm tree.
The patches are same to their original versions, except added Links: for
the original posts, and Signed-off-by: of mine.
Javier Carrasco (1):
selftests: damon: add access_memo
Adrian Moreno writes:
> On 2/16/24 16:28, Aaron Conole wrote:
>> Normally a spawned process under OVS is given a SIGTERM when the test
>> ends as part of cleanup. However, in case the process is still lingering
>> for some reason, we also send a SIGKILL to force it down faster.
>> Signed-off-by:
On 2/21/24 05:26, Marcos Paulo de Souza wrote:
On Tue, 20 Feb 2024 17:19:54 -0700 Shuah Khan wrote:
On 2/19/24 06:53, Marcos Paulo de Souza wrote:
On Mon, 19 Feb 2024 09:15:15 -0300 Marcos Paulo de Souza
wrote:
On Mon, 19 Feb 2024 14:35:16 +0800 kernel test robot wrote:
Hi Marcos,
ker
Hi,
On Wed, Feb 21, 2024 at 05:27:18PM +0800, David Gow wrote:
> 'days' is a s64 (from div_s64), and so should use a %lld specifier.
>
> This was found by extending KUnit's assertion macros to use gcc's
> __printf attribute.
>
> Fixes: 1d1bb12a8b18 ("rtc: Improve performance of rtc_time64_to_tm().
Hi,
On Wed, Feb 21, 2024 at 05:27:17PM +0800, David Gow wrote:
> 'days' is a s64 (from div_s64), and so should use a %lld specifier.
>
> This was found by extending KUnit's assertion macros to use gcc's
> __printf attribute.
>
> Fixes: 276010551664 ("time: Improve performance of time64_to_tm()")
>
Hi,
On Wed, Feb 21, 2024 at 05:27:16PM +0800, David Gow wrote:
> The 'i' passed as an assertion message is a size_t, so should use '%zu',
> not '%d'.
>
> This was found by annotating the _MSG() variants of KUnit's assertions
> to let gcc validate the format strings.
>
> Fixes: bb95ebbe89a7 ("lib:
On Wed, Feb 21, 2024 at 1:28 AM David Gow wrote:
>
> KUnit's executor_test logs the filter string in KUNIT_ASSERT_EQ_MSG(),
> but passed a random character from the filter, rather than the whole
> string.
Note: it's worse than that, afaict.
It's printing from a random bit of memory.
I was curiou
On 2/21/24 05:08, Haibo Xu wrote:
On Wed, Feb 21, 2024 at 4:37 PM Atish Patra wrote:
On 2/20/24 18:13, Haibo Xu wrote:
On Wed, Feb 21, 2024 at 7:03 AM Atish Patra wrote:
On Mon, Jan 22, 2024 at 1:48 AM Haibo Xu wrote:
Move vcpu_has_ext to the processor.c and rename it to __vcpu_has_ext
On Wed, Feb 21, 2024 at 12:18 PM H.J. Lu wrote:
>
> On Wed, Feb 21, 2024 at 11:22 AM Edgecombe, Rick P
> wrote:
> >
> > On Wed, 2024-02-21 at 14:06 -0500, dal...@libc.org wrote:
> > > Due to arbitrarily nestable signal frames, no, this does not suffice.
> > > An interrupted operation using the lo
On Wed, Feb 21, 2024 at 11:22 AM Edgecombe, Rick P
wrote:
>
> On Wed, 2024-02-21 at 14:06 -0500, dal...@libc.org wrote:
> > Due to arbitrarily nestable signal frames, no, this does not suffice.
> > An interrupted operation using the lock could be arbitrarily delayed,
> > even never execute again,
On Wed, Feb 21, 2024 at 07:22:21PM +, Edgecombe, Rick P wrote:
> On Wed, 2024-02-21 at 14:06 -0500, dal...@libc.org wrote:
> > Due to arbitrarily nestable signal frames, no, this does not suffice.
> > An interrupted operation using the lock could be arbitrarily delayed,
> > even never execute a
Hi,
On Wed, Feb 21, 2024 at 05:27:15PM +0800, David Gow wrote:
> The correct format specifier for p - n (both p and n are pointers) is
> %td, as the type should be ptrdiff_t.
I think %tu is better. d specifies a signed type. I don't doubt that the
warning is fixed but I think %tu represents the t
Hi,
On Wed, Feb 21, 2024 at 05:27:14PM +0800, David Gow wrote:
> KUnit's executor_test logs the filter string in KUNIT_ASSERT_EQ_MSG(),
> but passed a random character from the filter, rather than the whole
> string.
>
> This was found by annotating KUNIT_ASSERT_EQ_MSG() to let gcc validate
> the
Hi,
On Wed, Feb 21, 2024 at 05:27:22PM +0800, David Gow wrote:
> KUnit's assertion macros have variants which accept a printf format
> string, to allow tests to specify a more detailed message on failure.
> These (and the related KUNIT_FAIL() macro) ultimately wrap the
> __kunit_do_failed_assertio
On Wed, 2024-02-21 at 14:06 -0500, dal...@libc.org wrote:
> Due to arbitrarily nestable signal frames, no, this does not suffice.
> An interrupted operation using the lock could be arbitrarily delayed,
> even never execute again, making any call to dlopen deadlock.
Doh! Yep, it is not robust to th
On Mon, Feb 19, 2024 at 11:15:57PM -0300, Thiago Jung Bauermann wrote:
> The only issue as can be seen above is that the can_call_function test
> is failing. The child is getting a GCS Segmentation fault when returning
> from fork().
> I tried debugging it with GDB, but I don't see what's wrong s
On Wed, Feb 21, 2024 at 06:32:20PM +, Mark Brown wrote:
> On Wed, Feb 21, 2024 at 12:57:19PM -0500, dal...@libc.org wrote:
> > On Wed, Feb 21, 2024 at 05:36:12PM +, Mark Brown wrote:
>
> > > This feels like it's getting complicated and I fear it may be an uphill
> > > struggle to get such
On Wed, Feb 21, 2024 at 06:53:44PM +, Edgecombe, Rick P wrote:
> On Wed, 2024-02-21 at 13:30 -0500, dal...@libc.org wrote:
> > > 3 is the cleanest and safest I think, and it was thought it might
> > > not
> > > need kernel help, due to a scheme Florian had to direct signals to
> > > specific th
On Wed, 2024-02-21 at 13:30 -0500, dal...@libc.org wrote:
> > 3 is the cleanest and safest I think, and it was thought it might
> > not
> > need kernel help, due to a scheme Florian had to direct signals to
> > specific threads. It's my preference at this point.
>
> The operations where the shadow
On 2/21/2024 11:19, Lucas Lee Jing Yi wrote:
On a Ryzen 7840HS the highest_perf value is 196, not 166 as AMD assumed.
This leads to the advertised max clock speed to only be 4.35ghz
instead of 5.14ghz leading to a large degradation in performance.
Fix the broken assumption and revert back to the
2024-02-21, 10:33:30 -0800, Jakub Kicinski wrote:
> On Wed, 21 Feb 2024 14:59:40 +0100 Sabrina Dubroca wrote:
> > It's not exactly enough, since tls_record_content_type will return 0
> > on a content type mismatch. We'll have to translate that into an
> > "error".
>
> Ugh, that's unpleasant.
>
>
On Wed, 21 Feb 2024 14:59:40 +0100 Sabrina Dubroca wrote:
> It's not exactly enough, since tls_record_content_type will return 0
> on a content type mismatch. We'll have to translate that into an
> "error".
Ugh, that's unpleasant.
> I think it would be a bit nicer to set err=1 and then check
> e
On Wed, Feb 21, 2024 at 12:57:19PM -0500, dal...@libc.org wrote:
> On Wed, Feb 21, 2024 at 05:36:12PM +, Mark Brown wrote:
> > This feels like it's getting complicated and I fear it may be an uphill
> > struggle to get such code merged, at least for arm64. My instinct is
> > that it's going t
On Wed, Feb 21, 2024 at 06:12:30PM +, Edgecombe, Rick P wrote:
> On Wed, 2024-02-21 at 12:57 -0500, dal...@libc.org wrote:
> > > This feels like it's getting complicated and I fear it may be an
> > > uphill
> > > struggle to get such code merged, at least for arm64. My instinct
> > > is
> > >
On 2/21/24 07:44, Nicolai Stange wrote:
> Shresth Prasad writes:
>
>> I checked the source code and yes I am on the latest Linux next repo.
>>
>> Here's the warning:
>> /home/shresthp/dev/linux_work/linux_next/tools/testing/selftests/livepatch/test_modules/test_klp_state.c:38:24:
>> warning: ass
On Mon, 22 Jan 2024 21:05:03 +, Mark Brown wrote:
> While we have test coverage for the ptrace interface in our selftests
> the current programs have a number of gaps. The testing is done per
> regset so does not cover interactions and at no point do any of the
> tests actually run the traced p
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 4893c639cc3659cefaa675bf1e59f4e7571afb5c Add linux-next specific
files for 20240221
Error/Warning: (recently discovered and may have been fixed)
ld.lld: error: undefined symbol
On Mon, Feb 19, 2024 at 11:02:22PM -0300, Thiago Jung Bauermann wrote:
> Mark Brown writes:
> > + gcspr_el0 = addr + size - (2 * sizeof(u64));
> > + if (!gcs_consume_token(tsk, gcspr_el0)) {
> Should this code validate the end of stack marker? Or doesn't it matter
> whether t
On Wed, 2024-02-21 at 12:57 -0500, dal...@libc.org wrote:
> > This feels like it's getting complicated and I fear it may be an
> > uphill
> > struggle to get such code merged, at least for arm64. My instinct
> > is
> > that it's going to be much more robust and generally tractable to
> > let
> > t
On Wed, Feb 21, 2024 at 05:36:12PM +, Mark Brown wrote:
> On Wed, Feb 21, 2024 at 09:58:01AM -0500, dal...@libc.org wrote:
> > On Wed, Feb 21, 2024 at 01:53:10PM +, Mark Brown wrote:
> > > On Tue, Feb 20, 2024 at 08:27:37PM -0500, dal...@libc.org wrote:
> > > > On Wed, Feb 21, 2024 at 12:35
On Wed, Feb 21, 2024 at 09:58:01AM -0500, dal...@libc.org wrote:
> On Wed, Feb 21, 2024 at 01:53:10PM +, Mark Brown wrote:
> > On Tue, Feb 20, 2024 at 08:27:37PM -0500, dal...@libc.org wrote:
> > > On Wed, Feb 21, 2024 at 12:35:48AM +, Edgecombe, Rick P wrote:
> > > > (INCSSP, RSTORSSP, et
On 2/16/24 16:28, Aaron Conole wrote:
Normally a spawned process under OVS is given a SIGTERM when the test
ends as part of cleanup. However, in case the process is still lingering
for some reason, we also send a SIGKILL to force it down faster.
Signed-off-by: Aaron Conole
---
tools/testi
On a Ryzen 7840HS the highest_perf value is 196, not 166 as AMD assumed.
This leads to the advertised max clock speed to only be 4.35ghz
instead of 5.14ghz leading to a large degradation in performance.
Fix the broken assumption and revert back to the old logic for
getting highest_perf.
TEST:
Gee
Hi Oleksandr,
Thanks, sent in a new patch with the recommendations highlighted by the script.
Regards,
Lucas
We don't need new targets only to run two make modules and make clean.
We can test if TEST_GEN_MODS_DIR is specified, and then run the
commands.
Signed-off-by: Marcos Paulo de Souza
---
tools/testing/selftests/lib.mk | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --
The directory itself doesn't need have path handling, since it's only to
mean where is the directory that contains modules to be built.
Signed-off-by: Marcos Paulo de Souza
---
tools/testing/selftests/lib.mk | 3 ---
1 file changed, 3 deletions(-)
diff --git a/tools/testing/selftests/lib.mk b/t
By checking if KDIR is a valid directory we can safely skip the tests if
kernel-devel isn't installed (default value of KDIR), or if KDIR
variable passed doesn't exists.
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202402191417.xulh88ct-...@intel.com/
Signed-off-b
Ignore the binary used to test livepatching a syscall.
Signed-off-by: Marcos Paulo de Souza
---
tools/testing/selftests/livepatch/.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/testing/selftests/livepatch/.gitignore
b/tools/testing/selftests/livepatch/.gitignore
new file m
The changes on lib.mk are both for simplification and also
clarification, like in the case of not handling TEST_GEN_MODS_DIR
directly. There is a new patch to solve one issue reported by build bot.
These changes apply on top of the current kselftest-next branch. Please
review!
Signed-off-by: Marc
On Sat, Feb 17, 2024 at 09:01:53AM +0100, Greg Kroah-Hartman wrote:
> On Fri, Feb 16, 2024 at 07:31:12PM +0300, Alexey Dobriyan wrote:
> > > drivers/misc/ntsync.c | 1146 ++
> >
> > Assuming this doesn't go into futex(2) or some other existing code...
> >
> > Ca
On 2/20/24 7:54 PM, Kees Cook wrote:
Replace deprecated 0-length array in struct bpf_lpm_trie_key with
flexible array. Found with GCC 13:
../kernel/bpf/lpm_trie.c:207:51: warning: array subscript i is outside array
bounds of 'const __u8[0]' {aka 'const unsigned char[]'} [-Warray-bounds=]
207
It's always a good idea to have KASAN in tests.
Signed-off-by: Benjamin Tissoires
---
new in v3
---
tools/testing/selftests/hid/config.common | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/testing/selftests/hid/config.common
b/tools/testing/selftests/hid/config.common
index 0f456db
This test checks that we can actually delay a workload in a sleepable
context through bpf_timer.
When an event is injected, we push it on a map of type queue and schedule
a work.
When that work kicks in, it pulls the event from the queue, and wakes
up userspace through a ring buffer.
The use of t
Export the sleepable kfuncs we have on HID-BPF in tracing bpf programs,
but with the condition of being used in a sleepable context.
This allows to use the bpf_timer when used in a sleepable context
through bpf_timer_set_sleepable_cb() and initiate work from a device event.
Signed-off-by: Benjamin
Usual way of testing, we call the function and ensures we receive
the event
Signed-off-by: Benjamin Tissoires
---
no changes in v3
no changes in v2
---
tools/testing/selftests/hid/hid_bpf.c | 49 +-
tools/testing/selftests/hid/progs/hid.c| 22 +
It can be interesting to inject events from BPF as if the event were
to come from the device.
For example, some multitouch devices do not all the time send a proximity
out event, and we might want to send it for the physical device.
Compared to uhid, we can now inject events on any physical device
This time we need to ensure uhid receives it, thus the new mutex and
condition.
Signed-off-by: Benjamin Tissoires
---
no changes in v3
no changes in v2
---
tools/testing/selftests/hid/hid_bpf.c | 63 ++
tools/testing/selftests/hid/progs/hid.c| 24 +
We currently only export hid_hw_raw_request() as a BPF kfunc.
However, some devices require an explicit write on the Output Report
instead of the use of the control channel.
So also export hid_hw_output_report to BPF
Signed-off-by: Benjamin Tissoires
---
no changes in v3
no changes in v2
---
No code change, just move down the hid_bpf_get_data() kfunc definition
so we have only one block of __bpf_kfunc_start/end_defs()
Signed-off-by: Benjamin Tissoires
---
no changes in v3
no changes in v2
---
drivers/hid/bpf/hid_bpf_dispatch.c | 80 ++
1 file c
This is still a WIP, but I think this can be dropped as we never
get to this instruction. So what should we do here?
Signed-off-by: Benjamin Tissoires
---
kernel/bpf/verifier.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
ind
Now that we have bpf_timer_set_sleepable_cb() available and working, we
can tag the attached callback as sleepable, and let the verifier check
in the correct context the calls and kfuncs.
Signed-off-by: Benjamin Tissoires
---
new in v3 (split from v2 02/10)
---
include/linux/bpf_verifier.h |
In this patch, bpf_timer_set_sleepable_cb() is functionally equivalent
to bpf_timer_set_callback(), to the exception that it enforces
the timer to be started with BPF_F_TIMER_SLEEPABLE.
But given that bpf_timer_set_callback() is a helper when
bpf_timer_set_sleepable_cb() is a kfunc, we need to tea
We need to extend the bpf_timer API, but the way forward relies on kfuncs.
So make bpf_timer known for kfuncs from the verifier PoV
Signed-off-by: Benjamin Tissoires
---
new in v3 (split from v2 02/10)
---
kernel/bpf/verifier.c | 36
1 file changed, 36 inse
They are implemented as a workqueue, which means that there are no
guarantees of timing nor ordering.
Signed-off-by: Benjamin Tissoires
---
changes in v3:
- extracted the implementation in bpf_timer only, without
bpf_timer_set_sleepable_cb()
- rely on schedule_work() only, from bpf_timer_star
Currently we have a special case for BPF_FUNC_timer_set_callback,
let's introduce a helper we can extend for the kfunc that will come in
a later patch
Signed-off-by: Benjamin Tissoires
---
new in v3
---
kernel/bpf/verifier.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
di
No code change, but it'll allow to have only one place to change
everything when we add in_sleepable in cur_state.
Signed-off-by: Benjamin Tissoires
---
no changes in v3
changes in v2 (compared to the one attaches to v1 0/9):
- dropped the cur_state flag, so it can be put first
---
kernel/bpf
These 2 maps types are required for HID-BPF when a user wants to do
IO with a device from a sleepable tracing point.
Allowing BPF_MAP_TYPE_QUEUE (and therefore BPF_MAP_TYPE_STACK) allows
for a BPF program to prepare from an IRQ the list of HID commands to send
back to the device and then these com
[Partly a RFC/formal submission: there are still FIXMEs in the code]
[Also using bpf-next as the base tree for HID changes as there will
be conflicting changes otherwise, so I'm personaly fine for the HID
commits to go through bpf-next]
IMO, patches 1-3 and 9-14 are ready to go, rest is still pend
[replying to both of your messages here]
On Wed, Feb 21, 2024 at 3:59 AM Alexei Starovoitov
wrote:
>
> On Fri, Feb 16, 2024 at 10:50:10AM +0100, Benjamin Tissoires wrote:
> > static bool is_rbtree_lock_required_kfunc(u32 btf_id)
> > {
> > return is_bpf_rbtree_api_kfunc(btf_id);
> > @@ -12
On Thu, Feb 08, 2024 at 12:23:02AM -0800, Yi Liu wrote:
> If a domain is used as the parent in nested translation its mappings might
> be cached using DID of the nested domain. But the existing code ignores
> this fact to only invalidate the iotlb entries tagged by the domain's own
> DID.
> Loop t
On Wed, Feb 21, 2024 at 01:53:10PM +, Mark Brown wrote:
> On Tue, Feb 20, 2024 at 08:27:37PM -0500, dal...@libc.org wrote:
> > On Wed, Feb 21, 2024 at 12:35:48AM +, Edgecombe, Rick P wrote:
>
> > > (INCSSP, RSTORSSP, etc). These are a collection of instructions that
> > > allow limited con
Hi Christian,
On Tue, Feb 20, 2024 at 04:03:57PM +0100, Christian König wrote:
> Am 20.02.24 um 15:56 schrieb Maxime Ripard:
> > On Tue, Feb 20, 2024 at 02:28:53PM +0100, Christian König wrote:
> > > [SNIP]
> > > This kunit test is not meant to be run on real hardware, but rather just
> > > as
>
From: Vincent Donnefort
This test maps a ring-buffer and validate the meta-page after reset and
after emitting few events.
Link:
https://lore.kernel.org/linux-trace-kernel/20240220202310.2489614-7-vdonnef...@google.com
Cc: Shuah Khan
Cc: Shuah Khan
Cc: linux-kselftest@vger.kernel.org
Signed-
On Fri, Feb 16, 2024 at 11:08 PM Saurabh Singh Sengar
wrote:
>
> On Fri, Feb 16, 2024 at 05:05:51PM -0800, Frank Rowand wrote:
> > When enabling CONFIG_OF on a platform where 'of_root' is not populated
> > by firmware, we end up without a root node. In order to apply overlays
> > and create subnod
On 2/21/24 2:22 PM, Muhammad Usama Anjum wrote:
> Move test_dev_cgroup.c to prog_tests/dev_cgroup.c to be able to run it
> with test_progs. Replace dev_cgroup.bpf.o with skel header file,
> dev_cgroup.skel.h and load program from it accourdingly.
>
> ./test_progs -t test_dev_cgroup
> mknod: /t
2024-02-20, 17:50:53 -0800, Jakub Kicinski wrote:
> On Tue, 20 Feb 2024 00:10:58 +0100 Sabrina Dubroca wrote:
> > 2024-02-19, 12:07:03 -0800, Jakub Kicinski wrote:
> > > On Thu, 15 Feb 2024 17:17:31 +0100 Sabrina Dubroca wrote:
> > > > @@ -1772,7 +1772,8 @@ static int process_rx_list(struct
> >
On Tue, Feb 20, 2024 at 08:27:37PM -0500, dal...@libc.org wrote:
> On Wed, Feb 21, 2024 at 12:35:48AM +, Edgecombe, Rick P wrote:
> > (INCSSP, RSTORSSP, etc). These are a collection of instructions that
> > allow limited control of the SSP. When shadow stack gets disabled,
> > these suddenly t
On Wed, Feb 21, 2024 at 05:27:22PM +0800, David Gow wrote:
> KUnit's assertion macros have variants which accept a printf format
> string, to allow tests to specify a more detailed message on failure.
> These (and the related KUNIT_FAIL() macro) ultimately wrap the
> __kunit_do_failed_assertion() f
On Wed, Feb 21, 2024 at 05:27:21PM +0800, David Gow wrote:
> KUNIT_FAIL() is used to fail the xe_migrate test when an error occurs.
> However, there's a mismatch in the format specifier: '%li' is used to
> log 'err', which is an 'int'.
>
> Use '%i' instead of '%li', and for the case where we're pr
On Wed, Feb 21, 2024 at 05:27:20PM +0800, David Gow wrote:
> The drm_buddy_test's alloc_contiguous test used a u64 for the page size,
> which was then updated to be an 'unsigned long' to avoid 64-bit
> multiplication division helpers.
>
> However, the variable is logged by some KUNIT_ASSERT_EQ_MSG
On Wed, Feb 21, 2024 at 05:27:19PM +0800, David Gow wrote:
> KUNIT_FAIL() accepts a printf-style format string, but previously did
> not let gcc validate it with the __printf() attribute. The use of %lld
> for the result of PTR_ERR() is not correct.
>
> Instead, use %pe and pass the actual error p
On Wed, Feb 21, 2024 at 05:27:18PM +0800, David Gow wrote:
> 'days' is a s64 (from div_s64), and so should use a %lld specifier.
>
> This was found by extending KUnit's assertion macros to use gcc's
> __printf attribute.
>
> Fixes: 1d1bb12a8b18 ("rtc: Improve performance of rtc_time64_to_tm(). Ad
On Wed, Feb 21, 2024 at 05:27:17PM +0800, David Gow wrote:
> 'days' is a s64 (from div_s64), and so should use a %lld specifier.
>
> This was found by extending KUnit's assertion macros to use gcc's
> __printf attribute.
>
> Fixes: 276010551664 ("time: Improve performance of time64_to_tm()")
> Si
On Wed, Feb 21, 2024 at 05:27:16PM +0800, David Gow wrote:
> The 'i' passed as an assertion message is a size_t, so should use '%zu',
> not '%d'.
>
> This was found by annotating the _MSG() variants of KUnit's assertions
> to let gcc validate the format strings.
>
> Fixes: bb95ebbe89a7 ("lib: Int
On Wed, Feb 21, 2024 at 05:27:15PM +0800, David Gow wrote:
> The correct format specifier for p - n (both p and n are pointers) is
> %td, as the type should be ptrdiff_t.
>
> This was discovered by annotating KUnit assertion macros with gcc's
> printf specifier, but note that gcc incorrectly sugge
On Wed, Feb 21, 2024 at 05:27:14PM +0800, David Gow wrote:
> KUnit's executor_test logs the filter string in KUNIT_ASSERT_EQ_MSG(),
> but passed a random character from the filter, rather than the whole
> string.
>
> This was found by annotating KUNIT_ASSERT_EQ_MSG() to let gcc validate
> the form
1 - 100 of 129 matches
Mail list logo
