ha Levin wrote:
>> >
>> > On Wed, Jun 25, 2025 at 10:52:46AM +0200, Dmitry Vyukov wrote:
>> > >On Tue, 24 Jun 2025 at 22:04, Sasha Levin wrote:
>> > >
>> > >> >6. What's the goal of validation of the input arguments?
>> > >>
Moved ctl_tables elements for overflowuid and overflowgid into in
kernel/sys.c. Create a register function that keeps them under "kernel"
and run it after core with postcore_initcall.
This is part of a greater effort to move ctl tables into their
respective subsystems which will reduce
> On Wed, Jun 25, 2025 at 10:52:46AM +0200, Dmitry Vyukov wrote:
> >> > >On Tue, 24 Jun 2025 at 22:04, Sasha Levin wrote:
> >> > >
> >> > >> >6. What's the goal of validation of the input arguments?
> >> > >> >Kernel code
Levin wrote:
> >
> >> >6. What's the goal of validation of the input arguments?
> >> >Kernel code must do this validation anyway, right.
> >> >Any non-trivial validation is hard, e.g. even for open the validation
function
> >> >for file name wou
; >6. What's the goal of validation of the input arguments?
> > >> >Kernel code must do this validation anyway, right.
> > >> >Any non-trivial validation is hard, e.g. even for open the validation
> > >> >function
> > >> >for file name w
On Wed, 25 Jun 2025 at 17:55, Sasha Levin wrote:
>
> On Wed, Jun 25, 2025 at 10:52:46AM +0200, Dmitry Vyukov wrote:
> >On Tue, 24 Jun 2025 at 22:04, Sasha Levin wrote:
> >
> >> >6. What's the goal of validation of the input arguments?
> >> >Ke
On Wed, Jun 25, 2025 at 10:56:04AM +0200, Dmitry Vyukov wrote:
On Tue, 24 Jun 2025 at 22:04, Sasha Levin wrote:
>9. I see that syscalls and ioctls say:
>KAPI_CONTEXT(KAPI_CTX_PROCESS | KAPI_CTX_SLEEPABLE)
>Can't we make this implicit? Are there any other options?
Maybe? I wasn't sure how we'd
On Tue, 24 Jun 2025 at 16:05, Cyril Hrubis wrote:
>
> Hi!
> > 6. What's the goal of validation of the input arguments?
> > Kernel code must do this validation anyway, right.
> > Any non-trivial validation is hard, e.g. even for open the validation
> > funct
On Tue, 24 Jun 2025 at 22:04, Sasha Levin wrote:
> >9. I see that syscalls and ioctls say:
> >KAPI_CONTEXT(KAPI_CTX_PROCESS | KAPI_CTX_SLEEPABLE)
> >Can't we make this implicit? Are there any other options?
>
> Maybe? I wasn't sure how we'd describe somthing like getpid() which
> isn't supposed to
Hi!
> > >6. What's the goal of validation of the input arguments?
> > >Kernel code must do this validation anyway, right.
> > >Any non-trivial validation is hard, e.g. even for open the validation
> > >function
> > >for file name would ne
On Wed, Jun 25, 2025 at 10:52:46AM +0200, Dmitry Vyukov wrote:
On Tue, 24 Jun 2025 at 22:04, Sasha Levin wrote:
>6. What's the goal of validation of the input arguments?
>Kernel code must do this validation anyway, right.
>Any non-trivial validation is hard, e.g. even for open
On Tue, 24 Jun 2025 at 22:04, Sasha Levin wrote:
> >3. To reduce duplication we could use more type information, e.g. I was
> >always
> >frustrated that close is just:
> >
> >SYSCALL_DEFINE1(close, unsigned int, fd)
> >
> >whereas if we would do:
> >
> >typedef int fd_t;
> >SYSCALL_DEFINE1(close
On Tue, 24 Jun 2025 at 22:04, Sasha Levin wrote:
> >6. What's the goal of validation of the input arguments?
> >Kernel code must do this validation anyway, right.
> >Any non-trivial validation is hard, e.g. even for open the validation
> >function
> >for fil
atically:
https://raw.githubusercontent.com/google/syzkaller/refs/heads/master/sys/linux/auto.txt
Though, oviously that won't have user-readable string descriptions, can't be
used as a source
of truth, and may be challenging to integrate into kernel build process.
Though, extracting some o
Hi!
> 6. What's the goal of validation of the input arguments?
> Kernel code must do this validation anyway, right.
> Any non-trivial validation is hard, e.g. even for open the validation function
> for file name would need to have access to flags and check file precense
about parameter
> types and their semantic meaning, not the validation part.
> The conformance tests should test that actual syscall checking of
> arguments, not the validation added by this framework.
Exactly.
I do not think that it makes sense to encode the argument ranges and
functions to
eads/master/sys/linux/auto.txt
Though, oviously that won't have user-readable string descriptions, can't be
used as a source
of truth, and may be challenging to integrate into kernel build process.
Though, extracting some of that info automatically may be nice.
2. Does this framework
On Wed, Jun 18, 2025 at 02:29:37PM -0700, Kees Cook wrote:
On Sat, Jun 14, 2025 at 09:48:39AM -0400, Sasha Levin wrote:
This patch series introduces a framework for formally specifying kernel
APIs, addressing the long-standing challenge of maintaining stable
interfaces between the kernel and
On Sat, Jun 14, 2025 at 09:48:39AM -0400, Sasha Levin wrote:
> This patch series introduces a framework for formally specifying kernel
> APIs, addressing the long-standing challenge of maintaining stable
> interfaces between the kernel and user-space programs. As outlined in
> previous
On Sat, 14 Jun 2025 09:48:39 -0400
Sasha Levin wrote:
> This patch series introduces a framework for formally specifying kernel
> APIs, addressing the long-standing challenge of maintaining stable
> interfaces between the kernel and user-space programs. As outlined in
> previous
The kapi tool extracts and displays kernel API specifications.
Signed-off-by: Sasha Levin
---
Documentation/admin-guide/kernel-api-spec.rst | 198 ++-
tools/kapi/.gitignore | 4 +
tools/kapi/Cargo.toml | 19 +
tools/kapi/src/extractor
Add IOCTL API specification support to the kernel API specification
framework. This enables detailed documentation and runtime validation of
IOCTL interfaces.
Key features:
- IOCTL specification structure with command info and parameter details
- Registration/unregistration functions for IOCTL
Add a debugfs interface to expose kernel API specifications at runtime.
This allows tools and users to query the complete API specifications
through the debugfs filesystem.
The interface provides:
- /sys/kernel/debug/kapi/list - lists all available API specifications
- /sys/kernel/debug/kapi
This patch series introduces a framework for formally specifying kernel
APIs, addressing the long-standing challenge of maintaining stable
interfaces between the kernel and user-space programs. As outlined in
previous discussions about kernel ABI stability, the lack of
machine-readable API
Add a comprehensive framework for formally documenting kernel APIs with
inline specifications. This framework provides:
- Structured API documentation with parameter specifications, return
values, error conditions, and execution context requirements
- Runtime validation capabilities for
On 05.06.25 15:51, Lorenzo Stoakes wrote:
The walk_page_range_novma() function is rather confusing - it supports two
modes, one used often, the other used only for debugging.
The first mode is the common case of traversal of kernel page tables, which
is what nearly all callers use this for
On Wed, Jun 11, 2025 at 05:49:14PM -0400, Joel Fernandes wrote:
>
>
> On 6/11/2025 1:56 PM, Uladzislau Rezki (Sony) wrote:
> > Update the documentation about rcu_normal_wake_from_gp parameter.
> >
> > Signed-off-by: Uladzislau Rezki (Sony)
>
> Reviewed-by: Joel Fernandes
>
Thanks!
--
Uladzi
On 6/11/2025 1:56 PM, Uladzislau Rezki (Sony) wrote:
> Update the documentation about rcu_normal_wake_from_gp parameter.
>
> Signed-off-by: Uladzislau Rezki (Sony)
Reviewed-by: Joel Fernandes
Thanks.
> ---
> Documentation/admin-guide/kernel-parameters.txt | 3 ++-
>
Update the documentation about rcu_normal_wake_from_gp parameter.
Signed-off-by: Uladzislau Rezki (Sony)
---
Documentation/admin-guide/kernel-parameters.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation
Update the documentation about rcu_normal_wake_from_gp parameter.
Signed-off-by: Uladzislau Rezki (Sony)
---
Documentation/admin-guide/kernel-parameters.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin
vma() function is rather confusing - it supports
> > >> two
> > >> modes, one used often, the other used only for debugging.
> > >>
> > >> The first mode is the common case of traversal of kernel page tables,
> > >> which
> > >>
ed often, the other used only for debugging.
> >>
> >> The first mode is the common case of traversal of kernel page tables, which
> >> is what nearly all callers use this for.
> >>
> >> Secondly it provides an unusual debugging interface that allows for the
&g
On 05.06.25 21:19, Jann Horn wrote:
On Wed, Jun 4, 2025 at 4:21 PM Lorenzo Stoakes
wrote:
The walk_page_range_novma() function is rather confusing - it supports two
modes, one used often, the other used only for debugging.
The first mode is the common case of traversal of kernel page tables
On Wed, Jun 4, 2025 at 4:21 PM Lorenzo Stoakes
wrote:
> The walk_page_range_novma() function is rather confusing - it supports two
> modes, one used often, the other used only for debugging.
>
> The first mode is the common case of traversal of kernel page tables, which
> is
On 6/5/25 15:51, Lorenzo Stoakes wrote:
> The walk_page_range_novma() function is rather confusing - it supports two
> modes, one used often, the other used only for debugging.
>
> The first mode is the common case of traversal of kernel page tables, which
> is what nearly all c
The walk_page_range_novma() function is rather confusing - it supports two
modes, one used often, the other used only for debugging.
The first mode is the common case of traversal of kernel page tables, which
is what nearly all callers use this for.
Secondly it provides an unusual debugging
200, Vlastimil Babka wrote:
>>>> On 6/4/25 16:19, Lorenzo Stoakes wrote:
>>>>> The walk_page_range_novma() function is rather confusing - it supports two
>>>>> modes, one used often, the other used only for debugging.
>>>>>
>>>>>
> The walk_page_range_novma() function is rather confusing - it supports two
> >>> modes, one used often, the other used only for debugging.
> >>>
> >>> The first mode is the common case of traversal of kernel page tables,
> >>> which
> >>>
mode is the common case of traversal of kernel page tables, which
> > is what nearly all callers use this for.
> >
> > Secondly it provides an unusual debugging interface that allows for the
> > traversal of page tables in a userland range of memory even for that memory
>
ed often, the other used only for debugging.
>>>
>>> The first mode is the common case of traversal of kernel page tables, which
>>> is what nearly all callers use this for.
>>>
>>> Secondly it provides an unusual debugging interface that allows fo
mode is the common case of traversal of kernel page tables, which
> > is what nearly all callers use this for.
> >
> > Secondly it provides an unusual debugging interface that allows for the
> > traversal of page tables in a userland range of memory even for that memory
> >
On 6/4/25 16:19, Lorenzo Stoakes wrote:
> The walk_page_range_novma() function is rather confusing - it supports two
> modes, one used often, the other used only for debugging.
>
> The first mode is the common case of traversal of kernel page tables, which
> is what nearly all c
On 04.06.25 16:19, Lorenzo Stoakes wrote:
The walk_page_range_novma() function is rather confusing - it supports two
modes, one used often, the other used only for debugging.
The first mode is the common case of traversal of kernel page tables, which
is what nearly all callers use this for
On 6/4/25 10:19 PM, Lorenzo Stoakes wrote:
The walk_page_range_novma() function is rather confusing - it supports two
modes, one used often, the other used only for debugging.
The first mode is the common case of traversal of kernel page tables, which
is what nearly all callers use this for
On Wed, Jun 04, 2025 at 03:19:58PM +0100, Lorenzo Stoakes wrote:
> The walk_page_range_novma() function is rather confusing - it supports two
> modes, one used often, the other used only for debugging.
>
> The first mode is the common case of traversal of kernel page tables, whi
On 03.06.25 21:22, Lorenzo Stoakes wrote:
The walk_page_range_novma() function is rather confusing - it supports two
modes, one used often, the other used only for debugging.
The first mode is the common case of traversal of kernel page tables, which
is what nearly all callers use this for
On Wed, Jun 4, 2025 at 7:21 AM Lorenzo Stoakes
wrote:
>
> The walk_page_range_novma() function is rather confusing - it supports two
> modes, one used often, the other used only for debugging.
>
> The first mode is the common case of traversal of kernel page tables, which
>
The walk_page_range_novma() function is rather confusing - it supports two
modes, one used often, the other used only for debugging.
The first mode is the common case of traversal of kernel page tables, which
is what nearly all callers use this for.
Secondly it provides an unusual debugging
On Wed, Jun 04, 2025 at 02:26:57PM +0200, Oscar Salvador wrote:
> On Wed, Jun 04, 2025 at 10:09:05AM +0100, Lorenzo Stoakes wrote:
> > Nice idea to move to mm/internal.h also :) I like this...
> >
> > Will fixup on respin
>
> Dumb question but IIUC, walk_page_range_novma() will only be used by
> pt
On Wed, Jun 04, 2025 at 10:09:05AM +0100, Lorenzo Stoakes wrote:
> Nice idea to move to mm/internal.h also :) I like this...
>
> Will fixup on respin
Dumb question but IIUC, walk_page_range_novma() will only be used by
ptdump from now on, so why not stick it into mm/ptdump.c, which is where
the o
mode is the common case of traversal of kernel page tables, which
> > is what nearly all callers use this for.
>
> ... and what people should be using it for 🙂
:)
Yeah the whole intent of this patch is to detach the 'crazy debug' bit from
the 'used by arches all over
, one used often, the other used only for debugging.
> > >
> > > The first mode is the common case of traversal of kernel page tables,
> > > which
> > > is what nearly all callers use this for.
> >
> > ... and what people should be using it for 🙂
>
mode is the common case of traversal of kernel page tables, which
is what nearly all callers use this for.
... and what people should be using it for 🙂
Secondly it provides an unusual debugging interface that allows for the
traversal of page tables in a userland range of memory even for that
mode is the common case of traversal of kernel page tables, which
> > is what nearly all callers use this for.
>
> ... and what people should be using it for 🙂
>
> >
> > Secondly it provides an unusual debugging interface that allows for the
> > traversal of pa
The walk_page_range_novma() function is rather confusing - it supports two
modes, one used often, the other used only for debugging.
The first mode is the common case of traversal of kernel page tables, which
is what nearly all callers use this for.
Secondly it provides an unusual debugging
On Thu, May 22, 2025 at 6:04 PM Alexei Starovoitov
wrote:
>
> On Wed, May 21, 2025 at 8:00 AM Alan Maguire wrote:
> >
> > > Hi Alan,
> > >
> > > Thanks for taking a look at this. I've been following your related effort
> > > to allow /s
Hello:
This series was applied to bpf/bpf-next.git (master)
by Andrii Nakryiko :
On Tue, 20 May 2025 14:01:16 +0100 you wrote:
> I'd like to cut down the memory usage of parsing vmlinux BTF in ebpf-go.
> With some upcoming changes the library is sitting at 5MiB for a parse.
> Most of that memory
On Wed, May 21, 2025 at 8:00 AM Alan Maguire wrote:
>
> > Hi Alan,
> >
> > Thanks for taking a look at this. I've been following your related effort
> > to allow /sys/kernel/btf/vmlinux as a module in support of small systems
> > with kernel-size constrain
> Hi Alan,
>
> Thanks for taking a look at this. I've been following your related effort
> to allow /sys/kernel/btf/vmlinux as a module in support of small systems
> with kernel-size constraints, and wondered how this series might affect
> that work? Such support would
h64; all worked perfectly. Thanks!
Hi Alan,
Thanks for taking a look at this. I've been following your related effort
to allow /sys/kernel/btf/vmlinux as a module in support of small systems
with kernel-size constraints, and wondered how this series might affect
that work? Such support would
| 3 +-
kernel/bpf/sysfs_btf.c | 32
tools/lib/bpf/btf.c| 89 +-
tools/testing/selftests/bpf/prog_tests/btf_sysfs.c | 81
4 files changed, 186 insertions(+), 19 deletions(-)
---
base-c
When running hugevm tests in a machine without kernel config present, e.g.,
a VM running a kernel without CONFIG_IKCONFIG_PROC nor /boot/config-*,
skip hugevm tests, which reads kernel config to get page table level
information.
Signed-off-by: Zi Yan
Acked-by: Lorenzo Stoakes
---
.../selftests
Two guard_regions tests on userfaultfd fail when userfaultfd is not
present. Skip them instead.
hugevm test reads kernel config to get page table level information and
fails when neither /proc/config.gz nor /boot/config-* is present. Skip
it instead.
Zi Yan (2):
selftests/mm: skip
On Thu, May 15, 2025 at 07:43:40PM +0100, Lorenzo Stoakes wrote:
> On Thu, May 15, 2025 at 02:23:33PM -0400, Zi Yan wrote:
> > When running hugevm tests in a machine without kernel config present, e.g.,
> > a VM running a kernel without CONFIG_IKCONFIG_PROC nor /boot/config-*,
On Thu, May 15, 2025 at 02:23:33PM -0400, Zi Yan wrote:
> When running hugevm tests in a machine without kernel config present, e.g.,
> a VM running a kernel without CONFIG_IKCONFIG_PROC nor /boot/config-*,
> skip hugevm tests, which reads kernel config to get page table level
>
When running hugevm tests in a machine without kernel config present, e.g.,
a VM running a kernel without CONFIG_IKCONFIG_PROC nor /boot/config-*,
skip hugevm tests, which reads kernel config to get page table level
information.
Signed-off-by: Zi Yan
---
.../selftests/mm/va_high_addr_switch.sh
> I'd like to cut down the memory usage of parsing vmlinux BTF in ebpf-go.
> With some upcoming changes the library is sitting at 5MiB for a parse.
> Most of that memory is simply copying the BTF blob into user space.
> By allowing vmlinux BTF to be mmapped read-only into user space I can
> cut mem
On Fri, May 09, 2025 at 12:01:24PM -0700, Kees Cook wrote:
> On Fri, May 09, 2025 at 02:54:13PM +0200, Joel Granados wrote:
> > Move cad_pid as well as supporting function proc_do_cad_pid into
> > kernel/pic.c. Replaced call to __do_proc_dointvec with proc_dointvec
> > inside
t for mmapable vmlinux BTF
libbpf: Use mmap to parse vmlinux BTF from sysfs
include/asm-generic/vmlinux.lds.h | 3 +-
kernel/bpf/sysfs_btf.c | 32
tools/lib/bpf/btf.c| 85 ++
tools/te
On Fri, May 09, 2025 at 02:54:10PM +0200, Joel Granados wrote:
> make sysctl_max_threads static as it no longer needs to be exported into
> sysctl.c.
>
> This is part of a greater effort to move ctl tables into their
> respective subsystems which will reduce the merge confli
On Fri, May 09, 2025 at 02:54:13PM +0200, Joel Granados wrote:
> Move cad_pid as well as supporting function proc_do_cad_pid into
> kernel/pic.c. Replaced call to __do_proc_dointvec with proc_dointvec
> inside proc_do_cad_pid which requires the copy of the ctl_table to
> handle th
On Fri, May 09, 2025 at 02:54:12PM +0200, Joel Granados wrote:
> Move the ctl_table with the "tainted" proc_name into kernel/panic.c.
> With it moves the proc_tainted helper function.
>
> This is part of a greater effort to move ctl tables into their
> respective subsyst
On Fri, May 09, 2025 at 02:54:16PM +0200, Joel Granados wrote:
> Remove the following headers from the include list in sysctl.c.
>
> * These are removed as the related variables are no longer there.
> ===
> Include Related Var
> ==
On Fri, May 09, 2025 at 02:54:14PM +0200, Joel Granados wrote:
> This is part of a greater effort to move ctl tables into their
> respective subsystems which will reduce the merge conflicts in
> kernel/sysctl.c.
>
> Signed-off-by: Joel Granados
Another undocumented sysctl. ;) Thi
On Fri, May 09, 2025 at 02:54:10PM +0200, Joel Granados wrote:
> make sysctl_max_threads static as it no longer needs to be exported into
> sysctl.c.
>
> This is part of a greater effort to move ctl tables into their
> respective subsystems which will reduce the merge confli
On Fri, May 09, 2025 at 02:54:12PM +0200, Joel Granados wrote:
> Move the ctl_table with the "tainted" proc_name into kernel/panic.c.
> With it moves the proc_tainted helper function.
>
> This is part of a greater effort to move ctl tables into their
> respective subsyst
On Fri, May 09, 2025 at 02:54:13PM +0200, Joel Granados wrote:
> Move cad_pid as well as supporting function proc_do_cad_pid into
> kernel/pic.c. Replaced call to __do_proc_dointvec with proc_dointvec
> inside proc_do_cad_pid which requires the copy of the ctl_table to
> handle th
On Fri, May 09, 2025 at 02:54:16PM +0200, Joel Granados wrote:
> Remove the following headers from the include list in sysctl.c.
>
> * These are removed as the related variables are no longer there.
> ===
> Include Related Var
> ==
This is part of a greater effort to move ctl tables into their
respective subsystems which will reduce the merge conflicts in
kernel/sysctl.c.
Signed-off-by: Joel Granados
---
kernel/panic.c | 10 ++
kernel/sysctl.c | 10 --
2 files changed, 10 insertions(+), 10 deletions
Move cad_pid as well as supporting function proc_do_cad_pid into
kernel/pic.c. Replaced call to __do_proc_dointvec with proc_dointvec
inside proc_do_cad_pid which requires the copy of the ctl_table to
handle the temp value.
This is part of a greater effort to move ctl tables into their
respective
are no longer needed as intermediate includes
==
Include
==
linux/filter.h
linux/binfmts.h
Signed-off-by: Joel Granados
---
kernel/sysctl.c | 20
1 file changed, 20 deletions(-)
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index
make sysctl_max_threads static as it no longer needs to be exported into
sysctl.c.
This is part of a greater effort to move ctl tables into their
respective subsystems which will reduce the merge conflicts in
kernel/sysctl.c.
Signed-off-by: Joel Granados
---
include/linux/sysctl.h | 3
Move the ctl_table with the "tainted" proc_name into kernel/panic.c.
With it moves the proc_tainted helper function.
This is part of a greater effort to move ctl tables into their
respective subsystems which will reduce the merge conflicts in
kernel/sysctl.c.
Signed-off-by: Joe
>>> callback invocation.
>>>
>>> Platform:
>>> Architecture: arm64
>>> Virtualized environment: Apple Silicon M2 (Apple Virtualization Framework)
>>> Kernel version: 6.15.0-rc4+
>>> Attached Config: CONFIG_PREEMPT_VOLUN
t for mmapable vmlinux BTF
libbpf: Use mmap to parse vmlinux BTF from sysfs
include/asm-generic/vmlinux.lds.h | 3 +-
kernel/bpf/sysfs_btf.c | 37 ++
tools/lib/bpf/btf.c| 83 +++---
tools/te
er (3):
btf: allow mmap of vmlinux btf
selftests: bpf: add a test for mmapable vmlinux BTF
libbpf: Use mmap to parse vmlinux BTF from sysfs
include/asm-generic/vmlinux.lds.h | 3 +-
kernel/bpf/sysfs_btf.c | 36 +-
tools/lib/bpf/
vmlinux btf
> selftests: bpf: add a test for mmapable vmlinux BTF
>
> include/asm-generic/vmlinux.lds.h | 3 +-
> kernel/bpf/sysfs_btf.c | 25 ++-
> tools/testing/selftests/bpf/prog_tests/btf_sysfs.c | 79
> ++
usage by about 75%.
Signed-off-by: Lorenz Bauer
---
Lorenz Bauer (2):
btf: allow mmap of vmlinux btf
selftests: bpf: add a test for mmapable vmlinux BTF
include/asm-generic/vmlinux.lds.h | 3 +-
kernel/bpf/sysfs_btf.c | 25 ++-
Hello,
syzbot found the following issue on:
HEAD commit:82303a059aab selftests/bpf: Mitigate sockmap_ktls disconne..
git tree: bpf
console output: https://syzkaller.appspot.com/x/log.txt?x=17564c7058
kernel config: https://syzkaller.appspot.com/x/.config?x=2a31f7155996562
From: "Paul E. McKenney"
The srcu_lockdep.sh currently blindly trusts the rcutorture SRCU-P
scenario to build its kernel with lockdep enabled. Of course, this
dependency might not be obvious to someone rebalancing SRCU scenarios.
This commit therefore adds code to srcu_lockdep.sh tha
From: "Paul E. McKenney"
The srcu_lockdep.sh currently blindly trusts the rcutorture SRCU-P
scenario to build its kernel with lockdep enabled. Of course, this
dependency might not be obvious to someone rebalancing SRCU scenarios.
This commit therefore adds code to srcu_lockdep.sh tha
> Signed-off-by: Nathan Fontenot
>> Signed-off-by: Terry Bowman
>> ---
>> include/linux/ioport.h | 3 +++
>> kernel/resource.c | 55 +++---
>> 2 files changed, 54 insertions(+), 4 deletions(-)
>>
>> diff --git a/inclu
On 4/4/2025 8:25 AM, Andy Shevchenko wrote:
> On Fri, Apr 04, 2025 at 02:16:39PM +0100, Jonathan Cameron wrote:
>> On Thu, 3 Apr 2025 13:33:12 -0500 Terry Bowman wrote:
>
>>> Add a release_Sam_region_adjustable() interface to allow for
>>
>> Who is Sam? (typo)
>
> Somebody's uncle?
>
> ...
>
end to the
> common code and a new release_srmem_region_adjustable() is added to
> release SOFT RESERVE resources.
>
> Signed-off-by: Nathan Fontenot
> Signed-off-by: Terry Bowman
> ---
> include/linux/ioport.h | 3 +++
> kernel/resource.c | 55 +++
On Fri, Apr 04, 2025 at 02:16:39PM +0100, Jonathan Cameron wrote:
> On Thu, 3 Apr 2025 13:33:12 -0500 Terry Bowman wrote:
> > Add a release_Sam_region_adjustable() interface to allow for
>
> Who is Sam? (typo)
Somebody's uncle?
...
> > #ifdef CONFIG_MEMORY_HOTREMOVE
> > extern void release
Hi Terry,
kernel test robot noticed the following build warnings:
[auto build test WARNING on aae0594a7053c60b82621136257c8b648c67b512]
url:
https://github.com/intel-lab-lkp/linux/commits/Terry-Bowman/kernel-resource-Provide-mem-region-release-for-SOFT-RESERVES/20250404-023601
base
Hi Andy,
Thanks for reviewing this. I'll make updates for all you pointed out below.
Regards,
Terry
On 4/3/2025 1:40 PM, Andy Shevchenko wrote:
> On Thu, Apr 03, 2025 at 01:33:12PM -0500, Terry Bowman wrote:
>> From: Nathan Fontenot
>>
>> Add a release_Sam_region_adjustable() interface to allow
tenot
Signed-off-by: Terry Bowman
---
include/linux/ioport.h | 3 +++
kernel/resource.c | 55 +++---
2 files changed, 54 insertions(+), 4 deletions(-)
diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 5385349f0b8a..718360c9c724 100644
On Thu, Apr 03, 2025 at 01:33:12PM -0500, Terry Bowman wrote:
> From: Nathan Fontenot
>
> Add a release_Sam_region_adjustable() interface to allow for
> removing SOFT RESERVE memory resources. This extracts out the code
> to remove a mem region into a common __release_mem_region_adjustable()
> ro
The srcu_lockdep.sh currently blindly trusts the rcutorture SRCU-P
scenario to build its kernel with lockdep enabled. Of course, this
dependency might not be obvious to someone rebalancing SRCU scenarios.
This commit therefore adds code to srcu_lockdep.sh that verifies that
the .config file has
1 - 100 of 29786 matches
Mail list logo
