mirror of
https://github.com/linux-msm/laptops-kernel.git
synced 2026-08-13 14:19:53 -07:00
Add Renesas RZ/G3L RSPI support
Biju <biju.das.au@gmail.com> says: This patch series adds binding and driver support for RSPI IP found on the RZ/G3L SoC. The RSPI is compatible with RZ/V2H RSPI, but has 2 clocks compared to 3 on RZ/V2H. Link: https://patch.msgid.link/20260408085418.18770-1-biju.das.jz@bp.renesas.com
This commit is contained in:
Mark Brown
@@ -1,6 +1,7 @@
|
||||
Alan Cox <alan@lxorguk.ukuu.org.uk>
|
||||
Alan Cox <root@hraefn.swansea.linux.org.uk>
|
||||
Alyssa Rosenzweig <alyssa@rosenzweig.io>
|
||||
Askar Safin <safinaskar@gmail.com>
|
||||
Christoph Hellwig <hch@lst.de>
|
||||
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
||||
Marc Gonzalez <marc.w.gonzalez@free.fr>
|
||||
|
||||
@@ -316,6 +316,7 @@ Hans Verkuil <hverkuil@kernel.org> <hverkuil-cisco@xs4all.nl>
|
||||
Hans Verkuil <hverkuil@kernel.org> <hansverk@cisco.com>
|
||||
Hao Ge <hao.ge@linux.dev> <gehao@kylinos.cn>
|
||||
Harry Yoo <harry.yoo@oracle.com> <42.hyeyoo@gmail.com>
|
||||
Harry Yoo <harry@kernel.org> <harry.yoo@oracle.com>
|
||||
Heiko Carstens <hca@linux.ibm.com> <h.carstens@de.ibm.com>
|
||||
Heiko Carstens <hca@linux.ibm.com> <heiko.carstens@de.ibm.com>
|
||||
Heiko Stuebner <heiko@sntech.de> <heiko.stuebner@bqreaders.com>
|
||||
@@ -587,6 +588,7 @@ Morten Welinder <terra@gnome.org>
|
||||
Morten Welinder <welinder@anemone.rentec.com>
|
||||
Morten Welinder <welinder@darter.rentec.com>
|
||||
Morten Welinder <welinder@troll.com>
|
||||
Muhammad Usama Anjum <usama.anjum@arm.com> <usama.anjum@collabora.com>
|
||||
Mukesh Ojha <quic_mojha@quicinc.com> <mojha@codeaurora.org>
|
||||
Muna Sinada <quic_msinada@quicinc.com> <msinada@codeaurora.org>
|
||||
Murali Nalajala <quic_mnalajal@quicinc.com> <mnalajal@codeaurora.org>
|
||||
|
||||
@@ -85,6 +85,16 @@ In the example, 'Requester ID' means the ID of the device that sent
|
||||
the error message to the Root Port. Please refer to PCIe specs for other
|
||||
fields.
|
||||
|
||||
The 'TLP Header' is the prefix/header of the TLP that caused the error
|
||||
in raw hex format. To decode the TLP Header into human-readable form
|
||||
one may use tlp-tool:
|
||||
|
||||
https://github.com/mmpg-x86/tlp-tool
|
||||
|
||||
Example usage::
|
||||
|
||||
curl -L https://git.kernel.org/linus/2ca1c94ce0b6 | rtlp-tool --aer
|
||||
|
||||
AER Ratelimits
|
||||
--------------
|
||||
|
||||
|
||||
@@ -149,11 +149,33 @@ For architectures that require cache flushing for DMA coherence
|
||||
DMA_ATTR_MMIO will not perform any cache flushing. The address
|
||||
provided must never be mapped cacheable into the CPU.
|
||||
|
||||
DMA_ATTR_CPU_CACHE_CLEAN
|
||||
------------------------
|
||||
DMA_ATTR_DEBUGGING_IGNORE_CACHELINES
|
||||
------------------------------------
|
||||
|
||||
This attribute indicates the CPU will not dirty any cacheline overlapping this
|
||||
DMA_FROM_DEVICE/DMA_BIDIRECTIONAL buffer while it is mapped. This allows
|
||||
multiple small buffers to safely share a cacheline without risk of data
|
||||
corruption, suppressing DMA debug warnings about overlapping mappings.
|
||||
All mappings sharing a cacheline should have this attribute.
|
||||
This attribute indicates that CPU cache lines may overlap for buffers mapped
|
||||
with DMA_FROM_DEVICE or DMA_BIDIRECTIONAL.
|
||||
|
||||
Such overlap may occur when callers map multiple small buffers that reside
|
||||
within the same cache line. In this case, callers must guarantee that the CPU
|
||||
will not dirty these cache lines after the mappings are established. When this
|
||||
condition is met, multiple buffers can safely share a cache line without risking
|
||||
data corruption.
|
||||
|
||||
All mappings that share a cache line must set this attribute to suppress DMA
|
||||
debug warnings about overlapping mappings.
|
||||
|
||||
DMA_ATTR_REQUIRE_COHERENT
|
||||
-------------------------
|
||||
|
||||
DMA mapping requests with the DMA_ATTR_REQUIRE_COHERENT fail on any
|
||||
system where SWIOTLB or cache management is required. This should only
|
||||
be used to support uAPI designs that require continuous HW DMA
|
||||
coherence with userspace processes, for example RDMA and DRM. At a
|
||||
minimum the memory being mapped must be userspace memory from
|
||||
pin_user_pages() or similar.
|
||||
|
||||
Drivers should consider using dma_mmap_pages() instead of this
|
||||
interface when building their uAPIs, when possible.
|
||||
|
||||
It must never be used in an in-kernel driver that only works with
|
||||
kernel memory.
|
||||
|
||||
@@ -66,7 +66,7 @@ then:
|
||||
required:
|
||||
- refresh-rate-hz
|
||||
|
||||
additionalProperties: false
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
|
||||
@@ -301,6 +301,7 @@ properties:
|
||||
maxItems: 4
|
||||
|
||||
dependencies:
|
||||
pd-disable: [typec-power-opmode]
|
||||
sink-vdos-v1: [ sink-vdos ]
|
||||
sink-vdos: [ sink-vdos-v1 ]
|
||||
|
||||
|
||||
@@ -37,7 +37,7 @@ properties:
|
||||
const: 2
|
||||
|
||||
"#interrupt-cells":
|
||||
const: 1
|
||||
const: 2
|
||||
|
||||
ngpios:
|
||||
description:
|
||||
@@ -86,7 +86,7 @@ examples:
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
#interrupt-cells = <2>;
|
||||
interrupts = <53>, <53>, <53>, <53>,
|
||||
<53>, <53>, <53>, <53>,
|
||||
<53>, <53>, <53>, <53>,
|
||||
|
||||
@@ -33,6 +33,7 @@ properties:
|
||||
- const: rockchip,rk3066-spdif
|
||||
- items:
|
||||
- enum:
|
||||
- rockchip,rk3576-spdif
|
||||
- rockchip,rk3588-spdif
|
||||
- const: rockchip,rk3568-spdif
|
||||
|
||||
|
||||
@@ -164,7 +164,7 @@ allOf:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: st,stm32mph7-sai
|
||||
const: st,stm32h7-sai
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
|
||||
@@ -13,6 +13,7 @@ properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- enum:
|
||||
- renesas,r9a08g046-rspi # RZ/G3L
|
||||
- renesas,r9a09g057-rspi # RZ/V2H(P)
|
||||
- renesas,r9a09g077-rspi # RZ/T2H
|
||||
- items:
|
||||
@@ -90,6 +91,34 @@ required:
|
||||
|
||||
allOf:
|
||||
- $ref: spi-controller.yaml#
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- renesas,r9a08g046-rspi
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
maxItems: 2
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: pclk
|
||||
- const: tclk
|
||||
|
||||
dmas:
|
||||
maxItems: 2
|
||||
|
||||
dma-names:
|
||||
items:
|
||||
- const: rx
|
||||
- const: tx
|
||||
|
||||
required:
|
||||
- resets
|
||||
- reset-names
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
|
||||
@@ -783,6 +783,56 @@ controlled by the "uuid" mount option, which supports these values:
|
||||
mounted with "uuid=on".
|
||||
|
||||
|
||||
Durability and copy up
|
||||
----------------------
|
||||
|
||||
The fsync(2) system call ensures that the data and metadata of a file
|
||||
are safely written to the backing storage, which is expected to
|
||||
guarantee the existence of the information post system crash.
|
||||
|
||||
Without an fsync(2) call, there is no guarantee that the observed
|
||||
data after a system crash will be either the old or the new data, but
|
||||
in practice, the observed data after crash is often the old or new data
|
||||
or a mix of both.
|
||||
|
||||
When an overlayfs file is modified for the first time, copy up will
|
||||
create a copy of the lower file and its parent directories in the upper
|
||||
layer. Since the Linux filesystem API does not enforce any particular
|
||||
ordering on storing changes without explicit fsync(2) calls, in case
|
||||
of a system crash, the upper file could end up with no data at all
|
||||
(i.e. zeros), which would be an unusual outcome. To avoid this
|
||||
experience, overlayfs calls fsync(2) on the upper file before completing
|
||||
data copy up with rename(2) or link(2) to make the copy up "atomic".
|
||||
|
||||
By default, overlayfs does not explicitly call fsync(2) on copied up
|
||||
directories or on metadata-only copy up, so it provides no guarantee to
|
||||
persist the user's modification unless the user calls fsync(2).
|
||||
The fsync during copy up only guarantees that if a copy up is observed
|
||||
after a crash, the observed data is not zeroes or intermediate values
|
||||
from the copy up staging area.
|
||||
|
||||
On traditional local filesystems with a single journal (e.g. ext4, xfs),
|
||||
fsync on a file also persists the parent directory changes, because they
|
||||
are usually modified in the same transaction, so metadata durability during
|
||||
data copy up effectively comes for free. Overlayfs further limits risk by
|
||||
disallowing network filesystems as upper layer.
|
||||
|
||||
Overlayfs can be tuned to prefer performance or durability when storing
|
||||
to the underlying upper layer. This is controlled by the "fsync" mount
|
||||
option, which supports these values:
|
||||
|
||||
- "auto": (default)
|
||||
Call fsync(2) on upper file before completion of data copy up.
|
||||
No explicit fsync(2) on directory or metadata-only copy up.
|
||||
- "strict":
|
||||
Call fsync(2) on upper file and directories before completion of any
|
||||
copy up.
|
||||
- "volatile": [*]
|
||||
Prefer performance over durability (see `Volatile mount`_)
|
||||
|
||||
[*] The mount option "volatile" is an alias to "fsync=volatile".
|
||||
|
||||
|
||||
Volatile mount
|
||||
--------------
|
||||
|
||||
|
||||
@@ -27,10 +27,10 @@ for details.
|
||||
Sysfs entries
|
||||
-------------
|
||||
|
||||
The following attributes are supported. Current maxim attribute
|
||||
The following attributes are supported. Current maximum attribute
|
||||
is read-write, all other attributes are read-only.
|
||||
|
||||
in0_input Measured voltage in microvolts.
|
||||
in0_input Measured voltage in millivolts.
|
||||
|
||||
curr1_input Measured current in microamperes.
|
||||
curr1_max_alarm Overcurrent alarm in microamperes.
|
||||
curr1_input Measured current in milliamperes.
|
||||
curr1_max Overcurrent shutdown threshold in milliamperes.
|
||||
|
||||
@@ -51,8 +51,9 @@ temp1_max Provides thermal control temperature of the CPU package
|
||||
temp1_crit Provides shutdown temperature of the CPU package which
|
||||
is also known as the maximum processor junction
|
||||
temperature, Tjmax or Tprochot.
|
||||
temp1_crit_hyst Provides the hysteresis value from Tcontrol to Tjmax of
|
||||
the CPU package.
|
||||
temp1_crit_hyst Provides the hysteresis temperature of the CPU
|
||||
package. Returns Tcontrol, the temperature at which
|
||||
the critical condition clears.
|
||||
|
||||
temp2_label "DTS"
|
||||
temp2_input Provides current temperature of the CPU package scaled
|
||||
@@ -62,8 +63,9 @@ temp2_max Provides thermal control temperature of the CPU package
|
||||
temp2_crit Provides shutdown temperature of the CPU package which
|
||||
is also known as the maximum processor junction
|
||||
temperature, Tjmax or Tprochot.
|
||||
temp2_crit_hyst Provides the hysteresis value from Tcontrol to Tjmax of
|
||||
the CPU package.
|
||||
temp2_crit_hyst Provides the hysteresis temperature of the CPU
|
||||
package. Returns Tcontrol, the temperature at which
|
||||
the critical condition clears.
|
||||
|
||||
temp3_label "Tcontrol"
|
||||
temp3_input Provides current Tcontrol temperature of the CPU
|
||||
|
||||
@@ -5,8 +5,138 @@ Security bugs
|
||||
|
||||
Linux kernel developers take security very seriously. As such, we'd
|
||||
like to know when a security bug is found so that it can be fixed and
|
||||
disclosed as quickly as possible. Please report security bugs to the
|
||||
Linux kernel security team.
|
||||
disclosed as quickly as possible.
|
||||
|
||||
Preparing your report
|
||||
---------------------
|
||||
|
||||
Like with any bug report, a security bug report requires a lot of analysis work
|
||||
from the developers, so the more information you can share about the issue, the
|
||||
better. Please review the procedure outlined in
|
||||
Documentation/admin-guide/reporting-issues.rst if you are unclear about what
|
||||
information is helpful. The following information are absolutely necessary in
|
||||
**any** security bug report:
|
||||
|
||||
* **affected kernel version range**: with no version indication, your report
|
||||
will not be processed. A significant part of reports are for bugs that
|
||||
have already been fixed, so it is extremely important that vulnerabilities
|
||||
are verified on recent versions (development tree or latest stable
|
||||
version), at least by verifying that the code has not changed since the
|
||||
version where it was detected.
|
||||
|
||||
* **description of the problem**: a detailed description of the problem, with
|
||||
traces showing its manifestation, and why you consider that the observed
|
||||
behavior as a problem in the kernel, is necessary.
|
||||
|
||||
* **reproducer**: developers will need to be able to reproduce the problem to
|
||||
consider a fix as effective. This includes both a way to trigger the issue
|
||||
and a way to confirm it happens. A reproducer with low complexity
|
||||
dependencies will be needed (source code, shell script, sequence of
|
||||
instructions, file-system image etc). Binary-only executables are not
|
||||
accepted. Working exploits are extremely helpful and will not be released
|
||||
without consent from the reporter, unless they are already public. By
|
||||
definition if an issue cannot be reproduced, it is not exploitable, thus it
|
||||
is not a security bug.
|
||||
|
||||
* **conditions**: if the bug depends on certain configuration options,
|
||||
sysctls, permissions, timing, code modifications etc, these should be
|
||||
indicated.
|
||||
|
||||
In addition, the following information are highly desirable:
|
||||
|
||||
* **suspected location of the bug**: the file names and functions where the
|
||||
bug is suspected to be present are very important, at least to help forward
|
||||
the report to the appropriate maintainers. When not possible (for example,
|
||||
"system freezes each time I run this command"), the security team will help
|
||||
identify the source of the bug.
|
||||
|
||||
* **a proposed fix**: bug reporters who have analyzed the cause of a bug in
|
||||
the source code almost always have an accurate idea on how to fix it,
|
||||
because they spent a long time studying it and its implications. Proposing
|
||||
a tested fix will save maintainers a lot of time, even if the fix ends up
|
||||
not being the right one, because it helps understand the bug. When
|
||||
proposing a tested fix, please always format it in a way that can be
|
||||
immediately merged (see Documentation/process/submitting-patches.rst).
|
||||
This will save some back-and-forth exchanges if it is accepted, and you
|
||||
will be credited for finding and fixing this issue. Note that in this case
|
||||
only a ``Signed-off-by:`` tag is needed, without ``Reported-by:`` when the
|
||||
reporter and author are the same.
|
||||
|
||||
* **mitigations**: very often during a bug analysis, some ways of mitigating
|
||||
the issue appear. It is useful to share them, as they can be helpful to
|
||||
keep end users protected during the time it takes them to apply the fix.
|
||||
|
||||
Identifying contacts
|
||||
--------------------
|
||||
|
||||
The most effective way to report a security bug is to send it directly to the
|
||||
affected subsystem's maintainers and Cc: the Linux kernel security team. Do
|
||||
not send it to a public list at this stage, unless you have good reasons to
|
||||
consider the issue as being public or trivial to discover (e.g. result of a
|
||||
widely available automated vulnerability scanning tool that can be repeated by
|
||||
anyone).
|
||||
|
||||
If you're sending a report for issues affecting multiple parts in the kernel,
|
||||
even if they're fairly similar issues, please send individual messages (think
|
||||
that maintainers will not all work on the issues at the same time). The only
|
||||
exception is when an issue concerns closely related parts maintained by the
|
||||
exact same subset of maintainers, and these parts are expected to be fixed all
|
||||
at once by the same commit, then it may be acceptable to report them at once.
|
||||
|
||||
One difficulty for most first-time reporters is to figure the right list of
|
||||
recipients to send a report to. In the Linux kernel, all official maintainers
|
||||
are trusted, so the consequences of accidentally including the wrong maintainer
|
||||
are essentially a bit more noise for that person, i.e. nothing dramatic. As
|
||||
such, a suitable method to figure the list of maintainers (which kernel
|
||||
security officers use) is to rely on the get_maintainer.pl script, tuned to
|
||||
only report maintainers. This script, when passed a file name, will look for
|
||||
its path in the MAINTAINERS file to figure a hierarchical list of relevant
|
||||
maintainers. Calling it a first time with the finest level of filtering will
|
||||
most of the time return a short list of this specific file's maintainers::
|
||||
|
||||
$ ./scripts/get_maintainer.pl --no-l --no-r --pattern-depth 1 \
|
||||
drivers/example.c
|
||||
Developer One <dev1@example.com> (maintainer:example driver)
|
||||
Developer Two <dev2@example.org> (maintainer:example driver)
|
||||
|
||||
These two maintainers should then receive the message. If the command does not
|
||||
return anything, it means the affected file is part of a wider subsystem, so we
|
||||
should be less specific::
|
||||
|
||||
$ ./scripts/get_maintainer.pl --no-l --no-r drivers/example.c
|
||||
Developer One <dev1@example.com> (maintainer:example subsystem)
|
||||
Developer Two <dev2@example.org> (maintainer:example subsystem)
|
||||
Developer Three <dev3@example.com> (maintainer:example subsystem [GENERAL])
|
||||
Developer Four <dev4@example.org> (maintainer:example subsystem [GENERAL])
|
||||
|
||||
Here, picking the first, most specific ones, is sufficient. When the list is
|
||||
long, it is possible to produce a comma-delimited e-mail address list on a
|
||||
single line suitable for use in the To: field of a mailer like this::
|
||||
|
||||
$ ./scripts/get_maintainer.pl --no-tree --no-l --no-r --no-n --m \
|
||||
--no-git-fallback --no-substatus --no-rolestats --no-multiline \
|
||||
--pattern-depth 1 drivers/example.c
|
||||
dev1@example.com, dev2@example.org
|
||||
|
||||
or this for the wider list::
|
||||
|
||||
$ ./scripts/get_maintainer.pl --no-tree --no-l --no-r --no-n --m \
|
||||
--no-git-fallback --no-substatus --no-rolestats --no-multiline \
|
||||
drivers/example.c
|
||||
dev1@example.com, dev2@example.org, dev3@example.com, dev4@example.org
|
||||
|
||||
If at this point you're still facing difficulties spotting the right
|
||||
maintainers, **and only in this case**, it's possible to send your report to
|
||||
the Linux kernel security team only. Your message will be triaged, and you
|
||||
will receive instructions about whom to contact, if needed. Your message may
|
||||
equally be forwarded as-is to the relevant maintainers.
|
||||
|
||||
Sending the report
|
||||
------------------
|
||||
|
||||
Reports are to be sent over e-mail exclusively. Please use a working e-mail
|
||||
address, preferably the same that you want to appear in ``Reported-by`` tags
|
||||
if any. If unsure, send your report to yourself first.
|
||||
|
||||
The security team and maintainers almost always require additional
|
||||
information beyond what was initially provided in a report and rely on
|
||||
@@ -18,20 +148,12 @@ run additional tests. Reports where the reporter does not respond promptly
|
||||
or cannot effectively discuss their findings may be abandoned if the
|
||||
communication does not quickly improve.
|
||||
|
||||
As it is with any bug, the more information provided the easier it
|
||||
will be to diagnose and fix. Please review the procedure outlined in
|
||||
'Documentation/admin-guide/reporting-issues.rst' if you are unclear about what
|
||||
information is helpful. Any exploit code is very helpful and will not
|
||||
be released without consent from the reporter unless it has already been
|
||||
made public.
|
||||
|
||||
The report must be sent to maintainers, with the security team in ``Cc:``.
|
||||
The Linux kernel security team can be contacted by email at
|
||||
<security@kernel.org>. This is a private list of security officers
|
||||
who will help verify the bug report and develop and release a fix.
|
||||
If you already have a fix, please include it with your report, as
|
||||
that can speed up the process considerably. It is possible that the
|
||||
security team will bring in extra help from area maintainers to
|
||||
understand and fix the security vulnerability.
|
||||
who will help verify the bug report and assist developers working on a fix.
|
||||
It is possible that the security team will bring in extra help from area
|
||||
maintainers to understand and fix the security vulnerability.
|
||||
|
||||
Please send **plain text** emails without attachments where possible.
|
||||
It is much harder to have a context-quoted discussion about a complex
|
||||
@@ -42,7 +164,9 @@ reproduction steps, and follow it with a proposed fix, all in plain text.
|
||||
Markdown, HTML and RST formatted reports are particularly frowned upon since
|
||||
they're quite hard to read for humans and encourage to use dedicated viewers,
|
||||
sometimes online, which by definition is not acceptable for a confidential
|
||||
security report.
|
||||
security report. Note that some mailers tend to mangle formatting of plain
|
||||
text by default, please consult Documentation/process/email-clients.rst for
|
||||
more info.
|
||||
|
||||
Disclosure and embargoed information
|
||||
------------------------------------
|
||||
|
||||
@@ -8,7 +8,7 @@ Landlock: unprivileged access control
|
||||
=====================================
|
||||
|
||||
:Author: Mickaël Salaün
|
||||
:Date: January 2026
|
||||
:Date: March 2026
|
||||
|
||||
The goal of Landlock is to enable restriction of ambient rights (e.g. global
|
||||
filesystem or network access) for a set of processes. Because Landlock
|
||||
@@ -197,12 +197,27 @@ similar backwards compatibility check is needed for the restrict flags
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
__u32 restrict_flags = LANDLOCK_RESTRICT_SELF_LOG_NEW_EXEC_ON;
|
||||
if (abi < 7) {
|
||||
/* Clear logging flags unsupported before ABI 7. */
|
||||
__u32 restrict_flags =
|
||||
LANDLOCK_RESTRICT_SELF_LOG_NEW_EXEC_ON |
|
||||
LANDLOCK_RESTRICT_SELF_TSYNC;
|
||||
switch (abi) {
|
||||
case 1 ... 6:
|
||||
/* Removes logging flags for ABI < 7 */
|
||||
restrict_flags &= ~(LANDLOCK_RESTRICT_SELF_LOG_SAME_EXEC_OFF |
|
||||
LANDLOCK_RESTRICT_SELF_LOG_NEW_EXEC_ON |
|
||||
LANDLOCK_RESTRICT_SELF_LOG_SUBDOMAINS_OFF);
|
||||
__attribute__((fallthrough));
|
||||
case 7:
|
||||
/*
|
||||
* Removes multithreaded enforcement flag for ABI < 8
|
||||
*
|
||||
* WARNING: Without this flag, calling landlock_restrict_self(2) is
|
||||
* only equivalent if the calling process is single-threaded. Below
|
||||
* ABI v8 (and as of ABI v8, when not using this flag), a Landlock
|
||||
* policy would only be enforced for the calling thread and its
|
||||
* children (and not for all threads, including parents and siblings).
|
||||
*/
|
||||
restrict_flags &= ~LANDLOCK_RESTRICT_SELF_TSYNC;
|
||||
}
|
||||
|
||||
The next step is to restrict the current thread from gaining more privileges
|
||||
|
||||
+16
-7
@@ -3986,7 +3986,7 @@ F: drivers/hwmon/asus-ec-sensors.c
|
||||
ASUS NOTEBOOKS AND EEEPC ACPI/WMI EXTRAS DRIVERS
|
||||
M: Corentin Chary <corentin.chary@gmail.com>
|
||||
M: Luke D. Jones <luke@ljones.dev>
|
||||
M: Denis Benato <benato.denis96@gmail.com>
|
||||
M: Denis Benato <denis.benato@linux.dev>
|
||||
L: platform-driver-x86@vger.kernel.org
|
||||
S: Maintained
|
||||
W: https://asus-linux.org/
|
||||
@@ -8628,8 +8628,14 @@ F: drivers/gpu/drm/lima/
|
||||
F: include/uapi/drm/lima_drm.h
|
||||
|
||||
DRM DRIVERS FOR LOONGSON
|
||||
M: Jianmin Lv <lvjianmin@loongson.cn>
|
||||
M: Qianhai Wu <wuqianhai@loongson.cn>
|
||||
R: Huacai Chen <chenhuacai@kernel.org>
|
||||
R: Mingcong Bai <jeffbai@aosc.io>
|
||||
R: Xi Ruoyao <xry111@xry111.site>
|
||||
R: Icenowy Zheng <zhengxingda@iscas.ac.cn>
|
||||
L: dri-devel@lists.freedesktop.org
|
||||
S: Orphan
|
||||
S: Maintained
|
||||
T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
|
||||
F: drivers/gpu/drm/loongson/
|
||||
|
||||
@@ -9613,7 +9619,12 @@ F: include/linux/ext2*
|
||||
|
||||
EXT4 FILE SYSTEM
|
||||
M: "Theodore Ts'o" <tytso@mit.edu>
|
||||
M: Andreas Dilger <adilger.kernel@dilger.ca>
|
||||
R: Andreas Dilger <adilger.kernel@dilger.ca>
|
||||
R: Baokun Li <libaokun@linux.alibaba.com>
|
||||
R: Jan Kara <jack@suse.cz>
|
||||
R: Ojaswin Mujoo <ojaswin@linux.ibm.com>
|
||||
R: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
|
||||
R: Zhang Yi <yi.zhang@huawei.com>
|
||||
L: linux-ext4@vger.kernel.org
|
||||
S: Maintained
|
||||
W: http://ext4.wiki.kernel.org
|
||||
@@ -12009,7 +12020,6 @@ I2C SUBSYSTEM
|
||||
M: Wolfram Sang <wsa+renesas@sang-engineering.com>
|
||||
L: linux-i2c@vger.kernel.org
|
||||
S: Maintained
|
||||
W: https://i2c.wiki.kernel.org/
|
||||
Q: https://patchwork.ozlabs.org/project/linux-i2c/list/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git
|
||||
F: Documentation/i2c/
|
||||
@@ -12035,7 +12045,6 @@ I2C SUBSYSTEM HOST DRIVERS
|
||||
M: Andi Shyti <andi.shyti@kernel.org>
|
||||
L: linux-i2c@vger.kernel.org
|
||||
S: Maintained
|
||||
W: https://i2c.wiki.kernel.org/
|
||||
Q: https://patchwork.ozlabs.org/project/linux-i2c/list/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux.git
|
||||
F: Documentation/devicetree/bindings/i2c/
|
||||
@@ -16877,7 +16886,7 @@ M: Lorenzo Stoakes <ljs@kernel.org>
|
||||
R: Rik van Riel <riel@surriel.com>
|
||||
R: Liam R. Howlett <Liam.Howlett@oracle.com>
|
||||
R: Vlastimil Babka <vbabka@kernel.org>
|
||||
R: Harry Yoo <harry.yoo@oracle.com>
|
||||
R: Harry Yoo <harry@kernel.org>
|
||||
R: Jann Horn <jannh@google.com>
|
||||
L: linux-mm@kvack.org
|
||||
S: Maintained
|
||||
@@ -24343,7 +24352,7 @@ F: drivers/nvmem/layouts/sl28vpd.c
|
||||
|
||||
SLAB ALLOCATOR
|
||||
M: Vlastimil Babka <vbabka@kernel.org>
|
||||
M: Harry Yoo <harry.yoo@oracle.com>
|
||||
M: Harry Yoo <harry@kernel.org>
|
||||
M: Andrew Morton <akpm@linux-foundation.org>
|
||||
R: Hao Li <hao.li@linux.dev>
|
||||
R: Christoph Lameter <cl@gentwo.org>
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
VERSION = 7
|
||||
PATCHLEVEL = 0
|
||||
SUBLEVEL = 0
|
||||
EXTRAVERSION = -rc5
|
||||
EXTRAVERSION = -rc7
|
||||
NAME = Baby Opossum Posse
|
||||
|
||||
# *DOCUMENTATION*
|
||||
@@ -1654,7 +1654,7 @@ CLEAN_FILES += vmlinux.symvers modules-only.symvers \
|
||||
modules.builtin.ranges vmlinux.o.map vmlinux.unstripped \
|
||||
compile_commands.json rust/test \
|
||||
rust-project.json .vmlinux.objs .vmlinux.export.c \
|
||||
.builtin-dtbs-list .builtin-dtb.S
|
||||
.builtin-dtbs-list .builtin-dtbs.S
|
||||
|
||||
# Directories & files removed with 'make mrproper'
|
||||
MRPROPER_FILES += include/config include/generated \
|
||||
|
||||
@@ -252,6 +252,7 @@ config ARM64
|
||||
select HAVE_RSEQ
|
||||
select HAVE_RUST if RUSTC_SUPPORTS_ARM64
|
||||
select HAVE_STACKPROTECTOR
|
||||
select HAVE_STATIC_CALL if CFI
|
||||
select HAVE_SYSCALL_TRACEPOINTS
|
||||
select HAVE_KPROBES
|
||||
select HAVE_KRETPROBES
|
||||
|
||||
@@ -0,0 +1,31 @@
|
||||
/* SPDX-License-Identifier: GPL-2.0 */
|
||||
#ifndef _ASM_STATIC_CALL_H
|
||||
#define _ASM_STATIC_CALL_H
|
||||
|
||||
#define __ARCH_DEFINE_STATIC_CALL_TRAMP(name, target) \
|
||||
asm(" .pushsection .static_call.text, \"ax\" \n" \
|
||||
" .align 4 \n" \
|
||||
" .globl " name " \n" \
|
||||
name ": \n" \
|
||||
" hint 34 /* BTI C */ \n" \
|
||||
" adrp x16, 1f \n" \
|
||||
" ldr x16, [x16, :lo12:1f] \n" \
|
||||
" br x16 \n" \
|
||||
" .type " name ", %function \n" \
|
||||
" .size " name ", . - " name " \n" \
|
||||
" .popsection \n" \
|
||||
" .pushsection .rodata, \"a\" \n" \
|
||||
" .align 3 \n" \
|
||||
"1: .quad " target " \n" \
|
||||
" .popsection \n")
|
||||
|
||||
#define ARCH_DEFINE_STATIC_CALL_TRAMP(name, func) \
|
||||
__ARCH_DEFINE_STATIC_CALL_TRAMP(STATIC_CALL_TRAMP_STR(name), #func)
|
||||
|
||||
#define ARCH_DEFINE_STATIC_CALL_NULL_TRAMP(name) \
|
||||
ARCH_DEFINE_STATIC_CALL_TRAMP(name, __static_call_return0)
|
||||
|
||||
#define ARCH_DEFINE_STATIC_CALL_RET0_TRAMP(name) \
|
||||
ARCH_DEFINE_STATIC_CALL_TRAMP(name, __static_call_return0)
|
||||
|
||||
#endif /* _ASM_STATIC_CALL_H */
|
||||
@@ -46,6 +46,7 @@ obj-$(CONFIG_MODULES) += module.o module-plts.o
|
||||
obj-$(CONFIG_PERF_EVENTS) += perf_regs.o perf_callchain.o
|
||||
obj-$(CONFIG_HARDLOCKUP_DETECTOR_PERF) += watchdog_hld.o
|
||||
obj-$(CONFIG_HAVE_HW_BREAKPOINT) += hw_breakpoint.o
|
||||
obj-$(CONFIG_HAVE_STATIC_CALL) += static_call.o
|
||||
obj-$(CONFIG_CPU_PM) += sleep.o suspend.o
|
||||
obj-$(CONFIG_KGDB) += kgdb.o
|
||||
obj-$(CONFIG_EFI) += efi.o efi-rt-wrapper.o
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user