* Re: [PATCH] docs: fix typos in Documentation/PCI/
From: Bjorn Helgaas @ 2026-04-21 16:28 UTC (permalink / raw)
To: josh ziegler; +Cc: bhelgaas, corbet, skhan, linux-pci, linux-doc, linux-kernel
In-Reply-To: <20260421012059.251492-1-joshziegler76@gmail.com>
On Mon, Apr 20, 2026 at 09:20:59PM -0400, josh ziegler wrote:
> Fix "chose" -> "choose" in pci.rst
> Fix "result an" -> "result in an" in pciebus-howto.rst
>
> Signed-off-by: josh ziegler <joshziegler76@gmail.com>
Applied with Randy's ack to pci/misc for v7.2, thanks!
Updated subject line to match local history:
Documentation: PCI: Fix typos
> ---
> Documentation/PCI/pci.rst | 2 +-
> Documentation/PCI/pciebus-howto.rst | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/PCI/pci.rst b/Documentation/PCI/pci.rst
> index f4d2662871ab..be35e9a1ee75 100644
> --- a/Documentation/PCI/pci.rst
> +++ b/Documentation/PCI/pci.rst
> @@ -338,7 +338,7 @@ the PCI_IRQ_MSI and PCI_IRQ_MSIX flags will fail, so try to always
> specify PCI_IRQ_INTX as well.
>
> Drivers that have different interrupt handlers for MSI/MSI-X and
> -legacy INTx should chose the right one based on the msi_enabled
> +legacy INTx should choose the right one based on the msi_enabled
> and msix_enabled flags in the pci_dev structure after calling
> pci_alloc_irq_vectors.
>
> diff --git a/Documentation/PCI/pciebus-howto.rst b/Documentation/PCI/pciebus-howto.rst
> index 375d9ce171f6..9cc133ccdeec 100644
> --- a/Documentation/PCI/pciebus-howto.rst
> +++ b/Documentation/PCI/pciebus-howto.rst
> @@ -97,7 +97,7 @@ register its service with the PCI Express Port Bus driver (see
> section 5.2.1 & 5.2.2). It is important that a service driver
> initializes the pcie_port_service_driver data structure, included in
> header file /include/linux/pcieport_if.h, before calling these APIs.
> -Failure to do so will result an identity mismatch, which prevents
> +Failure to do so will result in an identity mismatch, which prevents
> the PCI Express Port Bus driver from loading a service driver.
>
> pcie_port_service_register
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH net-deletions] net: remove ax25 and amateur radio (hamradio) subsystem
From: Dan Cross @ 2026-04-21 16:17 UTC (permalink / raw)
To: stephen
Cc: Jakub Kicinski, davem, netdev, edumazet, pabeni, andrew+netdev,
horms, corbet, skhan, federico.vaga, carlos.bilbao, avadhut.naik,
alexs, si.yanteng, dzm91, 2023002089, tsbogend, dsahern,
jani.nikula, mchehab+huawei, gregkh, jirislaby, tytso, herbert,
ebiggers, johannes.berg, geert, pablo, tglx, mashiro.chen, mingo,
dqfext, jreuter, sdf, pkshih, enelsonmoore, mkl, toke, kees,
jlayton, wangliang74, aha310510, takamitz, kuniyu, linux-doc,
linux-mips
In-Reply-To: <20260421065507.2c5e3ba7@phoenix.local>
On Tue, Apr 21, 2026 at 9:55 AM Stephen Hemminger
<stephen@networkplumber.org> wrote:
> On Mon, 20 Apr 2026 19:18:23 -0700
> Jakub Kicinski <kuba@kernel.org> wrote:
> > Remove the amateur radio (AX.25, NET/ROM, ROSE) protocol implementation
> > and all associated hamradio device drivers from the kernel tree.
> > This set of protocols has long been a huge bug/syzbot magnet,
> > and since nobody stepped up to help us deal with the influx
> > of the AI-generated bug reports we need to move it out of tree
> > to protect our sanity.
> >
> > The code is moved to an out-of-tree repo:
> > https://github.com/linux-netdev/mod-orphan
> > if it's cleaned up and reworked there we can accept it back.
>
> It would be good if these protocols could be done in userspace
> or with BPF?
Consensus for a userspace implementation is what folks on linux-hams
seem to be converging on.
The amateur radio protocols are more or less specific to low-speed
links, they are not particularly coupled to anything else that
requires running in the kernel, and the main coupling point (IP over
AX.25) can be implemented via TAP/TUN.
There are several popular packages that already implement AX.25 and
NET/ROM in user-space (for the interested, LinBPQ seems to be the
canonical example). The main missing piece is ROSE, but it is likely
easier to add that to an existing package, or potentially something
brand new, than keep it in the kernel.
There's no compelling reason to keep these protocols in the kernel,
whether in-tree or out-of-tree; at least, one has not been
articulated.
- Dan C.
^ permalink raw reply
* Re: [PATCH 18/23] cpu/hotplug: Add a new cpuhp_offline_cb() API
From: Thomas Gleixner @ 2026-04-21 16:17 UTC (permalink / raw)
To: Waiman Long, Tejun Heo, Johannes Weiner, Michal Koutný,
Jonathan Corbet, Shuah Khan, Catalin Marinas, Will Deacon,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Guenter Roeck, Frederic Weisbecker, Paul E. McKenney,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Anna-Maria Behnsen, Ingo Molnar,
Chen Ridong, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Ben Segall, Mel Gorman, Valentin Schneider,
K Prateek Nayak, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: cgroups, linux-doc, linux-kernel, linux-arm-kernel, linux-hyperv,
linux-hwmon, rcu, netdev, linux-kselftest, Costa Shulyupin,
Qiliang Yuan, Waiman Long
In-Reply-To: <20260421030351.281436-19-longman@redhat.com>
On Mon, Apr 20 2026 at 23:03, Waiman Long wrote:
> Add a new cpuhp_offline_cb() API that allows us to offline a set of
> CPUs one-by-one, run the given callback function and then bring those
> CPUs back online again while inhibiting any concurrent CPU hotplug
> operations from happening.
Please provide a properly structured change log which explains the
context, the problem and the solution in separate paragraphs and this
order. This is not new. It's documented...
> This new API can be used to enable runtime adjustment of nohz_full and
> isolcpus boot command line options. A new cpuhp_offline_cb_mode flag
> is also added to signal that the system is in this offline callback
> transient state so that some hotplug operations can be optimized out
> if we choose to.
We chose nothing.
> +#include <linux/cpumask_types.h>
What for? This header only needs a 'struct cpumask' forward declaration
so that the compiler can handle the pointer argument, no?
> +typedef int (*cpuhp_cb_t)(void *arg);
You couldn't come up with a more generic name for this, right?
> struct device;
>
> extern int lockdep_is_cpus_held(void);
> @@ -29,6 +31,8 @@ void clear_tasks_mm_cpumask(int cpu);
> int remove_cpu(unsigned int cpu);
> int cpu_device_down(struct device *dev);
> void smp_shutdown_nonboot_cpus(unsigned int primary_cpu);
> +int cpuhp_offline_cb(struct cpumask *mask, cpuhp_cb_t func, void *arg);
Ditto.
> +extern bool cpuhp_offline_cb_mode;
Groan. The only users are in the cpusets code which invokes this muck
and should therefore know what's going on, no?
> #else /* CONFIG_HOTPLUG_CPU */
>
> @@ -43,6 +47,11 @@ static inline void cpu_hotplug_disable(void) { }
> static inline void cpu_hotplug_enable(void) { }
> static inline int remove_cpu(unsigned int cpu) { return -EPERM; }
> static inline void smp_shutdown_nonboot_cpus(unsigned int primary_cpu) { }
> +static inline int cpuhp_offline_cb(struct cpumask *mask, cpuhp_cb_t func, void *arg)
> +{
> + return -EPERM;
-EPERM?
> +/**
> + * cpuhp_offline_cb - offline CPUs, invoke callback function & online CPUs afterward
> + * @mask: A mask of CPUs to be taken offline and then online
> + * @func: A callback function to be invoked while the given CPUs are offline
> + * @arg: Argument to be passed back to the callback function
> + *
> + * Return: 0 if successful, an error code otherwise
> + */
> +int cpuhp_offline_cb(struct cpumask *mask, cpuhp_cb_t func, void *arg)
> +{
> + int off_cpu, on_cpu, ret, ret2 = 0;
> +
> + if (WARN_ON_ONCE(cpumask_empty(mask) ||
> + !cpumask_subset(mask, cpu_online_mask)))
> + return -EINVAL;
No line break required. You have 100 characters.
But what's worse is that the access to cpu_online_mask is not protected
against a concurrent CPU hotplug operation.
> +
> + pr_debug("%s: begin (CPU list = %*pbl)\n", __func__, cpumask_pr_args(mask));
Tracing?
> + lock_device_hotplug();
> + cpuhp_offline_cb_mode = true;
> + /*
> + * If all offline operations succeed, off_cpu should become nr_cpu_ids.
> + */
> + for_each_cpu(off_cpu, mask) {
> + ret = device_offline(get_cpu_device(off_cpu));
> + if (unlikely(ret))
> + break;
> + }
> + if (!ret)
> + ret = func(arg);
> +
> + /* Bring previously offline CPUs back online */
> + for_each_cpu(on_cpu, mask) {
> + int retries = 0;
> +
> + if (on_cpu == off_cpu)
> + break;
> +
> +retry:
> + ret2 = device_online(get_cpu_device(on_cpu));
> +
> + /*
> + * With the unlikely event that CPU hotplug is disabled while
> + * this operation is in progress, we will need to wait a bit
> + * for hotplug to hopefully be re-enabled again. If not, print
> + * a warning and return the error.
> + *
> + * cpu_hotplug_disabled is supposed to be accessed while
> + * holding the cpu_add_remove_lock mutex. So we need to
> + * use the data_race() macro to access it here.
> + */
> + while ((ret2 == -EBUSY) && data_race(cpu_hotplug_disabled) &&
> + (++retries <= 5)) {
> + msleep(20);
> + if (!data_race(cpu_hotplug_disabled))
> + goto retry;
> + }
> + if (ret2) {
> + pr_warn("%s: Failed to bring CPU %d back online!\n",
> + __func__, on_cpu);
Provide a proper text and not this silly __func__ thing.
> + break;
> + }
> + }
TBH. This is unreviewable gunk and the whole 'unlikely event that CPU
hotplug is disabled' is just a lazy hack.
All of this can be avoided including this made up callback function.
It's not rocket science to provide:
1) A function which serializes against any other CPU hotplug
related action.
2) A function which brings the CPUs in a given CPU mask down
3) A function which brings the CPUs in a given CPU mask up
4) A function which undoes #1
Yeah I know, it's more work and not convoluted enough. But see below.
That brings me to that other hack namely cpuhp_offline_cb_mode, which
you self described as such in patch 21/23:
> + /*
> + * Hack: In cpuhp_offline_cb_mode, pretend all partitions are empty
> + * to prevent unnecessary partition invalidation.
> + */
> + if (cpuhp_offline_cb_mode)
> + return false;
> +
We are not merging hacks. End of story. But you knew that already, no?
Let's take a step back and see what you really need to achieve:
1) Update tick_nohz_full_mask
2) Update the managed interrupt mask
3) Update CPU sets
Independent of the direction of this update you need to ensure that the
affected functionality keeps working correctly.
You achieve that by bulk offlining the affected CPUs, invoking a magic
callback and then bulk onlining the affected CPUs again, which requires
that ill defined cpuhp_offline_cb_mode hackery and probably some more
hacks all over the place.
You can achieve the same by doing CPU by CPU operations in the right
order without this mode hack, when you establish proper limitations for
this:
At no point in time it's allowed to empty a CPU set or a affected CPU
mask, except when you completely undo the isolation of CPUs.
That can be computed upfront w/o changing anything at all. Once the
validity is established, the update can proceed. Or you can leave it
to user space which can keep the pieces if it gets it wrong.
That's a reasonable limitation as there is absolutely zero justification
to support something like:
housekeeping_cpus = [CPU 0], isolated_cpus = [CPU 1]
---> housekeeping_cpus = [CPU 1], isolated_cpus = [CPU 0]
just because we can with enough horrible hacks.
If you get that out of the way, then a CPU by CPU update becomes the
obvious and simplest solution. The ordering constraints can be computed
in user space upfront and there is no reason to do any of this in the
kernel itself except for an eventual validation step. It might be a tad
slower, but this is all but a hotpath operation.
Just for the record. I suggested exactly this more than a year ago and
it's still the right thing to do.
And of course neither your cover letter nor any of the patches give a
proper rationale why you think that your bulk hackery is better. For the
very simple reason that there is no rationale at all.
This bulk muck is doomed when your ultimate goal is to avoid the stop
machine dance. With a per CPU update it is actually doable without more
ill defined hacks all over the place.
1) Bring down the CPU to CPUHP_AP_SCHED_WAIT_EMPTY, which is the last
state before stop machine is invoked.
At that point:
- no user space thread is running on the CPU anymore
- everything related to this CPU has been shut down or moved
elsewhere
- interrupt managed device queues are quiesced if the CPU was
the last online one in the queue affinity mask. If not the
interrupt might still be affine to the CPU, but there is at
least one other CPU available in the mask.
2) Update the tick NOHZ handover
This can be done without going into stop machine by providing a
hotplug callback right between CPUHP_AP_SMPBOOT_THREADS and
CPUHP_AP_IRQ_AFFINITY_ONLINE.
That's trivial enough to achieve and can work independently of
NOHZ full.
3) Rework the affinity management, so that interrupt affinities can
be reassigned in the CPUHP_AP_IRQ_AFFINITY_ONLINE state.
That needs a lot of thoughts, but there is no real reason why it
can't work.
4) Flip the housekeeping CPU masks in sched_cpu_wait_empty() after
balance_hotplug_wait().
5) Bring the CPU online again.
For #2 and #3 to work you need a separate CPU mask which avoids touching
CPU online mask. For #3 this needs some more work to avoid reassigning the
interrupts once sparse_irq_lock is dropped, but the bulk is achieved
with the separate CPU mask.
No?
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH v2 00/16] fs,x86/resctrl: Add kernel-mode (e.g., PLZA) support to the resctrl subsystem
From: Reinette Chatre @ 2026-04-21 16:15 UTC (permalink / raw)
To: Babu Moger, Moger, Babu, corbet@lwn.net, tony.luck@intel.com,
Dave.Martin@arm.com, james.morse@arm.com, tglx@kernel.org,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com
Cc: skhan@linuxfoundation.org, x86@kernel.org, hpa@zytor.com,
peterz@infradead.org, juri.lelli@redhat.com,
vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
vschneid@redhat.com, kas@kernel.org, rick.p.edgecombe@intel.com,
akpm@linux-foundation.org, pmladek@suse.com,
rdunlap@infradead.org, dapeng1.mi@linux.intel.com,
kees@kernel.org, elver@google.com, paulmck@kernel.org,
lirongqing@baidu.com, safinaskar@gmail.com, fvdl@google.com,
seanjc@google.com, pawan.kumar.gupta@linux.intel.com,
xin@zytor.com, tiala@microsoft.com, chang.seok.bae@intel.com,
Lendacky, Thomas, elena.reshetova@intel.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-coco@lists.linux.dev, kvm@vger.kernel.org,
eranian@google.com, peternewman@google.com
In-Reply-To: <e624f652-f0a6-4926-a0ab-c4486d41eb6d@amd.com>
Hi Babu,
On 4/21/26 8:08 AM, Babu Moger wrote:
> Hi Reinette,
>
> On 4/20/26 22:17, Reinette Chatre wrote:
>> Hi Babu,
>>
>> On 4/20/26 5:40 PM, Moger, Babu wrote:
>>>
>>> We already discussed moving back to the default group on every mode
>>> switch. Doing so here would once again cause extra MSR writes on
>>> each mode transition, which is undesirable.
>>>
>>
>> Needing to avoid extra MSR writes in resctrl is not so absolute. Consider, for
>> example, how resctrl initializes default allocations when a new resource group is
>> created. resctrl aims to initialize with sane defaults and the user is expected to
>> follow with desired allocations.
>>
>> I am not against optimizing, I just want to be careful with such general statements.
>>
>> Considering your proposal in https://lore.kernel.org/lkml/39e0c786-cc35-4555-bfb9-ff7cd758c423@amd.com/:
>>
>> I do not think we should make info/kernel_mode read-only. If I understand correctly
>> doing so would accommodate AMD PLZA but it ignores the discussions on how resctrl could
>> support MPAM ... or do you perhaps have proposal on how MPAM can be supported when considering
>> your proposal? Even if you do not want to consider MPAM - what if the PLZA_PQR register's
>> scope becomes per-CPU in the next version of AMD PLZA?
>>
>> The idea behind info/kernel_mode is that the active mode it identifies indicates which
>> configuration files exist to configure the active mode. Since the mode may not always
>> depend on global configuration, for which info/kernel_mode_assignment was created, but instead
>> rely on per-resource group files, I do not see how resctrl can build on a read-only
>> info/kernel_mode backed by a mode and group change via info/kernel_mode_assignment.
>> Specifically, MPAM support may not use info/kernel_mode_assignment at all.
>> Instead, MPAM may use something like described in https://lore.kernel.org/lkml/aYyxAPdTFejzsE42@e134344.arm.com/
>>
>> Could we perhaps consider dropping info/kernel_mode_assignment entirely for
>> AMD PLZA's global allocations? Similar to what you suggest, the mode and
>> group assignment could be done via the info/kernel_mode file instead?
>>
>> Thinking about this more since the CPUs allocation is global, these could *theoretically*
>> be included also (but see later).
>> This could mean that "kernel_mode_cpus" and "kernel_mode_cpus_list" could be dropped?
>> Although, this may complicate the interface since user space may want a convenient way
>> to modify just CPUs independently from needing to repeat the mode and group every time.
>>
>> Consider, for example:
>>
>> # echo "global_assign_ctrl_assign_mon_per_cpu:group=ctrl1/mon1/;cpus_list=5-8" > info/kernel_mode
>
> This looks reasonable.
>
>>
>> Having named fields (a) makes this extensible, (b) output does not need to be split among files,
>> and (c) "inherit_ctrl_and_mon" can continue to be supported.
>>
>> The named fields could be made optional, if group is omitted then it will become the
>> default resource group, and if cpus/cpus_list is omitted then it will default to all CPUs.
>> This may not be intuitive since a user may expect that not mentioning a field means
>> that the field is left untouched. Have you considered this scenario in your proposal?
>>
>> As an alternative the group could be made a required field and "kernel_mode_cpus"/"kernel_mode_cpuslist"
>> can stay? This may be the simplest approach.
>
> How about keeping a single option to update the CPUs using
> kernel_mode_cpus / kernel_mode_cpuslist within the group?
>
> Should we consider removing the per‑CPU extension altogether? By
> default, the mode already applies to all online CPUs, and any
> per‑CPU requirements can be handled within the group using
> kernel_mode_cpus / kernel_mode_cpuslist.
It sounds like we are saying the same thing?
When considering all the sharp corners I agree that keeping kernel_mode_cpus/kernel_mode_cpuslist
seems most user friendly. When doing so there is no need to include CPU assignment in the global
files.
>
> # echo "global_assign_ctrl_assign_mon_per_cpu:group=ctrl1/mon1/
>
> Why do we still need to keep the "inherit_ctrl_and_mon"? By default all the groups in the system falls in this category it is not plza enabled group.
>
>
> System boots up with following options if PLZA is supported.
>
> # cat info/kernel_mode
> global_assign_ctrl_assign_mon_per_cpu
> global_assign_ctrl_inherit_mon_per_cpu
>
> No groups are associated with kernel mode at this point.
To me it seems useful to be clear to user space on what the current mode is. If I understand correctly
above default scenario essentially means "inherit_ctrl_and_mon" but instead of adding it to this file
we will need to add documentation that describes to user space how this file should be interpreted.
It seems easier to me to just be clear via info/kernel_mode itself on what the current active mode is?
I think something like below will be more intuitive and not need much additional
documentation to understand (I am just adding the "uninitialized" as an example to match text
printed in schemata file during pseudo-locking ... even if there is a group named "uninitialized"
the lack of "/" could be used to make it clear what this means?):
# cat info/kernel_mode
[inherit_ctrl_and_mon]
global_assign_ctrl_assign_mon_per_cpu:group=uninitialized
global_assign_ctrl_inherit_mon_per_cpu:group=uninitialized
I also think an interface like this would be simpler for user space to use as it (user space) switches
between PLZA capable and non-PLZA capable systems since user space need not associate existence of
the file with some kernel mode state in addition to actual content of the file when it does exist.
I assumed that info/kernel_mode can just always be made visible and not depend on PLZA
capable hardware. This means that on Intel and Arm this file can show:
# cat info/kernel_mode
[inherit_ctrl_and_mon]
For Intel this is accurate and also for Arm if I interpret the Arm implementation correctly
(see mpam_thread_switch()) in https://lore.kernel.org/lkml/20260313144617.3420416-7-ben.horgan@arm.com/
>
> # echo "global_assign_ctrl_assign_mon_per_cpu:group=ctrl1/mon1/" > info/kernel_mode
>
> # cat info/kernel_mode
> global_assign_ctrl_assign_mon_per_cpu:group=ctrl1/mon1/
> global_assign_ctrl_inherit_mon_per_cpu
>
>
> # echo "global_assign_ctrl_inherit_mon_per_cpu:group=//" > info/kernel_mode
>
>
> # cat info/kernel_mode
> global_assign_ctrl_assign_mon_per_cpu
> global_assign_ctrl_inherit_mon_per_cpu:group=//
>
>
> How does this look?
In addition to above I think it will be helpful to add a clear indication to user
space on what the current active mode is, for example, via the [] characters.
Reinette
^ permalink raw reply
* Re: [PATCH v2 00/16] fs,x86/resctrl: Add kernel-mode (e.g., PLZA) support to the resctrl subsystem
From: Reinette Chatre @ 2026-04-21 16:12 UTC (permalink / raw)
To: Luck, Tony
Cc: Moger, Babu, Babu Moger, corbet@lwn.net, Dave.Martin@arm.com,
james.morse@arm.com, tglx@kernel.org, mingo@redhat.com,
bp@alien8.de, dave.hansen@linux.intel.com,
skhan@linuxfoundation.org, x86@kernel.org, hpa@zytor.com,
peterz@infradead.org, juri.lelli@redhat.com,
vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
vschneid@redhat.com, kas@kernel.org, rick.p.edgecombe@intel.com,
akpm@linux-foundation.org, pmladek@suse.com,
rdunlap@infradead.org, dapeng1.mi@linux.intel.com,
kees@kernel.org, elver@google.com, paulmck@kernel.org,
lirongqing@baidu.com, safinaskar@gmail.com, fvdl@google.com,
seanjc@google.com, pawan.kumar.gupta@linux.intel.com,
xin@zytor.com, tiala@microsoft.com, chang.seok.bae@intel.com,
Lendacky, Thomas, elena.reshetova@intel.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-coco@lists.linux.dev, kvm@vger.kernel.org,
eranian@google.com, peternewman@google.com
In-Reply-To: <aeeTnL3aisKgPJG-@agluck-desk3>
Hi Tony,
On 4/21/26 8:11 AM, Luck, Tony wrote:
> On Mon, Apr 20, 2026 at 05:21:50PM -0700, Reinette Chatre wrote:
>> On 4/20/26 5:03 PM, Luck, Tony wrote:
...
>>>> # echo "global_assign_ctrl_inherit_mon_per_cpu" > info/kernel_mode
>>>
>>> This mode needs a CLOSID for PLZA, but doesn't need an RMID.
>>>
>>>> At this stage, only the kernel mode is being changed. However, there is no
>>>> way to know which control group the user intends to assign to kernel mode.
>>>> All we know here is the selected mode.
>>>>
>>>> After this operation, the info/kernel_mode_assignment interface should
>>>> become visible. But the question is: what should it contain or point to at
>>>> this moment?
>>>>
>>>> # cat info/kernel_mode_assignment
>>>> ??
>>>>
>>>> Next operation: Assign the group
>>>>
>>>> # echo "ctrl1//" > info/kernel_mode_assignment
>>>
>>> Now ring0 code is using the CLOSID from the ctrl1 group.
>>
>> ... and user space tasks also continue to use the CLOSID from the
>> ctrl1 group.
>> It is up to user space to decide if a group is dedicated to kernel
>> mode or not. resctrl does not enforce it.
>>
>>>
>>> But the RMID for this group isn't used.
>>
>> RMID is still used by user mode that maintains existing behavior concerning
>> this group when considering its tasks/cpus/cpus_list files. RMID assigned to this
>> group is just not used for kernel mode.
>
> True, that the RMID is used if the user makes assignments using tasks/cpus/cpus_list
> for the ctrl1 group. But they might not do that.
>
>>
>>>
>>> Are we OK with "wasting" an RMID in this way?
>>
>> How do you see this RMID as "wasted"?
>
> Suppose the user doesn't assign tasks to the ctrl1 group?
>
> Perhaps the resources they want to make available to the kernel do
> not exactly match with resources that they want to provide to any
> tasks. In this case the RMID is wasted.
Under these circumstances, yes, the RMID will not be used.
A related scenario (when considering what may happen if user does not assign tasks to
the ctrl1 group) is when user space disables PLZA on all CPUs in a domain then the CLOSID
(as well as RMID since this is irrespective of rmid_en mode) associated with kernel_mode
will be unused in that domain.
Reinette
^ permalink raw reply
* Re: [PATCH v2 14/20] drm/mode-config: Create drm_mode_config_create_state()
From: Dmitry Baryshkov @ 2026-04-21 16:02 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Jyri Sarha, Tomi Valkeinen,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260320-drm-mode-config-init-v2-14-c63f1134e76c@kernel.org>
On Fri, Mar 20, 2026 at 05:27:21PM +0100, Maxime Ripard wrote:
> drm_mode_config_reset() can be used to create the initial state, but
> also to return to the initial state, when doing a suspend/resume cycle
> for example.
>
> It also affects both the software and the hardware, and drivers can
> choose to reset the hardware as well. Most will just create an empty
> state and the synchronisation between hardware and software states will
> effectively be done when the first commit is done.
>
> That dual role can be harmful, since some objects do need to be
> initialized but also need to be preserved across a suspend/resume cycle.
> drm_private_obj are such objects for example.
>
> Thus, let's create another helper for drivers to call to initialize
> their state when the driver is loaded, so we can make
> drm_mode_config_reset() only about handling suspend/resume and similar.
>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/drm_atomic.c | 12 +++++-
> drivers/gpu/drm/drm_mode_config.c | 87 +++++++++++++++++++++++++++++++++++++++
> include/drm/drm_mode_config.h | 1 +
> 3 files changed, 98 insertions(+), 2 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 10/20] drm/crtc: Add new atomic_create_state callback
From: Dmitry Baryshkov @ 2026-04-21 16:01 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Jyri Sarha, Tomi Valkeinen,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260320-drm-mode-config-init-v2-10-c63f1134e76c@kernel.org>
On Fri, Mar 20, 2026 at 05:27:17PM +0100, Maxime Ripard wrote:
> Commit 47b5ac7daa46 ("drm/atomic: Add new atomic_create_state callback
> to drm_private_obj") introduced a new pattern for allocating drm object
> states.
>
> Instead of relying on the reset() callback, it created a new
> atomic_create_state hook. This is helpful because reset is a bit
> overloaded: it's used to create the initial software tate, reset it, but
> also reset the hardware.
>
> It can also be used either at probe time, to create the initial state
> and possibly reset the hardware to an expected default, but also during
> suspend/resume.
>
> Both these cases come with different expectations too: during the
> initialization, we want to initialize all states, but during
> suspend/resume, drm_private_states for example are expected to be kept
> around.
>
> And reset() isn't fallible, which makes it harder to handle
> initialization errors properly.
>
> And this is only really relevant for some drivers, since all the helpers
> for reset only create a new state, and don't touch the hardware at all.
>
> It was thus decided to create a new hook that would allocate and
> initialize a pristine state without any side effect:
> atomic_create_state to untangle a bit some of it, and to separate the
> initialization with the actual reset one might need during a
> suspend/resume.
>
> Let's continue the transition to the new pattern with crtcs.
>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 47 +++++++++++++++++++++++++++++++
> drivers/gpu/drm/drm_mode_config.c | 21 +++++++++++++-
> include/drm/drm_atomic_state_helper.h | 4 +++
> include/drm/drm_crtc.h | 13 +++++++++
> 4 files changed, 84 insertions(+), 1 deletion(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 16/20] drm/atomic: Drop private obj state allocation
From: Dmitry Baryshkov @ 2026-04-21 15:59 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Jyri Sarha, Tomi Valkeinen,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi, Laurent Pinchart
In-Reply-To: <20260320-drm-mode-config-init-v2-16-c63f1134e76c@kernel.org>
On Fri, Mar 20, 2026 at 05:27:23PM +0100, Maxime Ripard wrote:
> Now that drm_dev_register() calls drm_mode_config_create_state() for
> every modeset driver, the private obj states will be initialized at
> driver registration automatically if they haven't already.
>
> Thus, the explicit initial allocation we have in
> drm_atomic_private_obj_init() is now redundant, and we can remove it.
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/drm_atomic.c | 7 -------
> 1 file changed, 7 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 20/20] drm/bridge_connector: Convert to atomic_create_state
From: Dmitry Baryshkov @ 2026-04-21 15:58 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Jyri Sarha, Tomi Valkeinen,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi, Laurent Pinchart
In-Reply-To: <20260320-drm-mode-config-init-v2-20-c63f1134e76c@kernel.org>
On Fri, Mar 20, 2026 at 05:27:27PM +0100, Maxime Ripard wrote:
> The connector created by drm_bridge_connector only initializes a
> pristine state in reset, which is equivalent to that atomic_create_state
> would expect. Let's convert to it.
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/display/drm_bridge_connector.c | 15 +++++++++++----
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 15/20] drm/drv: Call drm_mode_config_create_state() by default
From: Dmitry Baryshkov @ 2026-04-21 15:57 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: Maxime Ripard, Maarten Lankhorst, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Jyri Sarha, Tomi Valkeinen,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <dd39f423-1598-4749-8c95-98b8daf69680@suse.de>
On Tue, Apr 21, 2026 at 05:33:12PM +0200, Thomas Zimmermann wrote:
>
>
> Am 21.04.26 um 15:38 schrieb Thomas Zimmermann:
> > Hi
> >
> > Am 20.03.26 um 17:27 schrieb Maxime Ripard:
> > > Almost all drivers, and our documented skeleton, call
> > > drm_mode_config_reset() prior to calling drm_dev_register() to
> > > initialize its DRM object states.
> > >
> > > Now that we have drm_mode_config_create_state() to create that initial
> > > state if it doesn't exist, we can call it directly in
> > > drm_dev_register(). That way, we know that the initial atomic state will
> > > always be allocated without any boilerplate.
> > >
> > > Signed-off-by: Maxime Ripard <mripard@kernel.org>
> > > ---
> > > drivers/gpu/drm/drm_drv.c | 4 ++++
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > > index 2915118436ce8a6640cfb0c59936031990727ed1..820106d56ab399a39cac56d98662b5ddbcae8ded
> > > 100644
> > > --- a/drivers/gpu/drm/drm_drv.c
> > > +++ b/drivers/gpu/drm/drm_drv.c
> > > @@ -1097,10 +1097,14 @@ int drm_dev_register(struct drm_device *dev,
> > > unsigned long flags)
> > > if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> > > ret = drm_modeset_register_all(dev);
> > > if (ret)
> > > goto err_unload;
> > > +
> > > + ret = drm_mode_config_create_state(dev);
> > > + if (ret)
> > > + goto err_unload;
> >
> > Way too late. Lets rather go through drivers and call this where they
> > currently call drm_mode_config_reset() for initialization. This can be a
> > single-patch mass conversion IMHO.
>
> On a second thought, can't we modify the suspend code and leave the reset
> as-is for now? I'd still be interested to use reset as a means of
> initializing the hardware or loading state on probe. So keeping the _reset()
> calls in place might be helpful for that.
But isn't it the expected behaviour? The driver can reset(), but if
it didn't, the default would be to create empty working state. In the
end, the drivers also can call this function to create the state, don't
they (and then perform the readout logic)?
>
> What's the long-term plan here?
>
> Best regards
> Thomas
>
> >
> > Best regards
> > Thomas
> >
> > > }
> > > drm_panic_register(dev);
> > > drm_client_sysrq_register(dev);
> > > DRM_INFO("Initialized %s %d.%d.%d for %s on minor %d\n",
> > >
> >
>
> --
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
> GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
>
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 13/20] drm/connector: Add new atomic_create_state callback
From: Dmitry Baryshkov @ 2026-04-21 15:52 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Jyri Sarha, Tomi Valkeinen,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260320-drm-mode-config-init-v2-13-c63f1134e76c@kernel.org>
On Fri, Mar 20, 2026 at 05:27:20PM +0100, Maxime Ripard wrote:
> Commit 47b5ac7daa46 ("drm/atomic: Add new atomic_create_state callback
> to drm_private_obj") introduced a new pattern for allocating drm object
> states.
>
> Instead of relying on the reset() callback, it created a new
> atomic_create_state hook. This is helpful because reset is a bit
> overloaded: it's used to create the initial software tate, reset it, but
> also reset the hardware.
>
> It can also be used either at probe time, to create the initial state
> and possibly reset the hardware to an expected default, but also during
> suspend/resume.
>
> Both these cases come with different expectations too: during the
> initialization, we want to initialize all states, but during
> suspend/resume, drm_private_states for example are expected to be kept
> around.
>
> And reset() isn't fallible, which makes it harder to handle
> initialization errors properly.
>
> And this is only really relevant for some drivers, since all the helpers
> for reset only create a new state, and don't touch the hardware at all.
>
> It was thus decided to create a new hook that would allocate and
> initialize a pristine state without any side effect:
> atomic_create_state to untangle a bit some of it, and to separate the
> initialization with the actual reset one might need during a
> suspend/resume.
>
> Let's continue the transition to the new pattern with connectors.
>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 45 +++++++++++++++++++++++++++++++
> drivers/gpu/drm/drm_mode_config.c | 21 ++++++++++++++-
> include/drm/drm_atomic_state_helper.h | 4 +++
> include/drm/drm_connector.h | 13 +++++++++
> 4 files changed, 82 insertions(+), 1 deletion(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 11/20] drm/atomic-state-helper: Rename __drm_atomic_helper_connector_state_reset()
From: Dmitry Baryshkov @ 2026-04-21 15:50 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Jyri Sarha, Tomi Valkeinen,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260320-drm-mode-config-init-v2-11-c63f1134e76c@kernel.org>
On Fri, Mar 20, 2026 at 05:27:18PM +0100, Maxime Ripard wrote:
> __drm_atomic_helper_connector_state_reset() is used to initialize a
> newly allocated drm_connector_state, and is being typically called by
> the drm_connector_funcs.reset implementation.
>
> Since we want to consolidate DRM objects state allocation around the
> atomic_create_state callback that will only allocate and initialize a
> new drm_connector_state instance, we will need to call
> __drm_atomic_helper_connector_state_reset() from both the reset and
> atomic_create hooks.
>
> To avoid any confusion, we can thus rename
> __drm_atomic_helper_connector_state_reset() to
> __drm_atomic_helper_connector_state_init().
>
> Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 10 +++++-----
> include/drm/drm_atomic_state_helper.h | 2 +-
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 12/20] drm/hdmi: Rename __drm_atomic_helper_connector_hdmi_reset()
From: Dmitry Baryshkov @ 2026-04-21 15:50 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Jyri Sarha, Tomi Valkeinen,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260320-drm-mode-config-init-v2-12-c63f1134e76c@kernel.org>
On Fri, Mar 20, 2026 at 05:27:19PM +0100, Maxime Ripard wrote:
> __drm_atomic_helper_connector_hdmi_reset() is typically used to
> initialize a newly allocated drm_connector_state when the connector is
> using the HDMI helpers, and is being called by the
> drm_connector_funcs.reset implementation.
>
> Since we want to consolidate DRM objects state allocation around the
> atomic_create_state callback that will only allocate and initialize a
> new drm_connector_state instance, we will need to call
> __drm_atomic_helper_connector_hdmi_reset() from both the reset and
> atomic_create hooks.
>
> To avoid any confusion, we can thus rename
> __drm_atomic_helper_connector_hdmi_reset() to
> __drm_atomic_helper_connector_hdmi_state_init().
>
> Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/display/drm_bridge_connector.c | 4 ++--
> drivers/gpu/drm/display/drm_hdmi_state_helper.c | 14 ++++++++------
> drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 2 +-
> drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c | 2 +-
> drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
> include/drm/display/drm_hdmi_state_helper.h | 4 ++--
> 6 files changed, 15 insertions(+), 13 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 15/20] drm/drv: Call drm_mode_config_create_state() by default
From: Thomas Zimmermann @ 2026-04-21 15:33 UTC (permalink / raw)
To: Maxime Ripard, Maarten Lankhorst, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Simon Ser,
Harry Wentland, Melissa Wen, Sebastian Wick, Alex Hung,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Chen-Yu Tsai, Samuel Holland, Dave Stevenson, Maíra Canal,
Raspberry Pi Kernel Maintenance
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <79cc30d5-80b5-4d87-a3ad-36d6fad98853@suse.de>
Am 21.04.26 um 15:38 schrieb Thomas Zimmermann:
> Hi
>
> Am 20.03.26 um 17:27 schrieb Maxime Ripard:
>> Almost all drivers, and our documented skeleton, call
>> drm_mode_config_reset() prior to calling drm_dev_register() to
>> initialize its DRM object states.
>>
>> Now that we have drm_mode_config_create_state() to create that initial
>> state if it doesn't exist, we can call it directly in
>> drm_dev_register(). That way, we know that the initial atomic state will
>> always be allocated without any boilerplate.
>>
>> Signed-off-by: Maxime Ripard <mripard@kernel.org>
>> ---
>> drivers/gpu/drm/drm_drv.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>> index
>> 2915118436ce8a6640cfb0c59936031990727ed1..820106d56ab399a39cac56d98662b5ddbcae8ded
>> 100644
>> --- a/drivers/gpu/drm/drm_drv.c
>> +++ b/drivers/gpu/drm/drm_drv.c
>> @@ -1097,10 +1097,14 @@ int drm_dev_register(struct drm_device *dev,
>> unsigned long flags)
>> if (drm_core_check_feature(dev, DRIVER_MODESET)) {
>> ret = drm_modeset_register_all(dev);
>> if (ret)
>> goto err_unload;
>> +
>> + ret = drm_mode_config_create_state(dev);
>> + if (ret)
>> + goto err_unload;
>
> Way too late. Lets rather go through drivers and call this where they
> currently call drm_mode_config_reset() for initialization. This can be
> a single-patch mass conversion IMHO.
On a second thought, can't we modify the suspend code and leave the
reset as-is for now? I'd still be interested to use reset as a means of
initializing the hardware or loading state on probe. So keeping the
_reset() calls in place might be helpful for that.
What's the long-term plan here?
Best regards
Thomas
>
> Best regards
> Thomas
>
>> }
>> drm_panic_register(dev);
>> drm_client_sysrq_register(dev);
>> DRM_INFO("Initialized %s %d.%d.%d for %s on minor %d\n",
>>
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v2 1/2] kernel: param: handle NULL module_kset in lookup_or_create_module_kobject()
From: Greg Kroah-Hartman @ 2026-04-21 15:20 UTC (permalink / raw)
To: Shashank Balaji
Cc: Kay Sievers, Rafael J. Wysocki, Danilo Krummrich,
Suzuki K Poulose, Mike Leach, James Clark, Alexander Shishkin,
Maxime Coquelin, Alexandre Torgue, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Trevor Gross, Richard Cochran, Jonathan Corbet,
Shuah Khan, Rahul Bukte, Daniel Palmer, Tim Bird, linux-kernel,
driver-core, coresight, linux-arm-kernel, rust-for-linux,
linux-doc
In-Reply-To: <aeeQ5x1uMKT6cyxp@JPC00244420>
On Tue, Apr 21, 2026 at 11:59:51PM +0900, Shashank Balaji wrote:
> Hi Greg,
>
> Thanks for the quick feedback!
>
> On Tue, Apr 21, 2026 at 08:27:10AM +0200, Greg Kroah-Hartman wrote:
> > On Tue, Apr 21, 2026 at 03:02:34PM +0900, Shashank Balaji wrote:
> > > module_kset is initialized in a subsys_initcall. If a built-in driver tries to
> > > register before subsys_initcall with its struct device_driver's mod_name set,
> > > then a null module_kset is dereferenced via this call trace:
> > >
> > > [ 0.095865] Call trace:
> > > [ 0.095999] _raw_spin_lock+0x4c/0x6c (P)
> > > [ 0.096150] kset_find_obj+0x24/0x104
> > > [ 0.096209] lookup_or_create_module_kobject+0x2c/0xd8
> > > [ 0.096274] module_add_driver+0xd4/0x138
> > > [ 0.096328] bus_add_driver+0x16c/0x268
> > > [ 0.096380] driver_register+0x68/0x100
> > > [ 0.096428] __platform_driver_register+0x24/0x30
> > > [ 0.096486] tegra194_cbb_init+0x24/0x30
> > > [ 0.096540] do_one_initcall+0xdc/0x250
> > > [ 0.096608] do_initcall_level+0x9c/0xd0
> > > [ 0.096660] do_initcalls+0x54/0x94
> > > [ 0.096706] do_basic_setup+0x20/0x2c
> > > [ 0.096753] kernel_init_freeable+0xc8/0x154
> > > [ 0.096807] kernel_init+0x20/0x1a0
> > > [ 0.096851] ret_from_fork+0x10/0x20
> > >
> > > So, return null in lookup_or_create_module_kobject() if module_kset is null.
> > > Existing callers handle null already.
> > >
> > > Fixes: f30c53a873d0 ("MODULES: add the module name for built in kernel drivers")
> >
> > This isn't a bugfix.
>
> I'll drop it in the next version.
>
> > > Co-developed-by: Rahul Bukte <rahul.bukte@sony.com>
> > > Signed-off-by: Rahul Bukte <rahul.bukte@sony.com>
> > > Signed-off-by: Shashank Balaji <shashank.mahadasyam@sony.com>
> > > ---
> > > This bug is triggered by the next patch on arm64 defconfig: tegra194-cbb tries
> > > to register from a pure_initcall, and with the next patch adding mod_name, this
> > > null deref is hit.
> >
> > So this isn't a bug, it's a "don't do that" type of thing :)
> >
> > > ---
> > > kernel/params.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/kernel/params.c b/kernel/params.c
> > > index 74d620bc2521..881c7328c059 100644
> > > --- a/kernel/params.c
> > > +++ b/kernel/params.c
> > > @@ -752,6 +752,9 @@ lookup_or_create_module_kobject(const char *name)
> > > struct kobject *kobj;
> > > int err;
> > >
> > > + if (!module_kset)
> > > + return NULL;
> >
> > Are you sure that making this change is going to be ok?
> > mod_sysfs_init() should have been called first as the module has to be
> > created before it can be looked up.
> >
> > As you are wanting "built in" drivers to show up here, you are going to
> > beat the call to param_sysfs_init(), so don't do that. Make sure that
> > the drivers are NOT called before then.
>
> The reason lookup_or_create_module_kobject() can be reached with module_kset == NULL
> is that some platform drivers register before subsys_initcall: tegra194_cbb and
> tegra234_cbb at pure_initcall, plus roughly 375 others at core_initcall/arch_initcall
> (208 arch, 154 core, plus 2 pure and 13 _sync variants). These are dominated by
> pinctrl, clk, interconnect, gpio, and mailbox drivers across six SoC vendor trees
> (Qualcomm, MediaTek, Freescale, Samsung, Tegra, HiSilicon).
That's not good, everyone wants to be first. It's amazing it works at
all sometimes...
> Given that, three ways forward:
>
> 1. Move module_kset creation out of param_sysfs_init() (currently
> subsys_initcall) and call it directly from do_basic_setup()
> before do_initcalls(). This is the cleanest fix from a
> correctness angle: every initcall level sees a live
> module_kset. But it touches init/main.c and kernel/params.c,
> crosses two subsystem trees. I haven't fully audited
> dependencies at do_basic_setup() time.
That's one way, OR dynamically create the kset the first time it is
asked for.
> 2. Demote the ~377 early-initcall platform drivers to
> subsys_initcall or later. Impractical at scale given coordination
> across six vendor trees, and many of these levels seem to be
> architecturally required.
Ick, yeah, that is sure to be a nightmare as there will be regressions.
> 3. (This patch) Guard lookup_or_create_module_kobject() against
> NULL module_kset. Drivers registered before subsys_initcall
> don't get the /sys/.../module symlink, but they don't get it
> today either (drv->mod_name is NULL pre-patch, so the
> else-if (drv->mod_name) branch in module_add_driver() isn't
> taken). Verified on arm64: /sys/module/tegra194_cbb/ does not
> exist on a booted defconfig with or without my series. The
> guard preserves that exact state while letting the
> device_initcall majority get their symlinks as designed.
THat's going to confuse people as to why some have the link and others
do not. How about moving it earlier OR creating it dynamically when
first needed?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] docs/mm: clarify that we are not looking for LLM generated content
From: Zi Yan @ 2026-04-21 15:15 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: linux-doc, Andrew Morton, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Jonathan Corbet, Shuah Khan, Matthew Wilcox, Harry Yoo, linux-mm,
linux-kernel
In-Reply-To: <20260420-llmdoc-v1-1-47d2091177c4@kernel.org>
On 20 Apr 2026, at 17:03, David Hildenbrand (Arm) wrote:
> Let's make it clear that we are not looking for LLM generated content
> from contributors not familiar with the details of MM, as it shifts the
> real work onto reviewers.
>
> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
> ---
> Documentation/mm/index.rst | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
Acked-by: Zi Yan <ziy@nvidia.com>
>
> diff --git a/Documentation/mm/index.rst b/Documentation/mm/index.rst
> index 7aa2a8886908..13a79f5d092c 100644
> --- a/Documentation/mm/index.rst
> +++ b/Documentation/mm/index.rst
> @@ -7,6 +7,19 @@ of Linux. If you are looking for advice on simply allocating memory,
> see the :ref:`memory_allocation`. For controlling and tuning guides,
> see the :doc:`admin guide <../admin-guide/mm/index>`.
>
> +.. note::
> +
> + Unfortunately, parts of this guide are still incomplete or missing.
> + While we appreciate contributions, documentation in this area is hard
> + to get right and requires a lot of attention to detail. New contributors
> + should reach out to the relevant maintainers early.
> +
> + This guide is expected to reflect reality, which requires contributors
> + to have a detailed understanding. Documentation generated with LLMs
> + by contributors unfamiliar with these details shifts the real work onto
> + reviewers, which is why such contributions will be rejected without
> + further comment.
> +
> .. toctree::
> :maxdepth: 1
>
>
> ---
> base-commit: da6b5aae84beb0917ecb0c9fbc71169d145397ff
> change-id: 20260420-llmdoc-21bf5fadbd6f
>
> Best regards,
> --
> David Hildenbrand (Arm) <david@kernel.org>
Best Regards,
Yan, Zi
^ permalink raw reply
* Re: [PATCH] Documentation: coding-assistants: add optional Acted-By: trailer
From: Konstantin Ryabitsev @ 2026-04-21 15:14 UTC (permalink / raw)
To: Blake Morrison
Cc: Jonathan Corbet, Shuah Khan, workflows, linux-doc, linux-kernel
In-Reply-To: <20260420142741.3187814-1-blake@truealter.com>
On Mon, Apr 20, 2026 at 02:27:46PM +0000, Blake Morrison wrote:
> The existing policy correctly separates AI tool attribution
> (Assisted-by:) from legal accountability (Signed-off-by:). In practice,
> contributors increasingly work across pseudonymous and legal-name
> contexts, and a third slot -- identifying the human sovereign identity
> under which the work was performed -- lets downstream tooling (CI,
> provenance trackers, identity systems) bind a commit to a stable handle
> without disturbing the DCO.
>
> Add Acted-By: as an optional, informational companion trailer. It does
> not replace Signed-off-by:, does not change DCO requirements, and does
> not mandate any format; the out-of-tree
> draft-morrison-identity-attributed-commits defines one such scheme, but
> contributors are free to use any handle form they prefer.
This is fairly orthogonal to what LF is already attempting to do with OpenVTC
(https://github.com/OpenVTC). I'm giving this a NACK for now, not because I'm
trying to stifle this work, but because it's going at it from the wrong angle.
The "Acted-by" trailer is clearly intended to be a field for a cryptographic
hash, not for a name/email combo.
As such, it will most likely never be accepted by the kernel community for the
same reason the community rejected the Change-ID trailer -- it's an obscure
string of characters that requires specialized tooling to parse.
Reading the IETF proposal, this is just one of the trailers proposed, as the
following are also mentioned in the draft:
1. Acted-By:
2. Executed-By:
3. Drafted-With:
4. Identity-Signature:
5. Identity-Key-Id:
6. Identity-Anchor:
I see that they need to be "optionally provided" but I can guarantee you that
a maintainer that sees a patch submission with a slew of trailers like that
will reject it (and you will get an earful from Linus).
I recommend that instead of starting by introducing a new trailer on the kernel
list, you send your overall scheme proposal to the git list instead. Some of
the claims in the draft are questionable (e.g. that tree hashes survive
rebase or cherry-pick operations), and are specifically suspect within the
context of the kernel's patch-based workflow. A tree-hash for a patch created
by the submitter will almost certainly become invalid when the maintainer runs
"git am" on their series, so the proposed scheme will never really work for
the kernel, because the vast majority of cryptographic hashes will never
validate.
So, NACK for now, and I do recommend you start on the git list instead.
-K
^ permalink raw reply
* Re: [PATCH v2 00/16] fs,x86/resctrl: Add kernel-mode (e.g., PLZA) support to the resctrl subsystem
From: Luck, Tony @ 2026-04-21 15:11 UTC (permalink / raw)
To: Reinette Chatre
Cc: Moger, Babu, Babu Moger, corbet@lwn.net, Dave.Martin@arm.com,
james.morse@arm.com, tglx@kernel.org, mingo@redhat.com,
bp@alien8.de, dave.hansen@linux.intel.com,
skhan@linuxfoundation.org, x86@kernel.org, hpa@zytor.com,
peterz@infradead.org, juri.lelli@redhat.com,
vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
vschneid@redhat.com, kas@kernel.org, rick.p.edgecombe@intel.com,
akpm@linux-foundation.org, pmladek@suse.com,
rdunlap@infradead.org, dapeng1.mi@linux.intel.com,
kees@kernel.org, elver@google.com, paulmck@kernel.org,
lirongqing@baidu.com, safinaskar@gmail.com, fvdl@google.com,
seanjc@google.com, pawan.kumar.gupta@linux.intel.com,
xin@zytor.com, tiala@microsoft.com, chang.seok.bae@intel.com,
Lendacky, Thomas, elena.reshetova@intel.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-coco@lists.linux.dev, kvm@vger.kernel.org,
eranian@google.com, peternewman@google.com
In-Reply-To: <58b8fe0c-80f6-4ba2-abbe-90d0ceee6daa@intel.com>
On Mon, Apr 20, 2026 at 05:21:50PM -0700, Reinette Chatre wrote:
> Hi Tony,
>
> On 4/20/26 5:03 PM, Luck, Tony wrote:
> >> The system boots with these default settings:
> >>
> >> # cat info/kernel_mode
> >> [inherit_ctrl_and_mon]
> >> global_assign_ctrl_assign_mon_per_cpu
> >> global_assign_ctrl_inherit_mon_per_cpu
> >>
> >>
> >> At this point, the interface info/kernel_mode_assignment is not visible.
> >>
> >> Next, lets create a new control group:
> >>
> >> # mkdir ctrl1
> >
> > This allocates a CLOSID and an RMID for this group.
> >
> >> We want to designate this group as the new kernel-mode group.
> >>
> >> First operation: Change the mode:
> >>
> >> # echo "global_assign_ctrl_inherit_mon_per_cpu" > info/kernel_mode
> >
> > This mode needs a CLOSID for PLZA, but doesn't need an RMID.
> >
> >> At this stage, only the kernel mode is being changed. However, there is no
> >> way to know which control group the user intends to assign to kernel mode.
> >> All we know here is the selected mode.
> >>
> >> After this operation, the info/kernel_mode_assignment interface should
> >> become visible. But the question is: what should it contain or point to at
> >> this moment?
> >>
> >> # cat info/kernel_mode_assignment
> >> ??
> >>
> >> Next operation: Assign the group
> >>
> >> # echo "ctrl1//" > info/kernel_mode_assignment
> >
> > Now ring0 code is using the CLOSID from the ctrl1 group.
>
> ... and user space tasks also continue to use the CLOSID from the
> ctrl1 group.
> It is up to user space to decide if a group is dedicated to kernel
> mode or not. resctrl does not enforce it.
>
> >
> > But the RMID for this group isn't used.
>
> RMID is still used by user mode that maintains existing behavior concerning
> this group when considering its tasks/cpus/cpus_list files. RMID assigned to this
> group is just not used for kernel mode.
True, that the RMID is used if the user makes assignments using tasks/cpus/cpus_list
for the ctrl1 group. But they might not do that.
>
> >
> > Are we OK with "wasting" an RMID in this way?
>
> How do you see this RMID as "wasted"?
Suppose the user doesn't assign tasks to the ctrl1 group?
Perhaps the resources they want to make available to the kernel do
not exactly match with resources that they want to provide to any
tasks. In this case the RMID is wasted.
> >
> > Maybe it doesn't matter too much for AMD as you would just
> > avoid assigning any counters to this group. But should Intel
> > get around to doing PLZA-like functionality, that's a real
> > loss of an RMID that might be useful elsewhere.
>
> Reinette
-Tony
^ permalink raw reply
* Re: [PATCH v2 1/2] kernel: param: handle NULL module_kset in lookup_or_create_module_kobject()
From: Shashank Balaji @ 2026-04-21 14:59 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Kay Sievers, Rafael J. Wysocki, Danilo Krummrich,
Suzuki K Poulose, Mike Leach, James Clark, Alexander Shishkin,
Maxime Coquelin, Alexandre Torgue, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Trevor Gross, Richard Cochran, Jonathan Corbet,
Shuah Khan, Rahul Bukte, Daniel Palmer, Tim Bird, linux-kernel,
driver-core, coresight, linux-arm-kernel, rust-for-linux,
linux-doc
In-Reply-To: <2026042126-majesty-skyline-b76f@gregkh>
Hi Greg,
Thanks for the quick feedback!
On Tue, Apr 21, 2026 at 08:27:10AM +0200, Greg Kroah-Hartman wrote:
> On Tue, Apr 21, 2026 at 03:02:34PM +0900, Shashank Balaji wrote:
> > module_kset is initialized in a subsys_initcall. If a built-in driver tries to
> > register before subsys_initcall with its struct device_driver's mod_name set,
> > then a null module_kset is dereferenced via this call trace:
> >
> > [ 0.095865] Call trace:
> > [ 0.095999] _raw_spin_lock+0x4c/0x6c (P)
> > [ 0.096150] kset_find_obj+0x24/0x104
> > [ 0.096209] lookup_or_create_module_kobject+0x2c/0xd8
> > [ 0.096274] module_add_driver+0xd4/0x138
> > [ 0.096328] bus_add_driver+0x16c/0x268
> > [ 0.096380] driver_register+0x68/0x100
> > [ 0.096428] __platform_driver_register+0x24/0x30
> > [ 0.096486] tegra194_cbb_init+0x24/0x30
> > [ 0.096540] do_one_initcall+0xdc/0x250
> > [ 0.096608] do_initcall_level+0x9c/0xd0
> > [ 0.096660] do_initcalls+0x54/0x94
> > [ 0.096706] do_basic_setup+0x20/0x2c
> > [ 0.096753] kernel_init_freeable+0xc8/0x154
> > [ 0.096807] kernel_init+0x20/0x1a0
> > [ 0.096851] ret_from_fork+0x10/0x20
> >
> > So, return null in lookup_or_create_module_kobject() if module_kset is null.
> > Existing callers handle null already.
> >
> > Fixes: f30c53a873d0 ("MODULES: add the module name for built in kernel drivers")
>
> This isn't a bugfix.
I'll drop it in the next version.
> > Co-developed-by: Rahul Bukte <rahul.bukte@sony.com>
> > Signed-off-by: Rahul Bukte <rahul.bukte@sony.com>
> > Signed-off-by: Shashank Balaji <shashank.mahadasyam@sony.com>
> > ---
> > This bug is triggered by the next patch on arm64 defconfig: tegra194-cbb tries
> > to register from a pure_initcall, and with the next patch adding mod_name, this
> > null deref is hit.
>
> So this isn't a bug, it's a "don't do that" type of thing :)
>
> > ---
> > kernel/params.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/kernel/params.c b/kernel/params.c
> > index 74d620bc2521..881c7328c059 100644
> > --- a/kernel/params.c
> > +++ b/kernel/params.c
> > @@ -752,6 +752,9 @@ lookup_or_create_module_kobject(const char *name)
> > struct kobject *kobj;
> > int err;
> >
> > + if (!module_kset)
> > + return NULL;
>
> Are you sure that making this change is going to be ok?
> mod_sysfs_init() should have been called first as the module has to be
> created before it can be looked up.
>
> As you are wanting "built in" drivers to show up here, you are going to
> beat the call to param_sysfs_init(), so don't do that. Make sure that
> the drivers are NOT called before then.
The reason lookup_or_create_module_kobject() can be reached with module_kset == NULL
is that some platform drivers register before subsys_initcall: tegra194_cbb and
tegra234_cbb at pure_initcall, plus roughly 375 others at core_initcall/arch_initcall
(208 arch, 154 core, plus 2 pure and 13 _sync variants). These are dominated by
pinctrl, clk, interconnect, gpio, and mailbox drivers across six SoC vendor trees
(Qualcomm, MediaTek, Freescale, Samsung, Tegra, HiSilicon).
Given that, three ways forward:
1. Move module_kset creation out of param_sysfs_init() (currently
subsys_initcall) and call it directly from do_basic_setup()
before do_initcalls(). This is the cleanest fix from a
correctness angle: every initcall level sees a live
module_kset. But it touches init/main.c and kernel/params.c,
crosses two subsystem trees. I haven't fully audited
dependencies at do_basic_setup() time.
2. Demote the ~377 early-initcall platform drivers to
subsys_initcall or later. Impractical at scale given coordination
across six vendor trees, and many of these levels seem to be
architecturally required.
3. (This patch) Guard lookup_or_create_module_kobject() against
NULL module_kset. Drivers registered before subsys_initcall
don't get the /sys/.../module symlink, but they don't get it
today either (drv->mod_name is NULL pre-patch, so the
else-if (drv->mod_name) branch in module_add_driver() isn't
taken). Verified on arm64: /sys/module/tegra194_cbb/ does not
exist on a booted defconfig with or without my series. The
guard preserves that exact state while letting the
device_initcall majority get their symlinks as designed.
I went with option 3 because it preserves observable behaviour
everywhere and keeps the series scoped to driver-core. If you'd
rather I do option 1 instead, I'm happy to.
Thanks,
Shashank
^ permalink raw reply
* [PATCH v2] docs: kernel-parameters: document scope of irqaffinity= parameter
From: Aaron Tomlin @ 2026-04-21 15:09 UTC (permalink / raw)
To: corbet, skhan
Cc: tglx, akpm, bp, rdunlap, dave.hansen, feng.tang,
pawan.kumar.gupta, dapeng1.mi, kees, elver, paulmck, lirongqing,
bhelgaas, bigeasy, linux-doc, linux-kernel
There is a common misconception that the "irqaffinity=" boot parameter
acts as a global override for all hardware interrupts. In reality, it
only sets the irq_default_affinity mask, which is explicitly ignored
by managed interrupts (e.g., modern multiqueue storage controllers).
This patch updates kernel-parameters.txt to document this limitation,
directs users to "isolcpus=managed_irq" and
Documentation/core-api/irq/managed_irq.rst for further details.
Additionally, it updates managed_irq.rst to provide a debugfs example
demonstrating the IRQD_AFFINITY_MANAGED state flag.
Signed-off-by: Aaron Tomlin <atomlin@atomlin.com>
---
Changes in v1 [1]:
- Provided an example of a managed IRQ using CONFIG_GENERIC_IRQ_DEBUGFS
- Referenced Documentation/core-api/irq/managed_irq.rst
[1]: https://lore.kernel.org/lkml/20260414200245.1153919-1-atomlin@atomlin.com/
---
.../admin-guide/kernel-parameters.txt | 11 ++++
Documentation/core-api/irq/managed_irq.rst | 53 ++++++++++++++++++-
2 files changed, 62 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index cf3807641d89..365c4931700a 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2726,6 +2726,17 @@ Kernel parameters
irqaffinity= [SMP] Set the default irq affinity mask
The argument is a cpu list, as described above.
+ Note: This parameter only sets the default affinity
+ for unmanaged interrupts (e.g., legacy single-queue
+ devices or unmanaged pre/post vectors). It is
+ explicitly ignored by managed interrupts, such as
+ those utilised by modern multiqueue storage
+ controllers. To isolate CPUs from managed
+ interrupts, see "isolcpus=managed_irq".
+
+ For further details see:
+ Documentation/core-api/irq/managed_irq.rst
+
irqchip.gicv2_force_probe=
[ARM,ARM64,EARLY]
Format: <bool>
diff --git a/Documentation/core-api/irq/managed_irq.rst b/Documentation/core-api/irq/managed_irq.rst
index 05e295f3c289..8e973a7d1bd1 100644
--- a/Documentation/core-api/irq/managed_irq.rst
+++ b/Documentation/core-api/irq/managed_irq.rst
@@ -80,9 +80,58 @@ The following examples assume a system with 8 CPUs.
/proc/irq/48/effective_affinity_list:0
/proc/irq/48/smp_affinity_list:7
- This can be verified via the debugfs interface
- (/sys/kernel/debug/irq/irqs/48). The dstate field will include
+ If the Linux kernel was built with Kconfig CONFIG_GENERIC_IRQ_DEBUGFS
+ enabled, this can be verified via the debugfs interface (e.g.,
+ /sys/kernel/debug/irq/irqs/48). The dstate field will include
IRQD_IRQ_DISABLED, IRQD_IRQ_MASKED and IRQD_MANAGED_SHUTDOWN.
+ A managed IRQ will also include IRQD_AFFINITY_MANAGED. For example:
+
+ # cat /sys/kernel/debug/irq/irqs/87
+ handler: handle_edge_irq
+ device: 0000:41:00.0
+ status: 0x00000000
+ istate: 0x00004000
+ ddepth: 0
+ wdepth: 0
+ dstate: 0x19601200
+ IRQD_ACTIVATED
+ IRQD_IRQ_STARTED
+ IRQD_SINGLE_TARGET
+ IRQD_AFFINITY_SET
+ IRQD_AFFINITY_MANAGED
+ IRQD_AFFINITY_ON_ACTIVATE
+ IRQD_HANDLE_ENFORCE_IRQCTX
+ node: 0
+ affinity: 9
+ effectiv: 9
+ pending:
+ domain: IR-PCI-MSIX-0000:41:00.0-12
+ hwirq: 0x8
+ chip: IR-PCI-MSIX-0000:41:00.0
+ flags: 0x430
+ IRQCHIP_SKIP_SET_WAKE
+ IRQCHIP_ONESHOT_SAFE
+
+ address_hi: 0x00000000
+ address_lo: 0xfee00000
+ msg_data: 0x00000008
+ parent:
+ domain: AMD-IR-3-14
+ hwirq: 0x41000000
+ chip: AMD-IR
+ flags: 0x0
+ parent:
+ domain: VECTOR
+ hwirq: 0x57
+ chip: APIC
+ flags: 0x0
+ Vector: 33
+ Target: 9
+ move_in_progress: 0
+ is_managed: 1
+ can_reserve: 0
+ has_reserved: 0
+ cleanup_pending: 0
- A QEMU instance is booted with "-device virtio-scsi-pci,num_queues=2"
and the kernel command line includes:
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v2 00/16] fs,x86/resctrl: Add kernel-mode (e.g., PLZA) support to the resctrl subsystem
From: Babu Moger @ 2026-04-21 15:08 UTC (permalink / raw)
To: Reinette Chatre, Moger, Babu, corbet@lwn.net, tony.luck@intel.com,
Dave.Martin@arm.com, james.morse@arm.com, tglx@kernel.org,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com
Cc: skhan@linuxfoundation.org, x86@kernel.org, hpa@zytor.com,
peterz@infradead.org, juri.lelli@redhat.com,
vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
vschneid@redhat.com, kas@kernel.org, rick.p.edgecombe@intel.com,
akpm@linux-foundation.org, pmladek@suse.com,
rdunlap@infradead.org, dapeng1.mi@linux.intel.com,
kees@kernel.org, elver@google.com, paulmck@kernel.org,
lirongqing@baidu.com, safinaskar@gmail.com, fvdl@google.com,
seanjc@google.com, pawan.kumar.gupta@linux.intel.com,
xin@zytor.com, tiala@microsoft.com, chang.seok.bae@intel.com,
Lendacky, Thomas, elena.reshetova@intel.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-coco@lists.linux.dev, kvm@vger.kernel.org,
eranian@google.com, peternewman@google.com
In-Reply-To: <71099958-1ddf-40dc-8a3c-aa13d0c56fee@intel.com>
Hi Reinette,
On 4/20/26 22:17, Reinette Chatre wrote:
> Hi Babu,
>
> On 4/20/26 5:40 PM, Moger, Babu wrote:
>>
>> We already discussed moving back to the default group on every mode
>> switch. Doing so here would once again cause extra MSR writes on
>> each mode transition, which is undesirable.
>>
>
> Needing to avoid extra MSR writes in resctrl is not so absolute. Consider, for
> example, how resctrl initializes default allocations when a new resource group is
> created. resctrl aims to initialize with sane defaults and the user is expected to
> follow with desired allocations.
>
> I am not against optimizing, I just want to be careful with such general statements.
>
> Considering your proposal in https://lore.kernel.org/lkml/39e0c786-cc35-4555-bfb9-ff7cd758c423@amd.com/:
>
> I do not think we should make info/kernel_mode read-only. If I understand correctly
> doing so would accommodate AMD PLZA but it ignores the discussions on how resctrl could
> support MPAM ... or do you perhaps have proposal on how MPAM can be supported when considering
> your proposal? Even if you do not want to consider MPAM - what if the PLZA_PQR register's
> scope becomes per-CPU in the next version of AMD PLZA?
>
> The idea behind info/kernel_mode is that the active mode it identifies indicates which
> configuration files exist to configure the active mode. Since the mode may not always
> depend on global configuration, for which info/kernel_mode_assignment was created, but instead
> rely on per-resource group files, I do not see how resctrl can build on a read-only
> info/kernel_mode backed by a mode and group change via info/kernel_mode_assignment.
> Specifically, MPAM support may not use info/kernel_mode_assignment at all.
> Instead, MPAM may use something like described in https://lore.kernel.org/lkml/aYyxAPdTFejzsE42@e134344.arm.com/
>
> Could we perhaps consider dropping info/kernel_mode_assignment entirely for
> AMD PLZA's global allocations? Similar to what you suggest, the mode and
> group assignment could be done via the info/kernel_mode file instead?
>
> Thinking about this more since the CPUs allocation is global, these could *theoretically*
> be included also (but see later).
> This could mean that "kernel_mode_cpus" and "kernel_mode_cpus_list" could be dropped?
> Although, this may complicate the interface since user space may want a convenient way
> to modify just CPUs independently from needing to repeat the mode and group every time.
>
> Consider, for example:
>
> # echo "global_assign_ctrl_assign_mon_per_cpu:group=ctrl1/mon1/;cpus_list=5-8" > info/kernel_mode
This looks reasonable.
>
> Having named fields (a) makes this extensible, (b) output does not need to be split among files,
> and (c) "inherit_ctrl_and_mon" can continue to be supported.
>
> The named fields could be made optional, if group is omitted then it will become the
> default resource group, and if cpus/cpus_list is omitted then it will default to all CPUs.
> This may not be intuitive since a user may expect that not mentioning a field means
> that the field is left untouched. Have you considered this scenario in your proposal?
>
> As an alternative the group could be made a required field and "kernel_mode_cpus"/"kernel_mode_cpuslist"
> can stay? This may be the simplest approach.
How about keeping a single option to update the CPUs using
kernel_mode_cpus / kernel_mode_cpuslist within the group?
Should we consider removing the per‑CPU extension altogether? By
default, the mode already applies to all online CPUs, and any per‑CPU
requirements can be handled within the group using kernel_mode_cpus /
kernel_mode_cpuslist.
# echo "global_assign_ctrl_assign_mon_per_cpu:group=ctrl1/mon1/
Why do we still need to keep the "inherit_ctrl_and_mon"? By default all
the groups in the system falls in this category it is not plza enabled
group.
System boots up with following options if PLZA is supported.
# cat info/kernel_mode
global_assign_ctrl_assign_mon_per_cpu
global_assign_ctrl_inherit_mon_per_cpu
No groups are associated with kernel mode at this point.
# echo "global_assign_ctrl_assign_mon_per_cpu:group=ctrl1/mon1/" >
info/kernel_mode
# cat info/kernel_mode
global_assign_ctrl_assign_mon_per_cpu:group=ctrl1/mon1/
global_assign_ctrl_inherit_mon_per_cpu
# echo "global_assign_ctrl_inherit_mon_per_cpu:group=//" > info/kernel_mode
# cat info/kernel_mode
global_assign_ctrl_assign_mon_per_cpu
global_assign_ctrl_inherit_mon_per_cpu:group=//
How does this look?
Thanks
Babu
^ permalink raw reply
* Re: [PATCH v11 02/20] gpu: nova-core: gsp: Extract usable FB region from GSP
From: Joel Fernandes @ 2026-04-21 14:55 UTC (permalink / raw)
To: John Hubbard
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo, Bjorn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Dave Airlie, Daniel Almeida, Koen Koning,
dri-devel, rust-for-linux, Nikola Djukic, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Alex Deucher, Christian Koenig, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Huang Rui,
Matthew Auld, Lucas De Marchi, Thomas Hellstrom, Helge Deller,
Alex Gaynor, Boqun Feng, Alistair Popple, Timur Tabi, Edwin Peer,
Alexandre Courbot, Andrea Righi, Andy Ritger, Zhi Wang,
Balbir Singh, Philipp Stanner, Elle Rhumsaa, alexeyi,
Eliot Courtney, joel, linux-doc, amd-gfx, intel-gfx, intel-xe,
linux-fbdev
In-Reply-To: <b0c5267d-ea77-41c5-94d4-39c651761b3c@nvidia.com>
On Thu, Apr 16, 2026 at 04:26:48PM -0700, John Hubbard wrote:
> On 4/15/26 2:05 PM, Joel Fernandes wrote:
> ...
>
> Apologies, I found one more minor thing, while looking at a
> subsequent patch in this series:
>
> > impl MessageFromGsp for GetGspStaticInfoReply {
> > const FUNCTION: MsgFunction = MsgFunction::GetGspStaticInfo;
> > type Message = GspStaticConfigInfo;
> > - type InitError = Infallible;
> > + type InitError = Error;
> >
> > fn read(
> > msg: &Self::Message,
> > @@ -205,6 +209,7 @@ fn read(
> > ) -> Result<Self, Self::InitError> {
> > Ok(GetGspStaticInfoReply {
> > gpu_name: msg.gpu_name_str(),
> > + usable_fb_region: msg.first_usable_fb_region().ok_or(ENODEV)?,
>
> OK, failing out is correct here. But in addition, we should also
> log this at dev_err!() level. This is rare, surprising, and actionable,
> so perfect for that level of logging.
Sure, that works for me. Will add it in for v12.
thanks,
--
Joel Fernandes
^ permalink raw reply
* Re: [PATCH v12 01/16] set_memory: set_direct_map_* to take address
From: Lorenzo Stoakes @ 2026-04-21 14:43 UTC (permalink / raw)
To: Kalyazin, Nikita
Cc: kvm@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
bpf@vger.kernel.org, linux-kselftest@vger.kernel.org,
kernel@xen0n.name, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, loongarch@lists.linux.dev,
linux-pm@vger.kernel.org, pbonzini@redhat.com, corbet@lwn.net,
maz@kernel.org, oupton@kernel.org, joey.gouly@arm.com,
suzuki.poulose@arm.com, yuzenghui@huawei.com,
catalin.marinas@arm.com, will@kernel.org, seanjc@google.com,
tglx@kernel.org, mingo@redhat.com, bp@alien8.de,
dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
luto@kernel.org, peterz@infradead.org, willy@infradead.org,
akpm@linux-foundation.org, david@kernel.org,
lorenzo.stoakes@oracle.com, vbabka@kernel.org, rppt@kernel.org,
surenb@google.com, mhocko@suse.com, ast@kernel.org,
daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev,
eddyz87@gmail.com, song@kernel.org, yonghong.song@linux.dev,
john.fastabend@gmail.com, kpsingh@kernel.org, sdf@fomichev.me,
haoluo@google.com, jolsa@kernel.org, jgg@ziepe.ca,
jhubbard@nvidia.com, peterx@redhat.com, jannh@google.com,
pfalcato@suse.de, skhan@linuxfoundation.org, riel@surriel.com,
ryan.roberts@arm.com, jgross@suse.com, yu-cheng.yu@intel.com,
kas@kernel.org, coxu@redhat.com, ackerleytng@google.com,
yosry@kernel.org, ajones@ventanamicro.com, maobibo@loongson.cn,
tabba@google.com, prsampat@amd.com, wu.fei9@sanechips.com.cn,
mlevitsk@redhat.com, jmattson@google.com, jthoughton@google.com,
agordeev@linux.ibm.com, alex@ghiti.fr, aou@eecs.berkeley.edu,
borntraeger@linux.ibm.com, chenhuacai@kernel.org,
baolu.lu@linux.intel.com, dev.jain@arm.com, gor@linux.ibm.com,
hca@linux.ibm.com, palmer@dabbelt.com, pjw@kernel.org,
shijie@os.amperecomputing.com, svens@linux.ibm.com,
thuth@redhat.com, yang@os.amperecomputing.com,
Liam.Howlett@oracle.com, urezki@gmail.com,
zhengqi.arch@bytedance.com, gerald.schaefer@linux.ibm.com,
jiayuan.chen@shopee.com, lenb@kernel.org, pavel@kernel.org,
rafael@kernel.org, yangyicong@hisilicon.com,
vannapurve@google.com, jackmanb@google.com, patrick.roy@linux.dev,
Thomson, Jack, Itazuri, Takahiro, Manwaring, Derek
In-Reply-To: <20260410151746.61150-2-kalyazin@amazon.com>
On Fri, Apr 10, 2026 at 03:17:58PM +0000, Kalyazin, Nikita wrote:
> From: Nikita Kalyazin <nikita.kalyazin@linux.dev>
>
> Let's convert set_direct_map_*() to take an address instead of a page to
> prepare for adding helpers that operate on folios; it will be more
> efficient to convert from a folio directly to an address without going
> through a page first.
Hmm presumably these addresses have to be page-aligned? But now they might not
be _in theory_?
Is it clear to callers that they should pass page-aligned pointers? Might we
have an issue in future with somebody passing something unaligned?
>
> Acked-by: David Hildenbrand (Arm) <david@kernel.org>
> Signed-off-by: Nikita Kalyazin <nikita.kalyazin@linux.dev>
The logic looks good to me, just various stylistic issues and concerns about
alignment for future callers.
> ---
> arch/arm64/include/asm/set_memory.h | 7 ++++---
> arch/arm64/mm/pageattr.c | 19 +++++++++--------
> arch/loongarch/include/asm/set_memory.h | 7 ++++---
> arch/loongarch/mm/pageattr.c | 25 ++++++++++-------------
> arch/riscv/include/asm/set_memory.h | 7 ++++---
> arch/riscv/mm/pageattr.c | 17 ++++++++--------
> arch/s390/include/asm/set_memory.h | 7 ++++---
> arch/s390/mm/pageattr.c | 13 ++++++------
> arch/x86/include/asm/set_memory.h | 7 ++++---
> arch/x86/mm/pat/set_memory.c | 27 +++++++++++++------------
> include/linux/set_memory.h | 9 +++++----
> kernel/power/snapshot.c | 4 ++--
> mm/execmem.c | 6 ++++--
> mm/secretmem.c | 6 +++---
> mm/vmalloc.c | 11 ++++++----
> 15 files changed, 91 insertions(+), 81 deletions(-)
>
> diff --git a/arch/arm64/include/asm/set_memory.h b/arch/arm64/include/asm/set_memory.h
> index 90f61b17275e..c71a2a6812c4 100644
> --- a/arch/arm64/include/asm/set_memory.h
> +++ b/arch/arm64/include/asm/set_memory.h
> @@ -11,9 +11,10 @@ bool can_set_direct_map(void);
>
> int set_memory_valid(unsigned long addr, int numpages, int enable);
>
> -int set_direct_map_invalid_noflush(struct page *page);
> -int set_direct_map_default_noflush(struct page *page);
> -int set_direct_map_valid_noflush(struct page *page, unsigned nr, bool valid);
> +int set_direct_map_invalid_noflush(const void *addr);
> +int set_direct_map_default_noflush(const void *addr);
> +int set_direct_map_valid_noflush(const void *addr, unsigned long numpages,
> + bool valid);
I mean it's nitty, but it's weird having these being called 'addr' when they're
not giving you an address, they're giving you pointers to something.
E.g. if I have a 'struct vm_area_struct *vma' and I do *vma I get a VMA. If I do
a *addr here I get a... hmm :)
This looks to be a long-standing issue with page_address() (and probably,
necessarily, folio_address()). But still...
It causes you issues later, somewhat trivial ones but still, where you have
something like:
unsigned long addr = (unsigned long)page_address(page);
And now have a void *addr...
Maybe 'page_start' or something like that makes it clear that these need to be
page-aligned. Or plain 'ptr' works too? 'page_ptr'? Naming's hard :)
Would it be overly difficult to simply pass the addr as an unsigned long?
Also a const void * is iffy from a type safety point of view, because somebody
might not have got the memo, adds some code to that hands a struct page * and
there'd be no compiler issues. Obv. the same with unaligned stuff.
Using an unsigned long would avoid that (not the alignment issue though
obviously, but could imply that with param name maybe).
> bool kernel_page_present(struct page *page);
>
> int set_memory_encrypted(unsigned long addr, int numpages);
> diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
> index 358d1dc9a576..5aff94e1f8b2 100644
> --- a/arch/arm64/mm/pageattr.c
> +++ b/arch/arm64/mm/pageattr.c
> @@ -245,7 +245,7 @@ int set_memory_valid(unsigned long addr, int numpages, int enable)
> __pgprot(PTE_VALID));
> }
>
> -int set_direct_map_invalid_noflush(struct page *page)
> +int set_direct_map_invalid_noflush(const void *addr)
> {
> pgprot_t clear_mask = __pgprot(PTE_VALID);
> pgprot_t set_mask = __pgprot(0);
> @@ -253,11 +253,11 @@ int set_direct_map_invalid_noflush(struct page *page)
> if (!can_set_direct_map())
> return 0;
>
> - return update_range_prot((unsigned long)page_address(page),
> - PAGE_SIZE, set_mask, clear_mask);
> + return update_range_prot((unsigned long)addr, PAGE_SIZE, set_mask,
> + clear_mask);
> }
>
> -int set_direct_map_default_noflush(struct page *page)
> +int set_direct_map_default_noflush(const void *addr)
> {
> pgprot_t set_mask = __pgprot(PTE_VALID | PTE_WRITE);
> pgprot_t clear_mask = __pgprot(PTE_RDONLY);
> @@ -265,8 +265,8 @@ int set_direct_map_default_noflush(struct page *page)
> if (!can_set_direct_map())
> return 0;
>
> - return update_range_prot((unsigned long)page_address(page),
> - PAGE_SIZE, set_mask, clear_mask);
> + return update_range_prot((unsigned long)addr, PAGE_SIZE, set_mask,
> + clear_mask);
> }
>
> static int __set_memory_enc_dec(unsigned long addr,
> @@ -349,14 +349,13 @@ int realm_register_memory_enc_ops(void)
> return arm64_mem_crypt_ops_register(&realm_crypt_ops);
> }
>
> -int set_direct_map_valid_noflush(struct page *page, unsigned nr, bool valid)
> +int set_direct_map_valid_noflush(const void *addr, unsigned long numpages,
> + bool valid)
> {
> - unsigned long addr = (unsigned long)page_address(page);
NIT, but maybe less churny to keep this and make it (unsigned long)addr?
OTOH is more consistent with other stuff to do the way you have, so optional.
I kinda like spelling things out like this though.
> -
> if (!can_set_direct_map())
> return 0;
>
> - return set_memory_valid(addr, nr, valid);
> + return set_memory_valid((unsigned long)addr, numpages, valid);
Yeah I mean (unsigned long)addr looks really weird to me, nearly always 'addr'
references an address value like unsigned long in mm so :)
> }
>
> #ifdef CONFIG_DEBUG_PAGEALLOC
> diff --git a/arch/loongarch/include/asm/set_memory.h b/arch/loongarch/include/asm/set_memory.h
> index 55dfaefd02c8..5e9b67b2fea1 100644
> --- a/arch/loongarch/include/asm/set_memory.h
> +++ b/arch/loongarch/include/asm/set_memory.h
> @@ -15,8 +15,9 @@ int set_memory_ro(unsigned long addr, int numpages);
> int set_memory_rw(unsigned long addr, int numpages);
>
> bool kernel_page_present(struct page *page);
> -int set_direct_map_default_noflush(struct page *page);
> -int set_direct_map_invalid_noflush(struct page *page);
> -int set_direct_map_valid_noflush(struct page *page, unsigned nr, bool valid);
> +int set_direct_map_invalid_noflush(const void *addr);
> +int set_direct_map_default_noflush(const void *addr);
> +int set_direct_map_valid_noflush(const void *addr, unsigned long numpages,
> + bool valid);
>
> #endif /* _ASM_LOONGARCH_SET_MEMORY_H */
> diff --git a/arch/loongarch/mm/pageattr.c b/arch/loongarch/mm/pageattr.c
> index f5e910b68229..9e08905d3624 100644
> --- a/arch/loongarch/mm/pageattr.c
> +++ b/arch/loongarch/mm/pageattr.c
> @@ -198,32 +198,29 @@ bool kernel_page_present(struct page *page)
> return pte_present(ptep_get(pte));
> }
>
> -int set_direct_map_default_noflush(struct page *page)
> +int set_direct_map_default_noflush(const void *addr)
> {
> - unsigned long addr = (unsigned long)page_address(page);
OK we definitely need to de-duplicate here, repeatedly doing (unsigned long)addr
is a bit silly.
Also if you do, please const-ify the value.
> -
> - if (addr < vm_map_base)
> + if ((unsigned long)addr < vm_map_base)
> return 0;
>
> - return __set_memory(addr, 1, PAGE_KERNEL, __pgprot(0));
> + return __set_memory((unsigned long)addr, 1, PAGE_KERNEL, __pgprot(0));
> }
>
> -int set_direct_map_invalid_noflush(struct page *page)
> +int set_direct_map_invalid_noflush(const void *addr)
> {
> - unsigned long addr = (unsigned long)page_address(page);
> -
> - if (addr < vm_map_base)
> + if ((unsigned long)addr < vm_map_base)
> return 0;
>
> - return __set_memory(addr, 1, __pgprot(0), __pgprot(_PAGE_PRESENT | _PAGE_VALID));
> + return __set_memory((unsigned long)addr, 1, __pgprot(0),
> + __pgprot(_PAGE_PRESENT | _PAGE_VALID));
Same here... We could avoid most of the churn here altogether by saying ptr
instead of addr and just changing the addr = bit :)
> }
>
> -int set_direct_map_valid_noflush(struct page *page, unsigned nr, bool valid)
> +int set_direct_map_valid_noflush(const void *addr, unsigned long numpages,
> + bool valid)
> {
> - unsigned long addr = (unsigned long)page_address(page);
> pgprot_t set, clear;
>
> - if (addr < vm_map_base)
> + if ((unsigned long)addr < vm_map_base)
> return 0;
>
> if (valid) {
> @@ -234,5 +231,5 @@ int set_direct_map_valid_noflush(struct page *page, unsigned nr, bool valid)
> clear = __pgprot(_PAGE_PRESENT | _PAGE_VALID);
> }
>
> - return __set_memory(addr, 1, set, clear);
> + return __set_memory((unsigned long)addr, 1, set, clear);
Obv. same comments here and below, I will stop duplicating them, just assume
they apply to the whole thing :)
> }
> diff --git a/arch/riscv/include/asm/set_memory.h b/arch/riscv/include/asm/set_memory.h
> index 87389e93325a..a87eabd7fc78 100644
> --- a/arch/riscv/include/asm/set_memory.h
> +++ b/arch/riscv/include/asm/set_memory.h
> @@ -40,9 +40,10 @@ static inline int set_kernel_memory(char *startp, char *endp,
> }
> #endif
>
> -int set_direct_map_invalid_noflush(struct page *page);
> -int set_direct_map_default_noflush(struct page *page);
> -int set_direct_map_valid_noflush(struct page *page, unsigned nr, bool valid);
> +int set_direct_map_invalid_noflush(const void *addr);
> +int set_direct_map_default_noflush(const void *addr);
> +int set_direct_map_valid_noflush(const void *addr, unsigned long numpages,
> + bool valid);
> bool kernel_page_present(struct page *page);
>
> #endif /* __ASSEMBLER__ */
> diff --git a/arch/riscv/mm/pageattr.c b/arch/riscv/mm/pageattr.c
> index 3f76db3d2769..0a457177a88c 100644
> --- a/arch/riscv/mm/pageattr.c
> +++ b/arch/riscv/mm/pageattr.c
> @@ -374,19 +374,20 @@ int set_memory_nx(unsigned long addr, int numpages)
> return __set_memory(addr, numpages, __pgprot(0), __pgprot(_PAGE_EXEC));
> }
>
> -int set_direct_map_invalid_noflush(struct page *page)
> +int set_direct_map_invalid_noflush(const void *addr)
> {
> - return __set_memory((unsigned long)page_address(page), 1,
> - __pgprot(0), __pgprot(_PAGE_PRESENT));
> + return __set_memory((unsigned long)addr, 1, __pgprot(0),
> + __pgprot(_PAGE_PRESENT));
> }
>
> -int set_direct_map_default_noflush(struct page *page)
> +int set_direct_map_default_noflush(const void *addr)
> {
> - return __set_memory((unsigned long)page_address(page), 1,
> - PAGE_KERNEL, __pgprot(_PAGE_EXEC));
> + return __set_memory((unsigned long)addr, 1, PAGE_KERNEL,
> + __pgprot(_PAGE_EXEC));
> }
>
> -int set_direct_map_valid_noflush(struct page *page, unsigned nr, bool valid)
> +int set_direct_map_valid_noflush(const void *addr, unsigned long numpages,
> + bool valid)
> {
> pgprot_t set, clear;
>
> @@ -398,7 +399,7 @@ int set_direct_map_valid_noflush(struct page *page, unsigned nr, bool valid)
> clear = __pgprot(_PAGE_PRESENT);
> }
>
> - return __set_memory((unsigned long)page_address(page), nr, set, clear);
> + return __set_memory((unsigned long)addr, numpages, set, clear);
> }
>
> #ifdef CONFIG_DEBUG_PAGEALLOC
> diff --git a/arch/s390/include/asm/set_memory.h b/arch/s390/include/asm/set_memory.h
> index 94092f4ae764..3e43c3c96e67 100644
> --- a/arch/s390/include/asm/set_memory.h
> +++ b/arch/s390/include/asm/set_memory.h
> @@ -60,9 +60,10 @@ __SET_MEMORY_FUNC(set_memory_rox, SET_MEMORY_RO | SET_MEMORY_X)
> __SET_MEMORY_FUNC(set_memory_rwnx, SET_MEMORY_RW | SET_MEMORY_NX)
> __SET_MEMORY_FUNC(set_memory_4k, SET_MEMORY_4K)
>
> -int set_direct_map_invalid_noflush(struct page *page);
> -int set_direct_map_default_noflush(struct page *page);
> -int set_direct_map_valid_noflush(struct page *page, unsigned nr, bool valid);
> +int set_direct_map_invalid_noflush(const void *addr);
> +int set_direct_map_default_noflush(const void *addr);
> +int set_direct_map_valid_noflush(const void *addr, unsigned long numpages,
> + bool valid);
> bool kernel_page_present(struct page *page);
>
> #endif
> diff --git a/arch/s390/mm/pageattr.c b/arch/s390/mm/pageattr.c
> index bb29c38ae624..8e90ff5cf50d 100644
> --- a/arch/s390/mm/pageattr.c
> +++ b/arch/s390/mm/pageattr.c
> @@ -383,17 +383,18 @@ int __set_memory(unsigned long addr, unsigned long numpages, unsigned long flags
> return rc;
> }
>
> -int set_direct_map_invalid_noflush(struct page *page)
> +int set_direct_map_invalid_noflush(const void *addr)
> {
> - return __set_memory((unsigned long)page_to_virt(page), 1, SET_MEMORY_INV);
> + return __set_memory((unsigned long)addr, 1, SET_MEMORY_INV);
> }
>
> -int set_direct_map_default_noflush(struct page *page)
> +int set_direct_map_default_noflush(const void *addr)
> {
> - return __set_memory((unsigned long)page_to_virt(page), 1, SET_MEMORY_DEF);
> + return __set_memory((unsigned long)addr, 1, SET_MEMORY_DEF);
> }
>
> -int set_direct_map_valid_noflush(struct page *page, unsigned nr, bool valid)
> +int set_direct_map_valid_noflush(const void *addr, unsigned long numpages,
Why changing to numpages? I guess because it's not obvious what it's a count
of...
This really makes me think we're kinda making this interface a bit worse,
because before it had to be 'nr' pages, but now it's 'numpages of err something
starting at addr which isn't an address but a pointer and might not be aligned'.
If you called this 'page_ptr' then nr would be implicit and could be kept the
same I guess?
> + bool valid)
> {
> unsigned long flags;
>
> @@ -402,7 +403,7 @@ int set_direct_map_valid_noflush(struct page *page, unsigned nr, bool valid)
> else
> flags = SET_MEMORY_INV;
>
> - return __set_memory((unsigned long)page_to_virt(page), nr, flags);
> + return __set_memory((unsigned long)addr, numpages, flags);
> }
>
> bool kernel_page_present(struct page *page)
> diff --git a/arch/x86/include/asm/set_memory.h b/arch/x86/include/asm/set_memory.h
> index 4362c26aa992..b6a4173ff249 100644
> --- a/arch/x86/include/asm/set_memory.h
> +++ b/arch/x86/include/asm/set_memory.h
> @@ -86,9 +86,10 @@ int set_pages_wb(struct page *page, int numpages);
> int set_pages_ro(struct page *page, int numpages);
> int set_pages_rw(struct page *page, int numpages);
>
> -int set_direct_map_invalid_noflush(struct page *page);
> -int set_direct_map_default_noflush(struct page *page);
> -int set_direct_map_valid_noflush(struct page *page, unsigned nr, bool valid);
> +int set_direct_map_invalid_noflush(const void *addr);
> +int set_direct_map_default_noflush(const void *addr);
> +int set_direct_map_valid_noflush(const void *addr, unsigned long numpages,
> + bool valid);
> bool kernel_page_present(struct page *page);
>
> extern int kernel_set_to_readonly;
> diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
> index 40581a720fe8..7517195b75b9 100644
> --- a/arch/x86/mm/pat/set_memory.c
> +++ b/arch/x86/mm/pat/set_memory.c
> @@ -2587,9 +2587,9 @@ int set_pages_rw(struct page *page, int numpages)
> return set_memory_rw(addr, numpages);
> }
>
> -static int __set_pages_p(struct page *page, int numpages)
> +static int __set_pages_p(const void *addr, int numpages)
> {
> - unsigned long tempaddr = (unsigned long) page_address(page);
> + unsigned long tempaddr = (unsigned long)addr;
> struct cpa_data cpa = { .vaddr = &tempaddr,
> .pgd = NULL,
> .numpages = numpages,
> @@ -2606,9 +2606,9 @@ static int __set_pages_p(struct page *page, int numpages)
> return __change_page_attr_set_clr(&cpa, 1);
> }
>
> -static int __set_pages_np(struct page *page, int numpages)
> +static int __set_pages_np(const void *addr, int numpages)
> {
> - unsigned long tempaddr = (unsigned long) page_address(page);
> + unsigned long tempaddr = (unsigned long)addr;
This is even more horrid, tempaddr and addr, but different types...
Also let's please const-ify these kinds of local vars.
> struct cpa_data cpa = { .vaddr = &tempaddr,
> .pgd = NULL,
> .numpages = numpages,
> @@ -2625,22 +2625,23 @@ static int __set_pages_np(struct page *page, int numpages)
> return __change_page_attr_set_clr(&cpa, 1);
> }
>
> -int set_direct_map_invalid_noflush(struct page *page)
> +int set_direct_map_invalid_noflush(const void *addr)
> {
> - return __set_pages_np(page, 1);
> + return __set_pages_np(addr, 1);
> }
>
> -int set_direct_map_default_noflush(struct page *page)
> +int set_direct_map_default_noflush(const void *addr)
> {
> - return __set_pages_p(page, 1);
> + return __set_pages_p(addr, 1);
> }
>
> -int set_direct_map_valid_noflush(struct page *page, unsigned nr, bool valid)
> +int set_direct_map_valid_noflush(const void *addr, unsigned long numpages,
> + bool valid)
> {
> if (valid)
> - return __set_pages_p(page, nr);
> + return __set_pages_p(addr, numpages);
>
> - return __set_pages_np(page, nr);
> + return __set_pages_np(addr, numpages);
> }
>
> #ifdef CONFIG_DEBUG_PAGEALLOC
> @@ -2659,9 +2660,9 @@ void __kernel_map_pages(struct page *page, int numpages, int enable)
> * and hence no memory allocations during large page split.
> */
> if (enable)
> - __set_pages_p(page, numpages);
> + __set_pages_p(page_address(page), numpages);
> else
> - __set_pages_np(page, numpages);
> + __set_pages_np(page_address(page), numpages);
>
> /*
> * We should perform an IPI and flush all tlbs,
> diff --git a/include/linux/set_memory.h b/include/linux/set_memory.h
> index 3030d9245f5a..1a2563f525fc 100644
> --- a/include/linux/set_memory.h
> +++ b/include/linux/set_memory.h
> @@ -25,17 +25,18 @@ static inline int set_memory_rox(unsigned long addr, int numpages)
> #endif
>
> #ifndef CONFIG_ARCH_HAS_SET_DIRECT_MAP
> -static inline int set_direct_map_invalid_noflush(struct page *page)
> +static inline int set_direct_map_invalid_noflush(const void *addr)
> {
> return 0;
> }
> -static inline int set_direct_map_default_noflush(struct page *page)
> +static inline int set_direct_map_default_noflush(const void *addr)
> {
> return 0;
> }
>
> -static inline int set_direct_map_valid_noflush(struct page *page,
> - unsigned nr, bool valid)
> +static inline int set_direct_map_valid_noflush(const void *addr,
> + unsigned long numpages,
> + bool valid)
> {
> return 0;
> }
> diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c
> index 6e1321837c66..6eddfb22c0ff 100644
> --- a/kernel/power/snapshot.c
> +++ b/kernel/power/snapshot.c
> @@ -88,7 +88,7 @@ static inline int hibernate_restore_unprotect_page(void *page_address) {return 0
> static inline void hibernate_map_page(struct page *page)
> {
> if (IS_ENABLED(CONFIG_ARCH_HAS_SET_DIRECT_MAP)) {
> - int ret = set_direct_map_default_noflush(page);
> + int ret = set_direct_map_default_noflush(page_address(page));
>
> if (ret)
> pr_warn_once("Failed to remap page\n");
> @@ -101,7 +101,7 @@ static inline void hibernate_unmap_page(struct page *page)
> {
> if (IS_ENABLED(CONFIG_ARCH_HAS_SET_DIRECT_MAP)) {
> unsigned long addr = (unsigned long)page_address(page);
> - int ret = set_direct_map_invalid_noflush(page);
> + int ret = set_direct_map_invalid_noflush(page_address(page));
>
> if (ret)
> pr_warn_once("Failed to remap page\n");
> diff --git a/mm/execmem.c b/mm/execmem.c
> index 810a4ba9c924..220298ec87c8 100644
> --- a/mm/execmem.c
> +++ b/mm/execmem.c
> @@ -119,7 +119,8 @@ static int execmem_set_direct_map_valid(struct vm_struct *vm, bool valid)
> int err = 0;
>
> for (int i = 0; i < vm->nr_pages; i += nr) {
> - err = set_direct_map_valid_noflush(vm->pages[i], nr, valid);
> + err = set_direct_map_valid_noflush(page_address(vm->pages[i]),
> + nr, valid);
> if (err)
> goto err_restore;
> updated += nr;
> @@ -129,7 +130,8 @@ static int execmem_set_direct_map_valid(struct vm_struct *vm, bool valid)
>
> err_restore:
> for (int i = 0; i < updated; i += nr)
> - set_direct_map_valid_noflush(vm->pages[i], nr, !valid);
> + set_direct_map_valid_noflush(page_address(vm->pages[i]), nr,
> + !valid);
>
> return err;
> }
> diff --git a/mm/secretmem.c b/mm/secretmem.c
> index 11a779c812a7..fd29b33c6764 100644
> --- a/mm/secretmem.c
> +++ b/mm/secretmem.c
> @@ -72,7 +72,7 @@ static vm_fault_t secretmem_fault(struct vm_fault *vmf)
> goto out;
> }
>
> - err = set_direct_map_invalid_noflush(folio_page(folio, 0));
> + err = set_direct_map_invalid_noflush(folio_address(folio));
> if (err) {
> folio_put(folio);
> ret = vmf_error(err);
> @@ -87,7 +87,7 @@ static vm_fault_t secretmem_fault(struct vm_fault *vmf)
> * already happened when we marked the page invalid
> * which guarantees that this call won't fail
> */
> - set_direct_map_default_noflush(folio_page(folio, 0));
> + set_direct_map_default_noflush(folio_address(folio));
> folio_put(folio);
> if (err == -EEXIST)
> goto retry;
> @@ -151,7 +151,7 @@ static int secretmem_migrate_folio(struct address_space *mapping,
>
> static void secretmem_free_folio(struct folio *folio)
> {
> - set_direct_map_default_noflush(folio_page(folio, 0));
> + set_direct_map_default_noflush(folio_address(folio));
> folio_zero_segment(folio, 0, folio_size(folio));
> }
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 61caa55a4402..8822f73957d9 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -3342,14 +3342,17 @@ struct vm_struct *remove_vm_area(const void *addr)
> }
>
> static inline void set_area_direct_map(const struct vm_struct *area,
> - int (*set_direct_map)(struct page *page))
> + int (*set_direct_map)(const void *addr))
> {
> int i;
>
> /* HUGE_VMALLOC passes small pages to set_direct_map */
> - for (i = 0; i < area->nr_pages; i++)
> - if (page_address(area->pages[i]))
> - set_direct_map(area->pages[i]);
> + for (i = 0; i < area->nr_pages; i++) {
> + const void *addr = page_address(area->pages[i]);
> +
> + if (addr)
> + set_direct_map(addr);
> + }
> }
>
> /*
> --
> 2.50.1
>
Cheers, Lorenzo
^ permalink raw reply
* Re: [RFC, PATCH 00/12] userfaultfd: working set tracking for VM guest memory
From: Kiryl Shutsemau @ 2026-04-21 14:33 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Andrew Morton, Peter Xu, Lorenzo Stoakes, Mike Rapoport,
Suren Baghdasaryan, Vlastimil Babka, Liam R . Howlett, Zi Yan,
Jonathan Corbet, Shuah Khan, Sean Christopherson, Paolo Bonzini,
linux-mm, linux-kernel, linux-doc, linux-kselftest, kvm
In-Reply-To: <34f75083-29a3-4860-8a6e-94551d37ac6a@kernel.org>
On Tue, Apr 21, 2026 at 03:03:56PM +0200, David Hildenbrand (Arm) wrote:
> On 4/19/26 16:33, Kiryl Shutsemau wrote:
> > On Fri, Apr 17, 2026 at 01:26:34PM +0100, Kiryl Shutsemau wrote:
> >>> Leaving NUMA-balancing aside, a simple
> >>> mprotect(PROT_NONE)+mprotect(PROT_READ) would already be problematic to
> >>> distinguish both cases.
> >>
> >> Hm. I didn't consider this case (miss some uffd lore). Will rework to
> >> reuse existing PTE bit.
> >
> > See https://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git uffd/rfc-v3
> >
>
> Quick feedback from skimming over it:
>
>
> 1) ARCH_SUPPORTS_PROT_NONE needs some thought, because I am pretty sure all
> architectures support something like mprotect(PROT_NONE), and the config
> option might be misleading.
>
> So you very likely want to express different semantics here. You want to
> know whether pte_protnone()/pmd_protnone() works.
We do support mprotect(PROT_NONE) everywhere, but we don't always have a
way to distinguish such entries from others without VMA in hands. Like,
there are other PTEs that don't have present bit set. In my and NUMA
balancing context we cannot rely on VMA, because we want to install
PAGE_NONE entires into accessible VMA.
So we need two things; pte/pmd_protnone() checks and PAGE_NONE itself.
The first to test PTE for PAGE_NONE, the second for pte/pmd_modify() to
make the entry protnone.
Currently, generic code only use this functionality for NUMA balancing
and gated by NUMA balancing config option. So I moved it under separate
config option.
Do you want it to be named differently?
> 2) The other stuff is really just an extension of existing WP handling.
> I suspect we want to have some reasonable cleanups to not end up in
> common code with
>
> @@ -1841,7 +1841,7 @@ static void copy_huge_non_present_pmd(
> add_mm_counter(dst_mm, MM_ANONPAGES, HPAGE_PMD_NR);
> mm_inc_nr_ptes(dst_mm);
> pgtable_trans_huge_deposit(dst_mm, dst_pmd, pgtable);
> - if (!userfaultfd_wp(dst_vma))
> + if (!userfaultfd_wp(dst_vma) && !userfaultfd_rwp(dst_vma))
> pmd = pmd_swp_clear_uffd_wp(pmd);
> set_pmd_at(dst_mm, addr, dst_pmd, pmd);
>
> All the uffd handling should be better isolated (i.e., a single vma check?),
> and likely the uffd bit should be abstracted away from being called "wp" to
> something more generic.
>
> Maybe it's simply a "uffd" flag which's semantics depend
> on the vma flags.
>
> Maybe something like:
>
> @@ -1841,7 +1841,7 @@ static void copy_huge_non_present_pmd(
> add_mm_counter(dst_mm, MM_ANONPAGES, HPAGE_PMD_NR);
> mm_inc_nr_ptes(dst_mm);
> pgtable_trans_huge_deposit(dst_mm, dst_pmd, pgtable);
> if (!userfaultfd_uses_pte_bit(dst_vma))
> pmd = pmd_swp_clear_uffd(pmd);
> set_pmd_at(dst_mm, addr, dst_pmd, pmd);
>
> Not sure, needs another thought. But I think there are some decent
> cleanups to be had.
That's fair. Maybe userfaultfd_protected() name is better for the VMA
check?
And about UFFD_WP bit name. Maybe we can just drop _WP: _PAGE_UFFD_WP ->
_PAGE_UFFD, pte_uffd_wp() -> pte_uffd()?
But it is a lot of changes. Can I do the bit rename as a follow up
patchset?
> 3) Some other stuff needs a second thought, like
>
> diff --git a/mm/gup.c b/mm/gup.c
> index 8e7dc2c6ee738..08fc18f1290d4 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -695,7 +695,8 @@ static inline bool can_follow_write_pmd(pmd_t pmd, struct page *page,
> /* ... and a write-fault isn't required for other reasons. */
> if (pmd_needs_soft_dirty_wp(vma, pmd))
> return false;
> - return !userfaultfd_huge_pmd_wp(vma, pmd);
> + return !userfaultfd_huge_pmd_wp(vma, pmd) &&
> + !userfaultfd_huge_pmd_rwp(vma, pmd);
> }
>
> How can a pte be writable and prot_none at the same time? Maybe just confused AI
> output that you should carefully double check before sending that out officially.
Note that this path is for !pmd_write() case to begin with. It serves
FOLL_FORCE case. I believe this check is correct: we don't want to allow
to write to such pages even with FOLL_FORCE.
But looking around, I missed gup_can_follow_protnone() modification. It
has to return false for RWP.
> 4) How do we want to handle PM_UFFD_WP?
>
> We are pretty much out of flags soon. Overloading PM_UFFD_WP means that we will not
> be able to easily support using a separate bit.
>
> But our internal design will not easily allow that either, and I am not really
> sure we want to go down that path any time soon.
>
> Maybe we could document this for now as "In WP VMAs, indicated WP PTEs.
> Otherwise, in RWP VMAs, indicates RWP.". Whenever we would allow both at the
> same time, we could change the semantics. User space would fail to create one
> with both protection types for now either way.
Yeah. I think about doing documentation-only update for PM_UFFD_WP for
now.
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH 16/23] genirq/cpuhotplug: Use RCU to protect access of HK_TYPE_MANAGED_IRQ cpumask
From: Waiman Long @ 2026-04-21 14:29 UTC (permalink / raw)
To: Thomas Gleixner, Tejun Heo, Johannes Weiner, Michal Koutný,
Jonathan Corbet, Shuah Khan, Catalin Marinas, Will Deacon,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Guenter Roeck, Frederic Weisbecker, Paul E. McKenney,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Anna-Maria Behnsen, Ingo Molnar,
Chen Ridong, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Ben Segall, Mel Gorman, Valentin Schneider,
K Prateek Nayak, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: cgroups, linux-doc, linux-kernel, linux-arm-kernel, linux-hyperv,
linux-hwmon, rcu, netdev, linux-kselftest, Costa Shulyupin,
Qiliang Yuan
In-Reply-To: <87qzo8bs9m.ffs@tglx>
On 4/21/26 5:02 AM, Thomas Gleixner wrote:
> On Mon, Apr 20 2026 at 23:03, Waiman Long wrote:
>
>> As HK_TYPE_MANAGED_IRQ cpumask is going to be changeable at run time,
>> use RCU to protect access to the cpumask.
>>
>> To enable the new HK_TYPE_MANAGED_IRQ cpumask to take effect, the
>> following steps can be done.
> Can be done?
>
>> 1) Update the HK_TYPE_MANAGED_IRQ cpumask to take out the newly isolated
>> CPUs and add back the de-isolated CPUs.
>> 2) Tear down the affected CPUs to cause irq_migrate_all_off_this_cpu()
>> to be called on the affected CPUs to migrate the irqs to other
>> HK_TYPE_MANAGED_IRQ housekeeping CPUs.
>> 3) Bring up the previously offline CPUs to invoke
>> irq_affinity_online_cpu() to allow the newly de-isolated CPUs to
>> be used for managed irqs.
> Which previously offline CPUs?
This part should go into another patch.
>
>> diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
>> index 2e8072437826..8270c4de260b 100644
>> --- a/kernel/irq/manage.c
>> +++ b/kernel/irq/manage.c
>> @@ -263,6 +263,7 @@ int irq_do_set_affinity(struct irq_data *data, const struct cpumask *mask, bool
>> housekeeping_enabled(HK_TYPE_MANAGED_IRQ)) {
>> const struct cpumask *hk_mask;
>>
>> + guard(rcu)();
>> hk_mask = housekeeping_cpumask(HK_TYPE_MANAGED_IRQ);
>>
>> cpumask_and(tmp_mask, mask, hk_mask);
> How is this hunk related to $Subject?
The subject is actually about using RCU to protect access to
housekeeping cpumask. There are extra info in the commit log that
should go to another patch.
Cheers,
Longman
>
^ 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