Pull LoongArch fixes from Huacai Chen:
"A fix for tinyconfig build error, a fix for section mismatch warning,
and two cleanups of obsolete code"
* tag 'loongarch-fixes-5.19-4' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson:
LoongArch: Fix section mismatch warning
LoongArch: Fix build errors for tinyconfig
LoongArch: Remove obsolete mentions of vcsr
LoongArch: Drop these obsolete selects in Kconfig
Pull networking fixes from Paolo Abeni:
"Including fixes from bpf, netfilter, can, and bluetooth.
Current release - regressions:
- bluetooth: fix deadlock on hci_power_on_sync
Previous releases - regressions:
- sched: act_police: allow 'continue' action offload
- eth: usbnet: fix memory leak in error case
- eth: ibmvnic: properly dispose of all skbs during a failover
Previous releases - always broken:
- bpf:
- fix insufficient bounds propagation from
adjust_scalar_min_max_vals
- clear page contiguity bit when unmapping pool
- netfilter: nft_set_pipapo: release elements in clone from
abort path
- mptcp: netlink: issue MP_PRIO signals from userspace PMs
- can:
- rcar_canfd: fix data transmission failed on R-Car V3U
- gs_usb: gs_usb_open/close(): fix memory leak
Misc:
- add Wenjia as SMC maintainer"
* tag 'net-5.19-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (57 commits)
wireguard: Kconfig: select CRYPTO_CHACHA_S390
crypto: s390 - do not depend on CRYPTO_HW for SIMD implementations
wireguard: selftests: use microvm on x86
wireguard: selftests: always call kernel makefile
wireguard: selftests: use virt machine on m68k
wireguard: selftests: set fake real time in init
r8169: fix accessing unset transport header
net: rose: fix UAF bug caused by rose_t0timer_expiry
usbnet: fix memory leak in error case
Revert "tls: rx: move counting TlsDecryptErrors for sync"
mptcp: update MIB_RMSUBFLOW in cmd_sf_destroy
mptcp: fix local endpoint accounting
selftests: mptcp: userspace PM support for MP_PRIO signals
mptcp: netlink: issue MP_PRIO signals from userspace PMs
mptcp: Acquire the subflow socket lock before modifying MP_PRIO flags
mptcp: Avoid acquiring PM lock for subflow priority changes
mptcp: fix locking in mptcp_nl_cmd_sf_destroy()
net/mlx5e: Fix matchall police parameters validation
net/sched: act_police: allow 'continue' action offload
net: lan966x: hardcode the number of external ports
...
Pull pin control fixes from Linus Walleij:
- Tag Intel pin control as supported in MAINTAINERS
- Fix a NULL pointer exception in the Aspeed driver
- Correct some NAND functions in the Sunxi A83T driver
- Use the right offset for some Sunxi pins
- Fix a zero base offset in the Freescale (NXP) i.MX93
- Fix the IRQ support in the STM32 driver
* tag 'pinctrl-v5.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
pinctrl: stm32: fix optional IRQ support to gpios
pinctrl: imx: Add the zero base flag for imx93
pinctrl: sunxi: sunxi_pconf_set: use correct offset
pinctrl: sunxi: a83t: Fix NAND function name for some pins
pinctrl: aspeed: Fix potential NULL dereference in aspeed_pinmux_set_mux()
MAINTAINERS: Update Intel pin control to Supported
These are indeed "should not happen" situations, but it turns out recent
changes made the 'task_is_stopped_or_trace()' case trigger (fix for that
exists, is pending more testing), and the BUG_ON() makes it
unnecessarily hard to actually debug for no good reason.
It's been that way for a long time, but let's make it clear: BUG_ON() is
not good for debugging, and should never be used in situations where you
could just say "this shouldn't happen, but we can continue".
Use WARN_ON_ONCE() instead to make sure it gets logged, and then just
continue running. Instead of making the system basically unusuable
because you crashed the machine while potentially holding some very core
locks (eg this function is commonly called while holding 'tasklist_lock'
for writing).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
init_numa_memory() is annotated __init and not used by any module,
thus don't export it.
Remove not needed EXPORT_SYMBOL for init_numa_memory() to fix the
following section mismatch warning:
MODPOST vmlinux.symvers
WARNING: modpost: vmlinux.o(___ksymtab+init_numa_memory+0x0): Section mismatch in reference
from the variable __ksymtab_init_numa_memory to the function .init.text:init_numa_memory()
The symbol init_numa_memory is exported and annotated __init
Fix this by removing the __init annotation of init_numa_memory or drop the export.
This is build on Linux 5.19-rc4.
Fixes: d4b6f1562a ("LoongArch: Add Non-Uniform Memory Access (NUMA) support")
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Building loongarch:tinyconfig fails with the following error.
./arch/loongarch/include/asm/page.h: In function 'pfn_valid':
./arch/loongarch/include/asm/page.h:42:32: error: 'PHYS_OFFSET' undeclared
Add the missing include file and fix succeeding vdso errors.
Fixes: 09cfefb7fa ("LoongArch: Add memory management")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
The `vcsr` only exists in the old hardware design, it isn't used in any
shipped hardware from Loongson-3A5000 on. Both scalar FP and LSX/LASX
instructions use the `fcsr` as their control and status registers now.
For example, the RM control bit in fcsr0 is shared by FP, LSX and LASX
instructions.
Particularly, fcsr16 to fcsr31 are reserved for LSX/LASX now, access to
these registers has no visible effect if LSX/LASX is enabled, and will
cause SXD/ASXD exceptions if LSX/LASX is not enabled.
So, mentions of vcsr are obsolete in the first place (it was just used
for debugging), let's remove them.
Reviewed-by: WANG Xuerui <git@xen0n.name>
Signed-off-by: Qi Hu <huqi@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Commit fa96b57c14 ("LoongArch: Add build infrastructure") adds the new
file arch/loongarch/Kconfig.
As the work on LoongArch was probably quite some time under development,
various config symbols have changed and disappeared from the time of
initial writing of the Kconfig file and its inclusion in the repository.
The following four commits:
commit c126a53c27 ("arch: remove GENERIC_FIND_FIRST_BIT entirely")
commit 140c8180eb ("arch: remove HAVE_COPY_THREAD_TLS")
commit aca52c3983 ("mm: remove CONFIG_HAVE_MEMBLOCK")
commit 3f08a302f5 ("mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP option")
remove the mentioned config symbol, and enable the intended setup by
default without configuration.
Drop these obsolete selects in loongarch's Kconfig.
Reviewed-by: WANG Xuerui <git@xen0n.name>
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Jason A. Donenfeld says:
====================
wireguard patches for 5.19-rc6
1) A few small fixups to the selftests, per usual. Of particular note is
a fix for a test flake that occurred on especially fast systems that
boot in less than a second.
2) An addition during this cycle of some s390 crypto interacted with the
way wireguard selects dependencies, resulting in linker errors
reported by the kernel test robot. So Vladis sent in a patch for
that, which also required a small preparatory fix moving some Kconfig
symbols around.
====================
Link: https://lore.kernel.org/r/20220707003157.526645-1-Jason@zx2c4.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Various accelerated software implementation Kconfig values for S390 were
mistakenly placed into drivers/crypto/Kconfig, even though they're
mainly just SIMD code and live in arch/s390/crypto/ like usual. This
gives them the very unusual dependency on CRYPTO_HW, which leads to
problems elsewhere.
This patch fixes the issue by moving the Kconfig values for non-hardware
drivers into the usual place in crypto/Kconfig.
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This makes for faster tests, faster compile time, and allows us to ditch
ACPI finally.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
These selftests are used for much more extensive changes than just the
wireguard source files. So always call the kernel's build file, which
will do something or nothing after checking the whole tree, per usual.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Not all platforms have an RTC, and rather than trying to force one into
each, it's much easier to just set a fixed time. This is necessary
because WireGuard's latest handshakes parameter is returned in wallclock
time, and if the system time isn't set, and the system is really fast,
then this returns 0, which trips the test.
Turning this on requires setting CONFIG_COMPAT_32BIT_TIME=y, as musl
doesn't support settimeofday without it.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
There are UAF bugs caused by rose_t0timer_expiry(). The
root cause is that del_timer() could not stop the timer
handler that is running and there is no synchronization.
One of the race conditions is shown below:
(thread 1) | (thread 2)
| rose_device_event
| rose_rt_device_down
| rose_remove_neigh
rose_t0timer_expiry | rose_stop_t0timer(rose_neigh)
... | del_timer(&neigh->t0timer)
| kfree(rose_neigh) //[1]FREE
neigh->dce_mode //[2]USE |
The rose_neigh is deallocated in position [1] and use in
position [2].
The crash trace triggered by POC is like below:
BUG: KASAN: use-after-free in expire_timers+0x144/0x320
Write of size 8 at addr ffff888009b19658 by task swapper/0/0
...
Call Trace:
<IRQ>
dump_stack_lvl+0xbf/0xee
print_address_description+0x7b/0x440
print_report+0x101/0x230
? expire_timers+0x144/0x320
kasan_report+0xed/0x120
? expire_timers+0x144/0x320
expire_timers+0x144/0x320
__run_timers+0x3ff/0x4d0
run_timer_softirq+0x41/0x80
__do_softirq+0x233/0x544
...
This patch changes rose_stop_ftimer() and rose_stop_t0timer()
in rose_remove_neigh() to del_timer_sync() in order that the
timer handler could be finished before the resources such as
rose_neigh and so on are deallocated. As a result, the UAF
bugs could be mitigated.
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
Link: https://lore.kernel.org/r/20220705125610.77971-1-duoming@zju.edu.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Pull OpenRISC fixes from Stafford Horne:
"Fixups for OpenRISC found during recent testing:
- An OpenRISC irqchip fix to stop acking level interrupts which was
causing issues on SMP platforms
- A comment typo fix in our unwinder code"
* tag 'for-linus' of https://github.com/openrisc/linux:
openrisc: unwinder: Fix grammar issue in comment
irqchip: or1k-pic: Undefine mask_ack for level triggered hardware
Pull sound fixes from Takashi Iwai:
"This became largish as it includes the pending ASoC fixes.
Almost all changes are device-specific small fixes, while many of them
are coverage for mixer issues that were detected by selftest. In
addition, usual suspects for HD/USB-audio are there"
* tag 'sound-5.19-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (43 commits)
ALSA: cs46xx: Fix missing snd_card_free() call at probe error
ALSA: usb-audio: Add quirk for Fiero SC-01 (fw v1.0.0)
ALSA: usb-audio: Add quirk for Fiero SC-01
ALSA: hda/realtek: Add quirk for Clevo L140PU
ALSA: usb-audio: Add quirks for MacroSilicon MS2100/MS2106 devices
ASoC: madera: Fix event generation for rate controls
ASoC: madera: Fix event generation for OUT1 demux
ASoC: cs47l15: Fix event generation for low power mux control
ASoC: cs35l41: Add ASP TX3/4 source to register patch
ASoC: dapm: Initialise kcontrol data for mux/demux controls
ASoC: rt711-sdca: fix kernel NULL pointer dereference when IO error
ASoC: cs35l41: Correct some control names
ASoC: wm5110: Fix DRE control
ASoC: wm_adsp: Fix event for preloader
MAINTAINERS: update ASoC Qualcomm maintainer email-id
ASoC: rockchip: i2s: switch BCLK to GPIO
ASoC: SOF: Intel: disable IMR boot when resuming from ACPI S4 and S5 states
ASoC: SOF: pm: add definitions for S4 and S5 states
ASoC: SOF: pm: add explicit behavior for ACPI S1 and S2
ASoC: SOF: Intel: hda: Fix compressed stream position tracking
...
This reverts commit 284b4d93da.
When using TLS device offload and coming from tls_device_reencrypt()
flow, -EBADMSG error in tls_do_decryption() should not be counted
towards the TLSTlsDecryptError counter.
Move the counter increase back to the decrypt_internal() call site in
decrypt_skb_update().
This also fixes an issue where:
if (n_sgin < 1)
return -EBADMSG;
Errors in decrypt_internal() were not counted after the cited patch.
Fixes: 284b4d93da ("tls: rx: move counting TlsDecryptErrors for sync")
Cc: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Maxim Mikityanskiy <maximmi@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Gal Pressman <gal@nvidia.com>
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Mat Martineau says:
====================
mptcp: Path manager fixes for 5.19
The MPTCP userspace path manager is new in 5.19, and these patches fix
some issues in that new code.
Patches 1-3 fix path manager locking issues.
Patches 4 and 5 allow userspace path managers to change priority of
established subflows using the existing MPTCP_PM_CMD_SET_FLAGS generic
netlink command. Includes corresponding self test update.
Patches 6 and 7 fix accounting of available endpoint IDs and the
MPTCP_MIB_RMSUBFLOW counter.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch increases MPTCP_MIB_RMSUBFLOW mib counter in userspace pm
destroy subflow function mptcp_nl_cmd_sf_destroy() when removing subflow.
Fixes: 702c2f646d ("mptcp: netlink: allow userspace-driven subflow establishment")
Signed-off-by: Geliang Tang <geliang.tang@suse.com>
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In mptcp_pm_nl_rm_addr_or_subflow() we always mark as available
the id corresponding to the just removed address.
The used bitmap actually tracks only the local IDs: we must
restrict the operation when a (local) subflow is removed.
Fixes: a88c9e4969 ("mptcp: do not block subflows creation on errors")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This change updates the testing sample (pm_nl_ctl) to exercise
the updated MPTCP_PM_CMD_SET_FLAGS command for userspace PMs to
issue MP_PRIO signals over the selected subflow.
E.g. ./pm_nl_ctl set 10.0.1.2 port 47234 flags backup token 823274047 rip 10.0.1.1 rport 50003
userspace_pm.sh has a new selftest that invokes this command.
Fixes: 259a834fad ("selftests: mptcp: functional tests for the userspace PM type")
Acked-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Kishen Maloor <kishen.maloor@intel.com>
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When setting up a subflow's flags for sending MP_PRIO MPTCP options, the
subflow socket lock was not held while reading and modifying several
struct members that are also read and modified in mptcp_write_options().
Acquire the subflow socket lock earlier and send the MP_PRIO ACK with
that lock already acquired. Add a new variant of the
mptcp_subflow_send_ack() helper to use with the subflow lock held.
Fixes: 067065422f ("mptcp: add the outgoing MP_PRIO support")
Acked-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The in-kernel path manager code for changing subflow flags acquired both
the msk socket lock and the PM lock when possibly changing the "backup"
and "fullmesh" flags. mptcp_pm_nl_mp_prio_send_ack() does not access
anything protected by the PM lock, and it must release and reacquire
the PM lock.
By pushing the PM lock to where it is needed in mptcp_pm_nl_fullmesh(),
the lock is only acquired when the fullmesh flag is changed and the
backup flag code no longer has to release and reacquire the PM lock. The
change in locking context requires the MIB update to be modified - move
that to a better location instead.
This change also makes it possible to call
mptcp_pm_nl_mp_prio_send_ack() for the userspace PM commands without
manipulating the in-kernel PM lock.
Fixes: 0f9f696a50 ("mptcp: add set_flags command in PM netlink")
Acked-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The user-space PM subflow removal path uses a couple of helpers
that must be called under the msk socket lock and the current
code lacks such requirement.
Change the existing lock scope so that the relevant code is under
its protection.
Fixes: 702c2f646d ("mptcp: netlink: allow userspace-driven subflow establishment")
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/287
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vlad Buslov says:
====================
net: Fix police 'continue' action offload
TC act_police with 'continue' action had been supported by mlx5 matchall
classifier offload implementation for some time. However, 'continue' was
assumed implicitly and recently got broken in multiple places. Fix it in
both TC hardware offload validation code and mlx5 driver.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Referenced commit prepared the code for upcoming extension that allows mlx5
to offload police action attached to flower classifier. However, with
regard to existing matchall classifier offload validation should be
reversed as FLOW_ACTION_CONTINUE is the only supported notexceed police
action type. Fix the problem by allowing FLOW_ACTION_CONTINUE for police
action and extend scan_tc_matchall_fdb_actions() to only allow such actions
with matchall classifier.
Fixes: d97b4b105c ("flow_offload: reject offload for all drivers with invalid police parameters")
Signed-off-by: Vlad Buslov <vladbu@nvidia.com>
Acked-by: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Offloading police with action TC_ACT_UNSPEC was erroneously disabled even
though it was supported by mlx5 matchall offload implementation, which
didn't verify the action type but instead assumed that any single police
action attached to matchall classifier is a 'continue' action. Lack of
action type check made it non-obvious what mlx5 matchall implementation
actually supports and caused implementers and reviewers of referenced
commits to disallow it as a part of improved validation code.
Fixes: b8cd5831c6 ("net: flow_offload: add tc police action parameters")
Fixes: b50e462bc2 ("net/sched: act_police: Add extack messages for offload failure")
Signed-off-by: Vlad Buslov <vladbu@nvidia.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Tested-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Instead of counting the child nodes in the device tree, hardcode the
number of ports in the driver itself. The counting won't work at all
if an ethernet port is marked as disabled, e.g. because it is not
connected on the board at all.
It turns out that the LAN9662 and LAN9668 use the same switching IP
with the same synthesis parameters. The only difference is that the
output ports are not connected. Thus, we can just hardcode the
number of physical ports to 8.
Fixes: db8bcaad53 ("net: lan966x: add the basic lan966x driver")
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Link: https://lore.kernel.org/r/20220704153654.1167886-1-michael@walle.cc
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Luiz Augusto von Dentz says:
====================
bluetooth pull request for net:
- Fix deadlock when powering on.
* tag 'for-net-2022-07-05' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth:
Bluetooth: core: Fix deadlock on hci_power_on_sync.
====================
Link: https://lore.kernel.org/r/20220705202700.1689796-1-luiz.dentz@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
`cancel_work_sync(&hdev->power_on)` was moved to hci_dev_close_sync in
commit [1] to ensure that power_on work is canceled after HCI interface
down.
But, in certain cases power_on work function may call hci_dev_close_sync
itself: hci_power_on -> hci_dev_do_close -> hci_dev_close_sync ->
cancel_work_sync(&hdev->power_on), causing deadlock. In particular, this
happens when device is rfkilled on boot. To avoid deadlock, move
power_on work canceling out of hci_dev_do_close/hci_dev_close_sync.
Deadlock introduced by commit [1] was reported in [2,3] as broken
suspend. Suspend did not work because `hdev->req_lock` held as result of
`power_on` work deadlock. In fact, other BT features were not working.
It was not observed when testing [1] since it was verified without
rfkill in place.
NOTE: It is not needed to cancel power_on work from other places where
hci_dev_do_close/hci_dev_close_sync is called in case:
* Requests were serialized due to `hdev->req_workqueue`. The power_on
work is first in that workqueue.
* hci_rfkill_set_block which won't close device anyway until HCI_SETUP
is on.
* hci_sock_release which runs after hci_sock_bind which ensures
HCI_SETUP was cleared.
As result, behaviour is the same as in pre-dd06ed7 commit, except
power_on work cancel added to hci_dev_close.
[1]: commit ff7f292611 ("Bluetooth: core: Fix missing power_on work cancel on HCI close")
[2]: https://lore.kernel.org/lkml/20220614181706.26513-1-max.oss.09@gmail.com/
[2]: https://lore.kernel.org/lkml/1236061d-95dd-c3ad-a38f-2dae7aae51ef@o2.pl/
Fixes: ff7f292611 ("Bluetooth: core: Fix missing power_on work cancel on HCI close")
Signed-off-by: Vasyl Vavrychuk <vasyl.vavrychuk@opensynergy.com>
Reported-by: Max Krummenacher <max.krummenacher@toradex.com>
Reported-by: Mateusz Jonczyk <mat.jonczyk@o2.pl>
Tested-by: Max Krummenacher <max.krummenacher@toradex.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Pull xen security fixes from Juergen Gross:
- XSA-403 (4 patches for blkfront and netfront drivers):
Linux Block and Network PV device frontends don't zero memory regions
before sharing them with the backend (CVE-2022-26365,
CVE-2022-33740). Additionally the granularity of the grant table
doesn't allow sharing less than a 4K page, leading to unrelated data
residing in the same 4K page as data shared with a backend being
accessible by such backend (CVE-2022-33741, CVE-2022-33742).
- XSA-405 (1 patch for netfront driver, only 5.10 and newer):
While adding logic to support XDP (eXpress Data Path), a code label
was moved in a way allowing for SKBs having references (pointers)
retained for further processing to nevertheless be freed.
- XSA-406 (1 patch for Arm specific dom0 code):
When mapping pages of guests on Arm, dom0 is using an rbtree to keep
track of the foreign mappings.
Updating of that rbtree is not always done completely with the
related lock held, resulting in a small race window, which can be
used by unprivileged guests via PV devices to cause inconsistencies
of the rbtree. These inconsistencies can lead to Denial of Service
(DoS) of dom0, e.g. by causing crashes or the inability to perform
further mappings of other guests' memory pages.
* tag 'xsa-5.19-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
xen/arm: Fix race in RB-tree based P2M accounting
xen-netfront: restore __skb_queue_tail() positioning in xennet_get_responses()
xen/blkfront: force data bouncing when backend is untrusted
xen/netfront: force data bouncing when backend is untrusted
xen/netfront: fix leaking data in shared pages
xen/blkfront: fix leaking data in shared pages
The previous cleanup with devres may lead to the incorrect release
orders at the probe error handling due to the devres's nature. Until
we register the card, snd_card_free() has to be called at first for
releasing the stuff properly when the driver tries to manage and
release the stuff via card->private_free().
This patch fixes it by calling snd_card_free() manually on the error
from the probe callback.
Fixes: 5bff69b364 ("ALSA: cs46xx: Allocate resources with device-managed APIs")
Cc: <stable@vger.kernel.org>
Reported-and-tested-by: Jan Engelhardt <jengelh@inai.de>
Link: https://lore.kernel.org/r/p2p1s96o-746-74p4-s95-61qo1p7782pn@vanv.qr
Link: https://lore.kernel.org/r/20220705152336.350-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Vladimir Oltean says:
====================
Fix bridge_vlan_aware.sh and bridge_vlan_unaware.sh with IFF_UNICAST_FLT
Make sure that h1 and h2 don't drop packets with a random MAC DA, which
otherwise confuses these selftests. Also, fix an incorrect error message
found during those failures.
====================
Link: https://lore.kernel.org/r/20220703073626.937785-1-vladimir.oltean@nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
When packets are not received, they aren't received on $host1_if, so the
message talking about the second host not receiving them is incorrect.
Fix it.
Fixes: d4deb01467 ("selftests: forwarding: Add a test for FDB learning")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The first host interface has by default no interest in receiving packets
MAC DA de:ad:be:ef:13:37, so it might drop them before they hit the tc
filter and this might confuse the selftest.
Enable promiscuous mode such that the filter properly counts received
packets.
Fixes: d4deb01467 ("selftests: forwarding: Add a test for FDB learning")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Tested-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
As mentioned in the blamed commit, flood_unicast_test() works by
checking the match count on a tc filter placed on the receiving
interface.
But the second host interface (host2_if) has no interest in receiving a
packet with MAC DA de:ad:be:ef:13:37, so its RX filter drops it even
before the ingress tc filter gets to be executed. So we will incorrectly
get the message "Packet was not flooded when should", when in fact, the
packet was flooded as expected but dropped due to an unrelated reason,
at some other layer on the receiving side.
Force h2 to accept this packet by temporarily placing it in promiscuous
mode. Alternatively we could either deliver to its MAC address or use
tcpdump_start, but this has the fewest complications.
This fixes the "flooding" test from bridge_vlan_aware.sh and
bridge_vlan_unaware.sh, which calls flood_test from the lib.
Fixes: 236dd50bf6 ("selftests: forwarding: Add a test for flooded traffic")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Tested-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Marc Kleine-Budde says:
====================
can 2022-07-04
The 1st patch is by Oliver Hartkopp, targets the BCM CAN protocol and
converts a costly synchronize_rcu() to call_rcu() to fix a performance
regression.
Srinivas Neeli's patch for the xilinx_can driver drops the brp limit
down to 1, as only the pre-production silicon have an issue with a brp
of 1.
The next patch is by Duy Nguyen and fixes the data transmission on
R-Car V3U SoCs in the rcar_canfd driver.
Rhett Aultman's patch fixes a DMA memory leak in the gs_usb driver.
Liang He's patch removes an extra of_node_get() in the grcan driver.
The next 2 patches are by me, target the m_can driver and fix the
timestamp handling used for peripheral devices like the tcan4x5x.
Jimmy Assarsson contributes 3 patches for the kvaser_usb driver and
fixes CAN clock and bit timing related issues.
The remaining 5 patches target the mcp251xfd driver. Thomas Kopp
contributes 2 patches to improve the workaround for broken CRC when
reading the TBC register. 3 patches by me add a missing
hrtimer_cancel() during the ndo_stop() callback, and fix the reading
of the Device ID register.
* tag 'linux-can-fixes-for-5.19-20220704' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can:
can: mcp251xfd: mcp251xfd_register_get_dev_id(): fix endianness conversion
can: mcp251xfd: mcp251xfd_register_get_dev_id(): use correct length to read dev_id
can: mcp251xfd: mcp251xfd_stop(): add missing hrtimer_cancel()
can: mcp251xfd: mcp251xfd_regmap_crc_read(): update workaround broken CRC on TBC register
can: mcp251xfd: mcp251xfd_regmap_crc_read(): improve workaround handling for mcp2517fd
can: kvaser_usb: kvaser_usb_leaf: fix bittiming limits
can: kvaser_usb: kvaser_usb_leaf: fix CAN clock frequency regression
can: kvaser_usb: replace run-time checks with struct kvaser_usb_driver_info
can: m_can: m_can_{read_fifo,echo_tx_event}(): shift timestamp to full 32 bits
can: m_can: m_can_chip_config(): actually enable internal timestamping
can: grcan: grcan_probe(): remove extra of_node_get()
can: gs_usb: gs_usb_open/close(): fix memory leak
can: rcar_canfd: Fix data transmission failed on R-Car V3U
Revert "can: xilinx_can: Limit CANFD brp to 2"
can: bcm: use call_rcu() instead of costly synchronize_rcu()
====================
Link: https://lore.kernel.org/r/20220704122613.1551119-1-mkl@pengutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Pull ARM SoC fixes from Arnd Bergmann:
"Another set of minor patches for Arm DTS files and soc specific
drivers:
- More reference counting bug fixes for DT nodes, and other trivial
code fixes
- Multiple code fixes for the Arm SCMI firmware driver to improve
compatibility with firmware implementations.
- A patch series for at91 to address power management issues from
using the wrong DT compatible properties.
- A series of patches to fix pad settings for NXP imx8mp to leave the
configuration untouched from the boot loader
- Additional DT fixes for qualcomm and NXP platforms
- A boot time fix for stm32mp15 DT
- Konrad Dybcio becomes an additional reviewer for the Qualcomm
platforms"
* tag 'soc-fixes-5.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (42 commits)
soc: qcom: smem: use correct format characters
ARM: dts: stm32: add missing usbh clock and fix clk order on stm32mp15
ARM: dts: stm32: delete fixed clock node on STM32MP15-SCMI
ARM: dts: stm32: DSI should use LSE SCMI clock on DK1/ED1 STM32 board
ARM: dts: stm32: use the correct clock source for CEC on stm32mp151
ARM: dts: stm32: fix pwr regulators references to use scmi
soc: ixp4xx/npe: Fix unused match warning
ARM: at91: pm: Mark at91_pm_secure_init as __init
ARM: at91: fix soc detection for SAM9X60 SiPs
ARM: dts: at91: sama5d2_icp: fix eeprom compatibles
ARM: dts: at91: sam9x60ek: fix eeprom compatible and size
ARM: at91: pm: use proper compatibles for sama7g5's rtc and rtt
ARM: at91: pm: use proper compatibles for sam9x60's rtc and rtt
ARM: at91: pm: use proper compatible for sama5d2's rtc
arm64: dts: qcom: msm8992-*: Fix vdd_lvs1_2-supply typo
firmware: arm_scmi: Remove usage of the deprecated ida_simple_xxx API
firmware: arm_scmi: Fix response size warning for OPTEE transport
arm64: dts: imx8mp-icore-mx8mp-edim2.2: correct pad settings
arm64: dts: imx8mp-phyboard-pollux-rdk: correct i2c2 & mmc settings
arm64: dts: imx8mp-phyboard-pollux-rdk: correct eqos pad settings
...
STM32 DT fixes for v5.19, round 2
Highlights:
-----------
-Fixes STM32MP15:
- Add missing usbh clock and fix clk order for usbh to avoid PLL
issue.
- Fix SCMI version: use scmi regulator and update missing SCMI
clocks to be able to correcly boot.
* tag 'stm32-dt-for-v5.19-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32:
ARM: dts: stm32: add missing usbh clock and fix clk order on stm32mp15
ARM: dts: stm32: delete fixed clock node on STM32MP15-SCMI
ARM: dts: stm32: DSI should use LSE SCMI clock on DK1/ED1 STM32 board
ARM: dts: stm32: use the correct clock source for CEC on stm32mp151
ARM: dts: stm32: fix pwr regulators references to use scmi
Link: https://lore.kernel.org/r/1259e082-a3a4-96a5-ec9c-05dbb893a746@foss.st.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
When compiling with -Wformat, clang emits the following warnings:
drivers/soc/qcom/smem.c:847:41: warning: format specifies type 'unsigned
short' but the argument has type 'unsigned int' [-Wformat]
dev_err(smem->dev, "bad host %hu\n", remote_host);
~~~ ^~~~~~~~~~~
%u
./include/linux/dev_printk.h:144:65: note: expanded from macro 'dev_err'
dev_printk_index_wrap(_dev_err, KERN_ERR, dev, dev_fmt(fmt), ##__VA_ARGS__)
~~~ ^~~~~~~~~~~
./include/linux/dev_printk.h:110:23: note: expanded from macro 'dev_printk_index_wrap'
_p_func(dev, fmt, ##__VA_ARGS__); \
~~~ ^~~~~~~~~~~
drivers/soc/qcom/smem.c:852:47: warning: format specifies type 'unsigned
short' but the argument has type 'unsigned int' [-Wformat]
dev_err(smem->dev, "duplicate host %hu\n", remote_host);
~~~ ^~~~~~~~~~~
%u
./include/linux/dev_printk.h:144:65: note: expanded from macro 'dev_err'
dev_printk_index_wrap(_dev_err, KERN_ERR, dev, dev_fmt(fmt), ##__VA_ARGS__)
~~~ ^~~~~~~~~~~
./include/linux/dev_printk.h:110:23: note: expanded from macro 'dev_printk_index_wrap'
_p_func(dev, fmt, ##__VA_ARGS__); \
~~~ ^~~~~~~~~~~
The types of these arguments are unconditionally defined, so this patch
updates the format character to the correct one and change type of
remote_host to "u16" to match with other types.
Signed-off-by: Bill Wendling <morbo@google.com>
Tested-by: Justin Stitt <jstitt007@gmail.com>
Reviewed-by: Justin Stitt <jstitt007@gmail.com>
Link: https://github.com/ClangBuiltLinux/linux/issues/378
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
ASoC: Fixes for v5.19
A collection of fixes for v5.19, quite large but nothing major - a good
chunk of it is more stuff that was identified by mixer-test regarding
event generation.
The patch applies the same quirks used for SC-01 at firmware v1.1.0 to
the ones running v1.0.0, with respect to hard-coded sample rates.
I got two more units and successfully tested the patch series with both
firmwares.
The support is now complete (not accounting ASIO).
Signed-off-by: Egor Vorontsov <sdoregor@sdore.me>
Link: https://lore.kernel.org/r/20220627100041.2861494-2-sdoregor@sdore.me
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Fiero SC-01 is a USB sound card with two mono inputs and a single
stereo output. The inputs are composed into a single stereo stream.
The device uses a vendor-provided driver on Windows and does not work
at all without it. The driver mostly provides ASIO functionality, but
also alters the way the sound card is queried for sample rates and
clocks.
ALSA queries those failing with an EPIPE (same as Windows 10 does).
Presumably, the vendor-provided driver does not query it at all, simply
matching by VID:PID. Thus, I consider this a buggy firmware and adhere
to a set of fixed endpoint quirks instead.
The soundcard has an internal clock. Implicit feedback mode is required
for the playback.
I have updated my device to v1.1.0 from a Windows 10 VM using a vendor-
provided binary prior to the development, hoping for it to just begin
working. The device provides no obvious way to downgrade the firmware,
and regardless, there's no binary available for v1.0.0 anyway.
Thus, I will be getting another unit to extend the patch with support
for that. Expected to be a simple copy-paste of the existing one,
though.
There were no previous reports of that device in context of Linux
anywhere. Other issues have been reported though, but that's out of the
scope.
Signed-off-by: Egor Vorontsov <sdoregor@sdore.me>
Link: https://lore.kernel.org/r/20220627100041.2861494-1-sdoregor@sdore.me
Signed-off-by: Takashi Iwai <tiwai@suse.de>
