aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-08-16ipvs: fix racy memcpy in proc_do_sync_thresholdSishuai Gong1-0/+4
When two threads run proc_do_sync_threshold() in parallel, data races could happen between the two memcpy(): Thread-1 Thread-2 memcpy(val, valp, sizeof(val)); memcpy(valp, val, sizeof(val)); This race might mess up the (struct ctl_table *) table->data, so we add a mutex lock to serialize them. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Link: https://lore.kernel.org/netdev/[email protected]/ Signed-off-by: Sishuai Gong <[email protected]> Acked-by: Simon Horman <[email protected]> Acked-by: Julian Anastasov <[email protected]> Signed-off-by: Florian Westphal <[email protected]>
2023-08-16netfilter: set default timeout to 3 secs for sctp shutdown send and recv stateXin Long2-5/+5
In SCTP protocol, it is using the same timer (T2 timer) for SHUTDOWN and SHUTDOWN_ACK retransmission. However in sctp conntrack the default timeout value for SCTP_CONNTRACK_SHUTDOWN_ACK_SENT state is 3 secs while it's 300 msecs for SCTP_CONNTRACK_SHUTDOWN_SEND/RECV state. As Paolo Valerio noticed, this might cause unwanted expiration of the ct entry. In my test, with 1s tc netem delay set on the NAT path, after the SHUTDOWN is sent, the sctp ct entry enters SCTP_CONNTRACK_SHUTDOWN_SEND state. However, due to 300ms (too short) delay, when the SHUTDOWN_ACK is sent back from the peer, the sctp ct entry has expired and been deleted, and then the SHUTDOWN_ACK has to be dropped. Also, it is confusing these two sysctl options always show 0 due to all timeout values using sec as unit: net.netfilter.nf_conntrack_sctp_timeout_shutdown_recd = 0 net.netfilter.nf_conntrack_sctp_timeout_shutdown_sent = 0 This patch fixes it by also using 3 secs for sctp shutdown send and recv state in sctp conntrack, which is also RTO.initial value in SCTP protocol. Note that the very short time value for SCTP_CONNTRACK_SHUTDOWN_SEND/RECV was probably used for a rare scenario where SHUTDOWN is sent on 1st path but SHUTDOWN_ACK is replied on 2nd path, then a new connection started immediately on 1st path. So this patch also moves from SHUTDOWN_SEND/RECV to CLOSE when receiving INIT in the ORIGINAL direction. Fixes: 9fb9cbb1082d ("[NETFILTER]: Add nf_conntrack subsystem.") Reported-by: Paolo Valerio <[email protected]> Signed-off-by: Xin Long <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Florian Westphal <[email protected]>
2023-08-16netfilter: nf_tables: don't fail inserts if duplicate has expiredFlorian Westphal1-19/+4
nftables selftests fail: run-tests.sh testcases/sets/0044interval_overlap_0 Expected: 0-2 . 0-3, got: W: [FAILED] ./testcases/sets/0044interval_overlap_0: got 1 Insertion must ignore duplicate but expired entries. Moreover, there is a strange asymmetry in nft_pipapo_activate: It refetches the current element, whereas the other ->activate callbacks (bitmap, hash, rhash, rbtree) use elem->priv. Same for .remove: other set implementations take elem->priv, nft_pipapo_remove fetches elem->priv, then does a relookup, remove this. I suspect this was the reason for the change that prompted the removal of the expired check in pipapo_get() in the first place, but skipping exired elements there makes no sense to me, this helper is used for normal get requests, insertions (duplicate check) and deactivate callback. In first two cases expired elements must be skipped. For ->deactivate(), this gets called for DELSETELEM, so it seems to me that expired elements should be skipped as well, i.e. delete request should fail with -ENOENT error. Fixes: 24138933b97b ("netfilter: nf_tables: don't skip expired elements during walk") Signed-off-by: Florian Westphal <[email protected]>
2023-08-16netfilter: nf_tables: deactivate catchall elements in next generationFlorian Westphal1-0/+1
When flushing, individual set elements are disabled in the next generation via the ->flush callback. Catchall elements are not disabled. This is incorrect and may lead to double-deactivations of catchall elements which then results in memory leaks: WARNING: CPU: 1 PID: 3300 at include/net/netfilter/nf_tables.h:1172 nft_map_deactivate+0x549/0x730 CPU: 1 PID: 3300 Comm: nft Not tainted 6.5.0-rc5+ #60 RIP: 0010:nft_map_deactivate+0x549/0x730 [..] ? nft_map_deactivate+0x549/0x730 nf_tables_delset+0xb66/0xeb0 (the warn is due to nft_use_dec() detecting underflow). Fixes: aaa31047a6d2 ("netfilter: nftables: add catch-all set element support") Reported-by: lonial con <[email protected]> Signed-off-by: Florian Westphal <[email protected]>
2023-08-16netfilter: nf_tables: fix kdoc warnings after gc reworkFlorian Westphal2-1/+2
Jakub Kicinski says: We've got some new kdoc warnings here: net/netfilter/nft_set_pipapo.c:1557: warning: Function parameter or member '_set' not described in 'pipapo_gc' net/netfilter/nft_set_pipapo.c:1557: warning: Excess function parameter 'set' description in 'pipapo_gc' include/net/netfilter/nf_tables.h:577: warning: Function parameter or member 'dead' not described in 'nft_set' Fixes: 5f68718b34a5 ("netfilter: nf_tables: GC transaction API to avoid race with control plane") Fixes: f6c383b8c31a ("netfilter: nf_tables: adapt set backend to use GC transaction API") Reported-by: Jakub Kicinski <[email protected]> Closes: https://lore.kernel.org/netdev/[email protected]/ Signed-off-by: Florian Westphal <[email protected]>
2023-08-16netfilter: nf_tables: fix false-positive lockdep splatFlorian Westphal1-1/+12
->abort invocation may cause splat on debug kernels: WARNING: suspicious RCU usage net/netfilter/nft_set_pipapo.c:1697 suspicious rcu_dereference_check() usage! [..] rcu_scheduler_active = 2, debug_locks = 1 1 lock held by nft/133554: [..] (nft_net->commit_mutex){+.+.}-{3:3}, at: nf_tables_valid_genid [..] lockdep_rcu_suspicious+0x1ad/0x260 nft_pipapo_abort+0x145/0x180 __nf_tables_abort+0x5359/0x63d0 nf_tables_abort+0x24/0x40 nfnetlink_rcv+0x1a0a/0x22c0 netlink_unicast+0x73c/0x900 netlink_sendmsg+0x7f0/0xc20 ____sys_sendmsg+0x48d/0x760 Transaction mutex is held, so parallel updates are not possible. Switch to _protected and check mutex is held for lockdep enabled builds. Fixes: 212ed75dc5fb ("netfilter: nf_tables: integrate pipapo into commit protocol") Signed-off-by: Florian Westphal <[email protected]>
2023-08-15fbdev: goldfishfb: Do not check 0 for platform_get_irq()Zhu Wang1-2/+2
Since platform_get_irq() never returned zero, so it need not to check whether it returned zero, and we use the return error code of platform_get_irq() to replace the current return error code. Please refer to the commit a85a6c86c25b ("driver core: platform: Clarify that IRQ 0 is invalid") to get that platform_get_irq() never returned zero. Signed-off-by: Zhu Wang <[email protected]> Signed-off-by: Helge Deller <[email protected]>
2023-08-15fbdev: atmel_lcdfb: Remove redundant of_match_ptr()Ruan Jinjie1-1/+1
The driver depends on CONFIG_OF, it is not necessary to use of_match_ptr() here. Signed-off-by: Ruan Jinjie <[email protected]> Signed-off-by: Helge Deller <[email protected]>
2023-08-15fbdev: kyro: Remove unused declarationsYue Haibing1-12/+0
These declarations is never implemented since the beginning of git history. Signed-off-by: Yue Haibing <[email protected]> Signed-off-by: Helge Deller <[email protected]>
2023-08-15Merge tag 'parisc-for-6.5-rc7' of ↵Linus Torvalds1-24/+23
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux Pull parisc fix from Helge Deller: "Fix the parisc TLB ptlock checks so that they can be enabled together with the lightweight spinlock checks" * tag 'parisc-for-6.5-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: Fix CONFIG_TLB_PTLOCK to work with lightweight spinlock checks
2023-08-15Merge tag '6.5-rc6-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6Linus Torvalds2-8/+27
Pull smb client fixes from Steve French: "Three smb client fixes, all for stable: - fix for oops in unmount race with lease break of deferred close - debugging improvement for reconnect - fix for fscache deadlock (folio_wait_bit_common hang)" * tag '6.5-rc6-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6: smb3: display network namespace in debug information cifs: Release folio lock on fscache read hit. cifs: fix potential oops in cifs_oplock_break
2023-08-15Merge tag 'regulator-fix-v6.5-rc6' of ↵Linus Torvalds2-7/+7
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator Pull regulator fixes from Mark Brown: "Two small driver specific fixes: one incorrect definition for one of the Qualcomm regulators and better handling of poorly formed DTs in the DA9063 driver" * tag 'regulator-fix-v6.5-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: qcom-rpmh: Fix LDO 12 regulator for PM8550 regulator: da9063: better fix null deref with partial DT
2023-08-15net: fix the RTO timer retransmitting skb every 1ms if linear option is enabledJason Xing1-1/+3
In the real workload, I encountered an issue which could cause the RTO timer to retransmit the skb per 1ms with linear option enabled. The amount of lost-retransmitted skbs can go up to 1000+ instantly. The root cause is that if the icsk_rto happens to be zero in the 6th round (which is the TCP_THIN_LINEAR_RETRIES value), then it will always be zero due to the changed calculation method in tcp_retransmit_timer() as follows: icsk->icsk_rto = min(icsk->icsk_rto << 1, TCP_RTO_MAX); Above line could be converted to icsk->icsk_rto = min(0 << 1, TCP_RTO_MAX) = 0 Therefore, the timer expires so quickly without any doubt. I read through the RFC 6298 and found that the RTO value can be rounded up to a certain value, in Linux, say TCP_RTO_MIN as default, which is regarded as the lower bound in this patch as suggested by Eric. Fixes: 36e31b0af587 ("net: TCP thin linear timeouts") Suggested-by: Eric Dumazet <[email protected]> Signed-off-by: Jason Xing <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-08-15Merge tag 'asoc-fix-v6.5-rc6' of ↵Takashi Iwai12-35/+73
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v6.5 A fairly large collection of fixes here, mostly SOF and Intel related. The one core fix is Hans' change which reduces the log spam when working out new use cases for DPCM.
2023-08-15accel/qaic: Clean up integer overflow checking in map_user_pages()Dan Carpenter1-8/+18
The encode_dma() function has some validation on in_trans->size but it would be more clear to move those checks to find_and_map_user_pages(). The encode_dma() had two checks: if (in_trans->addr + in_trans->size < in_trans->addr || !in_trans->size) return -EINVAL; The in_trans->addr variable is the starting address. The in_trans->size variable is the total size of the transfer. The transfer can occur in parts and the resources->xferred_dma_size tracks how many bytes we have already transferred. This patch introduces a new variable "remaining" which represents the amount we want to transfer (in_trans->size) minus the amount we have already transferred (resources->xferred_dma_size). I have modified the check for if in_trans->size is zero to instead check if in_trans->size is less than resources->xferred_dma_size. If we have already transferred more bytes than in_trans->size then there are negative bytes remaining which doesn't make sense. If there are zero bytes remaining to be copied, just return success. The check in encode_dma() checked that "addr + size" could not overflow and barring a driver bug that should work, but it's easier to check if we do this in parts. First check that "in_trans->addr + resources->xferred_dma_size" is safe. Then check that "xfer_start_addr + remaining" is safe. My final concern was that we are dealing with u64 values but on 32bit systems the kmalloc() function will truncate the sizes to 32 bits. So I calculated "total = in_trans->size + offset_in_page(xfer_start_addr);" and returned -EINVAL if it were >= SIZE_MAX. This will not affect 64bit systems. Fixes: 129776ac2e38 ("accel/qaic: Add control path") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Jeffrey Hugo <[email protected]> Reviewed-by: Carl Vanderlip <[email protected]> Signed-off-by: Jeffrey Hugo <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-08-15accel/qaic: Fix slicing memory leakPranjal Ramajor Asha Kanojiya1-0/+1
The temporary buffer storing slicing configuration data from user is only freed on error. This is a memory leak. Free the buffer unconditionally. Fixes: ff13be830333 ("accel/qaic: Add datapath") Signed-off-by: Pranjal Ramajor Asha Kanojiya <[email protected]> Reviewed-by: Carl Vanderlip <[email protected]> Reviewed-by: Jeffrey Hugo <[email protected]> Signed-off-by: Jeffrey Hugo <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-08-15mmc: f-sdh30: fix order of function calls in sdhci_f_sdh30_removeYangtao Li1-4/+7
The order of function calls in sdhci_f_sdh30_remove is wrong, let's call sdhci_pltfm_unregister first. Cc: Uwe Kleine-König <[email protected]> Fixes: 5def5c1c15bf ("mmc: sdhci-f-sdh30: Replace with sdhci_pltfm") Signed-off-by: Yangtao Li <[email protected]> Reported-by: Uwe Kleine-König <[email protected]> Acked-by: Uwe Kleine-König <[email protected]> Acked-by: Adrian Hunter <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2023-08-15Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhostLinus Torvalds17-204/+515
Pull virtio fixes from Michael Tsirkin: "Just a bunch of bugfixes all over the place" * tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost: (26 commits) virtio-mem: check if the config changed before fake offlining memory virtio-mem: keep retrying on offline_and_remove_memory() errors in Sub Block Mode (SBM) virtio-mem: convert most offline_and_remove_memory() errors to -EBUSY virtio-mem: remove unsafe unplug in Big Block Mode (BBM) pds_vdpa: fix up debugfs feature bit printing pds_vdpa: alloc irq vectors on DRIVER_OK pds_vdpa: clean and reset vqs entries pds_vdpa: always allow offering VIRTIO_NET_F_MAC pds_vdpa: reset to vdpa specified mac virtio-net: Zero max_tx_vq field for VIRTIO_NET_CTRL_MQ_HASH_CONFIG case vdpa/mlx5: Fix crash on shutdown for when no ndev exists vdpa/mlx5: Delete control vq iotlb in destroy_mr only when necessary vdpa/mlx5: Fix mr->initialized semantics vdpa/mlx5: Correct default number of queues when MQ is on virtio-vdpa: Fix cpumask memory leak in virtio_vdpa_find_vqs() vduse: Use proper spinlock for IRQ injection vdpa: Enable strict validation for netlinks ops vdpa: Add max vqp attr to vdpa_nl_policy for nlattr length check vdpa: Add queue index attr to vdpa_nl_policy for nlattr length check vdpa: Add features attr to vdpa_nl_policy for nlattr length check ...
2023-08-14net: veth: Page pool creation error handling for existing pools onlyLiang Chen1-1/+2
The failure handling procedure destroys page pools for all queues, including those that haven't had their page pool created yet. this patch introduces necessary adjustments to prevent potential risks and inconsistency with the error handling behavior. Fixes: 0ebab78cbcbf ("net: veth: add page_pool for page recycling") Acked-by: Jesper Dangaard Brouer <[email protected]> Signed-off-by: Liang Chen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-08-14Merge branch 'octeon_ep-fixes-for-error-and-remove-paths'Jakub Kicinski2-5/+6
Michal Schmidt says: ==================== octeon_ep: fixes for error and remove paths I have an Octeon card that's misconfigured in a way that exposes a couple of bugs in the octeon_ep driver's error paths. It can reproduce the issues that patches 1 & 4 are fixing. Patches 2 & 3 are a result of reviewing the nearby code. ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-08-14octeon_ep: cancel queued works in probe error pathMichal Schmidt1-3/+4
If it fails to get the devices's MAC address, octep_probe exits while leaving the delayed work intr_poll_task queued. When the work later runs, it's a use after free. Move the cancelation of intr_poll_task from octep_remove into octep_device_cleanup. This does not change anything in the octep_remove flow, but octep_device_cleanup is called also in the octep_probe error path, where the cancelation is needed. Note that the cancelation of ctrl_mbox_task has to follow intr_poll_task's, because the ctrl_mbox_task may be queued by intr_poll_task. Fixes: 24d4333233b3 ("octeon_ep: poll for control messages") Signed-off-by: Michal Schmidt <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-08-14octeon_ep: cancel ctrl_mbox_task after intr_poll_taskMichal Schmidt1-1/+1
intr_poll_task may queue ctrl_mbox_task. The function octep_poll_non_ioq_interrupts_cn93_pf does this. When removing the driver and canceling these two works, cancel ctrl_mbox_task last to guarantee it does not run anymore. Fixes: 24d4333233b3 ("octeon_ep: poll for control messages") Signed-off-by: Michal Schmidt <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-08-14octeon_ep: cancel tx_timeout_task later in remove sequenceMichal Schmidt1-1/+1
tx_timeout_task is canceled too early when removing the driver. Nothing prevents .ndo_tx_timeout from triggering and queuing the work again. Better cancel it after the netdev is unregistered. It's harmless for octep_tx_timeout_task to run in the window between the unregistration and cancelation, because it checks netif_running. Fixes: 862cd659a6fb ("octeon_ep: Add driver framework and device initialization") Signed-off-by: Michal Schmidt <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-08-14octeon_ep: fix timeout value for waiting on mbox responseMichal Schmidt1-1/+1
The intention was to wait up to 500 ms for the mbox response. The third argument to wait_event_interruptible_timeout() is supposed to be the timeout duration. The driver mistakenly passed absolute time instead. Fixes: 577f0d1b1c5f ("octeon_ep: add separate mailbox command and response queues") Signed-off-by: Michal Schmidt <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-08-14net: macb: In ZynqMP resume always configure PS GTR for non-wakeup sourceRadhey Shyam Pandey1-3/+6
On Zynq UltraScale+ MPSoC ubuntu platform when systemctl issues suspend, network manager bring down the interface and goes into suspend. When it wakes up it again enables the interface. This leads to xilinx-psgtr "PLL lock timeout" on interface bringup, as the power management controller power down the entire FPD (including SERDES) if none of the FPD devices are in use and serdes is not initialized on resume. $ sudo rtcwake -m no -s 120 -v $ sudo systemctl suspend <this does ifconfig eth1 down> $ ifconfig eth1 up xilinx-psgtr fd400000.phy: lane 0 (type 10, protocol 5): PLL lock timeout phy phy-fd400000.phy.0: phy poweron failed --> -110 macb driver is called in this way: 1. macb_close: Stop network interface. In this function, it reset MACB IP and disables PHY and network interface. 2. macb_suspend: It is called in kernel suspend flow. But because network interface has been disabled(netif_running(ndev) is false), it does nothing and returns directly; 3. System goes into suspend state. Some time later, system is waken up by RTC wakeup device; 4. macb_resume: It does nothing because network interface has been disabled; 5. macb_open: It is called to enable network interface again. ethernet interface is initialized in this API but serdes which is power-off by PMUFW during FPD-off suspend is not initialized again and so we hit GT PLL lock issue on open. To resolve this PLL timeout issue always do PS GTR initialization when ethernet device is configured as non-wakeup source. Fixes: f22bd29ba19a ("net: macb: Fix ZynqMP SGMII non-wakeup source resume failure") Fixes: 8b73fa3ae02b ("net: macb: Added ZynqMP-specific initialization") Signed-off-by: Radhey Shyam Pandey <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-08-14sunrpc: set the bv_offset of first bvec in svc_tcp_sendmsgJeff Layton1-0/+3
svc_tcp_sendmsg used to factor in the xdr->page_base when sending pages, but commit 5df5dd03a8f7 ("sunrpc: Use sendmsg(MSG_SPLICE_PAGES) rather then sendpage") dropped that part of the handling. Fix it by setting the bv_offset of the first bvec. Fixes: 5df5dd03a8f7 ("sunrpc: Use sendmsg(MSG_SPLICE_PAGES) rather then sendpage") Signed-off-by: Jeff Layton <[email protected]> Signed-off-by: Chuck Lever <[email protected]>
2023-08-14i2c: bcm-iproc: Fix bcm_iproc_i2c_isr deadlock issueChengfeng Ye1-4/+7
iproc_i2c_rd_reg() and iproc_i2c_wr_reg() are called from both interrupt context (e.g. bcm_iproc_i2c_isr) and process context (e.g. bcm_iproc_i2c_suspend). Therefore, interrupts should be disabled to avoid potential deadlock. To prevent this scenario, use spin_lock_irqsave(). Fixes: 9a1038728037 ("i2c: iproc: add NIC I2C support") Signed-off-by: Chengfeng Ye <[email protected]> Acked-by: Ray Jui <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2023-08-14i2c: Update documentation to use .probe() againUwe Kleine-König1-1/+1
Since commit 03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") .probe() is the recommended callback to implement (again). Reflect this in the documentation and don't mention .probe_new() any more. Signed-off-by: Uwe Kleine-König <[email protected]> Reviewed-by: Jean Delvare <[email protected]> Reviewed-by: Javier Martinez Canillas <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2023-08-14drm/i915: fix display probe for IVB Q and IVB D GT2 serverJani Nikula1-3/+21
The current display probe is unable to differentiate between IVB Q and IVB D GT2 server, as they both have the same device id, but different subvendor and subdevice. This leads to the latter being misidentified as the former, and should just end up not having a display. However, the no display case returns a NULL as the display device info, and promptly oopses. As the IVB Q case is rare, and we're anyway moving towards GMD ID, handle the identification requiring subvendor and subdevice as a special case first, instead of unnecessarily growing the intel_display_ids[] array with subvendor and subdevice. [ 5.425298] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 5.426059] #PF: supervisor read access in kernel mode [ 5.426810] #PF: error_code(0x0000) - not-present page [ 5.427570] PGD 0 P4D 0 [ 5.428285] Oops: 0000 [#1] PREEMPT SMP PTI [ 5.429035] CPU: 0 PID: 137 Comm: (udev-worker) Not tainted 6.4.0-1-amd64 #1 Debian 6.4.4-1 [ 5.429759] Hardware name: HP HP Z220 SFF Workstation/HP Z220 SFF Workstation, BIOS 4.19-218-gb184e6e0a1 02/02/2023 [ 5.430485] RIP: 0010:intel_device_info_driver_create+0xf1/0x120 [i915] [ 5.431338] Code: 48 8b 97 80 1b 00 00 89 8f c0 1b 00 00 48 89 b7 b0 1b 00 00 48 89 97 b8 1b 00 00 0f b7 fd e8 76 e8 14 00 48 89 83 50 1b 00 00 <48> 8b 08 48 89 8b c4 1b 00 00 48 8b 48 08 48 89 8b cc 1b 00 00 8b [ 5.432920] RSP: 0018:ffffb8254044fb98 EFLAGS: 00010206 [ 5.433707] RAX: 0000000000000000 RBX: ffff923076e80000 RCX: 0000000000000000 [ 5.434494] RDX: 0000000000000260 RSI: 0000000100001000 RDI: 000000000000016a [ 5.435277] RBP: 000000000000016a R08: ffffb8254044fb00 R09: 0000000000000000 [ 5.436055] R10: ffff922d02761de8 R11: 00657361656c6572 R12: ffffffffc0e5d140 [ 5.436867] R13: ffff922d00b720d0 R14: 0000000076e80000 R15: ffff923078c0cae8 [ 5.437646] FS: 00007febd19a18c0(0000) GS:ffff92307c000000(0000) knlGS:0000000000000000 [ 5.438434] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 5.439218] CR2: 0000000000000000 CR3: 000000010256e002 CR4: 00000000001706f0 [ 5.440009] Call Trace: [ 5.440824] <TASK> [ 5.441611] ? __die+0x23/0x70 [ 5.442394] ? page_fault_oops+0x17d/0x4c0 [ 5.443173] ? exc_page_fault+0x7f/0x180 [ 5.443949] ? asm_exc_page_fault+0x26/0x30 [ 5.444756] ? intel_device_info_driver_create+0xf1/0x120 [i915] [ 5.445652] ? intel_device_info_driver_create+0xea/0x120 [i915] [ 5.446545] i915_driver_probe+0x7f/0xb60 [i915] [ 5.447431] ? drm_privacy_screen_get+0x15c/0x1a0 [drm] [ 5.448240] local_pci_probe+0x45/0xa0 [ 5.449013] pci_device_probe+0xc7/0x240 [ 5.449748] really_probe+0x19e/0x3e0 [ 5.450464] ? __pfx___driver_attach+0x10/0x10 [ 5.451172] __driver_probe_device+0x78/0x160 [ 5.451870] driver_probe_device+0x1f/0x90 [ 5.452601] __driver_attach+0xd2/0x1c0 [ 5.453293] bus_for_each_dev+0x88/0xd0 [ 5.453989] bus_add_driver+0x116/0x220 [ 5.454672] driver_register+0x59/0x100 [ 5.455336] i915_init+0x25/0xc0 [i915] [ 5.456104] ? __pfx_i915_init+0x10/0x10 [i915] [ 5.456882] do_one_initcall+0x5d/0x240 [ 5.457511] do_init_module+0x60/0x250 [ 5.458126] __do_sys_finit_module+0xac/0x120 [ 5.458721] do_syscall_64+0x60/0xc0 [ 5.459314] ? syscall_exit_to_user_mode+0x1b/0x40 [ 5.459897] ? do_syscall_64+0x6c/0xc0 [ 5.460510] entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 5.461082] RIP: 0033:0x7febd20b0eb9 [ 5.461648] Code: 08 89 e8 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 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 8b 0d 2f 1f 0d 00 f7 d8 64 89 01 48 [ 5.462905] RSP: 002b:00007fffabb1ba78 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 5.463554] RAX: ffffffffffffffda RBX: 0000561e6304f410 RCX: 00007febd20b0eb9 [ 5.464201] RDX: 0000000000000000 RSI: 00007febd2244f0d RDI: 0000000000000015 [ 5.464869] RBP: 00007febd2244f0d R08: 0000000000000000 R09: 000000000000000a [ 5.465512] R10: 0000000000000015 R11: 0000000000000246 R12: 0000000000020000 [ 5.466124] R13: 0000000000000000 R14: 0000561e63032b60 R15: 000000000000000a [ 5.466700] </TASK> [ 5.467271] Modules linked in: i915(+) drm_buddy video crc32_pclmul sr_mod hid_generic wmi crc32c_intel i2c_algo_bit sd_mod cdrom drm_display_helper cec usbhid rc_core ghash_clmulni_intel hid sha512_ssse3 ttm sha512_generic xhci_pci ehci_pci xhci_hcd ehci_hcd nvme ahci drm_kms_helper nvme_core libahci t10_pi libata psmouse aesni_intel scsi_mod crypto_simd i2c_i801 scsi_common crc64_rocksoft_generic cryptd i2c_smbus drm lpc_ich crc64_rocksoft crc_t10dif e1000e usbcore crct10dif_generic usb_common crct10dif_pclmul crc64 crct10dif_common button [ 5.469750] CR2: 0000000000000000 [ 5.470364] ---[ end trace 0000000000000000 ]--- [ 5.470971] RIP: 0010:intel_device_info_driver_create+0xf1/0x120 [i915] [ 5.471699] Code: 48 8b 97 80 1b 00 00 89 8f c0 1b 00 00 48 89 b7 b0 1b 00 00 48 89 97 b8 1b 00 00 0f b7 fd e8 76 e8 14 00 48 89 83 50 1b 00 00 <48> 8b 08 48 89 8b c4 1b 00 00 48 8b 48 08 48 89 8b cc 1b 00 00 8b [ 5.473034] RSP: 0018:ffffb8254044fb98 EFLAGS: 00010206 [ 5.473698] RAX: 0000000000000000 RBX: ffff923076e80000 RCX: 0000000000000000 [ 5.474371] RDX: 0000000000000260 RSI: 0000000100001000 RDI: 000000000000016a [ 5.475045] RBP: 000000000000016a R08: ffffb8254044fb00 R09: 0000000000000000 [ 5.475725] R10: ffff922d02761de8 R11: 00657361656c6572 R12: ffffffffc0e5d140 [ 5.476405] R13: ffff922d00b720d0 R14: 0000000076e80000 R15: ffff923078c0cae8 [ 5.477124] FS: 00007febd19a18c0(0000) GS:ffff92307c000000(0000) knlGS:0000000000000000 [ 5.477811] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 5.478499] CR2: 0000000000000000 CR3: 000000010256e002 CR4: 00000000001706f0 Fixes: 69d439818fe5 ("drm/i915/display: Make display responsible for probing its own IP") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8991 Cc: Matt Roper <[email protected]> Cc: Andrzej Hajda <[email protected]> Reviewed-by: Luca Coelho <[email protected]> Reviewed-by: Matt Roper <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 1435188307d128671f677eb908e165666dd83652) Signed-off-by: Rodrigo Vivi <[email protected]>
2023-08-14drm/i915/sdvo: fix panel_type initializationJani Nikula1-1/+1
Commit 3f9ffce5765d ("drm/i915: Do panel VBT init early if the VBT declares an explicit panel type") started using -1 as the value for unset panel_type. It gets initialized in intel_panel_init_alloc(), but the SDVO code never calls it. Call intel_panel_init_alloc() to initialize the panel, including the panel_type. Reported-by: Tomi Leppänen <[email protected]> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8896 Fixes: 3f9ffce5765d ("drm/i915: Do panel VBT init early if the VBT declares an explicit panel type") Cc: Ville Syrjälä <[email protected]> Cc: <[email protected]> # v6.1+ Reviewed-by: Uma Shankar <[email protected]> Tested-by: Tomi Leppänen <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 26e60294e8eacedc8ebb33405b2c375fd80e0900) Signed-off-by: Rodrigo Vivi <[email protected]>
2023-08-14drm/i915/guc/slpc: Restore efficient freq earlierVinay Belgaumkar1-8/+14
This should be done before the soft min/max frequencies are restored. When we disable the "Ignore efficient frequency" flag, GuC does not actually bring the requested freq down to RPn. Specifically, this scenario- - ignore efficient freq set to true - reduce min to RPn (from efficient) - suspend - resume (includes GuC load, restore soft min/max, restore efficient freq) - validate min freq has been resored to RPn This will fail if we didn't first restore(disable, in this case) efficient freq flag before setting the soft min frequency. v2: Bring the min freq down to RPn when we disable efficient freq (Rodrigo) Also made the change to set the min softlimit to RPn at init. Otherwise, we were storing RPe there. Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8736 Fixes: 55f9720dbf23 ("drm/i915/guc/slpc: Provide sysfs for efficient freq") Fixes: 95ccf312a1e4 ("drm/i915/guc/slpc: Allow SLPC to use efficient frequency") Signed-off-by: Vinay Belgaumkar <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: John Harrison <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 28e671114fb0f28f334fac8d0a6b9c395c7b0498) Signed-off-by: Rodrigo Vivi <[email protected]>
2023-08-14i2c: sun6i-p2wi: Fix an error message in probe()Dan Carpenter1-1/+2
The "ret" variable is uninitialized. It was the "p2wi->rstc" variable that was intended. We can also use the %pe string format to print the error code name instead of just the number. Fixes: 75ff8a340a81 ("i2c: sun6i-p2wi: Use devm_clk_get_enabled()") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2023-08-14btrfs: fix infinite directory readsFilipe Manana4-54/+84
The readdir implementation currently processes always up to the last index it finds. This however can result in an infinite loop if the directory has a large number of entries such that they won't all fit in the given buffer passed to the readdir callback, that is, dir_emit() returns a non-zero value. Because in that case readdir() will be called again and if in the meanwhile new directory entries were added and we still can't put all the remaining entries in the buffer, we keep repeating this over and over. The following C program and test script reproduce the problem: $ cat /mnt/readdir_prog.c #include <sys/types.h> #include <dirent.h> #include <stdio.h> int main(int argc, char *argv[]) { DIR *dir = opendir("."); struct dirent *dd; while ((dd = readdir(dir))) { printf("%s\n", dd->d_name); rename(dd->d_name, "TEMPFILE"); rename("TEMPFILE", dd->d_name); } closedir(dir); } $ gcc -o /mnt/readdir_prog /mnt/readdir_prog.c $ cat test.sh #!/bin/bash DEV=/dev/sdi MNT=/mnt/sdi mkfs.btrfs -f $DEV &> /dev/null #mkfs.xfs -f $DEV &> /dev/null #mkfs.ext4 -F $DEV &> /dev/null mount $DEV $MNT mkdir $MNT/testdir for ((i = 1; i <= 2000; i++)); do echo -n > $MNT/testdir/file_$i done cd $MNT/testdir /mnt/readdir_prog cd /mnt umount $MNT This behaviour is surprising to applications and it's unlike ext4, xfs, tmpfs, vfat and other filesystems, which always finish. In this case where new entries were added due to renames, some file names may be reported more than once, but this varies according to each filesystem - for example ext4 never reported the same file more than once while xfs reports the first 13 file names twice. So change our readdir implementation to track the last index number when opendir() is called and then make readdir() never process beyond that index number. This gives the same behaviour as ext4. Reported-by: Rob Landley <[email protected]> Link: https://lore.kernel.org/linux-btrfs/[email protected]/ Link: https://bugzilla.kernel.org/show_bug.cgi?id=217681 CC: [email protected] # 6.4+ Signed-off-by: Filipe Manana <[email protected]> Signed-off-by: David Sterba <[email protected]>
2023-08-14smb3: display network namespace in debug informationSteve French1-0/+10
We recently had problems where a network namespace was deleted causing hard to debug reconnect problems. To help deal with configuration issues like this it is useful to dump the network namespace to better debug what happened. So add this to information displayed in /proc/fs/cifs/DebugData for the server (and channels if mounted with multichannel). For example: Local Users To Server: 1 SecMode: 0x1 Req On Wire: 0 Net namespace: 4026531840 This can be easily compared with what is displayed for the processes on the system. For example /proc/1/ns/net in this case showed the same thing (see below), and we can see that the namespace is still valid in this example. 'net:[4026531840]' Cc: [email protected] Acked-by: Paulo Alcantara (SUSE) <[email protected]> Signed-off-by: Steve French <[email protected]>
2023-08-14i2c: hisi: Only handle the interrupt of the driver's transferYicong Yang1-0/+8
The controller may be shared with other port, for example the firmware. Handle the interrupt from other sources will cause crash since some data are not initialized. So only handle the interrupt of the driver's transfer and discard others. Fixes: d62fbdb99a85 ("i2c: add support for HiSilicon I2C controller") Signed-off-by: Yicong Yang <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wolfram Sang <[email protected]>
2023-08-14cifs: Release folio lock on fscache read hit.Russell Harmon via samba-technical1-1/+1
Under the current code, when cifs_readpage_worker is called, the call contract is that the callee should unlock the page. This is documented in the read_folio section of Documentation/filesystems/vfs.rst as: > The filesystem should unlock the folio once the read has completed, > whether it was successful or not. Without this change, when fscache is in use and cache hit occurs during a read, the page lock is leaked, producing the following stack on subsequent reads (via mmap) to the page: $ cat /proc/3890/task/12864/stack [<0>] folio_wait_bit_common+0x124/0x350 [<0>] filemap_read_folio+0xad/0xf0 [<0>] filemap_fault+0x8b1/0xab0 [<0>] __do_fault+0x39/0x150 [<0>] do_fault+0x25c/0x3e0 [<0>] __handle_mm_fault+0x6ca/0xc70 [<0>] handle_mm_fault+0xe9/0x350 [<0>] do_user_addr_fault+0x225/0x6c0 [<0>] exc_page_fault+0x84/0x1b0 [<0>] asm_exc_page_fault+0x27/0x30 This requires a reboot to resolve; it is a deadlock. Note however that the call to cifs_readpage_from_fscache does mark the page clean, but does not free the folio lock. This happens in __cifs_readpage_from_fscache on success. Releasing the lock at that point however is not appropriate as cifs_readahead also calls cifs_readpage_from_fscache and *does* unconditionally release the lock after its return. This change therefore effectively makes cifs_readpage_worker work like cifs_readahead. Signed-off-by: Russell Harmon <[email protected]> Acked-by: Paulo Alcantara (SUSE) <[email protected]> Reviewed-by: David Howells <[email protected]> Cc: [email protected] Signed-off-by: Steve French <[email protected]>
2023-08-14i2c: tegra: Fix i2c-tegra DMA config option processingParker Newman1-1/+1
Tegra processors prior to Tegra186 used APB DMA for I2C requiring CONFIG_TEGRA20_APB_DMA=y while Tegra186 and later use GPC DMA requiring CONFIG_TEGRA186_GPC_DMA=y. The check for if the processor uses APB DMA is inverted and so the wrong DMA config options are checked. This means if CONFIG_TEGRA20_APB_DMA=y but CONFIG_TEGRA186_GPC_DMA=n with a Tegra186 or later processor the driver will incorrectly think DMA is enabled and attempt to request DMA channels that will never be availible, leaving the driver in a perpetual EPROBE_DEFER state. Fixes: 48cb6356fae1 ("i2c: tegra: Add GPCDMA support") Signed-off-by: Parker Newman <[email protected]> Acked-by: Andi Shyti <[email protected]> Acked-by: Akhil R <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wolfram Sang <[email protected]>
2023-08-14i2c: tegra: Fix failure during probe deferral cleanupThierry Reding1-0/+1
If the driver fails to obtain a DMA channel, it will initiate cleanup and try to release the DMA channel that couldn't be retrieved. This will cause a crash because the cleanup will try to dereference an ERR_PTR()- encoded error code. However, there's nothing to clean up at this point yet, so we can avoid this by simply resetting the DMA channel to NULL instead of storing the error code. Fixes: fcc8a89a1c83 ("i2c: tegra: Share same DMA channel for RX and TX") Signed-off-by: Thierry Reding <[email protected]> Tested-by: Akhil R <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2023-08-14i2c: designware: Handle invalid SMBus block data response length valueTam Nguyen1-2/+13
In the I2C_FUNC_SMBUS_BLOCK_DATA case, the invalid length byte value (outside of 1-32) of the SMBus block data response from the Slave device is not correctly handled by the I2C Designware driver. In case IC_EMPTYFIFO_HOLD_MASTER_EN==1, which cannot be detected from the registers, the Master can be disabled only if the STOP bit is set. Without STOP bit set, the Master remains active, holding the bus until receiving a block data response length. This hangs the bus and is unrecoverable. Avoid this by issuing another dump read to reach the stop condition when an invalid length byte is received. Cc: [email protected] Signed-off-by: Tam Nguyen <[email protected]> Acked-by: Jarkko Nikula <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2023-08-14i2c: designware: Correct length byte validation logicQuan Nguyen1-1/+2
Commit 0daede80f870 ("i2c: designware: Convert driver to using regmap API") changes the logic to validate the whole 32-bit return value of DW_IC_DATA_CMD register instead of 8-bit LSB without reason. Later, commit f53f15ba5a85 ("i2c: designware: Get right data length"), introduced partial fix but not enough because the "tmp > 0" still test tmp as 32-bit value and is wrong in case the IC_DATA_CMD[11] is set. Revert the logic to just before commit 0daede80f870 ("i2c: designware: Convert driver to using regmap API"). Fixes: f53f15ba5a85 ("i2c: designware: Get right data length") Fixes: 0daede80f870 ("i2c: designware: Convert driver to using regmap API") Cc: [email protected] Signed-off-by: Tam Nguyen <[email protected]> Signed-off-by: Quan Nguyen <[email protected]> Acked-by: Jarkko Nikula <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2023-08-14i2c: imx-lpi2c: return -EINVAL when i2c peripheral clk doesn't workCarlos Song1-0/+3
On MX8X platforms, the default clock rate is 0 if without explicit clock setting in dts nodes. I2c can't work when i2c peripheral clk rate is 0. Add a i2c peripheral clk rate check before configuring the clock register. When i2c peripheral clk rate is 0 and directly return -EINVAL. Signed-off-by: Carlos Song <[email protected]> Acked-by: Dong Aisheng <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2023-08-14drm/panel: simple: Fix AUO G121EAN01 panel timings according to the docsLuca Ceresoli1-12/+12
Commit 03e909acd95a ("drm/panel: simple: Add support for AUO G121EAN01.4 panel") added support for this panel model, but the timings it implements are very different from what the datasheet describes. I checked both the G121EAN01.0 datasheet from [0] and the G121EAN01.4 one from [1] and they all have the same timings: for example the LVDS clock typical value is 74.4 MHz, not 66.7 MHz as implemented. Replace the timings with the ones from the documentation. These timings have been tested and the clock frequencies verified with an oscilloscope to ensure they are correct. Also use struct display_timing instead of struct drm_display_mode in order to also specify the minimum and maximum values. [0] https://embedded.avnet.com/product/g121ean01-0/ [1] https://embedded.avnet.com/product/g121ean01-4/ Fixes: 03e909acd95a ("drm/panel: simple: Add support for AUO G121EAN01.4 panel") Signed-off-by: Luca Ceresoli <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-08-14drm/panel: JDI LT070ME05000 simplify with dev_err_probe()David Heidelberg1-22/+14
Use the dev_err_probe() helper to simplify error handling during probe. This also handle scenario, when EDEFER is returned and useless error is printed. Fixes error: panel-jdi-lt070me05000 4700000.dsi.0: cannot get enable-gpio -517 Signed-off-by: David Heidelberg <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-08-14ARM: dts: am335x-bone-common: Add vcc-supply for on-board eepromShengyu Qu1-0/+1
The on-board eeprom on beaglebone series has a power supply from VDD_3V3A, add that to dts to reduce dummy regulator warning. Signed-off-by: Shengyu Qu <[email protected]> Message-ID: <TY3P286MB2611CDC84604B11570B4A8D2980FA@TY3P286MB2611.JPNP286.PROD.OUTLOOK.COM> Signed-off-by: Tony Lindgren <[email protected]>
2023-08-14ARM: dts: am335x-bone-common: Add GPIO PHY reset on revision C3 boardShengyu Qu1-0/+8
This patch adds ethernet PHY reset GPIO config for Beaglebone Black series boards with revision C3. This fixes a random phy startup failure bug discussed at [1]. The GPIO pin used for reset is not used on older revisions, so it is ok to apply to all board revisions. The reset timing was discussed and tested at [2]. [1] https://forum.digikey.com/t/ethernet-device-is-not-detecting-on-ubuntu-20-04-lts-on-bbg/19948 [2] https://forum.beagleboard.org/t/recognizing-a-beaglebone-black-rev-c3-board/31249/ Signed-off-by: Robert Nelson <[email protected]> Signed-off-by: Shengyu Qu <[email protected]> Message-ID: <TY3P286MB26113797A3B2EC7E0348BBB2980FA@TY3P286MB2611.JPNP286.PROD.OUTLOOK.COM> Signed-off-by: Tony Lindgren <[email protected]>
2023-08-14selftests: mirror_gre_changes: Tighten up the TTL test matchPetr Machata1-1/+2
This test verifies whether the encapsulated packets have the correct configured TTL. It does so by sending ICMP packets through the test topology and mirroring them to a gretap netdevice. On a busy host however, more than just the test ICMP packets may end up flowing through the topology, get mirrored, and counted. This leads to potential spurious failures as the test observes much more mirrored packets than the sent test packets, and assumes a bug. Fix this by tightening up the mirror action match. Change it from matchall to a flower classifier matching on ICMP packets specifically. Fixes: 45315673e0c5 ("selftests: forwarding: Test changes in mirror-to-gretap") Signed-off-by: Petr Machata <[email protected]> Tested-by: Mirsad Todorovac <[email protected]> Reviewed-by: Ido Schimmel <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-08-14x86/retpoline,kprobes: Skip optprobe check for indirect jumps with ↵Petr Pavlu4-32/+17
retpolines and IBT The kprobes optimization check can_optimize() calls insn_is_indirect_jump() to detect indirect jump instructions in a target function. If any is found, creating an optprobe is disallowed in the function because the jump could be from a jump table and could potentially land in the middle of the target optprobe. With retpolines, insn_is_indirect_jump() additionally looks for calls to indirect thunks which the compiler potentially used to replace original jumps. This extra check is however unnecessary because jump tables are disabled when the kernel is built with retpolines. The same is currently the case with IBT. Based on this observation, remove the logic to look for calls to indirect thunks and skip the check for indirect jumps altogether if the kernel is built with retpolines or IBT. Remove subsequently the symbols __indirect_thunk_start and __indirect_thunk_end which are no longer needed. Dropping this logic indirectly fixes a problem where the range [__indirect_thunk_start, __indirect_thunk_end] wrongly included also the return thunk. It caused that machines which used the return thunk as a mitigation and didn't have it patched by any alternative ended up not being able to use optprobes in any regular function. Fixes: 0b53c374b9ef ("x86/retpoline: Use -mfunction-return") Suggested-by: Peter Zijlstra (Intel) <[email protected]> Suggested-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Petr Pavlu <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Acked-by: Masami Hiramatsu (Google) <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-08-14x86/retpoline,kprobes: Fix position of thunk sections with CONFIG_LTO_CLANGPetr Pavlu3-9/+9
The linker script arch/x86/kernel/vmlinux.lds.S matches the thunk sections ".text.__x86.*" from arch/x86/lib/retpoline.S as follows: .text { [...] TEXT_TEXT [...] __indirect_thunk_start = .; *(.text.__x86.*) __indirect_thunk_end = .; [...] } Macro TEXT_TEXT references TEXT_MAIN which normally expands to only ".text". However, with CONFIG_LTO_CLANG, TEXT_MAIN becomes ".text .text.[0-9a-zA-Z_]*" which wrongly matches also the thunk sections. The output layout is then different than expected. For instance, the currently defined range [__indirect_thunk_start, __indirect_thunk_end] becomes empty. Prevent the problem by using ".." as the first separator, for example, ".text..__x86.indirect_thunk". This pattern is utilized by other explicit section names which start with one of the standard prefixes, such as ".text" or ".data", and that need to be individually selected in the linker script. [ nathan: Fix conflicts with SRSO and fold in fix issue brought up by Andrew Cooper in post-review: https://lore.kernel.org/[email protected] ] Fixes: dc5723b02e52 ("kbuild: add support for Clang LTO") Signed-off-by: Petr Pavlu <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-08-14x86/srso: Disable the mitigation on unaffected configurationsBorislav Petkov (AMD)1-1/+6
Skip the srso cmd line parsing which is not needed on Zen1/2 with SMT disabled and with the proper microcode applied (latter should be the case anyway) as those are not affected. Fixes: 5a15d8348881 ("x86/srso: Tie SBPB bit setting to microcode patch detection") Signed-off-by: Borislav Petkov (AMD) <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-08-14x86/CPU/AMD: Fix the DIV(0) initial fix attemptBorislav Petkov (AMD)4-2/+4
Initially, it was thought that doing an innocuous division in the #DE handler would take care to prevent any leaking of old data from the divider but by the time the fault is raised, the speculation has already advanced too far and such data could already have been used by younger operations. Therefore, do the innocuous division on every exit to userspace so that userspace doesn't see any potentially old data from integer divisions in kernel space. Do the same before VMRUN too, to protect host data from leaking into the guest too. Fixes: 77245f1c3c64 ("x86/CPU/AMD: Do not leak quotient data after a division by 0") Signed-off-by: Borislav Petkov (AMD) <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.