IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Cast pointers to unsigned long instead of to uint64_t to avoid this
problem on 32-bit arches:
31 6.89 debian:experimental-x-mips : FAIL gcc version 11.2.0 (Debian 11.2.0-18)
bench/breakpoint.c: In function 'breakpoint_setup':
bench/breakpoint.c:56:24: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
56 | attr.bp_addr = (uint64_t)addr;
| ^
cc1: all warnings being treated as errors
make[3]: *** [/git/perf-5.18.0-rc7/tools/build/Makefile.build:139: bench] Error 2
Fixes: 68a6772f11dbb1ed ("perf bench: Add breakpoint benchmarks")
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Dmitriy Vyukov <dvyukov@google.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Marco Elver <elver@google.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lore.kernel.org/lkml/YoLq1nHx1doi+VWl@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This reverts commit 1571d67dc190e50c6c56e8f88cdc39f7cc53166e.
This commit broke support for setting interrupt affinity. It looks like
that it is related to the chained IRQ handler. Revert this commit until
issue with setting interrupt affinity is fixed.
Fixes: 1571d67dc190 ("PCI: aardvark: Rewrite IRQ code to chained IRQ handler")
Link: https://lore.kernel.org/r/20220515125815.30157-1-pali@kernel.org
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
delta_ns is a s64, but it was being passed ptp_ocp_adjtime_coarse
as an u64. Also, it turns out that timespec64_add_ns() only handles
positive values, so perform the math with set_normalized_timespec().
Fixes: 90f8f4c0e3ce ("ptp: ocp: Add ptp_ocp_adjtime_coarse for large adjustments")
Suggested-by: Vadim Fedorenko <vfedorenko@novek.ru>
Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Acked-by: Vadim Fedorenko <vfedorenko@novek.ru>
Link: https://lore.kernel.org/r/20220513225231.1412-1-jonathan.lemon@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When running a combination of PPPoE on top of a VLAN, we need to set
info->outdev to the PPPoE device, otherwise PPPoE encap is skipped
during software offload.
Fixes: 72efd585f714 ("netfilter: flowtable: add pppoe support")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
When calling dev_fill_forward_path on a pppoe device, the provided destination
address is invalid. In order for the bridge fdb lookup to succeed, the pppoe
code needs to update ctx->daddr to the correct value.
Fix this by storing the address inside struct net_device_path_ctx
Fixes: f6efc675c9dd ("net: ppp: resolve forwarding path for bridge pppoe devices")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
The dst entry does not contain a valid hardware address, so skip the lookup
in order to avoid running into errors here.
The proper hardware address is filled in from nft_dev_path_info
Fixes: 72efd585f714 ("netfilter: flowtable: add pppoe support")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
If a flow cannot be offloaded, the code currently repeatedly tries again as
quickly as possible, which can significantly increase system load.
Fix this by limiting flow timeout update and hardware offload retry to once
per second.
Fixes: c07531c01d82 ("netfilter: flowtable: Remove redundant hw refresh bit")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
syzbot was able to trigger an Out-of-Bound on the pedit action:
UBSAN: shift-out-of-bounds in net/sched/act_pedit.c:238:43
shift exponent 1400735974 is too large for 32-bit type 'unsigned int'
CPU: 0 PID: 3606 Comm: syz-executor151 Not tainted 5.18.0-rc5-syzkaller-00165-g810c2f0a3f86 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
ubsan_epilogue+0xb/0x50 lib/ubsan.c:151
__ubsan_handle_shift_out_of_bounds.cold+0xb1/0x187 lib/ubsan.c:322
tcf_pedit_init.cold+0x1a/0x1f net/sched/act_pedit.c:238
tcf_action_init_1+0x414/0x690 net/sched/act_api.c:1367
tcf_action_init+0x530/0x8d0 net/sched/act_api.c:1432
tcf_action_add+0xf9/0x480 net/sched/act_api.c:1956
tc_ctl_action+0x346/0x470 net/sched/act_api.c:2015
rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5993
netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502
netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
netlink_unicast+0x543/0x7f0 net/netlink/af_netlink.c:1345
netlink_sendmsg+0x904/0xe00 net/netlink/af_netlink.c:1921
sock_sendmsg_nosec net/socket.c:705 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:725
____sys_sendmsg+0x6e2/0x800 net/socket.c:2413
___sys_sendmsg+0xf3/0x170 net/socket.c:2467
__sys_sendmsg+0xe5/0x1b0 net/socket.c:2496
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7fe36e9e1b59
Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffef796fe88 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe36e9e1b59
RDX: 0000000000000000 RSI: 0000000020000300 RDI: 0000000000000003
RBP: 00007fe36e9a5d00 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe36e9a5d90
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
</TASK>
The 'shift' field is not validated, and any value above 31 will
trigger out-of-bounds. The issue predates the git history, but
syzbot was able to trigger it only after the commit mentioned in
the fixes tag, and this change only applies on top of such commit.
Address the issue bounding the 'shift' value to the maximum allowed
by the relevant operator.
Reported-and-tested-by: syzbot+8ed8fc4c57e9dcf23ca6@syzkaller.appspotmail.com
Fixes: 8b796475fd78 ("net/sched: act_pedit: really ensure the skb is writable")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
At cleaning up and moving the device rename from the quirk table to
its own table, we removed the entry for Rane SL-1 as we thought it's
only for renaming. It turned out, however, that the quirk is required
for matching with the device that declares itself as no standard
audio but only as vendor-specific.
Restore the quirk entry for Rane SL-1 to fix the regression.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215887
Fixes: 5436f59bc5bc ("ALSA: usb-audio: Move device rename and profile quirks to an internal table")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20220516103112.12950-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEBsvAIBsPu6mG7thcrX5LkNig010FAmJ/+pYTHG1rbEBwZW5n
dXRyb25peC5kZQAKCRCtfkuQ2KDTXQSHB/9EEcms7LYv1N+SftYGIOA/rY+dhD+o
N6aLI0aFI3K1SK7BcnSuvamO+Wi6pEH/8twe/fFSphaKiQIiy7rE+FmU0BLPcvG1
ejISzRUdxDkWW0X7fZQfObf9MGOlostXjYWPb396OfOR/z45DvFmhuJX1ye/9W5+
HFmfbsGkDKzmZhgXrkP1Zj3ag4br2qJLPGsWmiH4QBBeWT6dokfqxiM0rNjA18Hp
gytGQ6AycHFhyEaAuyEQKNCpsce/s1f/dpQ5EsSxbNEHT4aV1qwc05fL4/SHmEih
zR8QjIy9d0I7fprM5VXrbLt5e7aQR9XIaJIZ+iL8t2LYhCnw/g4xkEQe
=ANrU
-----END PGP SIGNATURE-----
Merge tag 'linux-can-fixes-for-5.18-20220514' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can
Marc Kleine-Budde says:
====================
pull-request: can 2022-05-14
this is a pull request of 2 patches for net/master.
Changes to linux-can-fixes-for-5.18-20220513:
- adjusted Fixes: Tag on "Revert "can: m_can: pci: use custom bit timings for Elkhart Lake""
(Thanks Jakub)
Both patches are by Jarkko Nikula, target the m_can PCI driver
bindings, and fix usage of wrong bit timing constants for the Elkhart
Lake platform.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
The HP EliteBook 630 is using ALC236 codec which used 0x02 to control mute LED
and 0x01 to control micmute LED. Therefore, add a quirk to make it works.
Signed-off-by: Andy Chi <andy.chi@canonical.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20220513121648.28584-1-andy.chi@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In IPv4 setting the "disable_policy" flag on a device means no policy
should be enforced for traffic originating from the device. This was
implemented by seting the DST_NOPOLICY flag in the dst based on the
originating device.
However, dsts are cached in nexthops regardless of the originating
devices, in which case, the DST_NOPOLICY flag value may be incorrect.
Consider the following setup:
+------------------------------+
| ROUTER |
+-------------+ | +-----------------+ |
| ipsec src |----|-|ipsec0 | |
+-------------+ | |disable_policy=0 | +----+ |
| +-----------------+ |eth1|-|-----
+-------------+ | +-----------------+ +----+ |
| noipsec src |----|-|eth0 | |
+-------------+ | |disable_policy=1 | |
| +-----------------+ |
+------------------------------+
Where ROUTER has a default route towards eth1.
dst entries for traffic arriving from eth0 would have DST_NOPOLICY
and would be cached and therefore can be reused by traffic originating
from ipsec0, skipping policy check.
Fix by setting a IPSKB_NOPOLICY flag in IPCB and observing it instead
of the DST in IN/FWD IPv4 policy checks.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Signed-off-by: Eyal Birger <eyal.birger@gmail.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
There are 2 ways an engine can get reset in i915 and the method of reset
affects how KMD labels a context as guilty/innocent.
(1) GuC initiated engine-reset: GuC resets a hung engine and notifies
KMD. The context that hung on the engine is marked guilty and all other
contexts are innocent. The innocent contexts are resubmitted.
(2) GT based reset: When an engine heartbeat fails to tick, KMD
initiates a gt/chip reset. All active contexts are marked as guilty and
discarded.
In order to correctly mark the contexts as guilty/innocent, pass a mask
of engines that were reset to __guc_reset_context.
Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface")
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220426003045.3929439-1-umesh.nerlige.ramappa@intel.com
(cherry picked from commit 303760aa914b7f5ac9602dbb4b471a2ad52eeb3e)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Bspec has added some steps that check forDMC MMIO range before
programming them
v2: Fix for CI
v3: move register defines to .h (Anusha)
- Check MMIO restrictions per pipe
- Add MMIO restricton for v1 dmc header as well (Lucas)
v4: s/_PICK/_PICK_EVEN and use it only for Pipe DMC scenario.
- clean up sanity check logic.(Lucas)
- Add MMIO range for RKL as well.(Anusha)
v5: Use DISPLAY_VER instead of per platform check (Lucas)
BSpec: 49193
Cc: stable@vger.kernel.org
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220511000847.1068302-1-anusha.srivatsa@intel.com
(cherry picked from commit 21c47196aec3a93f913a7515e1e7b30e6c54d6c6)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Here is one fix, and 3 documentation updates for 5.18-rc7.
The fix is for the firmware loader which resolves a long-reported
problem where the credentials of the firmware loader could be set to a
userspace process without enough permissions to actually load the
firmware image. Many Android vendors have been reporting this for quite
some time.
The documentation updates are for the embargoed-hardware-issues.rst file
to add a new entry, change an existing one, and sort the list to make
changes easier in the future.
All of these have been in linux-next for a while with no reported
issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCYoEMSw8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ynl8wCgw54h8hggK6eikgctGuyoLJZjDR4AnRVNvtQi
ItQ1+zHzBjkdz1s/DlM7
=/7MV
-----END PGP SIGNATURE-----
Merge tag 'driver-core-5.18-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Pull driver core fixes from Greg KH:
"Here is one fix, and three documentation updates for 5.18-rc7.
The fix is for the firmware loader which resolves a long-reported
problem where the credentials of the firmware loader could be set to a
userspace process without enough permissions to actually load the
firmware image. Many Android vendors have been reporting this for
quite some time.
The documentation updates are for the embargoed-hardware-issues.rst
file to add a new entry, change an existing one, and sort the list to
make changes easier in the future.
All of these have been in linux-next for a while with no reported
issues"
* tag 'driver-core-5.18-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
Documentation/process: Update ARM contact for embargoed hardware issues
Documentation/process: Add embargoed HW contact for Ampere Computing
Documentation/process: Make groups alphabetical and use tabs consistently
firmware_loader: use kernel credentials when reading firmware
Here are 2 small driver fixes for 5.18-rc7 that resolve reported
problems:
- slimbus driver irq bugfix
- interconnect sync state bugfix
Both of these have been in linux-next with no reported problems.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCYoELfQ8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+yn1EACeMMP4A10lS7sKlgyM6ftMKA1hu7UAniih+zD/
yGi9Fx4SxUUhYKelF75P
=n7+j
-----END PGP SIGNATURE-----
Merge tag 'char-misc-5.18-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc driver fixes from Greg KH:
"Here are two small driver fixes for 5.18-rc7 that resolve reported
problems:
- slimbus driver irq bugfix
- interconnect sync state bugfix
Both of these have been in linux-next with no reported problems"
* tag 'char-misc-5.18-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
slimbus: qcom: Fix IRQ check in qcom_slim_probe
interconnect: Restore sync state by ignoring ipa-virt in provider count
Here are some small tty n_gsm and serial driver fixes for 5.18-rc7 that
resolve reported problems. They include:
- n_gsm fixes for reported issues
- 8250_mtk driver fixes for some platforms
- fsl_lpuart driver fix for reported problem.
- digicolor driver fix for reported problem.
All have been in linux-next for a while with no reported problems.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCYoEM8g8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ylkRgCePwdlqU8cJAePVKVEQVbBmqV2DQgAoL4aGeH7
/4ZvKAc/3AmUOBU+46sa
=my19
-----END PGP SIGNATURE-----
Merge tag 'tty-5.18-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Pull tty/serial driver fixes from Greg KH:
"Here are some small tty n_gsm and serial driver fixes for 5.18-rc7
that resolve reported problems. They include:
- n_gsm fixes for reported issues
- 8250_mtk driver fixes for some platforms
- fsl_lpuart driver fix for reported problem.
- digicolor driver fix for reported problem.
All have been in linux-next for a while with no reported problems"
* tag 'tty-5.18-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
fsl_lpuart: Don't enable interrupts too early
tty: n_gsm: fix invalid gsmtty_write_room() result
tty: n_gsm: fix mux activation issues in gsm_config()
tty: n_gsm: fix buffer over-read in gsm_dlci_data()
serial: 8250_mtk: Fix register address for XON/XOFF character
serial: 8250_mtk: Make sure to select the right FEATURE_SEL
serial: 8250_mtk: Fix UART_EFR register address
tty/serial: digicolor: fix possible null-ptr-deref in digicolor_uart_probe()
Here are some small fixes for reported issues with some USB drivers.
They include:
- xhci fixes for xhci-mtk platform driver
- typec driver fixes for reported problems.
- cdc-wdm read-stuck fix
- gadget driver fix for reported race condition
- new usb-serial driver ids
All of these have been in linux-next with no reported problems.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCYoENmA8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ymxrwCeIzUtnkEw80tyjr3r/ciuZgfqM90AoJ50aiIV
YqYG8aVcUUrM47qQuYUX
=I21N
-----END PGP SIGNATURE-----
Merge tag 'usb-5.18-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB fixes from Greg KH:
"Here are some small fixes for reported issues with some USB drivers.
They include:
- xhci fixes for xhci-mtk platform driver
- typec driver fixes for reported problems.
- cdc-wdm read-stuck fix
- gadget driver fix for reported race condition
- new usb-serial driver ids
All of these have been in linux-next with no reported problems"
* tag 'usb-5.18-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
usb: xhci-mtk: remove bandwidth budget table
usb: xhci-mtk: fix fs isoc's transfer error
usb: gadget: fix race when gadget driver register via ioctl
usb: typec: tcpci_mt6360: Update for BMC PHY setting
usb: gadget: uvc: allow for application to cleanly shutdown
usb: typec: tcpci: Don't skip cleanup in .remove() on error
usb: cdc-wdm: fix reading stuck on device close
USB: serial: qcserial: add support for Sierra Wireless EM7590
USB: serial: option: add Fibocom MA510 modem
USB: serial: option: add Fibocom L610 modem
USB: serial: pl2303: add device id for HP LM930 Display
- Fix KVM PR on 32-bit, which was broken by some MMU code refactoring.
Thanks to: Alexander Graf, Matt Evans.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCAAxFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAmKA5psTHG1wZUBlbGxl
cm1hbi5pZC5hdQAKCRBR6+o8yOGlgHnjD/4/YU1y7XU/h0RjYwiKfVlVbIFXjFkB
xMgijdI87SCSU94O8h/7WqhVEwfS8dM+jBa9F4Ky6nOqLMnAE1B/zPzE1P9KAvLl
kilLQ9Wl/VhR+PqD62UofevhwsPA+neLkKKAfWMjMvRp4wHvAk18ILNAxhq4D3hP
7KyK4sQntBVwnObWuopJoEeKuoDFa/0VRr/VC29CKowWRzIgwo/OVBBzAxrYUT0g
HjhNO4zPyJ6mxanO24cWokXekxWKU07NvIeU4dP6nOreUJvfxfpmEbhsxrC8YLo1
Fy7MWGQLwvq8D7UHeWPh+OOhIuPQDIDseXaW3m4mkLmMqxy5Y+D2aCyto/Rl8B97
yPqWmcYjdLoac0CS3l+CQUcCTc5YPZ7zDkPkrKdvutyrPqgTkTgRFWrOIlLJtV7f
H++hVj0RMiFyjPPAUWNtByKwdwq+lAN1OqrtrksWhX6aSZJIgcR0pUQM1YFqDQU1
IOErcs2JjrwxYOGDIgB6zE/UNClDaoS5J0p4utgtnRyQB1VHnUqv8+3wP3+7ATYG
I7smX7ce/RRtLvJTXIgNc406ibj/TOW9icneBZ9m1+2WWcBb4JpUMiBBwyhCsn7x
xHzJLof4LLKxCdjalBb8w7mQ4yO5i9IHrOEgb/TD3P5MXjBhWZOljky+j7NUXzgb
9IFdAGOPnXwcFw==
=HVUs
-----END PGP SIGNATURE-----
Merge tag 'powerpc-5.18-5' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
Pull powerpc fix from Michael Ellerman:
- Fix KVM PR on 32-bit, which was broken by some MMU code refactoring.
Thanks to: Alexander Graf, and Matt Evans.
* tag 'powerpc-5.18-5' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
KVM: PPC: Book3S PR: Enable MSR_DR for switch_mmu_context()
pasta from the corresponding s390 code screwed up the address calculation
for marking the sub-pmd ranges via memset by omitting the ALIGN_DOWN() to
calculate the proper start address. It's a mystery why this code is not
generic and shared because there is nothing architecture specific in there,
but that's too intrusive for a backportable fix.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCgAxFiEEQp8+kY+LLUocC4bMphj1TA10mKEFAmKAxpUTHHRnbHhAbGlu
dXRyb25peC5kZQAKCRCmGPVMDXSYoce3EACRBl9gb+3gU/qXcjyM09AaqIYo084t
ewJnbsmvM7y0zCqgEKB7TKzQ7DEcrzz+woATWkEI3WiC12SYh3OAd8MfoTkp9p3n
RlGtlqXozus0fppbkiXUyrOcWZjAFsTXpKNqZr1xTDaAJjQYlhgZKo7kedUDhe2N
5IX5ss/cZM/mnUR+AFY55jQR6pEnMY3qjC5vTVd/nqPIo8T6ZvLmmXdm8HnF1f+Y
a64h9PpvjOHfGw+ljFaMUtIH6JEpyIomai1VUFbhYyaiTVFI2AZVkvuHS2Pg18/R
NPWDjNozd9PBRlYcvXWmFyNCe4CuCAq6hy3IctVUUINVg7+/68mRoLxnFaWYaQcx
dl1bUE0F6I1XWRxLMx7uUWHffVyY8bomPB2koNII+AqgMOoKaUT1pNWPQzSQw0aw
Etjb2pVj9sfJ84VOfzlh7SObAU/Bf7lCXNUpNXvEPH71L/B4cIe+XpvWgNB1Ezpz
gXX6TLxmlPnwJokmeQ/gnO+bWGsjBRNu+cCsLHu2MGFuFJyPePhBMNvfnBv/A0jG
9lTq9zztiWJO2iu/TC/wRA21SBMvmipz23DIdv5Jhl0b+mP/qOSPQpZu9P3bRPIu
C4X8nQLP4DDF4juRJtgFqKdfI9A9h50phnvrOaOPn7Lnrx99Hbg0/2h9bU7lA2Ly
qe9+nz/i5CAC6w==
=f+jf
-----END PGP SIGNATURE-----
Merge tag 'x86-urgent-2022-05-15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fix from Thomas Gleixner:
"A single fix for the handling of unpopulated sub-pmd spaces.
The copy & pasta from the corresponding s390 code screwed up the
address calculation for marking the sub-pmd ranges via memset by
omitting the ALIGN_DOWN() to calculate the proper start address.
It's a mystery why this code is not generic and shared because there
is nothing architecture specific in there, but that's too intrusive
for a backportable fix"
* tag 'x86-urgent-2022-05-15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/mm: Fix marking of unused sub-pmd ranges
in the middle of the arguments. This reordering broke BPF programs which
relied on the old argument list. While tracepoints are not considered
stable ABI, it's not trivial to make BPF cope with such a change, but it's
being worked on. For now restore the original argument order and move the
new argument to the end of the argument list.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCgAxFiEEQp8+kY+LLUocC4bMphj1TA10mKEFAmKAxKQTHHRnbHhAbGlu
dXRyb25peC5kZQAKCRCmGPVMDXSYoThID/4jp/8GiKsf1jPgKkU39Yw7qAePzObQ
V9K2XLxSwH27D+UpmOPODnckzHJMtX0M4Z+sGMgGSPe/IvOVj+NEmUiQGU29sDwg
T7If2FSHMutPCB9QL26kxjmebU+SdllRwrJylOA1ZNduunczxKlpATJ5vneCC/Qt
D5VpB3XlwT31pd9UdoW/kV5uQK6bFR7qREWXhONZ+HyzsKJdV0vGe2ZX6U7ek2/d
XJxETE1eXlsMr+2VY5lkxhr596uPJgDAM9g+OknO/Lal/I7WoUchDN2giItzn6RY
XWxPK85mE59MwTa6PQCJcO8A7r2KcHfGrbFVjA9h1jhREtsZigb9ZemDgQ+s8goT
znIIlTO2l7ed2VDMU/mt3zZuS0rMshn/8Axk+AN3N6gKffV6F4q0BpZUUccGe+FM
tfQ34YGmMKx6uuyHPPZCQd1buJuDuXNyZF7XFO3uxv9BGt3x42aswAbx1zYIV+ZR
Uj/Vnojoc1aBdffVSUL0he+vjutYixx4gb8nh0ZFa5FTe70XDvPGTUTTOSW6BOq0
yiFOWtG8MbziVBDE2iKmfUMT+dPQd0+PW8szk8J9yOJyOnTu9y6KkyWl2JRllSxT
Qv7icnMN5P1xqN/c4P+8Iq0CrVItyxMJ0Ouc29tsNPHYkzsBo4c0XAn94mib1O17
zyJYW0F9UVHOSg==
=6Bvx
-----END PGP SIGNATURE-----
Merge tag 'sched-urgent-2022-05-15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull scheduler fix from Thomas Gleixner:
"The recent expansion of the sched switch tracepoint inserted a new
argument in the middle of the arguments. This reordering broke BPF
programs which relied on the old argument list.
While tracepoints are not considered stable ABI, it's not trivial to
make BPF cope with such a change, but it's being worked on. For now
restore the original argument order and move the new argument to the
end of the argument list"
* tag 'sched-urgent-2022-05-15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched/tracing: Append prev_state to tp args instead
interrupt code. The consolidation of the interrupt handler invocation code
added an unconditional warning when generic_handle_domain_irq() is invoked
from outside hard interrupt context. That's overbroad as the requirement
for invoking these handlers in hard interrupt context is only required for
certain interrupt types. The subsequently called code already contains a
warning which triggers conditionally for interrupt chips which indicate
this requirement in their properties. Remove the overbroad one.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCgAxFiEEQp8+kY+LLUocC4bMphj1TA10mKEFAmKAwyATHHRnbHhAbGlu
dXRyb25peC5kZQAKCRCmGPVMDXSYod4+D/9KrvIKGNSRKThw1zx4w1FzeOtRjhiT
HdwiNENKUhClWQHTzfv1xHOEv1hFVTuuz5tP2zIfzkKrDe1/dijZY9P/QvdEhp+s
idRzxaclWlxsxv4K8zqD1i/0klQ91YBA5aADgn4t1vY4WdWtJpbkFW8tndoAUAZR
THrFBGrvBdhjsSwK5VVfZcwNNeIh0lGG83vE8zPnzI7fbNxuAa1pI9bAigSa9jIT
zYcMm+mmC7eIdjeLD/Vx5Rujn3/MOLfmAfv9TwNIH2heQo6RwtINt0mzuDqKibOh
ly6T1Ol12WQuOLy5dYHglvogAzhJP49RbsQHCxU9S7BaWqcVfHuN88WhU/JXgfHn
UGdE3ppJpNHk/IqGSUyilDUzXgR9YH3j+XOYNnG2PidDWl5aPwuU1h9L7wdJnDZy
5Ou6JVmQjYc2+A6YeCZsNl+FdyvWpH+Gc/oGi09Saf1kCFuAVW11mkhRFHawWfHW
SZRpbSWxE+v0QFDd6T+IajSEwifw4+Ua8yjxRUU1dpsTcxHdFxGBlFFIebeYXlzJ
Xx2fASyCdlMzlEj7qegU2Y67yn0+yQjziZLaOCMtDtbWFO9APV447lEb5FcImqgi
XTT2HHw5sPZpLLoCED2zRoAsrh+aK9rJyH9pWEoRYvxVgmO613Qkw8GVJSmm8mO+
tZraqHFkoTuxRg==
=pJj8
-----END PGP SIGNATURE-----
Merge tag 'irq-urgent-2022-05-15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull irq fix from Thomas Gleixner:
"A single fix for a recent (introduced in 5.16) regression in the core
interrupt code.
The consolidation of the interrupt handler invocation code added an
unconditional warning when generic_handle_domain_irq() is invoked from
outside hard interrupt context. That's overbroad as the requirement
for invoking these handlers in hard interrupt context is only required
for certain interrupt types. The subsequently called code already
contains a warning which triggers conditionally for interrupt chips
which indicate this requirement in their properties.
Remove the overbroad one"
* tag 'irq-urgent-2022-05-15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
genirq: Remove WARN_ON_ONCE() in generic_handle_domain_irq()
Will reported the following splat when running with Protected KVM
enabled:
[ 2.427181] ------------[ cut here ]------------
[ 2.427668] WARNING: CPU: 3 PID: 1 at arch/arm64/kvm/mmu.c:489 __create_hyp_private_mapping+0x118/0x1ac
[ 2.428424] Modules linked in:
[ 2.429040] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 5.18.0-rc2-00084-g8635adc4efc7 #1
[ 2.429589] Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
[ 2.430286] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 2.430734] pc : __create_hyp_private_mapping+0x118/0x1ac
[ 2.431091] lr : create_hyp_exec_mappings+0x40/0x80
[ 2.431377] sp : ffff80000803baf0
[ 2.431597] x29: ffff80000803bb00 x28: 0000000000000000 x27: 0000000000000000
[ 2.432156] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
[ 2.432561] x23: ffffcd96c343b000 x22: 0000000000000000 x21: ffff80000803bb40
[ 2.433004] x20: 0000000000000004 x19: 0000000000001800 x18: 0000000000000000
[ 2.433343] x17: 0003e68cf7efdd70 x16: 0000000000000004 x15: fffffc81f602a2c8
[ 2.434053] x14: ffffdf8380000000 x13: ffffcd9573200000 x12: ffffcd96c343b000
[ 2.434401] x11: 0000000000000004 x10: ffffcd96c1738000 x9 : 0000000000000004
[ 2.434812] x8 : ffff80000803bb40 x7 : 7f7f7f7f7f7f7f7f x6 : 544f422effff306b
[ 2.435136] x5 : 000000008020001e x4 : ffff207d80a88c00 x3 : 0000000000000005
[ 2.435480] x2 : 0000000000001800 x1 : 000000014f4ab800 x0 : 000000000badca11
[ 2.436149] Call trace:
[ 2.436600] __create_hyp_private_mapping+0x118/0x1ac
[ 2.437576] create_hyp_exec_mappings+0x40/0x80
[ 2.438180] kvm_init_vector_slots+0x180/0x194
[ 2.458941] kvm_arch_init+0x80/0x274
[ 2.459220] kvm_init+0x48/0x354
[ 2.459416] arm_init+0x20/0x2c
[ 2.459601] do_one_initcall+0xbc/0x238
[ 2.459809] do_initcall_level+0x94/0xb4
[ 2.460043] do_initcalls+0x54/0x94
[ 2.460228] do_basic_setup+0x1c/0x28
[ 2.460407] kernel_init_freeable+0x110/0x178
[ 2.460610] kernel_init+0x20/0x1a0
[ 2.460817] ret_from_fork+0x10/0x20
[ 2.461274] ---[ end trace 0000000000000000 ]---
Indeed, the Protected KVM mode promotes __create_hyp_private_mapping()
to a hypercall as EL1 no longer has access to the hypervisor's stage-1
page-table. However, the call from kvm_init_vector_slots() happens after
pKVM has been initialized on the primary CPU, but before it has been
initialized on secondaries. As such, if the KVM initcall procedure is
migrated from one CPU to another in this window, the hypercall may end up
running on a CPU for which EL2 has not been initialized.
Fortunately, the pKVM hypervisor doesn't rely on the host to re-map the
vectors in the private range, so the hypercall in question is in fact
superfluous. Skip it when pKVM is enabled.
Reported-by: Will Deacon <will@kernel.org>
Signed-off-by: Quentin Perret <qperret@google.com>
[maz: simplified the checks slightly]
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220513092607.35233-1-qperret@google.com
When adding support for the slightly wonky Apple M1, we had to
populate ID_AA64PFR0_EL1.GIC==1 to present something to the guest,
as the HW itself doesn't advertise the feature.
However, we gated this on the in-kernel irqchip being created.
This causes some trouble for QEMU, which snapshots the state of
the registers before creating a virtual GIC, and then tries to
restore these registers once the GIC has been created. Obviously,
between the two stages, ID_AA64PFR0_EL1.GIC has changed value,
and the write fails.
The fix is to actually emulate the HW, and always populate the
field if the HW is capable of it.
Fixes: 562e530fd770 ("KVM: arm64: Force ID_AA64PFR0_EL1.GIC=1 when exposing a virtual GICv3")
Cc: stable@vger.kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Oliver Upton <oupton@google.com>
Link: https://lore.kernel.org/r/20220503211424.3375263-1-maz@kernel.org
Now when Intel Elkhart Lake uses again common bit timing and there are
no other users for custom bit timing, we can bring back the changes
done by the commit 0ddd83fbebbc ("can: m_can: remove support for
custom bit timing").
This effectively reverts commit ea768b2ffec6 ("Revert "can: m_can:
remove support for custom bit timing"") while taking into account
commit ea22ba40debe ("can: m_can: make custom bittiming fields const")
and commit 7d4a101c0bd3 ("can: dev: add sanity check in
can_set_static_ctrlmode()").
Link: https://lore.kernel.org/all/20220512124144.536850-2-jarkko.nikula@linux.intel.com
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
This reverts commit 0e8ffdf3b86dfd44b651f91b12fcae76c25c453b.
Commit 0e8ffdf3b86d ("can: m_can: pci: use custom bit timings for
Elkhart Lake") broke the test case using bitrate switching.
| ip link set can0 up type can bitrate 500000 dbitrate 4000000 fd on
| ip link set can1 up type can bitrate 500000 dbitrate 4000000 fd on
| candump can0 &
| cangen can1 -I 0x800 -L 64 -e -fb \
| -D 11223344deadbeef55667788feedf00daabbccdd44332211 -n 1 -v -v
Above commit does everything correctly according to the datasheet.
However datasheet wasn't correct.
I got confirmation from hardware engineers that the actual CAN
hardware on Intel Elkhart Lake is based on M_CAN version v3.2.0.
Datasheet was mirroring values from an another specification which was
based on earlier M_CAN version leading to wrong bit timings.
Therefore revert the commit and switch back to common bit timings.
Fixes: ea4c1787685d ("can: m_can: pci: use custom bit timings for Elkhart Lake")
Link: https://lore.kernel.org/all/20220512124144.536850-1-jarkko.nikula@linux.intel.com
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Reported-by: Chee Hou Ong <chee.houx.ong@intel.com>
Reported-by: Aman Kumar <aman.kumar@intel.com>
Reported-by: Pallavi Kumari <kumari.pallavi@intel.com>
Cc: <stable@vger.kernel.org> # v5.16+
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
- Fix two NDEBUG warnings in 'perf bench numa'.
- Fix ARM coresight `perf test` failure.
- Sync linux/kvm.h with the kernel sources.
- Add James and Mike as Arm64 performance events reviewers.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQR2GiIUctdOfX2qHhGyPKLppCJ+JwUCYn/zSgAKCRCyPKLppCJ+
J05jAP4gwHLXP1jcyixLRPrJc1tZjJlRSqdOkQn7n1wE4okh4QEA/2k4k+s4Onn6
YMCAJFFgzqi/U77uN5IBX3dLWZ02SAg=
=albT
-----END PGP SIGNATURE-----
Merge tag 'perf-tools-fixes-for-v5.18-2022-05-14' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux
Pull perf tools fixes from Arnaldo Carvalho de Melo:
- Fix two NDEBUG warnings in 'perf bench numa'
- Fix ARM coresight `perf test` failure
- Sync linux/kvm.h with the kernel sources
- Add James and Mike as Arm64 performance events reviewers
* tag 'perf-tools-fixes-for-v5.18-2022-05-14' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux:
MAINTAINERS: Add James and Mike as Arm64 performance events reviewers
tools headers UAPI: Sync linux/kvm.h with the kernel sources
perf tests: Fix coresight `perf test` failure.
perf bench: Fix two numa NDEBUG warnings
In gem_rx_refill rx_prepared_head is incremented at the beginning of
the while loop preparing the skb and data buffers. If the skb or data
buffer allocation fails, this BD will be unusable BDs until the head
loops back to the same BD (and obviously buffer allocation succeeds).
In the unlikely event that there's a string of allocation failures,
there will be an equal number of unusable BDs and an inconsistent RX
BD chain. Hence increment the head at the end of the while loop to be
clean.
Fixes: 4df95131ea80 ("net/macb: change RX path for GEM")
Signed-off-by: Harini Katakam <harini.katakam@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/20220512171900.32593-1-harini.katakam@xilinx.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Mat Martineau says:
====================
mptcp: Subflow accounting fix
This series contains a bug fix affecting the in-kernel path manager
(patch 1), where closing subflows would sometimes not adjust the PM's
count of active subflows. Patch 2 updates the selftests to exercise the
new code.
====================
Link: https://lore.kernel.org/r/20220512232642.541301-1-mathew.j.martineau@linux.intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add and delete a bunch of endpoints and verify the
respect of configured limits.
This covers the codepath introduced by the previous patch.
Fixes: 69c6ce7b6eca ("selftests: mptcp: add implicit endpoint test case")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
If the PM closes a fully established MPJ subflow or the subflow
creation errors out in it's early stage the subflows counter is
not bumped accordingly.
This change adds the missing accounting, additionally taking care
of updating accordingly the 'accept_subflow' flag.
Fixes: a88c9e496937 ("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: Jakub Kicinski <kuba@kernel.org>
fbdev:
- revert NULL deref fix that turned into a use-after-free
- prevent use-after-free in fbdev
- efifb/simplefb/vesafb: fix cleanup paths to avoid use-after-frees
dma-buf:
- fix panic in stats setup
vc4:
- fix hdmi build
nouveau:
- tegra iommu present fix
- fix leak in backlight name
vmwgfx:
- Black screen due to fences using FIFO checks on SVGA3
- Random black screens on boot due to uninitialized drm_mode_fb_cmd2
- Hangs on SVGA3 due to command buffers being used with gbobjects
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEEKbZHaGwW9KfbeusDHTzWXnEhr4FAmJ+37oACgkQDHTzWXnE
hr4ctRAAn4ew42dIcIySrU5OdXnSKkT3172SqI02w84lT3vTNFgfr7PMyeP0DGg6
64l1OHl/NpGXA53UaUJ/uLIp/qctg56YOUeQYj1OiAilqmmauHJlBgZF4czDl88W
gmz4LLdM8E0UP10LVDe60xqXIr6WEFxUlv1E6gu4Y9vv7EKTDtRsfBOvrkvPQKOJ
v6Y6iyulWQAk1KdiCxuKnQxA8/Pvk1bgE+gNdemX8ebwSr8i0UMi+JfpBxSeQXVw
Ot4AW9zWu1gDYden9D+zQTfcCEIrfDKyEHOz3+JHQXHUrW3HsYlCH/PfDCH0pS6w
fKjOGDVhmnU5oAElKzz1ipDVP+x2b8T9lXXWkI8TMQyk5NIgdBwO8nz1vPRgcyQJ
aoORiurmONxv7Hacf3xq1+4iLrkCnUFfDmDSYC1fKjomgcinBkvBjjAgGPZQ/rv0
cL0FAE+SQC1agku6PoWur5C5QZWBEnrSkFBBjEJRmdM26HoPJVvvzwh/MaT2vvhd
gk8iBijA3jKR+Oummv0IypsOblU8rNfl6kr4s1nxnOUDYvly+942MPw3yNXfHRmh
Vi7s2AeRcJzrsy0+gmCr62+cH00/cHPHfMde9c1r6ekVp+TCA2/nkUgt8WQf2PIq
OG5jvIqdNVGqDNXexS1kfrRB9KMXf/T83h/brqFDuMk5JhPlub8=
=wF/s
-----END PGP SIGNATURE-----
Merge tag 'drm-fixes-2022-05-14' of git://anongit.freedesktop.org/drm/drm
Pull more drm fixes from Dave Airlie:
"Turns out I was right, some fixes hadn't made it to me yet. The vmwgfx
ones also popped up later, but all seem like bad enough things to fix.
The dma-buf, vc4 and nouveau ones are all pretty small.
The fbdev fixes are a bit more complicated: a fix to cleanup fbdev
devices properly, uncovered some use-after-free bugs in existing
drivers. Then the fix for those bugs wasn't correct. This reverts that
fix, and puts the proper fixes in place in the drivers to avoid the
use-after-frees.
This has had a fair number of eyes on it at this stage, and I'm
confident enough that it puts things in the right place, and is less
dangerous than reverting our way out of the initial change at this
stage.
fbdev:
- revert NULL deref fix that turned into a use-after-free
- prevent use-after-free in fbdev
- efifb/simplefb/vesafb: fix cleanup paths to avoid use-after-frees
dma-buf:
- fix panic in stats setup
vc4:
- fix hdmi build
nouveau:
- tegra iommu present fix
- fix leak in backlight name
vmwgfx:
- Black screen due to fences using FIFO checks on SVGA3
- Random black screens on boot due to uninitialized drm_mode_fb_cmd2
- Hangs on SVGA3 due to command buffers being used with gbobjects"
* tag 'drm-fixes-2022-05-14' of git://anongit.freedesktop.org/drm/drm:
drm/vmwgfx: Disable command buffers on svga3 without gbobjects
drm/vmwgfx: Initialize drm_mode_fb_cmd2
drm/vmwgfx: Fix fencing on SVGAv3
drm/vc4: hdmi: Fix build error for implicit function declaration
dma-buf: call dma_buf_stats_setup after dmabuf is in valid list
fbdev: efifb: Fix a use-after-free due early fb_info cleanup
drm/nouveau: Fix a potential theorical leak in nouveau_get_backlight_name()
drm/nouveau/tegra: Stop using iommu_present()
fbdev: vesafb: Cleanup fb_info in .fb_destroy rather than .remove
fbdev: efifb: Cleanup fb_info in .fb_destroy rather than .remove
fbdev: simplefb: Cleanup fb_info in .fb_destroy rather than .remove
fbdev: Prevent possible use-after-free in fb_release()
Revert "fbdev: Make fb_release() return -ENODEV if fbdev was unregistered"
The manual describes function 0x6 of pin PA2 as "SPI1_CLK", so change
the comment to reflect that.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://lore.kernel.org/r/20220504170736.2669595-1-andre.przywara@arm.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Change suniv f1c100s pinctrl,PD14 multiplexing function lvds1 to uart2
When the pin PD13 and PD14 is setting up to uart2 function in dts,
there's an error occurred:
1c20800.pinctrl: unsupported function uart2 on pin PD14
Because 'uart2' is not any one multiplexing option of PD14,
and pinctrl don't know how to configure it.
So change the pin PD14 lvds1 function to uart2.
Signed-off-by: IotaHydrae <writeforever@foxmail.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Link: https://lore.kernel.org/r/tencent_70C1308DDA794C81CAEF389049055BACEC09@qq.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Before commit 322cff70d46c the fifo_time member of requests on a dispatch
list was not used. Commit 322cff70d46c introduces code that reads the
fifo_time member of requests on dispatch lists. Hence this patch that sets
the fifo_time member when adding a request to a dispatch list.
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ming Lei <ming.lei@redhat.com>
Cc: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Fixes: 322cff70d46c ("block/mq-deadline: Prioritize high-priority requests")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Link: https://lore.kernel.org/r/20220513171307.32564-1-bvanassche@acm.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
iommu detection improvement for nouveau, a memory leak fix for nouveau,
pointer dereference fix for dma_buf_file_release(), and a build breakage
fix for vc4
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCYn4I8QAKCRDj7w1vZxhR
xTQqAQCERNogpvxEuKGk1643nNiPtDLbYcwJMifqa7sQIQk13AD9EKR9oV+JyIZj
2tS06uFF1qWQeXAgS8wGToirZ2E3Fgo=
=a0hl
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-fixes-2022-05-13' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
Multiple fixes to fbdev to address a regression at unregistration, an
iommu detection improvement for nouveau, a memory leak fix for nouveau,
pointer dereference fix for dma_buf_file_release(), and a build breakage
fix for vc4
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220513073044.ymayac7x7bzatrt7@houat
- Fix filesystem block deallocation for short writes.
- Stop using glock holder auto-demotion for now.
- Get rid of buffered writes inefficiencies due to page
faults being disabled.
- Minor other cleanups.
-----BEGIN PGP SIGNATURE-----
iQJIBAABCAAyFiEEJZs3krPW0xkhLMTc1b+f6wMTZToFAmJ+wL4UHGFncnVlbmJh
QHJlZGhhdC5jb20ACgkQ1b+f6wMTZTqNkRAAuBc4oJ3Wkp/dkfF6MDY9DXqCzhQo
TodFIdEQvOUtncYBljE6DZQ9MT1sRvwxDe0nIjErFQzHYcW88zczILWOBRhrhlci
kANL6JtjSvtE3kecvR9I3nZX44aDETJliV3FX8n7vDSNMTIwjzW38d0XmDLX9t8F
bTEFv3rKsUzgcGaxpeQe7mzoQPi910WFPO/pos2ghuZwB1QEpdBrCESz4XB+OwKM
+V+8nooHvYp8T+2AzrBM6hBgsYelrBPRXlz6cYEjWY2FQuvQk/thX+zO2dvXCsPA
uNWJTCKJEsufWflPNI2ugZ9TVneIU1umGACoEHteeRvG6Qsg6K4Kf0EJEFf6Y0Tg
PKUJLUcdi0suS8UuUCBTAVAgCv9+ueLhIbbFeRkbHjxSjET7NQl2gbkfY2V1RsFt
yNFLMGU01xsb1YylncY4xQc9WVMDbPsdv1KGDF75njchuHZXhfg00ezPQys4Uy5R
0EUwqoPYNePV6VsoHLbU+kImf936VawP916yDiyflyz6UFSi5vNg7SwMqDrXpIxM
T8nNgrTC+Npv7T2xc8JhSFGv9T86nZXWjQTpDzV8onPvxdCLCT1cmm352aHqXd7+
wY9ZFJZ4iMoinYUkEzgySQW00+wK/AThQKQ6ImhLEvwxMUc6dJUnesVGkzLDGh9Z
KSfqgYzmlb2YdKY=
=FJq+
-----END PGP SIGNATURE-----
Merge tag 'gfs2-v5.18-rc4-fix3' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2
Pull gfs2 fixes from Andreas Gruenbacher:
"We've finally identified commit dc732906c245 ("gfs2: Introduce flag
for glock holder auto-demotion") to be the other cause of the
filesystem corruption we've been seeing. This feature isn't strictly
necessary anymore, so we've decided to stop using it for now.
With this and the gfs_iomap_end rounding fix you've already seen
("gfs2: Fix filesystem block deallocation for short writes" in this
pull request), we're corruption free again now.
- Fix filesystem block deallocation for short writes.
- Stop using glock holder auto-demotion for now.
- Get rid of buffered writes inefficiencies due to page faults being
disabled.
- Minor other cleanups"
* tag 'gfs2-v5.18-rc4-fix3' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2:
gfs2: Stop using glock holder auto-demotion for now
gfs2: buffered write prefaulting
gfs2: Align read and write chunks to the page cache
gfs2: Pull return value test out of should_fault_in_pages
gfs2: Clean up use of fault_in_iov_iter_{read,write}able
gfs2: Variable rename
gfs2: Fix filesystem block deallocation for short writes
We're having unresolved issues with the glock holder auto-demotion mechanism
introduced in commit dc732906c245. This mechanism was assumed to be essential
for avoiding frequent short reads and writes until commit 296abc0d91d8
("gfs2: No short reads or writes upon glock contention"). Since then,
when the inode glock is lost, it is simply re-acquired and the operation
is resumed. This means that apart from the performance penalty, we
might as well drop the inode glock before faulting in pages, and
re-acquire it afterwards.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
In gfs2_file_buffered_write, to increase the likelihood that all the
user memory we're trying to write will be resident in memory, carry out
the write in chunks and fault in each chunk of user memory before trying
to write it. Otherwise, some workloads will trigger frequent short
"internal" writes, causing filesystem blocks to be allocated and then
partially deallocated again when writing into holes, which is wasteful
and breaks reservations.
Neither the chunked writes nor any of the short "internal" writes are
user visible.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Four fixes, all in drivers. These patches mosly fix error legs and
exceptional conditions (scsi_dh_alua, qla2xxx). The lpfc fixes are
for coding issues with lpfc features.
Signed-off-by: James E.J. Bottomley <jejb@linux.ibm.com>
-----BEGIN PGP SIGNATURE-----
iJwEABMIAEQWIQTnYEDbdso9F2cI+arnQslM7pishQUCYn6p/SYcamFtZXMuYm90
dG9tbGV5QGhhbnNlbnBhcnRuZXJzaGlwLmNvbQAKCRDnQslM7pishUK2AQDUTr6B
qqMA9vgYzw7PcqOmWhR8WjStbJwmNsHImFvsigEA1ZG59Pf6UiAo8SFArhFDo7M9
ByFqhdka8gw0Z1fAsJM=
=od7V
-----END PGP SIGNATURE-----
Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"Four fixes, all in drivers.
These patches mosly fix error legs and exceptional conditions
(scsi_dh_alua, qla2xxx). The lpfc fixes are for coding issues with
lpfc features"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: lpfc: Correct BDE DMA address assignment for GEN_REQ_WQE
scsi: lpfc: Fix split code for FLOGI on FCoE
scsi: qla2xxx: Fix missed DMA unmap for aborted commands
scsi: scsi_dh_alua: Properly handle the ALUA transitioning state
Align the chunks that reads and writes are carried out in to the page
cache rather than the user buffers. This will be more efficient in
general, especially for allocating writes. Optimizing the case that the
user buffer is gfs2 backed isn't very useful; we only need to make sure
we won't deadlock.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Pull the return value test of the previous read or write operation out
of should_fault_in_pages(). In a following patch, we'll fault in pages
before the I/O and there will be no return value to check.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Instead of counting the number of bytes read from the filesystem,
functions gfs2_file_direct_read and gfs2_file_read_iter count the number
of bytes written into the user buffer. Conversely, functions
gfs2_file_direct_write and gfs2_file_buffered_write count the number of
bytes read from the user buffer. This is nothing but confusing, so
change the read functions to count how many bytes they have read, and
the write functions to count how many bytes they have written.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
When a write cannot be carried out in full, gfs2_iomap_end() releases
blocks that have been allocated for this write but haven't been used.
To compute the end of the allocation, gfs2_iomap_end() incorrectly
rounded the end of the attempted write down to the next block boundary
to arrive at the end of the allocation. It would have to round up, but
the end of the allocation is also available as iomap->offset +
iomap->length, so just use that instead.
In addition, use round_up() for computing the start of the unused range.
Fixes: 64bc06bb32ee ("gfs2: iomap buffered write support")
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
preserve SELinux context on newly created files and to avoid improper
usage of folio->private field which triggered BUG_ONs, both marked for
stable.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCAAxFiEEydHwtzie9C7TfviiSn/eOAIR84sFAmJ+kC4THGlkcnlvbW92
QGdtYWlsLmNvbQAKCRBKf944AhHzi0dJB/9tCG5VsOa8wyh/eR6HZyAHAGtXEnPB
qUn+bOvsRFw65GorwvbQw5fgXrQSaxzEgYuOEuCKOCA1KUxpYTGwYMhZIGNS0ZQm
251MyfGl3+aahe3H2pAkbuk8HnUq+989BPiRzwpTi0vZMDZNy1nyuE7VK+Nw/77w
E+swcFeyvmimKSlXURH6LQFzamxcnTdFoGRL1cc+97xOFSmbq3JSS+ZhrHhlZEyi
7C5tIfz8BtNGswCh2HfHhmFWxBAe0GWll6SqvKq2go/1Cg4UUiCn5BMsGCAYnL3G
eFnt3n7b3NARfSdoI+OCWa5yVERRDy7c4zxzyqdIxLKI1LVhXRhHqdaR
=73K4
-----END PGP SIGNATURE-----
Merge tag 'ceph-for-5.18-rc7' of https://github.com/ceph/ceph-client
Pull ceph fix from Ilya Dryomov:
"Two fixes to properly maintain xattrs on async creates and thus
preserve SELinux context on newly created files and to avoid improper
usage of folio->private field which triggered BUG_ONs.
Both marked for stable"
* tag 'ceph-for-5.18-rc7' of https://github.com/ceph/ceph-client:
ceph: check folio PG_private bit instead of folio->private
ceph: fix setting of xattrs on async created inodes
Highlights include:
Stable fixes:
- SUNRPC: Ensure that the gssproxy client can start in a connected state
Bugfixes:
- Revert "SUNRPC: Ensure gss-proxy connects on setup"
- nfs: fix broken handling of the softreval mount option
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEESQctxSBg8JpV8KqEZwvnipYKAPIFAmJ+j5kACgkQZwvnipYK
APIQag/+JXtDt9xo0SsGTMJ2PJArnRoyd3QcZjJtoabaZTylZyILZ20sxvt/jgby
miOKrI+bbsykbrwQijRLF/Yys1G+iMBzSWy4lpJ9eH4AVkfjr5qqauRbPobo/ZiI
i5fDLR84FlzKYWBY1Nv6YE5VREukIlXbrq7KWe/HoS7/hSAamhkUv+a0M8iNLGO4
QtH7+M0iBZTI9yM4gFAcMAANV21SxvjqP1z62kbCp00qO2mL0PgF/2pxC9WgX24/
EZX037ykzKFkjgWfzT8+/eIfCQGIPi/9e6Ir4Bc99psVFOYd1YxkTLBycNwm1VOz
5RLORbURDVMPQH2/qZ57u7B0gJF76UZM4pH3gv+i9nFhoUqf3kFZAOy48MZEFz3X
sPiQZLck63mvO9Bd3QX6pFZc0datiYmhuXRknjxV6Bz/Y41y3NzeJeX4r88s4q7l
tisZDmaIm0Q+H07QOTL0aCk456amP6XLnO1+nu/PSR/3ImwJSaOpypHx/BxDJUTG
TvpY1ouBZ8irfT6JrbfVnSdbedIZx4c+6btVw6mlT40edZF6M3r+3s8s2TU7x+co
uiBMB4Qj/C19zqcf/DziiL1PZEJPm3lk0fBHc6JIWCV4I3eYxQ5J4nFJsy8/jPm1
lTgreoHWfnYC3WhlxUk+N3+9X/9+iFEJUxqGYfANf8GFaGqcYVQ=
=/Yg+
-----END PGP SIGNATURE-----
Merge tag 'nfs-for-5.18-4' of git://git.linux-nfs.org/projects/trondmy/linux-nfs
Pull NFS client bugfixes from Trond Myklebust:
"One more pull request. There was a bug in the fix to ensure that gss-
proxy continues to work correctly after we fixed the AF_LOCAL socket
leak in the RPC code. This therefore reverts that broken patch, and
replaces it with one that works correctly.
Stable fixes:
- SUNRPC: Ensure that the gssproxy client can start in a connected
state
Bugfixes:
- Revert "SUNRPC: Ensure gss-proxy connects on setup"
- nfs: fix broken handling of the softreval mount option"
* tag 'nfs-for-5.18-4' of git://git.linux-nfs.org/projects/trondmy/linux-nfs:
nfs: fix broken handling of the softreval mount option
SUNRPC: Ensure that the gssproxy client can start in a connected state
Revert "SUNRPC: Ensure gss-proxy connects on setup"
