Hi Aleksa
On Thu, May 23, 2024 at 8:39 PM wrote:
>
> From: Jeff Xu
>
> Add documentation for MFD_NOEXEC_SEAL and MFD_EXEC
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Jeff Xu
> ---
> Documentation/userspace-api/index.rst | 1 +
> Documentation/userspace-api/mfd_noexec.rst | 90
From: Jeff Xu
By default, memfd_create() creates a non-sealable MFD, unless the
MFD_ALLOW_SEALING flag is set.
When the MFD_NOEXEC_SEAL flag is initially introduced, the MFD created
with that flag is sealable, even though MFD_ALLOW_SEALING is not set.
This patch changes MFD_NOEXEC_SEAL to be
From: Jeff Xu
Add documentation for MFD_NOEXEC_SEAL and MFD_EXEC
Cc: sta...@vger.kernel.org
Signed-off-by: Jeff Xu
---
Documentation/userspace-api/index.rst | 1 +
Documentation/userspace-api/mfd_noexec.rst | 90 ++
2 files changed, 91 insertions(+)
create mode
From: Jeff Xu
By default, memfd_create() creates a non-sealable MFD, unless the
MFD_ALLOW_SEALING flag is set.
When the MFD_NOEXEC_SEAL flag is initially introduced, the MFD created
with that flag is sealable, even though MFD_ALLOW_SEALING is not set.
This patch changes MFD_NOEXEC_SEAL to be
From: Geliang Tang
For getting rid of the second parameter of do_test(), this patch adds a
new callback post_connect_cb in struct network_helper_opts, it will be
invoked after connect_fd_to_addr() in connect_to_fd_opts().
Then define a dctcp dedicated post_connect_cb callback, invoking
From: Geliang Tang
This patch uses connect_to_fd_opts() instead of using connect_fd_to_fd()
and settcpca() in do_test() in prog_tests/bpf_tcp_ca.c to accept a struct
network_helper_opts argument.
Then define a dctcp dedicated post_socket_cb callback stg_post_socket_cb(),
invoking both cc_cb()
From: Geliang Tang
This patch uses new helper start_server_str() in do_test() in bpf_tcp_ca.c
to accept a struct network_helper_opts argument instead of using
start_server() and settcpca(). Then change the type of the first paramenter
of do_test() into a struct network_helper_opts one.
Define
From: Geliang Tang
It's a tech debt that start_server() does not take the "opts" argument.
It's pretty handy to have start_server() as a helper that takes string
address.
So this patch creates a new helper start_server_str(). Then start_server()
can be a wrapper of it.
Signed-off-by: Geliang
From: Geliang Tang
Since the post_socket_cb() callback is added in struct network_helper_opts,
it's make sense to use it not only in __start_server(), but also in
connect_to_fd_opts(). Then it can be used to set TCP_CONGESTION sockopt.
Add a "void *" type member cb_opts into struct
From: Geliang Tang
It's not possible to have one generic/common "struct post_socket_opts"
for all tests. It's better to have the individual test define its own
callback opts struct.
So this patch drops struct post_socket_opts, and changes the second
parameter of post_socket_cb as "void *" type.
From: Geliang Tang
This patchset uses post_socket_cb and post_connect_cb callbacks of struct
network_helper_opts to refactor do_test() in bpf_tcp_ca.c to move dctcp
test dedicated code out of do_test() into test_dctcp().
v4:
- address Martin's comments in v3 (thanks).
- drop 2 patches, keep
On Thu, 23 May 2024 22:40:25 +0200 David Hildenbrand wrote:
> > You have sta...@vger.kernel.org in the mail headers, so I assume you're
> > proposing this for backporting. When doing this, please include
> >
> > Cc:
> >
> > in the changelog footers and also include a Fixes: target. I'm
> >
1. In order to make rtctest more explicit and robust, we propose to use
RTC_PARAM_GET ioctl interface to check rtc alarm feature state before
running alarm related tests.
2. The rtctest requires the read permission on /dev/rtc0. The rtctest will
be skipped if the /dev/rtc0 is not readable.
The rtctest requires the read permission on /dev/rtc0. The rtctest will
be skipped if the /dev/rtc0 is not readable.
Reviewed-by: Koba Ko
Reviewed-by: Matthew R. Ochs
Signed-off-by: Joseph Jang
---
tools/testing/selftests/rtc/rtctest.c | 11 ++-
1 file changed, 10 insertions(+), 1
In alarm_wkalm_set and alarm_wkalm_set_minute test, they use different
ioctl (RTC_ALM_SET/RTC_WKALM_SET) for alarm feature detection. They will
skip testing if RTC_ALM_SET/RTC_WKALM_SET ioctl returns an EINVAL error
code. This design may miss detecting real problems when the
efi.set_wakeup_time()
From: Masami Hiramatsu (Google)
Add a basic uprobe testcase which checks whether add/remove/trace
operations works on /bin/sh.
Signed-off-by: Masami Hiramatsu (Google)
---
.../ftrace/test.d/dynevent/add_remove_uprobe.tc| 26
1 file changed, 26 insertions(+)
create
On Thu, 23 May 2024 12:45:41 -0400
Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> A regression happened where running the ownership test passes on the first
> iteration but fails running it a second time. This was caught and fixed,
> but a later change brought it back. The
Hi Ilpo,
On 5/20/24 5:30 AM, Ilpo Järvinen wrote:
For MBM/MBA tests, measure_vals() calls get_mem_bw_imc() that performs
the measurement over a duration of sleep(1) call. The memory bandwidth
numbers from IMC are derived over this duration. The resctrl FS derived
memory bandwidth, however, is
On Thu, 23 May 2024 16:32:26 -0700 Kees Cook wrote:
> On Tue, May 14, 2024 at 12:52:13PM -0700, Kees Cook wrote:
> > On Tue, May 14, 2024 at 10:46:46AM -0700, Andrew Morton wrote:
> > > On Mon, 15 Apr 2024 16:35:19 + jef...@chromium.org wrote:
> > >
> > > > This patchset proposes a new
On Tue, May 14, 2024 at 12:52:13PM -0700, Kees Cook wrote:
> On Tue, May 14, 2024 at 10:46:46AM -0700, Andrew Morton wrote:
> > On Mon, 15 Apr 2024 16:35:19 + jef...@chromium.org wrote:
> >
> > > This patchset proposes a new mseal() syscall for the Linux kernel.
> >
> > I have not moved this
2024. május 23., csütörtök 22:44 keltezéssel, Jeff Xu írta:
> Hi Barnabás
>
> Is that OK that I work on V2 ? It will be based on your V1 change and
> I will also add more test cases.
Sure, please go ahead. At the very end of this letter you'll find
the commit message that I would have sent in
Hi Barnabás
Is that OK that I work on V2 ? It will be based on your V1 change and
I will also add more test cases.
Thanks
-Jeff
-
On Thu, May 23, 2024 at 12:45 PM Andrew Morton
wrote:
>
> On Wed, 22 May 2024 19:32:35 -0700 Jeff Xu wrote:
>
> > >
> > > It's a change to a userspace API, yes?
On 23.05.24 21:13, Andrew Morton wrote:
On Thu, 23 May 2024 01:39:05 -0500 Donet Tom wrote:
Commit 1b151e2435fc ("block: Remove special-casing of compound
pages") caused a change in behaviour when releasing the pages
if the buffer does not start at the beginning of the page. This
was because
On Wed, 22 May 2024 19:32:35 -0700 Jeff Xu wrote:
> >
> > It's a change to a userspace API, yes? Please let's have a detailed
> > description of why this is OK. Why it won't affect any existing users.
> >
> Unfortunately, this is a breaking change that might break a
> application if they do
On Thu, 23 May 2024 01:39:05 -0500 Donet Tom wrote:
> Commit 1b151e2435fc ("block: Remove special-casing of compound
> pages") caused a change in behaviour when releasing the pages
> if the buffer does not start at the beginning of the page. This
> was because the calculation of the number of
On 5/23/24 12:12, Edward Liaw wrote:
On Thu, May 23, 2024 at 11:02 AM Shuah Khan wrote:
On 5/22/24 20:28, John Hubbard wrote:
On 5/22/24 10:46 AM, Edward Liaw wrote:
On Wed, May 22, 2024 at 4:21 AM Mark Brown wrote:
On Wed, May 22, 2024 at 12:56:48AM +, Edward Liaw wrote:
...
You've
On 5/22/24 2:23 AM, Geliang Tang wrote:
diff --git a/tools/testing/selftests/bpf/prog_tests/sk_assign.c
b/tools/testing/selftests/bpf/prog_tests/sk_assign.c
index 0b9bd1d6f7cc..517d1186e386 100644
--- a/tools/testing/selftests/bpf/prog_tests/sk_assign.c
+++
On Thu, May 23, 2024 at 11:02 AM Shuah Khan wrote:
>
> On 5/22/24 20:28, John Hubbard wrote:
> > On 5/22/24 10:46 AM, Edward Liaw wrote:
> >> On Wed, May 22, 2024 at 4:21 AM Mark Brown wrote:
> >>> On Wed, May 22, 2024 at 12:56:48AM +, Edward Liaw wrote:
> > ...
> >>> You've not provided a
On 5/22/24 17:36, Shuah Khan wrote:
On 5/22/24 17:32, patchwork-bot+linux-ri...@kernel.org wrote:
Hello:
This series was applied to riscv/linux.git (fixes)
by Tejun Heo :
Hi Tejun,
I noticed you weren't on the email I sent in response.
Please drop this series. There is simpler fix to the
On 5/22/24 20:28, John Hubbard wrote:
On 5/22/24 10:46 AM, Edward Liaw wrote:
On Wed, May 22, 2024 at 4:21 AM Mark Brown wrote:
On Wed, May 22, 2024 at 12:56:48AM +, Edward Liaw wrote:
...
You've not provided a Signed-off-by for this so people can't do anything
with it, please see
On Thu, May 23, 2024 at 9:20 AM Jeff Xu wrote:
>
> On Thu, May 23, 2024 at 1:24 AM David Rheinsberg wrote:
> >
> > Hi
> >
> > On Thu, May 23, 2024, at 4:25 AM, Barnabás Pőcze wrote:
> > > 2024. május 23., csütörtök 1:23 keltezéssel, Andrew Morton
> > > írta:
> > >> It's a change to a userspace
From: "Steven Rostedt (Google)"
A regression happened where running the ownership test passes on the first
iteration but fails running it a second time. This was caught and fixed,
but a later change brought it back. The regression was missed because the
automated tests only run the tests once
On Thu, May 23, 2024 at 1:24 AM David Rheinsberg wrote:
>
> Hi
>
> On Thu, May 23, 2024, at 4:25 AM, Barnabás Pőcze wrote:
> > 2024. május 23., csütörtök 1:23 keltezéssel, Andrew Morton
> > írta:
> >> It's a change to a userspace API, yes? Please let's have a detailed
> >> description of why
Currrentl a 32 bit 1u value is being shifted more than 32 bits causing
overflow and incorrect checking of bits 32-63. Fix this by using the
BIT_ULL macro for shifting bits.
Detected by cppcheck:
sev_init2_tests.c:108:34: error: Shifting 32-bit value by 63 bits is
undefined behaviour
On 23/05/2024 16:35, Dan Carpenter wrote:
On Thu, May 23, 2024 at 12:38:02PM +0100, Colin Ian King wrote:
Currrentl a 32 bit 1u value is being shifted more than 32 bits causing
overflow and incorrect checking of bits 32-63. Fix this by using the
BIT_ULL macro for shifting bits.
Detected by
On Thu, May 23, 2024 at 12:38:02PM +0100, Colin Ian King wrote:
> Currrentl a 32 bit 1u value is being shifted more than 32 bits causing
> overflow and incorrect checking of bits 32-63. Fix this by using the
> BIT_ULL macro for shifting bits.
>
> Detected by cppcheck:
> sev_init2_tests.c:108:34:
Hi Deepak,
On Mon, May 13, 2024 at 7:32 PM Deepak Gupta wrote:
>
> On Sun, May 12, 2024 at 06:31:24PM +0200, Alexandre Ghiti wrote:
> >On 04/04/2024 01:35, Deepak Gupta wrote:
> >>`fork` implements copy on write (COW) by making pages readonly in child
> >>and parent both.
> >>
>
On Mon, Mar 04, 2024 at 06:45:33PM -0300, Helen Koike wrote:
> Hi Linus,
>
> Thank you for your reply and valuable inputs.
>
> On 01/03/2024 17:10, Linus Torvalds wrote:
> > On Fri, 1 Mar 2024 at 02:27, Nikolai Kondrashov wrote:
> > >
> > > I agree, it's hard to imagine even a simple majority
Currrentl a 32 bit 1u value is being shifted more than 32 bits causing
overflow and incorrect checking of bits 32-63. Fix this by using the
BIT_ULL macro for shifting bits.
Detected by cppcheck:
sev_init2_tests.c:108:34: error: Shifting 32-bit value by 63 bits is
undefined behaviour
On Mon, May 20, 2024 at 05:56:28PM +, Edward Liaw wrote:
> From: Mark Brown
>
> [ Upstream commit 907f33028871fa7c9a3db1efd467b78ef82cce20 ]
>
> The standard library perror() function provides a convenient way to print
> an error message based on the current errno but this doesn't play
Currently array buf is not being initialized and so garbage values
on the stack are being used in the mq_send calls. Initialize the
values in the array to zero.
Cleans up cppcheck warning:
mq_perf_tests.c:334:25: error: Uninitialized variable: buff [uninitvar]
Signed-off-by: Colin Ian King
---
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni :
On Mon, 20 May 2024 23:58:43 + you wrote:
> Testing a network device that has large numbers of bytes/packets may
> overflow. Using stats64 when comparing fixes this problem.
>
> I tripped on this while iterating on a
Hi
On Thu, May 23, 2024, at 4:25 AM, Barnabás Pőcze wrote:
> 2024. május 23., csütörtök 1:23 keltezéssel, Andrew Morton
> írta:
>> It's a change to a userspace API, yes? Please let's have a detailed
>> description of why this is OK. Why it won't affect any existing users.
>
> Yes, it is a
This patch is "Rejected", according to Jakub's comments:
https://lore.kernel.org/bpf/87zfsiw3a3@cloudflare.com/
Thanks,
-Geliang
On Wed, 2024-05-22 at 18:08 +0800, Geliang Tang wrote:
> From: Geliang Tang
>
> Since prog_attach_type[] array is defined, it makes sense to use it
> paired
>
From: Geliang Tang
bpf_map_lookup_elem is invoked in bpf_prog3() already, no need to invoke
it again. This patch drops it.
Signed-off-by: Geliang Tang
---
tools/testing/selftests/bpf/progs/test_sockmap_kern.h | 3 ---
1 file changed, 3 deletions(-)
diff --git
From: Geliang Tang
The value of recv in msg_loop may be negative, like EWOULDBLOCK, so it's
necessary to check if it is positive before accumulating it to bytes_recvd.
Fixes: 16962b2404ac ("bpf: sockmap, add selftests")
Signed-off-by: Geliang Tang
---
From: Geliang Tang
The array size of map_fd[] is 9, not 8. This patch changes it as a more
general form: ARRAY_SIZE(map_fd).
Signed-off-by: Geliang Tang
---
tools/testing/selftests/bpf/test_sockmap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Geliang Tang
The program fds can be got by using bpf_program__fd(progs[]), then
prog_fd becomes useless. This patch drops it.
Signed-off-by: Geliang Tang
---
tools/testing/selftests/bpf/test_sockmap.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git
From: Geliang Tang
bpf_program__attach_sockmap() needs to take a parameter of type bpf_program
instead of an fd, so tx_prog_fd becomes useless. This patch uses a pointer
tx_prog to point to an item in progs[] array.
Signed-off-by: Geliang Tang
---
tools/testing/selftests/bpf/test_sockmap.c |
From: Geliang Tang
Switch attachments to bpf_link using bpf_program__attach_sockmap() instead
of bpf_prog_attach().
This patch adds a new array progs[] to replace prog_fd[] array, set in
populate_progs() for each program in bpf object.
And another new array links[] to save the attached
From: Geliang Tang
There's already a definition of i in run_options() at the beginning, no
need to define a new one in "if (tx_prog_fd > 0)" block.
Signed-off-by: Geliang Tang
---
tools/testing/selftests/bpf/test_sockmap.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
From: Geliang Tang
The values of tx_prog_fd in run_options() should not be 0, so set it as -1
in else branch, and test it using "if (tx_prog_fd > 0)" condition, not
"if (tx_prog_fd)" or "if (tx_prog_fd >= 0)".
Signed-off-by: Geliang Tang
---
tools/testing/selftests/bpf/test_sockmap.c | 6
From: Geliang Tang
This patchset contains some fixes and improvements for test_sockmap.
3-5: switching attachments to bpf_link as Jakub suggested in [1].
1-2, 6-8: Small fixes.
[1]
https://lore.kernel.org/bpf/87zfsiw3a3@cloudflare.com/
Geliang Tang (8):
selftests/bpf: Fix tx_prog_fd
Commit 1b151e2435fc ("block: Remove special-casing of compound
pages") caused a change in behaviour when releasing the pages
if the buffer does not start at the beginning of the page. This
was because the calculation of the number of pages to release
was incorrect.
This was fixed by commit
On 2024-05-10 16:21, Mina Almasry wrote:
> +/* On error, returns the -errno. On success, returns number of bytes sent to
> the
> + * user. May not consume all of @remaining_len.
> + */
> +static int tcp_recvmsg_dmabuf(struct sock *sk, const struct sk_buff *skb,
> +
55 matches
Mail list logo
