* Re: [PATCH v2 4/4] cpufreq: Use policy->min/max init as QoS request
From: Jie Zhan @ 2026-05-20 8:38 UTC (permalink / raw)
To: Pierre Gondois, linux-kernel
Cc: Lifeng Zheng, Ionela Voinescu, Sumit Gupta, Zhongqiu Han,
Rafael J. Wysocki, Viresh Kumar, Jonathan Corbet, Shuah Khan,
Huang Rui, Mario Limonciello, Perry Yuan, K Prateek Nayak,
Srinivas Pandruvada, Len Brown, Saravana Kannan, linux-pm,
linux-doc
In-Reply-To: <20260511135538.522653-5-pierre.gondois@arm.com>
On 5/11/2026 9:55 PM, Pierre Gondois wrote:
> Consider policy->min/max being set in the driver .init()
> callback as a QoS request. Impacted driver are:
> - gx-suspmod.c (min)
> - cppc-cpufreq.c (min)
> - longrun.c (min/max)
>
> Update the documentation accordingly.
>
> Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
> ---
> Documentation/cpu-freq/cpu-drivers.rst | 10 ++++++++--
> drivers/cpufreq/cpufreq.c | 12 ++++++++++--
> 2 files changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/cpu-freq/cpu-drivers.rst b/Documentation/cpu-freq/cpu-drivers.rst
> index c5635ac3de547..ab4f3c0f3a89b 100644
> --- a/Documentation/cpu-freq/cpu-drivers.rst
> +++ b/Documentation/cpu-freq/cpu-drivers.rst
> @@ -114,8 +114,14 @@ Then, the driver must fill in the following values:
> |policy->cur | The current operating frequency of |
> | | this CPU (if appropriate) |
> +-----------------------------------+--------------------------------------+
> -|policy->min, | |
> -|policy->max, | |
> +|policy->min | If set by the driver in ->init(), |
> +| | used as initial minimum frequency |
> +| | QoS request. |
> ++-----------------------------------+--------------------------------------+
> +|policy->max | If set by the driver in ->init(), |
> +| | used as initial maximum frequency |
> +| | QoS request. |
> ++-----------------------------------+--------------------------------------+
Hi Pierre,
Trivial bit: add the general meaning alongside its driver usage at the init
stage, and mention it defaults to cpuinfo_min/max_freq if not set?
I mean something like:
The minimum/maximum scaling frequency. If set by the driver in ->init(),
used as initial minimum/maximum frequency QoS request; otherwise, follow
policy->cpuinfo.min/max_freq.
Thanks,
Jie
> |policy->policy and, if necessary, | |
> |policy->governor | must contain the "default policy" for|
> | | this CPU. A few moments later, |
[ ... ]
^ permalink raw reply
* Re: [PATCH v3 0/5] Support the FEAT_HDBSS introduced in Armv9.5
From: Tian Zheng @ 2026-05-20 8:51 UTC (permalink / raw)
To: Will Deacon, maz, oupton, catalin.marinas, corbet, pbonzini,
Tian Zheng
Cc: kernel-team, yuzenghui, wangzhou1, liuyonglong, yezhenyu2,
joey.gouly, kvmarm, kvm, linux-arm-kernel, linux-doc,
linux-kernel, skhan, suzuki.poulose, leo.bras, Jonathan Cameron
In-Reply-To: <177918656142.736362.17906576792384645789.b4-ty@kernel.org>
On 5/19/2026 11:23 PM, Will Deacon wrote:
> On Wed, 25 Feb 2026 12:04:16 +0800, Tian Zheng wrote:
>> This series of patches add support to the Hardware Dirty state tracking
>> Structure(HDBSS) feature, which is introduced by the ARM architecture
>> in the DDI0601(ID121123) version.
>>
>> The HDBSS feature is an extension to the architecture that enhances
>> tracking translation table descriptors' dirty state, identified as
>> FEAT_HDBSS. This feature utilizes hardware assistance to achieve dirty
>> page tracking, aiming to significantly reduce the overhead of scanning
>> for dirty pages.
>>
>> [...]
>
> Applied sysreg definitions to arm64 (for-next/sysregs), thanks!
>
> [1/5] arm64/sysreg: Add HDBSS related register information
> https://git.kernel.org/arm64/c/72f7be0c2e30
>
> Cheers,
Thanks!
Tian
^ permalink raw reply
* Re: [PATCH v2 1/2] tools/mm: add a standalone GUP microbenchmark
From: Mike Rapoport @ 2026-05-20 8:55 UTC (permalink / raw)
To: Sarthak Sharma
Cc: Andrew Morton, David Hildenbrand, Jonathan Corbet,
Jason Gunthorpe, John Hubbard, Peter Xu, Lorenzo Stoakes,
Liam R . Howlett, Vlastimil Babka, Suren Baghdasaryan,
Michal Hocko, Shuah Khan, linux-mm, linux-kselftest, linux-kernel,
linux-doc, Mark Brown
In-Reply-To: <20260519120506.184512-2-sarthak.sharma@arm.com>
(added broonie)
Hi,
On Tue, May 19, 2026 at 05:35:05PM +0530, Sarthak Sharma wrote:
> Add a command-line tool for benchmarking get_user_pages fast-path
> (GUP_FAST), pin_user_pages fast-path (PIN_FAST), and pin_user_pages
> longterm (PIN_LONGTERM) via the CONFIG_GUP_TEST debugfs interface.
>
> When invoked without arguments, gup_bench runs the same matrix of
> configurations as run_gup_matrix() in run_vmtests.sh: all three GUP
> commands across read/write, private/shared mappings, and a range of
> page counts, with THP on/off for regular mappings and hugetlb for huge
> page mappings.
>
> This tool is a mix of reused and new logic. The mapping/setup path comes
> from selftests/mm/gup_test.c, while the default benchmark matrix matches
> run_gup_matrix() in run_vmtests.sh. The standalone CLI and tools/mm
> integration are added here so tools/mm does not depend on kselftest.
>
> Add gup_bench to BUILD_TARGETS and INSTALL_TARGETS in tools/mm/Makefile,
> and ignore the resulting binary in tools/mm/.gitignore. While here, also
> add the missing thp_swap_allocator_test entry to .gitignore.
>
> Add tools/mm/gup_bench.c to the GUP entry in MAINTAINERS.
>
> Suggested-by: David Hildenbrand (Arm) <david@kernel.org>
> Signed-off-by: Sarthak Sharma <sarthak.sharma@arm.com>
> ---
> MAINTAINERS | 1 +
> tools/mm/.gitignore | 2 +
> tools/mm/Makefile | 6 +-
> tools/mm/gup_bench.c | 491 +++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 497 insertions(+), 3 deletions(-)
> create mode 100644 tools/mm/gup_bench.c
...
> +/*
> + * Local HugeTLB setup helpers for gup_bench.
> + *
> + * These helpers were copied from tools/testing/selftests/mm/ and adjusted to
> + * remove the ksft formatting. Keep this copy local so tools/mm does not
> + * depend on ksft output behavior.
> + */
It looks like self tests of at least 5 subsystems beside mm use hugetlb:
$ git grep -l "Hugepagesize:" tools/testing/selftests/ | grep -v "selftests/mm"
tools/testing/selftests/arm64/mte/check_hugetlb_options.c
tools/testing/selftests/cgroup/test_hugetlb_memcg.c
tools/testing/selftests/kvm/lib/test_util.c
tools/testing/selftests/memfd/common.c
tools/testing/selftests/net/tcp_mmap.c
It seems that we need to better share the common code in
tools/testing/selftest.
And adding another copy of the hugetlb detection and setup code does not
seem like a great idea.
> +
> +static unsigned int psize(void)
> +{
> + static unsigned int __page_size;
> +
> + if (!__page_size)
> + __page_size = sysconf(_SC_PAGESIZE);
> + return __page_size;
> +}
> +
> +static unsigned long default_huge_page_size(void)
> +{
> + FILE *f = fopen("/proc/meminfo", "r");
> + unsigned long hpage_size = 0;
> + char buf[256];
> +
> + if (!f)
> + return 0;
> + while (fgets(buf, sizeof(buf), f)) {
> + if (sscanf(buf, "Hugepagesize: %lu kB", &hpage_size) == 1)
> + break;
> + }
> + fclose(f);
> + hpage_size <<= 10;
> + return hpage_size;
> +}
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH v2 1/2] tools/mm: add a standalone GUP microbenchmark
From: Dev Jain @ 2026-05-20 9:02 UTC (permalink / raw)
To: Mike Rapoport, Sarthak Sharma
Cc: Andrew Morton, David Hildenbrand, Jonathan Corbet,
Jason Gunthorpe, John Hubbard, Peter Xu, Lorenzo Stoakes,
Liam R . Howlett, Vlastimil Babka, Suren Baghdasaryan,
Michal Hocko, Shuah Khan, linux-mm, linux-kselftest, linux-kernel,
linux-doc, Mark Brown
In-Reply-To: <ag13GbKcLMIoHOHj@kernel.org>
On 20/05/26 2:25 pm, Mike Rapoport wrote:
> (added broonie)
>
> Hi,
>
> On Tue, May 19, 2026 at 05:35:05PM +0530, Sarthak Sharma wrote:
>> Add a command-line tool for benchmarking get_user_pages fast-path
>> (GUP_FAST), pin_user_pages fast-path (PIN_FAST), and pin_user_pages
>> longterm (PIN_LONGTERM) via the CONFIG_GUP_TEST debugfs interface.
>>
>> When invoked without arguments, gup_bench runs the same matrix of
>> configurations as run_gup_matrix() in run_vmtests.sh: all three GUP
>> commands across read/write, private/shared mappings, and a range of
>> page counts, with THP on/off for regular mappings and hugetlb for huge
>> page mappings.
>>
>> This tool is a mix of reused and new logic. The mapping/setup path comes
>> from selftests/mm/gup_test.c, while the default benchmark matrix matches
>> run_gup_matrix() in run_vmtests.sh. The standalone CLI and tools/mm
>> integration are added here so tools/mm does not depend on kselftest.
>>
>> Add gup_bench to BUILD_TARGETS and INSTALL_TARGETS in tools/mm/Makefile,
>> and ignore the resulting binary in tools/mm/.gitignore. While here, also
>> add the missing thp_swap_allocator_test entry to .gitignore.
>>
>> Add tools/mm/gup_bench.c to the GUP entry in MAINTAINERS.
>>
>> Suggested-by: David Hildenbrand (Arm) <david@kernel.org>
>> Signed-off-by: Sarthak Sharma <sarthak.sharma@arm.com>
>> ---
>> MAINTAINERS | 1 +
>> tools/mm/.gitignore | 2 +
>> tools/mm/Makefile | 6 +-
>> tools/mm/gup_bench.c | 491 +++++++++++++++++++++++++++++++++++++++++++
>> 4 files changed, 497 insertions(+), 3 deletions(-)
>> create mode 100644 tools/mm/gup_bench.c
>
> ...
>
>> +/*
>> + * Local HugeTLB setup helpers for gup_bench.
>> + *
>> + * These helpers were copied from tools/testing/selftests/mm/ and adjusted to
>> + * remove the ksft formatting. Keep this copy local so tools/mm does not
>> + * depend on ksft output behavior.
>> + */
>
> It looks like self tests of at least 5 subsystems beside mm use hugetlb:
>
> $ git grep -l "Hugepagesize:" tools/testing/selftests/ | grep -v "selftests/mm"
> tools/testing/selftests/arm64/mte/check_hugetlb_options.c
> tools/testing/selftests/cgroup/test_hugetlb_memcg.c
> tools/testing/selftests/kvm/lib/test_util.c
> tools/testing/selftests/memfd/common.c
> tools/testing/selftests/net/tcp_mmap.c
>
> It seems that we need to better share the common code in
> tools/testing/selftest.
>
> And adding another copy of the hugetlb detection and setup code does not
> seem like a great idea.
Does it sound too insane to just do some sort of #include "../testing/selftests/mm/..."
to use the common helpers?
>
>> +
>> +static unsigned int psize(void)
>> +{
>> + static unsigned int __page_size;
>> +
>> + if (!__page_size)
>> + __page_size = sysconf(_SC_PAGESIZE);
>> + return __page_size;
>> +}
>> +
>> +static unsigned long default_huge_page_size(void)
>> +{
>> + FILE *f = fopen("/proc/meminfo", "r");
>> + unsigned long hpage_size = 0;
>> + char buf[256];
>> +
>> + if (!f)
>> + return 0;
>> + while (fgets(buf, sizeof(buf), f)) {
>> + if (sscanf(buf, "Hugepagesize: %lu kB", &hpage_size) == 1)
>> + break;
>> + }
>> + fclose(f);
>> + hpage_size <<= 10;
>> + return hpage_size;
>> +}
>
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: iio: dac: Add AD5529R
From: Jonathan Cameron @ 2026-05-20 9:41 UTC (permalink / raw)
To: Janani Sunil
Cc: David Lechner, Janani Sunil, Lars-Peter Clausen,
Michael Hennerich, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Philipp Zabel, Jonathan Corbet,
Shuah Khan, linux-iio, devicetree, linux-kernel, linux-doc,
rodrigo.alencar
In-Reply-To: <e245de68-555a-42c8-900b-a4abbaa4ea3e@gmail.com>
On Tue, 19 May 2026 09:13:24 +0200
Janani Sunil <jan.sun97@gmail.com> wrote:
> On 5/16/26 21:25, David Lechner wrote:
> > On 5/8/26 7:48 AM, Jonathan Cameron wrote:
> >> On Fri, 8 May 2026 13:55:47 +0200
> >> Janani Sunil <janani.sunil@analog.com> wrote:
> >>
> >>> Devicetree bindings for AD5529R 16 channel 12/16 bit high voltage,
> >>> buffered voltage output digital-to-analog converter (DAC) with an
> >>> integrated precision reference.
> >>>
> >>> Signed-off-by: Janani Sunil <janani.sunil@analog.com>
> >>> ---
> > ...
> >
> >>> + * Multiplexer for output voltage, load current sense and die temperature
> >>> +
> >>> + Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/ad5529r.pdf
> >>> +
> >>> +properties:
> >>> + compatible:
> >>> + const: adi,ad5529r
> >>> +
> >>> + reg:
> >>> + maxItems: 1
> >>> +
> >>> + spi-max-frequency:
> >>> + maximum: 50000000
> >>> +
> >>> + reset-gpios:
> >>> + maxItems: 1
> >>> + description:
> >>> + GPIO connected to the RESET pin. Active low. When asserted low,
> >>> + performs a power-on reset and initializes the device to its default state.
> >>> +
> >>> + vdd-supply:
> >>> + description: Digital power supply (typically 3.3V)
> >>> +
> >>> + avdd-supply:
> >>> + description: Analog power supply (typically 5V)
> >>> +
> >>> + hvdd-supply:
> >>> + description: High voltage positive supply (up to 40V for output range)
> >>> +
> >>> + hvss-supply:
> >>> + description: High voltage negative supply (ground or negative voltage)
> >> I don't mind doing it this way but in some similar cases where 0 is something that
> >> can be considered the 'default' we've made the supply optional. What was
> >> your reasoning for requiring it in this case?
> >>
> >> dt-bindings should be as complete as we can make them - with that in mind...
> >>
> >> There are some more interesting corners on this device the binding doesn't
> >> currently cover such as mux_out pin. We'd normally do that by making the
> >> driver potentially a client of an ADC
> >>
> >> Easier though is !alarm which smells like an interrupt.
> >> !clear probably a gpio. TG0-3 also GPIOs.
> > also optional vref-supply for external vs internal reference
>
> I will add bindings for optional Vref supply in the next version.
>
> Best Regards,
> Janani Sunil
Hi Janil
One of those process things. Don't reply to a review to say you
are going to do something suggested - just save us all reading an email
by making that clear in the change log for the next version.
Lots of folk are over enthusiastic in replying like you have done initially.
They only begin to appreciate why this is a bad idea when they start trying
to keep up with the mailing list firehoses!
Jonathan
>
^ permalink raw reply
* Re: [PATCH] dcache: add fs.dentry-limit sysctl with negative-first reaper
From: Amir Goldstein @ 2026-05-20 9:43 UTC (permalink / raw)
To: Ian Kent
Cc: Jan Kara, NeilBrown, Horst Birthelmer, Miklos Szeredi,
Jonathan Corbet, Shuah Khan, Alexander Viro, Christian Brauner,
linux-doc, linux-kernel, linux-fsdevel, Horst Birthelmer
In-Reply-To: <27a5593e-ffb8-4471-996f-7983bac0b1ab@themaw.net>
On Wed, May 20, 2026 at 9:16 AM Ian Kent <raven@themaw.net> wrote:
>
> On 19/5/26 17:12, Jan Kara wrote:
> > On Mon 18-05-26 21:39:13, Ian Kent wrote:
> >> On 18/5/26 16:19, Jan Kara wrote:
> >>> Hi Ian,
> >>>
> >>> On Mon 18-05-26 10:55:43, Ian Kent wrote:
> >>>> On 18/5/26 07:55, NeilBrown wrote:
> >>>>> On Fri, 15 May 2026, Horst Birthelmer wrote:
> >>>>> According to the email you linked, a problem arises when a directory has
> >>>>> a great many negative children. Code which walks the list of children
> >>>>> (such as fsnotify) while holding a lock can suffer unpredictable delays
> >>>>> and result in long lock-hold times. So maybe a limit on negative
> >>>>> dentries for any parent is what we really want. That would be clumsy to
> >>>>> implement I imagine.
> >>>> But the notion of dropping the dentry in ->d_delete() on last dput() is
> >>>> simple enough but did see regressions (the only other place in the VFS
> >>>> besides dentry_kill() that the inode is unlinked from the dentry on
> >>>> dput()). I wonder if the regression was related to the test itself
> >>>> deliberately recreating deleted files and if that really is normal
> >>>> behaviour. By itself that should prevent almost all negative dentries
> >>>> being retained. Although file systems could do this as well (think XFS
> >>>> inode recycling) it should be reasonable to require it be left to the
> >>>> VFS.
> >>>>
> >>>> But even that's not enough given that, in my case, there would still be
> >>>> around 4 million dentries in the LRU cache and in fsnotify there are
> >>>> directory child traversals holding the parent i_lock "spinlock" that are
> >>>> going to cause problems.
> >>> Do you mean there are very many positive children of a directory?
> >> Didn't quantify that.
> >>
> >> The symptom is the "Spinlock held for more than ... seconds" occurring in
> >> the log. So there are certainly a lot of children in the list, but it's
> >> an assumption the ratio of positive to negative entries is roughly the
> >> same as the overall ratio in the dcache.
> > OK, but that's not necessarily true. I have seen these complaints from the
> > kernel but in all the cases I remember it was due to negative dentries
> > accumultating in a particular directory. There are certain apps such as
> > ElasticSearch which really do like creating huge amounts of negative
> > dentries in one directory - they use hashes as filenames and use directory
> > lookup instead of a DB table lookup and lookup lots of non-existent keys...
>
> Umm ... that's a good point, I hadn't paid much attention to ENOENT result
>
> lookups, I'll need to check on the like cycle of those, I think they do get
>
> hashed. That has to be the other source of negative dentries that I've
>
> neglected ...
>
Yes, it has been claimed that some real life workloads create a lot of those.
If we can keep those at the tail of the children list, it will be best
for the fsnotify
iteration, which only cares about positive dentries.
> >
> >>>> so why is this traversal even retained in fsnotify?
> >>> Not sure which traversal you mean but if you set watch on a parent, you
> >>> have to walk all children to set PARENT_WATCHED flag so that you don't miss
> >>> events on children...
> >> Yes, that traversal is what I'm questioning ... again thanks.
> >>
> >> I think the function name is still fsnotify_set_children_dentry_flags()
> >> in recent kernels, the subject of commit 172e422ffea2 I mentioned above.
> > OK, thanks.
> >
> >> When you say miss events are you saying that accessing the parent dentry to
> >> work out if the child needs to respond to an event is quite expensive in the
> >> overall event processing context, that might make more sense to me ... or do
> >> I completely not yet understand the reasoning behind the need for the flag?
> > Close but not quite. The cost is the overhead of dget_parent() in
> > fsnotify_parent() which is often a couple of cache cold loads and atomic
> > instructions to find out we don't need to send any event for the current
> > write(2) or read(2) call. It gets worse if there are many IOs happening to
> > dentries in the same directory from multiple CPUs because instead of
> > cache-cold loads you get a cacheline contention on the parent.
> >
> >>>>> But what if we move dentries to the end of the list when they become
> >>>>> negative, and to the start of the list when they become positive? Then
> >>>>> code which walks the child list could simply abort on the first
> >>>>> negative.
> >>>>>
> >>>>> I doubt that would be quite as easy as it sounds, but it would at least
> >>>>> be more focused on the observed symptom rather than some whole-system
> >>>>> number which only vaguely correlates with the observed symptom.
> >>>>>
> >>>>> Maybe a completely different approach: change children-walking code to
> >>>>> drop and retake the lock (with appropriate validation) periodically.
> >>>>> What too would address the specific symptom.
> >>>> Another good question.
> >>>>
> >>>> I have assumed that dropping and re-taking the lock cannot be done but
> >>>> this is a question I would like answered as well. Dropping and re-taking
> >>>> lock would require, as Miklos pointed out to me off-list, recording the
> >>>> list position with say a cursor, introducing unwanted complexity when it
> >>>> would be better to accept the cost of a single extra access to the parent
> >>>> flags (which I assume is one reason to set the flag in the child).
> >>> The parent access is actually more expensive than you might think. Based on
> >>> experience with past fsnotify related performance regression I expect some
> >>> 20% performance hit for small tmpfs writes if you add unconditional parent
> >>> access to the write path.
> >> That sounds like a lot for what should be a memory access of an already in
> >> memory structure since the parent must be accessed to traverse the list of
> >> child entries. I clearly don't fully understand the implications of what
> >> I'm saying but there has been mention of another context ...
> > Parent dentry is of course in memory but often cache cold - you don't need
> > the parent to do e.g. write(2) to an already open file. You seem to be
> > somewhat confused about the child dentry list traversal (or maybe I'm
> > misunderstanding) - that happens only when placing the notification mark
> > but definitely not for each IO operation.
>
> LOL, confusion is a pretty common state of mind for me!
>
>
> I do get your point though and I am confusing the traversal with other
>
> operations. I think this answers the question I've been asking (maybe
>
> that wasn't obvious) about the reason for the traversal (ie. the reason
>
> to maintain a flag in the child).
>
>
> While I have looked at the code here I haven't absorbed it and I
>
> definitely don't understand it, your continued patience is appreciated
>
> and will be beneficial when I get time to look at it a bit closer. I
>
> do still need to use a notifications mechanism to match up with Miklos's
>
> statmount implementation to get the full benefit of that in user space,
>
> if I ever get a chance to work on that again.
>
>
> So it sounds like it would be worth while considering a traversal that's
>
> based on taking a reference on each dentry rather than a spinlock for
>
> the duration. It would be tricky though, for obvious reasons, like
>
> children added during the traversal, added overhead of getting the next
>
> entry reference, etc.
Didn't look closely, but it feels like RCU traversal should be
possible if entries are added to the tail, or to the END_OF_POSITIVE
location.
When we discussed the "negavites at tail" at LSFMM
it was said that managing the transitions positive<->negative
would be challenging, but I don't know that anyone tried to look closer at this.
At least for fsnotify, positive->negative transition is not a problem
w.r.t skipping entry and observing entry twice during positive iteration.
If negative->positive transitions inserts at END_OF_POSITIVE
location, then should be fine as well?
Iterators that need to iterate all children can do this under lock.
Does that make sense?
Thanks,
Amir.
^ permalink raw reply
* Re: [PATCH RFC v4 09/10] Documentation: ABI: testing: add docs for ad9910 sysfs entries
From: Jonathan Cameron @ 2026-05-20 9:54 UTC (permalink / raw)
To: Rodrigo Alencar
Cc: Rodrigo Alencar via B4 Relay, rodrigo.alencar, linux-iio,
devicetree, linux-kernel, linux-doc, linux-hardening,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel, Jonathan Corbet, Shuah Khan, Kees Cook,
Gustavo A. R. Silva
In-Reply-To: <pkx5v4od3wkyyzxomfrjf4ei7leboadzth262xnl55fvu76pf3@yqrezmo6gtq7>
On Mon, 18 May 2026 16:27:23 +0100
Rodrigo Alencar <455.rodrigo.alencar@gmail.com> wrote:
> On 26/05/18 02:45PM, Jonathan Cameron wrote:
> > On Sun, 17 May 2026 18:30:27 +0100
> > Rodrigo Alencar <455.rodrigo.alencar@gmail.com> wrote:
> >
> > > On 26/05/17 03:58PM, Jonathan Cameron wrote:
> > > > On Fri, 08 May 2026 18:00:25 +0100
> > > > Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
> > > >
> > > > > From: Rodrigo Alencar <rodrigo.alencar@analog.com>
> > > > >
> > > > > Add custom ABI documentation file for the DDS AD9910 with sysfs entries to
> > > > > control Parallel Port, Digital Ramp Generator and OSK parameters.
> > > > >
> > > > > Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
> > > > I'm fine with phase and frequency as defined, but for the scaling it made me wonder.
> > > > For outvoltage0 channels the assumption the value is the peak voltage so if
> > > > we know what input to be modulated by the ramp generator can we express them
> > > > in volts (well milivolts) rather than as a scaling multiplier?
> > >
> > > The DAC output is current-based and differential. Voltage conversion would happen
> > > outside the device...
> >
> > Why aren't we representing this as out_altcurrentX-Y_xxxx?
>
> Good point! altcurrent makes more sense than altvoltage if we want to use raw to
> control the output level rather than scale, which would be a constant to convert
> raw into current units (what is the one that is used in the sysfs ABI? Ampere, mA or uA?)
Same as non alternating version so mA (which is a historical design error we have
long been stuck with :() The altvoltageY_raw docs don't give a unit either.
If you don't mind, please send a patch adding that whilst you are here.
Same mid to peak - hopefully that is what any users not modifying to RMS have
been doing!
Seems we either never had one or that particular bit of ABI doc is missing.
Please add an entry for altcurrentX_raw
>
> Not sure about the benefits on setting "differential" in channel spec.. the name would
> become out_altcurrentX-altcurrentY_xxxxx...
Becomes a question of whether it is useful to represent that - maybe not
in this particular case.
>
> Is there any modifier for amplitude/peak/envelope? I see IIO_MOD_RMS, which could be used
> if adding a 1/sqrt(2) factor to the fixed scale.
For altcurrent / altvoltage assumption is it's mid to peak. Unless the modifier switches
it to RMS as you've noted.
>
> Then, I would consider something like out_altcurrent_rms_xxxx as a good alternative.
>
> "scale" would be a constant in the top-level phy channel
>
> single tone profile channels would have:
> - frequency
> - phase
> - raw
>
> drg ramp up/down channels:
> - frequency and frequency_roc
> - phase and phase_roc
> - raw and raw_roc
>
> parallel port channel(s):
> - frequency_scale and frequency_offset (frequency destination)
> - phase_offset (polar destination)
> - offset (polar destination)
>
> osk channel:
> - raw
> - raw_roc
>
> raw_roc could be just roc, but that sounds like it carries the scale and refers to
> a current value? and maybe that breaks consistency with other destination attributes?
> I am fine with just roc if that refers to the raw value, not (raw * scale).
This is a good question. We ran into ambiguity with events where we have to derive
if it is _raw or _processed for the thresholds based on whether the main attribute
is _raw or _processed. Nice to avoid doing that again.
I'd be interesting in others views on this but to me raw_roc seems fine.
>
> With all the above, still using altvoltage is not incorrect, just a matter on how
> we want to express the units.
Agreed - but to get to directly useable values we'd need to provide info on the
external circuit - and given we are dealing with AC signals that is tricky to do
in a compact way.
> Note that using raw instead of scale to control the
> amplitude is just another option to tackle the problem. I suppose that the
> important thing here is being technically corrent and consistent in terms of
> usage. Maybe out_altcurrent_rms_* is more clear in terms of amplitude level.
Agreed. It is always (?) possible to switch between scale and raw.
For an ADC the distinction is clear as we can't control _raw. For a DAC it all gets
rather value as we can logically control both and for an AC type of DAC / DDS it
all gets less intuitive. As you say, consistency is key.
I'd like us to at least be consistent across DDS devices. Perhaps we need some
general documentation on whatever the outcome of this discussion is to record
some of the logic behind those decisions.
>
> >
> >
> > > using a resistor load or an op-amp transimpedance stage,
> > > and I am no expert on that, but that often requires impedance matching so voltage
> > > levels may depend on the frequency. Then, I suppose that voltage is not the right
> > > unit to use.
> >
> > Understood that it can get complex!
> > >
> > > The scale here controls the amplitude of the varying signal. Assuming the peak voltage
> > > (amplitude) is constant means we have a constant envelope, but that should not mean
> > > we can't control it or it should not mean that the hardware can have other ways to
> > > control it. That said, scale behaves as a "gain multiplier".
> > Understood. Given it's the envelope then if scale happened to be 1 always it would
> > be presented as _processed. So this is consistent with other channel types.
> >
> > >
> > > >
> > > > That seems to me like it fits better with the overall ABI.
> > > >
> > > > > +What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_scale_offset
> > > > > +KernelVersion:
> > > > > +Contact: linux-iio@vger.kernel.org
> > > > > +Description:
> > > > > + For a channel that allows amplitude control through buffers, this
> > > > > + represents the value for a base amplitude scale. The actual output
> > > > > + amplitude scale is a result with the sum of this value.
> > > > > +
> > > >
> > > > > +
> > > > > +What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_scale_roc
> > > >
> > > > Silly question perhaps but can work out how this related to millivolts/sec
> > > > That might make a more intuitive interface than scaling multiplier per sec
> > > > Perhaps the combination with offset makes this impossible though maybe that
> > > > could be a expressed as a voltage offset? Afterall if the amplitude being
> > > > scaled is 5V then 5 * (offset + scale) = 5 * offset + 5 * scale
> > > >
> > > > > +KernelVersion:
> > > > > +Contact: linux-iio@vger.kernel.org
> > > > > +Description:
> > > > > + Amplitude scale rate of change in 1/s for channels that ramp
> > > > > + amplitude. This value may be influenced by the channel's
> > > > > + sampling_frequency setting.
> > > >
> > > >
> > >
> >
>
^ permalink raw reply
* Re: [PATCH RESEND bpf-next v10 2/8] bpf: clear list node owner and unlink before drop
From: Kaitao Cheng @ 2026-05-20 9:55 UTC (permalink / raw)
To: Eduard Zingerman
Cc: bpf, Alexei Starovoitov, linux-kernel, linux-doc, ast, memxor,
corbet, martin.lau, daniel, andrii, song, yonghong.song,
john.fastabend, kpsingh, sdf, haoluo, jolsa, shuah, chengkaitao,
skhan, vmalik, linux-kselftest, martin.lau, clm, ihor.solodrai,
bot+bpf-ci
In-Reply-To: <782833db5da77e4aa9761fc410827e7abe8583c8.camel@gmail.com>
在 2026/5/20 06:56, Eduard Zingerman 写道:
> On Mon, 2026-05-18 at 11:02 +0800, Kaitao Cheng wrote:
>
> [...]
>
>>>>> The patch does have a bug, however. To fix the issues we are seeing now,
>>>>> I propose the additional changes below and would appreciate feedback.
>>>>>
>>>>> --- a/kernel/bpf/helpers.c
>>>>> +++ b/kernel/bpf/helpers.c
>>>>> @@ -2263,8 +2263,10 @@ void bpf_list_head_free(const struct btf_field *field, void *list_head,
>>>>> if (!head->next || list_empty(head))
>>>>> goto unlock;
>>>>> list_for_each_safe(pos, n, head) {
>>>>> - WRITE_ONCE(container_of(pos,
>>>>> - struct bpf_list_node_kern, list_head)->owner, NULL);
>>>>> + struct bpf_list_node_kern *node;
>>>>> +
>>>>> + node = container_of(pos, struct bpf_list_node_kern, list_head);
>>>>> + WRITE_ONCE(node->owner, BPF_PTR_POISON);
>>>>> list_move_tail(pos, &drain);
>>>>> }
>>>>> unlock:
>>>>> @@ -2272,8 +2274,12 @@ void bpf_list_head_free(const struct btf_field *field, void *list_head,
>>>>> __bpf_spin_unlock_irqrestore(spin_lock);
>>>>>
>>>>> while (!list_empty(&drain)) {
>>>>> + struct bpf_list_node_kern *node;
>>>>> +
>>>>> pos = drain.next;
>>>>> + node = container_of(pos, struct bpf_list_node_kern, list_head);
>>>>> list_del_init(pos);
>>>>> + WRITE_ONCE(node->owner, NULL);
>
> Is CPU allowed to reorder the stores in list_del_init() and WRITE_ONCE()?
> If it is, I think there is a race here.
Thanks for taking a close look at this. You are right that there is an
ordering issue here, but I don't think the specific sequence illustrated
by the example below is problematic.
> Thread #1:
> enter bpf_list_head_free()
> acquire H1 lock
> list_move_tail(pos, &drain); // reordered
> <-- ip here -->
> WRITE_ONCE(node->owner, BPF_PTR_POISON); // reordered
>
> Thread #2:
>
> acquire H1 lock
> n = bpf_refcount_acquire()
> release H1 lock
> acquire H2 lock
> enter __bpf_list_add()
> <-- ip here -->
> cmpxchg(&node->owner, NULL, BPF_PTR_POISON)
Even if the stores from list_move_tail(pos, &drain) become visible before
WRITE_ONCE(node->owner, BPF_PTR_POISON), node->owner is not NULL in that
window. Before the WRITE_ONCE(), it still points to H1. After the WRITE_ONCE(),
it is BPF_PTR_POISON. In both cases, __bpf_list_add() will fail:
cmpxchg(&node->owner, NULL, BPF_PTR_POISON)
because the old value is neither NULL nor expected to become NULL from this
part of bpf_list_head_free().
However, I agree that your original concern about the ordering between
list_del_init() and WRITE_ONCE(node->owner, NULL) is valid for the later
drain loop:
list_del_init(pos);
WRITE_ONCE(node->owner, NULL);
Here owner == NULL is the signal that the node can be inserted into another
list. Since WRITE_ONCE() does not provide release ordering, another CPU may
observe owner == NULL and successfully acquire the node in __bpf_list_add()
before the list_del_init() stores are visible. In that case __bpf_list_add()
can link the node into H2, and the delayed stores from list_del_init() may
then overwrite the node's list pointers and corrupt the H2 list.
So the fix should be to publish owner == NULL with release ordering after the
node has been fully unlinked, for example:
```
--- a/kernel/bpf/helpers.c
+++ b/kernel/bpf/helpers.c
@@ -2279,7 +2279,8 @@ void bpf_list_head_free(const struct btf_field *field, void *list_head,
pos = drain.next;
node = container_of(pos, struct bpf_list_node_kern, list_head);
list_del_init(pos);
- WRITE_ONCE(node->owner, NULL);
+ /* Ensure __bpf_list_add() sees the node as unlinked. */
+ smp_store_release(&node->owner, NULL);
/* The contained type can also have resources, including a
* bpf_list_head which needs to be freed.
*/
@@ -2607,7 +2608,8 @@ static struct bpf_list_node *__bpf_list_del(struct bpf_list_head *head,
return NULL;
list_del_init(n);
- WRITE_ONCE(node->owner, NULL);
+ /* Ensure __bpf_list_add() sees the node as unlinked. */
+ smp_store_release(&node->owner, NULL);
return (struct bpf_list_node *)n;
}
```
The existing cmpxchg() in __bpf_list_add() is a successful RMW with return
value, so it is fully ordered and is sufficient on the acquire side.
--
Thanks
Kaitao Cheng
^ permalink raw reply
* Re: [PATCH net-next v2 2/2] net: ti: icssg: Add HSR and LRE PA statistics
From: MD Danish Anwar @ 2026-05-20 10:00 UTC (permalink / raw)
To: Jakub Kicinski, Luka Gejak
Cc: Felix Maurer, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Roger Quadros,
Andrew Lunn, Meghana Malladi, Jacob Keller, David Carlier,
Vadim Fedorenko, Kevin Hao, netdev, linux-doc, linux-kernel,
linux-arm-kernel, Vladimir Oltean
In-Reply-To: <20260519165646.09b0783f@kernel.org>
Hi Jakub,
On 20/05/26 5:26 am, Jakub Kicinski wrote:
> On Tue, 19 May 2026 07:55:55 +0200 Luka Gejak wrote:
>> On May 19, 2026 3:45:06 AM GMT+02:00, Jakub Kicinski <kuba@kernel.org> wrote:
>>> On Thu, 14 May 2026 13:26:05 +0530 MD Danish Anwar wrote:
>>>> Add new firmware PA statistics counters for HSR and LRE to the ethtool
>>>> statistics exposed by the ICSSG driver.
>>>>
>>>> New statistics added:
>>>> - FW_HSR_FWD_CHECK_FAIL_DROP: Packets dropped on the HSR forwarding path
>>>> - FW_HSR_HE_CHECK_FAIL_DROP: Packets dropped on the HSR host egress path
>>>> - FW_HSR_SKIP_HOST_DUP_DISCARD_FRAMES: Frames with duplicate discard
>>>> skipped
>>>> - FW_LRE_CNT_UNIQUE/DUPLICATE/MULTIPLE_RX: LRE duplicate detection
>>>> counters
>>>> - FW_LRE_CNT_RX/TX: LRE per-port frame counters
>>>> - FW_LRE_CNT_OWN_RX: Own HSR tagged frames received
>>>> - FW_LRE_CNT_ERRWRONGLAN: Frames with wrong LAN identifier (PRP)
>>>>
>>>> Document the new HSR/LRE statistics in icssg_prueth.rst.
>>>
>>> To an untrained eye these stats look like stuff that could
>>> be standardized across drivers.
>>>
>>> Luka, Felix, others on CC, do you think we should expose these
>> >from HSR over netlink as "standard" offload stats different drivers
>>> can plug into or not worth it?
>>
>> I think there is a case for standardizing part of this, but I would
>> not standardize the whole set as-is.
>>
>> The LRE counters look generic enough to me, especially:
>> - unique rx
>> - duplicate rx
>> - multiple rx
>> - rx / tx
>> - own rx
>> - wrong LAN, PRP only
>>
>> Those are protocol/LRE concepts rather than TI firmware details, so
>> exposing them from the HSR/PRP layer sounds useful. I would expect
>> both the software implementation and offloaded implementations to be
>> able to provide at least some of them, with unsupported counters
>> omitted or reported as not available.
>> I would not put the firmware check/drop counters in the same standard
>> bucket, though:
>> - FW_HSR_FWD_CHECK_FAIL_DROP
>> - FW_HSR_HE_CHECK_FAIL_DROP
>> - FW_HSR_SKIP_HOST_DUP_DISCARD_FRAMES
>
> Thanks for the breakdown!
>
>> Those sound more like implementation/debug counters for the ICSSG
>> firmware pipeline. They are still useful in ethtool driver stats, but
>> I would be hesitant to bake their exact semantics into HSR UAPI.
>> So my preference would be:
>> 1. Keep driver-private ethtool stats for the full firmware counter set.
>> 2. Add a small HSR/PRP standard stats set separately, limited to
>> well-defined LRE counters.
>> 3. Make the HSR layer expose them, with offload drivers plugging in via
>> an optional callback or offload stats op.
>> 4. Define the counters carefully, including whether they are per-HSR
>> device or per-port A/B, and what PRP-only counters mean for HSR.
>>
>> I do not think this patch should blindly become the UAPI definition,
>
> Not at all, the unique / multiple stats gave me pause. We should
> only put in the standard API what can be easily and unambiguously
> defined given the protocol spec.
>
>> but I do think it points at a useful follow-up. If we want to avoid
>> adding driver-private names first and then standardizing different
>> names later, then it may be worth asking Danish to split the
>> protocol-level LRE counters out and route those through a common HSR
>> stats interface.
>
> As a general policy we ask for standard stats to be added first and
> ethtool to only contain what didn't fit in the standard ones.
> There are some technical reasons but it's mostly a mindset thing.
What should be the next steps here? Is there any existing defined set of
stats where I could populate stats from ICSSG firmware for HSR (similar
to ndo_get_stats64 callback). Or de we need to implement a new callback
that will do this for HSR.
I agree with Luka on the categorization,
Below stats can be generic,
- unique rx
- duplicate rx
- multiple rx
- rx / tx
- own rx
- wrong LAN, PRP only
Below stats can be driver specific and can be pulled using `ethtool -S`
on child interfaces of HSR
- FW_HSR_FWD_CHECK_FAIL_DROP
- FW_HSR_HE_CHECK_FAIL_DROP
- FW_HSR_SKIP_HOST_DUP_DISCARD_FRAMES
Let me know if I should go ahead and implement this.
--
Thanks and Regards,
Danish
^ permalink raw reply
* Re: [PATCH v2 4/4] cpufreq: Use policy->min/max init as QoS request
From: Viresh Kumar @ 2026-05-20 10:03 UTC (permalink / raw)
To: Pierre Gondois
Cc: linux-kernel, Jie Zhan, Lifeng Zheng, Ionela Voinescu,
Sumit Gupta, Zhongqiu Han, Rafael J. Wysocki, Jonathan Corbet,
Shuah Khan, Huang Rui, Mario Limonciello, Perry Yuan,
K Prateek Nayak, Srinivas Pandruvada, Len Brown, Saravana Kannan,
linux-pm, linux-doc
In-Reply-To: <20260511135538.522653-5-pierre.gondois@arm.com>
On 11-05-26, 15:55, Pierre Gondois wrote:
> @@ -1399,8 +1399,16 @@ static void cpufreq_policy_free(struct cpufreq_policy *policy)
>
> static int cpufreq_policy_init_qos(struct cpufreq_policy *policy)
> {
> + unsigned int min_freq, max_freq;
> int ret;
>
> + /* Use policy->min/max set by the driver as QoS requests. */
> + min_freq = max(FREQ_QOS_MIN_DEFAULT_VALUE, policy->min);
> + if (policy->max)
> + max_freq = min(FREQ_QOS_MAX_DEFAULT_VALUE, policy->max);
> + else
> + max_freq = FREQ_QOS_MAX_DEFAULT_VALUE;
> +
Why is this required to be done before setting policy->min/max ? And
so I don't think patch 1/4 is required at all.
> /*
> * If the driver didn't set policy->min/max, set them as
> * they are used to clamp frequency requests.
> @@ -1418,12 +1426,12 @@ static int cpufreq_policy_init_qos(struct cpufreq_policy *policy)
> }
>
> ret = freq_qos_add_request(&policy->constraints, &policy->min_freq_req,
> - FREQ_QOS_MIN, FREQ_QOS_MIN_DEFAULT_VALUE);
> + FREQ_QOS_MIN, min_freq);
> if (ret < 0)
> return ret;
>
> ret = freq_qos_add_request(&policy->constraints, &policy->max_freq_req,
> - FREQ_QOS_MAX, FREQ_QOS_MAX_DEFAULT_VALUE);
> + FREQ_QOS_MAX, max_freq);
> if (ret < 0)
> return ret;
>
> --
> 2.43.0
--
viresh
^ permalink raw reply
* Re: [PATCH v4 1/4] Introducing pw_lock() and per-cpu queue & flush work
From: Frederic Weisbecker @ 2026-05-20 10:08 UTC (permalink / raw)
To: Leonardo Bras
Cc: Jonathan Corbet, Shuah Khan, Peter Zijlstra, Ingo Molnar,
Will Deacon, Boqun Feng, Waiman Long, Andrew Morton,
David Hildenbrand, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Jann Horn, Pedro Falcato, Brendan Jackman, Johannes Weiner,
Zi Yan, Harry Yoo, Hao Li, Christoph Lameter, David Rientjes,
Roman Gushchin, Chris Li, Kairui Song, Kemeng Shi, Nhat Pham,
Baoquan He, Barry Song, Youngjun Park, Qi Zheng, Shakeel Butt,
Axel Rasmussen, Yuanchu Xie, Wei Xu, Borislav Petkov (AMD),
Randy Dunlap, Feng Tang, Dapeng Mi, Kees Cook, Marco Elver,
Jakub Kicinski, Li RongQing, Eric Biggers, Paul E. McKenney,
Nathan Chancellor, Nicolas Schier, Miguel Ojeda,
Thomas Weißschuh, Thomas Gleixner, Douglas Anderson,
Gary Guo, Christian Brauner, Pasha Tatashin, Coiby Xu,
Masahiro Yamada, linux-doc, linux-kernel, linux-mm,
linux-rt-devel, Marcelo Tosatti
In-Reply-To: <20260519012754.240804-2-leobras.c@gmail.com>
Le Mon, May 18, 2026 at 10:27:47PM -0300, Leonardo Bras a écrit :
> Some places in the kernel implement a parallel programming strategy
> consisting on local_locks() for most of the work, and some rare remote
> operations are scheduled on target cpu. This keeps cache bouncing low since
> cacheline tends to be mostly local, and avoids the cost of locks in non-RT
> kernels, even though the very few remote operations will be expensive due
> to scheduling overhead.
>
> On the other hand, for RT workloads this can represent a problem:
> scheduling work on remote cpu that are executing low latency tasks
> is undesired and can introduce unexpected deadline misses.
>
> It's interesting, though, that local_lock()s in RT kernels become
> spinlock(). We can make use of those to avoid scheduling work on a remote
> cpu by directly updating another cpu's per_cpu structure, while holding
> it's spinlock().
>
> In order to do that, it's necessary to introduce a new set of functions to
> make it possible to get another cpu's per-cpu "local" lock (pw_{un,}lock*)
> and also do the corresponding queueing (pw_queue_on()) and flushing
> (pw_flush()) helpers to run the remote work.
>
> Users of non-RT kernels but with low latency requirements can select
> similar functionality by using the CONFIG_PWLOCKS compile time option.
>
> On CONFIG_PWLOCKS disabled kernels, no changes are expected, as every
> one of the introduced helpers work the exactly same as the current
> implementation:
> pw_{un,}lock*() -> local_{un,}lock*() (ignores cpu parameter)
> pw_queue_on() -> queue_work_on()
> pw_flush() -> flush_work()
>
> For PWLOCKS enabled kernels, though, pw_{un,}lock*() will use the extra
> cpu parameter to select the correct per-cpu structure to work on,
> and acquire the spinlock for that cpu.
>
> pw_queue_on() will just call the requested function in the current
> cpu, which will operate in another cpu's per-cpu object. Since the
> local_locks() become spinlock()s in PWLOCKS enabled kernels, we are
> safe doing that.
>
> pw_flush() then becomes a no-op since no work is actually scheduled on a
> remote cpu.
>
> Some minimal code rework is needed in order to make this mechanism work:
> The calls for local_{un,}lock*() on the functions that are currently
> scheduled on remote cpus need to be replaced by either pw_{un,}lock_*(),
> PWLOCKS enabled kernels they can reference a different cpu. It's also
> necessary to use a pw_struct instead of a work_struct, but it just
> contains a work struct and, in CONFIG_PWLOCKS, the target cpu.
>
> This should have almost no impact on non-CONFIG_PWLOCKS kernels: few
> this_cpu_ptr() will become per_cpu_ptr(,smp_processor_id()) on non-hotpath
> functions.
>
> On CONFIG_PWLOCKS kernels, this should avoid deadlines misses by
> removing scheduling noise.
>
> Signed-off-by: Leonardo Bras <leobras.c@gmail.com>
> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
I like it! Just a few observations:
> +#ifndef CONFIG_PWLOCKS
> +
> +typedef local_lock_t pw_lock_t;
> +typedef local_trylock_t pw_trylock_t;
> +
> +struct pw_struct {
> + struct work_struct work;
> +};
> +
> +#define pw_lock_init(lock) \
> + local_lock_init(lock)
> +
> +#define pw_trylock_init(lock) \
> + local_trylock_init(lock)
> +
> +#define pw_lock(lock, cpu) \
> + local_lock(lock)
For debugging purpose, it would be nice to ensure that in those off-case,
cpu is indeed the local one. Basically all the non-local functions, those that
take a cpu, should verify:
lockdep_assert(cpu == smp_processor_id())
> +
> +#define pw_lock_local(lock) \
> + local_lock(lock)
> +
> +#define pw_lock_irqsave(lock, flags, cpu) \
> + local_lock_irqsave(lock, flags)
> +
> +#define pw_lock_local_irqsave(lock, flags) \
> + local_lock_irqsave(lock, flags)
> +
> +#define pw_trylock(lock, cpu) \
> + local_trylock(lock)
> +
> +#define pw_trylock_local(lock) \
> + local_trylock(lock)
> +
> +#define pw_trylock_irqsave(lock, flags, cpu) \
> + local_trylock_irqsave(lock, flags)
> +
> +#define pw_unlock(lock, cpu) \
> + local_unlock(lock)
> +
> +#define pw_unlock_local(lock) \
> + local_unlock(lock)
> +
> +#define pw_unlock_irqrestore(lock, flags, cpu) \
> + local_unlock_irqrestore(lock, flags)
> +
> +#define pw_unlock_local_irqrestore(lock, flags) \
> + local_unlock_irqrestore(lock, flags)
> +
> +#define pw_lockdep_assert_held(lock) \
> + lockdep_assert_held(lock)
> +
> +#define pw_queue_on(c, wq, pw) \
> + queue_work_on(c, wq, &(pw)->work)
> +
> +#define pw_flush(pw) \
> + flush_work(&(pw)->work)
> +
> +#define pw_get_cpu(pw) smp_processor_id()
> +
> +#define pw_is_cpu_remote(cpu) (false)
> +
> +#define INIT_PW(pw, func, c) \
> + INIT_WORK(&(pw)->work, (func))
> +
> +#else /* CONFIG_PWLOCKS */
> +
> +DECLARE_STATIC_KEY_MAYBE(CONFIG_PWLOCKS_DEFAULT, pw_sl);
> +
> +typedef union {
> + spinlock_t sl;
> + local_lock_t ll;
> +} pw_lock_t;
> +
> +typedef union {
> + spinlock_t sl;
> + local_trylock_t ll;
> +} pw_trylock_t;
> +
> +struct pw_struct {
> + struct work_struct work;
> + int cpu;
> +};
> +
> +#ifdef CONFIG_PREEMPT_RT
> +#define preempt_or_migrate_disable migrate_disable
> +#define preempt_or_migrate_enable migrate_enable
> +#else
> +#define preempt_or_migrate_disable preempt_disable
> +#define preempt_or_migrate_enable preempt_enable
This can be no-op in !CONFIG_PREEMPT_RT because non-rt spinlocks
disable preemption already.
> +#endif
> +
> +#define pw_lock_init(lock) \
> +do { \
> + if (static_branch_maybe(CONFIG_PWLOCKS_DEFAULT, &pw_sl)) \
> + spin_lock_init(lock.sl); \
> + else \
> + local_lock_init(lock.ll); \
> +} while (0)
It looks like all these macros could be inline functions.
> +
> +#define pw_trylock_init(lock) \
> +do { \
> + if (static_branch_maybe(CONFIG_PWLOCKS_DEFAULT, &pw_sl)) \
> + spin_lock_init(lock.sl); \
> + else \
> + local_trylock_init(lock.ll); \
> +} while (0)
> +
> +#define pw_lock(lock, cpu)
> \
And those could have the same local CPU debug check.
> +do { \
> + if (static_branch_maybe(CONFIG_PWLOCKS_DEFAULT, &pw_sl)) \
> + spin_lock(per_cpu_ptr(lock.sl, cpu)); \
> + else \
> + local_lock(lock.ll); \
> +} while (0)
> +
> +#define pw_lock_local(lock) \
> +do { \
> + if (static_branch_maybe(CONFIG_PWLOCKS_DEFAULT, &pw_sl)) { \
> + preempt_or_migrate_disable(); \
> + spin_lock(this_cpu_ptr(lock.sl)); \
> + } else { \
> + local_lock(lock.ll); \
> + } \
> +} while (0)
> +
> +#define pw_lock_irqsave(lock, flags, cpu) \
> +do { \
> + if (static_branch_maybe(CONFIG_PWLOCKS_DEFAULT, &pw_sl)) \
> + spin_lock_irqsave(per_cpu_ptr(lock.sl, cpu), flags); \
> + else \
> + local_lock_irqsave(lock.ll, flags); \
> +} while (0)
> +
> +#define pw_lock_local_irqsave(lock, flags) \
> +do { \
> + if (static_branch_maybe(CONFIG_PWLOCKS_DEFAULT, &pw_sl)) { \
> + preempt_or_migrate_disable(); \
> + spin_lock_irqsave(this_cpu_ptr(lock.sl), flags); \
> + } else { \
> + local_lock_irqsave(lock.ll, flags); \
> + } \
> +} while (0)
> +
> +#define pw_trylock(lock, cpu) \
> +({ \
> + int t; \
> + if (static_branch_maybe(CONFIG_PWLOCKS_DEFAULT, &pw_sl)) \
> + t = spin_trylock(per_cpu_ptr(lock.sl, cpu)); \
> + else \
> + t = local_trylock(lock.ll); \
> + t; \
> +})
> +
> +#define pw_trylock_local(lock) \
> +({ \
> + int t; \
> + if (static_branch_maybe(CONFIG_PWLOCKS_DEFAULT, &pw_sl)) { \
> + preempt_or_migrate_disable(); \
> + t = spin_trylock(this_cpu_ptr(lock.sl)); \
> + if (!t) \
> + preempt_or_migrate_enable();
> \
This is duplicating the RT logic in local_lock_internal.h and it would be
tempting to propose spin_local_lock_t that both pw and RT local_lock could rely
upon. But I'm afraid that would create a less readable result:
- we would need to check the CONFIG_PREEMPT_RT there before doing the
migrate_disable/enable
- RT local lock don't take the lock on IRQ/NMI, which is fine as pw is not
expected to be used on the non-threaded parts of IRQs not NMIs. Still that's
one more conditional to add there.
- we'll need to differenciate local/remote operations.
Well let's stick to what you did for now (Peter might have a different opinion though).
> + } else { \
> + t = local_trylock(lock.ll); \
> + } \
> + t; \
> +})
> +
> +#define pw_trylock_irqsave(lock, flags, cpu) \
> +({ \
> + int t; \
> + if (static_branch_maybe(CONFIG_PWLOCKS_DEFAULT, &pw_sl)) \
> + t = spin_trylock_irqsave(per_cpu_ptr(lock.sl, cpu), flags); \
> + else \
> + t = local_trylock_irqsave(lock.ll, flags); \
> + t; \
> +})
> +
> +#define pw_unlock(lock, cpu) \
> +do { \
> + if (static_branch_maybe(CONFIG_PWLOCKS_DEFAULT, &pw_sl)) \
> + spin_unlock(per_cpu_ptr(lock.sl, cpu)); \
> + else \
> + local_unlock(lock.ll); \
> +} while (0)
> +
> +#define pw_unlock_local(lock) \
> +do { \
> + if (static_branch_maybe(CONFIG_PWLOCKS_DEFAULT, &pw_sl)) { \
> + spin_unlock(this_cpu_ptr(lock.sl)); \
> + preempt_or_migrate_enable(); \
> + } else { \
> + local_unlock(lock.ll); \
> + } \
> +} while (0)
> +
> +#define pw_unlock_irqrestore(lock, flags, cpu) \
> +do { \
> + if (static_branch_maybe(CONFIG_PWLOCKS_DEFAULT, &pw_sl)) \
> + spin_unlock_irqrestore(per_cpu_ptr(lock.sl, cpu), flags); \
> + else \
> + local_unlock_irqrestore(lock.ll, flags); \
> +} while (0)
> +
> +#define pw_unlock_local_irqrestore(lock, flags) \
> +do { \
> + if (static_branch_maybe(CONFIG_PWLOCKS_DEFAULT, &pw_sl)) { \
> + spin_unlock_irqrestore(this_cpu_ptr(lock.sl), flags); \
> + preempt_or_migrate_enable(); \
> + } else { \
> + local_unlock_irqrestore(lock.ll, flags); \
> + } \
> +} while (0)
> +
> +#define pw_lockdep_assert_held(lock) \
> +do { \
> + if (static_branch_maybe(CONFIG_PWLOCKS_DEFAULT, &pw_sl)) \
> + lockdep_assert_held(this_cpu_ptr(lock.sl)); \
> + else \
> + lockdep_assert_held(this_cpu_ptr(lock.ll)); \
> +} while (0)
> +
> +#define pw_queue_on(c, wq, pw) \
> +do { \
> + int __c = c; \
> + struct pw_struct *__pw = (pw); \
> + if (static_branch_maybe(CONFIG_PWLOCKS_DEFAULT, &pw_sl)) { \
> + WARN_ON((__c) != __pw->cpu); \
> + __pw->work.func(&__pw->work); \
> + } else { \
> + queue_work_on(__c, wq, &(__pw)->work); \
> + } \
> +} while (0)
> +
> +/*
> + * Does nothing if PWLOCKS is set to use spinlock, as the task is already done at the
> + * time pw_queue_on() returns.
> + */
> +#define pw_flush(pw) \
> +do { \
> + struct pw_struct *__pw = (pw); \
> + if (!static_branch_maybe(CONFIG_PWLOCKS_DEFAULT, &pw_sl)) \
> + flush_work(&__pw->work); \
> +} while (0)
> +
> +#define pw_get_cpu(w) container_of((w), struct pw_struct, work)->cpu
> +
> +#define pw_is_cpu_remote(cpu) ((cpu) != smp_processor_id())
> +
> +#define INIT_PW(pw, func, c) \
> +do { \
> + struct pw_struct *__pw = (pw); \
> + INIT_WORK(&__pw->work, (func)); \
> + __pw->cpu = (c); \
> +} while (0)
> +
> +#endif /* CONFIG_PWLOCKS */
> +#endif /* LINUX_PWLOCKS_H */
> diff --git a/kernel/pwlocks.c b/kernel/pwlocks.c
> new file mode 100644
> index 000000000000..1ebf5cb979b9
> --- /dev/null
> +++ b/kernel/pwlocks.c
> @@ -0,0 +1,47 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include "linux/export.h"
> +#include <linux/sched.h>
> +#include <linux/pwlocks.h>
> +#include <linux/string.h>
> +#include <linux/sched/isolation.h>
> +
> +DEFINE_STATIC_KEY_MAYBE(CONFIG_PWLOCKS_DEFAULT, pw_sl);
> +EXPORT_SYMBOL(pw_sl);
> +
> +static bool pwlocks_param_specified;
> +
> +static int __init pwlocks_setup(char *str)
> +{
> + int opt;
> +
> + if (!get_option(&str, &opt)) {
> + pr_warn("PWLOCKS: invalid pwlocks parameter: %s, ignoring.\n", str);
> + return 0;
> + }
> +
> + if (opt)
> + static_branch_enable(&pw_sl);
> + else
> + static_branch_disable(&pw_sl);
> +
> + pwlocks_param_specified = true;
> +
> + return 1;
> +}
> +__setup("pwlocks=", pwlocks_setup);
> +
> +/*
> + * Enable PWLOCKS if CPUs want to avoid kernel noise.
> + */
> +static int __init pwlocks_init(void)
> +{
> + if (pwlocks_param_specified)
> + return 0;
> +
> + if (housekeeping_enabled(HK_TYPE_KERNEL_NOISE))
> + static_branch_enable(&pw_sl);
> +
> + return 0;
> +}
> +
> +late_initcall(pwlocks_init);
That should be a pre-SMP initcall. Otherwise you risk some asymetric calls.
Thanks.
--
Frederic Weisbecker
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2 1/2] tools/mm: add a standalone GUP microbenchmark
From: Sarthak Sharma @ 2026-05-20 10:15 UTC (permalink / raw)
To: Mike Rapoport
Cc: Andrew Morton, David Hildenbrand, Jonathan Corbet,
Jason Gunthorpe, John Hubbard, Peter Xu, Lorenzo Stoakes,
Liam R . Howlett, Vlastimil Babka, Suren Baghdasaryan,
Michal Hocko, Shuah Khan, linux-mm, linux-kselftest, linux-kernel,
linux-doc, Mark Brown
In-Reply-To: <ag13GbKcLMIoHOHj@kernel.org>
Hi Mike!
On 5/20/26 2:25 PM, Mike Rapoport wrote:
> (added broonie)
>
> Hi,
>
> On Tue, May 19, 2026 at 05:35:05PM +0530, Sarthak Sharma wrote:
>> Add a command-line tool for benchmarking get_user_pages fast-path
>> (GUP_FAST), pin_user_pages fast-path (PIN_FAST), and pin_user_pages
>> longterm (PIN_LONGTERM) via the CONFIG_GUP_TEST debugfs interface.
>>
>> When invoked without arguments, gup_bench runs the same matrix of
>> configurations as run_gup_matrix() in run_vmtests.sh: all three GUP
>> commands across read/write, private/shared mappings, and a range of
>> page counts, with THP on/off for regular mappings and hugetlb for huge
>> page mappings.
>>
>> This tool is a mix of reused and new logic. The mapping/setup path comes
>> from selftests/mm/gup_test.c, while the default benchmark matrix matches
>> run_gup_matrix() in run_vmtests.sh. The standalone CLI and tools/mm
>> integration are added here so tools/mm does not depend on kselftest.
>>
>> Add gup_bench to BUILD_TARGETS and INSTALL_TARGETS in tools/mm/Makefile,
>> and ignore the resulting binary in tools/mm/.gitignore. While here, also
>> add the missing thp_swap_allocator_test entry to .gitignore.
>>
>> Add tools/mm/gup_bench.c to the GUP entry in MAINTAINERS.
>>
>> Suggested-by: David Hildenbrand (Arm) <david@kernel.org>
>> Signed-off-by: Sarthak Sharma <sarthak.sharma@arm.com>
>> ---
>> MAINTAINERS | 1 +
>> tools/mm/.gitignore | 2 +
>> tools/mm/Makefile | 6 +-
>> tools/mm/gup_bench.c | 491 +++++++++++++++++++++++++++++++++++++++++++
>> 4 files changed, 497 insertions(+), 3 deletions(-)
>> create mode 100644 tools/mm/gup_bench.c
>
> ...
>
>> +/*
>> + * Local HugeTLB setup helpers for gup_bench.
>> + *
>> + * These helpers were copied from tools/testing/selftests/mm/ and adjusted to
>> + * remove the ksft formatting. Keep this copy local so tools/mm does not
>> + * depend on ksft output behavior.
>> + */
>
> It looks like self tests of at least 5 subsystems beside mm use hugetlb:
>
> $ git grep -l "Hugepagesize:" tools/testing/selftests/ | grep -v "selftests/mm"
> tools/testing/selftests/arm64/mte/check_hugetlb_options.c
> tools/testing/selftests/cgroup/test_hugetlb_memcg.c
> tools/testing/selftests/kvm/lib/test_util.c
> tools/testing/selftests/memfd/common.c
> tools/testing/selftests/net/tcp_mmap.c
>
> It seems that we need to better share the common code in
> tools/testing/selftest.
>
> And adding another copy of the hugetlb detection and setup code does not
> seem like a great idea.
Agreed, but that was the least disruptive approach I could think of.
I am thinking of doing this now: should I move the
hugepage_settings.[ch] to tools/lib/ and move the read_num(),
write_num(), read_file() and write_file() helpers to a separate file in
tools/lib/ itself without any ksft dependency? Then both
tools/testing/selftests/* and tools/mm/ could share the same code.
Please let me know if some different approach is preferred.
>
>> +
>> +static unsigned int psize(void)
>> +{
>> + static unsigned int __page_size;
>> +
>> + if (!__page_size)
>> + __page_size = sysconf(_SC_PAGESIZE);
>> + return __page_size;
>> +}
>> +
>> +static unsigned long default_huge_page_size(void)
>> +{
>> + FILE *f = fopen("/proc/meminfo", "r");
>> + unsigned long hpage_size = 0;
>> + char buf[256];
>> +
>> + if (!f)
>> + return 0;
>> + while (fgets(buf, sizeof(buf), f)) {
>> + if (sscanf(buf, "Hugepagesize: %lu kB", &hpage_size) == 1)
>> + break;
>> + }
>> + fclose(f);
>> + hpage_size <<= 10;
>> + return hpage_size;
>> +}
>
^ permalink raw reply
* Re: [PATCH v11 4/6] iio: adc: ad4691: add SPI offload support
From: Jonathan Cameron @ 2026-05-20 10:36 UTC (permalink / raw)
To: Andy Shevchenko
Cc: David Lechner, Sabau, Radu bogdan, Lars-Peter Clausen,
Hennerich, Michael, Sa, Nuno, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Uwe Kleine-König,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski,
Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <agtZwbeVeZdnlXTI@ashevche-desk.local>
On Mon, 18 May 2026 21:26:09 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Mon, May 18, 2026 at 10:16:38AM -0500, David Lechner wrote:
> > On 5/18/26 10:14 AM, Sabau, Radu bogdan wrote:
> > >> -----Original Message-----
> > >> From: David Lechner <dlechner@baylibre.com>
> > >> Sent: Saturday, May 16, 2026 8:53 PM
>
> ...
>
> > >>> + if (st->manual_mode && st->offload)
> > >>> + return sysfs_emit(buf, "%llu\n", READ_ONCE(st->offload-
> > >>> trigger_hz));
> > >>
> > >> Why do we need READ_ONCE?
> > >
> > > trigger_hz is u64 and if the target is 32-bit, a 64-bit access compiles to two 32-bit
> > > instructions, so show() reading it without a lock and store() writing it concurrently
> > > can produce a torn value at the compiler level. READ_ONCE/WRITE_ONCE suppress
> > > the compiler transformations that would allow that splitting or caching. We could
> > > have st->lock in show() instead, but that felt heavier than necessary for a single
> > > scalar where a transiently stale-but-whole read is fine.
> >
> > I would go with the mutex. It will be easier for people to understand.
>
> But why? READ_ONCE() here is exactly enough. We do not care about
> serialisation, we care only about integrity. With mutex it will confuse
> (some) people more, e.g., me. Because in that case I would think about
> some specific access to it that may happen. Yes, I saw many times the show
> functions that do mutex and then print the result when mutex is not held
> anymore, but for simple cases like here, mutex is overkill. Interestingly
> that using guard()() inside show makes the mentioned functions to print
> (almost) latest value of the variable in question. It narrows window down
> as printing will go inside critical section.
>
I think it's worth noting that we are very lax in IIO wrt to READ_ONCE()
usage. It might be worth starting to tighten that up for state variable reads
etc whether they are 64 bit or not (that just increases the chances).
In theory compilers can do far too many evil things. I've been scared
of pushing this because of the massive number of incorrect instances
(and the bad example I set with early drivers :(), but it would be good
to have a few examples in tree so we can start to encourage people to
do that stuff right.
Jonathan
^ permalink raw reply
* [PATCH AUTOSEL 7.0-6.6] docs: cgroup-v1: Update charge-commit section
From: Sasha Levin @ 2026-05-20 11:18 UTC (permalink / raw)
To: patches, stable
Cc: T.J. Mercier, Tejun Heo, Sasha Levin, hannes, mkoutny, corbet,
cgroups, linux-doc, linux-kernel
In-Reply-To: <20260520111944.3424570-1-sashal@kernel.org>
From: "T.J. Mercier" <tjmercier@google.com>
[ Upstream commit d8769544bde51b0ac980d10f8fe9f9fed6c95995 ]
Commit 1d8f136a421f ("memcg/hugetlb: remove memcg hugetlb
try-commit-cancel protocol") removed mem_cgroup_commit_charge() and
mem_cgroup_cancel_charge(), but the docs still refer to those functions.
There is no longer any charge cancellation.
Update the docs to match the code.
Signed-off-by: T.J. Mercier <tjmercier@google.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Phase 1: Commit Message Forensics
Step 1.1 Record: subsystem `docs: cgroup-v1`; action verb `Update`;
intent: update `Documentation/admin-guide/cgroup-v1/memcg_test.rst` so
the charge-commit section matches current memcg code.
Step 1.2 Record: tags present: `Signed-off-by: T.J. Mercier
<tjmercier@google.com>` and `Signed-off-by: Tejun Heo <tj@kernel.org>`.
No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`,
`Link:`, or `Cc: stable@vger.kernel.org` tags in the committed message.
Step 1.3 Record: the body says commit `1d8f136a421f` removed
`mem_cgroup_commit_charge()` and `mem_cgroup_cancel_charge()`, while the
cgroup-v1 memcg docs still name them and describe cancellation.
Symptom/failure mode: incorrect documentation only. Version information:
the referenced removal commit is from 2025-01-13 in the local object
database; candidate commit is from 2026-04-30. Root cause: docs were not
updated when the code was changed.
Step 1.4 Record: this is not a hidden runtime bug fix. It is an explicit
documentation correctness fix.
## Phase 2: Diff Analysis
Step 2.1 Record: one file changed: `Documentation/admin-
guide/cgroup-v1/memcg_test.rst`, `2 insertions(+), 4 deletions(-)`. No
functions modified. Scope: single-file documentation-only surgical
change.
Step 2.2 Record: before, the section was titled `charge-commit-cancel`,
listed `mem_cgroup_commit_charge()` or `mem_cgroup_cancel_charge()`, and
described `cancel()`. After, it is titled `charge-commit`, lists
`commit_charge()`, and removes the cancellation text.
Step 2.3 Record: bug category is documentation/comment correctness.
Specific mechanism: removes stale references to APIs that are absent in
current `6.19.y`/`7.0.y` code and in `origin/master`.
Step 2.4 Record: fix quality is obviously correct for trees whose memcg
code no longer has `mem_cgroup_commit_charge()` /
`mem_cgroup_cancel_charge()`. Regression risk is zero runtime risk, but
there is a branch-selection concern: `stable/linux-6.12.y` still
contains those functions, so this exact doc update would be misleading
there.
## Phase 3: Git History Investigation
Step 3.1 Record: `git blame` before the candidate shows the stale doc
lines came from `f3f5edc5e41e` in this repository’s history. `git blame
origin/master` shows the changed lines attributed to `d8769544bde51`.
Step 3.2 Record: no `Fixes:` tag. I still inspected referenced commit
`1d8f136a421f26747e58c01281cba5bffae8d289`; it removed prototypes and
implementations for `mem_cgroup_commit_charge()`,
`mem_cgroup_cancel_charge()`, and related hugetlb try/commit/cancel
helpers.
Step 3.3 Record: recent history for `Documentation/admin-
guide/cgroup-v1/memcg_test.rst` on `origin/master` has only the file
introduction/import commit and this candidate. Related path history
shows the candidate was merged via `cgroup-for-7.1-rc2-fixes`. No
prerequisite doc series found.
Step 3.4 Record: author `T.J. Mercier` has at least one other cgroup-
related commit in `origin/master`; Tejun Heo is listed in `MAINTAINERS`
as cgroup maintainer and committed the patch.
Step 3.5 Record: no code dependencies for the patch itself. It can apply
standalone to the current `stable/linux-7.0.y` checkout. Applicability
must be gated by whether the target tree’s code has removed the old
APIs.
## Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c d8769544bde51...` found the original
submission at
`https://patch.msgid.link/20260430201142.240387-1-tjmercier@google.com`.
`b4 dig -a` found only v1 of a single-patch series. The mbox contains
Tejun’s reply: “Applied to cgroup/for-7.1-fixes.” No NAKs or concerns
found in the saved thread.
Step 4.2 Record: `b4 dig -w` shows recipients included cgroup
maintainers/list and docs list: `tj@kernel.org`, `hannes@cmpxchg.org`,
`mkoutny@suse.com`, `cgroups@vger.kernel.org`, `corbet@lwn.net`,
`skhan@linuxfoundation.org`, `linux-doc@vger.kernel.org`, `linux-
kernel@vger.kernel.org`.
Step 4.3 Record: no `Reported-by` or bug-report `Link:` tags. No syzbot,
bugzilla, or user-impact bug report applies.
Step 4.4 Record: b4 found a standalone single-patch series, not part of
a multi-patch dependency chain.
Step 4.5 Record: web search did not find stable-list discussion for this
exact patch. `WebFetch` to lore/patch.msgid was blocked by Anubis, but
b4 successfully fetched the mbox.
## Phase 5: Code Semantic Analysis
Step 5.1 Record: no functions modified by the diff.
Step 5.2 Record: no callers affected by the diff. For documentation
accuracy, I verified current `stable/linux-7.0.y` code has
`commit_charge()` callers in `charge_memcg()`,
`mem_cgroup_replace_folio()`, and `mem_cgroup_migrate()`.
Step 5.3 Record: no changed callees. The relevant current code has
`commit_charge()` assigning `folio->memcg_data`, and callers also invoke
`memcg1_commit_charge()` where appropriate.
Step 5.4 Record: runtime reachability is not relevant because no
executable code changes.
Step 5.5 Record: similar stale docs pattern exists in stable branches;
however code state differs by branch. `6.19.y`/`7.0.y` have stale docs
and no old API. `6.12.y` still has `mem_cgroup_commit_charge()` and
`mem_cgroup_cancel_charge()` in code.
## Phase 6: Cross-Referencing And Stable Tree Analysis
Step 6.1 Record: buggy stale documentation exists in
`stable/linux-7.0.y`, `stable/linux-6.19.y`, `stable/linux-6.18.y`,
`stable/linux-6.6.y`, `stable/linux-6.1.y`, `stable/linux-5.15.y`, and
`stable/linux-5.10.y` by exact doc grep. I verified the old APIs are
absent in several of those trees, but `stable/linux-6.12.y` still
contains `mem_cgroup_commit_charge()` and `mem_cgroup_cancel_charge()`,
so this exact upstream text is not universally correct for all
maintained stable lines.
Step 6.2 Record: `git apply --check` of the candidate diff succeeds on
the current `stable/linux-7.0.y` checkout. Expected backport difficulty:
clean for trees with matching doc context; branch-specific review needed
for `6.12.y`.
Step 6.3 Record: no related stable fix for this exact doc update found
by local stable branch ancestry checks or web search.
## Phase 7: Subsystem And Maintainer Context
Step 7.1 Record: subsystem is cgroup-v1 memcg documentation.
Criticality: peripheral/runtime-none; important only for documentation
correctness.
Step 7.2 Record: cgroup and memcg areas are active; recent
`origin/master` history includes multiple cgroup/mm fixes. The candidate
was applied by the cgroup maintainer.
## Phase 8: Impact And Risk Assessment
Step 8.1 Record: affected population is documentation readers and
developers/admins consulting old cgroup-v1 memcg internals. No kernel
runtime users are affected.
Step 8.2 Record: trigger condition is reading or relying on the stale
documentation. Unprivileged users cannot trigger a kernel failure
because there is no runtime behavior.
Step 8.3 Record: failure mode is incorrect documentation. Severity: LOW.
It can mislead developers/admins, but it does not fix crash, corruption,
leak, deadlock, or security behavior.
Step 8.4 Record: benefit is low but real for documentation correctness,
especially because the stable rules exception allows
documentation/comment fixes and runtime risk is zero. Risk is very low
for branches whose code matches the new text; risk is documentation-
regression risk if applied to a branch like `6.12.y` where cancellation
APIs still exist.
## Phase 9: Final Synthesis
Step 9.1 Record: evidence for backporting: tiny docs-only patch;
corrects verified stale references in current `7.0.y` and `6.19.y`;
applied by cgroup maintainer; no runtime regression risk; documentation
fixes are allowed. Evidence against: no runtime bug or user-visible
stability issue; not correct for every stable branch, specifically
verified `6.12.y` still has the old commit/cancel APIs. Unresolved: I
did not exhaustively validate every maintained stable branch’s memcg API
state.
Step 9.2 Stable rules checklist:
1. Obviously correct and tested? Yes for matching-code branches;
verified by code grep, `git diff --check`, and `git apply --check` on
`7.0.y`.
2. Fixes a real bug that affects users? It fixes incorrect
documentation, not runtime behavior.
3. Important issue? No runtime severity; LOW documentation correctness
issue.
4. Small and contained? Yes, 6-line docs-only diff in one file.
5. No new features or APIs? Yes.
6. Can apply to stable trees? Yes to at least current `7.0.y`; should
not be applied blindly to `6.12.y`.
Step 9.3 Record: exception category is documentation fix.
Step 9.4 Decision: backport is acceptable for stable trees whose memcg
implementation no longer has charge cancellation APIs. It should be
excluded from trees like `6.12.y` where the old APIs still exist. With
that branch-selection caveat, this qualifies under the documentation-fix
exception.
Verification:
- [Phase 1] Parsed candidate commit
`d8769544bde51b0ac980d10f8fe9f9fed6c95995`: only two Signed-off-by
tags, no bug/report/stable tags.
- [Phase 2] `git show --stat --patch`: confirmed one docs file, `2
insertions(+), 4 deletions(-)`.
- [Phase 3] `git show 1d8f136a421f...`: confirmed referenced commit
removed `mem_cgroup_commit_charge()` and `mem_cgroup_cancel_charge()`
from mainline code.
- [Phase 3] `git log origin/master --grep`: found candidate and merge
via `cgroup-for-7.1-rc2-fixes`.
- [Phase 4] `b4 dig`: found lore thread and exact patch-id match.
- [Phase 4] `b4 dig -a`: only v1 single-patch series.
- [Phase 4] `b4 dig -w`: relevant cgroup and docs maintainers/lists were
included.
- [Phase 4] Saved mbox: confirmed Tejun replied “Applied to
cgroup/for-7.1-fixes”; no NAKs or stable nomination found.
- [Phase 5] `rg`/`git grep`: confirmed current code uses
`commit_charge()` and no longer has old API names in `7.0.y`.
- [Phase 6] `git apply --check`: candidate applies cleanly to current
`7.0.y`.
- [Phase 6] Branch checks: `6.12.y` still has
`mem_cgroup_commit_charge()` and `mem_cgroup_cancel_charge()`, so this
patch must not be applied there unchanged.
- [Phase 8] Runtime impact verified as none because only
`Documentation/admin-guide/cgroup-v1/memcg_test.rst` changes.
**YES**
Documentation/admin-guide/cgroup-v1/memcg_test.rst | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/Documentation/admin-guide/cgroup-v1/memcg_test.rst b/Documentation/admin-guide/cgroup-v1/memcg_test.rst
index 9f8e27355cba5..7c7cd457cf695 100644
--- a/Documentation/admin-guide/cgroup-v1/memcg_test.rst
+++ b/Documentation/admin-guide/cgroup-v1/memcg_test.rst
@@ -47,21 +47,19 @@ Please note that implementation details can be changed.
Called when swp_entry's refcnt goes down to 0. A charge against swap
disappears.
-3. charge-commit-cancel
+3. charge-commit
=======================
Memcg pages are charged in two steps:
- mem_cgroup_try_charge()
- - mem_cgroup_commit_charge() or mem_cgroup_cancel_charge()
+ - commit_charge()
At try_charge(), there are no flags to say "this page is charged".
at this point, usage += PAGE_SIZE.
At commit(), the page is associated with the memcg.
- At cancel(), simply usage -= PAGE_SIZE.
-
Under below explanation, we assume CONFIG_SWAP=y.
4. Anonymous
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0] docs: hwmon: sy7636a: fix temperature sysfs attribute name
From: Sasha Levin @ 2026-05-20 11:18 UTC (permalink / raw)
To: patches, stable
Cc: Chen-Shi-Hong, Guenter Roeck, Sasha Levin, corbet, linux-hwmon,
linux-doc, linux-kernel
In-Reply-To: <20260520111944.3424570-1-sashal@kernel.org>
From: Chen-Shi-Hong <eric039eric@gmail.com>
[ Upstream commit 51f57607e30bee282a1d40845f89a311cbb26481 ]
The hwmon sysfs naming convention uses
temp[1-*]_input for temperature channels.
Documentation/hwmon/sy7636a-hwmon.rst currently documents
temp0_input, while the driver uses the standard hwmon
temperature channel interface.
Update the documentation to use temp1_input.
Signed-off-by: Chen-Shi-Hong <eric039eric@gmail.com>
Link: https://lore.kernel.org/r/20260514154108.1937-1-eric039eric@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Phase 1: Commit Message Forensics
Record: Subsystem is `docs: hwmon: sy7636a`. Action verb is `fix`.
Claimed intent is to correct the documented temperature sysfs attribute
name from `temp0_input` to `temp1_input`.
Record: Tags present: `Signed-off-by: Chen-Shi-Hong
<eric039eric@gmail.com>`, `Link:
https://lore.kernel.org/r/20260514154108.1937-1-eric039eric@gmail.com`,
`Signed-off-by: Guenter Roeck <linux@roeck-us.net>`. No `Fixes:`,
`Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`, or `Cc:
stable`.
Record: The commit describes a documentation bug: the sy7636a hwmon
document names `temp0_input`, while hwmon temperature channels are named
`temp[1-*]_input`. No crash, data corruption, or runtime bug is claimed.
Record: This is not a hidden runtime bug fix. It is an explicit
documentation correctness fix.
## Phase 2: Diff Analysis
Record: One file changed: `Documentation/hwmon/sy7636a-hwmon.rst`, 1
insertion and 1 deletion. No functions modified. Scope is a single-file
documentation-only surgical fix.
Record: Before, the document told users to read `temp0_input`. After, it
tells users to read `temp1_input`. No normal/error/init runtime path
changes.
Record: Bug category is documentation/API-description correctness.
Verified against `Documentation/hwmon/sysfs-interface.rst`, which
documents `temp[1-*]_input`, and `drivers/hwmon/hwmon.c`, where
temperature attributes use `temp%d_input` with base index `1`.
Record: Fix quality is obviously correct and minimal. Runtime regression
risk is zero because no code changes.
## Phase 3: Git History Investigation
Record: `git blame` shows `temp0_input` was introduced by
`de34a40532507` when the sy7636a hwmon driver/doc was added. Ancestry
checks show that commit is not in `v5.17` but is in `v5.18`, so the
documentation bug exists from v5.18 onward where the driver exists.
Record: No `Fixes:` tag is present, so there was no Fixes target to
follow.
Record: Related file history on `origin/master`: `51f57607e30be` doc
attribute fix, `2f88425ef590b` regulator-enable leak fix,
`68c2a8b59d231` sensor description doc fix, `80038a758b7fc` alias
addition, `5b5d8ae019543` constification, `a96f688b4e446` underline
warning fix, `de34a40532507` driver addition. This patch is standalone
for trees with the current doc context.
Record: Author history under hwmon/doc paths shows only this commit from
Chen-Shi-Hong in the checked history. Guenter Roeck, the hwmon
maintainer, committed/applied it.
Record: No functional dependencies. For older stable trees that do not
contain `68c2a8b59d231`, the exact patch context differs and needs a
trivial manual backport.
## Phase 4: Mailing List And External Research
Record: `b4 dig -c 51f57607e30be` found the original submission at
`https://patch.msgid.link/20260514154108.1937-1-eric039eric@gmail.com`.
Record: `b4 dig -a` found only v1 of a single-patch series. No newer
unapplied revision found.
Record: `b4 dig -w` showed recipients included Chen-Shi-Hong, Guenter
Roeck, Jonathan Corbet, Shuah Khan, `linux-hwmon`, `linux-doc`, and
`linux-kernel`.
Record: The b4-fetched thread contains Guenter Roeck replying “Applied.”
No NAKs, objections, or stable-specific nomination were found in that
thread. Lore `WebFetch` was blocked by Anubis, but `b4` successfully
retrieved the thread.
## Phase 5: Code Semantic Analysis
Record: No code functions are modified.
Record: Manual code tracing verified the documentation claim:
`drivers/hwmon/sy7636a-hwmon.c` registers `HWMON_CHANNEL_INFO(temp,
HWMON_T_INPUT)`. `drivers/hwmon/hwmon.c` formats temperature attributes
with `temp%d_input`, and `hwmon_attr_base()` returns `1` for temperature
sensors. Therefore the first temperature channel is `temp1_input`.
Record: Callers/callees are not applicable to the patch because it
changes documentation only. The affected “path” is users reading the
hwmon documentation.
Record: Similar pattern check found the generic hwmon documentation and
many hwmon docs use `temp1_input`, supporting the correction.
## Phase 6: Stable Tree Analysis
Record: `v5.15` does not contain `Documentation/hwmon/sy7636a-hwmon.rst`
or `drivers/hwmon/sy7636a-hwmon.c`, so the patch is not applicable
there.
Record: `v6.1`, `v6.6`, and `v6.12` contain the sy7636a driver and the
wrong `temp0_input` documentation. `v7.0` contains the wrong attribute
name with the newer “external NTC” text.
Record: The exact patch applies cleanly to the current
`stable/linux-7.0.y` checkout. It does not apply cleanly to `v6.1` or
`v6.6` because the surrounding description text differs before the later
doc description fix; a trivial one-line context-adjusted backport is
needed there.
Record: No alternate fix for this exact documentation bug was found in
local stable history.
## Phase 7: Subsystem Context
Record: Subsystem is hwmon documentation. Criticality is low for
runtime, but it documents a userspace-visible sysfs ABI path for sy7636a
hardware users.
Record: The sy7636a hwmon files have low churn and only a handful of
targeted fixes since introduction.
## Phase 8: Impact And Risk
Record: Affected population is sy7636a hardware users and anyone writing
scripts or instructions based on
`Documentation/hwmon/sy7636a-hwmon.rst`.
Record: Trigger is reading/following the documentation. If followed
literally, users look for a non-existent `temp0_input` instead of the
actual `temp1_input`.
Record: Failure severity is LOW: documentation/user guidance bug, not a
kernel crash or data corruption issue.
Record: Benefit is modest but real: correct stable documentation for a
userspace-visible hwmon attribute. Risk is effectively zero: one
documentation line, no code, no ABI change.
## Phase 9: Final Synthesis
Evidence for backporting: verified documentation is wrong; verified
driver/core generate `temp1_input`; patch is one-line documentation-
only; hwmon maintainer applied it; documentation fixes are an allowed
stable exception with no runtime regression risk.
Evidence against backporting: it is not a serious runtime bug, security
issue, crash, or data corruption fix. Older stable trees before the
sensor-description doc change need a trivial context adjustment.
Stable rules checklist: obviously correct, yes; fixes a real
documentation bug, yes; important runtime issue, no; small and
contained, yes; no new feature/API, yes; stable applicability, yes for
v7.0 cleanly and older applicable with minor backport adjustment.
Exception category: documentation fix.
Verification:
- [Phase 1] Parsed exact commit `51f57607e30be` from `origin/master` and
confirmed tags/message.
- [Phase 2] Inspected exact diff: one doc line changes `temp0_input` to
`temp1_input`.
- [Phase 3] `git blame` confirmed `temp0_input` came from
`de34a40532507`; ancestry checks place it first in v5.18.
- [Phase 4] `b4 dig` found the original patch; `b4 dig -a` showed v1
only; `b4 dig -w` showed appropriate hwmon/doc recipients; b4 mbox
showed Guenter replied “Applied.”
- [Phase 5] Read sy7636a driver and hwmon core; confirmed first
temperature channel is named `temp1_input`.
- [Phase 6] Checked `v5.15`, `v6.1`, `v6.6`, `v6.12`, and `v7.0`
content; exact patch applies to current 7.0 stable, not directly to
v6.1/v6.6 due context.
- [Phase 8] Confirmed no runtime code changes, so regression risk is
zero.
This should be backported where the sy7636a documentation exists, with
trivial context adjustment for older trees as needed.
**YES**
Documentation/hwmon/sy7636a-hwmon.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/hwmon/sy7636a-hwmon.rst b/Documentation/hwmon/sy7636a-hwmon.rst
index 0143ce0e5db76..03d866aba6e81 100644
--- a/Documentation/hwmon/sy7636a-hwmon.rst
+++ b/Documentation/hwmon/sy7636a-hwmon.rst
@@ -22,5 +22,5 @@ The following sensors are supported
sysfs-Interface
---------------
-temp0_input
+temp1_input
- Temperature of external NTC (milli-degree C)
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-6.12] Documentation: kvm: update links in the references section of AMD Memory Encryption
From: Sasha Levin @ 2026-05-20 11:19 UTC (permalink / raw)
To: patches, stable
Cc: Ninad Naik, Liam Merwick, Paolo Bonzini, Sasha Levin, corbet, kvm,
linux-doc, linux-kernel
In-Reply-To: <20260520111944.3424570-1-sashal@kernel.org>
From: Ninad Naik <ninadnaik07@gmail.com>
[ Upstream commit 80f4a7b8ce7513c203562191426e4d4cc635b095 ]
Replace non-working links in the reference section with the working ones.
Signed-off-by: Ninad Naik <ninadnaik07@gmail.com>
Link: https://patch.msgid.link/20260511174302.811918-1-ninadnaik07@gmail.com/
Reviewed-by: Liam Merwick <liam.merwick@oracle.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Phase 1: Commit Message Forensics
Step 1.1 Record: Subsystem `Documentation: kvm`; action verb `update` /
body verb `Replace`; intent is to replace non-working AMD Memory
Encryption reference links with working links.
Step 1.2 Record: Tags found: `Signed-off-by: Ninad Naik
<ninadnaik07@gmail.com>`, `Link: https://patch.msgid.link/20260511174302
.811918-1-ninadnaik07@gmail.com/`, `Reviewed-by: Liam Merwick
<liam.merwick@oracle.com>`, `Signed-off-by: Paolo Bonzini
<pbonzini@redhat.com>`. No `Fixes:`, `Reported-by:`, `Tested-by:`,
`Acked-by:`, or `Cc: stable@vger.kernel.org`.
Step 1.3 Record: The commit body describes a documentation issue only:
reference links in `Documentation/virt/kvm/x86/amd-memory-
encryption.rst` no longer work as intended. The user-visible symptom is
stale/broken documentation references for AMD SEV/SEV-SNP material. No
runtime failure, crash, data corruption, or kernel version note is
described.
Step 1.4 Record: This is not a hidden runtime bug fix. It is a direct
documentation fix, which is an allowed stable exception category due to
zero runtime risk.
## Phase 2: Diff Analysis
Step 2.1 Record: One file changed: `Documentation/virt/kvm/x86/amd-
memory-encryption.rst`, 4 insertions and 4 deletions. No functions are
modified. Scope classification: single-file surgical documentation
update.
Step 2.2 Record: Before, four reference labels pointed to older AMD
URLs. After, those labels point to current AMD Technical Information
Portal URLs, and the SNP firmware ABI reference points to a current AMD
PDF path. Only the `References` section is affected.
Step 2.3 Record: Bug category is documentation correctness, specifically
stale external references. No synchronization, memory safety, reference
counting, initialization, type, logic, or hardware workaround code is
involved.
Step 2.4 Record: Fix quality is high: the diff only swaps URL strings,
preserves labels, and does not touch kernel code or public APIs.
Regression risk is effectively limited to the possibility of choosing a
less useful URL, not runtime behavior.
## Phase 3: Git History Investigation
Step 3.1 Record: `git blame` on the reference section showed the white-
paper line came from `fbabc2eaef9fd7` in v6.3-rc1, the SNP firmware ABI
line came from `136d8bc931c84f` in v6.11-rc1, and older reference lines
are present in stable branches back to at least `v5.15` by direct branch
grep. Some blame output for pre-rename lines hit a boundary attribution,
so I did not rely on that boundary commit as the true source.
Step 3.2 Record: No `Fixes:` tag is present, so there is no specific
introducing commit to follow.
Step 3.3 Record: Recent file history on `origin/master` includes KVM
SEV/SNP documentation and API additions, including `20c3c4108d58f`,
`dcbcc2323c806`, `ad27ce155566f`, `dee5a47cc7a45`, and `136d8bc931c84f`.
The candidate is standalone because it only changes URL strings and does
not depend on those code/API changes to be meaningful where the same
reference lines exist.
Step 3.4 Record: `git log --author='Ninad Naik'` showed this author has
other documentation link/spelling style commits, including
`a362ae6e7e85b` for `amd-pstate` dead links and `5ed26ffe57ffc` for a
`hwmon` link. I did not verify the author as a KVM maintainer; Paolo
Bonzini committed/applied it and Liam Merwick reviewed it.
Step 3.5 Record: No code symbols or function dependencies exist. The
patch can apply standalone where the same documentation reference block
exists; older stable branches may need context/path adjustments.
## Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c 80f4a7b8ce751` found the original patch
thread at `https://patch.msgid.link/20260511174302.811918-1-
ninadnaik07@gmail.com`. `b4 dig -a` found only v1; `b4 am -c` found no
newer revision.
Step 4.2 Record: `b4 dig -w` showed the patch was sent to KVM and docs
maintainers/lists, including Paolo Bonzini, Jonathan Corbet, Sean
Christopherson, Michael Roth, Liam Merwick, `kvm@vger.kernel.org`, and
`linux-doc@vger.kernel.org`.
Step 4.3 Record: There is no separate bug report or reporter tag. The
thread contains Liam Merwick’s `Reviewed-by` and Paolo Bonzini’s
“Applied, thanks.” I found no NAKs or concerns in the fetched thread.
Step 4.4 Record: The patch is a one-patch series. No related required
patches were identified.
Step 4.5 Record: Web search did not find stable-specific discussion for
this exact subject/hash. Direct WebFetch of lore stable search was
blocked by Anubis, so stable-list search is partially unverified.
## Phase 5: Code Semantic Analysis
Step 5.1 Record: No functions are modified.
Step 5.2 Record: No callers exist because this is documentation.
Documentation references to this file exist from
`Documentation/virt/kvm/api.rst`, `Documentation/admin-guide/kernel-
parameters.txt`, `Documentation/virt/kvm/x86/index.rst`, and related
documentation pages.
Step 5.3 Record: No callees exist. The changed labels are consumed by
Sphinx/ReST documentation rendering.
Step 5.4 Record: No runtime call chain exists. User impact is
documentation usability for KVM SEV/SEV-SNP developers/users.
Step 5.5 Record: Similar pattern exists in prior documentation link
fixes, including `fbabc2eaef9fd7` for an AMD memory encryption white-
paper URL and `bad0524e24201` for an x86 SEV documentation URL.
## Phase 6: Cross-Referencing And Stable Tree Analysis
Step 6.1 Record: Stable branches contain affected references.
`stable/linux-5.15.y` and `stable/linux-6.1.y` contain the old KVM AMD
memory encryption doc with three AMD references. `stable/linux-6.6.y`
contains the three current old references. `stable/linux-6.12.y` through
`stable/linux-7.0.y` contain all four references, including the SNP
firmware ABI link.
Step 6.2 Record: Backport difficulty is clean for the current
`linux-7.0.y`-based tree: `git apply --check` succeeded. Older trees
likely need small manual adjustment: `5.15.y` uses the pre-`x86/` path,
`5.15.y`/`6.1.y` have an older white-paper URL, and `6.6.y` lacks the
SNP firmware ABI line.
Step 6.3 Record: `stable/linux-7.0.y` does not contain this candidate
commit by subject. I found prior related doc-link fixes, but not this
exact KVM reference update in stable branches checked.
## Phase 7: Subsystem And Maintainer Context
Step 7.1 Record: Subsystem is KVM x86 documentation for AMD SEV/SEV-SNP.
Criticality is peripheral for runtime kernel stability, but relevant to
KVM confidential-computing documentation users.
Step 7.2 Record: File history shows active KVM SEV/SNP documentation
churn due to recent SEV-SNP commands and API documentation. The touched
change itself is isolated documentation.
## Phase 8: Impact And Risk Assessment
Step 8.1 Record: Affected population is documentation users, especially
KVM/SEV/SEV-SNP developers and operators consulting AMD specs from
stable kernel docs.
Step 8.2 Record: Trigger condition is reading the documentation
references. It is not syscall- or runtime-triggered, and unprivileged
runtime triggering is not applicable.
Step 8.3 Record: Failure mode is stale/non-direct documentation links.
Severity is LOW for runtime stability, but valid under the
documentation-fix exception.
Step 8.4 Record: Benefit is modest but real: stable documentation points
users at current AMD references. Risk is very low: 4 URL replacements in
one `.rst` file, no code, no ABI, no behavior change. Risk-benefit ratio
is favorable because runtime regression risk is effectively zero.
## Phase 9: Final Synthesis
Step 9.1 Record: Evidence for backporting: documentation fix exception
applies; patch is tiny; reviewed; applied by KVM maintainer Paolo
Bonzini; no NAKs found; affected references exist in stable trees;
current `7.0.y` patch application check succeeds. Evidence against: no
runtime bug, no crash/security/data-loss impact, and older stable
branches need minor backport adjustment. Unresolved: lore stable search
was blocked by Anubis, so I could not fully verify stable-list
discussion.
Step 9.2 Record: Stable rules checklist: obviously correct and reviewed:
yes; fixes a real issue: yes, stale documentation references; important
runtime issue: no, but documentation fixes are an allowed exception;
small and contained: yes, 4 lines changed in one file; no new
features/APIs: yes; can apply to stable: yes for current `7.0.y`, likely
clean for `6.12.y+`, minor adjustment for older branches.
Step 9.3 Record: Exception category: documentation fix. This is
explicitly the kind of zero-runtime-risk update that can be accepted
even though it is not a runtime correctness fix.
Step 9.4 Record: Decision is YES. Backporting is appropriate for stable
trees that carry the affected documentation, with minor manual
adjustment where older branch context differs.
## Verification
- [Phase 1] `git show --format=fuller --stat --patch 80f4a7b8ce751`:
confirmed subject, tags, one-file documentation diff, and no runtime-
code changes.
- [Phase 2] Diff inspection: confirmed 4 URL replacements only in
`Documentation/virt/kvm/x86/amd-memory-encryption.rst`.
- [Phase 3] `git blame -L 652,664`: confirmed local history for the
reference block, including `fbabc2eaef9fd7` and `136d8bc931c84f`.
- [Phase 3] `git describe --contains`: confirmed `fbabc2eaef9fd7` first
appears by v6.3-rc1 and `136d8bc931c84f` by v6.11-rc1.
- [Phase 3] `git log origin/master --oneline -20 --
Documentation/virt/kvm/x86/amd-memory-encryption.rst`: confirmed
recent KVM SEV/SNP doc history and candidate placement.
- [Phase 4] `b4 dig -c 80f4a7b8ce751`: found original patch thread by
patch-id.
- [Phase 4] `b4 dig -c 80f4a7b8ce751 -a`: confirmed only v1 series.
- [Phase 4] `b4 dig -c 80f4a7b8ce751 -w`: confirmed KVM/docs maintainers
and lists were included.
- [Phase 4] `b4 mbox`/saved thread plus `rg`: confirmed `Reviewed-by:
Liam Merwick` and Paolo’s “Applied, thanks”; found no NAK/stable
request text.
- [Phase 4] WebFetch of lore/patch URLs was blocked by Anubis; b4
successfully fetched the thread.
- [Phase 5] `rg` in the doc file: confirmed changed labels are
referenced by SEV/SNP documentation text.
- [Phase 5] `rg` under `Documentation`: confirmed documentation pages
link to `amd-memory-encryption.rst`.
- [Phase 6] `git grep` across `stable/linux-5.15.y`, `6.1.y`, `6.6.y`,
`6.12.y`, `6.15.y`, `6.16.y`, `6.17.y`, `6.18.y`, `6.19.y`, and
`7.0.y`: confirmed affected old references exist and identified branch
differences.
- [Phase 6] `git diff 80f4a7b8ce751^ 80f4a7b8ce751 | git apply --check`:
confirmed clean application to the current `7.0.y`-based working tree.
- [Phase 8] URL checks with Python HEAD/WebFetch: confirmed old direct
AMD URLs no longer behave as direct PDF references in several cases,
while the new SNP ABI URL returns an AMD PDF; other new AMD TIP URLs
resolve to AMD documentation portal pages.
- UNVERIFIED: full stable mailing-list history, because direct lore
stable WebFetch was blocked by Anubis and web search found no exact
stable discussion.
**YES**
Documentation/virt/kvm/x86/amd-memory-encryption.rst | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/virt/kvm/x86/amd-memory-encryption.rst b/Documentation/virt/kvm/x86/amd-memory-encryption.rst
index b2395dd4769de..bd04a908a8dbd 100644
--- a/Documentation/virt/kvm/x86/amd-memory-encryption.rst
+++ b/Documentation/virt/kvm/x86/amd-memory-encryption.rst
@@ -656,8 +656,8 @@ References
See [white-paper]_, [api-spec]_, [amd-apm]_, [kvm-forum]_, and [snp-fw-abi]_
for more info.
-.. [white-paper] https://developer.amd.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf
-.. [api-spec] https://support.amd.com/TechDocs/55766_SEV-KM_API_Specification.pdf
-.. [amd-apm] https://support.amd.com/TechDocs/24593.pdf (section 15.34)
+.. [white-paper] https://docs.amd.com/v/u/en-US/memory-encryption-white-paper
+.. [api-spec] https://docs.amd.com/v/u/en-US/55766_PUB_3.24_SEV_API
+.. [amd-apm] https://docs.amd.com/v/u/en-US/24593_3.44_APM_Vol2 (section 15.34)
.. [kvm-forum] https://www.linux-kvm.org/images/7/74/02x08A-Thomas_Lendacky-AMDs_Virtualizatoin_Memory_Encryption_Technology.pdf
-.. [snp-fw-abi] https://www.amd.com/system/files/TechDocs/56860.pdf
+.. [snp-fw-abi] https://www.amd.com/content/dam/amd/en/documents/developer/56860.pdf
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-6.18] ALSA: doc: cs35l56: Update path to HDA driver source
From: Sasha Levin @ 2026-05-20 11:19 UTC (permalink / raw)
To: patches, stable
Cc: Richard Fitzgerald, Takashi Iwai, Sasha Levin, david.rhodes,
perex, tiwai, corbet, linux-sound, patches, linux-doc,
linux-kernel
In-Reply-To: <20260520111944.3424570-1-sashal@kernel.org>
From: Richard Fitzgerald <rf@opensource.cirrus.com>
[ Upstream commit 74e8409821ac8cda70bf23eb593f2c7f6e3b5a2f ]
The HDA drivers were moved to sound/hda/... so update a Documentation
reference that still pointed to the old location.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260511104148.36382-1-rf@opensource.cirrus.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Phase 1: Commit Message Forensics
Record 1.1: Subsystem `ALSA: doc: cs35l56`; action verb `Update`;
intent: correct a stale documentation path to the HDA driver source.
Record 1.2: Tags present in supplied message: `Signed-off-by: Richard
Fitzgerald <rf@opensource.cirrus.com>`, `Link: https://patch.msgid.link/
20260511104148.36382-1-rf@opensource.cirrus.com`, `Signed-off-by:
Takashi Iwai <tiwai@suse.de>`. No `Fixes:`, `Reported-by:`, `Tested-
by:`, `Reviewed-by:`, `Acked-by:`, or `Cc: stable`.
Record 1.3: The body says the HDA drivers moved to `sound/hda/...`,
leaving this documentation reference pointing at the old
`sound/pci/hda/...` location. Symptom is incorrect documentation only;
no runtime failure, crash, data corruption, or security impact is
described.
Record 1.4: This is not a hidden runtime bug fix. It is a direct
documentation correction.
## Phase 2: Diff Analysis
Record 2.1: One file changed: `Documentation/sound/codecs/cs35l56.rst`,
1 insertion and 1 deletion. No functions modified. Scope: single-file
documentation-only surgical change.
Record 2.2: Before: HDA users were pointed to
`sound/pci/hda/cs35l56_hda.c`. After: they are pointed to
`sound/hda/codecs/side-codecs/cs35l56_hda.c`.
Record 2.3: Bug category: documentation correctness fix. Verified
current tree has `sound/hda/codecs/side-codecs/cs35l56_hda.c`;
`sound/pci/hda` does not exist in this checkout.
Record 2.4: Fix quality is obvious and minimal. Regression risk is
runtime zero, but backport targeting matters: applying it to older trees
where the driver is still under `sound/pci/hda` would make the
documentation wrong.
## Phase 3: Git History Investigation
Record 3.1: `git blame` shows the stale documentation line was
introduced by `088fb4ee17fc4` (`ALSA: doc: cs35l56: Add information
about Cirrus Logic CS35L54/56/57`). The line became stale when
`6014e9021b28e` moved HDA codec drivers into `sound/hda/codecs`.
Record 3.2: No `Fixes:` tag is present, so there was no Fixes target to
follow.
Record 3.3: Recent file history shows only CS35L56 documentation
updates. Related source movement is `6014e9021b28e`, which renamed
`sound/pci/hda/cs35l56_hda.c` to `sound/hda/codecs/side-
codecs/cs35l56_hda.c`.
Record 3.4: Author Richard Fitzgerald has multiple recent CS35L56/HDA-
related commits in this subsystem, including documentation and HDA
driver fixes.
Record 3.5: Dependency identified: this patch is correct only in trees
that already contain the HDA move commit `6014e9021b28e`.
## Phase 4: Mailing List And External Research
Record 4.1: `b4 am` using message ID
`20260511104148.36382-1-rf@opensource.cirrus.com` found a single patch
submission and reported no newer revision. Direct `WebFetch` to
lore/patch.msgid.link was blocked by Anubis, but `b4` retrieved the
mbox.
Record 4.2: `b4 dig -c` could not be run for the candidate commit
because no candidate commit hash was supplied and the commit was not
found on checked named branches searched. `b4 am` verified author DKIM
signatures and the patch metadata. `b4 dig -c 6014e9021b28e -w` verified
the prerequisite move patch was an ALSA HDA series sent to `linux-sound`
and relevant HDA/Cirrus recipients.
Record 4.3: No bug report, syzbot report, crash report, or user report
is linked.
Record 4.4: Candidate is standalone as a documentation update, but
semantically depends on the prior source-tree move.
Record 4.5: Web searches and local pending branch searches found no
stable-specific discussion for this exact documentation patch.
## Phase 5: Code Semantic Analysis
Record 5.1: No functions modified; documentation text only.
Record 5.2: No callers; this is not runtime code.
Record 5.3: No callees; no allocations, locks, I/O, or side effects.
Record 5.4: No userspace-triggerable kernel execution path. Impact is
limited to readers of the documentation.
Record 5.5: Search found the old path only in
`Documentation/sound/codecs/cs35l56.rst` among `.rst` files checked.
## Phase 6: Stable Tree Analysis
Record 6.1: Tag containment shows the documentation exists from
`v6.13+`; the HDA move exists from `v6.17+`. Therefore the stale-path
documentation issue exists only in trees containing both, i.e.
approximately `v6.17+` and later.
Record 6.2: `git apply --check` confirms the patch applies cleanly to
the current `7.0.y` tree. Backport difficulty is trivial for affected
trees, but it must not be applied to trees where the HDA driver still
lives under `sound/pci/hda`.
Record 6.3: No related stable fix for this exact path correction was
found in local pending branches.
## Phase 7: Subsystem And Maintainer Context
Record 7.1: Subsystem is ALSA sound documentation for Cirrus CS35L56
HDA/SoundWire amplifiers. Criticality: peripheral/documentation, not
runtime core.
Record 7.2: Sound documentation and HDA side-codec areas are actively
maintained; recent logs show multiple CS35L56/HDA commits.
## Phase 8: Impact And Risk Assessment
Record 8.1: Affected population: developers, maintainers, integrators,
and users consulting this CS35L56 documentation in kernels where the HDA
source has moved.
Record 8.2: Trigger condition: reading the documentation. Not
triggerable as a kernel runtime fault.
Record 8.3: Failure mode: stale documentation path. Severity LOW, but
documentation fixes are explicitly acceptable stable material due zero
runtime risk.
Record 8.4: Benefit is modest but real for affected trees; risk is very
low if limited to trees with `6014e9021b28e`, but negative for older
trees where the old path is still correct.
## Phase 9: Final Synthesis
Record 9.1: Evidence for backporting: fixes an objectively wrong
documentation reference, one-line contained patch, no runtime regression
risk, applies cleanly to current `7.0.y`, documentation/comment fixes
are an accepted stable exception. Evidence against: no runtime bug, no
important crash/security/corruption impact, and it must be branch-
limited. Unresolved: exact upstream candidate commit hash was not
available locally.
Record 9.2: Stable rules: obviously correct: yes; tested: `b4` says
applies cleanly and local `git apply --check` passed; fixes a real bug:
yes, documentation bug; important runtime issue: no; small and
contained: yes, 1 line; no new feature/API: yes; applies to affected
stable trees: yes, for trees after the HDA move.
Record 9.3: Exception category: documentation fix.
Record 9.4: Decision: backport is appropriate, but only to stable trees
that already contain the HDA source move to `sound/hda/codecs/side-
codecs`. Do not apply to older stable trees where
`sound/pci/hda/cs35l56_hda.c` remains the correct path.
## Verification
- [Phase 1] Parsed supplied commit message and downloaded mbox:
confirmed subject, author, message ID, and one-line documentation
rationale.
- [Phase 2] Read `Documentation/sound/codecs/cs35l56.rst`: confirmed old
path is present.
- [Phase 2] Checked filesystem: confirmed `sound/hda/codecs/side-
codecs/cs35l56_hda.c` exists and `sound/pci/hda` does not in current
tree.
- [Phase 3] `git blame -L 35,45`: confirmed stale line came from
`088fb4ee17fc4`.
- [Phase 3] `git show 6014e9021b28e`: confirmed HDA codecs, including
`cs35l56_hda.c`, were moved from `sound/pci/hda` to
`sound/hda/codecs/side-codecs`.
- [Phase 4] `b4 am`: retrieved the patch, found one patch, no newer
revision, DKIM signed.
- [Phase 4] `b4 dig -c <msgid>`: failed because `b4 dig` requires a
commit-ish, not a message ID.
- [Phase 4] WebFetch to lore/patch.msgid.link: blocked by Anubis.
- [Phase 6] `git tag --contains`: documentation starts at `v6.13+`; HDA
move starts at `v6.17+`.
- [Phase 6] `git apply --check`: candidate patch applies cleanly to
current tree.
- [Phase 6] `git ls-tree`: `v6.6`/`v6.12` have old HDA source path and
no affected doc; `v6.18` has both affected doc and new HDA source
path.
- UNVERIFIED: Candidate final upstream commit hash, because it was not
found on searched local named branches and was not provided.
**YES**
Documentation/sound/codecs/cs35l56.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/sound/codecs/cs35l56.rst b/Documentation/sound/codecs/cs35l56.rst
index d5363b08f5152..b3f8c1c238518 100644
--- a/Documentation/sound/codecs/cs35l56.rst
+++ b/Documentation/sound/codecs/cs35l56.rst
@@ -40,7 +40,7 @@ There are two drivers in the kernel
*For systems using SoundWire*: sound/soc/codecs/cs35l56.c and associated files
-*For systems using HDA*: sound/pci/hda/cs35l56_hda.c
+*For systems using HDA*: sound/hda/codecs/side-codecs/cs35l56_hda.c
Firmware
========
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0] Documentation: security-bugs: do not systematically Cc the security team
From: Sasha Levin @ 2026-05-20 11:19 UTC (permalink / raw)
To: patches, stable
Cc: Willy Tarreau, Greg KH, Leon Romanovsky, Jonathan Corbet,
Sasha Levin, security, workflows, linux-doc, linux-kernel
In-Reply-To: <20260520111944.3424570-1-sashal@kernel.org>
From: Willy Tarreau <w@1wt.eu>
[ Upstream commit aed3c3346765e4317bb2ec6ff872e1c952e128ab ]
With the increase of automated reports, the security team is dealing
with way more messages than really needed. The reporting process works
well with most teams so there is no need to systematically involve the
security team in reports.
Let's suggest to keep it for small lists of recipients and new reporters
only. This should continue to cover the risk of lost messages while
reducing the volume from prolific reporters.
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Leon Romanovsky <leon@kernel.org>
Reviewed-by: Leon Romanovsky <leon@kernel.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20260509094755.2838-2-w@1wt.eu>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Phase 1: Commit Message Forensics
Record 1.1: Subsystem `Documentation/process/security-bugs`; action verb
`do not`; intent is to update security bug reporting instructions so
reporters do not always Cc the security team.
Record 1.2: Tags present: `Cc: Greg KH <gregkh@linuxfoundation.org>`,
`Cc: Leon Romanovsky <leon@kernel.org>`, `Reviewed-by: Leon Romanovsky
<leon@kernel.org>`, `Reviewed-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>`, `Signed-off-by: Willy Tarreau
<w@1wt.eu>`, `Signed-off-by: Jonathan Corbet <corbet@lwn.net>`,
`Message-ID: <20260509094755.2838-2-w@1wt.eu>`. No `Fixes:`, no
`Reported-by:`, no `Tested-by:`, no `Cc: stable`.
Record 1.3: The body describes a process/documentation problem:
increased automated reports create more mail to the security team than
needed. Symptom is excess security-team involvement, not a kernel
runtime crash or data corruption. No affected kernel versions are named.
Record 1.4: This is not a hidden code bug fix. It is an explicit
documentation/process update that corrects now-overbroad guidance.
## Phase 2: Diff Analysis
Record 2.1: One file changed: `Documentation/process/security-bugs.rst`,
9 insertions and 1 deletion in the submitted patch. No functions are
modified. Scope is single-file documentation-only.
Record 2.2: Before: reports “must” be sent to maintainers with the
security team in Cc. After: reports still go to maintainers, but
security-team Cc is mandatory only for two-or-fewer recipients, advised
for early reports or specific help, and no longer necessary for
comfortable reporters sending to large teams.
Record 2.3: Bug category is documentation/process correctness. No
resource leak, race, memory safety, refcount, initialization, endian, or
hardware quirk mechanism exists.
Record 2.4: Fix quality is high for its scope: small, reviewed,
documentation-only, no runtime behavior. Regression risk is limited to
possibly changing reporter behavior; no kernel runtime regression is
possible from the diff itself.
## Phase 3: Git History Investigation
Record 3.1: `git blame` shows the replaced sentence was introduced by
`a72b832a482372` (“Documentation: explain how to find maintainers
addresses for security reports”), first contained by `v7.0-rc7~8^2~2`.
Record 3.2: No `Fixes:` tag is present, so there is no Fixes target to
follow.
Record 3.3: Recent history of `Documentation/process/security-bugs.rst`
shows a series of security-reporting documentation updates by Willy
Tarreau, including contact/process clarifications and typo fixes. This
patch is standalone at the diff level but part of a three-patch
documentation series.
Record 3.4: The author has multiple recent commits in
`Documentation/process/security-bugs.rst`. Maintainer lookup identifies
`Security Officers <security@kernel.org>` and `Jonathan Corbet
<corbet@lwn.net>` for this file.
Record 3.5: No code dependencies or functions exist. The exact patch
depends on the newer rewritten security-bugs document layout present in
`7.0.y`; older stable branches do not contain `a72b832a482372`.
## Phase 4: Mailing List And External Research
Record 4.1: `b4 dig -c` could not be used because no candidate commit
SHA was available locally or in the prompt, and local `master`, `docs-
next`, and `all-next` searches did not find the commit object. Using the
supplied Message-ID, `b4 am` found the original submission at
`https://patch.msgid.link/20260509094755.2838-1-w@1wt.eu`.
Record 4.2: `b4 am` and the mbox show v3 of a 3-patch series, 33 thread
messages, sent to Greg KH, Leon Romanovsky, Jonathan Corbet, Shuah Khan,
`security@kernel.org`, `workflows@vger.kernel.org`, `linux-
doc@vger.kernel.org`, and `linux-kernel@vger.kernel.org`.
Record 4.3: No bug report link, syzbot report, Bugzilla report, or user
crash report exists. Lore WebFetch was blocked by Anubis, but `b4`
successfully fetched the mbox.
Record 4.4: Series context: patch 1/3 is this Cc guidance change; patch
2/3 adds security-bug/threat-model documentation; patch 3/3 clarifies
AI-assisted reports. Cover letter says v2 reworded the “when to Cc” part
based on Greg’s feedback; v3 included wording/structure feedback and
added reviews.
Record 4.5: I found no stable-specific discussion or stable nomination
in the fetched thread. Jonathan Corbet said he applied the series to
`docs-fixes` after short linux-next exposure.
## Phase 5: Code Semantic Analysis
Record 5.1: No functions modified; documentation only.
Record 5.2: No callers; affected audience is readers of
`Documentation/process/security-bugs.rst`.
Record 5.3: No callees or side effects.
Record 5.4: Reachability is not runtime reachability. The path is
“reporter reads stable-tree documentation and follows reporting
instructions.”
Record 5.5: `rg` found the old mandatory-Cc sentence only in
`Documentation/process/security-bugs.rst`; related security-team
references remain elsewhere in the same document.
## Phase 6: Cross-Referencing And Stable Tree Analysis
Record 6.1: `a72b832a482372` is an ancestor of `stable/linux-7.0.y` but
not of local `stable/linux-5.15.y`, `stable/linux-6.1.y`,
`stable/linux-6.6.y`, `stable/linux-6.12.y`, `stable/linux-6.18.y`, or
`stable/linux-6.19.y`. So this exact buggy/obsolete sentence is
confirmed in `7.0.y`; older local stable trees have older document
layouts.
Record 6.2: `b4` reports the series base applies cleanly to the current
tree, which is `stable/linux-7.0.y`. Older stable trees would need a
different documentation backport if maintainers wanted equivalent
guidance there.
Record 6.3: No related stable fix for this exact wording was found in
local history.
## Phase 7: Subsystem And Maintainer Context
Record 7.1: Subsystem is documentation/process, specifically security
bug reporting. Criticality is process-important, not runtime
core/driver/filesystem criticality.
Record 7.2: The file has active recent development, with several
2025-2026 security-reporting documentation updates.
## Phase 8: Impact And Risk Assessment
Record 8.1: Affected population is documentation readers: security bug
reporters, maintainers, and the kernel security team. No running kernel
users are directly affected.
Record 8.2: Trigger is following the stable tree’s security-bug
reporting documentation. This can be done by any reporter, but it is not
a syscall or kernel execution path.
Record 8.3: Failure mode severity is low for runtime stability, but
medium for security-process efficiency: the old wording can
unnecessarily add the private security team to large-team reports.
Record 8.4: Benefit is moderate for keeping security reporting guidance
current and reducing unnecessary private-list traffic. Risk is very low
because the patch is documentation-only and reviewed.
## Phase 9: Final Synthesis
Record 9.1: Evidence for backporting: documentation-only; zero runtime
regression risk; corrects overbroad/obsolete reporting guidance;
reviewed by Leon Romanovsky and Greg Kroah-Hartman; applied by
documentation maintainer Jonathan Corbet; relevant to security reporting
workflow; clean for `7.0.y`.
Evidence against: it does not fix a kernel runtime bug, crash, security
vulnerability, corruption, or deadlock; older stable trees do not
contain the exact rewritten section, so this exact patch is mainly
applicable to `7.0.y`.
Unresolved: I could not run `b4 dig -c` without a commit SHA, and
WebFetch of lore was blocked by Anubis. The `b4` Message-ID fetch
supplied the needed thread content.
Record 9.2: Stable rules: obviously correct and reviewed: yes. Fixes
real user-visible runtime bug: no. Important
crash/security/corruption/deadlock: no. Small and contained: yes, one
documentation file. No new feature/API: yes. Applies to stable: yes for
`7.0.y`; older branches need separate handling.
Record 9.3: Exception category: documentation fix/update. This is the
reason it qualifies despite not being a runtime bug.
Record 9.4: Decision: backport where the affected documentation exists,
especially `7.0.y`. The runtime benefit is nonexistent, but the risk is
also nonexistent, and stable policy exceptions allow documentation fixes
that correct obsolete guidance.
## Verification
- Phase 1: Parsed supplied commit tags and b4 patch headers; confirmed
no `Fixes:`, `Reported-by:`, `Tested-by`, or `Cc: stable`.
- Phase 2: Read supplied diff and b4 patch; confirmed one documentation
file, 9 insertions/1 deletion, no code.
- Phase 3: Ran `git blame -L 148,152 -- Documentation/process/security-
bugs.rst`; old sentence introduced by `a72b832a482372`.
- Phase 3: Ran `git describe --contains a72b832a482372`; first contained
around `v7.0-rc7~8^2~2`.
- Phase 3: Ran file and author history commands; confirmed recent
related docs updates by Willy Tarreau.
- Phase 4: Local `git log` searches on current history, `master`, `docs-
next`, and `all-next` did not find the candidate commit object.
- Phase 4: `b4 am -o /tmp/security-bugs-b4
20260509094755.2838-2-w@1wt.eu` found a v3 3-patch series, 33
messages, and reported clean apply to current tree.
- Phase 4: `b4 mbox` saved the thread mbox; `rg` found no stable
nomination or NAK for this patch.
- Phase 4: WebFetch of lore URLs was blocked by Anubis; not used for the
final decision.
- Phase 5: `rg` over `Documentation` confirmed the exact mandatory-Cc
sentence appears in `Documentation/process/security-bugs.rst`.
- Phase 6: `git merge-base --is-ancestor a72b832a482372
stable/linux-7.0.y` returned true; checks for `5.15.y`, `6.1.y`,
`6.6.y`, `6.12.y`, `6.18.y`, and `6.19.y` returned false.
- Phase 7: `./scripts/get_maintainer.pl` identified Security Officers
and Jonathan Corbet for the file; `MAINTAINERS` confirms
`DOCUMENTATION PROCESS`, `SECURITY CONTACT`, and `STABLE BRANCH`
entries.
- Phase 8: Failure mode verified from commit text and diff only:
documentation/process burden, not runtime failure.
**YES**
Documentation/process/security-bugs.rst | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index 27b028e858610..6dc525858125e 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -148,7 +148,15 @@ run additional tests. Reports where the reporter does not respond promptly
or cannot effectively discuss their findings may be abandoned if the
communication does not quickly improve.
-The report must be sent to maintainers, with the security team in ``Cc:``.
+The report must be sent to maintainers. If there are two or fewer
+recipients in your message, you must also always Cc: the Linux kernel
+security team who will ensure the message is delivered to the proper
+people, and will be able to assist small maintainer teams with processes
+they may not be familiar with. For larger teams, Cc: the Linux kernel
+security team for your first few reports or when seeking specific help,
+such as when resending a message which got no response within a week.
+Once you have become comfortable with the process for a few reports, it is
+no longer necessary to Cc: the security list when sending to large teams.
The Linux kernel security team can be contacted by email at
<security@kernel.org>. This is a private list of security officers
who will help verify the bug report and assist developers working on a fix.
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 00/12] misc/syncobj: add /dev/syncobj device
From: Christian König @ 2026-05-20 11:21 UTC (permalink / raw)
To: Michel Dänzer, Xaver Hugl
Cc: Julian Orth, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Sumit Semwal, Jonathan Corbet,
Shuah Khan, Arnd Bergmann, Greg Kroah-Hartman, dri-devel,
linux-kernel, linux-media, linaro-mm-sig, linux-doc,
wayland-devel
In-Reply-To: <385a4d4f-fe22-41a7-8d4b-4dc6bc9930d3@mailbox.org>
On 5/20/26 10:13, Michel Dänzer wrote:
> On 5/19/26 18:00, Christian König wrote:
>> On 5/19/26 17:31, Xaver Hugl wrote:
>>> Am Di., 19. Mai 2026 um 15:29 Uhr schrieb Christian König
>>> <christian.koenig@amd.com>:
>>>>> 1. This series makes the ability to manipulate syncobjs available
>>>>> independently of attached hardware.
>>>>> 2. It makes it available under a consistent path /dev/syncobj.
>>>>
>>>> Exactly that is a big no-go. This has to be under /dev/dri.
>>> FWIW udmabuf is also under /dev directly, but I don't think any
>>> compositor developer would complain about a different path.
>>> What are the rules for that? Could this simply be put in /dev/dri/syncobj?
>>
>> The syncobj are actually the DRM specific way of doing things. The general kernel wide way is to use sync files (see drivers/dma-buf/sync_file.c).
>>
>> But there has already been tons of problems with those sync files. E.g. they doesn't support your use case at all since they don't have wait before submit behavior.
>>
>> So there are already ways to do this, but the Linux kernel so far told everybody that this is forbidden. The DRM syncobj wait before signal functionality is much better, but then basically the second try to do this.
>
> I'm not quite sure what you're getting at here, just to be clear though:
>
> While the syncobj Wayland protocol extension supports wait-before-submit behaviour at the Wayland protocol level, it doesn't need or cause wait-before-submit behaviour for DMA fences in the kernel. The usual rules apply to fences attached to syncobj timeline points. The wait-before-submit behaviour at the Wayland protocol level comes from allowing submit before a fence is attached to the acquire timeline point.
Yeah I know. I'm one of the people who came up with the idea of doing wait before signal this way in the drm_syncobj.
What I wanted to say is that a lot of people used the dma_fence to implement wait before signal before and got a bloody nose from that.
> (It took me a while to realize this distinction, before which I mistakenly thought the kernel's DMA fence rules would prohibit wait-before-submit behaviour at the Wayland protocol level as well)
This is what surprised me.
The drm_syncobj implementation solved the wait before signal for the kernel, but my last feedback was that we basically just moved the issue to userspace and Wayland compositors would have quite some overhead to implement it correctly.
That compositors now use eventfd to simplify that was news to me but makes totally sense in hindsight.
But anyway, we need to somehow simplify the drm_syncobj -> eventfd usage in the compositor. That requirement is perfectly justified and avoiding importing the drm_syncobj fd into any DRM driver should actually be really easy to implement.
Regards,
Christian.
^ permalink raw reply
* Re: [PATCH v5 02/13] iio: core: support 64-bit register through debugfs
From: Jonathan Cameron @ 2026-05-20 11:31 UTC (permalink / raw)
To: Rodrigo Alencar
Cc: rodrigo.alencar, linux-iio, devicetree, linux-kernel, linux-doc,
linux-hardening, Lars-Peter Clausen, Michael Hennerich,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva
In-Reply-To: <unsohuo2hfsa7zzhprfpvtbatmu3guew6jpal7k2wvirpzwxfn@rjb4uz3k5dp3>
On Mon, 18 May 2026 14:56:06 +0100
Rodrigo Alencar <455.rodrigo.alencar@gmail.com> wrote:
> On 26/05/17 06:56PM, sashiko-bot@kernel.org wrote:
> > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> > - [Medium] Silent truncation of 64-bit values when written to a 32-bit register access function.
> > --
> >
> > commit 64785a0c1416e2cf718b558aa7a2cc9ac39b2d81
> > Author: Rodrigo Alencar <rodrigo.alencar@analog.com>
> >
> > iio: core: support 64-bit register through debugfs
> >
> > This commit introduces a debugfs_reg64_access function pointer to iio_info
> > to allow 64-bit register reads and writes through debugfs. The file operation
> > callbacks are modified to prefer the 64-bit variant when available.
> >
> > > diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> > > index e587aca79b8e7..5c8404efd0a56 100644
> > > --- a/drivers/iio/industrialio-core.c
> > > +++ b/drivers/iio/industrialio-core.c
> >
> > [ ... ]
> >
> > > @@ -429,7 +439,7 @@ static ssize_t iio_debugfs_write_reg(struct file *file,
> > >
> > > buf[ret] = '\0';
> > >
> > > - ret = sscanf(buf, "%i %i", ®, &val);
> > > + ret = sscanf(buf, "%i %lli", ®, &val64);
> > >
> > > switch (ret) {
> > > case 1:
> > > @@ -437,8 +447,12 @@ static ssize_t iio_debugfs_write_reg(struct file *file,
> > > break;
> > > case 2:
> > > iio_dev_opaque->cached_reg_addr = reg;
> > > - ret = indio_dev->info->debugfs_reg_access(indio_dev, reg,
> > > - val, NULL);
> > > + if (indio_dev->info->debugfs_reg64_access)
> > > + ret = indio_dev->info->debugfs_reg64_access(indio_dev, reg,
> > > + val64, NULL);
> > > + else
> > > + ret = indio_dev->info->debugfs_reg_access(indio_dev, reg,
> > > + val64, NULL);
> >
> > Could this introduce a regression where values are silently truncated if the
> > provided input exceeds 32 bits?
> >
> > Since the input is now unconditionally parsed as a 64-bit integer, falling
> > back to debugfs_reg_access (which takes an unsigned int for writeval) will
> > implicitly cast val64. If a user provides a value larger than UINT_MAX to a
> > driver that only provides the 32-bit callback, it appears the value will be
> > truncated rather than rejected with an error like -EINVAL.
>
> Maybe -EINVAL can be returned for that case indeed. For a debug interface I
> did not see that as a problem.
Agreed - I don't see this as important either way.
>
> > --
> > Sashiko AI review · https://sashiko.dev/#/patchset/20260517-ad9910-iio-driver-v5-0-31599c88314a@analog.com?part=2
>
^ permalink raw reply
* Re: [PATCH 00/12] misc/syncobj: add /dev/syncobj device
From: Julian Orth @ 2026-05-20 11:46 UTC (permalink / raw)
To: Christian König
Cc: Michel Dänzer, Xaver Hugl, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Sumit Semwal,
Jonathan Corbet, Shuah Khan, Arnd Bergmann, Greg Kroah-Hartman,
dri-devel, linux-kernel, linux-media, linaro-mm-sig, linux-doc,
wayland-devel
In-Reply-To: <1e94106a-f72e-447e-9885-2d2cc8f8e722@amd.com>
On Wed, May 20, 2026 at 1:21 PM Christian König
<christian.koenig@amd.com> wrote:
>
> On 5/20/26 10:13, Michel Dänzer wrote:
> > On 5/19/26 18:00, Christian König wrote:
> >> On 5/19/26 17:31, Xaver Hugl wrote:
> >>> Am Di., 19. Mai 2026 um 15:29 Uhr schrieb Christian König
> >>> <christian.koenig@amd.com>:
> >>>>> 1. This series makes the ability to manipulate syncobjs available
> >>>>> independently of attached hardware.
> >>>>> 2. It makes it available under a consistent path /dev/syncobj.
> >>>>
> >>>> Exactly that is a big no-go. This has to be under /dev/dri.
> >>> FWIW udmabuf is also under /dev directly, but I don't think any
> >>> compositor developer would complain about a different path.
> >>> What are the rules for that? Could this simply be put in /dev/dri/syncobj?
> >>
> >> The syncobj are actually the DRM specific way of doing things. The general kernel wide way is to use sync files (see drivers/dma-buf/sync_file.c).
> >>
> >> But there has already been tons of problems with those sync files. E.g. they doesn't support your use case at all since they don't have wait before submit behavior.
> >>
> >> So there are already ways to do this, but the Linux kernel so far told everybody that this is forbidden. The DRM syncobj wait before signal functionality is much better, but then basically the second try to do this.
> >
> > I'm not quite sure what you're getting at here, just to be clear though:
> >
> > While the syncobj Wayland protocol extension supports wait-before-submit behaviour at the Wayland protocol level, it doesn't need or cause wait-before-submit behaviour for DMA fences in the kernel. The usual rules apply to fences attached to syncobj timeline points. The wait-before-submit behaviour at the Wayland protocol level comes from allowing submit before a fence is attached to the acquire timeline point.
>
> Yeah I know. I'm one of the people who came up with the idea of doing wait before signal this way in the drm_syncobj.
>
> What I wanted to say is that a lot of people used the dma_fence to implement wait before signal before and got a bloody nose from that.
>
> > (It took me a while to realize this distinction, before which I mistakenly thought the kernel's DMA fence rules would prohibit wait-before-submit behaviour at the Wayland protocol level as well)
>
> This is what surprised me.
>
> The drm_syncobj implementation solved the wait before signal for the kernel, but my last feedback was that we basically just moved the issue to userspace and Wayland compositors would have quite some overhead to implement it correctly.
>
> That compositors now use eventfd to simplify that was news to me but makes totally sense in hindsight.
>
> But anyway, we need to somehow simplify the drm_syncobj -> eventfd usage in the compositor.
That is not the only usage in the compositor. Compositors use all of
the following operations on syncobjs:
- creating syncobjs
- waiting for points synchronously
- signaling points without a sync file
- querying points
- transferring sync files between points
- exporting sync files
- importing sync files
Which you can see by looking at the userspace code linked in the cover
letter. Bypassing the handle in one ioctl would gain compositors
nothing since they would still have to convert to handles and manage
their lifetime for all other ioctls.
> That requirement is perfectly justified and avoiding importing the drm_syncobj fd into any DRM driver should actually be really easy to implement.
That is what this series does.
>
> Regards,
> Christian.
^ permalink raw reply
* Re: [PATCH] video: console: mdacon: remove this obsolete driver
From: Helge Deller @ 2026-05-20 11:45 UTC (permalink / raw)
To: Ethan Nelson-Moore, linux-doc, linux-alpha, linux-serial,
linux-fbdev, Linux DRI Development, linuxppc-dev
Cc: Jonathan Corbet, Shuah Khan, Richard Henderson, Matt Turner,
Magnus Lindholm, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Greg Kroah-Hartman,
Jiri Slaby, Nicolas Pitre
In-Reply-To: <20260520033155.17378-1-enelsonmoore@gmail.com>
On 5/20/26 05:31, Ethan Nelson-Moore wrote:
> The mdacon driver supports using ISA MDA or Hercules-compatible display
> adapters as a secondary text console. This was commonly used in the
> 1990s and earlier for debugging software which took over the primary
> display. It is highly unlikely anyone is doing so nowadays because
> serial consoles and much better methods of debugging exist.
>
> The driver is not enabled by any defconfig, nor any of the
> dozens of distro configs collected at [1]. It has been relegated to VTs
> 13-16 since commit 0b9cf3aa6b1e ("mdacon messing up default vc's - set
> default to vc13-16 again") in Linux 2.6.27 (and before Linux 2.5.53 -
> see the link in the message of the above commit). The change in 2.6.27
> was done because it was incorrectly detecting non-MDA adapters as MDA
> and taking over all VTs, rendering them unusable.
>
> Furthermore, vgacon supports using MDA/Hercules-compatible adapters as
> the primary text console, so any systems with only one of these
> adapters were already using vgacon and will not experience any loss in
> functionality from the removal of this driver.
>
> Given all of these factors, the mdacon driver is likely entirely
> unused. Remove it.
I've applied this patch to the fbdev git tree, since I also believe that
there is no use case or user left (with Linux kernels >= 7.0), which uses the mdacon.
If someone thinks we need to keep it, please speak up.
Helge
>
> [1] https://github.com/nyrahul/linux-kernel-configs/tree/f0bee86a135a0406ea427855f52702dd00d770f9
>
> Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
> ---
> .../admin-guide/kernel-parameters.txt | 5 -
> arch/alpha/kernel/io.c | 2 +-
> arch/powerpc/include/asm/vga.h | 4 +-
> drivers/tty/vt/vt.c | 3 -
> drivers/video/console/Kconfig | 15 -
> drivers/video/console/Makefile | 1 -
> drivers/video/console/mdacon.c | 566 ------------------
> include/linux/console.h | 2 -
> include/linux/vt_buffer.h | 2 +-
> 9 files changed, 4 insertions(+), 596 deletions(-)
> delete mode 100644 drivers/video/console/mdacon.c
^ permalink raw reply
* Re: [PATCH v2 1/2] tools/mm: add a standalone GUP microbenchmark
From: Mark Brown @ 2026-05-20 11:58 UTC (permalink / raw)
To: Sarthak Sharma
Cc: Mike Rapoport, Andrew Morton, David Hildenbrand, Jonathan Corbet,
Jason Gunthorpe, John Hubbard, Peter Xu, Lorenzo Stoakes,
Liam R . Howlett, Vlastimil Babka, Suren Baghdasaryan,
Michal Hocko, Shuah Khan, linux-mm, linux-kselftest, linux-kernel,
linux-doc
In-Reply-To: <9382431f-3746-4477-bbef-87abb58bf180@arm.com>
[-- Attachment #1: Type: text/plain, Size: 910 bytes --]
On Wed, May 20, 2026 at 03:45:53PM +0530, Sarthak Sharma wrote:
> On 5/20/26 2:25 PM, Mike Rapoport wrote:
> > It seems that we need to better share the common code in
> > tools/testing/selftest.
> > And adding another copy of the hugetlb detection and setup code does not
> > seem like a great idea.
> Agreed, but that was the least disruptive approach I could think of.
> I am thinking of doing this now: should I move the
> hugepage_settings.[ch] to tools/lib/ and move the read_num(),
> write_num(), read_file() and write_file() helpers to a separate file in
> tools/lib/ itself without any ksft dependency? Then both
> tools/testing/selftests/* and tools/mm/ could share the same code.
Using tools/lib sounds sensible to me - as well as the sharing it makes
it clear that it's a library used by multiple things so avoids the
issues we sometimes have with selftest directories referencing each
other.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH mm-unstable v17 11/14] mm/khugepaged: Introduce mTHP collapse support
From: Nico Pache @ 2026-05-20 12:05 UTC (permalink / raw)
To: Wei Yang
Cc: linux-doc, linux-kernel, linux-mm, linux-trace-kernel, aarcange,
akpm, anshuman.khandual, apopple, baohua, baolin.wang, byungchul,
catalin.marinas, cl, corbet, dave.hansen, david, dev.jain, gourry,
hannes, hughd, jack, jackmanb, jannh, jglisse, joshua.hahnjy, kas,
lance.yang, liam, ljs, mathieu.desnoyers, matthew.brost, mhiramat,
mhocko, peterx, pfalcato, rakie.kim, raquini, rdunlap, rientjes,
rostedt, rppt, ryan.roberts, shivankg, sunnanyong, surenb,
thomas.hellstrom, tiwai, usamaarif642, vbabka, vishal.moola,
wangkefeng.wang, will, willy, yang, ying.huang, ziy, zokeefe
In-Reply-To: <20260512154431.jxcs632mqqatqtsw@master>
On Tue, May 12, 2026 at 9:44 AM Wei Yang <richard.weiyang@gmail.com> wrote:
>
> On Mon, May 11, 2026 at 12:58:11PM -0600, Nico Pache wrote:
> >Enable khugepaged to collapse to mTHP orders. This patch implements the
> >main scanning logic using a bitmap to track occupied pages and a stack
> >structure that allows us to find optimal collapse sizes.
> >
> >Previous to this patch, PMD collapse had 3 main phases, a light weight
> >scanning phase (mmap_read_lock) that determines a potential PMD
> >collapse, an alloc phase (mmap unlocked), then finally heavier collapse
> >phase (mmap_write_lock).
> >
> >To enabled mTHP collapse we make the following changes:
> >
> >During PMD scan phase, track occupied pages in a bitmap. When mTHP
> >orders are enabled, we remove the restriction of max_ptes_none during the
> >scan phase to avoid missing potential mTHP collapse candidates. Once we
> >have scanned the full PMD range and updated the bitmap to track occupied
> >pages, we use the bitmap to find the optimal mTHP size.
> >
> >Implement collapse_scan_bitmap() to perform binary recursion on the bitmap
> >and determine the best eligible order for the collapse. A stack structure
> >is used instead of traditional recursion to manage the search. This also
> >prevents a traditional recursive approach when the kernel stack struct is
> >limited. The algorithm recursively splits the bitmap into smaller chunks to
> >find the highest order mTHPs that satisfy the collapse criteria. We start
> >by attempting the PMD order, then moved on the consecutively lower orders
> >(mTHP collapse). The stack maintains a pair of variables (offset, order),
> >indicating the number of PTEs from the start of the PMD, and the order of
> >the potential collapse candidate.
> >
> >The algorithm for consuming the bitmap works as such:
> > 1) push (0, HPAGE_PMD_ORDER) onto the stack
> > 2) pop the stack
> > 3) check if the number of set bits in that (offset,order) pair
> > statisfy the max_ptes_none threshold for that order
> > 4) if yes, attempt collapse
> > 5) if no (or collapse fails), push two new stack items representing
> > the left and right halves of the current bitmap range, at the
> > next lower order
> > 6) repeat at step (2) until stack is empty.
> >
> >Below is a diagram representing the algorithm and stack items:
> >
> > offset mid_offset
> > | |
> > | |
> > v v
> > ____________________________________
> > | PTE Page Table |
> > --------------------------------------
> > <-------><------->
> > order-1 order-1
> >
> >mTHP collapses reject regions containing swapped out or shared pages.
> >This is because adding new entries can lead to new none pages, and these
> >may lead to constant promotion into a higher order mTHP. A similar
> >issue can occur with "max_ptes_none > HPAGE_PMD_NR/2" due to a collapse
> >introducing at least 2x the number of pages, and on a future scan will
> >satisfy the promotion condition once again. This issue is prevented via
> >the collapse_max_ptes_none() function which imposes the max_ptes_none
> >restrictions above.
> >
> >We currently only support mTHP collapse for max_ptes_none values of 0
> >and HPAGE_PMD_NR - 1. resulting in the following behavior:
> >
> > - max_ptes_none=0: Never introduce new empty pages during collapse
> > - max_ptes_none=HPAGE_PMD_NR-1: Always try collapse to the highest
> > available mTHP order
> >
> >Any other max_ptes_none value will emit a warning and skip mTHP collapse
> >attempts. There should be no behavior change for PMD collapse.
> >
> >Once we determine what mTHP sizes fits best in that PMD range a collapse
> >is attempted. A minimum collapse order of 2 is used as this is the lowest
> >order supported by anon memory as defined by THP_ORDERS_ALL_ANON.
> >
> >Currently madv_collapse is not supported and will only attempt PMD
> >collapse.
> >
> >We can also remove the check for is_khugepaged inside the PMD scan as
> >the collapse_max_ptes_none() function handles this logic now.
> >
> >Signed-off-by: Nico Pache <npache@redhat.com>
>
> [...]
>
> >+static int mthp_collapse(struct mm_struct *mm, unsigned long address,
> >+ int referenced, int unmapped, struct collapse_control *cc,
> >+ unsigned long enabled_orders)
> >+{
> >+ unsigned int nr_occupied_ptes, nr_ptes;
> >+ int max_ptes_none, collapsed = 0, stack_size = 0;
> >+ unsigned long collapse_address;
> >+ struct mthp_range range;
> >+ u16 offset;
> >+ u8 order;
> >+
> >+ collapse_mthp_stack_push(cc, &stack_size, 0, HPAGE_PMD_ORDER);
> >+
> >+ while (stack_size) {
> >+ range = collapse_mthp_stack_pop(cc, &stack_size);
> >+ order = range.order;
> >+ offset = range.offset;
> >+ nr_ptes = 1UL << order;
> >+
> >+ if (!test_bit(order, &enabled_orders))
> >+ goto next_order;
> >+
> >+ max_ptes_none = collapse_max_ptes_none(cc, NULL, order);
>
> I am thinking whether there is a behavioral change for userfaultfd_armed(vma).
>
> collapse_single_pmd()
> collapse_scan_pmd
> max_ptes_none = collapse_max_ptes_none(cc, vma)
> max_ptes_none = KHUGEPAGED_MAX_PTES_LIMIT --- (1)
> mthp_collapse
> max_ptes_none = collapse_max_ptes_none(cc, NULL) --- (2)
> collapse_huge_page(mm)
> hugepage_vma_revalidate(&vma)
> __collapse_huge_page_isolate(vma)
> max_ptes_none = collapse_max_ptes_none(cc, vma)
>
> Before mthp_collapse() introduced, userfaultfd_armed(vma) is skipped if there
> is any pte_none_or_zero() in collapse_scan_pmd().
>
> But now, max_ptes_none could be set to KHUGEPAGED_MAX_PTES_LIMIT at (1), so
> that we can scan all the pte to get the bitmap. This means
> userfaultfd_armed(vma) could continue even with pte_none_or_zero().
>
> Then in mthp_collapse(), collapse_max_ptes_none() at (2) ignores
> userfaultfd_armed(vma), which means it will continue to collapse a
> userfaultfd_armed(vma) when there is pte_none_or_zero().
>
> The good news is we will stop at __collapse_huge_page_isolate(), where we
> get collapse_max_ptes_none() with vma. But we already did a lot of work.
Good catch!
As you stated we eventually ensure we respect the uffd checks. So
there are no correctness issues, just the potential for wasted cycles.
At (1) we only do this if mTHPs are enabled. If that is the case, the
only waste that can arise is at the PMD order, as that order respects
the max_ptes_none value.
I think one approach is to gate (1) with the uffd check as well. That
way, if mTHPs are enabled and its uffd-armed, max_ptes_none will stay
at 0, and we bail early on the scan early if any none_ptes are hit.
But then we lose the ability to collapse to mTHPs that are uffd-armed,
where the PMD has none/zero-ptes and the mTHP fully has 0
non-none/zero-ptes.
ie) assume a PMD is 16 x's [xxxxxxxx00000000]
where x is a populated pte and 0 is not
If we guard this scan (1), then we will never check if its possible to
collapse to the smaller orders.
Let me know if you see a flaw in my logic, I think it's best to keep it as is?
>
> Not sure if I missed something.
>
> >+
> >+ if (max_ptes_none < 0)
> >+ return collapsed;
> >+
> >+ nr_occupied_ptes = collapse_mthp_count_present(cc, offset,
> >+ nr_ptes);
> >+
> >+ if (nr_occupied_ptes >= nr_ptes - max_ptes_none) {
> >+ int ret;
> >+
> >+ collapse_address = address + offset * PAGE_SIZE;
> >+ ret = collapse_huge_page(mm, collapse_address, referenced,
> >+ unmapped, cc, order);
> >+ if (ret == SCAN_SUCCEED) {
> >+ collapsed += nr_ptes;
> >+ continue;
> >+ }
> >+ }
> >+
> >+next_order:
> >+ if (order > KHUGEPAGED_MIN_MTHP_ORDER) {
> >+ const u8 next_order = order - 1;
> >+ const u16 mid_offset = offset + (nr_ptes / 2);
> >+
> >+ collapse_mthp_stack_push(cc, &stack_size, mid_offset,
> >+ next_order);
> >+ collapse_mthp_stack_push(cc, &stack_size, offset,
> >+ next_order);
> >+ }
> >+ }
> >+ return collapsed;
> >+}
> >+
> > static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> > struct vm_area_struct *vma, unsigned long start_addr,
> > bool *lock_dropped, struct collapse_control *cc)
> > {
> >- const int max_ptes_none = collapse_max_ptes_none(cc, vma, HPAGE_PMD_ORDER);
> >+ int max_ptes_none = collapse_max_ptes_none(cc, vma, HPAGE_PMD_ORDER);
> > const unsigned int max_ptes_shared = collapse_max_ptes_shared(cc, HPAGE_PMD_ORDER);
> > const unsigned int max_ptes_swap = collapse_max_ptes_swap(cc, HPAGE_PMD_ORDER);
> >+ enum tva_type tva_flags = cc->is_khugepaged ? TVA_KHUGEPAGED : TVA_FORCED_COLLAPSE;
> > pmd_t *pmd;
> >- pte_t *pte, *_pte;
> >- int none_or_zero = 0, shared = 0, referenced = 0;
> >+ pte_t *pte, *_pte, pteval;
> >+ int i;
> >+ int none_or_zero = 0, shared = 0, nr_collapsed = 0, referenced = 0;
> > enum scan_result result = SCAN_FAIL;
> > struct page *page = NULL;
> > struct folio *folio = NULL;
> > unsigned long addr;
> >+ unsigned long enabled_orders;
> > spinlock_t *ptl;
> > int node = NUMA_NO_NODE, unmapped = 0;
> >
> >@@ -1429,8 +1579,19 @@ static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> > goto out;
> > }
> >
> >+ bitmap_zero(cc->mthp_bitmap, MAX_PTRS_PER_PTE);
> > memset(cc->node_load, 0, sizeof(cc->node_load));
> > nodes_clear(cc->alloc_nmask);
> >+
> >+ enabled_orders = collapse_allowable_orders(vma, vma->vm_flags, tva_flags);
>
> Would it be 0 at this point?
If your question relates to the issue you brought up above, then yes,
max_ptes_none would be 0 if it's uffd-armed. We must recheck the
uffd-armed status before modifying it to 511.
>
> >+
> >+ /*
> >+ * If PMD is the only enabled order, enforce max_ptes_none, otherwise
> >+ * scan all pages to populate the bitmap for mTHP collapse.
> >+ */
> >+ if (enabled_orders != BIT(HPAGE_PMD_ORDER))
> >+ max_ptes_none = KHUGEPAGED_MAX_PTES_LIMIT;
> >+
> > pte = pte_offset_map_lock(mm, pmd, start_addr, &ptl);
> > if (!pte) {
> > cc->progress++;
> >@@ -1438,11 +1599,13 @@ static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> > goto out;
> > }
> >
> >- for (addr = start_addr, _pte = pte; _pte < pte + HPAGE_PMD_NR;
> >- _pte++, addr += PAGE_SIZE) {
> >+ for (i = 0; i < HPAGE_PMD_NR; i++) {
> >+ _pte = pte + i;
> >+ addr = start_addr + i * PAGE_SIZE;
> >+ pteval = ptep_get(_pte);
> >+
> > cc->progress++;
> >
> >- pte_t pteval = ptep_get(_pte);
> > if (pte_none_or_zero(pteval)) {
> > if (++none_or_zero > max_ptes_none) {
> > result = SCAN_EXCEED_NONE_PTE;
> >@@ -1522,6 +1685,8 @@ static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> > }
> > }
> >
> >+ /* Set bit for occupied pages */
> >+ __set_bit(i, cc->mthp_bitmap);
> > /*
> > * Record which node the original page is from and save this
> > * information to cc->node_load[].
> >@@ -1580,10 +1745,11 @@ static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> > if (result == SCAN_SUCCEED) {
> > /* collapse_huge_page expects the lock to be dropped before calling */
> > mmap_read_unlock(mm);
> >- result = collapse_huge_page(mm, start_addr, referenced,
> >- unmapped, cc, HPAGE_PMD_ORDER);
> >+ nr_collapsed = mthp_collapse(mm, start_addr, referenced, unmapped,
> >+ cc, enabled_orders);
> > /* collapse_huge_page will return with the mmap_lock released */
>
> collapse_huge_page will return with mmap_lock released, but mthp_collapse()
> may not?
We are now releasing the lock before calling mthp_collapse, which
subsequently calls collapse_huge_page. Even if `collapse_huge_page` is
never called-- say, because enabled_orders is 0 (which should not
happen) and all collapse orders are skipped (never calling
collapse_huge_page)-- we still return here with the lock dropped.
I think this is sound. Let me know if you think differently.
Cheers :)
-- Nico
>
> > *lock_dropped = true;
> >+ result = nr_collapsed ? SCAN_SUCCEED : SCAN_FAIL;
> > }
> > out:
> > trace_mm_khugepaged_scan_pmd(mm, folio, referenced,
> >--
> >2.54.0
>
> --
> Wei Yang
> Help you, Help me
>
^ permalink raw reply
* Re: [PATCH v6 02/43] KVM: Rename KVM_GENERIC_MEMORY_ATTRIBUTES to KVM_VM_MEMORY_ATTRIBUTES
From: Fuad Tabba @ 2026-05-20 12:08 UTC (permalink / raw)
To: ackerleytng
Cc: aik, andrew.jones, binbin.wu, brauner, chao.p.peng, david,
ira.weiny, jmattson, jthoughton, michael.roth, oupton,
pankaj.gupta, qperret, rick.p.edgecombe, rientjes, shivankg,
steven.price, willy, wyihan, yan.y.zhao, forkloop, pratyush,
suzuki.poulose, aneesh.kumar, liam, Paolo Bonzini,
Sean Christopherson, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Jonathan Corbet, Shuah Khan,
Shuah Khan, Vishal Annapurve, Andrew Morton, Chris Li,
Kairui Song, Kemeng Shi, Nhat Pham, Baoquan He, Barry Song,
Axel Rasmussen, Yuanchu Xie, Wei Xu, Youngjun Park, Qi Zheng,
Shakeel Butt, Kiryl Shutsemau, Jason Gunthorpe, Vlastimil Babka,
kvm, linux-kernel, linux-trace-kernel, linux-doc, linux-kselftest,
linux-mm, linux-coco
In-Reply-To: <20260507-gmem-inplace-conversion-v6-2-91ab5a8b19a4@google.com>
On Thu, 7 May 2026 at 21:22, Ackerley Tng via B4 Relay
<devnull+ackerleytng.google.com@kernel.org> wrote:
>
> From: Sean Christopherson <seanjc@google.com>
>
> Rename the per-VM memory attributes Kconfig to make it explicitly about
> per-VM attributes in anticipation of adding memory attributes support to
> guest_memfd, at which point it will be possible (and desirable) to have
> memory attributes without the per-VM support, even in x86.
>
> No functional change intended.
>
> Signed-off-by: Sean Christopherson <seanjc@google.com>
> Signed-off-by: Ackerley Tng <ackerleytng@google.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Cheers,
/fuad
> ---
> arch/x86/include/asm/kvm_host.h | 2 +-
> arch/x86/kvm/Kconfig | 6 +++---
> arch/x86/kvm/mmu/mmu.c | 2 +-
> arch/x86/kvm/x86.c | 2 +-
> include/linux/kvm_host.h | 8 ++++----
> include/trace/events/kvm.h | 4 ++--
> virt/kvm/Kconfig | 2 +-
> virt/kvm/kvm_main.c | 14 +++++++-------
> 8 files changed, 20 insertions(+), 20 deletions(-)
>
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index c470e40a00aa4..60b997764beef 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -2369,7 +2369,7 @@ void kvm_configure_mmu(bool enable_tdp, int tdp_forced_root_level,
> int tdp_max_root_level, int tdp_huge_page_level);
>
>
> -#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
> +#ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> #define kvm_arch_has_private_mem(kvm) ((kvm)->arch.has_private_mem)
> #endif
>
> diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
> index 801bf9e520db3..26f6afd51bbdc 100644
> --- a/arch/x86/kvm/Kconfig
> +++ b/arch/x86/kvm/Kconfig
> @@ -84,7 +84,7 @@ config KVM_SW_PROTECTED_VM
> bool "Enable support for KVM software-protected VMs"
> depends on EXPERT
> depends on KVM_X86 && X86_64
> - select KVM_GENERIC_MEMORY_ATTRIBUTES
> + select KVM_VM_MEMORY_ATTRIBUTES
> help
> Enable support for KVM software-protected VMs. Currently, software-
> protected VMs are purely a development and testing vehicle for
> @@ -135,7 +135,7 @@ config KVM_INTEL_TDX
> bool "Intel Trust Domain Extensions (TDX) support"
> default y
> depends on INTEL_TDX_HOST
> - select KVM_GENERIC_MEMORY_ATTRIBUTES
> + select KVM_VM_MEMORY_ATTRIBUTES
> select HAVE_KVM_ARCH_GMEM_POPULATE
> help
> Provides support for launching Intel Trust Domain Extensions (TDX)
> @@ -159,7 +159,7 @@ config KVM_AMD_SEV
> depends on KVM_AMD && X86_64
> depends on CRYPTO_DEV_SP_PSP && !(KVM_AMD=y && CRYPTO_DEV_CCP_DD=m)
> select ARCH_HAS_CC_PLATFORM
> - select KVM_GENERIC_MEMORY_ATTRIBUTES
> + select KVM_VM_MEMORY_ATTRIBUTES
> select HAVE_KVM_ARCH_GMEM_PREPARE
> select HAVE_KVM_ARCH_GMEM_INVALIDATE
> select HAVE_KVM_ARCH_GMEM_POPULATE
> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index 892246204435c..a80a876ab4ad6 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
> @@ -7899,7 +7899,7 @@ void kvm_mmu_pre_destroy_vm(struct kvm *kvm)
> vhost_task_stop(kvm->arch.nx_huge_page_recovery_thread);
> }
>
> -#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
> +#ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> static bool hugepage_test_mixed(struct kvm_memory_slot *slot, gfn_t gfn,
> int level)
> {
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 0a1b63c63d1a9..1560de1e95be0 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -13625,7 +13625,7 @@ static int kvm_alloc_memslot_metadata(struct kvm *kvm,
> }
> }
>
> -#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
> +#ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> kvm_mmu_init_memslot_memory_attributes(kvm, slot);
> #endif
>
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 4c14aee1fb063..7b9faa3545300 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -722,7 +722,7 @@ static inline int kvm_arch_vcpu_memslots_id(struct kvm_vcpu *vcpu)
> }
> #endif
>
> -#ifndef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
> +#ifndef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> static inline bool kvm_arch_has_private_mem(struct kvm *kvm)
> {
> return false;
> @@ -871,7 +871,7 @@ struct kvm {
> #ifdef CONFIG_HAVE_KVM_PM_NOTIFIER
> struct notifier_block pm_notifier;
> #endif
> -#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
> +#ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> /* Protected by slots_lock (for writes) and RCU (for reads) */
> struct xarray mem_attr_array;
> #endif
> @@ -2528,7 +2528,7 @@ static inline bool kvm_memslot_is_gmem_only(const struct kvm_memory_slot *slot)
> return slot->flags & KVM_MEMSLOT_GMEM_ONLY;
> }
>
> -#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
> +#ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> static inline unsigned long kvm_get_memory_attributes(struct kvm *kvm, gfn_t gfn)
> {
> return xa_to_value(xa_load(&kvm->mem_attr_array, gfn));
> @@ -2550,7 +2550,7 @@ static inline bool kvm_mem_is_private(struct kvm *kvm, gfn_t gfn)
> {
> return false;
> }
> -#endif /* CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES */
> +#endif /* CONFIG_KVM_VM_MEMORY_ATTRIBUTES */
>
> #ifdef CONFIG_KVM_GUEST_MEMFD
> int kvm_gmem_get_pfn(struct kvm *kvm, struct kvm_memory_slot *slot,
> diff --git a/include/trace/events/kvm.h b/include/trace/events/kvm.h
> index b282e3a867696..1ba72bd73ea2f 100644
> --- a/include/trace/events/kvm.h
> +++ b/include/trace/events/kvm.h
> @@ -358,7 +358,7 @@ TRACE_EVENT(kvm_dirty_ring_exit,
> TP_printk("vcpu %d", __entry->vcpu_id)
> );
>
> -#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
> +#ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> /*
> * @start: Starting address of guest memory range
> * @end: End address of guest memory range
> @@ -383,7 +383,7 @@ TRACE_EVENT(kvm_vm_set_mem_attributes,
> TP_printk("%#016llx -- %#016llx [0x%lx]",
> __entry->start, __entry->end, __entry->attr)
> );
> -#endif /* CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES */
> +#endif /* CONFIG_KVM_VM_MEMORY_ATTRIBUTES */
>
> TRACE_EVENT(kvm_unmap_hva_range,
> TP_PROTO(unsigned long start, unsigned long end),
> diff --git a/virt/kvm/Kconfig b/virt/kvm/Kconfig
> index 794976b88c6f9..5119cb37145fc 100644
> --- a/virt/kvm/Kconfig
> +++ b/virt/kvm/Kconfig
> @@ -100,7 +100,7 @@ config KVM_ELIDE_TLB_FLUSH_IF_YOUNG
> config KVM_MMU_LOCKLESS_AGING
> bool
>
> -config KVM_GENERIC_MEMORY_ATTRIBUTES
> +config KVM_VM_MEMORY_ATTRIBUTES
> bool
>
> config KVM_GUEST_MEMFD
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 89489996fbc1e..306153abbafa5 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -1115,7 +1115,7 @@ static struct kvm *kvm_create_vm(unsigned long type, const char *fdname)
> spin_lock_init(&kvm->mn_invalidate_lock);
> rcuwait_init(&kvm->mn_memslots_update_rcuwait);
> xa_init(&kvm->vcpu_array);
> -#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
> +#ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> xa_init(&kvm->mem_attr_array);
> #endif
>
> @@ -1300,7 +1300,7 @@ static void kvm_destroy_vm(struct kvm *kvm)
> cleanup_srcu_struct(&kvm->irq_srcu);
> srcu_barrier(&kvm->srcu);
> cleanup_srcu_struct(&kvm->srcu);
> -#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
> +#ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> xa_destroy(&kvm->mem_attr_array);
> #endif
> kvm_arch_free_vm(kvm);
> @@ -2418,7 +2418,7 @@ static int kvm_vm_ioctl_clear_dirty_log(struct kvm *kvm,
> }
> #endif /* CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT */
>
> -#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
> +#ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> static u64 kvm_supported_mem_attributes(struct kvm *kvm)
> {
> if (!kvm || kvm_arch_has_private_mem(kvm))
> @@ -2623,7 +2623,7 @@ static int kvm_vm_ioctl_set_mem_attributes(struct kvm *kvm,
>
> return kvm_vm_set_mem_attributes(kvm, start, end, attrs->attributes);
> }
> -#endif /* CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES */
> +#endif /* CONFIG_KVM_VM_MEMORY_ATTRIBUTES */
>
> struct kvm_memory_slot *gfn_to_memslot(struct kvm *kvm, gfn_t gfn)
> {
> @@ -4921,7 +4921,7 @@ static int kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg)
> case KVM_CAP_SYSTEM_EVENT_DATA:
> case KVM_CAP_DEVICE_CTRL:
> return 1;
> -#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
> +#ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> case KVM_CAP_MEMORY_ATTRIBUTES:
> return kvm_supported_mem_attributes(kvm);
> #endif
> @@ -5325,7 +5325,7 @@ static long kvm_vm_ioctl(struct file *filp,
> break;
> }
> #endif /* CONFIG_HAVE_KVM_IRQ_ROUTING */
> -#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
> +#ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> case KVM_SET_MEMORY_ATTRIBUTES: {
> struct kvm_memory_attributes attrs;
>
> @@ -5336,7 +5336,7 @@ static long kvm_vm_ioctl(struct file *filp,
> r = kvm_vm_ioctl_set_mem_attributes(kvm, &attrs);
> break;
> }
> -#endif /* CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES */
> +#endif /* CONFIG_KVM_VM_MEMORY_ATTRIBUTES */
> case KVM_CREATE_DEVICE: {
> struct kvm_create_device cd;
>
>
> --
> 2.54.0.563.g4f69b47b94-goog
>
>
^ 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