| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Since commit 2d47c6956ab3 ("ubsan: Tighten UBSAN_BOUNDS on GCC"),
UBSAN_BOUNDS no longer pretends 1-element arrays are unbounded. Walking
bmSublinkSpeedAttr will trigger a warning, so make it a proper flexible
array. Add a union to keep the struct size identical for userspace in
case anything was depending on the old size.
False positive warning was:
UBSAN: array-index-out-of-bounds in drivers/usb/host/xhci-hub.c:231:31 index 1 is out of range for type '__le32 [1]'
for this line of code:
ssp_cap->bmSublinkSpeedAttr[offset++] = cpu_to_le32(attr);
Reported-by: Borislav Petkov <[email protected]>
Closes: https://lore.kernel.org/lkml/2023062945-fencing-pebble-0411@gregkh/
Reported-by: Mirsad Todorovac <[email protected]>
Closes: https://lore.kernel.org/lkml/[email protected]/
Cc: Greg Kroah-Hartman <[email protected]>
Cc: "Gustavo A. R. Silva" <[email protected]>
Tested-by: "Borislav Petkov (AMD)" <[email protected]>
Tested-by: Mirsad Todorovac <[email protected]>
Reviewed-by: "Gustavo A. R. Silva" <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Kees Cook <[email protected]>
|
|
Pull more xfs updates from Darrick Wong:
- Fix some ordering problems with log items during log recovery
- Don't deadlock the system by trying to flush busy freed extents while
holding on to busy freed extents
- Improve validation of log geometry parameters when reading the
primary superblock
- Validate the length field in the AGF header
- Fix recordset filtering bugs when re-calling GETFSMAP to return more
results when the resultset didn't previously fit in the caller's
buffer
- Fix integer overflows in GETFSMAP when working with rt volumes larger
than 2^32 fsblocks
- Fix GETFSMAP reporting the undefined space beyond the last rtextent
- Fix filtering bugs in GETFSMAP's log device backend if the log ever
becomes longer than 2^32 fsblocks
- Improve validation of file offsets in the GETFSMAP range parameters
- Fix an off by one bug in the pmem media failure notification
computation
- Validate the length field in the AGI header too
* tag 'xfs-6.5-merge-5' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
xfs: Remove unneeded semicolon
xfs: AGI length should be bounds checked
xfs: fix the calculation for "end" and "length"
xfs: fix xfs_btree_query_range callers to initialize btree rec fully
xfs: validate fsmap offsets specified in the query keys
xfs: fix logdev fsmap query result filtering
xfs: clean up the rtbitmap fsmap backend
xfs: fix getfsmap reporting past the last rt extent
xfs: fix integer overflows in the fsmap rtbitmap and logdev backends
xfs: fix interval filtering in multi-step fsmap queries
xfs: fix bounds check in xfs_defer_agfl_block()
xfs: AGF length has never been bounds checked
xfs: journal geometry is not properly bounds checked
xfs: don't block in busy flushing when freeing extents
xfs: allow extent free intents to be retried
xfs: pass alloc flags through to xfs_extent_busy_flush()
xfs: use deferred frees for btree block freeing
xfs: don't reverse order of items in bulk AIL insertion
xfs: remove redundant initializations of pointers drop_leaf and save_leaf
|
|
The IXP4XX_EXP_T1_MASK was shifted one bit to the right, overlapping
IXP4XX_EXP_T2_MASK and leaving bit 29 unused. The offset being wrong is
also confirmed at least by the datasheet of IXP45X/46X [1].
Fix this by aligning it to IXP4XX_EXP_T1_SHIFT.
[1] https://www.intel.com/content/dam/www/public/us/en/documents/manuals/ixp45x-ixp46x-developers-manual.pdf
Cc: [email protected]
Fixes: 1c953bda90ca ("bus: ixp4xx: Add a driver for IXP4xx expansion bus")
Signed-off-by: Jonas Gorski <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Arnd Bergmann <[email protected]>
|
|
Add missing whitespace between node name/label and opening {.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Arnd Bergmann <[email protected]>
|
|
Randy reported build errors in linux-next where XIP_KERNEL was enabled.
ARCH_THEAD requires alternatives to support the non-standard ISA
extensions used by the THEAD cores, which are mutually exclusive with
XIP kernels. Clone the dependency list from the Allwinner entry, since
Allwinner's D1 uses T-Head cores with the same non-standard extensions.
Reported-by: Randy Dunlap <[email protected]>
Reviewed-by: Randy Dunlap <[email protected]>
Tested-by: Randy Dunlap <[email protected]> # build-tested
Link: https://lore.kernel.org/all/[email protected]/
Fixes: da47ce003963 ("riscv: Add the T-HEAD SoC family Kconfig option")
Reviewed-by: Palmer Dabbelt <[email protected]>
Acked-by: Palmer Dabbelt <[email protected]>
Signed-off-by: Conor Dooley <[email protected]>
Link: https://lore.kernel.org/r/20230628-left-attractor-94b7bd5fbb83@wendy
Signed-off-by: Arnd Bergmann <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm
Pull pwm updates from Thierry Reding:
"There's a little bit of everything in here: we've got various
improvements and cleanups to drivers, some fixes across the board and
a bit of new hardware support"
* tag 'pwm/for-6.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (22 commits)
dt-bindings: pwm: convert pwm-bcm2835 bindings to YAML
pwm: Add Renesas RZ/G2L MTU3a PWM driver
pwm: mtk_disp: Fix the disable flow of disp_pwm
dt-bindings: pwm: restrict node name suffixes
pwm: pca9685: Switch i2c driver back to use .probe()
pwm: ab8500: Fix error code in probe()
MAINTAINERS: add pwm to PolarFire SoC entry
pwm: add microchip soft ip corePWM driver
pwm: sysfs: Do not apply state to already disabled PWMs
pwm: imx-tpm: force 'real_period' to be zero in suspend
pwm: meson: make full use of common clock framework
pwm: meson: don't use hdmi/video clock as mux parent
pwm: meson: switch to using struct clk_parent_data for mux parents
pwm: meson: remove not needed check in meson_pwm_calc
pwm: meson: fix handling of period/duty if greater than UINT_MAX
pwm: meson: modify and simplify calculation in meson_pwm_get_state
dt-bindings: pwm: Add R-Car V3U device tree bindings
dt-bindings: pwm: imx: add i.MX8QXP compatible
pwm: mediatek: Add support for MT7981
dt-bindings: pwm: mediatek: Add mediatek,mt7981 compatible
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux
Pull more devicetree updates from Rob Herring:
- Whitespace clean-ups in binding examples
- Restrict node name suffixes to "-[0-9]+" for cases of multiple
instances which don't have unit-addresses
- Convert brcm,kona-wdt and cdns,wdt-r1p2 watchdog bindings to DT
schema
* tag 'devicetree-for-6.5-2' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux:
dt-bindings: soc: qcom: stats: Update maintainer email
dt-bindings: cleanup DTS example whitespaces
dt-bindings: timestamp: restrict node name suffixes
dt-bindings: slimbus: restrict node name suffixes
dt-bindings: watchdog: restrict node name suffixes
dt-bindings: watchdog: brcm,kona-wdt: convert txt file to yaml
dt-bindings: watchdog: cdns,wdt-r1p2: Convert cadence watchdog to yaml
|
|
supported.
Arm has multiple PMU types for heterogeneous systems, but doesn't
currently support PERF_PMU_CAP_EXTENDED_HW_TYPE. Make the tests
support both scenarios so that they pass on Arm, and will still pass
once PERF_PMU_CAP_EXTENDED_HW_TYPE support is added.
Fixes: 27c9fcfc1e14 ("perf test: Update parse-events expectations to test for multiple events")
Acked-by: Ian Rogers <[email protected]>
Signed-off-by: James Clark <[email protected]>
Cc: Mark Rutland <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Adrian Hunter <[email protected]>
Cc: Arnaldo Carvalho de Melo <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: Ingo Molnar <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Namhyung Kim <[email protected]>
|
|
The test looks for a PMU from sysfs with type = PERF_TYPE_RAW when
opening a raw event. Arm doesn't have a real raw PMU, only core PMUs
with unique types other than raw.
Instead of looking for a matching PMU, just test that the event type
was parsed as raw and skip the PMU search on Arm. The raw event type
test should also apply to all platforms so add it outside of the ifdef.
Fixes: aefde50a446b ("perf test: Fix parse-events tests for >1 core PMU")
Acked-by: Ian Rogers <[email protected]>
Signed-off-by: James Clark <[email protected]>
Cc: Mark Rutland <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Adrian Hunter <[email protected]>
Cc: Arnaldo Carvalho de Melo <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: Ingo Molnar <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Namhyung Kim <[email protected]>
|
|
When moving devices from one namespace to another, mc addresses are
cleaned in software while not removed from application firmware. Thus
the mc addresses are remained and will cause resource leak.
Now use `__dev_mc_unsync` to clean mc addresses when closing port.
Fixes: e20aa071cd95 ("nfp: fix schedule in atomic context when sync mc address")
Cc: [email protected]
Signed-off-by: Yinjun Zhang <[email protected]>
Acked-by: Simon Horman <[email protected]>
Signed-off-by: Louis Peens <[email protected]>
Reviewed-by: Jacob Keller <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf
Daniel Borkmann says:
====================
pull-request: bpf 2023-07-05
We've added 2 non-merge commits during the last 1 day(s) which contain
a total of 3 files changed, 16 insertions(+), 4 deletions(-).
The main changes are:
1) Fix BTF to warn but not returning an error for a NULL BTF to still be
able to load modules under CONFIG_DEBUG_INFO_BTF, from SeongJae Park.
2) Fix xsk sockets to honor SO_BINDTODEVICE in bind(), from Ilya Maximets.
* tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf:
xsk: Honor SO_BINDTODEVICE on bind
bpf, btf: Warn but return no error for NULL btf from __register_btf_kfunc_id_set()
====================
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire
Pull soundwire updates from Vinod Koul:
- Stream handling and slave alert handling
- Qualcomm Soundwire v2.0.0 controller support
- Intel ACE2.x initial support and code reorganization
* tag 'soundwire-6.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire: (55 commits)
soundwire: stream: Make master_list ordered to prevent deadlocks
soundwire: bus: Prevent lockdep asserts when stream has multiple buses
soundwire: qcom: fix storing port config out-of-bounds
soundwire: intel_ace2x: fix SND_SOC_SOF_HDA_MLINK dependency
soundwire: debugfs: Add missing SCP registers
soundwire: stream: Remove unnecessary gotos
soundwire: stream: Invert logic on runtime alloc flags
soundwire: stream: Remove unneeded checks for NULL bus
soundwire: bandwidth allocation: Remove pointless variable
soundwire: cadence: revisit parity injection
soundwire: intel/cadence: update hardware reset sequence
soundwire: intel_bus_common: enable interrupts last
soundwire: intel_bus_common: update error log
soundwire: amd: Improve error message in remove callback
soundwire: debugfs: fix unbalanced pm_runtime_put()
soundwire: qcom: fix unbalanced pm_runtime_put()
soundwire: qcom: set clk stop need reset flag at runtime
soundwire: qcom: add software workaround for bus clash interrupt assertion
soundwire: qcom: wait for fifo to be empty before suspend
soundwire: qcom: drop unused struct qcom_swrm_ctrl members
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
Pull media updates from Mauro Carvalho Chehab:
- Lots of improvement at atomisp driver, which is starting to look in
good shape
- Mediatek vcodec driver has gained support for av1 and hevc stateless
codecs
- New sensor driver: ov01a10
- verisilicon driver has gained AV1 entropy helpers
- tegra-video has gained support for Tegra20 parallel input
- dvb core has gained an extra property to better support DVB-S2X
- as usual, lots of cleanups, fixes and improvements on media drivers
* tag 'media/v6.5-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (253 commits)
media: wl128x: fix a clang warning
media: dvb: mb86a20s: get rid of a clang-15 warning
media: cec: i2c: ch7322: also select REGMAP
media: add HAS_IOPORT dependencies
media: tc358746: select CONFIG_GENERIC_PHY
media: mediatek: vcodec: Add dbgfs help function
media: mediatek: vcodec: Add encode to support dbgfs
media: mediatek: vcodec: Change dbgfs interface to support encode
media: mediatek: vcodec: Get each instance format type
media: mediatek: vcodec: Get each context resolution information
media: mediatek: vcodec: Add a debugfs file to get different useful information
media: mediatek: vcodec: Add debug params to control different log level
media: mediatek: vcodec: Add debugfs interface to get debug information
media: mediatek: vcodec: support stateless AV1 decoder
media: verisilicon: Conditionally ignore native formats
media: verisilicon: Enable AV1 decoder on rk3588
media: verisilicon: Add film grain feature to AV1 driver
media: verisilicon: Add Rockchip AV1 decoder
media: verisilicon: Add AV1 entropy helpers
media: verisilicon: Compute motion vectors size for AV1 frames
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace
Pull tracing tooling updates from Steven Rostedt:
- Add cgroup support for rtla via the -C option
- Add --house-keeping option that tells rtla where to place the
housekeeping threads
- Have rtla/timerlat have its own tracing instance instead of using the
top level tracing instance that is the default for other tracing
users to use
- Add auto analysis to timerlat_hist
- Have rtla start the tracers after creating the instances
- Reduce rtla hwnoise down to 75% from 100% as it runs with preemption
disabled and can cause system instability at 100%
- Add support to run timerlat_top and timerlat_hist threads in
user-space instead of just using the kernel tasks
- Some minor clean ups and documentation changes
* tag 'trace-tools-v6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
Documentation: Add tools/rtla timerlat -u option documentation
rtla/timerlat_hist: Add timerlat user-space support
rtla/timerlat_top: Add timerlat user-space support
rtla/hwnoise: Reduce runtime to 75%
rtla: Start the tracers after creating all instances
rtla/timerlat_hist: Add auto-analysis support
rtla/timerlat: Give timerlat auto analysis its own instance
rtla: Automatically move rtla to a house-keeping cpu
rtla: Change monitored_cpus from char * to cpu_set_t
rtla: Add --house-keeping option
rtla: Add -C cgroup support
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux
Pull more parisc architecture updates from Helge Deller:
- Fix all compiler warnings in arch/parisc and drivers/parisc when
compiled with W=1
* tag 'parisc-for-6.5-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
parisc: syscalls: Avoid compiler warnings with W=1
parisc: math-emu: Avoid compiler warnings with W=1
parisc: Raise minimal GCC version to 12.0.0
parisc: unwind: Avoid missing prototype warning for handle_interruption()
parisc: smp: Add declaration for start_cpu_itimer()
parisc: pdt: Get prototype for arch_report_meminfo()
|
|
The unxlate_dev_mem_ptr() function has no prototype on the sh architecture
which does not include asm-generic/io.h. This results in the following
build failure:
drivers/char/mem.c: In function 'read_mem':
drivers/char/mem.c:164:25: error: implicit declaration of function 'unxlate_dev_mem_ptr'
This compile error is now seen because commit 99b619b37ae1 ("mips: provide
unxlate_dev_mem_ptr() in asm/io.h") removed the weak function which was
previously in place to handle this problem.
Add a trivial macro to the sh header to provide the now missing dummy
function.
Fixes: 99b619b37ae1 ("mips: provide unxlate_dev_mem_ptr() in asm/io.h")
Cc: Arnd Bergmann <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Reviewed-by: John Paul Adrian Glaubitz <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: John Paul Adrian Glaubitz <[email protected]>
|
|
According to the hardware manual [1], the DMAC found in the SH7709 SoC
features only 4 channels. While at it, also sort the existing targets.
[1] https://www.renesas.com/us/en/document/mah/sh7709s-group-hardware-manual (p. 373)
Signed-off-by: Artur Rojek <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: John Paul Adrian Glaubitz <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: John Paul Adrian Glaubitz <[email protected]>
|
|
None of the supported SH4 family SoCs features a second DMAC module. As
this definition negatively impacts DMA channel calculation for the above
targets, remove it from the code.
Signed-off-by: Artur Rojek <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: John Paul Adrian Glaubitz <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: John Paul Adrian Glaubitz <[email protected]>
|
|
Various SoCs of the SH3, SH4 and SH4A family, which use this driver,
feature a differing number of DMA channels, which can be distributed
between up to two DMAC modules. The existing implementation fails to
correctly accommodate for all those variations, resulting in wrong
channel offset calculations and leading to kernel panics.
Rewrite dma_base_addr() in order to properly calculate channel offsets
in a DMAC module. Fix dmaor_read_reg() and dmaor_write_reg(), so that
the correct DMAC module base is selected for the DMAOR register.
Fixes: 7f47c7189b3e8f19 ("sh: dma: More legacy cpu dma chainsawing.")
Signed-off-by: Artur Rojek <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: John Paul Adrian Glaubitz <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: John Paul Adrian Glaubitz <[email protected]>
|
|
Every compiler flag added by arch/sh/Makefile is passed to the
compiler twice:
$(KBUILD_CPPFLAGS) + $(KBUILD_CFLAGS) is used for compiling *.c
$(KBUILD_CPPFLAGS) + $(KBUILD_AFLAGS) is used for compiling *.S
Given the above, adding $(cflags-y) to all of KBUILD_{CPP/C/A}FLAGS
ends up with duplication.
Add -I options to $(KBUILD_CPPFLAGS), and the rest of $(cflags-y)
to KBUILD_{C,A}FLAGS.
Signed-off-by: Masahiro Yamada <[email protected]>
Acked-by: Randy Dunlap <[email protected]>
Tested-by: Randy Dunlap <[email protected]>
Reviewed-by: John Paul Adrian Glaubitz <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: John Paul Adrian Glaubitz <[email protected]>
|
|
Shorten the code. No functional change intended.
Signed-off-by: Masahiro Yamada <[email protected]>
Acked-by: Randy Dunlap <[email protected]>
Tested-by: Randy Dunlap <[email protected]>
Reviewed-by: John Paul Adrian Glaubitz <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: John Paul Adrian Glaubitz <[email protected]>
|
|
This is the last user of core-y in arch/sh.
Use the standard obj-y syntax.
Signed-off-by: Masahiro Yamada <[email protected]>
Acked-by: Randy Dunlap <[email protected]>
Tested-by: Randy Dunlap <[email protected]>
Reviewed-by: John Paul Adrian Glaubitz <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: John Paul Adrian Glaubitz <[email protected]>
|
|
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 <[email protected]>
Link: https://lore.kernel.org/oe-kbuild-all/[email protected]/
Signed-off-by: Masahiro Yamada <[email protected]>
Acked-by: Randy Dunlap <[email protected]>
Tested-by: Randy Dunlap <[email protected]>
Reviewed-by: John Paul Adrian Glaubitz <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: John Paul Adrian Glaubitz <[email protected]>
|
|
I added a warning about about GUP no longer expanding the stack in
commit a425ac5365f6 ("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 <[email protected]>
Reported-by: John Hubbard <[email protected]>
Reported-by: [email protected]
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Replace my email.
Cc: [email protected]
Signed-off-by: Maulik Shah <[email protected]>
Acked-by: Krzysztof Kozlowski <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Rob Herring <[email protected]>
|
|
The DTS code coding style expects spaces around '=' sign.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Reviewed-by: Matthias Brugger <[email protected]>
Acked-by: Jonathan Cameron <[email protected]>
Reviewed-by: Conor Dooley <[email protected]>
Acked-by: Dmitry Baryshkov <[email protected]> #display/msm
Acked-by: Neil Armstrong <[email protected]>
Acked-by: Mike Leach <[email protected]>
Reviewed-by: Mathieu Poirier <[email protected]>
Acked-by: Vinod Koul <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Rob Herring <[email protected]>
|
|
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/[email protected]/
Link: https://lore.kernel.org/linux-trace-kernel/[email protected]
Cc: Mark Rutland <[email protected]>
Cc: Azeem Shaikh <[email protected]>
Cc: Kees Cook <[email protected]>
Acked-by: Masami Hiramatsu (Google) <[email protected]>
Signed-off-by: Steven Rostedt (Google) <[email protected]>
|
|
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: 832f15f42646 ("RISC-V: Treat IPIs as normal Linux IRQs")
Reported-by: Conor Dooley <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/20230703-dupe-frying-79ae2ccf94eb@spud
Cc: Anup Patel <[email protected]>
Cc: Palmer Dabbelt <[email protected]>
Cc: Linus Torvalds <[email protected]>
Tested-by: Conor Dooley <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Palmer Dabbelt <[email protected]>
|
|
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/[email protected]
Suggested-by: James Houghton <[email protected]>
Cc: Ryan Roberts <[email protected]>
Signed-off-by: John Hubbard <[email protected]>
Reviewed-by: Andrew Jones <[email protected]>
Reviewed-by: Ryan Roberts <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Palmer Dabbelt <[email protected]>
|
|
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 <[email protected]>
CC: Paul Walmsley <[email protected]>
CC: Rob Herring <[email protected]>
CC: Krzysztof Kozlowski <[email protected]>
CC: Alistair Francis <[email protected]>
CC: Andrew Jones <[email protected]>
CC: Anup Patel <[email protected]>
CC: Atish Patra <[email protected]>
CC: Jessica Clarke <[email protected]>
CC: Rick Chen <[email protected]>
CC: Leo <[email protected]>
CC: Oleksii <[email protected]>
CC: [email protected]
CC: [email protected]
CC: [email protected]
CC: [email protected]
CC: [email protected]
Reviewed-by: Palmer Dabbelt <[email protected]>
Acked-by: Palmer Dabbelt <[email protected]>
Reviewed-by: Rob Herring <[email protected]>
Signed-off-by: Conor Dooley <[email protected]>
Link: https://lore.kernel.org/r/20230702-eats-scorebook-c951f170d29f@spud
Signed-off-by: Palmer Dabbelt <[email protected]>
|
|
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/[email protected]
Cc: Will Deacon <[email protected]>
Cc: Mark Rutland <[email protected]>
Cc: Donglin Peng <[email protected]>
Fixes: 3646970322464 ("arm64: ftrace: Enable HAVE_FUNCTION_GRAPH_RETVAL")
Signed-off-by: Arnd Bergmann <[email protected]>
Acked-by: Florent Revest <[email protected]>
Reviewed-by: Randy Dunlap <[email protected]>
Tested-by: Randy Dunlap <[email protected]> # build-tested
Acked-by: Catalin Marinas <[email protected]>
Signed-off-by: Steven Rostedt (Google) <[email protected]>
|
|
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: [email protected]
Fixes: 8a062902be725 ("tracing: Add tracing error log")
Signed-off-by: Mateusz Stachyra <[email protected]>
Suggested-by: Steven Rostedt <[email protected]>
Acked-by: Masami Hiramatsu (Google) <[email protected]>
Signed-off-by: Steven Rostedt (Google) <[email protected]>
|
|
MTL C0 stepping fixed issue related to butrress interrupt status clearing,
to clear an interrupt status it is required to write 1 to specific
status bit field. This allows to execute read, modify and write routine.
Writing 0 will not clear the interrupt and will cause interrupt storm.
Fixes: 35b137630f08 ("accel/ivpu: Introduce a new DRM driver for Intel VPU")
Cc: [email protected] # 6.3.x
Signed-off-by: Karol Wachowski <[email protected]>
Reviewed-by: Jacek Lawrynowicz <[email protected]>
Signed-off-by: Stanislaw Gruszka <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Incorrect REGB_WR32() macro was used to access VPUIP register.
Use correct REGV_WR32().
Fixes: 35b137630f08 ("accel/ivpu: Introduce a new DRM driver for Intel VPU")
Cc: [email protected] # 6.3.x
Signed-off-by: Karol Wachowski <[email protected]>
Reviewed-by: Jacek Lawrynowicz <[email protected]>
Signed-off-by: Stanislaw Gruszka <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
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 <[email protected]>
|
|
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: 9a0b36509df0 ("selftests: mptcp: support MPTCP_PM_CMD_ANNOUNCE")
Cc: [email protected]
Fixes: ecd2a77d672f ("selftests: mptcp: support MPTCP_PM_CMD_REMOVE")
Fixes: cf8d0a6dfd64 ("selftests: mptcp: support MPTCP_PM_CMD_SUBFLOW_CREATE")
Fixes: 57cc361b8d38 ("selftests: mptcp: support MPTCP_PM_CMD_SUBFLOW_DESTROY")
Fixes: ca188a25d43f ("selftests: mptcp: userspace PM support for MP_PRIO signals")
Signed-off-by: Matthieu Baerts <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
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: fed61c4b584c ("selftests: mptcp: make 2nd net namespace use tcp syn cookies unconditionally")
Cc: [email protected]
Signed-off-by: Matthieu Baerts <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
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: 259a834fadda ("selftests: mptcp: functional tests for the userspace PM type")
Cc: [email protected]
Acked-by: Paolo Abeni <[email protected]>
Signed-off-by: Matthieu Baerts <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
"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: ca188a25d43f ("selftests: mptcp: userspace PM support for MP_PRIO signals")
Cc: [email protected]
Acked-by: Paolo Abeni <[email protected]>
Signed-off-by: Matthieu Baerts <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
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: dc65fe82fb07 ("selftests: mptcp: add packet mark test case")
Cc: [email protected]
Acked-by: Paolo Abeni <[email protected]>
Signed-off-by: Matthieu Baerts <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
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: dc65fe82fb07 ("selftests: mptcp: add packet mark test case")
Cc: [email protected]
Acked-by: Paolo Abeni <[email protected]>
Signed-off-by: Matthieu Baerts <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
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: 5fb62e9cd3ad ("selftests: mptcp: add tproxy test case")
Cc: [email protected]
Acked-by: Paolo Abeni <[email protected]>
Signed-off-by: Matthieu Baerts <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
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: b29fcfb54cd7 ("mptcp: full disconnect implementation")
Cc: [email protected]
Reported-by: Christoph Paasch <[email protected]>
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/414
Signed-off-by: Paolo Abeni <[email protected]>
Reviewed-by: Matthieu Baerts <[email protected]>
Signed-off-by: Matthieu Baerts <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
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: 57fc0f1ceaa4 ("mptcp: ensure listener is unhashed before updating the sk status")
Cc: [email protected]
Signed-off-by: Paolo Abeni <[email protected]>
Reviewed-by: Matthieu Baerts <[email protected]>
Signed-off-by: Matthieu Baerts <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Pull yet more a typo fix in the converter code.
Signed-off-by: Takashi Iwai <[email protected]>
|
|
Fix data->system.parm2 typo.
Fixes: e9e02819a98a ("ALSA: seq: Automatic conversion of UMP events")
Signed-off-by: Minjie Du <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
|
|
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: 2390166a6b45 ("s390/qeth: clean up L3 sysfs code")
Reviewed-by: Alexandra Winter <[email protected]>
Reviewed-by: Wenjia Zhang <[email protected]>
Signed-off-by: Thorsten Winkler <[email protected]>
Signed-off-by: Alexandra Winter <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
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: b81fac906a8f ("x86/fpu: Move FPU initialization into arch_cpu_finalize_init()")
Signed-off-by: Juergen Gross <[email protected]>
Signed-off-by: Borislav Petkov (AMD) <[email protected]>
Reviewed-by: Boris Ostrovsky <[email protected]>
Acked-by: Thomas Gleixner <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
This reverts commit 534066a983df0935847061c844eb178f8a53a9e7.
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 <[email protected]>
|
|
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
|