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
so that other test cases can use it for vCPU extension check.
Signed-off-by: Haibo Xu
R
kselftest/next build: 5 builds: 1 failed, 4 passed, 1 error, 5 warnings
(v6.8-rc1-48-g6f1a214d446b2)
Full Build Summary:
https://kernelci.org/build/kselftest/branch/next/kernel/v6.8-rc1-48-g6f1a214d446b2/
Tree: kselftest
Branch: next
Git Describe: v6.8-rc1-48-g6f1a214d446b2
Git Commit: 6f1a214d
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: /tmp/test_dev_cgroup_null: Operation not permitted
64+0 reco
KUnit has several macros which accept a log message, which can contain
printf format specifiers. Some of these (the explicit log macros)
already use the __printf() gcc attribute to ensure the format specifiers
are valid, but those which could fail the test, and hence used
__kunit_do_failed_assertio
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 format string.
Fixes: 76066f93f1df ("kunit: add tests for filtering attrib
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 suggested a %d or %ld
specifier (depending on the pointer size of the arch
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: Introduce CONFIG_MEMCPY_KUNIT_TEST")
Signed-off-by: David Gow
---
lib/memc
'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()")
Signed-off-by: David Gow
---
kernel/time/time_test.c | 2 +-
1 file chang
'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(). Add
tests.")
Signed-off-by: David Gow
---
drivers/rtc/lib_test.c | 2 +
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 pointer. printk() will format
it correctly (and give a symbolic name r
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() using the
'%d' or '%llu' format specifiers, the former of which is
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 an
error pointer, just use '%pe', instead of extracting the er
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() function, which accepted a printf format
specifier, but did not have
kselftest/next kselftest-lib: 3 runs, 2 regressions (v6.8-rc1-48-g6f1a214d446b2)
Regressions Summary
---
platform | arch | lab | compiler | defconfig
| regressions
-+---+---+--+--
kselftest/next kselftest-seccomp: 2 runs, 1 regressions
(v6.8-rc1-48-g6f1a214d446b2)
Regressions Summary
---
platform | arch | lab | compiler | defconfig
| regressions
-+---+-+--+-
kselftest/next kselftest-cpufreq: 5 runs, 3 regressions
(v6.8-rc1-48-g6f1a214d446b2)
Regressions Summary
---
platform | arch | lab | compiler | defconfig
| regressions
-+---+-+--+-
kselftest/next kselftest-livepatch: 1 runs, 1 regressions
(v6.8-rc1-48-g6f1a214d446b2)
Regressions Summary
---
platform| arch | lab | compiler | defconfig
| regressions
+--+---+--+--
kselftest/next kselftest-lkdtm: 2 runs, 1 regressions
(v6.8-rc1-48-g6f1a214d446b2)
Regressions Summary
---
platform| arch | lab | compiler | defconfig
| regressions
+--+---+--+--
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: assignment to ‘struct klp_state *’ from ‘int’ makes pointer from
integer without a ca
On 21/02/2024 09:27, 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() using the
'%d' or '%llu' f
Am 21.02.24 um 10:27 schrieb David Gow:
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() using the
'%d' or '%llu'
On Wed, Feb 21, 2024 at 08:49:58AM +0100, Janosch Frank wrote:
> On 2/20/24 22:12, Eric Farman wrote:
> > Hi Janosch,
> >
> > Here is a new (final?) version for the AR/MEM_OP issue I'm attempting to
> > address. Hopefully they can be picked up to whatever tree makes sense.
> >
>
> I've got good
On Wed, 2024-02-21 at 12:26 +0100, Heiko Carstens wrote:
> On Wed, Feb 21, 2024 at 08:49:58AM +0100, Janosch Frank wrote:
> > On 2/20/24 22:12, Eric Farman wrote:
> > > Hi Janosch,
> > >
> > > Here is a new (final?) version for the AR/MEM_OP issue I'm
> > > attempting to
> > > address. Hopefully t
On Tue, 2024-02-20 at 11:22 -0800, Jakub Kicinski wrote:
> When running selftests for our subsystem in our CI we'd like all
> tests to pass. Currently some tests use SKIP for cases they
> expect to fail, because the kselftest_harness limits the return
> codes to pass/fail/skip.
>
> Clean up and su
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,
> >>>
> >>> kernel tes
On Mon, 19 Feb 2024 15:16:51 +0800 kernel test robot wrote:
> Hi Marcos,
>
> kernel test robot noticed the following build warnings:
>
> [auto build test WARNING on 345e8abe4c355bc24bab3f4a5634122e55be8665]
>
> url:
> https://github.com/intel-lab-lkp/linux/commits/Marcos-Paulo-de-Souza/sel
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: assignment to ‘struct klp_state *’ from ‘int’ makes
Commit d393acce7b3f ("drm/tests: Switch to kunit devices") switched the
DRM device creation helpers from an ad-hoc implementation to the new
kunit device creation helpers introduced in commit d03c720e03bd ("kunit:
Add APIs for managing devices").
However, while the DRM helpers were using a platfor
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
> >>> so that
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
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: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: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: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: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: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: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: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 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
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 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
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
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-
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
>
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
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
[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
[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
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
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
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
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
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
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
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 |
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
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
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
---
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 +
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
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 +
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
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
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
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
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
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
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
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
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
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 --
Hi Oleksandr,
Thanks, sent in a new patch with the recommendations highlighted by the script.
Regards,
Lucas
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
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 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 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, 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 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
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, 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
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 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 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, 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
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 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
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 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, 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 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, 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
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
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: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
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
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 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 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 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
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:
1 - 100 of 129 matches
Mail list logo
