* Re: [PATCH 1/2] kallsyms: show function parameter info in oops/WARN dumps
From: Sasha Levin @ 2026-03-24 16:00 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Andrew Morton, Masahiro Yamada, Nathan Chancellor, Nicolas Schier,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Peter Zijlstra, Josh Poimboeuf, Petr Mladek,
Alexei Starovoitov, Jonathan Corbet, David Gow, Kees Cook,
Greg KH, Luis Chamberlain, Steven Rostedt, Helge Deller,
Randy Dunlap, Geert Uytterhoeven, Juergen Gross, James Bottomley,
Alexey Dobriyan, Vlastimil Babka, Laurent Pinchart, Petr Pavlu,
X86 ML, LKML, Linux Kbuild mailing list, open list:DOCUMENTATION,
linux-modules, bpf
In-Reply-To: <CAADnVQJjJwRtUQNZAhLoXF7DYprhU97xJReZg9izV7n3f7=uJQ@mail.gmail.com>
On Tue, Mar 24, 2026 at 08:03:30AM -0700, Alexei Starovoitov wrote:
>On Mon, Mar 23, 2026 at 9:49 AM Sasha Levin <sashal@kernel.org> wrote:
>>
>> Embed DWARF-derived function parameter name and type information in the
>> kernel image so that oops and WARN dumps display the crashing function's
>> register-passed arguments with their names, types, and values.
>>
>> A new build-time tool (scripts/gen_paraminfo.c) parses DW_TAG_subprogram
>> and DW_TAG_formal_parameter entries from DWARF .debug_info, extracting
>> parameter names and human-readable type strings. The resulting tables are
>> stored in .rodata using the same two-phase link approach as lineinfo.
>>
>> At runtime, kallsyms_show_paraminfo() performs a binary search on the
>> paraminfo tables, maps parameters to x86-64 calling convention registers
>> (RDI, RSI, RDX, RCX, R8, R9), and prints each parameter's name, type,
>> and value from pt_regs. If a parameter value matches the page fault
>> address (CR2), it is highlighted with "<-- fault address".
>>
>> Integration at show_regs() means this works for both oops and WARN()
>> automatically, since both paths provide full pt_regs at the exception
>> point.
>>
>> Example output:
>>
>> Function parameters (ext4_readdir):
>> file (struct file *) = 0xffff888123456000
>> ctx (struct dir_context *) = 0x0000000000001234 <-- fault address
>>
>> Gated behind CONFIG_KALLSYMS_PARAMINFO (depends on CONFIG_KALLSYMS_LINEINFO).
>> Adds approximately 1-2 MB to the kernel image for ~58K functions.
>>
>> Assisted-by: Claude:claude-opus-4-6
>> Signed-off-by: Sasha Levin <sashal@kernel.org>
>
>Nack.
>
>You asked claude to reinvent pahole and BTF and it did it
>completely missing years of fine tuning that pahole does.
Let's keep this on the technical side please.
>dwarf cannot be trusted as-is. pahole converts it carefully
>by analyzing optimized out arguments and dropping signatures
Fair point about pahole and optimized-out args. The problem is that BTF depends
on BPF_SYSCALL, and the environments I care about can't enable either.
Automotive, robotics, and safety configs all have DWARF and KALLSYMS but no
path to BTF.
>from BTF that are not accurate. This work is still ongoing.
>For example see this set:
>https://lore.kernel.org/bpf/20260320190917.1970524-1-yonghong.song@linux.dev/
Ack. I wasn't familiar with this, and looks like it makes the 2nd patch in this
series unnecessary.
>pahole isn't perfect, but what you attempted to do here
>is just broken.
I hear you that raw DWARF isn't perfect with optimized code, but I'd rather
show best-effort info than nothing. Happy to mark it as such in the output.
Open to suggestions on improving accuracy without the BTF dependency.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH] doc: Add CPU Isolation documentation
From: Waiman Long @ 2026-03-24 16:00 UTC (permalink / raw)
To: Sebastian Andrzej Siewior, Frederic Weisbecker
Cc: LKML, Anna-Maria Behnsen, Gabriele Monaco, Ingo Molnar,
Jonathan Corbet, Marcelo Tosatti, Marco Crivellari, Michal Hocko,
Paul E . McKenney, Peter Zijlstra, Phil Auld, Steven Rostedt,
Thomas Gleixner, Valentin Schneider, Vlastimil Babka, linux-doc
In-Reply-To: <20260324153823.VKwebBuG@linutronix.de>
On 3/24/26 11:38 AM, Sebastian Andrzej Siewior wrote:
> On 2025-08-09 11:42:47 [+0200], Frederic Weisbecker wrote:
> …
>> --- /dev/null
>> +++ b/Documentation/admin-guide/cpu-isolation.rst
>> @@ -0,0 +1,338 @@
> …
>> +CPUSET configuration (cgroup v2)
>> +--------------------------------
>> +
>> +Assuming cgroup v2 is mounted to /sys/fs/cgroup, the following script
>> +isolates CPU 7 from scheduler domains.
>> +
>> + cd /sys/fs/cgroup
>> + # Activate the cpuset subsystem
>> + echo +cpuset > cgroup.subtree_control
>> + # Create partition to be isolated
>> + mkdir test
>> + cd test
>> + echo +cpuset > cgroup.subtree_control
>> + # Isolate CPU 7
>> + echo 7 > cpuset.cpus
>> + echo "isolated" > cpuset.cpus.partition
> while looking at this again, shouldn't you also do
> echo 7 > cpuset.cpus.exclusive
>
> to ensure the CPU isn't used somewhere else?
For backport compatibility, the use of cpuset.cpus.exclusive is optional
for creating a local partition underneath the cgroup root. The example
should still work without setting cpuset.cpus.exclusive.
Cheers,
Longman
^ permalink raw reply
* [PATCH] docs: driver-api: fix 6 spelling typos in Documentation/driver-api
From: tovicito @ 2026-03-24 15:49 UTC (permalink / raw)
To: corrbet; +Cc: skhan, linux-doc, linux-kernel, tovicito
Signed-off-by: tovicito <tovictakamine@gmail.com>
---
Documentation/driver-api/acpi/acpi-drivers.rst | 2 +-
Documentation/driver-api/cxl/platform/acpi/cedt.rst | 2 +-
Documentation/driver-api/cxl/platform/bios-and-efi.rst | 2 +-
Documentation/driver-api/dmaengine/pxa_dma.rst | 2 +-
Documentation/driver-api/libata.rst | 2 +-
Documentation/driver-api/pci/p2pdma.rst | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/driver-api/acpi/acpi-drivers.rst b/Documentation/driver-api/acpi/acpi-drivers.rst
index b1fbbddb8..376b6d8a6 100644
--- a/Documentation/driver-api/acpi/acpi-drivers.rst
+++ b/Documentation/driver-api/acpi/acpi-drivers.rst
@@ -47,7 +47,7 @@ generally be avoided and so struct acpi_driver objects should not be used.
Moreover, a device ID is necessary to bind a driver directly to an ACPI device
node, but device IDs are not generally associated with all of them. Some of
them contain alternative information allowing the corresponding pieces of
-hardware to be identified, for example represeted by an _ADR object return
+hardware to be identified, for example represented by an _ADR object return
value, and device IDs are not used in those cases. In consequence, confusingly
enough, binding an ACPI driver to an ACPI device node may even be impossible.
diff --git a/Documentation/driver-api/cxl/platform/acpi/cedt.rst b/Documentation/driver-api/cxl/platform/acpi/cedt.rst
index 1d9c9d359..217a75fb4 100644
--- a/Documentation/driver-api/cxl/platform/acpi/cedt.rst
+++ b/Documentation/driver-api/cxl/platform/acpi/cedt.rst
@@ -55,7 +55,7 @@ voltile vs persistent, etc). One or more bits may be set. ::
Bit[1]: CXL Type 3 Memory
Bit[2]: Volatile Memory
Bit[3]: Persistent Memory
- Bit[4]: Fixed Config (HPA cannot be re-used)
+ Bit[4]: Fixed Config (HPA cannot be reused)
INTRA-host-bridge interleave (multiple devices on one host bridge) is NOT
reported in this structure, and is solely defined via CXL device decoder
diff --git a/Documentation/driver-api/cxl/platform/bios-and-efi.rst b/Documentation/driver-api/cxl/platform/bios-and-efi.rst
index a4b44c018..5d918b06f 100644
--- a/Documentation/driver-api/cxl/platform/bios-and-efi.rst
+++ b/Documentation/driver-api/cxl/platform/bios-and-efi.rst
@@ -277,7 +277,7 @@ The CFMWS field of the CEDT has special restriction bits which describe whether
the described memory region allows volatile or persistent memory (or both). If
the platform intends to support either:
-1) A device with multiple medias, or
+1) A device with multiple media, or
2) Using a persistent memory device as normal memory
A platform may wish to create multiple CEDT CFMWS entries to describe the same
diff --git a/Documentation/driver-api/dmaengine/pxa_dma.rst b/Documentation/driver-api/dmaengine/pxa_dma.rst
index 442ee691a..8f9da66b0 100644
--- a/Documentation/driver-api/dmaengine/pxa_dma.rst
+++ b/Documentation/driver-api/dmaengine/pxa_dma.rst
@@ -40,7 +40,7 @@ Design
======
a) Virtual channels
Same concept as in sa11x0 driver, ie. a driver was assigned a "virtual
-channel" linked to the requestor line, and the physical DMA channel is
+channel" linked to the requester line, and the physical DMA channel is
assigned on the fly when the transfer is issued.
b) Transfer anatomy for a scatter-gather transfer
diff --git a/Documentation/driver-api/libata.rst b/Documentation/driver-api/libata.rst
index 93d97fe78..28b8437f6 100644
--- a/Documentation/driver-api/libata.rst
+++ b/Documentation/driver-api/libata.rst
@@ -286,7 +286,7 @@ and other exceptional conditions. The primary responsibility of an
implementation is to call :c:func:`ata_std_error_handler`.
:c:func:`ata_std_error_handler` will perform a standard error handling sequence
-to resurect failed devices, detach lost devices and add new devices (if any).
+to resurrect failed devices, detach lost devices and add new devices (if any).
This function will call the various reset operations for a port, as needed.
These operations are as follows.
diff --git a/Documentation/driver-api/pci/p2pdma.rst b/Documentation/driver-api/pci/p2pdma.rst
index 280673b50..d3f406cca 100644
--- a/Documentation/driver-api/pci/p2pdma.rst
+++ b/Documentation/driver-api/pci/p2pdma.rst
@@ -38,7 +38,7 @@ for all usage refcounts to reach zero.
At the lowest level the P2P subsystem offers a naked struct p2p_provider that
delegates lifecycle management to the providing driver. It is expected that
drivers using this option will wrap their MMIO memory in DMABUF and use DMABUF
-to provide an invalidation shutdown. These MMIO addresess have no struct page, and
+to provide an invalidation shutdown. These MMIO addresses have no struct page, and
if used with mmap() must create special PTEs. As such there are very few
kernel uAPIs that can accept pointers to them; in particular they cannot be used
with read()/write(), including O_DIRECT.
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] doc: Add CPU Isolation documentation
From: Sebastian Andrzej Siewior @ 2026-03-24 15:38 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: LKML, Anna-Maria Behnsen, Gabriele Monaco, Ingo Molnar,
Jonathan Corbet, Marcelo Tosatti, Marco Crivellari, Michal Hocko,
Paul E . McKenney, Peter Zijlstra, Phil Auld, Steven Rostedt,
Thomas Gleixner, Valentin Schneider, Vlastimil Babka, Waiman Long,
linux-doc
In-Reply-To: <20250809094247.8384-1-frederic@kernel.org>
On 2025-08-09 11:42:47 [+0200], Frederic Weisbecker wrote:
…
> --- /dev/null
> +++ b/Documentation/admin-guide/cpu-isolation.rst
> @@ -0,0 +1,338 @@
…
> +CPUSET configuration (cgroup v2)
> +--------------------------------
> +
> +Assuming cgroup v2 is mounted to /sys/fs/cgroup, the following script
> +isolates CPU 7 from scheduler domains.
> +
> + cd /sys/fs/cgroup
> + # Activate the cpuset subsystem
> + echo +cpuset > cgroup.subtree_control
> + # Create partition to be isolated
> + mkdir test
> + cd test
> + echo +cpuset > cgroup.subtree_control
> + # Isolate CPU 7
> + echo 7 > cpuset.cpus
> + echo "isolated" > cpuset.cpus.partition
while looking at this again, shouldn't you also do
echo 7 > cpuset.cpus.exclusive
to ensure the CPU isn't used somewhere else?
Sebastian
^ permalink raw reply
* Re: [PATCH] bootconfig: Apply early options from embedded config
From: Masami Hiramatsu @ 2026-03-24 15:38 UTC (permalink / raw)
To: Breno Leitao
Cc: Jonathan Corbet, Shuah Khan, linux-kernel, linux-trace-kernel,
linux-doc, oss, paulmck, rostedt, kernel-team
In-Reply-To: <20260324-early_bootconfig-v1-1-1c0e625aff06@debian.org>
On Tue, 24 Mar 2026 05:52:33 -0700
Breno Leitao <leitao@debian.org> wrote:
> Right not is impossible to set early parameters in bootconfig, which
> limits the usage of bootconfig to some critical parameters.
>
> Add bootconfig_apply_early_params() which walks all kernel.* keys in the
> parsed XBC tree and calls do_early_param() for each one. It is called
> from setup_boot_config() immediately after a successful xbc_init() on
> the embedded data, which happens before parse_early_param() runs in
> start_kernel().
>
> This allows early options such as:
>
> kernel.mitigations = off
> kernel.irqchip.gicv3_pseudo_nmi = 1
>
> to be placed in the embedded bootconfig and take effect, without
> requiring them to be on the kernel command line.
>
> Early options in initrd bootconfig are still silently ignored, as the
> initrd is only available after the early param window has closed.
>
> Document this behaviour in both Kconfig and the admin guide.
Thanks Breno, this makes things clearer.
This looks good to me.
Thanks,
>
> Signed-off-by: Breno Leitao <leitao@debian.org>
> ---
> Documentation/admin-guide/bootconfig.rst | 4 ++
> init/Kconfig | 6 +++
> init/main.c | 67 +++++++++++++++++++++++++++++++-
> 3 files changed, 76 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/admin-guide/bootconfig.rst b/Documentation/admin-guide/bootconfig.rst
> index f712758472d5c..e820f33d3ad16 100644
> --- a/Documentation/admin-guide/bootconfig.rst
> +++ b/Documentation/admin-guide/bootconfig.rst
> @@ -169,6 +169,10 @@ Boot Kernel With a Boot Config
> There are two options to boot the kernel with bootconfig: attaching the
> bootconfig to the initrd image or embedding it in the kernel itself.
>
> +Early options (those registered with ``early_param()``) may only be
> +specified in the embedded bootconfig, because the initrd is not yet
> +available when early parameters are processed.
> +
> Attaching a Boot Config to Initrd
> ---------------------------------
>
> diff --git a/init/Kconfig b/init/Kconfig
> index 938fbe6a91e15..5e8057e73fe06 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1534,6 +1534,12 @@ config BOOT_CONFIG_EMBED
> image. But if the system doesn't support initrd, this option will
> help you by embedding a bootconfig file while building the kernel.
>
> + Unlike bootconfig attached to initrd, the embedded bootconfig also
> + supports early options (those registered with early_param()). Any
> + kernel.* key in the embedded bootconfig is applied before
> + parse_early_param() runs. Early options in initrd bootconfig will
> + not be applied.
> +
> If unsure, say N.
>
> config BOOT_CONFIG_EMBED_FILE
> diff --git a/init/main.c b/init/main.c
> index 453ac9dff2da0..eba42b2351d47 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -416,9 +416,63 @@ static int __init warn_bootconfig(char *str)
> return 0;
> }
>
> +/*
> + * do_early_param() is defined later in this file but called from
> + * bootconfig_apply_early_params() below, so we need a forward declaration.
> + */
> +static int __init do_early_param(char *param, char *val,
> + const char *unused, void *arg);
> +
> +/*
> + * bootconfig_apply_early_params - dispatch kernel.* keys from the embedded
> + * bootconfig as early_param() calls.
> + *
> + * early_param() handlers must run before most of the kernel initialises
> + * (e.g. before the GIC driver reads irqchip.gicv3_pseudo_nmi). A bootconfig
> + * attached to the initrd arrives too late for this because the initrd is not
> + * mapped yet when early params are processed. The embedded bootconfig lives
> + * in the kernel image itself (.init.data), so it is always reachable.
> + *
> + * This function is called from setup_boot_config() which runs in
> + * start_kernel() before parse_early_param(), making the timing correct.
> + */
> +static void __init bootconfig_apply_early_params(void)
> +{
> + char val_buf[COMMAND_LINE_SIZE];
> + struct xbc_node *knode, *root;
> + const char *val;
> +
> + root = xbc_find_node("kernel");
> + if (!root)
> + return;
> +
> + /*
> + * Keys that do not match any early_param() handler are silently
> + * ignored — do_early_param() always returns 0.
> + */
> + xbc_node_for_each_key_value(root, knode, val) {
> + if (xbc_node_compose_key_after(root, knode, xbc_namebuf, XBC_KEYLEN_MAX) < 0)
> + continue;
> +
> + if (!val) {
> + do_early_param(xbc_namebuf, NULL, NULL, NULL);
> + continue;
> + }
> +
> + /*
> + * We need to copy const char *val to a char pointer,
> + * which is what do_early_param() need, given it might
> + * call strsep(), strtok() later.
> + */
> + strscpy(val_buf, val, sizeof(val_buf));
> + do_early_param(xbc_namebuf, val_buf, NULL, NULL);
> + }
> +}
> +
> static void __init setup_boot_config(void)
> {
> static char tmp_cmdline[COMMAND_LINE_SIZE] __initdata;
> + bool using_embedded = false;
> const char *msg, *data;
> int pos, ret;
> size_t size;
> @@ -427,8 +481,17 @@ static void __init setup_boot_config(void)
> /* Cut out the bootconfig data even if we have no bootconfig option */
> data = get_boot_config_from_initrd(&size);
> /* If there is no bootconfig in initrd, try embedded one. */
> - if (!data)
> + if (!data) {
> data = xbc_get_embedded_bootconfig(&size);
> + /*
> + * Record that we are using the embedded config so that
> + * bootconfig_apply_early_params() is called below.
> + * When CONFIG_BOOT_CONFIG_EMBED is not set,
> + * xbc_get_embedded_bootconfig() is a stub returning NULL, so
> + * data is always NULL here and using_embedded stays false.
> + */
> + using_embedded = data;
> + }
>
> strscpy(tmp_cmdline, boot_command_line, COMMAND_LINE_SIZE);
> err = parse_args("bootconfig", tmp_cmdline, NULL, 0, 0, 0, NULL,
> @@ -466,6 +529,8 @@ static void __init setup_boot_config(void)
> } else {
> xbc_get_info(&ret, NULL);
> pr_info("Load bootconfig: %ld bytes %d nodes\n", (long)size, ret);
> + if (using_embedded)
> + bootconfig_apply_early_params();
> /* keys starting with "kernel." are passed via cmdline */
> extra_command_line = xbc_make_cmdline("kernel");
> /* Also, "init." keys are init arguments */
>
> ---
> base-commit: 785f0eb2f85decbe7c1ef9ae922931f0194ffc2e
> change-id: 20260323-early_bootconfig-2efc4509af3d
>
> Best regards,
> --
> Breno Leitao <leitao@debian.org>
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH RFC 0/2] kernel-doc: better handle data prototypes
From: Mauro Carvalho Chehab @ 2026-03-24 15:33 UTC (permalink / raw)
To: Linux Doc Mailing List, Jonathan Corbet
Cc: Mauro Carvalho Chehab, linux-kernel
In-Reply-To: <cover.1773998596.git.mchehab+huawei@kernel.org>
On Fri, 20 Mar 2026 10:46:39 +0100
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> Hi Jon,
>
> Don't merge this series. It is just a heads on about what I'm
> working right now.
>
> This is basically a proof of concept, not yet integrated with
> kernel-doc. It helps to show that investing on a tokenizer
> was a good idea.
>
> I'm still testing the code.
Heh, getting it working is hard, but I ended with something that
should work with a somewhat complex scenario.
The new version is at my scratch repository at:
https://github.com/mchehab/linux PR_CDataParser-v2
I'm expecting that this parser should be able to handle:
- typedef (for data types);
- struct
- union
- enum
- var
So, after properly integrated(*), it should simplify a lot the
code inside kdoc_parser.
(*) right now, it is minimally integrated, handling just
struct/unions.
My current plan is to test it more with real-case scenarios,
aiming to submit it after 7.1-rc1, as it sounds to be that a
change like that is too late to be submitted like that.
IMO the newer code should be more reliable than the current
approach and should produce a better output once done.
--
Thanks,
Mauro
For this input:
<snip>
/**
* struct property_entry - property entry
*
* @name: name description
* @length: length description
* @is_inline: is_inline description
* @bar: bar description
* @my_enum: my_enum description
* @test: test description
* @anonymous: anon description
* @type: type description
* @literal: literal description
* @pointer: pointer description
* @value: value description
* @boou8_data: boou8_data description
* @u16_data: u16_data description
* @u32_data: u32_data description
* @u64_data: u64_data description
* @str: str description
* @prop_name: prop name description
*/
struct property_entry {
const char *name;
size_t length;
bool is_inline; /* TEST */
struct foo {
char *bar[12];
struct {
enum enum_type my_enum; /* TEST 2 */
struct {
uint_t test; /* TEST 3 */
static const int anonymous;
};
} foobar ;
;;
{};
};
enum dev_prop_type type;
enum {
EXPRESSION_LITERAL,
EXPRESSION_BINARY,
EXPRESSION_UNARY,
EXPRESSION_FUNCTION,
EXPRESSION_ARRAY
} literal;
union {
const void *pointer;
union {
u8 boou8_data[sizeof(u64) / sizeof(u8)];
u16 u16_data[sizeof(u64) / sizeof(u16)];
u32 u32_data[sizeof(u64) / sizeof(u32)];
u64 u64_data[sizeof(u64) / sizeof(u64)];
const char *str[sizeof(u64) / sizeof(char *)];
};
};
char *prop_name;
};
</snip>
Kernel-doc produces a proper result:
<snip>
Ignoring foobar
.. c:struct:: property_entry
property entry
.. container:: kernelindent
**Definition**::
struct property_entry {
const char *name;
size_t length;
bool is_inline;
struct foo {
char *bar[12];
struct {
enum enum_type my_enum;
struct {
uint_t test;
static const int anonymous;
};
} foobar;
{
};
};
enum dev_prop_type type;
enum {
EXPRESSION_LITERAL,
EXPRESSION_BINARY,
EXPRESSION_UNARY,
EXPRESSION_FUNCTION,
EXPRESSION_ARRAY } literal;
union {
const void *pointer;
union {
u8 boou8_data[sizeof(u64) / sizeof(u8)];
u16 u16_data[sizeof(u64) / sizeof(u16)];
u32 u32_data[sizeof(u64) / sizeof(u32)];
u64 u64_data[sizeof(u64) / sizeof(u64)];
const char *str[sizeof(u64) / sizeof(char *)];
};
};
char *prop_name;
}
};
**Members**
``{unnamed_struct}``
anonymous
``name``
name description
``length``
length description
``is_inline``
is_inline description
``bar``
bar description
``my_enum``
my_enum description
``{unnamed_struct}``
anonymous
``test``
test description
``anonymous``
anon description
``type``
type description
``literal``
literal description
``{unnamed_union}``
anonymous
``pointer``
pointer description
``boou8_data``
boou8_data description
``u16_data``
u16_data description
``u32_data``
u32_data description
``u64_data``
u64_data description
``str``
str description
``prop_name``
prop name description
</snip>
^ permalink raw reply
* Re: [PATCH v4 08/21] mm: add vm_ops->mapped hook
From: Vlastimil Babka (SUSE) @ 2026-03-24 15:32 UTC (permalink / raw)
To: Lorenzo Stoakes (Oracle), Andrew Morton
Cc: Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Bodo Stroesser, Martin K . Petersen,
David Howells, Marc Dionne, Alexander Viro, Christian Brauner,
Jan Kara, David Hildenbrand, Liam R . Howlett, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Jann Horn, Pedro Falcato,
linux-kernel, linux-doc, linux-hyperv, linux-stm32,
linux-arm-kernel, linux-mtd, linux-staging, linux-scsi,
target-devel, linux-afs, linux-fsdevel, linux-mm, Ryan Roberts
In-Reply-To: <4c5e98297eb0aae9565c564e1c296a112702f144.1774045440.git.ljs@kernel.org>
On 3/20/26 23:39, Lorenzo Stoakes (Oracle) wrote:
> Previously, when a driver needed to do something like establish a
> reference count, it could do so in the mmap hook in the knowledge that the
> mapping would succeed.
>
> With the introduction of f_op->mmap_prepare this is no longer the case, as
> it is invoked prior to actually establishing the mapping.
>
> mmap_prepare is not appropriate for this kind of thing as it is called
> before any merge might take place, and after which an error might occur
> meaning resources could be leaked.
>
> To take this into account, introduce a new vm_ops->mapped callback which
> is invoked when the VMA is first mapped (though notably - not when it is
> merged - which is correct and mirrors existing mmap/open/close behaviour).
>
> We do better that vm_ops->open() here, as this callback can return an
> error, at which point the VMA will be unmapped.
>
> Note that vm_ops->mapped() is invoked after any mmap action is complete
> (such as I/O remapping).
>
> We intentionally do not expose the VMA at this point, exposing only the
> fields that could be used, and an output parameter in case the operation
> needs to update the vma->vm_private_data field.
>
> In order to deal with stacked filesystems which invoke inner filesystem's
> mmap() invocations, add __compat_vma_mapped() and invoke it on vfs_mmap()
> (via compat_vma_mmap()) to ensure that the mapped callback is handled when
> an mmap() caller invokes a nested filesystem's mmap_prepare() callback.
>
> Update the mmap_prepare documentation to describe the mapped hook and make
> it clear what its intended use is.
>
> The vm_ops->mapped() call is handled by the mmap complete logic to ensure
> the same code paths are handled by both the compatibility and VMA layers.
>
> Additionally, update VMA userland test headers to reflect the change.
>
> Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ permalink raw reply
* Re: [PATCH v4] landlock: Expand restrict flags example for ABI version 8
From: Günther Noack @ 2026-03-24 15:30 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Panagiotis "Ivory" Vasilopoulos, Jonathan Corbet,
Shuah Khan, linux-security-module, linux-doc, linux-kernel,
Dan Cojocaru
In-Reply-To: <20260324.aqu5Eic7Thee@digikod.net>
On Tue, Mar 24, 2026 at 04:06:01PM +0100, Mickaël Salaün wrote:
> On Tue, Mar 24, 2026 at 10:48:29AM +0100, Günther Noack wrote:
> > Apologies for the delay, this must have slipped through the cracks.
> > Thanks for bringing it up again. Yes, this looks good.
> >
> > Signed-off-by: Günther Noack <gnoack@google.com>
>
> Shouldn't it be a Reviewed-by?
Absolutely, thanks! I meant to send a Reviewed-by.
Please ignore the previous message.
Reviewed-by: Günther Noack <gnoack@google.com>
—Günther
^ permalink raw reply
* Re: [PATCH V9 7/8] dax: Add fs_dax_get() func to prepare dax for fs-dax usage
From: Dave Jiang @ 2026-03-24 15:25 UTC (permalink / raw)
To: John Groves, John Groves, Miklos Szeredi, Dan Williams,
Bernd Schubert, Alison Schofield
Cc: John Groves, Jonathan Corbet, Shuah Khan, Vishal Verma,
Matthew Wilcox, Jan Kara, Alexander Viro, David Hildenbrand,
Christian Brauner, Darrick J . Wong, Randy Dunlap, Jeff Layton,
Amir Goldstein, Jonathan Cameron, Stefan Hajnoczi, Joanne Koong,
Josef Bacik, Bagas Sanjaya, Chen Linxuan, James Morse, Fuad Tabba,
Sean Christopherson, Shivank Garg, Ackerley Tng, Gregory Price,
Aravind Ramesh, Ajay Joshi, venkataravis@micron.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
nvdimm@lists.linux.dev, linux-cxl@vger.kernel.org,
linux-fsdevel@vger.kernel.org
In-Reply-To: <0100019d1d484ddc-2487f887-7ecd-49a3-abfe-9dabec28873f-000000@email.amazonses.com>
On 3/23/26 5:39 PM, John Groves wrote:
> From: John Groves <john@groves.net>
>
> The fs_dax_get() function should be called by fs-dax file systems after
> opening a fsdev dax device. This adds holder_operations, which provides
> a memory failure callback path and effects exclusivity between callers
> of fs_dax_get().
>
> fs_dax_get() is specific to fsdev_dax, so it checks the driver type
> (which required touching bus.[ch]). fs_dax_get() fails if fsdev_dax is
> not bound to the memory.
>
> This function serves the same role as fs_dax_get_by_bdev(), which dax
> file systems call after opening the pmem block device.
>
> This can't be located in fsdev.c because struct dax_device is opaque
> there.
>
> This will be called by fs/fuse/famfs.c in a subsequent commit.
>
> Signed-off-by: John Groves <john@groves.net>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
> ---
> drivers/dax/bus.c | 2 --
> drivers/dax/bus.h | 2 ++
> drivers/dax/super.c | 66 ++++++++++++++++++++++++++++++++++++++++++++-
> include/linux/dax.h | 17 +++++++++---
> 4 files changed, 80 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
> index 562e2b06f61a..8a8710a8234e 100644
> --- a/drivers/dax/bus.c
> +++ b/drivers/dax/bus.c
> @@ -39,8 +39,6 @@ static int dax_bus_uevent(const struct device *dev, struct kobj_uevent_env *env)
> return add_uevent_var(env, "MODALIAS=" DAX_DEVICE_MODALIAS_FMT, 0);
> }
>
> -#define to_dax_drv(__drv) container_of_const(__drv, struct dax_device_driver, drv)
> -
> static struct dax_id *__dax_match_id(const struct dax_device_driver *dax_drv,
> const char *dev_name)
> {
> diff --git a/drivers/dax/bus.h b/drivers/dax/bus.h
> index 880bdf7e72d7..dc6f112ac4a4 100644
> --- a/drivers/dax/bus.h
> +++ b/drivers/dax/bus.h
> @@ -42,6 +42,8 @@ struct dax_device_driver {
> void (*remove)(struct dev_dax *dev);
> };
>
> +#define to_dax_drv(__drv) container_of_const(__drv, struct dax_device_driver, drv)
> +
> int __dax_driver_register(struct dax_device_driver *dax_drv,
> struct module *module, const char *mod_name);
> #define dax_driver_register(driver) \
> diff --git a/drivers/dax/super.c b/drivers/dax/super.c
> index ba0b4cd18a77..d4ab60c406bf 100644
> --- a/drivers/dax/super.c
> +++ b/drivers/dax/super.c
> @@ -14,6 +14,7 @@
> #include <linux/fs.h>
> #include <linux/cacheinfo.h>
> #include "dax-private.h"
> +#include "bus.h"
>
> /**
> * struct dax_device - anchor object for dax services
> @@ -111,6 +112,10 @@ struct dax_device *fs_dax_get_by_bdev(struct block_device *bdev, u64 *start_off,
> }
> EXPORT_SYMBOL_GPL(fs_dax_get_by_bdev);
>
> +#endif /* CONFIG_BLOCK && CONFIG_FS_DAX */
> +
> +#if IS_ENABLED(CONFIG_FS_DAX)
> +
> void fs_put_dax(struct dax_device *dax_dev, void *holder)
> {
> if (dax_dev && holder &&
> @@ -119,7 +124,66 @@ void fs_put_dax(struct dax_device *dax_dev, void *holder)
> put_dax(dax_dev);
> }
> EXPORT_SYMBOL_GPL(fs_put_dax);
> -#endif /* CONFIG_BLOCK && CONFIG_FS_DAX */
> +
> +/**
> + * fs_dax_get() - get ownership of a devdax via holder/holder_ops
> + *
> + * fs-dax file systems call this function to prepare to use a devdax device for
> + * fsdax. This is like fs_dax_get_by_bdev(), but the caller already has struct
> + * dev_dax (and there is no bdev). The holder makes this exclusive.
> + *
> + * @dax_dev: dev to be prepared for fs-dax usage
> + * @holder: filesystem or mapped device inside the dax_device
> + * @hops: operations for the inner holder
> + *
> + * Returns: 0 on success, <0 on failure
> + */
> +int fs_dax_get(struct dax_device *dax_dev, void *holder,
> + const struct dax_holder_operations *hops)
> +{
> + struct dev_dax *dev_dax;
> + struct dax_device_driver *dax_drv;
> + int id;
> +
> + id = dax_read_lock();
> + if (!dax_dev || !dax_alive(dax_dev) || !igrab(&dax_dev->inode)) {
> + dax_read_unlock(id);
> + return -ENODEV;
> + }
> + dax_read_unlock(id);
> +
> + /* Verify the device is bound to fsdev_dax driver */
> + dev_dax = dax_get_private(dax_dev);
> + if (!dev_dax) {
> + iput(&dax_dev->inode);
> + return -ENODEV;
> + }
> +
> + device_lock(&dev_dax->dev);
> + if (!dev_dax->dev.driver) {
> + device_unlock(&dev_dax->dev);
> + iput(&dax_dev->inode);
> + return -ENODEV;
> + }
> + dax_drv = to_dax_drv(dev_dax->dev.driver);
> + if (dax_drv->type != DAXDRV_FSDEV_TYPE) {
> + device_unlock(&dev_dax->dev);
> + iput(&dax_dev->inode);
> + return -EOPNOTSUPP;
> + }
> + device_unlock(&dev_dax->dev);
> +
> + if (cmpxchg(&dax_dev->holder_data, NULL, holder)) {
> + iput(&dax_dev->inode);
> + return -EBUSY;
> + }
> +
> + dax_dev->holder_ops = hops;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(fs_dax_get);
> +#endif /* CONFIG_FS_DAX */
>
> enum dax_device_flags {
> /* !alive + rcu grace period == no new operations / mappings */
> diff --git a/include/linux/dax.h b/include/linux/dax.h
> index b19bfe0c2fd1..bf37b9a982f3 100644
> --- a/include/linux/dax.h
> +++ b/include/linux/dax.h
> @@ -130,7 +130,6 @@ int dax_add_host(struct dax_device *dax_dev, struct gendisk *disk);
> void dax_remove_host(struct gendisk *disk);
> struct dax_device *fs_dax_get_by_bdev(struct block_device *bdev, u64 *start_off,
> void *holder, const struct dax_holder_operations *ops);
> -void fs_put_dax(struct dax_device *dax_dev, void *holder);
> #else
> static inline int dax_add_host(struct dax_device *dax_dev, struct gendisk *disk)
> {
> @@ -145,12 +144,13 @@ static inline struct dax_device *fs_dax_get_by_bdev(struct block_device *bdev,
> {
> return NULL;
> }
> -static inline void fs_put_dax(struct dax_device *dax_dev, void *holder)
> -{
> -}
> #endif /* CONFIG_BLOCK && CONFIG_FS_DAX */
>
> #if IS_ENABLED(CONFIG_FS_DAX)
> +void fs_put_dax(struct dax_device *dax_dev, void *holder);
> +int fs_dax_get(struct dax_device *dax_dev, void *holder,
> + const struct dax_holder_operations *hops);
> +struct dax_device *inode_dax(struct inode *inode);
> int dax_writeback_mapping_range(struct address_space *mapping,
> struct dax_device *dax_dev, struct writeback_control *wbc);
> int dax_folio_reset_order(struct folio *folio);
> @@ -164,6 +164,15 @@ dax_entry_t dax_lock_mapping_entry(struct address_space *mapping,
> void dax_unlock_mapping_entry(struct address_space *mapping,
> unsigned long index, dax_entry_t cookie);
> #else
> +static inline void fs_put_dax(struct dax_device *dax_dev, void *holder)
> +{
> +}
> +
> +static inline int fs_dax_get(struct dax_device *dax_dev, void *holder,
> + const struct dax_holder_operations *hops)
> +{
> + return -EOPNOTSUPP;
> +}
> static inline struct page *dax_layout_busy_page(struct address_space *mapping)
> {
> return NULL;
^ permalink raw reply
* Re: [PATCH V9 5/8] dax: Add dax_operations for use by fs-dax on fsdev dax
From: Dave Jiang @ 2026-03-24 15:23 UTC (permalink / raw)
To: John Groves, John Groves, Miklos Szeredi, Dan Williams,
Bernd Schubert, Alison Schofield
Cc: John Groves, Jonathan Corbet, Shuah Khan, Vishal Verma,
Matthew Wilcox, Jan Kara, Alexander Viro, David Hildenbrand,
Christian Brauner, Darrick J . Wong, Randy Dunlap, Jeff Layton,
Amir Goldstein, Jonathan Cameron, Stefan Hajnoczi, Joanne Koong,
Josef Bacik, Bagas Sanjaya, Chen Linxuan, James Morse, Fuad Tabba,
Sean Christopherson, Shivank Garg, Ackerley Tng, Gregory Price,
Aravind Ramesh, Ajay Joshi, venkataravis@micron.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
nvdimm@lists.linux.dev, linux-cxl@vger.kernel.org,
linux-fsdevel@vger.kernel.org
In-Reply-To: <0100019d1d47e459-48f2a4e6-edab-4002-bde3-2ba642deccaf-000000@email.amazonses.com>
On 3/23/26 5:39 PM, John Groves wrote:
> From: John Groves <John@Groves.net>
>
> fsdev: Add dax_operations for use by famfs.
>
> This replicates the functionality from drivers/nvdimm/pmem.c that
> conventional fs-dax file systems (e.g. xfs) use to support dax
> read/write/mmap to a daxdev - without which famfs can't sit atop a
> daxdev.
>
> - These methods are based on pmem_dax_ops from drivers/nvdimm/pmem.c
> - fsdev_dax_direct_access() returns the hpa, pfn and kva. The kva was
> newly stored as dev_dax->virt_addr by dev_dax_probe().
> - The hpa/pfn are used for mmap (dax_iomap_fault()), and the kva is used
> for read/write (dax_iomap_rw())
> - fsdev_dax_recovery_write() and dev_dax_zero_page_range() have not been
> tested yet. I'm looking for suggestions as to how to test those.
> - dax-private.h: add dev_dax->cached_size, which fsdev needs to
> remember. The dev_dax size cannot change while a driver is bound
> (dev_dax_resize returns -EBUSY if dev->driver is set). Caching the size
> at probe time allows fsdev's direct_access path can use it without
> acquiring dax_dev_rwsem (which isn't exported anyway).
>
> Signed-off-by: John Groves <john@groves.net>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
> ---
> drivers/dax/dax-private.h | 1 +
> drivers/dax/fsdev.c | 84 +++++++++++++++++++++++++++++++++++++++
> 2 files changed, 85 insertions(+)
>
> diff --git a/drivers/dax/dax-private.h b/drivers/dax/dax-private.h
> index 7a3727d76a68..ee8f3af8387f 100644
> --- a/drivers/dax/dax-private.h
> +++ b/drivers/dax/dax-private.h
> @@ -85,6 +85,7 @@ struct dev_dax {
> struct dax_region *region;
> struct dax_device *dax_dev;
> void *virt_addr;
> + u64 cached_size;
> unsigned int align;
> int target_node;
> bool dyn_id;
> diff --git a/drivers/dax/fsdev.c b/drivers/dax/fsdev.c
> index c75478d3d548..be3d2b0e8418 100644
> --- a/drivers/dax/fsdev.c
> +++ b/drivers/dax/fsdev.c
> @@ -28,6 +28,85 @@
> * - No mmap support - all access is through fs-dax/iomap
> */
>
> +static void fsdev_write_dax(void *pmem_addr, struct page *page,
> + unsigned int off, unsigned int len)
> +{
> + while (len) {
> + void *mem = kmap_local_page(page);
> + unsigned int chunk = min_t(unsigned int, len, PAGE_SIZE - off);
> +
> + memcpy_flushcache(pmem_addr, mem + off, chunk);
> + kunmap_local(mem);
> + len -= chunk;
> + off = 0;
> + page++;
> + pmem_addr += chunk;
> + }
> +}
> +
> +static long __fsdev_dax_direct_access(struct dax_device *dax_dev, pgoff_t pgoff,
> + long nr_pages, enum dax_access_mode mode, void **kaddr,
> + unsigned long *pfn)
> +{
> + struct dev_dax *dev_dax = dax_get_private(dax_dev);
> + size_t size = nr_pages << PAGE_SHIFT;
> + size_t offset = pgoff << PAGE_SHIFT;
> + void *virt_addr = dev_dax->virt_addr + offset;
> + phys_addr_t phys;
> + unsigned long local_pfn;
> +
> + phys = dax_pgoff_to_phys(dev_dax, pgoff, nr_pages << PAGE_SHIFT);
> + if (phys == -1) {
> + dev_dbg(&dev_dax->dev,
> + "pgoff (%#lx) out of range\n", pgoff);
> + return -EFAULT;
> + }
> +
> + if (kaddr)
> + *kaddr = virt_addr;
> +
> + local_pfn = PHYS_PFN(phys);
> + if (pfn)
> + *pfn = local_pfn;
> +
> + /*
> + * Use cached_size which was computed at probe time. The size cannot
> + * change while the driver is bound (resize returns -EBUSY).
> + */
> + return PHYS_PFN(min(size, dev_dax->cached_size - offset));
> +}
> +
> +static int fsdev_dax_zero_page_range(struct dax_device *dax_dev,
> + pgoff_t pgoff, size_t nr_pages)
> +{
> + void *kaddr;
> +
> + WARN_ONCE(nr_pages > 1, "%s: nr_pages > 1\n", __func__);
> + __fsdev_dax_direct_access(dax_dev, pgoff, 1, DAX_ACCESS, &kaddr, NULL);
> + fsdev_write_dax(kaddr, ZERO_PAGE(0), 0, PAGE_SIZE);
> + return 0;
> +}
> +
> +static long fsdev_dax_direct_access(struct dax_device *dax_dev,
> + pgoff_t pgoff, long nr_pages, enum dax_access_mode mode,
> + void **kaddr, unsigned long *pfn)
> +{
> + return __fsdev_dax_direct_access(dax_dev, pgoff, nr_pages, mode,
> + kaddr, pfn);
> +}
> +
> +static size_t fsdev_dax_recovery_write(struct dax_device *dax_dev, pgoff_t pgoff,
> + void *addr, size_t bytes, struct iov_iter *i)
> +{
> + return _copy_from_iter_flushcache(addr, bytes, i);
> +}
> +
> +static const struct dax_operations dev_dax_ops = {
> + .direct_access = fsdev_dax_direct_access,
> + .zero_page_range = fsdev_dax_zero_page_range,
> + .recovery_write = fsdev_dax_recovery_write,
> +};
> +
> static void fsdev_cdev_del(void *cdev)
> {
> cdev_del(cdev);
> @@ -167,6 +246,11 @@ static int fsdev_dax_probe(struct dev_dax *dev_dax)
> }
> }
>
> + /* Cache size now; it cannot change while driver is bound */
> + dev_dax->cached_size = 0;
> + for (i = 0; i < dev_dax->nr_range; i++)
> + dev_dax->cached_size += range_len(&dev_dax->ranges[i].range);
> +
> /*
> * Use MEMORY_DEVICE_FS_DAX without setting vmemmap_shift, leaving
> * folios at order-0. Unlike device.c (MEMORY_DEVICE_GENERIC), this
^ permalink raw reply
* Re: [PATCH] Documentation/rtla: Document SIGINT behavior
From: Steven Rostedt @ 2026-03-24 15:22 UTC (permalink / raw)
To: Tomas Glozar
Cc: Jonathan Corbet, Shuah Khan, John Kacur, Luis Goncalves,
Crystal Wood, Costa Shulyupin, Wander Lairson Costa, LKML,
linux-trace-kernel, linux-doc, Attila Fazekas
In-Reply-To: <20260324123229.152424-1-tglozar@redhat.com>
On Tue, 24 Mar 2026 13:32:29 +0100
Tomas Glozar <tglozar@redhat.com> wrote:
> The behavior of RTLA on receiving SIGINT is currently undocumented.
>
> Describe it in RTLA's common appendix that appears in man pages for all
> RTLA tools to avoid confusion.
>
> Suggested-by: Attila Fazekas <afazekas@redhat.com>
> Signed-off-by: Tomas Glozar <tglozar@redhat.com>
> ---
>
> Note: There was a bug in SIGINT behavior, fixed in upcoming commit [1].
>
> [1] https://lore.kernel.org/linux-trace-kernel/20260310160725.144443-1-tglozar@redhat.com/
Hmm, this may be interesting enough to add to the change log itself.
>
> Documentation/tools/rtla/common_appendix.txt | 21 ++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/Documentation/tools/rtla/common_appendix.txt b/Documentation/tools/rtla/common_appendix.txt
> index 53cae7537537..8c90a02588e7 100644
> --- a/Documentation/tools/rtla/common_appendix.txt
> +++ b/Documentation/tools/rtla/common_appendix.txt
> @@ -1,5 +1,26 @@
> .. SPDX-License-Identifier: GPL-2.0
>
> +SIGINT BEHAVIOR
> +===============
> +
> +On the first SIGINT, RTLA exits after collecting all outstanding samples up to
> +the point of receiving the signal.
> +
> +When receiving more than one SIGINT, RTLA discards any outstanding samples, and
> +exits while displaying only samples that have already been processed.
> +
> +If SIGINT is received during RTLA cleanup, RTLA exits immediately via
> +the default signal handler.
> +
> +Note: For the purpose of SIGINT behavior, the expiry of duration specified via
> +the -d/--duration option is treated as equivalent to receiving a SIGINT. For
> +example, a SIGINT received after duration expired but samples have not been
> +processed yet will drop any outstanding samples.
> +
> +Also note that when using the timerlat tool in BPF mode, samples are processed
> +in-kernel; RTLA only copies them out to display them to the user. A second
> +SIGINT does not affect in-kernel sample aggregation.
But does it affect the user space side of reading that information?
> +
> EXIT STATUS
> ===========
>
Other than that ... LGTM,
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
-- Steve
^ permalink raw reply
* Re: [PATCH V9 3/8] dax: add fsdev.c driver for fs-dax on character dax
From: Dave Jiang @ 2026-03-24 15:19 UTC (permalink / raw)
To: John Groves, John Groves, Miklos Szeredi, Dan Williams,
Bernd Schubert, Alison Schofield
Cc: John Groves, Jonathan Corbet, Shuah Khan, Vishal Verma,
Matthew Wilcox, Jan Kara, Alexander Viro, David Hildenbrand,
Christian Brauner, Darrick J . Wong, Randy Dunlap, Jeff Layton,
Amir Goldstein, Jonathan Cameron, Stefan Hajnoczi, Joanne Koong,
Josef Bacik, Bagas Sanjaya, Chen Linxuan, James Morse, Fuad Tabba,
Sean Christopherson, Shivank Garg, Ackerley Tng, Gregory Price,
Aravind Ramesh, Ajay Joshi, venkataravis@micron.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
nvdimm@lists.linux.dev, linux-cxl@vger.kernel.org,
linux-fsdevel@vger.kernel.org
In-Reply-To: <0100019d1d476420-6b0bf60e-3b3a-4868-8f5f-484cd55d4709-000000@email.amazonses.com>
On 3/23/26 5:38 PM, John Groves wrote:
> From: John Groves <john@groves.net>
>
> The new fsdev driver provides pages/folios initialized compatibly with
> fsdax - normal rather than devdax-style refcounting, and starting out
> with order-0 folios.
>
> When fsdev binds to a daxdev, it is usually (always?) switching from the
> devdax mode (device.c), which pre-initializes compound folios according
> to its alignment. Fsdev uses fsdev_clear_folio_state() to switch the
> folios into a fsdax-compatible state.
>
> A side effect of this is that raw mmap doesn't (can't?) work on an fsdev
> dax instance. Accordingly, The fsdev driver does not provide raw mmap -
> devices must be put in 'devdax' mode (drivers/dax/device.c) to get raw
> mmap capability.
>
> In this commit is just the framework, which remaps pages/folios compatibly
> with fsdax.
>
> Enabling dax changes:
>
> - bus.h: add DAXDRV_FSDEV_TYPE driver type
> - bus.c: allow DAXDRV_FSDEV_TYPE drivers to bind to daxdevs
> - dax.h: prototype inode_dax(), which fsdev needs
>
> Suggested-by: Dan Williams <dan.j.williams@intel.com>
> Suggested-by: Gregory Price <gourry@gourry.net>
> Signed-off-by: John Groves <john@groves.net>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
> ---
> MAINTAINERS | 8 ++
> drivers/dax/Kconfig | 11 ++
> drivers/dax/Makefile | 2 +
> drivers/dax/bus.c | 4 +
> drivers/dax/bus.h | 1 +
> drivers/dax/fsdev.c | 245 +++++++++++++++++++++++++++++++++++++++++++
> fs/dax.c | 1 +
> 7 files changed, 272 insertions(+)
> create mode 100644 drivers/dax/fsdev.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7d10988cbc62..eedf4cce56ed 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7298,6 +7298,14 @@ L: linux-cxl@vger.kernel.org
> S: Supported
> F: drivers/dax/
>
> +DEVICE DIRECT ACCESS (DAX) [fsdev_dax]
> +M: John Groves <jgroves@micron.com>
> +M: John Groves <John@Groves.net>
> +L: nvdimm@lists.linux.dev
> +L: linux-cxl@vger.kernel.org
> +S: Supported
> +F: drivers/dax/fsdev.c
> +
> DEVICE FREQUENCY (DEVFREQ)
> M: MyungJoo Ham <myungjoo.ham@samsung.com>
> M: Kyungmin Park <kyungmin.park@samsung.com>
> diff --git a/drivers/dax/Kconfig b/drivers/dax/Kconfig
> index d656e4c0eb84..7051b70980d5 100644
> --- a/drivers/dax/Kconfig
> +++ b/drivers/dax/Kconfig
> @@ -61,6 +61,17 @@ config DEV_DAX_HMEM_DEVICES
> depends on DEV_DAX_HMEM && DAX
> def_bool y
>
> +config DEV_DAX_FSDEV
> + tristate "FSDEV DAX: fs-dax compatible devdax driver"
> + depends on DEV_DAX && FS_DAX
> + help
> + Support fs-dax access to DAX devices via a character device
> + interface. Unlike device_dax (which pre-initializes compound folios
> + based on device alignment), this driver leaves folios at order-0 so
> + that fs-dax filesystems can manage folio order dynamically.
> +
> + Say M if unsure.
> +
> config DEV_DAX_KMEM
> tristate "KMEM DAX: map dax-devices as System-RAM"
> default DEV_DAX
> diff --git a/drivers/dax/Makefile b/drivers/dax/Makefile
> index 5ed5c39857c8..ba35bda7abef 100644
> --- a/drivers/dax/Makefile
> +++ b/drivers/dax/Makefile
> @@ -4,11 +4,13 @@ obj-$(CONFIG_DEV_DAX) += device_dax.o
> obj-$(CONFIG_DEV_DAX_KMEM) += kmem.o
> obj-$(CONFIG_DEV_DAX_PMEM) += dax_pmem.o
> obj-$(CONFIG_DEV_DAX_CXL) += dax_cxl.o
> +obj-$(CONFIG_DEV_DAX_FSDEV) += fsdev_dax.o
>
> dax-y := super.o
> dax-y += bus.o
> device_dax-y := device.o
> dax_pmem-y := pmem.o
> dax_cxl-y := cxl.o
> +fsdev_dax-y := fsdev.o
>
> obj-y += hmem/
> diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
> index e4bd5c9f006c..562e2b06f61a 100644
> --- a/drivers/dax/bus.c
> +++ b/drivers/dax/bus.c
> @@ -81,6 +81,10 @@ static int dax_match_type(const struct dax_device_driver *dax_drv, struct device
> !IS_ENABLED(CONFIG_DEV_DAX_KMEM))
> return 1;
>
> + /* fsdev driver can also bind to device-type dax devices */
> + if (dax_drv->type == DAXDRV_FSDEV_TYPE && type == DAXDRV_DEVICE_TYPE)
> + return 1;
> +
> return 0;
> }
>
> diff --git a/drivers/dax/bus.h b/drivers/dax/bus.h
> index cbbf64443098..880bdf7e72d7 100644
> --- a/drivers/dax/bus.h
> +++ b/drivers/dax/bus.h
> @@ -31,6 +31,7 @@ struct dev_dax *devm_create_dev_dax(struct dev_dax_data *data);
> enum dax_driver_type {
> DAXDRV_KMEM_TYPE,
> DAXDRV_DEVICE_TYPE,
> + DAXDRV_FSDEV_TYPE,
> };
>
> struct dax_device_driver {
> diff --git a/drivers/dax/fsdev.c b/drivers/dax/fsdev.c
> new file mode 100644
> index 000000000000..8b5c6976ad17
> --- /dev/null
> +++ b/drivers/dax/fsdev.c
> @@ -0,0 +1,245 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* Copyright(c) 2026 Micron Technology, Inc. */
> +#include <linux/memremap.h>
> +#include <linux/pagemap.h>
> +#include <linux/module.h>
> +#include <linux/device.h>
> +#include <linux/cdev.h>
> +#include <linux/slab.h>
> +#include <linux/dax.h>
> +#include <linux/uio.h>
> +#include <linux/fs.h>
> +#include <linux/mm.h>
> +#include "dax-private.h"
> +#include "bus.h"
> +
> +/*
> + * FS-DAX compatible devdax driver
> + *
> + * Unlike drivers/dax/device.c which pre-initializes compound folios based
> + * on device alignment (via vmemmap_shift), this driver leaves folios
> + * uninitialized similar to pmem. This allows fs-dax filesystems like famfs
> + * to work without needing special handling for pre-initialized folios.
> + *
> + * Key differences from device.c:
> + * - pgmap type is MEMORY_DEVICE_FS_DAX (not MEMORY_DEVICE_GENERIC)
> + * - vmemmap_shift is NOT set (folios remain order-0)
> + * - fs-dax can dynamically create compound folios as needed
> + * - No mmap support - all access is through fs-dax/iomap
> + */
> +
> +static void fsdev_cdev_del(void *cdev)
> +{
> + cdev_del(cdev);
> +}
> +
> +static void fsdev_kill(void *dev_dax)
> +{
> + kill_dev_dax(dev_dax);
> +}
> +
> +/*
> + * Page map operations for FS-DAX mode
> + * Similar to fsdax_pagemap_ops in drivers/nvdimm/pmem.c
> + *
> + * Note: folio_free callback is not needed for MEMORY_DEVICE_FS_DAX.
> + * The core mm code in free_zone_device_folio() handles the wake_up_var()
> + * directly for this memory type.
> + */
> +static int fsdev_pagemap_memory_failure(struct dev_pagemap *pgmap,
> + unsigned long pfn, unsigned long nr_pages, int mf_flags)
> +{
> + struct dev_dax *dev_dax = pgmap->owner;
> + u64 offset = PFN_PHYS(pfn) - dev_dax->ranges[0].range.start;
> + u64 len = nr_pages << PAGE_SHIFT;
> +
> + return dax_holder_notify_failure(dev_dax->dax_dev, offset,
> + len, mf_flags);
> +}
> +
> +static const struct dev_pagemap_ops fsdev_pagemap_ops = {
> + .memory_failure = fsdev_pagemap_memory_failure,
> +};
> +
> +/*
> + * Clear any stale folio state from pages in the given range.
> + * This is necessary because device_dax pre-initializes compound folios
> + * based on vmemmap_shift, and that state may persist after driver unbind.
> + * Since fsdev_dax uses MEMORY_DEVICE_FS_DAX without vmemmap_shift, fs-dax
> + * expects to find clean order-0 folios that it can build into compound
> + * folios on demand.
> + *
> + * At probe time, no filesystem should be mounted yet, so all mappings
> + * are stale and must be cleared along with compound state.
> + */
> +static void fsdev_clear_folio_state(struct dev_dax *dev_dax)
> +{
> + for (int i = 0; i < dev_dax->nr_range; i++) {
> + struct range *range = &dev_dax->ranges[i].range;
> + unsigned long pfn = PHYS_PFN(range->start);
> + unsigned long end_pfn = PHYS_PFN(range->end) + 1;
> +
> + while (pfn < end_pfn) {
> + struct folio *folio = pfn_folio(pfn);
> + int order = dax_folio_reset_order(folio);
> +
> + pfn += 1UL << order;
> + }
> + }
> +}
> +
> +static void fsdev_clear_folio_state_action(void *data)
> +{
> + fsdev_clear_folio_state(data);
> +}
> +
> +static int fsdev_open(struct inode *inode, struct file *filp)
> +{
> + struct dax_device *dax_dev = inode_dax(inode);
> + struct dev_dax *dev_dax = dax_get_private(dax_dev);
> +
> + filp->private_data = dev_dax;
> +
> + return 0;
> +}
> +
> +static int fsdev_release(struct inode *inode, struct file *filp)
> +{
> + return 0;
> +}
> +
> +static const struct file_operations fsdev_fops = {
> + .llseek = noop_llseek,
> + .owner = THIS_MODULE,
> + .open = fsdev_open,
> + .release = fsdev_release,
> +};
> +
> +static int fsdev_dax_probe(struct dev_dax *dev_dax)
> +{
> + struct dax_device *dax_dev = dev_dax->dax_dev;
> + struct device *dev = &dev_dax->dev;
> + struct dev_pagemap *pgmap;
> + struct inode *inode;
> + struct cdev *cdev;
> + void *addr;
> + int rc, i;
> +
> + if (static_dev_dax(dev_dax)) {
> + if (dev_dax->nr_range > 1) {
> + dev_warn(dev, "static pgmap / multi-range device conflict\n");
> + return -EINVAL;
> + }
> +
> + pgmap = dev_dax->pgmap;
> + } else {
> + size_t pgmap_size;
> +
> + if (dev_dax->pgmap) {
> + dev_warn(dev, "dynamic-dax with pre-populated page map\n");
> + return -EINVAL;
> + }
> +
> + pgmap_size = struct_size(pgmap, ranges, dev_dax->nr_range - 1);
> + pgmap = devm_kzalloc(dev, pgmap_size, GFP_KERNEL);
> + if (!pgmap)
> + return -ENOMEM;
> +
> + pgmap->nr_range = dev_dax->nr_range;
> + dev_dax->pgmap = pgmap;
> +
> + for (i = 0; i < dev_dax->nr_range; i++) {
> + struct range *range = &dev_dax->ranges[i].range;
> +
> + pgmap->ranges[i] = *range;
> + }
> + }
> +
> + for (i = 0; i < dev_dax->nr_range; i++) {
> + struct range *range = &dev_dax->ranges[i].range;
> +
> + if (!devm_request_mem_region(dev, range->start,
> + range_len(range), dev_name(dev))) {
> + dev_warn(dev, "mapping%d: %#llx-%#llx could not reserve range\n",
> + i, range->start, range->end);
> + return -EBUSY;
> + }
> + }
> +
> + /*
> + * Use MEMORY_DEVICE_FS_DAX without setting vmemmap_shift, leaving
> + * folios at order-0. Unlike device.c (MEMORY_DEVICE_GENERIC), this
> + * lets fs-dax dynamically build compound folios as needed, similar
> + * to pmem behavior.
> + */
> + pgmap->type = MEMORY_DEVICE_FS_DAX;
> + pgmap->ops = &fsdev_pagemap_ops;
> + pgmap->owner = dev_dax;
> +
> + addr = devm_memremap_pages(dev, pgmap);
> + if (IS_ERR(addr))
> + return PTR_ERR(addr);
> +
> + /*
> + * Clear any stale compound folio state left over from a previous
> + * driver (e.g., device_dax with vmemmap_shift). Also register this
> + * as a devm action so folio state is cleared on unbind, ensuring
> + * clean pages for subsequent drivers (e.g., kmem for system-ram).
> + */
> + fsdev_clear_folio_state(dev_dax);
> + rc = devm_add_action_or_reset(dev, fsdev_clear_folio_state_action,
> + dev_dax);
> + if (rc)
> + return rc;
> +
> + /* Detect whether the data is at a non-zero offset into the memory */
> + if (pgmap->range.start != dev_dax->ranges[0].range.start) {
> + u64 phys = dev_dax->ranges[0].range.start;
> + u64 pgmap_phys = dev_dax->pgmap[0].range.start;
> + u64 data_offset = 0;
> +
> + if (!WARN_ON(pgmap_phys > phys))
> + data_offset = phys - pgmap_phys;
> +
> + pr_debug("%s: offset detected phys=%llx pgmap_phys=%llx offset=%llx\n",
> + __func__, phys, pgmap_phys, data_offset);
> + }
> +
> + inode = dax_inode(dax_dev);
> + cdev = inode->i_cdev;
> + cdev_init(cdev, &fsdev_fops);
> + cdev->owner = dev->driver->owner;
> + cdev_set_parent(cdev, &dev->kobj);
> + rc = cdev_add(cdev, dev->devt, 1);
> + if (rc)
> + return rc;
> +
> + rc = devm_add_action_or_reset(dev, fsdev_cdev_del, cdev);
> + if (rc)
> + return rc;
> +
> + run_dax(dax_dev);
> + return devm_add_action_or_reset(dev, fsdev_kill, dev_dax);
> +}
> +
> +static struct dax_device_driver fsdev_dax_driver = {
> + .probe = fsdev_dax_probe,
> + .type = DAXDRV_FSDEV_TYPE,
> +};
> +
> +static int __init dax_init(void)
> +{
> + return dax_driver_register(&fsdev_dax_driver);
> +}
> +
> +static void __exit dax_exit(void)
> +{
> + dax_driver_unregister(&fsdev_dax_driver);
> +}
> +
> +MODULE_AUTHOR("John Groves");
> +MODULE_DESCRIPTION("FS-DAX Device: fs-dax compatible devdax driver");
> +MODULE_LICENSE("GPL");
> +module_init(dax_init);
> +module_exit(dax_exit);
> +MODULE_ALIAS_DAX_DEVICE(0);
> diff --git a/fs/dax.c b/fs/dax.c
> index eba86802a7a7..b91a2535149a 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -430,6 +430,7 @@ int dax_folio_reset_order(struct folio *folio)
>
> return order;
> }
> +EXPORT_SYMBOL_GPL(dax_folio_reset_order);
>
> static inline unsigned long dax_folio_put(struct folio *folio)
> {
^ permalink raw reply
* (no subject)
From: Víctor Pando @ 2026-03-24 15:18 UTC (permalink / raw)
To: corbet@lwn.net; +Cc: skhan@linuxfoundation.org, linux-doc, linux-kernel
From 1661cbef48706b600e613908e4e08ef3ec7214fa Mon Sep 17 00:00:00 2001
From: tovicito <tovictakamine@gmail.com>
Date: Tue, 24 Mar 2026 16:01:56 +0100
Subject: [PATCH] docs: driver-api: fix 6 spelling typos in
Documentation/driver-api
Signed-off-by: tovicito <tovictakamine@gmail.com>
---
Documentation/driver-api/acpi/acpi-drivers.rst | 2 +-
Documentation/driver-api/cxl/platform/acpi/cedt.rst | 2 +-
Documentation/driver-api/cxl/platform/bios-and-efi.rst | 2 +-
Documentation/driver-api/dmaengine/pxa_dma.rst | 2 +-
Documentation/driver-api/libata.rst | 2 +-
Documentation/driver-api/pci/p2pdma.rst | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/driver-api/acpi/acpi-drivers.rst
b/Documentation/driver-api/acpi/acpi-drivers.rst
index b1fbbddb8..376b6d8a6 100644
--- a/Documentation/driver-api/acpi/acpi-drivers.rst
+++ b/Documentation/driver-api/acpi/acpi-drivers.rst
@@ -47,7 +47,7 @@ generally be avoided and so struct acpi_driver
objects should not be used.
Moreover, a device ID is necessary to bind a driver directly to an ACPI device
node, but device IDs are not generally associated with all of them. Some of
them contain alternative information allowing the corresponding pieces of
-hardware to be identified, for example represeted by an _ADR object return
+hardware to be identified, for example represented by an _ADR object return
value, and device IDs are not used in those cases. In consequence, confusingly
enough, binding an ACPI driver to an ACPI device node may even be impossible.
diff --git a/Documentation/driver-api/cxl/platform/acpi/cedt.rst
b/Documentation/driver-api/cxl/platform/acpi/cedt.rst
index 1d9c9d359..217a75fb4 100644
--- a/Documentation/driver-api/cxl/platform/acpi/cedt.rst
+++ b/Documentation/driver-api/cxl/platform/acpi/cedt.rst
@@ -55,7 +55,7 @@ voltile vs persistent, etc). One or more bits may be set. ::
Bit[1]: CXL Type 3 Memory
Bit[2]: Volatile Memory
Bit[3]: Persistent Memory
- Bit[4]: Fixed Config (HPA cannot be re-used)
+ Bit[4]: Fixed Config (HPA cannot be reused)
INTRA-host-bridge interleave (multiple devices on one host bridge) is NOT
reported in this structure, and is solely defined via CXL device decoder
diff --git a/Documentation/driver-api/cxl/platform/bios-and-efi.rst
b/Documentation/driver-api/cxl/platform/bios-and-efi.rst
index a4b44c018..5d918b06f 100644
--- a/Documentation/driver-api/cxl/platform/bios-and-efi.rst
+++ b/Documentation/driver-api/cxl/platform/bios-and-efi.rst
@@ -277,7 +277,7 @@ The CFMWS field of the CEDT has special
restriction bits which describe whether
the described memory region allows volatile or persistent memory (or both). If
the platform intends to support either:
-1) A device with multiple medias, or
+1) A device with multiple media, or
2) Using a persistent memory device as normal memory
A platform may wish to create multiple CEDT CFMWS entries to describe the same
diff --git a/Documentation/driver-api/dmaengine/pxa_dma.rst
b/Documentation/driver-api/dmaengine/pxa_dma.rst
index 442ee691a..8f9da66b0 100644
--- a/Documentation/driver-api/dmaengine/pxa_dma.rst
+++ b/Documentation/driver-api/dmaengine/pxa_dma.rst
@@ -40,7 +40,7 @@ Design
======
a) Virtual channels
Same concept as in sa11x0 driver, ie. a driver was assigned a "virtual
-channel" linked to the requestor line, and the physical DMA channel is
+channel" linked to the requester line, and the physical DMA channel is
assigned on the fly when the transfer is issued.
b) Transfer anatomy for a scatter-gather transfer
diff --git a/Documentation/driver-api/libata.rst
b/Documentation/driver-api/libata.rst
index 93d97fe78..28b8437f6 100644
--- a/Documentation/driver-api/libata.rst
+++ b/Documentation/driver-api/libata.rst
@@ -286,7 +286,7 @@ and other exceptional conditions. The primary
responsibility of an
implementation is to call :c:func:`ata_std_error_handler`.
:c:func:`ata_std_error_handler` will perform a standard error handling sequence
-to resurect failed devices, detach lost devices and add new devices (if any).
+to resurrect failed devices, detach lost devices and add new devices (if any).
This function will call the various reset operations for a port, as needed.
These operations are as follows.
diff --git a/Documentation/driver-api/pci/p2pdma.rst
b/Documentation/driver-api/pci/p2pdma.rst
index 280673b50..d3f406cca 100644
--- a/Documentation/driver-api/pci/p2pdma.rst
+++ b/Documentation/driver-api/pci/p2pdma.rst
@@ -38,7 +38,7 @@ for all usage refcounts to reach zero.
At the lowest level the P2P subsystem offers a naked struct p2p_provider that
delegates lifecycle management to the providing driver. It is expected that
drivers using this option will wrap their MMIO memory in DMABUF and use DMABUF
-to provide an invalidation shutdown. These MMIO addresess have no
struct page, and
+to provide an invalidation shutdown. These MMIO addresses have no
struct page, and
if used with mmap() must create special PTEs. As such there are very few
kernel uAPIs that can accept pointers to them; in particular they
cannot be used
with read()/write(), including O_DIRECT.
--
2.53.0
^ permalink raw reply related
* Re: [PATCH V9 01/10] famfs_fuse: Update macro s/FUSE_IS_DAX/FUSE_IS_VIRTIO_DAX/
From: Jonathan Cameron @ 2026-03-24 15:12 UTC (permalink / raw)
To: John Groves
Cc: John Groves, Miklos Szeredi, Dan Williams, Bernd Schubert,
Alison Schofield, John Groves, Jonathan Corbet, Shuah Khan,
Vishal Verma, Dave Jiang, Matthew Wilcox, Jan Kara,
Alexander Viro, David Hildenbrand, Christian Brauner,
Darrick J . Wong, Randy Dunlap, Jeff Layton, Amir Goldstein,
Stefan Hajnoczi, Joanne Koong, Josef Bacik, Bagas Sanjaya,
Chen Linxuan, James Morse, Fuad Tabba, Sean Christopherson,
Shivank Garg, Ackerley Tng, Gregory Price, Aravind Ramesh,
Ajay Joshi, venkataravis@micron.com, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, nvdimm@lists.linux.dev,
linux-cxl@vger.kernel.org, linux-fsdevel@vger.kernel.org
In-Reply-To: <0100019d1d494e7b-2f01e83a-ebaa-4d1b-ae35-33b882a7bda4-000000@email.amazonses.com>
On Tue, 24 Mar 2026 00:40:36 +0000
John Groves <john@jagalactic.com> wrote:
> From: John Groves <john@groves.net>
>
> Virtio_fs now needs to determine if an inode is DAX && not famfs.
FWIW patch bundles broke sashiko
https://sashiko.dev/#/message/0100019d1d46d094-cc0a4b79-3bd2-43e8-a08d-ab8cd21266a6-000000%40email.amazonses.com
It only reviewed the fuse part. (I was looking to see what it had found I missed
in the DAX ones).
> This relaces the FUSE_IS_DAX() macro with FUSE_IS_VIRTIO_DAX(),
replaces (Sashiko spell checks ;)
> in preparation for famfs in later commits. The dummy
> fuse_file_famfs() macro will be replaced with a working
> function.
>
> Reviewed-by: Joanne Koong <joannelkoong@gmail.com>
> Reviewed-by: Dave Jiang <dave.jiang@intel.com>
> Signed-off-by: John Groves <john@groves.net>
> ---
> fs/fuse/dir.c | 2 +-
> fs/fuse/file.c | 13 ++++++++-----
> fs/fuse/fuse_i.h | 9 ++++++++-
> fs/fuse/inode.c | 4 ++--
> fs/fuse/iomode.c | 2 +-
> 5 files changed, 20 insertions(+), 10 deletions(-)
>
> diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c
> index 7ac6b232ef12..c63f097bc697 100644
> --- a/fs/fuse/dir.c
> +++ b/fs/fuse/dir.c
> @@ -2161,7 +2161,7 @@ int fuse_do_setattr(struct mnt_idmap *idmap, struct dentry *dentry,
> is_truncate = true;
> }
>
> - if (FUSE_IS_DAX(inode) && is_truncate) {
> + if (FUSE_IS_VIRTIO_DAX(fi) && is_truncate) {
> filemap_invalidate_lock(mapping);
> fault_blocked = true;
> err = fuse_dax_break_layouts(inode, 0, -1);
> diff --git a/fs/fuse/file.c b/fs/fuse/file.c
> index b1bb7153cb78..4ee5065737d8 100644
> --- a/fs/fuse/file.c
> +++ b/fs/fuse/file.c
> @@ -252,7 +252,7 @@ static int fuse_open(struct inode *inode, struct file *file)
> int err;
> bool is_truncate = (file->f_flags & O_TRUNC) && fc->atomic_o_trunc;
> bool is_wb_truncate = is_truncate && fc->writeback_cache;
> - bool dax_truncate = is_truncate && FUSE_IS_DAX(inode);
> + bool dax_truncate = is_truncate && FUSE_IS_VIRTIO_DAX(fi);
>
> if (fuse_is_bad(inode))
> return -EIO;
> @@ -1812,11 +1812,12 @@ static ssize_t fuse_file_read_iter(struct kiocb *iocb, struct iov_iter *to)
> struct file *file = iocb->ki_filp;
> struct fuse_file *ff = file->private_data;
> struct inode *inode = file_inode(file);
> + struct fuse_inode *fi = get_fuse_inode(inode);
>
> if (fuse_is_bad(inode))
> return -EIO;
>
> - if (FUSE_IS_DAX(inode))
> + if (FUSE_IS_VIRTIO_DAX(fi))
> return fuse_dax_read_iter(iocb, to);
>
> /* FOPEN_DIRECT_IO overrides FOPEN_PASSTHROUGH */
> @@ -1833,11 +1834,12 @@ static ssize_t fuse_file_write_iter(struct kiocb *iocb, struct iov_iter *from)
> struct file *file = iocb->ki_filp;
> struct fuse_file *ff = file->private_data;
> struct inode *inode = file_inode(file);
> + struct fuse_inode *fi = get_fuse_inode(inode);
>
> if (fuse_is_bad(inode))
> return -EIO;
>
> - if (FUSE_IS_DAX(inode))
> + if (FUSE_IS_VIRTIO_DAX(fi))
> return fuse_dax_write_iter(iocb, from);
>
> /* FOPEN_DIRECT_IO overrides FOPEN_PASSTHROUGH */
> @@ -2370,10 +2372,11 @@ static int fuse_file_mmap(struct file *file, struct vm_area_struct *vma)
> struct fuse_file *ff = file->private_data;
> struct fuse_conn *fc = ff->fm->fc;
> struct inode *inode = file_inode(file);
> + struct fuse_inode *fi = get_fuse_inode(inode);
> int rc;
>
> /* DAX mmap is superior to direct_io mmap */
> - if (FUSE_IS_DAX(inode))
> + if (FUSE_IS_VIRTIO_DAX(fi))
> return fuse_dax_mmap(file, vma);
>
> /*
> @@ -2934,7 +2937,7 @@ static long fuse_file_fallocate(struct file *file, int mode, loff_t offset,
> .mode = mode
> };
> int err;
> - bool block_faults = FUSE_IS_DAX(inode) &&
> + bool block_faults = FUSE_IS_VIRTIO_DAX(fi) &&
> (!(mode & FALLOC_FL_KEEP_SIZE) ||
> (mode & (FALLOC_FL_PUNCH_HOLE | FALLOC_FL_ZERO_RANGE)));
>
> diff --git a/fs/fuse/fuse_i.h b/fs/fuse/fuse_i.h
> index 7f16049387d1..45e108dec771 100644
> --- a/fs/fuse/fuse_i.h
> +++ b/fs/fuse/fuse_i.h
> @@ -1508,7 +1508,14 @@ void fuse_free_conn(struct fuse_conn *fc);
>
> /* dax.c */
>
> -#define FUSE_IS_DAX(inode) (IS_ENABLED(CONFIG_FUSE_DAX) && IS_DAX(inode))
> +static inline bool fuse_file_famfs(struct fuse_inode *fuse_inode) /* Will be superseded */
> +{
> + (void)fuse_inode;
> + return false;
> +}
> +#define FUSE_IS_VIRTIO_DAX(fuse_inode) (IS_ENABLED(CONFIG_FUSE_DAX) \
> + && IS_DAX(&fuse_inode->inode) \
> + && !fuse_file_famfs(fuse_inode))
The AI overlord pointed out you should probably have a few more brackets
just in case someone passes something odd in as fuse_inode. Lets assume
they don't pass things with side effects in.
#define FUSE_IS_VIRTIO_DAX(fuse_inode) (IS_ENABLED(CONFIG_FUSE_DAX) \
&& IS_DAX(&(fuse_inode)->inode) \
&& !fuse_file_famfs(fuse_inode))
>
> ssize_t fuse_dax_read_iter(struct kiocb *iocb, struct iov_iter *to);
> ssize_t fuse_dax_write_iter(struct kiocb *iocb, struct iov_iter *from);
> diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c
> index e57b8af06be9..1333b3ebb18a 100644
> --- a/fs/fuse/inode.c
> +++ b/fs/fuse/inode.c
> @@ -162,7 +162,7 @@ static void fuse_evict_inode(struct inode *inode)
> /* Will write inode on close/munmap and in all other dirtiers */
> WARN_ON(inode_state_read_once(inode) & I_DIRTY_INODE);
>
> - if (FUSE_IS_DAX(inode))
> + if (FUSE_IS_VIRTIO_DAX(fi))
> dax_break_layout_final(inode);
>
> truncate_inode_pages_final(&inode->i_data);
> @@ -170,7 +170,7 @@ static void fuse_evict_inode(struct inode *inode)
> if (inode->i_sb->s_flags & SB_ACTIVE) {
> struct fuse_conn *fc = get_fuse_conn(inode);
>
> - if (FUSE_IS_DAX(inode))
> + if (FUSE_IS_VIRTIO_DAX(fi))
> fuse_dax_inode_cleanup(inode);
> if (fi->nlookup) {
> fuse_queue_forget(fc, fi->forget, fi->nodeid,
> diff --git a/fs/fuse/iomode.c b/fs/fuse/iomode.c
> index 3728933188f3..31ee7f3304c6 100644
> --- a/fs/fuse/iomode.c
> +++ b/fs/fuse/iomode.c
> @@ -203,7 +203,7 @@ int fuse_file_io_open(struct file *file, struct inode *inode)
> * io modes are not relevant with DAX and with server that does not
> * implement open.
> */
> - if (FUSE_IS_DAX(inode) || !ff->args)
> + if (FUSE_IS_VIRTIO_DAX(fi) || !ff->args)
> return 0;
>
> /*
^ permalink raw reply
* Re: [PATCH] docs: Document pahole v1.26 requirement for KF_IMPLICIT_ARGS kfuncs
From: Alexei Starovoitov @ 2026-03-24 15:12 UTC (permalink / raw)
To: zhidao su, Ihor Solodrai
Cc: Jonathan Corbet, workflows, LKML, open list:DOCUMENTATION, bpf,
Shuah Khan, zhidao su
In-Reply-To: <20260324062028.2479059-1-suzhidao@xiaomi.com>
On Mon, Mar 23, 2026 at 11:22 PM zhidao su <soolaugust@gmail.com> wrote:
>
> Since Linux 7.0, kfuncs annotated with KF_IMPLICIT_ARGS require pahole
> v1.26 or later. Without it, such kfuncs have incorrect BTF prototypes in
> vmlinux, causing BPF programs to fail with 'func_proto incompatible with
> vmlinux' error.
>
> This affects all sched_ext kfuncs (e.g. scx_bpf_create_dsq,
> scx_bpf_dispatch) and other KF_IMPLICIT_ARGS kfuncs across the kernel.
> Ubuntu 24.04 LTS ships pahole v1.25 by default, causing 23/30 sched_ext
> selftests to fail on affected systems.
I don't think that's true.
At least when implicit args were designed the goal was to avoid
pahole dependencies.
Please share exact steps to reproduce.
Updating doc is definitely not an answer.
pw-bot: cr
^ permalink raw reply
* [kees:dev/v7.0-rc2/obt 2/4] htmldocs: Documentation/process/arithmetic-overflow.rst: WARNING: document isn't included in any toctree [toc.not_included]
From: kernel test robot @ 2026-03-24 15:11 UTC (permalink / raw)
To: Justin Stitt; +Cc: oe-kbuild-all, Kees Cook, linux-doc
tree: https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git dev/v7.0-rc2/obt
head: 537858cd27d509ec0dedfa4b96bc1d0e461367b1
commit: 9e0190e84f2ecf5ff7314441655d71913095654e [2/4] compiler_attributes: Add overflow_behavior macros __wrap and __trap
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
docutils: docutils (Docutils 0.21.2, Python 3.13.5, on linux)
reproduce: (https://download.01.org/0day-ci/archive/20260324/202603241633.kh2zxFVG-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603241633.kh2zxFVG-lkp@intel.com/
All warnings (new ones prefixed by >>):
Documentation/userspace-api/landlock:526: ./include/uapi/linux/landlock.h:45: ERROR: Unknown target name: "network flags". [docutils]
Documentation/userspace-api/landlock:526: ./include/uapi/linux/landlock.h:50: ERROR: Unknown target name: "scope flags". [docutils]
Documentation/userspace-api/landlock:526: ./include/uapi/linux/landlock.h:24: ERROR: Unknown target name: "filesystem flags". [docutils]
Documentation/userspace-api/landlock:535: ./include/uapi/linux/landlock.h:166: ERROR: Unknown target name: "filesystem flags". [docutils]
Documentation/userspace-api/landlock:535: ./include/uapi/linux/landlock.h:189: ERROR: Unknown target name: "network flags". [docutils]
>> Documentation/process/arithmetic-overflow.rst: WARNING: document isn't included in any toctree [toc.not_included]
Documentation/networking/skbuff:36: ./include/linux/skbuff.h:181: WARNING: Failed to create a cross reference. A title or caption not found: 'crc' [ref.ref]
>> Documentation/process/arithmetic-overflow.rst:25: WARNING: undefined label: '_open_coded_wrap_around' [ref.ref]
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 2/2] kallsyms: add BTF-based deep parameter rendering in oops dumps
From: Alexei Starovoitov @ 2026-03-24 15:07 UTC (permalink / raw)
To: Sasha Levin
Cc: Andrew Morton, Masahiro Yamada, Nathan Chancellor, Nicolas Schier,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Peter Zijlstra, Josh Poimboeuf, Petr Mladek,
Alexei Starovoitov, Jonathan Corbet, David Gow, Kees Cook,
Greg KH, Luis Chamberlain, Steven Rostedt, Helge Deller,
Randy Dunlap, Geert Uytterhoeven, Juergen Gross, James Bottomley,
Alexey Dobriyan, Vlastimil Babka, Laurent Pinchart, Petr Pavlu,
X86 ML, LKML, Linux Kbuild mailing list, open list:DOCUMENTATION,
linux-modules, bpf
In-Reply-To: <20260323164858.1939248-3-sashal@kernel.org>
On Mon, Mar 23, 2026 at 9:49 AM Sasha Levin <sashal@kernel.org> wrote:
>
> +static const char *extract_struct_name(const char *type_str, bool *is_union,
> + char *name_buf, size_t bufsz)
> +{
> + const char *p, *end;
> +
> + *is_union = false;
> +
> + /* Must end with " *" to be a pointer */
> + end = type_str + strlen(type_str);
> + if (end - type_str < 3 || end[-1] != '*' || end[-2] != ' ')
> + return NULL;
> +
> + if (!strncmp(type_str, "struct ", 7)) {
> + p = type_str + 7;
> + } else if (!strncmp(type_str, "union ", 6)) {
> + p = type_str + 6;
> + *is_union = true;
> + } else {
> + return NULL;
> + }
> +
> + /* Copy name up to the " *" */
> + {
> + size_t len = (end - 2) - p;
> +
> + if (len == 0 || len >= bufsz)
> + return NULL;
> + memcpy(name_buf, p, len);
> + name_buf[len] = '\0';
> + }
> +
> + return name_buf;
Nack. This is just awful.
You didn't even bother to reformat what claude spat out.
Which means you didn't think it through.
It prints something that looks plausible
which is the opposite of what kernel crash dump should be.
crash output should be accurate and not a guess work.
^ permalink raw reply
* Re: [PATCH V9 8/8] dax: export dax_dev_get()
From: Jonathan Cameron @ 2026-03-24 15:06 UTC (permalink / raw)
To: John Groves
Cc: John Groves, Miklos Szeredi, Dan Williams, Bernd Schubert,
Alison Schofield, John Groves, Jonathan Corbet, Shuah Khan,
Vishal Verma, Dave Jiang, Matthew Wilcox, Jan Kara,
Alexander Viro, David Hildenbrand, Christian Brauner,
Darrick J . Wong, Randy Dunlap, Jeff Layton, Amir Goldstein,
Stefan Hajnoczi, Joanne Koong, Josef Bacik, Bagas Sanjaya,
Chen Linxuan, James Morse, Fuad Tabba, Sean Christopherson,
Shivank Garg, Ackerley Tng, Gregory Price, Aravind Ramesh,
Ajay Joshi, venkataravis@micron.com, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, nvdimm@lists.linux.dev,
linux-cxl@vger.kernel.org, linux-fsdevel@vger.kernel.org
In-Reply-To: <0100019d1d487fb8-c84bb720-35d3-4d50-8eb4-c92254121bcb-000000@email.amazonses.com>
On Tue, 24 Mar 2026 00:39:43 +0000
John Groves <john@jagalactic.com> wrote:
> From: John Groves <john@groves.net>
>
> famfs needs to look up a dax_device by dev_t when resolving fmap
> entries that reference character dax devices.
>
> Reviewed-by: Dave Jiang <dave.jiang@intel.com>
> Signed-off-by: John Groves <john@groves.net>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
^ permalink raw reply
* Re: [PATCH] Documentation/admin-guide/mm/damon: fix 'parametrs' typo
From: SeongJae Park @ 2026-03-24 15:06 UTC (permalink / raw)
To: Cheng-Han Wu
Cc: SeongJae Park, corbet, damon, linux-mm, linux-doc, linux-kernel,
skhan
In-Reply-To: <20260324144851.12883-1-hank20010209@gmail.com>
On Tue, 24 Mar 2026 22:48:51 +0800 Cheng-Han Wu <hank20010209@gmail.com> wrote:
> Fix the misspelling of "parametrs" as "parameters" in
> reclaim.rst and lru_sort.rst.
Thank you for finding and fixing these!
>
> Signed-off-by: Cheng-Han Wu <hank20010209@gmail.com>
Reviewed-by: SeongJae Park <sj@kernel.org>
Thanks,
SJ
[...]
^ permalink raw reply
* Re: [PATCH v4] landlock: Expand restrict flags example for ABI version 8
From: Mickaël Salaün @ 2026-03-24 15:06 UTC (permalink / raw)
To: Günther Noack
Cc: Panagiotis "Ivory" Vasilopoulos, Jonathan Corbet,
Shuah Khan, linux-security-module, linux-doc, linux-kernel,
Dan Cojocaru
In-Reply-To: <acJa_56LtPeeH956@google.com>
On Tue, Mar 24, 2026 at 10:48:29AM +0100, Günther Noack wrote:
> Hello!
>
> On Mon, Mar 23, 2026 at 07:56:21PM +0100, Mickaël Salaün wrote:
> > Thanks! I pushed your patch in next with a minor fix.
> >
> > Günther, does it look good to you?
> >
> > On Wed, Mar 04, 2026 at 07:13:04PM +0100, Panagiotis "Ivory" Vasilopoulos wrote:
> > > Add LANDLOCK_RESTRICT_SELF_TSYNC to the backwards compatibility example
> > > for restrict flags. This introduces completeness, similar to that of
> > > the ruleset attributes example. However, as the new example can impact
> > > enforcement in certain cases, an appropriate warning is also included.
> > >
> > > Additionally, I modified the two comments of the example to make them
> > > more consistent with the ruleset attributes example's.
> > >
> > > Signed-off-by: Panagiotis 'Ivory' Vasilopoulos <git@n0toose.net>
> > > Co-developed-by: Dan Cojocaru <dan@dcdev.ro>
> > > Signed-off-by: Dan Cojocaru <dan@dcdev.ro>
> > > ---
> > > Changes in v4:
> > > - Make warning somewhat more terse, merge comments.
> > > - Remove some sensationalization. ("Don't copy-paste this just yet!")
> > > - Apply Günther's suggestion (v3 "recycled" some phrases, was long)
> > > - ... but also retain some of the wording on ABI differences
> > > - Provide a brief overview that contextualizes the example further:
> > > - Clarify the difference behind ABI < 8 & ABI v8, to avoid
> > > misunderstandings on which option is the default.
> > > - Make "linear reading" easier.
> > > - Based on Mickaël's feedback: Avoid cans of worms w.r.t. use cases
> > > - Link to v3: https://lore.kernel.org/r/20260228-landlock-docs-add-tsync-example-v3-1-140ab50f0524@n0toose.net
> > >
> > > Changes in v3:
> > > - Add __attribute__((fallthrough)) like in earlier example.
> > > - Improve comment for LANDLOCK_RESTRICT_SELF_TSYNC (ABI < 8) example.
> > > - Add relevant warning for ABI < 8 example based on Günther's feedback.
> > > - Link to v2: https://lore.kernel.org/r/20260221-landlock-docs-add-tsync-example-v2-1-60990986bba5@n0toose.net
> > >
> > > Changes in v2:
> > > - Fix formatting error.
> > > - Link to v1: https://lore.kernel.org/r/20260221-landlock-docs-add-tsync-example-v1-1-f89383809eb4@n0toose.net
> > > ---
> > > Documentation/userspace-api/landlock.rst | 22 ++++++++++++++++++----
> > > 1 file changed, 18 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/Documentation/userspace-api/landlock.rst b/Documentation/userspace-api/landlock.rst
> > > index 13134bccdd39d78ddce3daf454f32dda162ce91b..64c7138a788d74f99da0a71428da392b3d873bf8 100644
> > > --- a/Documentation/userspace-api/landlock.rst
> > > +++ b/Documentation/userspace-api/landlock.rst
> > > @@ -196,13 +196,27 @@ similar backwards compatibility check is needed for the restrict flags
> > > (see sys_landlock_restrict_self() documentation for available flags):
> > >
> > > .. code-block:: c
> > > -
> > > - __u32 restrict_flags = LANDLOCK_RESTRICT_SELF_LOG_NEW_EXEC_ON;
> > > - if (abi < 7) {
> > > - /* Clear logging flags unsupported before ABI 7. */
> > > + __u32 restrict_flags =
> > > + LANDLOCK_RESTRICT_SELF_LOG_NEW_EXEC_ON |
> > > + LANDLOCK_RESTRICT_SELF_TSYNC;
> > > + switch (abi) {
> > > + case 1 ... 6:
> > > + /* Clear logging flags unsupported for ABI < 7 */
> > > restrict_flags &= ~(LANDLOCK_RESTRICT_SELF_LOG_SAME_EXEC_OFF |
> > > LANDLOCK_RESTRICT_SELF_LOG_NEW_EXEC_ON |
> > > LANDLOCK_RESTRICT_SELF_LOG_SUBDOMAINS_OFF);
> > > + __attribute__((fallthrough));
> > > + case 7:
> > > + /*
> > > + * Removes multithreaded enforcement flag unsupported for ABI < 8
> > > + *
> > > + * WARNING: Without this flag, calling landlock_restrict_self(2) is
> > > + * only equivalent if the calling process is single-threaded. Below
> > > + * ABI v8 (and as of ABI v8, when not using this flag), a Landlock
> > > + * policy would only be enforced for the calling thread and its
> > > + * children (and not for all threads, including parents and siblings).
> > > + */
> > > + restrict_flags &= ~LANDLOCK_RESTRICT_SELF_TSYNC;
> > > }
> > >
> > > The next step is to restrict the current thread from gaining more privileges
> > >
> > > ---
> > > base-commit: ceb977bfe9e8715e6cd3a4785c7aab8ea5cd2b77
> > > change-id: 20260221-landlock-docs-add-tsync-example-e8fd5c64a366
> > >
> > > Best regards,
> > > --
> > > Panagiotis "Ivory" Vasilopoulos <git@n0toose.net>
> > >
> > >
>
> Apologies for the delay, this must have slipped through the cracks.
> Thanks for bringing it up again. Yes, this looks good.
>
> Signed-off-by: Günther Noack <gnoack@google.com>
Shouldn't it be a Reviewed-by?
^ permalink raw reply
* Re: [PATCH V9 7/8] dax: Add fs_dax_get() func to prepare dax for fs-dax usage
From: Jonathan Cameron @ 2026-03-24 15:05 UTC (permalink / raw)
To: John Groves
Cc: John Groves, Miklos Szeredi, Dan Williams, Bernd Schubert,
Alison Schofield, John Groves, Jonathan Corbet, Shuah Khan,
Vishal Verma, Dave Jiang, Matthew Wilcox, Jan Kara,
Alexander Viro, David Hildenbrand, Christian Brauner,
Darrick J . Wong, Randy Dunlap, Jeff Layton, Amir Goldstein,
Stefan Hajnoczi, Joanne Koong, Josef Bacik, Bagas Sanjaya,
Chen Linxuan, James Morse, Fuad Tabba, Sean Christopherson,
Shivank Garg, Ackerley Tng, Gregory Price, Aravind Ramesh,
Ajay Joshi, venkataravis@micron.com, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, nvdimm@lists.linux.dev,
linux-cxl@vger.kernel.org, linux-fsdevel@vger.kernel.org
In-Reply-To: <0100019d1d484ddc-2487f887-7ecd-49a3-abfe-9dabec28873f-000000@email.amazonses.com>
On Tue, 24 Mar 2026 00:39:31 +0000
John Groves <john@jagalactic.com> wrote:
> From: John Groves <john@groves.net>
>
> The fs_dax_get() function should be called by fs-dax file systems after
> opening a fsdev dax device. This adds holder_operations, which provides
> a memory failure callback path and effects exclusivity between callers
> of fs_dax_get().
>
> fs_dax_get() is specific to fsdev_dax, so it checks the driver type
> (which required touching bus.[ch]). fs_dax_get() fails if fsdev_dax is
> not bound to the memory.
>
> This function serves the same role as fs_dax_get_by_bdev(), which dax
> file systems call after opening the pmem block device.
>
> This can't be located in fsdev.c because struct dax_device is opaque
> there.
>
> This will be called by fs/fuse/famfs.c in a subsequent commit.
>
> Signed-off-by: John Groves <john@groves.net>
Hi John,
Looks like a stray header change - see inline.
With that tidied up.
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> #define dax_driver_register(driver) \
> diff --git a/drivers/dax/super.c b/drivers/dax/super.c
> index ba0b4cd18a77..d4ab60c406bf 100644
> --- a/drivers/dax/super.c
> +++ b/drivers/dax/super.c
> diff --git a/include/linux/dax.h b/include/linux/dax.h
> index b19bfe0c2fd1..bf37b9a982f3 100644
> --- a/include/linux/dax.h
> +++ b/include/linux/dax.h
> #if IS_ENABLED(CONFIG_FS_DAX)
> +void fs_put_dax(struct dax_device *dax_dev, void *holder);
> +int fs_dax_get(struct dax_device *dax_dev, void *holder,
> + const struct dax_holder_operations *hops);
> +struct dax_device *inode_dax(struct inode *inode);
What's this? Not used in this patch and not stubbed.
It's in drivers/dax/dax-private.h already and given I assume code builds
before this patch (and it's not used in patch 8) then presumably it doesn't
need to be here.
I got suspicious due to the lack of stub rather indicating something differnt
form the other two.
> int dax_writeback_mapping_range(struct address_space *mapping,
> struct dax_device *dax_dev, struct writeback_control *wbc);
> int dax_folio_reset_order(struct folio *folio);
> @@ -164,6 +164,15 @@ dax_entry_t dax_lock_mapping_entry(struct address_space *mapping,
> void dax_unlock_mapping_entry(struct address_space *mapping,
> unsigned long index, dax_entry_t cookie);
> #else
> +static inline void fs_put_dax(struct dax_device *dax_dev, void *holder)
> +{
> +}
> +
> +static inline int fs_dax_get(struct dax_device *dax_dev, void *holder,
> + const struct dax_holder_operations *hops)
> +{
> + return -EOPNOTSUPP;
> +}
> static inline struct page *dax_layout_busy_page(struct address_space *mapping)
> {
> return NULL;
^ permalink raw reply
* Re: [PATCH 1/2] kallsyms: show function parameter info in oops/WARN dumps
From: Alexei Starovoitov @ 2026-03-24 15:03 UTC (permalink / raw)
To: Sasha Levin
Cc: Andrew Morton, Masahiro Yamada, Nathan Chancellor, Nicolas Schier,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Peter Zijlstra, Josh Poimboeuf, Petr Mladek,
Alexei Starovoitov, Jonathan Corbet, David Gow, Kees Cook,
Greg KH, Luis Chamberlain, Steven Rostedt, Helge Deller,
Randy Dunlap, Geert Uytterhoeven, Juergen Gross, James Bottomley,
Alexey Dobriyan, Vlastimil Babka, Laurent Pinchart, Petr Pavlu,
X86 ML, LKML, Linux Kbuild mailing list, open list:DOCUMENTATION,
linux-modules, bpf
In-Reply-To: <20260323164858.1939248-2-sashal@kernel.org>
On Mon, Mar 23, 2026 at 9:49 AM Sasha Levin <sashal@kernel.org> wrote:
>
> Embed DWARF-derived function parameter name and type information in the
> kernel image so that oops and WARN dumps display the crashing function's
> register-passed arguments with their names, types, and values.
>
> A new build-time tool (scripts/gen_paraminfo.c) parses DW_TAG_subprogram
> and DW_TAG_formal_parameter entries from DWARF .debug_info, extracting
> parameter names and human-readable type strings. The resulting tables are
> stored in .rodata using the same two-phase link approach as lineinfo.
>
> At runtime, kallsyms_show_paraminfo() performs a binary search on the
> paraminfo tables, maps parameters to x86-64 calling convention registers
> (RDI, RSI, RDX, RCX, R8, R9), and prints each parameter's name, type,
> and value from pt_regs. If a parameter value matches the page fault
> address (CR2), it is highlighted with "<-- fault address".
>
> Integration at show_regs() means this works for both oops and WARN()
> automatically, since both paths provide full pt_regs at the exception
> point.
>
> Example output:
>
> Function parameters (ext4_readdir):
> file (struct file *) = 0xffff888123456000
> ctx (struct dir_context *) = 0x0000000000001234 <-- fault address
>
> Gated behind CONFIG_KALLSYMS_PARAMINFO (depends on CONFIG_KALLSYMS_LINEINFO).
> Adds approximately 1-2 MB to the kernel image for ~58K functions.
>
> Assisted-by: Claude:claude-opus-4-6
> Signed-off-by: Sasha Levin <sashal@kernel.org>
Nack.
You asked claude to reinvent pahole and BTF and it did it
completely missing years of fine tuning that pahole does.
dwarf cannot be trusted as-is. pahole converts it carefully
by analyzing optimized out arguments and dropping signatures
from BTF that are not accurate. This work is still ongoing.
For example see this set:
https://lore.kernel.org/bpf/20260320190917.1970524-1-yonghong.song@linux.dev/
pahole isn't perfect, but what you attempted to do here
is just broken.
^ permalink raw reply
* Re: [RFC PATCH v1 1/1] This patch set introces a new action: DAMOS_COLLAPSE.
From: Gutierrez Asier @ 2026-03-24 15:01 UTC (permalink / raw)
To: SeongJae Park
Cc: artem.kuzin, stepanov.anatoly, wangkefeng.wang, yanquanmin1,
zuoze1, damon, akpm, ljs, Liam.Howlett, vbabka, rppt, surenb,
mhocko, corbet, skhan, linux-doc, linux-mm, linux-kernel
In-Reply-To: <20260324141257.91322-1-sj@kernel.org>
On 3/24/2026 5:12 PM, SeongJae Park wrote:
> On Tue, 24 Mar 2026 16:57:22 +0300 Gutierrez Asier <gutierrez.asier@huawei-partners.com> wrote:
>
>>
>>
>> On 3/24/2026 3:39 AM, SeongJae Park wrote:
>>> Hello Asier,
>>>
>>> On Mon, 23 Mar 2026 14:56:45 +0000 <gutierrez.asier@huawei-partners.com> wrote:
>>>
>>>> From: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
>>>>
>>>> For DAMOS_HUGEPAGE and DAMOS_NOHUGEPAGE to work, khugepaged should be
>>>> working, since it relies on hugepage_madvise to add a new slot. This
>>>> slot should be picked up by khugepaged and eventually collapse (or
>>>> not, if we are using DAMOS_NOHUGEPAGE) the pages. If THP is not
>>>> enabled, khugepaged will not be working, and therefore no collapse
>>>> will happen.
>>>>
>>>> DAMOS_COLLAPSE eventually calls madvise_collapse, which will collapse
>>>> the address range synchronously.
>>>>
>>>> This new action may be required to support autotuning with hugepage as
>>>> a goal[1].
>>>>
>>>> [1]: https://lore.kernel.org/damon/20260313000816.79933-1-sj@kernel.org/
>>>>
>>>> ---------
>>>> Benchmarks:
>>>>
>>>> T n: THP never
>>>> T m: THP madvise
>>>> D h: DAMON action hugepage
>>>> D c: DAMON action collapse
>>>>
>>>> +------------------+----------+----------+----------+
>>>> | | T n, D h | T m, D h | T n, D c |
>>>> +------------------+----------+----------+----------+
>>>> | Total memory use | 2.07 | 2.09 | 2.07 |
>>>> | Huge pages | 0 | 1.3 | 1.25 |
>>>> +------------------+----------+----------+----------+
>>>
>>> Thank you for sharing the benchmark results! But, I'm having a hard time to
>>> understand what this really means. Could you please further clarify the setup
>>> of the benchmarks and interpretation of the results?
>> I will fix the cover in the next version, which I will submit soon.
>>
>> I tested the patch in a physical server with MariaDB 10.5. I run
>> sysbench to load the server.
>>
>> I check 3 scenarios:
>> - DAMON action hugepage for the database task, THP as never
>> - DAMON action hugepage, THP madvise
>> - DAMON action collapse, THP never
>>
>> I compared the memory consumption, both in overall in the server and
>> anonymous huge page consumption. The results are in the table
>>
>> T n: THP never
>> T m: THP madvise
>> D h: DAMON action hugepage
>> D c: DAMON action collapse
>
> Thank you for sharing the details of the setup, Asier.
>
>>
>> +------------------+----------+----------+----------+
>> | | T n, D h | T m, D h | T n, D c |
>> +------------------+----------+----------+----------+
>> | Total memory use | 2.07 | 2.09 | 2.07 |
>> | Huge pages | 0 | 1.3 | 1.25 |
>> +------------------+----------+----------+----------+
>
> Could you please further share interpretation of the results? What these
> results mean? Does it show some benefit of DAMOS_COLLAPSE?
In the first row is the total memory consumption in GB by the server
and in the second row the huge page consumption.
What this table shows is that DAMON action "hugepage" doesn't lead
to any hugepage collapse unless THP is set to madvise. If DAMON
action is set to "collapse", hugepage collapses happen, even when
THP is disabled. The memory consumption for DAMON "collapse" is
slightly lower than with "hugepage", since madvise applies to the
entire server and other application may request to collapse pages
through madvise.
Regarding the performance, I saw improvement from no hugepage at all
to use of hugepages. No significant difference between "hugepage" and
"collapse" actions. I will have a look to the logs and publish it a bit
later.
> Also, how is the performance? Does it show some difference?
>
>>>
>>>>
>>>> Changes
>>>> ---------
>>>> v1-v2:
>>>> Added benchmarks
>>>> Added damos_filter_type documentation for new action to fix kernel-doc
>>>
>>> Please add Changelog on the commentary section [1]. Also, please consider
>>> adding links to previous versions.
>>>
>>>>
>>>> Signed-off-by: Asier Gutierrez <gutierrez.asier@huawei-partners.com>
>>>> ---
>>>> Documentation/mm/damon/design.rst | 4 ++++
>>>> include/linux/damon.h | 2 ++
>>>> mm/damon/sysfs-schemes.c | 4 ++++
>>>> mm/damon/vaddr.c | 3 +++
>>>> tools/testing/selftests/damon/sysfs.py | 11 ++++++-----
>>>> 5 files changed, 19 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst
>>>> index 838b14d22519..405142641e55 100644
>>>> --- a/Documentation/mm/damon/design.rst
>>>> +++ b/Documentation/mm/damon/design.rst
>>>> @@ -467,6 +467,10 @@ that supports each action are as below.
>>>> Supported by ``vaddr`` and ``fvaddr`` operations set. When
>>>> TRANSPARENT_HUGEPAGE is disabled, the application of the action will just
>>>> fail.
>>>> + - ``collapse``: Call ``madvise()`` for the region with ``MADV_COLLAPSE``.
>>>> + Supported by ``vaddr`` and ``fvaddr`` operations set. When
>>>> + TRANSPARENT_HUGEPAGE is disabled, the application of the action will just
>>>> + fail.
>>>> - ``lru_prio``: Prioritize the region on its LRU lists.
>>>> Supported by ``paddr`` operations set.
>>>> - ``lru_deprio``: Deprioritize the region on its LRU lists.
>>>> diff --git a/include/linux/damon.h b/include/linux/damon.h
>>>> index d9a3babbafc1..6941113968ec 100644
>>>> --- a/include/linux/damon.h
>>>> +++ b/include/linux/damon.h
>>>> @@ -121,6 +121,7 @@ struct damon_target {
>>>> * @DAMOS_PAGEOUT: Reclaim the region.
>>>> * @DAMOS_HUGEPAGE: Call ``madvise()`` for the region with MADV_HUGEPAGE.
>>>> * @DAMOS_NOHUGEPAGE: Call ``madvise()`` for the region with MADV_NOHUGEPAGE.
>>>> + * @DAMOS_COLLAPSE: Call ``madvise()`` for the region with MADV_COLLAPSE.
>>>> * @DAMOS_LRU_PRIO: Prioritize the region on its LRU lists.
>>>> * @DAMOS_LRU_DEPRIO: Deprioritize the region on its LRU lists.
>>>> * @DAMOS_MIGRATE_HOT: Migrate the regions prioritizing warmer regions.
>>>> @@ -140,6 +141,7 @@ enum damos_action {
>>>> DAMOS_PAGEOUT,
>>>> DAMOS_HUGEPAGE,
>>>> DAMOS_NOHUGEPAGE,
>>>> + DAMOS_COLLAPSE,
>>>> DAMOS_LRU_PRIO,
>>>> DAMOS_LRU_DEPRIO,
>>>> DAMOS_MIGRATE_HOT,
>>>> diff --git a/mm/damon/sysfs-schemes.c b/mm/damon/sysfs-schemes.c
>>>> index 5186966dafb3..aa08a8f885fb 100644
>>>> --- a/mm/damon/sysfs-schemes.c
>>>> +++ b/mm/damon/sysfs-schemes.c
>>>> @@ -2041,6 +2041,10 @@ static struct damos_sysfs_action_name damos_sysfs_action_names[] = {
>>>> .action = DAMOS_NOHUGEPAGE,
>>>> .name = "nohugepage",
>>>> },
>>>> + {
>>>> + .action = DAMOS_COLLAPSE,
>>>> + .name = "collapse",
>>>> + },
>>>> {
>>>> .action = DAMOS_LRU_PRIO,
>>>> .name = "lru_prio",
>>>> diff --git a/mm/damon/vaddr.c b/mm/damon/vaddr.c
>>>> index b069dbc7e3d2..dd5f2d7027ac 100644
>>>> --- a/mm/damon/vaddr.c
>>>> +++ b/mm/damon/vaddr.c
>>>> @@ -903,6 +903,9 @@ static unsigned long damon_va_apply_scheme(struct damon_ctx *ctx,
>>>> case DAMOS_NOHUGEPAGE:
>>>> madv_action = MADV_NOHUGEPAGE;
>>>> break;
>>>> + case DAMOS_COLLAPSE:
>>>> + madv_action = MADV_COLLAPSE;
>>>> + break;
>>>> case DAMOS_MIGRATE_HOT:
>>>> case DAMOS_MIGRATE_COLD:
>>>> return damos_va_migrate(t, r, scheme, sz_filter_passed);
>>>> diff --git a/tools/testing/selftests/damon/sysfs.py b/tools/testing/selftests/damon/sysfs.py
>>>> index 3aa5c91548a5..c6476e63f4fb 100755
>>>> --- a/tools/testing/selftests/damon/sysfs.py
>>>> +++ b/tools/testing/selftests/damon/sysfs.py
>>>> @@ -123,11 +123,12 @@ def assert_scheme_committed(scheme, dump):
>>>> 'pageout': 2,
>>>> 'hugepage': 3,
>>>> 'nohugeapge': 4,
>>>> - 'lru_prio': 5,
>>>> - 'lru_deprio': 6,
>>>> - 'migrate_hot': 7,
>>>> - 'migrate_cold': 8,
>>>> - 'stat': 9,
>>>> + 'collapse': 5
>>>
>>> Comman is missed?
>>>
>>>> + 'lru_prio': 6,
>>>> + 'lru_deprio': 7,
>>>> + 'migrate_hot': 8,
>>>> + 'migrate_cold': 9,
>>>> + 'stat': 10,
>>>> }
>>>> assert_true(dump['action'] == action_val[scheme.action], 'action', dump)
>>>> assert_true(dump['apply_interval_us'] == scheme. apply_interval_us,
>>>> --
>>>> 2.43.0
>>>
>>> Other than the selftest part, code looks good. Please consider dropping RFC
>>> tag from the next spin. Clarifying more details about the test would be
>>> helpful, though.
>>>
>>> [1] https://docs.kernel.org/process/submitting-patches.html#commentary
>>>
>>>
>>> Thanks,
>>> SJ
>>>
>>
>> SJ, should I remove the RFC tag for the next version?
>
> If you feel comfortable with it, please do so.
>
>
> Thanks,
> SJ
>
> [...]
>
--
Asier Gutierrez
Huawei
^ permalink raw reply
* Re: [PATCH v10 28/30] KVM: arm64: selftests: Skip impossible invalid value tests
From: Mark Brown @ 2026-03-24 14:56 UTC (permalink / raw)
To: Ben Horgan
Cc: Marc Zyngier, Joey Gouly, Catalin Marinas, Suzuki K Poulose,
Will Deacon, Paolo Bonzini, Jonathan Corbet, Shuah Khan,
Oliver Upton, Dave Martin, Fuad Tabba, Mark Rutland,
linux-arm-kernel, kvmarm, linux-kernel, kvm, linux-doc,
linux-kselftest, Peter Maydell, Eric Auger
In-Reply-To: <0f8d0966-4e05-4d5a-a523-098b3dbcf7d9@arm.com>
[-- Attachment #1: Type: text/plain, Size: 371 bytes --]
On Tue, Mar 24, 2026 at 02:54:54PM +0000, Ben Horgan wrote:
> On 3/6/26 17:01, Mark Brown wrote:
> > + default:
> > + *skip = true;
> > + break;
> > + }
> > }
> I hacked up a quick loop to check what this function is doing.
> With a mask=0x1 I see some value returned that have bits set
> outside of the mask.
Thanks, do you happen to still have that to hand?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v10 28/30] KVM: arm64: selftests: Skip impossible invalid value tests
From: Ben Horgan @ 2026-03-24 14:54 UTC (permalink / raw)
To: Mark Brown, Marc Zyngier, Joey Gouly, Catalin Marinas,
Suzuki K Poulose, Will Deacon, Paolo Bonzini, Jonathan Corbet,
Shuah Khan, Oliver Upton
Cc: Dave Martin, Fuad Tabba, Mark Rutland, linux-arm-kernel, kvmarm,
linux-kernel, kvm, linux-doc, linux-kselftest, Peter Maydell,
Eric Auger
In-Reply-To: <20260306-kvm-arm64-sme-v10-28-43f7683a0fb7@kernel.org>
Hi Mark,
On 3/6/26 17:01, Mark Brown wrote:
> The set_id_regs test currently assumes that there will always be invalid
> values available in bitfields for it to generate but this may not be the
> case if the architecture has defined meanings for every possible value for
> the bitfield. An assert added in commit bf09ee918053e ("KVM: arm64:
> selftests: Remove ARM64_FEATURE_FIELD_BITS and its last user") refuses to
> run for single bit fields which will show the issue most readily but there
> is no reason wider ones can't show the same issue.
>
> Rework the tests for invalid value to check if an invalid value can be
> generated and skip the test if not, removing the assert.
>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
> tools/testing/selftests/kvm/arm64/set_id_regs.c | 63 +++++++++++++++++++++----
> 1 file changed, 53 insertions(+), 10 deletions(-)
>
> diff --git a/tools/testing/selftests/kvm/arm64/set_id_regs.c b/tools/testing/selftests/kvm/arm64/set_id_regs.c
> index bfca7be3e766..928e7d9e5ab7 100644
> --- a/tools/testing/selftests/kvm/arm64/set_id_regs.c
> +++ b/tools/testing/selftests/kvm/arm64/set_id_regs.c
> @@ -317,11 +317,12 @@ uint64_t get_safe_value(const struct reg_ftr_bits *ftr_bits, uint64_t ftr)
> }
>
> /* Return an invalid value to a given ftr_bits an ftr value */
> -uint64_t get_invalid_value(const struct reg_ftr_bits *ftr_bits, uint64_t ftr)
> +uint64_t get_invalid_value(const struct reg_ftr_bits *ftr_bits, uint64_t ftr,
> + bool *skip)
> {
> uint64_t ftr_max = ftr_bits->mask >> ftr_bits->shift;
>
> - TEST_ASSERT(ftr_max > 1, "This test doesn't support single bit features");
> + *skip = false;
>
> if (ftr_bits->sign == FTR_UNSIGNED) {
> switch (ftr_bits->type) {
> @@ -329,42 +330,81 @@ uint64_t get_invalid_value(const struct reg_ftr_bits *ftr_bits, uint64_t ftr)
> ftr = max((uint64_t)ftr_bits->safe_val + 1, ftr + 1);
> break;
> case FTR_LOWER_SAFE:
> + if (ftr == ftr_max)
> + *skip = true;
> ftr++;
> break;
> case FTR_HIGHER_SAFE:
> + if (ftr == 0)
> + *skip = true;
> ftr--;
> break;
> case FTR_HIGHER_OR_ZERO_SAFE:
> - if (ftr == 0)
> + switch (ftr) {
> + case 0:
> ftr = ftr_max;
> - else
> + break;
> + case 1:
> + *skip = true;
> + break;
> + default:
> ftr--;
> + break;
> + }
> break;
> default:
> + *skip = true;
> break;
> }
> } else if (ftr != ftr_max) {
> switch (ftr_bits->type) {
> case FTR_EXACT:
> ftr = max((uint64_t)ftr_bits->safe_val + 1, ftr + 1);
> + if (ftr >= ftr_max)
> + *skip = true;
> break;
> case FTR_LOWER_SAFE:
> ftr++;
> break;
> case FTR_HIGHER_SAFE:
> - ftr--;
> + /* FIXME: "need to check for the actual highest." */
> + if (ftr == ftr_max)
> + *skip = true;
> + else
> + ftr--;
> break;
> case FTR_HIGHER_OR_ZERO_SAFE:
> - if (ftr == 0)
> - ftr = ftr_max - 1;
> - else
> + switch (ftr) {
> + case 0:
> + if (ftr_max > 1)
> + ftr = ftr_max - 1;
> + else
> + *skip = true;
> + break;
> + case 1:
> + *skip = true;
> + break;
> + default:
> ftr--;
> + break;
> + }
> break;
> default:
> + *skip = true;
> break;
> }
> } else {
> - ftr = 0;
> + switch (ftr_bits->type) {
> + case FTR_LOWER_SAFE:
> + if (ftr == 0)
> + *skip = true;
> + else
> + ftr = 0;
> + break;
> + default:
> + *skip = true;
> + break;
> + }
> }
I hacked up a quick loop to check what this function is doing.
With a mask=0x1 I see some value returned that have bits set
outside of the mask.
safe_val ftr out
UNSIGNED
FTR_EXACT
0x0 0x0 0x1
0x0 0x1 0x2 # out of range
0x1 0x0 0x2 # out of range
0x1 0x1 0x2 # out of range
FTR_LOWER_SAFE
0x0 0x0 0x1
0x0 0x1 SKIP
0x1 0x0 0x1
0x1 0x1 SKIP
FTR_HIGHER_SAFE
0x0 0x0 SKIP
0x0 0x1 0x0
0x1 0x0 SKIP
0x1 0x1 0x0
FTR_HIGHER_OR_ZERO_SAFE
0x0 0x0 0x1
0x0 0x1 SKIP
0x1 0x0 0x1
0x1 0x1 SKIP
SIGNED
FTR_EXACT
0x0 0x0 SKIP
0x0 0x1 SKIP
0x1 0x0 SKIP
0x1 0x1 SKIP
FTR_LOWER_SAFE
0x0 0x0 0x1
0x0 0x1 0x0
0x1 0x0 0x1
0x1 0x1 0x0
FTR_HIGHER_SAFE
0x0 0x0 0xffffffffffffffff # out of range
0x0 0x1 SKIP
0x1 0x0 0xffffffffffffffff # out of range
0x1 0x1 SKIP
FTR_HIGHER_OR_ZERO_SAFE
0x0 0x0 SKIP
0x0 0x1 SKIP
0x1 0x0 SKIP
0x1 0x1 SKIP
Thanks,
Ben
>
> return ftr;
> @@ -399,12 +439,15 @@ static void test_reg_set_fail(struct kvm_vcpu *vcpu, uint64_t reg,
> uint8_t shift = ftr_bits->shift;
> uint64_t mask = ftr_bits->mask;
> uint64_t val, old_val, ftr;
> + bool skip;
> int r;
>
> val = vcpu_get_reg(vcpu, reg);
> ftr = (val & mask) >> shift;
>
> - ftr = get_invalid_value(ftr_bits, ftr);
> + ftr = get_invalid_value(ftr_bits, ftr, &skip);
> + if (skip)
> + return;
>
> old_val = val;
> ftr <<= shift;
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox