* [PATCH v6 0/2] PCI: s390: Expose the UID as an arch specific PCI slot attribute
From: Niklas Schnelle @ 2026-04-02 20:34 UTC (permalink / raw)
To: Bjorn Helgaas, Jonathan Corbet, Lukas Wunner, Shuah Khan
Cc: Farhan Ali, Alexander Gordeev, Christian Borntraeger,
Gerald Schaefer, Gerd Bayer, Heiko Carstens, Julian Ruess,
Matthew Rosato, Peter Oberparleiter, Ramesh Errabolu,
Sven Schnelle, Vasily Gorbik, linux-doc, linux-kernel, linux-pci,
linux-s390, Niklas Schnelle
Hi all,
Add a mechanism for architecture specific attributes on
PCI slots in order to add the user-defined ID (UID) as an s390 specific
PCI slot attribute. First though improve some issues with the s390 specific
documentation of PCI sysfs attributes noticed during development.
Also note, I considered adding the UID as a generic slot index attribute
analogous to the PCI device index attribute (SMBIOS index / s390 UID)
but decided against it as this seems rather s390 specific and having
it named UID makes things easier for users and aligns with the existing
separate uid device attribute.
Thanks,
Niklas
v5->v6:
- Add documentation cleanup patch before adding new slot attribute
- Link to v5: https://lore.kernel.org/r/20260401-uid_slot-v5-1-e73036c74bf6@linux.ibm.com
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
---
---
Niklas Schnelle (2):
docs: s390/pci: Improve and update PCI documentation
PCI: s390: Expose the UID as an arch specific PCI slot attribute
Documentation/arch/s390/pci.rst | 146 +++++++++++++++++++++++++++-------------
arch/s390/include/asm/pci.h | 4 ++
arch/s390/pci/pci_sysfs.c | 20 ++++++
drivers/pci/slot.c | 13 +++-
4 files changed, 137 insertions(+), 46 deletions(-)
---
base-commit: 7aaa8047eafd0bd628065b15757d9b48c5f9c07d
change-id: 20250923-uid_slot-e3559cf5ca30
Best regards,
--
Niklas Schnelle
^ permalink raw reply
* Re: [PATCH v7 1/9] KVM: x86: Define KVM_X86_QUIRK_NESTED_SVM_SHARED_PAT
From: Yosry Ahmed @ 2026-04-02 20:26 UTC (permalink / raw)
To: Jim Mattson
Cc: kernel test robot, Paolo Bonzini, Jonathan Corbet, Shuah Khan,
Sean Christopherson, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, kvm, linux-doc,
linux-kernel, linux-kselftest, oe-kbuild-all
In-Reply-To: <CALMp9eSO6gz4R0f1S=E-sA3YE8KE0uJ30otcGsMV1NS3ujUcNA@mail.gmail.com>
> It looks like svm.h should include x86.h.
>
> Sean: Do you want me to send a new series?
FWIW, this is the same problem as:
https://lore.kernel.org/kvm/CAO9r8zPuDcHMObfzTQVY-P0Z3kXZbw6y5KJizxvpFWXdW7uKbQ@mail.gmail.com/.
So only the first series that gets picked up will need the fixup.
^ permalink raw reply
* Re: [PATCH] Documentation: kbuild: Update the debug information notes in reproducible-builds.rst
From: Nicolas Schier @ 2026-04-02 20:19 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Jonathan Corbet, Shuah Khan, linux-kbuild, linux-doc,
linux-kernel, Alexander Coffin
In-Reply-To: <20260313-kbuild-docs-repro-builds-fdebug-prefix-map-updates-v1-1-3aeeef7fa710@kernel.org>
On Fri, 13 Mar 2026 16:37:29 -0700, Nathan Chancellor wrote:
> Documentation: kbuild: Update the debug information notes in reproducible-builds.rst
Applied to kbuild/linux.git (kbuild-next-unstable), thanks!
[1/1] Documentation: kbuild: Update the debug information notes in reproducible-builds.rst
https://git.kernel.org/kbuild/c/d88af9ef
Please look out for regression or issue reports or other follow up
comments, as they may result in the patch/series getting dropped,
reverted or modified (e.g. trailers). Patches applied to the
kbuild-next-unstable branch are accepted pending wider testing in
linux-next and any post-commit review; they will generally be moved
to the kbuild-next branch in about a week if no issues are found.
Best regards,
--
Nicolas
^ permalink raw reply
* Re: [PATCH v7 1/9] KVM: x86: Define KVM_X86_QUIRK_NESTED_SVM_SHARED_PAT
From: Jim Mattson @ 2026-04-02 19:39 UTC (permalink / raw)
To: kernel test robot
Cc: Paolo Bonzini, Jonathan Corbet, Shuah Khan, Sean Christopherson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, kvm, linux-doc, linux-kernel, linux-kselftest,
Yosry Ahmed, oe-kbuild-all
In-Reply-To: <202603301501.N2sdlIQ9-lkp@intel.com>
On Mon, Mar 30, 2026 at 12:50 AM kernel test robot <lkp@intel.com> wrote:
>
> Hi Jim,
>
> kernel test robot noticed the following build errors:
>
> [auto build test ERROR on 3d6cdcc8883b5726513d245eef0e91cabfc397f7]
>
> url: https://github.com/intel-lab-lkp/linux/commits/Jim-Mattson/KVM-x86-Define-KVM_X86_QUIRK_NESTED_SVM_SHARED_PAT/20260328-110805
> base: 3d6cdcc8883b5726513d245eef0e91cabfc397f7
> patch link: https://lore.kernel.org/r/20260327234023.2659476-2-jmattson%40google.com
> patch subject: [PATCH v7 1/9] KVM: x86: Define KVM_X86_QUIRK_NESTED_SVM_SHARED_PAT
> config: x86_64-randconfig-016-20260330 (https://download.01.org/0day-ci/archive/20260330/202603301501.N2sdlIQ9-lkp@intel.com/config)
> compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260330/202603301501.N2sdlIQ9-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/202603301501.N2sdlIQ9-lkp@intel.com/
>
> All errors (new ones prefixed by >>):
>
> In file included from arch/x86/kvm/svm/svm_onhyperv.c:11:
> arch/x86/kvm/svm/svm.h: In function 'l2_has_separate_pat':
> >> arch/x86/kvm/svm/svm.h:626:18: error: implicit declaration of function 'kvm_check_has_quirk'; did you mean 'kvm_check_request'? [-Wimplicit-function-declaration]
> 626 | !kvm_check_has_quirk(svm->vcpu.kvm,
> | ^~~~~~~~~~~~~~~~~~~
> | kvm_check_request
> In file included from arch/x86/kvm/svm/svm_ops.h:7,
> from arch/x86/kvm/svm/svm_onhyperv.c:12:
> arch/x86/kvm/x86.h: At top level:
> >> arch/x86/kvm/x86.h:429:20: error: conflicting types for 'kvm_check_has_quirk'; have 'bool(struct kvm *, u64)' {aka '_Bool(struct kvm *, long long unsigned int)'}
> 429 | static inline bool kvm_check_has_quirk(struct kvm *kvm, u64 quirk)
> | ^~~~~~~~~~~~~~~~~~~
> arch/x86/kvm/svm/svm.h:626:18: note: previous implicit declaration of 'kvm_check_has_quirk' with type 'int()'
> 626 | !kvm_check_has_quirk(svm->vcpu.kvm,
> | ^~~~~~~~~~~~~~~~~~~
> --
It looks like svm.h should include x86.h.
Sean: Do you want me to send a new series?
^ permalink raw reply
* Re: [PATCH 3/3] Documentation: clarify the mandatory and desirable info for security reports
From: Willy Tarreau @ 2026-04-02 19:20 UTC (permalink / raw)
To: Randy Dunlap
Cc: greg, edumazet, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel
In-Reply-To: <d26e37d4-0a29-4aaf-9034-3e1cc91bc6ce@infradead.org>
On Thu, Apr 02, 2026 at 12:17:38PM -0700, Randy Dunlap wrote:
>
>
> On 4/2/26 12:03 PM, Willy Tarreau wrote:
> > Hi Randy,
> >
> > On Thu, Apr 02, 2026 at 11:50:00AM -0700, Randy Dunlap wrote:
> >>
> >> On 4/2/26 11:26 AM, Willy Tarreau wrote:
> >>> A significant part of the effort of the security team consists in begging
> >>> reporters for patch proposals, or asking them to provide them in regular
> >>> format, and most of the time they're willing to provide this, they just
> >>> didn't know that it would help. So let's add a section detailing the
> >>> required and desirable contents in a security report to help reporters
> >>> write more actionable reports which do not require round trips.
> >>>
> >>> Cc: Eric Dumazet <edumazet@google.com>
> >>> Cc: Greg KH <greg@kroah.com>
> >>> Signed-off-by: Willy Tarreau <w@1wt.eu>
> >>> ---
> >>> Documentation/process/security-bugs.rst | 66 ++++++++++++++++++++++---
> >>> 1 file changed, 59 insertions(+), 7 deletions(-)
> >>>
> >>> diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
> >>> index 6937fa9fba5a..b243ac24eb12 100644
> >>> --- a/Documentation/process/security-bugs.rst
> >>> +++ b/Documentation/process/security-bugs.rst
> >>> @@ -7,6 +7,65 @@ Linux kernel developers take security very seriously. As such, we'd
> >>> like to know when a security bug is found so that it can be fixed and
> >>> disclosed as quickly as possible.
> >>>
> >>> +Preparing your report
> >>> +---------------------
> >>> +
> >>> +Like with any bug report, a security bug report requires a lot of analysis work
> >>> +from the developers, so the more information you can share about the issue, the
> >>> +better. Please review the procedure outlined in
> >>> +'Documentation/admin-guide/reporting-issues.rst' if you are unclear about what
> >>
> >> Drop the single quote marks.
> >
> > I just moved this part as-is, and I've been extremely hesitant to change
> > formatting as I can't easily check the validity of the output.
> >
> >>> +information is helpful. The following information are absolutely necessary in
> >>> +**any** security bug report:
> >>> +
> >>> + * **affected kernel version range**: with no version indication, your report
> >>> + will not be processed. A significant part of reports are for bugs that
> >>> + have already been fixed, so it is extremely important that vulnerabilities
> >>> + are verified on recent versions (development tree or latest stable
> >>> + version), at least by verifying that the code has not changed since the
> >>> + version where it was detected.
> >>> +
> >>> + * **description of the problem**: a detailed description of the problem, with
> >>> + traces showing its manifestation, and why you consider that the observed
> >>> + behavior as a problem in the kernel, is necessary.
> >>> +
> >>> + * **reproducer**: developers will need to be able to reproduce the problem to
> >>> + consider a fix as effective. This includes both a way to trigger the issue
> >>> + and a way to confirm it happens. A reproducer with low complexity
> >>> + dependencies will be needed (source code, shell script, sequence of
> >>> + instructions, file-system image etc). Binary-only executables are not
> >>> + accepted. Working exploits are extremely helpful and will not be released
> >>> + without consent from the reporter, unless they are already public. By
> >>> + definition if an issue cannot be reproduced, it is not exploitable, thus it
> >>> + is not a security bug.
> >>> +
> >>> + * **conditions**: if the bug depends on certain configuration options,
> >>> + sysctls, permissions, timing, code modifications etc, these should be
> >>> + indicated.
> >>> +
> >>> +In addition, the following information are highly desirable:
> >>> +
> >>> + * **suspected location of the bug**: the file names and functions where the
> >>> + bug is suspected to be present are very important, at least to help forward
> >>> + the report to the appropriate maintainers. When not possible (for example,
> >>> + "system freezes each time I run this command"), the security team will help
> >>> + identify the source of the bug.
> >>> +
> >>> + * **a proposed fix**: bug reporters who have analyzed the cause of a bug in
> >>> + the source code almost always have an accurate idea on how to fix it,
> >>> + because they spent a long time studying it and its implications. Proposing
> >>> + a tested fix will save maintainers a lot of time, even if the fix ends up
> >>> + not being the right one, because it helps understand the bug. When
> >>> + proposing a tested fix, please always format it in a way that can be
> >>> + immediately merged (see :doc:`regular patch submission
> >>> + <../process/submitting-patches>`). This will save some back-and-forth
> >>
> >> Hm, I don't see anything in submitting-patches.rst called "regular patch submission".
> >> Is it in some other patch?
> >
> > Not sure what you mean. Is this supposed to be a sub-section and not just a
> > title ? On https://www.kernel.org/doc/html/latest/process/security-bugs.html
> > it appears as the title. This one was already present in the same document
> > and was moved there without a change.
>
> I see. Sorry for the noise.
No worries, I appreciate your help, the format is not trivial and mistakes
are easy!
Thanks,
Willy
^ permalink raw reply
* Re: [PATCH 3/3] Documentation: clarify the mandatory and desirable info for security reports
From: Randy Dunlap @ 2026-04-02 19:17 UTC (permalink / raw)
To: Willy Tarreau
Cc: greg, edumazet, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel
In-Reply-To: <ac69iG5fihUd82yH@1wt.eu>
On 4/2/26 12:03 PM, Willy Tarreau wrote:
> Hi Randy,
>
> On Thu, Apr 02, 2026 at 11:50:00AM -0700, Randy Dunlap wrote:
>>
>> On 4/2/26 11:26 AM, Willy Tarreau wrote:
>>> A significant part of the effort of the security team consists in begging
>>> reporters for patch proposals, or asking them to provide them in regular
>>> format, and most of the time they're willing to provide this, they just
>>> didn't know that it would help. So let's add a section detailing the
>>> required and desirable contents in a security report to help reporters
>>> write more actionable reports which do not require round trips.
>>>
>>> Cc: Eric Dumazet <edumazet@google.com>
>>> Cc: Greg KH <greg@kroah.com>
>>> Signed-off-by: Willy Tarreau <w@1wt.eu>
>>> ---
>>> Documentation/process/security-bugs.rst | 66 ++++++++++++++++++++++---
>>> 1 file changed, 59 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
>>> index 6937fa9fba5a..b243ac24eb12 100644
>>> --- a/Documentation/process/security-bugs.rst
>>> +++ b/Documentation/process/security-bugs.rst
>>> @@ -7,6 +7,65 @@ Linux kernel developers take security very seriously. As such, we'd
>>> like to know when a security bug is found so that it can be fixed and
>>> disclosed as quickly as possible.
>>>
>>> +Preparing your report
>>> +---------------------
>>> +
>>> +Like with any bug report, a security bug report requires a lot of analysis work
>>> +from the developers, so the more information you can share about the issue, the
>>> +better. Please review the procedure outlined in
>>> +'Documentation/admin-guide/reporting-issues.rst' if you are unclear about what
>>
>> Drop the single quote marks.
>
> I just moved this part as-is, and I've been extremely hesitant to change
> formatting as I can't easily check the validity of the output.
>
>>> +information is helpful. The following information are absolutely necessary in
>>> +**any** security bug report:
>>> +
>>> + * **affected kernel version range**: with no version indication, your report
>>> + will not be processed. A significant part of reports are for bugs that
>>> + have already been fixed, so it is extremely important that vulnerabilities
>>> + are verified on recent versions (development tree or latest stable
>>> + version), at least by verifying that the code has not changed since the
>>> + version where it was detected.
>>> +
>>> + * **description of the problem**: a detailed description of the problem, with
>>> + traces showing its manifestation, and why you consider that the observed
>>> + behavior as a problem in the kernel, is necessary.
>>> +
>>> + * **reproducer**: developers will need to be able to reproduce the problem to
>>> + consider a fix as effective. This includes both a way to trigger the issue
>>> + and a way to confirm it happens. A reproducer with low complexity
>>> + dependencies will be needed (source code, shell script, sequence of
>>> + instructions, file-system image etc). Binary-only executables are not
>>> + accepted. Working exploits are extremely helpful and will not be released
>>> + without consent from the reporter, unless they are already public. By
>>> + definition if an issue cannot be reproduced, it is not exploitable, thus it
>>> + is not a security bug.
>>> +
>>> + * **conditions**: if the bug depends on certain configuration options,
>>> + sysctls, permissions, timing, code modifications etc, these should be
>>> + indicated.
>>> +
>>> +In addition, the following information are highly desirable:
>>> +
>>> + * **suspected location of the bug**: the file names and functions where the
>>> + bug is suspected to be present are very important, at least to help forward
>>> + the report to the appropriate maintainers. When not possible (for example,
>>> + "system freezes each time I run this command"), the security team will help
>>> + identify the source of the bug.
>>> +
>>> + * **a proposed fix**: bug reporters who have analyzed the cause of a bug in
>>> + the source code almost always have an accurate idea on how to fix it,
>>> + because they spent a long time studying it and its implications. Proposing
>>> + a tested fix will save maintainers a lot of time, even if the fix ends up
>>> + not being the right one, because it helps understand the bug. When
>>> + proposing a tested fix, please always format it in a way that can be
>>> + immediately merged (see :doc:`regular patch submission
>>> + <../process/submitting-patches>`). This will save some back-and-forth
>>
>> Hm, I don't see anything in submitting-patches.rst called "regular patch submission".
>> Is it in some other patch?
>
> Not sure what you mean. Is this supposed to be a sub-section and not just a
> title ? On https://www.kernel.org/doc/html/latest/process/security-bugs.html
> it appears as the title. This one was already present in the same document
> and was moved there without a change.
I see. Sorry for the noise.
--
~Randy
^ permalink raw reply
* Re: [PATCH 2/3] Documentation: explain how to find maintainers addresses for security reports
From: Willy Tarreau @ 2026-04-02 19:05 UTC (permalink / raw)
To: Randy Dunlap
Cc: greg, edumazet, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel
In-Reply-To: <e9f0bbe9-fbff-45c8-af99-4c66982bd2cd@infradead.org>
On Thu, Apr 02, 2026 at 11:42:51AM -0700, Randy Dunlap wrote:
>
>
> On 4/2/26 11:26 AM, Willy Tarreau wrote:
> > These days, 80% of the work done by the security team consists in
> > locating the affected subsystem in a report, running get_maintainers on
> > it, forwarding the report to these persons and responding to the reporter
> > with them in Cc. This is a huge and unneeded overhead that we must try to
> > lower for a better overall efficiency. This patch adds a complete section
> > explaining how to figure the list of recipients to send the report to.
> >
> > Cc: Eric Dumazet <edumazet@google.com>
> > Cc: Greg KH <greg@kroah.com>
> > Signed-off-by: Willy Tarreau <w@1wt.eu>
> > ---
> > Documentation/process/security-bugs.rst | 76 ++++++++++++++++++++++++-
> > 1 file changed, 73 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
> > index da7937fd59df..6937fa9fba5a 100644
> > --- a/Documentation/process/security-bugs.rst
> > +++ b/Documentation/process/security-bugs.rst
>
>
> > Markdown, HTML and RST formatted reports are particularly frowned upon since
> > they're quite hard to read for humans and encourage to use dedicated viewers,
> > sometimes online, which by definition is not acceptable for a confidential
> > -security report.
> > +security report. Note that some mailers tend to mangle formatting of plain
> > +text by default, please consult :doc:`the email client howto
> > +<../process/email-clients>` for more info.
>
> Just use the file name and let automarkup do its job:
>
> text by default; please consult Documentation/process/email-clients.rst
> for more information.
>
> It's also more convenient for text readers that way.
If that's supposed to work, I'm indeed all for it! I must confess that
I have not even understood the reason for "../process" when coming from
the same directory, but I just picked that from existing entries.
Thanks for your feedback, much appreciated!
Willy
^ permalink raw reply
* Re: [PATCH 3/3] Documentation: clarify the mandatory and desirable info for security reports
From: Willy Tarreau @ 2026-04-02 19:03 UTC (permalink / raw)
To: Randy Dunlap
Cc: greg, edumazet, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel
In-Reply-To: <18127458-1951-4b44-bcbb-a5747a3b4b6b@infradead.org>
Hi Randy,
On Thu, Apr 02, 2026 at 11:50:00AM -0700, Randy Dunlap wrote:
>
> On 4/2/26 11:26 AM, Willy Tarreau wrote:
> > A significant part of the effort of the security team consists in begging
> > reporters for patch proposals, or asking them to provide them in regular
> > format, and most of the time they're willing to provide this, they just
> > didn't know that it would help. So let's add a section detailing the
> > required and desirable contents in a security report to help reporters
> > write more actionable reports which do not require round trips.
> >
> > Cc: Eric Dumazet <edumazet@google.com>
> > Cc: Greg KH <greg@kroah.com>
> > Signed-off-by: Willy Tarreau <w@1wt.eu>
> > ---
> > Documentation/process/security-bugs.rst | 66 ++++++++++++++++++++++---
> > 1 file changed, 59 insertions(+), 7 deletions(-)
> >
> > diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
> > index 6937fa9fba5a..b243ac24eb12 100644
> > --- a/Documentation/process/security-bugs.rst
> > +++ b/Documentation/process/security-bugs.rst
> > @@ -7,6 +7,65 @@ Linux kernel developers take security very seriously. As such, we'd
> > like to know when a security bug is found so that it can be fixed and
> > disclosed as quickly as possible.
> >
> > +Preparing your report
> > +---------------------
> > +
> > +Like with any bug report, a security bug report requires a lot of analysis work
> > +from the developers, so the more information you can share about the issue, the
> > +better. Please review the procedure outlined in
> > +'Documentation/admin-guide/reporting-issues.rst' if you are unclear about what
>
> Drop the single quote marks.
I just moved this part as-is, and I've been extremely hesitant to change
formatting as I can't easily check the validity of the output.
> > +information is helpful. The following information are absolutely necessary in
> > +**any** security bug report:
> > +
> > + * **affected kernel version range**: with no version indication, your report
> > + will not be processed. A significant part of reports are for bugs that
> > + have already been fixed, so it is extremely important that vulnerabilities
> > + are verified on recent versions (development tree or latest stable
> > + version), at least by verifying that the code has not changed since the
> > + version where it was detected.
> > +
> > + * **description of the problem**: a detailed description of the problem, with
> > + traces showing its manifestation, and why you consider that the observed
> > + behavior as a problem in the kernel, is necessary.
> > +
> > + * **reproducer**: developers will need to be able to reproduce the problem to
> > + consider a fix as effective. This includes both a way to trigger the issue
> > + and a way to confirm it happens. A reproducer with low complexity
> > + dependencies will be needed (source code, shell script, sequence of
> > + instructions, file-system image etc). Binary-only executables are not
> > + accepted. Working exploits are extremely helpful and will not be released
> > + without consent from the reporter, unless they are already public. By
> > + definition if an issue cannot be reproduced, it is not exploitable, thus it
> > + is not a security bug.
> > +
> > + * **conditions**: if the bug depends on certain configuration options,
> > + sysctls, permissions, timing, code modifications etc, these should be
> > + indicated.
> > +
> > +In addition, the following information are highly desirable:
> > +
> > + * **suspected location of the bug**: the file names and functions where the
> > + bug is suspected to be present are very important, at least to help forward
> > + the report to the appropriate maintainers. When not possible (for example,
> > + "system freezes each time I run this command"), the security team will help
> > + identify the source of the bug.
> > +
> > + * **a proposed fix**: bug reporters who have analyzed the cause of a bug in
> > + the source code almost always have an accurate idea on how to fix it,
> > + because they spent a long time studying it and its implications. Proposing
> > + a tested fix will save maintainers a lot of time, even if the fix ends up
> > + not being the right one, because it helps understand the bug. When
> > + proposing a tested fix, please always format it in a way that can be
> > + immediately merged (see :doc:`regular patch submission
> > + <../process/submitting-patches>`). This will save some back-and-forth
>
> Hm, I don't see anything in submitting-patches.rst called "regular patch submission".
> Is it in some other patch?
Not sure what you mean. Is this supposed to be a sub-section and not just a
title ? On https://www.kernel.org/doc/html/latest/process/security-bugs.html
it appears as the title. This one was already present in the same document
and was moved there without a change.
Thanks a lot for your help!
Willy
^ permalink raw reply
* Re: [PATCH 3/3] Documentation: clarify the mandatory and desirable info for security reports
From: Randy Dunlap @ 2026-04-02 18:50 UTC (permalink / raw)
To: Willy Tarreau, greg
Cc: edumazet, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel
In-Reply-To: <20260402182655.8636-4-w@1wt.eu>
On 4/2/26 11:26 AM, Willy Tarreau wrote:
> A significant part of the effort of the security team consists in begging
> reporters for patch proposals, or asking them to provide them in regular
> format, and most of the time they're willing to provide this, they just
> didn't know that it would help. So let's add a section detailing the
> required and desirable contents in a security report to help reporters
> write more actionable reports which do not require round trips.
>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Greg KH <greg@kroah.com>
> Signed-off-by: Willy Tarreau <w@1wt.eu>
> ---
> Documentation/process/security-bugs.rst | 66 ++++++++++++++++++++++---
> 1 file changed, 59 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
> index 6937fa9fba5a..b243ac24eb12 100644
> --- a/Documentation/process/security-bugs.rst
> +++ b/Documentation/process/security-bugs.rst
> @@ -7,6 +7,65 @@ Linux kernel developers take security very seriously. As such, we'd
> like to know when a security bug is found so that it can be fixed and
> disclosed as quickly as possible.
>
> +Preparing your report
> +---------------------
> +
> +Like with any bug report, a security bug report requires a lot of analysis work
> +from the developers, so the more information you can share about the issue, the
> +better. Please review the procedure outlined in
> +'Documentation/admin-guide/reporting-issues.rst' if you are unclear about what
Drop the single quote marks.
> +information is helpful. The following information are absolutely necessary in
> +**any** security bug report:
> +
> + * **affected kernel version range**: with no version indication, your report
> + will not be processed. A significant part of reports are for bugs that
> + have already been fixed, so it is extremely important that vulnerabilities
> + are verified on recent versions (development tree or latest stable
> + version), at least by verifying that the code has not changed since the
> + version where it was detected.
> +
> + * **description of the problem**: a detailed description of the problem, with
> + traces showing its manifestation, and why you consider that the observed
> + behavior as a problem in the kernel, is necessary.
> +
> + * **reproducer**: developers will need to be able to reproduce the problem to
> + consider a fix as effective. This includes both a way to trigger the issue
> + and a way to confirm it happens. A reproducer with low complexity
> + dependencies will be needed (source code, shell script, sequence of
> + instructions, file-system image etc). Binary-only executables are not
> + accepted. Working exploits are extremely helpful and will not be released
> + without consent from the reporter, unless they are already public. By
> + definition if an issue cannot be reproduced, it is not exploitable, thus it
> + is not a security bug.
> +
> + * **conditions**: if the bug depends on certain configuration options,
> + sysctls, permissions, timing, code modifications etc, these should be
> + indicated.
> +
> +In addition, the following information are highly desirable:
> +
> + * **suspected location of the bug**: the file names and functions where the
> + bug is suspected to be present are very important, at least to help forward
> + the report to the appropriate maintainers. When not possible (for example,
> + "system freezes each time I run this command"), the security team will help
> + identify the source of the bug.
> +
> + * **a proposed fix**: bug reporters who have analyzed the cause of a bug in
> + the source code almost always have an accurate idea on how to fix it,
> + because they spent a long time studying it and its implications. Proposing
> + a tested fix will save maintainers a lot of time, even if the fix ends up
> + not being the right one, because it helps understand the bug. When
> + proposing a tested fix, please always format it in a way that can be
> + immediately merged (see :doc:`regular patch submission
> + <../process/submitting-patches>`). This will save some back-and-forth
Hm, I don't see anything in submitting-patches.rst called "regular patch submission".
Is it in some other patch?
> + exchanges if it is accepted, and you will be credited for finding and
> + fixing this issue. Note that in this case only a ``Signed-off-by:`` tag is
> + needed, without ``Reported-by:` when the reporter and author are the same.
--
~Randy
^ permalink raw reply
* Re: [PATCH 2/3] Documentation: explain how to find maintainers addresses for security reports
From: Randy Dunlap @ 2026-04-02 18:42 UTC (permalink / raw)
To: Willy Tarreau, greg
Cc: edumazet, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel
In-Reply-To: <20260402182655.8636-3-w@1wt.eu>
On 4/2/26 11:26 AM, Willy Tarreau wrote:
> These days, 80% of the work done by the security team consists in
> locating the affected subsystem in a report, running get_maintainers on
> it, forwarding the report to these persons and responding to the reporter
> with them in Cc. This is a huge and unneeded overhead that we must try to
> lower for a better overall efficiency. This patch adds a complete section
> explaining how to figure the list of recipients to send the report to.
>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Greg KH <greg@kroah.com>
> Signed-off-by: Willy Tarreau <w@1wt.eu>
> ---
> Documentation/process/security-bugs.rst | 76 ++++++++++++++++++++++++-
> 1 file changed, 73 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
> index da7937fd59df..6937fa9fba5a 100644
> --- a/Documentation/process/security-bugs.rst
> +++ b/Documentation/process/security-bugs.rst
> Markdown, HTML and RST formatted reports are particularly frowned upon since
> they're quite hard to read for humans and encourage to use dedicated viewers,
> sometimes online, which by definition is not acceptable for a confidential
> -security report.
> +security report. Note that some mailers tend to mangle formatting of plain
> +text by default, please consult :doc:`the email client howto
> +<../process/email-clients>` for more info.
Just use the file name and let automarkup do its job:
text by default; please consult Documentation/process/email-clients.rst
for more information.
It's also more convenient for text readers that way.
>
> Disclosure and embargoed information
> ------------------------------------
--
~Randy
^ permalink raw reply
* [PATCH v4 3/3] dpll: zl3073x: implement frequency monitoring
From: Ivan Vecera @ 2026-04-02 18:40 UTC (permalink / raw)
To: netdev
Cc: Petr Oros, Arkadiusz Kubalewski, David S. Miller, Donald Hunter,
Eric Dumazet, Jakub Kicinski, Jiri Pirko, Jonathan Corbet,
Michal Schmidt, Paolo Abeni, Prathosh Satish, Shuah Khan,
Simon Horman, Vadim Fedorenko, linux-doc, linux-kernel
In-Reply-To: <20260402184057.1890514-1-ivecera@redhat.com>
Extract common measurement latch logic from zl3073x_ref_ffo_update()
into a new zl3073x_ref_freq_meas_latch() helper and add
zl3073x_ref_freq_meas_update() that uses it to latch and read absolute
input reference frequencies in Hz.
Add meas_freq field to struct zl3073x_ref and the corresponding
zl3073x_ref_meas_freq_get() accessor. The measured frequencies are
updated periodically alongside the existing FFO measurements.
Add freq_monitor boolean to struct zl3073x_dpll and implement the
freq_monitor_set/get device callbacks to enable/disable frequency
monitoring via the DPLL netlink interface.
Implement measured_freq_get pin callback for input pins that returns the
measured input frequency in mHz.
Reviewed-by: Petr Oros <poros@redhat.com>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
drivers/dpll/zl3073x/core.c | 88 ++++++++++++++++++++++++++-----
drivers/dpll/zl3073x/dpll.c | 100 ++++++++++++++++++++++++++++++++++--
drivers/dpll/zl3073x/dpll.h | 2 +
drivers/dpll/zl3073x/ref.h | 14 +++++
4 files changed, 187 insertions(+), 17 deletions(-)
diff --git a/drivers/dpll/zl3073x/core.c b/drivers/dpll/zl3073x/core.c
index 6363002d48d46..cb47a5db061aa 100644
--- a/drivers/dpll/zl3073x/core.c
+++ b/drivers/dpll/zl3073x/core.c
@@ -632,22 +632,21 @@ int zl3073x_ref_phase_offsets_update(struct zl3073x_dev *zldev, int channel)
}
/**
- * zl3073x_ref_ffo_update - update reference fractional frequency offsets
+ * zl3073x_ref_freq_meas_latch - latch reference frequency measurements
* @zldev: pointer to zl3073x_dev structure
+ * @type: measurement type (ZL_REF_FREQ_MEAS_CTRL_*)
*
- * The function asks device to update fractional frequency offsets latch
- * registers the latest measured values, reads and stores them into
+ * The function waits for the previous measurement to finish, selects all
+ * references and requests a new measurement of the given type.
*
* Return: 0 on success, <0 on error
*/
static int
-zl3073x_ref_ffo_update(struct zl3073x_dev *zldev)
+zl3073x_ref_freq_meas_latch(struct zl3073x_dev *zldev, u8 type)
{
- int i, rc;
+ int rc;
- /* Per datasheet we have to wait for 'ref_freq_meas_ctrl' to be zero
- * to ensure that the measured data are coherent.
- */
+ /* Wait for previous measurement to finish */
rc = zl3073x_poll_zero_u8(zldev, ZL_REG_REF_FREQ_MEAS_CTRL,
ZL_REF_FREQ_MEAS_CTRL);
if (rc)
@@ -663,15 +662,64 @@ zl3073x_ref_ffo_update(struct zl3073x_dev *zldev)
if (rc)
return rc;
- /* Request frequency offset measurement */
- rc = zl3073x_write_u8(zldev, ZL_REG_REF_FREQ_MEAS_CTRL,
- ZL_REF_FREQ_MEAS_CTRL_REF_FREQ_OFF);
+ /* Request measurement */
+ rc = zl3073x_write_u8(zldev, ZL_REG_REF_FREQ_MEAS_CTRL, type);
if (rc)
return rc;
/* Wait for finish */
- rc = zl3073x_poll_zero_u8(zldev, ZL_REG_REF_FREQ_MEAS_CTRL,
- ZL_REF_FREQ_MEAS_CTRL);
+ return zl3073x_poll_zero_u8(zldev, ZL_REG_REF_FREQ_MEAS_CTRL,
+ ZL_REF_FREQ_MEAS_CTRL);
+}
+
+/**
+ * zl3073x_ref_freq_meas_update - update measured input reference frequencies
+ * @zldev: pointer to zl3073x_dev structure
+ *
+ * The function asks device to latch measured input reference frequencies
+ * and stores the results in the ref state.
+ *
+ * Return: 0 on success, <0 on error
+ */
+static int
+zl3073x_ref_freq_meas_update(struct zl3073x_dev *zldev)
+{
+ int i, rc;
+
+ rc = zl3073x_ref_freq_meas_latch(zldev, ZL_REF_FREQ_MEAS_CTRL_REF_FREQ);
+ if (rc)
+ return rc;
+
+ /* Read measured frequencies in Hz (unsigned 32-bit, LSB = 1 Hz) */
+ for (i = 0; i < ZL3073X_NUM_REFS; i++) {
+ u32 value;
+
+ rc = zl3073x_read_u32(zldev, ZL_REG_REF_FREQ(i), &value);
+ if (rc)
+ return rc;
+
+ zldev->ref[i].meas_freq = value;
+ }
+
+ return 0;
+}
+
+/**
+ * zl3073x_ref_ffo_update - update reference fractional frequency offsets
+ * @zldev: pointer to zl3073x_dev structure
+ *
+ * The function asks device to latch the latest measured fractional
+ * frequency offset values, reads and stores them into the ref state.
+ *
+ * Return: 0 on success, <0 on error
+ */
+static int
+zl3073x_ref_ffo_update(struct zl3073x_dev *zldev)
+{
+ int i, rc;
+
+ rc = zl3073x_ref_freq_meas_latch(zldev,
+ ZL_REF_FREQ_MEAS_CTRL_REF_FREQ_OFF);
if (rc)
return rc;
@@ -714,6 +762,20 @@ zl3073x_dev_periodic_work(struct kthread_work *work)
dev_warn(zldev->dev, "Failed to update phase offsets: %pe\n",
ERR_PTR(rc));
+ /* Update measured input reference frequencies if any DPLL has
+ * frequency monitoring enabled.
+ */
+ list_for_each_entry(zldpll, &zldev->dplls, list) {
+ if (zldpll->freq_monitor) {
+ rc = zl3073x_ref_freq_meas_update(zldev);
+ if (rc)
+ dev_warn(zldev->dev,
+ "Failed to update measured frequencies: %pe\n",
+ ERR_PTR(rc));
+ break;
+ }
+ }
+
/* Update references' fractional frequency offsets */
rc = zl3073x_ref_ffo_update(zldev);
if (rc)
diff --git a/drivers/dpll/zl3073x/dpll.c b/drivers/dpll/zl3073x/dpll.c
index a29f606318f6d..d788ca45a17e5 100644
--- a/drivers/dpll/zl3073x/dpll.c
+++ b/drivers/dpll/zl3073x/dpll.c
@@ -39,6 +39,7 @@
* @pin_state: last saved pin state
* @phase_offset: last saved pin phase offset
* @freq_offset: last saved fractional frequency offset
+ * @measured_freq: last saved measured frequency
*/
struct zl3073x_dpll_pin {
struct list_head list;
@@ -54,6 +55,7 @@ struct zl3073x_dpll_pin {
enum dpll_pin_state pin_state;
s64 phase_offset;
s64 freq_offset;
+ u32 measured_freq;
};
/*
@@ -202,6 +204,21 @@ zl3073x_dpll_input_pin_ffo_get(const struct dpll_pin *dpll_pin, void *pin_priv,
return 0;
}
+static int
+zl3073x_dpll_input_pin_measured_freq_get(const struct dpll_pin *dpll_pin,
+ void *pin_priv,
+ const struct dpll_device *dpll,
+ void *dpll_priv, u64 *measured_freq,
+ struct netlink_ext_ack *extack)
+{
+ struct zl3073x_dpll_pin *pin = pin_priv;
+
+ *measured_freq = pin->measured_freq;
+ *measured_freq *= DPLL_PIN_MEASURED_FREQUENCY_DIVIDER;
+
+ return 0;
+}
+
static int
zl3073x_dpll_input_pin_frequency_get(const struct dpll_pin *dpll_pin,
void *pin_priv,
@@ -1116,6 +1133,35 @@ zl3073x_dpll_phase_offset_monitor_set(const struct dpll_device *dpll,
return 0;
}
+static int
+zl3073x_dpll_freq_monitor_get(const struct dpll_device *dpll,
+ void *dpll_priv,
+ enum dpll_feature_state *state,
+ struct netlink_ext_ack *extack)
+{
+ struct zl3073x_dpll *zldpll = dpll_priv;
+
+ if (zldpll->freq_monitor)
+ *state = DPLL_FEATURE_STATE_ENABLE;
+ else
+ *state = DPLL_FEATURE_STATE_DISABLE;
+
+ return 0;
+}
+
+static int
+zl3073x_dpll_freq_monitor_set(const struct dpll_device *dpll,
+ void *dpll_priv,
+ enum dpll_feature_state state,
+ struct netlink_ext_ack *extack)
+{
+ struct zl3073x_dpll *zldpll = dpll_priv;
+
+ zldpll->freq_monitor = (state == DPLL_FEATURE_STATE_ENABLE);
+
+ return 0;
+}
+
static const struct dpll_pin_ops zl3073x_dpll_input_pin_ops = {
.direction_get = zl3073x_dpll_pin_direction_get,
.esync_get = zl3073x_dpll_input_pin_esync_get,
@@ -1123,6 +1169,7 @@ static const struct dpll_pin_ops zl3073x_dpll_input_pin_ops = {
.ffo_get = zl3073x_dpll_input_pin_ffo_get,
.frequency_get = zl3073x_dpll_input_pin_frequency_get,
.frequency_set = zl3073x_dpll_input_pin_frequency_set,
+ .measured_freq_get = zl3073x_dpll_input_pin_measured_freq_get,
.phase_offset_get = zl3073x_dpll_input_pin_phase_offset_get,
.phase_adjust_get = zl3073x_dpll_input_pin_phase_adjust_get,
.phase_adjust_set = zl3073x_dpll_input_pin_phase_adjust_set,
@@ -1151,6 +1198,8 @@ static const struct dpll_device_ops zl3073x_dpll_device_ops = {
.phase_offset_avg_factor_set = zl3073x_dpll_phase_offset_avg_factor_set,
.phase_offset_monitor_get = zl3073x_dpll_phase_offset_monitor_get,
.phase_offset_monitor_set = zl3073x_dpll_phase_offset_monitor_set,
+ .freq_monitor_get = zl3073x_dpll_freq_monitor_get,
+ .freq_monitor_set = zl3073x_dpll_freq_monitor_set,
.supported_modes_get = zl3073x_dpll_supported_modes_get,
};
@@ -1572,6 +1621,7 @@ zl3073x_dpll_pin_ffo_check(struct zl3073x_dpll_pin *pin)
struct zl3073x_dev *zldev = zldpll->dev;
const struct zl3073x_ref *ref;
u8 ref_id;
+ s64 ffo;
/* Get reference monitor status */
ref_id = zl3073x_input_pin_ref_get(pin->id);
@@ -1582,10 +1632,47 @@ zl3073x_dpll_pin_ffo_check(struct zl3073x_dpll_pin *pin)
return false;
/* Compare with previous value */
- if (pin->freq_offset != ref->ffo) {
+ ffo = zl3073x_ref_ffo_get(ref);
+ if (pin->freq_offset != ffo) {
dev_dbg(zldev->dev, "%s freq offset changed: %lld -> %lld\n",
- pin->label, pin->freq_offset, ref->ffo);
- pin->freq_offset = ref->ffo;
+ pin->label, pin->freq_offset, ffo);
+ pin->freq_offset = ffo;
+
+ return true;
+ }
+
+ return false;
+}
+
+/**
+ * zl3073x_dpll_pin_measured_freq_check - check for pin measured frequency
+ * change
+ * @pin: pin to check
+ *
+ * Check for the given pin's measured frequency change.
+ *
+ * Return: true on measured frequency change, false otherwise
+ */
+static bool
+zl3073x_dpll_pin_measured_freq_check(struct zl3073x_dpll_pin *pin)
+{
+ struct zl3073x_dpll *zldpll = pin->dpll;
+ struct zl3073x_dev *zldev = zldpll->dev;
+ const struct zl3073x_ref *ref;
+ u8 ref_id;
+ u32 freq;
+
+ if (!zldpll->freq_monitor)
+ return false;
+
+ ref_id = zl3073x_input_pin_ref_get(pin->id);
+ ref = zl3073x_ref_state_get(zldev, ref_id);
+
+ freq = zl3073x_ref_meas_freq_get(ref);
+ if (pin->measured_freq != freq) {
+ dev_dbg(zldev->dev, "%s measured freq changed: %u -> %u\n",
+ pin->label, pin->measured_freq, freq);
+ pin->measured_freq = freq;
return true;
}
@@ -1677,13 +1764,18 @@ zl3073x_dpll_changes_check(struct zl3073x_dpll *zldpll)
pin_changed = true;
}
- /* Check for phase offset and ffo change once per second */
+ /* Check for phase offset, ffo, and measured freq change
+ * once per second.
+ */
if (zldpll->check_count % 2 == 0) {
if (zl3073x_dpll_pin_phase_offset_check(pin))
pin_changed = true;
if (zl3073x_dpll_pin_ffo_check(pin))
pin_changed = true;
+
+ if (zl3073x_dpll_pin_measured_freq_check(pin))
+ pin_changed = true;
}
if (pin_changed)
diff --git a/drivers/dpll/zl3073x/dpll.h b/drivers/dpll/zl3073x/dpll.h
index 115ee4f67e7ab..434c32a7db123 100644
--- a/drivers/dpll/zl3073x/dpll.h
+++ b/drivers/dpll/zl3073x/dpll.h
@@ -15,6 +15,7 @@
* @id: DPLL index
* @check_count: periodic check counter
* @phase_monitor: is phase offset monitor enabled
+ * @freq_monitor: is frequency monitor enabled
* @ops: DPLL device operations for this instance
* @dpll_dev: pointer to registered DPLL device
* @tracker: tracking object for the acquired reference
@@ -28,6 +29,7 @@ struct zl3073x_dpll {
u8 id;
u8 check_count;
bool phase_monitor;
+ bool freq_monitor;
struct dpll_device_ops ops;
struct dpll_device *dpll_dev;
dpll_tracker tracker;
diff --git a/drivers/dpll/zl3073x/ref.h b/drivers/dpll/zl3073x/ref.h
index 06d8d4d97ea26..be16be20dbc7e 100644
--- a/drivers/dpll/zl3073x/ref.h
+++ b/drivers/dpll/zl3073x/ref.h
@@ -23,6 +23,7 @@ struct zl3073x_dev;
* @sync_ctrl: reference sync control
* @config: reference config
* @ffo: current fractional frequency offset
+ * @meas_freq: measured input frequency in Hz
* @mon_status: reference monitor status
*/
struct zl3073x_ref {
@@ -40,6 +41,7 @@ struct zl3073x_ref {
);
struct_group(stat, /* Status */
s64 ffo;
+ u32 meas_freq;
u8 mon_status;
);
};
@@ -68,6 +70,18 @@ zl3073x_ref_ffo_get(const struct zl3073x_ref *ref)
return ref->ffo;
}
+/**
+ * zl3073x_ref_meas_freq_get - get measured input frequency
+ * @ref: pointer to ref state
+ *
+ * Return: measured input frequency in Hz
+ */
+static inline u32
+zl3073x_ref_meas_freq_get(const struct zl3073x_ref *ref)
+{
+ return ref->meas_freq;
+}
+
/**
* zl3073x_ref_freq_get - get given input reference frequency
* @ref: pointer to ref state
--
2.52.0
^ permalink raw reply related
* [PATCH v4 2/3] dpll: add frequency monitoring callback ops
From: Ivan Vecera @ 2026-04-02 18:40 UTC (permalink / raw)
To: netdev
Cc: Vadim Fedorenko, Arkadiusz Kubalewski, David S. Miller,
Donald Hunter, Eric Dumazet, Jakub Kicinski, Jiri Pirko,
Jonathan Corbet, Michal Schmidt, Paolo Abeni, Petr Oros,
Prathosh Satish, Shuah Khan, Simon Horman, linux-doc,
linux-kernel
In-Reply-To: <20260402184057.1890514-1-ivecera@redhat.com>
Add new callback operations for a dpll device:
- freq_monitor_get(..) - to obtain current state of frequency monitor
feature from dpll device,
- freq_monitor_set(..) - to allow feature configuration.
Add new callback operation for a dpll pin:
- measured_freq_get(..) - to obtain the measured frequency in mHz.
Obtain the feature state value using the get callback and provide it to
the user if the device driver implements callbacks. The measured_freq_get
pin callback is only invoked when the frequency monitor is enabled.
The freq_monitor_get device callback is required when measured_freq_get
is provided by the driver.
Execute the set callback upon user requests.
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
Changes v3 -> v4:
- Moved freq_monitor_{g,s}et validation from netlink to pin
registration with WARN_ON (Vadim)
Changes v2 -> v3:
- Made freq_monitor_get required when measured_freq_get is present (Jakub)
Changes v1 -> v2:
- Renamed actual-frequency to measured-frequency (Vadim)
---
drivers/dpll/dpll_core.c | 5 ++-
drivers/dpll/dpll_netlink.c | 90 +++++++++++++++++++++++++++++++++++++
include/linux/dpll.h | 10 +++++
3 files changed, 104 insertions(+), 1 deletion(-)
diff --git a/drivers/dpll/dpll_core.c b/drivers/dpll/dpll_core.c
index 3f54754cdec4b..cbb635db43210 100644
--- a/drivers/dpll/dpll_core.c
+++ b/drivers/dpll/dpll_core.c
@@ -876,7 +876,10 @@ dpll_pin_register(struct dpll_device *dpll, struct dpll_pin *pin,
if (WARN_ON(!ops) ||
WARN_ON(!ops->state_on_dpll_get) ||
- WARN_ON(!ops->direction_get))
+ WARN_ON(!ops->direction_get) ||
+ WARN_ON(ops->measured_freq_get &&
+ (!dpll_device_ops(dpll)->freq_monitor_get ||
+ !dpll_device_ops(dpll)->freq_monitor_set)))
return -EINVAL;
mutex_lock(&dpll_lock);
diff --git a/drivers/dpll/dpll_netlink.c b/drivers/dpll/dpll_netlink.c
index 83cbd64abf5a4..af7ce62ec55ca 100644
--- a/drivers/dpll/dpll_netlink.c
+++ b/drivers/dpll/dpll_netlink.c
@@ -175,6 +175,26 @@ dpll_msg_add_phase_offset_monitor(struct sk_buff *msg, struct dpll_device *dpll,
return 0;
}
+static int
+dpll_msg_add_freq_monitor(struct sk_buff *msg, struct dpll_device *dpll,
+ struct netlink_ext_ack *extack)
+{
+ const struct dpll_device_ops *ops = dpll_device_ops(dpll);
+ enum dpll_feature_state state;
+ int ret;
+
+ if (ops->freq_monitor_set && ops->freq_monitor_get) {
+ ret = ops->freq_monitor_get(dpll, dpll_priv(dpll),
+ &state, extack);
+ if (ret)
+ return ret;
+ if (nla_put_u32(msg, DPLL_A_FREQUENCY_MONITOR, state))
+ return -EMSGSIZE;
+ }
+
+ return 0;
+}
+
static int
dpll_msg_add_phase_offset_avg_factor(struct sk_buff *msg,
struct dpll_device *dpll,
@@ -400,6 +420,38 @@ static int dpll_msg_add_ffo(struct sk_buff *msg, struct dpll_pin *pin,
ffo);
}
+static int dpll_msg_add_measured_freq(struct sk_buff *msg, struct dpll_pin *pin,
+ struct dpll_pin_ref *ref,
+ struct netlink_ext_ack *extack)
+{
+ const struct dpll_device_ops *dev_ops = dpll_device_ops(ref->dpll);
+ const struct dpll_pin_ops *ops = dpll_pin_ops(ref);
+ struct dpll_device *dpll = ref->dpll;
+ enum dpll_feature_state state;
+ u64 measured_freq;
+ int ret;
+
+ if (!ops->measured_freq_get)
+ return 0;
+ ret = dev_ops->freq_monitor_get(dpll, dpll_priv(dpll),
+ &state, extack);
+ if (ret)
+ return ret;
+ if (state == DPLL_FEATURE_STATE_DISABLE)
+ return 0;
+ ret = ops->measured_freq_get(pin, dpll_pin_on_dpll_priv(dpll, pin),
+ dpll, dpll_priv(dpll), &measured_freq,
+ extack);
+ if (ret)
+ return ret;
+ if (nla_put_64bit(msg, DPLL_A_PIN_MEASURED_FREQUENCY,
+ sizeof(measured_freq), &measured_freq,
+ DPLL_A_PIN_PAD))
+ return -EMSGSIZE;
+
+ return 0;
+}
+
static int
dpll_msg_add_pin_freq(struct sk_buff *msg, struct dpll_pin *pin,
struct dpll_pin_ref *ref, struct netlink_ext_ack *extack)
@@ -670,6 +722,9 @@ dpll_cmd_pin_get_one(struct sk_buff *msg, struct dpll_pin *pin,
if (ret)
return ret;
ret = dpll_msg_add_ffo(msg, pin, ref, extack);
+ if (ret)
+ return ret;
+ ret = dpll_msg_add_measured_freq(msg, pin, ref, extack);
if (ret)
return ret;
ret = dpll_msg_add_pin_esync(msg, pin, ref, extack);
@@ -722,6 +777,9 @@ dpll_device_get_one(struct dpll_device *dpll, struct sk_buff *msg,
if (ret)
return ret;
ret = dpll_msg_add_phase_offset_avg_factor(msg, dpll, extack);
+ if (ret)
+ return ret;
+ ret = dpll_msg_add_freq_monitor(msg, dpll, extack);
if (ret)
return ret;
@@ -948,6 +1006,32 @@ dpll_phase_offset_avg_factor_set(struct dpll_device *dpll, struct nlattr *a,
extack);
}
+static int
+dpll_freq_monitor_set(struct dpll_device *dpll, struct nlattr *a,
+ struct netlink_ext_ack *extack)
+{
+ const struct dpll_device_ops *ops = dpll_device_ops(dpll);
+ enum dpll_feature_state state = nla_get_u32(a), old_state;
+ int ret;
+
+ if (!(ops->freq_monitor_set && ops->freq_monitor_get)) {
+ NL_SET_ERR_MSG_ATTR(extack, a,
+ "dpll device not capable of frequency monitor");
+ return -EOPNOTSUPP;
+ }
+ ret = ops->freq_monitor_get(dpll, dpll_priv(dpll), &old_state,
+ extack);
+ if (ret) {
+ NL_SET_ERR_MSG(extack,
+ "unable to get current state of frequency monitor");
+ return ret;
+ }
+ if (state == old_state)
+ return 0;
+
+ return ops->freq_monitor_set(dpll, dpll_priv(dpll), state, extack);
+}
+
static int
dpll_pin_freq_set(struct dpll_pin *pin, struct nlattr *a,
struct netlink_ext_ack *extack)
@@ -1878,6 +1962,12 @@ dpll_set_from_nlattr(struct dpll_device *dpll, struct genl_info *info)
if (ret)
return ret;
break;
+ case DPLL_A_FREQUENCY_MONITOR:
+ ret = dpll_freq_monitor_set(dpll, a,
+ info->extack);
+ if (ret)
+ return ret;
+ break;
}
}
diff --git a/include/linux/dpll.h b/include/linux/dpll.h
index 2ce295b46b8cd..b7277a8b484d2 100644
--- a/include/linux/dpll.h
+++ b/include/linux/dpll.h
@@ -52,6 +52,12 @@ struct dpll_device_ops {
int (*phase_offset_avg_factor_get)(const struct dpll_device *dpll,
void *dpll_priv, u32 *factor,
struct netlink_ext_ack *extack);
+ int (*freq_monitor_set)(const struct dpll_device *dpll, void *dpll_priv,
+ enum dpll_feature_state state,
+ struct netlink_ext_ack *extack);
+ int (*freq_monitor_get)(const struct dpll_device *dpll, void *dpll_priv,
+ enum dpll_feature_state *state,
+ struct netlink_ext_ack *extack);
};
struct dpll_pin_ops {
@@ -110,6 +116,10 @@ struct dpll_pin_ops {
int (*ffo_get)(const struct dpll_pin *pin, void *pin_priv,
const struct dpll_device *dpll, void *dpll_priv,
s64 *ffo, struct netlink_ext_ack *extack);
+ int (*measured_freq_get)(const struct dpll_pin *pin, void *pin_priv,
+ const struct dpll_device *dpll,
+ void *dpll_priv, u64 *measured_freq,
+ struct netlink_ext_ack *extack);
int (*esync_set)(const struct dpll_pin *pin, void *pin_priv,
const struct dpll_device *dpll, void *dpll_priv,
u64 freq, struct netlink_ext_ack *extack);
--
2.52.0
^ permalink raw reply related
* [PATCH v4 1/3] dpll: add frequency monitoring to netlink spec
From: Ivan Vecera @ 2026-04-02 18:40 UTC (permalink / raw)
To: netdev
Cc: Vadim Fedorenko, Arkadiusz Kubalewski, David S. Miller,
Donald Hunter, Eric Dumazet, Jakub Kicinski, Jiri Pirko,
Jonathan Corbet, Michal Schmidt, Paolo Abeni, Petr Oros,
Prathosh Satish, Shuah Khan, Simon Horman, linux-doc,
linux-kernel
In-Reply-To: <20260402184057.1890514-1-ivecera@redhat.com>
Add DPLL_A_FREQUENCY_MONITOR device attribute to allow control over
the frequency monitor feature. The attribute uses the existing
dpll_feature_state enum (enable/disable) and is present in both
device-get reply and device-set request.
Add DPLL_A_PIN_MEASURED_FREQUENCY pin attribute to expose the measured
input frequency in millihertz (mHz). The attribute is present in the
pin-get reply. Add DPLL_PIN_MEASURED_FREQUENCY_DIVIDER constant to
allow userspace to extract integer and fractional parts.
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
Changes v2 -> v3:
- Improved frequency-monitor doc wording (Jakub)
- Changed measured-frequency to mHz with divider constant (Jakub)
Changes v1 -> v2:
- Renamed actual-frequency to measured-frequency (Vadim)
---
Documentation/driver-api/dpll.rst | 20 +++++++++++++++
Documentation/netlink/specs/dpll.yaml | 35 +++++++++++++++++++++++++++
drivers/dpll/dpll_nl.c | 5 ++--
include/uapi/linux/dpll.h | 5 +++-
4 files changed, 62 insertions(+), 3 deletions(-)
diff --git a/Documentation/driver-api/dpll.rst b/Documentation/driver-api/dpll.rst
index 83118c728ed90..93c191b2d0898 100644
--- a/Documentation/driver-api/dpll.rst
+++ b/Documentation/driver-api/dpll.rst
@@ -250,6 +250,24 @@ in the ``DPLL_A_PIN_PHASE_OFFSET`` attribute.
``DPLL_A_PHASE_OFFSET_MONITOR`` attr state of a feature
=============================== ========================
+Frequency monitor
+=================
+
+Some DPLL devices may offer the capability to measure the actual
+frequency of all available input pins. The attribute and current feature state
+shall be included in the response message of the ``DPLL_CMD_DEVICE_GET``
+command for supported DPLL devices. In such cases, users can also control
+the feature using the ``DPLL_CMD_DEVICE_SET`` command by setting the
+``enum dpll_feature_state`` values for the attribute.
+Once enabled the measured input frequency for each input pin shall be
+returned in the ``DPLL_A_PIN_MEASURED_FREQUENCY`` attribute. The value
+is in millihertz (mHz), using ``DPLL_PIN_MEASURED_FREQUENCY_DIVIDER``
+as the divider.
+
+ =============================== ========================
+ ``DPLL_A_FREQUENCY_MONITOR`` attr state of a feature
+ =============================== ========================
+
Embedded SYNC
=============
@@ -411,6 +429,8 @@ according to attribute purpose.
``DPLL_A_PIN_STATE`` attr state of pin on the parent
pin
``DPLL_A_PIN_CAPABILITIES`` attr bitmask of pin capabilities
+ ``DPLL_A_PIN_MEASURED_FREQUENCY`` attr measured frequency of
+ an input pin in mHz
==================================== ==================================
==================================== =================================
diff --git a/Documentation/netlink/specs/dpll.yaml b/Documentation/netlink/specs/dpll.yaml
index 3dd48a32f7837..40465a3d7fc20 100644
--- a/Documentation/netlink/specs/dpll.yaml
+++ b/Documentation/netlink/specs/dpll.yaml
@@ -240,6 +240,20 @@ definitions:
integer part of a measured phase offset value.
Value of (DPLL_A_PHASE_OFFSET % DPLL_PHASE_OFFSET_DIVIDER) is a
fractional part of a measured phase offset value.
+ -
+ type: const
+ name: pin-measured-frequency-divider
+ value: 1000
+ doc: |
+ pin measured frequency divider allows userspace to calculate
+ a value of measured input frequency as a fractional value with
+ three digit decimal precision (millihertz).
+ Value of (DPLL_A_PIN_MEASURED_FREQUENCY /
+ DPLL_PIN_MEASURED_FREQUENCY_DIVIDER) is an integer part of
+ a measured frequency value.
+ Value of (DPLL_A_PIN_MEASURED_FREQUENCY %
+ DPLL_PIN_MEASURED_FREQUENCY_DIVIDER) is a fractional part of
+ a measured frequency value.
-
type: enum
name: feature-state
@@ -319,6 +333,13 @@ attribute-sets:
name: phase-offset-avg-factor
type: u32
doc: Averaging factor applied to calculation of reported phase offset.
+ -
+ name: frequency-monitor
+ type: u32
+ enum: feature-state
+ doc: Current or desired state of the frequency monitor feature.
+ If enabled, dpll device shall measure all currently available
+ inputs for their actual input frequency.
-
name: pin
enum-name: dpll_a_pin
@@ -456,6 +477,17 @@ attribute-sets:
Value is in PPT (parts per trillion, 10^-12).
Note: This attribute provides higher resolution than the standard
fractional-frequency-offset (which is in PPM).
+ -
+ name: measured-frequency
+ type: u64
+ doc: |
+ The measured frequency of the input pin in millihertz (mHz).
+ Value of (DPLL_A_PIN_MEASURED_FREQUENCY /
+ DPLL_PIN_MEASURED_FREQUENCY_DIVIDER) is an integer part (Hz)
+ of a measured frequency value.
+ Value of (DPLL_A_PIN_MEASURED_FREQUENCY %
+ DPLL_PIN_MEASURED_FREQUENCY_DIVIDER) is a fractional part
+ of a measured frequency value.
-
name: pin-parent-device
@@ -544,6 +576,7 @@ operations:
- type
- phase-offset-monitor
- phase-offset-avg-factor
+ - frequency-monitor
dump:
reply: *dev-attrs
@@ -563,6 +596,7 @@ operations:
- mode
- phase-offset-monitor
- phase-offset-avg-factor
+ - frequency-monitor
-
name: device-create-ntf
doc: Notification about device appearing
@@ -643,6 +677,7 @@ operations:
- esync-frequency-supported
- esync-pulse
- reference-sync
+ - measured-frequency
dump:
request:
diff --git a/drivers/dpll/dpll_nl.c b/drivers/dpll/dpll_nl.c
index a2b22d4921142..1e652340a5d73 100644
--- a/drivers/dpll/dpll_nl.c
+++ b/drivers/dpll/dpll_nl.c
@@ -43,11 +43,12 @@ static const struct nla_policy dpll_device_get_nl_policy[DPLL_A_ID + 1] = {
};
/* DPLL_CMD_DEVICE_SET - do */
-static const struct nla_policy dpll_device_set_nl_policy[DPLL_A_PHASE_OFFSET_AVG_FACTOR + 1] = {
+static const struct nla_policy dpll_device_set_nl_policy[DPLL_A_FREQUENCY_MONITOR + 1] = {
[DPLL_A_ID] = { .type = NLA_U32, },
[DPLL_A_MODE] = NLA_POLICY_RANGE(NLA_U32, 1, 2),
[DPLL_A_PHASE_OFFSET_MONITOR] = NLA_POLICY_MAX(NLA_U32, 1),
[DPLL_A_PHASE_OFFSET_AVG_FACTOR] = { .type = NLA_U32, },
+ [DPLL_A_FREQUENCY_MONITOR] = NLA_POLICY_MAX(NLA_U32, 1),
};
/* DPLL_CMD_PIN_ID_GET - do */
@@ -115,7 +116,7 @@ static const struct genl_split_ops dpll_nl_ops[] = {
.doit = dpll_nl_device_set_doit,
.post_doit = dpll_post_doit,
.policy = dpll_device_set_nl_policy,
- .maxattr = DPLL_A_PHASE_OFFSET_AVG_FACTOR,
+ .maxattr = DPLL_A_FREQUENCY_MONITOR,
.flags = GENL_ADMIN_PERM | GENL_CMD_CAP_DO,
},
{
diff --git a/include/uapi/linux/dpll.h b/include/uapi/linux/dpll.h
index de0005f28e5c5..871685f7c353b 100644
--- a/include/uapi/linux/dpll.h
+++ b/include/uapi/linux/dpll.h
@@ -191,7 +191,8 @@ enum dpll_pin_capabilities {
DPLL_PIN_CAPABILITIES_STATE_CAN_CHANGE = 4,
};
-#define DPLL_PHASE_OFFSET_DIVIDER 1000
+#define DPLL_PHASE_OFFSET_DIVIDER 1000
+#define DPLL_PIN_MEASURED_FREQUENCY_DIVIDER 1000
/**
* enum dpll_feature_state - Allow control (enable/disable) and status checking
@@ -218,6 +219,7 @@ enum dpll_a {
DPLL_A_CLOCK_QUALITY_LEVEL,
DPLL_A_PHASE_OFFSET_MONITOR,
DPLL_A_PHASE_OFFSET_AVG_FACTOR,
+ DPLL_A_FREQUENCY_MONITOR,
__DPLL_A_MAX,
DPLL_A_MAX = (__DPLL_A_MAX - 1)
@@ -254,6 +256,7 @@ enum dpll_a_pin {
DPLL_A_PIN_REFERENCE_SYNC,
DPLL_A_PIN_PHASE_ADJUST_GRAN,
DPLL_A_PIN_FRACTIONAL_FREQUENCY_OFFSET_PPT,
+ DPLL_A_PIN_MEASURED_FREQUENCY,
__DPLL_A_PIN_MAX,
DPLL_A_PIN_MAX = (__DPLL_A_PIN_MAX - 1)
--
2.52.0
^ permalink raw reply related
* [PATCH v4 0/3] dpll: add frequency monitoring feature
From: Ivan Vecera @ 2026-04-02 18:40 UTC (permalink / raw)
To: netdev
Cc: Arkadiusz Kubalewski, David S. Miller, Donald Hunter,
Eric Dumazet, Jakub Kicinski, Jiri Pirko, Jonathan Corbet,
Michal Schmidt, Paolo Abeni, Petr Oros, Prathosh Satish,
Shuah Khan, Simon Horman, Vadim Fedorenko, linux-doc,
linux-kernel
This series adds support for monitoring the measured input frequency
of DPLL input pins via the DPLL netlink interface.
Some DPLL devices can measure the actual frequency being received on
input pins. The approach mirrors the existing phase-offset-monitor
feature: a device-level attribute (DPLL_A_FREQUENCY_MONITOR) enables
or disables monitoring, and a per-pin attribute
(DPLL_A_PIN_MEASURED_FREQUENCY) exposes the measured frequency in
millihertz (mHz) when monitoring is enabled.
Patch 1 adds the new attributes to the DPLL netlink spec (dpll.yaml),
the DPLL_PIN_MEASURED_FREQUENCY_DIVIDER constant, regenerates the
auto-generated UAPI header and netlink policy, and updates
Documentation/driver-api/dpll.rst.
Patch 2 adds the callback operations (freq_monitor_get/set for
devices, measured_freq_get for pins) and the corresponding netlink
GET/SET handlers in the DPLL core. The core only invokes
measured_freq_get when the frequency monitor is enabled on the parent
device. The freq_monitor_get callback is required when measured_freq_get
is provided.
Patch 3 implements the feature in the ZL3073x driver by extracting
a common measurement latch helper from the existing FFO update path,
adding a frequency measurement function, and wiring up the new
callbacks.
Changes v3 -> v4:
- Moved freq_monitor_{g,s}et validation from netlink to pin
registration with WARN_ON (Vadim)
Changes v2 -> v3:
- Improved frequency-monitor doc wording (Jakub)
- Changed measured-frequency to mHz with divider constant (Jakub)
- Made freq_monitor_get required when measured_freq_get is present (Jakub)
Changes v1 -> v2:
- Renamed actual-frequency to measured-frequency (Vadim)
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Ivan Vecera (3):
dpll: add frequency monitoring to netlink spec
dpll: add frequency monitoring callback ops
dpll: zl3073x: implement frequency monitoring
Documentation/driver-api/dpll.rst | 20 ++++++
Documentation/netlink/specs/dpll.yaml | 35 +++++++++
drivers/dpll/dpll_core.c | 5 +-
drivers/dpll/dpll_netlink.c | 90 +++++++++++++++++++++++
drivers/dpll/dpll_nl.c | 5 +-
drivers/dpll/zl3073x/core.c | 88 +++++++++++++++++++----
drivers/dpll/zl3073x/dpll.c | 100 ++++++++++++++++++++++++--
drivers/dpll/zl3073x/dpll.h | 2 +
drivers/dpll/zl3073x/ref.h | 14 ++++
include/linux/dpll.h | 10 +++
include/uapi/linux/dpll.h | 5 +-
11 files changed, 353 insertions(+), 21 deletions(-)
--
2.52.0
^ permalink raw reply
* Re: [PATCH v7 4/4] RISC-V: KVM: add KVM_CAP_RISCV_SET_HGATP_MODE
From: Radim Krčmář @ 2026-04-02 18:27 UTC (permalink / raw)
To: fangyu.yu, pbonzini, corbet, anup, atish.patra, pjw, palmer, aou,
alex, skhan
Cc: guoren, andrew.jones, linux-doc, kvm, kvm-riscv, linux-riscv,
linux-kernel
In-Reply-To: <20260402132303.6252-5-fangyu.yu@linux.alibaba.com>
2026-04-02T21:23:03+08:00, <fangyu.yu@linux.alibaba.com>:
> From: Fangyu Yu <fangyu.yu@linux.alibaba.com>
>
> Add a VM capability that allows userspace to select the G-stage page table
> format by setting HGATP.MODE on a per-VM basis.
>
> Userspace enables the capability via KVM_ENABLE_CAP, passing the requested
> HGATP.MODE in args[0]. The request is rejected with -EINVAL if the mode is
> not supported by the host, and with -EBUSY if the VM has already been
> committed (e.g. vCPUs have been created or any memslot is populated).
>
> KVM_CHECK_EXTENSION(KVM_CAP_RISCV_SET_HGATP_MODE) returns a bitmask of the
> HGATP.MODE formats supported by the host.
>
> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com>
> Reviewed-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
> Reviewed-by: Guo Ren <guoren@kernel.org>
> ---
> diff --git a/arch/riscv/kvm/vm.c b/arch/riscv/kvm/vm.c
> @@ -211,12 +214,23 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>
> int kvm_vm_ioctl_enable_cap(struct kvm *kvm, struct kvm_enable_cap *cap)
> {
> + case KVM_CAP_RISCV_SET_HGATP_MODE:
> + if (!kvm_riscv_hgatp_mode_is_valid(cap->args[0]))
> + return -EINVAL;
> +
> + if (kvm->created_vcpus || !kvm_are_all_memslots_empty(kvm))
> + return -EBUSY;
Since multiple VM ioctls can execute concurrently, I would protect
created_vcpus by kvm->lock and kvm_are_all_memslots_empty by
kvm->slots_lock.
Thanks.
^ permalink raw reply
* [PATCH 0/3] Documentation: clarify required info in security reports
From: Willy Tarreau @ 2026-04-02 18:26 UTC (permalink / raw)
To: greg
Cc: edumazet, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel, Willy Tarreau
Hi Greg,
I'm sending you the doc clarifications we discussed for the process of
reporting security issues. It's cut into the 3 patches I shared this
morning on the security list (plus two typos fixed and a paragraph
asking for one single issue per report):
- one patch that reminds our need for a valid e-mail address
- one that explains to reporters how to proceed to find maintainers
addresses, hoping we won't have to do it for 90% of reports anymore
- one that enumerates basic requirements for every report
I think it covers the difficulties we've faced this week. As always,
we might possibly find tiny adjustments to add, but my goal would be
for such updates to be merged in time to update the public page ASAP
so that we can redirect incomplete reports in an attempt to lower the
team's current load.
Thanks!
Willy
---
Willy Tarreau (3):
Documentation: minor updates to the security contacts
Documentation: explain how to find maintainers addresses for security
reports
Documentation: clarify the mandatory and desirable info for security
reports
Documentation/process/security-bugs.rst | 147 +++++++++++++++++++++---
1 file changed, 132 insertions(+), 15 deletions(-)
--
2.52.0
^ permalink raw reply
* [PATCH 3/3] Documentation: clarify the mandatory and desirable info for security reports
From: Willy Tarreau @ 2026-04-02 18:26 UTC (permalink / raw)
To: greg
Cc: edumazet, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel, Willy Tarreau
In-Reply-To: <20260402182655.8636-1-w@1wt.eu>
A significant part of the effort of the security team consists in begging
reporters for patch proposals, or asking them to provide them in regular
format, and most of the time they're willing to provide this, they just
didn't know that it would help. So let's add a section detailing the
required and desirable contents in a security report to help reporters
write more actionable reports which do not require round trips.
Cc: Eric Dumazet <edumazet@google.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
Documentation/process/security-bugs.rst | 66 ++++++++++++++++++++++---
1 file changed, 59 insertions(+), 7 deletions(-)
diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index 6937fa9fba5a..b243ac24eb12 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -7,6 +7,65 @@ Linux kernel developers take security very seriously. As such, we'd
like to know when a security bug is found so that it can be fixed and
disclosed as quickly as possible.
+Preparing your report
+---------------------
+
+Like with any bug report, a security bug report requires a lot of analysis work
+from the developers, so the more information you can share about the issue, the
+better. Please review the procedure outlined in
+'Documentation/admin-guide/reporting-issues.rst' if you are unclear about what
+information is helpful. The following information are absolutely necessary in
+**any** security bug report:
+
+ * **affected kernel version range**: with no version indication, your report
+ will not be processed. A significant part of reports are for bugs that
+ have already been fixed, so it is extremely important that vulnerabilities
+ are verified on recent versions (development tree or latest stable
+ version), at least by verifying that the code has not changed since the
+ version where it was detected.
+
+ * **description of the problem**: a detailed description of the problem, with
+ traces showing its manifestation, and why you consider that the observed
+ behavior as a problem in the kernel, is necessary.
+
+ * **reproducer**: developers will need to be able to reproduce the problem to
+ consider a fix as effective. This includes both a way to trigger the issue
+ and a way to confirm it happens. A reproducer with low complexity
+ dependencies will be needed (source code, shell script, sequence of
+ instructions, file-system image etc). Binary-only executables are not
+ accepted. Working exploits are extremely helpful and will not be released
+ without consent from the reporter, unless they are already public. By
+ definition if an issue cannot be reproduced, it is not exploitable, thus it
+ is not a security bug.
+
+ * **conditions**: if the bug depends on certain configuration options,
+ sysctls, permissions, timing, code modifications etc, these should be
+ indicated.
+
+In addition, the following information are highly desirable:
+
+ * **suspected location of the bug**: the file names and functions where the
+ bug is suspected to be present are very important, at least to help forward
+ the report to the appropriate maintainers. When not possible (for example,
+ "system freezes each time I run this command"), the security team will help
+ identify the source of the bug.
+
+ * **a proposed fix**: bug reporters who have analyzed the cause of a bug in
+ the source code almost always have an accurate idea on how to fix it,
+ because they spent a long time studying it and its implications. Proposing
+ a tested fix will save maintainers a lot of time, even if the fix ends up
+ not being the right one, because it helps understand the bug. When
+ proposing a tested fix, please always format it in a way that can be
+ immediately merged (see :doc:`regular patch submission
+ <../process/submitting-patches>`). This will save some back-and-forth
+ exchanges if it is accepted, and you will be credited for finding and
+ fixing this issue. Note that in this case only a ``Signed-off-by:`` tag is
+ needed, without ``Reported-by:` when the reporter and author are the same.
+
+ * **mitigations**: very often during a bug analysis, some ways of mitigating
+ the issue appear. It is useful to share them, as they can be helpful to
+ keep end users protected during the time it takes them to apply the fix.
+
Identifying contacts
--------------------
@@ -89,13 +148,6 @@ run additional tests. Reports where the reporter does not respond promptly
or cannot effectively discuss their findings may be abandoned if the
communication does not quickly improve.
-As it is with any bug, the more information provided the easier it
-will be to diagnose and fix. Please review the procedure outlined in
-'Documentation/admin-guide/reporting-issues.rst' if you are unclear about what
-information is helpful. Any exploit code is very helpful and will not
-be released without consent from the reporter unless it has already been
-made public.
-
The report must be sent to maintainers, with the security team in ``Cc:``.
The Linux kernel security team can be contacted by email at
<security@kernel.org>. This is a private list of security officers
--
2.52.0
^ permalink raw reply related
* [PATCH 2/3] Documentation: explain how to find maintainers addresses for security reports
From: Willy Tarreau @ 2026-04-02 18:26 UTC (permalink / raw)
To: greg
Cc: edumazet, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel, Willy Tarreau
In-Reply-To: <20260402182655.8636-1-w@1wt.eu>
These days, 80% of the work done by the security team consists in
locating the affected subsystem in a report, running get_maintainers on
it, forwarding the report to these persons and responding to the reporter
with them in Cc. This is a huge and unneeded overhead that we must try to
lower for a better overall efficiency. This patch adds a complete section
explaining how to figure the list of recipients to send the report to.
Cc: Eric Dumazet <edumazet@google.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
Documentation/process/security-bugs.rst | 76 ++++++++++++++++++++++++-
1 file changed, 73 insertions(+), 3 deletions(-)
diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index da7937fd59df..6937fa9fba5a 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -5,8 +5,75 @@ Security bugs
Linux kernel developers take security very seriously. As such, we'd
like to know when a security bug is found so that it can be fixed and
-disclosed as quickly as possible. Please report security bugs to the
-Linux kernel security team.
+disclosed as quickly as possible.
+
+Identifying contacts
+--------------------
+
+The most effective way to report a security bug is to send it directly to the
+affected subsystem's maintainers and Cc: the Linux kernel security team. Do
+not send it to a public list at this stage, unless you have good reasons to
+consider the issue as being public or trivial to discover (e.g. result of a
+widely available automated vulnerability scanning tool that can be repeated by
+anyone).
+
+If you're sending a report for issues affecting multiple parts in the kernel,
+even if they're fairly similar issues, please send individual messages (think
+that maintainers will not all work on the issues at the same time). The only
+exception is when an issue concerns closely related parts maintained by the
+exact same subset of maintainers, and these parts are expected to be fixed all
+at once by the same commit, then it may be acceptable to report them at once.
+
+One difficulty for most first-time reporters is to figure the right list of
+recipients to send a report to. In the Linux kernel, all official maintainers
+are trusted, so the consequences of accidentally including the wrong maintainer
+are essentially a bit more noise for that person, i.e. nothing dramatic. As
+such, a suitable method to figure the list of maintainers (which kernel
+security officers use) is to rely on the get_maintainers.pl script, tuned to
+only report maintainers. This script, when passed a file name, will look for
+its path in the MAINTAINERS file to figure a hierarchical list of relevant
+maintainers. Calling it a first time with the finest level of filtering will
+most of the time return a short list of this specific file's maintainers::
+
+ $ ./scripts/get_maintainer.pl --no-l --no-r --pattern-depth 1 \
+ drivers/example.c
+ Developer One <dev1@example.com> (maintainer:example driver)
+ Developer Two <dev2@example.org> (maintainer:example driver)
+
+These two maintainers should then receive the message. If the command does not
+return anything, it means the affected file is part of a wider subsystem, so we
+should be less specific::
+
+ $ ./scripts/get_maintainer.pl --no-l --no-r drivers/example.c
+ Developer One <dev1@example.com> (maintainer:example subsystem)
+ Developer Two <dev2@example.org> (maintainer:example subsystem)
+ Developer Three <dev3@example.com> (maintainer:example subsystem [GENERAL])
+ Developer Four <dev4@example.org> (maintainer:example subsystem [GENERAL])
+
+Here, picking the first, most specific ones, is sufficient. When the list is
+long, it is possible to produce a comma-delimited e-mail address list on a
+single line suitable for use in the To: field of a mailer like this::
+
+ $ ./scripts/get_maintainer.pl --no-tree --no-l --no-r --no-n --m \
+ --no-git-fallback --no-substatus --no-rolestats --no-multiline \
+ --pattern-depth 1 drivers/example.c
+ dev1@example.com, dev2@example.org
+
+or this for the wider list::
+
+ $ ./scripts/get_maintainer.pl --no-tree --no-l --no-r --no-n --m \
+ --no-git-fallback --no-substatus --no-rolestats --no-multiline \
+ drivers/example.c
+ dev1@example.com, dev2@example.org, dev3@example.com, dev4@example.org
+
+If at this point you're still facing difficulties spotting the right
+maintainers, **and only in this case**, it's possible to send your report to
+the Linux kernel security team only. Your message will be triaged, and you
+will receive instructions about whom to contact, if needed. Your message may
+equally be forwarded as-is to the relevant maintainers.
+
+Sending the report
+------------------
Reports are to be sent over e-mail exclusively. Please use a working e-mail
address, preferably the same that you want to appear in ``Reported-by`` tags
@@ -29,6 +96,7 @@ information is helpful. Any exploit code is very helpful and will not
be released without consent from the reporter unless it has already been
made public.
+The report must be sent to maintainers, with the security team in ``Cc:``.
The Linux kernel security team can be contacted by email at
<security@kernel.org>. This is a private list of security officers
who will help verify the bug report and assist developers working on a fix.
@@ -44,7 +112,9 @@ reproduction steps, and follow it with a proposed fix, all in plain text.
Markdown, HTML and RST formatted reports are particularly frowned upon since
they're quite hard to read for humans and encourage to use dedicated viewers,
sometimes online, which by definition is not acceptable for a confidential
-security report.
+security report. Note that some mailers tend to mangle formatting of plain
+text by default, please consult :doc:`the email client howto
+<../process/email-clients>` for more info.
Disclosure and embargoed information
------------------------------------
--
2.52.0
^ permalink raw reply related
* [PATCH 1/3] Documentation: minor updates to the security contacts
From: Willy Tarreau @ 2026-04-02 18:26 UTC (permalink / raw)
To: greg
Cc: edumazet, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel, Willy Tarreau
In-Reply-To: <20260402182655.8636-1-w@1wt.eu>
This clarifies the fact that the bug reporters must use a valid
e-mail address to send their report, and that the security team
assists developers working on a fix but doesn't always produce
fixes on its own.
Cc: Eric Dumazet <edumazet@google.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
Documentation/process/security-bugs.rst | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index c0cf93e11565..da7937fd59df 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -8,6 +8,10 @@ like to know when a security bug is found so that it can be fixed and
disclosed as quickly as possible. Please report security bugs to the
Linux kernel security team.
+Reports are to be sent over e-mail exclusively. Please use a working e-mail
+address, preferably the same that you want to appear in ``Reported-by`` tags
+if any. If unsure, send your report to yourself first.
+
The security team and maintainers almost always require additional
information beyond what was initially provided in a report and rely on
active and efficient collaboration with the reporter to perform further
@@ -27,11 +31,9 @@ made public.
The Linux kernel security team can be contacted by email at
<security@kernel.org>. This is a private list of security officers
-who will help verify the bug report and develop and release a fix.
-If you already have a fix, please include it with your report, as
-that can speed up the process considerably. It is possible that the
-security team will bring in extra help from area maintainers to
-understand and fix the security vulnerability.
+who will help verify the bug report and assist developers working on a fix.
+It is possible that the security team will bring in extra help from area
+maintainers to understand and fix the security vulnerability.
Please send **plain text** emails without attachments where possible.
It is much harder to have a context-quoted discussion about a complex
--
2.52.0
^ permalink raw reply related
* Re: [PATCH v7 3/4] RISC-V: KVM: Detect and expose supported HGATP G-stage modes
From: Radim Krčmář @ 2026-04-02 18:19 UTC (permalink / raw)
To: fangyu.yu, pbonzini, corbet, anup, atish.patra, pjw, palmer, aou,
alex, skhan
Cc: guoren, andrew.jones, linux-doc, kvm, kvm-riscv, linux-riscv,
linux-kernel
In-Reply-To: <20260402132303.6252-4-fangyu.yu@linux.alibaba.com>
2026-04-02T21:23:02+08:00, <fangyu.yu@linux.alibaba.com>:
> From: Fangyu Yu <fangyu.yu@linux.alibaba.com>
>
> Extend kvm_riscv_gstage_mode_detect() to record HGATP.MODE values 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>
> Reviewed-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
> Reviewed-by: Guo Ren <guoren@kernel.org>
> ---
> diff --git a/arch/riscv/include/asm/kvm_gstage.h b/arch/riscv/include/asm/kvm_gstage.h
> @@ -102,4 +103,14 @@ static inline void kvm_riscv_gstage_init(struct kvm_gstage *gstage, struct kvm *
> +static inline bool kvm_riscv_hgatp_mode_is_valid(unsigned long mode)
> +{
> + return kvm_riscv_gstage_supported_mode_mask & BIT(mode);
Shifting by more than the bit width is undefined behavior in C.
RV64 effectively translates BIT(mode) to 1UL << (mode & 0x3f), so this
could allow values larger than the mask.
Thanks.
^ permalink raw reply
* Re: [PATCH v7 1/4] RISC-V: KVM: Support runtime configuration for per-VM's HGATP mode
From: Radim Krčmář @ 2026-04-02 18:03 UTC (permalink / raw)
To: fangyu.yu, pbonzini, corbet, anup, atish.patra, pjw, palmer, aou,
alex, skhan
Cc: guoren, andrew.jones, linux-doc, kvm, kvm-riscv, linux-riscv,
linux-kernel
In-Reply-To: <20260402132303.6252-2-fangyu.yu@linux.alibaba.com>
2026-04-02T21:23:00+08:00, <fangyu.yu@linux.alibaba.com>:
> From: Fangyu Yu <fangyu.yu@linux.alibaba.com>
>
> Introduces one per-VM architecture-specific fields to support runtime
> configuration of the G-stage page table format:
>
> - kvm->arch.pgd_levels: the corresponding number of page table levels
> for the selected mode.
>
> These fields replace the previous global variables
> kvm_riscv_gstage_mode and kvm_riscv_gstage_pgd_levels, enabling different
> virtual machines to independently select their G-stage page table format
> instead of being forced to share the maximum mode detected by the kernel
> at boot time.
>
> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com>
> Reviewed-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
> Reviewed-by: Anup Patel <anup@brainfault.org>
> Reviewed-by: Guo Ren <guoren@kernel.org>
> ---
> diff --git a/arch/riscv/kvm/vm.c b/arch/riscv/kvm/vm.c
> @@ -199,7 +199,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> r = KVM_USER_MEM_SLOTS;
> break;
> case KVM_CAP_VM_GPA_BITS:
> - r = kvm_riscv_gstage_gpa_bits;
> + r = kvm_riscv_gstage_gpa_bits(kvm->arch.pgd_levels);
kvm_vm_ioctl_check_extension() also gets called from with kvm == NULL
from kvm_dev_ioctl(). I think we can continue to return
...(kvm_riscv_gstage_max_pgd_levels) in that case.
Thanks.
^ permalink raw reply
* Re: [PATCH v8 2/3] hwmon: ltc4283: Add support for the LTC4283 Swap Controller
From: Nuno Sá @ 2026-04-02 17:12 UTC (permalink / raw)
To: Guenter Roeck
Cc: Nuno Sá, linux-gpio, linux-hwmon, devicetree, linux-doc,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Linus Walleij, Bartosz Golaszewski
In-Reply-To: <32c4c4dc-91db-4286-82e5-1d3269c76a74@roeck-us.net>
On Tue, Mar 31, 2026 at 06:31:59AM -0700, Guenter Roeck wrote:
> On 3/31/26 02:48, Nuno Sá wrote:
> > On Mon, Mar 30, 2026 at 08:47:32AM -0700, Guenter Roeck wrote:
> > > On 3/30/26 02:28, Nuno Sá wrote:
> > > > Hi Guenter, Regarding AI review, I think most of the points were
> > > > discussed in previous revisions, but there are two valid.
> > > >
> > > > On Fri, Mar 27, 2026 at 05:26:15PM +0000, Nuno Sá wrote:
> > > > > Support the LTC4283 Hot Swap Controller. The device features programmable
> > > > > current limit with foldback and independently adjustable inrush current to
> > > > > optimize the MOSFET safe operating area (SOA). The SOA timer limits MOSFET
> > > > > temperature rise for reliable protection against overstresses.
> > > > >
> > > > > An I2C interface and onboard ADC allow monitoring of board current,
> > > > > voltage, power, energy, and fault status.
> > > > >
> > > > > Signed-off-by: Nuno Sá <nuno.sa@analog.com>
> > > > > ---
> > > > > Documentation/hwmon/index.rst | 1 +
> > > > > Documentation/hwmon/ltc4283.rst | 266 ++++++
> > > > > MAINTAINERS | 1 +
> > > > > drivers/hwmon/Kconfig | 12 +
> > > > > drivers/hwmon/Makefile | 1 +
> > > > > drivers/hwmon/ltc4283.c | 1796 +++++++++++++++++++++++++++++++++++++++
> > > > > 6 files changed, 2077 insertions(+)
> > > > >
> > > >
> > > > ...
> > > >
> > > > > +static int ltc4283_read_in_alarm(struct ltc4283_hwmon *st, u32 channel,
> > > > > + bool max_alm, long *val)
> > > > > +{
> > > > > + if (channel == LTC4283_VPWR)
> > > > > + return ltc4283_read_alarm(st, LTC4283_ADC_ALM_LOG_1,
> > > > > + BIT(2 + max_alm), val);
> > > > > +
> > > > > + if (channel >= LTC4283_CHAN_ADI_1 && channel <= LTC4283_CHAN_ADI_4) {
> > > > > + u32 bit = (channel - LTC4283_CHAN_ADI_1) * 2;
> > > > > + /*
> > > > > + * Lower channels go to higher bits. We also want to go +1 down
> > > > > + * in the min_alarm case.
> > > > > + */
> > > > > + return ltc4283_read_alarm(st, LTC4283_ADC_ALM_LOG_2,
> > > > > + BIT(7 - bit - !max_alm), val);
> > > > > + }
> > > > > +
> > > > > + if (channel >= LTC4283_CHAN_ADIO_1 && channel <= LTC4283_CHAN_ADIO_4) {
> > > > > + u32 bit = (channel - LTC4283_CHAN_ADIO_1) * 2;
> > > > > +
> > > > > + return ltc4283_read_alarm(st, LTC4283_ADC_ALM_LOG_3,
> > > > > + BIT(7 - bit - !max_alm), val);
> > > > > + }
> > > > > +
> > > > > + if (channel >= LTC4283_CHAN_ADIN12 && channel <= LTC4283_CHAN_ADIN34) {
> > > > > + u32 bit = (channel - LTC4283_CHAN_ADIN12) * 2;
> > > > > +
> > > > > + return ltc4283_read_alarm(st, LTC4283_ADC_ALM_LOG_5,
> > > > > + BIT(7 - bit - !max_alm), val);
> > > > > + }
> > > >
> > > > "Will this condition handle the ADIO12 and ADIO34 differential channels?
> > > > It looks like channels 14 and 15 fall through to the default return intended
> > > > for the DRAIN channel. Since reading the alarm implicitly clears the register
> > > > bits, could reading these ADIO alarms unintentionally clear actual DRAIN
> > > > alarms? Should the upper bound be LTC4283_CHAN_ADIO34?"
> > > >
> > > > Good catch and should be:
> > > >
> > > > - if (channel >= LTC4283_CHAN_ADIN12 && channel <= LTC4283_CHAN_ADIN34) {
> > > > + if (channel >= LTC4283_CHAN_ADIN12 && channel <= LTC4283_CHAN_ADIO34) {
> > > >
> > > > > +
> > > > > + if (channel == LTC4283_CHAN_DRNS)
> > > > > + return ltc4283_read_alarm(st, LTC4283_ADC_ALM_LOG_4,
> > > > > + BIT(6 + max_alm), val);
> > > > > +
> > > > > + return ltc4283_read_alarm(st, LTC4283_ADC_ALM_LOG_4, BIT(4 + max_alm),
> > > > > + val);
> > > > > +}
> > > >
> > > > ...
> > > >
> > > > > +
> > > > > +static int ltc4283_probe(struct i2c_client *client)
> > > > > +{
> > > > > + struct device *dev = &client->dev, *hwmon;
> > > > > + struct auxiliary_device *adev;
> > > > > + struct ltc4283_hwmon *st;
> > > > > + int ret;
> > > > > +
> > > > > + st = devm_kzalloc(dev, sizeof(*st), GFP_KERNEL);
> > > > > + if (!st)
> > > > > + return -ENOMEM;
> > > > > +
> > > > > + if (!i2c_check_functionality(client->adapter,
> > > > > + I2C_FUNC_SMBUS_BYTE_DATA |
> > > > > + I2C_FUNC_SMBUS_WORD_DATA |
> > > > > + I2C_FUNC_SMBUS_READ_I2C_BLOCK))
> > > > > + return -EOPNOTSUPP;
> > > > > +
> > > > > + st->client = client;
> > > > > + st->map = devm_regmap_init(dev, <c4283_regmap_bus, client,
> > > > > + <c4283_regmap_config);
> > > > > + if (IS_ERR(st->map))
> > > > > + return dev_err_probe(dev, PTR_ERR(st->map),
> > > > > + "Failed to create regmap\n");
> > > > > +
> > > > > + ret = ltc4283_setup(st, dev);
> > > > > + if (ret)
> > > > > + return ret;
> > > > > +
> > > > > + hwmon = devm_hwmon_device_register_with_info(dev, "ltc4283", st,
> > > > > + <c4283_chip_info, NULL);
> > > > > +
> > > > > + if (IS_ERR(hwmon))
> > > > > + return PTR_ERR(hwmon);
> > > > > +
> > > > > + ltc4283_debugfs_init(st, client);
> > > > > +
> > > > > + if (!st->gpio_mask)
> > > > > + return 0;
> > > > > +
> > > > > + adev = devm_auxiliary_device_create(dev, "gpio", &st->gpio_mask);
> > > > > + if (!adev)
> > > > > + return dev_err_probe(dev, -ENODEV, "Failed to add GPIO device\n");
> > > >
> > > > "Does this allow multiple LTC4283 chips to probe successfully?
> > > > Without allocating a unique ID per I2C instance, it seems the first probed
> > > > chip takes the generic name. If a second chip is present, it might attempt
> > > > to register with the exact same name, resulting in a failure in device_add()
> > > > and aborting the probe."
> > > >
> > > > Also looks valid and I suspect is one of those that a quick look will
> > > > find more "offenders". I would purpose:
> > > >
> > > > - adev = devm_auxiliary_device_create(dev, "gpio", &st->gpio_mask);
> > > > + adev = __devm_auxiliary_device_create(dev, KBUILD_MODNAME, "gpio",
> > > > + &st->gpio_mask, client->addr);
> > > >
> > >
> > > That would still fail if there are multiple chips at the same I2C address
> > > on multiple I2C busses. Check drivers/gpu/drm/bridge/ti-sn65dsi86.c which has
> > > the same problem.
> >
> > I did looked at that one but totally forgot the multiple busses
> > scenario.
> >
> > >
> > > > If there's nothing else and you agree with the above, is this something
> > > > you can tweak while applying or should I spin a new version?
> > > >
> > >
> > > Please respin. Also, regarding the other concerns:
> > >
> > > Can BIT(8) * st->rsense wrap to zero on 32-bit architectures?
> > > BIT(8) is a 32-bit unsigned long and st->rsense is a u32. If a user sets a
> > > very large sense resistor value via the device tree, the multiplication could
> > > wrap to 0, causing a division-by-zero kernel panic. Should the divisor use
> > > BIT_ULL(8)?
> > >
> > > Unless I am missing something, this _can_ overflow. Try to provide a sense
> > > resistor value of 1677721600. Yes, it is unreasonable to specify such large
> > > rsense values, but why not just limit it such that it does not overflow ?
> >
> > Yes, that's pretty much my reasoning (regarding the unreasonable
> > rsense). I could just make BIT_ULL() and be done with it. I can also
> > also cap rsense to a max value but i'm not 100% what that value would
> > be. Maybe 1 ohm is already more than reasonable. I can also ask internally. Any
> > preference on this one?
> >
>
> I'd suggest to reject large (unreasonable) values. In this case, rejecting rsense
> values >= 1677721600 should solve the problem.
>
> > >
> > > Also, for the overflow concerns, if you are sure they can not happen, I'll
> > > really need to write the unit test code to make sure that this is indeed
> > > the case.
> > >
> >
> > Hmm, for the val * MILLI case, well it should not happen but given it
> > depends on user input, better if I clamp it before passing the
> > value to ltc4283_write_in_byte(). Yes, we clamp again inside the
> > write_bytes() API but not a big deal.
> >
> > For the st->power_max is again one of those cases where the values would
> > not make sense (I think - the combination of vsense_max and rsense). Just looking
> > at the code, it can overflow but this one I'm not really sure how we could handle it.
> > Maybe clamp power_max to U8_MAX and have a warning message in ltc4283_read_power_byte() if
> > we overflow long in which case we need a power64 attr?
> >
> > But even clamping does not make much sense here. The power limit register
> > is 8 bits, so if our design (rsense + vsense_max) overflows that,
> > there's nothing we can do other that erroring out.
> >
>
> Again, why not just reject unreasonable values such that calculations
> can not overflow ?
>
> In other drivers, the common approach is to reject unreeasonable values if
> provided through devicetree and to clamp them if provided through sysfs.
> I don't see why that would not work here.
Hi Guenter,
Just FYI, I intended to re-spin today but then I started to double check
the st->power_max logic. If I did not messed up 14.5uOhm is the minimum rsense
we can take so that we don't overflow long on 32bits systems. I'm not sure but
I think it's plausible to have values lower than that. So, bottom line, I
asked internally to some HW folks, who definitely know these systems
better than I do, about that 14,5 min value. I'm waiting for feedback
but it might be that we end up needing power64 attrs as you suggested
some revisions ago.
- Nuno Sá
>
> Thanks,
> Guenter
>
^ permalink raw reply
* Re: [PATCH RFC v4 10/44] KVM: guest_memfd: Add support for KVM_SET_MEMORY_ATTRIBUTES2
From: Ackerley Tng @ 2026-04-02 16:20 UTC (permalink / raw)
To: Michael Roth
Cc: aik, andrew.jones, binbin.wu, brauner, chao.p.peng, david,
ira.weiny, jmattson, jroedel, jthoughton, oupton, pankaj.gupta,
qperret, rick.p.edgecombe, rientjes, shivankg, steven.price,
tabba, willy, wyihan, yan.y.zhao, forkloop, pratyush,
suzuki.poulose, aneesh.kumar, Paolo Bonzini, Sean Christopherson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Jonathan Corbet, Shuah Khan, Shuah Khan,
Vishal Annapurve, Andrew Morton, Chris Li, Kairui Song,
Kemeng Shi, Nhat Pham, Baoquan He, Barry Song, Axel Rasmussen,
Yuanchu Xie, Wei Xu, Jason Gunthorpe, Vlastimil Babka, kvm,
linux-kernel, linux-trace-kernel, linux-doc, linux-kselftest,
linux-mm
In-Reply-To: <CAEvNRgFkusZeKxGctUpTTbYjdi7nZL1ZZar-gT7XRUOCZ2xtpw@mail.gmail.com>
Ackerley Tng <ackerleytng@google.com> writes:
>
> [...snip...]
>
>> In the case of SNP, there is a
>> documentation/parameter check in snp_launch_update() that needs to be
>> relaxed in order for userspace to be able to pass in a NULL 'src'
>> parameter (since, for in-place conversion, it would be initialized in place
>> as shared memory prior to the call, since by the time kvm_gmem_poulate()
>> it will have been set to private and therefore cannot be faulted in via
>> GUP (and if it could, we'd be unecessarily copying the src back on top
>> of itself since src/dst are the same).
>
>
> [...snip...]
>
>
> Btw, if snp_launch_update() is going to accept a NULL src parameter and
> launch-update the src in-place:
>
> + Will userspace have to set that memory to private before calling launch
> update?
> + If yes, then would we need some other mode of conversion that is
> not ZERO and not quite PRESERVE (since PRESERVE is defined as that
> the guest will see what the host wrote post-encryption, but it
> sounds like launch update is doing the encryption)
> + Or should launch update be called when that memory is shared? Will
> launch update then also set that memory to private in guest_memfd?
>
Update after today's guest_memfd biweekly:
guest_memfd's populate will first check that the memory is shared, then
also set the memory to private after the populate.
KVM must not make assumptions about any memory that is private, so it
should actually only be operating on memory that is shared. This is
aligned with pre-in-place-conversion, since before this series, there
was no way to populate from private memory anyway.
>>
>> [...snip...]
>>
^ permalink raw reply
* [PATCH 2/3] Docs/admin-guide/mm/damon: fix 'parametrs' typo
From: SeongJae Park @ 2026-04-02 15:57 UTC (permalink / raw)
To: Andrew Morton
Cc: Cheng-Han Wu, Liam R. Howlett, David Hildenbrand, Jonathan Corbet,
Lorenzo Stoakes, Michal Hocko, Mike Rapoport, SeongJae Park,
Shuah Khan, Suren Baghdasaryan, Vlastimil Babka, damon, linux-doc,
linux-kernel, linux-mm
In-Reply-To: <20260402155733.77050-1-sj@kernel.org>
From: Cheng-Han Wu <hank20010209@gmail.com>
Fix the misspelling of "parametrs" as "parameters" in
reclaim.rst and lru_sort.rst.
Signed-off-by: Cheng-Han Wu <hank20010209@gmail.com>
Signed-off-by: SeongJae Park <sj@kernel.org>
---
Changes from v1
(https://lore.kernel.org/20260324144851.12883-1-hank20010209@gmail.com)
- Rebase to latest mm-new.
Documentation/admin-guide/mm/damon/lru_sort.rst | 2 +-
Documentation/admin-guide/mm/damon/reclaim.rst | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/mm/damon/lru_sort.rst b/Documentation/admin-guide/mm/damon/lru_sort.rst
index 14cc6b2db897..25e2f042a383 100644
--- a/Documentation/admin-guide/mm/damon/lru_sort.rst
+++ b/Documentation/admin-guide/mm/damon/lru_sort.rst
@@ -75,7 +75,7 @@ Make DAMON_LRU_SORT reads the input parameters again, except ``enabled``.
Input parameters that updated while DAMON_LRU_SORT is running are not applied
by default. Once this parameter is set as ``Y``, DAMON_LRU_SORT reads values
-of parametrs except ``enabled`` again. Once the re-reading is done, this
+of parameters except ``enabled`` again. Once the re-reading is done, this
parameter is set as ``N``. If invalid parameters are found while the
re-reading, DAMON_LRU_SORT will be disabled.
diff --git a/Documentation/admin-guide/mm/damon/reclaim.rst b/Documentation/admin-guide/mm/damon/reclaim.rst
index 2068f1346b9c..17e938c319e3 100644
--- a/Documentation/admin-guide/mm/damon/reclaim.rst
+++ b/Documentation/admin-guide/mm/damon/reclaim.rst
@@ -67,7 +67,7 @@ Make DAMON_RECLAIM reads the input parameters again, except ``enabled``.
Input parameters that updated while DAMON_RECLAIM is running are not applied
by default. Once this parameter is set as ``Y``, DAMON_RECLAIM reads values
-of parametrs except ``enabled`` again. Once the re-reading is done, this
+of parameters except ``enabled`` again. Once the re-reading is done, this
parameter is set as ``N``. If invalid parameters are found while the
re-reading, DAMON_RECLAIM will be disabled.
--
2.47.3
^ permalink raw reply related
* [PATCH 0/3] mm/damon: non-hotfix reviewed patches in damon/next tree
From: SeongJae Park @ 2026-04-02 15:57 UTC (permalink / raw)
To: Andrew Morton
Cc: SeongJae Park, Liam R. Howlett, David Hildenbrand,
Jonathan Corbet, Lorenzo Stoakes, Michal Hocko, Mike Rapoport,
Shuah Khan, Suren Baghdasaryan, Vlastimil Babka, damon, linux-doc,
linux-kernel, linux-mm
Re-posting non-hotfix DAMON patches that reviewed by DAMON maintainer
but not yet merged into mm.git. Those are not urgent, so it should be
ok to be merged after the next rc1. This is just a headsup. I will
post these again after next rc1, if these are not merged into mm.git by
then.
The first patch from Liew Rui Yan add a minor performance optimization
using ilog2() instead of inefficient manual implementation of the
functionality.
The second patch from Cheng-Han Wu fixes a minor typo:
s/parametrs/parameters/.
The third patch from Liew Rui Yan make commit_inputs operation of
DAMON_RECLAIM and DAMON_LRU_SORT synchronous to improve the user
experience.
Cheng-Han Wu (1):
Docs/admin-guide/mm/damon: fix 'parametrs' typo
Liew Rui Yan (2):
mm/damon/ops-common: optimize damon_hot_score() using ilog2()
mm/damon: add synchronous commit for commit_inputs
.../admin-guide/mm/damon/lru_sort.rst | 2 +-
.../admin-guide/mm/damon/reclaim.rst | 2 +-
mm/damon/lru_sort.c | 46 ++++++++++++++++---
mm/damon/ops-common.c | 9 ++--
mm/damon/reclaim.c | 46 ++++++++++++++++---
5 files changed, 86 insertions(+), 19 deletions(-)
base-commit: 2c5f83f56c4a5ec75db054510007baaa1fbe4ad5
--
2.47.3
^ 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