5.16.5-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainerPATCH 146/200 octeontx2-pf: cn10k: Ensure valid pointers are freed to aura
In reply to Greg Kroah-HartmanFrom: Geetha sowjanya <[email protected]>
[ Upstream commit c5d731c54a17677939bd59ee8be4ed74d7485ba4 ]
While freeing SQB pointers to aura, driver first memcpy to target address and then triggers lmtst operation to free pointer to the aura. We need to ensure(by adding dmb barrier)that memcpy is finished before pointers are freed to the aura. This patch also adds the missing sq context structure entry in debugfs.
--- drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c | 2 ++ drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h | 1 + 2 files changed, 3 insertions(+)
drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c +2 -0
@@ -1224,6 +1224,8 @@ static void print_nix_cn10k_sq_ctx(struct seq_file *m,seq_printf (m,"W3: head_offset\t\t\t%d\nW3: smenq_next_sqb_vld\t\t%d\n\n" , sq_ctx->head_offset, sq_ctx->smenq_next_sqb_vld); +seq_printf (m,"W3: smq_next_sq_vld\t\t%d\nW3: smq_pend\t\t\t%d\n" , + sq_ctx->smq_next_sq_vld, sq_ctx->smq_pend);seq_printf (m,"W4: next_sqb \t\t\t%llx\n\n" , sq_ctx->next_sqb);seq_printf (m,"W5: tail_sqb \t\t\t%llx\n\n" , sq_ctx->tail_sqb);seq_printf (m,"W6: smenq_sqb \t\t\t%llx\n\n" , sq_ctx->smenq_sqb);
drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h +1 -0
@@ -603,6 +603,7 @@ static inline void __cn10k_aura_freeptr(struct otx2_nic *pfvf, u64 aura, size++; tar_addr |= ((size -1 ) &0x7 ) <<4 ; } +dma_wmb ();memcpy ((u64 *)lmt_info->lmt_addr, ptrs,sizeof (u64) * num_ptrs);/* Perform LMTST flush */ cn10k_lmt_flush (val, tar_addr);
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 147/200 octeontx2-af: Increase link credit restore polling timeout
In reply to Greg Kroah-HartmanFrom: Geetha sowjanya <[email protected]>
[ Upstream commit 1581d61b42d985cefe7b71eea67ab3bfcbf34d0f ]
It's been observed that sometimes link credit restore takes a lot of time than the current timeout. This patch increases the default timeout value and return the proper error value on failure.
--- drivers/net/ethernet/marvell/octeontx2/af/mbox.h | 1 + drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c | 4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-)
drivers/net/ethernet/marvell/octeontx2/af/mbox.h +1 -0
@@ -732,6 +732,7 @@ enum nix_af_status {NIX_AF_ERR_BANDPROF_INVAL_REQ =-428 ,NIX_AF_ERR_CQ_CTX_WRITE_ERR =-429 ,NIX_AF_ERR_AQ_CTX_RETRY_WRITE =-430 , + NIX_AF_ERR_LINK_CREDITS = -431, };/* For NIX RX vtag action */
drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c +2 -2
@@ -3891,8 +3891,8 @@ nix_config_link_credits(struct rvu *rvu, int blkaddr, int link, NIX_AF_TL1X_SW_XOFF(schq), BIT_ULL(0)); } - rc = -EBUSY ; - poll_tmo = jiffies +usecs_to_jiffies (10000 ); + rc =NIX_AF_ERR_LINK_CREDITS ; + poll_tmo = jiffies +usecs_to_jiffies (200000 );/* Wait for credits to return */ do { if (time_after(jiffies, poll_tmo))
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 148/200 octeontx2-af: cn10k: Do not enable RPM loopback for LPC interfaces
In reply to Greg Kroah-HartmanFrom: Geetha sowjanya <[email protected]>
[ Upstream commit df66b6ebc5dcf7253e35a640b9ec4add54195c25 ]
Internal looback is not supported to low rate LPCS interface like SGMII/QSGMII. Hence don't allow to enable for such interfaces.
--- .../net/ethernet/marvell/octeontx2/af/rpm.c | 27 +++++++++---------- 1 file changed, 12 insertions(+), 15 deletions(-)
drivers/net/ethernet/marvell/octeontx2/af/rpm.c +12 -15
@@ -291,23 +291,20 @@ int rpm_lmac_internal_loopback(void *rpmd, int lmac_id, bool enable)if (!rpm || lmac_id >= rpm->lmac_count)return -ENODEV ; lmac_type = rpm->mac_ops->get_lmac_type (rpm, lmac_id); -if (lmac_type ==LMAC_MODE_100G_R ) { - cfg =rpm_read (rpm, lmac_id,RPMX_MTI_PCS100X_CONTROL1 ); - -if (enable) - cfg |=RPMX_MTI_PCS_LBK ; -else - cfg &= ~RPMX_MTI_PCS_LBK ; -rpm_write (rpm, lmac_id,RPMX_MTI_PCS100X_CONTROL1 , cfg); - }else { - cfg =rpm_read (rpm, lmac_id,RPMX_MTI_LPCSX_CONTROL1 ); -if (enable) - cfg |=RPMX_MTI_PCS_LBK ; -else - cfg &= ~RPMX_MTI_PCS_LBK ; -rpm_write (rpm, lmac_id,RPMX_MTI_LPCSX_CONTROL1 , cfg); + +if (lmac_type ==LMAC_MODE_QSGMII || lmac_type ==LMAC_MODE_SGMII ) { +dev_err (&rpm->pdev->dev,"loopback not supported for LPC mode\n" ); +return 0 ; } + cfg =rpm_read (rpm, lmac_id,RPMX_MTI_PCS100X_CONTROL1 ); + +if (enable) + cfg |=RPMX_MTI_PCS_LBK ; +else + cfg &= ~RPMX_MTI_PCS_LBK ; +rpm_write (rpm, lmac_id,RPMX_MTI_PCS100X_CONTROL1 , cfg); +return 0 ; }
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 149/200 octeontx2-pf: Forward error codes to VF
In reply to Greg Kroah-HartmanFrom: Subbaraya Sundeep <[email protected]>
[ Upstream commit a8db854be28622a2477cb21cdf7f829adbb2c42d ]
PF forwards its VF messages to AF and corresponding replies from AF to VF. AF sets proper error code in the replies after processing message requests. Currently PF checks the error codes in replies and sends invalid message to VF. This way VF lacks the information of error code set by AF for its messages. This patch changes that such that PF simply forwards AF replies so that VF can handle error codes.
--- drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c +6 -1
@@ -394,7 +394,12 @@ static int otx2_forward_vf_mbox_msgs(struct otx2_nic *pf, dst_mdev->msg_size = mbox_hdr->msg_size; dst_mdev->num_msgs = num_msgs; err =otx2_sync_mbox_msg (dst_mbox); -if (err) { +/* Error code -EIO indicate there is a communication failure +* to the AF. Rest of the error codes indicate that AF processed +* VF messages and set the error codes in response messages +* (if any) so simply forward responses to VF. +*/ +if (err == -EIO ) {dev_warn (pf->dev,"AF not responding to VF%d messages\n" , vf);/* restore PF mbase and exit */
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 150/200 octeontx2-af: Add KPU changes to parse NGIO as separate layer
In reply to Greg Kroah-HartmanFrom: Kiran Kumar K <[email protected]>
[ Upstream commit 745166fcf01cecc4f5ff3defc6586868349a43f9 ]
With current KPU profile NGIO is being parsed along with CTAG as a single layer. Because of this MCAM/ntuple rules installed with ethertype as 0x8842 are not being hit. Adding KPU profile changes to parse NGIO in separate ltype and CTAG in separate ltype.
--- .../marvell/octeontx2/af/npc_profile.h | 70 +++++++++---------- 1 file changed, 35 insertions(+), 35 deletions(-)
drivers/net/ethernet/marvell/octeontx2/af/npc_profile.h +35 -35
@@ -185,7 +185,6 @@ enum npc_kpu_parser_state {NPC_S_KPU2_QINQ ,NPC_S_KPU2_ETAG ,NPC_S_KPU2_EXDSA , -NPC_S_KPU2_NGIO ,NPC_S_KPU2_CPT_CTAG ,NPC_S_KPU2_CPT_QINQ , NPC_S_KPU3_CTAG,
@@ -212,6 +211,7 @@ enum npc_kpu_parser_state {NPC_S_KPU5_NSH ,NPC_S_KPU5_CPT_IP ,NPC_S_KPU5_CPT_IP6 , +NPC_S_KPU5_NGIO ,NPC_S_KPU6_IP6_EXT ,NPC_S_KPU6_IP6_HOP_DEST , NPC_S_KPU6_IP6_ROUT,
@@ -1120,15 +1120,6 @@ static struct npc_kpu_profile_cam kpu1_cam_entries[] = {0x0000 ,0x0000 , }, - { -NPC_S_KPU1_ETHER ,0xff , -NPC_ETYPE_CTAG , -0xffff , -NPC_ETYPE_NGIO , -0xffff , -0x0000 , -0x0000 , - }, {NPC_S_KPU1_ETHER ,0xff , NPC_ETYPE_CTAG,
@@ -1966,6 +1957,15 @@ static struct npc_kpu_profile_cam kpu2_cam_entries[] = {0x0000 ,0x0000 , }, + { +NPC_S_KPU2_CTAG ,0xff , +NPC_ETYPE_NGIO , +0xffff , +0x0000 , +0x0000 , +0x0000 , +0x0000 , + }, {NPC_S_KPU2_CTAG ,0xff , NPC_ETYPE_PPPOE,
@@ -2749,15 +2749,6 @@ static struct npc_kpu_profile_cam kpu2_cam_entries[] = {0x0000 ,0x0000 , }, - { -NPC_S_KPU2_NGIO ,0xff , -0x0000 , -0x0000 , -0x0000 , -0x0000 , -0x0000 , -0x0000 , - }, {NPC_S_KPU2_CPT_CTAG ,0xff , NPC_ETYPE_IP,
@@ -5089,6 +5080,15 @@ static struct npc_kpu_profile_cam kpu5_cam_entries[] = {0x0000 ,0x0000 , }, + { +NPC_S_KPU5_NGIO ,0xff , +0x0000 , +0x0000 , +0x0000 , +0x0000 , +0x0000 , +0x0000 , + }, {NPC_S_NA ,0X00 , 0x0000,
@@ -8422,14 +8422,6 @@ static struct npc_kpu_profile_action kpu1_action_entries[] = {0 ,0 ,0 ,0 ,0 , }, - { -NPC_ERRLEV_RE ,NPC_EC_NOERR , -8 ,12 ,0 ,0 ,0 , -NPC_S_KPU2_NGIO ,12 ,1 , -NPC_LID_LA ,NPC_LT_LA_ETHER , -0 , -0 ,0 ,0 ,0 , - }, {NPC_ERRLEV_RE ,NPC_EC_NOERR , 8, 12, 0, 0, 0,
@@ -9194,6 +9186,14 @@ static struct npc_kpu_profile_action kpu2_action_entries[] = {0 ,0 ,0 ,0 ,0 , }, + { +NPC_ERRLEV_RE ,NPC_EC_NOERR , +0 ,0 ,0 ,2 ,0 , +NPC_S_KPU5_NGIO ,6 ,1 , +NPC_LID_LB ,NPC_LT_LB_CTAG , +0 , +0 ,0 ,0 ,0 , + }, {NPC_ERRLEV_RE ,NPC_EC_NOERR , 8, 0, 6, 2, 0,
@@ -9890,14 +9890,6 @@ static struct npc_kpu_profile_action kpu2_action_entries[] = {NPC_F_LB_U_UNK_ETYPE |NPC_F_LB_L_EXDSA ,0 ,0 ,0 ,0 , }, - { -NPC_ERRLEV_RE ,NPC_EC_NOERR , -0 ,0 ,0 ,0 ,1 , -NPC_S_NA ,0 ,1 , -NPC_LID_LC ,NPC_LT_LC_NGIO , -0 , -0 ,0 ,0 ,0 , - }, {NPC_ERRLEV_RE ,NPC_EC_NOERR , 8, 0, 6, 2, 0,
@@ -11973,6 +11965,14 @@ static struct npc_kpu_profile_action kpu5_action_entries[] = {0 ,0 ,0 ,0 ,0 , }, + { +NPC_ERRLEV_RE ,NPC_EC_NOERR , +0 ,0 ,0 ,0 ,1 , +NPC_S_NA ,0 ,1 , +NPC_LID_LC ,NPC_LT_LC_NGIO , +0 , +0 ,0 ,0 ,0 , + }, {NPC_ERRLEV_LC ,NPC_EC_UNK , 0, 0, 0, 0, 1,
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 151/200 rxrpc: Adjust retransmission backoff
In reply to Greg Kroah-HartmanFrom: David Howells <[email protected]>
[ Upstream commit 2c13c05c5ff4b9fc907b07f7311821910ebaaf8a ]
Improve retransmission backoff by only backing off when we retransmit data packets rather than when we set the lost ack timer.
To this end:
(1) In rxrpc_resend(), use rxrpc_get_rto_backoff() when setting the retransmission timer and only tell it that we are retransmitting if we actually have things to retransmit.
Note that it's possible for the retransmission algorithm to race with the processing of a received ACK, so we may see no packets needing retransmission.
(2) In rxrpc_send_data_packet(), don't bump the backoff when setting the ack_lost_at timer, as it may then get bumped twice.
With this, when looking at one particular packet, the retransmission intervals were seen to be 1.5ms, 2ms, 3ms, 5ms, 9ms, 17ms, 33ms, 71ms, 136ms, 264ms, 544ms, 1.088s, 2.1s, 4.2s and 8.3s.
--- net/rxrpc/call_event.c | 8 +++----- net/rxrpc/output.c | 2 +- 2 files changed, 4 insertions(+), 6 deletions(-)
net/rxrpc/call_event.c +3 -5
@@ -157,7 +157,7 @@ static void rxrpc_congestion_timeout(struct rxrpc_call *call)static void rxrpc_resend (struct rxrpc_call *call,unsigned long now_j) {struct sk_buff *skb; -unsigned long resend_at, rto_j; +unsigned long resend_at;rxrpc_seq_t cursor, seq, top;ktime_t now, max_age, oldest, ack_ts;int ix;
@@ -165,10 +165,8 @@ static void rxrpc_resend(struct rxrpc_call *call, unsigned long now_j)_enter ("{%d,%d}" , call->tx_hard_ack, call->tx_top); - rto_j = call->peer->rto_j; - now =ktime_get_real (); - max_age =ktime_sub (now,jiffies_to_usecs (rto_j)); + max_age =ktime_sub (now,jiffies_to_usecs (call->peer->rto_j));spin_lock_bh (&call->lock);
@@ -213,7 +211,7 @@ static void rxrpc_resend(struct rxrpc_call *call, unsigned long now_j) } resend_at =nsecs_to_jiffies (ktime_to_ns (ktime_sub (now, oldest))); - resend_at += jiffies + rto_j; + resend_at += jiffies +rxrpc_get_rto_backoff (call->peer, retrans);WRITE_ONCE (call->resend_at, resend_at);if (unacked)
net/rxrpc/output.c +1 -1
@@ -468,7 +468,7 @@ done:if (call->peer->rtt_count >1 ) {unsigned long nowj = jiffies, ack_lost_at; - ack_lost_at =rxrpc_get_rto_backoff (call->peer, retrans); + ack_lost_at =rxrpc_get_rto_backoff (call->peer, false); ack_lost_at += nowj;WRITE_ONCE (call->ack_lost_at, ack_lost_at); rxrpc_reduce_call_timer(call, ack_lost_at, nowj,
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 152/200 efi/libstub: arm64: Fix image check alignment at entry
In reply to Greg Kroah-HartmanFrom: Mihai Carabas <[email protected]>
[ Upstream commit e9b7c3a4263bdcfd31bc3d03d48ce0ded7a94635 ]
The kernel is aligned at SEGMENT_SIZE and this is the size populated in the PE headers:
arch/arm64/kernel/efi-header.S: .long SEGMENT_ALIGN // SectionAlignment
EFI_KIMG_ALIGN is defined as: (SEGMENT_ALIGN > THREAD_ALIGN ? SEGMENT_ALIGN :THREAD_ALIGN)
So it depends on THREAD_ALIGN. On newer builds this message started to appear even though the loader is taking into account the PE header (which is stating SEGMENT_ALIGN).
--- drivers/firmware/efi/libstub/arm64-stub.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/firmware/efi/libstub/arm64-stub.c +3 -3
@@ -119,9 +119,9 @@ efi_status_t handle_kernel_image(unsigned long *image_addr,if (image->image_base != _text)efi_err ("FIRMWARE BUG: efi_loaded_image_t::image_base has bogus value\n" ); -if (!IS_ALIGNED ((u64 )_text,EFI_KIMG_ALIGN )) -efi_err ("FIRMWARE BUG: kernel image not aligned on %ldk boundary\n" , -EFI_KIMG_ALIGN >>10 ); +if (!IS_ALIGNED ((u64 )_text,SEGMENT_ALIGN )) +efi_err ("FIRMWARE BUG: kernel image not aligned on %dk boundary\n" , +SEGMENT_ALIGN >>10 ); kernel_size = _edata - _text; kernel_memsize = kernel_size + (_end - _edata);
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 153/200 io_uring: fix bug in slow unregistering of nodes
In reply to Greg Kroah-HartmanFrom: Dylan Yudaken <[email protected]>
[ Upstream commit b36a2050040b2d839bdc044007cdd57101d7f881 ]
In some cases io_rsrc_ref_quiesce will call io_rsrc_node_switch_start, and then immediately flush the delayed work queue &ctx->rsrc_put_work.
However the percpu_ref_put does not immediately destroy the node, it will be called asynchronously via RCU. That ends up with io_rsrc_node_ref_zero only being called after rsrc_put_work has been flushed, and so the process ends up sleeping for 1 second unnecessarily.
This patch executes the put code immediately if we are busy quiescing.
--- fs/io_uring.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
fs/io_uring.c +6 -1
@@ -7761,10 +7761,15 @@ static __cold void io_rsrc_node_ref_zero(struct percpu_ref *ref)struct io_ring_ctx *ctx = node->rsrc_data->ctx;unsigned long flags;bool first_add = false; +unsigned long delay =HZ ;spin_lock_irqsave (&ctx->rsrc_ref_lock, flags); node->done = true; +/* if we are mid-quiesce then do not delay */ +if (node->rsrc_data->quiesce) + delay =0 ; +while (!list_empty (&ctx->rsrc_ref_list)) { node =list_first_entry (&ctx->rsrc_ref_list, struct io_rsrc_node, node);
@@ -7777,7 +7782,7 @@ static __cold void io_rsrc_node_ref_zero(struct percpu_ref *ref)spin_unlock_irqrestore (&ctx->rsrc_ref_lock, flags);if (first_add) -mod_delayed_work (system_wq, &ctx->rsrc_put_work,HZ ); +mod_delayed_work (system_wq, &ctx->rsrc_put_work, delay); }static struct io_rsrc_node *io_rsrc_node_alloc (struct io_ring_ctx *ctx)
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 154/200 block: fix memory leak in disk_register_independent_access_ranges
In reply to Greg Kroah-HartmanFrom: Miaoqian Lin <[email protected]>
[ Upstream commit 83114df32ae779df57e0af99a8ba6c3968b2ba3d ]
kobject_init_and_add() takes reference even when it fails. According to the doc of kobject_init_and_add()
If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object.
Fix this issue by adding kobject_put().
Callback function blk_ia_ranges_sysfs_release() in kobject_put() can handle the pointer "iars" properly.
--- block/blk-ia-ranges.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
block/blk-ia-ranges.c +1 -1
@@ -144,7 +144,7 @@ int disk_register_independent_access_ranges(struct gendisk *disk, &q->kobj, "%s", "independent_access_ranges");if (ret) { q->ia_ranges =NULL ; -kfree (iars); +kobject_put (&iars->kobj);return ret; }
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 155/200 Drivers: hv: balloon: account for vmbus packet header in max_pkt_size
In reply to Greg Kroah-HartmanFrom: Yanming Liu <[email protected]>
[ Upstream commit 96d9d1fa5cd505078534113308ced0aa56d8da58 ]
Commit adae1e931acd ("Drivers: hv: vmbus: Copy packets sent by Hyper-V out of the ring buffer") introduced a notion of maximum packet size in vmbus channel and used that size to initialize a buffer holding all incoming packet along with their vmbus packet header. hv_balloon uses the default maximum packet size VMBUS_DEFAULT_MAX_PKT_SIZE which matches its maximum message size, however vmbus_open expects this size to also include vmbus packet header. This leads to 4096 bytes dm_unballoon_request messages being truncated to 4080 bytes. When the driver tries to read next packet it starts from a wrong read_index, receives garbage and prints a lot of "Unhandled message: type:
<garbage>" in dmesg.
Allocate the buffer with HV_HYP_PAGE_SIZE more bytes to make room for the header.
--- drivers/hv/hv_balloon.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/hv/hv_balloon.c +7 -0
@@ -1660,6 +1660,13 @@ static int balloon_connect_vsp(struct hv_device *dev)unsigned long t;int ret; +/* +* max_pkt_size should be large enough for one vmbus packet header plus +* our receive buffer size. Hyper-V sends messages up to +* HV_HYP_PAGE_SIZE bytes long on balloon channel. +*/ + dev->channel->max_pkt_size =HV_HYP_PAGE_SIZE *2 ; + ret =vmbus_open (dev->channel, dm_ring_size, dm_ring_size,NULL ,0 , balloon_onchannelcallback, dev);if (ret)
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 156/200 hwmon: (lm90) Re-enable interrupts after alert clears
In reply to Greg Kroah-HartmanFrom: Guenter Roeck <[email protected]>
[ Upstream commit bc341a1a98827925082e95db174734fc8bd68af6 ]
If alert handling is broken, interrupts are disabled after an alert and re-enabled after the alert clears. However, if there is an interrupt handler, this does not apply if alerts were originally disabled and enabled when the driver was loaded. In that case, interrupts will stay disabled after an alert was handled though the alert handler even after the alert condition clears. Address the situation by always re-enabling interrupts after the alert condition clears if there is an interrupt handler.
--- drivers/hwmon/lm90.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/hwmon/lm90.c +1 -1
@@ -848,7 +848,7 @@ static int lm90_update_device(struct device *dev)* Re-enable ALERT# output if it was originally enabled and * relevant alarms are all clear */ -if (!(data->config_orig &0x80 ) && +if ((client->irq || !(data->config_orig &0x80 )) && !(data->alarms & data->alert_alarms)) {if (data->config &0x80 ) {dev_dbg (&client->dev,"Re-enabling ALERT#\n" );
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 157/200 hwmon: (lm90) Mark alert as broken for MAX6654
In reply to Greg Kroah-HartmanFrom: Guenter Roeck <[email protected]>
[ Upstream commit a53fff96f35763d132a36c620b183fdf11022d7a ]
Experiments with MAX6654 show that its alert function is broken, similar to other chips supported by the lm90 driver. Mark it accordingly.
--- drivers/hwmon/lm90.c | 1 + 1 file changed, 1 insertion(+)
drivers/hwmon/lm90.c +1 -0
@@ -400,6 +400,7 @@ static const struct lm90_params lm90_params[] = { .reg_local_ext = MAX6657_REG_R_LOCAL_TEMPL, }, [max6654] = { + .flags = LM90_HAVE_BROKEN_ALERT, .alert_alarms = 0x7c, .max_convrate = 7, .reg_local_ext = MAX6657_REG_R_LOCAL_TEMPL,
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 158/200 hwmon: (lm90) Fix sysfs and udev notifications
In reply to Greg Kroah-HartmanFrom: Guenter Roeck <[email protected]>
[ Upstream commit d379880d9adb9f1ada3f1266aa49ea2561328e08 ]
sysfs and udev notifications need to be sent to the _alarm attributes, not to the value attributes.
--- drivers/hwmon/lm90.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
drivers/hwmon/lm90.c +6 -6
@@ -1808,22 +1808,22 @@ static bool lm90_is_tripped(struct i2c_client *client, u16 *status)if (st &LM90_STATUS_LLOW )hwmon_notify_event (data->hwmon_dev, hwmon_temp, - hwmon_temp_min,0 ); + hwmon_temp_min_alarm,0 );if (st &LM90_STATUS_RLOW )hwmon_notify_event (data->hwmon_dev, hwmon_temp, - hwmon_temp_min,1 ); + hwmon_temp_min_alarm,1 );if (st2 &MAX6696_STATUS2_R2LOW )hwmon_notify_event (data->hwmon_dev, hwmon_temp, - hwmon_temp_min,2 ); + hwmon_temp_min_alarm,2 );if (st &LM90_STATUS_LHIGH )hwmon_notify_event (data->hwmon_dev, hwmon_temp, - hwmon_temp_max,0 ); + hwmon_temp_max_alarm,0 );if (st &LM90_STATUS_RHIGH )hwmon_notify_event (data->hwmon_dev, hwmon_temp, - hwmon_temp_max,1 ); + hwmon_temp_max_alarm,1 );if (st2 &MAX6696_STATUS2_R2HIGH )hwmon_notify_event (data->hwmon_dev, hwmon_temp, - hwmon_temp_max,2 ); + hwmon_temp_max_alarm,2 );return true; }
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 159/200 hwmon: (adt7470) Prevent divide by zero in adt7470_fan_write()
In reply to Greg Kroah-HartmanFrom: Dan Carpenter <[email protected]>
[ Upstream commit c1ec0cabc36718efc7fe8b4157d41b82d08ec1d2 ]
The "val" variable is controlled by the user and comes from hwmon_attr_store(). The FAN_RPM_TO_PERIOD() macro divides by "val" so a zero will crash the system. Check for that and return -EINVAL. Negatives are also invalid so return -EINVAL for those too.
--- drivers/hwmon/adt7470.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/hwmon/adt7470.c +3 -0
@@ -662,6 +662,9 @@ static int adt7470_fan_write(struct device *dev, u32 attr, int channel, long valstruct adt7470_data *data =dev_get_drvdata (dev);int err; +if (val <=0 ) +return -EINVAL ; + val =FAN_RPM_TO_PERIOD (val); val =clamp_val (val,1 ,65534 );
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 160/200 powerpc/perf: Fix power_pmu_disable to call clear_pmi_irq_pending only if PMI is pending
In reply to Greg Kroah-HartmanFrom: Athira Rajeev <[email protected]>
[ Upstream commit fb6433b48a178d4672cb26632454ee0b21056eaa ]
Running selftest with CONFIG_PPC_IRQ_SOFT_MASK_DEBUG enabled in kernel triggered below warning:
[ 172.851380] ------------[ cut here ]------------ [ 172.851391] WARNING: CPU: 8 PID: 2901 at arch/powerpc/include/asm/hw_irq.h:246 power_pmu_disable+0x270/0x280 [ 172.851402] Modules linked in: dm_mod bonding nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables rfkill nfnetlink sunrpc xfs libcrc32c pseries_rng xts vmx_crypto uio_pdrv_genirq uio sch_fq_codel ip_tables ext4 mbcache jbd2 sd_mod t10_pi sg ibmvscsi ibmveth scsi_transport_srp fuse [ 172.851442] CPU: 8 PID: 2901 Comm: lost_exception_ Not tainted 5.16.0-rc5-03218-g798527287598 #2 [ 172.851451] NIP: c00000000013d600 LR: c00000000013d5a4 CTR: c00000000013b180 [ 172.851458] REGS: c000000017687860 TRAP: 0700 Not tainted (5.16.0-rc5-03218-g798527287598) [ 172.851465] MSR: 8000000000029033 <SF,EE,ME,IR,DR,RI,LE> CR: 48004884 XER: 20040000 [ 172.851482] CFAR: c00000000013d5b4 IRQMASK: 1 [ 172.851482] GPR00: c00000000013d5a4 c000000017687b00 c000000002a10600 0000000000000004 [ 172.851482] GPR04: 0000000082004000 c0000008ba08f0a8 0000000000000000 00000008b7ed0000 [ 172.851482] GPR08: 00000000446194f6 0000000000008000 c00000000013b118 c000000000d58e68 [ 172.851482] GPR12: c00000000013d390 c00000001ec54a80 0000000000000000 0000000000000000 [ 172.851482] GPR16: 0000000000000000 0000000000000000 c000000015d5c708 c0000000025396d0 [ 172.851482] GPR20: 0000000000000000 0000000000000000 c00000000a3bbf40 0000000000000003 [ 172.851482] GPR24: 0000000000000000 c0000008ba097400 c0000000161e0d00 c00000000a3bb600 [ 172.851482] GPR28: c000000015d5c700 0000000000000001 0000000082384090 c0000008ba0020d8 [ 172.851549] NIP [c00000000013d600] power_pmu_disable+0x270/0x280 [ 172.851557] LR [c00000000013d5a4] power_pmu_disable+0x214/0x280 [ 172.851565] Call Trace: [ 172.851568] [c000000017687b00] [c00000000013d5a4] power_pmu_disable+0x214/0x280 (unreliable) [ 172.851579] [c000000017687b40] [c0000000003403ac] perf_pmu_disable+0x4c/0x60 [ 172.851588] [c000000017687b60] [c0000000003445e4] __perf_event_task_sched_out+0x1d4/0x660 [ 172.851596] [c000000017687c50] [c000000000d1175c] __schedule+0xbcc/0x12a0 [ 172.851602] [c000000017687d60] [c000000000d11ea8] schedule+0x78/0x140 [ 172.851608] [c000000017687d90] [c0000000001a8080] sys_sched_yield+0x20/0x40 [ 172.851615] [c000000017687db0] [c0000000000334dc] system_call_exception+0x18c/0x380 [ 172.851622] [c000000017687e10] [c00000000000c74c] system_call_common+0xec/0x268
The warning indicates that MSR_EE being set(interrupt enabled) when there was an overflown PMC detected. This could happen in power_pmu_disable since it runs under interrupt soft disable condition ( local_irq_save ) and not with interrupts hard disabled. commit 2c9ac51b850d ("powerpc/perf: Fix PMU callbacks to clear pending PMI before resetting an overflown PMC") intended to clear PMI pending bit in Paca when disabling the PMU. It could happen that PMC gets overflown while code is in power_pmu_disable callback function. Hence add a check to see if PMI pending bit is set in Paca before clearing it via clear_pmi_pending.
--- arch/powerpc/perf/core-book3s.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-)
arch/powerpc/perf/core-book3s.c +14 -3
@@ -1326,9 +1326,20 @@ static void power_pmu_disable(struct pmu *pmu)* Otherwise provide a warning if there is PMI pending, but * no counter is found overflown. */ -if (any_pmc_overflown (cpuhw)) -clear_pmi_irq_pending (); -else +if (any_pmc_overflown (cpuhw)) { +/* +* Since power_pmu_disable runs under local_irq_save, it +* could happen that code hits a PMC overflow without PMI +* pending in paca. Hence only clear PMI pending if it was +* set. +* +* If a PMI is pending, then MSR[EE] must be disabled (because +* the masked PMI handler disabling EE). So it is safe to +* call clear_pmi_irq_pending(). +*/ +if (pmi_irq_pending ()) +clear_pmi_irq_pending (); + }else WARN_ON (pmi_irq_pending ()); val = mmcra = cpuhw->mmcr.mmcra;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 161/200 ipv4: fix ip option filtering for locally generated fragments
In reply to Greg Kroah-HartmanFrom: Jakub Kicinski <[email protected]>
[ Upstream commit 27a8caa59babb96c5890569e131bc0eb6d45daee ]
During IP fragmentation we sanitize IP options. This means overwriting options which should not be copied with NOPs. Only the first fragment has the original, full options.
ip_fraglist_prepare() copies the IP header and options from previous fragment to the next one. Commit 19c3401a917b ("net: ipv4: place control buffer handling away from fragmentation iterators") moved sanitizing options before ip_fraglist_prepare() which means options are sanitized and then overwritten again with the old values.
Fixing this is not enough, however, nor did the sanitization work prior to aforementioned commit.
ip_options_fragment() (which does the sanitization) uses ipcb->opt.optlen for the length of the options. ipcb->opt of fragments is not populated (it's 0), only the head skb has the state properly built. So even when called at the right time ip_options_fragment() does nothing. This seems to date back all the way to v2.5.44 when the fast path for pre-fragmented skbs had been introduced. Prior to that ip_options_build() would have been called for every fragment (in fact ever since v2.5.44 the fragmentation handing in ip_options_build() has been dead code, I'll clean it up in -next).
In the original patch (see Link) caixf mentions fixing the handling for fragments other than the second one, but I'm not sure how _any_ fragment could have had their options sanitized with the code as it stood.
Tested with python (MTU on lo lowered to 1000 to force fragmentation):
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) s.setsockopt(socket.IPPROTO_IP, socket.IP_OPTIONS,
bytearray([7,4,5,192, 20|0x80,4,1,0]))
s.sendto(b'1'*2000, ('127.0.0.1', 1234))
Before:
IP (tos 0x0, ttl 64, id 1053, offset 0, flags [+], proto UDP (17), length 996, options (RR [bad length 4] [bad ptr 5] 192.148.4.1,,RA value 256))
localhost.36500 > localhost.search-agent: UDP, length 2000
IP (tos 0x0, ttl 64, id 1053, offset 968, flags [+], proto UDP (17), length 996, options (RR [bad length 4] [bad ptr 5] 192.148.4.1,,RA value 256))
localhost > localhost: udp
IP (tos 0x0, ttl 64, id 1053, offset 1936, flags [none], proto UDP (17), length 100, options (RR [bad length 4] [bad ptr 5] 192.148.4.1,,RA value 256))
localhost > localhost: udp
After:
IP (tos 0x0, ttl 96, id 42549, offset 0, flags [+], proto UDP (17), length 996, options (RR [bad length 4] [bad ptr 5] 192.148.4.1,,RA value 256))
localhost.51607 > localhost.search-agent: UDP, bad length 2000 > 960
IP (tos 0x0, ttl 96, id 42549, offset 968, flags [+], proto UDP (17), length 996, options (NOP,NOP,NOP,NOP,RA value 256))
localhost > localhost: udp
IP (tos 0x0, ttl 96, id 42549, offset 1936, flags [none], proto UDP (17), length 100, options (NOP,NOP,NOP,NOP,RA value 256))
localhost > localhost: udp
RA (20 | 0x80) is now copied as expected, RR (7) is "NOPed out".
--- net/ipv4/ip_output.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-)
net/ipv4/ip_output.c +12 -3
@@ -826,15 +826,24 @@ int ip_do_fragment(struct net *net, struct sock *sk, struct sk_buff *skb,/* Everything is OK. Generate! */ ip_fraglist_init (skb, iph, hlen, &iter); -if (iter.frag) -ip_options_fragment (iter.frag); -for (;;) {/* Prepare header of the next frame, * before previous one went down. */ if (iter.frag) { +bool first_frag = (iter.offset ==0 ); +IPCB (iter.frag)->flags =IPCB (skb)->flags;ip_fraglist_prepare (skb, &iter); +if (first_frag &&IPCB (skb)->opt.optlen) { +/* ipcb->opt is not populated for frags +* coming from __ip_make_skb(), +* ip_options_fragment() needs optlen +*/ +IPCB (iter.frag)->opt.optlen = +IPCB (skb)->opt.optlen; +ip_options_fragment (iter.frag); +ip_send_check (iter.iph); + } } skb->tstamp = tstamp;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 162/200 ibmvnic: Allow extra failures before disabling
In reply to Greg Kroah-HartmanFrom: Sukadev Bhattiprolu <[email protected]>
[ Upstream commit db9f0e8bf79e6da7068b5818fea0ffd9d0d4b4da ]
If auto-priority-failover (APF) is enabled and there are at least two backing devices of different priorities, some resets like fail-over, change-param etc can cause at least two back to back failovers. (Failover from high priority backing device to lower priority one and then back to the higher priority one if that is still functional).
Depending on the timimg of the two failovers it is possible to trigger a "hard" reset and for the hard reset to fail due to failovers. When this occurs, the driver assumes that the network is unstable and disables the VNIC for a 60-second "settling time". This in turn can cause the ethtool command to fail with "No such device" while the vnic automatically recovers a little while later.
Given that it's possible to have two back to back failures, allow for extra failures before disabling the vnic for the settling time.
--- drivers/net/ethernet/ibm/ibmvnic.c | 21 +++++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-)
drivers/net/ethernet/ibm/ibmvnic.c +17 -4
@@ -2598,6 +2598,7 @@ static void __ibmvnic_reset(struct work_struct *work)struct ibmvnic_rwi *rwi;unsigned long flags;u32 reset_state; +int num_fails =0 ;int rc =0 ; adapter = container_of(work, struct ibmvnic_adapter, ibmvnic_reset);
@@ -2651,11 +2652,23 @@ static void __ibmvnic_reset(struct work_struct *work) rc =do_hard_reset (adapter, rwi, reset_state);rtnl_unlock (); } -if (rc) { -/* give backing device time to settle down */ +if (rc) + num_fails++; +else + num_fails =0 ; + +/* If auto-priority-failover is enabled we can get +* back to back failovers during resets, resulting +* in at least two failed resets (from high-priority +* backing device to low-priority one and then back) +* If resets continue to fail beyond that, give the +* adapter some time to settle down before retrying. +*/ +if (num_fails >=3 ) {netdev_dbg (adapter->netdev, -"[S:%s] Hard reset failed, waiting 60 secs\n" , -adapter_state_to_string (adapter->state)); +"[S:%s] Hard reset failed %d times, waiting 60 secs\n" , +adapter_state_to_string (adapter->state), + num_fails);set_current_state (TASK_UNINTERRUPTIBLE );schedule_timeout (60 *HZ ); }
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 163/200 ibmvnic: init ->running_cap_crqs early
In reply to Greg Kroah-HartmanFrom: Sukadev Bhattiprolu <[email protected]>
[ Upstream commit 151b6a5c06b678687f64f2d9a99fd04d5cd32b72 ]
We use ->running_cap_crqs to determine when the ibmvnic_tasklet() should send out the next protocol message type. i.e when we get back responses to all our QUERY_CAPABILITY CRQs we send out REQUEST_CAPABILITY crqs. Similiary, when we get responses to all the REQUEST_CAPABILITY crqs, we send out the QUERY_IP_OFFLOAD CRQ.
We currently increment ->running_cap_crqs as we send out each CRQ and have the ibmvnic_tasklet() send out the next message type, when this running_cap_crqs count drops to 0.
This assumes that all the CRQs of the current type were sent out before the count drops to 0. However it is possible that we send out say 6 CRQs, get preempted and receive all the 6 responses before we send out the remaining CRQs. This can result in ->running_cap_crqs count dropping to zero before all messages of the current type were sent and we end up sending the next protocol message too early.
Instead initialize the ->running_cap_crqs upfront so the tasklet will only send the next protocol message after all responses are received.
Use the cap_reqs local variable to also detect any discrepancy (either now or in future) in the number of capability requests we actually send.
Currently only send_query_cap() is affected by this behavior (of sending next message early) since it is called from the worker thread (during reset) and from application thread (during ->ndo_open()) and they can be preempted. send_request_cap() is only called from the tasklet which processes CRQ responses sequentially, is not be affected. But to maintain the existing symmtery with send_query_capability() we update send_request_capability() also.
--- drivers/net/ethernet/ibm/ibmvnic.c | 106 +++++++++++++++++++---------- 1 file changed, 71 insertions(+), 35 deletions(-)
drivers/net/ethernet/ibm/ibmvnic.c +71 -35
@@ -3849,11 +3849,25 @@ static void send_request_cap(struct ibmvnic_adapter *adapter, int retry)struct device *dev = &adapter->vdev->dev;union ibmvnic_crq crq;int max_entries; +int cap_reqs; + +/* We send out 6 or 7 REQUEST_CAPABILITY CRQs below (depending on +* the PROMISC flag). Initialize this count upfront. When the tasklet +* receives a response to all of these, it will send the next protocol +* message (QUERY_IP_OFFLOAD). +*/ +if (!(adapter->netdev->flags &IFF_PROMISC ) || + adapter->promisc_supported) + cap_reqs =7 ; +else + cap_reqs =6 ;if (!retry) {/* Sub-CRQ entries are 32 byte long */ int entries_page =4 *PAGE_SIZE / (sizeof (u64) *4 ); +atomic_set (&adapter->running_cap_crqs, cap_reqs); +if (adapter->min_tx_entries_per_subcrq > entries_page || adapter->min_rx_add_entries_per_subcrq > entries_page) {dev_err (dev,"Fatal, invalid entries per sub-crq\n" );
@@ -3914,44 +3928,45 @@ static void send_request_cap(struct ibmvnic_adapter *adapter, int retry) adapter->opt_rx_comp_queues; adapter->req_rx_add_queues = adapter->max_rx_add_queues; + }else { +atomic_add (cap_reqs, &adapter->running_cap_crqs); } -memset (&crq,0 ,sizeof (crq)); crq.request_capability.first =IBMVNIC_CRQ_CMD ; crq.request_capability.cmd =REQUEST_CAPABILITY ; crq.request_capability.capability =cpu_to_be16 (REQ_TX_QUEUES ); crq.request_capability.number =cpu_to_be64 (adapter->req_tx_queues); -atomic_inc (&adapter->running_cap_crqs); + cap_reqs--;ibmvnic_send_crq (adapter, &crq); crq.request_capability.capability =cpu_to_be16 (REQ_RX_QUEUES ); crq.request_capability.number =cpu_to_be64 (adapter->req_rx_queues); -atomic_inc (&adapter->running_cap_crqs); + cap_reqs--;ibmvnic_send_crq (adapter, &crq); crq.request_capability.capability =cpu_to_be16 (REQ_RX_ADD_QUEUES ); crq.request_capability.number =cpu_to_be64 (adapter->req_rx_add_queues); -atomic_inc (&adapter->running_cap_crqs); + cap_reqs--;ibmvnic_send_crq (adapter, &crq); crq.request_capability.capability =cpu_to_be16 (REQ_TX_ENTRIES_PER_SUBCRQ ); crq.request_capability.number =cpu_to_be64 (adapter->req_tx_entries_per_subcrq); -atomic_inc (&adapter->running_cap_crqs); + cap_reqs--;ibmvnic_send_crq (adapter, &crq); crq.request_capability.capability =cpu_to_be16 (REQ_RX_ADD_ENTRIES_PER_SUBCRQ ); crq.request_capability.number =cpu_to_be64 (adapter->req_rx_add_entries_per_subcrq); -atomic_inc (&adapter->running_cap_crqs); + cap_reqs--;ibmvnic_send_crq (adapter, &crq); crq.request_capability.capability =cpu_to_be16 (REQ_MTU ); crq.request_capability.number =cpu_to_be64 (adapter->req_mtu); -atomic_inc (&adapter->running_cap_crqs); + cap_reqs--;ibmvnic_send_crq (adapter, &crq);if (adapter->netdev->flags &IFF_PROMISC ) {
@@ -3959,16 +3974,21 @@ static void send_request_cap(struct ibmvnic_adapter *adapter, int retry) crq.request_capability.capability =cpu_to_be16 (PROMISC_REQUESTED ); crq.request_capability.number =cpu_to_be64 (1 ); -atomic_inc (&adapter->running_cap_crqs); + cap_reqs--;ibmvnic_send_crq (adapter, &crq); } }else { crq.request_capability.capability =cpu_to_be16 (PROMISC_REQUESTED ); crq.request_capability.number =cpu_to_be64 (0 ); -atomic_inc (&adapter->running_cap_crqs); + cap_reqs--;ibmvnic_send_crq (adapter, &crq); } + +/* Keep at end to catch any discrepancy between expected and actual +* CRQs sent. +*/ +WARN_ON (cap_reqs !=0 ); } static int pending_scrq(struct ibmvnic_adapter *adapter,
@@ -4362,118 +4382,132 @@ static void send_query_map(struct ibmvnic_adapter *adapter)static void send_query_cap (struct ibmvnic_adapter *adapter) {union ibmvnic_crq crq; +int cap_reqs; + +/* We send out 25 QUERY_CAPABILITY CRQs below. Initialize this count +* upfront. When the tasklet receives a response to all of these, it +* can send out the next protocol messaage (REQUEST_CAPABILITY). +*/ + cap_reqs =25 ; + +atomic_set (&adapter->running_cap_crqs, cap_reqs); -atomic_set (&adapter->running_cap_crqs,0 );memset (&crq,0 ,sizeof (crq)); crq.query_capability.first =IBMVNIC_CRQ_CMD ; crq.query_capability.cmd =QUERY_CAPABILITY ; crq.query_capability.capability =cpu_to_be16 (MIN_TX_QUEUES ); -atomic_inc (&adapter->running_cap_crqs);ibmvnic_send_crq (adapter, &crq); + cap_reqs--; crq.query_capability.capability =cpu_to_be16 (MIN_RX_QUEUES ); -atomic_inc (&adapter->running_cap_crqs);ibmvnic_send_crq (adapter, &crq); + cap_reqs--; crq.query_capability.capability =cpu_to_be16 (MIN_RX_ADD_QUEUES ); -atomic_inc (&adapter->running_cap_crqs);ibmvnic_send_crq (adapter, &crq); + cap_reqs--; crq.query_capability.capability =cpu_to_be16 (MAX_TX_QUEUES ); -atomic_inc (&adapter->running_cap_crqs);ibmvnic_send_crq (adapter, &crq); + cap_reqs--; crq.query_capability.capability =cpu_to_be16 (MAX_RX_QUEUES ); -atomic_inc (&adapter->running_cap_crqs);ibmvnic_send_crq (adapter, &crq); + cap_reqs--; crq.query_capability.capability =cpu_to_be16 (MAX_RX_ADD_QUEUES ); -atomic_inc (&adapter->running_cap_crqs);ibmvnic_send_crq (adapter, &crq); + cap_reqs--; crq.query_capability.capability =cpu_to_be16 (MIN_TX_ENTRIES_PER_SUBCRQ ); -atomic_inc (&adapter->running_cap_crqs);ibmvnic_send_crq (adapter, &crq); + cap_reqs--; crq.query_capability.capability =cpu_to_be16 (MIN_RX_ADD_ENTRIES_PER_SUBCRQ ); -atomic_inc (&adapter->running_cap_crqs);ibmvnic_send_crq (adapter, &crq); + cap_reqs--; crq.query_capability.capability =cpu_to_be16 (MAX_TX_ENTRIES_PER_SUBCRQ ); -atomic_inc (&adapter->running_cap_crqs);ibmvnic_send_crq (adapter, &crq); + cap_reqs--; crq.query_capability.capability =cpu_to_be16 (MAX_RX_ADD_ENTRIES_PER_SUBCRQ ); -atomic_inc (&adapter->running_cap_crqs);ibmvnic_send_crq (adapter, &crq); + cap_reqs--; crq.query_capability.capability =cpu_to_be16 (TCP_IP_OFFLOAD ); -atomic_inc (&adapter->running_cap_crqs);ibmvnic_send_crq (adapter, &crq); + cap_reqs--; crq.query_capability.capability =cpu_to_be16 (PROMISC_SUPPORTED ); -atomic_inc (&adapter->running_cap_crqs);ibmvnic_send_crq (adapter, &crq); + cap_reqs--; crq.query_capability.capability =cpu_to_be16 (MIN_MTU ); -atomic_inc (&adapter->running_cap_crqs);ibmvnic_send_crq (adapter, &crq); + cap_reqs--; crq.query_capability.capability =cpu_to_be16 (MAX_MTU ); -atomic_inc (&adapter->running_cap_crqs);ibmvnic_send_crq (adapter, &crq); + cap_reqs--; crq.query_capability.capability =cpu_to_be16 (MAX_MULTICAST_FILTERS ); -atomic_inc (&adapter->running_cap_crqs);ibmvnic_send_crq (adapter, &crq); + cap_reqs--; crq.query_capability.capability =cpu_to_be16 (VLAN_HEADER_INSERTION ); -atomic_inc (&adapter->running_cap_crqs);ibmvnic_send_crq (adapter, &crq); + cap_reqs--; crq.query_capability.capability =cpu_to_be16 (RX_VLAN_HEADER_INSERTION ); -atomic_inc (&adapter->running_cap_crqs);ibmvnic_send_crq (adapter, &crq); + cap_reqs--; crq.query_capability.capability =cpu_to_be16 (MAX_TX_SG_ENTRIES ); -atomic_inc (&adapter->running_cap_crqs);ibmvnic_send_crq (adapter, &crq); + cap_reqs--; crq.query_capability.capability =cpu_to_be16 (RX_SG_SUPPORTED ); -atomic_inc (&adapter->running_cap_crqs);ibmvnic_send_crq (adapter, &crq); + cap_reqs--; crq.query_capability.capability =cpu_to_be16 (OPT_TX_COMP_SUB_QUEUES ); -atomic_inc (&adapter->running_cap_crqs);ibmvnic_send_crq (adapter, &crq); + cap_reqs--; crq.query_capability.capability =cpu_to_be16 (OPT_RX_COMP_QUEUES ); -atomic_inc (&adapter->running_cap_crqs);ibmvnic_send_crq (adapter, &crq); + cap_reqs--; crq.query_capability.capability =cpu_to_be16 (OPT_RX_BUFADD_Q_PER_RX_COMP_Q ); -atomic_inc (&adapter->running_cap_crqs);ibmvnic_send_crq (adapter, &crq); + cap_reqs--; crq.query_capability.capability =cpu_to_be16 (OPT_TX_ENTRIES_PER_SUBCRQ ); -atomic_inc (&adapter->running_cap_crqs);ibmvnic_send_crq (adapter, &crq); + cap_reqs--; crq.query_capability.capability =cpu_to_be16 (OPT_RXBA_ENTRIES_PER_SUBCRQ ); -atomic_inc (&adapter->running_cap_crqs);ibmvnic_send_crq (adapter, &crq); + cap_reqs--; crq.query_capability.capability =cpu_to_be16 (TX_RX_DESC_REQ ); -atomic_inc (&adapter->running_cap_crqs); +ibmvnic_send_crq (adapter, &crq); + cap_reqs--; + +/* Keep at end to catch any discrepancy between expected and actual +* CRQs sent. +*/ +WARN_ON (cap_reqs !=0 ); }static void send_query_ip_offload (struct ibmvnic_adapter *adapter)
@@ -4777,6 +4811,8 @@ static void handle_request_cap_rsp(union ibmvnic_crq *crq,char *name;atomic_dec (&adapter->running_cap_crqs); +netdev_dbg (adapter->netdev,"Outstanding request-caps: %d\n" , +atomic_read (&adapter->running_cap_crqs));switch (be16_to_cpu (crq->request_capability_rsp.capability)) {case REQ_TX_QUEUES : req_value = &adapter->req_tx_queues;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 164/200 ibmvnic: dont spin in tasklet
In reply to Greg Kroah-HartmanFrom: Sukadev Bhattiprolu <[email protected]>
[ Upstream commit 48079e7fdd0269d66b1d7d66ae88bd03162464ad ]
ibmvnic_tasklet() continuously spins waiting for responses to all capability requests. It does this to avoid encountering an error during initialization of the vnic. However if there is a bug in the VIOS and we do not receive a response to one or more queries the tasklet ends up spinning continuously leading to hard lock ups.
If we fail to receive a message from the VIOS it is reasonable to timeout the login attempt rather than spin indefinitely in the tasklet.
--- drivers/net/ethernet/ibm/ibmvnic.c | 6 ------ 1 file changed, 6 deletions(-)
drivers/net/ethernet/ibm/ibmvnic.c +0 -6
@@ -5491,12 +5491,6 @@ static void ibmvnic_tasklet(struct tasklet_struct *t)ibmvnic_handle_crq (crq, adapter); crq->generic.first =0 ; } - -/* remain in tasklet until all -* capabilities responses are received -*/ -if (!adapter->wait_capability) - done = true; }/* if capabilities CRQ's were sent in this tasklet, the following * tasklet must wait until all responses are received
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 165/200 net/smc: Transitional solution for clcsock race issue
In reply to Greg Kroah-HartmanFrom: Wen Gu <[email protected]>
[ Upstream commit c0bf3d8a943b6f2e912b7c1de03e2ef28e76f760 ]
We encountered a crash in smc_setsockopt() and it is caused by accessing smc->clcsock after clcsock was released.
BUG: kernel NULL pointer dereference, address: 0000000000000020 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 50309 Comm: nginx Kdump: loaded Tainted: G E 5.16.0-rc4+ #53 RIP: 0010:smc_setsockopt+0x59/0x280 [smc] Call Trace: <TASK> __sys_setsockopt+0xfc/0x190 __x64_sys_setsockopt+0x20/0x30 do_syscall_64+0x34/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f16ba83918e </TASK>
This patch tries to fix it by holding clcsock_release_lock and checking whether clcsock has already been released before access.
In case that a crash of the same reason happens in smc_getsockopt() or smc_switch_to_fallback(), this patch also checkes smc->clcsock in them too. And the caller of smc_switch_to_fallback() will identify whether fallback succeeds according to the return value.
--- net/smc/af_smc.c | 63 +++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 51 insertions(+), 12 deletions(-)
net/smc/af_smc.c +51 -12
@@ -566,12 +566,17 @@ static void smc_stat_fallback(struct smc_sock *smc)mutex_unlock (&net->smc.mutex_fback_rsn); } -static void smc_switch_to_fallback (struct smc_sock *smc,int reason_code) +static int smc_switch_to_fallback (struct smc_sock *smc,int reason_code) {wait_queue_head_t *smc_wait =sk_sleep (&smc->sk); -wait_queue_head_t *clc_wait =sk_sleep (smc->clcsock->sk); +wait_queue_head_t *clc_wait;unsigned long flags; +mutex_lock (&smc->clcsock_release_lock); +if (!smc->clcsock) { +mutex_unlock (&smc->clcsock_release_lock); +return -EBADF ; + } smc->use_fallback = true; smc->fallback_rsn = reason_code;smc_stat_fallback (smc);
@@ -586,18 +591,30 @@ static void smc_switch_to_fallback(struct smc_sock *smc, int reason_code)* smc socket->wq, which should be removed * to clcsocket->wq during the fallback. */ + clc_wait =sk_sleep (smc->clcsock->sk);spin_lock_irqsave (&smc_wait->lock, flags);spin_lock_nested (&clc_wait->lock,SINGLE_DEPTH_NESTING );list_splice_init (&smc_wait->head, &clc_wait->head);spin_unlock (&clc_wait->lock);spin_unlock_irqrestore (&smc_wait->lock, flags); } +mutex_unlock (&smc->clcsock_release_lock); +return 0 ; }/* fall back during connect */ static int smc_connect_fallback (struct smc_sock *smc,int reason_code) { -smc_switch_to_fallback (smc, reason_code); +struct net *net =sock_net (&smc->sk); +int rc =0 ; + + rc =smc_switch_to_fallback (smc, reason_code); +if (rc) {/* fallback fails */ +this_cpu_inc (net->smc.smc_stats->clnt_hshake_err_cnt); +if (smc->sk.sk_state ==SMC_INIT ) +sock_put (&smc->sk);/* passive closing */ +return rc; + }smc_copy_sock_settings_to_clc (smc); smc->connect_nonblock =0 ;if (smc->sk.sk_state ==SMC_INIT )
@@ -1514,11 +1531,12 @@ static void smc_listen_decline(struct smc_sock *new_smc, int reason_code, {/* RDMA setup failed, switch back to TCP */ smc_conn_abort (new_smc, local_first); -if (reason_code <0 ) {/* error, no fallback possible */ +if (reason_code <0 || +smc_switch_to_fallback (new_smc, reason_code)) { +/* error, no fallback possible */ smc_listen_out_err (new_smc);return ; } -smc_switch_to_fallback (new_smc, reason_code);if (reason_code && reason_code !=SMC_CLC_DECL_PEERDECL ) {if (smc_clc_send_decline (new_smc, reason_code, version) <0 ) {smc_listen_out_err (new_smc);
@@ -1960,8 +1978,11 @@ static void smc_listen_work(struct work_struct *work)/* check if peer is smc capable */ if (!tcp_sk (newclcsock->sk)->syn_smc) { -smc_switch_to_fallback (new_smc,SMC_CLC_DECL_PEERNOSMC ); -smc_listen_out_connected (new_smc); + rc =smc_switch_to_fallback (new_smc,SMC_CLC_DECL_PEERNOSMC ); +if (rc) +smc_listen_out_err (new_smc); +else +smc_listen_out_connected (new_smc);return ; }
@@ -2250,7 +2271,9 @@ static int smc_sendmsg(struct socket *sock, struct msghdr *msg, size_t len)if (msg->msg_flags &MSG_FASTOPEN ) {if (sk->sk_state ==SMC_INIT && !smc->connect_nonblock) { -smc_switch_to_fallback (smc,SMC_CLC_DECL_OPTUNSUPP ); + rc =smc_switch_to_fallback (smc,SMC_CLC_DECL_OPTUNSUPP ); +if (rc) + goto out; }else { rc = -EINVAL ; goto out;
@@ -2443,6 +2466,11 @@ static int smc_setsockopt(struct socket *sock, int level, int optname,/* generic setsockopts reaching us here always apply to the * CLC socket */ +mutex_lock (&smc->clcsock_release_lock); +if (!smc->clcsock) { +mutex_unlock (&smc->clcsock_release_lock); +return -EBADF ; + }if (unlikely (!smc->clcsock->ops->setsockopt)) rc = -EOPNOTSUPP ;else
@@ -2452,6 +2480,7 @@ static int smc_setsockopt(struct socket *sock, int level, int optname, sk->sk_err = smc->clcsock->sk->sk_err;sk_error_report (sk); } +mutex_unlock (&smc->clcsock_release_lock);if (optlen <sizeof (int ))return -EINVAL ;
@@ -2468,7 +2497,7 @@ static int smc_setsockopt(struct socket *sock, int level, int optname,case TCP_FASTOPEN_NO_COOKIE :/* option not supported by SMC */ if (sk->sk_state ==SMC_INIT && !smc->connect_nonblock) { -smc_switch_to_fallback (smc,SMC_CLC_DECL_OPTUNSUPP ); + rc =smc_switch_to_fallback (smc,SMC_CLC_DECL_OPTUNSUPP ); }else { rc = -EINVAL ; }
@@ -2511,13 +2540,23 @@ static int smc_getsockopt(struct socket *sock, int level, int optname, char __user *optval, int __user *optlen) { struct smc_sock *smc; +int rc; smc =smc_sk (sock->sk); +mutex_lock (&smc->clcsock_release_lock); +if (!smc->clcsock) { +mutex_unlock (&smc->clcsock_release_lock); +return -EBADF ; + }/* socket options apply to the CLC socket */ -if (unlikely (!smc->clcsock->ops->getsockopt)) +if (unlikely (!smc->clcsock->ops->getsockopt)) { +mutex_unlock (&smc->clcsock_release_lock);return -EOPNOTSUPP ; -return smc->clcsock->ops->getsockopt (smc->clcsock, level, optname, - optval, optlen); + } + rc = smc->clcsock->ops->getsockopt (smc->clcsock, level, optname, + optval, optlen); +mutex_unlock (&smc->clcsock_release_lock); +return rc; } static int smc_ioctl(struct socket *sock, unsigned int cmd,
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 166/200 video: hyperv_fb: Fix validation of screen resolution
In reply to Greg Kroah-HartmanFrom: Michael Kelley <[email protected]>
[ Upstream commit 9ff5549b1d1d3c3a9d71220d44bd246586160f1d ]
In the WIN10 version of the Synthetic Video protocol with Hyper-V, Hyper-V reports a list of supported resolutions as part of the protocol negotiation. The driver calculates the maximum width and height from the list of resolutions, and uses those maximums to validate any screen resolution specified in the video= option on the kernel boot line.
This method of validation is incorrect. For example, the list of supported resolutions could contain 1600x1200 and 1920x1080, both of which fit in an 8 Mbyte frame buffer. But calculating the max width and height yields 1920 and 1200, and 1920x1200 resolution does not fit in an 8 Mbyte frame buffer. Unfortunately, this resolution is accepted, causing a kernel fault when the driver accesses memory outside the frame buffer.
Instead, validate the specified screen resolution by calculating its size, and comparing against the frame buffer size. Delete the code for calculating the max width and height from the list of resolutions, since these max values have no use. Also add the frame buffer size to the info message to aid in understanding why a resolution might be rejected.
--- drivers/video/fbdev/hyperv_fb.c | 16 +++------------- 1 file changed, 3 insertions(+), 13 deletions(-)
drivers/video/fbdev/hyperv_fb.c +3 -13
@@ -287,8 +287,6 @@ struct hvfb_par {static uint screen_width =HVFB_WIDTH ;static uint screen_height =HVFB_HEIGHT ; -static uint screen_width_max =HVFB_WIDTH ; -static uint screen_height_max =HVFB_HEIGHT ;static uint screen_depth;static uint screen_fb_size;static uint dio_fb_size;/* FB size for deferred IO */
@@ -582,7 +580,6 @@ static int synthvid_get_supported_resolution(struct hv_device *hdev)int ret =0 ;unsigned long t;u8 index; -int i;memset (msg,0 ,sizeof (struct synthvid_msg )); msg->vid_hdr.type =SYNTHVID_RESOLUTION_REQUEST ;
@@ -613,13 +610,6 @@ static int synthvid_get_supported_resolution(struct hv_device *hdev) goto out; } -for (i =0 ; i < msg->resolution_resp.resolution_count; i++) { - screen_width_max = max_t(unsigned int, screen_width_max, - msg->resolution_resp.supported_resolution[i].width); - screen_height_max = max_t(unsigned int, screen_height_max, - msg->resolution_resp.supported_resolution[i].height); - } - screen_width = msg->resolution_resp.supported_resolution[index].width; screen_height =
@@ -941,7 +931,7 @@ static void hvfb_get_option(struct fb_info *info) if (x < HVFB_WIDTH_MIN || y < HVFB_HEIGHT_MIN || (synthvid_ver_ge(par->synthvid_version, SYNTHVID_VERSION_WIN10) && - (x > screen_width_max || y > screen_height_max)) || + (x * y * screen_depth / 8 > screen_fb_size)) || (par->synthvid_version == SYNTHVID_VERSION_WIN8 && x * y * screen_depth / 8 > SYNTHVID_FB_SIZE_WIN8) || (par->synthvid_version == SYNTHVID_VERSION_WIN7 &&
@@ -1194,8 +1184,8 @@ static int hvfb_probe(struct hv_device *hdev, }hvfb_get_option (info); -pr_info ("Screen resolution: %dx%d, Color depth: %d\n" , - screen_width, screen_height, screen_depth); +pr_info ("Screen resolution: %dx%d, Color depth: %d, Frame buffer size: %d\n" , + screen_width, screen_height, screen_depth, screen_fb_size); ret =hvfb_getmem (hdev, info);if (ret) {
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 167/200 can: tcan4x5x: regmap: fix max register value
In reply to Greg Kroah-HartmanFrom: Marc Kleine-Budde <[email protected]>
[ Upstream commit e59986de5ff701494e14c722b78b6e6d513e0ab5 ]
The MRAM of the tcan4x5x has a size of 2K and starts at 0x8000. There are no further registers in the tcan4x5x making 0x87fc the biggest addressable register.
This patch fixes the max register value of the regmap config from 0x8ffc to 0x87fc.
--- drivers/net/can/m_can/tcan4x5x-regmap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/can/m_can/tcan4x5x-regmap.c +1 -1
@@ -12,7 +12,7 @@#define TCAN4X5X_SPI_INSTRUCTION_WRITE (0x61 << 24)#define TCAN4X5X_SPI_INSTRUCTION_READ (0x41 << 24) -#define TCAN4X5X_MAX_REGISTER 0x8ffc +#define TCAN4X5X_MAX_REGISTER 0x87fc static int tcan4x5x_regmap_gather_write(void *context, const void *reg, size_t reg_len,
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 168/200 hwmon: (nct6775) Fix crash in clear_caseopen
In reply to Greg Kroah-HartmanFrom: Guenter Roeck <[email protected]>
[ Upstream commit 79da533d3cc717ccc05ddbd3190da8a72bc2408b ]
Paweł Marciniak reports the following crash, observed when clearing the chassis intrusion alarm.
BUG: kernel NULL pointer dereference, address: 0000000000000028 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 3 PID: 4815 Comm: bash Tainted: G S 5.16.2-200.fc35.x86_64 #1 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z97 Extreme4, BIOS P2.60A 05/03/2018 RIP: 0010:clear_caseopen+0x5a/0x120 [nct6775] Code: 68 70 e8 e9 32 b1 e3 85 c0 0f 85 d2 00 00 00 48 83 7c 24 ... RSP: 0018:ffffabcb02803dd8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000000 RDX: ffff8e8808192880 RSI: 0000000000000000 RDI: ffff8e87c7509a68 RBP: 0000000000000000 R08: 0000000000000001 R09: 000000000000000a R10: 000000000000000a R11: f000000000000000 R12: 000000000000001f R13: ffff8e87c7509828 R14: ffff8e87c7509a68 R15: ffff8e88494527a0 FS: 00007f4db9151740(0000) GS:ffff8e8ebfec0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000028 CR3: 0000000166b66001 CR4: 00000000001706e0 Call Trace: <TASK> kernfs_fop_write_iter+0x11c/0x1b0 new_sync_write+0x10b/0x180 vfs_write+0x209/0x2a0 ksys_write+0x4f/0xc0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae
The problem is that the device passed to clear_caseopen() is the hwmon device, not the platform device, and the platform data is not set in the hwmon device. Store the pointer to sio_data in struct nct6775_data and get if from there if needed.
--- drivers/hwmon/nct6775.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/hwmon/nct6775.c +3 -3
@@ -1175,7 +1175,7 @@ static inline u8 in_to_reg(u32 val, u8 nr)struct nct6775_data {int addr;/* IO base of hw monitor block */ -int sioreg;/* SIO register address */ +struct nct6775_sio_data *sio_data;enum kinds kind;const char *name;
@@ -3561,7 +3561,7 @@ clear_caseopen(struct device *dev, struct device_attribute *attr, const char *buf, size_t count) {struct nct6775_data *data =dev_get_drvdata (dev); -struct nct6775_sio_data *sio_data =dev_get_platdata (dev); +struct nct6775_sio_data *sio_data = data->sio_data;int nr =to_sensor_dev_attr (attr)->index -INTRUSION_ALARM_BASE ;unsigned long val;u8 reg;
@@ -3969,7 +3969,7 @@ static int nct6775_probe(struct platform_device *pdev)return -ENOMEM ; data->kind = sio_data->kind; - data->sioreg = sio_data->sioreg; + data->sio_data = sio_data;if (sio_data->access == access_direct) { data->addr = res->start;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 169/200 drm/msm/hdmi: Fix missing put_device() call in msm_hdmi_get_phy
In reply to Greg Kroah-HartmanFrom: Miaoqian Lin <[email protected]>
[ Upstream commit 774fe0cd838d1b1419d41ab4ea0613c80d4ecbd7 ]
The reference taken by 'of_find_device_by_node()' must be released when not needed anymore.
Add the corresponding 'put_device()' in the error handling path.
--- drivers/gpu/drm/msm/hdmi/hdmi.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/gpu/drm/msm/hdmi/hdmi.c +6 -1
@@ -95,10 +95,15 @@ static int msm_hdmi_get_phy(struct hdmi *hdmi)of_node_put (phy_node); -if (!phy_pdev || !hdmi->phy) { +if (!phy_pdev) {DRM_DEV_ERROR (&pdev->dev,"phy driver is not ready\n" );return -EPROBE_DEFER ; } +if (!hdmi->phy) { +DRM_DEV_ERROR (&pdev->dev,"phy driver is not ready\n" ); +put_device (&phy_pdev->dev); +return -EPROBE_DEFER ; + } hdmi->phy_dev =get_device (&phy_pdev->dev);
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 170/200 drm/msm/dpu: invalid parameter check in dpu_setup_dspp_pcc
In reply to Greg Kroah-HartmanFrom: José Expósito <[email protected]>
[ Upstream commit 170b22234d5495f5e0844246e23f004639ee89ba ]
The function performs a check on the "ctx" input parameter, however, it is used before the check.
Initialize the "base" variable after the sanity check to avoid a possible NULL pointer dereference.
Addresses-Coverity-ID: 1493866 ("Null pointer dereference")
--- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c +9 -2
@@ -26,9 +26,16 @@ static void dpu_setup_dspp_pcc(struct dpu_hw_dspp *ctx, struct dpu_hw_pcc_cfg *cfg) { -u32 base = ctx->cap->sblk->pcc.base; +u32 base; -if (!ctx || !base) { +if (!ctx) { +DRM_ERROR ("invalid ctx %pK\n" , ctx); +return ; + } + + base = ctx->cap->sblk->pcc.base; + +if (!base) {DRM_ERROR ("invalid ctx %pK pcc base 0x%x\n" , ctx, base);return ; }
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 171/200 drm/msm/a6xx: Add missing suspend_count increment
In reply to Greg Kroah-HartmanFrom: Rob Clark <[email protected]>
[ Upstream commit 860a7b2a87b7c743154824d0597b6c3eb3b53154 ]
--- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/gpu/drm/msm/adreno/a6xx_gpu.c +2 -0
@@ -1557,6 +1557,8 @@ static int a6xx_pm_suspend(struct msm_gpu *gpu)for (i =0 ; i < gpu->nr_rings; i++) a6xx_gpu->shadow[i] =0 ; + gpu->suspend_count++; +return 0 ; }
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 172/200 yam: fix a memory leak in yam_siocdevprivate()
In reply to Greg Kroah-HartmanFrom: Hangyu Hua <[email protected]>
[ Upstream commit 29eb31542787e1019208a2e1047bb7c76c069536 ]
ym needs to be free when ym->cmd != SIOCYAMSMCS.
--- drivers/net/hamradio/yam.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
drivers/net/hamradio/yam.c +1 -3
@@ -950,9 +950,7 @@ static int yam_siocdevprivate(struct net_device *dev, struct ifreq *ifr, void __ ym =memdup_user (data,sizeof (struct yamdrv_ioctl_mcs ));if (IS_ERR (ym))return PTR_ERR (ym); -if (ym->cmd !=SIOCYAMSMCS ) -return -EINVAL ; -if (ym->bitrate >YAM_MAXBITRATE ) { +if (ym->cmd !=SIOCYAMSMCS || ym->bitrate >YAM_MAXBITRATE ) {kfree (ym);return -EINVAL ; }
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 173/200 net: cpsw: Properly initialise struct page_pool_params
In reply to Greg Kroah-HartmanFrom: Toke Høiland-Jørgensen <[email protected]>
[ Upstream commit c63003e3d99761afb280add3b30de1cf30fa522b ]
The cpsw driver didn't properly initialise the struct page_pool_params before calling page_pool_create(), which leads to crashes after the struct has been expanded with new parameters.
The second Fixes tag below is where the buggy code was introduced, but because the code was moved around this patch will only apply on top of the commit in the first Fixes tag.
--- drivers/net/ethernet/ti/cpsw_priv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/ti/cpsw_priv.c +1 -1
@@ -1144,7 +1144,7 @@ int cpsw_fill_rx_channels(struct cpsw_priv *priv)static struct page_pool *cpsw_create_page_pool (struct cpsw_common *cpsw,int size) { -struct page_pool_params pp_params; +struct page_pool_params pp_params = {};struct page_pool *pool; pp_params.order =0 ;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 174/200 net: hns3: handle empty unknown interrupt for VF
In reply to Greg Kroah-HartmanFrom: Yufeng Mo <[email protected]>
[ Upstream commit 2f61353cd2f789a4229b6f5c1c24a40a613357bb ]
Since some interrupt states may be cleared by hardware, the driver may receive an empty interrupt. Currently, the VF driver directly disables the vector0 interrupt in this case. As a result, the VF is unavailable. Therefore, the vector0 interrupt should be enabled in this case.
--- drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c +1 -2
@@ -2496,8 +2496,7 @@ static irqreturn_t hclgevf_misc_irq_handle(int irq, void *data)break ; } -if (event_cause !=HCLGEVF_VECTOR0_EVENT_OTHER ) -hclgevf_enable_vector (&hdev->misc_vector, true); +hclgevf_enable_vector (&hdev->misc_vector, true);return IRQ_HANDLED ; }
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 175/200 KVM: selftests: Re-enable access_tracking_perf_test
In reply to Greg Kroah-HartmanFrom: David Matlack <[email protected]>
[ Upstream commit de1956f48543e90f94b1194395f33140898b39b2 ]
This selftest was accidentally removed by commit 6a58150859fd ("selftest: KVM: Add intra host migration tests"). Add it back.
Message-Id: <[email protected]>
--- tools/testing/selftests/kvm/Makefile | 1 + 1 file changed, 1 insertion(+)
tools/testing/selftests/kvm/Makefile +1 -0
@@ -77,6 +77,7 @@ TEST_GEN_PROGS_x86_64 += x86_64/xen_shinfo_test TEST_GEN_PROGS_x86_64 += x86_64/xen_vmcall_test TEST_GEN_PROGS_x86_64 += x86_64/vmx_pi_mmio_test TEST_GEN_PROGS_x86_64 += x86_64/sev_migrate_tests +TEST_GEN_PROGS_x86_64 += access_tracking_perf_test TEST_GEN_PROGS_x86_64 += demand_paging_test TEST_GEN_PROGS_x86_64 += dirty_log_test TEST_GEN_PROGS_x86_64 += dirty_log_perf_test
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 176/200 sch_htb: Fail on unsupported parameters when offload is requested
In reply to Greg Kroah-HartmanFrom: Maxim Mikityanskiy <[email protected]>
[ Upstream commit 429c3be8a5e2695b5b92a6a12361eb89eb185495 ]
The current implementation of HTB offload doesn't support some parameters. Instead of ignoring them, actively return the EINVAL error when they are set to non-defaults.
As this patch goes to stable, the driver API is not changed here. If future drivers support more offload parameters, the checks can be moved to the driver side.
Note that the buffer and cbuffer parameters are also not supported, but the tc userspace tool assigns some default values derived from rate and ceil, and identifying these defaults in sch_htb would be unreliable, so they are still ignored.
--- net/sched/sch_htb.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+)
net/sched/sch_htb.c +20 -0
@@ -1810,6 +1810,26 @@ static int htb_change_class(struct Qdisc *sch, u32 classid,if (!hopt->rate.rate || !hopt->ceil.rate) goto failure; +if (q->offload) { +/* Options not supported by the offload. */ +if (hopt->rate.overhead || hopt->ceil.overhead) { +NL_SET_ERR_MSG (extack,"HTB offload doesn't support the overhead parameter" ); + goto failure; + } +if (hopt->rate.mpu || hopt->ceil.mpu) { +NL_SET_ERR_MSG (extack,"HTB offload doesn't support the mpu parameter" ); + goto failure; + } +if (hopt->quantum) { +NL_SET_ERR_MSG (extack,"HTB offload doesn't support the quantum parameter" ); + goto failure; + } +if (hopt->prio) { +NL_SET_ERR_MSG (extack,"HTB offload doesn't support the prio parameter" ); + goto failure; + } + } +/* Keeping backward compatible with rate_table based iproute2 tc */ if (hopt->rate.linklayer ==TC_LINKLAYER_UNAWARE ) qdisc_put_rtab(qdisc_get_rtab(&hopt->rate, tb[TCA_HTB_RTAB],
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 177/200 Revert "drm/ast: Support 1600x900 with 108MHz PCLK"
In reply to Greg Kroah-HartmanFrom: Dave Airlie <[email protected]>
[ Upstream commit 76cea3d95513fe40000d06a3719c4bb6b53275e2 ]
This reverts commit 9bb7b689274b67ecb3641e399e76f84adc627df1.
This caused a regression reported to Red Hat.
--- drivers/gpu/drm/ast/ast_tables.h | 2 -- 1 file changed, 2 deletions(-)
drivers/gpu/drm/ast/ast_tables.h +0 -2
@@ -282,8 +282,6 @@ static const struct ast_vbios_enhtable res_1360x768[] = { };static const struct ast_vbios_enhtable res_1600x900[] = { - {1800 ,1600 ,24 ,80 ,1000 ,900 ,1 ,3 ,VCLK108 ,/* 60Hz */ - (SyncPP | Charx8Dot | LineCompareOff | WideScreenMode | NewModeInfo),60 ,3 ,0x3A }, {1760 ,1600 ,48 ,32 ,926 ,900 ,3 ,5 ,VCLK97_75 ,/* 60Hz CVT RB */ (SyncNP | Charx8Dot | LineCompareOff | WideScreenMode | NewModeInfo | AST2500PreCatchCRT),60 ,1 ,0x3A },
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 178/200 KVM: selftests: Dont skip L2s VMCALL in SMM test for SVM guest
In reply to Greg Kroah-HartmanFrom: Sean Christopherson <[email protected]>
[ Upstream commit 4cf3d3ebe8794c449af3e0e8c1d790c97e461d20 ]
Don't skip the vmcall() in l2_guest_code() prior to re-entering L2, doing so will result in L2 running to completion, popping '0' off the stack for RET, jumping to address '0', and ultimately dying with a triple fault shutdown.
It's not at all obvious why the test re-enters L2 and re-executes VMCALL, but presumably it serves a purpose. The VMX path doesn't skip vmcall(), and the test can't possibly have passed on SVM, so just do what VMX does.
Message-Id: <[email protected]>
--- tools/testing/selftests/kvm/x86_64/smm_test.c | 1 - 1 file changed, 1 deletion(-)
tools/testing/selftests/kvm/x86_64/smm_test.c +0 -1
@@ -105,7 +105,6 @@ static void guest_code(void *arg)if (cpu_has_svm ()) {run_guest (svm->vmcb, svm->vmcb_gpa); - svm->vmcb->save.rip +=3 ;run_guest (svm->vmcb, svm->vmcb_gpa); }else {vmlaunch ();
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 179/200 ceph: put the requests/sessions when it fails to alloc memory
In reply to Greg Kroah-HartmanFrom: Xiubo Li <[email protected]>
[ Upstream commit 89d43d0551a848e70e63d9ba11534aaeabc82443 ]
When failing to allocate the sessions memory we should make sure the req1 and req2 and the sessions get put. And also in case the max_sessions decreased so when kreallocate the new memory some sessions maybe missed being put.
And if the max_sessions is 0 krealloc will return ZERO_SIZE_PTR, which will lead to a distinct access fault.
URL: https://tracker.ceph.com/issues/53819
--- fs/ceph/caps.c | 55 +++++++++++++++++++++++++++++++++----------------- 1 file changed, 37 insertions(+), 18 deletions(-)
fs/ceph/caps.c +37 -18
@@ -2218,6 +2218,7 @@ static int unsafe_request_wait(struct inode *inode)struct ceph_mds_client *mdsc =ceph_sb_to_client (inode->i_sb)->mdsc;struct ceph_inode_info *ci =ceph_inode (inode);struct ceph_mds_request *req1 =NULL , *req2 =NULL ; +unsigned int max_sessions;int ret, err =0 ;spin_lock (&ci->i_unsafe_lock);
@@ -2235,37 +2236,45 @@ static int unsafe_request_wait(struct inode *inode) }spin_unlock (&ci->i_unsafe_lock); +/* +* The mdsc->max_sessions is unlikely to be changed +* mostly, here we will retry it by reallocating the +* sessions array memory to get rid of the mdsc->mutex +* lock. +*/ +retry: + max_sessions = mdsc->max_sessions; +/* * Trigger to flush the journal logs in all the relevant MDSes * manually, or in the worst case we must wait at most 5 seconds * to wait the journal logs to be flushed by the MDSes periodically. */ -if (req1 || req2) { +if ((req1 || req2) &&likely (max_sessions)) {struct ceph_mds_session **sessions =NULL ;struct ceph_mds_session *s;struct ceph_mds_request *req; -unsigned int max;int i; -/* -* The mdsc->max_sessions is unlikely to be changed -* mostly, here we will retry it by reallocating the -* sessions arrary memory to get rid of the mdsc->mutex -* lock. -*/ -retry: - max = mdsc->max_sessions; - sessions =krealloc (sessions, max *sizeof (s), __GFP_ZERO); -if (!sessions) -return -ENOMEM ; + sessions =kzalloc (max_sessions *sizeof (s),GFP_KERNEL ); +if (!sessions) { + err = -ENOMEM ; + goto out; + }spin_lock (&ci->i_unsafe_lock);if (req1) {list_for_each_entry (req, &ci->i_unsafe_dirops, r_unsafe_dir_item) { s = req->r_session; -if (unlikely (s->s_mds >= max)) { +if (unlikely (s->s_mds >= max_sessions)) {spin_unlock (&ci->i_unsafe_lock); +for (i =0 ; i < max_sessions; i++) { + s = sessions[i]; +if (s) +ceph_put_mds_session (s); + } +kfree (sessions); goto retry; }if (!sessions[s->s_mds]) {
@@ -2278,8 +2287,14 @@ retry:list_for_each_entry (req, &ci->i_unsafe_iops, r_unsafe_target_item) { s = req->r_session; -if (unlikely (s->s_mds >= max)) { +if (unlikely (s->s_mds >= max_sessions)) {spin_unlock (&ci->i_unsafe_lock); +for (i =0 ; i < max_sessions; i++) { + s = sessions[i]; +if (s) +ceph_put_mds_session (s); + } +kfree (sessions); goto retry; }if (!sessions[s->s_mds]) {
@@ -2300,7 +2315,7 @@ retry:spin_unlock (&ci->i_ceph_lock);/* send flush mdlog request to MDSes */ -for (i =0 ; i < max; i++) { +for (i =0 ; i < max_sessions; i++) { s = sessions[i];if (s) {send_flush_mdlog (s);
@@ -2317,15 +2332,19 @@ retry: ceph_timeout_jiffies(req1->r_timeout));if (ret) err = -EIO ; -ceph_mdsc_put_request (req1); }if (req2) { ret = !wait_for_completion_timeout (&req2->r_safe_completion,ceph_timeout_jiffies (req2->r_timeout));if (ret) err = -EIO ; -ceph_mdsc_put_request (req2); } + +out: +if (req1) +ceph_mdsc_put_request (req1); +if (req2) +ceph_mdsc_put_request (req2);return err; }
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 180/200 gve: Fix GFP flags when allocing pages
In reply to Greg Kroah-HartmanFrom: Catherine Sullivan <[email protected]>
[ Upstream commit a92f7a6feeb3884c69c1c7c1f13bccecb2228ad0 ]
Use GFP_ATOMIC when allocating pages out of the hotpath, continue to use GFP_KERNEL when allocating pages during setup.
GFP_KERNEL will allow blocking which allows it to succeed more often in a low memory enviornment but in the hotpath we do not want to allow the allocation to block.
--- drivers/net/ethernet/google/gve/gve.h | 2 +- drivers/net/ethernet/google/gve/gve_main.c | 6 +++--- drivers/net/ethernet/google/gve/gve_rx.c | 3 ++- drivers/net/ethernet/google/gve/gve_rx_dqo.c | 2 +- 4 files changed, 7 insertions(+), 6 deletions(-)
drivers/net/ethernet/google/gve/gve.h +1 -1
@@ -830,7 +830,7 @@ static inline bool gve_is_gqi(struct gve_priv *priv)/* buffers */ int gve_alloc_page (struct gve_priv *priv,struct device *dev,struct page **page,dma_addr_t *dma, -enum dma_data_direction ); +enum dma_data_direction ,gfp_t gfp_flags);void gve_free_page (struct device *dev,struct page *page,dma_addr_t dma,enum dma_data_direction );/* tx handling */
drivers/net/ethernet/google/gve/gve_main.c +3 -3
@@ -752,9 +752,9 @@ static void gve_free_rings(struct gve_priv *priv)int gve_alloc_page (struct gve_priv *priv,struct device *dev,struct page **page,dma_addr_t *dma, -enum dma_data_direction dir) +enum dma_data_direction dir,gfp_t gfp_flags) { - *page =alloc_page (GFP_KERNEL ); + *page =alloc_page (gfp_flags);if (!*page) { priv->page_alloc_fail++;return -ENOMEM ;
@@ -797,7 +797,7 @@ static int gve_alloc_queue_page_list(struct gve_priv *priv, u32 id,for (i =0 ; i < pages; i++) { err =gve_alloc_page (priv, &priv->pdev->dev, &qpl->pages[i], &qpl->page_buses[i], -gve_qpl_dma_dir (priv, id)); +gve_qpl_dma_dir (priv, id),GFP_KERNEL );/* caller handles clean up */ if (err)return -ENOMEM ;
drivers/net/ethernet/google/gve/gve_rx.c +2 -1
@@ -86,7 +86,8 @@ static int gve_rx_alloc_buffer(struct gve_priv *priv, struct device *dev,dma_addr_t dma;int err; - err =gve_alloc_page (priv, dev, &page, &dma,DMA_FROM_DEVICE ); + err =gve_alloc_page (priv, dev, &page, &dma,DMA_FROM_DEVICE , +GFP_ATOMIC );if (err)return err;
drivers/net/ethernet/google/gve/gve_rx_dqo.c +1 -1
@@ -157,7 +157,7 @@ static int gve_alloc_page_dqo(struct gve_priv *priv,int err; err =gve_alloc_page (priv, &priv->pdev->dev, &buf_state->page_info.page, - &buf_state->addr,DMA_FROM_DEVICE ); + &buf_state->addr,DMA_FROM_DEVICE ,GFP_KERNEL );if (err)return err;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 181/200 Revert "ipv6: Honor all IPv6 PIO Valid Lifetime values"
In reply to Greg Kroah-HartmanFrom: Guillaume Nault <[email protected]>
[ Upstream commit 36268983e90316b37000a005642af42234dabb36 ]
This reverts commit b75326c201242de9495ff98e5d5cff41d7fc0d9d.
This commit breaks Linux compatibility with USGv6 tests. The RFC this commit was based on is actually an expired draft: no published RFC currently allows the new behaviour it introduced.
Without full IETF endorsement, the flash renumbering scenario this patch was supposed to enable is never going to work, as other IPv6 equipements on the same LAN will keep the 2 hours limit.
--- include/net/addrconf.h | 2 ++ net/ipv6/addrconf.c | 27 ++++++++++++++++++++------- 2 files changed, 22 insertions(+), 7 deletions(-)
include/net/addrconf.h +2 -0
@@ -6,6 +6,8 @@#define RTR_SOLICITATION_INTERVAL (4*HZ)#define RTR_SOLICITATION_MAX_INTERVAL (3600*HZ)/* 1 hour */ +#define MIN_VALID_LIFETIME (2*3600)/* 2 hours */ +#define TEMP_VALID_LIFETIME (7*86400)#define TEMP_PREFERRED_LIFETIME (86400)#define REGEN_MAX_RETRY (3)
net/ipv6/addrconf.c +20 -7
@@ -2589,7 +2589,7 @@ int addrconf_prefix_rcv_add_addr(struct net *net, struct net_device *dev, __u32 valid_lft, u32 prefered_lft) {struct inet6_ifaddr *ifp =ipv6_get_ifaddr (net, addr, dev,1 ); -int create =0 ; +int create =0 , update_lft =0 ;if (!ifp && valid_lft) {int max_addresses = in6_dev->cnf.max_addresses;
@@ -2633,19 +2633,32 @@ int addrconf_prefix_rcv_add_addr(struct net *net, struct net_device *dev,unsigned long now;u32 stored_lft; -/* Update lifetime (RFC4862 5.5.3 e) -* We deviate from RFC4862 by honoring all Valid Lifetimes to -* improve the reaction of SLAAC to renumbering events -* (draft-gont-6man-slaac-renum-06, Section 4.2) -*/ +/* update lifetime (RFC2462 5.5.3 e) */ spin_lock_bh (&ifp->lock); now = jiffies;if (ifp->valid_lft > (now - ifp->tstamp) /HZ ) stored_lft = ifp->valid_lft - (now - ifp->tstamp) /HZ ;else stored_lft =0 ; -if (!create && stored_lft) { +const u32 minimum_lft =min_t (u32, + stored_lft,MIN_VALID_LIFETIME ); + valid_lft =max (valid_lft, minimum_lft); + +/* RFC4862 Section 5.5.3e: +* "Note that the preferred lifetime of the +* corresponding address is always reset to +* the Preferred Lifetime in the received +* Prefix Information option, regardless of +* whether the valid lifetime is also reset or +* ignored." +* +* So we should always update prefered_lft here. +*/ + update_lft =1 ; + } + +if (update_lft) { ifp->valid_lft = valid_lft; ifp->prefered_lft = prefered_lft; ifp->tstamp = now;
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 182/200 net: bridge: vlan: fix single net device option dumping
In reply to Greg Kroah-HartmanFrom: Nikolay Aleksandrov <[email protected]>
[ Upstream commit dcb2c5c6ca9b9177f04abaf76e5a983d177c9414 ]
When dumping vlan options for a single net device we send the same entries infinitely because user-space expects a 0 return at the end but we keep returning skb->len and restarting the dump on retry. Fix it by returning the value from br_vlan_dump_dev() if it completed or there was an error. The only case that must return skb->len is when the dump was incomplete and needs to continue (-EMSGSIZE).
--- net/bridge/br_vlan.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
net/bridge/br_vlan.c +2 -1
@@ -2020,7 +2020,8 @@ static int br_vlan_rtm_dump(struct sk_buff *skb, struct netlink_callback *cb) goto out_err; } err =br_vlan_dump_dev (dev, skb, cb, dump_flags); -if (err && err != -EMSGSIZE ) +/* if the dump completed without an error we return 0 here */ +if (err != -EMSGSIZE ) goto out_err; }else {for_each_netdev_rcu (net, dev) {
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 183/200 ipv4: raw: lock the socket in raw_bind()
In reply to Greg Kroah-HartmanFrom: Eric Dumazet <[email protected]>
[ Upstream commit 153a0d187e767c68733b8e9f46218eb1f41ab902 ]
For some reason, raw_bind() forgot to lock the socket.
BUG: KCSAN: data-race in __ip4_datagram_connect / raw_bind
write to 0xffff8881170d4308 of 4 bytes by task 5466 on cpu 0:
raw_bind+0x1b0/0x250 net/ipv4/raw.c:739 inet_bind+0x56/0xa0 net/ipv4/af_inet.c:443 __sys_bind+0x14b/0x1b0 net/socket.c:1697 __do_sys_bind net/socket.c:1708 [inline] __se_sys_bind net/socket.c:1706 [inline] __x64_sys_bind+0x3d/0x50 net/socket.c:1706 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae
read to 0xffff8881170d4308 of 4 bytes by task 5468 on cpu 1:
__ip4_datagram_connect+0xb7/0x7b0 net/ipv4/datagram.c:39 ip4_datagram_connect+0x2a/0x40 net/ipv4/datagram.c:89 inet_dgram_connect+0x107/0x190 net/ipv4/af_inet.c:576 __sys_connect_file net/socket.c:1900 [inline] __sys_connect+0x197/0x1b0 net/socket.c:1917 __do_sys_connect net/socket.c:1927 [inline] __se_sys_connect net/socket.c:1924 [inline] __x64_sys_connect+0x3d/0x50 net/socket.c:1924 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae
value changed: 0x00000000 -> 0x0003007f
Reported by Kernel Concurrency Sanitizer on:
CPU: 1 PID: 5468 Comm: syz-executor.5 Not tainted 5.17.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
--- net/ipv4/raw.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
net/ipv4/raw.c +4 -1
@@ -721,6 +721,7 @@ static int raw_bind(struct sock *sk, struct sockaddr *uaddr, int addr_len)int ret = -EINVAL ;int chk_addr_ret; +lock_sock (sk);if (sk->sk_state !=TCP_CLOSE || addr_len <sizeof (struct sockaddr_in )) goto out;
@@ -740,7 +741,9 @@ static int raw_bind(struct sock *sk, struct sockaddr *uaddr, int addr_len) inet->inet_saddr =0 ;/* Use device */ sk_dst_reset (sk); ret =0 ; -out:return ret; +out: +release_sock (sk); +return ret; }/*
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 184/200 ipv4: tcp: send zero IPID in SYNACK messages
In reply to Greg Kroah-HartmanFrom: Eric Dumazet <[email protected]>
[ Upstream commit 970a5a3ea86da637471d3cd04d513a0755aba4bf ]
In commit 431280eebed9 ("ipv4: tcp: send zero IPID for RST and ACK sent in SYN-RECV and TIME-WAIT state") we took care of some ctl packets sent by TCP.
It turns out we need to use a similar strategy for SYNACK packets.
By default, they carry IP_DF and IPID==0, but there are ways to ask them to use the hashed IP ident generator and thus be used to build off-path attacks.
(Ref: Off-Path TCP Exploits of the Mixed IPID Assignment)
One of this way is to force (before listener is started) echo 1 >/proc/sys/net/ipv4/ip_no_pmtu_disc
Another way is using forged ICMP ICMP_FRAG_NEEDED with a very small MTU (like 68) to force a false return from ip_dont_fragment()
In this patch, ip_build_and_send_pkt() uses the following heuristics.
1) Most SYNACK packets are smaller than IPV4_MIN_MTU and therefore can use IP_DF regardless of the listener or route pmtu setting.
2) In case the SYNACK packet is bigger than IPV4_MIN_MTU, we use prandom_u32() generator instead of the IPv4 hashed ident one.
--- net/ipv4/ip_output.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)
net/ipv4/ip_output.c +9 -2
@@ -162,12 +162,19 @@ int ip_build_and_send_pkt(struct sk_buff *skb, const struct sock *sk, iph->daddr = (opt && opt->opt.srr ? opt->opt.faddr : daddr); iph->saddr = saddr; iph->protocol = sk->sk_protocol; -if (ip_dont_fragment (sk, &rt->dst)) { +/* Do not bother generating IPID for small packets (eg SYNACK) */ +if (skb->len <=IPV4_MIN_MTU ||ip_dont_fragment (sk, &rt->dst)) { iph->frag_off =htons (IP_DF ); iph->id =0 ; }else { iph->frag_off =0 ; -__ip_select_ident (net, iph,1 ); +/* TCP packets here are SYNACK with fat IPv4/TCP options. +* Avoid using the hashed IP ident generator. +*/ +if (sk->sk_protocol ==IPPROTO_TCP ) + iph->id = (__force __be16 )prandom_u32 (); +else +__ip_select_ident (net, iph,1 ); }if (opt && opt->opt.optlen) {
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 185/200 ipv4: remove sparse error in ip_neigh_gw4()
In reply to Greg Kroah-HartmanFrom: Eric Dumazet <[email protected]>
[ Upstream commit 3c42b2019863b327caa233072c50739d4144dd16 ]
./include/net/route.h:373:48: warning: incorrect type in argument 2 (different base types)./include/net/route.h:373:48: expected unsigned int [usertype] key./include/net/route.h:373:48: got restricted __be32 [usertype] daddr
--- include/net/route.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/net/route.h +1 -1
@@ -369,7 +369,7 @@ static inline struct neighbour *ip_neigh_gw4(struct net_device *dev, {struct neighbour *neigh; - neigh =__ipv4_neigh_lookup_noref (dev, daddr); + neigh =__ipv4_neigh_lookup_noref (dev, (__force u32 )daddr);if (unlikely (!neigh)) neigh =__neigh_create (&arp_tbl, &daddr, dev, false);
Signature · 1 line
2.34.1
Greg Kroah-Hartman
maintainerPATCH 186/200 net: bridge: vlan: fix memory leak in __allowed_ingress
In reply to Greg Kroah-HartmanFrom: Tim Yi <[email protected]>
[ Upstream commit fd20d9738395cf8e27d0a17eba34169699fccdff ]
When using per-vlan state, if vlan snooping and stats are disabled, untagged or priority-tagged ingress frame will go to check pvid state. If the port state is forwarding and the pvid state is not learning/forwarding, untagged or priority-tagged frame will be dropped but skb memory is not freed.
Should free skb when __allowed_ingress returns false.
--- net/bridge/br_vlan.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
net/bridge/br_vlan.c +3 -3
@@ -560,10 +560,10 @@ static bool __allowed_ingress(const stru !br_opt_get(br, BROPT_VLAN_STATS_ENABLED)) {if (*state ==BR_STATE_FORWARDING ) { *state =br_vlan_get_pvid_state (vg); -return br_vlan_state_allowed (*state, true); - }else { -return true; +if (!br_vlan_state_allowed (*state, true)) + goto drop; } +return true; } } v =br_vlan_find (vg, *vid);
Greg Kroah-Hartman
maintainerPATCH 187/200 irqchip/realtek-rtl: Map control data to virq
In reply to Greg Kroah-HartmanFrom: Sander Vanheule <[email protected]>
commit 291e79c7e2eb6fdc016453597b78482e06199d0f upstream.
The driver assigned the irqchip and irq handler to the hardware irq, instead of the virq. This is incorrect, and only worked because these irq numbers happened to be the same on the devices used for testing the original driver.
--- drivers/irqchip/irq-realtek-rtl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/irqchip/irq-realtek-rtl.c +1 -1
@@ -62,7 +62,7 @@ static struct irq_chip realtek_ictl_irqstatic int intc_map (struct irq_domain *d,unsigned int irq,irq_hw_number_t hw) { -irq_set_chip_and_handler (hw, &realtek_ictl_irq, handle_level_irq); +irq_set_chip_and_handler (irq, &realtek_ictl_irq, handle_level_irq);return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 188/200 irqchip/realtek-rtl: Fix off-by-one in routing
In reply to Greg Kroah-HartmanFrom: Sander Vanheule <[email protected]>
commit 91351b5dd0fd494eb2d85e1bb6aca77b067447e0 upstream.
There is an offset between routing values (1..6) and the connected MIPS CPU interrupts (2..7), but no distinction was made between these two values.
This issue was previously hidden during testing, because an interrupt mapping was used where for each required interrupt another (unused) routing was configured, with an offset of +1.
Offset the CPU IRQ numbers by -1 to retrieve the correct routing value.
--- drivers/irqchip/irq-realtek-rtl.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
drivers/irqchip/irq-realtek-rtl.c +5 -3
@@ -95,7 +95,8 @@ out:* SoC interrupts are cascaded to MIPS CPU interrupts according to the * interrupt-map in the device tree. Each SoC interrupt gets 4 bits for * the CPU interrupt in an Interrupt Routing Register. Max 32 SoC interrupts -* thus go into 4 IRRs. +* thus go into 4 IRRs. A routing value of '0' means the interrupt is left +* disconnected. Routing values {1..15} connect to output lines {0..14}. */ static int __init map_interrupts (struct device_node *node,struct irq_domain *domain) {
@@ -134,7 +135,7 @@ static int __init map_interrupts(structof_node_put (cpu_ictl); cpu_int =be32_to_cpup (imap +2 ); -if (cpu_int >7 ) +if (cpu_int >7 || cpu_int <2 )return -EINVAL ;if (!(mips_irqs_set &BIT (cpu_int))) {
@@ -143,7 +144,8 @@ static int __init map_interrupts(struct mips_irqs_set |=BIT (cpu_int); } - regs[(soc_int *4 ) /32 ] |= cpu_int << (soc_int *4 ) %32 ; +/* Use routing values (1..6) for CPU interrupts (2..7) */ + regs[(soc_int *4 ) /32 ] |= (cpu_int -1 ) << (soc_int *4 ) %32 ; imap +=3 ; }
Greg Kroah-Hartman
maintainerPATCH 189/200 dt-bindings: can: tcan4x5x: fix mram-cfg RX FIFO config
In reply to Greg Kroah-HartmanFrom: Marc Kleine-Budde <[email protected]>
commit 17a30422621c0e04cb6060d20d7edcefd7463347 upstream.
This tcan4x5x only comes with 2K of MRAM, a RX FIFO with a dept of 32 doesn't fit into the MRAM. Use a depth of 16 instead.
--- Documentation/devicetree/bindings/net/can/tcan4x5x.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Documentation/devicetree/bindings/net/can/tcan4x5x.txt +1 -1
@@ -31,7 +31,7 @@ tcan4x5x: tcan4x5x@0 { #address-cells = <1>; #size-cells = <1>; spi-max-frequency = <10000000>; - bosch,mram-cfg = <0x0 0 0 32 0 0 1 1>; + bosch,mram-cfg = <0x0 0 0 16 0 0 1 1>; interrupt-parent = <&gpio1>; interrupts = <14 IRQ_TYPE_LEVEL_LOW>; device-state-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
Greg Kroah-Hartman
maintainerPATCH 190/200 PCI: mt7621: Remove unused function pcie_rmw()
In reply to Greg Kroah-HartmanFrom: Sergio Paracuellos <[email protected]>
commit c035366d9c9fe48d947ee6c43465ab43d42e20f2 upstream.
Function pcie_rmw() is not being used at all and can be deleted. Hence get rid of it, which fixes this warning:
drivers/pci/controller/pcie-mt7621.c:112:20: warning: unused function 'pcie_rmw' [-Wunused-function]
--- drivers/pci/controller/pcie-mt7621.c | 9 --------- 1 file changed, 9 deletions(-)
drivers/pci/controller/pcie-mt7621.c +0 -9
@@ -109,15 +109,6 @@ static inline void pcie_write(struct mt7writel_relaxed (val, pcie->base + reg); } -static inline void pcie_rmw (struct mt7621_pcie *pcie,u32 reg,u32 clr,u32 set) -{ -u32 val =readl_relaxed (pcie->base + reg); - - val &= ~clr; - val |= set; -writel_relaxed (val, pcie->base + reg); -} -static inline u32 pcie_port_read (struct mt7621_pcie_port *port,u32 reg) {return readl_relaxed (port->base + reg);
Greg Kroah-Hartman
maintainerPATCH 191/200 perf/core: Fix cgroup event list management
In reply to Greg Kroah-HartmanFrom: Namhyung Kim <[email protected]>
commit c5de60cd622a2607c043ba65e25a6e9998a369f9 upstream.
The active cgroup events are managed in the per-cpu cgrp_cpuctx_list. This list is only accessed from current cpu and not protected by any locks. But from the commit ef54c1a476ae ("perf: Rework perf_event_exit_event()"), it's possible to access (actually modify) the list from another cpu.
In the perf_remove_from_context(), it can remove an event from the context without an IPI when the context is not active. This is not safe with cgroup events which can have some active events in the context even if ctx->is_active is 0 at the moment. The target cpu might be in the middle of list iteration at the same time.
If the event is enabled when it's about to be closed, it might call perf_cgroup_event_disable() and list_del() with the cgrp_cpuctx_list on a different cpu.
This resulted in a crash due to an invalid list pointer access during the cgroup list traversal on the cpu which the event belongs to.
Let's fallback to IPI to access the cgrp_cpuctx_list from that cpu. Similarly, perf_install_in_context() should use IPI for the cgroup events too.
--- kernel/events/core.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)
kernel/events/core.c +9 -2
@@ -2458,7 +2458,11 @@ static void perf_remove_from_context(str* event_function_call() user. */ raw_spin_lock_irq (&ctx->lock); -if (!ctx->is_active) { +/* +* Cgroup events are per-cpu events, and must IPI because of +* cgrp_cpuctx_list. +*/ +if (!ctx->is_active && !is_cgroup_event (event)) {__perf_remove_from_context (event,__get_cpu_context (ctx), ctx, (void *)flags);raw_spin_unlock_irq (&ctx->lock);
@@ -2891,11 +2895,14 @@ perf_install_in_context(struct perf_even* perf_event_attr::disabled events will not run and can be initialized * without IPI. Except when this is the first event for the context, in * that case we need the magic of the IPI to set ctx->is_active. +* Similarly, cgroup events for the context also needs the IPI to +* manipulate the cgrp_cpuctx_list. * * The IOC_ENABLE that is sure to follow the creation of a disabled * event will issue the IPI and reprogram the hardware. */ -if (__perf_effective_state (event) ==PERF_EVENT_STATE_OFF && ctx->nr_events) { +if (__perf_effective_state (event) ==PERF_EVENT_STATE_OFF && + ctx->nr_events && !is_cgroup_event (event)) {raw_spin_lock_irq (&ctx->lock);if (ctx->task ==TASK_TOMBSTONE ) {raw_spin_unlock_irq (&ctx->lock);
Greg Kroah-Hartman
maintainerPATCH 192/200 psi: fix "no previous prototype" warnings when CONFIG_CGROUPS=n
In reply to Greg Kroah-HartmanFrom: Suren Baghdasaryan <[email protected]>
commit 51e50fbd3efc6064c30ed73a5e009018b36e290a upstream.
When CONFIG_CGROUPS is disabled psi code generates the following warnings:
kernel/sched/psi.c:1112:21: warning: no previous prototype for 'psi_trigger_create' [-Wmissing-prototypes]
1112 | struct psi_trigger *psi_trigger_create(struct psi_group *group,
| ^~~~~~~~~~~~~~~~~~
kernel/sched/psi.c:1182:6: warning: no previous prototype for 'psi_trigger_destroy' [-Wmissing-prototypes]
1182 | void psi_trigger_destroy(struct psi_trigger *t)
| ^~~~~~~~~~~~~~~~~~~
kernel/sched/psi.c:1249:10: warning: no previous prototype for 'psi_trigger_poll' [-Wmissing-prototypes]
1249 | __poll_t psi_trigger_poll(void **trigger_ptr,
| ^~~~~~~~~~~~~~~~Change the declarations of these functions in the header to provide the prototypes even when they are unused.
--- include/linux/psi.h | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-)
include/linux/psi.h +5 -6
@@ -24,18 +24,17 @@ void psi_memstall_enter(unsigned long *fvoid psi_memstall_leave (unsigned long *flags);int psi_show (struct seq_file *s,struct psi_group *group,enum psi_res res); - -#ifdef CONFIG_CGROUPS -int psi_cgroup_alloc (struct cgroup *cgrp); -void psi_cgroup_free (struct cgroup *cgrp); -void cgroup_move_task (struct task_struct *p,struct css_set *to); -struct psi_trigger *psi_trigger_create (struct psi_group *group,char *buf,size_t nbytes,enum psi_res res);void psi_trigger_destroy (struct psi_trigger *t);__poll_t psi_trigger_poll (void **trigger_ptr,struct file *file,poll_table *wait); + +#ifdef CONFIG_CGROUPS +int psi_cgroup_alloc (struct cgroup *cgrp); +void psi_cgroup_free (struct cgroup *cgrp); +void cgroup_move_task (struct task_struct *p,struct css_set *to);#endif #else /* CONFIG_PSI */
Greg Kroah-Hartman
maintainerPATCH 193/200 psi: fix "defined but not used" warnings when CONFIG_PROC_FS=n
In reply to Greg Kroah-HartmanFrom: Suren Baghdasaryan <[email protected]>
commit 44585f7bc0cb01095bc2ad4258049c02bbad21ef upstream.
When CONFIG_PROC_FS is disabled psi code generates the following warnings:
kernel/sched/psi.c:1364:30: warning: 'psi_cpu_proc_ops' defined but not used [-Wunused-const-variable=]
1364 | static const struct proc_ops psi_cpu_proc_ops = {
| ^~~~~~~~~~~~~~~~
kernel/sched/psi.c:1355:30: warning: 'psi_memory_proc_ops' defined but not used [-Wunused-const-variable=]
1355 | static const struct proc_ops psi_memory_proc_ops = {
| ^~~~~~~~~~~~~~~~~~~
kernel/sched/psi.c:1346:30: warning: 'psi_io_proc_ops' defined but not used [-Wunused-const-variable=]
1346 | static const struct proc_ops psi_io_proc_ops = {
| ^~~~~~~~~~~~~~~Make definitions of these structures and related functions conditional on CONFIG_PROC_FS config.
--- kernel/sched/psi.c | 79 +++++++++++++++++++++++++++-------------------------- 1 file changed, 41 insertions(+), 38 deletions(-)
kernel/sched/psi.c +41 -38
@@ -1082,44 +1082,6 @@ int psi_show(struct seq_file *m, structreturn 0 ; } -static int psi_io_show (struct seq_file *m,void *v) -{ -return psi_show (m, &psi_system,PSI_IO ); -} - -static int psi_memory_show (struct seq_file *m,void *v) -{ -return psi_show (m, &psi_system,PSI_MEM ); -} - -static int psi_cpu_show (struct seq_file *m,void *v) -{ -return psi_show (m, &psi_system,PSI_CPU ); -} - -static int psi_open (struct file *file,int (*psi_show)(struct seq_file *,void *)) -{ -if (file->f_mode &FMODE_WRITE && !capable (CAP_SYS_RESOURCE )) -return -EPERM ; - -return single_open (file, psi_show,NULL ); -} - -static int psi_io_open (struct inode *inode,struct file *file) -{ -return psi_open (file, psi_io_show); -} - -static int psi_memory_open (struct inode *inode,struct file *file) -{ -return psi_open (file, psi_memory_show); -} - -static int psi_cpu_open (struct inode *inode,struct file *file) -{ -return psi_open (file, psi_cpu_show); -} -struct psi_trigger *psi_trigger_create (struct psi_group *group,char *buf,size_t nbytes,enum psi_res res) {
@@ -1278,6 +1240,45 @@ __poll_t psi_trigger_poll(void **triggerreturn ret; } +#ifdef CONFIG_PROC_FS +static int psi_io_show (struct seq_file *m,void *v) +{ +return psi_show (m, &psi_system,PSI_IO ); +} + +static int psi_memory_show (struct seq_file *m,void *v) +{ +return psi_show (m, &psi_system,PSI_MEM ); +} + +static int psi_cpu_show (struct seq_file *m,void *v) +{ +return psi_show (m, &psi_system,PSI_CPU ); +} + +static int psi_open (struct file *file,int (*psi_show)(struct seq_file *,void *)) +{ +if (file->f_mode &FMODE_WRITE && !capable (CAP_SYS_RESOURCE )) +return -EPERM ; + +return single_open (file, psi_show,NULL ); +} + +static int psi_io_open (struct inode *inode,struct file *file) +{ +return psi_open (file, psi_io_show); +} + +static int psi_memory_open (struct inode *inode,struct file *file) +{ +return psi_open (file, psi_memory_show); +} + +static int psi_cpu_open (struct inode *inode,struct file *file) +{ +return psi_open (file, psi_cpu_show); +} +static ssize_t psi_write (struct file *file,const char __user *user_buf,size_t nbytes,enum psi_res res) {
@@ -1392,3 +1393,5 @@ static int __init psi_proc_init(void) return 0; }module_init (psi_proc_init); + +#endif /* CONFIG_PROC_FS */
Greg Kroah-Hartman
maintainerPATCH 194/200 usb: dwc3: xilinx: fix uninitialized return value
In reply to Greg Kroah-HartmanFrom: Robert Hancock <[email protected]>
commit b470947c3672f7eb7c4c271d510383d896831cc2 upstream.
A previous patch to skip part of the initialization when a USB3 PHY was not present could result in the return value being uninitialized in that case, causing spurious probe failures. Initialize ret to 0 to avoid this.
--- drivers/usb/dwc3/dwc3-xilinx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/dwc3/dwc3-xilinx.c +1 -1
@@ -99,7 +99,7 @@ static int dwc3_xlnx_init_zynqmp(structstruct device *dev = priv_data->dev;struct reset_control *crst, *hibrst, *apbrst;struct phy *usb3_phy; -int ret; +int ret =0 ;u32 reg; usb3_phy =devm_phy_optional_get (dev,"usb3-phy" );
Greg Kroah-Hartman
maintainerPATCH 195/200 usr/include/Makefile: add linux/nfc.h to the compile-test coverage
In reply to Greg Kroah-HartmanFrom: Dmitry V. Levin <[email protected]>
commit 10756dc5b02bff370ddd351d7744bc99ada659c2 upstream.
As linux/nfc.h userspace compilation was finally fixed by commits 79b69a83705e ("nfc: uapi: use kernel size_t to fix user-space builds") and 7175f02c4e5f ("uapi: fix linux/nfc.h userspace compilation errors"), there is no need to keep the compile-test exception for it in usr/include/Makefile.
--- usr/include/Makefile | 1 - 1 file changed, 1 deletion(-)
usr/include/Makefile +0 -1
@@ -35,7 +35,6 @@ no-header-test += linux/hdlc/ioctl.h no-header-test += linux/ivtv.h no-header-test += linux/kexec.h no-header-test += linux/matroxfb.h -no-header-test += linux/nfc.h no-header-test += linux/omap3isp.h no-header-test += linux/omapfb.h no-header-test += linux/patchkey.h
Greg Kroah-Hartman
maintainerPATCH 196/200 tools/testing/scatterlist: add missing defines
In reply to Greg Kroah-HartmanFrom: Maor Gottlieb <[email protected]>
[ Upstream commit 0226bd64da52aa23120d1450c37a424387827a21 ]
The cited commits replaced preemptible with pagefault_disabled and flush_kernel_dcache_page with flush_dcache_page respectively, hence need to update the corresponding defines in the test.
scatterlist.c: In function ‘sg_miter_stop’:
scatterlist.c:919:4: warning: implicit declaration of function ‘flush_dcache_page’ [-Wimplicit-function-declaration]
flush_dcache_page(miter->page);
^~~~~~~~~~~~~~~~~
In file included from linux/scatterlist.h:8:0,
from scatterlist.c:9:
scatterlist.c:922:18: warning: implicit declaration of function ‘pagefault_disabled’ [-Wimplicit-function-declaration]
WARN_ON_ONCE(!pagefault_disabled());
^
linux/mm.h:23:25: note: in definition of macro ‘WARN_ON_ONCE’
int __ret_warn_on = !!(condition); \
^~~~~~~~~--- tools/testing/scatterlist/linux/mm.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
tools/testing/scatterlist/linux/mm.h +2 -1
@@ -74,7 +74,7 @@ static inline unsigned long page_to_phys __UNIQUE_ID(min1_), __UNIQUE_ID(min2_), \ x, y) -#define preemptible () (1) +#define pagefault_disabled () (0)static inline void *kmap (struct page *page) {
@@ -127,6 +127,7 @@ kmalloc_array(unsigned int n, unsigned i#define kmemleak_free (a)#define PageSlab (p) (0) +#define flush_dcache_page (p)#define MAX_ERRNO 4095
Greg Kroah-Hartman
maintainerPATCH 197/200 KVM: nVMX: Rename vmcs_to_field_offset{,_table}
In reply to Greg Kroah-HartmanFrom: Vitaly Kuznetsov <[email protected]>
commit 2423a4c0d17418eca1ba1e3f48684cb2ab7523d5 upstream.
vmcs_to_field_offset{,_table} may sound misleading as VMCS is an opaque blob which is not supposed to be accessed directly. In fact, vmcs_to_field_offset{,_table} are related to KVM defined VMCS12 structure.
Rename vmcs_field_to_offset() to get_vmcs12_field_offset() for clarity.
No functional change intended.
Message-Id: <[email protected]>
--- arch/x86/kvm/vmx/nested.c | 6 +++--- arch/x86/kvm/vmx/vmcs12.c | 4 ++-- arch/x86/kvm/vmx/vmcs12.h | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-)
arch/x86/kvm/vmx/nested.c +3 -3
@@ -5086,7 +5086,7 @@ static int handle_vmread(struct kvm_vcpu/* Decode instruction info and find the field to read */ field =kvm_register_read (vcpu, (((instr_info) >>28 ) &0xf )); - offset =vmcs_field_to_offset (field); + offset =get_vmcs12_field_offset (field);if (offset <0 )return nested_vmx_fail (vcpu,VMXERR_UNSUPPORTED_VMCS_COMPONENT );
@@ -5189,7 +5189,7 @@ static int handle_vmwrite(struct kvm_vcp field =kvm_register_read (vcpu, (((instr_info) >>28 ) &0xf )); - offset =vmcs_field_to_offset (field); + offset =get_vmcs12_field_offset (field);if (offset <0 )return nested_vmx_fail (vcpu,VMXERR_UNSUPPORTED_VMCS_COMPONENT );
@@ -6435,7 +6435,7 @@ static u64 nested_vmx_calc_vmcs_enum_msr max_idx =0 ;for (i =0 ; i < nr_vmcs12_fields; i++) {/* The vmcs12 table is very, very sparsely populated. */ -if (!vmcs_field_to_offset_table[i]) +if (!vmcs12_field_offsets[i])continue ; idx =vmcs_field_index (VMCS12_IDX_TO_ENC (i));
arch/x86/kvm/vmx/vmcs12.c +2 -2
@@ -8,7 +8,7 @@ FIELD(number, name), \ [ROL16(number##_HIGH, 6)] = VMCS12_OFFSET(name) + sizeof(u32) -const unsigned short vmcs_field_to_offset_table[] = { +const unsigned short vmcs12_field_offsets[] = {FIELD (VIRTUAL_PROCESSOR_ID , virtual_processor_id),FIELD (POSTED_INTR_NV , posted_intr_nv),FIELD (GUEST_ES_SELECTOR , guest_es_selector),
@@ -151,4 +151,4 @@ const unsigned short vmcs_field_to_offseFIELD (HOST_RSP , host_rsp), FIELD(HOST_RIP, host_rip), }; -const unsigned int nr_vmcs12_fields =ARRAY_SIZE (vmcs_field_to_offset_table); +const unsigned int nr_vmcs12_fields =ARRAY_SIZE (vmcs12_field_offsets);
arch/x86/kvm/vmx/vmcs12.h +3 -3
@@ -361,10 +361,10 @@ static inline void vmx_check_vmcs12_offsCHECK_OFFSET (guest_pml_index,996 ); } -extern const unsigned short vmcs_field_to_offset_table[]; +extern const unsigned short vmcs12_field_offsets[];extern const unsigned int nr_vmcs12_fields; -static inline short vmcs_field_to_offset (unsigned long field) +static inline short get_vmcs12_field_offset (unsigned long field) {unsigned short offset;unsigned int index;
@@ -377,7 +377,7 @@ static inline short vmcs_field_to_offsetreturn -ENOENT ; index =array_index_nospec (index, nr_vmcs12_fields); - offset = vmcs_field_to_offset_table[index]; + offset = vmcs12_field_offsets[index];if (offset ==0 )return -ENOENT ;return offset;
Greg Kroah-Hartman
maintainerPATCH 198/200 KVM: nVMX: Implement evmcs_field_offset() suitable for handle_vmread()
In reply to Greg Kroah-HartmanFrom: Vitaly Kuznetsov <[email protected]>
commit 892a42c10ddb945d3a4dcf07dccdf9cb98b21548 upstream.
In preparation to allowing reads from Enlightened VMCS from handle_vmread(), implement evmcs_field_offset() to get the correct read offset. get_evmcs_offset(), which is being used by KVM-on-Hyper-V, is almost what's needed but a few things need to be adjusted. First, WARN_ON() is unacceptable for handle_vmread() as any field can (in theory) be supplied by the guest and not all fields are defined in eVMCS v1. Second, we need to handle 'holes' in eVMCS (missing fields). It also sounds like a good idea to WARN_ON() if such fields are ever accessed by KVM-on-Hyper-V.
Implement dedicated evmcs_field_offset() helper.
No functional change intended.
Message-Id: <[email protected]>
--- arch/x86/kvm/vmx/evmcs.c | 3 +-- arch/x86/kvm/vmx/evmcs.h | 32 ++++++++++++++++++++++++-------- 2 files changed, 25 insertions(+), 10 deletions(-)
arch/x86/kvm/vmx/evmcs.c +1 -2
@@ -12,8 +12,6 @@DEFINE_STATIC_KEY_FALSE (enable_evmcs); -#if IS_ENABLED (CONFIG_HYPERV ) -#define EVMCS1_OFFSET (x) offsetof(struct hv_enlightened_vmcs, x)#define EVMCS1_FIELD (number, name, clean_field)[ROL16(number, 6)] = \ {EVMCS1_OFFSET(name), clean_field}
@@ -296,6 +294,7 @@ const struct evmcs_field vmcs_field_to_e };const unsigned int nr_evmcs_1_fields =ARRAY_SIZE (vmcs_field_to_evmcs_1); +#if IS_ENABLED (CONFIG_HYPERV )__init void evmcs_sanitize_exec_ctrls (struct vmcs_config *vmcs_conf) { vmcs_conf->pin_based_exec_ctrl &= ~EVMCS1_UNSUPPORTED_PINCTRL ;
arch/x86/kvm/vmx/evmcs.h +24 -8
@@ -63,8 +63,6 @@ DECLARE_STATIC_KEY_FALSE(enable_evmcs);#define EVMCS1_UNSUPPORTED_VMENTRY_CTRL (VM_ENTRY_LOAD_IA32_PERF_GLOBAL_CTRL)#define EVMCS1_UNSUPPORTED_VMFUNC (VMX_VMFUNC_EPTP_SWITCHING) -#if IS_ENABLED(CONFIG_HYPERV) -struct evmcs_field {u16 offset;u16 clean_field;
@@ -73,26 +71,44 @@ struct evmcs_field {extern const struct evmcs_field vmcs_field_to_evmcs_1[];extern const unsigned int nr_evmcs_1_fields; -static __always_inline int get_evmcs_offset(unsigned long field, -u16 *clean_field) +static __always_inline int evmcs_field_offset(unsigned long field, +u16 *clean_field) {unsigned int index =ROL16 (field,6 );const struct evmcs_field *evmcs_field; -if (unlikely (index >= nr_evmcs_1_fields)) { -WARN_ONCE (1 ,"KVM: accessing unsupported EVMCS field %lx\n" , - field); +if (unlikely (index >= nr_evmcs_1_fields))return -ENOENT ; - } evmcs_field = &vmcs_field_to_evmcs_1[index]; +/* +* Use offset=0 to detect holes in eVMCS. This offset belongs to +* 'revision_id' but this field has no encoding and is supposed to +* be accessed directly. +*/ +if (unlikely (!evmcs_field->offset)) +return -ENOENT ; +if (clean_field) *clean_field = evmcs_field->clean_field;return evmcs_field->offset; } +#if IS_ENABLED (CONFIG_HYPERV ) + +static __always_inline int get_evmcs_offset(unsigned long field, +u16 *clean_field) +{ +int offset =evmcs_field_offset (field, clean_field); + +WARN_ONCE (offset <0 ,"KVM: accessing unsupported EVMCS field %lx\n" , + field); + +return offset; +} + static __always_inline void evmcs_write64(unsigned long field, u64 value) {u16 clean_field;
Greg Kroah-Hartman
maintainerPATCH 199/200 KVM: nVMX: Allow VMREAD when Enlightened VMCS is in use
In reply to Greg Kroah-HartmanFrom: Vitaly Kuznetsov <[email protected]>
commit 6cbbaab60ff33f59355492c241318046befd9ffc upstream.
Hyper-V TLFS explicitly forbids VMREAD and VMWRITE instructions when Enlightened VMCS interface is in use:
"Any VMREAD or VMWRITE instructions while an enlightened VMCS is active is unsupported and can result in unexpected behavior.""
Windows 11 + WSL2 seems to ignore this, attempts to VMREAD VMCS field 0x4404 ("VM-exit interruption information") are observed. Failing these attempts with nested_vmx_failInvalid() makes such guests unbootable.
Microsoft confirms this is a Hyper-V bug and claims that it'll get fixed eventually but for the time being we need a workaround. (Temporary) allow VMREAD to get data from the currently loaded Enlightened VMCS.
Note: VMWRITE instructions remain forbidden, it is not clear how to handle them properly and hopefully won't ever be needed.
Message-Id: <[email protected]>
--- arch/x86/kvm/vmx/evmcs.h | 12 ++++++++++ arch/x86/kvm/vmx/nested.c | 55 ++++++++++++++++++++++++++++++++-------------- 2 files changed, 51 insertions(+), 16 deletions(-)
arch/x86/kvm/vmx/evmcs.h +12 -0
@@ -96,6 +96,18 @@ static __always_inline int evmcs_field_oreturn evmcs_field->offset; } +static inline u64 evmcs_read_any (struct hv_enlightened_vmcs *evmcs, +unsigned long field,u16 offset) +{ +/* +* vmcs12_read_any() doesn't care whether the supplied structure +* is 'struct vmcs12' or 'struct hv_enlightened_vmcs' as it takes +* the exact offset of the required field, use it for convenience +* here. +*/ +return vmcs12_read_any ((void *)evmcs, field, offset); +} +#if IS_ENABLED (CONFIG_HYPERV ) static __always_inline int get_evmcs_offset(unsigned long field,
arch/x86/kvm/vmx/nested.c +39 -16
72 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 200/200 block: Fix wrong offset in bio_truncate()
In reply to Greg Kroah-HartmanFrom: OGAWA Hirofumi <[email protected]>
commit 3ee859e384d453d6ac68bfd5971f630d9fa46ad3 upstream.
bio_truncate() clears the buffer outside of last block of bdev, however current bio_truncate() is using the wrong offset of page. So it can return the uninitialized data.
This happened when both of truncated/corrupted FS and userspace (via bdev) are trying to read the last of bdev.
--- block/bio.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
block/bio.c +2 -1
@@ -569,7 +569,8 @@ static void bio_truncate(struct bio *bio offset = new_size - done; else offset =0 ; -zero_user (bv.bv_page, offset, bv.bv_len - offset); +zero_user (bv.bv_page, bv.bv_offset + offset, + bv.bv_len - offset); truncated = true; } done += bv.bv_len;
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.16.5 release. There are 200 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 Wed, 02 Feb 2022 10:51:59 +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.16.5-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.16.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v5.16:
10 builds: 10 pass, 0 fail
28 boots: 28 pass, 0 fail
122 tests: 122 pass, 0 failLinux version: 5.16.5-rc1-g04f8430582e6
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04Jon
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.16.5 release. There are 200 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 Wed, 02 Feb 2022 10:51:59 +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.16.5-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.16.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.16.5-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git branch: linux-5.16.y
* git commit: 04f8430582e6a2a7bb728d05119e2d66bd3c819a
* git describe: v5.16.4-201-g04f8430582e6
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.16.y/build/v5.16.4-201-g04f8430582e6
## Test Regressions (compared to v5.16.4-187-g950d978a980e) No test regressions found.
## Metric Regressions (compared to v5.16.4-187-g950d978a980e) No metric regressions found.
## Test Fixes (compared to v5.16.4-187-g950d978a980e) No test fixes found.
## Metric Fixes (compared to v5.16.4-187-g950d978a980e) No metric fixes found.
## Test result summary
total: 84643, pass: 72410, fail: 848, skip: 10560, xfail: 825
## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 259 total, 259 passed, 0 failed
* arm64: 37 total, 37 passed, 0 failed
* dragonboard-410c: 1 total, 1 passed, 0 failed
* hi6220-hikey: 1 total, 1 passed, 0 failed
* i386: 36 total, 36 passed, 0 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 34 total, 34 passed, 0 failed
* parisc: 12 total, 12 passed, 0 failed
* powerpc: 52 total, 48 passed, 4 failed
* riscv: 24 total, 20 passed, 4 failed
* s390: 18 total, 18 passed, 0 failed
* sh: 24 total, 24 passed, 0 failed
* sparc: 12 total, 12 passed, 0 failed
* x15: 1 total, 1 passed, 0 failed
* x86: 1 total, 1 passed, 0 failed
* x86_64: 37 total, 37 passed, 0 failed
## Test suites summary
* fwts
* igt-gpu-tools
* kselftest-
* kselftest-android
* kselftest-arm64
* kselftest-arm64/arm64.btitest.bti_c_func
* kselftest-arm64/arm64.btitest.bti_j_func
* kselftest-arm64/arm64.btitest.bti_jc_func
* kselftest-arm64/arm64.btitest.bti_none_func
* kselftest-arm64/arm64.btitest.nohint_func
* kselftest-arm64/arm64.btitest.paciasp_func
* kselftest-arm64/arm64.nobtitest.bti_c_func
* kselftest-arm64/arm64.nobtitest.bti_j_func
* kselftest-arm64/arm64.nobtitest.bti_jc_func
* kselftest-arm64/arm64.nobtitest.bti_none_func
* kselftest-arm64/arm64.nobtitest.nohint_func
* kselftest-arm64/arm64.nobtitest.paciasp_func
* kselftest-bpf
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-lkdtm
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* 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-vm
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* packetdrill
* perf
* prep-inline
* rcutorture
* ssuite
* v4l2-compliance
--
Linaro LKFT
https://lkft.linaro.org
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.16.5 release. There are 200 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 Wed, 02 Feb 2022 10:51:59 +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.16.5-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.16.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 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.16.5 release. There are 200 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 Wed, 02 Feb 2022 10:51:59 +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.16.5-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.16.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels:
Signature · 1 line
Florian
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.16.5 release. There are 200 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 Wed, 02 Feb 2022 10:51:59 +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.16.5-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.16.y
and the diffstat can be found below.thanks,
greg k-h
Hi Greg,
Compiled and booted on my test system Lenovo P50s: Intel Core i7 No emergency and critical messages in the dmesg
./perf bench sched all
# Running sched/messaging benchmark...
# 20 sender and receiver processes per group
# 10 groups == 400 processes run
Total time: 0.436 [sec]
# Running sched/pipe benchmark...
# Executed 1000000 pipe operations between two processes
Total time: 7.170 [sec]
7.170326 usecs/op
139463 ops/secThanks
-Zan
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.16.5 release. There are 200 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 Wed, 02 Feb 2022 10:51:59 +0000. Anything received after that time might be too late.
Build results:
total: 155 pass: 154 fail: 1 Failed builds: powerpc:ppc32_allmodconfig Qemu test results: total: 488 pass: 488 fail: 0
As with v5.15.y, the build error is not new and fixed with commit 33a0da68fb07 ("mtd: rawnand: mpc5121: Remove unused variable in ads5121_select_chip()").
Guenter
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.16.5 release. There are 200 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 Wed, 02 Feb 2022 10:51:59 +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.16.5-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.16.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.16.5 release. There are 200 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.
Successfully compiled and booted on my system (x86_64 localmodconfig). Also successfully cross-compiled for arm64 (bcm2711_defconfig taken from raspberry pi kernel sources) and ppc64 (gamecube_defconfig).
Signature · 1 line
An old man doll... just what I always wanted! - Clara
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.16.5 release. There are 200 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 Wed, 02 Feb 2022 10:51:59 +0000. Anything received after that time might be too late.
Hi Greg,
5.16.5-rc1 tested.
Run tested on:
- Allwinner H6 (Tanix TX6)
- Intel Tiger Lake x86_64 (nuc11 i7-1165G7)
In addition - build tested on:
- Allwinner A64
- Allwinner H3
- Allwinner H5
- NXP iMX6
- NXP iMX8
- Qualcomm Dragonboard
- Rockchip RK3288
- Rockchip RK3328
- Rockchip RK3399pro
- Samsung Exynos
--
Rudi
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.16.5 release. There are 200 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 Wed, 02 Feb 2022 10:51:59 +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.16.5-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.16.y
and the diffstat can be found below.thanks,
greg k-h
5.16.5-rc1 Successfully Compiled and booted on my Raspberry PI 4b (8g) (bcm2711)