Shorten the code. No functional change intended.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Link: https://lore.kernel.org/r/20230219141555.2308306-3-masahiroy@kernel.org
Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
This is the last user of core-y in arch/sh.
Use the standard obj-y syntax.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Link: https://lore.kernel.org/r/20230219141555.2308306-2-masahiroy@kernel.org
Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
The 0day bot reports a lot of warnings (or errors due to CONFIG_WERROR)
like this:
cc1: error: arch/sh/include/mach-hp6xx: No such file or directory [-Werror=missing-include-dirs]
Indeed, arch/sh/include/mach-hp6xx does not exist.
While -Wmissing-include-dirs is only a W=1 warning, it may be
annoying when CONFIG_BTRFS_FS is enabled because fs/btrfs/Makefile
unconditionally adds this warning option.
arch/sh/Makefile defines machdir-y for two purposes:
- Build platform code in arch/sh/boards/mach-*/
- Add arch/sh/include/mach-*/ to the header search path
For the latter, some platforms use arch/sh/include/mach-common/
instead of having its own arch/sh/include/mach-*/.
Drop unneeded machdir-y to omit non-existing include directories.
To build arch/sh/boards/mach-*/, use the standard obj-y syntax in
arch/sh/boards/Makefile.
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/oe-kbuild-all/202302190641.30VVXnPb-lkp@intel.com/
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Link: https://lore.kernel.org/r/20230219141555.2308306-1-masahiroy@kernel.org
Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
I added a warning about about GUP no longer expanding the stack in
commit a425ac5365 ("gup: add warning if some caller would seem to want
stack expansion"), but didn't really expect anybody to hit it.
And it's true that nobody seems to have hit a _real_ case yet, but we
certainly have a number of reports of false positives. Which not only
causes extra noise in itself, but might also end up hiding any real
cases if they do exist.
So let's tighten up the warning condition, and replace the simplistic
vma = find_vma(mm, start);
if (vma && (start < vma->vm_start)) {
WARN_ON_ONCE(vma->vm_flags & VM_GROWSDOWN);
with a
vma = gup_vma_lookup(mm, start);
helper function which works otherwise like just "vma_lookup()", but with
some heuristics for when to warn about gup no longer causing stack
expansion.
In particular, don't just warn for "below the stack", but warn if it's
_just_ below the stack (with "just below" arbitrarily defined as 64kB,
because why not?). And rate-limit it to at most once per hour, which
means that any false positives shouldn't completely hide subsequent
reports, but we won't be flooding the logs about it either.
The previous code triggered when some GUP user (chromium crashpad)
accessing past the end of the previous vma, for example. That has never
expanded the stack, it just causes GUP to return early, and as such we
shouldn't be warning about it.
This is still going trigger the randomized testers, but to mitigate the
noise from that, use "dump_stack()" instead of "WARN_ON_ONCE()" to get
the kernel call chain. We'll get the relevant information, but syzbot
shouldn't get too upset about it.
Also, don't even bother with the GROWSUP case, which would be using
different heuristics entirely, but only happens on parisc.
Reported-by: kernel test robot <oliver.sang@intel.com>
Reported-by: John Hubbard <jhubbard@nvidia.com>
Reported-by: syzbot+6cf44e127903fdf9d929@syzkaller.appspotmail.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Instead of checking for -E2BIG, it is better to just check for less than
zero of strscpy() for error. Testing for -E2BIG is not very robust, and
the calling code does not really care about the error code, just that
there was an error.
One of the updates to convert strlcpy() to strscpy() had a v2 version
that changed the test from testing against -E2BIG to less than zero, but I
took the v1 version that still tested for -E2BIG.
Link: https://lore.kernel.org/linux-trace-kernel/20230615180420.400769-1-azeemshaikh38@gmail.com/
Link: https://lore.kernel.org/linux-trace-kernel/20230704100807.707d1605@rorschach.local.home
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Azeem Shaikh <azeemshaikh38@gmail.com>
Cc: Kees Cook <keescook@chromium.org>
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Conor reports that risc-v tries to enable IPIs before telling the
core code to enable RCU. With the introduction of the mapple tree
as a backing store for the irq descriptors, this results in
a very shouty boot sequence, as RCU is legitimately upset.
Restore some sanity by moving the risc_ipi_enable() call after
notify_cpu_starting(), which explicitly enables RCU on the calling
CPU.
Fixes: 832f15f426 ("RISC-V: Treat IPIs as normal Linux IRQs")
Reported-by: Conor Dooley <conor@kernel.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20230703-dupe-frying-79ae2ccf94eb@spud
Cc: Anup Patel <apatel@ventanamicro.com>
Cc: Palmer Dabbelt <palmer@rivosinc.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Tested-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20230703183126.1567625-1-maz@kernel.org
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
The WARN_ON_ONCE() statement in riscv's huge_pte_alloc() is susceptible
to false positives, because the pte is read twice at the C language
level, locklessly, within the same conditional statement. Depending on
compiler behavior, this can lead to generated machine code that actually
reads the pte just once, or twice. Reading twice will expose the code to
changing pte values and cause incorrect behavior.
In [1], similar code actually caused a kernel crash on 64-bit x86, when
using clang to build the kernel, but only after the conversion from *pte
reads, to ptep_get(pte). The latter uses READ_ONCE(), which forced a
double read of *pte.
Rather than waiting for the upcoming ptep_get() conversion, just convert
this part of the code now, but in a way that avoids the above problem:
take a single snapshot of the pte before using it in the WARN
conditional.
As expected, this preparatory step does not actually change the
generated code ("make mm/hugetlbpage.s"), on riscv64, when using a gcc
12.2 cross compiler.
[1] https://lore.kernel.org/20230630013203.1955064-1-jhubbard@nvidia.com
Suggested-by: James Houghton <jthoughton@google.com>
Cc: Ryan Roberts <ryan.roberts@arm.com>
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
Link: https://lore.kernel.org/r/20230703190044.311730-1-jhubbard@nvidia.com
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
intro
=====
When the RISC-V dt-bindings were accepted upstream in Linux, the base
ISA etc had yet to be ratified. By the ratification of the base ISA,
incompatible changes had snuck into the specifications - for example the
Zicsr and Zifencei extensions were spun out of the base ISA.
Fast forward to today, and the reason for this patch.
Currently the riscv,isa dt property permits only a specific subset of
the ISA string - in particular it excludes version numbering.
With the current constraints, it is not possible to discern whether
"rv64i" means that the hart supports the fence.i instruction, for
example.
Future systems may choose to implement their own instruction fencing,
perhaps using a vendor extension, or they may not implement the optional
counter extensions. Software needs a way to determine this.
versioning schemes
==================
"Use the extension versions that are described in the ISA manual" you
may say, and it's not like this has not been considered.
Firstly, software that parses the riscv,isa property at runtime will
need to contain a lookup table of some sort that maps arbitrary versions
to versions it understands. There is not a consistent application of
version number applied to extensions, with a higgledy-piggledy
collection of tags, "bare" and versioned documents awaiting the reader
on the "recently ratified extensions" page:
https://wiki.riscv.org/display/HOME/Recently+Ratified+Extensions
As an aside, and this is reflected in the patch too, since many
extensions have yet to appear in a release of the ISA specs,
they are defined by commits in their respective "working draft"
repositories.
Secondly, there is an issue of backwards compatibility, whereby allowing
numbers in the ISA string, some parsers may be broken. This would
require an additional property to be created to even use the versions in
this manner.
~boolean properties~ string array property
==========================================
If a new property is needed, the whole approach may as well be looked at
from the bottom up. A string with limited character choices etc is
hardly the best approach for communicating extension information to
software.
Switching to using properties that are defined on a per extension basis,
allows us to define explicit meanings for the DT representation of each
extension - rather than the current situation where different operating
systems or other bits of software may impart different meanings to
characters in the string.
Clearly the best source of meanings is the specifications themselves,
this just provides us the ability to choose at what point in time the
meaning is set. If an extension changes incompatibility in the future,
a new property will be required.
Off-list, some of the RVI folks have committed to shoring up the wording
in either the ISA specifications, the riscv-isa-manual or
so that in the future, modifications to and additions or removals of
features will require a new extension. Codifying that assertion
somewhere would make it quite unlikely that compatibility would be
broken, but we have the tools required to deal with it, if & when it
crops up.
It is in our collective interest, as consumers of extension meanings, to
define a scheme that enforces compatibility.
The use of individual elements, rather than a single string, will also
permit validation that the properties have a meaning, as well as
potentially reject mutually exclusive combinations, or enforce
dependencies between extensions. That would not have be possible with
the current dt-schema infrastructure for arbitrary strings, as we would
need to add a riscv,isa parser to dt-validate!
That's not implemented in this patch, but rather left as future work (for
the brave, or the foolish).
parser simplicity
=================
Many systems that parse DT at runtime already implement an function that
can check for the presence of a string in an array of string, as it is
similar to the process for parsing a list of compatible strings, so a
bunch of new, custom, DT parsing should not be needed.
Getting rid of "riscv,isa" parsing would be a nice simplification, but
unfortunately for backwards compatibility with old dtbs, existing
parsers may not be removable - which may greatly simplify
dt parsing code. In Linux, for example, checking for whether a hart
supports an extension becomes as simple as:
of_property_match_string(node, "riscv,isa-extensions", "zicbom")
vendor extensions
=================
Compared to riscv,isa, this proposed scheme promotes vendor extensions,
oft touted as the strength of RISC-V, to first-class citizens.
At present, extensions are defined as meaning what the RISC-V ISA
specifications say they do. There is no realistic way of using that
interface to provide cross-platform definitions for what vendor
extensions mean. Vendor extensions may also have even less consistency
than RVI do in terms of versioning, or no care about backwards
compatibility.
The new property allows us to assign explicit meanings on a per vendor
extension basis, backed up by a description of their meanings.
fin
===
Create a new file to store the extension meanings and a new
riscv,isa-base property to replace the aspect of riscv,isa that is
not represented by the new property - the base ISA implemented by a hart.
As a starting point, add properties for extensions currently used in
Linux.
Finally, mark riscv,isa as deprecated, as removing support for it in
existing programs would be an ABI break.
CC: Palmer Dabbelt <palmer@dabbelt.com>
CC: Paul Walmsley <paul.walmsley@sifive.com>
CC: Rob Herring <robh+dt@kernel.org>
CC: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
CC: Alistair Francis <alistair.francis@wdc.com>
CC: Andrew Jones <ajones@ventanamicro.com>
CC: Anup Patel <apatel@ventanamicro.com>
CC: Atish Patra <atishp@atishpatra.org>
CC: Jessica Clarke <jrtc27@jrtc27.com>
CC: Rick Chen <rick@andestech.com>
CC: Leo <ycliang@andestech.com>
CC: Oleksii <oleksii.kurochko@gmail.com>
CC: linux-riscv@lists.infradead.org
CC: qemu-riscv@nongnu.org
CC: u-boot@lists.denx.de
CC: devicetree@vger.kernel.org
CC: linux-kernel@vger.kernel.org
Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20230702-eats-scorebook-c951f170d29f@spud
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
It appears that a merge conflict ended up hiding a newly added constant
in some configurations:
arch/arm64/kernel/entry-ftrace.S: Assembler messages:
arch/arm64/kernel/entry-ftrace.S:59: Error: undefined symbol FTRACE_OPS_DIRECT_CALL used as an immediate value
FTRACE_OPS_DIRECT_CALL is still used when CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS
is enabled, even if CONFIG_FUNCTION_GRAPH_TRACER is disabled, so change the
ifdef accordingly.
Link: https://lkml.kernel.org/r/20230623152204.2216297-1-arnd@kernel.org
Cc: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Donglin Peng <pengdonglin@sangfor.com.cn>
Fixes: 3646970322 ("arm64: ftrace: Enable HAVE_FUNCTION_GRAPH_RETVAL")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Florent Revest <revest@chromium.org>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Fix an issue in function 'tracing_err_log_open'.
The function doesn't call 'seq_open' if the file is opened only with
write permissions, which results in 'file->private_data' being left as null.
If we then use 'lseek' on that opened file, 'seq_lseek' dereferences
'file->private_data' in 'mutex_lock(&m->lock)', resulting in a kernel panic.
Writing to this node requires root privileges, therefore this bug
has very little security impact.
Tracefs node: /sys/kernel/tracing/error_log
Example Kernel panic:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038
Call trace:
mutex_lock+0x30/0x110
seq_lseek+0x34/0xb8
__arm64_sys_lseek+0x6c/0xb8
invoke_syscall+0x58/0x13c
el0_svc_common+0xc4/0x10c
do_el0_svc+0x24/0x98
el0_svc+0x24/0x88
el0t_64_sync_handler+0x84/0xe4
el0t_64_sync+0x1b4/0x1b8
Code: d503201f aa0803e0 aa1f03e1 aa0103e9 (c8e97d02)
---[ end trace 561d1b49c12cf8a5 ]---
Kernel panic - not syncing: Oops: Fatal exception
Link: https://lore.kernel.org/linux-trace-kernel/20230703155237eucms1p4dfb6a19caa14c79eb6c823d127b39024@eucms1p4
Link: https://lore.kernel.org/linux-trace-kernel/20230704102706eucms1p30d7ecdcc287f46ad67679fc8491b2e0f@eucms1p3
Cc: stable@vger.kernel.org
Fixes: 8a062902be ("tracing: Add tracing error log")
Signed-off-by: Mateusz Stachyra <m.stachyra@samsung.com>
Suggested-by: Steven Rostedt <rostedt@goodmis.org>
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Matthieu Baerts says:
====================
mptcp: fixes for v6.5
Here is a first batch of fixes for v6.5 and older.
The fixes are not linked to each others.
Patch 1 ensures subflows are unhashed before cleaning the backlog to
avoid races. This fixes another recent fix from v6.4.
Patch 2 does not rely on implicit state check in mptcp_listen() to avoid
races when receiving an MP_FASTCLOSE. A regression from v5.17.
The rest fixes issues in the selftests.
Patch 3 makes sure errors when setting up the environment are no longer
ignored. For v5.17+.
Patch 4 uses 'iptables-legacy' if available to be able to run on older
kernels. A fix for v5.13 and newer.
Patch 5 catches errors when issues are detected with packet marks. Also
for v5.13+.
Patch 6 uses the correct variable instead of an undefined one. Even if
there was no visible impact, it can help to find regressions later. An
issue visible in v5.19+.
Patch 7 makes sure errors with some sub-tests are reported to have the
selftest marked as failed as expected. Also for v5.19+.
Patch 8 adds a kernel config that is required to execute MPTCP
selftests. It is valid for v5.9+.
Patch 9 fixes issues when validating the userspace path-manager with
32-bit arch, an issue affecting v5.19+.
====================
Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
When using pm_nl_ctl to validate userspace path-manager's behaviours, it
was failing on 32-bit architectures ~half of the time.
pm_nl_ctl was not reporting any error but the command was not doing what
it was expected to do. As a result, the expected linked event was not
triggered after and the test failed.
This is due to the fact the token given in argument to the application
was parsed as an integer with atoi(): in a 32-bit arch, if the number
was bigger than INT_MAX, 2147483647 was used instead.
This can simply be fixed by using strtoul() instead of atoi().
The errors have been seen "by chance" when manually looking at the
results from LKFT.
Fixes: 9a0b36509d ("selftests: mptcp: support MPTCP_PM_CMD_ANNOUNCE")
Cc: stable@vger.kernel.org
Fixes: ecd2a77d67 ("selftests: mptcp: support MPTCP_PM_CMD_REMOVE")
Fixes: cf8d0a6dfd ("selftests: mptcp: support MPTCP_PM_CMD_SUBFLOW_CREATE")
Fixes: 57cc361b8d ("selftests: mptcp: support MPTCP_PM_CMD_SUBFLOW_DESTROY")
Fixes: ca188a25d4 ("selftests: mptcp: userspace PM support for MP_PRIO signals")
Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
MPTCP selftests are using TCP SYN Cookies for quite a while now, since
v5.9.
Some CIs don't have this config option enabled and this is causing
issues in the tests:
# ns1 MPTCP -> ns1 (10.0.1.1:10000 ) MPTCP (duration 167ms) sysctl: cannot stat /proc/sys/net/ipv4/tcp_syncookies: No such file or directory
# [ OK ]./mptcp_connect.sh: line 554: [: -eq: unary operator expected
There is no impact in the results but the test is not doing what it is
supposed to do.
Fixes: fed61c4b58 ("selftests: mptcp: make 2nd net namespace use tcp syn cookies unconditionally")
Cc: stable@vger.kernel.org
Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
A message was mentioning an issue with the "remove" tests but the
selftest was not marked as failed.
Directly exit with an error like it is done everywhere else in this
selftest.
Link: https://github.com/multipath-tcp/mptcp_net-next/issues/368
Fixes: 259a834fad ("selftests: mptcp: functional tests for the userspace PM type")
Cc: stable@vger.kernel.org
Acked-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
"server4_port" variable is not set but "app4_port" is the server port in
v4 and the correct variable name to use.
The port is optional so there was no visible impact.
Link: https://github.com/multipath-tcp/mptcp_net-next/issues/368
Fixes: ca188a25d4 ("selftests: mptcp: userspace PM support for MP_PRIO signals")
Cc: stable@vger.kernel.org
Acked-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
When an error was detected when checking the marks, a message was
correctly printed mentioning the error but followed by another one
saying everything was OK and the selftest was not marked as failed as
expected.
Now the 'ret' variable is directly set to 1 in order to make sure the
exit is done with an error, similar to what is done in other functions.
While at it, the error is correctly propagated to the caller.
Link: https://github.com/multipath-tcp/mptcp_net-next/issues/368
Fixes: dc65fe82fb ("selftests: mptcp: add packet mark test case")
Cc: stable@vger.kernel.org
Acked-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
IPTables commands using 'iptables-nft' fail on old kernels, at least
on v5.15 because it doesn't see the default IPTables chains:
$ iptables -L
iptables/1.8.2 Failed to initialize nft: Protocol not supported
As a first step before switching to NFTables, we can use iptables-legacy
if available.
Link: https://github.com/multipath-tcp/mptcp_net-next/issues/368
Fixes: dc65fe82fb ("selftests: mptcp: add packet mark test case")
Cc: stable@vger.kernel.org
Acked-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
In case of "external" errors when preparing the environment for the
TProxy tests, the subtests were marked as skipped.
This is fine but it means these errors are ignored. On MPTCP Public CI,
we do want to catch such issues and mark the selftest as failed if there
are such issues. We can then use mptcp_lib_fail_if_expected_feature()
helper that has been recently added to fail if needed.
Link: https://github.com/multipath-tcp/mptcp_net-next/issues/368
Fixes: 5fb62e9cd3 ("selftests: mptcp: add tproxy test case")
Cc: stable@vger.kernel.org
Acked-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Since the blamed commit, closing the first subflow resets the first
subflow socket state to SS_UNCONNECTED.
The current mptcp listen implementation relies only on such
state to prevent touching not-fully-disconnected sockets.
Incoming mptcp fastclose (or paired endpoint removal) unconditionally
closes the first subflow.
All the above allows an incoming fastclose followed by a listen() call
to successfully race with a blocking recvmsg(), potentially causing the
latter to hit a divide by zero bug in cleanup_rbuf/__tcp_select_window().
Address the issue explicitly checking the msk socket state in
mptcp_listen(). An alternative solution would be moving the first
subflow socket state update into mptcp_disconnect(), but in the long
term the first subflow socket should be removed: better avoid relaying
on it for internal consistency check.
Fixes: b29fcfb54c ("mptcp: full disconnect implementation")
Cc: stable@vger.kernel.org
Reported-by: Christoph Paasch <cpaasch@apple.com>
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/414
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
While tacking care of the mptcp-level listener I unintentionally
moved the subflow level unhash after the subflow listener backlog
cleanup.
That could cause some nasty race and makes the code harder to read.
Address the issue restoring the proper order of operations.
Fixes: 57fc0f1cea ("mptcp: ensure listener is unhashed before updating the sk status")
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Change boolean parameter of function "qeth_l3_vipa_store" inside the
"qeth_l3_dev_vipa_del4_store" function from "true" to "false" because
"true" is used for adding a virtual ip address and "false" for deleting.
Fixes: 2390166a6b ("s390/qeth: clean up L3 sysfs code")
Reviewed-by: Alexandra Winter <wintera@linux.ibm.com>
Reviewed-by: Wenjia Zhang <wenjia@linux.ibm.com>
Signed-off-by: Thorsten Winkler <twinkler@linux.ibm.com>
Signed-off-by: Alexandra Winter <wintera@linux.ibm.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Moving the call of fpu__init_cpu() from cpu_init() to start_secondary()
broke Xen PV guests, as those don't call start_secondary() for APs.
Call fpu__init_cpu() in Xen's cpu_bringup(), which is the Xen PV
replacement of start_secondary().
Fixes: b81fac906a ("x86/fpu: Move FPU initialization into arch_cpu_finalize_init()")
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20230703130032.22916-1-jgross@suse.com
This reverts commit 534066a983.
It's actively detrimental in that it hides files that shouldn't be
hidden.
If I have some b4 mbx file in my git directory, it either was already
applied with "git am" and is now stale, or maybe it's waiting for that
to happen. In neither case is "ignore it" the right option.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
These are the first few patches in the Scope-based Resource Management
series that introduce the infrastructure but not any conversions as of
yet.
Adding the infrastructure now allows multiple people to start using them.
Of note is that Sparse will need some work since it doesn't yet
understand this attribute and might have decl-after-stmt issues -- but I
think that's being worked on.
-----BEGIN PGP SIGNATURE-----
iQJJBAABCgAzFiEEv3OU3/byMaA0LqWJdkfhpEvA5LoFAmSZehYVHHBldGVyekBp
bmZyYWRlYWQub3JnAAoJEHZH4aRLwOS6uC0P/0pduumvCE+osm869VOroHeVqz6B
B36oqJlD1uqIA8JWiNW8TbpUUqTvU0FyW1jU1YnUdol5Kb3XH7APQIayGj2HM+Mc
kMyHc4/ICxBzRI7STiBtCEbHIwYAfuibCAfuq7QP4GDw4vHKvUC7BUUaUdbQSey0
IyUsvgPqLRL1KW3tb2z7Zfz6Oo/f0A/+viTiqOKNxSctXaD7TOEUpIZ/RhIgWbIV
as65sgzLD/87HV9LbtTyOQCxjR5lpDlTaITapMfgwC9bQ8vQwjmaX3WETIlUmufl
8QG3wiPIDynmqjmpEeY+Cyjcu/Gbz/2XENPgHBd6g2yJSFLSyhSGcDBAZ/lFKlnB
eIJqwIFUvpMbAskNxHooNz1zHzqHhOYcCSUITRk6PG8AS1HOD/aNij4sWHMzJSWU
R3ZUOEf5k6FkER3eAKxEEsJ2HtIurOVfvFXwN1e0iCKvNiQ1QdP74LddcJqsrTY6
ihXsfVbtJarM9dakuWgk3fOj79cx3BQEm82002vvNzhRRUB5Fx7v47lyB5mAcYEl
Al9gsLg4mKkVNiRh/tcelchKPp9WOKcXFEKiqom75VNwZH4oa+KSaa4GdDUQZzNs
73/Zj6gPzFBP1iLwqicvg5VJIzacKuH59WRRQr1IudTxYgWE67yz1OVicplD0WaR
l0tF9LFAdBHUy8m/
=adZ8
-----END PGP SIGNATURE-----
Merge tag 'core_guards_for_6.5_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue
Pull scope-based resource management infrastructure from Peter Zijlstra:
"These are the first few patches in the Scope-based Resource Management
series that introduce the infrastructure but not any conversions as of
yet.
Adding the infrastructure now allows multiple people to start using
them.
Of note is that Sparse will need some work since it doesn't yet
understand this attribute and might have decl-after-stmt issues"
* tag 'core_guards_for_6.5_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue:
kbuild: Drop -Wdeclaration-after-statement
locking: Introduce __cleanup() based infrastructure
apparmor: Free up __cleanup() name
dmaengine: ioat: Free up __cleanup() name
When an AFS FS.StoreData RPC call is made, amongst other things it is
given the resultant file size to be. On the server, this is processed
by truncating the file to new size and then writing the data.
Now, kafs has a lock (vnode->io_lock) that serves to serialise
operations against a specific vnode (ie. inode), but the parameters for
the op are set before the lock is taken. This allows two writebacks
(say sync and kswapd) to race - and if writes are ongoing the writeback
for a later write could occur before the writeback for an earlier one if
the latter gets interrupted.
Note that afs_writepages() cannot take i_mutex and only takes a shared
lock on vnode->validate_lock.
Also note that the server does the truncation and the write inside a
lock, so there's no problem at that end.
Fix this by moving the calculation for the proposed new i_size inside
the vnode->io_lock. Also reset the iterator (which we might have read
from) and update the mtime setting there.
Fixes: bd80d8a80e ("afs: Use ITER_XARRAY for writing")
Reported-by: Marc Dionne <marc.dionne@auristor.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Jeffrey Altman <jaltman@auristor.com>
Reviewed-by: Marc Dionne <marc.dionne@auristor.com>
cc: linux-afs@lists.infradead.org
cc: linux-fsdevel@vger.kernel.org
Link: https://lore.kernel.org/r/3526895.1687960024@warthog.procyon.org.uk/
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
MAC block on CN10K (RPM) supports hardware timestamp configuration. The
previous patch which added timestamp configuration support has a bug.
Though the netdev driver requests to disable timestamp configuration,
the driver is always enabling it.
This patch fixes the same.
Fixes: d148920868 ("octeontx2-af: cn10k: RPM hardware timestamp configuration")
Signed-off-by: Hariprasad Kelam <hkelam@marvell.com>
Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEE9zuTYTs0RXF+Ke33EVvVyTe/1WoFAmSkQkYACgkQEVvVyTe/
1Wr21A/+LLrN6fmY8wCnZqdk1i3Qlob8CpqeGEL0zV3yMVeE+d16AxI3uvm8GCAZ
RAkTWUVwiLqnv8Ua28lylvWiM4Rmr1gwxoCCd19NlHrU2Suy599dXeE530aUxpuo
PG74XR+3RHQ+tg1PJmLUiOtSqOwgBeWHaESfTyVhdNM7ywQGU4PCejxD8WAfOAuu
rzEfYsX1deQ0vidRvc/Y2XFdW91woML2FoMmyqhS52pinRJ04clIheSe8poczgQ4
xIg+GMc6XdIYW42XdEKPGE/sCEq3nFLAQZgMJDXUvt6fAHxeVhirslNKYwzBS35w
lqlUTTcf7oo0yJr2vf8Ut9yNMZPYaxsOr9UR4+23IkJj9NP8jkowwih0nc85R1yr
8eYLu3IwNlmP6azg4dHtzw5UZzJ6eabG63gNVJCyl7wqC+hkcOvt3IQDv2nklX38
oDMX9VO3IUNyl5katAjGhPYYmUXTB/YJgnbgQGu77ZVizKQHgonyFglNQb8USFwP
gHkLE3RWuTd6BaNOcKqDJSr63S6ylLPX7xfvYvrncTnoeGCcumKFhAYx3fHX3kIo
42ZyEiVq0hhmqfRH5AQgE9MhBzN7c6jmrSyQHM6GaMvmLCDRtKBVQH6Y4iC5VoJ1
JSXLFAy9aVu0DdcCdTsjgOb1t8FOyC0kFtZsdZLnDQKcZngRXoo=
=YILi
-----END PGP SIGNATURE-----
Merge tag 'ovl-update-6.5-2' of git://git.kernel.org/pub/scm/linux/kernel/git/overlayfs/vfs
Pull more overlayfs updates from Amir Goldstein:
"This is a small 'move code around' followup by Christian to his work
on porting overlayfs to the new mount api for 6.5. It makes things a
bit cleaner and simpler for the next development cycle when I hand
overlayfs back over to Miklos"
* tag 'ovl-update-6.5-2' of git://git.kernel.org/pub/scm/linux/kernel/git/overlayfs/vfs:
ovl: move all parameter handling into params.{c,h}
- Move the freeze/thaw logic from glock callback context to process /
worker thread context to prevent deadlocks.
- Fix a quota reference couting bug in do_qc().
- Carry on deallocating inodes even when gfs2_rindex_update() fails.
- Retry filesystem-internal reads when they are interruped by a signal.
- Eliminate kmap_atomic() in favor of kmap_local_page() /
memcpy_{from,to}_page().
- Get rid of noop_direct_IO.
- And a few more minor fixes and cleanups.
-----BEGIN PGP SIGNATURE-----
iQJIBAABCAAyFiEEJZs3krPW0xkhLMTc1b+f6wMTZToFAmSkEWIUHGFncnVlbmJh
QHJlZGhhdC5jb20ACgkQ1b+f6wMTZTqTSQ/+OKFnr1O1pVFP2k4CA5bGuJX4sfOt
TT045OAfy7VuE79q1Xi6HZ880kdP7fg4XUbcrwm45fEt5Q5kbbe6pjP34fCGGVSE
vLmb5BG/msb6fDLRN17S6uzyqKwFv9tGofTAtCtWTs7gmtezpBByHNHAu6duG89c
5LOhUbz3BhIOPrHUs6RB3h/OpmofVNwWCKQmfCEzYsHMzoWz1XuZJMWRb5Ho6BII
mOF0tWlEfr5gdavyWZ9UkuHqe3HI/1PfUNFVAD9S/V3kp2XPnc+HM3yP+S8df4p8
HT5VqVjH3JQL7sf6CnUXo9LP1veB+hHuvAaOyrHIKqHbIHwgxlWIIYcEYWKEGG8p
1CMjm6bI/hLQuFBUrpD1z3ppLavPZdl16Z3kCAVx8Ixl3livqMuiiZGBRdtBGdBr
RT66+SX1GurLp1EcWncqEXdJ5jgYKqVeArZKdh3thXSVaO+b8yq3IeuDRHseLnLA
egyzO3yLocvze3YFiZI4Y0V4ako9NO+2GNPd5+O9Bh9L7RepjiMCloDNpfDPQsTR
fJdW4t9vMts2eCzRASsXBUdUUV0k1Qvxdm+9BbDHFW9YvH7BQzEoi6qTZFsamdGT
NQqKdhrfiKsSEA8HFCgePYPzOGMAyH7fiaQUaXUGwkZy6AVmK+piKlJn+csNKbHQ
3dUo4upAzoeMwsA=
=GKxj
-----END PGP SIGNATURE-----
Merge tag 'gfs2-v6.4-rc5-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2
Pull gfs2 updates from Andreas Gruenbacher:
- Move the freeze/thaw logic from glock callback context to process /
worker thread context to prevent deadlocks
- Fix a quota reference couting bug in do_qc()
- Carry on deallocating inodes even when gfs2_rindex_update() fails
- Retry filesystem-internal reads when they are interruped by a signal
- Eliminate kmap_atomic() in favor of kmap_local_page() /
memcpy_{from,to}_page()
- Get rid of noop_direct_IO
- And a few more minor fixes and cleanups
* tag 'gfs2-v6.4-rc5-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2: (23 commits)
gfs2: Add quota_change type
gfs2: Use memcpy_{from,to}_page where appropriate
gfs2: Convert remaining kmap_atomic calls to kmap_local_page
gfs2: Replace deprecated kmap_atomic with kmap_local_page
gfs: Get rid of unnucessary locking in inode_go_dump
gfs2: gfs2_freeze_lock_shared cleanup
gfs2: Replace sd_freeze_state with SDF_FROZEN flag
gfs2: Rework freeze / thaw logic
gfs2: Rename SDF_{FS_FROZEN => FREEZE_INITIATOR}
gfs2: Reconfiguring frozen filesystem already rejected
gfs2: Rename gfs2_freeze_lock{ => _shared }
gfs2: Rename the {freeze,thaw}_super callbacks
gfs2: Rename remaining "transaction" glock references
gfs2: retry interrupted internal reads
gfs2: Fix possible data races in gfs2_show_options()
gfs2: Fix duplicate should_fault_in_pages() call
gfs2: set FMODE_CAN_ODIRECT instead of a dummy direct_IO method
gfs2: Don't remember delete unless it's successful
gfs2: Update rl_unlinked before releasing rgrp lock
gfs2: Fix gfs2_qa_get imbalance in gfs2_quota_hold
...
Vladimir Oltean says:
====================
dsa: Fix mangled link-local MAC DAs with SJA1105 DSA
The SJA1105 hardware tagging protocol is weird and will put DSA
information (source port, switch ID) in the MAC DA of the packets sent
to the CPU, and then send some additional (meta) packets which contain
the original bytes from the previous packet's MAC DA.
The tagging protocol driver contains logic to handle this, but the meta
frames are optional functionality, and there are configurations when
they aren't received (no PTP RX timestamping). Thus, the MAC DA from
packets sent to the stack is not correct in all cases.
Also, during testing it was found that the MAC DA patching procedure was
incorrect.
The investigation comes as a result of this discussion with Paolo:
https://lore.kernel.org/netdev/f494387c8d55d9b1d5a3e88beedeeb448f2e6cc3.camel@redhat.com/
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
incl_srcpt has the limitation, mentioned in commit b4638af888 ("net:
dsa: sja1105: always enable the INCL_SRCPT option"), that frames with a
MAC DA of 01:80:c2:xx:yy:zz will be received as 01:80:c2:00:00:zz unless
PTP RX timestamping is enabled.
The incl_srcpt option was initially unconditionally enabled, then that
changed with commit 42824463d3 ("net: dsa: sja1105: Limit use of
incl_srcpt to bridge+vlan mode"), then again with b4638af888 ("net:
dsa: sja1105: always enable the INCL_SRCPT option"). Bottom line is that
it now needs to be always enabled, otherwise the driver does not have a
reliable source of information regarding source_port and switch_id for
link-local traffic (tag_8021q VLANs may be imprecise since now they
identify an entire bridging domain when ports are not standalone).
If we accept that PTP RX timestamping (and therefore, meta frame
generation) is always enabled in hardware, then that limitation could be
avoided and packets with any MAC DA can be properly received, because
meta frames do contain the original bytes from the MAC DA of their
associated link-local packet.
This change enables meta frame generation unconditionally, which also
has the nice side effects of simplifying the switch control path
(a switch reset is no longer required on hwtstamping settings change)
and the tagger data path (it no longer needs to be informed whether to
expect meta frames or not - it always does).
Fixes: 227d07a07e ("net: dsa: sja1105: Add support for traffic through standalone ports")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The SJA1105 manual says that at offset 4 into the meta frame payload we
have "MAC destination byte 2" and at offset 5 we have "MAC destination
byte 1". These are counted from the LSB, so byte 1 is h_dest[ETH_HLEN-2]
aka h_dest[4] and byte 2 is h_dest[ETH_HLEN-3] aka h_dest[3].
The sja1105_meta_unpack() function decodes these the other way around,
so a frame with MAC DA 01:80:c2:11:22:33 is received by the network
stack as having 01:80:c2:22:11:33.
Fixes: e53e18a6fe ("net: dsa: sja1105: Receive and decode meta frames")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
strlcpy() reads the entire source buffer first.
This read may exceed the destination size limit.
This is both inefficient and can lead to linear read
overflows if a source string is not NUL-terminated [1].
In an effort to remove strlcpy() completely [2], replace
strlcpy() here with strscpy().
No return values were used, so direct replacement is safe.
[1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy
[2] https://github.com/KSPP/linux/issues/89
Signed-off-by: Azeem Shaikh <azeemshaikh38@gmail.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
PPTP uses pppox sockets (struct pppox_sock). These sockets don't embed
an inet_sock structure, so it's invalid to call inet_sk() on them.
Therefore, the ip_route_output_ports() call in pptp_connect() has two
problems:
* The tos variable is set with RT_CONN_FLAGS(sk), which calls
inet_sk() on the pppox socket.
* ip_route_output_ports() tries to retrieve routing flags using
inet_sk_flowi_flags(), which is also going to call inet_sk() on the
pppox socket.
While PPTP doesn't use inet sockets, it's actually really layered on
top of IP and therefore needs a proper way to do fib lookups. So let's
define pptp_route_output() to get a struct rtable from a pptp socket.
Let's also replace the ip_route_output_ports() call of pptp_xmit() for
consistency.
In practice, this means that:
* pptp_connect() sets ->flowi4_tos and ->flowi4_flags to zero instead
of using bits of unrelated struct pppox_sock fields.
* pptp_xmit() now respects ->sk_mark and ->sk_uid.
* pptp_xmit() now calls the security_sk_classify_flow() security
hook, thus allowing to set ->flowic_secid.
* pptp_xmit() now passes the pppox socket to xfrm_lookup_route().
Found by code inspection.
Fixes: 00959ade36 ("PPTP: PPP over IPv4 (Point-to-Point Tunneling Protocol)")
Signed-off-by: Guillaume Nault <gnault@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The mlxsw_sp_crif_alloc() function returns NULL on error. It doesn't
return error pointers. Fix the check.
Fixes: 78126cfd5d ("mlxsw: spectrum_router: Maintain CRIF for fallback loopback RIF")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
- Add missing __init annotation to one function in the intel_idle
drvier (Rafael Wysocki).
- Make intel_pstate use a correct scaling factor when mapping HWP
performance levels to frequency values on hybrid-capable systems
with disabled E-cores (Srinivas Pandruvada).
- Fix Kconfig dependencies of the cpufreq-dt-platform driver (Viresh
Kumar).
- Add support to build cpufreq-dt-platdev as a module (Zhipeng Wang).
- Don't allocate Sparc's cpufreq_driver dynamically (Viresh Kumar).
- Add support for TI's AM62A7 platform (Vibhore Vardhan).
- Add support for Armada's ap807 platform (Russell King (Oracle)).
- Add support for StarFive JH7110 SoC (Mason Huo).
- Fix voltage selection for Mediatek Socs (Daniel Golle).
- Fix error handling in Tegra's cpufreq driver (Christophe JAILLET).
- Document Qualcomm's IPQ8074 in DT bindings (Robert Marko).
- Don't warn for disabling a non-existing frequency for imx6q cpufreq
driver (Christoph Niedermaier).
- Use dev_err_probe() in Qualcomm's cpufreq driver (Andrew Halaney).
- Simplify performance state related logic in the OPP core (Viresh
Kumar).
- Fix use-after-free and improve locking around lazy_opp_tables (Viresh
Kumar, Stephan Gerhold).
- Minor cleanups - using dev_err_probe() and rate-limiting debug
messages (Andrew Halaney, Adrián Larumbe).
-----BEGIN PGP SIGNATURE-----
iQJGBAABCAAwFiEE4fcc61cGeeHD/fCwgsRv/nhiVHEFAmSkTGwSHHJqd0Byand5
c29ja2kubmV0AAoJEILEb/54YlRxbxAQAJ92EqcE2n2Eyts6KU7n3sKu8jEIiNPV
3bdFgTfjsc26Sm+ppiISRkk0CCNcyljCM4I5wRtEe4+hfTszAdrFd2SNYUHjHCZl
xIz9MVtZlh3ODm2d8ClFvQEL3So+oO6UG5V5IS27/34sfgQAS+77AWtjdh/j8d+0
ZM4jikbR87eACmpmgAjp17LIH2qdKx4Sri5VUZSNVde4es/m306gkhT5hZFDrRai
S+s/Mxfp4sxSNNiZC6nXp10bvU/cT7ZWsOcaaOltZmt/Y9yWiLFEmNKjR3ljvzOA
H6EPMcfhdBUiIhdMpjqMttVNOOgaU2ma/JKQF5JLDkFCnT/BGVi3HsvA8uT8tIgA
doSZ0+ODQ7ar/v55Rv9ENwshfb5oaPDV729EhQyCrNCc77yvjwA1sXoeDEuS2GXa
sYXHIsuAs/aNzUdIQZ2G5pjG0zs3xu6oMODfbYoPGg3tj9ITT6TqxnBkjBhsfTKl
bv0bqh/nMPVcLZaOEXvM538XiEfKmGz9wWH5d8WydyDkCGTG97m/bQaZOlEry7RY
R70vPOi8ArVRwJlmW5Gl8NENy2DsCMj+BXmxMU2EwhwL1KLvDWQ+Qf6MFU7o0iym
W/5RQGbbH/clVJL+zXSTsqmfMJanrIM4DY2wKaRz0o2xxiOh/cNRuzm0ZjfAmbml
MjEhdmcNX76P
=7lBb
-----END PGP SIGNATURE-----
Merge tag 'pm-6.5-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull more power management updates from Rafael Wysocki:
"These add support for new hardware (ap807 and AM62A7), fix several
issues in cpufreq drivers and in the operating performance points
(OPP) framework, fix up intel_idle after recent changes and add
documentation.
Specifics:
- Add missing __init annotation to one function in the intel_idle
drvier (Rafael Wysocki)
- Make intel_pstate use a correct scaling factor when mapping HWP
performance levels to frequency values on hybrid-capable systems
with disabled E-cores (Srinivas Pandruvada)
- Fix Kconfig dependencies of the cpufreq-dt-platform driver (Viresh
Kumar)
- Add support to build cpufreq-dt-platdev as a module (Zhipeng Wang)
- Don't allocate Sparc's cpufreq_driver dynamically (Viresh Kumar)
- Add support for TI's AM62A7 platform (Vibhore Vardhan)
- Add support for Armada's ap807 platform (Russell King (Oracle))
- Add support for StarFive JH7110 SoC (Mason Huo)
- Fix voltage selection for Mediatek Socs (Daniel Golle)
- Fix error handling in Tegra's cpufreq driver (Christophe JAILLET)
- Document Qualcomm's IPQ8074 in DT bindings (Robert Marko)
- Don't warn for disabling a non-existing frequency for imx6q cpufreq
driver (Christoph Niedermaier)
- Use dev_err_probe() in Qualcomm's cpufreq driver (Andrew Halaney)
- Simplify performance state related logic in the OPP core (Viresh
Kumar)
- Fix use-after-free and improve locking around lazy_opp_tables
(Viresh Kumar, Stephan Gerhold)
- Minor cleanups - using dev_err_probe() and rate-limiting debug
messages (Andrew Halaney, Adrián Larumbe)"
* tag 'pm-6.5-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (23 commits)
cpufreq: intel_pstate: Fix scaling for hybrid-capable systems with disabled E-cores
cpufreq: Make CONFIG_CPUFREQ_DT_PLATDEV depend on OF
intel_idle: Add __init annotation to matchup_vm_state_with_baremetal()
OPP: Properly propagate error along when failing to get icc_path
OPP: Use dev_err_probe() when failing to get icc_path
cpufreq: qcom-cpufreq-hw: Use dev_err_probe() when failing to get icc paths
cpufreq: mediatek: correct voltages for MT7622 and MT7623
cpufreq: armada-8k: add ap807 support
OPP: Simplify the over-designed pstate <-> level dance
OPP: pstate is only valid for genpd OPP tables
OPP: don't drop performance constraint on OPP table removal
OPP: Protect `lazy_opp_tables` list with `opp_table_lock`
OPP: Staticize `lazy_opp_tables` in of.c
cpufreq: dt-platdev: Support building as module
opp: Fix use-after-free in lazy_opp_tables after probe deferral
dt-bindings: cpufreq: qcom-cpufreq-nvmem: document IPQ8074
cpufreq: dt-platdev: Blacklist ti,am62a7 SoC
cpufreq: ti-cpufreq: Add support for AM62A7
OPP: rate-limit debug messages when no change in OPP is required
cpufreq: imx6q: don't warn for disabling a non-existing frequency
...
driver updates needed more time to bake in linux-next.
Updates:
- Support for more clk controllers in Qualcomm SoCs such as SM8350,
SM8450, SDX75, SC8280XP, and IPQ9574
- Runtime PM enablement of some more Qualcomm clk controllers
- Various fixes to Qualcomm clk driver data to use correct clk_ops
and to check halt bits properly
- AT91 updates to modernize with clk_parent_data structures
Fixes:
- Remove "syscon" from dt binding fix for ti,j721e-system-controller
- Fix determine rate in the Tegra driver that got wrecked by the
refactorting of muxes this merge window
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEE9L57QeeUxqYDyoaDrQKIl8bklSUFAmSkRq8RHHNib3lkQGtl
cm5lbC5vcmcACgkQrQKIl8bklSUgHBAAkXU0agruD22fecxI/RliNIwyRY4F8CNW
aKuz5XSGLTZAgaBDjFHPb2VSph9NXbFsLxxmxdrf7bDCAw6ww90vK0G9+JS/b/9D
fGhqvl+d8oFeFAislr7eSDhKCMlKd5I+v6mUUk0WrPqKddHtIvq2Wh8j7+j9OZmh
2lov68N95xYTKQPs4+mb0geDktCnFKJsIt2z9DnyPi5ixS5d6qJARXmOruJt7mbq
1bd9iJLmOZPWm703hJcreLgyo9zhTxLY+BUrHM4S8J72BTFHN/OyLyKai25mSXll
Odw4/G42VuykV03kvyAZNS2ebhw1DJ+px9jrfU5FH6TqIgfZG2tBnP0RkPbamNcA
Y9ZBNtaJMfIk/Nqg5q8cyO72y2sfc2QUNt2qn0i02BxOSfSLLxQDuKiWPbilC7ju
9zYDGIZUhZWLpfK3a+QWAU0VNGak+sq/ZbAQijI8q8MriilwhonQsXQerQC0Jzcw
zKdMoVPCedK411UZh9fMmIBwEsAFEtYo/qDynpv+w0zwkpDY2t5Sh7lGlQFOiynZ
YVFbUD7EEf3GJmftdEWTHQpEd+GlkWRoGHO3L9hfyxxUANXQGXhpI4YvpfldntmK
UlGguQwRqqDzdCm+tBiFlt+j4Vh5A8ywTSG8HLzxy7Gsu7BRkqcafRrlxNmMK8Wv
aCixlFKAkdA=
=cF5c
-----END PGP SIGNATURE-----
Merge tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
Pull more clk updates from Stephen Boyd:
"Another set of clk driver updates and fixes for the merge window. The
driver updates needed more time to bake in linux-next.
Updates:
- Support for more clk controllers in Qualcomm SoCs such as SM8350,
SM8450, SDX75, SC8280XP, and IPQ9574
- Runtime PM enablement of some more Qualcomm clk controllers
- Various fixes to Qualcomm clk driver data to use correct clk_ops
and to check halt bits properly
- AT91 updates to modernize with clk_parent_data structures
Fixes:
- Remove 'syscon' from dt binding fix for ti,j721e-system-controller
- Fix determine rate in the Tegra driver that got wrecked by the
refactorting of muxes this merge window"
* tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: (69 commits)
clk: tegra: Avoid calling an uninitialized function
dt-bindings: mfd: ti,j721e-system-controller: Remove syscon from example
clk: at91: sama7g5: s/ep_chg_chg_id/ep_chg_id
clk: at91: sama7g5: switch to parent_hw and parent_data
clk: at91: sckc: switch to parent_data/parent_hw
clk: at91: clk-sam9x60-pll: add support for parent_hw
clk: at91: clk-utmi: add support for parent_hw
clk: at91: clk-system: add support for parent_hw
clk: at91: clk-programmable: add support for parent_hw
clk: at91: clk-peripheral: add support for parent_hw
clk: at91: clk-master: add support for parent_hw
clk: at91: clk-generated: add support for parent_hw
clk: at91: clk-main: add support for parent_data/parent_hw
clk: qcom: gcc-sc8280xp: Add runtime PM
clk: qcom: gpucc-sc8280xp: Add runtime PM
clk: qcom: mmcc-msm8974: fix MDSS_GDSC power flags
clk: qcom: gpucc-sm6375: Enable runtime pm
dt-bindings: clock: sm6375-gpucc: Add VDD_GX
clk: qcom: gcc-sm6115: Add missing PLL config properties
clk: qcom: clk-alpha-pll: Add a way to update some bits of test_ctl(_hi)
...
The updates consist of three parts; UAPI update, OHCI driver update, and
several bug fixes.
Firstly, the 1394 OHCI specification defines method to retrieve hardware
time stamps for asynchronous communication, which was previously
unavailable in user space. This change adds new events to the UAPI,
allowing applications to retrieve the time when asynchronous packet are
received and sent. The new events are tested in the breeding edge of
libhinawa and look to work well. The new version of libhinawa will be
released after current merge window is closed.
* https://git.kernel.org/pub/scm/libs/ieee1394/libhinawa.git/
Secondly, the FireWire stack includes a PCM device driver for 1394 OHCI
hardware, This change modernizes the driver by managed resource (devres)
framework.
Lastly, the rest of change is bug fixes for firewire-net and firewire-core.
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQQE66IEYNDXNBPeGKSsLtaWM8LwEwUCZKQI3wAKCRCsLtaWM8Lw
ExxhAP9rgLdnERNyL0Pw5PoNM71KBXVLYn35UasDZiyraq5UHQEAmptFKIXCwPLY
/kw3oumcKTEbYCiiI94JAesfFX/fRw0=
=LT8K
-----END PGP SIGNATURE-----
Merge tag 'firewire-6.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394
Pull firewire updates from Takashi Sakamoto:
"This consist of three parts; UAPI update, OHCI driver update, and
several bug fixes.
Firstly, the 1394 OHCI specification defines method to retrieve
hardware time stamps for asynchronous communication, which was
previously unavailable in user space. This adds new events to the
UAPI, allowing applications to retrieve the time when asynchronous
packet are received and sent. The new events are tested in the
bleeding edge of libhinawa and look to work well. The new version of
libhinawa will be released after current merge window is closed:
https://git.kernel.org/pub/scm/libs/ieee1394/libhinawa.git/
Secondly, the FireWire stack includes a PCM device driver for 1394
OHCI hardware, This change modernizes the driver by managed resource
(devres) framework.
Lastly, bug fixes for firewire-net and firewire-core"
* tag 'firewire-6.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394: (25 commits)
firewire: net: fix use after free in fwnet_finish_incoming_packet()
firewire: core: obsolete usage of GFP_ATOMIC at building node tree
firewire: ohci: release buffer for AR req/resp contexts when managed resource is released
firewire: ohci: use devres for content of configuration ROM
firewire: ohci: use devres for IT, IR, AT/receive, and AT/request contexts
firewire: ohci: use devres for list of isochronous contexts
firewire: ohci: use devres for requested IRQ
firewire: ohci: use devres for misc DMA buffer
firewire: ohci: use devres for MMIO region mapping
firewire: ohci: use devres for PCI-related resources
firewire: ohci: use devres for memory object of ohci structure
firewire: fix warnings to generate UAPI documentation
firewire: fix build failure due to missing module license
firewire: cdev: implement new event relevant to phy packet with time stamp
firewire: cdev: add new event to notify phy packet with time stamp
firewire: cdev: code refactoring to dispatch event for phy packet
firewire: cdev: implement new event to notify response subaction with time stamp
firewire: cdev: add new event to notify response subaction with time stamp
firewire: cdev: code refactoring to operate event of response
firewire: core: implement variations to send request and wait for response with time stamp
...
Instead of doing two pass parsing of the table, replace
acpi_match_device_ids() with acpi_match_acpi_device().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
There are at least two places in the kernel that are using
the SMB0001 HID. Make it to be available via acpi_drivers.h
header file. While at it, replace hard coded one with a
definition.
Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
Acked-by: Wolfram Sang <wsa@kernel.org> # for I2C
Link: https://lore.kernel.org/r/20230621151652.79579-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
After switching i2c-scmi driver to be a platform one, it stopped
being enumerated on number of Kontron platforms, because it's
listed in the forbidden_id_list.
To resolve the situation, add a flag to driver data to allow devices
with no resources in _CRS to be enumerated via platform bus.
Fixes: 03d4287add ("i2c: scmi: Convert to be a platform driver")
Closes: https://lore.kernel.org/r/60c1756765b9a3f1eab0dcbd84f59f00fe1caf48.camel@kontron.com
Link: https://lore.kernel.org/r/20230621151652.79579-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
[ rjw: Move has_resource definition to the block in which it is used and
initialize it to 'false' ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Match the ACPI device against a given list of ACPI IDs.
Subsequent changes will make use of this.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
[ rjw: Changelog edit ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Vegard Nossum pointed out two different problems with the error handling
in init_module_from_file():
(a) the idempotent loading code didn't clean up properly in some error
cases, leaving the on-stack 'struct idempotent' element still in
the hash table
(b) failure to read the module file would nonsensically update the
'invalid_kread_bytes' stat counter with the error value
The first error is quite nasty, in that it can then cause subsequent
idempotent loads of that same file to access stale stack contents of the
previous failure. The case may not happen in any normal situation
(explaining all the "Tested-by's on the original change), and requires
admin privileges, but syzkaller triggers random bad behavior as a
result:
BUG: soft lockup in sys_finit_module
BUG: unable to handle kernel paging request in init_module_from_file
general protection fault in init_module_from_file
INFO: task hung in init_module_from_file
KASAN: out-of-bounds Read in init_module_from_file
KASAN: slab-out-of-bounds Read in init_module_from_file
...
The second error is fairly benign and just leads to nonsensical stats
(and has been around since the debug stats were added).
Vegard also provided a patch for the idempotent loading issue, but I'd
rather re-organize the code and make it more legible using another level
of helper functions than add the usual "goto out" error handling.
Link: https://lore.kernel.org/lkml/20230704100852.23452-1-vegard.nossum@oracle.com/
Fixes: 9b9879fc03 ("modules: catch concurrent module loads, treat them as idempotent")
Reported-by: Vegard Nossum <vegard.nossum@oracle.com>
Reported-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Reported-by: syzbot+9c2bdc9d24e4a7abe741@syzkaller.appspotmail.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
There are two pieces of data being exported from drivers/acpi/scan.c
(acpi_device_lock and acpi_wakeup_device_list) that don't have their
definitions declared in anything scan.c is including.
Fix the following sparse warnings by including sleep.h to add the
declarations of acpi_device_lock and acpi_wakeup_device_list to
fix the followng sparse warnings:
drivers/acpi/scan.c:42:1: warning: symbol 'acpi_device_lock' was not declared. Should it be static?
drivers/acpi/scan.c:43:1: warning: symbol 'acpi_wakeup_device_list' was not declared. Should it be static?
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Merge CPU power management updates for 6.5-rc1:
- Add missing __init annotation to one function in the intel_idle
drvier (Rafael Wysocki).
- Make intel_pstate use a correct scaling factor when mapping HWP
performance levels to frequency values on hybrid-capable systems
with disabled E-cores (Srinivas Pandruvada).
- Fix Kconfig dependencies of the cpufreq-dt-platform driver (Viresh
Kumar).
- Add support to build cpufreq-dt-platdev as a module (Zhipeng Wang).
- Don't allocate Sparc's cpufreq_driver dynamically (Viresh Kumar).
- Add support for TI's AM62A7 platform (Vibhore Vardhan).
- Add support for Armada's ap807 platform (Russell King (Oracle)).
- Add support for StarFive JH7110 SoC (Mason Huo).
- Fix voltage selection for Mediatek Socs (Daniel Golle).
- Fix error handling in Tegra's cpufreq driver (Christophe JAILLET).
- Document Qualcomm's IPQ8074 in DT bindings (Robert Marko).
- Don't warn for disabling a non-existing frequency for imx6q cpufreq
driver (Christoph Niedermaier).
- Use dev_err_probe() in Qualcomm's cpufreq driver (Andrew Halaney).
* pm-cpufreq:
cpufreq: intel_pstate: Fix scaling for hybrid-capable systems with disabled E-cores
cpufreq: Make CONFIG_CPUFREQ_DT_PLATDEV depend on OF
cpufreq: qcom-cpufreq-hw: Use dev_err_probe() when failing to get icc paths
cpufreq: mediatek: correct voltages for MT7622 and MT7623
cpufreq: armada-8k: add ap807 support
cpufreq: dt-platdev: Support building as module
dt-bindings: cpufreq: qcom-cpufreq-nvmem: document IPQ8074
cpufreq: dt-platdev: Blacklist ti,am62a7 SoC
cpufreq: ti-cpufreq: Add support for AM62A7
cpufreq: imx6q: don't warn for disabling a non-existing frequency
cpufreq: sparc: Don't allocate cpufreq_driver dynamically
cpufreq: tegra194: Fix an error handling path in tegra194_cpufreq_probe()
cpufreq: dt-platdev: Add JH7110 SOC to the allowlist
* pm-cpuidle:
intel_idle: Add __init annotation to matchup_vm_state_with_baremetal()
As of commit 2ac8743437 ("RISC-V: split early & late of_node to
hartid mapping") my CI complains about newly added pr_err() messages
during boot, for example:
[ 0.000000] Couldn't find cpu id for hartid [0]
[ 0.000000] riscv-intc: unable to find hart id for /cpus/cpu@0/interrupt-controller
Before the split, riscv_of_processor_hartid() contained a check for
whether the cpu was "available", before calling riscv_hartid_to_cpuid(),
but after the split riscv_of_processor_hartid() can be called for cpus
that are disabled.
Most callers of riscv_hartid_to_cpuid() already report custom errors
where it falls, making this print superfluous in those case. In other
places, the print adds nothing - see riscv_intc_init() for example.
Fixes: 2ac8743437 ("RISC-V: split early & late of_node to hartid mapping")
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20230629-paternity-grafted-b901b76d04a0@wendy
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
The RISC-V vector specification states:
Executing a system call causes all caller-saved vector registers
(v0-v31, vl, vtype) and vstart to become unspecified.
The vector registers are set to all 1s, vill is set (invalid), and the
vector status is set to Dirty.
That way we can prevent userspace from accidentally relying on the
stated save.
Rémi pointed out [1] that writing to the registers might be
superfluous, and setting vill is sufficient.
Link: https://lore.kernel.org/linux-riscv/12784326.9UPPK3MAeB@basile.remlab.net/ # [1]
Suggested-by: Darius Rad <darius@bluespec.com>
Suggested-by: Palmer Dabbelt <palmer@rivosinc.com>
Suggested-by: Rémi Denis-Courmont <remi@remlab.net>
Signed-off-by: Björn Töpel <bjorn@rivosinc.com>
Link: https://lore.kernel.org/r/20230629142228.1125715-1-bjorn@kernel.org
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
Masahiro Yamada