* Re: [PATCH v2 3/3] misc: Remove old APDS990x driver
From: Greg Kroah-Hartman @ 2026-04-19 8:42 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, Arnd Bergmann, Randy Dunlap, linux-iio, devicetree,
linux-kernel, linux-doc
In-Reply-To: <20260419083125.35572-4-clamor95@gmail.com>
On Sun, Apr 19, 2026 at 11:31:24AM +0300, Svyatoslav Ryhel wrote:
> The Avago APDS9900/9901 ALS/Proximity sensor is now supported by tsl2772
> IIO driver so there is no need to keep this old implementation. Remove it.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> Documentation/misc-devices/apds990x.rst | 128 ---
> drivers/misc/Kconfig | 10 -
> drivers/misc/Makefile | 1 -
> drivers/misc/apds990x.c | 1284 -----------------------
> include/linux/platform_data/apds990x.h | 65 --
> 5 files changed, 1488 deletions(-)
> delete mode 100644 Documentation/misc-devices/apds990x.rst
> delete mode 100644 drivers/misc/apds990x.c
> delete mode 100644 include/linux/platform_data/apds990x.h
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [PATCH] Documentation: adopt new coding style of type-aware kmalloc-family
From: Jonathan Corbet @ 2026-04-19 10:29 UTC (permalink / raw)
To: Manuel Ebner, Shuah Khan, linux-doc
Cc: lrcu, linux-kernel, workflows, linux-sound, rcu, linux-media,
Manuel Ebner, Kees Cook
In-Reply-To: <20260419065824.165921-4-manuelebner@mailbox.org>
Manuel Ebner <manuelebner@mailbox.org> writes:
> Update the documentation to reflect new type-aware kmalloc-family as
> suggested in commit 2932ba8d9c99 ("slab: Introduce kmalloc_obj() and family")
>
> ptr = kmalloc(sizeof(*ptr), gfp);
> -> ptr = kmalloc_obj(*ptr, gfp);
> ptr = kmalloc(sizeof(struct some_obj_name), gfp);
> -> ptr = kmalloc_obj(*ptr, gfp);
> ptr = kzalloc(sizeof(*ptr), gfp);
> -> ptr = kzalloc_obj(*ptr, gfp);
> ptr = kmalloc_array(count, sizeof(*ptr), gfp);
> -> ptr = kmalloc_objs(*ptr, count, gfp);
> ptr = kcalloc(count, sizeof(*ptr), gfp);
> -> ptr = kzalloc_objs(*ptr, count, gfp);
>
> Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
Just to be sure, did you write this patch yourself, or did you use some
sort of coding assistant?
Adding Kees, who did this work and might have something to add here.
> ---
> .../RCU/Design/Requirements/Requirements.rst | 6 +++---
> Documentation/RCU/listRCU.rst | 2 +-
> Documentation/RCU/whatisRCU.rst | 4 ++--
This patch will surely need to be split up; the RCU folks, for example,
will want to evaluate the change separately.
> Documentation/core-api/kref.rst | 4 ++--
> Documentation/core-api/list.rst | 4 ++--
> Documentation/core-api/memory-allocation.rst | 4 ++--
> Documentation/driver-api/mailbox.rst | 4 ++--
> Documentation/driver-api/media/v4l2-fh.rst | 2 +-
> Documentation/kernel-hacking/locking.rst | 4 ++--
> Documentation/locking/locktypes.rst | 4 ++--
> Documentation/process/coding-style.rst | 8 ++++----
> .../sound/kernel-api/writing-an-alsa-driver.rst | 12 ++++++------
> Documentation/spi/spi-summary.rst | 4 ++--
> .../translations/it_IT/kernel-hacking/locking.rst | 4 ++--
> .../translations/it_IT/locking/locktypes.rst | 4 ++--
> .../translations/it_IT/process/coding-style.rst | 2 +-
> .../translations/sp_SP/process/coding-style.rst | 2 +-
> Documentation/translations/zh_CN/core-api/kref.rst | 4 ++--
> .../translations/zh_CN/process/coding-style.rst | 2 +-
> .../zh_CN/video4linux/v4l2-framework.txt | 2 +-
> .../translations/zh_TW/process/coding-style.rst | 2 +-
> 21 files changed, 42 insertions(+), 42 deletions(-)
>
> diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst
> index b5cdbba3ec2e..faca5a9c8c12 100644
> --- a/Documentation/RCU/Design/Requirements/Requirements.rst
> +++ b/Documentation/RCU/Design/Requirements/Requirements.rst
> @@ -206,7 +206,7 @@ non-\ ``NULL``, locklessly accessing the ``->a`` and ``->b`` fields.
>
> 1 bool add_gp_buggy(int a, int b)
> 2 {
> - 3 p = kmalloc(sizeof(*p), GFP_KERNEL);
> + 3 p = kmalloc_obj(*p, GFP_KERNEL);
So you have not gone with the "implicit GFP_KERNEL" approach that Linus
added. Given that, I assume, he wanted that to be the normal style, we
should probably go with it.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v2 2/3] iio: tsl2772: add support for Avago APDS9900/9901 ALS/Proximity sensor
From: Jonathan Cameron @ 2026-04-19 11:29 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Arnd Bergmann, Greg Kroah-Hartman, Randy Dunlap, linux-iio,
devicetree, linux-kernel, linux-doc
In-Reply-To: <20260419083125.35572-3-clamor95@gmail.com>
On Sun, 19 Apr 2026 11:31:23 +0300
Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> The Avago APDS990x has the same register set as the TAOS/AMS TSL2772 so
> just add the correct bindings and the appropriate LUX table derived from
> the values in the datasheet. Driver was tested on the LG Optimus Vu P895.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Hi Svyatoslav,
Just one small thing.
Experience has given me a strong aversion to the use of wildcards
in naming within drivers. They go wrong too often because companies
can seem to resist using similar names for very different parts.
> ---
> drivers/iio/light/tsl2772.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/iio/light/tsl2772.c b/drivers/iio/light/tsl2772.c
> index c8f15ba95267..8dab34bf00ca 100644
> --- a/drivers/iio/light/tsl2772.c
> +++ b/drivers/iio/light/tsl2772.c
> @@ -127,6 +127,7 @@ enum {
> tmd2672,
> tsl2772,
> tmd2772,
> + apds990x,
As above, just name this after one of the supported parts. apds9900
That doesn't stop you using it for multiple compatible devices.
Same applies for all the uses of x as a wildcard.
thanks,
Jonathan
> apds9930,
> };
^ permalink raw reply
* Re: [PATCH] Documentation: adopt new coding style of type-aware kmalloc-family
From: Manuel Ebner @ 2026-04-19 11:33 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, linux-doc
Cc: lrcu, linux-kernel, workflows, linux-sound, rcu, linux-media,
Kees Cook
In-Reply-To: <87se8rw8df.fsf@trenco.lwn.net>
On Sun, 2026-04-19 at 04:29 -0600, Jonathan Corbet wrote:
> Manuel Ebner <manuelebner@mailbox.org> writes:
>
> > Update the documentation to reflect new type-aware kmalloc-family as
> > suggested in commit 2932ba8d9c99 ("slab: Introduce kmalloc_obj() and
> > family")
> >
> > ptr = kmalloc(sizeof(*ptr), gfp);
> > -> ptr = kmalloc_obj(*ptr, gfp);
> > ptr = kmalloc(sizeof(struct some_obj_name), gfp);
> > -> ptr = kmalloc_obj(*ptr, gfp);
> > ptr = kzalloc(sizeof(*ptr), gfp);
> > -> ptr = kzalloc_obj(*ptr, gfp);
> > ptr = kmalloc_array(count, sizeof(*ptr), gfp);
> > -> ptr = kmalloc_objs(*ptr, count, gfp);
> > ptr = kcalloc(count, sizeof(*ptr), gfp);
> > -> ptr = kzalloc_objs(*ptr, count, gfp);
> >
> > Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
>
> Just to be sure, did you write this patch yourself, or did you use some
> sort of coding assistant?
I wrote the patch myself.
> Adding Kees, who did this work and might have something to add here.
Thanks.
> > ---
> > .../RCU/Design/Requirements/Requirements.rst | 6 +++---
> > Documentation/RCU/listRCU.rst | 2 +-
> > Documentation/RCU/whatisRCU.rst | 4 ++--
>
> This patch will surely need to be split up; the RCU folks, for example,
> will want to evaluate the change separately.
will do that in [v2]
>
> > Documentation/core-api/kref.rst | 4 ++--
> > Documentation/core-api/list.rst | 4 ++--
> > Documentation/core-api/memory-allocation.rst | 4 ++--
> > Documentation/driver-api/mailbox.rst | 4 ++--
> > Documentation/driver-api/media/v4l2-fh.rst | 2 +-
> > Documentation/kernel-hacking/locking.rst | 4 ++--
> > Documentation/locking/locktypes.rst | 4 ++--
> > Documentation/process/coding-style.rst | 8 ++++----
> > .../sound/kernel-api/writing-an-alsa-driver.rst | 12 ++++++------
> > Documentation/spi/spi-summary.rst | 4 ++--
> > .../translations/it_IT/kernel-hacking/locking.rst | 4 ++--
> > .../translations/it_IT/locking/locktypes.rst | 4 ++--
> > .../translations/it_IT/process/coding-style.rst | 2 +-
> > .../translations/sp_SP/process/coding-style.rst | 2 +-
> > Documentation/translations/zh_CN/core-api/kref.rst | 4 ++--
> > .../translations/zh_CN/process/coding-style.rst | 2 +-
> > .../zh_CN/video4linux/v4l2-framework.txt | 2 +-
> > .../translations/zh_TW/process/coding-style.rst | 2 +-
> > 21 files changed, 42 insertions(+), 42 deletions(-)
> >
> > diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst
> > b/Documentation/RCU/Design/Requirements/Requirements.rst
> > index b5cdbba3ec2e..faca5a9c8c12 100644
> > --- a/Documentation/RCU/Design/Requirements/Requirements.rst
> > +++ b/Documentation/RCU/Design/Requirements/Requirements.rst
> > @@ -206,7 +206,7 @@ non-\ ``NULL``, locklessly accessing the ``->a`` and ``-
> > >b`` fields.
> >
> > 1 bool add_gp_buggy(int a, int b)
> > 2 {
> > - 3 p = kmalloc(sizeof(*p), GFP_KERNEL);
> > + 3 p = kmalloc_obj(*p, GFP_KERNEL);
>
> So you have not gone with the "implicit GFP_KERNEL" approach that Linus
> added. Given that, I assume, he wanted that to be the normal style, we
> should probably go with it.
I scanned those 8 replies by Linus, but i can't figure out what you mean with
implicit GFP_Kernel approach, can you give me a hint?
https://lore.kernel.org/all/?q=slab%3A+Introduce+kmalloc_obj%28%29+and+family+f%3Atorvalds
> Thanks,
>
> jon
Thanks,
manuel
^ permalink raw reply
* Re: [PATCH] Documentation: adopt new coding style of type-aware kmalloc-family
From: Jonathan Corbet @ 2026-04-19 11:43 UTC (permalink / raw)
To: Manuel Ebner, Shuah Khan, linux-doc
Cc: lrcu, linux-kernel, workflows, linux-sound, rcu, linux-media,
Kees Cook
In-Reply-To: <295490d9bd8b9d519dda5c4551e7dbaf36492a8a.camel@mailbox.org>
Manuel Ebner <manuelebner@mailbox.org> writes:
>> So you have not gone with the "implicit GFP_KERNEL" approach that Linus
>> added. Given that, I assume, he wanted that to be the normal style, we
>> should probably go with it.
>
> I scanned those 8 replies by Linus, but i can't figure out what you mean with
> implicit GFP_Kernel approach, can you give me a hint?
>
> https://lore.kernel.org/all/?q=slab%3A+Introduce+kmalloc_obj%28%29+and+family+f%3Atorvalds
See https://lwn.net/Articles/1062856/
jon
^ permalink raw reply
* Re: [PATCH v2 2/3] iio: tsl2772: add support for Avago APDS9900/9901 ALS/Proximity sensor
From: Svyatoslav Ryhel @ 2026-04-19 11:50 UTC (permalink / raw)
To: Jonathan Cameron
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Arnd Bergmann, Greg Kroah-Hartman, Randy Dunlap, linux-iio,
devicetree, linux-kernel, linux-doc
In-Reply-To: <20260419122950.67355f4c@jic23-huawei>
нд, 19 квіт. 2026 р. о 14:30 Jonathan Cameron <jic23@kernel.org> пише:
>
> On Sun, 19 Apr 2026 11:31:23 +0300
> Svyatoslav Ryhel <clamor95@gmail.com> wrote:
>
> > The Avago APDS990x has the same register set as the TAOS/AMS TSL2772 so
> > just add the correct bindings and the appropriate LUX table derived from
> > the values in the datasheet. Driver was tested on the LG Optimus Vu P895.
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Hi Svyatoslav,
>
> Just one small thing.
>
> Experience has given me a strong aversion to the use of wildcards
> in naming within drivers. They go wrong too often because companies
> can seem to resist using similar names for very different parts.
>
Noted.
> > ---
> > drivers/iio/light/tsl2772.c | 16 ++++++++++++++++
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/drivers/iio/light/tsl2772.c b/drivers/iio/light/tsl2772.c
> > index c8f15ba95267..8dab34bf00ca 100644
> > --- a/drivers/iio/light/tsl2772.c
> > +++ b/drivers/iio/light/tsl2772.c
> > @@ -127,6 +127,7 @@ enum {
> > tmd2672,
> > tsl2772,
> > tmd2772,
> > + apds990x,
>
> As above, just name this after one of the supported parts. apds9900
> That doesn't stop you using it for multiple compatible devices.
>
> Same applies for all the uses of x as a wildcard.
>
If this is the only thing keeping you from picking this patchset may I
resend with apds990x fixed right away?
> thanks,
>
> Jonathan
>
> > apds9930,
> > };
>
^ permalink raw reply
* htmldocs: Documentation/iio/ad9910.rst:451: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
From: kernel test robot @ 2026-04-19 12:24 UTC (permalink / raw)
To: Rodrigo Alencar; +Cc: oe-kbuild-all, 0day robot, linux-doc
tree: https://github.com/intel-lab-lkp/linux/commits/Rodrigo-Alencar-via-B4-Relay/dt-bindings-iio-frequency-add-ad9910/20260419-104913
head: 5ac9bfbe149f0815ff3156530d694c8c4a39dc75
commit: 5ac9bfbe149f0815ff3156530d694c8c4a39dc75 docs: iio: add documentation for ad9910 driver
date: 9 hours ago
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
docutils: docutils (Docutils 0.21.2, Python 3.13.5, on linux)
reproduce: (https://download.01.org/0day-ci/archive/20260419/202604191436.eNqraDV2-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202604191436.eNqraDV2-lkp@intel.com/
All warnings (new ones prefixed by >>):
Runtime Survivability
===================== [docutils]
Documentation/iio/ad9910.rst:444: ERROR: Unexpected indentation. [docutils]
Documentation/iio/ad9910.rst:447: ERROR: Unexpected indentation. [docutils]
>> Documentation/iio/ad9910.rst:451: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
Documentation/iio/ad9910.rst:452: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
Documentation/iio/ad9910.rst:459: ERROR: Unexpected indentation. [docutils]
Documentation/mm/memfd_preservation:7: ./mm/memfd_luo.c:13: ERROR: Unexpected section title.
vim +451 Documentation/iio/ad9910.rst
440
441 - 72-byte header:
442 - 4-byte big-endian word count: number of 32-bit words to be loaded (0-1024)
443 - 4-byte big-endian CFR1 value: configuration for the CFR1 register. Only
444 bits relevant to RAM mode (data destination and internal profile control)
445 are considered. Other bits are ignored and have no effect.
446 - Bits [30:29]: RAM data destination:
447 - 00: frequency
448 - 01: phase
449 - 10: amplitude
450 - 11: polar
> 451 - Bits [20:17]: Internal profile control (see Table 14 of the datasheet).
452 - 8 sets of 8-byte big-endian profile data for profiles 0-7. Each set contains:
453 - Bits [55:40]: Address step rate value
454 - Bits [39:30]: End address for the profile
455 - Bits [23:14]: Start address for the profile
456 - Bit [5]: no-dwell high for ramp-up mode
457 - Bit [3]: zero-crossing for direct-switch mode
458 - Bits [2:0]: operating mode:
459 - 000: direct switch
460 - 001: ramp-up
461 - 010: bidirectional
462 - 011: bidirectional continuous
463 - 100: ramp-up continuous
464 - Followed by the specified number of 32-bit big-endian data words.
465
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] docs: Add overview and SLUB allocator sections to slab documentation
From: Lorenzo Stoakes @ 2026-04-19 13:17 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Matthew Wilcox, Nick Huang, Vlastimil Babka, Harry Yoo,
Andrew Morton, Jonathan Corbet, Hao Li, Christoph Lameter,
David Rientjes, Roman Gushchin, Liam R . Howlett, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Shuah Khan, linux-mm, linux-doc,
linux-kernel
In-Reply-To: <c113f667-f897-42cc-a0e5-b8a0bbd91be3@kernel.org>
On Sun, Apr 19, 2026 at 10:35:44AM +0200, David Hildenbrand (Arm) wrote:
> On 4/18/26 18:15, Matthew Wilcox wrote:
> > On Sat, Apr 18, 2026 at 10:07:22AM +0100, Lorenzo Stoakes wrote:
> >> On Sat, Apr 18, 2026 at 12:06:19AM +0000, Nick Huang wrote:
> >>> - Add "Overview" section explaining the slab allocator's role and purpose
> >>> - Document the three main slab allocator implementations (SLAB, SLUB, SLOB)
> >>
> >> The fact you're insanely wrong about the current state of slab only makes this
> >> worse.
> >
> > This is actually a new low. We've always had to contend with people
> > putting up outdated or just wrong information on web pages, and there's
> > little we can do about it. Witness all the outdated information about
> > THP that's based on code that's been deleted for over a decade.
> >
> > But now we've got AI trained on all this wrong/ out of date information,
> > and, er, "enthusiasts" who are trying to change the correct information
> > in the kernel to match what the deluded AI "thinks" should be true.
> >
> > Let that sink in.
Ugh ye gawds. My attitude is nip this in the bud early.
I'm very harsh in response to these things for a reason - firstly, it's rude,
obnoxious + disrespectful, so a negative response is wholly appropriate.
But more importantly, I want to SET A PRECEDENT that if you send this crap
you'll get a VERY negative response.
Clueless but good faith or bad faith - it's straight up plagiarism and that's
totally unacceptable.
> >
>
> I think we should make it very clear that we don't want doc updates from someone
> that is not a renowned expert in that area or wants to become an expert in that
> area (and already discussed working on the docs with maintainers/experts).
>
> Otherwise we'll have this same discussion over and over again.
>
> diff --git a/Documentation/mm/index.rst b/Documentation/mm/index.rst
> index 7aa2a88869083..8c5721001c8bb 100644
> --- a/Documentation/mm/index.rst
> +++ b/Documentation/mm/index.rst
> @@ -7,6 +7,11 @@ of Linux. If you are looking for advice on simply allocating
> memory,
> see the :ref:`memory_allocation`. For controlling and tuning guides,
> see the :doc:`admin guide <../admin-guide/mm/index>`.
>
> +A lot of documentation in this guide is still incomplete. If you are not
> +a renowned expert in the specific area, but you want to contribute bigger
> +chunks of documentation, talk to the respective MM experts first. LLM
> +generated slop from non-experts will be rejected without further comments.
> +
> .. toctree::
> :maxdepth: 1
>
>
>
> LLMs are just the tip of the iceberg. It will all be developmend-by review with
> inexperienced contributors. And we are only willing to put in the effort to
> teach contributors if the contributors are not actually worth our time: i.e.,
> LLM kiddies that will actually stick around and help the subsystem in the long run.
>
>
> The whole doc update stuff is similar to people just grepping for TODOs in the
> kernel and then using an LLM to produce code they have no idea about.
>
> It's the evolution of typo fixes: review load without any benefit.
Agree with all of that!
Let's do that, happy to give tags on a patch for the above :)
>
> --
> Cheers,
>
> David
>
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH] docs/zh_CN: polish how-to.rst
From: Alex Shi @ 2026-04-19 13:28 UTC (permalink / raw)
To: Dongliang Mu, Alex Shi, Yanteng Si, Jonathan Corbet, Shuah Khan
Cc: linux-doc, linux-kernel
In-Reply-To: <20260418091014.2064780-1-dzm91@hust.edu.cn>
Applied thanks!
On 2026/4/18 17:10, Dongliang Mu wrote:
> Editorial pass on the Chinese translation contributor guide.
>
> - Fix typos: 网络通常 → 通畅; remove trailing backticks on the
> checktransupdate.py command; mis-placed 。 → ， in the 紧急处理
> section; 您/你 and 的/地 inconsistencies in 进阶.
> - Correct "git email" to "git send-email", matching usage
> elsewhere in the document.
> - Replace an invalid <URL> inline form with a bare URL so Sphinx
> renders the lore.kernel.org link.
> - Tighten grammar and wording: 针对于 → 面向; drop redundant
> 最多 before 不超过 and tautological 即可; remove double 的 in
> 您的翻译的内容; resolve ambiguity around 继续 placement in the
> 把补丁提交到邮件列表 section; and similar small fixes.
>
> Assisted-by:Claude:claude-opus-4-6
> Signed-off-by: Dongliang Mu<dzm91@hust.edu.cn>
> ---
> Documentation/translations/zh_CN/how-to.rst | 46 ++++++++++-----------
> 1 file changed, 23 insertions(+), 23 deletions(-)
>
> diff --git a/Documentation/translations/zh_CN/how-to.rst b/Documentation/translations/zh_CN/how-to.rst
> index 7ae5d8765888..a46d7395b11c 100644
> --- a/Documentation/translations/zh_CN/how-to.rst
> +++ b/Documentation/translations/zh_CN/how-to.rst
> @@ -13,20 +13,20 @@ Linux 内核中文文档翻译规范
> 过去几年，在广大社区爱好者的友好合作下，Linux 内核中文文档迎来了蓬勃的发
> 展。在翻译的早期，一切都是混乱的，社区对译稿只有一个准确翻译的要求，以鼓
> 励更多的开发者参与进来，这是从 0 到 1 的必然过程，所以早期的中文文档目录
> -更加具有多样性，不过好在文档不多，维护上并没有过大的压力。
> +呈现出较强的多样性，不过好在文档不多，维护上并没有过大的压力。
>
> 然而，世事变幻，不觉有年，现在内核中文文档在前进的道路上越走越远，很多潜
> 在的问题逐渐浮出水面，而且随着中文文档数量的增加，翻译更多的文档与提高中
> 文文档可维护性之间的矛盾愈发尖锐。由于文档翻译的特殊性，很多开发者并不会
> 一直更新文档，如果中文文档落后英文文档太多，文档更新的工作量会远大于重新
> 翻译。而且邮件列表中陆续有新的面孔出现，他们那股热情，就像燃烧的火焰，能
> -瞬间点燃整个空间，可是他们的补丁往往具有个性，这会给审阅带来了很大的困难，
> +瞬间点燃整个空间，可是他们的补丁往往具有个性，这给审阅带来了很大的困难，
> reviewer 们只能耐心地指导他们如何与社区更好地合作，但是这项工作具有重复
> 性，长此以往，会渐渐浇灭 reviewer 审阅的热情。
>
> -虽然内核文档中已经有了类似的贡献指南，但是缺乏专门针对于中文翻译的，尤其
> +虽然内核文档中已经有了类似的贡献指南，但是缺乏专门面向中文翻译的，尤其
> 是对于新手来说，浏览大量的文档反而更加迷惑，该文档就是为了缓解这一问题而
> -编写，目的是为提供给新手一个快速翻译指南。
> +编写，旨在为新手提供一份快速翻译指南。
>
> 详细的贡献指南：Documentation/translations/zh_CN/process/index.rst。
>
> @@ -145,8 +145,8 @@ Git 和邮箱配置
> sudo dnf install git-email
> vim ~/.gitconfig
>
> -这里是我的一个配置文件示范，请根据您的邮箱域名服务商提供的手册替换到对
> -应的字段。
> +这里是我的一个配置文件示范，请根据您的邮箱域名服务商提供的手册替换对应
> +的字段。
> ::
>
> [user]
> @@ -190,7 +190,7 @@ Git 和邮箱配置
> 译文格式要求
> ------------
>
> - - 每行长度最多不超过 40 个字符
> + - 每行长度不超过 40 个字符
> - 每行长度请保持一致
> - 标题的下划线长度请按照一个英文一个字符、一个中文两个字符与标题对齐
> - 其它的修饰符请与英文文档保持一致
> @@ -211,7 +211,7 @@ Git 和邮箱配置
> --------
>
> 中文文档有每行 40 字符限制，因为一个中文字符等于 2 个英文字符。但是社区并
> -没有那么严格，一个诀窍是将您的翻译的内容与英文原文的每行长度对齐即可，这样，
> +没有那么严格，一个诀窍是将您翻译的内容与英文原文的每行长度对齐，这样，
> 您也不必总是检查有没有超限。
>
> 如果您的英文阅读能力有限，可以考虑使用辅助翻译工具，例如 deepseek。但是您
> @@ -309,8 +309,8 @@ warning 不需要解决::
>
> 重新导出再次检测，重复这个过程，直到处理完所有的补丁。
>
> -最后，如果检测时没有 warning 和 error 需要被处理或者您只有一个补丁，请跳
> -过下面这个步骤，否则请重新导出补丁制作封面::
> +最后，如果检测时没有需要处理的 warning 和 error，或者您只有一个补丁，请
> +跳过下面这个步骤，否则请重新导出补丁制作封面::
>
> git format-patch -N --cover-letter --thread=shallow
> # N 要替换为补丁数量，一般 N 大于 1
> @@ -335,7 +335,7 @@ warning 不需要解决::
> docs/zh_CN: add xxxxx
> ...
>
> -如果您只有一个补丁，则可以不制作封面，即 0 号补丁，只需要执行::
> +如果您只有一个补丁，则无需制作封面（即 0 号补丁），只需执行::
>
> git format-patch -1
>
> @@ -361,13 +361,13 @@ warning 不需要解决::
> git send-email *.patch --to <maintainer email addr> --cc <others addr>
> # 一个 to 对应一个地址，一个 cc 对应一个地址，有几个就写几个
>
> -执行该命令时，请确保网络通常，邮件发送成功一般会返回 250。
> +执行该命令时，请确保网络通畅，邮件发送成功一般会返回 250。
>
> 您可以先发送给自己，尝试发出的 patch 是否可以用 'git am' 工具正常打上。
> 如果检查正常， 您就可以放心的发送到社区评审了。
>
> -如果该步骤被中断，您可以检查一下，继续用上条命令发送失败的补丁，一定不要再
> -次发送已经发送成功的补丁。
> +如果该步骤被中断，您可以检查一下，然后用上条命令继续发送失败的补丁，一定不
> +要再次发送已经发送成功的补丁。
>
> 积极参与审阅过程并迭代补丁
> ==========================
> @@ -380,7 +380,7 @@ reviewer 的评论，做到每条都有回复，每个回复都落实到位。
>
> - 请先将您的邮箱客户端信件回复修改为 **纯文本** 格式，并去除所有签名，尤其是
> 企业邮箱。
> - - 然后点击回复按钮，并将要回复的邮件带入，
> + - 然后点击回复按钮，并引用要回复的邮件，
> - 在第一条评论行尾换行，输入您的回复
> - 在第二条评论行尾换行，输入您的回复
> - 直到处理完最后一条评论，换行空两行输入问候语和署名
> @@ -425,10 +425,10 @@ reviewer 的评论，做到每条都有回复，每个回复都落实到位。
> 紧急处理
> --------
>
> -如果您发送到邮件列表之后。发现发错了补丁集，尤其是在多个版本迭代的过程中；
> +如果您发送到邮件列表之后，发现发错了补丁集，尤其是在多个版本迭代的过程中；
> 自己发现了一些不妥的翻译；发送错了邮件列表……
>
> -git email 默认会抄送给您一份，所以您可以切换为审阅者的角色审查自己的补丁，
> +git send-email 默认会抄送给您一份，所以您可以切换为审阅者的角色审查自己的补丁，
> 并留下评论，描述有何不妥，将在下个版本怎么改，并付诸行动，重新提交，但是
> 注意频率，每天提交的次数不要超过两次。
>
> @@ -437,7 +437,7 @@ git email 默认会抄送给您一份，所以您可以切换为审阅者的角
> 对于首次参与 Linux 内核中文文档翻译的新手，建议您在 linux 目录中运行以下命令：
> ::
>
> - tools/docs/checktransupdate.py -l zh_CN``
> + tools/docs/checktransupdate.py -l zh_CN
>
> 该命令会列出需要翻译或更新的英文文档，结果同时保存在 checktransupdate.log 中。
>
> @@ -446,9 +446,9 @@ git email 默认会抄送给您一份，所以您可以切换为审阅者的角
> 进阶
> ----
>
> -希望您不只是单纯的翻译内核文档，在熟悉了一起与社区工作之后，您可以审阅其他
> +希望您不只是单纯地翻译内核文档，在熟悉了与社区协作之后，您可以审阅其他
> 开发者的翻译，或者提出具有建设性的主张。与此同时，与文档对应的代码更加有趣，
> -而且需要完善的地方还有很多，勇敢地去探索，然后提交你的想法吧。
> +而且需要完善的地方还有很多，勇敢地去探索，然后提交您的想法吧。
>
> 常见的问题
> ==========
> @@ -467,7 +467,7 @@ Maintainer 回复补丁不能正常 apply
> ------------------
>
> 大部分情况下，是由于您发送了非纯文本格式的信件，请尽量避免使用 webmail，推荐
> -使用邮件客户端，比如 thunderbird，记得在设置中的回信配置那改为纯文本发送。
> +使用邮件客户端，比如 thunderbird，记得在设置的回信配置中改为纯文本发送。
>
> -如果超过了 24 小时，您依旧没有在<https://lore.kernel.org/linux-doc/>发现您的
> -邮件，请联系您的网络管理员帮忙解决。
> +如果超过了 24 小时，您依旧没有在https://lore.kernel.org/linux-doc/ 上找到您
> +的邮件，请联系您的网络管理员帮忙解决。
> -- 2.43.0
>
^ permalink raw reply
* Re: [PATCH] docs/zh_CN: add --no-merges to git log example in how-to.rst
From: Alex Shi @ 2026-04-19 13:32 UTC (permalink / raw)
To: Ben Guo, Alex Shi, Yanteng Si, Dongliang Mu, Jonathan Corbet
Cc: linux-doc, linux-kernel, hust-os-kernel-patches
In-Reply-To: <20260416042647.3646595-1-ben.guo@openatom.club>
Applied thanks!
On 2026/4/16 12:26, Ben Guo wrote:
> Add --no-merges flag to prevent referencing merge commits in the
> through-commit field of translation commit messages.
>
> Signed-off-by: Ben Guo<ben.guo@openatom.club>
> ---
> Documentation/translations/zh_CN/how-to.rst | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/translations/zh_CN/how-to.rst b/Documentation/translations/zh_CN/how-to.rst
> index 7ae5d876588..39ed7054fa3 100644
> --- a/Documentation/translations/zh_CN/how-to.rst
> +++ b/Documentation/translations/zh_CN/how-to.rst
> @@ -257,7 +257,9 @@ Git 和邮箱配置
>
> Update the translation through commit b080e52110ea
> ("docs: update self-protection __ro_after_init status")
> - # 请执行 git log --oneline <您翻译的英文文档路径>，并替换上述内容
> + # 请执行 git log --no-merges --oneline <您翻译的英文文档路径>
> + # 并替换上述内容。注意：应引用实际修改文件内容的 commit，
> + # 而非 merge commit
>
> Signed-off-by: Yanteng Si<si.yanteng@linux.dev>
> # 如果您前面的步骤正确执行，该行会自动显示，否则请检查 gitconfig 文件
> -- 2.53.0
^ permalink raw reply
* Re: [PATCH v2 3/3] misc: Remove old APDS990x driver
From: Jonathan Cameron @ 2026-04-19 13:33 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Arnd Bergmann, Greg Kroah-Hartman, Randy Dunlap, linux-iio,
devicetree, linux-kernel, linux-doc
In-Reply-To: <20260419083125.35572-4-clamor95@gmail.com>
On Sun, 19 Apr 2026 11:31:24 +0300
Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> The Avago APDS9900/9901 ALS/Proximity sensor is now supported by tsl2772
> IIO driver so there is no need to keep this old implementation. Remove it.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> Documentation/misc-devices/apds990x.rst | 128 ---
Sashiko AI reviewing is now running on anything that hits linux-iio@vger.kernel.org
I'm slowly getting into the habit of checking out what it finds though
I'm 500+ emails behind so it might not be that thorough today :*
Anyhow, it caught an easy one here.
This file is referenced from Documentation/misc-devices/index.rst
so that needs an update as well.
There is the obvious point of ABI compatibility raised as well, but given
we don't seem to be getting much push back on that maybe that's not a significant
concern.
Jonathan
> drivers/misc/Kconfig | 10 -
> drivers/misc/Makefile | 1 -
> drivers/misc/apds990x.c | 1284 -----------------------
> include/linux/platform_data/apds990x.h | 65 --
> 5 files changed, 1488 deletions(-)
> delete mode 100644 Documentation/misc-devices/apds990x.rst
> delete mode 100644 drivers/misc/apds990x.c
> delete mode 100644 include/linux/platform_data/apds990x.h
^ permalink raw reply
* Re: [PATCH v2 2/3] iio: tsl2772: add support for Avago APDS9900/9901 ALS/Proximity sensor
From: Jonathan Cameron @ 2026-04-19 13:37 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Arnd Bergmann, Greg Kroah-Hartman, Randy Dunlap, linux-iio,
devicetree, linux-kernel, linux-doc
In-Reply-To: <20260419083125.35572-3-clamor95@gmail.com>
On Sun, 19 Apr 2026 11:31:23 +0300
Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> The Avago APDS990x has the same register set as the TAOS/AMS TSL2772 so
A Sashiko review comment makes me wonder about one thing below if the
register set does match. Maybe it's a bit more subtle than this
patch description suggests?
> just add the correct bindings and the appropriate LUX table derived from
> the values in the datasheet. Driver was tested on the LG Optimus Vu P895.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> drivers/iio/light/tsl2772.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/iio/light/tsl2772.c b/drivers/iio/light/tsl2772.c
> index c8f15ba95267..8dab34bf00ca 100644
> --- a/drivers/iio/light/tsl2772.c
> +++ b/drivers/iio/light/tsl2772.c
> @@ -127,6 +127,7 @@ enum {
> tmd2672,
> tsl2772,
> tmd2772,
> + apds990x,
> apds9930,
> };
>
> @@ -221,6 +222,12 @@ static const struct tsl2772_lux tmd2x72_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> { 0, 0 },
> };
>
> +static const struct tsl2772_lux apds990x_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> + { 52000, 115960 },
> + { 36400, 73840 },
> + { 0, 0 },
> +};
> +
> static const struct tsl2772_lux apds9930_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> { 52000, 96824 },
> { 38792, 67132 },
> @@ -238,6 +245,7 @@ static const struct tsl2772_lux *tsl2772_default_lux_table_group[] = {
> [tmd2672] = tmd2x72_lux_table,
> [tsl2772] = tsl2x72_lux_table,
> [tmd2772] = tmd2x72_lux_table,
> + [apds990x] = apds990x_lux_table,
> [apds9930] = apds9930_lux_table,
> };
>
> @@ -289,6 +297,7 @@ static const int tsl2772_int_time_avail[][6] = {
> [tmd2672] = { 0, 2730, 0, 2730, 0, 699000 },
> [tsl2772] = { 0, 2730, 0, 2730, 0, 699000 },
> [tmd2772] = { 0, 2730, 0, 2730, 0, 699000 },
> + [apds990x] = { 0, 2720, 0, 2720, 0, 696000 },
> [apds9930] = { 0, 2730, 0, 2730, 0, 699000 },
> };
>
> @@ -316,6 +325,7 @@ static const u8 device_channel_config[] = {
> [tmd2672] = PRX2,
> [tsl2772] = ALSPRX2,
> [tmd2772] = ALSPRX2,
> + [apds990x] = ALSPRX,
This is different from tsl2772?
> [apds9930] = ALSPRX2,
> };
^ permalink raw reply
* Re: [PATCH v2 3/3] misc: Remove old APDS990x driver
From: Svyatoslav Ryhel @ 2026-04-19 13:41 UTC (permalink / raw)
To: Jonathan Cameron
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Arnd Bergmann, Greg Kroah-Hartman, Randy Dunlap, linux-iio,
devicetree, linux-kernel, linux-doc
In-Reply-To: <20260419143346.45ed78c2@jic23-huawei>
нд, 19 квіт. 2026 р. о 16:33 Jonathan Cameron <jic23@kernel.org> пише:
>
> On Sun, 19 Apr 2026 11:31:24 +0300
> Svyatoslav Ryhel <clamor95@gmail.com> wrote:
>
> > The Avago APDS9900/9901 ALS/Proximity sensor is now supported by tsl2772
> > IIO driver so there is no need to keep this old implementation. Remove it.
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > ---
> > Documentation/misc-devices/apds990x.rst | 128 ---
> Sashiko AI reviewing is now running on anything that hits linux-iio@vger.kernel.org
>
> I'm slowly getting into the habit of checking out what it finds though
> I'm 500+ emails behind so it might not be that thorough today :*
>
> Anyhow, it caught an easy one here.
>
> This file is referenced from Documentation/misc-devices/index.rst
> so that needs an update as well.
>
Good catch, index was not updated, I will do so in v3.
> There is the obvious point of ABI compatibility raised as well, but given
> we don't seem to be getting much push back on that maybe that's not a significant
> concern.
I did not found any ABI in the Documentation/ABI regarding this sensor
using grep, maybe you are more familiar?
>
> Jonathan
>
> > drivers/misc/Kconfig | 10 -
> > drivers/misc/Makefile | 1 -
> > drivers/misc/apds990x.c | 1284 -----------------------
> > include/linux/platform_data/apds990x.h | 65 --
> > 5 files changed, 1488 deletions(-)
> > delete mode 100644 Documentation/misc-devices/apds990x.rst
> > delete mode 100644 drivers/misc/apds990x.c
> > delete mode 100644 include/linux/platform_data/apds990x.h
^ permalink raw reply
* Re: [PATCH v2 2/3] iio: tsl2772: add support for Avago APDS9900/9901 ALS/Proximity sensor
From: Svyatoslav Ryhel @ 2026-04-19 13:46 UTC (permalink / raw)
To: Jonathan Cameron
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Arnd Bergmann, Greg Kroah-Hartman, Randy Dunlap, linux-iio,
devicetree, linux-kernel, linux-doc
In-Reply-To: <20260419143751.11ec0b69@jic23-huawei>
нд, 19 квіт. 2026 р. о 16:38 Jonathan Cameron <jic23@kernel.org> пише:
>
> On Sun, 19 Apr 2026 11:31:23 +0300
> Svyatoslav Ryhel <clamor95@gmail.com> wrote:
>
> > The Avago APDS990x has the same register set as the TAOS/AMS TSL2772 so
>
> A Sashiko review comment makes me wonder about one thing below if the
> register set does match. Maybe it's a bit more subtle than this
> patch description suggests?
>
> > just add the correct bindings and the appropriate LUX table derived from
> > the values in the datasheet. Driver was tested on the LG Optimus Vu P895.
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > ---
> > drivers/iio/light/tsl2772.c | 16 ++++++++++++++++
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/drivers/iio/light/tsl2772.c b/drivers/iio/light/tsl2772.c
> > index c8f15ba95267..8dab34bf00ca 100644
> > --- a/drivers/iio/light/tsl2772.c
> > +++ b/drivers/iio/light/tsl2772.c
> > @@ -127,6 +127,7 @@ enum {
> > tmd2672,
> > tsl2772,
> > tmd2772,
> > + apds990x,
> > apds9930,
> > };
> >
> > @@ -221,6 +222,12 @@ static const struct tsl2772_lux tmd2x72_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > { 0, 0 },
> > };
> >
> > +static const struct tsl2772_lux apds990x_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > + { 52000, 115960 },
> > + { 36400, 73840 },
> > + { 0, 0 },
> > +};
> > +
> > static const struct tsl2772_lux apds9930_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > { 52000, 96824 },
> > { 38792, 67132 },
> > @@ -238,6 +245,7 @@ static const struct tsl2772_lux *tsl2772_default_lux_table_group[] = {
> > [tmd2672] = tmd2x72_lux_table,
> > [tsl2772] = tsl2x72_lux_table,
> > [tmd2772] = tmd2x72_lux_table,
> > + [apds990x] = apds990x_lux_table,
> > [apds9930] = apds9930_lux_table,
> > };
> >
> > @@ -289,6 +297,7 @@ static const int tsl2772_int_time_avail[][6] = {
> > [tmd2672] = { 0, 2730, 0, 2730, 0, 699000 },
> > [tsl2772] = { 0, 2730, 0, 2730, 0, 699000 },
> > [tmd2772] = { 0, 2730, 0, 2730, 0, 699000 },
> > + [apds990x] = { 0, 2720, 0, 2720, 0, 696000 },
> > [apds9930] = { 0, 2730, 0, 2730, 0, 699000 },
> > };
> >
> > @@ -316,6 +325,7 @@ static const u8 device_channel_config[] = {
> > [tmd2672] = PRX2,
> > [tsl2772] = ALSPRX2,
> > [tmd2772] = ALSPRX2,
> > + [apds990x] = ALSPRX,
>
> This is different from tsl2772?
yes, lux table is different and made according to datasheet,
tsl2772_int_time_avail differs, ALSPRX configuration assumes that
proximity sensor needs no calibration which is true for apds9900/1
while tsl2772 needs calibration, device ID is different 0x20/0x29 for
apds and 0x30 for tsl2772
>
> > [apds9930] = ALSPRX2,
> > };
>
^ permalink raw reply
* Re: [PATCH v7 1/4] KVM: arm64: PMU: Add kvm_pmu_enabled_counter_mask()
From: Marc Zyngier @ 2026-04-19 14:13 UTC (permalink / raw)
To: Akihiko Odaki
Cc: Oliver Upton, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Kees Cook, Gustavo A. R. Silva,
Paolo Bonzini, Jonathan Corbet, Shuah Khan, linux-arm-kernel,
kvmarm, linux-kernel, linux-hardening, devel, kvm, linux-doc,
linux-kselftest
In-Reply-To: <20260418-hybrid-v7-1-2bf39ad009bf@rsg.ci.i.u-tokyo.ac.jp>
On Sat, 18 Apr 2026 09:14:23 +0100,
Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote:
>
> This function will be useful to enumerate enabled counters.
Consider expanding this commit message a bit. Something along the
lines of:
"Add kvm_pmu_enabled_counter_mask() as an accessor returning a 64bit
mask of the counters enabled on a given vcpu.
This will eventually be useful to iterate over the counters."
Thanks,
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* Re: [RFC, PATCH 00/12] userfaultfd: working set tracking for VM guest memory
From: Kiryl Shutsemau @ 2026-04-19 14:33 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Andrew Morton, Peter Xu, Lorenzo Stoakes, Mike Rapoport,
Suren Baghdasaryan, Vlastimil Babka, Liam R . Howlett, Zi Yan,
Jonathan Corbet, Shuah Khan, Sean Christopherson, Paolo Bonzini,
linux-mm, linux-kernel, linux-doc, linux-kselftest, kvm
In-Reply-To: <aeImfRrrvr3UoKtL@thinkstation>
On Fri, Apr 17, 2026 at 01:26:34PM +0100, Kiryl Shutsemau wrote:
> > Leaving NUMA-balancing aside, a simple
> > mprotect(PROT_NONE)+mprotect(PROT_READ) would already be problematic to
> > distinguish both cases.
>
> Hm. I didn't consider this case (miss some uffd lore). Will rework to
> reuse existing PTE bit.
See https://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git uffd/rfc-v3
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH v7 2/4] KVM: arm64: PMU: Protect the list of PMUs with RCU
From: Marc Zyngier @ 2026-04-19 14:34 UTC (permalink / raw)
To: Akihiko Odaki
Cc: Oliver Upton, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Kees Cook, Gustavo A. R. Silva,
Paolo Bonzini, Jonathan Corbet, Shuah Khan, linux-arm-kernel,
kvmarm, linux-kernel, linux-hardening, devel, kvm, linux-doc,
linux-kselftest
In-Reply-To: <20260418-hybrid-v7-2-2bf39ad009bf@rsg.ci.i.u-tokyo.ac.jp>
On Sat, 18 Apr 2026 09:14:24 +0100,
Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote:
>
> Convert the list of PMUs to a RCU-protected list that has primitives to
> avoid read-side contention.
>
> Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
> ---
> arch/arm64/kvm/pmu-emul.c | 14 ++++++--------
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm64/kvm/pmu-emul.c b/arch/arm64/kvm/pmu-emul.c
> index 59ec96e09321..ef5140bbfe28 100644
> --- a/arch/arm64/kvm/pmu-emul.c
> +++ b/arch/arm64/kvm/pmu-emul.c
> @@ -7,9 +7,9 @@
> #include <linux/cpu.h>
> #include <linux/kvm.h>
> #include <linux/kvm_host.h>
> -#include <linux/list.h>
> #include <linux/perf_event.h>
> #include <linux/perf/arm_pmu.h>
> +#include <linux/rculist.h>
> #include <linux/uaccess.h>
> #include <asm/kvm_emulate.h>
> #include <kvm/arm_pmu.h>
> @@ -26,7 +26,6 @@ static bool kvm_pmu_counter_is_enabled(struct kvm_pmc *pmc);
>
> bool kvm_supports_guest_pmuv3(void)
> {
> - guard(mutex)(&arm_pmus_lock);
> return !list_empty(&arm_pmus);
Please read include/linux/rculist.h and the discussion about the
interaction of list_empty() with RCU-protected lists. How about using
list_first_or_null_rcu() for peace of mind?
Thanks,
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* Re: [PATCH v2 3/3] misc: Remove old APDS990x driver
From: Jonathan Cameron @ 2026-04-19 16:22 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Arnd Bergmann, Greg Kroah-Hartman, Randy Dunlap, linux-iio,
devicetree, linux-kernel, linux-doc
In-Reply-To: <CAPVz0n1qrSYr16zSSqRHuTWVkRfdC+c9w+mxAhtzgfHzL41XFw@mail.gmail.com>
On Sun, 19 Apr 2026 16:41:24 +0300
Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> нд, 19 квіт. 2026 р. о 16:33 Jonathan Cameron <jic23@kernel.org> пише:
> >
> > On Sun, 19 Apr 2026 11:31:24 +0300
> > Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> >
> > > The Avago APDS9900/9901 ALS/Proximity sensor is now supported by tsl2772
> > > IIO driver so there is no need to keep this old implementation. Remove it.
> > >
> > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > ---
> > > Documentation/misc-devices/apds990x.rst | 128 ---
> > Sashiko AI reviewing is now running on anything that hits linux-iio@vger.kernel.org
> >
> > I'm slowly getting into the habit of checking out what it finds though
> > I'm 500+ emails behind so it might not be that thorough today :*
> >
> > Anyhow, it caught an easy one here.
> >
> > This file is referenced from Documentation/misc-devices/index.rst
> > so that needs an update as well.
> >
>
> Good catch, index was not updated, I will do so in v3.
>
> > There is the obvious point of ABI compatibility raised as well, but given
> > we don't seem to be getting much push back on that maybe that's not a significant
> > concern.
>
> I did not found any ABI in the Documentation/ABI regarding this sensor
> using grep, maybe you are more familiar?
Doesn't matter if it's documented explicitly (many older drivers are not).
The question is whether anyone has supported parts and userspace code that
makes use of the sysfs files this driver provides.
Their userspace will be broken by dropping it. The lack of upstream users
makes this less critical but it can be argued it's still a possible regression.
Jonathan
>
> >
> > Jonathan
> >
> > > drivers/misc/Kconfig | 10 -
> > > drivers/misc/Makefile | 1 -
> > > drivers/misc/apds990x.c | 1284 -----------------------
> > > include/linux/platform_data/apds990x.h | 65 --
> > > 5 files changed, 1488 deletions(-)
> > > delete mode 100644 Documentation/misc-devices/apds990x.rst
> > > delete mode 100644 drivers/misc/apds990x.c
> > > delete mode 100644 include/linux/platform_data/apds990x.h
^ permalink raw reply
* Re: [PATCH v2 2/3] iio: tsl2772: add support for Avago APDS9900/9901 ALS/Proximity sensor
From: Jonathan Cameron @ 2026-04-19 16:24 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Arnd Bergmann, Greg Kroah-Hartman, Randy Dunlap, linux-iio,
devicetree, linux-kernel, linux-doc
In-Reply-To: <CAPVz0n1iB9iC+TFrGK5ajXjdk8-g8vzr4ZbXdvW5=F8iukanaA@mail.gmail.com>
On Sun, 19 Apr 2026 14:50:55 +0300
Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> нд, 19 квіт. 2026 р. о 14:30 Jonathan Cameron <jic23@kernel.org> пише:
> >
> > On Sun, 19 Apr 2026 11:31:23 +0300
> > Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> >
> > > The Avago APDS990x has the same register set as the TAOS/AMS TSL2772 so
> > > just add the correct bindings and the appropriate LUX table derived from
> > > the values in the datasheet. Driver was tested on the LG Optimus Vu P895.
> > >
> > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > Hi Svyatoslav,
> >
> > Just one small thing.
> >
> > Experience has given me a strong aversion to the use of wildcards
> > in naming within drivers. They go wrong too often because companies
> > can seem to resist using similar names for very different parts.
> >
>
> Noted.
>
> > > ---
> > > drivers/iio/light/tsl2772.c | 16 ++++++++++++++++
> > > 1 file changed, 16 insertions(+)
> > >
> > > diff --git a/drivers/iio/light/tsl2772.c b/drivers/iio/light/tsl2772.c
> > > index c8f15ba95267..8dab34bf00ca 100644
> > > --- a/drivers/iio/light/tsl2772.c
> > > +++ b/drivers/iio/light/tsl2772.c
> > > @@ -127,6 +127,7 @@ enum {
> > > tmd2672,
> > > tsl2772,
> > > tmd2772,
> > > + apds990x,
> >
> > As above, just name this after one of the supported parts. apds9900
> > That doesn't stop you using it for multiple compatible devices.
> >
> > Same applies for all the uses of x as a wildcard.
> >
>
> If this is the only thing keeping you from picking this patchset may I
> resend with apds990x fixed right away?
No. I'm just one reviewer - others may need more time. You should wait
at least a few days before sending a new version unless I've specifically
requested a rushed version.
I only do that if I'm trying to get something in at the end of a kernel
cycle or there are dependencies on a patch from others. In this case, neither
applies so please take your time. I'd normally suggest approximately a week.
Thanks,
Jonathan
>
> > thanks,
> >
> > Jonathan
> >
> > > apds9930,
> > > };
> >
^ permalink raw reply
* Re: [PATCH v2 2/3] iio: tsl2772: add support for Avago APDS9900/9901 ALS/Proximity sensor
From: Jonathan Cameron @ 2026-04-19 16:24 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Arnd Bergmann, Greg Kroah-Hartman, Randy Dunlap, linux-iio,
devicetree, linux-kernel, linux-doc
In-Reply-To: <CAPVz0n048kPMAnGQpOk0_SPtQ+hz=-p6jdyRYPB5d+CD9i7_Cw@mail.gmail.com>
On Sun, 19 Apr 2026 16:46:25 +0300
Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> нд, 19 квіт. 2026 р. о 16:38 Jonathan Cameron <jic23@kernel.org> пише:
> >
> > On Sun, 19 Apr 2026 11:31:23 +0300
> > Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> >
> > > The Avago APDS990x has the same register set as the TAOS/AMS TSL2772 so
> >
> > A Sashiko review comment makes me wonder about one thing below if the
> > register set does match. Maybe it's a bit more subtle than this
> > patch description suggests?
> >
> > > just add the correct bindings and the appropriate LUX table derived from
> > > the values in the datasheet. Driver was tested on the LG Optimus Vu P895.
> > >
> > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > ---
> > > drivers/iio/light/tsl2772.c | 16 ++++++++++++++++
> > > 1 file changed, 16 insertions(+)
> > >
> > > diff --git a/drivers/iio/light/tsl2772.c b/drivers/iio/light/tsl2772.c
> > > index c8f15ba95267..8dab34bf00ca 100644
> > > --- a/drivers/iio/light/tsl2772.c
> > > +++ b/drivers/iio/light/tsl2772.c
> > > @@ -127,6 +127,7 @@ enum {
> > > tmd2672,
> > > tsl2772,
> > > tmd2772,
> > > + apds990x,
> > > apds9930,
> > > };
> > >
> > > @@ -221,6 +222,12 @@ static const struct tsl2772_lux tmd2x72_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > > { 0, 0 },
> > > };
> > >
> > > +static const struct tsl2772_lux apds990x_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > > + { 52000, 115960 },
> > > + { 36400, 73840 },
> > > + { 0, 0 },
> > > +};
> > > +
> > > static const struct tsl2772_lux apds9930_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > > { 52000, 96824 },
> > > { 38792, 67132 },
> > > @@ -238,6 +245,7 @@ static const struct tsl2772_lux *tsl2772_default_lux_table_group[] = {
> > > [tmd2672] = tmd2x72_lux_table,
> > > [tsl2772] = tsl2x72_lux_table,
> > > [tmd2772] = tmd2x72_lux_table,
> > > + [apds990x] = apds990x_lux_table,
> > > [apds9930] = apds9930_lux_table,
> > > };
> > >
> > > @@ -289,6 +297,7 @@ static const int tsl2772_int_time_avail[][6] = {
> > > [tmd2672] = { 0, 2730, 0, 2730, 0, 699000 },
> > > [tsl2772] = { 0, 2730, 0, 2730, 0, 699000 },
> > > [tmd2772] = { 0, 2730, 0, 2730, 0, 699000 },
> > > + [apds990x] = { 0, 2720, 0, 2720, 0, 696000 },
> > > [apds9930] = { 0, 2730, 0, 2730, 0, 699000 },
> > > };
> > >
> > > @@ -316,6 +325,7 @@ static const u8 device_channel_config[] = {
> > > [tmd2672] = PRX2,
> > > [tsl2772] = ALSPRX2,
> > > [tmd2772] = ALSPRX2,
> > > + [apds990x] = ALSPRX,
> >
> > This is different from tsl2772?
>
> yes, lux table is different and made according to datasheet,
> tsl2772_int_time_avail differs, ALSPRX configuration assumes that
> proximity sensor needs no calibration which is true for apds9900/1
> while tsl2772 needs calibration, device ID is different 0x20/0x29 for
> apds and 0x30 for tsl2772
All makes sense but that means the patch description needs to be
more precise about what elements are compatible, or use vaguer wording
like 'similar to'.
Jonathan
>
> >
> > > [apds9930] = ALSPRX2,
> > > };
> >
>
^ permalink raw reply
* Re: [PATCH v2 2/3] iio: tsl2772: add support for Avago APDS9900/9901 ALS/Proximity sensor
From: Svyatoslav Ryhel @ 2026-04-19 16:28 UTC (permalink / raw)
To: Jonathan Cameron
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Arnd Bergmann, Greg Kroah-Hartman, Randy Dunlap, linux-iio,
devicetree, linux-kernel, linux-doc
In-Reply-To: <20260419172458.375e7897@jic23-huawei>
нд, 19 квіт. 2026 р. о 19:25 Jonathan Cameron <jic23@kernel.org> пише:
>
> On Sun, 19 Apr 2026 16:46:25 +0300
> Svyatoslav Ryhel <clamor95@gmail.com> wrote:
>
> > нд, 19 квіт. 2026 р. о 16:38 Jonathan Cameron <jic23@kernel.org> пише:
> > >
> > > On Sun, 19 Apr 2026 11:31:23 +0300
> > > Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> > >
> > > > The Avago APDS990x has the same register set as the TAOS/AMS TSL2772 so
> > >
> > > A Sashiko review comment makes me wonder about one thing below if the
> > > register set does match. Maybe it's a bit more subtle than this
> > > patch description suggests?
> > >
> > > > just add the correct bindings and the appropriate LUX table derived from
> > > > the values in the datasheet. Driver was tested on the LG Optimus Vu P895.
> > > >
> > > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > > ---
> > > > drivers/iio/light/tsl2772.c | 16 ++++++++++++++++
> > > > 1 file changed, 16 insertions(+)
> > > >
> > > > diff --git a/drivers/iio/light/tsl2772.c b/drivers/iio/light/tsl2772.c
> > > > index c8f15ba95267..8dab34bf00ca 100644
> > > > --- a/drivers/iio/light/tsl2772.c
> > > > +++ b/drivers/iio/light/tsl2772.c
> > > > @@ -127,6 +127,7 @@ enum {
> > > > tmd2672,
> > > > tsl2772,
> > > > tmd2772,
> > > > + apds990x,
> > > > apds9930,
> > > > };
> > > >
> > > > @@ -221,6 +222,12 @@ static const struct tsl2772_lux tmd2x72_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > > > { 0, 0 },
> > > > };
> > > >
> > > > +static const struct tsl2772_lux apds990x_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > > > + { 52000, 115960 },
> > > > + { 36400, 73840 },
> > > > + { 0, 0 },
> > > > +};
> > > > +
> > > > static const struct tsl2772_lux apds9930_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > > > { 52000, 96824 },
> > > > { 38792, 67132 },
> > > > @@ -238,6 +245,7 @@ static const struct tsl2772_lux *tsl2772_default_lux_table_group[] = {
> > > > [tmd2672] = tmd2x72_lux_table,
> > > > [tsl2772] = tsl2x72_lux_table,
> > > > [tmd2772] = tmd2x72_lux_table,
> > > > + [apds990x] = apds990x_lux_table,
> > > > [apds9930] = apds9930_lux_table,
> > > > };
> > > >
> > > > @@ -289,6 +297,7 @@ static const int tsl2772_int_time_avail[][6] = {
> > > > [tmd2672] = { 0, 2730, 0, 2730, 0, 699000 },
> > > > [tsl2772] = { 0, 2730, 0, 2730, 0, 699000 },
> > > > [tmd2772] = { 0, 2730, 0, 2730, 0, 699000 },
> > > > + [apds990x] = { 0, 2720, 0, 2720, 0, 696000 },
> > > > [apds9930] = { 0, 2730, 0, 2730, 0, 699000 },
> > > > };
> > > >
> > > > @@ -316,6 +325,7 @@ static const u8 device_channel_config[] = {
> > > > [tmd2672] = PRX2,
> > > > [tsl2772] = ALSPRX2,
> > > > [tmd2772] = ALSPRX2,
> > > > + [apds990x] = ALSPRX,
> > >
> > > This is different from tsl2772?
> >
> > yes, lux table is different and made according to datasheet,
> > tsl2772_int_time_avail differs, ALSPRX configuration assumes that
> > proximity sensor needs no calibration which is true for apds9900/1
> > while tsl2772 needs calibration, device ID is different 0x20/0x29 for
> > apds and 0x30 for tsl2772
>
> All makes sense but that means the patch description needs to be
> more precise about what elements are compatible, or use vaguer wording
> like 'similar to'.
>
Fair, noted.
> Jonathan
>
> >
> > >
> > > > [apds9930] = ALSPRX2,
> > > > };
> > >
> >
>
^ permalink raw reply
* [PATCH] Documentation: fix spelling mistake "Minumum" -> "Minimum"
From: Ninad Naik @ 2026-04-19 17:08 UTC (permalink / raw)
To: mpearson-lenovo, derekjohn.clark, W_Armin, corbet, skhan
Cc: platform-driver-x86, linux-doc, linux-kernel, me,
linux-kernel-mentees, Ninad Naik
There is a spelling mistake in Documentation/wmi/devices/lenovo-wmi-other.rst.
Fixing it.
Signed-off-by: Ninad Naik <ninadnaik07@gmail.com>
---
Documentation/wmi/devices/lenovo-wmi-other.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/wmi/devices/lenovo-wmi-other.rst b/Documentation/wmi/devices/lenovo-wmi-other.rst
index 01d471156738..1d0410500d3f 100644
--- a/Documentation/wmi/devices/lenovo-wmi-other.rst
+++ b/Documentation/wmi/devices/lenovo-wmi-other.rst
@@ -144,5 +144,5 @@ data using the `bmfdec <https://github.com/pali/bmfdec>`_ utility:
[WmiDataId(1), read, Description("Mode.")] uint32 NumOfFans;
[WmiDataId(2), read, Description("Fan ID."), WmiSizeIs("NumOfFans")] uint32 FanId[];
[WmiDataId(3), read, Description("Maximum Fan Speed."), WmiSizeIs("NumOfFans")] uint32 FanMaxSpeed[];
- [WmiDataId(4), read, Description("Minumum Fan Speed."), WmiSizeIs("NumOfFans")] uint32 FanMinSpeed[];
+ [WmiDataId(4), read, Description("Minimum Fan Speed."), WmiSizeIs("NumOfFans")] uint32 FanMinSpeed[];
};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v7 3/4] KVM: arm64: PMU: Introduce FIXED_COUNTERS_ONLY
From: Marc Zyngier @ 2026-04-19 17:19 UTC (permalink / raw)
To: Akihiko Odaki
Cc: Oliver Upton, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Kees Cook, Gustavo A. R. Silva,
Paolo Bonzini, Jonathan Corbet, Shuah Khan, linux-arm-kernel,
kvmarm, linux-kernel, linux-hardening, devel, kvm, linux-doc,
linux-kselftest
In-Reply-To: <20260418-hybrid-v7-3-2bf39ad009bf@rsg.ci.i.u-tokyo.ac.jp>
On Sat, 18 Apr 2026 09:14:25 +0100,
Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote:
>
> On a heterogeneous arm64 system, KVM's PMU emulation is based on the
> features of a single host PMU instance. When a vCPU is migrated to a
> pCPU with an incompatible PMU, counters such as PMCCNTR_EL0 stop
> incrementing.
>
> Although this behavior is permitted by the architecture, Windows does
> not handle it gracefully and may crash with a division-by-zero error.
>
> The current workaround requires VMMs to pin vCPUs to a set of pCPUs
> that share a compatible PMU. This is difficult to implement correctly in
> QEMU/libvirt, where pinning occurs after vCPU initialization, and it
> also restricts the guest to a subset of available pCPUs.
>
> Introduce the KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY attribute to
> create a "fixed-counters-only" PMU. When set, KVM exposes a PMU that is
> compatible with all pCPUs but that does not support programmable
> event counters which may have different feature sets on different PMUs.
>
> This allows Windows guests to run reliably on heterogeneous systems
> without crashing, even without vCPU pinning, and enables VMMs to
> schedule vCPUs across all available pCPUs, making full use of the host
> hardware.
>
> Much like KVM_ARM_VCPU_PMU_V3_IRQ and other read-write attributes, this
> attribute provides a getter that facilitates kernel and userspace
> debugging/testing.
OK, so that's the sales pitch. But how is it implemented? I would like
to be able to read a high-level description of the implementation
trade-offs.
>
> Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
> ---
> Documentation/virt/kvm/devices/vcpu.rst | 29 ++++++
> arch/arm64/include/asm/kvm_host.h | 2 +
> arch/arm64/include/uapi/asm/kvm.h | 1 +
> arch/arm64/kvm/arm.c | 1 +
> arch/arm64/kvm/pmu-emul.c | 155 +++++++++++++++++++++++---------
> include/kvm/arm_pmu.h | 2 +
> 6 files changed, 147 insertions(+), 43 deletions(-)
>
> diff --git a/Documentation/virt/kvm/devices/vcpu.rst b/Documentation/virt/kvm/devices/vcpu.rst
> index 60bf205cb373..e0aeb1897d77 100644
> --- a/Documentation/virt/kvm/devices/vcpu.rst
> +++ b/Documentation/virt/kvm/devices/vcpu.rst
> @@ -161,6 +161,35 @@ explicitly selected, or the number of counters is out of range for the
> selected PMU. Selecting a new PMU cancels the effect of setting this
> attribute.
>
> +1.6 ATTRIBUTE: KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY
> +------------------------------------------------------
> +
> +:Parameters: no additional parameter in kvm_device_attr.addr
> +
> +:Returns:
> +
> + ======= =====================================================
> + -EBUSY Attempted to set after initializing PMUv3 or running
> + VCPU, or attempted to set for the first time after
> + setting an event filter
> + -ENXIO Attempted to get before setting
> + -ENODEV Attempted to set while PMUv3 not supported
> + ======= =====================================================
> +
> +If set, PMUv3 will be emulated without programmable event counters. The VCPU
> +will use any compatible hardware PMU. This attribute is particularly useful on
Not quite "any PMU". It will use *the* PMU of the physical CPU,
irrespective of the implementation.
> +heterogeneous systems where different hardware PMUs cover different physical
> +CPUs. The compatibility of hardware PMUs can be checked with
> +KVM_ARM_VCPU_PMU_V3_SET_PMU. All VCPUs in a VM share this attribute. It isn't
> +possible to set it for the first time if a PMU event filter is already present.
"for the first time" gives the impression that it will work if you try
again. I'd rather we say that "This feature is incompatible with the
existence of a PMU event filter".
Furthermore, the architecture currently describes *two* fixed-function
counters (cycles and instructions), while KVM only expose the cycle
counter. I'm all for the extra abstraction, but what does it mean for
migration if we enable FEAT_PMUv3_ICNTR?
> +
> +Note that KVM will not make any attempts to run the VCPU on the physical CPUs
> +with compatible hardware PMUs. This is entirely left to userspace. However,
> +attempting to run the VCPU on an unsupported CPU will fail and KVM_RUN will
> +return with exit_reason = KVM_EXIT_FAIL_ENTRY and populate the fail_entry struct
> +by setting hardware_entry_failure_reason field to
> +KVM_EXIT_FAIL_ENTRY_CPU_UNSUPPORTED and the cpu field to the processor id.
> +
This is mostly a copy-paste of the previous section. How relevant is
this to the fixed-counters-only feature? If the whole point of this
stuff is to ensure compatibility across CPUs with different PMU
implementations, surely what you describe here is the opposite of what
you want.
My preference would be to move this to a separate patch in any case,
more on that below.
> 2. GROUP: KVM_ARM_VCPU_TIMER_CTRL
> =================================
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 59f25b85be2b..b59e0182472c 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -353,6 +353,8 @@ struct kvm_arch {
> #define KVM_ARCH_FLAG_WRITABLE_IMP_ID_REGS 10
> /* Unhandled SEAs are taken to userspace */
> #define KVM_ARCH_FLAG_EXIT_SEA 11
> + /* PMUv3 is emulated without progammable event counters */
> +#define KVM_ARCH_FLAG_PMU_V3_FIXED_COUNTERS_ONLY 12
> unsigned long flags;
>
> /* VM-wide vCPU feature set */
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index a792a599b9d6..474c84fa757f 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -436,6 +436,7 @@ enum {
> #define KVM_ARM_VCPU_PMU_V3_FILTER 2
> #define KVM_ARM_VCPU_PMU_V3_SET_PMU 3
> #define KVM_ARM_VCPU_PMU_V3_SET_NR_COUNTERS 4
> +#define KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY 5
> #define KVM_ARM_VCPU_TIMER_CTRL 1
> #define KVM_ARM_VCPU_TIMER_IRQ_VTIMER 0
> #define KVM_ARM_VCPU_TIMER_IRQ_PTIMER 1
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index 620a465248d1..dca16ca26d32 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -634,6 +634,7 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
> if (has_vhe())
> kvm_vcpu_load_vhe(vcpu);
> kvm_arch_vcpu_load_fp(vcpu);
> + kvm_vcpu_load_pmu(vcpu);
> kvm_vcpu_pmu_restore_guest(vcpu);
> if (kvm_arm_is_pvtime_enabled(&vcpu->arch))
> kvm_make_request(KVM_REQ_RECORD_STEAL, vcpu);
> diff --git a/arch/arm64/kvm/pmu-emul.c b/arch/arm64/kvm/pmu-emul.c
> index ef5140bbfe28..d1009c144581 100644
> --- a/arch/arm64/kvm/pmu-emul.c
> +++ b/arch/arm64/kvm/pmu-emul.c
> @@ -326,7 +326,10 @@ u64 kvm_pmu_implemented_counter_mask(struct kvm_vcpu *vcpu)
>
> static void kvm_pmc_enable_perf_event(struct kvm_pmc *pmc)
> {
> - if (!pmc->perf_event) {
> + struct kvm_vcpu *vcpu = kvm_pmc_to_vcpu(pmc);
> +
> + if (!pmc->perf_event ||
> + !cpumask_test_cpu(vcpu->cpu, &to_arm_pmu(pmc->perf_event->pmu)->supported_cpus)) {
> kvm_pmu_create_perf_event(pmc);
> return;
> }
> @@ -667,10 +670,8 @@ static bool kvm_pmc_counts_at_el2(struct kvm_pmc *pmc)
> return kvm_pmc_read_evtreg(pmc) & ARMV8_PMU_INCLUDE_EL2;
> }
>
> -static int kvm_map_pmu_event(struct kvm *kvm, unsigned int eventsel)
> +static int kvm_map_pmu_event(struct arm_pmu *pmu, unsigned int eventsel)
> {
> - struct arm_pmu *pmu = kvm->arch.arm_pmu;
> -
> /*
> * The CPU PMU likely isn't PMUv3; let the driver provide a mapping
> * for the guest's PMUv3 event ID.
This refactor should be in its own patch. This sort of minor change is
adding noise to the mean of the patch, for no good reason.
> @@ -681,6 +682,23 @@ static int kvm_map_pmu_event(struct kvm *kvm, unsigned int eventsel)
> return eventsel;
> }
>
> +static struct arm_pmu *kvm_pmu_probe_armpmu(int cpu)
> +{
> + struct arm_pmu_entry *entry;
> + struct arm_pmu *pmu;
> +
> + guard(rcu)();
> +
> + list_for_each_entry_rcu(entry, &arm_pmus, entry) {
> + pmu = entry->arm_pmu;
> +
> + if (cpumask_test_cpu(cpu, &pmu->supported_cpus))
> + return pmu;
> + }
> +
> + return NULL;
> +}
> +
> /**
> * kvm_pmu_create_perf_event - create a perf event for a counter
> * @pmc: Counter context
> @@ -694,6 +712,12 @@ static void kvm_pmu_create_perf_event(struct kvm_pmc *pmc)
> int eventsel;
> u64 evtreg;
>
> + if (test_bit(KVM_ARCH_FLAG_PMU_V3_FIXED_COUNTERS_ONLY, &vcpu->kvm->arch.flags)) {
> + arm_pmu = kvm_pmu_probe_armpmu(vcpu->cpu);
> + if (!arm_pmu)
> + return;
How is it possible to not get a PMU here? We don't expose the PMU to a
guest at all if there are CPUs without PMUs, see the comment in
kvm_host_pmu_init(). So I'd expect this to never fail.
> + }
> +
> evtreg = kvm_pmc_read_evtreg(pmc);
>
> kvm_pmu_stop_counter(pmc);
> @@ -722,7 +746,7 @@ static void kvm_pmu_create_perf_event(struct kvm_pmc *pmc)
> * Don't create an event if we're running on hardware that requires
> * PMUv3 event translation and we couldn't find a valid mapping.
> */
> - eventsel = kvm_map_pmu_event(vcpu->kvm, eventsel);
> + eventsel = kvm_map_pmu_event(arm_pmu, eventsel);
> if (eventsel < 0)
> return;
>
> @@ -810,42 +834,6 @@ void kvm_host_pmu_init(struct arm_pmu *pmu)
> list_add_tail_rcu(&entry->entry, &arm_pmus);
> }
>
> -static struct arm_pmu *kvm_pmu_probe_armpmu(void)
> -{
> - struct arm_pmu_entry *entry;
> - struct arm_pmu *pmu;
> - int cpu;
> -
> - guard(rcu)();
> -
> - /*
> - * It is safe to use a stale cpu to iterate the list of PMUs so long as
> - * the same value is used for the entirety of the loop. Given this, and
> - * the fact that no percpu data is used for the lookup there is no need
> - * to disable preemption.
> - *
> - * It is still necessary to get a valid cpu, though, to probe for the
> - * default PMU instance as userspace is not required to specify a PMU
> - * type. In order to uphold the preexisting behavior KVM selects the
> - * PMU instance for the core during vcpu init. A dependent use
> - * case would be a user with disdain of all things big.LITTLE that
> - * affines the VMM to a particular cluster of cores.
> - *
> - * In any case, userspace should just do the sane thing and use the UAPI
> - * to select a PMU type directly. But, be wary of the baggage being
> - * carried here.
> - */
> - cpu = raw_smp_processor_id();
> - list_for_each_entry_rcu(entry, &arm_pmus, entry) {
> - pmu = entry->arm_pmu;
> -
> - if (cpumask_test_cpu(cpu, &pmu->supported_cpus))
> - return pmu;
> - }
> -
> - return NULL;
> -}
> -
Same thing for the refactoring of this function. Moving it, changing
the signature and moving the comment somewhere else would be better
placed on its own.
> static u64 __compute_pmceid(struct arm_pmu *pmu, bool pmceid1)
> {
> u32 hi[2], lo[2];
> @@ -888,6 +876,9 @@ u64 kvm_pmu_get_pmceid(struct kvm_vcpu *vcpu, bool pmceid1)
> u64 val, mask = 0;
> int base, i, nr_events;
>
> + if (test_bit(KVM_ARCH_FLAG_PMU_V3_FIXED_COUNTERS_ONLY, &vcpu->kvm->arch.flags))
> + return 0;
> +
> if (!pmceid1) {
> val = compute_pmceid0(cpu_pmu);
> base = 0;
> @@ -915,6 +906,26 @@ u64 kvm_pmu_get_pmceid(struct kvm_vcpu *vcpu, bool pmceid1)
> return val & mask;
> }
>
> +void kvm_vcpu_load_pmu(struct kvm_vcpu *vcpu)
> +{
> + unsigned long mask = kvm_pmu_enabled_counter_mask(vcpu);
> + struct kvm_pmc *pmc;
> + struct arm_pmu *cpu_pmu;
Move these to be inside the loop.
> + int i;
> +
> + for_each_set_bit(i, &mask, 32) {
> + pmc = kvm_vcpu_idx_to_pmc(vcpu, i);
> + if (!pmc->perf_event)
> + continue;
> +
> + cpu_pmu = to_arm_pmu(pmc->perf_event->pmu);
> + if (!cpumask_test_cpu(vcpu->cpu, &cpu_pmu->supported_cpus)) {
> + kvm_make_request(KVM_REQ_RELOAD_PMU, vcpu);
> + break;
> + }
> + }
> +}
> +
Why do we need to inflict this on VMs that do not have the fixed
counter restriction?
And even then, all you have to reconfigure is the cycle counter. So
why the loop? All we want to find out is whether the cycle counter is
instantiated on the PMU that matches the current CPU.
> void kvm_vcpu_reload_pmu(struct kvm_vcpu *vcpu)
> {
> u64 mask = kvm_pmu_implemented_counter_mask(vcpu);
> @@ -1016,6 +1027,9 @@ u8 kvm_arm_pmu_get_max_counters(struct kvm *kvm)
> {
> struct arm_pmu *arm_pmu = kvm->arch.arm_pmu;
>
> + if (test_bit(KVM_ARCH_FLAG_PMU_V3_FIXED_COUNTERS_ONLY, &kvm->arch.flags))
> + return 0;
> +
> /*
> * PMUv3 requires that all event counters are capable of counting any
> * event, though the same may not be true of non-PMUv3 hardware.
> @@ -1070,7 +1084,24 @@ static void kvm_arm_set_pmu(struct kvm *kvm, struct arm_pmu *arm_pmu)
> */
> int kvm_arm_set_default_pmu(struct kvm *kvm)
> {
> - struct arm_pmu *arm_pmu = kvm_pmu_probe_armpmu();
> + /*
> + * It is safe to use a stale cpu to iterate the list of PMUs so long as
> + * the same value is used for the entirety of the loop. Given this, and
> + * the fact that no percpu data is used for the lookup there is no need
> + * to disable preemption.
> + *
> + * It is still necessary to get a valid cpu, though, to probe for the
> + * default PMU instance as userspace is not required to specify a PMU
> + * type. In order to uphold the preexisting behavior KVM selects the
> + * PMU instance for the core during vcpu init. A dependent use
> + * case would be a user with disdain of all things big.LITTLE that
> + * affines the VMM to a particular cluster of cores.
> + *
> + * In any case, userspace should just do the sane thing and use the UAPI
> + * to select a PMU type directly. But, be wary of the baggage being
> + * carried here.
> + */
> + struct arm_pmu *arm_pmu = kvm_pmu_probe_armpmu(raw_smp_processor_id());
>
> if (!arm_pmu)
> return -ENODEV;
> @@ -1098,6 +1129,7 @@ static int kvm_arm_pmu_v3_set_pmu(struct kvm_vcpu *vcpu, int pmu_id)
> break;
> }
>
> + clear_bit(KVM_ARCH_FLAG_PMU_V3_FIXED_COUNTERS_ONLY, &kvm->arch.flags);
Why does this need to be cleared? I'd rather we make sure it is never
set the first place.
> kvm_arm_set_pmu(kvm, arm_pmu);
> cpumask_copy(kvm->arch.supported_cpus, &arm_pmu->supported_cpus);
> ret = 0;
> @@ -1108,11 +1140,42 @@ static int kvm_arm_pmu_v3_set_pmu(struct kvm_vcpu *vcpu, int pmu_id)
> return ret;
> }
>
> +static int kvm_arm_pmu_v3_set_pmu_fixed_counters_only(struct kvm_vcpu *vcpu)
> +{
> + struct kvm *kvm = vcpu->kvm;
> + struct arm_pmu_entry *entry;
> + struct arm_pmu *arm_pmu;
> + struct cpumask *supported_cpus = kvm->arch.supported_cpus;
> +
> + lockdep_assert_held(&kvm->arch.config_lock);
> +
> + if (kvm_vm_has_ran_once(kvm) ||
> + (kvm->arch.pmu_filter &&
> + !test_bit(KVM_ARCH_FLAG_PMU_V3_FIXED_COUNTERS_ONLY, &kvm->arch.flags)))
> + return -EBUSY;
> +
> + set_bit(KVM_ARCH_FLAG_PMU_V3_FIXED_COUNTERS_ONLY, &kvm->arch.flags);
> + kvm_arm_set_nr_counters(kvm, 0);
> + cpumask_clear(supported_cpus);
What is the purpose of this cpumask_clear()? Under what conditions can
you have something else?
> +
> + guard(rcu)();
> +
> + list_for_each_entry_rcu(entry, &arm_pmus, entry) {
> + arm_pmu = entry->arm_pmu;
> + cpumask_or(supported_cpus, supported_cpus, &arm_pmu->supported_cpus);
Why isn't supported_cpus directly set to possible_cpus? Isn't that the
base requirement that you can run on any CPU at all?
> + }
> +
> + return 0;
> +}
> +
> static int kvm_arm_pmu_v3_set_nr_counters(struct kvm_vcpu *vcpu, unsigned int n)
> {
> struct kvm *kvm = vcpu->kvm;
>
> - if (!kvm->arch.arm_pmu)
> + lockdep_assert_held(&kvm->arch.config_lock);
> +
> + if (!kvm->arch.arm_pmu &&
> + !test_bit(KVM_ARCH_FLAG_PMU_V3_FIXED_COUNTERS_ONLY, &kvm->arch.flags))
> return -EINVAL;
>
> if (n > kvm_arm_pmu_get_max_counters(kvm))
> @@ -1227,6 +1290,8 @@ int kvm_arm_pmu_v3_set_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr)
>
> return kvm_arm_pmu_v3_set_nr_counters(vcpu, n);
> }
> + case KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY:
> + return kvm_arm_pmu_v3_set_pmu_fixed_counters_only(vcpu);
> case KVM_ARM_VCPU_PMU_V3_INIT:
> return kvm_arm_pmu_v3_init(vcpu);
> }
> @@ -1253,6 +1318,9 @@ int kvm_arm_pmu_v3_get_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr)
> irq = vcpu->arch.pmu.irq_num;
> return put_user(irq, uaddr);
> }
> + case KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY:
> + if (test_bit(KVM_ARCH_FLAG_PMU_V3_FIXED_COUNTERS_ONLY, &vcpu->kvm->arch.flags))
With 6 occurrences of this test_bit(), it feels like it'd be valuable
to have a dedicate predicate to help with readability.
> + return 0;
> }
>
> return -ENXIO;
> @@ -1266,6 +1334,7 @@ int kvm_arm_pmu_v3_has_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr)
> case KVM_ARM_VCPU_PMU_V3_FILTER:
> case KVM_ARM_VCPU_PMU_V3_SET_PMU:
> case KVM_ARM_VCPU_PMU_V3_SET_NR_COUNTERS:
> + case KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY:
> if (kvm_vcpu_has_pmu(vcpu))
> return 0;
> }
> diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
> index 96754b51b411..1375cbaf97b2 100644
> --- a/include/kvm/arm_pmu.h
> +++ b/include/kvm/arm_pmu.h
> @@ -56,6 +56,7 @@ void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
> void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
> void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
> u64 select_idx);
> +void kvm_vcpu_load_pmu(struct kvm_vcpu *vcpu);
> void kvm_vcpu_reload_pmu(struct kvm_vcpu *vcpu);
> int kvm_arm_pmu_v3_set_attr(struct kvm_vcpu *vcpu,
> struct kvm_device_attr *attr);
> @@ -161,6 +162,7 @@ static inline u64 kvm_pmu_get_pmceid(struct kvm_vcpu *vcpu, bool pmceid1)
> static inline void kvm_pmu_update_vcpu_events(struct kvm_vcpu *vcpu) {}
> static inline void kvm_vcpu_pmu_restore_guest(struct kvm_vcpu *vcpu) {}
> static inline void kvm_vcpu_pmu_restore_host(struct kvm_vcpu *vcpu) {}
> +static inline void kvm_vcpu_load_pmu(struct kvm_vcpu *vcpu) {}
> static inline void kvm_vcpu_reload_pmu(struct kvm_vcpu *vcpu) {}
> static inline u8 kvm_arm_pmu_get_pmuver_limit(void)
> {
>
In conclusion, I find this patch to be rather messy. For a start, it
needs to be split in at least 5 patches:
- at least two for the refactoring
- one for the PMU core changes
- one for the UAPI
- one for documentation
I'd also like some clarification on how this is intended to work if we
enable FEAT_PMUv3_ICNTR, because the definition seems to be designed
to encompass all fixed-function counters, and I expect this to grow
over time.
I'm also not planning to look at the selftest at this stage.
Thanks,
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* [PATCH 7.2 v16 00/13] khugepaged: mTHP support
From: Nico Pache @ 2026-04-19 18:57 UTC (permalink / raw)
To: linux-doc, linux-kernel, linux-mm, linux-trace-kernel
Cc: 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.Howlett, ljs,
mathieu.desnoyers, matthew.brost, mhiramat, mhocko, npache,
peterx, pfalcato, rakie.kim, raquini, rdunlap, richard.weiyang,
rientjes, rostedt, rppt, ryan.roberts, shivankg, sunnanyong,
surenb, thomas.hellstrom, tiwai, usamaarif642, vbabka,
vishal.moola, wangkefeng.wang, will, willy, yang, ying.huang, ziy,
zokeefe
The following series provides khugepaged with the capability to collapse
anonymous memory regions to mTHPs.
To achieve this we generalize the khugepaged functions to no longer depend
on PMD_ORDER. Then during the PMD scan, we use a bitmap to track individual
pages that are occupied (!none/zero). After the PMD scan is done, we use
the bitmap to find the optimal mTHP sizes for the PMD range. The
restriction on max_ptes_none is removed during the scan, to make sure we
account for the whole PMD range in the bitmap. When no mTHP size is
enabled, the legacy behavior of khugepaged is maintained.
We currently only support max_ptes_none values of 0 or HPAGE_PMD_NR - 1
(ie 511). If any other value is specified, the kernel will emit a warning
and no mTHP collapse will be attempted. If a mTHP collapse is attempted,
but contains swapped out, or shared pages, we don't perform the collapse.
It is now also possible to collapse to mTHPs without requiring the PMD THP
size to be enabled. These limitations are to prevent collapse "creep"
behavior. This prevents constantly promoting mTHPs to the next available
size, which would occur because a collapse introduces more non-zero pages
that would satisfy the promotion condition on subsequent scans.
Patch 1-2: Generalize hugepage_vma_revalidate and alloc_charge_folio
for arbitrary orders.
Patch 3: Rework max_ptes_* handling into helper functions
Patch 4-5: Generalize __collapse_huge_page_* and collapse_huge_page
Patch 6: Skip collapsing mTHP to smaller orders
Patch 7-8: Add per-order mTHP statistics and tracepoints
Patch 9: Introduce collapse_allowable_orders helper function
Patch 10-12: Introduce bitmap and mTHP collapse support, fully enabled
Patch 13: Documentation
Testing:
- Built for x86_64, aarch64, ppc64le, and s390x
- ran all arches on test suites provided by the kernel-tests project
- internal testing suites: functional testing and performance testing
- selftests mm
- I created a test script that I used to push khugepaged to its limits
while monitoring a number of stats and tracepoints. The code is
available here[1] (Run in legacy mode for these changes and set mthp
sizes to inherit)
The summary from my testings was that there was no significant
regression noticed through this test. In some cases my changes had
better collapse latencies, and was able to scan more pages in the same
amount of time/work, but for the most part the results were consistent.
- redis testing. I did some testing with these changes along with my defer
changes (see followup [2] post for more details). We've decided to get
the mTHP changes merged first before attempting the defer series.
- some basic testing on 64k page size.
- lots of general use.
V16 Changes:
- This was quite the respin, so hopefully everything is ok! I dropped
some acks/rb on patches that changed significantly. Major changes
are related to the locking cleanup in collapse_huge_page().
sorry if i missed any feedback there was quite a bit of minor requests
- New cleanup patch: introduce collapse_max_ptes_none/shared/swap()
helpers, absorbing madvise_collapse special-casing (David)
- Merge "introduce collapse_max_ptes_none helper" into the generalize
__collapse_huge_page_* patch, dropping the separate patch (David)
- Simplify collapse_huge_page() locking: move mmap_read_unlock() to
caller, remove mmap_locked tracking parameter entirely (Lorenzo)
- Use enum tva_type instead of bool is_khugepaged in
collapse_allowable_orders() (David, Lorenzo)
- collapse_allowable_orders() takes (vma, tva_flags), accesses
vma->vm_flags internally (Lorenzo)
- Rename mthp_* functions to collapse_mthp_* prefix (David, Lorenzo)
- Use MAX_PTRS_PER_PTE consistently for bitmap ops (Lorenzo)
- Downgrade BUG_ON() to WARN_ON_ONCE() in collapse_huge_page() (Lorenzo)
- Add /*expect_anon=*/true annotation to revalidate calls (Lorenzo)
- Pull common spin_lock + WARN_ON_ONCE out of PMD/mTHP branch (Lorenzo)
- Fix pteval declaration style; use end_addr variable (Lorenzo)
- Use ternary for result assignment in collapse_scan_pmd() (Lorenzo)
- Improve anon_vma locking comment for mTHP case (Lorenzo)
- Document why skip-smaller-order isn't done in scan phase (David)
- Make documentation of max_ptes_none mTHP behavior (only 0 and
HPAGE_PMD_NR-1 supported) in admin guide more apparent. (David, Lorenzo)
- Collect new Acks/RB tags from v15 review
V15: https://lore.kernel.org/all/20260226031741.230674-1-npache@redhat.com
V14: https://lore.kernel.org/all/20260122192841.128719-1-npache@redhat.com
V13: https://lore.kernel.org/all/20251201174627.23295-1-npache@redhat.com
V12: https://lore.kernel.org/all/20251022183717.70829-1-npache@redhat.com
V11: https://lore.kernel.org/all/20250912032810.197475-1-npache@redhat.com
V10: https://lore.kernel.org/all/20250819134205.622806-1-npache@redhat.com
V9 : https://lore.kernel.org/all/20250714003207.113275-1-npache@redhat.com
V8 : https://lore.kernel.org/all/20250702055742.102808-1-npache@redhat.com
V7 : https://lore.kernel.org/all/20250515032226.128900-1-npache@redhat.com
V6 : https://lore.kernel.org/all/20250515030312.125567-1-npache@redhat.com
V5 : https://lore.kernel.org/all/20250428181218.85925-1-npache@redhat.com
V4 : https://lore.kernel.org/all/20250417000238.74567-1-npache@redhat.com
V3 : https://lore.kernel.org/all/20250414220557.35388-1-npache@redhat.com
V2 : https://lore.kernel.org/all/20250211003028.213461-1-npache@redhat.com
V1 : https://lore.kernel.org/all/20250108233128.14484-1-npache@redhat.com
A big thanks to everyone that has reviewed, tested, and participated in
the development process. Its been a great experience working with all of
you on this endeavor.
[1] - https://gitlab.com/npache/khugepaged_mthp_test
[2] - https://lore.kernel.org/lkml/20250515033857.132535-1-npache@redhat.com/
Baolin Wang (1):
mm/khugepaged: run khugepaged for all orders
Dev Jain (1):
mm/khugepaged: generalize alloc_charge_folio()
Nico Pache (11):
mm/khugepaged: generalize hugepage_vma_revalidate for mTHP support
mm/khugepaged: rework max_ptes_* handling with helper functions
mm/khugepaged: generalize __collapse_huge_page_* for mTHP support
mm/khugepaged: generalize collapse_huge_page for mTHP collapse
mm/khugepaged: skip collapsing mTHP to smaller orders
mm/khugepaged: add per-order mTHP collapse failure statistics
mm/khugepaged: improve tracepoints for mTHP orders
mm/khugepaged: introduce collapse_allowable_orders helper function
mm/khugepaged: Introduce mTHP collapse support
mm/khugepaged: avoid unnecessary mTHP collapse attempts
Documentation: mm: update the admin guide for mTHP collapse
Documentation/admin-guide/mm/transhuge.rst | 81 ++-
include/linux/huge_mm.h | 5 +
include/linux/khugepaged.h | 6 +-
include/trace/events/huge_memory.h | 34 +-
mm/huge_memory.c | 13 +-
mm/khugepaged.c | 623 ++++++++++++++++-----
mm/vma.c | 6 +-
tools/testing/vma/include/stubs.h | 3 +-
8 files changed, 589 insertions(+), 182 deletions(-)
base-commit: 4569c01e84d440f1f6c79df1e13e9c86a9fb80ca
--
2.53.0
^ permalink raw reply
* [PATCH 7.2 v16 01/13] mm/khugepaged: generalize hugepage_vma_revalidate for mTHP support
From: Nico Pache @ 2026-04-19 18:57 UTC (permalink / raw)
To: linux-doc, linux-kernel, linux-mm, linux-trace-kernel
Cc: 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.Howlett, ljs,
mathieu.desnoyers, matthew.brost, mhiramat, mhocko, npache,
peterx, pfalcato, rakie.kim, raquini, rdunlap, richard.weiyang,
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: <20260419185750.260784-1-npache@redhat.com>
For khugepaged to support different mTHP orders, we must generalize this
to check if the PMD is not shared by another VMA and that the order is
enabled.
No functional change in this patch. Also correct a comment about the
functionality of the revalidation and fix a double space issues.
Reviewed-by: Wei Yang <richard.weiyang@gmail.com>
Reviewed-by: Lance Yang <lance.yang@linux.dev>
Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
Reviewed-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Zi Yan <ziy@nvidia.com>
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
Co-developed-by: Dev Jain <dev.jain@arm.com>
Signed-off-by: Dev Jain <dev.jain@arm.com>
Signed-off-by: Nico Pache <npache@redhat.com>
---
mm/khugepaged.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index b8452dbdb043..53e7e4be172d 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -902,12 +902,13 @@ static int collapse_find_target_node(struct collapse_control *cc)
/*
* If mmap_lock temporarily dropped, revalidate vma
- * before taking mmap_lock.
+ * after taking the mmap_lock again.
* Returns enum scan_result value.
*/
static enum scan_result hugepage_vma_revalidate(struct mm_struct *mm, unsigned long address,
- bool expect_anon, struct vm_area_struct **vmap, struct collapse_control *cc)
+ bool expect_anon, struct vm_area_struct **vmap,
+ struct collapse_control *cc, unsigned int order)
{
struct vm_area_struct *vma;
enum tva_type type = cc->is_khugepaged ? TVA_KHUGEPAGED :
@@ -920,15 +921,16 @@ static enum scan_result hugepage_vma_revalidate(struct mm_struct *mm, unsigned l
if (!vma)
return SCAN_VMA_NULL;
+ /* Always check the PMD order to ensure its not shared by another VMA */
if (!thp_vma_suitable_order(vma, address, PMD_ORDER))
return SCAN_ADDRESS_RANGE;
- if (!thp_vma_allowable_order(vma, vma->vm_flags, type, PMD_ORDER))
+ if (!thp_vma_allowable_orders(vma, vma->vm_flags, type, BIT(order)))
return SCAN_VMA_CHECK;
/*
* Anon VMA expected, the address may be unmapped then
* remapped to file after khugepaged reaquired the mmap_lock.
*
- * thp_vma_allowable_order may return true for qualified file
+ * thp_vma_allowable_orders may return true for qualified file
* vmas.
*/
if (expect_anon && (!(*vmap)->anon_vma || !vma_is_anonymous(*vmap)))
@@ -1121,7 +1123,8 @@ static enum scan_result collapse_huge_page(struct mm_struct *mm, unsigned long a
goto out_nolock;
mmap_read_lock(mm);
- result = hugepage_vma_revalidate(mm, address, true, &vma, cc);
+ result = hugepage_vma_revalidate(mm, address, true, &vma, cc,
+ HPAGE_PMD_ORDER);
if (result != SCAN_SUCCEED) {
mmap_read_unlock(mm);
goto out_nolock;
@@ -1155,7 +1158,8 @@ static enum scan_result collapse_huge_page(struct mm_struct *mm, unsigned long a
* mmap_lock.
*/
mmap_write_lock(mm);
- result = hugepage_vma_revalidate(mm, address, true, &vma, cc);
+ result = hugepage_vma_revalidate(mm, address, true, &vma, cc,
+ HPAGE_PMD_ORDER);
if (result != SCAN_SUCCEED)
goto out_up_write;
/* check if the pmd is still valid */
@@ -2857,8 +2861,8 @@ int madvise_collapse(struct vm_area_struct *vma, unsigned long start,
mmap_unlocked = false;
*lock_dropped = true;
result = hugepage_vma_revalidate(mm, addr, false, &vma,
- cc);
- if (result != SCAN_SUCCEED) {
+ cc, HPAGE_PMD_ORDER);
+ if (result != SCAN_SUCCEED) {
last_fail = result;
goto out_nolock;
}
--
2.53.0
^ permalink raw reply related
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