5.4.274-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainerPATCH 134/215 x86/cpufeatures: Add new word for scattered features
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sandipan Das <[email protected]>
commit 7f274e609f3d5f45c22b1dd59053f6764458b492 upstream.
Add a new word for scattered features because all free bits among the existing Linux-defined auxiliary flags have been exhausted.
--- arch/x86/include/asm/cpufeature.h | 6 ++++-- arch/x86/include/asm/cpufeatures.h | 2 +- arch/x86/include/asm/disabled-features.h | 3 ++- arch/x86/include/asm/required-features.h | 3 ++- 4 files changed, 9 insertions(+), 5 deletions(-)
arch/x86/include/asm/cpufeature.h +4 -2
@@ -92,8 +92,9 @@ extern const char * const x86_bug_flags[ CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 18, feature_bit) || \ CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 19, feature_bit) || \ CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 20, feature_bit) || \ + CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 21, feature_bit) || \ REQUIRED_MASK_CHECK || \ - BUILD_BUG_ON_ZERO(NCAPINTS != 21)) + BUILD_BUG_ON_ZERO(NCAPINTS != 22))#define DISABLED_MASK_BIT_SET (feature_bit) \ ( CHECK_BIT_IN_MASK_WORD(DISABLED_MASK, 0, feature_bit) || \
@@ -117,8 +118,9 @@ extern const char * const x86_bug_flags[ CHECK_BIT_IN_MASK_WORD(DISABLED_MASK, 18, feature_bit) || \ CHECK_BIT_IN_MASK_WORD(DISABLED_MASK, 19, feature_bit) || \ CHECK_BIT_IN_MASK_WORD(DISABLED_MASK, 20, feature_bit) || \ + CHECK_BIT_IN_MASK_WORD(DISABLED_MASK, 21, feature_bit) || \ DISABLED_MASK_CHECK || \ - BUILD_BUG_ON_ZERO(NCAPINTS != 21)) + BUILD_BUG_ON_ZERO(NCAPINTS != 22))#define cpu_has (c, bit) \ (__builtin_constant_p(bit) && REQUIRED_MASK_BIT_SET(bit) ? 1 : \
arch/x86/include/asm/cpufeatures.h +1 -1
@@ -13,7 +13,7 @@/* * Defines x86 CPU feature bits */ -#define NCAPINTS 21/* N 32-bit words worth of info */ +#define NCAPINTS 22/* N 32-bit words worth of info */ #define NBUGINTS 2/* N 32-bit bug flags */ /*
arch/x86/include/asm/disabled-features.h +2 -1
@@ -86,6 +86,7 @@#define DISABLED_MASK18 0#define DISABLED_MASK19 0#define DISABLED_MASK20 0 -#define DISABLED_MASK_CHECK BUILD_BUG_ON_ZERO(NCAPINTS != 21) +#define DISABLED_MASK21 0 +#define DISABLED_MASK_CHECK BUILD_BUG_ON_ZERO(NCAPINTS != 22)#endif /* _ASM_X86_DISABLED_FEATURES_H */
arch/x86/include/asm/required-features.h +2 -1
@@ -103,6 +103,7 @@#define REQUIRED_MASK18 0#define REQUIRED_MASK19 0#define REQUIRED_MASK20 0 -#define REQUIRED_MASK_CHECK BUILD_BUG_ON_ZERO(NCAPINTS != 21) +#define REQUIRED_MASK21 0 +#define REQUIRED_MASK_CHECK BUILD_BUG_ON_ZERO(NCAPINTS != 22)#endif /* _ASM_X86_REQUIRED_FEATURES_H */
Greg Kroah-Hartman
maintainerPATCH 135/215 Bluetooth: hci_event: set the conn encrypted before conn establishes
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hui Wang <[email protected]>
commit c569242cd49287d53b73a94233db40097d838535 upstream.
We have a BT headset (Lenovo Thinkplus XT99), the pairing and connecting has no problem, once this headset is paired, bluez will remember this device and will auto re-connect it whenever the device is powered on. The auto re-connecting works well with Windows and Android, but with Linux, it always fails. Through debugging, we found at the rfcomm connection stage, the bluetooth stack reports "Connection refused - security block (0x0003)".
For this device, the re-connecting negotiation process is different from other BT headsets, it sends the Link_KEY_REQUEST command before the CONNECT_REQUEST completes, and it doesn't send ENCRYPT_CHANGE command during the negotiation. When the device sends the "connect complete" to hci, the ev->encr_mode is 1.
So here in the conn_complete_evt(), if ev->encr_mode is 1, link type is ACL and HCI_CONN_ENCRYPT is not set, we set HCI_CONN_ENCRYPT to this conn, and update conn->enc_key_size accordingly.
After this change, this BT headset could re-connect with Linux successfully. This is the btmon log after applying the patch, after receiving the "Connect Complete" with "Encryption: Enabled", will send the command to read encryption key size:
Quoted 1 line
HCI Event: Connect Request (
0x04) plen 10
Address: 8C:3C:AA:D8:11:67 (OUI 8C-3C-AA)
Class: 0x240404
Major class: Audio/Video (headset, speaker, stereo, video, vcr) Minor class: Wearable Headset Device
Rendering (Printing, Speaker)
Audio (Speaker, Microphone, Headset)
Link type: ACL (0x01)
...
Quoted 1 line
HCI Event: Link Key Request (
0x17) plen 6
Address: 8C:3C:AA:D8:11:67 (OUI 8C-3C-AA)
< HCI Command: Link Key Request Reply (0x01|0x000b) plen 22
Address: 8C:3C:AA:D8:11:67 (OUI 8C-3C-AA)
Link key: ${32-hex-digits-key}...
Quoted 1 line
HCI Event: Connect Complete (
0x03) plen 11
Status: Success (0x00)
Handle: 256
Address: 8C:3C:AA:D8:11:67 (OUI 8C-3C-AA)
Link type: ACL (0x01)
Encryption: Enabled (0x01)
< HCI Command: Read Encryption Key... (0x05|0x0008) plen 2
Handle: 256
< ACL Data TX: Handle 256 flags 0x00 dlen 10
L2CAP: Information Request (0x0a) ident 1 len 2
Type: Extended features supported (0x0002)Quoted 1 line
HCI Event: Command Complete (
0x0e) plen 7
Read Encryption Key Size (0x05|0x0008) ncmd 1
Status: Success (0x00)
Handle: 256
Key size: 16--- net/bluetooth/hci_event.c | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+)
net/bluetooth/hci_event.c +25 -0
@@ -2537,6 +2537,31 @@ static void hci_conn_complete_evt(structif (test_bit (HCI_ENCRYPT , &hdev->flags))set_bit (HCI_CONN_ENCRYPT , &conn->flags); +/* "Link key request" completed ahead of "connect request" completes */ +if (ev->encr_mode ==1 && !test_bit (HCI_CONN_ENCRYPT , &conn->flags) && + ev->link_type ==ACL_LINK ) { +struct link_key *key; +struct hci_cp_read_enc_key_size cp; + + key =hci_find_link_key (hdev, &ev->bdaddr); +if (key) { +set_bit (HCI_CONN_ENCRYPT , &conn->flags); + +if (!(hdev->commands[20 ] &0x10 )) { + conn->enc_key_size =HCI_LINK_KEY_SIZE ; + }else { + cp.handle =cpu_to_le16 (conn->handle); +if (hci_send_cmd (hdev,HCI_OP_READ_ENC_KEY_SIZE , +sizeof (cp), &cp)) { +bt_dev_err (hdev,"sending read key size failed" ); + conn->enc_key_size =HCI_LINK_KEY_SIZE ; + } + } + +hci_encrypt_cfm (conn, ev->status); + } + } +/* Get remote features */ if (conn->type ==ACL_LINK ) {struct hci_cp_read_remote_features cp;
Greg Kroah-Hartman
maintainerPATCH 136/215 Bluetooth: Fix TOCTOU in HCI debugfs implementation
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bastien Nocera <[email protected]>
commit 7835fcfd132eb88b87e8eb901f88436f63ab60f7 upstream.
struct hci_dev members conn_info_max_age, conn_info_min_age, le_conn_max_interval, le_conn_min_interval, le_adv_max_interval, and le_adv_min_interval can be modified from the HCI core code, as well through debugfs.
The debugfs implementation, that's only available to privileged users, will check for boundaries, making sure that the minimum value being set is strictly above the maximum value that already exists, and vice-versa.
However, as both minimum and maximum values can be changed concurrently to us modifying them, we need to make sure that the value we check is the value we end up using.
For example, with ->conn_info_max_age set to 10, conn_info_min_age_set() gets called from vfs handlers to set conn_info_min_age to 8.
In conn_info_min_age_set(), this goes through:
if (val == 0 || val > hdev->conn_info_max_age) return -EINVAL;
Concurrently, conn_info_max_age_set() gets called to set to set the conn_info_max_age to 7:
if (val == 0 || val > hdev->conn_info_max_age) return -EINVAL;
That check will also pass because we used the old value (10) for conn_info_max_age.
After those checks that both passed, the struct hci_dev access is mutex-locked, disabling concurrent access, but that does not matter because the invalid value checks both passed, and we'll end up with conn_info_min_age = 8 and conn_info_max_age = 7
To fix this problem, we need to lock the structure access before so the check and assignment are not interrupted.
This fix was originally devised by the BassCheck[1] team, and considered the problem to be an atomicity one. This isn't the case as there aren't any concerns about the variable changing while we check it, but rather after we check it parallel to another change.
This patch fixes CVE-2024-24858 and CVE-2024-24857.
[1] https://sites.google.com/view/basscheck/
--- net/bluetooth/hci_debugfs.c | 48 +++++++++++++++++++++++++++++--------------- 1 file changed, 32 insertions(+), 16 deletions(-)
net/bluetooth/hci_debugfs.c +32 -16
@@ -200,10 +200,12 @@ static int conn_info_min_age_set(void *d {struct hci_dev *hdev = data; -if (val ==0 || val > hdev->conn_info_max_age) +hci_dev_lock (hdev); +if (val ==0 || val > hdev->conn_info_max_age) { +hci_dev_unlock (hdev);return -EINVAL ; + } -hci_dev_lock (hdev); hdev->conn_info_min_age = val;hci_dev_unlock (hdev);
@@ -228,10 +230,12 @@ static int conn_info_max_age_set(void *d {struct hci_dev *hdev = data; -if (val ==0 || val < hdev->conn_info_min_age) +hci_dev_lock (hdev); +if (val ==0 || val < hdev->conn_info_min_age) { +hci_dev_unlock (hdev);return -EINVAL ; + } -hci_dev_lock (hdev); hdev->conn_info_max_age = val;hci_dev_unlock (hdev);
@@ -508,10 +512,12 @@ static int sniff_min_interval_set(void * {struct hci_dev *hdev = data; -if (val ==0 || val %2 || val > hdev->sniff_max_interval) +hci_dev_lock (hdev); +if (val ==0 || val %2 || val > hdev->sniff_max_interval) { +hci_dev_unlock (hdev);return -EINVAL ; + } -hci_dev_lock (hdev); hdev->sniff_min_interval = val;hci_dev_unlock (hdev);
@@ -536,10 +542,12 @@ static int sniff_max_interval_set(void * {struct hci_dev *hdev = data; -if (val ==0 || val %2 || val < hdev->sniff_min_interval) +hci_dev_lock (hdev); +if (val ==0 || val %2 || val < hdev->sniff_min_interval) { +hci_dev_unlock (hdev);return -EINVAL ; + } -hci_dev_lock (hdev); hdev->sniff_max_interval = val;hci_dev_unlock (hdev);
@@ -780,10 +788,12 @@ static int conn_min_interval_set(void *d {struct hci_dev *hdev = data; -if (val <0x0006 || val >0x0c80 || val > hdev->le_conn_max_interval) +hci_dev_lock (hdev); +if (val <0x0006 || val >0x0c80 || val > hdev->le_conn_max_interval) { +hci_dev_unlock (hdev);return -EINVAL ; + } -hci_dev_lock (hdev); hdev->le_conn_min_interval = val;hci_dev_unlock (hdev);
@@ -808,10 +818,12 @@ static int conn_max_interval_set(void *d {struct hci_dev *hdev = data; -if (val <0x0006 || val >0x0c80 || val < hdev->le_conn_min_interval) +hci_dev_lock (hdev); +if (val <0x0006 || val >0x0c80 || val < hdev->le_conn_min_interval) { +hci_dev_unlock (hdev);return -EINVAL ; + } -hci_dev_lock (hdev); hdev->le_conn_max_interval = val;hci_dev_unlock (hdev);
@@ -920,10 +932,12 @@ static int adv_min_interval_set(void *da {struct hci_dev *hdev = data; -if (val <0x0020 || val >0x4000 || val > hdev->le_adv_max_interval) +hci_dev_lock (hdev); +if (val <0x0020 || val >0x4000 || val > hdev->le_adv_max_interval) { +hci_dev_unlock (hdev);return -EINVAL ; + } -hci_dev_lock (hdev); hdev->le_adv_min_interval = val;hci_dev_unlock (hdev);
@@ -948,10 +962,12 @@ static int adv_max_interval_set(void *da {struct hci_dev *hdev = data; -if (val <0x0020 || val >0x4000 || val < hdev->le_adv_min_interval) +hci_dev_lock (hdev); +if (val <0x0020 || val >0x4000 || val < hdev->le_adv_min_interval) { +hci_dev_unlock (hdev);return -EINVAL ; + } -hci_dev_lock (hdev); hdev->le_adv_max_interval = val;hci_dev_unlock (hdev);
Greg Kroah-Hartman
maintainerPATCH 137/215 netfilter: nf_tables: disallow timeout for anonymous sets
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pablo Neira Ayuso <[email protected]>
commit e26d3009efda338f19016df4175f354a9bd0a4ab upstream.
Never used from userspace, disallow these parameters.
[Keerthana: code surrounding the patch is different because nft_set_desc is not present in v4.19-v5.10]
--- net/netfilter/nf_tables_api.c | 7 +++++++ 1 file changed, 7 insertions(+)
net/netfilter/nf_tables_api.c +7 -0
@@ -3816,6 +3816,9 @@ static int nf_tables_newset(struct net *if (!(flags &NFT_SET_TIMEOUT ))return -EINVAL ; +if (flags &NFT_SET_ANONYMOUS ) +return -EOPNOTSUPP ; + err =nf_msecs_to_jiffies64 (nla[NFTA_SET_TIMEOUT ], &timeout);if (err)return err;
@@ -3824,6 +3827,10 @@ static int nf_tables_newset(struct net *if (nla[NFTA_SET_GC_INTERVAL ] !=NULL ) {if (!(flags &NFT_SET_TIMEOUT ))return -EINVAL ; + +if (flags &NFT_SET_ANONYMOUS ) +return -EOPNOTSUPP ; + gc_int =ntohl (nla_get_be32 (nla[NFTA_SET_GC_INTERVAL ])); }
Greg Kroah-Hartman
maintainerPATCH 138/215 net/rds: fix possible cp null dereference
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mahmoud Adam <[email protected]>
commit 62fc3357e079a07a22465b9b6ef71bb6ea75ee4b upstream.
cp might be null, calling cp->cp_conn would produce null dereference
[Simon Horman adds:]
Analysis:
* cp is a parameter of __rds_rdma_map and is not reassigned.
* The following call-sites pass a NULL cp argument to __rds_rdma_map()
- rds_get_mr()
- rds_get_mr_for_dest
* Prior to the code above, the following assumes that cp may be NULL (which is indicative, but could itself be unnecessary)
trans_private = rs->rs_transport->get_mr( sg, nents, rs, &mr->r_key, cp ? cp->cp_conn : NULL, args->vec.addr, args->vec.bytes, need_odp ? ODP_ZEROBASED : ODP_NOT_NEEDED);
* The code modified by this patch is guarded by IS_ERR(trans_private), where trans_private is assigned as per the previous point in this analysis.
The only implementation of get_mr that I could locate is rds_ib_get_mr() which can return an ERR_PTR if the conn (4th) argument is NULL.
* ret is set to PTR_ERR(trans_private).
rds_ib_get_mr can return ERR_PTR(-ENODEV) if the conn (4th) argument is NULL. Thus ret may be -ENODEV in which case the code in question will execute.
Conclusion:
* cp may be NULL at the point where this patch adds a check; this patch does seem to address a possible bug
--- net/rds/rdma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/rds/rdma.c +1 -1
@@ -280,7 +280,7 @@ static int __rds_rdma_map(struct rds_sockfree (sg); ret =PTR_ERR (trans_private);/* Trigger connection so that its ready for the next retry */ -if (ret == -ENODEV ) +if (ret == -ENODEV && cp)rds_conn_connect_if_down (cp->cp_conn); goto out; }
Greg Kroah-Hartman
maintainerPATCH 139/215 vfio/pci: Disable auto-enable of exclusive INTx IRQ
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Williamson <[email protected]>
[ Upstream commit fe9a7082684eb059b925c535682e68c34d487d43 ]
Currently for devices requiring masking at the irqchip for INTx, ie. devices without DisINTx support, the IRQ is enabled in request_irq() and subsequently disabled as necessary to align with the masked status flag. This presents a window where the interrupt could fire between these events, resulting in the IRQ incrementing the disable depth twice. This would be unrecoverable for a user since the masked flag prevents nested enables through vfio.
Instead, invert the logic using IRQF_NO_AUTOEN such that exclusive INTx is never auto-enabled, then unmask as required.
--- drivers/vfio/pci/vfio_pci_intrs.c | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-)
drivers/vfio/pci/vfio_pci_intrs.c +10 -7
@@ -199,8 +199,15 @@ static int vfio_intx_set_signal(struct v vdev->ctx[0 ].trigger = trigger; +/* +* Devices without DisINTx support require an exclusive interrupt, +* IRQ masking is performed at the IRQ chip. The masked status is +* protected by vdev->irqlock. Setup the IRQ without auto-enable and +* unmask as necessary below under lock. DisINTx is unmodified by +* the IRQ configuration and may therefore use auto-enable. +*/ if (!vdev->pci_2_3) - irqflags =0 ; + irqflags =IRQF_NO_AUTOEN ; ret =request_irq (pdev->irq, vfio_intx_handler, irqflags, vdev->ctx[0 ].name, vdev);
@@ -211,13 +218,9 @@ static int vfio_intx_set_signal(struct vreturn ret; } -/* -* INTx disable will stick across the new irq setup, -* disable_irq won't. -*/ spin_lock_irqsave (&vdev->irqlock, flags); -if (!vdev->pci_2_3 && vdev->ctx[0 ].masked) -disable_irq_nosync (pdev->irq); +if (!vdev->pci_2_3 && !vdev->ctx[0 ].masked) +enable_irq (pdev->irq);spin_unlock_irqrestore (&vdev->irqlock, flags);return 0 ;
Greg Kroah-Hartman
maintainerPATCH 140/215 vfio/pci: Lock external INTx masking ops
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Williamson <[email protected]>
[ Upstream commit 810cd4bb53456d0503cc4e7934e063835152c1b7 ]
Mask operations through config space changes to DisINTx may race INTx configuration changes via ioctl. Create wrappers that add locking for paths outside of the core interrupt code.
In particular, irq_type is updated holding igate, therefore testing is_intx() requires holding igate. For example clearing DisINTx from config space can otherwise race changes of the interrupt configuration.
This aligns interfaces which may trigger the INTx eventfd into two camps, one side serialized by igate and the other only enabled while INTx is configured. A subsequent patch introduces synchronization for the latter flows.
--- drivers/vfio/pci/vfio_pci_intrs.c | 30 ++++++++++++++++++++++++------ 1 file changed, 24 insertions(+), 6 deletions(-)
drivers/vfio/pci/vfio_pci_intrs.c +24 -6
@@ -33,11 +33,13 @@ static void vfio_send_intx_eventfd(voideventfd_signal (vdev->ctx[0 ].trigger,1 ); } -void vfio_pci_intx_mask (struct vfio_pci_device *vdev) +static void __vfio_pci_intx_mask (struct vfio_pci_device *vdev) {struct pci_dev *pdev = vdev->pdev;unsigned long flags; +lockdep_assert_held (&vdev->igate); +spin_lock_irqsave (&vdev->irqlock, flags);/*
@@ -65,6 +67,13 @@ void vfio_pci_intx_mask(struct vfio_pci_spin_unlock_irqrestore (&vdev->irqlock, flags); } +void vfio_pci_intx_mask (struct vfio_pci_device *vdev) +{ +mutex_lock (&vdev->igate); +__vfio_pci_intx_mask (vdev); +mutex_unlock (&vdev->igate); +} +/* * If this is triggered by an eventfd, we can't call eventfd_signal * or else we'll deadlock on the eventfd wait queue. Return >0 when
@@ -107,12 +116,21 @@ static int vfio_pci_intx_unmask_handler(return ret; } -void vfio_pci_intx_unmask (struct vfio_pci_device *vdev) +static void __vfio_pci_intx_unmask (struct vfio_pci_device *vdev) { +lockdep_assert_held (&vdev->igate); +if (vfio_pci_intx_unmask_handler (vdev,NULL ) >0 )vfio_send_intx_eventfd (vdev,NULL ); } +void vfio_pci_intx_unmask (struct vfio_pci_device *vdev) +{ +mutex_lock (&vdev->igate); +__vfio_pci_intx_unmask (vdev); +mutex_unlock (&vdev->igate); +} +static irqreturn_t vfio_intx_handler (int irq,void *dev_id) {struct vfio_pci_device *vdev = dev_id;
@@ -428,11 +446,11 @@ static int vfio_pci_set_intx_unmask(strureturn -EINVAL ;if (flags &VFIO_IRQ_SET_DATA_NONE ) { -vfio_pci_intx_unmask (vdev); +__vfio_pci_intx_unmask (vdev); }else if (flags &VFIO_IRQ_SET_DATA_BOOL ) {uint8_t unmask = *(uint8_t *)data;if (unmask) -vfio_pci_intx_unmask (vdev); +__vfio_pci_intx_unmask (vdev); }else if (flags &VFIO_IRQ_SET_DATA_EVENTFD ) {int32_t fd = *(int32_t *)data;if (fd >=0 )
@@ -455,11 +473,11 @@ static int vfio_pci_set_intx_mask(structreturn -EINVAL ;if (flags &VFIO_IRQ_SET_DATA_NONE ) { -vfio_pci_intx_mask (vdev); +__vfio_pci_intx_mask (vdev); }else if (flags &VFIO_IRQ_SET_DATA_BOOL ) {uint8_t mask = *(uint8_t *)data;if (mask) -vfio_pci_intx_mask (vdev); +__vfio_pci_intx_mask (vdev); }else if (flags &VFIO_IRQ_SET_DATA_EVENTFD ) {return -ENOTTY ;/* XXX implement me */ }
Greg Kroah-Hartman
maintainerPATCH 141/215 vfio: Introduce interface to flush virqfd inject workqueue
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Williamson <[email protected]>
[ Upstream commit b620ecbd17a03cacd06f014a5d3f3a11285ce053 ]
In order to synchronize changes that can affect the thread callback, introduce an interface to force a flush of the inject workqueue. The irqfd pointer is only valid under spinlock, but the workqueue cannot be flushed under spinlock. Therefore the flush work for the irqfd is queued under spinlock. The vfio_irqfd_cleanup_wq workqueue is re-used for queuing this work such that flushing the workqueue is also ordered relative to shutdown.
--- drivers/vfio/virqfd.c | 21 +++++++++++++++++++++ include/linux/vfio.h | 2 ++ 2 files changed, 23 insertions(+)
drivers/vfio/virqfd.c +21 -0
@@ -101,6 +101,13 @@ static void virqfd_inject(struct work_st virqfd->thread (virqfd->opaque, virqfd->data); } +static void virqfd_flush_inject (struct work_struct *work) +{ + struct virqfd *virqfd = container_of(work, struct virqfd, flush_inject); + +flush_work (&virqfd->inject); +} + int vfio_virqfd_enable(void *opaque, int (*handler)(void *, void *), void (*thread)(void *, void *),
@@ -124,6 +131,7 @@ int vfio_virqfd_enable(void *opaque,INIT_WORK (&virqfd->shutdown, virqfd_shutdown);INIT_WORK (&virqfd->inject, virqfd_inject); +INIT_WORK (&virqfd->flush_inject, virqfd_flush_inject); irqfd =fdget (fd);if (!irqfd.file) {
@@ -214,6 +222,19 @@ void vfio_virqfd_disable(struct virqfd * }EXPORT_SYMBOL_GPL (vfio_virqfd_disable); +void vfio_virqfd_flush_thread (struct virqfd **pvirqfd) +{ +unsigned long flags; + +spin_lock_irqsave (&virqfd_lock, flags); +if (*pvirqfd && (*pvirqfd)->thread) +queue_work (vfio_irqfd_cleanup_wq, &(*pvirqfd)->flush_inject); +spin_unlock_irqrestore (&virqfd_lock, flags); + +flush_workqueue (vfio_irqfd_cleanup_wq); +} +EXPORT_SYMBOL_GPL (vfio_virqfd_flush_thread); +module_init (vfio_virqfd_init);module_exit (vfio_virqfd_exit);
include/linux/vfio.h +2 -0
@@ -186,6 +186,7 @@ struct virqfd {wait_queue_entry_t wait;poll_table pt;struct work_struct shutdown; +struct work_struct flush_inject;struct virqfd **pvirqfd; };
@@ -194,5 +195,6 @@ extern int vfio_virqfd_enable(void *opaqvoid (*thread)(void *,void *), void *data, struct virqfd **pvirqfd, int fd);extern void vfio_virqfd_disable (struct virqfd **pvirqfd); +void vfio_virqfd_flush_thread (struct virqfd **pvirqfd);#endif /* VFIO_H */
Greg Kroah-Hartman
maintainerPATCH 142/215 vfio/pci: Create persistent INTx handler
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Williamson <[email protected]>
[ Upstream commit 18c198c96a815c962adc2b9b77909eec0be7df4d ]
A vulnerability exists where the eventfd for INTx signaling can be deconfigured, which unregisters the IRQ handler but still allows eventfds to be signaled with a NULL context through the SET_IRQS ioctl or through unmask irqfd if the device interrupt is pending.
Ideally this could be solved with some additional locking; the igate mutex serializes the ioctl and config space accesses, and the interrupt handler is unregistered relative to the trigger, but the irqfd path runs asynchronous to those. The igate mutex cannot be acquired from the atomic context of the eventfd wake function. Disabling the irqfd relative to the eventfd registration is potentially incompatible with existing userspace.
As a result, the solution implemented here moves configuration of the INTx interrupt handler to track the lifetime of the INTx context object and irq_type configuration, rather than registration of a particular trigger eventfd. Synchronization is added between the ioctl path and eventfd_signal() wrapper such that the eventfd trigger can be dynamically updated relative to in-flight interrupts or irqfd callbacks.
--- drivers/vfio/pci/vfio_pci_intrs.c | 149 ++++++++++++++++++++------------------ 1 file changed, 82 insertions(+), 67 deletions(-)
drivers/vfio/pci/vfio_pci_intrs.c +82 -67
@@ -29,8 +29,13 @@ static void vfio_send_intx_eventfd(void {struct vfio_pci_device *vdev = opaque; -if (likely (is_intx (vdev) && !vdev->virq_disabled)) -eventfd_signal (vdev->ctx[0 ].trigger,1 ); +if (likely (is_intx (vdev) && !vdev->virq_disabled)) { +struct eventfd_ctx *trigger; + + trigger =READ_ONCE (vdev->ctx[0 ].trigger); +if (likely (trigger)) +eventfd_signal (trigger,1 ); + } }static void __vfio_pci_intx_mask (struct vfio_pci_device *vdev)
@@ -157,98 +162,104 @@ static irqreturn_t vfio_intx_handler(intreturn ret; } -static int vfio_intx_enable (struct vfio_pci_device *vdev) +static int vfio_intx_enable (struct vfio_pci_device *vdev, +struct eventfd_ctx *trigger) { +struct pci_dev *pdev = vdev->pdev; +unsigned long irqflags; +char *name; +int ret; +if (!is_irq_none (vdev))return -EINVAL ; -if (!vdev->pdev->irq) +if (!pdev->irq)return -ENODEV ; + name =kasprintf (GFP_KERNEL ,"vfio-intx(%s)" ,pci_name (pdev)); +if (!name) +return -ENOMEM ; + vdev->ctx =kzalloc (sizeof (struct vfio_pci_irq_ctx ),GFP_KERNEL );if (!vdev->ctx)return -ENOMEM ; vdev->num_ctx =1 ; + vdev->ctx[0 ].name = name; + vdev->ctx[0 ].trigger = trigger; +/* -* If the virtual interrupt is masked, restore it. Devices -* supporting DisINTx can be masked at the hardware level -* here, non-PCI-2.3 devices will have to wait until the -* interrupt is enabled. +* Fill the initial masked state based on virq_disabled. After +* enable, changing the DisINTx bit in vconfig directly changes INTx +* masking. igate prevents races during setup, once running masked +* is protected via irqlock. +* +* Devices supporting DisINTx also reflect the current mask state in +* the physical DisINTx bit, which is not affected during IRQ setup. +* +* Devices without DisINTx support require an exclusive interrupt. +* IRQ masking is performed at the IRQ chip. Again, igate protects +* against races during setup and IRQ handlers and irqfds are not +* yet active, therefore masked is stable and can be used to +* conditionally auto-enable the IRQ. +* +* irq_type must be stable while the IRQ handler is registered, +* therefore it must be set before request_irq(). */ vdev->ctx[0 ].masked = vdev->virq_disabled; -if (vdev->pci_2_3) -pci_intx (vdev->pdev, !vdev->ctx[0 ].masked); +if (vdev->pci_2_3) { +pci_intx (pdev, !vdev->ctx[0 ].masked); + irqflags =IRQF_SHARED ; + }else { + irqflags = vdev->ctx[0 ].masked ?IRQF_NO_AUTOEN :0 ; + } vdev->irq_type =VFIO_PCI_INTX_IRQ_INDEX ; + ret =request_irq (pdev->irq, vfio_intx_handler, + irqflags, vdev->ctx[0 ].name, vdev); +if (ret) { + vdev->irq_type =VFIO_PCI_NUM_IRQS ; +kfree (name); + vdev->num_ctx =0 ; +kfree (vdev->ctx); +return ret; + } +return 0 ; } -static int vfio_intx_set_signal (struct vfio_pci_device *vdev,int fd) +static int vfio_intx_set_signal (struct vfio_pci_device *vdev, +struct eventfd_ctx *trigger) {struct pci_dev *pdev = vdev->pdev; -unsigned long irqflags =IRQF_SHARED ; -struct eventfd_ctx *trigger; -unsigned long flags; -int ret; - -if (vdev->ctx[0 ].trigger) { -free_irq (pdev->irq, vdev); -kfree (vdev->ctx[0 ].name); -eventfd_ctx_put (vdev->ctx[0 ].trigger); - vdev->ctx[0 ].trigger =NULL ; - } - -if (fd <0 )/* Disable only */ -return 0 ; - - vdev->ctx[0 ].name =kasprintf (GFP_KERNEL ,"vfio-intx(%s)" , -pci_name (pdev)); -if (!vdev->ctx[0 ].name) -return -ENOMEM ; - - trigger =eventfd_ctx_fdget (fd); -if (IS_ERR (trigger)) { -kfree (vdev->ctx[0 ].name); -return PTR_ERR (trigger); - } +struct eventfd_ctx *old; - vdev->ctx[0 ].trigger = trigger; + old = vdev->ctx[0 ].trigger; -/* -* Devices without DisINTx support require an exclusive interrupt, -* IRQ masking is performed at the IRQ chip. The masked status is -* protected by vdev->irqlock. Setup the IRQ without auto-enable and -* unmask as necessary below under lock. DisINTx is unmodified by -* the IRQ configuration and may therefore use auto-enable. -*/ -if (!vdev->pci_2_3) - irqflags =IRQF_NO_AUTOEN ; +WRITE_ONCE (vdev->ctx[0 ].trigger, trigger); - ret =request_irq (pdev->irq, vfio_intx_handler, - irqflags, vdev->ctx[0 ].name, vdev); -if (ret) { - vdev->ctx[0 ].trigger =NULL ; -kfree (vdev->ctx[0 ].name); -eventfd_ctx_put (trigger); -return ret; +/* Releasing an old ctx requires synchronizing in-flight users */ +if (old) { +synchronize_irq (pdev->irq); +vfio_virqfd_flush_thread (&vdev->ctx[0 ].unmask); +eventfd_ctx_put (old); } -spin_lock_irqsave (&vdev->irqlock, flags); -if (!vdev->pci_2_3 && !vdev->ctx[0 ].masked) -enable_irq (pdev->irq); -spin_unlock_irqrestore (&vdev->irqlock, flags); -return 0 ; }static void vfio_intx_disable (struct vfio_pci_device *vdev) { +struct pci_dev *pdev = vdev->pdev; +vfio_virqfd_disable (&vdev->ctx[0 ].unmask);vfio_virqfd_disable (&vdev->ctx[0 ].mask); -vfio_intx_set_signal (vdev,-1 ); +free_irq (pdev->irq, vdev); +if (vdev->ctx[0 ].trigger) +eventfd_ctx_put (vdev->ctx[0 ].trigger); +kfree (vdev->ctx[0 ].name); vdev->irq_type =VFIO_PCI_NUM_IRQS ; vdev->num_ctx =0 ;kfree (vdev->ctx);
@@ -498,19 +509,23 @@ static int vfio_pci_set_intx_trigger(strreturn -EINVAL ;if (flags &VFIO_IRQ_SET_DATA_EVENTFD ) { +struct eventfd_ctx *trigger =NULL ;int32_t fd = *(int32_t *)data;int ret; +if (fd >=0 ) { + trigger =eventfd_ctx_fdget (fd); +if (IS_ERR (trigger)) +return PTR_ERR (trigger); + } +if (is_intx (vdev)) -return vfio_intx_set_signal (vdev, fd); + ret =vfio_intx_set_signal (vdev, trigger); +else + ret =vfio_intx_enable (vdev, trigger); - ret =vfio_intx_enable (vdev); -if (ret) -return ret; - - ret =vfio_intx_set_signal (vdev, fd); -if (ret) -vfio_intx_disable (vdev); +if (ret && trigger) +eventfd_ctx_put (trigger);return ret; }
Greg Kroah-Hartman
maintainerPATCH 143/215 vfio/platform: Create persistent IRQ handlers
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Williamson <[email protected]>
[ Upstream commit 675daf435e9f8e5a5eab140a9864dfad6668b375 ]
The vfio-platform SET_IRQS ioctl currently allows loopback triggering of an interrupt before a signaling eventfd has been configured by the user, which thereby allows a NULL pointer dereference.
Rather than register the IRQ relative to a valid trigger, register all IRQs in a disabled state in the device open path. This allows mask operations on the IRQ to nest within the overall enable state governed by a valid eventfd signal. This decouples @masked, protected by the @locked spinlock from @trigger, protected via the @igate mutex.
In doing so, it's guaranteed that changes to @trigger cannot race the IRQ handlers because the IRQ handler is synchronously disabled before modifying the trigger, and loopback triggering of the IRQ via ioctl is safe due to serialization with trigger changes via igate.
For compatibility, request_irq() failures are maintained to be local to the SET_IRQS ioctl rather than a fatal error in the open device path. This allows, for example, a userspace driver with polling mode support to continue to work regardless of moving the request_irq() call site. This necessarily blocks all SET_IRQS access to the failed index.
--- drivers/vfio/platform/vfio_platform_irq.c | 101 ++++++++++++++++++++---------- 1 file changed, 68 insertions(+), 33 deletions(-)
drivers/vfio/platform/vfio_platform_irq.c +68 -33
@@ -136,6 +136,16 @@ static int vfio_platform_set_irq_unmask(return 0 ; } +/* +* The trigger eventfd is guaranteed valid in the interrupt path +* and protected by the igate mutex when triggered via ioctl. +*/ +static void vfio_send_eventfd (struct vfio_platform_irq *irq_ctx) +{ +if (likely (irq_ctx->trigger)) +eventfd_signal (irq_ctx->trigger,1 ); +} +static irqreturn_t vfio_automasked_irq_handler (int irq,void *dev_id) {struct vfio_platform_irq *irq_ctx = dev_id;
@@ -155,7 +165,7 @@ static irqreturn_t vfio_automasked_irq_hspin_unlock_irqrestore (&irq_ctx->lock, flags);if (ret ==IRQ_HANDLED ) -eventfd_signal (irq_ctx->trigger,1 ); +vfio_send_eventfd (irq_ctx);return ret; }
@@ -164,22 +174,19 @@ static irqreturn_t vfio_irq_handler(int {struct vfio_platform_irq *irq_ctx = dev_id; -eventfd_signal (irq_ctx->trigger,1 ); +vfio_send_eventfd (irq_ctx);return IRQ_HANDLED ; }static int vfio_set_trigger (struct vfio_platform_device *vdev,int index, -int fd,irq_handler_t handler) +int fd) {struct vfio_platform_irq *irq = &vdev->irqs[index];struct eventfd_ctx *trigger; -int ret;if (irq->trigger) { -irq_clear_status_flags (irq->hwirq,IRQ_NOAUTOEN ); -free_irq (irq->hwirq, irq); -kfree (irq->name); +disable_irq (irq->hwirq);eventfd_ctx_put (irq->trigger); irq->trigger =NULL ; }
@@ -187,30 +194,20 @@ static int vfio_set_trigger(struct vfio_if (fd <0 )/* Disable only */ return 0 ; - irq->name =kasprintf (GFP_KERNEL ,"vfio-irq[%d](%s)" , - irq->hwirq, vdev->name); -if (!irq->name) -return -ENOMEM ; - trigger =eventfd_ctx_fdget (fd); -if (IS_ERR (trigger)) { -kfree (irq->name); +if (IS_ERR (trigger))return PTR_ERR (trigger); - } irq->trigger = trigger; -irq_set_status_flags (irq->hwirq,IRQ_NOAUTOEN ); - ret =request_irq (irq->hwirq, handler,0 , irq->name, irq); -if (ret) { -kfree (irq->name); -eventfd_ctx_put (trigger); - irq->trigger =NULL ; -return ret; - } - -if (!irq->masked) -enable_irq (irq->hwirq); +/* +* irq->masked effectively provides nested disables within the overall +* enable relative to trigger. Specifically request_irq() is called +* with NO_AUTOEN, therefore the IRQ is initially disabled. The user +* may only further disable the IRQ with a MASK operations because +* irq->masked is initially false. +*/ +enable_irq (irq->hwirq);return 0 ; }
@@ -229,7 +226,7 @@ static int vfio_platform_set_irq_trigger handler = vfio_irq_handler;if (!count && (flags &VFIO_IRQ_SET_DATA_NONE )) -return vfio_set_trigger (vdev, index,-1 , handler); +return vfio_set_trigger (vdev, index,-1 );if (start !=0 || count !=1 )return -EINVAL ;
@@ -237,7 +234,7 @@ static int vfio_platform_set_irq_triggerif (flags &VFIO_IRQ_SET_DATA_EVENTFD ) {int32_t fd = *(int32_t *)data; -return vfio_set_trigger (vdev, index, fd, handler); +return vfio_set_trigger (vdev, index, fd); }if (flags &VFIO_IRQ_SET_DATA_NONE ) {
@@ -261,6 +258,14 @@ int vfio_platform_set_irqs_ioctl(struct unsigned start, unsigned count, uint32_t flags, void *data) = NULL; +/* +* For compatibility, errors from request_irq() are local to the +* SET_IRQS path and reflected in the name pointer. This allows, +* for example, polling mode fallback for an exclusive IRQ failure. +*/ +if (IS_ERR (vdev->irqs[index].name)) +return PTR_ERR (vdev->irqs[index].name); +switch (flags &VFIO_IRQ_SET_ACTION_TYPE_MASK ) {case VFIO_IRQ_SET_ACTION_MASK : func = vfio_platform_set_irq_mask;
@@ -281,7 +286,7 @@ int vfio_platform_set_irqs_ioctl(structint vfio_platform_irq_init (struct vfio_platform_device *vdev) { -int cnt =0 , i; +int cnt =0 , i, ret =0 ;while (vdev->get_irq (vdev, cnt) >=0 ) cnt++;
@@ -292,29 +297,54 @@ int vfio_platform_irq_init(struct vfio_pfor (i =0 ; i < cnt; i++) {int hwirq = vdev->get_irq (vdev, i); +irq_handler_t handler = vfio_irq_handler; -if (hwirq <0 ) +if (hwirq <0 ) { + ret = -EINVAL ; goto err; + }spin_lock_init (&vdev->irqs[i].lock); vdev->irqs[i].flags =VFIO_IRQ_INFO_EVENTFD ; -if (irq_get_trigger_type (hwirq) &IRQ_TYPE_LEVEL_MASK ) +if (irq_get_trigger_type (hwirq) &IRQ_TYPE_LEVEL_MASK ) { vdev->irqs[i].flags |=VFIO_IRQ_INFO_MASKABLE |VFIO_IRQ_INFO_AUTOMASKED ; + handler = vfio_automasked_irq_handler; + } vdev->irqs[i].count =1 ; vdev->irqs[i].hwirq = hwirq; vdev->irqs[i].masked = false; + vdev->irqs[i].name =kasprintf (GFP_KERNEL , +"vfio-irq[%d](%s)" , hwirq, + vdev->name); +if (!vdev->irqs[i].name) { + ret = -ENOMEM ; + goto err; + } + + ret =request_irq (hwirq, handler,IRQF_NO_AUTOEN , + vdev->irqs[i].name, &vdev->irqs[i]); +if (ret) { +kfree (vdev->irqs[i].name); + vdev->irqs[i].name =ERR_PTR (ret); + } } vdev->num_irqs = cnt;return 0 ; err: +for (--i; i >=0 ; i--) { +if (!IS_ERR (vdev->irqs[i].name)) { +free_irq (vdev->irqs[i].hwirq, &vdev->irqs[i]); +kfree (vdev->irqs[i].name); + } + }kfree (vdev->irqs); -return -EINVAL ; +return ret; }void vfio_platform_irq_cleanup (struct vfio_platform_device *vdev)
@@ -324,7 +354,12 @@ void vfio_platform_irq_cleanup(struct vffor (i =0 ; i < vdev->num_irqs; i++) {vfio_virqfd_disable (&vdev->irqs[i].mask);vfio_virqfd_disable (&vdev->irqs[i].unmask); -vfio_set_trigger (vdev, i,-1 ,NULL ); +if (!IS_ERR (vdev->irqs[i].name)) { +free_irq (vdev->irqs[i].hwirq, &vdev->irqs[i]); +if (vdev->irqs[i].trigger) +eventfd_ctx_put (vdev->irqs[i].trigger); +kfree (vdev->irqs[i].name); + } } vdev->num_irqs =0 ;
Greg Kroah-Hartman
maintainerPATCH 144/215 Revert "x86/mm/ident_map: Use gbpages only where full GB page should be mapped."
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ingo Molnar <[email protected]>
commit c567f2948f57bdc03ed03403ae0234085f376b7d upstream.
This reverts commit d794734c9bbfe22f86686dc2909c25f5ffe1a572.
While the original change tries to fix a bug, it also unintentionally broke existing systems, see the regressions reported at:
https://lore.kernel.org/all/[email protected]/
Since d794734c9bbf was also marked for -stable, let's back it out before causing more damage.
Note that due to another upstream change the revert was not 100% automatic:
0a845e0f6348 mm/treewide: replace pud_large() with pud_leaf()
--- arch/x86/mm/ident_map.c | 23 +++++------------------ 1 file changed, 5 insertions(+), 18 deletions(-)
arch/x86/mm/ident_map.c +5 -18
@@ -26,31 +26,18 @@ static int ident_pud_init(struct x86_mapfor (; addr < end; addr = next) {pud_t *pud = pud_page +pud_index (addr);pmd_t *pmd; -bool use_gbpage; next = (addr &PUD_MASK ) +PUD_SIZE ;if (next > end) next = end; -/* if this is already a gbpage, this portion is already mapped */ -if (pud_large (*pud)) -continue ; - -/* Is using a gbpage allowed? */ - use_gbpage = info->direct_gbpages; - -/* Don't use gbpage if it maps more than the requested region. */ -/* at the begining: */ - use_gbpage &= ((addr & ~PUD_MASK ) ==0 ); -/* ... or at the end: */ - use_gbpage &= ((next & ~PUD_MASK ) ==0 ); - -/* Never overwrite existing mappings */ - use_gbpage &= !pud_present (*pud); - -if (use_gbpage) { +if (info->direct_gbpages) {pud_t pudval; +if (pud_present (*pud)) +continue ; + + addr &=PUD_MASK ; pudval =__pud ((addr - info->offset) | info->page_flag);set_pud (pud, pudval);continue ;
Greg Kroah-Hartman
maintainerPATCH 145/215 mm, vmscan: prevent infinite loop for costly GFP_NOIO | __GFP_RETRY_MAYFAIL allocations
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vlastimil Babka <[email protected]>
commit 803de9000f334b771afacb6ff3e78622916668b0 upstream.
Sven reports an infinite loop in __alloc_pages_slowpath() for costly order __GFP_RETRY_MAYFAIL allocations that are also GFP_NOIO. Such combination can happen in a suspend/resume context where a GFP_KERNEL allocation can have __GFP_IO masked out via gfp_allowed_mask.
Quoting Sven:
1. try to do a "costly" allocation (order > PAGE_ALLOC_COSTLY_ORDER) with __GFP_RETRY_MAYFAIL set.
2. page alloc's __alloc_pages_slowpath tries to get a page from the freelist. This fails because there is nothing free of that costly order.
3. page alloc tries to reclaim by calling __alloc_pages_direct_reclaim, which bails out because a zone is ready to be compacted; it pretends to have made a single page of progress.
4. page alloc tries to compact, but this always bails out early because __GFP_IO is not set (it's not passed by the snd allocator, and even if it were, we are suspending so the __GFP_IO flag would be cleared anyway).
5. page alloc believes reclaim progress was made (because of the pretense in item 3) and so it checks whether it should retry compaction. The compaction retry logic thinks it should try again, because:
a) reclaim is needed because of the early bail-out in item 4
b) a zonelist is suitable for compaction
6. goto 2. indefinite stall.
(end quote)
The immediate root cause is confusing the COMPACT_SKIPPED returned from __alloc_pages_direct_compact() (step 4) due to lack of __GFP_IO to be indicating a lack of order-0 pages, and in step 5 evaluating that in should_compact_retry() as a reason to retry, before incrementing and limiting the number of retries. There are however other places that wrongly assume that compaction can happen while we lack __GFP_IO.
To fix this, introduce gfp_compaction_allowed() to abstract the __GFP_IO evaluation and switch the open-coded test in try_to_compact_pages() to use it.
Also use the new helper in:
- compaction_ready(), which will make reclaim not bail out in step 3, so there's at least one attempt to actually reclaim, even if chances are small for a costly order
- in_reclaim_compaction() which will make should_continue_reclaim() return false and we don't over-reclaim unnecessarily
- in __alloc_pages_slowpath() to set a local variable can_compact, which is then used to avoid retrying reclaim/compaction for costly allocations (step 5) if we can't compact and also to skip the early compaction attempt that we do in some cases
--- include/linux/gfp.h | 9 +++++++++ mm/compaction.c | 7 +------ mm/page_alloc.c | 10 ++++++---- mm/vmscan.c | 5 ++++- 4 files changed, 20 insertions(+), 11 deletions(-)
include/linux/gfp.h +9 -0
@@ -608,6 +608,15 @@ static inline bool pm_suspended_storage( }#endif /* CONFIG_PM_SLEEP */ +/* +* Check if the gfp flags allow compaction - GFP_NOIO is a really +* tricky context because the migration might require IO. +*/ +static inline bool gfp_compaction_allowed (gfp_t gfp_mask) +{ +return IS_ENABLED (CONFIG_COMPACTION ) && (gfp_mask & __GFP_IO); +} +#ifdef CONFIG_CONTIG_ALLOC /* The below functions must be run on a range from a single zone. */ extern int alloc_contig_range(unsigned long start, unsigned long end,
mm/compaction.c +1 -6
@@ -2343,16 +2343,11 @@ enum compact_result try_to_compact_pages unsigned int alloc_flags, const struct alloc_context *ac, enum compact_priority prio, struct page **capture) { - int may_perform_io = gfp_mask & __GFP_IO; struct zoneref *z;struct zone *zone;enum compact_result rc =COMPACT_SKIPPED ; -/* -* Check if the GFP flags allow compaction - GFP_NOIO is really -* tricky context because the migration might require IO -*/ -if (!may_perform_io) +if (!gfp_compaction_allowed (gfp_mask))return COMPACT_SKIPPED ;trace_mm_compaction_try_to_compact_pages (order, gfp_mask, prio);
mm/page_alloc.c +6 -4
@@ -4445,6 +4445,7 @@ __alloc_pages_slowpath(gfp_t gfp_mask, u struct alloc_context *ac) {bool can_direct_reclaim = gfp_mask & __GFP_DIRECT_RECLAIM; +bool can_compact =gfp_compaction_allowed (gfp_mask);const bool costly_order = order >PAGE_ALLOC_COSTLY_ORDER ;struct page *page =NULL ;unsigned int alloc_flags;
@@ -4510,7 +4511,7 @@ restart:* Don't try this for allocations that are allowed to ignore * watermarks, as the ALLOC_NO_WATERMARKS attempt didn't yet happen. */ -if (can_direct_reclaim && +if (can_direct_reclaim && can_compact && (costly_order || (order >0 && ac->migratetype !=MIGRATE_MOVABLE )) && !gfp_pfmemalloc_allowed (gfp_mask)) {
@@ -4621,9 +4622,10 @@ retry:/* * Do not retry costly high order allocations unless they are -* __GFP_RETRY_MAYFAIL +* __GFP_RETRY_MAYFAIL and we can compact */ -if (costly_order && !(gfp_mask & __GFP_RETRY_MAYFAIL)) +if (costly_order && (!can_compact || + !(gfp_mask & __GFP_RETRY_MAYFAIL))) goto nopage; if (should_reclaim_retry(gfp_mask, order, ac, alloc_flags,
@@ -4636,7 +4638,7 @@ retry:* implementation of the compaction depends on the sufficient amount * of free memory (see __compaction_suitable) */ -if (did_some_progress >0 && +if (did_some_progress >0 && can_compact &&should_compact_retry (ac, order, alloc_flags, compact_result, &compact_priority, &compaction_retries))
mm/vmscan.c +4 -1
@@ -2691,7 +2691,7 @@ static void shrink_node_memcg(struct pgl/* Use reclaim/compaction for costly allocs or under memory pressure */ static bool in_reclaim_compaction (struct scan_control *sc) { -if (IS_ENABLED (CONFIG_COMPACTION ) && sc->order && +if (gfp_compaction_allowed (sc->gfp_mask) && sc->order && (sc->order >PAGE_ALLOC_COSTLY_ORDER || sc->priority <DEF_PRIORITY -2 ))return true;
@@ -2940,6 +2940,9 @@ static inline bool compaction_ready(struunsigned long watermark;enum compact_result suitable; +if (!gfp_compaction_allowed (sc->gfp_mask)) +return false; + suitable =compaction_suitable (zone, sc->order,0 , sc->reclaim_idx);if (suitable ==COMPACT_SUCCESS )/* Allocation should succeed already. Don't reclaim. */
Greg Kroah-Hartman
maintainerPATCH 146/215 netfilter: nf_tables: flush pending destroy work before exit_net release
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pablo Neira Ayuso <[email protected]>
commit 24cea9677025e0de419989ecb692acd4bb34cac2 upstream.
Similar to 2c9f0293280e ("netfilter: nf_tables: flush pending destroy work before netlink notifier") to address a race between exit_net and the destroy workqueue.
The trace below shows an element to be released via destroy workqueue while exit_net path (triggered via module removal) has already released the set that is used in such transaction.
[ 1360.547789] BUG: KASAN: slab-use-after-free in nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.547861] Read of size 8 at addr ffff888140500cc0 by task kworker/4:1/152465 [ 1360.547870] CPU: 4 PID: 152465 Comm: kworker/4:1 Not tainted 6.8.0+ #359 [ 1360.547882] Workqueue: events nf_tables_trans_destroy_work [nf_tables] [ 1360.547984] Call Trace: [ 1360.547991] <TASK> [ 1360.547998] dump_stack_lvl+0x53/0x70 [ 1360.548014] print_report+0xc4/0x610 [ 1360.548026] ? __virt_addr_valid+0xba/0x160 [ 1360.548040] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 1360.548054] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548176] kasan_report+0xae/0xe0 [ 1360.548189] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548312] nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548447] ? __pfx_nf_tables_trans_destroy_work+0x10/0x10 [nf_tables] [ 1360.548577] ? _raw_spin_unlock_irq+0x18/0x30 [ 1360.548591] process_one_work+0x2f1/0x670 [ 1360.548610] worker_thread+0x4d3/0x760 [ 1360.548627] ? __pfx_worker_thread+0x10/0x10 [ 1360.548640] kthread+0x16b/0x1b0 [ 1360.548653] ? __pfx_kthread+0x10/0x10 [ 1360.548665] ret_from_fork+0x2f/0x50 [ 1360.548679] ? __pfx_kthread+0x10/0x10 [ 1360.548690] ret_from_fork_asm+0x1a/0x30 [ 1360.548707] </TASK>
[ 1360.548719] Allocated by task 192061: [ 1360.548726] kasan_save_stack+0x20/0x40 [ 1360.548739] kasan_save_track+0x14/0x30 [ 1360.548750] __kasan_kmalloc+0x8f/0xa0 [ 1360.548760] __kmalloc_node+0x1f1/0x450 [ 1360.548771] nf_tables_newset+0x10c7/0x1b50 [nf_tables] [ 1360.548883] nfnetlink_rcv_batch+0xbc4/0xdc0 [nfnetlink] [ 1360.548909] nfnetlink_rcv+0x1a8/0x1e0 [nfnetlink] [ 1360.548927] netlink_unicast+0x367/0x4f0 [ 1360.548935] netlink_sendmsg+0x34b/0x610 [ 1360.548944] ____sys_sendmsg+0x4d4/0x510 [ 1360.548953] ___sys_sendmsg+0xc9/0x120 [ 1360.548961] __sys_sendmsg+0xbe/0x140 [ 1360.548971] do_syscall_64+0x55/0x120 [ 1360.548982] entry_SYSCALL_64_after_hwframe+0x55/0x5d
[ 1360.548994] Freed by task 192222: [ 1360.548999] kasan_save_stack+0x20/0x40 [ 1360.549009] kasan_save_track+0x14/0x30 [ 1360.549019] kasan_save_free_info+0x3b/0x60 [ 1360.549028] poison_slab_object+0x100/0x180 [ 1360.549036] __kasan_slab_free+0x14/0x30 [ 1360.549042] kfree+0xb6/0x260 [ 1360.549049] __nft_release_table+0x473/0x6a0 [nf_tables] [ 1360.549131] nf_tables_exit_net+0x170/0x240 [nf_tables] [ 1360.549221] ops_exit_list+0x50/0xa0 [ 1360.549229] free_exit_list+0x101/0x140 [ 1360.549236] unregister_pernet_operations+0x107/0x160 [ 1360.549245] unregister_pernet_subsys+0x1c/0x30 [ 1360.549254] nf_tables_module_exit+0x43/0x80 [nf_tables] [ 1360.549345] __do_sys_delete_module+0x253/0x370 [ 1360.549352] do_syscall_64+0x55/0x120 [ 1360.549360] entry_SYSCALL_64_after_hwframe+0x55/0x5d
(gdb) list *__nft_release_table+0x4730x1e033 is in __nft_release_table (net/netfilter/nf_tables_api.c:11354).
11349 list_for_each_entry_safe(flowtable, nf, &table->flowtables, list) {
11350 list_del(&flowtable->list);
11351 nft_use_dec(&table->use);
11352 nf_tables_flowtable_destroy(flowtable);
11353 }
11354 list_for_each_entry_safe(set, ns, &table->sets, list) {
11355 list_del(&set->list);
11356 nft_use_dec(&table->use);
11357 if (set->flags & (NFT_SET_MAP | NFT_SET_OBJECT))11358 nft_map_deactivate(&ctx, set);
(gdb)
[ 1360.549372] Last potentially related work creation: [ 1360.549376] kasan_save_stack+0x20/0x40 [ 1360.549384] __kasan_record_aux_stack+0x9b/0xb0 [ 1360.549392] __queue_work+0x3fb/0x780 [ 1360.549399] queue_work_on+0x4f/0x60 [ 1360.549407] nft_rhash_remove+0x33b/0x340 [nf_tables] [ 1360.549516] nf_tables_commit+0x1c6a/0x2620 [nf_tables] [ 1360.549625] nfnetlink_rcv_batch+0x728/0xdc0 [nfnetlink] [ 1360.549647] nfnetlink_rcv+0x1a8/0x1e0 [nfnetlink] [ 1360.549671] netlink_unicast+0x367/0x4f0 [ 1360.549680] netlink_sendmsg+0x34b/0x610 [ 1360.549690] ____sys_sendmsg+0x4d4/0x510 [ 1360.549697] ___sys_sendmsg+0xc9/0x120 [ 1360.549706] __sys_sendmsg+0xbe/0x140 [ 1360.549715] do_syscall_64+0x55/0x120 [ 1360.549725] entry_SYSCALL_64_after_hwframe+0x55/0x5d
--- net/netfilter/nf_tables_api.c | 1 + 1 file changed, 1 insertion(+)
net/netfilter/nf_tables_api.c +1 -0
@@ -8476,6 +8476,7 @@ static void __exit nf_tables_module_exitunregister_netdevice_notifier (&nf_tables_flowtable_notifier);nft_chain_filter_fini ();nft_chain_route_fini (); +nf_tables_trans_destroy_flush_work ();unregister_pernet_subsys (&nf_tables_net_ops);cancel_work_sync (&trans_gc_work);cancel_work_sync (&trans_destroy_work);
Greg Kroah-Hartman
maintainerPATCH 147/215 netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get()
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ziyang Xuan <[email protected]>
commit 24225011d81b471acc0e1e315b7d9905459a6304 upstream.
nft_unregister_flowtable_type() within nf_flow_inet_module_exit() can concurrent with __nft_flowtable_type_get() within nf_tables_newflowtable(). And thhere is not any protection when iterate over nf_tables_flowtables list in __nft_flowtable_type_get(). Therefore, there is pertential data-race of nf_tables_flowtables list entry.
Use list_for_each_entry_rcu() to iterate over nf_tables_flowtables list in __nft_flowtable_type_get(), and use rcu_read_lock() in the caller nft_flowtable_type_get() to protect the entire type query process.
--- net/netfilter/nf_tables_api.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
net/netfilter/nf_tables_api.c +7 -2
@@ -6041,11 +6041,12 @@ static int nf_tables_flowtable_parse_hooreturn err; } +/* call under rcu_read_lock */ static const struct nf_flowtable_type *__nft_flowtable_type_get (u8 family) {const struct nf_flowtable_type *type; -list_for_each_entry (type, &nf_tables_flowtables, list) { +list_for_each_entry_rcu (type, &nf_tables_flowtables, list) {if (family == type->family)return type; }
@@ -6057,9 +6058,13 @@ nft_flowtable_type_get(struct net *net, {const struct nf_flowtable_type *type; +rcu_read_lock (); type =__nft_flowtable_type_get (family); -if (type !=NULL &&try_module_get (type->owner)) +if (type !=NULL &&try_module_get (type->owner)) { +rcu_read_unlock ();return type; + } +rcu_read_unlock ();lockdep_nfnl_nft_mutex_not_held ();#ifdef CONFIG_MODULES
Greg Kroah-Hartman
maintainerPATCH 148/215 bpf, sockmap: Prevent lock inversion deadlock in map delete elem
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jakub Sitnicki <[email protected]>
commit ff91059932401894e6c86341915615c5eb0eca48 upstream.
syzkaller started using corpuses where a BPF tracing program deletes elements from a sockmap/sockhash map. Because BPF tracing programs can be invoked from any interrupt context, locks taken during a map_delete_elem operation must be hardirq-safe. Otherwise a deadlock due to lock inversion is possible, as reported by lockdep:
CPU0 CPU1
---- ----
lock(&htab->buckets[i].lock);
local_irq_disable();
lock(&host->lock);
lock(&htab->buckets[i].lock);
<Interrupt>
lock(&host->lock);Locks in sockmap are hardirq-unsafe by design. We expects elements to be deleted from sockmap/sockhash only in task (normal) context with interrupts enabled, or in softirq context.
Detect when map_delete_elem operation is invoked from a context which is _not_ hardirq-unsafe, that is interrupts are disabled, and bail out with an error.
Note that map updates are not affected by this issue. BPF verifier does not allow updating sockmap/sockhash from a BPF tracing program today.
--- net/core/sock_map.c | 6 ++++++ 1 file changed, 6 insertions(+)
net/core/sock_map.c +6 -0
@@ -321,6 +321,9 @@ static int __sock_map_delete(struct bpf_struct sock *sk;int err =0 ; +if (irqs_disabled ()) +return -EOPNOTSUPP ;/* locks here are hardirq-unsafe */ +raw_spin_lock_bh (&stab->lock); sk = *psk;if (!sk_test || sk_test == sk)
@@ -654,6 +657,9 @@ static int sock_hash_delete_elem(structstruct bpf_htab_elem *elem;int ret = -ENOENT ; +if (irqs_disabled ()) +return -EOPNOTSUPP ;/* locks here are hardirq-unsafe */ + hash =sock_hash_bucket_hash (key, key_size); bucket =sock_hash_select_bucket (htab, hash);
Greg Kroah-Hartman
maintainerPATCH 149/215 net/sched: act_skbmod: prevent kernel-infoleak
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
commit d313eb8b77557a6d5855f42d2234bd592c7b50dd upstream.
syzbot found that tcf_skbmod_dump() was copying four bytes from kernel stack to user space [1].
The issue here is that 'struct tc_skbmod' has a four bytes hole.
We need to clear the structure before filling fields.
[1]
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline] BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline] BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline] BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 instrument_copy_to_user include/linux/instrumented.h:114 [inline] copy_to_user_iter lib/iov_iter.c:24 [inline] iterate_ubuf include/linux/iov_iter.h:29 [inline] iterate_and_advance2 include/linux/iov_iter.h:245 [inline] iterate_and_advance include/linux/iov_iter.h:271 [inline] _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 copy_to_iter include/linux/uio.h:196 [inline] simple_copy_to_iter net/core/datagram.c:532 [inline] __skb_datagram_iter+0x185/0x1000 net/core/datagram.c:420 skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546 skb_copy_datagram_msg include/linux/skbuff.h:4050 [inline] netlink_recvmsg+0x432/0x1610 net/netlink/af_netlink.c:1962 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x2c4/0x340 net/socket.c:1068 __sys_recvfrom+0x35a/0x5f0 net/socket.c:2242 __do_sys_recvfrom net/socket.c:2260 [inline] __se_sys_recvfrom net/socket.c:2256 [inline] __x64_sys_recvfrom+0x126/0x1d0 net/socket.c:2256 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75
Uninit was stored to memory at:
pskb_expand_head+0x30f/0x19d0 net/core/skbuff.c:2253 netlink_trim+0x2c2/0x330 net/netlink/af_netlink.c:1317 netlink_unicast+0x9f/0x1260 net/netlink/af_netlink.c:1351 nlmsg_unicast include/net/netlink.h:1144 [inline] nlmsg_notify+0x21d/0x2f0 net/netlink/af_netlink.c:2610 rtnetlink_send+0x73/0x90 net/core/rtnetlink.c:741 rtnetlink_maybe_send include/linux/rtnetlink.h:17 [inline] tcf_add_notify net/sched/act_api.c:2048 [inline] tcf_action_add net/sched/act_api.c:2071 [inline] tc_ctl_action+0x146e/0x19d0 net/sched/act_api.c:2119 rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595 netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2559 rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6613 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xf4c/0x1260 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10df/0x11f0 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 ____sys_sendmsg+0x877/0xb60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75
Uninit was stored to memory at:
__nla_put lib/nlattr.c:1041 [inline] nla_put+0x1c6/0x230 lib/nlattr.c:1099 tcf_skbmod_dump+0x23f/0xc20 net/sched/act_skbmod.c:256 tcf_action_dump_old net/sched/act_api.c:1191 [inline] tcf_action_dump_1+0x85e/0x970 net/sched/act_api.c:1227 tcf_action_dump+0x1fd/0x460 net/sched/act_api.c:1251 tca_get_fill+0x519/0x7a0 net/sched/act_api.c:1628 tcf_add_notify_msg net/sched/act_api.c:2023 [inline] tcf_add_notify net/sched/act_api.c:2042 [inline] tcf_action_add net/sched/act_api.c:2071 [inline] tc_ctl_action+0x1365/0x19d0 net/sched/act_api.c:2119 rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595 netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2559 rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6613 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xf4c/0x1260 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10df/0x11f0 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 ____sys_sendmsg+0x877/0xb60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75
Local variable opt created at:
tcf_skbmod_dump+0x9d/0xc20 net/sched/act_skbmod.c:244 tcf_action_dump_old net/sched/act_api.c:1191 [inline] tcf_action_dump_1+0x85e/0x970 net/sched/act_api.c:1227
Bytes 188-191 of 248 are uninitialized Memory access of size 248 starts at ffff888117697680 Data copied to user address 00007ffe56d855f0
--- net/sched/act_skbmod.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
net/sched/act_skbmod.c +5 -5
@@ -219,13 +219,13 @@ static int tcf_skbmod_dump(struct sk_bufstruct tcf_skbmod *d =to_skbmod (a);unsigned char *b =skb_tail_pointer (skb);struct tcf_skbmod_params *p; -struct tc_skbmod opt = { - .index = d->tcf_index, - .refcnt =refcount_read (&d->tcf_refcnt) - ref, - .bindcnt =atomic_read (&d->tcf_bindcnt) - bind, - }; +struct tc_skbmod opt;struct tcf_t t; +memset (&opt,0 ,sizeof (opt)); + opt.index = d->tcf_index; + opt.refcnt =refcount_read (&d->tcf_refcnt) - ref, + opt.bindcnt =atomic_read (&d->tcf_bindcnt) - bind;spin_lock_bh (&d->tcf_lock); opt.action = d->tcf_action; p = rcu_dereference_protected(d->skbmod_p,
Greg Kroah-Hartman
maintainerPATCH 150/215 net: stmmac: fix rx queue priority assignment
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Piotr Wejman <[email protected]>
commit b3da86d432b7cd65b025a11f68613e333d2483db upstream.
The driver should ensure that same priority is not mapped to multiple rx queues. From DesignWare Cores Ethernet Quality-of-Service Databook, section 17.1.29 MAC_RxQ_Ctrl2:
"[...]The software must ensure that the content of this field is mutually exclusive to the PSRQ fields for other queues, that is, the same priority is not mapped to multiple Rx queues[...]"
Previously rx_queue_priority() function was:
- clearing all priorities from a queue
- adding new priorities to that queue
After this patch it will:
- first assign new priorities to a queue
- then remove those priorities from all other queues
- keep other priorities previously assigned to that queue
--- drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 40 +++++++++++++++----- drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c | 38 +++++++++++++++---- 2 files changed, 62 insertions(+), 16 deletions(-)
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c +31 -9
@@ -75,19 +75,41 @@ static void dwmac4_rx_queue_priority(str u32 prio, u32 queue) { void __iomem *ioaddr = hw->pcsr; -u32 base_register; -u32 value; +u32 clear_mask =0 ; +u32 ctrl2, ctrl3; +int i; - base_register = (queue <4 ) ?GMAC_RXQ_CTRL2 :GMAC_RXQ_CTRL3 ; -if (queue >=4 ) - queue -=4 ; + ctrl2 =readl (ioaddr +GMAC_RXQ_CTRL2 ); + ctrl3 =readl (ioaddr +GMAC_RXQ_CTRL3 ); + +/* The software must ensure that the same priority +* is not mapped to multiple Rx queues +*/ +for (i =0 ; i <4 ; i++) + clear_mask |= ((prio <<GMAC_RXQCTRL_PSRQX_SHIFT (i)) & +GMAC_RXQCTRL_PSRQX_MASK (i)); - value =readl (ioaddr + base_register); + ctrl2 &= ~clear_mask; + ctrl3 &= ~clear_mask; - value &= ~GMAC_RXQCTRL_PSRQX_MASK (queue); - value |= (prio <<GMAC_RXQCTRL_PSRQX_SHIFT (queue)) & +/* First assign new priorities to a queue, then +* clear them from others queues +*/ +if (queue <4 ) { + ctrl2 |= (prio <<GMAC_RXQCTRL_PSRQX_SHIFT (queue)) &GMAC_RXQCTRL_PSRQX_MASK (queue); -writel (value, ioaddr + base_register); + +writel (ctrl2, ioaddr +GMAC_RXQ_CTRL2 ); +writel (ctrl3, ioaddr +GMAC_RXQ_CTRL3 ); + }else { + queue -=4 ; + + ctrl3 |= (prio <<GMAC_RXQCTRL_PSRQX_SHIFT (queue)) & +GMAC_RXQCTRL_PSRQX_MASK (queue); + +writel (ctrl3, ioaddr +GMAC_RXQ_CTRL3 ); +writel (ctrl2, ioaddr +GMAC_RXQ_CTRL2 ); + } } static void dwmac4_tx_queue_priority(struct mac_device_info *hw,
drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c +31 -7
@@ -96,17 +96,41 @@ static void dwxgmac2_rx_queue_prio(struc u32 queue) {void __iomem *ioaddr = hw->pcsr; -u32 value, reg; +u32 clear_mask =0 ; +u32 ctrl2, ctrl3; +int i; - reg = (queue <4 ) ?XGMAC_RXQ_CTRL2 :XGMAC_RXQ_CTRL3 ; -if (queue >=4 ) + ctrl2 =readl (ioaddr +XGMAC_RXQ_CTRL2 ); + ctrl3 =readl (ioaddr +XGMAC_RXQ_CTRL3 ); + +/* The software must ensure that the same priority +* is not mapped to multiple Rx queues +*/ +for (i =0 ; i <4 ; i++) + clear_mask |= ((prio <<XGMAC_PSRQ_SHIFT (i)) & +XGMAC_PSRQ (i)); + + ctrl2 &= ~clear_mask; + ctrl3 &= ~clear_mask; + +/* First assign new priorities to a queue, then +* clear them from others queues +*/ +if (queue <4 ) { + ctrl2 |= (prio <<XGMAC_PSRQ_SHIFT (queue)) & +XGMAC_PSRQ (queue); + +writel (ctrl2, ioaddr +XGMAC_RXQ_CTRL2 ); +writel (ctrl3, ioaddr +XGMAC_RXQ_CTRL3 ); + }else { queue -=4 ; - value =readl (ioaddr + reg); - value &= ~XGMAC_PSRQ (queue); - value |= (prio <<XGMAC_PSRQ_SHIFT (queue)) &XGMAC_PSRQ (queue); + ctrl3 |= (prio <<XGMAC_PSRQ_SHIFT (queue)) & +XGMAC_PSRQ (queue); -writel (value, ioaddr + reg); +writel (ctrl3, ioaddr +XGMAC_RXQ_CTRL3 ); +writel (ctrl2, ioaddr +XGMAC_RXQ_CTRL2 ); + } } static void dwxgmac2_tx_queue_prio(struct mac_device_info *hw, u32 prio,
Greg Kroah-Hartman
maintainerPATCH 151/215 selftests: reuseaddr_conflict: add missing new line at the end of the output
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jakub Kicinski <[email protected]>
commit 31974122cfdeaf56abc18d8ab740d580d9833e90 upstream.
The netdev CI runs in a VM and captures serial, so stdout and stderr get combined. Because there's a missing new line in stderr the test ends up corrupting KTAP:
# Successok 1 selftests: net: reuseaddr_conflict
which should have been:
# Success
ok 1 selftests: net: reuseaddr_conflict
--- tools/testing/selftests/net/reuseaddr_conflict.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/testing/selftests/net/reuseaddr_conflict.c +1 -1
@@ -109,6 +109,6 @@ int main(void) fd1 =open_port (0 ,1 );if (fd1 >=0 )error (1 ,0 ,"Was allowed to create an ipv4 reuseport on an already bound non-reuseport socket with no ipv6" ); -fprintf (stderr,"Success" ); +fprintf (stderr,"Success\n" );return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 152/215 ipv6: Fix infinite recursion in fib6_dump_done().
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kuniyuki Iwashima <[email protected]>
commit d21d40605bca7bd5fc23ef03d4c1ca1f48bc2cae upstream.
syzkaller reported infinite recursive calls of fib6_dump_done() during netlink socket destruction. [1]
Quoted 1 line
From the log, syzkaller sent an
AF_UNSPECRTM_GETROUTEmessage, and then
the response was generated. The following recvmmsg() resumed the dump for IPv6, but the first call of inet6_dump_fib() failed at kzalloc() due to the fault injection. [0]
12:01:34 executing program 3:
r0 = socket$nl_route(0x10, 0x3, 0x0)
sendmsg$nl_route(r0, ... snip ...)
recvmmsg(r0, ... snip ...) (fail_nth: 8)
Here, fib6_dump_done() was set to nlk_sk(sk)->cb.done, and the next call of inet6_dump_fib() set it to nlk_sk(sk)->cb.args[3]. syzkaller stopped receiving the response halfway through, and finally netlink_sock_destruct() called nlk_sk(sk)->cb.done().
fib6_dump_done() calls fib6_dump_end() and nlk_sk(sk)->cb.done() if it is still not NULL. fib6_dump_end() rewrites nlk_sk(sk)->cb.done() by nlk_sk(sk)->cb.args[3], but it has the same function, not NULL, calling itself recursively and hitting the stack guard page.
To avoid the issue, let's set the destructor after kzalloc().
[0]:FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
CPU: 1 PID: 432110 Comm: syz-executor.3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:117) should_fail_ex (lib/fault-inject.c:52 lib/fault-inject.c:153) should_failslab (mm/slub.c:3733) kmalloc_trace (mm/slub.c:3748 mm/slub.c:3827 mm/slub.c:3992) inet6_dump_fib (./include/linux/slab.h:628 ./include/linux/slab.h:749 net/ipv6/ip6_fib.c:662) rtnl_dump_all (net/core/rtnetlink.c:4029) netlink_dump (net/netlink/af_netlink.c:2269) netlink_recvmsg (net/netlink/af_netlink.c:1988) ____sys_recvmsg (net/socket.c:1046 net/socket.c:2801) ___sys_recvmsg (net/socket.c:2846) do_recvmmsg (net/socket.c:2943) __x64_sys_recvmmsg (net/socket.c:3041 net/socket.c:3034 net/socket.c:3034)
[1]:
BUG: TASK stack guard page was hit at 00000000f2fa9af1 (stack is 00000000b7912430..000000009a436beb) stack guard page: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 223719 Comm: kworker/1:3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Workqueue: events netlink_sock_destruct_work RIP: 0010:fib6_dump_done (net/ipv6/ip6_fib.c:570) Code: 3c 24 e8 f3 e9 51 fd e9 28 fd ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 41 57 41 56 41 55 41 54 55 48 89 fd <53> 48 8d 5d 60 e8 b6 4d 07 fd 48 89 da 48 b8 00 00 00 00 00 fc ff RSP: 0018:ffffc9000d980000 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffffffff84405990 RCX: ffffffff844059d3 RDX: ffff8881028e0000 RSI: ffffffff84405ac2 RDI: ffff88810c02f358 RBP: ffff88810c02f358 R08: 0000000000000007 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000224 R12: 0000000000000000 R13: ffff888007c82c78 R14: ffff888007c82c68 R15: ffff888007c82c68 FS: 0000000000000000(0000) GS:ffff88811b100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc9000d97fff8 CR3: 0000000102309002 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <#DF> </#DF> <TASK> fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1)) fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1)) ... fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1)) fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1)) netlink_sock_destruct (net/netlink/af_netlink.c:401) __sk_destruct (net/core/sock.c:2177 (discriminator 2)) sk_destruct (net/core/sock.c:2224) __sk_free (net/core/sock.c:2235) sk_free (net/core/sock.c:2246) process_one_work (kernel/workqueue.c:3259) worker_thread (kernel/workqueue.c:3329 kernel/workqueue.c:3416) kthread (kernel/kthread.c:388) ret_from_fork (arch/x86/kernel/process.c:153) ret_from_fork_asm (arch/x86/entry/entry_64.S:256) Modules linked in:
--- net/ipv6/ip6_fib.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)
net/ipv6/ip6_fib.c +7 -7
@@ -591,19 +591,19 @@ static int inet6_dump_fib(struct sk_buffif (!w) {/* New dump: * -* 1. hook callback destructor. -*/ - cb->args[3 ] = (long )cb->done; - cb->done = fib6_dump_done; - -/* -* 2. allocate and initialize walker. +* 1. allocate and initialize walker. */ w =kzalloc (sizeof (*w),GFP_ATOMIC );if (!w)return -ENOMEM ; w->func = fib6_dump_node; cb->args[2 ] = (long )w; + +/* 2. hook callback destructor. +*/ + cb->args[3 ] = (long )cb->done; + cb->done = fib6_dump_done; + } arg.skb = skb;
Greg Kroah-Hartman
maintainerPATCH 153/215 i40e: fix vf may be used uninitialized in this function warning
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Aleksandr Loktionov <[email protected]>
commit f37c4eac99c258111d414d31b740437e1925b8e8 upstream.
To fix the regression introduced by commit 52424f974bc5, which causes servers hang in very hard to reproduce conditions with resets races. Using two sources for the information is the root cause.
In this function before the fix bumping v didn't mean bumping vf pointer. But the code used this variables interchangeably, so stale vf could point to different/not intended vf.
Remove redundant "v" variable and iterate via single VF pointer across whole function instead to guarantee VF pointer validity.
--- drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 34 +++++++++------------ 1 file changed, 16 insertions(+), 18 deletions(-)
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c +16 -18
@@ -1534,8 +1534,8 @@ bool i40e_reset_all_vfs(struct i40e_pf * {struct i40e_hw *hw = &pf->hw;struct i40e_vf *vf; -int i, v;u32 reg; +int i;/* If we don't have any VFs, then there is nothing to reset */ if (!pf->num_alloc_vfs)
@@ -1546,11 +1546,10 @@ bool i40e_reset_all_vfs(struct i40e_pf *return false;/* Begin reset on all VFs at once */ -for (v =0 ; v < pf->num_alloc_vfs; v++) { - vf = &pf->vf[v]; +for (vf = &pf->vf[0 ]; vf < &pf->vf[pf->num_alloc_vfs]; ++vf) {/* If VF is being reset no need to trigger reset again */ if (!test_bit (I40E_VF_STATE_RESETTING , &vf->vf_states)) -i40e_trigger_vf_reset (&pf->vf[v], flr); +i40e_trigger_vf_reset (vf, flr); }/* HW requires some time to make sure it can flush the FIFO for a VF
@@ -1559,14 +1558,13 @@ bool i40e_reset_all_vfs(struct i40e_pf ** the VFs using a simple iterator that increments once that VF has * finished resetting. */ -for (i =0 , v =0 ; i <10 && v < pf->num_alloc_vfs; i++) { +for (i =0 , vf = &pf->vf[0 ]; i <10 && vf < &pf->vf[pf->num_alloc_vfs]; ++i) {usleep_range (10000 ,20000 );/* Check each VF in sequence, beginning with the VF to fail * the previous check. */ -while (v < pf->num_alloc_vfs) { - vf = &pf->vf[v]; +while (vf < &pf->vf[pf->num_alloc_vfs]) {if (!test_bit (I40E_VF_STATE_RESETTING , &vf->vf_states)) { reg =rd32 (hw,I40E_VPGEN_VFRSTAT (vf->vf_id));if (!(reg &I40E_VPGEN_VFRSTAT_VFRD_MASK ))
@@ -1576,7 +1574,7 @@ bool i40e_reset_all_vfs(struct i40e_pf */* If the current VF has finished resetting, move on * to the next VF in sequence. */ - v++; + ++vf; } }
@@ -1586,39 +1584,39 @@ bool i40e_reset_all_vfs(struct i40e_pf */* Display a warning if at least one VF didn't manage to reset in * time, but continue on with the operation. */ -if (v < pf->num_alloc_vfs) +if (vf < &pf->vf[pf->num_alloc_vfs])dev_err (&pf->pdev->dev,"VF reset check timeout on VF %d\n" , - pf->vf[v].vf_id); + vf->vf_id);usleep_range (10000 ,20000 );/* Begin disabling all the rings associated with VFs, but do not wait * between each VF. */ -for (v =0 ; v < pf->num_alloc_vfs; v++) { +for (vf = &pf->vf[0 ]; vf < &pf->vf[pf->num_alloc_vfs]; ++vf) {/* On initial reset, we don't have any queues to disable */ -if (pf->vf[v].lan_vsi_idx ==0 ) +if (vf->lan_vsi_idx ==0 )continue ;/* If VF is reset in another thread just continue */ if (test_bit (I40E_VF_STATE_RESETTING , &vf->vf_states))continue ; -i40e_vsi_stop_rings_no_wait (pf->vsi[pf->vf[v].lan_vsi_idx]); +i40e_vsi_stop_rings_no_wait (pf->vsi[vf->lan_vsi_idx]); }/* Now that we've notified HW to disable all of the VF rings, wait * until they finish. */ -for (v =0 ; v < pf->num_alloc_vfs; v++) { +for (vf = &pf->vf[0 ]; vf < &pf->vf[pf->num_alloc_vfs]; ++vf) {/* On initial reset, we don't have any queues to disable */ -if (pf->vf[v].lan_vsi_idx ==0 ) +if (vf->lan_vsi_idx ==0 )continue ;/* If VF is reset in another thread just continue */ if (test_bit (I40E_VF_STATE_RESETTING , &vf->vf_states))continue ; -i40e_vsi_wait_queues_disabled (pf->vsi[pf->vf[v].lan_vsi_idx]); +i40e_vsi_wait_queues_disabled (pf->vsi[vf->lan_vsi_idx]); }/* Hw may need up to 50ms to finish disabling the RX queues. We
@@ -1627,12 +1625,12 @@ bool i40e_reset_all_vfs(struct i40e_pf *mdelay (50 );/* Finish the reset on each VF */ -for (v =0 ; v < pf->num_alloc_vfs; v++) { +for (vf = &pf->vf[0 ]; vf < &pf->vf[pf->num_alloc_vfs]; ++vf) {/* If VF is reset in another thread just continue */ if (test_bit (I40E_VF_STATE_RESETTING , &vf->vf_states))continue ; -i40e_cleanup_reset_vf (&pf->vf[v]); +i40e_cleanup_reset_vf (vf); }i40e_flush (hw);
Greg Kroah-Hartman
maintainerPATCH 154/215 staging: mmal-vchiq: Allocate and free components as required
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Stevenson <[email protected]>
[ Upstream commit 8c589e1794a31e9a381916b0280260ab601e4d6e ]
The existing code assumed that there would only ever be 4 components, and never freed the entries once used.
Allow arbitrary creation and destruction of components.
Stable-dep-of: f37e76abd614 ("staging: vc04_services: fix information leak in create_component()")
--- .../vc04_services/bcm2835-camera/mmal-vchiq.c | 29 ++++++++++++------- .../vc04_services/bcm2835-camera/mmal-vchiq.h | 1 + 2 files changed, 20 insertions(+), 10 deletions(-)
drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c +19 -10
@@ -31,8 +31,11 @@#define USE_VCHIQ_ARM #include "interface/vchi/vchi.h" -/* maximum number of components supported */ -#define VCHIQ_MMAL_MAX_COMPONENTS 4 +/* +* maximum number of components supported. +* This matches the maximum permitted by default on the VPU +*/ +#define VCHIQ_MMAL_MAX_COMPONENTS 64/*#define FULL_MSG_DUMP 1*/
@@ -167,8 +170,6 @@ struct vchiq_mmal_instance {/* protect accesses to context_map */ struct mutex context_map_lock; -/* component to use next */ -int component_idx;struct vchiq_mmal_component component[VCHIQ_MMAL_MAX_COMPONENTS ];/* ordered workqueue to process all bulk operations */
@@ -1616,18 +1617,24 @@ int vchiq_mmal_component_init(struct vchiq_mmal_instance *instance, {int ret;int idx;/* port index */ -struct vchiq_mmal_component *component; +struct vchiq_mmal_component *component =NULL ;if (mutex_lock_interruptible (&instance->vchiq_mutex))return -EINTR ; -if (instance->component_idx ==VCHIQ_MMAL_MAX_COMPONENTS ) { +for (idx =0 ; idx <VCHIQ_MMAL_MAX_COMPONENTS ; idx++) { +if (!instance->component[idx].in_use) { + component = &instance->component[idx]; + component->in_use =1 ; +break ; + } + } + +if (!component) { ret = -EINVAL ;/* todo is this correct error? */ goto unlock; } - component = &instance->component[instance->component_idx]; - ret =create_component (instance, component, name);if (ret <0 ) { pr_err("%s: failed to create component %d (Not enough GPU mem?)\n",
@@ -1678,8 +1685,6 @@ int vchiq_mmal_component_init(struct vchiq_mmal_instance *instance, goto release_component; } - instance->component_idx++; - *component_out = component;mutex_unlock (&instance->vchiq_mutex);
@@ -1689,6 +1694,8 @@ int vchiq_mmal_component_init(struct vchiq_mmal_instance *instance, release_component:destroy_component (instance, component); unlock: +if (component) + component->in_use =0 ;mutex_unlock (&instance->vchiq_mutex);return ret;
@@ -1710,6 +1717,8 @@ int vchiq_mmal_component_finalise(struct vchiq_mmal_instance *instance, ret =destroy_component (instance, component); + component->in_use =0 ; +mutex_unlock (&instance->vchiq_mutex);return ret;
drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.h +1 -0
@@ -82,6 +82,7 @@ struct vchiq_mmal_port { };struct vchiq_mmal_component { +u32 in_use:1 ;u32 enabled:1 ;u32 handle;/* VideoCore handle for component */ u32 inputs;/* Number of input ports */
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 155/215 staging: mmal-vchiq: Fix client_component for 64 bit kernel
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Stevenson <[email protected]>
[ Upstream commit 22e64b486adc4785542f8002c3af4c895490f841 ]
The MMAL client_component field is used with the event mechanism to allow the client to identify the component for which the event is generated.
The field is only 32bits in size, therefore we can't use a pointer to the component in a 64 bit kernel.
Component handles are already held in an array per VCHI instance, so use the array index as the client_component handle to avoid having to create a new IDR for this purpose.
Stable-dep-of: f37e76abd614 ("staging: vc04_services: fix information leak in create_component()")
--- drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c | 8 +++++++- drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.h | 1 + 2 files changed, 8 insertions(+), 1 deletion(-)
drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c +7 -1
@@ -928,7 +928,7 @@ static int create_component(struct vchiq_mmal_instance *instance,/* build component create message */ m.h.type =MMAL_MSG_TYPE_COMPONENT_CREATE ; - m.u.component_create.client_component = (u32 )(unsigned long )component; + m.u.component_create.client_component = component->client_component;strncpy (m.u.component_create.name, name,sizeof (m.u.component_create.name));
@@ -1635,6 +1635,12 @@ int vchiq_mmal_component_init(struct vchiq_mmal_instance *instance, goto unlock; } +/* We need a handle to reference back to our component structure. +* Use the array index in instance->component rather than rolling +* another IDR. +*/ + component->client_component = idx; + ret =create_component (instance, component, name);if (ret <0 ) { pr_err("%s: failed to create component %d (Not enough GPU mem?)\n",
drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.h +1 -0
@@ -92,6 +92,7 @@ struct vchiq_mmal_component {struct vchiq_mmal_port input[MAX_PORT_COUNT ];/* input ports */ struct vchiq_mmal_port output[MAX_PORT_COUNT ];/* output ports */ struct vchiq_mmal_port clock[MAX_PORT_COUNT ];/* clock ports */ +u32 client_component;/* Used to ref back to client struct */ };int vchiq_mmal_init (struct vchiq_mmal_instance **out_instance);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 156/215 staging: vc04_services: changen strncpy() to strscpy_pad()
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <[email protected]>
[ Upstream commit ef25725b7f8aaffd7756974d3246ec44fae0a5cf ]
gcc-14 warns about this strncpy() that results in a non-terminated string for an overflow:
In file included from include/linux/string.h:369,
from drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c:20:
In function 'strncpy',
inlined from 'create_component' at drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c:940:2:include/linux/fortify-string.h:108:33: error: '__builtin_strncpy' specified bound 128 equals destination size [-Werror=stringop-truncation]
Change it to strscpy_pad(), which produces a properly terminated and zero-padded string.
Stable-dep-of: f37e76abd614 ("staging: vc04_services: fix information leak in create_component()")
--- drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c +2 -2
@@ -929,8 +929,8 @@ static int create_component(struct vchiq_mmal_instance *instance,/* build component create message */ m.h.type =MMAL_MSG_TYPE_COMPONENT_CREATE ; m.u.component_create.client_component = component->client_component; -strncpy (m.u.component_create.name, name, -sizeof (m.u.component_create.name)); +strscpy_pad (m.u.component_create.name, name, +sizeof (m.u.component_create.name)); ret = send_synchronous_mmal_msg(instance, &m, sizeof(m.u.component_create),
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 157/215 staging: vc04_services: fix information leak in create_component()
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
[ Upstream commit f37e76abd614b68987abc8e5c22d986013349771 ]
The m.u.component_create.pid field is for debugging and in the mainline kernel it's not used anything. However, it still needs to be set to something to prevent disclosing uninitialized stack data. Set it to zero.
--- drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c | 1 + 1 file changed, 1 insertion(+)
drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c +1 -0
@@ -931,6 +931,7 @@ static int create_component(struct vchiq_mmal_instance *instance, m.u.component_create.client_component = component->client_component;strscpy_pad (m.u.component_create.name, name,sizeof (m.u.component_create.name)); + m.u.component_create.pid =0 ; ret = send_synchronous_mmal_msg(instance, &m, sizeof(m.u.component_create),
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 158/215 fs: add a vfs_fchown helper
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christoph Hellwig <[email protected]>
[ Upstream commit c04011fe8cbd80af1be6e12b53193bf3846750d7 ]
Add a helper for struct file based chown operations. To be used by the initramfs code soon.
Stable-dep-of: 4624b346cf67 ("init: open /initrd.image with O_LARGEFILE")
--- fs/open.c | 29 +++++++++++++++++------------ include/linux/fs.h | 2 ++ 2 files changed, 19 insertions(+), 12 deletions(-)
fs/open.c +17 -12
@@ -708,23 +708,28 @@ SYSCALL_DEFINE3(lchown, const char __user *, filename, uid_t, user, gid_t, group AT_SYMLINK_NOFOLLOW); } +int vfs_fchown (struct file *file,uid_t user,gid_t group) +{ +int error; + + error =mnt_want_write_file (file); +if (error) +return error; +audit_file (file); + error =chown_common (&file->f_path, user, group); +mnt_drop_write_file (file); +return error; +} +int ksys_fchown (unsigned int fd,uid_t user,gid_t group) {struct fd f =fdget (fd);int error = -EBADF ; -if (!f.file) - goto out; - - error =mnt_want_write_file (f.file); -if (error) - goto out_fput; -audit_file (f.file); - error =chown_common (&f.file->f_path, user, group); -mnt_drop_write_file (f.file); -out_fput: -fdput (f); -out: +if (f.file) { + error =vfs_fchown (f.file, user, group); +fdput (f); + }return error; }
include/linux/fs.h +2 -0
@@ -1730,6 +1730,8 @@ int vfs_mkobj(struct dentry *, umode_t,int (*f)(struct dentry *,umode_t ,void *), void *); +int vfs_fchown (struct file *file,uid_t user,gid_t group); +extern long vfs_ioctl (struct file *file,unsigned int cmd,unsigned long arg);#ifdef CONFIG_COMPAT
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 159/215 fs: add a vfs_fchmod helper
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christoph Hellwig <[email protected]>
[ Upstream commit 9e96c8c0e94eea2f69a9705f5d0f51928ea26c17 ]
Add a helper for struct file based chmode operations. To be used by the initramfs code soon.
Stable-dep-of: 4624b346cf67 ("init: open /initrd.image with O_LARGEFILE")
--- fs/open.c | 9 +++++++-- include/linux/fs.h | 1 + 2 files changed, 8 insertions(+), 2 deletions(-)
fs/open.c +7 -2
@@ -570,14 +570,19 @@ static int chmod_common(const struct path *path, umode_t mode)return error; } +int vfs_fchmod (struct file *file,umode_t mode) +{ +audit_file (file); +return chmod_common (&file->f_path, mode); +} +int ksys_fchmod (unsigned int fd,umode_t mode) {struct fd f =fdget (fd);int err = -EBADF ;if (f.file) { -audit_file (f.file); - err =chmod_common (&f.file->f_path, mode); + err =vfs_fchmod (f.file, mode);fdput (f); }return err;
include/linux/fs.h +1 -0
@@ -1731,6 +1731,7 @@ int vfs_mkobj(struct dentry *, umode_t, void *);int vfs_fchown (struct file *file,uid_t user,gid_t group); +int vfs_fchmod (struct file *file,umode_t mode);extern long vfs_ioctl (struct file *file,unsigned int cmd,unsigned long arg);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 160/215 initramfs: switch initramfs unpacking to struct file based APIs
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christoph Hellwig <[email protected]>
[ Upstream commit bf6419e4d5440c6d414a320506c5488857a5b001 ]
There is no good reason to mess with file descriptors from in-kernel code, switch the initramfs unpacking to struct file based write instead.
Stable-dep-of: 4624b346cf67 ("init: open /initrd.image with O_LARGEFILE")
--- init/initramfs.c | 47 ++++++++++++++++++++++++++--------------------- 1 file changed, 26 insertions(+), 21 deletions(-)
init/initramfs.c +26 -21
@@ -11,13 +11,14 @@#include <linux/utime.h> #include <linux/file.h> -static ssize_t __init xwrite (int fd,const char *p,size_t count) +static ssize_t __init xwrite (struct file *file,const char *p,size_t count, +loff_t *pos) {ssize_t out =0 ;/* sys_write only can write MAX_RW_COUNT aka 2G-4K bytes at most */ while (count) { -ssize_t rv =ksys_write (fd, p, count); +ssize_t rv =kernel_write (file, p, count, pos);if (rv <0 ) {if (rv == -EINTR || rv == -EAGAIN )
@@ -315,7 +316,8 @@ static int __init maybe_link(void)return 0 ; } -static __initdata int wfd; +static __initdata struct file *wfile; +static __initdata loff_t wfile_pos;static int __init do_name (void ) {
@@ -332,16 +334,17 @@ static int __init do_name(void)int openflags =O_WRONLY |O_CREAT ;if (ml !=1 ) openflags |=O_TRUNC ; - wfd =ksys_open (collected, openflags, mode); - -if (wfd >=0 ) { -ksys_fchown (wfd, uid, gid); -ksys_fchmod (wfd, mode); -if (body_len) -ksys_ftruncate (wfd, body_len); - vcollected =kstrdup (collected,GFP_KERNEL ); - state = CopyFile; - } + wfile =filp_open (collected, openflags, mode); +if (IS_ERR (wfile)) +return 0 ; + wfile_pos =0 ; + +vfs_fchown (wfile, uid, gid); +vfs_fchmod (wfile, mode); +if (body_len) +vfs_truncate (&wfile->f_path, body_len); + vcollected =kstrdup (collected,GFP_KERNEL ); + state = CopyFile; } }else if (S_ISDIR (mode)) {ksys_mkdir (collected, mode);
@@ -363,16 +366,16 @@ static int __init do_name(void)static int __init do_copy (void ) {if (byte_count >= body_len) { -if (xwrite (wfd, victim, body_len) != body_len) +if (xwrite (wfile, victim, body_len, &wfile_pos) != body_len)error ("write error" ); -ksys_close (wfd); +fput (wfile);do_utime (vcollected, mtime);kfree (vcollected);eat (body_len); state = SkipIt;return 0 ; }else { -if (xwrite (wfd, victim, byte_count) != byte_count) +if (xwrite (wfile, victim, byte_count, &wfile_pos) != byte_count)error ("write error" ); body_len -= byte_count;eat (byte_count);
@@ -620,21 +623,23 @@ static inline void clean_rootfs(void)static void __init populate_initrd_image (char *err) {ssize_t written; -int fd; +struct file *file; +loff_t pos =0 ;unpack_to_rootfs (__initramfs_start, __initramfs_size);printk (KERN_INFO "rootfs image is not initramfs (%s); looks like an initrd\n" , err); - fd =ksys_open ("/initrd.image" ,O_WRONLY |O_CREAT ,0700 ); -if (fd <0 ) + file =filp_open ("/initrd.image" ,O_WRONLY |O_CREAT ,0700 ); +if (IS_ERR (file))return ; - written =xwrite (fd, (char *)initrd_start, initrd_end - initrd_start); + written =xwrite (file, (char *)initrd_start, initrd_end - initrd_start, + &pos);if (written != initrd_end - initrd_start)pr_err ("/initrd.image: incomplete write (%zd != %ld)\n" , written, initrd_end - initrd_start); -ksys_close (fd); +fput (file); }#else static void __init populate_initrd_image (char *err)
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 161/215 init: open /initrd.image with O_LARGEFILE
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: John Sperbeck <[email protected]>
[ Upstream commit 4624b346cf67400ef46a31771011fb798dd2f999 ]
If initrd data is larger than 2Gb, we'll eventually fail to write to the /initrd.image file when we hit that limit, unless O_LARGEFILE is set.
--- init/initramfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
init/initramfs.c +1 -1
@@ -630,7 +630,7 @@ static void __init populate_initrd_image(char *err)printk (KERN_INFO "rootfs image is not initramfs (%s); looks like an initrd\n" , err); - file =filp_open ("/initrd.image" ,O_WRONLY |O_CREAT ,0700 ); + file =filp_open ("/initrd.image" ,O_WRONLY |O_CREAT |O_LARGEFILE ,0700 );if (IS_ERR (file))return ;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 162/215 erspan: Add type I version 0 support.
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: William Tu <[email protected]>
[ Upstream commit f989d546a2d5a9f001f6f8be49d98c10ab9b1897 ]
The Type I ERSPAN frame format is based on the barebones IP + GRE(4-byte) encapsulation on top of the raw mirrored frame. Both type I and II use 0x88BE as protocol type. Unlike type II and III, no sequence number or key is required.
To creat a type I erspan tunnel device:
$ ip link add dev erspan11 type erspan \
local 172.16.1.100 remote 172.16.1.200 \
erspan_ver 0Stable-dep-of: 17af420545a7 ("erspan: make sure erspan_base_hdr is present in skb->head")
--- include/net/erspan.h | 19 +++++++++++++-- net/ipv4/ip_gre.c | 58 ++++++++++++++++++++++++++++++++------------ 2 files changed, 60 insertions(+), 17 deletions(-)
include/net/erspan.h +17 -2
@@ -2,7 +2,19 @@#define __LINUX_ERSPAN_H/* -* GRE header for ERSPAN encapsulation (8 octets [34:41]) -- 8 bytes +* GRE header for ERSPAN type I encapsulation (4 octets [34:37]) +* 0 1 2 3 +* 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +* |0|0|0|0|0|00000|000000000|00000| Protocol Type for ERSPAN | +* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +* +* The Type I ERSPAN frame format is based on the barebones IP + GRE +* encapsulation (as described above) on top of the raw mirrored frame. +* There is no extra ERSPAN header. +* +* +* GRE header for ERSPAN type II and II encapsulation (8 octets [34:41]) * 0 1 2 3 * 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -43,7 +55,7 @@* | Platform Specific Info | * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * -* GRE proto ERSPAN type II = 0x88BE, type III = 0x22EB +* GRE proto ERSPAN type I/II = 0x88BE, type III = 0x22EB */ #include <uapi/linux/erspan.h>
@@ -139,6 +151,9 @@ static inline u8 get_hwid(const struct erspan_md2 *md2)static inline int erspan_hdr_len (int version) { +if (version ==0 ) +return 0 ; +return sizeof (struct erspan_base_hdr ) + (version ==1 ?ERSPAN_V1_MDSIZE :ERSPAN_V2_MDSIZE ); }
net/ipv4/ip_gre.c +43 -15
109 lines not on this page · raw message
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 163/215 erspan: make sure erspan_base_hdr is present in skb->head
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 17af420545a750f763025149fa7b833a4fc8b8f0 ]
syzbot reported a problem in ip6erspan_rcv() [1]
Issue is that ip6erspan_rcv() (and erspan_rcv()) no longer make sure erspan_base_hdr is present in skb linear part (skb->head) before getting @ver field from it.
Add the missing pskb_may_pull() calls.
v2: Reload iph pointer in erspan_rcv() after pskb_may_pull()
because skb->head might have changed.
[1]
BUG: KMSAN: uninit-value in pskb_may_pull_reason include/linux/skbuff.h:2742 [inline] BUG: KMSAN: uninit-value in pskb_may_pull include/linux/skbuff.h:2756 [inline] BUG: KMSAN: uninit-value in ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline] BUG: KMSAN: uninit-value in gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610 pskb_may_pull_reason include/linux/skbuff.h:2742 [inline] pskb_may_pull include/linux/skbuff.h:2756 [inline] ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline] gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610 ip6_protocol_deliver_rcu+0x1d4c/0x2ca0 net/ipv6/ip6_input.c:438 ip6_input_finish net/ipv6/ip6_input.c:483 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492 ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586 dst_input include/net/dst.h:460 [inline] ip6_rcv_finish+0x955/0x970 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:314 [inline] ipv6_rcv+0xde/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5538 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5652 netif_receive_skb_internal net/core/dev.c:5738 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5798 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1549 tun_get_user+0x5566/0x69e0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2108 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb63/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xe0 fs/read_write.c:652 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75
Uninit was created at:
slab_post_alloc_hook mm/slub.c:3804 [inline] slab_alloc_node mm/slub.c:3845 [inline] kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577 __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668 alloc_skb include/linux/skbuff.h:1318 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795 tun_alloc_skb drivers/net/tun.c:1525 [inline] tun_get_user+0x209a/0x69e0 drivers/net/tun.c:1846 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2108 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb63/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xe0 fs/read_write.c:652 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 CPU: 1 PID: 5045 Comm: syz-executor114 Not tainted 6.9.0-rc1-syzkaller-00021-g962490525cff #0
--- net/ipv4/ip_gre.c | 5 +++++ net/ipv6/ip6_gre.c | 3 +++ 2 files changed, 8 insertions(+)
net/ipv4/ip_gre.c +5 -0
@@ -278,8 +278,13 @@ static int erspan_rcv(struct sk_buff *skb, struct tnl_ptk_info *tpi, tpi->flags |TUNNEL_NO_KEY , iph->saddr, iph->daddr, 0); }else { +if (unlikely (!pskb_may_pull (skb, + gre_hdr_len +sizeof (*ershdr)))) +return PACKET_REJECT ; + ershdr = (struct erspan_base_hdr *)(skb->data + gre_hdr_len); ver = ershdr->ver; + iph =ip_hdr (skb); tunnel =ip_tunnel_lookup (itn, skb->dev->ifindex, tpi->flags |TUNNEL_KEY , iph->saddr, iph->daddr, tpi->key);
net/ipv6/ip6_gre.c +3 -0
@@ -531,6 +531,9 @@ static int ip6erspan_rcv(struct sk_buff *skb,struct ip6_tnl *tunnel;u8 ver; +if (unlikely (!pskb_may_pull (skb,sizeof (*ershdr)))) +return PACKET_REJECT ; + ipv6h =ipv6_hdr (skb); ershdr = (struct erspan_base_hdr *)skb->data; ver = ershdr->ver;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 164/215 net: ravb: Always process TX descriptor ring
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Barker <[email protected]>
[ Upstream commit 596a4254915f94c927217fe09c33a6828f33fb25 ]
The TX queue should be serviced each time the poll function is called, even if the full RX work budget has been consumed. This prevents starvation of the TX queue when RX bandwidth usage is high.
--- drivers/net/ethernet/renesas/ravb_main.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/net/ethernet/renesas/ravb_main.c +5 -2
@@ -911,12 +911,12 @@ static int ravb_poll(struct napi_struct *napi, int budget)int q = napi - priv->napi;int mask =BIT (q);int quota = budget; +bool unmask;/* Processing RX Descriptor Ring */ /* Clear RX interrupt */ ravb_write (ndev, ~(mask |RIS0_RESERVED ),RIS0 ); -if (ravb_rx (ndev, "a, q)) - goto out; + unmask = !ravb_rx (ndev, "a, q);/* Processing RX Descriptor Ring */ spin_lock_irqsave (&priv->lock, flags);
@@ -926,6 +926,9 @@ static int ravb_poll(struct napi_struct *napi, int budget)netif_wake_subqueue (ndev, q);spin_unlock_irqrestore (&priv->lock, flags); +if (!unmask) + goto out; +napi_complete (napi);/* Re-enable RX/TX interrupts */
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 165/215 ASoC: ops: Fix wraparound for mask in snd_soc_get_volsw
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stephen Lee <[email protected]>
[ Upstream commit fc563aa900659a850e2ada4af26b9d7a3de6c591 ]
In snd_soc_info_volsw(), mask is generated by figuring out the index of the most significant bit set in max and converting the index to a bitmask through bit shift 1. Unintended wraparound occurs when max is an integer value with msb bit set. Since the bit shift value 1 is treated as an integer type, the left shift operation will wraparound and set mask to 0 instead of all 1's. In order to fix this, we type cast 1 as 1ULL to prevent the wraparound.
--- sound/soc/soc-ops.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
sound/soc/soc-ops.c +1 -1
@@ -252,7 +252,7 @@ int snd_soc_get_volsw(struct snd_kcontrol *kcontrol,int max = mc->max;int min = mc->min;int sign_bit = mc->sign_bit; -unsigned int mask = (1 <<fls (max)) -1 ; +unsigned int mask = (1ULL <<fls (max)) -1 ;unsigned int invert = mc->invert;int val;int ret;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 166/215 ata: sata_sx4: fix pdc20621_get_from_dimm() on 64-bit
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <[email protected]>
[ Upstream commit 52f80bb181a9a1530ade30bc18991900bbb9697f ]
gcc warns about a memcpy() with overlapping pointers because of an incorrect size calculation:
In file included from include/linux/string.h:369,
from drivers/ata/sata_sx4.c:66:
In function 'memcpy_fromio',
inlined from 'pdc20621_get_from_dimm.constprop' at drivers/ata/sata_sx4.c:962:2:
include/linux/fortify-string.h:97:33: error: '__builtin_memcpy' accessing 4294934464 bytes at offsets 0 and [16, 16400] overlaps 6442385281 bytes at offset -2147450817 [-Werror=restrict]
97 | #define __underlying_memcpy __builtin_memcpy
| ^
include/linux/fortify-string.h:620:9: note: in expansion of macro '__underlying_memcpy'
620 | __underlying_##op(p, q, __fortify_size); \
| ^~~~~~~~~~~~~
include/linux/fortify-string.h:665:26: note: in expansion of macro '__fortify_memcpy_chk'
665 | #define memcpy(p, q, s) __fortify_memcpy_chk(p, q, s, \
| ^~~~~~~~~~~~~~~~~~~~
include/asm-generic/io.h:1184:9: note: in expansion of macro 'memcpy'
1184 | memcpy(buffer, __io_virt(addr), size);
| ^~~~~~The problem here is the overflow of an unsigned 32-bit number to a negative that gets converted into a signed 'long', keeping a large positive number.
Replace the complex calculation with a more readable min() variant that avoids the warning.
--- drivers/ata/sata_sx4.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
drivers/ata/sata_sx4.c +2 -4
@@ -1004,8 +1004,7 @@ static void pdc20621_get_from_dimm(struct ata_host *host, void *psource, offset -= (idx * window_size); idx++; - dist = ((long ) (window_size - (offset + size))) >=0 ? size : - (long ) (window_size - offset); + dist =min (size, window_size - offset);memcpy_fromio (psource, dimm_mmio + offset /4 , dist); psource += dist;
@@ -1053,8 +1052,7 @@ static void pdc20621_put_to_dimm(struct ata_host *host, void *psource,readl (mmio +PDC_DIMM_WINDOW_CTLR ); offset -= (idx * window_size); idx++; - dist = ((long )(s32)(window_size - (offset + size))) >=0 ? size : - (long ) (window_size - offset); + dist =min (size, window_size - offset);memcpy_toio (dimm_mmio + offset /4 , psource, dist);writel (0x01 , mmio +PDC_GENERAL_CTLR );readl (mmio +PDC_GENERAL_CTLR );
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 167/215 scsi: mylex: Fix sysfs buffer lengths
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <[email protected]>
[ Upstream commit 1197c5b2099f716b3de327437fb50900a0b936c9 ]
The myrb and myrs drivers use an odd way of implementing their sysfs files, calling snprintf() with a fixed length of 32 bytes to print into a page sized buffer. One of the strings is actually longer than 32 bytes, which clang can warn about:
drivers/scsi/myrb.c:1906:10: error: 'snprintf' will always be truncated; specified size is 32, but format string expands to at least 34 [-Werror,-Wformat-truncation] drivers/scsi/myrs.c:1089:10: error: 'snprintf' will always be truncated; specified size is 32, but format string expands to at least 34 [-Werror,-Wformat-truncation]
These could all be plain sprintf() without a length as the buffer is always long enough. On the other hand, sysfs files should not be overly long either, so just double the length to make sure the longest strings don't get truncated here.
--- drivers/scsi/myrb.c | 20 ++++++++++---------- drivers/scsi/myrs.c | 24 ++++++++++++------------ 2 files changed, 22 insertions(+), 22 deletions(-)
drivers/scsi/myrb.c +10 -10
@@ -1803,9 +1803,9 @@ static ssize_t raid_state_show(struct device *dev, name =myrb_devstate_name (ldev_info->state);if (name) - ret =snprintf (buf,32 ,"%s\n" , name); + ret =snprintf (buf,64 ,"%s\n" , name);else - ret =snprintf (buf,32 ,"Invalid (%02X)\n" , + ret =snprintf (buf,64 ,"Invalid (%02X)\n" , ldev_info->state); }else {struct myrb_pdev_state *pdev_info = sdev->hostdata;
@@ -1824,9 +1824,9 @@ static ssize_t raid_state_show(struct device *dev,else name =myrb_devstate_name (pdev_info->state);if (name) - ret =snprintf (buf,32 ,"%s\n" , name); + ret =snprintf (buf,64 ,"%s\n" , name);else - ret =snprintf (buf,32 ,"Invalid (%02X)\n" , + ret =snprintf (buf,64 ,"Invalid (%02X)\n" , pdev_info->state); }return ret;
@@ -1914,11 +1914,11 @@ static ssize_t raid_level_show(struct device *dev, name =myrb_raidlevel_name (ldev_info->raid_level);if (!name) -return snprintf (buf,32 ,"Invalid (%02X)\n" , +return snprintf (buf,64 ,"Invalid (%02X)\n" , ldev_info->state); -return snprintf (buf,32 ,"%s\n" , name); +return snprintf (buf,64 ,"%s\n" , name); } -return snprintf (buf,32 ,"Physical Drive\n" ); +return snprintf (buf,64 ,"Physical Drive\n" ); }static DEVICE_ATTR_RO (raid_level);
@@ -1931,15 +1931,15 @@ static ssize_t rebuild_show(struct device *dev,unsigned char status;if (sdev->channel <myrb_logical_channel (sdev->host)) -return snprintf (buf,32 ,"physical device - not rebuilding\n" ); +return snprintf (buf,64 ,"physical device - not rebuilding\n" ); status =myrb_get_rbld_progress (cb, &rbld_buf);if (rbld_buf.ldev_num != sdev->id || status !=MYRB_STATUS_SUCCESS ) -return snprintf (buf,32 ,"not rebuilding\n" ); +return snprintf (buf,64 ,"not rebuilding\n" ); -return snprintf (buf,32 ,"rebuilding block %u of %u\n" , +return snprintf (buf,64 ,"rebuilding block %u of %u\n" , rbld_buf.ldev_size - rbld_buf.blocks_left, rbld_buf.ldev_size); }
drivers/scsi/myrs.c +12 -12
@@ -950,9 +950,9 @@ static ssize_t raid_state_show(struct device *dev, name =myrs_devstate_name (ldev_info->dev_state);if (name) - ret =snprintf (buf,32 ,"%s\n" , name); + ret =snprintf (buf,64 ,"%s\n" , name);else - ret =snprintf (buf,32 ,"Invalid (%02X)\n" , + ret =snprintf (buf,64 ,"Invalid (%02X)\n" , ldev_info->dev_state); }else {struct myrs_pdev_info *pdev_info;
@@ -961,9 +961,9 @@ static ssize_t raid_state_show(struct device *dev, pdev_info = sdev->hostdata; name =myrs_devstate_name (pdev_info->dev_state);if (name) - ret =snprintf (buf,32 ,"%s\n" , name); + ret =snprintf (buf,64 ,"%s\n" , name);else - ret =snprintf (buf,32 ,"Invalid (%02X)\n" , + ret =snprintf (buf,64 ,"Invalid (%02X)\n" , pdev_info->dev_state); }return ret;
@@ -1069,13 +1069,13 @@ static ssize_t raid_level_show(struct device *dev, ldev_info = sdev->hostdata; name =myrs_raid_level_name (ldev_info->raid_level);if (!name) -return snprintf (buf,32 ,"Invalid (%02X)\n" , +return snprintf (buf,64 ,"Invalid (%02X)\n" , ldev_info->dev_state); }else name =myrs_raid_level_name (MYRS_RAID_PHYSICAL ); -return snprintf (buf,32 ,"%s\n" , name); +return snprintf (buf,64 ,"%s\n" , name); }static DEVICE_ATTR_RO (raid_level);
@@ -1089,7 +1089,7 @@ static ssize_t rebuild_show(struct device *dev,unsigned char status;if (sdev->channel < cs->ctlr_info->physchan_present) -return snprintf (buf,32 ,"physical device - not rebuilding\n" ); +return snprintf (buf,64 ,"physical device - not rebuilding\n" ); ldev_info = sdev->hostdata; ldev_num = ldev_info->ldev_num;
@@ -1101,11 +1101,11 @@ static ssize_t rebuild_show(struct device *dev,return -EIO ; }if (ldev_info->rbld_active) { -return snprintf (buf,32 ,"rebuilding block %zu of %zu\n" , +return snprintf (buf,64 ,"rebuilding block %zu of %zu\n" , (size_t )ldev_info->rbld_lba, (size_t )ldev_info->cfg_devsize); }else -return snprintf (buf,32 ,"not rebuilding\n" ); +return snprintf (buf,64 ,"not rebuilding\n" ); } static ssize_t rebuild_store(struct device *dev,
@@ -1194,7 +1194,7 @@ static ssize_t consistency_check_show(struct device *dev,unsigned char status;if (sdev->channel < cs->ctlr_info->physchan_present) -return snprintf (buf,32 ,"physical device - not checking\n" ); +return snprintf (buf,64 ,"physical device - not checking\n" ); ldev_info = sdev->hostdata;if (!ldev_info)
@@ -1202,11 +1202,11 @@ static ssize_t consistency_check_show(struct device *dev, ldev_num = ldev_info->ldev_num; status =myrs_get_ldev_info (cs, ldev_num, ldev_info);if (ldev_info->cc_active) -return snprintf (buf,32 ,"checking block %zu of %zu\n" , +return snprintf (buf,64 ,"checking block %zu of %zu\n" , (size_t )ldev_info->cc_lba, (size_t )ldev_info->cfg_devsize);else -return snprintf (buf,32 ,"not checking\n" ); +return snprintf (buf,64 ,"not checking\n" ); } static ssize_t consistency_check_store(struct device *dev,
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 168/215 ata: sata_mv: Fix PCI device ID table declaration compilation warning
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <[email protected]>
[ Upstream commit 3137b83a90646917c90951d66489db466b4ae106 ]
Building with W=1 shows a warning for an unused variable when CONFIG_PCI is diabled:
drivers/ata/sata_mv.c:790:35: error: unused variable 'mv_pci_tbl' [-Werror,-Wunused-const-variable] static const struct pci_device_id mv_pci_tbl[] = {
Move the table into the same block that containsn the pci_driver definition.
--- drivers/ata/sata_mv.c | 63 +++++++++++++++++++++---------------------- 1 file changed, 31 insertions(+), 32 deletions(-)
drivers/ata/sata_mv.c +31 -32
@@ -783,37 +783,6 @@ static const struct ata_port_info mv_port_info[] = { }, }; -static const struct pci_device_id mv_pci_tbl[] = { - {PCI_VDEVICE (MARVELL ,0x5040 ), chip_504x }, - {PCI_VDEVICE (MARVELL ,0x5041 ), chip_504x }, - {PCI_VDEVICE (MARVELL ,0x5080 ), chip_5080 }, - {PCI_VDEVICE (MARVELL ,0x5081 ), chip_508x }, -/* RocketRAID 1720/174x have different identifiers */ - {PCI_VDEVICE (TTI ,0x1720 ), chip_6042 }, - {PCI_VDEVICE (TTI ,0x1740 ), chip_6042 }, - {PCI_VDEVICE (TTI ,0x1742 ), chip_6042 }, - - {PCI_VDEVICE (MARVELL ,0x6040 ), chip_604x }, - {PCI_VDEVICE (MARVELL ,0x6041 ), chip_604x }, - {PCI_VDEVICE (MARVELL ,0x6042 ), chip_6042 }, - {PCI_VDEVICE (MARVELL ,0x6080 ), chip_608x }, - {PCI_VDEVICE (MARVELL ,0x6081 ), chip_608x }, - - {PCI_VDEVICE (ADAPTEC2 ,0x0241 ), chip_604x }, - -/* Adaptec 1430SA */ - {PCI_VDEVICE (ADAPTEC2 ,0x0243 ), chip_7042 }, - -/* Marvell 7042 support */ - {PCI_VDEVICE (MARVELL ,0x7042 ), chip_7042 }, - -/* Highpoint RocketRAID PCIe series */ - {PCI_VDEVICE (TTI ,0x2300 ), chip_7042 }, - {PCI_VDEVICE (TTI ,0x2310 ), chip_7042 }, - - { }/* terminate list */ -}; -static const struct mv_hw_ops mv5xxx_ops = { .phy_errata = mv5_phy_errata, .enable_leds = mv5_enable_leds,
@@ -4307,6 +4276,36 @@ static int mv_pci_init_one(struct pci_dev *pdev,static int mv_pci_device_resume (struct pci_dev *pdev);#endif +static const struct pci_device_id mv_pci_tbl[] = { + {PCI_VDEVICE (MARVELL ,0x5040 ), chip_504x }, + {PCI_VDEVICE (MARVELL ,0x5041 ), chip_504x }, + {PCI_VDEVICE (MARVELL ,0x5080 ), chip_5080 }, + {PCI_VDEVICE (MARVELL ,0x5081 ), chip_508x }, +/* RocketRAID 1720/174x have different identifiers */ + {PCI_VDEVICE (TTI ,0x1720 ), chip_6042 }, + {PCI_VDEVICE (TTI ,0x1740 ), chip_6042 }, + {PCI_VDEVICE (TTI ,0x1742 ), chip_6042 }, + + {PCI_VDEVICE (MARVELL ,0x6040 ), chip_604x }, + {PCI_VDEVICE (MARVELL ,0x6041 ), chip_604x }, + {PCI_VDEVICE (MARVELL ,0x6042 ), chip_6042 }, + {PCI_VDEVICE (MARVELL ,0x6080 ), chip_608x }, + {PCI_VDEVICE (MARVELL ,0x6081 ), chip_608x }, + + {PCI_VDEVICE (ADAPTEC2 ,0x0241 ), chip_604x }, + +/* Adaptec 1430SA */ + {PCI_VDEVICE (ADAPTEC2 ,0x0243 ), chip_7042 }, + +/* Marvell 7042 support */ + {PCI_VDEVICE (MARVELL ,0x7042 ), chip_7042 }, + +/* Highpoint RocketRAID PCIe series */ + {PCI_VDEVICE (TTI ,0x2300 ), chip_7042 }, + {PCI_VDEVICE (TTI ,0x2310 ), chip_7042 }, + + { }/* terminate list */ +};static struct pci_driver mv_pci_driver = { .name =DRV_NAME ,
@@ -4319,6 +4318,7 @@ static struct pci_driver mv_pci_driver = {#endif }; +MODULE_DEVICE_TABLE (pci, mv_pci_tbl);/** * mv_print_info - Dump key info to kernel log for perusal.
@@ -4491,7 +4491,6 @@ static void __exit mv_exit(void)MODULE_AUTHOR ("Brett Russ" );MODULE_DESCRIPTION ("SCSI low-level driver for Marvell SATA controllers" );MODULE_LICENSE ("GPL v2" ); -MODULE_DEVICE_TABLE (pci, mv_pci_tbl);MODULE_VERSION (DRV_VERSION );MODULE_ALIAS ("platform:" DRV_NAME );
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 169/215 ALSA: hda/realtek: Update Panasonic CF-SZ6 quirk to support headset with microphone
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: I Gede Agastya Darma Laksana <[email protected]>
commit 1576f263ee2147dc395531476881058609ad3d38 upstream.
This patch addresses an issue with the Panasonic CF-SZ6's existing quirk, specifically its headset microphone functionality. Previously, the quirk used ALC269_FIXUP_HEADSET_MODE, which does not support the CF-SZ6's design of a single 3.5mm jack for both mic and audio output effectively. The device uses pin 0x19 for the headset mic without jack detection.
Following verification on the CF-SZ6 and discussions with the original patch author, i determined that the update to ALC269_FIXUP_ASPIRE_HEADSET_MIC is the appropriate solution. This change is custom-designed for the CF-SZ6's unique hardware setup, which includes a single 3.5mm jack for both mic and audio output, connecting the headset microphone to pin 0x19 without the use of jack detection.
Message-ID: <[email protected]>
--- sound/pci/hda/patch_realtek.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
sound/pci/hda/patch_realtek.c +1 -1
@@ -8335,7 +8335,7 @@ static const struct snd_pci_quirk alc269SND_PCI_QUIRK (0x10ec ,0x124c ,"Intel Reference board" ,ALC295_FIXUP_CHROME_BOOK ),SND_PCI_QUIRK (0x10ec ,0x1252 ,"Intel Reference board" ,ALC295_FIXUP_CHROME_BOOK ),SND_PCI_QUIRK (0x10ec ,0x1254 ,"Intel Reference board" ,ALC295_FIXUP_CHROME_BOOK ), -SND_PCI_QUIRK (0x10f7 ,0x8338 ,"Panasonic CF-SZ6" ,ALC269_FIXUP_HEADSET_MODE ), +SND_PCI_QUIRK (0x10f7 ,0x8338 ,"Panasonic CF-SZ6" ,ALC269_FIXUP_ASPIRE_HEADSET_MIC ),SND_PCI_QUIRK (0x144d ,0xc109 ,"Samsung Ativ book 9 (NP900X3G)" ,ALC269_FIXUP_INV_DMIC ),SND_PCI_QUIRK (0x144d ,0xc169 ,"Samsung Notebook 9 Pen (NP930SBE-K01US)" ,ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET ), SND_PCI_QUIRK(0x144d, 0xc176, "Samsung Notebook 9 Pro (NP930MBE-K04US)", ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET),
Greg Kroah-Hartman
maintainerPATCH 170/215 x86/mce: Make sure to grab mce_sysfs_mutex in set_bank()
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Borislav Petkov (AMD) <[email protected]>
commit 3ddf944b32f88741c303f0b21459dbb3872b8bc5 upstream.
Modifying a MCA bank's MCA_CTL bits which control which error types to be reported is done over
/sys/devices/system/machinecheck/
├── machinecheck0 │ ├── bank0 │ ├── bank1 │ ├── bank10 │ ├── bank11
...
sysfs nodes by writing the new bit mask of events to enable.
When the write is accepted, the kernel deletes all current timers and reinits all banks.
Doing that in parallel can lead to initializing a timer which is already armed and in the timer wheel, i.e., in use already:
ODEBUG: init active (active state 0) object: ffff888063a28000 object
type: timer_list hint: mce_timer_fn+0x0/0x240 arch/x86/kernel/cpu/mce/core.c:2642
WARNING: CPU: 0 PID: 8120 at lib/debugobjects.c:514 debug_print_object+0x1a0/0x2a0 lib/debugobjects.c:514
Fix that by grabbing the sysfs mutex as the rest of the MCA sysfs code does.
Reported by: Yue Sun <[email protected]>
Reported by: xingwei lee <[email protected]>
--- arch/x86/kernel/cpu/mce/core.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
arch/x86/kernel/cpu/mce/core.c +3 -1
@@ -2228,12 +2228,14 @@ static ssize_t set_bank(struct device *sreturn -EINVAL ; b = &per_cpu (mce_banks_array, s->id)[bank]; -if (!b->init)return -ENODEV ; b->ctl = new; + +mutex_lock (&mce_sysfs_mutex);mce_restart (); +mutex_unlock (&mce_sysfs_mutex);return size; }
Greg Kroah-Hartman
maintainerPATCH 171/215 s390/entry: align system call table on 8 bytes
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sumanth Korikkar <[email protected]>
commit 378ca2d2ad410a1cd5690d06b46c5e2297f4c8c0 upstream.
Align system call table on 8 bytes. With sys_call_table entry size of 8 bytes that eliminates the possibility of a system call pointer crossing cache line boundary.
--- arch/s390/kernel/entry.S | 1 + 1 file changed, 1 insertion(+)
arch/s390/kernel/entry.S +1 -0
@@ -1542,6 +1542,7 @@ ENDPROC(cleanup_critical) .quad .Lsie_skip - .Lsie_entry #endif .section .rodata, "a" + .balign 8 #define SYSCALL(esame,emu) .quad __s390x_ ## esame .globl sys_call_table sys_call_table:
Greg Kroah-Hartman
maintainerPATCH 172/215 wifi: ath9k: fix LNA selection in ath_ant_try_scan()
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dmitry Antipov <[email protected]>
[ Upstream commit d6b27eb997ef9a2aa51633b3111bc4a04748e6d3 ]
In 'ath_ant_try_scan()', (most likely) the 2nd LNA's signal strength should be used in comparison against RSSI when selecting first LNA as the main one. Compile tested only.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
--- drivers/net/wireless/ath/ath9k/antenna.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/wireless/ath/ath9k/antenna.c +1 -1
@@ -643,7 +643,7 @@ static void ath_ant_try_scan(struct ath_ant_comb *antcomb, conf->main_lna_conf =ATH_ANT_DIV_COMB_LNA1 ; conf->alt_lna_conf =ATH_ANT_DIV_COMB_LNA1_PLUS_LNA2 ; }else if (antcomb->rssi_sub > - antcomb->rssi_lna1) { + antcomb->rssi_lna2) {/* set to A-B */ conf->main_lna_conf =ATH_ANT_DIV_COMB_LNA1 ; conf->alt_lna_conf =ATH_ANT_DIV_COMB_LNA1_MINUS_LNA2 ;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 173/215 batman-adv: Return directly after a failed batadv_dat_select_candidates() in batadv_dat_forward_data()
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Markus Elfring <[email protected]>
[ Upstream commit ffc15626c861f811f9778914be004fcf43810a91 ]
The kfree() function was called in one case by
the batadv_dat_forward_data() function during error handling even if the passed variable contained a null pointer. This issue was detected by using the Coccinelle software.
* Thus return directly after a batadv_dat_select_candidates() call failed at the beginning.
* Delete the label “out” which became unnecessary with this refactoring.
--- net/batman-adv/distributed-arp-table.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
net/batman-adv/distributed-arp-table.c +1 -2
@@ -682,7 +682,7 @@ static bool batadv_dat_forward_data(struct batadv_priv *bat_priv, cand =batadv_dat_select_candidates (bat_priv, ip, vid);if (!cand) - goto out; +return ret;batadv_dbg (BATADV_DBG_DAT , bat_priv,"DHT_SEND for %pI4\n" , &ip);
@@ -726,7 +726,6 @@ static bool batadv_dat_forward_data(struct batadv_priv *bat_priv,batadv_orig_node_put (cand[i].orig_node); } -out:kfree (cand);return ret; }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 174/215 batman-adv: Improve exception handling in batadv_throw_uevent()
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Markus Elfring <[email protected]>
[ Upstream commit 5593e9abf1cf2bf096366d8c7fd933bc69d561ce ]
The kfree() function was called in up to three cases by the batadv_throw_uevent() function during error handling even if the passed variable contained a null pointer. This issue was detected by using the Coccinelle software.
* Thus adjust jump targets.
* Reorder kfree() calls at the end.
--- net/batman-adv/main.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-)
net/batman-adv/main.c +8 -6
@@ -733,29 +733,31 @@ int batadv_throw_uevent(struct batadv_priv *bat_priv, enum batadv_uev_type type,"%s%s" ,BATADV_UEV_TYPE_VAR , batadv_uev_type_str[type]);if (!uevent_env[0 ]) - goto out; + goto report_error; uevent_env[1 ] =kasprintf (GFP_ATOMIC ,"%s%s" ,BATADV_UEV_ACTION_VAR , batadv_uev_action_str[action]);if (!uevent_env[1 ]) - goto out; + goto free_first_env;/* If the event is DEL, ignore the data field */ if (action !=BATADV_UEV_DEL ) { uevent_env[2 ] =kasprintf (GFP_ATOMIC ,"%s%s" ,BATADV_UEV_DATA_VAR , data);if (!uevent_env[2 ]) - goto out; + goto free_second_env; } ret =kobject_uevent_env (bat_kobj,KOBJ_CHANGE , uevent_env); -out: -kfree (uevent_env[0 ]); -kfree (uevent_env[1 ]);kfree (uevent_env[2 ]); +free_second_env: +kfree (uevent_env[1 ]); +free_first_env: +kfree (uevent_env[0 ]);if (ret) +report_error: batadv_dbg(BATADV_DBG_BATMAN, bat_priv, "Impossible to send uevent for (%s,%s,%s) event (err: %d)\n", batadv_uev_type_str[type],
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 175/215 VMCI: Fix memcpy() run-time warning in dg_dispatch_as_host()
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Harshit Mogalapalli <[email protected]>
[ Upstream commit 19b070fefd0d024af3daa7329cbc0d00de5302ec ]
Syzkaller hit 'WARNING in dg_dispatch_as_host' bug.
memcpy: detected field-spanning write (size 56) of single field "&dg_info->msg"
at drivers/misc/vmw_vmci/vmci_datagram.c:237 (size 24) WARNING: CPU: 0 PID: 1555 at drivers/misc/vmw_vmci/vmci_datagram.c:237 dg_dispatch_as_host+0x88e/0xa60 drivers/misc/vmw_vmci/vmci_datagram.c:237
Some code commentry, based on my understanding:
544 #define VMCI_DG_SIZE(_dg) (VMCI_DG_HEADERSIZE + (size_t)(_dg)->payload_size) /// This is 24 + payload_size
memcpy(&dg_info->msg, dg, dg_size); Destination = dg_info->msg ---> this is a 24 byte structure(struct vmci_datagram) Source = dg --> this is a 24 byte structure (struct vmci_datagram) Size = dg_size = 24 + payload_size
{payload_size = 56-24 =32} -- Syzkaller managed to set payload_size to 32.
35 struct delayed_datagram_info {
36 struct datagram_entry *entry; 37 struct work_struct work; 38 bool in_dg_host_queue; 39 /* msg and msg_payload must be together. */ 40 struct vmci_datagram msg; 41 u8 msg_payload[];
42 };
So those extra bytes of payload are copied into msg_payload[], a run time warning is seen while fuzzing with Syzkaller.
One possible way to fix the warning is to split the memcpy() into two parts -- one -- direct assignment of msg and second taking care of payload.
Gustavo quoted:
"Under FORTIFY_SOURCE we should not copy data across multiple members in a structure."
--- drivers/misc/vmw_vmci/vmci_datagram.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/misc/vmw_vmci/vmci_datagram.c +2 -1
@@ -234,7 +234,8 @@ static int dg_dispatch_as_host(u32 context_id, struct vmci_datagram *dg) dg_info->in_dg_host_queue = true; dg_info->entry = dst_entry; -memcpy (&dg_info->msg, dg, dg_size); + dg_info->msg = *dg; +memcpy (&dg_info->msg_payload, dg +1 , dg->payload_size);INIT_WORK (&dg_info->work, dg_delayed_dispatch);schedule_work (&dg_info->work);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 176/215 panic: Flush kernel log buffer at the end
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: John Ogness <[email protected]>
[ Upstream commit d988d9a9b9d180bfd5c1d353b3b176cb90d6861b ]
If the kernel crashes in a context where printk() calls always defer printing (such as in NMI or inside a printk_safe section) then the final panic messages will be deferred to irq_work. But if irq_work is not available, the messages will not get printed unless explicitly flushed. The result is that the final "end Kernel panic" banner does not get printed.
Add one final flush after the last printk() call to make sure the final panic messages make it out as well.
--- kernel/panic.c | 8 ++++++++ 1 file changed, 8 insertions(+)
kernel/panic.c +8 -0
@@ -404,6 +404,14 @@ void panic(const char *fmt, ...)/* Do not scroll important messages printed above */ suppress_printk =1 ; + +/* +* The final messages may not have been printed if in a context that +* defers printing (such as NMI) and irq_work is not available. +* Explicitly flush the kernel log buffer one last time. +*/ +console_flush_on_panic (CONSOLE_FLUSH_PENDING ); +local_irq_enable ();for (i =0 ; ; i +=PANIC_TIMER_STEP ) {touch_softlockup_watchdog ();
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 177/215 arm64: dts: rockchip: fix rk3328 hdmi ports node
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Jonker <[email protected]>
[ Upstream commit 1d00ba4700d1e0f88ae70d028d2e17e39078fa1c ]
Fix rk3328 hdmi ports node so that it matches the
rockchip,dw-hdmi.yaml binding.
--- arch/arm64/boot/dts/rockchip/rk3328.dtsi | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
arch/arm64/boot/dts/rockchip/rk3328.dtsi +10 -1
@@ -684,11 +684,20 @@ hdmi: hdmi@ff3c0000 { status = "disabled"; ports { - hdmi_in: port { + #address-cells = <1>; + #size-cells = <0>; + + hdmi_in: port@0 { + reg = <0>; + hdmi_in_vop: endpoint { remote-endpoint = <&vop_out_hdmi>; }; }; + + hdmi_out: port@1 { + reg = <1>; + }; }; };
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 178/215 arm64: dts: rockchip: fix rk3399 hdmi ports node
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Jonker <[email protected]>
[ Upstream commit f051b6ace7ffcc48d6d1017191f167c0a85799f6 ]
Fix rk3399 hdmi ports node so that it matches the
rockchip,dw-hdmi.yaml binding.
--- arch/arm64/boot/dts/rockchip/rk3399.dtsi | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
arch/arm64/boot/dts/rockchip/rk3399.dtsi +10 -2
@@ -1743,6 +1743,7 @@ simple-audio-card,codec { hdmi: hdmi@ff940000 { compatible = "rockchip,rk3399-dw-hdmi"; reg = <0x0 0xff940000 0x0 0x20000>; + reg-io-width = <4>; interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH 0>; clocks = <&cru PCLK_HDMI_CTRL>, <&cru SCLK_HDMI_SFR>,
@@ -1751,13 +1752,16 @@ hdmi: hdmi@ff940000 { <&cru PLL_VPLL>; clock-names = "iahb", "isfr", "cec", "grf", "vpll"; power-domains = <&power RK3399_PD_HDCP>; - reg-io-width = <4>; rockchip,grf = <&grf>; #sound-dai-cells = <0>; status = "disabled"; ports { - hdmi_in: port { + #address-cells = <1>; + #size-cells = <0>; + + hdmi_in: port@0 { + reg = <0>; #address-cells = <1>; #size-cells = <0>;
@@ -1770,6 +1774,10 @@ hdmi_in_vopl: endpoint@1 { remote-endpoint = <&vopl_out_hdmi>; }; }; + + hdmi_out: port@1 { + reg = <1>; + }; }; };
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 179/215 ionic: set adminq irq affinity
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shannon Nelson <[email protected]>
[ Upstream commit c699f35d658f3c21b69ed24e64b2ea26381e941d ]
We claim to have the AdminQ on our irq0 and thus cpu id 0, but we need to be sure we set the affinity hint to try to keep it there.
--- drivers/net/ethernet/pensando/ionic/ionic_lif.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/net/ethernet/pensando/ionic/ionic_lif.c +4 -1
@@ -1874,9 +1874,12 @@ static int ionic_lif_adminq_init(struct ionic_lif *lif)napi_enable (&qcq->napi); -if (qcq->flags &IONIC_QCQ_F_INTR ) +if (qcq->flags &IONIC_QCQ_F_INTR ) { +irq_set_affinity_hint (qcq->intr.vector, + &qcq->intr.affinity_mask);ionic_intr_mask (idev->intr_ctrl, qcq->intr.index,IONIC_INTR_MASK_CLEAR ); + } qcq->flags |=IONIC_QCQ_F_INITED ;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 180/215 tools/power x86_energy_perf_policy: Fix file leak in get_pkg_num()
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Samasth Norway Ananda <[email protected]>
[ Upstream commit f85450f134f0b4ca7e042dc3dc89155656a2299d ]
In function get_pkg_num() if fopen_or_die() succeeds it returns a file pointer to be used. But fclose() is never called before returning from the function.
--- tools/power/x86/x86_energy_perf_policy/x86_energy_perf_policy.c | 1 + 1 file changed, 1 insertion(+)
tools/power/x86/x86_energy_perf_policy/x86_energy_perf_policy.c +1 -0
@@ -1111,6 +1111,7 @@ unsigned int get_pkg_num(int cpu) retval =fscanf (fp,"%d\n" , &pkg);if (retval !=1 )errx (1 ,"%s: failed to parse" , pathname); +fclose (fp);return pkg; }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 181/215 btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks()
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Sterba <[email protected]>
[ Upstream commit 7411055db5ce64f836aaffd422396af0075fdc99 ]
The unhandled case in btrfs_relocate_sys_chunks() loop is a corruption, as it could be caused only by two impossible conditions:
- at first the search key is set up to look for a chunk tree item, with offset -1, this is an inexact search and the key->offset will contain the correct offset upon a successful search, a valid chunk tree item cannot have an offset -1
- after first successful search, the found_key corresponds to a chunk item, the offset is decremented by 1 before the next loop, it's impossible to find a chunk item there due to alignment and size constraints
--- fs/btrfs/volumes.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)
fs/btrfs/volumes.c +11 -1
@@ -3268,7 +3268,17 @@ static int btrfs_relocate_sys_chunks(struct btrfs_fs_info *fs_info)mutex_unlock (&fs_info->delete_unused_bgs_mutex); goto error; } -BUG_ON (ret ==0 );/* Corruption */ +if (ret ==0 ) { +/* +* On the first search we would find chunk tree with +* offset -1, which is not possible. On subsequent +* loops this would find an existing item on an invalid +* offset (one less than the previous one, wrong +* alignment and size). +*/ + ret = -EUCLEAN ; + goto error; + } ret =btrfs_previous_item (chunk_root, path, key.objectid, key.type);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 182/215 btrfs: export: handle invalid inode or root reference in btrfs_get_parent()
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Sterba <[email protected]>
[ Upstream commit 26b66d1d366a375745755ca7365f67110bbf6bd5 ]
The get_parent handler looks up a parent of a given dentry, this can be either a subvolume or a directory. The search is set up with offset -1 but it's never expected to find such item, as it would break allowed range of inode number or a root id. This means it's a corruption (ext4 also returns this error code).
--- fs/btrfs/export.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
fs/btrfs/export.c +8 -1
@@ -182,8 +182,15 @@ struct dentry *btrfs_get_parent(struct dentry *child) ret =btrfs_search_slot (NULL , root, &key, path,0 ,0 );if (ret <0 ) goto fail; +if (ret ==0 ) { +/* +* Key with offset of -1 found, there would have to exist an +* inode with such number or a root with such id. +*/ + ret = -EUCLEAN ; + goto fail; + } -BUG_ON (ret ==0 );/* Key with offset of -1 found */ if (path->slots[0 ] ==0 ) { ret = -ENOENT ; goto fail;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 183/215 btrfs: send: handle path ref underflow in header iterate_inode_ref()
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Sterba <[email protected]>
[ Upstream commit 3c6ee34c6f9cd12802326da26631232a61743501 ]
Change BUG_ON to proper error handling if building the path buffer fails. The pointers are not printed so we don't accidentally leak kernel addresses.
--- fs/btrfs/send.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
fs/btrfs/send.c +9 -1
@@ -973,7 +973,15 @@ static int iterate_inode_ref(struct btrfs_root *root, struct btrfs_path *path, ret =PTR_ERR (start); goto out; } -BUG_ON (start < p->buf); +if (unlikely (start < p->buf)) { +btrfs_err (root->fs_info, +"send: path ref buffer underflow for key (%llu %u %llu)" , + found_key->objectid, + found_key->type, + found_key->offset); + ret = -EINVAL ; + goto out; + } } p->start = start; }else {
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 184/215 Bluetooth: btintel: Fix null ptr deref in btintel_read_version
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Edward Adam Davis <[email protected]>
[ Upstream commit b79e040910101b020931ba0c9a6b77e81ab7f645 ]
If hci_cmd_sync_complete() is triggered and skb is NULL, then hdev->req_skb is NULL, which will cause this issue.
--- drivers/bluetooth/btintel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/bluetooth/btintel.c +1 -1
@@ -340,7 +340,7 @@ int btintel_read_version(struct hci_dev *hdev, struct intel_version *ver)struct sk_buff *skb; skb =__hci_cmd_sync (hdev,0xfc05 ,0 ,NULL ,HCI_CMD_TIMEOUT ); -if (IS_ERR (skb)) { +if (IS_ERR_OR_NULL (skb)) {bt_dev_err (hdev,"Reading Intel version information failed (%ld)" ,PTR_ERR (skb));return PTR_ERR (skb);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 185/215 Input: synaptics-rmi4 - fail probing if memory allocation for "phys" fails
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kunwu Chan <[email protected]>
[ Upstream commit bc4996184d56cfaf56d3811ac2680c8a0e2af56e ]
While input core can work with input->phys set to NULL userspace might depend on it, so better fail probing if allocation fails. The system must be in a pretty bad shape for it to happen anyway.
--- drivers/input/rmi4/rmi_driver.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/input/rmi4/rmi_driver.c +5 -1
@@ -1196,7 +1196,11 @@ static int rmi_driver_probe(struct device *dev) }rmi_driver_set_input_params (rmi_dev, data->input); data->input->phys =devm_kasprintf (dev,GFP_KERNEL , -"%s/input0" ,dev_name (dev)); +"%s/input0" ,dev_name (dev)); +if (!data->input->phys) { + retval = -ENOMEM ; + goto err; + } } retval =rmi_init_functions (data);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 186/215 sysv: dont call sb_bread() with pointers_lock held
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tetsuo Handa <[email protected]>
[ Upstream commit f123dc86388cb669c3d6322702dc441abc35c31e ]
syzbot is reporting sleep in atomic context in SysV filesystem [1], for sb_bread() is called with rw_spinlock held.
A "write_lock(&pointers_lock) => read_lock(&pointers_lock) deadlock" bug and a "sb_bread() with write_lock(&pointers_lock)" bug were introduced by "Replace BKL for chain locking with sysvfs-private rwlock" in Linux 2.5.12.
Then, "[PATCH] err1-40: sysvfs locking fix" in Linux 2.6.8 fixed the former bug by moving pointers_lock lock to the callers, but instead introduced a "sb_bread() with read_lock(&pointers_lock)" bug (which made this problem easier to hit).
Al Viro suggested that why not to do like get_branch()/get_block()/ find_shared() in Minix filesystem does. And doing like that is almost a revert of "[PATCH] err1-40: sysvfs locking fix" except that get_branch()
from with find_shared() is called without write_lock(&pointers_lock).
--- fs/sysv/itree.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-)
fs/sysv/itree.c +4 -6
@@ -82,9 +82,6 @@ static inline sysv_zone_t *block_end(struct buffer_head *bh)return (sysv_zone_t *)((char *)bh->b_data + bh->b_size); } -/* -* Requires read_lock(&pointers_lock) or write_lock(&pointers_lock) -*/ static Indirect *get_branch(struct inode *inode, int depth, int offsets[],
@@ -104,15 +101,18 @@ static Indirect *get_branch(struct inode *inode, bh =sb_bread (sb, block);if (!bh) goto failure; +read_lock (&pointers_lock);if (!verify_chain (chain, p)) goto changed;add_chain (++p, bh, (sysv_zone_t *)bh->b_data + *++offsets); +read_unlock (&pointers_lock);if (!p->key) goto no_block; }return NULL ; changed: +read_unlock (&pointers_lock);brelse (bh); *err = -EAGAIN ; goto no_block;
@@ -218,9 +218,7 @@ static int get_block(struct inode *inode, sector_t iblock, struct buffer_head *b goto out; reread: -read_lock (&pointers_lock); partial =get_branch (inode, depth, offsets, chain, &err); -read_unlock (&pointers_lock);/* Simplest case - block found, no allocation needed */ if (!partial) {
@@ -290,9 +288,9 @@ static Indirect *find_shared(struct inode *inode, *top =0 ;for (k = depth; k >1 && !offsets[k-1 ]; k--) ; + partial =get_branch (inode, k, offsets, chain, &err);write_lock (&pointers_lock); - partial =get_branch (inode, k, offsets, chain, &err);if (!partial) partial = chain + k-1 ;/*
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 187/215 scsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc()
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Justin Tee <[email protected]>
[ Upstream commit 2ae917d4bcab80ab304b774d492e2fcd6c52c06b ]
The call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return an unsuccessful status. In such cases, the elsiocb is not issued, the completion is not called, and thus the elsiocb resource is leaked.
Check return value after calling lpfc_sli4_resume_rpi() and conditionally release the elsiocb resource.
--- drivers/scsi/lpfc/lpfc_nportdisc.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/scsi/lpfc/lpfc_nportdisc.c +4 -2
@@ -781,8 +781,10 @@ lpfc_rcv_padisc(struct lpfc_vport *vport, struct lpfc_nodelist *ndlp,/* Save the ELS cmd */ elsiocb->drvrTimeout = cmd; -lpfc_sli4_resume_rpi (ndlp, - lpfc_mbx_cmpl_resume_rpi, elsiocb); +if (lpfc_sli4_resume_rpi (ndlp, + lpfc_mbx_cmpl_resume_rpi, + elsiocb)) +kfree (elsiocb); goto out; } }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 188/215 isofs: handle CDs with bad root inode but good Joliet root directory
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Henrie <[email protected]>
[ Upstream commit 4243bf80c79211a8ca2795401add9c4a3b1d37ca ]
I have a CD copy of the original Tom Clancy's Ghost Recon game from 2001. The disc mounts without error on Windows, but on Linux mounting fails with the message "isofs_fill_super: get root inode failed". The error originates in isofs_read_inode, which returns -EIO because de_len is 0. The superblock on this disc appears to be intentionally corrupt as a form of copy protection.
When the root inode is unusable, instead of giving up immediately, try to continue with the Joliet file table. This fixes the Ghost Recon CD and probably other copy-protected CDs too.
Message-Id: <[email protected]>
--- fs/isofs/inode.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-)
fs/isofs/inode.c +16 -2
@@ -912,8 +912,22 @@ static int isofs_fill_super(struct super_block *s, void *data, int silent)* we then decide whether to use the Joliet descriptor. */ inode =isofs_iget (s, sbi->s_firstdatazone,0 ); -if (IS_ERR (inode)) - goto out_no_root; + +/* +* Fix for broken CDs with a corrupt root inode but a correct Joliet +* root directory. +*/ +if (IS_ERR (inode)) { +if (joliet_level && sbi->s_firstdatazone != first_data_zone) { +printk (KERN_NOTICE +"ISOFS: root inode is unusable. " +"Disabling Rock Ridge and switching to Joliet." ); + sbi->s_rock =0 ; + inode =NULL ; + }else { + goto out_no_root; + } + }/* * Fix for broken CDs with Rock Ridge and empty ISO root directory but
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 189/215 media: sta2x11: fix irq handler cast
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <[email protected]>
[ Upstream commit 3de49ae81c3a0f83a554ecbce4c08e019f30168e ]
clang-16 warns about casting incompatible function pointers:
drivers/media/pci/sta2x11/sta2x11_vip.c:1057:6: error: cast from 'irqreturn_t (*)(int, struct sta2x11_vip *)' (aka 'enum irqreturn (*)(int, struct sta2x11_vip *)') to 'irq_handler_t' (aka 'enum irqreturn (*)(int, void *)') converts to incompatible function type [-Werror,-Wcast-function-type-strict]
Change the prototype of the irq handler to the regular version with a local variable to adjust the argument type.
--- drivers/media/pci/sta2x11/sta2x11_vip.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-)
drivers/media/pci/sta2x11/sta2x11_vip.c +4 -5
@@ -760,7 +760,7 @@ static const struct video_device video_dev_template = {/** * vip_irq - interrupt routine * @irq: Number of interrupt ( not used, correct number is assumed ) -* @vip: local data structure containing all information +* @data: local data structure containing all information * * check for both frame interrupts set ( top and bottom ). * check FIFO overflow, but limit number of log messages after open.
@@ -770,8 +770,9 @@ static const struct video_device video_dev_template = {* * IRQ_HANDLED, interrupt done. */ -static irqreturn_t vip_irq (int irq,struct sta2x11_vip *vip) +static irqreturn_t vip_irq (int irq,void *data) { +struct sta2x11_vip *vip = data;unsigned int status; status =reg_read (vip,DVP_ITS );
@@ -1053,9 +1054,7 @@ static int sta2x11_vip_init_one(struct pci_dev *pdev,spin_lock_init (&vip->slock); - ret =request_irq (pdev->irq, - (irq_handler_t ) vip_irq, -IRQF_SHARED ,KBUILD_MODNAME , vip); + ret =request_irq (pdev->irq, vip_irq,IRQF_SHARED ,KBUILD_MODNAME , vip);if (ret) {dev_err (&pdev->dev,"request_irq failed\n" ); ret = -ENODEV ;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 190/215 drm/amd/display: Fix nanosec stat overflow
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Aric Cyr <[email protected]>
[ Upstream commit 14d68acfd04b39f34eea7bea65dda652e6db5bf6 ]
[Why]
Nanosec stats can overflow on long running systems potentially causing statistic logging issues.
[How]
Use 64bit types for nanosec stats to ensure no overflow.
--- drivers/gpu/drm/amd/display/modules/inc/mod_stats.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/display/modules/inc/mod_stats.h +2 -2
@@ -51,10 +51,10 @@ void mod_stats_update_event(struct mod_stats *mod_stats, unsigned int length);void mod_stats_update_flip (struct mod_stats *mod_stats, -unsigned long timestamp_in_ns); +unsigned long long timestamp_in_ns);void mod_stats_update_vupdate (struct mod_stats *mod_stats, -unsigned long timestamp_in_ns); +unsigned long long timestamp_in_ns); void mod_stats_update_freesync(struct mod_stats *mod_stats, unsigned int v_total_min,
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 191/215 SUNRPC: increase size of rpc_wait_queue.qlen from unsigned short to unsigned int
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dai Ngo <[email protected]>
[ Upstream commit 2c35f43b5a4b9cdfaa6fdd946f5a212615dac8eb ]
When the NFS client is under extreme load the rpc_wait_queue.qlen counter can be overflowed. Here is an instant of the backlog queue overflow in a real world environment shown by drgn helper:
rpc_task_stats(rpc_clnt):
-------------------------rpc_clnt: 0xffff92b65d2bae00rpc_xprt: 0xffff9275db64f000
Queue: sending[64887] pending[524] backlog[30441] binding[0]
XMIT task: 0xffff925c6b1d8e98
WRITE: 750654
__dta_call_status_580: 65463
__dta_call_transmit_status_579: 1
call_reserveresult: 685189
nfs_client_init_is_complete: 1
COMMIT: 584
call_reserveresult: 573
__dta_call_status_580: 11
ACCESS: 1
__dta_call_status_580: 1
GETATTR: 10
__dta_call_status_580: 4
call_reserveresult: 6751249 tasks for server 111.222.333.444
Total tasks: 751249
count_rpc_wait_queues(xprt):
----------------------------
**** rpc_xprt: 0xffff9275db64f000 num_reqs: 65511wait_queue: xprt_binding[0] cnt: 0wait_queue: xprt_binding[1] cnt: 0wait_queue: xprt_binding[2] cnt: 0wait_queue: xprt_binding[3] cnt: 0 rpc_wait_queue[xprt_binding].qlen: 0 maxpriority: 0wait_queue: xprt_sending[0] cnt: 0wait_queue: xprt_sending[1] cnt: 64887wait_queue: xprt_sending[2] cnt: 0wait_queue: xprt_sending[3] cnt: 0 rpc_wait_queue[xprt_sending].qlen: 64887 maxpriority: 3wait_queue: xprt_pending[0] cnt: 524wait_queue: xprt_pending[1] cnt: 0wait_queue: xprt_pending[2] cnt: 0wait_queue: xprt_pending[3] cnt: 0 rpc_wait_queue[xprt_pending].qlen: 524 maxpriority: 0wait_queue: xprt_backlog[0] cnt: 0wait_queue: xprt_backlog[1] cnt: 685801wait_queue: xprt_backlog[2] cnt: 0wait_queue: xprt_backlog[3] cnt: 0 rpc_wait_queue[xprt_backlog].qlen: 30441 maxpriority: 3 [task cnt mismatch]
There is no effect on operations when this overflow occurs. However it causes confusion when trying to diagnose the performance problem.
--- include/linux/sunrpc/sched.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/linux/sunrpc/sched.h +1 -1
@@ -196,7 +196,7 @@ struct rpc_wait_queue {unsigned char maxpriority;/* maximum priority (0 if queue is not a priority queue) */ unsigned char priority;/* current priority */ unsigned char nr;/* # tasks remaining for cookie */ -unsigned short qlen;/* total # tasks waiting in queue */ +unsigned int qlen;/* total # tasks waiting in queue */ struct rpc_timer timer_list;#if IS_ENABLED (CONFIG_SUNRPC_DEBUG ) ||IS_ENABLED (CONFIG_TRACEPOINTS )const char * name;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 192/215 Revert "ACPI: PM: Block ASUS B1400CEAE from suspend to idle by default"
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Drake <[email protected]>
[ Upstream commit cb98555fcd8eee98c30165537c7e394f3a66e809 ]
This reverts commit d52848620de00cde4a3a5df908e231b8c8868250, which was originally put in place to work around a s2idle failure on this platform where the NVMe device was inaccessible upon resume.
After extended testing, we found that the firmware's implementation of S3 is buggy and intermittently fails to wake up the system. We need to revert to s2idle mode.
The NVMe issue has now been solved more precisely in the commit titled "PCI: Disable D3cold on Asus B1400 PCI-NVMe bridge"
--- drivers/acpi/sleep.c | 12 ------------ 1 file changed, 12 deletions(-)
drivers/acpi/sleep.c +0 -12
@@ -382,18 +382,6 @@ static const struct dmi_system_id acpisleep_dmi_table[] __initconst = { DMI_MATCH(DMI_PRODUCT_NAME, "20GGA00L00"), }, }, -/* -* ASUS B1400CEAE hangs on resume from suspend (see -* https://bugzilla.kernel.org/show_bug.cgi?id=215742). -*/ - { - .callback = init_default_s3, - .ident = "ASUS B1400CEAE", - .matches = { - DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), - DMI_MATCH(DMI_PRODUCT_NAME, "ASUS EXPERTBOOK B1400CEAE"), - }, - }, {}, };
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 193/215 block: prevent division by zero in blk_rq_stat_sum()
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Roman Smirnov <[email protected]>
[ Upstream commit 93f52fbeaf4b676b21acfe42a5152620e6770d02 ]
The expression dst->nr_samples + src->nr_samples may have zero value on overflow. It is necessary to add a check to avoid division by zero.
Found by Linux Verification Center (linuxtesting.org) with Svace.
--- block/blk-stat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
block/blk-stat.c +1 -1
@@ -28,7 +28,7 @@ void blk_rq_stat_init(struct blk_rq_stat *stat)/* src is a per-cpu stat, mean isn't initialized */ void blk_rq_stat_sum (struct blk_rq_stat *dst,struct blk_rq_stat *src) { -if (!src->nr_samples) +if (dst->nr_samples + src->nr_samples <= dst->nr_samples)return ; dst->min =min (dst->min, src->min);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 194/215 Input: allocate keycode for Display refresh rate toggle
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gergo Koteles <[email protected]>
[ Upstream commit cfeb98b95fff25c442f78a6f616c627bc48a26b7 ]
Newer Lenovo Yogas and Legions with 60Hz/90Hz displays send a wmi event when Fn + R is pressed. This is intended for use to switch between the two refresh rates.
Allocate a new KEY_REFRESH_RATE_TOGGLE keycode for it.
--- include/uapi/linux/input-event-codes.h | 1 + 1 file changed, 1 insertion(+)
include/uapi/linux/input-event-codes.h +1 -0
@@ -598,6 +598,7 @@#define KEY_ALS_TOGGLE 0x230/* Ambient light sensor */ #define KEY_ROTATE_LOCK_TOGGLE 0x231/* Display rotation lock */ +#define KEY_REFRESH_RATE_TOGGLE 0x232/* Display refresh rate toggle */ #define KEY_BUTTONCONFIG 0x240/* AL Button Configuration */ #define KEY_TASKMANAGER 0x241/* AL Task/Project Manager */
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 195/215 ktest: force $buildonly = 1 for make_warnings_file test type
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ricardo B. Marliere <[email protected]>
[ Upstream commit 07283c1873a4d0eaa0e822536881bfdaea853910 ]
The test type "make_warnings_file" should have no mandatory configuration parameters other than the ones required by the "build" test type, because its purpose is to create a file with build warnings that may or may not be used by other subsequent tests. Currently, the only way to use it as a stand-alone test is by setting POWER_CYCLE, CONSOLE, SSH_USER, BUILD_TARGET, TARGET_IMAGE, REBOOT_TYPE and GRUB_MENU.
--- tools/testing/ktest/ktest.pl | 1 + 1 file changed, 1 insertion(+)
tools/testing/ktest/ktest.pl +1 -0
@@ -768,6 +768,7 @@ sub set_value { if ($lvalue =~ /^(TEST|BISECT|CONFIG_BISECT)_TYPE(\[.*\])?$/ && $prvalue !~ /^(config_|)bisect$/ && $prvalue !~ /^build$/ && + $prvalue !~ /^make_warnings_file$/ && $buildonly) { # Note if a test is something other than build, then we
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 196/215 tools: iio: replace seekdir() in iio_generic_buffer
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Petre Rodan <[email protected]>
[ Upstream commit 4e6500bfa053dc133021f9c144261b77b0ba7dc8 ]
Replace seekdir() with rewinddir() in order to fix a localized glibc bug.
One of the glibc patches that stable Gentoo is using causes an improper directory stream positioning bug on 32bit arm. That in turn ends up as a floating point exception in iio_generic_buffer.
The attached patch provides a fix by using an equivalent function which should not cause trouble for other distros and is easier to reason about in general as it obviously always goes back to to the start.
https://sourceware.org/bugzilla/show_bug.cgi?id=31212
--- tools/iio/iio_utils.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/iio/iio_utils.c +1 -1
@@ -373,7 +373,7 @@ int build_channel_array(const char *device_dir, goto error_close_dir; } -seekdir (dp,0 ); +rewinddir (dp);while (ent =readdir (dp), ent) {if (strcmp (ent->d_name +strlen (ent->d_name) -strlen ("_en" ),"_en" ) ==0 ) {
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 197/215 usb: typec: tcpci: add generic tcpci fallback compatible
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marco Felsch <[email protected]>
[ Upstream commit 8774ea7a553e2aec323170d49365b59af0a2b7e0 ]
The driver already support the tcpci binding for the i2c_device_id so add the support for the of_device_id too.
--- drivers/usb/typec/tcpm/tcpci.c | 1 + 1 file changed, 1 insertion(+)
drivers/usb/typec/tcpm/tcpci.c +1 -0
@@ -634,6 +634,7 @@ MODULE_DEVICE_TABLE(i2c, tcpci_id);#ifdef CONFIG_OF static const struct of_device_id tcpci_of_match[] = { { .compatible ="nxp,ptn5110" , }, + { .compatible ="tcpci" , }, {}, };MODULE_DEVICE_TABLE (of, tcpci_of_match);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 198/215 usb: sl811-hcd: only defined function checkdone if QUIRK2 is defined
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Colin Ian King <[email protected]>
[ Upstream commit 12f371e2b6cb4b79c788f1f073992e115f4ca918 ]
Function checkdone is only required if QUIRK2 is defined, so add appropriate #if / #endif around the function.
Cleans up clang scan build warning:drivers/usb/host/sl811-hcd.c:588:18: warning: unused function 'checkdone' [-Wunused-function]
--- drivers/usb/host/sl811-hcd.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/usb/host/sl811-hcd.c +2 -0
@@ -585,6 +585,7 @@ done(struct sl811 *sl811, struct sl811h_ep *ep, u8 bank)finish_request (sl811, ep, urb, urbstat); } +#ifdef QUIRK2 static inline u8 checkdone (struct sl811 *sl811) {u8 ctl;
@@ -616,6 +617,7 @@ static inline u8 checkdone(struct sl811 *sl811)#endif return irqstat; } +#endif static irqreturn_t sl811h_irq (struct usb_hcd *hcd) {
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 199/215 fbdev: viafb: fix typo in hw_bitblt_1 and hw_bitblt_2
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Aleksandr Burakov <[email protected]>
[ Upstream commit bc87bb342f106a0402186bcb588fcbe945dced4b ]
There are some actions with value 'tmp' but 'dst_addr' is checked instead. It is obvious that a copy-paste error was made here and the value of variable 'tmp' should be checked here.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
--- drivers/video/fbdev/via/accel.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/video/fbdev/via/accel.c +2 -2
@@ -115,7 +115,7 @@ static int hw_bitblt_1(void __iomem *engine, u8 op, u32 width, u32 height,if (op !=VIA_BITBLT_FILL ) { tmp = src_mem ?0 : src_addr; -if (dst_addr &0xE0000007 ) { +if (tmp &0xE0000007 ) {printk (KERN_WARNING "hw_bitblt_1: Unsupported source " "address %X\n" , tmp);return -EINVAL ;
@@ -260,7 +260,7 @@ static int hw_bitblt_2(void __iomem *engine, u8 op, u32 width, u32 height,writel (tmp, engine +0x18 ); tmp = src_mem ?0 : src_addr; -if (dst_addr &0xE0000007 ) { +if (tmp &0xE0000007 ) {printk (KERN_WARNING "hw_bitblt_2: Unsupported source " "address %X\n" , tmp);return -EINVAL ;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 200/215 fbmon: prevent division by zero in fb_videomode_from_videomode()
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Roman Smirnov <[email protected]>
[ Upstream commit c2d953276b8b27459baed1277a4fdd5dd9bd4126 ]
The expression htotal * vtotal can have a zero value on overflow. It is necessary to prevent division by zero like in fb_var_to_videomode().
Found by Linux Verification Center (linuxtesting.org) with Svace.
--- drivers/video/fbdev/core/fbmon.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/video/fbdev/core/fbmon.c +4 -3
@@ -1311,7 +1311,7 @@ int fb_get_mode(int flags, u32 val, struct fb_var_screeninfo *var, struct fb_infint fb_videomode_from_videomode (const struct videomode *vm,struct fb_videomode *fbmode) { -unsigned int htotal, vtotal; +unsigned int htotal, vtotal, total; fbmode->xres = vm->hactive; fbmode->left_margin = vm->hback_porch;
@@ -1344,8 +1344,9 @@ int fb_videomode_from_videomode(const struct videomode *vm, vtotal = vm->vactive + vm->vfront_porch + vm->vback_porch + vm->vsync_len;/* prevent division by zero */ -if (htotal && vtotal) { - fbmode->refresh = vm->pixelclock / (htotal * vtotal); + total = htotal * vtotal; +if (total) { + fbmode->refresh = vm->pixelclock / total;/* a mode must have htotal and vtotal != 0 or it is invalid */ }else { fbmode->refresh =0 ;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 201/215 netfilter: nf_tables: reject new basechain after table flag update
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pablo Neira Ayuso <[email protected]>
commit 994209ddf4f430946f6247616b2e33d179243769 upstream.
When dormant flag is toggled, hooks are disabled in the commit phase by iterating over current chains in table (existing and new).
The following configuration allows for an inconsistent state:
add table x
add chain x y { type filter hook input priority 0; } add table x { flags dormant; }
add chain x w { type filter hook input priority 1; }
which triggers the following warning when trying to unregister chain w which is already unregistered.
[ 127.322252] WARNING: CPU: 7 PID: 1211 at net/netfilter/core.c:50 1 __nf_unregister_net_hook+0x21a/0x260 [...] [ 127.322519] Call Trace: [ 127.322521] <TASK> [ 127.322524] ? __warn+0x9f/0x1a0 [ 127.322531] ? __nf_unregister_net_hook+0x21a/0x260 [ 127.322537] ? report_bug+0x1b1/0x1e0 [ 127.322545] ? handle_bug+0x3c/0x70 [ 127.322552] ? exc_invalid_op+0x17/0x40 [ 127.322556] ? asm_exc_invalid_op+0x1a/0x20 [ 127.322563] ? kasan_save_free_info+0x3b/0x60 [ 127.322570] ? __nf_unregister_net_hook+0x6a/0x260 [ 127.322577] ? __nf_unregister_net_hook+0x21a/0x260 [ 127.322583] ? __nf_unregister_net_hook+0x6a/0x260 [ 127.322590] ? __nf_tables_unregister_hook+0x8a/0xe0 [nf_tables] [ 127.322655] nft_table_disable+0x75/0xf0 [nf_tables] [ 127.322717] nf_tables_commit+0x2571/0x2620 [nf_tables]
--- net/netfilter/nf_tables_api.c | 3 +++ 1 file changed, 3 insertions(+)
net/netfilter/nf_tables_api.c +3 -0
@@ -1805,6 +1805,9 @@ static int nf_tables_addchain(struct nft_ctx *ctx, u8 family, u8 genmask,struct nft_chain_hook hook;struct nf_hook_ops *ops; +if (table->flags & __NFT_TABLE_F_UPDATE) +return -EINVAL ; + err =nft_chain_parse_hook (net, nla, &hook, family, true);if (err <0 )return err;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 202/215 netfilter: nf_tables: release batch on table validation from abort path
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pablo Neira Ayuso <[email protected]>
commit a45e6889575c2067d3c0212b6bc1022891e65b91 upstream.
Unlike early commit path stage which triggers a call to abort, an explicit release of the batch is required on abort, otherwise mutex is released and commit_list remains in place.
Add WARN_ON_ONCE to ensure commit_list is empty from the abort path before releasing the mutex.
After this patch, commit_list is always assumed to be empty before grabbing the mutex, therefore
03c1f1ef1584 ("netfilter: Cleanup nft_net->module_list from nf_tables_exit_net()")
only needs to release the pending modules for registration.
--- net/netfilter/nf_tables_api.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-)
net/netfilter/nf_tables_api.c +10 -4
@@ -7564,10 +7564,11 @@ static int __nf_tables_abort(struct net *net, enum nfnl_abort_action action)struct nftables_pernet *nft_net =net_generic (net, nf_tables_net_id);struct nft_trans *trans, *next;struct nft_trans_elem *te; +int err =0 ;if (action ==NFNL_ABORT_VALIDATE &&nf_tables_validate (net) <0 ) -return -EAGAIN ; + err = -EAGAIN ;list_for_each_entry_safe_reverse (trans, next, &nft_net->commit_list, list) {
@@ -7700,7 +7701,7 @@ static int __nf_tables_abort(struct net *net, enum nfnl_abort_action action)else nf_tables_module_autoload_cleanup (net); -return 0 ; +return err; } static int nf_tables_abort(struct net *net, struct sk_buff *skb,
@@ -7714,6 +7715,8 @@ static int nf_tables_abort(struct net *net, struct sk_buff *skb, ret =__nf_tables_abort (net, action);nft_gc_seq_end (nft_net, gc_seq); +WARN_ON_ONCE (!list_empty (&nft_net->commit_list)); +mutex_unlock (&nft_net->commit_mutex);return ret;
@@ -8400,8 +8403,11 @@ static void __net_exit nf_tables_exit_net(struct net *net) gc_seq =nft_gc_seq_begin (nft_net); -if (!list_empty (&nft_net->commit_list)) -__nf_tables_abort (net,NFNL_ABORT_NONE ); +WARN_ON_ONCE (!list_empty (&nft_net->commit_list)); + +if (!list_empty (&nft_net->module_list)) +nf_tables_module_autoload_cleanup (net); +__nft_release_tables (net);nft_gc_seq_end (nft_net, gc_seq);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 203/215 netfilter: nf_tables: release mutex after nft_gc_seq_end from abort path
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pablo Neira Ayuso <[email protected]>
commit 0d459e2ffb541841714839e8228b845458ed3b27 upstream.
The commit mutex should not be released during the critical section between nft_gc_seq_begin() and nft_gc_seq_end(), otherwise, async GC worker could collect expired objects and get the released commit lock within the same GC sequence.
nf_tables_module_autoload() temporarily releases the mutex to load module dependencies, then it goes back to replay the transaction again. Move it at the end of the abort phase after nft_gc_seq_end() is called.
--- net/netfilter/nf_tables_api.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-)
net/netfilter/nf_tables_api.c +8 -5
@@ -7696,11 +7696,6 @@ static int __nf_tables_abort(struct net *net, enum nfnl_abort_action action)nf_tables_abort_release (trans); } -if (action ==NFNL_ABORT_AUTOLOAD ) -nf_tables_module_autoload (net); -else -nf_tables_module_autoload_cleanup (net); -return err; }
@@ -7717,6 +7712,14 @@ static int nf_tables_abort(struct net *net, struct sk_buff *skb,WARN_ON_ONCE (!list_empty (&nft_net->commit_list)); +/* module autoload needs to happen after GC sequence update because it +* temporarily releases and grabs mutex again. +*/ +if (action ==NFNL_ABORT_AUTOLOAD ) +nf_tables_module_autoload (net); +else +nf_tables_module_autoload_cleanup (net); +mutex_unlock (&nft_net->commit_mutex);return ret;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 204/215 netfilter: nf_tables: discard table flag update with pending basechain deletion
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pablo Neira Ayuso <[email protected]>
commit 1bc83a019bbe268be3526406245ec28c2458a518 upstream.
Hook unregistration is deferred to the commit phase, same occurs with hook updates triggered by the table dormant flag. When both commands are combined, this results in deleting a basechain while leaving its hook still registered in the core.
--- net/netfilter/nf_tables_api.c | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-)
net/netfilter/nf_tables_api.c +19 -1
@@ -903,6 +903,24 @@ static void nf_tables_table_disable(struct net *net, struct nft_table *table)#define __NFT_TABLE_F_UPDATE (__NFT_TABLE_F_WAS_DORMANT | \ __NFT_TABLE_F_WAS_AWAKEN) +static bool nft_table_pending_update (const struct nft_ctx *ctx) +{ +struct nftables_pernet *nft_net =net_generic (ctx->net, nf_tables_net_id); +struct nft_trans *trans; + +if (ctx->table->flags & __NFT_TABLE_F_UPDATE) +return true; + +list_for_each_entry (trans, &nft_net->commit_list, list) { +if (trans->ctx.table == ctx->table && + trans->msg_type ==NFT_MSG_DELCHAIN && +nft_is_base_chain (trans->ctx.chain)) +return true; + } + +return false; +} +static int nf_tables_updtable (struct nft_ctx *ctx) {struct nft_trans *trans;
@@ -920,7 +938,7 @@ static int nf_tables_updtable(struct nft_ctx *ctx)return 0 ;/* No dormant off/on/off/on games in single transaction */ -if (ctx->table->flags & __NFT_TABLE_F_UPDATE) +if (nft_table_pending_update (ctx))return -EINVAL ; trans = nft_trans_alloc(ctx, NFT_MSG_NEWTABLE,
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 205/215 tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thadeu Lima de Souza Cascardo <[email protected]>
commit 67c37756898a5a6b2941a13ae7260c89b54e0d88 upstream.
Any unprivileged user can attach N_GSM0710 ldisc, but it requires CAP_NET_ADMIN to create a GSM network anyway.
Require initial namespace CAP_NET_ADMIN to do that.
From: Salvatore Bonaccorso <[email protected]>
--- drivers/tty/n_gsm.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/tty/n_gsm.c +3 -0
@@ -2567,6 +2567,9 @@ static int gsmld_open(struct tty_structstruct gsm_mux *gsm;int ret; +if (!capable (CAP_NET_ADMIN )) +return -EPERM ; +if (tty->ops->write ==NULL )return -EINVAL ;
Greg Kroah-Hartman
maintainerPATCH 206/215 drm/vkms: call drm_atomic_helper_shutdown before drm_dev_put()
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guo Mengqi <[email protected]>
commit 73a82b22963d ("drm/atomic: Fix potential use-after-free in nonblocking commits") introduced drm_dev_get/put() to drm_atomic_helper_shutdown(). And this cause problem in vkms driver exit process.
vkms_exit()
drm_dev_put()
vkms_release()
drm_atomic_helper_shutdown()
drm_dev_get()
drm_dev_put()
vkms_release() ------ use after freeUsing 5.4 stable x86 image on qemu, below stacktrace can be triggered by load and unload vkms.ko.
root:~ # insmod vkms.ko
[ 76.957802] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 76.961490] [drm] Driver supports precise vblank timestamp query. [ 76.964416] [drm] Initialized vkms 1.0.0 20180514 for vkms on minor 0 root:~ # rmmod vkms.ko [ 79.650202] refcount_t: addition on 0; use-after-free. [ 79.650249] WARNING: CPU: 2 PID: 3533 at ../lib/refcount.c:25 refcount_warn_saturate+0xcf/0xf0 [ 79.654241] Modules linked in: vkms(-) [ 79.654249] CPU: 2 PID: 3533 Comm: rmmod Not tainted 5.4.273 #4 [ 79.654251] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 79.654262] RIP: 0010:refcount_warn_saturate+0xcf/0xf0 ... [ 79.654296] Call Trace: [ 79.654462] ? __warn+0x80/0xd0 [ 79.654473] ? refcount_warn_saturate+0xcf/0xf0 [ 79.654481] ? report_bug+0xb6/0x130 [ 79.654484] ? refcount_warn_saturate+0xcf/0xf0 [ 79.654489] ? fixup_bug.part.12+0x13/0x30 [ 79.654492] ? do_error_trap+0x90/0xb0 [ 79.654495] ? do_invalid_op+0x31/0x40 [ 79.654497] ? refcount_warn_saturate+0xcf/0xf0 [ 79.654504] ? invalid_op+0x1e/0x30 [ 79.654508] ? refcount_warn_saturate+0xcf/0xf0 [ 79.654516] drm_atomic_state_init+0x68/0xb0 [ 79.654543] drm_atomic_state_alloc+0x43/0x60 [ 79.654551] drm_atomic_helper_disable_all+0x13/0x180 [ 79.654562] drm_atomic_helper_shutdown+0x5f/0xb0 [ 79.654571] vkms_release+0x18/0x40 [vkms] [ 79.654575] vkms_exit+0x29/0xc00 [vkms] [ 79.654582] __x64_sys_delete_module+0x155/0x220 [ 79.654592] do_syscall_64+0x43/0x120 [ 79.654603] entry_SYSCALL_64_after_hwframe+0x5c/0xc1 [ 79.654619] ---[ end trace ce0c02f57ea6bf73 ]---
It seems that the proper unload sequence is:
drm_atomic_helper_shutdown(); drm_dev_put();
Just put drm_atomic_helper_shutdown() before drm_dev_put() should solve the problem.
Note that vkms exit code is refactored by commit 53d77aaa3f76 ("drm/vkms: Use devm_drm_dev_alloc") in tags/v5.10-rc1.
So this bug only exists on 4.19 and 5.4.
--- drivers/gpu/drm/vkms/vkms_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/vkms/vkms_drv.c +1 -1
@@ -60,7 +60,6 @@ static void vkms_release(struct drm_devi struct vkms_device *vkms = container_of(dev, struct vkms_device, drm);platform_device_unregister (vkms->platform); -drm_atomic_helper_shutdown (&vkms->drm);drm_mode_config_cleanup (&vkms->drm);drm_dev_fini (&vkms->drm);destroy_workqueue (vkms->output.composer_workq);
@@ -194,6 +193,7 @@ static void __exit vkms_exit(void) }drm_dev_unregister (&vkms_device->drm); +drm_atomic_helper_shutdown (&vkms_device->drm);drm_dev_put (&vkms_device->drm);kfree (vkms_device);
Greg Kroah-Hartman
maintainerPATCH 207/215 virtio: reenable config if freezing device failed
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Hildenbrand <[email protected]>
commit 310227f42882c52356b523e2f4e11690eebcd2ab upstream.
Currently, we don't reenable the config if freezing the device failed.
For example, virtio-mem currently doesn't support suspend+resume, and trying to freeze the device will always fail. Afterwards, the device will no longer respond to resize requests, because it won't get notified about config changes.
Let's fix this by re-enabling the config if freezing fails.
Message-Id: <[email protected]>
--- drivers/virtio/virtio.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
drivers/virtio/virtio.c +8 -2
@@ -381,13 +381,19 @@ EXPORT_SYMBOL_GPL(unregister_virtio_deviint virtio_device_freeze (struct virtio_device *dev) {struct virtio_driver *drv =drv_to_virtio (dev->dev.driver); +int ret;virtio_config_disable (dev); dev->failed = dev->config->get_status (dev) &VIRTIO_CONFIG_S_FAILED ; -if (drv && drv->freeze) -return drv->freeze (dev); +if (drv && drv->freeze) { + ret = drv->freeze (dev); +if (ret) { +virtio_config_enable (dev); +return ret; + } + }return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 208/215 x86/mm/pat: fix VM_PAT handling in COW mappings
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Hildenbrand <[email protected]>
commit 04c35ab3bdae7fefbd7c7a7355f29fa03a035221 upstream.
PAT handling won't do the right thing in COW mappings: the first PTE (or, in fact, all PTEs) can be replaced during write faults to point at anon folios. Reliably recovering the correct PFN and cachemode using follow_phys() from PTEs will not work in COW mappings.
Using follow_phys(), we might just get the address+protection of the anon folio (which is very wrong), or fail on swap/nonswap entries, failing follow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() and track_pfn_copy(), not properly calling free_pfn_range().
In free_pfn_range(), we either wouldn't call memtype_free() or would call it with the wrong range, possibly leaking memory.
To fix that, let's update follow_phys() to refuse returning anon folios, and fallback to using the stored PFN inside vma->vm_pgoff for COW mappings if we run into that.
We will now properly handle untrack_pfn() with COW mappings, where we don't need the cachemode. We'll have to fail fork()->track_pfn_copy() if the first page was replaced by an anon folio, though: we'd have to store the cachemode in the VMA to make this work, likely growing the VMA size.
For now, lets keep it simple and let track_pfn_copy() just fail in that
case: it would have failed in the past with swap/nonswap entries already, and it would have done the wrong thing with anon folios.
Simple reproducer to trigger the WARN_ON_ONCE() in untrack_pfn():
<--- C reproducer --->
#include <stdio.h>
#include <sys/mman.h>
#include <unistd.h>
#include <liburing.h>
int main(void)
{
struct io_uring_params p = {};
int ring_fd;
size_t size;
char *map;
ring_fd = io_uring_setup(1, &p);
if (ring_fd < 0) {
perror("io_uring_setup");
return 1;
}
size = p.sq_off.array + p.sq_entries * sizeof(unsigned);
/* Map the submission queue ring MAP_PRIVATE */
map = mmap(0, size, PROT_READ | PROT_WRITE, MAP_PRIVATE,
ring_fd, IORING_OFF_SQ_RING);
if (map == MAP_FAILED) {
perror("mmap");
return 1;
}
/* We have at least one page. Let's COW it. */
*map = 0;
pause();
return 0; }
<--- C reproducer --->
On a system with 16 GiB RAM and swap configured:
# ./iouring & # memhog 16G # killall iouring [ 301.552930] ------------[ cut here ]------------ [ 301.553285] WARNING: CPU: 7 PID: 1402 at arch/x86/mm/pat/memtype.c:1060 untrack_pfn+0xf4/0x100 [ 301.553989] Modules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_g [ 301.558232] CPU: 7 PID: 1402 Comm: iouring Not tainted 6.7.5-100.fc38.x86_64 #1 [ 301.558772] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebu4 [ 301.559569] RIP: 0010:untrack_pfn+0xf4/0x100 [ 301.559893] Code: 75 c4 eb cf 48 8b 43 10 8b a8 e8 00 00 00 3b 6b 28 74 b8 48 8b 7b 30 e8 ea 1a f7 000 [ 301.561189] RSP: 0018:ffffba2c0377fab8 EFLAGS: 00010282 [ 301.561590] RAX: 00000000ffffffea RBX: ffff9208c8ce9cc0 RCX: 000000010455e047 [ 301.562105] RDX: 07fffffff0eb1e0a RSI: 0000000000000000 RDI: ffff9208c391d200 [ 301.562628] RBP: 0000000000000000 R08: ffffba2c0377fab8 R09: 0000000000000000 [ 301.563145] R10: ffff9208d2292d50 R11: 0000000000000002 R12: 00007fea890e0000 [ 301.563669] R13: 0000000000000000 R14: ffffba2c0377fc08 R15: 0000000000000000 [ 301.564186] FS: 0000000000000000(0000) GS:ffff920c2fbc0000(0000) knlGS:0000000000000000 [ 301.564773] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 301.565197] CR2: 00007fea88ee8a20 CR3: 00000001033a8000 CR4: 0000000000750ef0 [ 301.565725] PKRU: 55555554 [ 301.565944] Call Trace: [ 301.566148] <TASK> [ 301.566325] ? untrack_pfn+0xf4/0x100 [ 301.566618] ? __warn+0x81/0x130 [ 301.566876] ? untrack_pfn+0xf4/0x100 [ 301.567163] ? report_bug+0x171/0x1a0 [ 301.567466] ? handle_bug+0x3c/0x80 [ 301.567743] ? exc_invalid_op+0x17/0x70 [ 301.568038] ? asm_exc_invalid_op+0x1a/0x20 [ 301.568363] ? untrack_pfn+0xf4/0x100 [ 301.568660] ? untrack_pfn+0x65/0x100 [ 301.568947] unmap_single_vma+0xa6/0xe0 [ 301.569247] unmap_vmas+0xb5/0x190 [ 301.569532] exit_mmap+0xec/0x340 [ 301.569801] __mmput+0x3e/0x130 [ 301.570051] do_exit+0x305/0xaf0 ...
--- arch/x86/mm/pat.c | 50 ++++++++++++++++++++++++++++++++++++-------------- mm/memory.c | 4 ++++ 2 files changed, 40 insertions(+), 14 deletions(-)
arch/x86/mm/pat.c +36 -14
@@ -34,6 +34,7 @@#include "pat_internal.h" #include "mm_internal.h" +#include "../../mm/internal.h" /* is_cow_mapping() */ #undef pr_fmt#define pr_fmt (fmt) "" fmt
@@ -955,6 +956,38 @@ static void free_pfn_range(u64 paddr, unfree_memtype (paddr, paddr + size); } +static int get_pat_info (struct vm_area_struct *vma,resource_size_t *paddr, +pgprot_t *pgprot) +{ +unsigned long prot; + +VM_WARN_ON_ONCE (!(vma->vm_flags &VM_PAT )); + +/* +* We need the starting PFN and cachemode used for track_pfn_remap() +* that covered the whole VMA. For most mappings, we can obtain that +* information from the page tables. For COW mappings, we might now +* suddenly have anon folios mapped and follow_phys() will fail. +* +* Fallback to using vma->vm_pgoff, see remap_pfn_range_notrack(), to +* detect the PFN. If we need the cachemode as well, we're out of luck +* for now and have to fail fork(). +*/ +if (!follow_phys (vma, vma->vm_start,0 , &prot, paddr)) { +if (pgprot) + *pgprot =__pgprot (prot); +return 0 ; + } +if (is_cow_mapping (vma->vm_flags)) { +if (pgprot) +return -EINVAL ; + *paddr = (resource_size_t )vma->vm_pgoff <<PAGE_SHIFT ; +return 0 ; + } +WARN_ON_ONCE (1 ); +return -EINVAL ; +} +/* * track_pfn_copy is called when vma that is covering the pfnmap gets * copied through copy_page_range().
@@ -965,20 +998,13 @@ static void free_pfn_range(u64 paddr, unint track_pfn_copy (struct vm_area_struct *vma) {resource_size_t paddr; -unsigned long prot;unsigned long vma_size = vma->vm_end - vma->vm_start;pgprot_t pgprot;if (vma->vm_flags &VM_PAT ) { -/* -* reserve the whole chunk covered by vma. We need the -* starting address and protection from pte. -*/ -if (follow_phys (vma, vma->vm_start,0 , &prot, &paddr)) { -WARN_ON_ONCE (1 ); +if (get_pat_info (vma, &paddr, &pgprot))return -EINVAL ; - } - pgprot =__pgprot (prot); +/* reserve the whole chunk covered by vma. */ return reserve_pfn_range (paddr, vma_size, &pgprot,1 ); }
@@ -1053,7 +1079,6 @@ void untrack_pfn(struct vm_area_struct * unsigned long size) {resource_size_t paddr; -unsigned long prot;if (vma && !(vma->vm_flags &VM_PAT ))return ;
@@ -1061,11 +1086,8 @@ void untrack_pfn(struct vm_area_struct */* free the chunk starting from pfn or the whole chunk */ paddr = (resource_size_t )pfn <<PAGE_SHIFT ;if (!paddr && !size) { -if (follow_phys (vma, vma->vm_start,0 , &prot, &paddr)) { -WARN_ON_ONCE (1 ); +if (get_pat_info (vma, &paddr,NULL ))return ; - } - size = vma->vm_end - vma->vm_start; }free_pfn_range (paddr, size);
mm/memory.c +4 -0
@@ -4428,6 +4428,10 @@ int follow_phys(struct vm_area_struct *v goto out; pte = *ptep; +/* Never return PFNs of anon folios in COW mappings. */ +if (vm_normal_page (vma, address, pte)) + goto unlock; +if ((flags &FOLL_WRITE ) && !pte_write (pte)) goto unlock;
Greg Kroah-Hartman
maintainerPATCH 209/215 drm/i915/gt: Reset queue_priority_hint on parking
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chris Wilson <[email protected]>
commit 4a3859ea5240365d21f6053ee219bb240d520895 upstream.
Originally, with strict in order execution, we could complete execution only when the queue was empty. Preempt-to-busy allows replacement of an active request that may complete before the preemption is processed by HW. If that happens, the request is retired from the queue, but the queue_priority_hint remains set, preventing direct submission until after the next CS interrupt is processed.
This preempt-to-busy race can be triggered by the heartbeat, which will also act as the power-management barrier and upon completion allow us to idle the HW. We may process the completion of the heartbeat, and begin parking the engine before the CS event that restores the queue_priority_hint, causing us to fail the assertion that it is MIN.
<3>[ 166.210729] __engine_park:283 GEM_BUG_ON(engine->sched_engine->queue_priority_hint != (-((int)(~0U >> 1)) - 1))
<0>[ 166.210781] Dumping ftrace buffer:
<0>[ 166.210795] ---------------------------------
...
<0>[ 167.302811] drm_fdin-1097 2..s1. 165741070us : trace_ports: 0000:00:02.0 rcs0: promote { ccid:20 1217:2 prio 0 }
<0>[ 167.302861] drm_fdin-1097 2d.s2. 165741072us : execlists_submission_tasklet: 0000:00:02.0 rcs0: preempting last=1217:2, prio=0, hint=2147483646
<0>[ 167.302928] drm_fdin-1097 2d.s2. 165741072us : __i915_request_unsubmit: 0000:00:02.0 rcs0: fence 1217:2, current 0
<0>[ 167.302992] drm_fdin-1097 2d.s2. 165741073us : __i915_request_submit: 0000:00:02.0 rcs0: fence 3:4660, current 4659
<0>[ 167.303044] drm_fdin-1097 2d.s1. 165741076us : execlists_submission_tasklet: 0000:00:02.0 rcs0: context:3 schedule-in, ccid:40
<0>[ 167.303095] drm_fdin-1097 2d.s1. 165741077us : trace_ports: 0000:00:02.0 rcs0: submit { ccid:40 3:4660* prio 2147483646 }
<0>[ 167.303159] kworker/-89 11..... 165741139us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence c90:2, current 2
<0>[ 167.303208] kworker/-89 11..... 165741148us : __intel_context_do_unpin: 0000:00:02.0 rcs0: context:c90 unpin
<0>[ 167.303272] kworker/-89 11..... 165741159us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence 1217:2, current 2
<0>[ 167.303321] kworker/-89 11..... 165741166us : __intel_context_do_unpin: 0000:00:02.0 rcs0: context:1217 unpin
<0>[ 167.303384] kworker/-89 11..... 165741170us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence 3:4660, current 4660
<0>[ 167.303434] kworker/-89 11d..1. 165741172us : __intel_context_retire: 0000:00:02.0 rcs0: context:1216 retire runtime: { total:56028ns, avg:56028ns }
<0>[ 167.303484] kworker/-89 11..... 165741198us : __engine_park: 0000:00:02.0 rcs0: parked
<0>[ 167.303534] <idle>-0 5d.H3. 165741207us : execlists_irq_handler: 0000:00:02.0 rcs0: semaphore yield: 00000040
<0>[ 167.303583] kworker/-89 11..... 165741397us : __intel_context_retire: 0000:00:02.0 rcs0: context:1217 retire runtime: { total:325575ns, avg:0ns }
<0>[ 167.303756] kworker/-89 11..... 165741777us : __intel_context_retire: 0000:00:02.0 rcs0: context:c90 retire runtime: { total:0ns, avg:0ns }
<0>[ 167.303806] kworker/-89 11..... 165742017us : __engine_park: __engine_park:283 GEM_BUG_ON(engine->sched_engine->queue_priority_hint != (-((int)(~0U >> 1)) - 1))
<0>[ 167.303811] ---------------------------------
<4>[ 167.304722] ------------[ cut here ]------------
<2>[ 167.304725] kernel BUG at drivers/gpu/drm/i915/gt/intel_engine_pm.c:283!
<4>[ 167.304731] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
<4>[ 167.304734] CPU: 11 PID: 89 Comm: kworker/11:1 Tainted: G W 6.8.0-rc2-CI_DRM_14193-gc655e0fd2804+ #1
<4>[ 167.304736] Hardware name: Intel Corporation Rocket Lake Client Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 04/21/2022
<4>[ 167.304738] Workqueue: i915-unordered retire_work_handler [i915]
<4>[ 167.304839] RIP: 0010:__engine_park+0x3fd/0x680 [i915]
<4>[ 167.304937] Code: 00 48 c7 c2 b0 e5 86 a0 48 8d 3d 00 00 00 00 e8 79 48 d4 e0 bf 01 00 00 00 e8 ef 0a d4 e0 31 f6 bf 09 00 00 00 e8 03 49 c0 e0 <0f> 0b 0f 0b be 01 00 00 00 e8 f5 61 fd ff 31 c0 e9 34 fd ff ff 48
<4>[ 167.304940] RSP: 0018:ffffc9000059fce0 EFLAGS: 00010246
<4>[ 167.304942] RAX: 0000000000000200 RBX: 0000000000000000 RCX: 0000000000000006
<4>[ 167.304944] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000009
<4>[ 167.304946] RBP: ffff8881330ca1b0 R08: 0000000000000001 R09: 0000000000000001
<4>[ 167.304947] R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881330ca000
<4>[ 167.304948] R13: ffff888110f02aa0 R14: ffff88812d1d0205 R15: ffff88811277d4f0
<4>[ 167.304950] FS: 0000000000000000(0000) GS:ffff88844f780000(0000) knlGS:0000000000000000
<4>[ 167.304952] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[ 167.304953] CR2: 00007fc362200c40 CR3: 000000013306e003 CR4: 0000000000770ef0
<4>[ 167.304955] PKRU: 55555554
<4>[ 167.304957] Call Trace:
<4>[ 167.304958] <TASK>
<4>[ 167.305573] ____intel_wakeref_put_last+0x1d/0x80 [i915]
<4>[ 167.305685] i915_request_retire.part.0+0x34f/0x600 [i915]
<4>[ 167.305800] retire_requests+0x51/0x80 [i915]
<4>[ 167.305892] intel_gt_retire_requests_timeout+0x27f/0x700 [i915]
<4>[ 167.305985] process_scheduled_works+0x2db/0x530
<4>[ 167.305990] worker_thread+0x18c/0x350
<4>[ 167.305993] kthread+0xfe/0x130
<4>[ 167.305997] ret_from_fork+0x2c/0x50
<4>[ 167.306001] ret_from_fork_asm+0x1b/0x30
<4>[ 167.306004] </TASK>It is necessary for the queue_priority_hint to be lower than the next request submission upon waking up, as we rely on the hint to decide when to kick the tasklet to submit that first request.
--- drivers/gpu/drm/i915/gt/intel_engine_pm.c | 3 --- drivers/gpu/drm/i915/gt/intel_lrc.c | 3 +++ 2 files changed, 3 insertions(+), 3 deletions(-)
drivers/gpu/drm/i915/gt/intel_engine_pm.c +0 -3
@@ -145,9 +145,6 @@ static int __engine_park(struct intel_waintel_engine_disarm_breadcrumbs (engine);intel_engine_pool_park (&engine->pool); -/* Must be reset upon idling, or we may miss the busy wakeup. */ -GEM_BUG_ON (engine->execlists.queue_priority_hint !=INT_MIN ); -if (engine->park) engine->park (engine);
drivers/gpu/drm/i915/gt/intel_lrc.c +3 -0
@@ -2992,6 +2992,9 @@ static u32 *gen11_emit_fini_breadcrumb_rstatic void execlists_park (struct intel_engine_cs *engine) {del_timer (&engine->execlists.timer); + +/* Reset upon idling, or we may delay the busy wakeup. */ +WRITE_ONCE (engine->execlists.queue_priority_hint,INT_MIN ); }void intel_execlists_set_default_submission (struct intel_engine_cs *engine)
Greg Kroah-Hartman
maintainerPATCH 210/215 x86/alternative: Dont call text_poke() in lazy TLB mode
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Juergen Gross <[email protected]>
commit abee7c494d8c41bb388839bccc47e06247f0d7de upstream.
When running in lazy TLB mode the currently active page tables might be the ones of a previous process, e.g. when running a kernel thread.
This can be problematic in case kernel code is being modified via text_poke() in a kernel thread, and on another processor exit_mmap() is active for the process which was running on the first cpu before the kernel thread.
As text_poke() is using a temporary address space and the former address space (obtained via cpu_tlbstate.loaded_mm) is restored afterwards, there is a race possible in case the cpu on which exit_mmap() is running wants to make sure there are no stale references to that address space on any cpu active (this e.g. is required when running as a Xen PV guest, where this problem has been observed and analyzed).
In order to avoid that, drop off TLB lazy mode before switching to the temporary address space.
--- arch/x86/include/asm/mmu_context.h | 9 +++++++++ 1 file changed, 9 insertions(+)
arch/x86/include/asm/mmu_context.h +9 -0
@@ -379,6 +379,15 @@ static inline temp_mm_state_t use_temportemp_mm_state_t temp_state;lockdep_assert_irqs_disabled (); + +/* +* Make sure not to be in TLB lazy mode, as otherwise we'll end up +* with a stale address space WITHOUT being in lazy mode after +* restoring the previous mm. +*/ +if (this_cpu_read (cpu_tlbstate.is_lazy)) +leave_mm (smp_processor_id ()); + temp_state.mm =this_cpu_read (cpu_tlbstate.loaded_mm);switch_mm_irqs_off (NULL , mm, current);
Greg Kroah-Hartman
maintainerPATCH 211/215 Bluetooth: btintel: Fixe build regression
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Luiz Augusto von Dentz <[email protected]>
commit 6e62ebfb49eb65bdcbfc5797db55e0ce7f79c3dd upstream.
This fixes the following build regression:
drivers-bluetooth-btintel.c-btintel_read_version()-warn:
passing-zero-to-PTR_ERR
--- drivers/bluetooth/btintel.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/bluetooth/btintel.c +2 -2
@@ -340,13 +340,13 @@ int btintel_read_version(struct hci_devstruct sk_buff *skb; skb =__hci_cmd_sync (hdev,0xfc05 ,0 ,NULL ,HCI_CMD_TIMEOUT ); -if (IS_ERR_OR_NULL (skb)) { +if (IS_ERR (skb)) {bt_dev_err (hdev,"Reading Intel version information failed (%ld)" ,PTR_ERR (skb));return PTR_ERR (skb); } -if (skb->len !=sizeof (*ver)) { +if (!skb || skb->len !=sizeof (*ver)) {bt_dev_err (hdev,"Intel version event size mismatch" );kfree_skb (skb);return -EILSEQ ;
Greg Kroah-Hartman
maintainerPATCH 212/215 VMCI: Fix possible memcpy() run-time warning in vmci_datagram_invoke_guest_handler()
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vasiliy Kovalev <[email protected]>
commit e606e4b71798cc1df20e987dde2468e9527bd376 upstream.
The changes are similar to those given in the commit 19b070fefd0d ("VMCI: Fix memcpy() run-time warning in dg_dispatch_as_host()").
Fix filling of the msg and msg_payload in dg_info struct, which prevents a possible "detected field-spanning write" of memcpy warning that is issued by the tracking mechanism __fortify_memcpy_chk.
--- drivers/misc/vmw_vmci/vmci_datagram.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/misc/vmw_vmci/vmci_datagram.c +2 -1
@@ -378,7 +378,8 @@ int vmci_datagram_invoke_guest_handler(s dg_info->in_dg_host_queue = false; dg_info->entry = dst_entry; -memcpy (&dg_info->msg, dg,VMCI_DG_SIZE (dg)); + dg_info->msg = *dg; +memcpy (&dg_info->msg_payload, dg +1 , dg->payload_size);INIT_WORK (&dg_info->work, dg_delayed_dispatch);schedule_work (&dg_info->work);
Greg Kroah-Hartman
maintainerPATCH 213/215 erspan: Check IFLA_GRE_ERSPAN_VER is set.
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: William Tu <[email protected]>
commit 51fa960d3b5163b1af22efdebcabfccc5d615ad6 upstream.
Add a check to make sure the IFLA_GRE_ERSPAN_VER is provided by users.
--- net/ipv4/ip_gre.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
net/ipv4/ip_gre.c +2 -1
@@ -1106,7 +1106,8 @@ static int erspan_validate(struct nlattrif (ret)return ret; -if (nla_get_u8 (data[IFLA_GRE_ERSPAN_VER ]) ==0 ) +if (data[IFLA_GRE_ERSPAN_VER ] && +nla_get_u8 (data[IFLA_GRE_ERSPAN_VER ]) ==0 )return 0 ;/* ERSPAN type II/III should only have GRE sequence and key flag */
Greg Kroah-Hartman
maintainerPATCH 214/215 ip_gre: do not report erspan version on GRE interface
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hangbin Liu <[email protected]>
commit ee496694b9eea651ae1aa4c4667d886cdf74aa3b upstream.
Although the type I ERSPAN is based on the barebones IP + GRE encapsulation and no extra ERSPAN header. Report erspan version on GRE interface looks unreasonable. Fix this by separating the erspan and gre fill info.
IPv6 GRE does not have this info as IPv6 only supports erspan version 1 and 2.
--- net/ipv4/ip_gre.c | 48 +++++++++++++++++++++++++++++------------------- 1 file changed, 29 insertions(+), 19 deletions(-)
net/ipv4/ip_gre.c +29 -19
@@ -1504,24 +1504,6 @@ static int ipgre_fill_info(struct sk_bufstruct ip_tunnel_parm *p = &t->parms;__be16 o_flags = p->o_flags; -if (t->erspan_ver <=2 ) { -if (t->erspan_ver !=0 && !t->collect_md) - o_flags |=TUNNEL_KEY ; - -if (nla_put_u8 (skb,IFLA_GRE_ERSPAN_VER , t->erspan_ver)) - goto nla_put_failure; - -if (t->erspan_ver ==1 ) { -if (nla_put_u32 (skb,IFLA_GRE_ERSPAN_INDEX , t->index)) - goto nla_put_failure; - }else if (t->erspan_ver ==2 ) { -if (nla_put_u8 (skb,IFLA_GRE_ERSPAN_DIR , t->dir)) - goto nla_put_failure; -if (nla_put_u16 (skb,IFLA_GRE_ERSPAN_HWID , t->hwid)) - goto nla_put_failure; - } - } - if (nla_put_u32(skb, IFLA_GRE_LINK, p->link) || nla_put_be16(skb, IFLA_GRE_IFLAGS, gre_tnl_flags_to_gre_flags(p->i_flags)) ||
@@ -1562,6 +1544,34 @@ nla_put_failure:return -EMSGSIZE ; } +static int erspan_fill_info (struct sk_buff *skb,const struct net_device *dev) +{ +struct ip_tunnel *t =netdev_priv (dev); + +if (t->erspan_ver <=2 ) { +if (t->erspan_ver !=0 && !t->collect_md) + t->parms.o_flags |=TUNNEL_KEY ; + +if (nla_put_u8 (skb,IFLA_GRE_ERSPAN_VER , t->erspan_ver)) + goto nla_put_failure; + +if (t->erspan_ver ==1 ) { +if (nla_put_u32 (skb,IFLA_GRE_ERSPAN_INDEX , t->index)) + goto nla_put_failure; + }else if (t->erspan_ver ==2 ) { +if (nla_put_u8 (skb,IFLA_GRE_ERSPAN_DIR , t->dir)) + goto nla_put_failure; +if (nla_put_u16 (skb,IFLA_GRE_ERSPAN_HWID , t->hwid)) + goto nla_put_failure; + } + } + +return ipgre_fill_info (skb, dev); + +nla_put_failure: +return -EMSGSIZE ; +} +static void erspan_setup (struct net_device *dev) {struct ip_tunnel *t =netdev_priv (dev);
@@ -1640,7 +1650,7 @@ static struct rtnl_link_ops erspan_link_ .changelink = erspan_changelink, .dellink = ip_tunnel_dellink, .get_size = ipgre_get_size, - .fill_info = ipgre_fill_info, + .fill_info = erspan_fill_info, .get_link_net = ip_tunnel_get_link_net, };
Greg Kroah-Hartman
maintainerPATCH 215/215 firmware: meson_sm: fix to avoid potential NULL pointer dereference
In reply to Greg Kroah-Hartman5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhang Shurong <[email protected]>
commit f2ed165619c16577c02b703a114a1f6b52026df4 upstream.
of_match_device() may fail and returns a NULL pointer.
Fix this by checking the return value of of_match_device.
--- drivers/firmware/meson/meson_sm.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/firmware/meson/meson_sm.c +2 -0
@@ -302,6 +302,8 @@ static int __init meson_sm_probe(structreturn -ENOMEM ; chip =of_match_device (meson_sm_ids, dev)->data; +if (!chip) +return -EINVAL ;if (chip->cmd_shmem_in_base) { fw->sm_shmem_in_base = meson_sm_map_shmem(chip->cmd_shmem_in_base,
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.274 release. There are 215 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 13 Apr 2024 09:53:55 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.274-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.4.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Signature · 1 line
Florian
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.274 release. There are 215 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 13 Apr 2024 09:53:55 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.274-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.4.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.274 release. There are 215 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Quoted 9 lines
Responses should be made by Sat, 13 Apr 2024 09:53:55 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.274-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.4.y
and the diffstat can be found below.
KernelCI report for stable-rc/linux-5.4.y for this week.
## stable-rc HEAD for linux-5.4.y:
Date: 2024-04-11
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/log/?h=82d3ef7640657b7e1fb7091841ba7a47a7a29ab4
## Build failures:
No build failures seen for the stable-rc/linux-5.4.y commit head \o/
## Boot failures:
No **new** boot failures seen for the stable-rc/linux-5.4.y commit head \o/
Thanks,
Shreeya Patel
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.274 release. There are 215 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 13 Apr 2024 09:53:55 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.274-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.4.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v5.4:
10 builds: 10 pass, 0 fail
24 boots: 24 pass, 0 fail
54 tests: 54 pass, 0 failLinux version: 5.4.274-rc1-g82d3ef764065
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04Jon
Hi Greg,
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.274 release. There are 215 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 13 Apr 2024 09:53:55 +0000. Anything received after that time might be too late.
No problems seen on x86_64 and aarch64 with our testing.
Thanks,
Harshit
Quoted 9 lines
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.274-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.4.y
and the diffstat can be found below.thanks,
greg k-h
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.274 release. There are 215 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 13 Apr 2024 09:53:55 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.274-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.4.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
## Build
* kernel: 5.4.274-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.4.y
* git commit: 82d3ef7640657b7e1fb7091841ba7a47a7a29ab4
* git describe: v5.4.273-216-g82d3ef764065
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.273-216-g82d3ef764065
## Test Regressions (compared to v5.4.273)
## Metric Regressions (compared to v5.4.273)
## Test Fixes (compared to v5.4.273)
## Metric Fixes (compared to v5.4.273)
## Test result summary
total: 102739, pass: 82092, fail: 2618, skip: 17956, xfail: 73
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 135 total, 135 passed, 0 failed
* arm64: 35 total, 33 passed, 2 failed
* i386: 23 total, 17 passed, 6 failed
* mips: 25 total, 25 passed, 0 failed
* parisc: 3 total, 0 passed, 3 failed
* powerpc: 30 total, 30 passed, 0 failed
* riscv: 9 total, 9 passed, 0 failed
* s390: 6 total, 6 passed, 0 failed
* sh: 10 total, 10 passed, 0 failed
* sparc: 6 total, 6 passed, 0 failed
* x86_64: 31 total, 31 passed, 0 failed
## Test suites summary
* boot
* kselftest-android
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers-dma-buf
* kselftest-efivarfs
* kselftest-exec
* kselftest-filesystems
* kselftest-filesystems-binderfs
* kselftest-filesystems-epoll
* kselftest-firmware
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-lib
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mm
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-net-forwarding
* kselftest-net-mptcp
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-user_events
* kselftest-vDSO
* kselftest-watchdog
* kselftest-x86
* kselftest-zram
* kunit
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-smoketest
* ltp-syscalls
* ltp-tracing
* perf
* rcutorture
--
Linaro LKFT
https://lkft.linaro.org
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.274 release. There are 215 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 13 Apr 2024 09:53:55 +0000. Anything received after that time might be too late.
[ ... ]
Quoted 4 lines
Sean Christopherson <[email protected]>
KVM: Always flush async #PF workqueue when vCPU is being destroyed
This backport is bad. In kvm_setup_async_pf(), it removes a call to kvm_get_kvm(). However, it does not remove the call to kvm_put_kvm() in its error handler. Also see upstream commit 7863e346e108 ("KVM:async_pf: Cleanup kvm_setup_async_pf()") which explains that one of the error paths in kvm_setup_async_pf() which is not supposed to be observed can be observed after all.
Guenter
Quoted 15 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.274 release. There are 215 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 13 Apr 2024 09:53:55 +0000. Anything received after that time might be too late.
[ ... ]
Quoted 4 lines
Sean Christopherson <[email protected]>
KVM: Always flush async #PF workqueue when vCPU is being destroyed
Quoted 7 lines
This backport is bad. In
kvm_setup_async_pf(), it removes a call tokvm_get_kvm(). However, it does not remove the call tokvm_put_kvm()in its error handler. Also see upstream commit7863e346e108("KVM:async_pf: Cleanupkvm_setup_async_pf()") which explains that one of the error paths inkvm_setup_async_pf()which is not supposed to be observed can be observed after all.
Reverting the above commit from v5.4.y fixes the problem. Alternatively, applying commit 7863e346e108 on top of v5.4.274 fixes it as well.
I added Phillip Pearson to Cc:; he did all the testing and can provide additional information if needed.
Thanks,
Guenter
Greg Kroah-Hartman
maintainerQuoted 24 lines · Guenter Roeck
Quoted 15 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.274 release. There are 215 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 13 Apr 2024 09:53:55 +0000. Anything received after that time might be too late.
[ ... ]
Quoted 4 lines
Sean Christopherson <[email protected]>
KVM: Always flush async #PF workqueue when vCPU is being destroyedQuoted 7 lines
This backport is bad. In
kvm_setup_async_pf(), it removes a call tokvm_get_kvm(). However, it does not remove the call tokvm_put_kvm()in its error handler. Also see upstream commit7863e346e108("KVM:async_pf: Cleanupkvm_setup_async_pf()") which explains that one of the error paths inkvm_setup_async_pf()which is not supposed to be observed can be observed after all.
Quoted 5 lines
Reverting the above commit from v5.4.y fixes the problem. Alternatively, applying commit
7863e346e108on top of v5.4.274 fixes it as well.I added Phillip Pearson to Cc:; he did all the testing and can provide additional information if needed.
So which is recommended, revert or add the other commit?
thanks,
greg k-h
Quoted 25 lines · Greg Kroah-Hartman
Quoted 24 lines · Guenter Roeck
Quoted 22 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.274 release. There are 215 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 13 Apr 2024 09:53:55 +0000. Anything received after that time might be too late.
[ ... ]
Quoted 4 lines
Sean Christopherson <[email protected]>
KVM: Always flush async #PF workqueue when vCPU is being destroyedThis backport is bad. In
kvm_setup_async_pf(), it removes a call tokvm_get_kvm(). However, it does not remove the call tokvm_put_kvm()in its error handler. Also see upstream commit7863e346e108("KVM:async_pf: Cleanupkvm_setup_async_pf()") which explains that one of the error paths inkvm_setup_async_pf()which is not supposed to be observed can be observed after all.
Quoted 8 lines
Quoted 5 lines
Reverting the above commit from v5.4.y fixes the problem. Alternatively, applying commit
7863e346e108on top of v5.4.274 fixes it as well.I added Phillip Pearson to Cc:; he did all the testing and can provide additional information if needed.
So which is recommended, revert or add the other commit?
We decided to apply 7863e346e108.
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/5465806
Guenter
Greg Kroah-Hartman
maintainerQuoted 29 lines · Guenter Roeck
Quoted 28 lines · Greg Kroah-Hartman
Quoted 27 lines · Guenter Roeck
Quoted 15 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.274 release. There are 215 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 13 Apr 2024 09:53:55 +0000. Anything received after that time might be too late.
[ ... ]
Quoted 4 lines
Sean Christopherson <[email protected]>
KVM: Always flush async #PF workqueue when vCPU is being destroyedQuoted 7 lines
This backport is bad. In
kvm_setup_async_pf(), it removes a call tokvm_get_kvm(). However, it does not remove the call tokvm_put_kvm()in its error handler. Also see upstream commit7863e346e108("KVM:async_pf: Cleanupkvm_setup_async_pf()") which explains that one of the error paths inkvm_setup_async_pf()which is not supposed to be observed can be observed after all.Reverting the above commit from v5.4.y fixes the problem. Alternatively, applying commit
7863e346e108on top of v5.4.274 fixes it as well.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
I added Phillip Pearson to Cc:; he did all the testing and can provide additional information if needed.
So which is recommended, revert or add the other commit?
We decided to apply
7863e346e108.https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/5465806
Great, will do the same here, thanks.
greg k-h