dropping stable email again.
David Hildenbrand writes:
> 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
>>>
David Hildenbrand writes:
dropping sta...@vger.kernel.org
> On 24.05.24 04:57, Andrew Morton wrote:
>> 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 doin
On 24.05.24 04:57, Andrew Morton wrote:
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:
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 non
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 10064
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 non
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
bpf_map_l
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() an
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 it
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 Ta
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 network_helpe
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 "t
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
> > a
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.
Joseph
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 dele
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() r
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 m
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 regressi
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 ca
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 mseal
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 v
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? P
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 t
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 bel
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 pag
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
+++ b/tools/testing/selftests/bpf/prog_tes
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 Si
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 p
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 Docume
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 A
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 per
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 thi
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 [shiftTooManyB
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 cppc
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: e
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.
> >>
> >>ptep_set_wrprot
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 a
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 [shiftTooManyB
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 nicel
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 qst
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 uAPI
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
> wi
47 matches
Mail list logo
