Rearrange initial setup of AMD IOMMU debugfs to segregate per IOMMU
setup and setup which is common for all IOMMUs. This ensures that common
debugfs paths (introduced in subsequent patches) are created only once
instead of being created for each IOMMU.
With the change, there is no need to use lock as amd_iommu_debugfs_setup()
will be called only once during AMD IOMMU initialization. So remove lock
acquisition in amd_iommu_debugfs_setup().
arm64: dts: rockchip: Add reset button to NanoPi R5S
The NanoPi R5S LTS version has a reset button, which is connected via
GPIO. Note that the non-LTS version does not have the reset button and
therefore on page 19 of the schematic version 2204 it is marked 'NC',
but it is connected on the LTS version.
arm64: dts: rockchip: Add rtc0 alias for NanoPi R5S + R5C
The RTC_HCTOSYS_DEVICE module defaults to rtc0 and should (highly)
preferable be assigned to a battery backed RTC module as it is used to
(re)initialize the system clock.
The R5S and R5C have a connector for a RTC battery which is used by
HYM8563 RTC. Both devices also have another RTC from the rk809 PMIC.
To make sure the HYM8563 is always assigned rtc0, add an alias for it.
This series improves a couple of aspects of MCTP bind() handling.
MCTP wasn't checking whether the same MCTP type was bound by multiple
sockets. That would result in messages being received by an arbitrary
socket, which isn't useful behaviour. Instead it makes more sense to
have the duplicate binds fail, the same as other network protocols.
An exception is made for more-specific binds to particular MCTP
addresses.
It is also useful to be able to limit a bind to only receive incoming
request messages (MCTP TO bit set) from a specific peer+type, so that
individual processes can communicate with separate MCTP peers. One
example is a PLDM firmware update requester, which will initiate
communication with a device, and then the device will connect back to the
requester process.
These limited binds are implemented by a connect() call on the socket
prior to bind. connect() isn't used in the general case for MCTP, since
a plain send() wouldn't provide the required MCTP tag argument for
addressing.
Signed-off-by: Matt Johnston <matt@codeconstruct.com.au>
====================
Matt Johnston [Thu, 10 Jul 2025 08:55:59 +0000 (16:55 +0800)]
net: mctp: Allow limiting binds to a peer address
Prior to calling bind() a program may call connect() on a socket to
restrict to a remote peer address.
Using connect() is the normal mechanism to specify a remote network
peer, so we use that here. In MCTP connect() is only used for bound
sockets - send() is not available for MCTP since a tag must be provided
for each message.
The smctp_type must match between connect() and bind() calls.
Matt Johnston [Thu, 10 Jul 2025 08:55:56 +0000 (16:55 +0800)]
net: mctp: Treat MCTP_NET_ANY specially in bind()
When a specific EID is passed as a bind address, it only makes sense to
interpret with an actual network ID, so resolve that to the default
network at bind time.
For bind address of MCTP_ADDR_ANY, we want to be able to capture traffic
to any network and address, so keep the current behaviour of matching
traffic from any network interface (don't interpret MCTP_NET_ANY as
the default network ID).
Matt Johnston [Thu, 10 Jul 2025 08:55:55 +0000 (16:55 +0800)]
net: mctp: Prevent duplicate binds
Disallow bind() calls that have the same arguments as existing bound
sockets. Previously multiple sockets could bind() to the same
type/local address, with an arbitrary socket receiving matched messages.
This is only a partial fix, a future commit will define precedence order
for MCTP_ADDR_ANY versus specific EID bind(), which are allowed to exist
together.
Fixes reset GPIO usage during probe by ensuring we retrieve the GPIO and
take the device out of reset (if it defaults to being in reset) before
we attempt to communicate with the device. This is achieved by moving
the call to tcan4x5x_get_gpios() before tcan4x5x_find_version() and
avoiding any device communication while getting the GPIOs. Once we
determine the version, we can then take the knowledge of which GPIOs we
obtained and use it to decide whether we need to disable the wake or
state pin functions within the device.
This change is necessary in a situation where the reset GPIO is pulled
high externally before the CPU takes control of it, meaning we need to
explicitly bring the device out of reset before we can start
communicating with it at all.
This also has the effect of fixing an issue where a reset of the device
would occur after having called tcan4x5x_disable_wake(), making the
original behavior not actually disable the wake. This patch should now
disable wake or state pin functions well after the reset occurs.
Signed-off-by: Brett Werling <brett.werling@garmin.com> Link: https://patch.msgid.link/20250711141728.1826073-1-brett.werling@garmin.com Cc: Markus Schneider-Pargmann <msp@baylibre.com> Fixes: 142c6dc6d9d7 ("can: tcan4x5x: Add support for tcan4552/4553") Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Alice Ryhl [Tue, 15 Jul 2025 07:51:40 +0000 (07:51 +0000)]
vfs: add Rust files to MAINTAINERS
These files are maintained by the VFS subsystem, thus add them to the
relevant MAINTAINERS entry to ensure that the maintainers are ccd on
relevant changes.
can: janz-ican3: use sysfs_emit() in fwinfo_show()
As recommended in Documentation/filesystems/sysfs.rst, show() callbacks
should use sysfs_emit() or sysfs_emit_at() to format values returned to
userspace. Replace scnprintf() with sysfs_emit() in fwinfo_show().
Ville Syrjälä [Fri, 11 Jul 2025 20:57:44 +0000 (23:57 +0300)]
wifi: iwlwifi: Fix botched indexing conversion
The conversion from compiler assisted indexing to manual
indexing wasn't done correctly. The array is still made
up of __le16 elements so multiplying the outer index by
the element size is not what we want. Fix it up.
This causes the kernel to oops when trying to transfer any
significant amount of data over wifi:
Cc: Miri Korenblit <miriam.rachel.korenblit@intel.com> Fixes: 6204d5130a64 ("wifi: iwlwifi: use bc entries instead of bc table also for pre-ax210") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20250711205744.28723-1-ville.syrjala@linux.intel.com Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
wifi: cfg80211: fix double free for link_sinfo in nl80211_station_dump()
Currently, the link_sinfo structure is being freed twice in
nl80211_dump_station(), once after the send_station() call and again
in the error handling path. This results in a double free of both
link_sinfo and link_sinfo->pertid, which might lead to undefined
behavior or kernel crashes.
Hence, fix by ensuring cfg80211_sinfo_release_content() is only
invoked once during execution of nl80211_station_dump().
Fixes: 49e47223ecc4 ("wifi: cfg80211: allocate memory for link_station info structure") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/all/81f30515-a83d-4b05-a9d1-e349969df9e9@sabinyo.mountain/ Reported-by: syzbot+4ba6272678aa468132c8@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68655325.a70a0220.5d25f.0316.GAE@google.com Signed-off-by: Sarika Sharma <quic_sarishar@quicinc.com> Link: https://patch.msgid.link/20250714084405.178066-1-quic_sarishar@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
wifi: cfg80211: fix off channel operation allowed check for MLO
In cfg80211_off_channel_oper_allowed(), the current logic disallows
off-channel operations if any link operates on a radar channel,
assuming such channels cannot be vacated. This assumption holds for
non-MLO interfaces but not for MLO.
With MLO and multi-radio devices, different links may operate on
separate radios. This allows one link to scan off-channel while
another remains on a radar channel. For example, in a 5 GHz
split-phy setup, the lower band can scan while the upper band
stays on a radar channel.
Off-channel operations can be allowed if the radio/link onto which the
input channel falls is different from the radio/link which has an active
radar channel. Therefore, fix cfg80211_off_channel_oper_allowed() by
returning false only if the requested channel maps to the same radio as
an active radar channel. Allow off-channel operations when the requested
channel is on a different radio, as in MLO with multi-radio setups.
arm64: samsung: MAINTAINERS: Add Tesla FSD DTS to Exynos entry
Effectively all Tesla FSD DTS patches go via Samsung Exynos SoC
maintainer, so add the pattern to make it obvious and reduce the chances
patches won't reach these maintainers.
Cc: Peter Griffin <peter.griffin@linaro.org> Cc: André Draszik <andre.draszik@linaro.org> Cc: Tudor Ambarus <tudor.ambarus@linaro.org> Cc: Alim Akhtar <alim.akhtar@samsung.com> Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Reviewed-by: André Draszik <andre.draszik@linaro.org> Link: https://lore.kernel.org/r/20250710073443.13788-4-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Effectively all Tesla FSD and Google GS101 DTS patches go via Samsung
SoC maintainer, who applies the same rules as for Samsung SoC: DTS must
be fully DT bindings compliant (`dtbs_check W=1`). Existing sources
already are compliant, so just document that implicit rule by mentioning
respective maintainer profile in their entries.
Cc: Peter Griffin <peter.griffin@linaro.org> Cc: André Draszik <andre.draszik@linaro.org> Cc: Tudor Ambarus <tudor.ambarus@linaro.org> Cc: Alim Akhtar <alim.akhtar@samsung.com> Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Reviewed-by: Peter Griffin <peter.griffin@linaro.org> Reviewed-by: André Draszik <andre.draszik@linaro.org> Link: https://lore.kernel.org/r/20250710073443.13788-3-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
wifi: mac80211: use RCU-safe iteration in ieee80211_csa_finish
The ieee80211_csa_finish() function currently uses for_each_sdata_link()
to iterate over links of sdata. However, this macro internally uses
wiphy_dereference(), which expects the wiphy->mtx lock to be held.
When ieee80211_csa_finish() is invoked under an RCU read-side critical
section (e.g., under rcu_read_lock()), this leads to a warning from the
RCU debugging framework.
This warning is triggered because wiphy_dereference() is not safe to use
without holding the wiphy mutex, and it is being used in an RCU context
without the required locking.
Fix this by introducing and using a new macro, for_each_sdata_link_rcu(),
which performs RCU-safe iteration over sdata links using
list_for_each_entry_rcu() and rcu_dereference(). This ensures that the
link pointers are accessed safely under RCU and eliminates the warning.
Fixes: f600832794c9 ("wifi: mac80211: restructure tx profile retrieval for MLO MBSSID") Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250711033846.40455-1-maharaja.kennadyrajan@oss.qualcomm.com
[unindent like the non-RCU macro] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Alex Gavin [Thu, 10 Jul 2025 21:14:30 +0000 (14:14 -0700)]
wifi: mac80211_hwsim: Update comments in header
- Reorders 'HWSIM_ATTR_PAD' to after 'HWSIM_ATTR_FREQ',
matching order in 'enum hwsim_attrs'
- Change references from old commands to new names
- Fixes typos
Yuvarani V [Thu, 10 Jul 2025 05:34:28 +0000 (11:04 +0530)]
wifi: mac80211: parse unsolicited broadcast probe response data
During commands like channel switch and color change, the updated
unsolicited broadcast probe response template may be provided. However,
this data is not parsed or acted upon in mac80211.
Add support to parse it and set the BSS changed flag
BSS_CHANGED_UNSOL_BCAST_PROBE_RESP so that drivers could take further
action.
Yuvarani V [Thu, 10 Jul 2025 05:34:27 +0000 (11:04 +0530)]
wifi: cfg80211: parse attribute to update unsolicited probe response template
At present, the updated unsolicited broadcast probe response template is
not processed during userspace commands such as channel switch or color
change. This leads to an issue where older incorrect unsolicited probe
response is still used during these events.
Add support to parse the netlink attribute and store it so that
mac80211/drivers can use it to set the BSS_CHANGED_UNSOL_BCAST_PROBE_RESP
flag in order to send the updated unsolicited broadcast probe response
templates during these events.
Johannes Berg [Wed, 9 Jul 2025 20:38:03 +0000 (23:38 +0300)]
wifi: mac80211: don't use TPE data from assoc response
Since there's no TPE element in the (re)assoc response, trying
to use the data from it just leads to using the defaults, even
though the real values had been set during authentication from
the discovered BSS information.
Fix this by simply not handling the TPE data in assoc response
since it's not intended to be present, if it changes later the
necessary changes will be made by tracking beacons later.
As a side effect, by passing the real frame subtype, now print
a correct value for ML reconfiguration responses.
If this action frame, with the value of IEEE80211_HT_CHANWIDTH_ANY,
arrives right after a beacon that changed the operational bandwidth from
20 MHz to 40 MHz, then updating the rate control bandwidth to 40 can
race with updating the chanctx width (that happens in the beacon
proccesing) back to 40 MHz:
in (**), the maximum between the capability width and the bss width is
returned. But the bss width was just updated to 40 in (*),
so the action frame handling code will increase the width of the rate
control before the chanctx was increased (in ***), leading to a FW error
(at least in iwlwifi driver. But this is wrong regardless).
Fix this by simply handling the action frame async, so it won't race
with the beacon proccessing.
wifi: mac80211: don't mark keys for inactive links as uploaded
During resume, the driver can call ieee80211_add_gtk_rekey for keys that
are not programmed into the device, e.g. keys of inactive links.
Don't mark such a key as uploaded to avoid removing it later from the
driver/device.
At the end of reconfig we are activating all the links that were active
before the error.
During the activation, _ieee80211_link_use_channel will unassign and
re-assign the chanctx from/to the link.
But we only need to do the assign, as we are re-building the state as it
was before the reconfig.
Johannes Berg [Wed, 9 Jul 2025 20:37:57 +0000 (23:37 +0300)]
wifi: mac80211: clean up cipher suite handling
Under the previous commit's assumption that FIPS isn't
supported by hardware, we don't need to modify the
cipher suite list, but just need to use the software
one instead of the driver's in this case, so clean up
the code.
Also fix it to exclude TKIP in this case, since that's
also dependent on RC4.
Johannes Berg [Wed, 9 Jul 2025 20:37:56 +0000 (23:37 +0300)]
wifi: mac80211: don't send keys to driver when fips_enabled
When fips_enabled is set, don't send any keys to the driver
(including possibly WoWLAN KEK/KCK material), assuming that
no device exists with the necessary certifications. If this
turns out to be false in the future, we can add a HW flag.
Johannes Berg [Wed, 9 Jul 2025 20:37:54 +0000 (23:37 +0300)]
wifi: mac80211: remove ieee80211_link_unreserve_chanctx() return value
All the paths that could return an error are considered
misuses of the function and WARN already, and none of
the callers ever check the return value. Remove it.
Johannes Berg [Wed, 9 Jul 2025 20:37:53 +0000 (23:37 +0300)]
wifi: mac80211: don't unreserve never reserved chanctx
If a link has no chanctx, indicating it is an inactive link
that we tracked CSA for, then attempting to unreserve the
reserved chanctx will throw a warning and fail, since there
never was a reserved chanctx. Skip the unreserve.
This reverts commit e3eac9f32ec0 ("wifi: cfg80211: Annotate struct
cfg80211_scan_request with __counted_by").
This really has been a completely failed experiment. There were
no actual bugs found, and yet at this point we already have four
"fixes" to it, with nothing to show for but code churn, and it
never even made the code any safer.
In all of the cases that ended up getting "fixed", the structure
is also internally inconsistent after the n_channels setting as
the channel list isn't actually filled yet. You cannot scan with
such a structure, that's just wrong. In mac80211, the struct is
also reused multiple times, so initializing it once is no good.
Some previous "fixes" (e.g. one in brcm80211) are also just setting
n_channels before accessing the array, under the assumption that the
code is correct and the array can be accessed, further showing that
the whole thing is just pointless when the allocation count and use
count are not separate.
If we really wanted to fix it, we'd need to separately track the
number of channels allocated and the number of channels currently
used, but given that no bugs were found despite the numerous syzbot
reports, that'd just be a waste of time.
Remove the __counted_by() annotation. We really should also remove
a number of the n_channels settings that are setting up a structure
that's inconsistent, but that can wait.
Forcibly disable KCSAN for the sev-nmi.c source file, which only
contains functions annotated as 'noinstr' but is emitted with calls to
KCSAN instrumentation nonetheless. E.g.,
Michael Straube [Sun, 13 Jul 2025 10:02:29 +0000 (12:02 +0200)]
staging: rtl8723bs: Efuse_WordEnableDataWrite() is not used
The function Efuse_WordEnableDataWrite() defined in rtw_efuse.c is not
used. Remove the function and code it is calling, i.e. the function
pointer (*Efuse_WordEnableDataWrite) in struct hal_ops and the function
Hal_EfuseWordEnableDataWrite() to which it points.
GPIO core already makes sure that offsets higher than the number of GPIOs
are never passed to controller callbacks. We can remove the unnecessary
check.
gpio: wcd934x: check the return value of regmap_update_bits()
regmap_update_bits() can fail so check its return value in
wcd_gpio_direction_output() for consistency with the rest of the code
and propagate any errors.
When restoring the default socket callbacks during a TLS handshake, we
need to acquire a write lock on sk_callback_lock. Previously, a read
lock was used, which is insufficient for modifying sk_user_data and
sk_data_ready.
nvme: fix misaccounting of nvme-mpath inflight I/O
Procedures for nvme-mpath IO accounting:
1) initialize nvme_request and clear flags;
2) set NVME_MPATH_IO_STATS and increase inflight counter when IO
started;
3) check NVME_MPATH_IO_STATS and decrease inflight counter when IO is
done;
However, for the case nvme_fail_nonready_command(), both step 1) and 2)
are skipped, and if old nvme_request set NVME_MPATH_IO_STATS and then
request is reused, step 3) will still be executed, causing inflight I/O
counter to be negative.
Fix the problem by clearing nvme_request in nvme_fail_nonready_command().
Fixes: ea5e5f42cd2c ("nvme-fabrics: avoid double completions in nvmf_fail_nonready_command") Reported-by: Yi Zhang <yi.zhang@redhat.com> Closes: https://lore.kernel.org/all/CAHj4cs_+dauobyYyP805t33WMJVzOWj=7+51p4_j9rA63D9sog@mail.gmail.com/ Signed-off-by: Yu Kuai <yukuai3@huawei.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
nvme: revert the cross-controller atomic write size validation
This was originally added by commit 8695f060a029 ("nvme: all namespaces
in a subsystem must adhere to a common atomic write size") to check
the all controllers in a subsystem report the same atomic write size,
but the check wasn't quite correct and caused problems for devices
with multiple namespaces that report different LBA sizes. Commit f46d273449ba ("nvme: fix atomic write size validation") tried to fix
this, but then caused problems for namespace rediscovery after a
format with an LBA size change that changes the AWUPF value.
This drops the validation and essentially reverts those two commits while
keeping the cleanup that went in between the two. We'll need to figure
out how to properly check for the mouse trap that nvme left us, but for
now revert the check to keep devices working for users who couldn't care
less about the atomic write feature.
Fixes: 8695f060a029 ("nvme: all namespaces in a subsystem must adhere to a common atomic write size") Fixes: f46d273449ba ("nvme: fix atomic write size validation") Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Alan Adamson <alan.adamson@oracle.com> Reviewed-by: Keith Busch <kbusch@kernel.org> Reviewed-by: John Garry <john.g.garry@oracle.com> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Tested-by: Alan Adamson <alan.adamson@oracle.com>
Naman Jain [Fri, 11 Jul 2025 06:08:46 +0000 (11:38 +0530)]
tools/hv: fcopy: Fix irregularities with size of ring buffer
Size of ring buffer, as defined in uio_hv_generic driver, is no longer
fixed to 16 KB. This creates a problem in fcopy, since this size was
hardcoded. With the change in place to make ring sysfs node actually
reflect the size of underlying ring buffer, it is safe to get the size
of ring sysfs file and use it for ring buffer size in fcopy daemon.
Fix the issue of disparity in ring buffer size, by making it dynamic
in fcopy uio daemon.
Cc: stable@vger.kernel.org Fixes: 0315fef2aff9 ("uio_hv_generic: Align ring size to system page") Signed-off-by: Naman Jain <namjain@linux.microsoft.com> Reviewed-by: Saurabh Sengar <ssengar@linux.microsoft.com> Reviewed-by: Long Li <longli@microsoft.com> Link: https://lore.kernel.org/r/20250711060846.9168-1-namjain@linux.microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org>
Message-ID: <20250711060846.9168-1-namjain@linux.microsoft.com>
PCI: hv: Use the correct hypercall for unmasking interrupts on nested
Running as nested root on MSHV imposes a different requirement
for the pci-hyperv controller.
In this setup, the interrupt will first come to the L1 (nested) hypervisor,
which will deliver it to the appropriate root CPU. Instead of issuing the
RETARGET hypercall, issue the MAP_DEVICE_INTERRUPT hypercall to L1 to
complete the setup.
Rename hv_arch_irq_unmask() to hv_irq_retarget_interrupt().
Co-developed-by: Jinank Jain <jinankjain@linux.microsoft.com> Signed-off-by: Jinank Jain <jinankjain@linux.microsoft.com> Signed-off-by: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com> Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com> Reviewed-by: Roman Kisel <romank@linux.microsoft.com> Reviewed-by: Michael Kelley <mhklinux@outlook.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/1752261532-7225-4-git-send-email-nunodasneves@linux.microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org>
Message-ID: <1752261532-7225-4-git-send-email-nunodasneves@linux.microsoft.com>
Move some of the logic of hv_irq_compose_irq_message() into
hv_map_msi_interrupt(). Make hv_map_msi_interrupt() a globally-available
helper function, which will be used to map PCI interrupts when running
in the root partition.
Signed-off-by: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com> Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com> Reviewed-by: Roman Kisel <romank@linux.microsoft.com> Reviewed-by: Michael Kelley <mhklinux@outlook.com> Link: https://lore.kernel.org/r/1752261532-7225-3-git-send-email-nunodasneves@linux.microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org>
Message-ID: <1752261532-7225-3-git-send-email-nunodasneves@linux.microsoft.com>
Nuno Das Neves [Fri, 11 Jul 2025 19:18:50 +0000 (12:18 -0700)]
Drivers: hv: Use nested hypercall for post message and signal event
When running nested, these hypercalls must be sent to the L0 hypervisor
or VMBus will fail.
Remove hv_do_nested_hypercall() and hv_do_fast_nested_hypercall8()
altogether and open-code these cases, since there are only 2 and all
they do is add the nested bit.
Namhyung Kim [Mon, 14 Jul 2025 05:21:43 +0000 (22:21 -0700)]
perf ftrace latency: Add -e option to measure time between two events
In addition to the function latency, it can measure events latencies.
Some kernel tracepoints are paired and it's menningful to measure how
long it takes between the two events. The latency is tracked for the
same thread.
Currently it only uses BPF to do the work but it can be lifted later.
Instead of having separate a BPF program for each tracepoint, it only
uses generic 'event_begin' and 'event_end' programs to attach to any
(raw) tracepoints.
Kees Cook [Sat, 28 Jun 2025 23:40:38 +0000 (16:40 -0700)]
kunit/fortify: Add back "volatile" for sizeof() constants
It seems the Clang can see through OPTIMIZER_HIDE_VAR when the constant
is coming from sizeof. Adding "volatile" back to these variables solves
this false positive without reintroducing the issues that originally led
to switching to OPTIMIZER_HIDE_VAR in the first place[1].
Dave Martin [Tue, 1 Jul 2025 13:56:16 +0000 (14:56 +0100)]
binfmt_elf: Warn on missing or suspicious regset note names
Now that all regset definitions declare an explicit note name, warn if
the note name is missing when generating a core dump. Simplify the
fallback to always guess "LINUX", which is appropriate for all
Linux-specific notes (i.e., all newly added notes, for a long time
now). The one standard exception (PR_FPREG) will no longer have an
"unexpected" note name overridden, but a warning will still be emitted.
Also warn if the specified note name doesn't match the legacy
pattern -- but don't bother to override the name in this case. This
warning can be removed in future if new note types emerge that require
a specific note name that is not "LINUX".
No functional change, beyond the extra noise in dmesg and not
overriding an unexpected note name for PR_FPREG any more.
Now that all upstream arches are ported to use USER_REGSET_NOTE_TYPE(),
new regsets created by copy-pasting existing code should end up correct
by construction.
projects / thirdparty / kernel / linux.git / log
