* Re: [PATCH v4] docs/ja_JP: translate more of submitting-patches.rst
From: Jonathan Corbet @ 2026-05-03 14:38 UTC (permalink / raw)
To: Akiyoshi Kurita, linux-doc; +Cc: linux-kernel, akiyks, Akiyoshi Kurita
In-Reply-To: <20260502070143.1015416-1-weibu@redadmin.org>
Akiyoshi Kurita <weibu@redadmin.org> writes:
> Translate the "Separate your changes", "Style-check your changes",
> and "Select the recipients for your patch" sections in
> Documentation/translations/ja_JP/process/submitting-patches.rst.
>
> Keep the wording close to the English text and wrap lines to match
> the style used in the surrounding Japanese translation.
>
> Signed-off-by: Akiyoshi Kurita <weibu@redadmin.org>
> ---
> v4:
> - Rebase onto docs-next
>
> .../ja_JP/process/submitting-patches.rst | 127 +++++++++++++++++-
> 1 file changed, 120 insertions(+), 7 deletions(-)
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH v2] docs: Remove stale ISDN parameters
From: Jonathan Corbet @ 2026-05-03 14:37 UTC (permalink / raw)
To: Costa Shulyupin, Jakub Kicinski, Shuah Khan, Randy Dunlap,
linux-doc, linux-kernel
Cc: Costa Shulyupin
In-Reply-To: <20260502120206.1289126-1-costa.shul@redhat.com>
Costa Shulyupin <costa.shul@redhat.com> writes:
> The icn= and pcbit= parameters referenced drivers removed in
> commit 02bbd9802da7 ("staging: i4l: delete the whole thing").
>
> Remove the stale parameter entries and the now-unused ISDN tag
> from the legend.
>
> Suggested-by: Randy Dunlap <rdunlap@infradead.org>
> Assisted-by: Claude:claude-opus-4-6
> ---
> v2: Remove pcbit= and ISDN too
> Address comments of Randy Dunlap
> V1: Remove icn=
>
> Signed-off-by: Costa Shulyupin <costa.shul@redhat.com>
> ---
This arrangement caused your signoff to be stripped out on application.
I've put it back, but please follow the normal patch format in the
future.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH] Documentation: translations: Fix "Linux Torvalds" -> "Linus Torvalds"
From: Jonathan Corbet @ 2026-05-03 14:35 UTC (permalink / raw)
To: Wang Zihan, linux-doc
Cc: federico.vaga, skhan, carlos.bilbao, avadhut.naik, linux-kernel,
Wang Zihan
In-Reply-To: <tencent_B98271DD90AC356719E15C06ACE473BB820A@qq.com>
Wang Zihan <jiyu03@qq.com> writes:
> Fix the misspelling of Linus Torvalds' first name in Italian
> and Spanish translations.
>
> Also fix "Linus Torvald" -> "Linus Torvalds" (missing 's') in
> Italian translations.
>
> Found by Christian Marillat.
>
> Signed-off-by: Wang Zihan <jiyu03@qq.com>
The fixes all seem good. It should have a proper Reported-by line,
though, and it seems you didn't CC Christian on this email...?
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v2] tty: synclink_gt: remove broken driver
From: Andrew Lunn @ 2026-05-03 14:23 UTC (permalink / raw)
To: Ethan Nelson-Moore
Cc: Greg Kroah-Hartman, linux-doc, netdev, linux-serial,
rust-for-linux, Jonathan Corbet, Shuah Khan, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Jiri Slaby, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Bagas Sanjaya, Haren Myneni,
Eric Biggers, Qingfang Deng, Julian Braha
In-Reply-To: <CADkSEUgPtjkKC684O3qB=koKDPwJoUj-qU_4Z_18NAU_+bBqkw@mail.gmail.com>
On Sat, May 02, 2026 at 11:00:53PM -0700, Ethan Nelson-Moore wrote:
> Hi, Greg,
>
> On Sat, May 2, 2026 at 10:44 PM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > Then that means someone uses it somewhere. Don't generate bindings for
> > something that will break because it is no longer in the tree :(
> That project generates bindings for every UAPI header automatically,
> but has a hardcoded list of them, so its presence there doesn't mean
> anyone is using it.
>
> > If no one does use it, then please get that project to fix their code so
> > that we don't break their build.
> They have had to remove headers from their list that got removed from
> the kernel before. I will send them a pull request to remove this
> header and then resend this patch with the UAPI header removal
> restored. Does that sound good to you?
Sounds like a whack a mole problem. I assume the recent removal of ATM
broke it as well? Maybe __has_include() could be used?
Andrew
^ permalink raw reply
* Re: [PATCH 7.2 v16 00/13] khugepaged: mTHP support
From: Andrew Morton @ 2026-05-03 13:32 UTC (permalink / raw)
To: Nico Pache, linux-doc, linux-kernel, linux-mm, linux-trace-kernel,
aarcange, anshuman.khandual, apopple, baohua, baolin.wang,
byungchul, catalin.marinas, cl, corbet, dave.hansen, david,
dev.jain, gourry, hannes, hughd, jack, jackmanb, jannh, jglisse,
joshua.hahnjy, kas, lance.yang, Liam.Howlett, ljs,
mathieu.desnoyers, matthew.brost, mhiramat, mhocko, peterx,
pfalcato, rakie.kim, raquini, rdunlap, richard.weiyang, rientjes,
rostedt, rppt, ryan.roberts, shivankg, sunnanyong, surenb,
thomas.hellstrom, tiwai, usamaarif642, vbabka, vishal.moola,
wangkefeng.wang, will, willy, yang, ying.huang, ziy, zokeefe
In-Reply-To: <20260503062109.0469201428642a4f7fcfd915@linux-foundation.org>
On Sun, 3 May 2026 06:21:09 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> On Sun, 3 May 2026 06:23:31 -0600 Nico Pache <npache@redhat.com> wrote:
>
> > Can you please pull the changes from the
> > staging branch so I can resend it soon (probably after LSFMM, so no
> > rush)?
>
> np, I've removed v16 from mm.git.
And that messed up Zi Yan's "Remove CONFIG_READ_ONLY_THP_FOR_FS and
enable file THP for writable files", so I've restored v16.
Please prepare v17 against mm-unstable.
^ permalink raw reply
* Re: [PATCH 7.2 v16 00/13] khugepaged: mTHP support
From: Andrew Morton @ 2026-05-03 13:21 UTC (permalink / raw)
To: Nico Pache
Cc: linux-doc, linux-kernel, linux-mm, linux-trace-kernel, aarcange,
anshuman.khandual, apopple, baohua, baolin.wang, byungchul,
catalin.marinas, cl, corbet, dave.hansen, david, dev.jain, gourry,
hannes, hughd, jack, jackmanb, jannh, jglisse, joshua.hahnjy, kas,
lance.yang, Liam.Howlett, ljs, mathieu.desnoyers, matthew.brost,
mhiramat, mhocko, peterx, pfalcato, rakie.kim, raquini, rdunlap,
richard.weiyang, rientjes, rostedt, rppt, ryan.roberts, shivankg,
sunnanyong, surenb, thomas.hellstrom, tiwai, usamaarif642, vbabka,
vishal.moola, wangkefeng.wang, will, willy, yang, ying.huang, ziy,
zokeefe
In-Reply-To: <CAA1CXcBJFoqDrkQbRE6JnpV-gjfNXe2sUxaCyXPC82h3qk9Jig@mail.gmail.com>
On Sun, 3 May 2026 06:23:31 -0600 Nico Pache <npache@redhat.com> wrote:
> Can you please pull the changes from the
> staging branch so I can resend it soon (probably after LSFMM, so no
> rush)?
np, I've removed v16 from mm.git.
^ permalink raw reply
* Re: [PATCH 7.2 v16 00/13] khugepaged: mTHP support
From: Nico Pache @ 2026-05-03 12:23 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-doc, linux-kernel, linux-mm, linux-trace-kernel, aarcange,
anshuman.khandual, apopple, baohua, baolin.wang, byungchul,
catalin.marinas, cl, corbet, dave.hansen, david, dev.jain, gourry,
hannes, hughd, jack, jackmanb, jannh, jglisse, joshua.hahnjy, kas,
lance.yang, Liam.Howlett, ljs, mathieu.desnoyers, matthew.brost,
mhiramat, mhocko, peterx, pfalcato, rakie.kim, raquini, rdunlap,
richard.weiyang, rientjes, rostedt, rppt, ryan.roberts, shivankg,
sunnanyong, surenb, thomas.hellstrom, tiwai, usamaarif642, vbabka,
vishal.moola, wangkefeng.wang, will, willy, yang, ying.huang, ziy,
zokeefe
In-Reply-To: <20260424065828.031775921990de37f83a2468@linux-foundation.org>
On 4/24/26 7:58 AM, Andrew Morton wrote:
> On Sun, 19 Apr 2026 12:57:37 -0600 Nico Pache <npache@redhat.com> wrote:
>
>> The following series provides khugepaged with the capability to collapse
>> anonymous memory regions to mTHPs.
>
> Lots of stuff here:
> https://sashiko.dev/#/patchset/20260419185750.260784-1-npache@redhat.com
>
> It's going to take some time. Hopefully worthwhile.
>
> As always, it's useful to hear about the usefulness of the AI review.
Ok I went through those! Can you please pull the changes from the
staging branch so I can resend it soon (probably after LSFMM, so no
rush)?
Heres my report:
patch 2 - rather useless as memcg does not have per order/mthp stats
patch 4 - good point, although kinda minor, same as what Usama brought up
patch 5 - either the concern is nonsense or im too dumb to understand
it. Maybe someone else can confirm
Patch 5.2 - Not a real concern (I don't think), given we've already
fully locked down the PTE table, nothing should be able to reach it.
It notes a specific config might be an issue, I will test with that
on.
Patch 9 - was a real concern, and my fault for semi-lazily stripping
out a variable without fully considering the effects. David noted this
too. Good news is that it got the reasoning for why it is bad correct.
Oddly, I did not see a bug during testing which I would expected to
show up in the madvise tests. I just reverted my changes, I will try
to clean this up in a future cleanup series... Although there may be
no good way around this madvise behavior.
Patch 10.1 - Good point, I had considered this during my design, but
then convinced myself I was incorrect. This actually saves us a lot of
heap space :) Gotta retest a lot though. First few tests show no issue
Patch 10.2 - Not a concern and if we made it here, it's already been
checked. Furthermore, the result would be the same. Although not a bad
question from the AI
Patch 10.3 - I dont think this is a valid concern at all
Patch 10.4 - I don't think this is a valid concern at all
Patch 10.5 - The first half is valid (although it's what the next
patch does), so it's not really that valid, it's just missing the
series context. second half hmm
Patch 10.6 - Not a real concern
Patch 11 - Not a bad consideration
Patch 12 - real bug from my last refactor
Patch 12.2 - Decent consideration, but not a real concern, just a design choice.
So yes overall very smart to check sashiko :) But as someone currently
actively working on sashiko I was already a fan.
Cheers,
-- Nico
>
^ permalink raw reply
* [PATCH v2 3/3] Documentation: security-bugs: clarify requirements for AI-assisted reports
From: Willy Tarreau @ 2026-05-03 11:35 UTC (permalink / raw)
To: greg
Cc: leon, security, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel, Willy Tarreau, Greg KH
In-Reply-To: <20260503113506.5710-1-w@1wt.eu>
AI tools are increasingly used to assist in bug discovery. While these
tools can identify valid issues, reports that are submitted without
manual verification often lack context, contain speculative impact
assessments, or include unnecessary formatting. Such reports increase
triage effort, waste maintainers' time and may be ignored.
Reports where the reporter has verified the issue and the proposed fix
typically meet quality standards. This documentation outlines specific
requirements for length, formatting, and impact evaluation to reduce
the effort needed to deal with these reports.
Cc: Greg KH <gregkh@linuxfoundation.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
Documentation/process/security-bugs.rst | 55 +++++++++++++++++++++++++
1 file changed, 55 insertions(+)
diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index 3b44464dd9ba7..bf62469a81266 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -159,6 +159,61 @@ 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.
+Responsible use of AI to find bugs
+----------------------------------
+
+A significant fraction of bug reports submitted to the security team are
+actually the result of code reviews assisted by AI tools. While this can be an
+efficient means to find bugs in rarely explored areas, it causes an overload on
+maintainers, who are sometimes forced to ignore such reports due to their poor
+quality or accuracy. As such, reporters must be particularly cautious about a
+number of points which tend to make these reports needlessly difficult to
+handle:
+
+ * **Length**: AI-generated reports tend to be excessively long, containing
+ multiple sections and excessive detail. This makes it difficult to spot
+ important information such as affected files, versions, and impact. Please
+ ensure that a clear summary of the problem and all critical details are
+ presented first. Do not require triage engineers to scan multiple pages of
+ text. Configure your tools to produce concise, human-style reports.
+
+ * **Formatting**: Most AI-generated reports are littered with Markdown tags.
+ These decorations complicate the search for important information and do
+ not survive the quoting processes involved in forwarding or replying.
+ Please **always convert your report to plain text** without any formatting
+ decorations before sending it.
+
+ * **Impact Evaluation**: Many AI-generated reports lack an understanding of
+ the kernel's threat model and go to great lengths inventing theoretical
+ consequences. This adds noise and complicates triage. Please stick to
+ verifiable facts (e.g., "this bug permits any user to gain CAP_NET_ADMIN")
+ without enumerating speculative implications. Have your tool read this
+ documentation as part of the evaluation process.
+
+ * **Reproducer**: AI-based tools are often capable of generating reproducers.
+ Please always ensure your tool provides one and **test it thoroughly**. If
+ the reproducer does not work, or if the tool cannot produce one, the
+ validity of the report should be seriously questioned.
+
+ * **Propose a Fix**: Many AI tools are actually better at writing code than
+ evaluating it. Please ask your tool to propose a fix and **test it** before
+ reporting the problem. If the fix cannot be tested because it relies on
+ rare hardware or almost extinct network protocols, the issue is likely not
+ a security bug. In any case, if a fix is proposed, it must adhere to
+ Documentation/process/submitting-patches.rst and include a 'Fixes:' tag
+ designating the commit that introduced the bug.
+
+Failure to consider these points exposes your report to the risk of being
+ignored.
+
+Use common sense when evaluating the report. If the affected file has not been
+touched for more than one year and is maintained by a single individual, it is
+likely that usage has declined and exposed users are virtually non-existent
+(e.g., drivers for very old hardware, obsolete filesystems). In such cases,
+there is no need to consume a maintainer's time with an unimportant report. If
+the issue is clearly trivial and publicly discoverable, you should report it
+directly to the public mailing lists.
+
Sending the report
------------------
--
2.52.0
^ permalink raw reply related
* [PATCH v2 0/3] Documentation: security-bugs: new updates covering triage and AI
From: Willy Tarreau @ 2026-05-03 11:35 UTC (permalink / raw)
To: greg
Cc: leon, security, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel, Willy Tarreau
This series tries to translate recent discussions on the security list
on how to better handle reports. It details:
- when not to Cc: the security list
- what classes of bugs do not need to be handled privately
- minimum requirements for AI-assisted reports
As usual, this is probably perfectible but can already help in the short
term as we can point it to reporters, so barring any strong disagreement,
better continue to proceed in small incremental improvements and observe
the effects.
Thanks!
Willy
---
v2:
- fixes for issues reported by Randy
- Greg's ack on the AI part
- reworded the "when to Cc" part based on Greg's feedback
(Greg I didn't take your original ack since the wording changed)
- split the threat model into its own document as per Greg's suggestion
---
Willy Tarreau (3):
Documentation: security-bugs: do not systematically Cc the security
team
Documentation: security-bugs: explain what is and is not a security
bug
Documentation: security-bugs: clarify requirements for AI-assisted
reports
Documentation/process/index.rst | 1 +
Documentation/process/security-bugs.rst | 93 +++++++++-
Documentation/process/threat-model.rst | 231 ++++++++++++++++++++++++
3 files changed, 324 insertions(+), 1 deletion(-)
create mode 100644 Documentation/process/threat-model.rst
--
2.52.0
^ permalink raw reply
* [PATCH v2 2/3] Documentation: security-bugs: explain what is and is not a security bug
From: Willy Tarreau @ 2026-05-03 11:35 UTC (permalink / raw)
To: greg
Cc: leon, security, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel, Willy Tarreau, Greg KH
In-Reply-To: <20260503113506.5710-1-w@1wt.eu>
The use of automated tools to find bugs in random locations of the kernel
induces a raise of security reports even if most of them should just be
reported as regular bugs. This patch is an attempt at drawing a line
between what qualifies as a security bug and what does not, hoping to
improve the situation and ease decision on the reporter's side.
It defers the enumeration to a new file, threat-model.rst, that tries
to enumerate various classes of issues that are and are not security
bugs. This should permit to more easily update this file for various
subsystem-specific rules without having to revisit the security bug
reporting guide.
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Leon Romanovsky <leon@kernel.org>
Suggested-by: Leon Romanovsky <leon@kernel.org>
Suggested-by: Greg KH <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
Documentation/process/index.rst | 1 +
Documentation/process/security-bugs.rst | 28 +++
Documentation/process/threat-model.rst | 231 ++++++++++++++++++++++++
3 files changed, 260 insertions(+)
create mode 100644 Documentation/process/threat-model.rst
diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst
index dbd6ea16aca70..aa7c959a52b87 100644
--- a/Documentation/process/index.rst
+++ b/Documentation/process/index.rst
@@ -86,6 +86,7 @@ regressions and security problems.
debugging/index
handling-regressions
security-bugs
+ threat-model
cve
embargoed-hardware-issues
diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index 6dc525858125e..3b44464dd9ba7 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -66,6 +66,34 @@ In addition, the following information are highly desirable:
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.
+What qualifies as a security bug
+--------------------------------
+
+It is important that most bugs are handled publicly so as to involve the widest
+possible audience and find the best solution. By nature, bugs that are handled
+in closed discussions between a small set of participants are less likely to
+produce the best possible fix (e.g., risk of missing valid use cases, limited
+testing abilities).
+
+It turns out that the majority of the bugs reported via the security team are
+just regular bugs that have been improperly qualified as security bugs due to
+ignorance or misunderstanding of the Linux kernel's threat model described in
+Documentation/process/threat-model.rst, and ought to have been sent through
+the normal channels described in Documentation/admin-guide/reporting-issues.rst
+instead.
+
+The security list exists for urgent bugs that grant an attacker a capability
+they are not supposed to have on a correctly configured production system, and
+can be easily exploited, representing an imminent threat to many users. Before
+reporting, consider whether the issue actually crosses a trust boundary on such
+a system.
+
+If you are unsure whether an issue qualifies, err on the side of reporting
+privately: the security team would rather triage a borderline report than miss
+a real vulnerability. Reporting ordinary bugs to the security list, however,
+does not make them move faster and consumes triage capacity that other reports
+need.
+
Identifying contacts
--------------------
diff --git a/Documentation/process/threat-model.rst b/Documentation/process/threat-model.rst
new file mode 100644
index 0000000000000..8cd46483cd8b5
--- /dev/null
+++ b/Documentation/process/threat-model.rst
@@ -0,0 +1,231 @@
+.. _threatmodel:
+
+The Linux Kernel threat model
+=============================
+
+There are a lot of assumptions regarding what the kernel protects against and
+what it does not protect against. These assumptions tend to cause confusion for
+bug reports (:doc:`security-related ones <security-bugs>` vs
+:doc:`non-security ones <../admin-guide/reporting-issues>`), and can complicate
+security enforcement when the responsibilities for some boundaries is not clear
+between the kernel, distros, administrators and users.
+
+This document tries to clarify the responsibilities of the kernel in this
+domain.
+
+The kernel's responsibilities
+-----------------------------
+
+The kernel abstracts access to local hardware resources and to remote systems
+in a way that allows multiple local users to get a fair share of the available
+resources granted to them, and, when the underlying hardware permits, to assign
+a level of confidentiality to their communications and to the data they are
+processing or storing.
+
+The kernel assumes that the underlying hardware behaves according to its
+specifications. This includes the integrity of the CPU's instruction set, the
+transparency of the branch prediction unit and the cache units, the consistency
+of the Memory Management Unit (MMU), the isolation of DMA-capable peripherals
+(e.g., via IOMMU), state transitions in controllers, ranges of values read from
+registers, the respect of documented hardware limitations, etc.
+
+When hardware fails to maintain its specified isolation (e.g., CPU bugs,
+side-channels, hardware response to unexpected inputs), the kernel will usually
+attempt to implement reasonable mitigations. These are best-effort measures
+intended to reduce the attack surface or elevate the cost of an attack within
+the limits of the hardware's facilities; they do not constitute a
+kernel-provided safety guarantee.
+
+Users always perform their activities under the authority of an administrator
+who is able to grant or deny various types of permissions that may affect how
+users benefit from available resources, or the level of confidentiality of
+their activities. Administrators may also delegate all or part of their own
+permissions to some users, particularly via capabilities but not only. All this
+is performed via configuration (sysctl, file-system permissions etc).
+
+The Linux Kernel applies a certain collection of default settings that match
+its threat model. Distros have their own threat model and will come with their
+own configuration presets, that the administrator may have to adjust to better
+suit their expectations (relax or restrict).
+
+By default, the Linux Kernel guarantees the following protections when running
+on common processors featuring privilege levels and memory management units:
+
+* **User-based isolation**: an unprivileged user may restrict access to their
+ own data from other unprivileged users running on the same system. This
+ includes:
+
+ * stored data, via file system permissions
+ * in-memory data (pages are not accessible by default to other users)
+ * process activity (ptrace is not permitted to other users)
+ * inter-process communication (other users may not observe data exchanged via
+ UNIX domain sockets or other IPC mechanisms).
+ * network communications within the same or with other systems
+
+* **Capability-based protection**:
+
+ * users not having the ``CAP_SYS_ADMIN`` capability may not alter the
+ kernel's configuration, memory nor state, change other users' view of the
+ file system layout, grant any user capabilities they do not have, nor
+ affect the system's availability (shutdown, reboot, panic, hang, or making
+ the system unresponsive via unbounded resource exhaustion).
+ * users not having the ``CAP_NET_ADMIN`` capability may not alter the network
+ configuration, intercept nor spoof network communications from other users
+ nor systems.
+ * users not having ``CAP_SYS_PTRACE`` may not observe other users' processes
+ activities.
+
+When ``CONFIG_USER_NS`` is set, the kernel also permits unprivileged users to
+create their own user namespace in which they have all capabilities, but with a
+number of restrictions (they may not perform actions that have impacts on the
+initial user namespace, such as changing time, loading modules or mounting
+block devices). Please refer to ``user_namespaces(7)`` for more details, the
+possibilities of user namespaces are not covered in this document.
+
+The kernel also offers a lot of troubleshooting and debugging facilities, which
+can constitute attack vectors when placed in wrong hands. While some of them
+are designed to be accessible to regular local users with a low risk (e.g.
+kernel logs via ``/proc/kmsg``), some would expose enough information to
+represent a risk in most places and the decision to expose them is under the
+administrator's responsibility (perf events, traces), and others are not
+designed to be accessed by non-privileged users (e.g. debugfs). Access to these
+facilities by a user who has been explicitly granted permission by an
+administrator does not constitute a security breach.
+
+Bugs that permit to violate the principles above constitute security breaches.
+However, bugs that permit one violation only once another one was already
+achieved are only weaknesses. The kernel applies a number of self-protection
+measures whose purpose is to avoid crossing a security boundary when certain
+classes of bugs are found, but a failure of these extra protections do not
+constitute a vulnerability alone.
+
+What does not constitute a security bug
+---------------------------------------
+
+In the Linux kernel's threat model, the following classes of problems are
+**NOT** considered as Linux Kernel security bugs. However, when it is believed
+that the kernel could do better, they should be reported, so that they can be
+reviewed and fixed where reasonably possible, but they will be handled as any
+regular bug:
+
+* **Configuration**:
+
+ * outdated kernels and particularly end-of-life branches are out of the scope
+ of the kernel's threat model: administrators are responsible for keeping
+ their system up to date. For a bug to qualify as a security bug, it must be
+ demonstrated that it affects actively maintained versions.
+
+ * build-level: changes to the kernel configuration that are explicitly
+ documented as lowering the security level (e.g. ``CONFIG_NOMMU``), or
+ targeted at developers only.
+
+ * OS-level: changes to command line parameters, sysctls, filesystem
+ permissions, user capabilities, exposure of privileged interfaces, that
+ explicitly increase exposure by either offering non-default access to
+ unprivileged users, or reduce the kernel's ability to enforce some
+ protections or mitigations. Example: write access to procfs or debugfs.
+
+ * issues triggered only when using features intended for development or
+ debugging (e.g., lockdep, KASAN, fault-injection): these features are known
+ to introduce overhead and potential instability and are not intended for
+ production use.
+
+ * loading of explicitly insecure/broken/staging modules, and generally any
+ using any subsystem marked as experimental or not intended for production
+ use.
+
+ * running out-of-tree modules or unofficial kernel forks; these should be
+ reported to the relevant vendor.
+
+* **Excess of initial privileges**:
+
+ * actions performed by a user already possessing the privileges required to
+ perform that action or modify that state (e.g. ``CAP_SYS_ADMIN``,
+ ``CAP_NET_ADMIN``, ``CAP_SYS_RAWIO``, ``CAP_SYS_MODULE`` with no further
+ boundary being crossed).
+
+ * actions performed in user namespace without permitting anything in the
+ initial namespace that was not already permitted to the same user there.
+
+ * anything performed by the root user in the initial namespace (e.g. kernel
+ oops when writing to a privileged device).
+
+* **Out of production use**:
+
+ This covers theoretical/probabilistic attacks that rely on laboratory
+ conditions with zero system noise, or those requiring an unrealistic number
+ of attempts (e.g., billions of trials) that would be detected by standard
+ system monitoring long before success, such as:
+
+ * prediction of random numbers that only works in a totally silent
+ environment (such as IP ID, TCP ports or sequence numbers that can only be
+ guessed in a lab).
+
+ * activity observation and information leaks based on probabilistic
+ approaches that are prone to measurement noise and not realistically
+ reproducible on a production system.
+
+ * issues that can only be triggered by heavy attacks (e.g. brute force) whose
+ impact on the system makes it unlikely or impossible to remain undetected
+ before they succeed (e.g. consuming all memory before succeeding).
+
+ * problems seen only under development simulators, emulators, or combinations
+ that do not exist on real systems at the time of reporting (issues
+ involving tens of millions of threads, tens of thousands of CPUs,
+ unrealistic CPU frequencies, RAM sizes or disk capacities, network speeds.
+
+ * issues whose reproduction requires hardware modification or emulation,
+ including fake USB devices that pretend to be another one.
+
+ * as well as issues that can be triggered at a cost that is orders of
+ magnitude higher than the expected benefits (e.g. fully functional keyboard
+ emulator only to retrieve 7 uninitialized bytes in a structure, or
+ brute-force method involving millions of connection attempts to guess a
+ port number).
+
+* **Hardening failures**:
+
+ * ability to bypass some of the kernel's hardening measures with no
+ demonstrable exploit path (e.g. ASLR bypass, events timing or probing with
+ no demonstrable consequence). These are just weaknesses, not
+ vulnerabilities.
+
+ * missing argument checks and failure to report certain errors with no
+ immediate consequence.
+
+* **Random information leaks**:
+
+ This concerns information leaks of small data parts that happen to be there
+ and that cannot be chosen by the attacker, or face access restrictions:
+
+ * structure padding reported by syscalls or other interfaces.
+
+ * identifiers, partial data, non-terminated strings reported in error
+ messages.
+
+ * Leaks of kernel memory addresses/pointers do not constitute an immediately
+ exploitable vector and are not security bugs, though they must be reported
+ and fixed.
+
+* **Crafted file system images**:
+
+ * bugs triggered by mounting a corrupted or maliciously crafted file system
+ image are generally not security bugs, as the kernel assumes the underlying
+ storage media is under the administrator's control, unless the filesystem
+ driver is specifically documented as being hardened against untrusted media.
+
+ * issues that are resolved, mitigated, or detected by running a filesystem
+ consistency check (fsck) on the image prior to mounting.
+
+* **Physical access**:
+
+ Issues that require physical access to the machine, hardware modification, or
+ the use of specialized hardware (e.g., logic analyzers, DMA-attack tools over
+ PCI-E/Thunderbolt) are out of scope unless the system is explicitly
+ configured with technologies meant to defend against such attacks
+ (e.g. IOMMU).
+
+* **Functional and performance regressions**:
+
+ Any issue that can be mitigated by setting proper permissions and limits
+ doesn't qualify as a security bug.
--
2.52.0
^ permalink raw reply related
* [PATCH v2 1/3] Documentation: security-bugs: do not systematically Cc the security team
From: Willy Tarreau @ 2026-05-03 11:35 UTC (permalink / raw)
To: greg
Cc: leon, security, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel, Willy Tarreau, Greg KH
In-Reply-To: <20260503113506.5710-1-w@1wt.eu>
With the increase of automated reports, the security team is dealing
with way more messages than really needed. The reporting process works
well with most teams so there is no need to systematically involve the
security team in reports.
Let's suggest to keep it for small lists of recipients and new reporters
only. This should continue to cover the risk of lost messages while
reducing the volume from prolific reporters.
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
Documentation/process/security-bugs.rst | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index 27b028e858610..6dc525858125e 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -148,7 +148,15 @@ run additional tests. Reports where the reporter does not respond promptly
or cannot effectively discuss their findings may be abandoned if the
communication does not quickly improve.
-The report must be sent to maintainers, with the security team in ``Cc:``.
+The report must be sent to maintainers. If there are two or fewer
+recipients in your message, you must also always Cc: the Linux kernel
+security team who will ensure the message is delivered to the proper
+people, and will be able to assist small maintainer teams with processes
+they may not be familiar with. For larger teams, Cc: the Linux kernel
+security team for your first few reports or when seeking specific help,
+such as when resending a message which got no response within a week.
+Once you have become comfortable with the process for a few reports, it is
+no longer necessary to Cc: the security list when sending to large teams.
The Linux kernel security team can be contacted by email at
<security@kernel.org>. This is a private list of security officers
who will help verify the bug report and assist developers working on a fix.
--
2.52.0
^ permalink raw reply related
* [PATCH 4/4] docs: admin-guide: add IGNORE_DIRS example for cscope
From: Cheng-Han Wu @ 2026-05-03 10:14 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan
Cc: Randy Dunlap, linux-doc, linux-kernel, Cheng-Han Wu
In-Reply-To: <20260503101429.254394-1-hank20010209@gmail.com>
The workload tracing guide shows how to build a cscope database by
running cscope command directly. The kernel build system also provides
a cscope target, which supports IGNORE_DIRS for excluding directories
from the generated database.
Mention make cscope and show how to exclude Documentation/ as an example.
Signed-off-by: Cheng-Han Wu <hank20010209@gmail.com>
---
Documentation/admin-guide/workload-tracing.rst | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Documentation/admin-guide/workload-tracing.rst b/Documentation/admin-guide/workload-tracing.rst
index c49c2a00a8b8..314e5f03474e 100644
--- a/Documentation/admin-guide/workload-tracing.rst
+++ b/Documentation/admin-guide/workload-tracing.rst
@@ -202,6 +202,15 @@ database. To get out of this mode press ctrl+d. -p option is used to
specify the number of file path components to display. -p10 is optimal
for browsing kernel sources.
+Alternatively, the kernel build system can generate the cscope database::
+
+ make cscope
+
+To exclude directories from the generated database, pass IGNORE_DIRS to
+the cscope target. For example, to exclude Documentation/, run::
+
+ make IGNORE_DIRS="Documentation" cscope
+
What is perf and how do we use it?
==================================
--
2.52.0
^ permalink raw reply related
* [PATCH 3/4] docs: admin-guide: clarify perf bench all behavior
From: Cheng-Han Wu @ 2026-05-03 10:14 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan
Cc: Randy Dunlap, linux-doc, linux-kernel, Cheng-Han Wu
In-Reply-To: <20260503101429.254394-1-hank20010209@gmail.com>
The workload tracing guide lists a fixed set of benchmarks for
"perf bench all". This list is stale and can become outdated when
perf adds, removes, or renames benchmark collections or individual
benchmarks.
Describe "perf bench all" as running all available benchmarks in the perf
bench framework instead. Also document how to list the collections and
benchmarks available on a given system.
Signed-off-by: Cheng-Han Wu <hank20010209@gmail.com>
---
.../admin-guide/workload-tracing.rst | 20 +++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/Documentation/admin-guide/workload-tracing.rst b/Documentation/admin-guide/workload-tracing.rst
index 43a3c8098654..c49c2a00a8b8 100644
--- a/Documentation/admin-guide/workload-tracing.rst
+++ b/Documentation/admin-guide/workload-tracing.rst
@@ -243,13 +243,21 @@ which can help mitigate performance regressions. It also acts as a common
benchmarking framework, enabling developers to easily create test cases,
integrate transparently, and use performance-rich tooling.
-"perf bench all" command runs the following benchmarks:
+"perf bench all" runs all available benchmarks in the perf bench
+framework. The exact set of benchmarks depends on the perf version and on
+the features enabled when perf was built.
- * sched/messaging
- * sched/pipe
- * syscall/basic
- * mem/memcpy
- * mem/memset
+To list the benchmark collections available on the current system, run::
+
+ perf bench
+
+To list benchmarks in a collection, run::
+
+ perf bench <collection>
+
+For example, to list the benchmarks in the mem collection, run::
+
+ perf bench mem
What is stress-ng and how do we use it?
=======================================
--
2.52.0
^ permalink raw reply related
* [PATCH 2/4] docs: admin-guide: fix stress-ng command examples
From: Cheng-Han Wu @ 2026-05-03 10:14 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan
Cc: Randy Dunlap, linux-doc, linux-kernel, Cheng-Han Wu
In-Reply-To: <20260503101429.254394-1-hank20010209@gmail.com>
The workload tracing guide includes stress-ng command examples with a
stray "command." word at the end. This makes the examples invalid if they
are copied and run directly.
Remove the stray word from the stress-ng example. Also use "--" in the
perf record example to clearly separate perf record options from the
workload command being recorded.
Signed-off-by: Cheng-Han Wu <hank20010209@gmail.com>
---
Documentation/admin-guide/workload-tracing.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/workload-tracing.rst b/Documentation/admin-guide/workload-tracing.rst
index 22cb05025ffc..43a3c8098654 100644
--- a/Documentation/admin-guide/workload-tracing.rst
+++ b/Documentation/admin-guide/workload-tracing.rst
@@ -271,7 +271,7 @@ exercised:
The following command runs the stressor::
- stress-ng --netdev 1 -t 60 --metrics command.
+ stress-ng --netdev 1 -t 60 --metrics
We can use the perf record command to record the events and information
associated with a process. This command records the profiling data in the
@@ -281,7 +281,7 @@ Using the following commands you can record the events associated with the
netdev stressor, view the generated report perf.data and annotate the output
to view the statistics of each instruction of the program::
- perf record stress-ng --netdev 1 -t 60 --metrics command.
+ perf record -- stress-ng --netdev 1 -t 60 --metrics
perf report
perf annotate
--
2.52.0
^ permalink raw reply related
* [PATCH 1/4] docs: admin-guide: fix typos in workload tracing guide
From: Cheng-Han Wu @ 2026-05-03 10:14 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan
Cc: Randy Dunlap, linux-doc, linux-kernel, Cheng-Han Wu
In-Reply-To: <20260503101429.254394-1-hank20010209@gmail.com>
Fix several typos in the workload tracing guide:
- sys_opennat() -> sys_openat()
- annotate the to view -> annotate the output to view
- sys_getegid -> sys_getegid()
Signed-off-by: Cheng-Han Wu <hank20010209@gmail.com>
---
Documentation/admin-guide/workload-tracing.rst | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/admin-guide/workload-tracing.rst b/Documentation/admin-guide/workload-tracing.rst
index 35963491b9f1..22cb05025ffc 100644
--- a/Documentation/admin-guide/workload-tracing.rst
+++ b/Documentation/admin-guide/workload-tracing.rst
@@ -278,8 +278,8 @@ associated with a process. This command records the profiling data in the
perf.data file in the same directory.
Using the following commands you can record the events associated with the
-netdev stressor, view the generated report perf.data and annotate the to
-view the statistics of each instruction of the program::
+netdev stressor, view the generated report perf.data and annotate the output
+to view the statistics of each instruction of the program::
perf record stress-ng --netdev 1 -t 60 --metrics command.
perf report
@@ -349,13 +349,13 @@ times each system call is invoked, and the corresponding Linux subsystem.
+-------------------+-----------+-----------------+-------------------------+
| geteuid | 1 | Process Mgmt. | sys_geteuid() |
+-------------------+-----------+-----------------+-------------------------+
-| getegid | 1 | Process Mgmt. | sys_getegid |
+| getegid | 1 | Process Mgmt. | sys_getegid() |
+-------------------+-----------+-----------------+-------------------------+
| close | 49951 | Filesystem | sys_close() |
+-------------------+-----------+-----------------+-------------------------+
| pipe | 604 | Filesystem | sys_pipe() |
+-------------------+-----------+-----------------+-------------------------+
-| openat | 48560 | Filesystem | sys_opennat() |
+| openat | 48560 | Filesystem | sys_openat() |
+-------------------+-----------+-----------------+-------------------------+
| fstat | 8338 | Filesystem | sys_fstat() |
+-------------------+-----------+-----------------+-------------------------+
--
2.52.0
^ permalink raw reply related
* [PATCH 0/4] docs: admin-guide: improve workload tracing guide
From: Cheng-Han Wu @ 2026-05-03 10:14 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan
Cc: Randy Dunlap, linux-doc, linux-kernel, Cheng-Han Wu
This series updates Documentation/admin-guide/workload-tracing.rst
- Patch 1 fixes several typos.
- Patch 2 fixes stress-ng and perf record command examples.
- Patch 3 replaces a stale fixed "perf bench all" benchmark list with a
description of the command behavior and how to query available benchmarks.
- Patch 4 mentions the kernel build system's cscope target and shows how
to exclude directories with IGNORE_DIRS.
Built test with:
make SPHINXDIRS=admin-guide htmldocs
Cheng-Han Wu (4):
docs: admin-guide: fix typos in workload tracing guide
docs: admin-guide: fix stress-ng command examples
docs: admin-guide: clarify perf bench all behavior
docs: admin-guide: add IGNORE_DIRS example for cscope
.../admin-guide/workload-tracing.rst | 41 +++++++++++++------
1 file changed, 29 insertions(+), 12 deletions(-)
--
2.52.0
^ permalink raw reply
* [syzbot ci] Re: mm: Support selecting doing direct COW for anonymous pmd entry
From: syzbot ci @ 2026-05-03 7:03 UTC (permalink / raw)
To: akpm, arnd, baohua, baolin.wang, corbet, david, dev.jain, jannh,
kasong, lance.yang, liam, linux-arch, linux-doc, linux-kernel,
linux-mm, ljs, lukabai, lukafocus, mhocko, npache, rppt,
ryan.roberts, skhan, surenb, vbabka, ziy
Cc: syzbot, syzkaller-bugs
In-Reply-To: <20260501-thp_cow-v1-0-005377483738@tencent.com>
syzbot ci has tested the following series
[v1] mm: Support selecting doing direct COW for anonymous pmd entry
https://lore.kernel.org/all/20260501-thp_cow-v1-0-005377483738@tencent.com
* [PATCH 1/5] mm: add basic madvise helpers and branch for THP setup
* [PATCH 2/5] mm: add pmd level THP COW parameter in sysfs
* [PATCH 3/5] mm: add pmd level THP COW judgement helpers
* [PATCH 4/5] mm: enable map_anon_folio_pmd_nopf to handle unshare
* [PATCH 5/5] mm: support choosing to do THP COW for anonymous pmd entry.
and found the following issue:
general protection fault in __page_table_check_pmds_set
Full report is available here:
https://ci.syzbot.org/series/37e78e03-c08b-4de1-9b07-a21c64f4f462
***
general protection fault in __page_table_check_pmds_set
tree: mm-new
URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/akpm/mm.git
base: 41cd9e3d23b8fd9e6c3c0311e9cb0304442c6141
arch: amd64
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config: https://ci.syzbot.org/builds/fcdd679f-29e8-43db-8792-d4fd97c62d91/config
syz repro: https://ci.syzbot.org/findings/87820d58-5d91-4c2e-b80b-5a75006e230d/syz_repro
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 0 UID: 0 PID: 5807 Comm: syz.1.18 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
RIP: 0010:__page_table_check_pmds_set+0x1d4/0x340 mm/page_table_check.c:240
Code: 00 00 4c 89 6c 24 08 4c 89 3c 24 4a 8d 2c fd f8 ff ff ff 31 db 49 bf 00 00 00 00 00 fc ff df 49 8d 3c 1e 48 89 f8 48 c1 e8 03 <42> 80 3c 38 00 74 05 e8 00 29 f4 ff 4d 8b 24 1e 45 89 e5 41 81 e5
RSP: 0018:ffffc90003c46ee0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff8881102a1d80 RSI: 0000000000000001 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000001 R09: 1ffff110242081d8
R10: dffffc0000000000 R11: ffffed10242081d9 R12: dffffc0000000000
R13: 0000000025c008e7 R14: 0000000000000000 R15: dffffc0000000000
FS: 00007fbef78216c0(0000) GS:ffff88818dc91000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b32f63fff CR3: 000000002350a000 CR4: 00000000000006f0
Call Trace:
<TASK>
page_table_check_pmds_set include/linux/page_table_check.h:92 [inline]
set_pmd_at arch/x86/include/asm/pgtable.h:1209 [inline]
map_anon_folio_pmd_nopf+0x452/0x480 mm/huge_memory.c:1449
collapse_huge_page mm/khugepaged.c:1411 [inline]
mthp_collapse mm/khugepaged.c:1530 [inline]
collapse_scan_pmd mm/khugepaged.c:1773 [inline]
collapse_single_pmd+0x4691/0x5540 mm/khugepaged.c:2786
madvise_collapse+0x300/0x7a0 mm/khugepaged.c:3218
madvise_vma_behavior+0x11b0/0x4210 mm/madvise.c:1383
madvise_walk_vmas+0x573/0xae0 mm/madvise.c:1738
madvise_do_behavior+0x386/0x540 mm/madvise.c:1954
do_madvise+0x1fa/0x2e0 mm/madvise.c:2047
__do_sys_madvise mm/madvise.c:2056 [inline]
__se_sys_madvise mm/madvise.c:2054 [inline]
__x64_sys_madvise+0xa6/0xc0 mm/madvise.c:2054
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fbef699cdd9
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fbef7821028 EFLAGS: 00000246 ORIG_RAX: 000000000000001c
RAX: ffffffffffffffda RBX: 00007fbef6c15fa0 RCX: 00007fbef699cdd9
RDX: 0000000000000019 RSI: 0000000000400000 RDI: 0000200000000000
RBP: 00007fbef6a32d69 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fbef6c16038 R14: 00007fbef6c15fa0 R15: 00007ffdddd640f8
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:__page_table_check_pmds_set+0x1d4/0x340 mm/page_table_check.c:240
Code: 00 00 4c 89 6c 24 08 4c 89 3c 24 4a 8d 2c fd f8 ff ff ff 31 db 49 bf 00 00 00 00 00 fc ff df 49 8d 3c 1e 48 89 f8 48 c1 e8 03 <42> 80 3c 38 00 74 05 e8 00 29 f4 ff 4d 8b 24 1e 45 89 e5 41 81 e5
RSP: 0018:ffffc90003c46ee0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff8881102a1d80 RSI: 0000000000000001 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000001 R09: 1ffff110242081d8
R10: dffffc0000000000 R11: ffffed10242081d9 R12: dffffc0000000000
R13: 0000000025c008e7 R14: 0000000000000000 R15: dffffc0000000000
FS: 00007fbef78216c0(0000) GS:ffff88818dc91000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b32f63fff CR3: 000000002350a000 CR4: 00000000000006f0
----------------
Code disassembly (best guess):
0: 00 00 add %al,(%rax)
2: 4c 89 6c 24 08 mov %r13,0x8(%rsp)
7: 4c 89 3c 24 mov %r15,(%rsp)
b: 4a 8d 2c fd f8 ff ff lea -0x8(,%r15,8),%rbp
12: ff
13: 31 db xor %ebx,%ebx
15: 49 bf 00 00 00 00 00 movabs $0xdffffc0000000000,%r15
1c: fc ff df
1f: 49 8d 3c 1e lea (%r14,%rbx,1),%rdi
23: 48 89 f8 mov %rdi,%rax
26: 48 c1 e8 03 shr $0x3,%rax
* 2a: 42 80 3c 38 00 cmpb $0x0,(%rax,%r15,1) <-- trapping instruction
2f: 74 05 je 0x36
31: e8 00 29 f4 ff call 0xfff42936
36: 4d 8b 24 1e mov (%r14,%rbx,1),%r12
3a: 45 89 e5 mov %r12d,%r13d
3d: 41 rex.B
3e: 81 .byte 0x81
3f: e5 .byte 0xe5
***
If these findings have caused you to resend the series or submit a
separate fix, please add the following tag to your commit message:
Tested-by: syzbot@syzkaller.appspotmail.com
---
This report is generated by a bot. It may contain errors.
syzbot ci engineers can be reached at syzkaller@googlegroups.com.
To test a patch for this bug, please reply with `#syz test`
(should be on a separate line).
The patch should be attached to the email.
Note: arguments like custom git repos and branches are not supported.
^ permalink raw reply
* Re: [PATCH v2] tty: synclink_gt: remove broken driver
From: Greg Kroah-Hartman @ 2026-05-03 6:08 UTC (permalink / raw)
To: Ethan Nelson-Moore
Cc: linux-doc, netdev, linux-serial, rust-for-linux, Jonathan Corbet,
Shuah Khan, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jiri Slaby, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Bagas Sanjaya, Haren Myneni,
Eric Biggers, Qingfang Deng, Julian Braha
In-Reply-To: <CADkSEUgPtjkKC684O3qB=koKDPwJoUj-qU_4Z_18NAU_+bBqkw@mail.gmail.com>
On Sat, May 02, 2026 at 11:00:53PM -0700, Ethan Nelson-Moore wrote:
> Hi, Greg,
>
> On Sat, May 2, 2026 at 10:44 PM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > Then that means someone uses it somewhere. Don't generate bindings for
> > something that will break because it is no longer in the tree :(
> That project generates bindings for every UAPI header automatically,
> but has a hardcoded lost of them, so its presence there doesn't mean
> anyone is using it.
>
> > If no one does use it, then please get that project to fix their code so
> > that we don't break their build.
> They have had to remove headers from their list that got removed from
> the kernel before. I will send them a pull request to remove this
> header and then resend this patch with the UAPI header removal
> restored. Does that sound good to you?
Yes, thanks.
^ permalink raw reply
* Re: [PATCH v2] tty: synclink_gt: remove broken driver
From: Ethan Nelson-Moore @ 2026-05-03 6:00 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-doc, netdev, linux-serial, rust-for-linux, Jonathan Corbet,
Shuah Khan, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jiri Slaby, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Bagas Sanjaya, Haren Myneni,
Eric Biggers, Qingfang Deng, Julian Braha
In-Reply-To: <2026050340-kilogram-prissy-a833@gregkh>
Hi, Greg,
On Sat, May 2, 2026 at 10:44 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> Then that means someone uses it somewhere. Don't generate bindings for
> something that will break because it is no longer in the tree :(
That project generates bindings for every UAPI header automatically,
but has a hardcoded lost of them, so its presence there doesn't mean
anyone is using it.
> If no one does use it, then please get that project to fix their code so
> that we don't break their build.
They have had to remove headers from their list that got removed from
the kernel before. I will send them a pull request to remove this
header and then resend this patch with the UAPI header removal
restored. Does that sound good to you?
Ethan
^ permalink raw reply
* Re: [PATCH v2] tty: synclink_gt: remove broken driver
From: Greg Kroah-Hartman @ 2026-05-03 5:43 UTC (permalink / raw)
To: Ethan Nelson-Moore
Cc: linux-doc, netdev, linux-serial, rust-for-linux, Jonathan Corbet,
Shuah Khan, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jiri Slaby, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Bagas Sanjaya, Haren Myneni,
Eric Biggers, Qingfang Deng, Julian Braha
In-Reply-To: <20260503030801.14080-1-enelsonmoore@gmail.com>
On Sat, May 02, 2026 at 08:07:38PM -0700, Ethan Nelson-Moore wrote:
> The synclink_gt driver was marked as broken in commit 426263d5fb40
> ("tty: synclink_gt: mark as BROKEN") in July 2023 because it had severe
> structural problems and there had been no evidence of users since 2016.
> Since then, no meaningful improvements have been made to the driver,
> and it is unlikely that will ever happen due to the lack of interest.
> Drop the driver and references to it in comments and documentation.
> Retain include/uapi/linux/synclink.h to avoid breaking userspace
> software.
>
> Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
> ---
> Changes from v1:
> - Retain UAPI header - the linux-raw-sys Rust crate generates bindings
> for it [1]
Then that means someone uses it somewhere. Don't generate bindings for
something that will break because it is no longer in the tree :(
If no one does use it, then please get that project to fix their code so
that we don't break their build.
thanks,
greg k-h
^ permalink raw reply
* Re: [RFC PATCH] bpf: introduce TAINT_UNSAFE_BPF for mutating helpers
From: bot+bpf-ci @ 2026-05-03 4:44 UTC (permalink / raw)
To: atomlin, corbet, song, kpsingh, mattbobrowski, ast, daniel,
andrii, eddyz87, memxor, rostedt, mhiramat
Cc: skhan, jolsa, martin.lau, yonghong.song, mathieu.desnoyers,
atomlin, neelx, sean, chjohnst, steve, mproche, nick.lange,
linux-doc, linux-kernel, bpf, linux-trace-kernel, ast, andrii,
daniel, martin.lau, eddyz87, yonghong.song, clm, ihor.solodrai
In-Reply-To: <20260503035220.520479-1-atomlin@atomlin.com>
[-- Attachment #1: Type: text/plain, Size: 5603 bytes --]
> diff --git a/Documentation/admin-guide/tainted-kernels.rst b/Documentation/admin-guide/tainted-kernels.rst
> index 9ead927a37c0..630f24996e7b 100644
> --- a/Documentation/admin-guide/tainted-kernels.rst
> +++ b/Documentation/admin-guide/tainted-kernels.rst
> @@ -79,30 +79,31 @@ which bits are set::
> Table for decoding tainted state
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> -=== === ====== ========================================================
> -Bit Log Number Reason that got the kernel tainted
> -=== === ====== ========================================================
[ ... ]
> + 19 _/J 524288 userspace used a mutating debug operation in fwctl
> + 20 _/V 1048576 an unsafe eBPF program (mutating helper) was loaded
> +=== === ======= ========================================================
This isn't a bug, but the bottom border has 7 equals signs (=======) for
the Number column while the top and header borders have 6 (======). Will
this cause a Sphinx 'Malformed table' warning when rendering the
documentation?
Earlier in the same file, around line 77, there's a shell command example
for checking taint bits. With the addition of bit 20, shouldn't that
command be updated from 'seq 20' to 'seq 21' so it checks all 21 bits
(0-20)?
The current command only checks bits 0-19:
$ for i in $(seq 20); do echo $(($i-1)) $(($(cat /proc/sys/kernel/tainted)>>($i-1)&1));done
Since 'seq 20' produces 1..20, and the expression uses $(($i-1)), it only
computes bit positions 0..19, missing the newly added bit 20.
> @@ -189,3 +190,8 @@ More detailed explanation for tainting
> 19) ``J`` if userspace opened /dev/fwctl/* and performed a FWTCL_RPC_DEBUG_WRITE
> to use the devices debugging features. Device debugging features could
> cause the device to malfunction in undefined ways.
> +
> + 20) ``V`` if an eBPF program utilising unsafe, mutating helpers (such as
> + bpf_probe_write_user() or bpf_override_return()) was loaded. These helpers
> + bypass standard eBPF safety guarantees and can alter execution flow or
> + corrupt memory.
> diff --git a/include/linux/panic.h b/include/linux/panic.h
> index f1dd417e54b2..8622c02c2c24 100644
> --- a/include/linux/panic.h
> +++ b/include/linux/panic.h
> @@ -88,7 +88,8 @@ static inline void set_arch_panic_timeout(int timeout, int arch_default_timeout)
> #define TAINT_RANDSTRUCT 17
> #define TAINT_TEST 18
> #define TAINT_FWCTL 19
> -#define TAINT_FLAGS_COUNT 20
> +#define TAINT_UNSAFE_BPF 20
> +#define TAINT_FLAGS_COUNT 21
> #define TAINT_FLAGS_MAX ((1UL << TAINT_FLAGS_COUNT) - 1)
>
> struct taint_flag {
> diff --git a/kernel/panic.c b/kernel/panic.c
> index 20feada5319d..1ae19bd8fc1d 100644
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -825,6 +825,7 @@ const struct taint_flag taint_flags[TAINT_FLAGS_COUNT] = {
> TAINT_FLAG(RANDSTRUCT, 'T', ' '),
> TAINT_FLAG(TEST, 'N', ' '),
> TAINT_FLAG(FWCTL, 'J', ' '),
> + TAINT_FLAG(UNSAFE_BPF, 'V', ' '),
> };
>
> #undef TAINT_FLAG
There's a comment earlier in this file that explicitly states: "if you
modify the taint_flags or TAINT_FLAGS_COUNT, please also modify
tools/debugging/kernel-chktaint and
Documentation/admin-guide/tainted-kernels.rst".
While the Documentation was updated, was tools/debugging/kernel-chktaint
also updated? The script currently processes flags 0-19 and ends with the
J flag check. Without adding a section to check bit 20, the script won't
decode the 'V' character in the taint string output when
TAINT_UNSAFE_BPF is set.
The script would need something like:
T=`expr $T / 2`
if [ `expr $T % 2` -eq 0 ]; then
addout " "
else
addout "V"
echo " * an unsafe eBPF program (mutating helper) was loaded (#20)"
fi
> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> index a822c589c9bd..3f893d9ea764 100644
> --- a/kernel/trace/bpf_trace.c
> +++ b/kernel/trace/bpf_trace.c
> @@ -183,6 +183,7 @@ unsigned int trace_call_bpf_faultable(struct trace_event_call *call, void *ctx)
> #ifdef CONFIG_BPF_KPROBE_OVERRIDE
> BPF_CALL_2(bpf_override_return, struct pt_regs *, regs, unsigned long, rc)
> {
> + add_taint(TAINT_UNSAFE_BPF, LOCKDEP_STILL_OK);
> regs_set_return_value(regs, rc);
> override_function_with_return(regs);
> return 0;
Since bpf_override_return is a helper invoked at runtime and can execute
frequently on hot kprobes, will calling add_taint() here cause severe
cache line bouncing?
Looking at add_taint(), it unconditionally calls set_bit() on the global
tainted_mask.
Also, the commit message and documentation mention the system is tainted
when an unsafe eBPF program 'was loaded'. By applying the taint here
during execution instead of at program load time (e.g., in the verifier),
could this allow an unsafe BPF program to remain dormant and avoid
detection until a specific trigger occurs?
> @@ -372,6 +373,8 @@ BPF_CALL_3(bpf_probe_write_user, void __user *, unsafe_ptr, const void *, src,
> if (unlikely(!nmi_uaccess_okay()))
> return -EPERM;
>
> + add_taint(TAINT_UNSAFE_BPF, LOCKDEP_STILL_OK);
> +
> return copy_to_user_nofault(unsafe_ptr, src, size);
> }
Similarly here, will invoking add_taint() on every execution of
bpf_probe_write_user() cause significant performance degradation when
executed concurrently across multiple CPUs?
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/25269516443
^ permalink raw reply
* Re: [RFC PATCH] bpf: introduce TAINT_UNSAFE_BPF for mutating helpers
From: Randy Dunlap @ 2026-05-03 4:29 UTC (permalink / raw)
To: Aaron Tomlin, corbet, song, kpsingh, mattbobrowski, ast, daniel,
andrii, eddyz87, memxor, rostedt, mhiramat
Cc: skhan, jolsa, martin.lau, yonghong.song, mathieu.desnoyers, neelx,
sean, chjohnst, steve, mproche, nick.lange, linux-doc,
linux-kernel, bpf, linux-trace-kernel
In-Reply-To: <20260503035220.520479-1-atomlin@atomlin.com>
Hi,
On 5/2/26 8:52 PM, Aaron Tomlin wrote:
> The primary remit of the eBPF verifier is to ensure that eBPF programs
> can neither crash the kernel nor corrupt memory. Nevertheless,
> administrative utilities such as "bpftrace --unsafe" permit the loading
> of programs that employ destructive or mutating helpers, most notably
> bpf_probe_write_user() and bpf_override_return().
>
> Since commit b28573ebfabe ("bpf: Remove bpf_probe_write_user() warning
> message"), the kernel no longer issues a warning when an attempt is made to
> invoke such destructive helpers.
>
> Consequently, this patch introduces a novel kernel taint flag,
> TAINT_UNSAFE_BPF ("V"). Tainting the kernel establishes a permanent and
> readily auditable indicator (i.e., /proc/sys/kernel/tainted) to alert
> maintainers and that the kernel's execution flow or user memory may have
> been compromised by an eBPF program.
>
> Signed-off-by: Aaron Tomlin <atomlin@atomlin.com>
> ---
> Documentation/admin-guide/tainted-kernels.rst | 54 ++++++++++---------
> include/linux/panic.h | 3 +-
> kernel/panic.c | 1 +
> kernel/trace/bpf_trace.c | 3 ++
> 4 files changed, 36 insertions(+), 25 deletions(-)
>
> diff --git a/Documentation/admin-guide/tainted-kernels.rst b/Documentation/admin-guide/tainted-kernels.rst
> index 9ead927a37c0..630f24996e7b 100644
> --- a/Documentation/admin-guide/tainted-kernels.rst
> +++ b/Documentation/admin-guide/tainted-kernels.rst
> @@ -79,30 +79,31 @@ which bits are set::
> Table for decoding tainted state
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> -=== === ====== ========================================================
> -Bit Log Number Reason that got the kernel tainted
> -=== === ====== ========================================================
> - 0 G/P 1 proprietary module was loaded
> - 1 _/F 2 module was force loaded
> - 2 _/S 4 kernel running on an out of specification system
> - 3 _/R 8 module was force unloaded
> - 4 _/M 16 processor reported a Machine Check Exception (MCE)
> - 5 _/B 32 bad page referenced or some unexpected page flags
> - 6 _/U 64 taint requested by userspace application
> - 7 _/D 128 kernel died recently, i.e. there was an OOPS or BUG
> - 8 _/A 256 ACPI table overridden by user
> - 9 _/W 512 kernel issued warning
> - 10 _/C 1024 staging driver was loaded
> - 11 _/I 2048 workaround for bug in platform firmware applied
> - 12 _/O 4096 externally-built ("out-of-tree") module was loaded
> - 13 _/E 8192 unsigned module was loaded
> - 14 _/L 16384 soft lockup occurred
> - 15 _/K 32768 kernel has been live patched
> - 16 _/X 65536 auxiliary taint, defined for and used by distros
> - 17 _/T 131072 kernel was built with the struct randomization plugin
> - 18 _/N 262144 an in-kernel test has been run
> - 19 _/J 524288 userspace used a mutating debug operation in fwctl
> -=== === ====== ========================================================
> +=== === ====== ========================================================
> +Bit Log Number Reason that got the kernel tainted
> +=== === ====== ========================================================
> + 0 G/P 1 proprietary module was loaded
> + 1 _/F 2 module was force loaded
> + 2 _/S 4 kernel running on an out of specification system
> + 3 _/R 8 module was force unloaded
> + 4 _/M 16 processor reported a Machine Check Exception (MCE)
> + 5 _/B 32 bad page referenced or some unexpected page flags
> + 6 _/U 64 taint requested by userspace application
> + 7 _/D 128 kernel died recently, i.e. there was an OOPS or BUG
> + 8 _/A 256 ACPI table overridden by user
> + 9 _/W 512 kernel issued warning
> + 10 _/C 1024 staging driver was loaded
> + 11 _/I 2048 workaround for bug in platform firmware applied
> + 12 _/O 4096 externally-built ("out-of-tree") module was loaded
> + 13 _/E 8192 unsigned module was loaded
> + 14 _/L 16384 soft lockup occurred
> + 15 _/K 32768 kernel has been live patched
> + 16 _/X 65536 auxiliary taint, defined for and used by distros
> + 17 _/T 131072 kernel was built with the struct randomization plugin
> + 18 _/N 262144 an in-kernel test has been run
> + 19 _/J 524288 userspace used a mutating debug operation in fwctl
> + 20 _/V 1048576 an unsafe eBPF program (mutating helper) was loaded
> +=== === ======= ========================================================
>
> Note: The character ``_`` is representing a blank in this table to make reading
> easier.
> @@ -189,3 +190,8 @@ More detailed explanation for tainting
> 19) ``J`` if userspace opened /dev/fwctl/* and performed a FWTCL_RPC_DEBUG_WRITE
> to use the devices debugging features. Device debugging features could
> cause the device to malfunction in undefined ways.
> +
> + 20) ``V`` if an eBPF program utilising unsafe, mutating helpers (such as
> + bpf_probe_write_user() or bpf_override_return()) was loaded. These helpers
> + bypass standard eBPF safety guarantees and can alter execution flow or
> + corrupt memory.
(If this patch goes forward:)
In this same file (above), there is a little script around line 77 where
it should be changed:
s/20/21/
Also please update tools/debugging/kernel-chktaint for this taint flag.
--
~Randy
^ permalink raw reply
* [PATCH] char: applicom: remove low-quality, unused driver
From: Ethan Nelson-Moore @ 2026-05-03 3:58 UTC (permalink / raw)
To: linux-kernel, linux-doc
Cc: Ethan Nelson-Moore, Jonathan Corbet, Shuah Khan, Arnd Bergmann,
Greg Kroah-Hartman, Jiri Slaby (SUSE), Max Nikulin,
Martin K. Petersen
The applicom driver supports PCI Profibus cards from Applicom, later
acquired by Molex. It has severe coding style issues and has attracted
a number of bug and security fixes over the years, despite the fact
that no one appears to be using it. It was broken from at least the
beginning of Git history (Linux 2.6.12-rc2 in April 2005) until October
2008, when a fatal bug was fixed in commit bc20589bf1c6 ("applicom.c:
fix apparently-broken code in do_ac_read()"). In the commit message,
the author commented that no one they knew was able to test the change.
Since then, there have been no commits that indicate the driver is
being used. Later PCI and PCI-Express Applicom Profibus cards only
officially support Windows [1], and even the PCI-Express cards have
been discontinued [2]. Given all these factors, remove the driver to
reduce future maintenance workload.
[1] https://www.sarcitalia.it/file_upload/prodotti//PCIE1500S7_PFB_987651-3769_0876250001505823933.pdf
[2] https://us.rs-online.com/product/molex-woodhead-brad/112011-5026/70631928/
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
Documentation/admin-guide/devices.txt | 1 -
drivers/char/Kconfig | 15 -
drivers/char/Makefile | 1 -
drivers/char/applicom.c | 857 --------------------------
drivers/char/applicom.h | 86 ---
5 files changed, 960 deletions(-)
delete mode 100644 drivers/char/applicom.c
delete mode 100644 drivers/char/applicom.h
diff --git a/Documentation/admin-guide/devices.txt b/Documentation/admin-guide/devices.txt
index 440633642fea..f544399675fa 100644
--- a/Documentation/admin-guide/devices.txt
+++ b/Documentation/admin-guide/devices.txt
@@ -291,7 +291,6 @@
154 = /dev/pmu Macintosh PowerBook power manager
155 =
156 = /dev/lcd Front panel LCD display
- 157 = /dev/ac Applicom Intl Profibus card
158 = /dev/nwbutton Netwinder external button
159 = /dev/nwdebug Netwinder debug interface
160 = /dev/nwflash Netwinder flash memory
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 2a3a37b2cf3c..a0e58be77aa0 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -220,21 +220,6 @@ config XILINX_HWICAP
If unsure, say N.
-config APPLICOM
- tristate "Applicom intelligent fieldbus card support"
- depends on PCI
- help
- This driver provides the kernel-side support for the intelligent
- fieldbus cards made by Applicom International. More information
- about these cards can be found on the WWW at the address
- <https://www.applicom-int.com/>, or by email from David Woodhouse
- <dwmw2@infradead.org>.
-
- To compile this driver as a module, choose M here: the
- module will be called applicom.
-
- If unsure, say N.
-
config SONYPI
tristate "Sony Vaio Programmable I/O Control Device support"
depends on X86_32 && PCI && INPUT && HAS_IOPORT
diff --git a/drivers/char/Makefile b/drivers/char/Makefile
index 47bdc882797a..fb6aa6a5d2c7 100644
--- a/drivers/char/Makefile
+++ b/drivers/char/Makefile
@@ -17,7 +17,6 @@ obj-$(CONFIG_PRINTER) += lp.o
obj-$(CONFIG_APM_EMULATION) += apm-emulation.o
obj-$(CONFIG_DTLK) += dtlk.o
-obj-$(CONFIG_APPLICOM) += applicom.o
obj-$(CONFIG_SONYPI) += sonypi.o
obj-$(CONFIG_HPET) += hpet.o
obj-$(CONFIG_XILINX_HWICAP) += xilinx_hwicap/
diff --git a/drivers/char/applicom.c b/drivers/char/applicom.c
deleted file mode 100644
index c138c468f3a4..000000000000
--- a/drivers/char/applicom.c
+++ /dev/null
@@ -1,857 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/* Derived from Applicom driver ac.c for SCO Unix */
-/* Ported by David Woodhouse, Axiom (Cambridge) Ltd. */
-/* dwmw2@infradead.org 30/8/98 */
-/* $Id: ac.c,v 1.30 2000/03/22 16:03:57 dwmw2 Exp $ */
-/* This module is for Linux 2.1 and 2.2 series kernels. */
-/*****************************************************************************/
-/* J PAGET 18/02/94 passage V2.4.2 ioctl avec code 2 reset to les interrupt */
-/* ceci pour reseter correctement apres une sortie sauvage */
-/* J PAGET 02/05/94 passage V2.4.3 dans le traitement de d'interruption, */
-/* LoopCount n'etait pas initialise a 0. */
-/* F LAFORSE 04/07/95 version V2.6.0 lecture bidon apres acces a une carte */
-/* pour liberer le bus */
-/* J.PAGET 19/11/95 version V2.6.1 Nombre, addresse,irq n'est plus configure */
-/* et passe en argument a acinit, mais est scrute sur le bus pour s'adapter */
-/* au nombre de cartes presentes sur le bus. IOCL code 6 affichait V2.4.3 */
-/* F.LAFORSE 28/11/95 creation de fichiers acXX.o avec les differentes */
-/* addresses de base des cartes, IOCTL 6 plus complet */
-/* J.PAGET le 19/08/96 copie de la version V2.6 en V2.8.0 sans modification */
-/* de code autre que le texte V2.6.1 en V2.8.0 */
-/*****************************************************************************/
-
-
-#include <linux/kernel.h>
-#include <linux/module.h>
-#include <linux/interrupt.h>
-#include <linux/sched/signal.h>
-#include <linux/slab.h>
-#include <linux/errno.h>
-#include <linux/mutex.h>
-#include <linux/miscdevice.h>
-#include <linux/pci.h>
-#include <linux/wait.h>
-#include <linux/init.h>
-#include <linux/fs.h>
-#include <linux/nospec.h>
-
-#include <asm/io.h>
-#include <linux/uaccess.h>
-
-#include "applicom.h"
-
-
-/* NOTE: We use for loops with {write,read}b() instead of
- memcpy_{from,to}io throughout this driver. This is because
- the board doesn't correctly handle word accesses - only
- bytes.
-*/
-
-
-#undef DEBUG
-
-#define MAX_BOARD 8 /* maximum of pc board possible */
-#define MAX_ISA_BOARD 4
-#define LEN_RAM_IO 0x800
-
-#ifndef PCI_VENDOR_ID_APPLICOM
-#define PCI_VENDOR_ID_APPLICOM 0x1389
-#define PCI_DEVICE_ID_APPLICOM_PCIGENERIC 0x0001
-#define PCI_DEVICE_ID_APPLICOM_PCI2000IBS_CAN 0x0002
-#define PCI_DEVICE_ID_APPLICOM_PCI2000PFB 0x0003
-#endif
-
-static DEFINE_MUTEX(ac_mutex);
-static char *applicom_pci_devnames[] = {
- "PCI board",
- "PCI2000IBS / PCI2000CAN",
- "PCI2000PFB"
-};
-
-static const struct pci_device_id applicom_pci_tbl[] = {
- { PCI_VDEVICE(APPLICOM, PCI_DEVICE_ID_APPLICOM_PCIGENERIC) },
- { PCI_VDEVICE(APPLICOM, PCI_DEVICE_ID_APPLICOM_PCI2000IBS_CAN) },
- { PCI_VDEVICE(APPLICOM, PCI_DEVICE_ID_APPLICOM_PCI2000PFB) },
- { 0 }
-};
-MODULE_DEVICE_TABLE(pci, applicom_pci_tbl);
-
-MODULE_AUTHOR("David Woodhouse & Applicom International");
-MODULE_DESCRIPTION("Driver for Applicom Profibus card");
-MODULE_LICENSE("GPL");
-MODULE_ALIAS_MISCDEV(AC_MINOR);
-
-static struct applicom_board {
- unsigned long PhysIO;
- void __iomem *RamIO;
- wait_queue_head_t FlagSleepSend;
- long irq;
- spinlock_t mutex;
-} apbs[MAX_BOARD];
-
-static unsigned int irq; /* interrupt number IRQ */
-static unsigned long mem; /* physical segment of board */
-
-module_param_hw(irq, uint, irq, 0);
-MODULE_PARM_DESC(irq, "IRQ of the Applicom board");
-module_param_hw(mem, ulong, iomem, 0);
-MODULE_PARM_DESC(mem, "Shared Memory Address of Applicom board");
-
-static unsigned int numboards; /* number of installed boards */
-static volatile unsigned char Dummy;
-static DECLARE_WAIT_QUEUE_HEAD(FlagSleepRec);
-static unsigned int WriteErrorCount; /* number of write error */
-static unsigned int ReadErrorCount; /* number of read error */
-static unsigned int DeviceErrorCount; /* number of device error */
-
-static ssize_t ac_read (struct file *, char __user *, size_t, loff_t *);
-static ssize_t ac_write (struct file *, const char __user *, size_t, loff_t *);
-static long ac_ioctl(struct file *, unsigned int, unsigned long);
-static irqreturn_t ac_interrupt(int, void *);
-
-static const struct file_operations ac_fops = {
- .owner = THIS_MODULE,
- .read = ac_read,
- .write = ac_write,
- .unlocked_ioctl = ac_ioctl,
-};
-
-static struct miscdevice ac_miscdev = {
- AC_MINOR,
- "ac",
- &ac_fops
-};
-
-static int dummy; /* dev_id for request_irq() */
-
-static int ac_register_board(unsigned long physloc, void __iomem *loc,
- unsigned char boardno)
-{
- volatile unsigned char byte_reset_it;
-
- if((readb(loc + CONF_END_TEST) != 0x00) ||
- (readb(loc + CONF_END_TEST + 1) != 0x55) ||
- (readb(loc + CONF_END_TEST + 2) != 0xAA) ||
- (readb(loc + CONF_END_TEST + 3) != 0xFF))
- return 0;
-
- if (!boardno)
- boardno = readb(loc + NUMCARD_OWNER_TO_PC);
-
- if (!boardno || boardno > MAX_BOARD) {
- printk(KERN_WARNING "Board #%d (at 0x%lx) is out of range (1 <= x <= %d).\n",
- boardno, physloc, MAX_BOARD);
- return 0;
- }
-
- if (apbs[boardno - 1].RamIO) {
- printk(KERN_WARNING "Board #%d (at 0x%lx) conflicts with previous board #%d (at 0x%lx)\n",
- boardno, physloc, boardno, apbs[boardno-1].PhysIO);
- return 0;
- }
-
- boardno--;
-
- apbs[boardno].PhysIO = physloc;
- apbs[boardno].RamIO = loc;
- init_waitqueue_head(&apbs[boardno].FlagSleepSend);
- spin_lock_init(&apbs[boardno].mutex);
- byte_reset_it = readb(loc + RAM_IT_TO_PC);
-
- numboards++;
- return boardno + 1;
-}
-
-static void __exit applicom_exit(void)
-{
- unsigned int i;
-
- misc_deregister(&ac_miscdev);
-
- for (i = 0; i < MAX_BOARD; i++) {
-
- if (!apbs[i].RamIO)
- continue;
-
- if (apbs[i].irq)
- free_irq(apbs[i].irq, &dummy);
-
- iounmap(apbs[i].RamIO);
- }
-}
-
-static int __init applicom_init(void)
-{
- int i, numisa = 0;
- struct pci_dev *dev = NULL;
- void __iomem *RamIO;
- int boardno, ret;
-
- printk(KERN_INFO "Applicom driver: $Id: ac.c,v 1.30 2000/03/22 16:03:57 dwmw2 Exp $\n");
-
- /* No mem and irq given - check for a PCI card */
-
- while ( (dev = pci_get_class(PCI_CLASS_OTHERS << 16, dev))) {
-
- if (!pci_match_id(applicom_pci_tbl, dev))
- continue;
-
- if (pci_enable_device(dev)) {
- pci_dev_put(dev);
- return -EIO;
- }
-
- RamIO = ioremap(pci_resource_start(dev, 0), LEN_RAM_IO);
-
- if (!RamIO) {
- printk(KERN_INFO "ac.o: Failed to ioremap PCI memory "
- "space at 0x%llx\n",
- (unsigned long long)pci_resource_start(dev, 0));
- pci_disable_device(dev);
- pci_dev_put(dev);
- return -EIO;
- }
-
- printk(KERN_INFO "Applicom %s found at mem 0x%llx, irq %d\n",
- applicom_pci_devnames[dev->device-1],
- (unsigned long long)pci_resource_start(dev, 0),
- dev->irq);
-
- boardno = ac_register_board(pci_resource_start(dev, 0),
- RamIO, 0);
- if (!boardno) {
- printk(KERN_INFO "ac.o: PCI Applicom device doesn't have correct signature.\n");
- iounmap(RamIO);
- pci_disable_device(dev);
- continue;
- }
-
- if (request_irq(dev->irq, &ac_interrupt, IRQF_SHARED, "Applicom PCI", &dummy)) {
- printk(KERN_INFO "Could not allocate IRQ %d for PCI Applicom device.\n", dev->irq);
- iounmap(RamIO);
- pci_disable_device(dev);
- apbs[boardno - 1].RamIO = NULL;
- continue;
- }
-
- /* Enable interrupts. */
-
- writeb(0x40, apbs[boardno - 1].RamIO + RAM_IT_FROM_PC);
-
- apbs[boardno - 1].irq = dev->irq;
- }
-
- /* Finished with PCI cards. If none registered,
- * and there was no mem/irq specified, exit */
-
- if (!mem || !irq) {
- if (numboards)
- goto fin;
- else {
- printk(KERN_INFO "ac.o: No PCI boards found.\n");
- printk(KERN_INFO "ac.o: For an ISA board you must supply memory and irq parameters.\n");
- return -ENXIO;
- }
- }
-
- /* Now try the specified ISA cards */
-
- for (i = 0; i < MAX_ISA_BOARD; i++) {
- RamIO = ioremap(mem + (LEN_RAM_IO * i), LEN_RAM_IO);
-
- if (!RamIO) {
- printk(KERN_INFO "ac.o: Failed to ioremap the ISA card's memory space (slot #%d)\n", i + 1);
- continue;
- }
-
- if (!(boardno = ac_register_board((unsigned long)mem+ (LEN_RAM_IO*i),
- RamIO,i+1))) {
- iounmap(RamIO);
- continue;
- }
-
- printk(KERN_NOTICE "Applicom ISA card found at mem 0x%lx, irq %d\n", mem + (LEN_RAM_IO*i), irq);
-
- if (!numisa) {
- if (request_irq(irq, &ac_interrupt, IRQF_SHARED, "Applicom ISA", &dummy)) {
- printk(KERN_WARNING "Could not allocate IRQ %d for ISA Applicom device.\n", irq);
- iounmap(RamIO);
- apbs[boardno - 1].RamIO = NULL;
- }
- else
- apbs[boardno - 1].irq = irq;
- }
- else
- apbs[boardno - 1].irq = 0;
-
- numisa++;
- }
-
- if (!numisa)
- printk(KERN_WARNING "ac.o: No valid ISA Applicom boards found "
- "at mem 0x%lx\n", mem);
-
- fin:
- init_waitqueue_head(&FlagSleepRec);
-
- WriteErrorCount = 0;
- ReadErrorCount = 0;
- DeviceErrorCount = 0;
-
- if (numboards) {
- ret = misc_register(&ac_miscdev);
- if (ret) {
- printk(KERN_WARNING "ac.o: Unable to register misc device\n");
- goto out;
- }
- for (i = 0; i < MAX_BOARD; i++) {
- int serial;
- char boardname[(SERIAL_NUMBER - TYPE_CARD) + 1];
-
- if (!apbs[i].RamIO)
- continue;
-
- for (serial = 0; serial < SERIAL_NUMBER - TYPE_CARD; serial++)
- boardname[serial] = readb(apbs[i].RamIO + TYPE_CARD + serial);
-
- boardname[serial] = 0;
-
-
- printk(KERN_INFO "Applicom board %d: %s, PROM V%d.%d",
- i+1, boardname,
- (int)(readb(apbs[i].RamIO + VERS) >> 4),
- (int)(readb(apbs[i].RamIO + VERS) & 0xF));
-
- serial = (readb(apbs[i].RamIO + SERIAL_NUMBER) << 16) +
- (readb(apbs[i].RamIO + SERIAL_NUMBER + 1) << 8) +
- (readb(apbs[i].RamIO + SERIAL_NUMBER + 2) );
-
- if (serial != 0)
- printk(" S/N %d\n", serial);
- else
- printk("\n");
- }
- return 0;
- }
-
- else
- return -ENXIO;
-
-out:
- for (i = 0; i < MAX_BOARD; i++) {
- if (!apbs[i].RamIO)
- continue;
- if (apbs[i].irq)
- free_irq(apbs[i].irq, &dummy);
- iounmap(apbs[i].RamIO);
- }
- return ret;
-}
-
-module_init(applicom_init);
-module_exit(applicom_exit);
-
-
-static ssize_t ac_write(struct file *file, const char __user *buf, size_t count, loff_t * ppos)
-{
- unsigned int NumCard; /* Board number 1 -> 8 */
- unsigned int IndexCard; /* Index board number 0 -> 7 */
- unsigned char TicCard; /* Board TIC to send */
- unsigned long flags; /* Current priority */
- struct st_ram_io st_loc;
- struct mailbox tmpmailbox;
-#ifdef DEBUG
- int c;
-#endif
- DECLARE_WAITQUEUE(wait, current);
-
- if (count != sizeof(struct st_ram_io) + sizeof(struct mailbox)) {
- static int warncount = 5;
- if (warncount) {
- printk(KERN_INFO "Hmmm. write() of Applicom card, length %zd != expected %zd\n",
- count, sizeof(struct st_ram_io) + sizeof(struct mailbox));
- warncount--;
- }
- return -EINVAL;
- }
-
- if(copy_from_user(&st_loc, buf, sizeof(struct st_ram_io)))
- return -EFAULT;
-
- if(copy_from_user(&tmpmailbox, &buf[sizeof(struct st_ram_io)],
- sizeof(struct mailbox)))
- return -EFAULT;
-
- NumCard = st_loc.num_card; /* board number to send */
- TicCard = st_loc.tic_des_from_pc; /* tic number to send */
- IndexCard = NumCard - 1;
-
- if (IndexCard >= MAX_BOARD)
- return -EINVAL;
- IndexCard = array_index_nospec(IndexCard, MAX_BOARD);
-
- if (!apbs[IndexCard].RamIO)
- return -EINVAL;
-
-#ifdef DEBUG
- printk("Write to applicom card #%d. struct st_ram_io follows:",
- IndexCard+1);
-
- for (c = 0; c < sizeof(struct st_ram_io);) {
-
- printk("\n%5.5X: %2.2X", c, ((unsigned char *) &st_loc)[c]);
-
- for (c++; c % 8 && c < sizeof(struct st_ram_io); c++) {
- printk(" %2.2X", ((unsigned char *) &st_loc)[c]);
- }
- }
-
- printk("\nstruct mailbox follows:");
-
- for (c = 0; c < sizeof(struct mailbox);) {
- printk("\n%5.5X: %2.2X", c, ((unsigned char *) &tmpmailbox)[c]);
-
- for (c++; c % 8 && c < sizeof(struct mailbox); c++) {
- printk(" %2.2X", ((unsigned char *) &tmpmailbox)[c]);
- }
- }
-
- printk("\n");
-#endif
-
- spin_lock_irqsave(&apbs[IndexCard].mutex, flags);
-
- /* Test octet ready correct */
- if(readb(apbs[IndexCard].RamIO + DATA_FROM_PC_READY) > 2) {
- Dummy = readb(apbs[IndexCard].RamIO + VERS);
- spin_unlock_irqrestore(&apbs[IndexCard].mutex, flags);
- printk(KERN_WARNING "APPLICOM driver write error board %d, DataFromPcReady = %d\n",
- IndexCard,(int)readb(apbs[IndexCard].RamIO + DATA_FROM_PC_READY));
- DeviceErrorCount++;
- return -EIO;
- }
-
- /* Place ourselves on the wait queue */
- set_current_state(TASK_INTERRUPTIBLE);
- add_wait_queue(&apbs[IndexCard].FlagSleepSend, &wait);
-
- /* Check whether the card is ready for us */
- while (readb(apbs[IndexCard].RamIO + DATA_FROM_PC_READY) != 0) {
- Dummy = readb(apbs[IndexCard].RamIO + VERS);
- /* It's busy. Sleep. */
-
- spin_unlock_irqrestore(&apbs[IndexCard].mutex, flags);
- schedule();
- if (signal_pending(current)) {
- remove_wait_queue(&apbs[IndexCard].FlagSleepSend,
- &wait);
- return -EINTR;
- }
- spin_lock_irqsave(&apbs[IndexCard].mutex, flags);
- set_current_state(TASK_INTERRUPTIBLE);
- }
-
- /* We may not have actually slept */
- set_current_state(TASK_RUNNING);
- remove_wait_queue(&apbs[IndexCard].FlagSleepSend, &wait);
-
- writeb(1, apbs[IndexCard].RamIO + DATA_FROM_PC_READY);
-
- /* Which is best - lock down the pages with rawio and then
- copy directly, or use bounce buffers? For now we do the latter
- because it works with 2.2 still */
- {
- unsigned char *from = (unsigned char *) &tmpmailbox;
- void __iomem *to = apbs[IndexCard].RamIO + RAM_FROM_PC;
- int c;
-
- for (c = 0; c < sizeof(struct mailbox); c++)
- writeb(*(from++), to++);
- }
-
- writeb(0x20, apbs[IndexCard].RamIO + TIC_OWNER_FROM_PC);
- writeb(0xff, apbs[IndexCard].RamIO + NUMCARD_OWNER_FROM_PC);
- writeb(TicCard, apbs[IndexCard].RamIO + TIC_DES_FROM_PC);
- writeb(NumCard, apbs[IndexCard].RamIO + NUMCARD_DES_FROM_PC);
- writeb(2, apbs[IndexCard].RamIO + DATA_FROM_PC_READY);
- writeb(1, apbs[IndexCard].RamIO + RAM_IT_FROM_PC);
- Dummy = readb(apbs[IndexCard].RamIO + VERS);
- spin_unlock_irqrestore(&apbs[IndexCard].mutex, flags);
- return 0;
-}
-
-static int do_ac_read(int IndexCard, char __user *buf,
- struct st_ram_io *st_loc, struct mailbox *mailbox)
-{
- void __iomem *from = apbs[IndexCard].RamIO + RAM_TO_PC;
- unsigned char *to = (unsigned char *)mailbox;
-#ifdef DEBUG
- int c;
-#endif
-
- st_loc->tic_owner_to_pc = readb(apbs[IndexCard].RamIO + TIC_OWNER_TO_PC);
- st_loc->numcard_owner_to_pc = readb(apbs[IndexCard].RamIO + NUMCARD_OWNER_TO_PC);
-
-
- {
- int c;
-
- for (c = 0; c < sizeof(struct mailbox); c++)
- *(to++) = readb(from++);
- }
- writeb(1, apbs[IndexCard].RamIO + ACK_FROM_PC_READY);
- writeb(1, apbs[IndexCard].RamIO + TYP_ACK_FROM_PC);
- writeb(IndexCard+1, apbs[IndexCard].RamIO + NUMCARD_ACK_FROM_PC);
- writeb(readb(apbs[IndexCard].RamIO + TIC_OWNER_TO_PC),
- apbs[IndexCard].RamIO + TIC_ACK_FROM_PC);
- writeb(2, apbs[IndexCard].RamIO + ACK_FROM_PC_READY);
- writeb(0, apbs[IndexCard].RamIO + DATA_TO_PC_READY);
- writeb(2, apbs[IndexCard].RamIO + RAM_IT_FROM_PC);
- Dummy = readb(apbs[IndexCard].RamIO + VERS);
-
-#ifdef DEBUG
- printk("Read from applicom card #%d. struct st_ram_io follows:", NumCard);
-
- for (c = 0; c < sizeof(struct st_ram_io);) {
- printk("\n%5.5X: %2.2X", c, ((unsigned char *)st_loc)[c]);
-
- for (c++; c % 8 && c < sizeof(struct st_ram_io); c++) {
- printk(" %2.2X", ((unsigned char *)st_loc)[c]);
- }
- }
-
- printk("\nstruct mailbox follows:");
-
- for (c = 0; c < sizeof(struct mailbox);) {
- printk("\n%5.5X: %2.2X", c, ((unsigned char *)mailbox)[c]);
-
- for (c++; c % 8 && c < sizeof(struct mailbox); c++) {
- printk(" %2.2X", ((unsigned char *)mailbox)[c]);
- }
- }
- printk("\n");
-#endif
- return (sizeof(struct st_ram_io) + sizeof(struct mailbox));
-}
-
-static ssize_t ac_read (struct file *filp, char __user *buf, size_t count, loff_t *ptr)
-{
- unsigned long flags;
- unsigned int i;
- unsigned char tmp;
- int ret = 0;
- DECLARE_WAITQUEUE(wait, current);
-#ifdef DEBUG
- int loopcount=0;
-#endif
- /* No need to ratelimit this. Only root can trigger it anyway */
- if (count != sizeof(struct st_ram_io) + sizeof(struct mailbox)) {
- printk( KERN_WARNING "Hmmm. read() of Applicom card, length %zd != expected %zd\n",
- count,sizeof(struct st_ram_io) + sizeof(struct mailbox));
- return -EINVAL;
- }
-
- while(1) {
- /* Stick ourself on the wait queue */
- set_current_state(TASK_INTERRUPTIBLE);
- add_wait_queue(&FlagSleepRec, &wait);
-
- /* Scan each board, looking for one which has a packet for us */
- for (i=0; i < MAX_BOARD; i++) {
- if (!apbs[i].RamIO)
- continue;
- spin_lock_irqsave(&apbs[i].mutex, flags);
-
- tmp = readb(apbs[i].RamIO + DATA_TO_PC_READY);
-
- if (tmp == 2) {
- struct st_ram_io st_loc;
- struct mailbox mailbox;
-
- /* Got a packet for us */
- memset(&st_loc, 0, sizeof(st_loc));
- ret = do_ac_read(i, buf, &st_loc, &mailbox);
- spin_unlock_irqrestore(&apbs[i].mutex, flags);
- set_current_state(TASK_RUNNING);
- remove_wait_queue(&FlagSleepRec, &wait);
-
- if (copy_to_user(buf, &st_loc, sizeof(st_loc)))
- return -EFAULT;
- if (copy_to_user(buf + sizeof(st_loc), &mailbox, sizeof(mailbox)))
- return -EFAULT;
- return tmp;
- }
-
- if (tmp > 2) {
- /* Got an error */
- Dummy = readb(apbs[i].RamIO + VERS);
-
- spin_unlock_irqrestore(&apbs[i].mutex, flags);
- set_current_state(TASK_RUNNING);
- remove_wait_queue(&FlagSleepRec, &wait);
-
- printk(KERN_WARNING "APPLICOM driver read error board %d, DataToPcReady = %d\n",
- i,(int)readb(apbs[i].RamIO + DATA_TO_PC_READY));
- DeviceErrorCount++;
- return -EIO;
- }
-
- /* Nothing for us. Try the next board */
- Dummy = readb(apbs[i].RamIO + VERS);
- spin_unlock_irqrestore(&apbs[i].mutex, flags);
-
- } /* per board */
-
- /* OK - No boards had data for us. Sleep now */
-
- schedule();
- remove_wait_queue(&FlagSleepRec, &wait);
-
- if (signal_pending(current))
- return -EINTR;
-
-#ifdef DEBUG
- if (loopcount++ > 2) {
- printk(KERN_DEBUG "Looping in ac_read. loopcount %d\n", loopcount);
- }
-#endif
- }
-}
-
-static irqreturn_t ac_interrupt(int vec, void *dev_instance)
-{
- unsigned int i;
- unsigned int FlagInt;
- unsigned int LoopCount;
- int handled = 0;
-
- // printk("Applicom interrupt on IRQ %d occurred\n", vec);
-
- LoopCount = 0;
-
- do {
- FlagInt = 0;
- for (i = 0; i < MAX_BOARD; i++) {
-
- /* Skip if this board doesn't exist */
- if (!apbs[i].RamIO)
- continue;
-
- spin_lock(&apbs[i].mutex);
-
- /* Skip if this board doesn't want attention */
- if(readb(apbs[i].RamIO + RAM_IT_TO_PC) == 0) {
- spin_unlock(&apbs[i].mutex);
- continue;
- }
-
- handled = 1;
- FlagInt = 1;
- writeb(0, apbs[i].RamIO + RAM_IT_TO_PC);
-
- if (readb(apbs[i].RamIO + DATA_TO_PC_READY) > 2) {
- printk(KERN_WARNING "APPLICOM driver interrupt err board %d, DataToPcReady = %d\n",
- i+1,(int)readb(apbs[i].RamIO + DATA_TO_PC_READY));
- DeviceErrorCount++;
- }
-
- if((readb(apbs[i].RamIO + DATA_FROM_PC_READY) > 2) &&
- (readb(apbs[i].RamIO + DATA_FROM_PC_READY) != 6)) {
-
- printk(KERN_WARNING "APPLICOM driver interrupt err board %d, DataFromPcReady = %d\n",
- i+1,(int)readb(apbs[i].RamIO + DATA_FROM_PC_READY));
- DeviceErrorCount++;
- }
-
- if (readb(apbs[i].RamIO + DATA_TO_PC_READY) == 2) { /* mailbox sent by the card ? */
- if (waitqueue_active(&FlagSleepRec)) {
- wake_up_interruptible(&FlagSleepRec);
- }
- }
-
- if (readb(apbs[i].RamIO + DATA_FROM_PC_READY) == 0) { /* ram i/o free for write by pc ? */
- if (waitqueue_active(&apbs[i].FlagSleepSend)) { /* process sleep during read ? */
- wake_up_interruptible(&apbs[i].FlagSleepSend);
- }
- }
- Dummy = readb(apbs[i].RamIO + VERS);
-
- if(readb(apbs[i].RamIO + RAM_IT_TO_PC)) {
- /* There's another int waiting on this card */
- spin_unlock(&apbs[i].mutex);
- i--;
- } else {
- spin_unlock(&apbs[i].mutex);
- }
- }
- if (FlagInt)
- LoopCount = 0;
- else
- LoopCount++;
- } while(LoopCount < 2);
- return IRQ_RETVAL(handled);
-}
-
-
-
-static long ac_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
-
-{ /* @ ADG ou ATO selon le cas */
- int i;
- unsigned char IndexCard;
- void __iomem *pmem;
- int ret = 0;
- static int warncount = 10;
- volatile unsigned char byte_reset_it;
- struct st_ram_io *adgl;
- void __user *argp = (void __user *)arg;
-
- /* In general, the device is only openable by root anyway, so we're not
- particularly concerned that bogus ioctls can flood the console. */
-
- adgl = memdup_user(argp, sizeof(struct st_ram_io));
- if (IS_ERR(adgl))
- return PTR_ERR(adgl);
-
- mutex_lock(&ac_mutex);
- IndexCard = adgl->num_card-1;
-
- if (cmd != 6 && IndexCard >= MAX_BOARD)
- goto err;
- IndexCard = array_index_nospec(IndexCard, MAX_BOARD);
-
- if (cmd != 6 && !apbs[IndexCard].RamIO)
- goto err;
-
- switch (cmd) {
-
- case 0:
- pmem = apbs[IndexCard].RamIO;
- for (i = 0; i < sizeof(struct st_ram_io); i++)
- ((unsigned char *)adgl)[i]=readb(pmem++);
- if (copy_to_user(argp, adgl, sizeof(struct st_ram_io)))
- ret = -EFAULT;
- break;
- case 1:
- pmem = apbs[IndexCard].RamIO + CONF_END_TEST;
- for (i = 0; i < 4; i++)
- adgl->conf_end_test[i] = readb(pmem++);
- for (i = 0; i < 2; i++)
- adgl->error_code[i] = readb(pmem++);
- for (i = 0; i < 4; i++)
- adgl->parameter_error[i] = readb(pmem++);
- pmem = apbs[IndexCard].RamIO + VERS;
- adgl->vers = readb(pmem);
- pmem = apbs[IndexCard].RamIO + TYPE_CARD;
- for (i = 0; i < 20; i++)
- adgl->reserv1[i] = readb(pmem++);
- *(int *)&adgl->reserv1[20] =
- (readb(apbs[IndexCard].RamIO + SERIAL_NUMBER) << 16) +
- (readb(apbs[IndexCard].RamIO + SERIAL_NUMBER + 1) << 8) +
- (readb(apbs[IndexCard].RamIO + SERIAL_NUMBER + 2) );
-
- if (copy_to_user(argp, adgl, sizeof(struct st_ram_io)))
- ret = -EFAULT;
- break;
- case 2:
- pmem = apbs[IndexCard].RamIO + CONF_END_TEST;
- for (i = 0; i < 10; i++)
- writeb(0xff, pmem++);
- writeb(adgl->data_from_pc_ready,
- apbs[IndexCard].RamIO + DATA_FROM_PC_READY);
-
- writeb(1, apbs[IndexCard].RamIO + RAM_IT_FROM_PC);
-
- for (i = 0; i < MAX_BOARD; i++) {
- if (apbs[i].RamIO) {
- byte_reset_it = readb(apbs[i].RamIO + RAM_IT_TO_PC);
- }
- }
- break;
- case 3:
- pmem = apbs[IndexCard].RamIO + TIC_DES_FROM_PC;
- writeb(adgl->tic_des_from_pc, pmem);
- break;
- case 4:
- pmem = apbs[IndexCard].RamIO + TIC_OWNER_TO_PC;
- adgl->tic_owner_to_pc = readb(pmem++);
- adgl->numcard_owner_to_pc = readb(pmem);
- if (copy_to_user(argp, adgl,sizeof(struct st_ram_io)))
- ret = -EFAULT;
- break;
- case 5:
- writeb(adgl->num_card, apbs[IndexCard].RamIO + NUMCARD_OWNER_TO_PC);
- writeb(adgl->num_card, apbs[IndexCard].RamIO + NUMCARD_DES_FROM_PC);
- writeb(adgl->num_card, apbs[IndexCard].RamIO + NUMCARD_ACK_FROM_PC);
- writeb(4, apbs[IndexCard].RamIO + DATA_FROM_PC_READY);
- writeb(1, apbs[IndexCard].RamIO + RAM_IT_FROM_PC);
- break;
- case 6:
- printk(KERN_INFO "APPLICOM driver release .... V2.8.0 ($Revision: 1.30 $)\n");
- printk(KERN_INFO "Number of installed boards . %d\n", (int) numboards);
- printk(KERN_INFO "Segment of board ........... %X\n", (int) mem);
- printk(KERN_INFO "Interrupt IRQ number ....... %d\n", (int) irq);
- for (i = 0; i < MAX_BOARD; i++) {
- int serial;
- char boardname[(SERIAL_NUMBER - TYPE_CARD) + 1];
-
- if (!apbs[i].RamIO)
- continue;
-
- for (serial = 0; serial < SERIAL_NUMBER - TYPE_CARD; serial++)
- boardname[serial] = readb(apbs[i].RamIO + TYPE_CARD + serial);
- boardname[serial] = 0;
-
- printk(KERN_INFO "Prom version board %d ....... V%d.%d %s",
- i+1,
- (int)(readb(apbs[i].RamIO + VERS) >> 4),
- (int)(readb(apbs[i].RamIO + VERS) & 0xF),
- boardname);
-
-
- serial = (readb(apbs[i].RamIO + SERIAL_NUMBER) << 16) +
- (readb(apbs[i].RamIO + SERIAL_NUMBER + 1) << 8) +
- (readb(apbs[i].RamIO + SERIAL_NUMBER + 2) );
-
- if (serial != 0)
- printk(" S/N %d\n", serial);
- else
- printk("\n");
- }
- if (DeviceErrorCount != 0)
- printk(KERN_INFO "DeviceErrorCount ........... %d\n", DeviceErrorCount);
- if (ReadErrorCount != 0)
- printk(KERN_INFO "ReadErrorCount ............. %d\n", ReadErrorCount);
- if (WriteErrorCount != 0)
- printk(KERN_INFO "WriteErrorCount ............ %d\n", WriteErrorCount);
- if (waitqueue_active(&FlagSleepRec))
- printk(KERN_INFO "Process in read pending\n");
- for (i = 0; i < MAX_BOARD; i++) {
- if (apbs[i].RamIO && waitqueue_active(&apbs[i].FlagSleepSend))
- printk(KERN_INFO "Process in write pending board %d\n",i+1);
- }
- break;
- default:
- ret = -ENOTTY;
- break;
- }
-
- if (cmd != 6)
- Dummy = readb(apbs[IndexCard].RamIO + VERS);
-
- kfree(adgl);
- mutex_unlock(&ac_mutex);
- return ret;
-
-err:
- if (warncount) {
- pr_warn("APPLICOM driver IOCTL, bad board number %d\n",
- (int)IndexCard + 1);
- warncount--;
- }
- kfree(adgl);
- mutex_unlock(&ac_mutex);
- return -EINVAL;
-
-}
-
diff --git a/drivers/char/applicom.h b/drivers/char/applicom.h
deleted file mode 100644
index 282e08f159d5..000000000000
--- a/drivers/char/applicom.h
+++ /dev/null
@@ -1,86 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/* $Id: applicom.h,v 1.2 1999/08/28 15:09:49 dwmw2 Exp $ */
-
-
-#ifndef __LINUX_APPLICOM_H__
-#define __LINUX_APPLICOM_H__
-
-
-#define DATA_TO_PC_READY 0x00
-#define TIC_OWNER_TO_PC 0x01
-#define NUMCARD_OWNER_TO_PC 0x02
-#define TIC_DES_TO_PC 0x03
-#define NUMCARD_DES_TO_PC 0x04
-#define DATA_FROM_PC_READY 0x05
-#define TIC_OWNER_FROM_PC 0x06
-#define NUMCARD_OWNER_FROM_PC 0x07
-#define TIC_DES_FROM_PC 0x08
-#define NUMCARD_DES_FROM_PC 0x09
-#define ACK_FROM_PC_READY 0x0E
-#define TIC_ACK_FROM_PC 0x0F
-#define NUMCARD_ACK_FROM_PC 0x010
-#define TYP_ACK_FROM_PC 0x011
-#define CONF_END_TEST 0x012
-#define ERROR_CODE 0x016
-#define PARAMETER_ERROR 0x018
-#define VERS 0x01E
-#define RAM_TO_PC 0x040
-#define RAM_FROM_PC 0x0170
-#define TYPE_CARD 0x03C0
-#define SERIAL_NUMBER 0x03DA
-#define RAM_IT_FROM_PC 0x03FE
-#define RAM_IT_TO_PC 0x03FF
-
-struct mailbox{
- u16 stjb_codef; /* offset 00 */
- s16 stjb_status; /* offset 02 */
- u16 stjb_ticuser_root; /* offset 04 */
- u8 stjb_piduser[4]; /* offset 06 */
- u16 stjb_mode; /* offset 0A */
- u16 stjb_time; /* offset 0C */
- u16 stjb_stop; /* offset 0E */
- u16 stjb_nfonc; /* offset 10 */
- u16 stjb_ncard; /* offset 12 */
- u16 stjb_nchan; /* offset 14 */
- u16 stjb_nes; /* offset 16 */
- u16 stjb_nb; /* offset 18 */
- u16 stjb_typvar; /* offset 1A */
- u32 stjb_adr; /* offset 1C */
- u16 stjb_ticuser_dispcyc; /* offset 20 */
- u16 stjb_ticuser_protocol; /* offset 22 */
- u8 stjb_filler[12]; /* offset 24 */
- u8 stjb_data[256]; /* offset 30 */
- };
-
-struct st_ram_io
-{
- unsigned char data_to_pc_ready;
- unsigned char tic_owner_to_pc;
- unsigned char numcard_owner_to_pc;
- unsigned char tic_des_to_pc;
- unsigned char numcard_des_to_pc;
- unsigned char data_from_pc_ready;
- unsigned char tic_owner_from_pc;
- unsigned char numcard_owner_from_pc;
- unsigned char tic_des_from_pc;
- unsigned char numcard_des_from_pc;
- unsigned char ack_to_pc_ready;
- unsigned char tic_ack_to_pc;
- unsigned char numcard_ack_to_pc;
- unsigned char typ_ack_to_pc;
- unsigned char ack_from_pc_ready;
- unsigned char tic_ack_from_pc;
- unsigned char numcard_ack_from_pc;
- unsigned char typ_ack_from_pc;
- unsigned char conf_end_test[4];
- unsigned char error_code[2];
- unsigned char parameter_error[4];
- unsigned char time_base;
- unsigned char nul_inc;
- unsigned char vers;
- unsigned char num_card;
- unsigned char reserv1[32];
-};
-
-
-#endif /* __LINUX_APPLICOM_H__ */
--
2.43.0
^ permalink raw reply related
* [RFC PATCH] bpf: introduce TAINT_UNSAFE_BPF for mutating helpers
From: Aaron Tomlin @ 2026-05-03 3:52 UTC (permalink / raw)
To: corbet, song, kpsingh, mattbobrowski, ast, daniel, andrii,
eddyz87, memxor, rostedt, mhiramat
Cc: skhan, jolsa, martin.lau, yonghong.song, mathieu.desnoyers,
atomlin, neelx, sean, chjohnst, steve, mproche, nick.lange,
linux-doc, linux-kernel, bpf, linux-trace-kernel
The primary remit of the eBPF verifier is to ensure that eBPF programs
can neither crash the kernel nor corrupt memory. Nevertheless,
administrative utilities such as "bpftrace --unsafe" permit the loading
of programs that employ destructive or mutating helpers, most notably
bpf_probe_write_user() and bpf_override_return().
Since commit b28573ebfabe ("bpf: Remove bpf_probe_write_user() warning
message"), the kernel no longer issues a warning when an attempt is made to
invoke such destructive helpers.
Consequently, this patch introduces a novel kernel taint flag,
TAINT_UNSAFE_BPF ("V"). Tainting the kernel establishes a permanent and
readily auditable indicator (i.e., /proc/sys/kernel/tainted) to alert
maintainers and that the kernel's execution flow or user memory may have
been compromised by an eBPF program.
Signed-off-by: Aaron Tomlin <atomlin@atomlin.com>
---
Documentation/admin-guide/tainted-kernels.rst | 54 ++++++++++---------
include/linux/panic.h | 3 +-
kernel/panic.c | 1 +
kernel/trace/bpf_trace.c | 3 ++
4 files changed, 36 insertions(+), 25 deletions(-)
diff --git a/Documentation/admin-guide/tainted-kernels.rst b/Documentation/admin-guide/tainted-kernels.rst
index 9ead927a37c0..630f24996e7b 100644
--- a/Documentation/admin-guide/tainted-kernels.rst
+++ b/Documentation/admin-guide/tainted-kernels.rst
@@ -79,30 +79,31 @@ which bits are set::
Table for decoding tainted state
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-=== === ====== ========================================================
-Bit Log Number Reason that got the kernel tainted
-=== === ====== ========================================================
- 0 G/P 1 proprietary module was loaded
- 1 _/F 2 module was force loaded
- 2 _/S 4 kernel running on an out of specification system
- 3 _/R 8 module was force unloaded
- 4 _/M 16 processor reported a Machine Check Exception (MCE)
- 5 _/B 32 bad page referenced or some unexpected page flags
- 6 _/U 64 taint requested by userspace application
- 7 _/D 128 kernel died recently, i.e. there was an OOPS or BUG
- 8 _/A 256 ACPI table overridden by user
- 9 _/W 512 kernel issued warning
- 10 _/C 1024 staging driver was loaded
- 11 _/I 2048 workaround for bug in platform firmware applied
- 12 _/O 4096 externally-built ("out-of-tree") module was loaded
- 13 _/E 8192 unsigned module was loaded
- 14 _/L 16384 soft lockup occurred
- 15 _/K 32768 kernel has been live patched
- 16 _/X 65536 auxiliary taint, defined for and used by distros
- 17 _/T 131072 kernel was built with the struct randomization plugin
- 18 _/N 262144 an in-kernel test has been run
- 19 _/J 524288 userspace used a mutating debug operation in fwctl
-=== === ====== ========================================================
+=== === ====== ========================================================
+Bit Log Number Reason that got the kernel tainted
+=== === ====== ========================================================
+ 0 G/P 1 proprietary module was loaded
+ 1 _/F 2 module was force loaded
+ 2 _/S 4 kernel running on an out of specification system
+ 3 _/R 8 module was force unloaded
+ 4 _/M 16 processor reported a Machine Check Exception (MCE)
+ 5 _/B 32 bad page referenced or some unexpected page flags
+ 6 _/U 64 taint requested by userspace application
+ 7 _/D 128 kernel died recently, i.e. there was an OOPS or BUG
+ 8 _/A 256 ACPI table overridden by user
+ 9 _/W 512 kernel issued warning
+ 10 _/C 1024 staging driver was loaded
+ 11 _/I 2048 workaround for bug in platform firmware applied
+ 12 _/O 4096 externally-built ("out-of-tree") module was loaded
+ 13 _/E 8192 unsigned module was loaded
+ 14 _/L 16384 soft lockup occurred
+ 15 _/K 32768 kernel has been live patched
+ 16 _/X 65536 auxiliary taint, defined for and used by distros
+ 17 _/T 131072 kernel was built with the struct randomization plugin
+ 18 _/N 262144 an in-kernel test has been run
+ 19 _/J 524288 userspace used a mutating debug operation in fwctl
+ 20 _/V 1048576 an unsafe eBPF program (mutating helper) was loaded
+=== === ======= ========================================================
Note: The character ``_`` is representing a blank in this table to make reading
easier.
@@ -189,3 +190,8 @@ More detailed explanation for tainting
19) ``J`` if userspace opened /dev/fwctl/* and performed a FWTCL_RPC_DEBUG_WRITE
to use the devices debugging features. Device debugging features could
cause the device to malfunction in undefined ways.
+
+ 20) ``V`` if an eBPF program utilising unsafe, mutating helpers (such as
+ bpf_probe_write_user() or bpf_override_return()) was loaded. These helpers
+ bypass standard eBPF safety guarantees and can alter execution flow or
+ corrupt memory.
diff --git a/include/linux/panic.h b/include/linux/panic.h
index f1dd417e54b2..8622c02c2c24 100644
--- a/include/linux/panic.h
+++ b/include/linux/panic.h
@@ -88,7 +88,8 @@ static inline void set_arch_panic_timeout(int timeout, int arch_default_timeout)
#define TAINT_RANDSTRUCT 17
#define TAINT_TEST 18
#define TAINT_FWCTL 19
-#define TAINT_FLAGS_COUNT 20
+#define TAINT_UNSAFE_BPF 20
+#define TAINT_FLAGS_COUNT 21
#define TAINT_FLAGS_MAX ((1UL << TAINT_FLAGS_COUNT) - 1)
struct taint_flag {
diff --git a/kernel/panic.c b/kernel/panic.c
index 20feada5319d..1ae19bd8fc1d 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -825,6 +825,7 @@ const struct taint_flag taint_flags[TAINT_FLAGS_COUNT] = {
TAINT_FLAG(RANDSTRUCT, 'T', ' '),
TAINT_FLAG(TEST, 'N', ' '),
TAINT_FLAG(FWCTL, 'J', ' '),
+ TAINT_FLAG(UNSAFE_BPF, 'V', ' '),
};
#undef TAINT_FLAG
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index af7079aa0f36..4e7e5bf76dcb 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -155,6 +155,7 @@ unsigned int trace_call_bpf(struct trace_event_call *call, void *ctx)
#ifdef CONFIG_BPF_KPROBE_OVERRIDE
BPF_CALL_2(bpf_override_return, struct pt_regs *, regs, unsigned long, rc)
{
+ add_taint(TAINT_UNSAFE_BPF, LOCKDEP_STILL_OK);
regs_set_return_value(regs, rc);
override_function_with_return(regs);
return 0;
@@ -344,6 +345,8 @@ BPF_CALL_3(bpf_probe_write_user, void __user *, unsafe_ptr, const void *, src,
if (unlikely(!nmi_uaccess_okay()))
return -EPERM;
+ add_taint(TAINT_UNSAFE_BPF, LOCKDEP_STILL_OK);
+
return copy_to_user_nofault(unsafe_ptr, src, size);
}
--
2.51.0
^ permalink raw reply related
* Re: [PATCH net-next 2/5] net: ethernet: oa_tc6: Allow custom mii_bus
From: Andrew Lunn @ 2026-05-03 3:50 UTC (permalink / raw)
To: ciprian.regus
Cc: Parthiban Veerasooran, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Shuah Khan, Heiner Kallweit, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, linux-kernel,
linux-doc, devicetree
In-Reply-To: <20260503-adin1140-driver-v1-2-dd043cdd88f0@analog.com>
> @@ -538,32 +539,37 @@ static int oa_tc6_mdiobus_register(struct oa_tc6 *tc6)
> {
> int ret;
>
> - tc6->mdiobus = mdiobus_alloc();
> if (!tc6->mdiobus) {
> - netdev_err(tc6->netdev, "MDIO bus alloc failed\n");
> - return -ENOMEM;
> + tc6->mdiobus = mdiobus_alloc();
> + if (!tc6->mdiobus) {
> + netdev_err(tc6->netdev, "MDIO bus alloc failed\n");
> + return -ENOMEM;
> + }
> +
> + tc6->mdiobus->read = oa_tc6_mdiobus_read;
> + tc6->mdiobus->write = oa_tc6_mdiobus_write;
> + /* OPEN Alliance 10BASE-T1x compliance MAC-PHYs will have both C22 and
> + * C45 registers space. If the PHY is discovered via C22 bus protocol it
> + * assumes it uses C22 protocol and always uses C22 registers indirect
> + * access to access C45 registers. This is because, we don't have a
> + * clean separation between C22/C45 register space and C22/C45 MDIO bus
> + * protocols. Resulting, PHY C45 registers direct access can't be used
> + * which can save multiple SPI bus access. To support this feature, PHY
> + * drivers can set .read_mmd/.write_mmd in the PHY driver to call
> + * .read_c45/.write_c45. Ex: drivers/net/phy/microchip_t1s.c
> + */
> + tc6->mdiobus->read_c45 = oa_tc6_mdiobus_read_c45;
> + tc6->mdiobus->write_c45 = oa_tc6_mdiobus_write_c45;
> +
> + tc6->own_mdiobus = true;
> }
>
> tc6->mdiobus->priv = tc6;
> - tc6->mdiobus->read = oa_tc6_mdiobus_read;
> - tc6->mdiobus->write = oa_tc6_mdiobus_write;
> - /* OPEN Alliance 10BASE-T1x compliance MAC-PHYs will have both C22 and
> - * C45 registers space. If the PHY is discovered via C22 bus protocol it
> - * assumes it uses C22 protocol and always uses C22 registers indirect
> - * access to access C45 registers. This is because, we don't have a
> - * clean separation between C22/C45 register space and C22/C45 MDIO bus
> - * protocols. Resulting, PHY C45 registers direct access can't be used
> - * which can save multiple SPI bus access. To support this feature, PHY
> - * drivers can set .read_mmd/.write_mmd in the PHY driver to call
> - * .read_c45/.write_c45. Ex: drivers/net/phy/microchip_t1s.c
> - */
> - tc6->mdiobus->read_c45 = oa_tc6_mdiobus_read_c45;
> - tc6->mdiobus->write_c45 = oa_tc6_mdiobus_write_c45;
> - tc6->mdiobus->name = "oa-tc6-mdiobus";
> tc6->mdiobus->parent = tc6->dev;
> + tc6->mdiobus->name = "oa-tc6-mdiobus";
>
> snprintf(tc6->mdiobus->id, ARRAY_SIZE(tc6->mdiobus->id), "%s",
> - dev_name(&tc6->spi->dev));
> + dev_name(&tc6->spi->dev));
>
> ret = mdiobus_register(tc6->mdiobus);
> if (ret) {
> @@ -577,19 +583,30 @@ static int oa_tc6_mdiobus_register(struct oa_tc6 *tc6)
>
> static void oa_tc6_mdiobus_unregister(struct oa_tc6 *tc6)
> {
> + if (!tc6->mdiobus)
> + return;
> +
> mdiobus_unregister(tc6->mdiobus);
> - mdiobus_free(tc6->mdiobus);
> +
> + if (tc6->own_mdiobus)
> + mdiobus_free(tc6->mdiobus);
> }
>
> static int oa_tc6_phy_init(struct oa_tc6 *tc6)
> {
> int ret;
>
> - ret = oa_tc6_check_phy_reg_direct_access_capability(tc6);
> - if (ret) {
> - netdev_err(tc6->netdev,
> - "Direct PHY register access is not supported by the MAC-PHY\n");
> - return ret;
> + /* If the driver provided a mii_bus, it is also responsible for
> + * implementing the bus access methods, so we don't have to worry
> + * about checking the PHY access mode.
> + */
> + if (!tc6->mdiobus) {
> + ret = oa_tc6_check_phy_reg_direct_access_capability(tc6);
> + if (ret) {
> + netdev_err(tc6->netdev,
> + "Direct PHY register access is not supported by the MAC-PHY\n");
> + return ret;
> + }
This all seems pretty invasive and ugly. Please could you think what
happens if instead of passing in an mdiobus, you pass a phydev. Is the
change to the core simpler and cleaner?
Andrew
^ 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