* Re: [PATCH v2] Docs: iio: ad7191 Correct clock configuration
From: Jonathan Cameron @ 2026-03-27 7:31 UTC (permalink / raw)
To: Ammar Mustafa
Cc: Andy Shevchenko, Alisa-Dariana Roman, David Lechner, Nuno Sá,
Andy Shevchenko, Jonathan Corbet, Shuah Khan, linux-iio,
linux-doc, linux-kernel
In-Reply-To: <acWthfEL_HGtVykN@TARS>
On Thu, 26 Mar 2026 18:04:53 -0400
Ammar Mustafa <ammarmustafa34@gmail.com> wrote:
> On Sun, Mar 22, 2026 at 12:13:14PM +0000, Jonathan Cameron wrote:
> > On Sat, 28 Feb 2026 12:50:46 +0200
> > Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> >
> > > On Fri, Feb 27, 2026 at 02:08:33PM -0500, Ammar Mustafa wrote:
> > > > Correct the ad7191 documentation to match the datasheet:
> > > > - Fix inverted CLKSEL pin logic: device uses external clock when pin is
> > > > inactive, and internal CMOS/crystal when high.
> > >
> > > high --> active
> > >
> > > Thanks, this part looks good in the below documentation update.
> > >
> > > > - Correct CMOS-compatible clock pin from MCLK2 to MCLK1.
> > >
> > > I haven't checked driver yet, but is it only for a single component?
> > > Can you double check that _all_ supported by the driver have the same
> > > in their datasheet(s)?
> > >
> > > ...
> >
> > Hi Ammar,
> >
> > Just a quick note to say I'm going to mark this one in patchwork
> > as needing a new version given Andy's questions have been here a while.
> >
> > Thanks,
> >
> > Jonathan
> >
> > >
> > > > +- When CLKSEL pin is ACTIVE: Uses internal 4.92MHz clock (no clock property
> > > > needed)
> > > > -- When CLKSEL pin is tied HIGH: Requires external clock source
> > > > +- When CLKSEL pin is INACTIVE: Requires external clock source
> > > > - Can be a crystal between MCLK1 and MCLK2 pins
> > > > - - Or a CMOS-compatible clock driving MCLK2 pin
> > > > + - Or a CMOS-compatible clock driving MCLK1 pin and MCLK2 left unconnected
> > > > - Must specify the "clocks" property in device tree when using external clock
> > >
> >
>
> Hi Jonathon,
>
> I replied to Andy's questionm not sure if I can attach it in mutt for you,
> but we found that this driver only supports the AD7191 so no other
> documentation needs to be updated or check for this issue.
> Let me know if I need to do anything else to have this patch merged.
>
Given it's docs, I'll a sneak it in (not so worried if this one gets
build time in linux-next). Applied.
Thanks,
Jonathan
> Thank you,
>
> Ammar Mustafa
^ permalink raw reply
* Re: [PATCH v1 6/6] docs: misc: amd-sbi: Document SBTSI userspace interface
From: Greg KH @ 2026-03-27 7:25 UTC (permalink / raw)
To: Akshay Gupta
Cc: linux-kernel, corbet, skhan, linux, arnd, Prathima.Lk,
naveenkrishna.chatradhi, Anand.Umarji, linux-doc, linux-hwmon,
kunyi
In-Reply-To: <20260323110811.2898997-7-Akshay.Gupta@amd.com>
On Mon, Mar 23, 2026 at 04:38:11PM +0530, Akshay Gupta wrote:
> From: Prathima <Prathima.Lk@amd.com>
>
> - Document AMD sideband IOCTL description defined
> for SBTSI and its usage.
> User space C-APIs are made available by esmi_oob_library [1],
> which is provided by the E-SMS project [2].
>
> Link: https://github.com/amd/esmi_oob_library [1]
> Link: https://www.amd.com/en/developer/e-sms.html [2]
Ok, nevermind, here's the documentation :)
But it's very tiny, it's not saying what the api actually is.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v1 5/6] misc: amd-sbi: Add SBTSI ioctl register transfer interface
From: Greg KH @ 2026-03-27 7:24 UTC (permalink / raw)
To: Akshay Gupta
Cc: linux-kernel, corbet, skhan, linux, arnd, Prathima.Lk,
naveenkrishna.chatradhi, Anand.Umarji, linux-doc, linux-hwmon,
kunyi
In-Reply-To: <20260323110811.2898997-6-Akshay.Gupta@amd.com>
On Mon, Mar 23, 2026 at 04:38:10PM +0530, Akshay Gupta wrote:
> + dev_info(&client->dev, "Removed sbtsi driver\n");
When drivers work properly, they are quiet. No need for this kernel log
spam.
And were are all of these new ioctls documented and where is the
userspace tools that use them?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v1 1/6] hwmon/misc: amd-sbi: Move core SBTSI support from hwmon to misc
From: gregkh @ 2026-03-27 7:23 UTC (permalink / raw)
To: Guenter Roeck
Cc: Gupta, Akshay, linux-kernel@vger.kernel.org, corbet@lwn.net,
skhan@linuxfoundation.org, arnd@arndb.de, L k, Prathima,
Chatradhi, Naveen Krishna, Umarji, Anand,
linux-doc@vger.kernel.org, linux-hwmon@vger.kernel.org,
kunyi@google.com
In-Reply-To: <60ab1803-accb-4ac3-91bd-f6d24354c19a@roeck-us.net>
On Thu, Mar 26, 2026 at 10:52:29PM -0700, Guenter Roeck wrote:
> On 3/26/26 22:07, Gupta, Akshay wrote:
> >
> > On 3/24/2026 5:03 PM, Guenter Roeck wrote:
> > > Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
> > >
> > >
> > > On 3/24/26 03:36, Gupta, Akshay wrote:
> > > > On 3/23/2026 7:45 PM, Guenter Roeck wrote:
> > > > > Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
> > > > >
> > > > >
> > > > > On 3/23/26 04:08, Akshay Gupta wrote:
> > > > > > From: Prathima <Prathima.Lk@amd.com>
> > > > > >
> > > > > > Move SBTSI core functionality out of the hwmon-only path and into
> > > > > > drivers/misc/amd-sbi so it can be reused by non-hwmon consumers.
> > > > > >
> > > > > > This split prepares the driver for additional interfaces while keeping
> > > > > > hwmon support as an optional layer on top of common SBTSI core logic.
> > > > > >
> > > > > This moves the driver out of hwmon space into misc/amd-sbi which,
> > > > > in my opinion, is completely unnecessary to accomplish the stated goals.
> > > > >
> > > > > I assume this is to be able to make changes which do not follow
> > > > > the hwmon ABI and/or to bypass hwmon subsystem review, similar
> > > > > to what has been done by others.
> > > > >
> > > > > Obviously, I think this is a bad idea. I won't give it a NACK,
> > > > > but I won't approve (nor review) it either.
> > > > >
> > > > > Guenter
> > > > Hi Guenter,
> > > >
> > > > Thank you for your quick response.
> > > >
> > > > At present, TSI supports a range of functionalities that cannot be exposed through hwmon. Additionally, a new protocol leveraging the TSI endpoint in hardware has been introduced, which, to our understanding, cannot be accommodated within the hwmon subsystem.
> > > >
> > > > Since we already support the RMI interface via misc/amd-sbi, we believe this remains the appropriate place to continue AMD's out-of-band support.
> > > >
> > > > I will update the commit message and cover letter to clearly articulate the rationale behind this change.
> > > >
> > > > Thank you
> > > >
> > > That is neither a reason or an argument for moving _hwmon_ part of the code
> > > out of the hwmon subsystem.
> > Following feedback from the Greg and MFD subsystem maintainers, we introduced an sb-rmi driver under misc/ that calls devm_hwmon_device_register_with_info(). We are considering the same approach for the sb-tsi driver. Would you recommend a more suitable alternative?
>
> I would have suggested to use an auxiliary driver, similar to PECI,
> but who am I to argue if senior maintainers suggest otherwise.
Sounds like an aux driver makes sense to me too, I don't remember saying
that you HAD to call devm_hwmon_device_register_with_info(), where was
that stated in previous reviews?
thanks,
greg k-h
^ permalink raw reply
* Re: kernel-doc overly verbose with V=0
From: Mauro Carvalho Chehab @ 2026-03-27 6:11 UTC (permalink / raw)
To: Jacob Keller
Cc: Jonathan Corbet, Linux Doc Mailing List, Shuah Khan, Randy Dunlap,
linux-kernel@vger.kernel.org
In-Reply-To: <297f6ef2-1760-4b85-a55e-73a2f061d641@intel.com>
On Wed, 25 Mar 2026 13:42:44 -0700
Jacob Keller <jacob.e.keller@intel.com> wrote:
> On 3/25/2026 4:50 AM, Mauro Carvalho Chehab wrote:
> > On Tue, 24 Mar 2026 13:37:39 -0700
> > Jacob Keller <jacob.e.keller@intel.com> wrote:
> >
> >> Hi,
> >>
> >> I recently saw some strange behavior with the Python kernel-doc. I was
> >> seeing the verbose info lines from the kernel-doc script, i.e.:
> >>
> >>> Info: ice_ptp_hw.c:5377 Scanning doc for function ice_cgu_get_pin_freq_supp
> >>> Info: ice_ptp_hw.c:5406 Scanning doc for function ice_cgu_get_pin_name
> >>> Info: ice_ptp_hw.c:5441 Scanning doc for function ice_cgu_state_to_name
> >>> Info: ice_ptp_hw.c:5463 Scanning doc for function ice_get_dpll_ref_sw_status
> >>> Info: ice_ptp_hw.c:5505 Scanning doc for function ice_set_dpll_ref_sw_status
> >>> Info: ice_ptp_hw.c:5544 Scanning doc for function ice_get_cgu_state
> >>> Info: ice_ptp_hw.c:5612 Scanning doc for function ice_get_cgu_rclk_pin_info
> >>> Info: ice_ptp_hw.c:5671 Scanning doc for function ice_cgu_get_output_pin_state_caps
> >>> Info: ice_ptp_hw.c:5733 Scanning doc for function ice_ptp_lock
> >>> Info: ice_ptp_hw.c:5770 Scanning doc for function ice_ptp_unlock
> >>> Info: ice_ptp_hw.c:5782 Scanning doc for function ice_ptp_init_hw
> >>> Info: ice_ptp_hw.c:5811 Scanning doc for function ice_ptp_write_port_cmd
> >>> Info: ice_ptp_hw.c:5834 Scanning doc for function ice_ptp_one_port_cmd
> >>> Info: ice_ptp_hw.c:5866 Scanning doc for function ice_ptp_port_cmd
> >>> Info: ice_ptp_hw.c:5901 Scanning doc for function ice_ptp_tmr_cmd
> >>> Info: ice_ptp_hw.c:5934 Scanning doc for function ice_ptp_init_time
> >>> Info: ice_ptp_hw.c:5986 Scanning doc for function ice_ptp_write_incval
> >>> Info: ice_ptp_hw.c:6035 Scanning doc for function ice_ptp_write_incval_locked
> >>> Info: ice_ptp_hw.c:6056 Scanning doc for function ice_ptp_adj_clock
> >>> Info: ice_ptp_hw.c:6107 Scanning doc for function ice_read_phy_tstamp
> >>> Info: ice_ptp_hw.c:6134 Scanning doc for function ice_clear_phy_tstamp
> >>> Info: ice_ptp_hw.c:6164 Scanning doc for function ice_ptp_reset_ts_memory
> >>> Info: ice_ptp_hw.c:6183 Scanning doc for function ice_ptp_init_phc
> >>> Info: ice_ptp_hw.c:6215 Scanning doc for function ice_get_phy_tx_tstamp_ready
> >>> Info: ice_ptp_hw.c:6247 Scanning doc for function ice_check_phy_tx_tstamp_ready
> >>> Info: ice_ptp_hw.c:6273 Scanning doc for function ice_ptp_config_sfd
> >>> Info: ice_ptp_hw.c:6293 Scanning doc for function refsync_pin_id_valid
> >>
> >> I didn't understand why I was seeing this as it should only be happening
> >> if running kernel-doc in verbose mode. Then I discovered I had set
> >> KBUILD_VERBOSE=0 in my environment.
> >>
> >> The python kernel-doc implementation reads this in the __init__ for
> >> KernelFiles() on line 165:
> >>
> >>> if not verbose:
> >>> verbose = bool(os.environ.get("KBUILD_VERBOSE", 0))
> >>
> >> After some debugging, I realized this reads KBUILD_VERBOSE as a string,
> >> then converts it to a boolean using python's standard rules, so "0"
> >> becomes true, which enables the verbose output.
> >
> > Looking at tools/docs/sphinx-build-wrapper, it implements verbosity
> > by doing:
> >
> > verbose = bool(os.environ.get("KBUILD_VERBOSE", "") != "")
> >
> > which will also have the same problem as the one you detected.
> >
>
> Yep.
>
> > Perhaps the right fix would be to first convert to int then to bool
> > on both places, in a way that "" will also be handled properly.
> > Perhaps with:
> >
> > try:
> > verbose = bool(int(os.environ.get("KBUILD_VERBOSE", 0)))
> > except ValueError:
> > # Handles an eventual case where verbosity is not a number
> > # like KBUILD_VERBOSE=""
> > verbose = False
> > >> This is in contrast to the (now removed) kernel-doc.pl script which
> >> checked the value for a 1:
> >>
> >>> if (defined($ENV{'KBUILD_VERBOSE'}) && $ENV{'KBUILD_VERBOSE'} =~ '1')
> >> The same behavior happens if you assign V=0 on the command line or to
> >> any other non-empty string, since when V is set on the command line it
> >> sets KBUILD_VERBOSE.
> >
> > That's funny... we did test make V=0 htmldocs / make V=1 htmldocs
> >
>
> Strange. The Makefile does this:
>
> ifeq ("$(origin V)", "command line")
> KBUILD_VERBOSE = $(V)
> endif
>
> I can see KBUILD_VERBOSE=0 from the top level Makefile, but you're right
> it doesn't seem to trigger the environment variable..
>
> > It sounds that the problem is only if you explicitly set it without
> > relying on gnu make.
> >
>
> Adding some warn prints I do see the Makefile sets KBUILD_VERBOSE=0 when
> you do V=0.. and it has an export clause for KBUILD_VERBOSE
>
> Oh, it might be your particular build doesn't have W=1 so checkdoc isn't
> being defined and thus kernel-doc isn't running?
>
> If I do "make W=1 V=0" I do actually see these lines:
>
> > Info: ../drivers/pci/pci.c:3646 Scanning doc for function pci_acs_init
> > Info: ../drivers/pci/pci.c:3663 Scanning doc for function pci_enable_atomic_ops_to_root
> > Info: ../drivers/pci/pci.c:3746 Scanning doc for function pci_release_region
> > Info: ../drivers/pci/pci.c:3772 Scanning doc for function __pci_request_region
> > Info: ../drivers/pci/pci.c:3820 Scanning doc for function pci_request_region
> > Info: ../drivers/pci/pci.c:3841 Scanning doc for function pci_release_selected_regions
> > Info: ../drivers/pci/pci.c:3879 Scanning doc for function pci_request_selected_regions
> > Info: ../drivers/pci/pci.c:3894 Scanning doc for function pci_request_selected_regions_exclusive
> > Info: ../drivers/pci/pci.c:3910 Scanning doc for function pci_release_regions
> > Info: ../drivers/pci/pci.c:3925 Scanning doc for function pci_request_regions
> > Info: ../drivers/pci/pci.c:3944 Scanning doc for function pci_request_regions_exclusive
> > Info: ../drivers/pci/pci.c:4026 Scanning doc for function pci_remap_iospace
> > Info: ../drivers/pci/pci.c:4062 Scanning doc for function pci_unmap_iospace
> > Info: ../drivers/pci/pci.c:4097 Scanning doc for function pcibios_setup
> > Info: ../drivers/pci/pci.c:4109 Scanning doc for function pcibios_set_master
> > Info: ../drivers/pci/pci.c:4136 Scanning doc for function pci_set_master
> > Info: ../drivers/pci/pci.c:4150 Scanning doc for function pci_clear_master
> > Info: ../drivers/pci/pci.c:4160 Scanning doc for function pci_set_cacheline_size
> > Info: ../drivers/pci/pci.c:4198 Scanning doc for function pci_set_mwi
> > Info: ../drivers/pci/pci.c:4229 Scanning doc for function pci_try_set_mwi
> > Info: ../drivers/pci/pci.c:4248 Scanning doc for function pci_clear_mwi
> > Info: ../drivers/pci/pci.c:4268 Scanning doc for function pci_disable_parity
> > Info: ../drivers/pci/pci.c:4285 Scanning doc for function pci_intx
> > Info: ../drivers/pci/pci.c:4310 Scanning doc for function pci_wait_for_pending_transaction
> > Info: ../drivers/pci/pci.c:4326 Scanning doc for function pcie_flr
> > Info: ../drivers/pci/pci.c:4366 Scanning doc for function pcie_reset_flr
> > Info: ../drivers/pci/pci.c:4443 Scanning doc for function pci_pm_reset
> > Info: ../drivers/pci/pci.c:4497 Scanning doc for function pcie_wait_for_link_status
> > Info: ../drivers/pci/pci.c:4527 Scanning doc for function pcie_retrain_link
> > Info: ../drivers/pci/pci.c:4592 Scanning doc for function pcie_wait_for_link_delay
> > Info: ../drivers/pci/pci.c:4642 Scanning doc for function pcie_wait_for_link
> > Info: ../drivers/pci/pci.c:4679 Scanning doc for function pci_bridge_wait_for_secondary_bus
> > Info: ../drivers/pci/pci.c:4818 Scanning doc for function pci_bridge_secondary_bus_reset
> > Info: ../drivers/pci/pci.c:5077 Scanning doc for function __pci_reset_function_locked
> > Info: ../drivers/pci/pci.c:5135 Scanning doc for function pci_init_reset_methods
> > Info: ../drivers/pci/pci.c:5167 Scanning doc for function pci_reset_function
> > Info: ../drivers/pci/pci.c:5214 Scanning doc for function pci_reset_function_locked
> > Info: ../drivers/pci/pci.c:5252 Scanning doc for function pci_try_reset_function
>
> >> Of course, I can remove KBUILD_VERBOSE from my environment, I'm not
> >> entirely sure when or why I added it.
> >>
> >> Would think it would make sense to update the kdoc_files.py script to
> >> check and interpret the string value the same way the perl script used
> >> to? It seems reasonable to me that users might set "V=0" thinking that
> >> it disables the verbosity. Other verbosity checks are based on the
> >> string containing a 1,
> >
> > kernel-doc has a set of "-W" flags to control its verbosity. Direct
> > support for KBUILD_VERBOSE was added there just to make it bug-compatible
> > with kernel-doc.pl when building via Makefile.
> >
>
> Right.
>
> > Yet, as using it via "make htmldocs" don't use "-W", IMO it makes
> > sense to ensure that "-Wall" is enabled if V=1.
> >
>
> We enable -Wall if KBUILD_EXTRA_WARN contains a 2:
>
> ifeq ($(KBUILD_EXTMOD),)
> ifneq ($(KBUILD_EXTRA_WARN),)
> cmd_checkdoc = PYTHONDONTWRITEBYTECODE=1 $(PYTHON3) $(KERNELDOC) -none
> $(KDOCFLAGS) \
> $(if $(findstring 2, $(KBUILD_EXTRA_WARN)), -Wall) \
> $<
> endif
> endif
>
> If KBUILD_EXTRA_WARN has 2 we do -Wall, and if its any non-zero value we
> enable checkdoc. KBUILD_VERBOSE is handled internally to the script so
> not part of the Make invocation.
>
> So V=0 only manifests if KBUILD_EXTRA_WARN is set.
>
> We set KBUILD_EXTRA_WARN in top level:
>
> ifeq ("$(origin W)", "command line")
> KBUILD_EXTRA_WARN := $(W)
> endif
>
> export KBUILD_EXTRA_WARN
Good point.
>
> >> (some even use 2 for even more printing).
> >
> > Documentation had support for V=2, but this was dropped on this
> > commit:
> > c0d3b83100c8 ("kbuild: do not print extra logs for V=2")
> >
>
> Looks like there's some stale leftover bits then:
>
> #
> # If KBUILD_VERBOSE contains 1, the whole command is echoed.
> # If KBUILD_VERBOSE contains 2, the reason for rebuilding is printed.
> #
> # To put more focus on warnings, be less verbose as default
> # Use 'make V=1' to see the full commands
> I don't have strong opinions either way.
>
>
> >> I'm not entirely sure what the best implementation for python is to
> >> avoid this misinterpretation, so I haven't drafted a proper patch yet.
> >
> > Perhaps something like the patch below (untested).
> >
>
> The patch seems reasonable, though I don't know about the enabling other
> errors, as those are controlled by W=2 right now. I don't personally
> have objections to enabling them with V as well, but others might?
As W=2 already turns those, I opted to just apply the fix
for KBUILD_VERBOSE without touching -W macros:
https://lore.kernel.org/linux-doc/7a99788db75630fb14828d612c0fd77c45ec1891.1774591065.git.mchehab+huawei@kernel.org/T/#u
On a very quick test with:
$ make W=2 V=0 drivers/pci/
and with:
$ KBUILD_VERBOSE="asdf" ./scripts/kernel-doc drivers/pci/ -none
$ KBUILD_VERBOSE="" ./scripts/kernel-doc drivers/pci/ -none
$ KBUILD_VERBOSE="0" ./scripts/kernel-doc drivers/pci/ -none
$ KBUILD_VERBOSE=0 ./scripts/kernel-doc drivers/pci/ -none
None of the above enabled verbosity.
Using either one of the above:
$ KBUILD_VERBOSE=1 ./scripts/kernel-doc drivers/pci/ -none
$ KBUILD_VERBOSE="1" ./scripts/kernel-doc drivers/pci/ -none
made it verbose.
So, I guess this should be enough to fix the issue. Please test
and reply to the patch if it works or not for you.
Thanks,
Mauro
^ permalink raw reply
* [PATCH] doc tools: better handle KBUILD_VERBOSE
From: Mauro Carvalho Chehab @ 2026-03-27 5:57 UTC (permalink / raw)
To: Jonathan Corbet, Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, linux-kernel, Jacob Keller,
Mauro Carvalho Chehab, Randy Dunlap, Shuah Khan
As reported by Jacob, there are troubles when KBUILD_VERBOSE is
set at the environment.
Fix it on both kernel-doc and sphinx-build-wrapper.
Reported-by: Jacob Keller <jacob.e.keller@intel.com>
Closes: https://lore.kernel.org/linux-doc/9367d899-53af-4d9c-9320-22fc4dbadca5@intel.com/
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
tools/docs/sphinx-build-wrapper | 7 ++++++-
tools/lib/python/kdoc/kdoc_files.py | 7 ++++++-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/tools/docs/sphinx-build-wrapper b/tools/docs/sphinx-build-wrapper
index 2c63d28f639d..1bb962202784 100755
--- a/tools/docs/sphinx-build-wrapper
+++ b/tools/docs/sphinx-build-wrapper
@@ -238,7 +238,12 @@ class SphinxBuilder:
self.latexopts = os.environ.get("LATEXOPTS", "")
if not verbose:
- verbose = bool(os.environ.get("KBUILD_VERBOSE", "") != "")
+ try:
+ verbose = bool(int(os.environ.get("KBUILD_VERBOSE", 0)))
+ except ValueError:
+ # Handles an eventual case where verbosity is not a number
+ # like KBUILD_VERBOSE=""
+ verbose = False
if verbose is not None:
self.verbose = verbose
diff --git a/tools/lib/python/kdoc/kdoc_files.py b/tools/lib/python/kdoc/kdoc_files.py
index 2428cfc4e843..ed82b6e6ab25 100644
--- a/tools/lib/python/kdoc/kdoc_files.py
+++ b/tools/lib/python/kdoc/kdoc_files.py
@@ -238,7 +238,12 @@ class KernelFiles():
"""
if not verbose:
- verbose = bool(os.environ.get("KBUILD_VERBOSE", 0))
+ try:
+ verbose = bool(int(os.environ.get("KBUILD_VERBOSE", 0)))
+ except ValueError:
+ # Handles an eventual case where verbosity is not a number
+ # like KBUILD_VERBOSE=""
+ verbose = False
if out_style is None:
out_style = OutputFormat()
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v1 1/6] hwmon/misc: amd-sbi: Move core SBTSI support from hwmon to misc
From: Guenter Roeck @ 2026-03-27 5:52 UTC (permalink / raw)
To: Gupta, Akshay, linux-kernel@vger.kernel.org
Cc: corbet@lwn.net, skhan@linuxfoundation.org, arnd@arndb.de,
gregkh@linuxfoundation.org, L k, Prathima,
Chatradhi, Naveen Krishna, Umarji, Anand,
linux-doc@vger.kernel.org, linux-hwmon@vger.kernel.org,
kunyi@google.com
In-Reply-To: <9e05e255-6245-415c-8c74-ee4f1809976c@amd.com>
On 3/26/26 22:07, Gupta, Akshay wrote:
>
> On 3/24/2026 5:03 PM, Guenter Roeck wrote:
>> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>>
>>
>> On 3/24/26 03:36, Gupta, Akshay wrote:
>>> On 3/23/2026 7:45 PM, Guenter Roeck wrote:
>>>> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>>>>
>>>>
>>>> On 3/23/26 04:08, Akshay Gupta wrote:
>>>>> From: Prathima <Prathima.Lk@amd.com>
>>>>>
>>>>> Move SBTSI core functionality out of the hwmon-only path and into
>>>>> drivers/misc/amd-sbi so it can be reused by non-hwmon consumers.
>>>>>
>>>>> This split prepares the driver for additional interfaces while keeping
>>>>> hwmon support as an optional layer on top of common SBTSI core logic.
>>>>>
>>>> This moves the driver out of hwmon space into misc/amd-sbi which,
>>>> in my opinion, is completely unnecessary to accomplish the stated goals.
>>>>
>>>> I assume this is to be able to make changes which do not follow
>>>> the hwmon ABI and/or to bypass hwmon subsystem review, similar
>>>> to what has been done by others.
>>>>
>>>> Obviously, I think this is a bad idea. I won't give it a NACK,
>>>> but I won't approve (nor review) it either.
>>>>
>>>> Guenter
>>> Hi Guenter,
>>>
>>> Thank you for your quick response.
>>>
>>> At present, TSI supports a range of functionalities that cannot be exposed through hwmon. Additionally, a new protocol leveraging the TSI endpoint in hardware has been introduced, which, to our understanding, cannot be accommodated within the hwmon subsystem.
>>>
>>> Since we already support the RMI interface via misc/amd-sbi, we believe this remains the appropriate place to continue AMD's out-of-band support.
>>>
>>> I will update the commit message and cover letter to clearly articulate the rationale behind this change.
>>>
>>> Thank you
>>>
>> That is neither a reason or an argument for moving _hwmon_ part of the code
>> out of the hwmon subsystem.
> Following feedback from the Greg and MFD subsystem maintainers, we introduced an sb-rmi driver under misc/ that calls devm_hwmon_device_register_with_info(). We are considering the same approach for the sb-tsi driver. Would you recommend a more suitable alternative?
I would have suggested to use an auxiliary driver, similar to PECI,
but who am I to argue if senior maintainers suggest otherwise.
Guenter
^ permalink raw reply
* Re: [PATCH v1 1/6] hwmon/misc: amd-sbi: Move core SBTSI support from hwmon to misc
From: Gupta, Akshay @ 2026-03-27 5:07 UTC (permalink / raw)
To: Guenter Roeck, linux-kernel@vger.kernel.org
Cc: corbet@lwn.net, skhan@linuxfoundation.org, arnd@arndb.de,
gregkh@linuxfoundation.org, L k, Prathima,
Chatradhi, Naveen Krishna, Umarji, Anand,
linux-doc@vger.kernel.org, linux-hwmon@vger.kernel.org,
kunyi@google.com
In-Reply-To: <91e527b8-f753-411b-bdf5-7439edb48c34@roeck-us.net>
On 3/24/2026 5:03 PM, Guenter Roeck wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>
>
> On 3/24/26 03:36, Gupta, Akshay wrote:
>> On 3/23/2026 7:45 PM, Guenter Roeck wrote:
>>> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>>>
>>>
>>> On 3/23/26 04:08, Akshay Gupta wrote:
>>>> From: Prathima <Prathima.Lk@amd.com>
>>>>
>>>> Move SBTSI core functionality out of the hwmon-only path and into
>>>> drivers/misc/amd-sbi so it can be reused by non-hwmon consumers.
>>>>
>>>> This split prepares the driver for additional interfaces while keeping
>>>> hwmon support as an optional layer on top of common SBTSI core logic.
>>>>
>>> This moves the driver out of hwmon space into misc/amd-sbi which,
>>> in my opinion, is completely unnecessary to accomplish the stated goals.
>>>
>>> I assume this is to be able to make changes which do not follow
>>> the hwmon ABI and/or to bypass hwmon subsystem review, similar
>>> to what has been done by others.
>>>
>>> Obviously, I think this is a bad idea. I won't give it a NACK,
>>> but I won't approve (nor review) it either.
>>>
>>> Guenter
>> Hi Guenter,
>>
>> Thank you for your quick response.
>>
>> At present, TSI supports a range of functionalities that cannot be exposed through hwmon. Additionally, a new protocol leveraging the TSI endpoint in hardware has been introduced, which, to our understanding, cannot be accommodated within the hwmon subsystem.
>>
>> Since we already support the RMI interface via misc/amd-sbi, we believe this remains the appropriate place to continue AMD's out-of-band support.
>>
>> I will update the commit message and cover letter to clearly articulate the rationale behind this change.
>>
>> Thank you
>>
> That is neither a reason or an argument for moving _hwmon_ part of the code
> out of the hwmon subsystem.
Following feedback from the Greg and MFD subsystem maintainers, we
introduced an sb-rmi driver under misc/ that calls
devm_hwmon_device_register_with_info(). We are considering the same
approach for the sb-tsi driver. Would you recommend a more suitable
alternative?
>
> FWIW, your patch series removes a lot of error handling code. Sashiko has
> a field day with it.
>
> Guenter
Thank you for the feedback. I will review and address this in the next
version.
>
^ permalink raw reply
* Re: Re: [PATCH v5 2/3] RISC-V: KVM: Detect and expose supported HGATP G-stage modes
From: fangyu.yu @ 2026-03-27 1:55 UTC (permalink / raw)
To: anup
Cc: alex, andrew.jones, aou, atish.patra, corbet, fangyu.yu, guoren,
kvm-riscv, kvm, linux-doc, linux-kernel, linux-riscv, palmer,
pbonzini, pjw, radim.krcmar
In-Reply-To: <CAAhSdy2uMY+-9W34G3QJ3m9XWg2dq_PeNB_9j9B3viZaRg=SUQ@mail.gmail.com>
>> From: Fangyu Yu <fangyu.yu@linux.alibaba.com>
>>
>> Extend kvm_riscv_gstage_mode_detect() to probe all HGATP.MODE values
>> supported by the host and record them in a bitmask. Keep tracking the
>> maximum supported G-stage page table level for existing internal users.
>>
>> Also provide lightweight helpers to retrieve the supported-mode bitmask
>> and validate a requested HGATP.MODE against it.
>>
>> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com>
>> ---
>> arch/riscv/include/asm/kvm_gstage.h | 11 ++++++++
>> arch/riscv/kvm/gstage.c | 43 +++++++++++++++--------------
>> 2 files changed, 34 insertions(+), 20 deletions(-)
>>
>> diff --git a/arch/riscv/include/asm/kvm_gstage.h b/arch/riscv/include/asm/kvm_gstage.h
>> index b12605fbca44..76c37b5dc02d 100644
>> --- a/arch/riscv/include/asm/kvm_gstage.h
>> +++ b/arch/riscv/include/asm/kvm_gstage.h
>> @@ -30,6 +30,7 @@ struct kvm_gstage_mapping {
>> #endif
>>
>> extern unsigned long kvm_riscv_gstage_max_pgd_levels;
>> +extern u32 kvm_riscv_gstage_mode_mask;
>
>s/u32/unsigned long/
>s/kvm_riscv_gstage_mode_mask/kvm_riscv_gstage_supported_mode_mask/
>
Ack, will switch the type to unsigned long and rename it to
kvm_riscv_gstage_supported_mode_mask in the next revision.
>>
>> #define kvm_riscv_gstage_pgd_xbits 2
>> #define kvm_riscv_gstage_pgd_size (1UL << (HGATP_PAGE_SHIFT + kvm_riscv_gstage_pgd_xbits))
>> @@ -75,4 +76,14 @@ void kvm_riscv_gstage_wp_range(struct kvm_gstage *gstage, gpa_t start, gpa_t end
>>
>> void kvm_riscv_gstage_mode_detect(void);
>>
>> +static inline u32 kvm_riscv_get_hgatp_mode_mask(void)
>> +{
>> + return kvm_riscv_gstage_mode_mask;
>> +}
>> +
>> +static inline bool kvm_riscv_hgatp_mode_is_valid(unsigned long mode)
>> +{
>> + return kvm_riscv_gstage_mode_mask & BIT(mode);
>> +}
>> +
>> #endif
>> diff --git a/arch/riscv/kvm/gstage.c b/arch/riscv/kvm/gstage.c
>> index 2d0045f502d1..328d4138f162 100644
>> --- a/arch/riscv/kvm/gstage.c
>> +++ b/arch/riscv/kvm/gstage.c
>> @@ -16,6 +16,8 @@ unsigned long kvm_riscv_gstage_max_pgd_levels __ro_after_init = 3;
>> #else
>> unsigned long kvm_riscv_gstage_max_pgd_levels __ro_after_init = 2;
>> #endif
>> +/* Bitmask of supported HGATP.MODE encodings (BIT(HGATP_MODE_*)). */
>> +u32 kvm_riscv_gstage_mode_mask __ro_after_init;
>>
>> #define gstage_pte_leaf(__ptep) \
>> (pte_val(*(__ptep)) & (_PAGE_READ | _PAGE_WRITE | _PAGE_EXEC))
>> @@ -315,42 +317,43 @@ void kvm_riscv_gstage_wp_range(struct kvm_gstage *gstage, gpa_t start, gpa_t end
>> }
>> }
>>
>> +static bool __init kvm_riscv_hgatp_mode_supported(unsigned long mode)
>> +{
>> + csr_write(CSR_HGATP, mode << HGATP_MODE_SHIFT);
>> + return ((csr_read(CSR_HGATP) >> HGATP_MODE_SHIFT) == mode);
>> +}
>> +
>> void __init kvm_riscv_gstage_mode_detect(void)
>> {
>> + kvm_riscv_gstage_mode_mask = 0;
>> + kvm_riscv_gstage_max_pgd_levels = 0;
>> +
>> #ifdef CONFIG_64BIT
>> - /* Try Sv57x4 G-stage mode */
>> - csr_write(CSR_HGATP, HGATP_MODE_SV57X4 << HGATP_MODE_SHIFT);
>> - if ((csr_read(CSR_HGATP) >> HGATP_MODE_SHIFT) == HGATP_MODE_SV57X4) {
>> - kvm_riscv_gstage_max_pgd_levels = 5;
>> - goto done;
>> + /* Try Sv39x4 G-stage mode */
>> + if (kvm_riscv_hgatp_mode_supported(HGATP_MODE_SV39X4)) {
>> + kvm_riscv_gstage_mode_mask |= BIT(HGATP_MODE_SV39X4);
>> + kvm_riscv_gstage_max_pgd_levels = 3;
>> }
>>
>> /* Try Sv48x4 G-stage mode */
>> - csr_write(CSR_HGATP, HGATP_MODE_SV48X4 << HGATP_MODE_SHIFT);
>> - if ((csr_read(CSR_HGATP) >> HGATP_MODE_SHIFT) == HGATP_MODE_SV48X4) {
>> + if (kvm_riscv_hgatp_mode_supported(HGATP_MODE_SV48X4)) {
>> + kvm_riscv_gstage_mode_mask |= BIT(HGATP_MODE_SV48X4);
>> kvm_riscv_gstage_max_pgd_levels = 4;
>> - goto done;
>> }
>>
>> - /* Try Sv39x4 G-stage mode */
>> - csr_write(CSR_HGATP, HGATP_MODE_SV39X4 << HGATP_MODE_SHIFT);
>> - if ((csr_read(CSR_HGATP) >> HGATP_MODE_SHIFT) == HGATP_MODE_SV39X4) {
>> - kvm_riscv_gstage_max_pgd_levels = 3;
>> - goto done;
>> + /* Try Sv57x4 G-stage mode */
>> + if (kvm_riscv_hgatp_mode_supported(HGATP_MODE_SV57X4)) {
>> + kvm_riscv_gstage_mode_mask |= BIT(HGATP_MODE_SV57X4);
>> + kvm_riscv_gstage_max_pgd_levels = 5;
>> }
>> #else /* CONFIG_32BIT */
>> /* Try Sv32x4 G-stage mode */
>> - csr_write(CSR_HGATP, HGATP_MODE_SV32X4 << HGATP_MODE_SHIFT);
>> - if ((csr_read(CSR_HGATP) >> HGATP_MODE_SHIFT) == HGATP_MODE_SV32X4) {
>> + if (kvm_riscv_hgatp_mode_supported(HGATP_MODE_SV32X4)) {
>> + kvm_riscv_gstage_mode_mask |= BIT(HGATP_MODE_SV32X4);
>> kvm_riscv_gstage_max_pgd_levels = 2;
>> - goto done;
>> }
>> #endif
>>
>> - /* KVM depends on !HGATP_MODE_OFF */
>> - kvm_riscv_gstage_max_pgd_levels = 0;
>> -
>> -done:
>
>Here are some statements from RISC-V privilege specification:
>"Implementations that support Sv48 must also support Sv39."
>"Implementations that support Sv57 must also support Sv48."
>"The conversion of an Sv32x4, Sv39x4, Sv48x4, or Sv57x4 guest physical
>address is accomplished with the
>same algorithm used for Sv32, Sv39, Sv48, or Sv57, as presented in
>Section 12.3.2, except that:"
>"hgatp substitutes for the usual satp;"
>
>Based on above it is a waste to try each and every mode.
>For example: if mode Sv48x4 is supported then Sv39x4 is also supported.
>
Radmi and I discussed this topic before; please refer to the following link:
https://lore.kernel.org/linux-riscv/20260131061238.52708-1-fangyu.yu@linux.alibaba.com/
>Regards,
>Anup
Thanks,
Fangyu
^ permalink raw reply
* Re: Re: [PATCH v5 1/3] RISC-V: KVM: Support runtime configuration for per-VM's HGATP mode
From: fangyu.yu @ 2026-03-27 1:55 UTC (permalink / raw)
To: anup
Cc: alex, andrew.jones, aou, atish.patra, corbet, fangyu.yu, guoren,
kvm-riscv, kvm, linux-doc, linux-kernel, linux-riscv, palmer,
pbonzini, pjw, radim.krcmar
In-Reply-To: <CAAhSdy059XmTckHrX8xjk44pR=1BkaUuPQ-Cf+4BRTBoigBZ+g@mail.gmail.com>
>> diff --git a/arch/riscv/kvm/vmid.c b/arch/riscv/kvm/vmid.c
>> index cf34d448289d..c15bdb1dd8be 100644
>> --- a/arch/riscv/kvm/vmid.c
>> +++ b/arch/riscv/kvm/vmid.c
>> @@ -26,7 +26,8 @@ static DEFINE_SPINLOCK(vmid_lock);
>> void __init kvm_riscv_gstage_vmid_detect(void)
>> {
>> /* Figure-out number of VMID bits in HW */
>> - csr_write(CSR_HGATP, (kvm_riscv_gstage_mode << HGATP_MODE_SHIFT) | HGATP_VMID);
>> + csr_write(CSR_HGATP, (kvm_riscv_gstage_mode(kvm_riscv_gstage_max_pgd_levels) <<
>> + HGATP_MODE_SHIFT) | HGATP_VMID);
>> vmid_bits = csr_read(CSR_HGATP);
>> vmid_bits = (vmid_bits & HGATP_VMID) >> HGATP_VMID_SHIFT;
>> vmid_bits = fls_long(vmid_bits);
>> --
>> 2.50.1
>>
>>
>
>Regards,
>Anup
Hi Anup:
Thanks for the review.
I'll incorporate all of the above changes and post an updated version (v6) shortly.
Thanks,
Fangyu
^ permalink raw reply
* Re: [PATCH net-next v2] docs/mlx5: Fix typo subfuction
From: patchwork-bot+netdevbpf @ 2026-03-27 1:40 UTC (permalink / raw)
To: Ryohei Kinugawa
Cc: rrameshbabu, saeedm, leon, tariqt, mbloch, davem, edumazet, kuba,
pabeni, horms, corbet, skhan, netdev, linux-rdma, linux-doc, joe
In-Reply-To: <20260324053416.70166-1-ryohei.kinugawa@gmail.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 24 Mar 2026 14:34:10 +0900 you wrote:
> Fix two typos:
> - 'Subfunctons' -> 'Subfunctions'
> - 'subfuction' -> 'subfunction'
>
> Reviewed-by: Joe Damato <joe@dama.to>
> Signed-off-by: Ryohei Kinugawa <ryohei.kinugawa@gmail.com>
>
> [...]
Here is the summary with links:
- [net-next,v2] docs/mlx5: Fix typo subfuction
https://git.kernel.org/netdev/net-next/c/ed8edcd47529
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH V9 3/8] dax: add fsdev.c driver for fs-dax on character dax
From: John Groves @ 2026-03-27 0:56 UTC (permalink / raw)
To: Ira Weiny
Cc: Jonathan Cameron, John Groves, Miklos Szeredi, Dan Williams,
Bernd Schubert, Alison Schofield, John Groves, Jonathan Corbet,
Shuah Khan, Vishal Verma, Dave Jiang, Matthew Wilcox, Jan Kara,
Alexander Viro, David Hildenbrand, Christian Brauner,
Darrick J . Wong, Randy Dunlap, Jeff Layton, Amir Goldstein,
Stefan Hajnoczi, Joanne Koong, Josef Bacik, Bagas Sanjaya,
Chen Linxuan, James Morse, Fuad Tabba, Sean Christopherson,
Shivank Garg, Ackerley Tng, Gregory Price, Aravind Ramesh,
Ajay Joshi, venkataravis@micron.com, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, nvdimm@lists.linux.dev,
linux-cxl@vger.kernel.org, linux-fsdevel@vger.kernel.org
In-Reply-To: <69c5b7411999c_14003310089@iweiny-mobl.notmuch>
On 26/03/26 05:46PM, Ira Weiny wrote:
> John Groves wrote:
> > On 26/03/25 11:04AM, Ira Weiny wrote:
> > > John Groves wrote:
> > > > On 26/03/24 02:39PM, Jonathan Cameron wrote:
> > > > > On Tue, 24 Mar 2026 00:38:31 +0000
> > > > > John Groves <john@jagalactic.com> wrote:
> > > > >
> > > > > > From: John Groves <john@groves.net>
> > > > > >
> > > > > > The new fsdev driver provides pages/folios initialized compatibly with
> > > > > > fsdax - normal rather than devdax-style refcounting, and starting out
> > > > > > with order-0 folios.
> > > > > >
> > > > > > When fsdev binds to a daxdev, it is usually (always?) switching from the
> > > > > > devdax mode (device.c), which pre-initializes compound folios according
> > > > > > to its alignment. Fsdev uses fsdev_clear_folio_state() to switch the
> > > > > > folios into a fsdax-compatible state.
> > > > > >
> > > > > > A side effect of this is that raw mmap doesn't (can't?) work on an fsdev
> > > > > > dax instance. Accordingly, The fsdev driver does not provide raw mmap -
> > > > > > devices must be put in 'devdax' mode (drivers/dax/device.c) to get raw
> > > > > > mmap capability.
> > > > > >
> > > > > > In this commit is just the framework, which remaps pages/folios compatibly
> > > > > > with fsdax.
> > > > > >
> > > > > > Enabling dax changes:
> > > > > >
> > > > > > - bus.h: add DAXDRV_FSDEV_TYPE driver type
> > > > > > - bus.c: allow DAXDRV_FSDEV_TYPE drivers to bind to daxdevs
> > > > > > - dax.h: prototype inode_dax(), which fsdev needs
> > > > > >
> > > > > > Suggested-by: Dan Williams <dan.j.williams@intel.com>
> > > > > > Suggested-by: Gregory Price <gourry@gourry.net>
> > > > > > Signed-off-by: John Groves <john@groves.net>
> > > > >
> > > > > I was kind of thinking you'd go with a hidden KCONFIG option with default
> > > > > magic to do the same build condition to you had in the Makefil, but one the
> > > > > user can opt in or out for is also fine.
> > > > >
> > > > > Comments on that below. Meh, I think this is better anyway :)
> > > > >
> > > > > Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> > > > >
> > > > >
> > > > >
> > > > > > diff --git a/drivers/dax/Kconfig b/drivers/dax/Kconfig
> > > > > > index d656e4c0eb84..7051b70980d5 100644
> > > > > > --- a/drivers/dax/Kconfig
> > > > > > +++ b/drivers/dax/Kconfig
> > > > > > @@ -61,6 +61,17 @@ config DEV_DAX_HMEM_DEVICES
> > > > > > depends on DEV_DAX_HMEM && DAX
> > > > > > def_bool y
> > > > > >
> > > > > > +config DEV_DAX_FSDEV
> > > > > > + tristate "FSDEV DAX: fs-dax compatible devdax driver"
> > > > > > + depends on DEV_DAX && FS_DAX
> > > > > > + help
> > > > > > + Support fs-dax access to DAX devices via a character device
> > > > > > + interface. Unlike device_dax (which pre-initializes compound folios
> > > > > > + based on device alignment), this driver leaves folios at order-0 so
> > > > > > + that fs-dax filesystems can manage folio order dynamically.
> > > > > > +
> > > > > > + Say M if unsure.
> > > > > Fine like this, but if you wanted to hide it in interests of not
> > > > > confusing users...
> > > > >
> > > > > config DEV_DAX_FSDEV
> > > > > tristate
> > > > > depends on DEV_DAX && FS_DAX
> > > > > default DEV_DAX
> > > >
> > > > I like this better. I see no reason not to default to including fsdev.
> > > > It does nothing other than frustrating famfs users if it's off - since
> > > > building it still has no effect unless you put a daxdev in famfs mode.
> > > >
> > > > Ira, it's kinda in your hands at the moment. Do you feel like making this
> > > > change?
> > >
> > > I don't mind making this change. But we have to deal with the breakage to
> > > current device dax users.
> > >
> > > https://lore.kernel.org/all/69c36921255b6_e9d8d1009b@iweiny-mobl.notmuch/
> > >
> > > What am I missing?
> > >
> > > Ira
> >
> > OK, I can reproduce that failure with kernel 7.0.0-rc5 and
> > straight ndctl v84. So it's not famfs.
>
> No it is the fsdev_dax driver which causes the issue.
>
> I can reload the driver and effectively change the order the drivers are
> searched.
>
> I can prove this with a simple print. With my test system (where
> fsdev_dax _happens_ to be the first driver searched) the failure happens.
>
> [ 526.564232] IKW searching drv type 0 ; type 1
> [ 526.564515] IKW searching drv type 2 ; type 1
>
> If I remove your driver (modprobe -r fsdev_dax) prior to running the test
> I get.
>
> [ 59.748171] IKW searching drv type 0 ; type 1
> [ 59.749127] IKW searching drv type 1 ; type 1
>
> And it passes. I can continue by loading fsdev_dax back and it will
> continue to work. If you are getting this to pass it must be because in
> your system that driver gets loaded first... not sure how.
>
> This is with the same exact kernel just with your module removed at run
> time.
>
> dax_match_type() needs some other way of matching when the fsdev_dax
> driver should be used.
I think the correct answer is that fsdev/famfs should never automatically
match and bind. Weird that I haven't seen it do that (or maybe it did but
I didn't notice?)
If one does a mkfs.famfs or 'famfs mount', the famfs tools already try to
bind fsdev/famfs mode if necessary and fail if they can't.
>
> I'm not seeing a clear path ATM.
I do, but I need to test it out. If it works I'll send a v10 patch set
in a day or two.
Also, I am definitely seeing ndctl/dax test failures from the device-dax
and dm.sh tests at rc5 with no famfs code (dax or otherwise) at all; I'm
puzzled that you don't see any ndctl test failures in that situation. If
I understood Allison correctly, she saw something similar to what I saw).
But no worries, we'll get it sorted.
If my strategy works, the next version won't ever automatically bind fsdev,
but it will be explicitly bindable via daxctl or famfs tools. Famfs does not
need fsdev to ever be automatically bound do dax mem...
>
> >
> > I also studied the verbose logs trying to figure out if famfs
> > could cause it (while running a famfs kernel and ndctl), but
> > I don't see it.
> >
> > Then I tried non-famfs kernel and ndctl and it's the same with
> > or without famfs kernel and famfs ndctl.
>
> :-/ I'm not seeing any failures with rc5.
>
> Also I'm not running with famfs. Just the dax changes.
Right - if fsdev ever gets automatically bound instead of
drivers/dax/device.c, that's my bad. Weird that I haven't seen that happen,
but that's why we review and test :D
>
> Ira
Thank you,
John
^ permalink raw reply
* Re: [PATCH] docs: Document pahole v1.26 requirement for KF_IMPLICIT_ARGS kfuncs
From: Tejun Heo @ 2026-03-27 0:28 UTC (permalink / raw)
To: Ihor Solodrai
Cc: zhidao su, Alexei Starovoitov, Jonathan Corbet, linux-doc,
linux-kernel, sched-ext, bpf
In-Reply-To: <e0ca748d-3204-4160-b37d-0f76cbac8c6c@linux.dev>
On Thu, Mar 26, 2026 at 03:06:28PM -0700, Ihor Solodrai wrote:
> On 3/24/26 11:46 AM, zhidao su wrote:
> > On Tue, 24 Mar 2026 08:12:12 -0700, Alexei Starovoitov wrote:
> >> I don't think that's true.
> >> At least when implicit args were designed the goal was to avoid
> >> pahole dependencies.
> >> Please share exact steps to reproduce.
> >
> > Here are the exact reproduction steps and code path analysis.
>
> Hi everyone, sorry I'm late to the party.
>
> First of all, a *Nack* to the doc change in isolation, I agree with
> Alexei here. Tejun, I suggest to revert it.
Ah, right, this isn't sched_ext proper even. Sorry about that. Reverting.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 0/4] hwmon: Add WITRN USB tester driver
From: Guenter Roeck @ 2026-03-27 0:05 UTC (permalink / raw)
To: Rong Zhang, Jonathan Corbet, Shuah Khan
Cc: linux-hwmon, linux-kernel, linux-doc
In-Reply-To: <20260327-b4-hwmon-witrn-v1-0-8d2f1896c045@rong.moe>
On 3/26/26 12:19, Rong Zhang wrote:
> WITRN produces a series of devices to monitor power characteristics of
> USB connections and display those on a on-device display. Most of them
> contain an additional port which exposes the measurements via USB HID.
>
> These devices report sensor values in IEEE-754 float (binary32) format.
> The driver must perform floating-point number to integer conversions to
> provide hwmon channels. Meanwhile, they also report accumulative float
> values, and simple division or multiplication turns them into useful
> hwmon channels.
>
> Patch 1 adds label support for 64-bit energy attributes, as the driver
> needs it.
>
> Patch 2 adds a helper module for floating-point to integer conversions,
> so that the conversion, multification and division methods can be used
> in this driver as well as other drivers (I am also working on another
> USB tester driver that needs it).
>
> Patch 3 adds a barebone HID driver for WITRN K2.
>
> Patch 4 adds hwmon channels and attributes to the driver.
>
> Signed-off-by: Rong Zhang <i@rong.moe>
> ---
> Rong Zhang (4):
> hwmon: Add label support for 64-bit energy attributes
> hwmon: New helper module for floating-point to integer conversions
Nack. This is not a hwmon problem and should reside in a driver or in lib/
(if it is needed by multiple drivers).
> hwmon: Add barebone HID driver for WITRN
Nack. This is the wrong place for such a driver. It should reside somewhere
in drivers/usb, or maybe in drivers/misc/.
> hwmon: (witrn) Add monitoring support
This should be implemented as auxiliary driver.
Sashiko has a lot of feedback that you might want to address before
resubmitting.
https://sashiko.dev/#/patchset/20260327-b4-hwmon-witrn-v1-0-8d2f1896c045%40rong.moe
Thanks,
Guenter
>
> Documentation/hwmon/index.rst | 1 +
> Documentation/hwmon/witrn.rst | 53 ++++
> MAINTAINERS | 7 +
> drivers/hwmon/Kconfig | 14 +
> drivers/hwmon/Makefile | 2 +
> drivers/hwmon/hwmon-fp.c | 262 ++++++++++++++++
> drivers/hwmon/hwmon-fp.h | 212 +++++++++++++
> drivers/hwmon/hwmon.c | 1 +
> drivers/hwmon/witrn.c | 691 ++++++++++++++++++++++++++++++++++++++++++
> 9 files changed, 1243 insertions(+)
> ---
> base-commit: 0138af2472dfdef0d56fc4697416eaa0ff2589bd
> change-id: 20260327-b4-hwmon-witrn-a629b9040250
>
> Thanks,
> Rong
>
^ permalink raw reply
* Re: [PATCH 1/4] hwmon: Add label support for 64-bit energy attributes
From: Guenter Roeck @ 2026-03-26 23:41 UTC (permalink / raw)
To: Rong Zhang
Cc: Jonathan Corbet, Shuah Khan, linux-hwmon, linux-kernel, linux-doc
In-Reply-To: <20260327-b4-hwmon-witrn-v1-1-8d2f1896c045@rong.moe>
On Fri, Mar 27, 2026 at 03:19:50AM +0800, Rong Zhang wrote:
> Since commit 0bcd01f757bc ("hwmon: Introduce 64-bit energy attribute
> support"), devices can report 64-bit energy values by selecting the
> sensor type "energy64". However, such sensors can't report their labels
> since is_string_attr() was not updated to match it.
>
> Add label support for 64-bit energy attributes by updating
> is_string_attr() to match hwmon_energy64 in addition to hwmon_energy.
>
> Signed-off-by: Rong Zhang <i@rong.moe>
Applied.
Thanks,
Guenter
^ permalink raw reply
* [POC PATCH 6/6] KVM: selftests: Test content modes ZERO and PRESERVE for SNP
From: Ackerley Tng @ 2026-03-26 23:36 UTC (permalink / raw)
To: ackerleytng
Cc: aik, akpm, andrew.jones, aneesh.kumar, axelrasmussen, baohua, bhe,
binbin.wu, bp, brauner, chao.p.peng, chrisl, corbet, dave.hansen,
david, forkloop, hpa, ira.weiny, jgg, jmattson, jroedel,
jthoughton, kasong, kvm, linux-doc, linux-kernel, linux-kselftest,
linux-mm, linux-trace-kernel, mathieu.desnoyers, mhiramat,
michael.roth, mingo, nphamcs, oupton, pankaj.gupta, pbonzini,
pratyush, qperret, rick.p.edgecombe, rientjes, rostedt, seanjc,
shikemeng, shivankg, shuah, skhan, steven.price, suzuki.poulose,
tabba, tglx, vannapurve, vbabka, weixugc, willy, wyihan, x86,
yan.y.zhao, yuanchu
In-Reply-To: <cover.1774568083.git.ackerleytng@google.com>
Signed-off-by: Ackerley Tng <ackerleytng@google.com>
---
.../selftests/kvm/x86/sev_smoke_test.c | 47 +++++++++++++++++--
1 file changed, 44 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/kvm/x86/sev_smoke_test.c b/tools/testing/selftests/kvm/x86/sev_smoke_test.c
index c40c359f78901..b076e0afc3077 100644
--- a/tools/testing/selftests/kvm/x86/sev_smoke_test.c
+++ b/tools/testing/selftests/kvm/x86/sev_smoke_test.c
@@ -365,7 +365,26 @@ static void guest_code_conversion(u8 *test_shared_gva, u8 *test_private_gva, u64
vmgexit();
}
-static void test_conversion(uint64_t policy)
+static void vm_set_memory_attributes_expect_error(struct kvm_vm *vm, u64 gpa,
+ size_t size, u64 attributes,
+ u64 flags, int expected_errno)
+{
+ loff_t error_offset = -1;
+ size_t len_ignored;
+ loff_t offset;
+ int gmem_fd;
+ int ret;
+
+ gmem_fd = kvm_gpa_to_guest_memfd(vm, gpa, &offset, &len_ignored);
+ ret = __gmem_set_memory_attributes(gmem_fd, offset, size, attributes,
+ &error_offset, flags);
+
+ TEST_ASSERT_EQ(ret, -1);
+ TEST_ASSERT_EQ(offset, error_offset);
+ TEST_ASSERT_EQ(errno, expected_errno);
+}
+
+static void test_conversion(uint64_t policy, u64 content_mode)
{
vm_vaddr_t test_private_gva;
vm_vaddr_t test_shared_gva;
@@ -409,6 +428,21 @@ static void test_conversion(uint64_t policy)
TEST_ASSERT_EQ(vcpu->run->hypercall.args[1], 1);
TEST_ASSERT_EQ(vcpu->run->hypercall.args[2], KVM_MAP_GPA_RANGE_ENCRYPTED | KVM_MAP_GPA_RANGE_PAGE_SZ_4K);
+ /* ZERO when setting memory attributes to private is always not supported. */
+ vm_set_memory_attributes_expect_error(vm, test_gpa, PAGE_SIZE,
+ KVM_MEMORY_ATTRIBUTE_PRIVATE,
+ KVM_SET_MEMORY_ATTRIBUTES2_ZERO,
+ EOPNOTSUPP);
+
+ /* PRESERVE is not supported for SNP. */
+ vm_set_memory_attributes_expect_error(vm, test_gpa, PAGE_SIZE, 0,
+ KVM_SET_MEMORY_ATTRIBUTES2_PRESERVE,
+ EOPNOTSUPP);
+ vm_set_memory_attributes_expect_error(vm, test_gpa, PAGE_SIZE,
+ KVM_MEMORY_ATTRIBUTE_PRIVATE,
+ KVM_SET_MEMORY_ATTRIBUTES2_PRESERVE,
+ EOPNOTSUPP);
+
vm_mem_set_private(vm, test_gpa, PAGE_SIZE, KVM_SET_MEMORY_ATTRIBUTES2_MODE_UNSPECIFIED);
vcpu_run(vcpu);
@@ -419,7 +453,12 @@ static void test_conversion(uint64_t policy)
TEST_ASSERT_EQ(vcpu->run->hypercall.args[1], 1);
TEST_ASSERT_EQ(vcpu->run->hypercall.args[2], KVM_MAP_GPA_RANGE_DECRYPTED | KVM_MAP_GPA_RANGE_PAGE_SZ_4K);
- vm_mem_set_shared(vm, test_gpa, PAGE_SIZE, KVM_SET_MEMORY_ATTRIBUTES2_MODE_UNSPECIFIED);
+ vm_mem_set_shared(vm, test_gpa, PAGE_SIZE, content_mode);
+
+ if (content_mode == KVM_SET_MEMORY_ATTRIBUTES2_ZERO)
+ TEST_ASSERT_EQ(READ_ONCE(*(u8 *)test_hva), 0);
+ else
+ fprintf(stderr, "test_hva contents = %x\n", READ_ONCE(*(u8 *)test_hva));
vcpu_run(vcpu);
@@ -441,7 +480,9 @@ int main(int argc, char *argv[])
// test_sev_smoke(guest_sev_es_code, KVM_X86_SEV_ES_VM, SEV_POLICY_ES);
if (kvm_cpu_has(X86_FEATURE_SEV_SNP)) {
- test_conversion(snp_default_policy());
+ test_conversion(snp_default_policy(), KVM_SET_MEMORY_ATTRIBUTES2_MODE_UNSPECIFIED);
+ test_conversion(snp_default_policy(), KVM_SET_MEMORY_ATTRIBUTES2_ZERO);
+
// test_sev_smoke(guest_snp_code, KVM_X86_SNP_VM, snp_default_policy());
}
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply related
* [POC PATCH 5/6] KVM: selftests: Test conversions for SNP
From: Ackerley Tng @ 2026-03-26 23:36 UTC (permalink / raw)
To: ackerleytng
Cc: aik, akpm, andrew.jones, aneesh.kumar, axelrasmussen, baohua, bhe,
binbin.wu, bp, brauner, chao.p.peng, chrisl, corbet, dave.hansen,
david, forkloop, hpa, ira.weiny, jgg, jmattson, jroedel,
jthoughton, kasong, kvm, linux-doc, linux-kernel, linux-kselftest,
linux-mm, linux-trace-kernel, mathieu.desnoyers, mhiramat,
michael.roth, mingo, nphamcs, oupton, pankaj.gupta, pbonzini,
pratyush, qperret, rick.p.edgecombe, rientjes, rostedt, seanjc,
shikemeng, shivankg, shuah, skhan, steven.price, suzuki.poulose,
tabba, tglx, vannapurve, vbabka, weixugc, willy, wyihan, x86,
yan.y.zhao, yuanchu
In-Reply-To: <cover.1774568083.git.ackerleytng@google.com>
Signed-off-by: Ackerley Tng <ackerleytng@google.com>
---
.../selftests/kvm/x86/sev_smoke_test.c | 190 +++++++++++++++++-
1 file changed, 185 insertions(+), 5 deletions(-)
diff --git a/tools/testing/selftests/kvm/x86/sev_smoke_test.c b/tools/testing/selftests/kvm/x86/sev_smoke_test.c
index 7e69da01cecf4..c40c359f78901 100644
--- a/tools/testing/selftests/kvm/x86/sev_smoke_test.c
+++ b/tools/testing/selftests/kvm/x86/sev_smoke_test.c
@@ -253,17 +253,197 @@ static void test_sev_smoke(void *guest, uint32_t type, uint64_t policy)
}
}
+#define GHCB_MSR_REG_GPA_REQ 0x012
+#define GHCB_MSR_REG_GPA_REQ_VAL(v) \
+ /* GHCBData[63:12] */ \
+ (((u64)((v) & GENMASK_ULL(51, 0)) << 12) | \
+ /* GHCBData[11:0] */ \
+ GHCB_MSR_REG_GPA_REQ)
+
+#define GHCB_MSR_REG_GPA_RESP 0x013
+#define GHCB_MSR_REG_GPA_RESP_VAL(v) \
+ /* GHCBData[63:12] */ \
+ (((u64)(v) & GENMASK_ULL(63, 12)) >> 12)
+
+#define GHCB_DATA_LOW 12
+#define GHCB_MSR_INFO_MASK (BIT_ULL(GHCB_DATA_LOW) - 1)
+#define GHCB_RESP_CODE(v) ((v) & GHCB_MSR_INFO_MASK)
+
+/*
+ * SNP Page State Change Operation
+ *
+ * GHCBData[55:52] - Page operation:
+ * 0x0001 Page assignment, Private
+ * 0x0002 Page assignment, Shared
+ */
+enum psc_op {
+ SNP_PAGE_STATE_PRIVATE = 1,
+ SNP_PAGE_STATE_SHARED,
+};
+
+#define GHCB_MSR_PSC_REQ 0x014
+#define GHCB_MSR_PSC_REQ_GFN(gfn, op) \
+ /* GHCBData[55:52] */ \
+ (((u64)((op) & 0xf) << 52) | \
+ /* GHCBData[51:12] */ \
+ ((u64)((gfn) & GENMASK_ULL(39, 0)) << 12) | \
+ /* GHCBData[11:0] */ \
+ GHCB_MSR_PSC_REQ)
+
+#define GHCB_MSR_PSC_RESP 0x015
+#define GHCB_MSR_PSC_RESP_VAL(val) \
+ /* GHCBData[63:32] */ \
+ (((u64)(val) & GENMASK_ULL(63, 32)) >> 32)
+
+static u64 ghcb_gpa;
+static void snp_register_ghcb(void)
+{
+ u64 ghcb_pfn = ghcb_gpa >> PAGE_SHIFT;
+ u64 val;
+
+ GUEST_ASSERT(ghcb_gpa);
+
+ wrmsr(MSR_AMD64_SEV_ES_GHCB, GHCB_MSR_REG_GPA_REQ_VAL(ghcb_gpa >> PAGE_SHIFT));
+ vmgexit();
+
+ val = rdmsr(MSR_AMD64_SEV_ES_GHCB);
+ GUEST_ASSERT_EQ(GHCB_RESP_CODE(val), GHCB_MSR_REG_GPA_RESP);
+ GUEST_ASSERT_EQ(GHCB_MSR_REG_GPA_RESP_VAL(val), ghcb_pfn);
+}
+
+static void snp_page_state_change(u64 gpa, enum psc_op op)
+{
+ u64 val;
+
+ wrmsr(MSR_AMD64_SEV_ES_GHCB, GHCB_MSR_PSC_REQ_GFN(gpa >> PAGE_SHIFT, op));
+ vmgexit();
+
+ val = rdmsr(MSR_AMD64_SEV_ES_GHCB);
+ GUEST_ASSERT_EQ(GHCB_RESP_CODE(val), GHCB_MSR_PSC_RESP);
+ GUEST_ASSERT_EQ(GHCB_MSR_PSC_RESP_VAL(val), 0);
+}
+
+#define RMP_PG_SIZE_4K 0
+static inline void pvalidate(void *vaddr, bool validate)
+{
+ bool no_rmpupdate;
+ int rc;
+
+ /* "pvalidate" mnemonic support in binutils 2.36 and newer */
+ asm volatile(".byte 0xF2, 0x0F, 0x01, 0xFF\n\t"
+ : "=@ccc"(no_rmpupdate), "=a"(rc)
+ : "a"(vaddr), "c"(RMP_PG_SIZE_4K), "d"(validate)
+ : "memory", "cc");
+
+ GUEST_ASSERT(!no_rmpupdate);
+ GUEST_ASSERT_EQ(rc, 0);
+}
+
+#define CONVERSION_TEST_VALUE_SHARED_1 0xab
+#define CONVERSION_TEST_VALUE_SHARED_2 0xcd
+#define CONVERSION_TEST_VALUE_PRIVATE 0xef
+#define CONVERSION_TEST_VALUE_SHARED_3 0xbc
+static void guest_code_conversion(u8 *test_shared_gva, u8 *test_private_gva, u64 test_gpa)
+{
+ snp_register_ghcb();
+
+ GUEST_ASSERT_EQ(READ_ONCE(*test_shared_gva), CONVERSION_TEST_VALUE_SHARED_1);
+ WRITE_ONCE(*test_shared_gva, CONVERSION_TEST_VALUE_SHARED_2);
+
+ snp_page_state_change(test_gpa, SNP_PAGE_STATE_PRIVATE);
+ pvalidate(test_private_gva, true);
+
+ WRITE_ONCE(*test_private_gva, CONVERSION_TEST_VALUE_PRIVATE);
+ GUEST_ASSERT_EQ(READ_ONCE(*test_private_gva), CONVERSION_TEST_VALUE_PRIVATE);
+
+ pvalidate(test_private_gva, false);
+ snp_page_state_change(test_gpa, SNP_PAGE_STATE_SHARED);
+
+ WRITE_ONCE(*test_shared_gva, CONVERSION_TEST_VALUE_SHARED_3);
+
+ wrmsr(MSR_AMD64_SEV_ES_GHCB, GHCB_MSR_TERM_REQ);
+ vmgexit();
+}
+
+static void test_conversion(uint64_t policy)
+{
+ vm_vaddr_t test_private_gva;
+ vm_vaddr_t test_shared_gva;
+ struct kvm_vcpu *vcpu;
+ vm_vaddr_t ghcb_gva;
+ vm_paddr_t test_gpa;
+ struct kvm_vm *vm;
+ void *ghcb_hva;
+ void *test_hva;
+
+ vm = vm_sev_create_with_one_vcpu(KVM_X86_SNP_VM, guest_code_conversion, &vcpu);
+
+ ghcb_gva = vm_vaddr_alloc_shared(vm, PAGE_SIZE, KVM_UTIL_MIN_VADDR,
+ MEM_REGION_TEST_DATA);
+ ghcb_hva = addr_gva2hva(vm, ghcb_gva);
+ ghcb_gpa = addr_gva2gpa(vm, ghcb_gva);
+ sync_global_to_guest(vm, ghcb_gpa);
+
+ test_shared_gva = vm_vaddr_alloc_shared(vm, PAGE_SIZE, KVM_UTIL_MIN_VADDR,
+ MEM_REGION_TEST_DATA);
+ test_hva = addr_gva2hva(vm, test_shared_gva);
+ test_gpa = addr_gva2gpa(vm, test_shared_gva);
+
+ test_private_gva = vm_vaddr_unused_gap(vm, PAGE_SIZE, KVM_UTIL_MIN_VADDR);
+ ___virt_pg_map(vm, &vm->mmu, test_private_gva, test_gpa, PG_SIZE_4K, true);
+
+ vcpu_args_set(vcpu, 3, test_shared_gva, test_private_gva, test_gpa);
+
+ vm_sev_launch(vm, policy, NULL);
+
+ WRITE_ONCE(*(u8 *)test_hva, CONVERSION_TEST_VALUE_SHARED_1);
+
+ fprintf(stderr, "ghcb_hva=%p ghcb_gpa=%lx ghcb_gva=%lx\n", ghcb_hva, ghcb_gpa, ghcb_gva);
+ fprintf(stderr, "test_hva=%p test_gpa=%lx test_private_gva=%lx test_shared_gva=%lx\n", test_hva, test_gpa, test_private_gva, test_shared_gva);
+
+ vcpu_run(vcpu);
+
+ TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_HYPERCALL);
+ TEST_ASSERT_EQ(vcpu->run->hypercall.nr, KVM_HC_MAP_GPA_RANGE);
+ TEST_ASSERT_EQ(vcpu->run->hypercall.args[0], test_gpa);
+ TEST_ASSERT_EQ(vcpu->run->hypercall.args[1], 1);
+ TEST_ASSERT_EQ(vcpu->run->hypercall.args[2], KVM_MAP_GPA_RANGE_ENCRYPTED | KVM_MAP_GPA_RANGE_PAGE_SZ_4K);
+
+ vm_mem_set_private(vm, test_gpa, PAGE_SIZE, KVM_SET_MEMORY_ATTRIBUTES2_MODE_UNSPECIFIED);
+
+ vcpu_run(vcpu);
+
+ TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_HYPERCALL);
+ TEST_ASSERT_EQ(vcpu->run->hypercall.nr, KVM_HC_MAP_GPA_RANGE);
+ TEST_ASSERT_EQ(vcpu->run->hypercall.args[0], test_gpa);
+ TEST_ASSERT_EQ(vcpu->run->hypercall.args[1], 1);
+ TEST_ASSERT_EQ(vcpu->run->hypercall.args[2], KVM_MAP_GPA_RANGE_DECRYPTED | KVM_MAP_GPA_RANGE_PAGE_SZ_4K);
+
+ vm_mem_set_shared(vm, test_gpa, PAGE_SIZE, KVM_SET_MEMORY_ATTRIBUTES2_MODE_UNSPECIFIED);
+
+ vcpu_run(vcpu);
+
+ TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_SYSTEM_EVENT);
+ TEST_ASSERT_EQ(vcpu->run->system_event.type, KVM_SYSTEM_EVENT_SEV_TERM);
+ TEST_ASSERT_EQ(vcpu->run->system_event.ndata, 1);
+ TEST_ASSERT_EQ(vcpu->run->system_event.data[0], GHCB_MSR_TERM_REQ);
+
+ TEST_ASSERT_EQ(*(u8 *)test_hva, CONVERSION_TEST_VALUE_SHARED_3);
+}
+
int main(int argc, char *argv[])
{
TEST_REQUIRE(kvm_cpu_has(X86_FEATURE_SEV));
- test_sev_smoke(guest_sev_code, KVM_X86_SEV_VM, 0);
+ // test_sev_smoke(guest_sev_code, KVM_X86_SEV_VM, 0);
- if (kvm_cpu_has(X86_FEATURE_SEV_ES))
- test_sev_smoke(guest_sev_es_code, KVM_X86_SEV_ES_VM, SEV_POLICY_ES);
+ // if (kvm_cpu_has(X86_FEATURE_SEV_ES))
+ // test_sev_smoke(guest_sev_es_code, KVM_X86_SEV_ES_VM, SEV_POLICY_ES);
- if (kvm_cpu_has(X86_FEATURE_SEV_SNP))
- test_sev_smoke(guest_snp_code, KVM_X86_SNP_VM, snp_default_policy());
+ if (kvm_cpu_has(X86_FEATURE_SEV_SNP)) {
+ test_conversion(snp_default_policy());
+ // test_sev_smoke(guest_snp_code, KVM_X86_SNP_VM, snp_default_policy());
+ }
return 0;
}
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply related
* [POC PATCH 4/6] KVM: selftests: Allow specifying CoCo-privateness while mapping a page
From: Ackerley Tng @ 2026-03-26 23:36 UTC (permalink / raw)
To: ackerleytng
Cc: aik, akpm, andrew.jones, aneesh.kumar, axelrasmussen, baohua, bhe,
binbin.wu, bp, brauner, chao.p.peng, chrisl, corbet, dave.hansen,
david, forkloop, hpa, ira.weiny, jgg, jmattson, jroedel,
jthoughton, kasong, kvm, linux-doc, linux-kernel, linux-kselftest,
linux-mm, linux-trace-kernel, mathieu.desnoyers, mhiramat,
michael.roth, mingo, nphamcs, oupton, pankaj.gupta, pbonzini,
pratyush, qperret, rick.p.edgecombe, rientjes, rostedt, seanjc,
shikemeng, shivankg, shuah, skhan, steven.price, suzuki.poulose,
tabba, tglx, vannapurve, vbabka, weixugc, willy, wyihan, x86,
yan.y.zhao, yuanchu
In-Reply-To: <cover.1774568083.git.ackerleytng@google.com>
Signed-off-by: Ackerley Tng <ackerleytng@google.com>
---
tools/testing/selftests/kvm/include/x86/processor.h | 2 ++
tools/testing/selftests/kvm/lib/x86/processor.c | 13 ++++++++++---
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/kvm/include/x86/processor.h b/tools/testing/selftests/kvm/include/x86/processor.h
index 469a221221575..64870968ee47a 100644
--- a/tools/testing/selftests/kvm/include/x86/processor.h
+++ b/tools/testing/selftests/kvm/include/x86/processor.h
@@ -1499,6 +1499,8 @@ enum pg_level {
void tdp_mmu_init(struct kvm_vm *vm, int pgtable_levels,
struct pte_masks *pte_masks);
+void ___virt_pg_map(struct kvm_vm *vm, struct kvm_mmu *mmu, uint64_t vaddr,
+ uint64_t paddr, int level, bool private);
void __virt_pg_map(struct kvm_vm *vm, struct kvm_mmu *mmu, uint64_t vaddr,
uint64_t paddr, int level);
void virt_map_level(struct kvm_vm *vm, uint64_t vaddr, uint64_t paddr,
diff --git a/tools/testing/selftests/kvm/lib/x86/processor.c b/tools/testing/selftests/kvm/lib/x86/processor.c
index 23a44941e2837..fcdc4ae40b167 100644
--- a/tools/testing/selftests/kvm/lib/x86/processor.c
+++ b/tools/testing/selftests/kvm/lib/x86/processor.c
@@ -254,8 +254,8 @@ static uint64_t *virt_create_upper_pte(struct kvm_vm *vm,
return pte;
}
-void __virt_pg_map(struct kvm_vm *vm, struct kvm_mmu *mmu, uint64_t vaddr,
- uint64_t paddr, int level)
+void ___virt_pg_map(struct kvm_vm *vm, struct kvm_mmu *mmu, uint64_t vaddr,
+ uint64_t paddr, int level, bool private)
{
const uint64_t pg_size = PG_LEVEL_SIZE(level);
uint64_t *pte = &mmu->pgd;
@@ -307,12 +307,19 @@ void __virt_pg_map(struct kvm_vm *vm, struct kvm_mmu *mmu, uint64_t vaddr,
* Neither SEV nor TDX supports shared page tables, so only the final
* leaf PTE needs manually set the C/S-bit.
*/
- if (vm_is_gpa_protected(vm, paddr))
+ if (private)
*pte |= PTE_C_BIT_MASK(mmu);
else
*pte |= PTE_S_BIT_MASK(mmu);
}
+void __virt_pg_map(struct kvm_vm *vm, struct kvm_mmu *mmu, uint64_t vaddr,
+ uint64_t paddr, int level)
+{
+ ___virt_pg_map(vm, mmu, vaddr, paddr, level,
+ vm_is_gpa_protected(vm, paddr));
+}
+
void virt_arch_pg_map(struct kvm_vm *vm, uint64_t vaddr, uint64_t paddr)
{
__virt_pg_map(vm, &vm->mmu, vaddr, paddr, PG_LEVEL_4K);
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply related
* [POC PATCH 3/6] KVM: selftests: Make guest_code_xsave more friendly
From: Ackerley Tng @ 2026-03-26 23:36 UTC (permalink / raw)
To: ackerleytng
Cc: aik, akpm, andrew.jones, aneesh.kumar, axelrasmussen, baohua, bhe,
binbin.wu, bp, brauner, chao.p.peng, chrisl, corbet, dave.hansen,
david, forkloop, hpa, ira.weiny, jgg, jmattson, jroedel,
jthoughton, kasong, kvm, linux-doc, linux-kernel, linux-kselftest,
linux-mm, linux-trace-kernel, mathieu.desnoyers, mhiramat,
michael.roth, mingo, nphamcs, oupton, pankaj.gupta, pbonzini,
pratyush, qperret, rick.p.edgecombe, rientjes, rostedt, seanjc,
shikemeng, shivankg, shuah, skhan, steven.price, suzuki.poulose,
tabba, tglx, vannapurve, vbabka, weixugc, willy, wyihan, x86,
yan.y.zhao, yuanchu
In-Reply-To: <cover.1774568083.git.ackerleytng@google.com>
The original implementation of guest_code_xsave makes a jmp to
guest_sev_es_code in inline assembly. When code that uses guest_sev_es_code
is removed, guest_sev_es_code will be optimized out, leading to a linking
error since guest_code_xsave still tries to jmp to guest_sev_es_code.
Rewrite guest_code_xsave() to instead make a call, in C, to
guest_sev_es_code(), so that usage of guest_sev_es_code() is made known to
the compiler.
This rewriting also gives a name to the xsave inline assembly, improving
readability.
Signed-off-by: Ackerley Tng <ackerleytng@google.com>
---
.../selftests/kvm/x86/sev_smoke_test.c | 24 +++++++++++++------
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/tools/testing/selftests/kvm/x86/sev_smoke_test.c b/tools/testing/selftests/kvm/x86/sev_smoke_test.c
index 8bd37a476f159..7e69da01cecf4 100644
--- a/tools/testing/selftests/kvm/x86/sev_smoke_test.c
+++ b/tools/testing/selftests/kvm/x86/sev_smoke_test.c
@@ -80,13 +80,23 @@ static void guest_sev_code(void)
GUEST_DONE();
}
-/* Stash state passed via VMSA before any compiled code runs. */
-extern void guest_code_xsave(void);
-asm("guest_code_xsave:\n"
- "mov $" __stringify(XFEATURE_MASK_X87_AVX) ", %eax\n"
- "xor %edx, %edx\n"
- "xsave (%rdi)\n"
- "jmp guest_sev_es_code");
+static void xsave_all_registers(void *addr)
+{
+ __asm__ __volatile__(
+ "mov $" __stringify(XFEATURE_MASK_X87_AVX) ", %eax\n"
+ "xor %edx, %edx\n"
+ "xsave (%0)"
+ :
+ : "r"(addr)
+ : "eax", "edx", "memory"
+ );
+}
+
+static void guest_code_xsave(void *vmsa_gva)
+{
+ xsave_all_registers(vmsa_gva);
+ guest_sev_es_code();
+}
static void compare_xsave(u8 *from_host, u8 *from_guest)
{
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply related
* [POC PATCH 2/6] KVM: selftests: Call snp_launch_update_data() providing copy of memory
From: Ackerley Tng @ 2026-03-26 23:36 UTC (permalink / raw)
To: ackerleytng
Cc: aik, akpm, andrew.jones, aneesh.kumar, axelrasmussen, baohua, bhe,
binbin.wu, bp, brauner, chao.p.peng, chrisl, corbet, dave.hansen,
david, forkloop, hpa, ira.weiny, jgg, jmattson, jroedel,
jthoughton, kasong, kvm, linux-doc, linux-kernel, linux-kselftest,
linux-mm, linux-trace-kernel, mathieu.desnoyers, mhiramat,
michael.roth, mingo, nphamcs, oupton, pankaj.gupta, pbonzini,
pratyush, qperret, rick.p.edgecombe, rientjes, rostedt, seanjc,
shikemeng, shivankg, shuah, skhan, steven.price, suzuki.poulose,
tabba, tglx, vannapurve, vbabka, weixugc, willy, wyihan, x86,
yan.y.zhao, yuanchu
In-Reply-To: <cover.1774568083.git.ackerleytng@google.com>
Call snp_launch_update_data() providing a copy of the memory to be
loaded. KVM_SEV_SNP_LAUNCH_UPDATE populates memory into private memory by
first GUP-ing the source memory, then encrypting it into private memory.
The hva that was specified as the source is in this case also the
destination where the private memory will be placed after encryption.
KVM_SEV_SNP_LAUNCH_UPDATE requires the destination to be private memory,
but private memory cannot be accessed by the host and hence cannot be
GUP-ed. Hence, make a copy of the memory to be loaded, and use that as the
source, so that the source can be GUP-ed, and the destination is still
private.
Signed-off-by: Ackerley Tng <ackerleytng@google.com>
---
tools/testing/selftests/kvm/lib/x86/sev.c | 35 +++++++++++++++++++----
1 file changed, 29 insertions(+), 6 deletions(-)
diff --git a/tools/testing/selftests/kvm/lib/x86/sev.c b/tools/testing/selftests/kvm/lib/x86/sev.c
index d3a7241e5fc13..1b937034a5c11 100644
--- a/tools/testing/selftests/kvm/lib/x86/sev.c
+++ b/tools/testing/selftests/kvm/lib/x86/sev.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0-only
#include <stdint.h>
#include <stdbool.h>
+#include <sys/mman.h>
#include "sev.h"
@@ -31,17 +32,39 @@ static void encrypt_region(struct kvm_vm *vm, struct userspace_mem_region *regio
sparsebit_for_each_set_range(protected_phy_pages, i, j) {
const uint64_t size = (j - i + 1) * vm->page_size;
const uint64_t offset = (i - lowest_page_in_region) * vm->page_size;
+ void *source;
+
+ /*
+ * Is SNP the only place where private=true? If yes,
+ * then we don't need the private parameter, we can
+ * just check if the vm is SNP. Or maybe it depends on
+ * whether TDX, etc use the private parameter.
+ */
+ if (private) {
+ const void *hva = addr_gpa2hva(vm, gpa_base + offset);
+
+ source = kvm_mmap(size, PROT_READ | PROT_WRITE,
+ MAP_ANONYMOUS | MAP_PRIVATE, -1);
+ /*
+ * Make a copy before setting private, because
+ * snp_launch_update_data() needs to GUP the
+ * source, and private memory cannot be
+ * GUP-ed.
+ */
+ memcpy(source, hva, size);
- if (private)
vm_mem_set_private(vm, gpa_base + offset, size, 0);
+ }
- if (is_sev_snp_vm(vm))
+ if (is_sev_snp_vm(vm)) {
snp_launch_update_data(vm, gpa_base + offset,
- (uint64_t)addr_gpa2hva(vm, gpa_base + offset),
- size, page_type);
- else
- sev_launch_update_data(vm, gpa_base + offset, size);
+ (uint64_t)source, size,
+ page_type);
+ kvm_munmap(source, size);
+ } else {
+ sev_launch_update_data(vm, gpa_base + offset, size);
+ }
}
}
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply related
* [POC PATCH 1/6] KVM: selftests: Initialize guest_memfd with INIT_SHARED
From: Ackerley Tng @ 2026-03-26 23:36 UTC (permalink / raw)
To: ackerleytng
Cc: aik, akpm, andrew.jones, aneesh.kumar, axelrasmussen, baohua, bhe,
binbin.wu, bp, brauner, chao.p.peng, chrisl, corbet, dave.hansen,
david, forkloop, hpa, ira.weiny, jgg, jmattson, jroedel,
jthoughton, kasong, kvm, linux-doc, linux-kernel, linux-kselftest,
linux-mm, linux-trace-kernel, mathieu.desnoyers, mhiramat,
michael.roth, mingo, nphamcs, oupton, pankaj.gupta, pbonzini,
pratyush, qperret, rick.p.edgecombe, rientjes, rostedt, seanjc,
shikemeng, shivankg, shuah, skhan, steven.price, suzuki.poulose,
tabba, tglx, vannapurve, vbabka, weixugc, willy, wyihan, x86,
yan.y.zhao, yuanchu, Sagi Shahar
In-Reply-To: <cover.1774568083.git.ackerleytng@google.com>
Initialize guest_memfd with INIT_SHARED for VM types that require
guest_memfd.
Memory in the first memslot is used by the selftest framework to load
code, page tables, interrupt descriptor tables, and basically everything
the selftest needs to run. The selftest framework sets all of these up
assuming that the memory in the memslot can be written to from the
host. Align with that behavior by initializing guest_memfd as shared so
that all the writes from the host are permitted.
guest_memfd memory can later be marked private if necessary by CoCo
platform-specific initialization functions.
Suggested-by: Sagi Shahar <sagis@google.com>
Signed-off-by: Ackerley Tng <ackerleytng@google.com>
---
tools/testing/selftests/kvm/lib/kvm_util.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/kvm/lib/kvm_util.c b/tools/testing/selftests/kvm/lib/kvm_util.c
index eaa5a1afa1d9b..68241e458807a 100644
--- a/tools/testing/selftests/kvm/lib/kvm_util.c
+++ b/tools/testing/selftests/kvm/lib/kvm_util.c
@@ -483,8 +483,10 @@ struct kvm_vm *__vm_create(struct vm_shape shape, uint32_t nr_runnable_vcpus,
{
uint64_t nr_pages = vm_nr_pages_required(shape.mode, nr_runnable_vcpus,
nr_extra_pages);
+ enum vm_mem_backing_src_type src_type;
struct userspace_mem_region *slot0;
struct kvm_vm *vm;
+ u64 gmem_flags;
int i, flags;
kvm_set_files_rlimit(nr_runnable_vcpus);
@@ -502,7 +504,15 @@ struct kvm_vm *__vm_create(struct vm_shape shape, uint32_t nr_runnable_vcpus,
if (is_guest_memfd_required(shape))
flags |= KVM_MEM_GUEST_MEMFD;
- vm_userspace_mem_region_add(vm, VM_MEM_SRC_ANONYMOUS, 0, 0, nr_pages, flags);
+ gmem_flags = 0;
+ src_type = VM_MEM_SRC_ANONYMOUS;
+ if (is_guest_memfd_required(shape) && kvm_has_gmem_attributes) {
+ src_type = VM_MEM_SRC_SHMEM;
+ gmem_flags = GUEST_MEMFD_FLAG_MMAP | GUEST_MEMFD_FLAG_INIT_SHARED;
+ }
+
+ vm_mem_add(vm, src_type, 0, 0, nr_pages, flags, -1, 0, gmem_flags);
+
for (i = 0; i < NR_MEM_REGIONS; i++)
vm->memslots[i] = 0;
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply related
* [POC PATCH 0/6] guest_memfd in-place conversion selftests for SNP
From: Ackerley Tng @ 2026-03-26 23:36 UTC (permalink / raw)
To: ackerleytng
Cc: aik, akpm, andrew.jones, aneesh.kumar, axelrasmussen, baohua, bhe,
binbin.wu, bp, brauner, chao.p.peng, chrisl, corbet, dave.hansen,
david, forkloop, hpa, ira.weiny, jgg, jmattson, jroedel,
jthoughton, kasong, kvm, linux-doc, linux-kernel, linux-kselftest,
linux-mm, linux-trace-kernel, mathieu.desnoyers, mhiramat,
michael.roth, mingo, nphamcs, oupton, pankaj.gupta, pbonzini,
pratyush, qperret, rick.p.edgecombe, rientjes, rostedt, seanjc,
shikemeng, shivankg, shuah, skhan, steven.price, suzuki.poulose,
tabba, tglx, vannapurve, vbabka, weixugc, willy, wyihan, x86,
yan.y.zhao, yuanchu
In-Reply-To: <20260326-gmem-inplace-conversion-v4-0-e202fe950ffd@google.com>
With these POC patches, I was able to test the set memory
attributes/conversion ioctls with SNP. The content policies work :)
Ackerley Tng (6):
KVM: selftests: Initialize guest_memfd with INIT_SHARED
KVM: selftests: Call snp_launch_update_data() providing copy of memory
KVM: selftests: Make guest_code_xsave more friendly
KVM: selftests: Allow specifying CoCo-privateness while mapping a page
KVM: selftests: Test conversions for SNP
KVM: selftests: Test content modes ZERO and PRESERVE for SNP
.../selftests/kvm/include/x86/processor.h | 2 +
tools/testing/selftests/kvm/lib/kvm_util.c | 12 +-
.../testing/selftests/kvm/lib/x86/processor.c | 13 +-
tools/testing/selftests/kvm/lib/x86/sev.c | 35 ++-
.../selftests/kvm/x86/sev_smoke_test.c | 255 +++++++++++++++++-
5 files changed, 295 insertions(+), 22 deletions(-)
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply
* [PATCH] Documentation: Provide hints on how to debug Python GDB scripts
From: Florian Fainelli @ 2026-03-26 23:32 UTC (permalink / raw)
To: linux-kernel, akpm
Cc: tglx, radu, Florian Fainelli, Jonathan Corbet, Shuah Khan,
Illia Ostapyshyn, open list:DOCUMENTATION PROCESS,
open list:DOCUMENTATION
By default GDB does not print a full stack of its integrated Python
interpreter, thus making the debugging of GDB scripts more painful than
it has to be.
Suggested-by: Radu Rendec <radu@rendec.net>
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
---
Documentation/process/debugging/gdb-kernel-debugging.rst | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Documentation/process/debugging/gdb-kernel-debugging.rst b/Documentation/process/debugging/gdb-kernel-debugging.rst
index 9475c759c722..53e225760a4d 100644
--- a/Documentation/process/debugging/gdb-kernel-debugging.rst
+++ b/Documentation/process/debugging/gdb-kernel-debugging.rst
@@ -173,3 +173,12 @@ this is just a snapshot of the initial version::
Detailed help can be obtained via "help <command-name>" for commands and "help
function <function-name>" for convenience functions.
+
+Debugging GDB scripts
+---------------------
+
+GDB does not enable a full Python backtrace which can make debugging GDB
+scripts more difficult than necessary. The following will allow for printing a
+full backtrace of the python environment::
+
+ (gdb) set python print-stack full
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] checkpatch: allow correctly handle full files on stdin
From: Joe Perches @ 2026-03-26 23:27 UTC (permalink / raw)
To: Dmitry Torokhov, Andrew Morton
Cc: Dwaipayan Ray, Lukas Bulwahn, Andy Whitcroft, Jonathan Corbet,
Shuah Khan, workflows, linux-doc, linux-kernel
In-Reply-To: <acW9KGbNm8bLg-cr@google.com>
On Thu, 2026-03-26 at 16:19 -0700, Dmitry Torokhov wrote:
> On Thu, Mar 26, 2026 at 03:56:27PM -0700, Joe Perches wrote:
> I gave you feedback. You elided it.
> > > Could you please point me to it? All I saw is "just save it"
> > Seems constructive to me.
> As constructive as "You're holding it wrong". I want to be able to run
> checkpatch as I am typing, not at some later time. My editor shows
> diagnostics as a virtual text, so it is quite confusing that the error
> is still shown even after I fixed the issue.
>
> It looks like I forgot to add akpm to CC, let me add him...
No worries. nak.
It's not something I want to support.
cheers, Joe
^ permalink raw reply
* Re: [PATCH v4 11/13] ima: Support staging and deleting N measurements entries
From: steven chen @ 2026-03-26 23:19 UTC (permalink / raw)
To: Roberto Sassu, corbet, skhan, zohar, dmitry.kasatkin,
eric.snowberg, paul, jmorris, serge
Cc: linux-doc, linux-kernel, linux-integrity, linux-security-module,
gregorylumen, nramas, Roberto Sassu
In-Reply-To: <20260326173011.1191815-12-roberto.sassu@huaweicloud.com>
On 3/26/2026 10:30 AM, Roberto Sassu wrote:
> From: Roberto Sassu <roberto.sassu@huawei.com>
>
> Add support for sending a value N between 1 and ULONG_MAX to the staging
> interface. This value represents the number of measurements that should be
> deleted from the current measurements list.
>
> This staging method allows the remote attestation agents to easily separate
> the measurements that were verified (staged and deleted) from those that
> weren't due to the race between taking a TPM quote and reading the
> measurements list.
>
> In order to minimize the locking time of ima_extend_list_mutex, deleting
> N entries is realized by staging the entire current measurements list
> (with the lock), by determining the N-th staged entry (without the lock),
> and by splicing the entries in excess back to the current measurements list
> (with the lock). Finally, the N entries are deleted (without the lock).
>
> Flushing the hash table is not supported for N entries, since it would
> require removing the N entries one by one from the hash table under the
> ima_extend_list_mutex lock, which would increase the locking time.
>
> The ima_extend_list_mutex lock is necessary in ima_dump_measurement_list()
> because ima_queue_staged_delete_partial() uses __list_cut_position() to
> modify ima_measurements_staged, for which no RCU-safe variant exists. For
> the staging with prompt flavor alone, list_replace_rcu() could have been
> used instead, but since both flavors share the same kexec serialization
> path, the mutex is required regardless.
>
> Link: https://github.com/linux-integrity/linux/issues/1
> Suggested-by: Steven Chen <chenste@linux.microsoft.com>
> Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
> ---
> security/integrity/ima/Kconfig | 3 ++
> security/integrity/ima/ima.h | 1 +
> security/integrity/ima/ima_fs.c | 22 +++++++++-
> security/integrity/ima/ima_queue.c | 70 ++++++++++++++++++++++++++++++
> 4 files changed, 95 insertions(+), 1 deletion(-)
>
> diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
> index e714726f3384..6ddb4e77bff5 100644
> --- a/security/integrity/ima/Kconfig
> +++ b/security/integrity/ima/Kconfig
> @@ -341,6 +341,9 @@ config IMA_STAGING
> It allows user space to stage the measurements list for deletion and
> to delete the staged measurements after confirmation.
>
> + Or, alternatively, it allows user space to specify N measurements
> + entries to be deleted.
> +
> On kexec, staging is reverted and staged measurements are prepended
> to the current measurements list when measurements are copied to the
> secondary kernel.
> diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
> index 699b735dec7d..de0693fce53c 100644
> --- a/security/integrity/ima/ima.h
> +++ b/security/integrity/ima/ima.h
> @@ -319,6 +319,7 @@ struct ima_template_desc *lookup_template_desc(const char *name);
> bool ima_template_has_modsig(const struct ima_template_desc *ima_template);
> int ima_queue_stage(void);
> int ima_queue_staged_delete_all(void);
> +int ima_queue_staged_delete_partial(unsigned long req_value);
> int ima_restore_measurement_entry(struct ima_template_entry *entry);
> int ima_restore_measurement_list(loff_t bufsize, void *buf);
> int ima_measurements_show(struct seq_file *m, void *v);
> diff --git a/security/integrity/ima/ima_fs.c b/security/integrity/ima/ima_fs.c
> index 39d9128e9f22..eb3f343c1138 100644
> --- a/security/integrity/ima/ima_fs.c
> +++ b/security/integrity/ima/ima_fs.c
> @@ -28,6 +28,7 @@
> * Requests:
> * 'A\n': stage the entire measurements list
> * 'D\n': delete all staged measurements
> + * '[1, ULONG_MAX]\n' delete N measurements entries
> */
> #define STAGED_REQ_LENGTH 21
>
> @@ -319,6 +320,7 @@ static ssize_t ima_measurements_staged_write(struct file *file,
> size_t datalen, loff_t *ppos)
> {
> char req[STAGED_REQ_LENGTH];
> + unsigned long req_value;
> int ret;
>
> if (*ppos > 0 || datalen < 2 || datalen > STAGED_REQ_LENGTH)
> @@ -346,7 +348,25 @@ static ssize_t ima_measurements_staged_write(struct file *file,
> ret = ima_queue_staged_delete_all();
> break;
> default:
> - ret = -EINVAL;
> + if (ima_flush_htable) {
> + pr_debug("Deleting staged N measurements not supported when flushing the hash table is requested\n");
> + return -EINVAL;
> + }
> +
> + ret = kstrtoul(req, 10, &req_value);
> + if (ret < 0)
> + return ret;
> +
> + if (req_value == 0) {
> + pr_debug("Must delete at least one entry\n");
> + return -EINVAL;
> + }
> +
> + ret = ima_queue_stage();
> + if (ret < 0)
> + return ret;
> +
> + ret = ima_queue_staged_delete_partial(req_value);
The default processing is "Trim N" idea plus performance improvement.
Here do everything in one time. And this is what I said in v3.
[PATCH v3 1/3] ima: Remove ima_h_table structure
<https://lore.kernel.org/linux-integrity/c61aeaa79929a98cb3a6d30835972891fac3570f.camel@linux.ibm.com/T/#t>
The important two parts of trimming is "trim N" and performance improvement.
The performance improvement include two parts:
hash table staging
active log list staging
And I think "Trim N" plus performance improvement is the right direction
to go.
Lots of code for two steps "stage and trim" "stage" part can be removed.
Also race condition may happen if not holding the list all time in user
space
during attestation period: from stage, read list, attestation and trimming.
So in order to improve the above user space lock time, "Trim T:N" can be
used
not to hold list long in user space during attestation.
For Trim T:N, T represent total log trimmed since system boot up. Please
refer to
https://lore.kernel.org/linux-integrity/20260205235849.7086-1-chenste@linux.microsoft.com/T/#t
Thanks,
Steven
> }
>
> if (ret < 0)
> diff --git a/security/integrity/ima/ima_queue.c b/security/integrity/ima/ima_queue.c
> index f5c18acfbc43..4fb557d61a88 100644
> --- a/security/integrity/ima/ima_queue.c
> +++ b/security/integrity/ima/ima_queue.c
> @@ -371,6 +371,76 @@ int ima_queue_staged_delete_all(void)
> return 0;
> }
>
> +int ima_queue_staged_delete_partial(unsigned long req_value)
> +{
> + unsigned long req_value_copy = req_value;
> + unsigned long size_to_remove = 0, num_to_remove = 0;
> + struct list_head *cut_pos = NULL;
> + LIST_HEAD(ima_measurements_trim);
> + struct ima_queue_entry *qe;
> + int ret = 0;
> +
> + /*
> + * Safe walk (no concurrent write), not under ima_extend_list_mutex
> + * for performance reasons.
> + */
> + list_for_each_entry(qe, &ima_measurements_staged, later) {
> + size_to_remove += get_binary_runtime_size(qe->entry);
> + num_to_remove++;
> +
> + if (--req_value_copy == 0) {
> + /* qe->later always points to a valid list entry. */
> + cut_pos = &qe->later;
> + break;
> + }
> + }
> +
> + /* Nothing to remove, undoing staging. */
> + if (req_value_copy > 0) {
> + size_to_remove = 0;
> + num_to_remove = 0;
> + ret = -ENOENT;
> + }
> +
> + mutex_lock(&ima_extend_list_mutex);
> + if (list_empty(&ima_measurements_staged)) {
> + mutex_unlock(&ima_extend_list_mutex);
> + return -ENOENT;
> + }
> +
> + if (cut_pos != NULL)
> + /*
> + * ima_dump_measurement_list() does not modify the list,
> + * cut_pos remains the same even if it was computed before
> + * the lock.
> + */
> + __list_cut_position(&ima_measurements_trim,
> + &ima_measurements_staged, cut_pos);
> +
> + atomic_long_sub(num_to_remove, &ima_num_entries[BINARY_STAGED]);
> + atomic_long_add(atomic_long_read(&ima_num_entries[BINARY_STAGED]),
> + &ima_num_entries[BINARY]);
> + atomic_long_set(&ima_num_entries[BINARY_STAGED], 0);
> +
> + if (IS_ENABLED(CONFIG_IMA_KEXEC)) {
> + binary_runtime_size[BINARY_STAGED] -= size_to_remove;
> + binary_runtime_size[BINARY] +=
> + binary_runtime_size[BINARY_STAGED];
> + binary_runtime_size[BINARY_STAGED] = 0;
> + }
> +
> + /*
> + * Splice (prepend) any remaining non-deleted staged entries to the
> + * active list (RCU not needed, there cannot be concurrent readers).
> + */
> + list_splice(&ima_measurements_staged, &ima_measurements);
> + INIT_LIST_HEAD(&ima_measurements_staged);
> + mutex_unlock(&ima_extend_list_mutex);
> +
> + ima_queue_delete(&ima_measurements_trim, false);
> + return ret;
> +}
> +
> static void ima_queue_delete(struct list_head *head, bool flush_htable)
> {
> struct ima_queue_entry *qe, *qe_tmp;
^ 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