5.17.4-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainerPATCH 159/219 net: usb: aqc111: Fix out-of-bounds accesses in RX fixup
In reply to Greg Kroah-HartmanFrom: Marcin Kozlowski <[email protected]>
[ Upstream commit afb8e246527536848b9b4025b40e613edf776a9d ]
aqc111_rx_fixup() contains several out-of-bounds accesses that can be triggered by a malicious (or defective) USB device, in particular:
- The metadata array (desc_offset..desc_offset+2*pkt_count) can be out of bounds, causing OOB reads and (on big-endian systems) OOB endianness flips.
- A packet can overlap the metadata array, causing a later OOB endianness flip to corrupt data used by a cloned SKB that has already been handed off into the network stack.
- A packet SKB can be constructed whose tail is far beyond its end, causing out-of-bounds heap data to be considered part of the SKB's data.
Found doing variant analysis. Tested it with another driver (ax88179_178a), since I don't have a aqc111 device to test it, but the code looks very similar.
--- drivers/net/usb/aqc111.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
drivers/net/usb/aqc111.c +7 -2
@@ -1102,10 +1102,15 @@ static int aqc111_rx_fixup(struct usbnet *dev, struct sk_buff *skb)if (start_of_descs != desc_offset) goto err; -/* self check desc_offset from header*/ -if (desc_offset >= skb_len) +/* self check desc_offset from header and make sure that the +* bounds of the metadata array are inside the SKB +*/ +if (pkt_count *2 + desc_offset >= skb_len) goto err; +/* Packets must not overlap the metadata array */ +skb_trim (skb, desc_offset); +if (pkt_count ==0 ) goto err;
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 160/219 myri10ge: fix an incorrect free for skb in myri10ge_sw_tso
In reply to Greg Kroah-HartmanFrom: Xiaomeng Tong <[email protected]>
[ Upstream commit b423e54ba965b4469b48e46fd16941f1e1701697 ]
All remaining skbs should be released when myri10ge_xmit fails to transmit a packet. Fix it within another skb_list_walk_safe.
--- drivers/net/ethernet/myricom/myri10ge/myri10ge.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
drivers/net/ethernet/myricom/myri10ge/myri10ge.c +2 -4
@@ -2903,11 +2903,9 @@ static netdev_tx_t myri10ge_sw_tso(struct sk_buff *skb, status =myri10ge_xmit (curr, dev);if (status !=0 ) {dev_kfree_skb_any (curr); -if (segs !=NULL ) { - curr = segs; - segs = next; + skb_list_walk_safe(next, curr, next) { curr->next =NULL ; -dev_kfree_skb_any (segs); +dev_kfree_skb_any (curr); } goto drop; }
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 161/219 spi: cadence-quadspi: fix protocol setup for non-1-1-X operations
In reply to Greg Kroah-HartmanFrom: Matthias Schiffer <[email protected]>
[ Upstream commit 97e4827d775faa9a32b5e1a97959c69dd77d17a3 ]
cqspi_set_protocol() only set the data width, but ignored the command and address width (except for 8-8-8 DTR ops), leading to corruption of all transfers using 1-X-X or X-X-X ops. Fix by setting the other two widths as well.
While we're at it, simplify the code a bit by replacing the CQSPI_INST_TYPE_* constants with ilog2().
Tested on a TI AM64x with a Macronix MX25U51245G QSPI flash with 1-4-4 read and write operations.
--- drivers/spi/spi-cadence-quadspi.c | 46 ++++++++----------------------- 1 file changed, 12 insertions(+), 34 deletions(-)
drivers/spi/spi-cadence-quadspi.c +12 -34
@@ -19,6 +19,7 @@#include <linux/iopoll.h> #include <linux/jiffies.h> #include <linux/kernel.h> +#include <linux/log2.h> #include <linux/module.h> #include <linux/of_device.h> #include <linux/of.h>
@@ -102,12 +103,6 @@ struct cqspi_driver_platdata {#define CQSPI_TIMEOUT_MS 500#define CQSPI_READ_TIMEOUT_MS 10 -/* Instruction type */ -#define CQSPI_INST_TYPE_SINGLE 0 -#define CQSPI_INST_TYPE_DUAL 1 -#define CQSPI_INST_TYPE_QUAD 2 -#define CQSPI_INST_TYPE_OCTAL 3 -#define CQSPI_DUMMY_CLKS_PER_BYTE 8#define CQSPI_DUMMY_BYTES_MAX 4#define CQSPI_DUMMY_CLKS_MAX 31
@@ -376,10 +371,6 @@ static unsigned int cqspi_calc_dummy(const struct spi_mem_op *op, bool dtr)static int cqspi_set_protocol (struct cqspi_flash_pdata *f_pdata,const struct spi_mem_op *op) { - f_pdata->inst_width =CQSPI_INST_TYPE_SINGLE ; - f_pdata->addr_width =CQSPI_INST_TYPE_SINGLE ; - f_pdata->data_width =CQSPI_INST_TYPE_SINGLE ; -/* * For an op to be DTR, cmd phase along with every other non-empty * phase should have dtr field set to 1. If an op phase has zero
@@ -389,32 +380,23 @@ static int cqspi_set_protocol(struct cqspi_flash_pdata *f_pdata, (!op->addr.nbytes || op->addr.dtr) && (!op->data.nbytes || op->data.dtr); -switch (op->data.buswidth) { -case 0 : -break ; -case 1 : - f_pdata->data_width =CQSPI_INST_TYPE_SINGLE ; -break ; -case 2 : - f_pdata->data_width =CQSPI_INST_TYPE_DUAL ; -break ; -case 4 : - f_pdata->data_width =CQSPI_INST_TYPE_QUAD ; -break ; -case 8 : - f_pdata->data_width =CQSPI_INST_TYPE_OCTAL ; -break ; -default : -return -EINVAL ; - } + f_pdata->inst_width =0 ; +if (op->cmd.buswidth) + f_pdata->inst_width =ilog2 (op->cmd.buswidth); + + f_pdata->addr_width =0 ; +if (op->addr.buswidth) + f_pdata->addr_width =ilog2 (op->addr.buswidth); + + f_pdata->data_width =0 ; +if (op->data.buswidth) + f_pdata->data_width =ilog2 (op->data.buswidth);/* Right now we only support 8-8-8 DTR mode. */ if (f_pdata->dtr) {switch (op->cmd.buswidth) {case 0 : -break ;case 8 : - f_pdata->inst_width =CQSPI_INST_TYPE_OCTAL ;break ;default :return -EINVAL ;
@@ -422,9 +404,7 @@ static int cqspi_set_protocol(struct cqspi_flash_pdata *f_pdata,switch (op->addr.buswidth) {case 0 : -break ;case 8 : - f_pdata->addr_width =CQSPI_INST_TYPE_OCTAL ;break ;default :return -EINVAL ;
@@ -432,9 +412,7 @@ static int cqspi_set_protocol(struct cqspi_flash_pdata *f_pdata,switch (op->data.buswidth) {case 0 : -break ;case 8 : - f_pdata->data_width =CQSPI_INST_TYPE_OCTAL ;break ;default :return -EINVAL ;
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 162/219 drm/amd/display: Correct Slice reset calculation
In reply to Greg Kroah-HartmanFrom: Chris Park <[email protected]>
[ Upstream commit 862a876c3a6372f2fa9d0c6510f1976ac94fc857 ]
[Why]
Once DSC slice cannot fit pixel clock, we incorrectly reset min slices to 0 and allow max slice to operate, even when max slice itself cannot fit the pixel clock properly.
[How]
Change the sequence such that we correctly determine DSC is not possible when both min slices and max slices cannot fit pixel clock per slice.
--- drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c +2 -2
@@ -864,11 +864,11 @@ static bool setup_dsc_config( min_slices_h =inc_num_slices (dsc_common_caps.slice_caps, min_slices_h); } + is_dsc_possible = (min_slices_h <= max_slices_h); +if (pic_width % min_slices_h !=0 ) min_slices_h =0 ;// DSC TODO: Maybe try increasing the number of slices first? - is_dsc_possible = (min_slices_h <= max_slices_h); -if (min_slices_h ==0 && max_slices_h ==0 ) is_dsc_possible = false;
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 163/219 drm/amd/display: Enable power gating before init_pipes
In reply to Greg Kroah-HartmanFrom: Roman Li <[email protected]>
[ Upstream commit 58e16c752e9540b28a873c44c3bee83e022007c1 ]
[Why]
In init_hw() we call init_pipes() before enabling power gating. init_pipes() tries to power gate dsc but it may fail because required force-ons are not released yet.
As a result with dsc config the following errors observed on resume:
"REG_WAIT timeout 1us * 1000 tries - dcn20_dsc_pg_control" "REG_WAIT timeout 1us * 1000 tries - dcn20_dpp_pg_control" "REG_WAIT timeout 1us * 1000 tries - dcn20_hubp_pg_control"
[How]
Move enable_power_gating_plane() before init_pipes() in init_hw()
--- drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 5 +++-- drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c | 5 +++-- drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hwseq.c | 5 +++-- 3 files changed, 9 insertions(+), 6 deletions(-)
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c +3 -2
@@ -1501,6 +1501,9 @@ void dcn10_init_hw(struct dc *dc)if (dc->config.power_down_display_on_boot)dc_link_blank_all_dp_displays (dc); +if (hws->funcs.enable_power_gating_plane) + hws->funcs.enable_power_gating_plane (dc->hwseq, true); +/* If taking control over from VBIOS, we may want to optimize our first * mode set, so we need to skip powering down pipes until we know which * pipes we want to use.
@@ -1553,8 +1556,6 @@ void dcn10_init_hw(struct dc *dc)REG_UPDATE (DCFCLK_CNTL ,DCFCLK_GATE_DIS ,0 ); } -if (hws->funcs.enable_power_gating_plane) - hws->funcs.enable_power_gating_plane (dc->hwseq, true);if (dc->clk_mgr->funcs->notify_wm_ranges) dc->clk_mgr->funcs->notify_wm_ranges (dc->clk_mgr);
drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c +3 -2
@@ -548,6 +548,9 @@ void dcn30_init_hw(struct dc *dc)if (dc->config.power_down_display_on_boot)dc_link_blank_all_dp_displays (dc); +if (hws->funcs.enable_power_gating_plane) + hws->funcs.enable_power_gating_plane (dc->hwseq, true); +/* If taking control over from VBIOS, we may want to optimize our first * mode set, so we need to skip powering down pipes until we know which * pipes we want to use.
@@ -625,8 +628,6 @@ void dcn30_init_hw(struct dc *dc)REG_UPDATE (DCFCLK_CNTL ,DCFCLK_GATE_DIS ,0 ); } -if (hws->funcs.enable_power_gating_plane) - hws->funcs.enable_power_gating_plane (dc->hwseq, true);if (!dcb->funcs->is_accelerated_mode (dcb) && dc->res_pool->hubbub->funcs->init_watermarks) dc->res_pool->hubbub->funcs->init_watermarks (dc->res_pool->hubbub);
drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hwseq.c +3 -2
@@ -200,6 +200,9 @@ void dcn31_init_hw(struct dc *dc)if (dc->config.power_down_display_on_boot)dc_link_blank_all_dp_displays (dc); +if (hws->funcs.enable_power_gating_plane) + hws->funcs.enable_power_gating_plane (dc->hwseq, true); +/* If taking control over from VBIOS, we may want to optimize our first * mode set, so we need to skip powering down pipes until we know which * pipes we want to use.
@@ -249,8 +252,6 @@ void dcn31_init_hw(struct dc *dc)REG_UPDATE (DCFCLK_CNTL ,DCFCLK_GATE_DIS ,0 ); } -if (hws->funcs.enable_power_gating_plane) - hws->funcs.enable_power_gating_plane (dc->hwseq, true);if (!dcb->funcs->is_accelerated_mode (dcb) && dc->res_pool->hubbub->funcs->init_watermarks) dc->res_pool->hubbub->funcs->init_watermarks (dc->res_pool->hubbub);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 164/219 drm/amd/display: Revert FEC check in validation
In reply to Greg Kroah-HartmanFrom: Martin Leung <[email protected]>
[ Upstream commit b2075fce104b88b789c15ef1ed2b91dc94198e26 ]
why and how:
causes failure on install on certain machines
--- drivers/gpu/drm/amd/display/dc/core/dc.c | 4 ---- 1 file changed, 4 deletions(-)
drivers/gpu/drm/amd/display/dc/core/dc.c +0 -4
@@ -1495,10 +1495,6 @@ bool dc_validate_seamless_boot_timing(const struct dc *dc,if (!link->link_enc->funcs->is_dig_enabled (link->link_enc))return false; -/* Check for FEC status*/ -if (link->link_enc->funcs->fec_is_active (link->link_enc)) -return false; - enc_inst = link->link_enc->funcs->get_dig_frontend (link->link_enc);if (enc_inst ==ENGINE_ID_UNKNOWN )
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 165/219 drm/amd/display: Fix allocate_mst_payload assert on resume
In reply to Greg Kroah-HartmanFrom: Roman Li <[email protected]>
[ Upstream commit f4346fb3edf7720db3f7f5e1cab1f667cd024280 ]
[Why]
On resume we do link detection for all non-MST connectors. MST is handled separately. However the condition for telling if connector is on mst branch is not enough for mst hub case. Link detection for mst branch link leads to mst topology reset. That causes assert in dc_link_allocate_mst_payload()
[How]
Use link type as indicator for mst link.
--- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +2 -1
@@ -2693,7 +2693,8 @@ static int dm_resume(void *handle)* this is the case when traversing through already created * MST connectors, should be skipped */ -if (aconnector->mst_port) +if (aconnector->dc_link && + aconnector->dc_link->type == dc_connection_mst_branch)continue ;mutex_lock (&aconnector->hpd_lock);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 166/219 drbd: set QUEUE_FLAG_STABLE_WRITES
In reply to Greg Kroah-HartmanFrom: Christoph Böhmwalder <[email protected]>
[ Upstream commit 286901941fd18a52b2138fddbbf589ad3639eb00 ]
We want our pages not to change while they are being written.
--- drivers/block/drbd/drbd_main.c | 1 + 1 file changed, 1 insertion(+)
drivers/block/drbd/drbd_main.c +1 -0
@@ -2739,6 +2739,7 @@ enum drbd_ret_code drbd_create_device(struct drbd_config_context *adm_ctx, unsigsprintf (disk->disk_name,"drbd%d" , minor); disk->private_data = device; +blk_queue_flag_set (QUEUE_FLAG_STABLE_WRITES , disk->queue);blk_queue_write_cache (disk->queue, true, true);/* Setting the max_hw_sectors to an odd value of 8kibyte here This triggers a max_bio_size message upon first attach or connect */
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 167/219 scsi: mpt3sas: Fail reset operation if config request timed out
In reply to Greg Kroah-HartmanFrom: Sreekanth Reddy <[email protected]>
[ Upstream commit f61eb1216c959f93ffabd3b8781fa5b2b22f8907 ]
As part of controller reset operation the driver issues a config request command. If this command gets times out, then fail the controller reset operation instead of retrying it.
--- drivers/scsi/mpt3sas/mpt3sas_config.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
drivers/scsi/mpt3sas/mpt3sas_config.c +6 -3
@@ -394,10 +394,13 @@ _config_request(struct MPT3SAS_ADAPTER *ioc, Mpi2ConfigRequest_t retry_count++;if (ioc->config_cmds.smid == smid)mpt3sas_base_free_smid (ioc, smid); -if ((ioc->shost_recovery) || (ioc->config_cmds.status & -MPT3_CMD_RESET ) || ioc->pci_error_recovery) +if (ioc->config_cmds.status &MPT3_CMD_RESET ) goto retry_config; - issue_host_reset =1 ; +if (ioc->shost_recovery || ioc->pci_error_recovery) { + issue_host_reset =0 ; + r = -EFAULT ; + }else + issue_host_reset =1 ; goto free_mem; }
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 168/219 scsi: mvsas: Add PCI ID of RocketRaid 2640
In reply to Greg Kroah-HartmanFrom: Alexey Galakhov <[email protected]>
[ Upstream commit 5f2bce1e222028dc1c15f130109a17aa654ae6e8 ]
The HighPoint RocketRaid 2640 is a low-cost SAS controller based on Marvell chip. The chip in question was already supported by the kernel, just the PCI ID of this particular board was missing.
--- drivers/scsi/mvsas/mv_init.c | 1 + 1 file changed, 1 insertion(+)
drivers/scsi/mvsas/mv_init.c +1 -0
@@ -646,6 +646,7 @@ static struct pci_device_id mvs_pci_table[] = { { PCI_VDEVICE(ARECA, PCI_DEVICE_ID_ARECA_1300), chip_1300 }, { PCI_VDEVICE(ARECA, PCI_DEVICE_ID_ARECA_1320), chip_1320 }, { PCI_VDEVICE(ADAPTEC2, 0x0450), chip_6440 }, + { PCI_VDEVICE(TTI, 0x2640), chip_6440 }, { PCI_VDEVICE(TTI, 0x2710), chip_9480 }, { PCI_VDEVICE(TTI, 0x2720), chip_9480 }, { PCI_VDEVICE(TTI, 0x2721), chip_9480 },
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 169/219 scsi: megaraid_sas: Target with invalid LUN ID is deleted during scan
In reply to Greg Kroah-HartmanFrom: Chandrakanth patil <[email protected]>
[ Upstream commit 56495f295d8e021f77d065b890fc0100e3f9f6d8 ]
The megaraid_sas driver supports single LUN for RAID devices. That is LUN
0. All other LUNs are unsupported. When a device scan on a logical target with invalid LUN number is invoked through sysfs, that target ends up getting removed.
Add LUN ID validation in the slave destroy function to avoid the target deletion.
--- drivers/scsi/megaraid/megaraid_sas.h | 3 +++ drivers/scsi/megaraid/megaraid_sas_base.c | 7 +++++++ 2 files changed, 10 insertions(+)
drivers/scsi/megaraid/megaraid_sas.h +3 -0
@@ -2558,6 +2558,9 @@ struct megasas_instance_template {#define MEGASAS_IS_LOGICAL (sdev) \ ((sdev->channel < MEGASAS_MAX_PD_CHANNELS) ? 0 : 1) +#define MEGASAS_IS_LUN_VALID (sdev) \ + (((sdev)->lun == 0) ? 1 : 0) +#define MEGASAS_DEV_INDEX (scp) \ (((scp->device->channel % 2) * MEGASAS_MAX_DEV_PER_CHANNEL) + \ scp->device->id)
drivers/scsi/megaraid/megaraid_sas_base.c +7 -0
@@ -2126,6 +2126,9 @@ static int megasas_slave_alloc(struct scsi_device *sdev) goto scan_target; }return -ENXIO ; + }else if (!MEGASAS_IS_LUN_VALID (sdev)) { +sdev_printk (KERN_INFO , sdev,"%s: invalid LUN\n" , __func__); +return -ENXIO ; } scan_target:
@@ -2156,6 +2159,10 @@ static void megasas_slave_destroy(struct scsi_device *sdev) instance =megasas_lookup_instance (sdev->host->host_no);if (MEGASAS_IS_LOGICAL (sdev)) { +if (!MEGASAS_IS_LUN_VALID (sdev)) { +sdev_printk (KERN_INFO , sdev,"%s: invalid LUN\n" , __func__); +return ; + } ld_tgt_id =MEGASAS_TARGET_ID (sdev); instance->ld_tgtid_status[ld_tgt_id] =LD_TARGET_ID_DELETED ;if (megasas_dbg_lvl &LD_PD_DEBUG )
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 170/219 drivers: net: slip: fix NPD bug in sl_tx_timeout()
In reply to Greg Kroah-HartmanFrom: Duoming Zhou <[email protected]>
[ Upstream commit ec4eb8a86ade4d22633e1da2a7d85a846b7d1798 ]
When a slip driver is detaching, the slip_close() will act to cleanup necessary resources and sl->tty is set to NULL in slip_close(). Meanwhile, the packet we transmit is blocked, sl_tx_timeout() will be called. Although slip_close() and sl_tx_timeout() use sl->lock to synchronize, we don`t judge whether sl->tty equals to NULL in sl_tx_timeout() and the null pointer dereference bug will happen.
(Thread 1) | (Thread 2)
| slip_close()
| spin_lock_bh(&sl->lock)
| ...
... | sl->tty = NULL //(1)
sl_tx_timeout() | spin_unlock_bh(&sl->lock)
spin_lock(&sl->lock); |
... | ...
tty_chars_in_buffer(sl->tty)|
if (tty->ops->..) //(2) |
... | synchronize_rcu()We set NULL to sl->tty in position (1) and dereference sl->tty in position (2).
This patch adds check in sl_tx_timeout(). If sl->tty equals to NULL, sl_tx_timeout() will goto out.
--- drivers/net/slip/slip.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/slip/slip.c +1 -1
@@ -469,7 +469,7 @@ static void sl_tx_timeout(struct net_device *dev, unsigned int txqueue)spin_lock (&sl->lock);if (netif_queue_stopped (dev)) { -if (!netif_running (dev)) +if (!netif_running (dev) || !sl->tty) goto out;/* May be we must check transmitter timeout here ?
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 171/219 x86,bpf: Avoid IBT objtool warning
In reply to Greg Kroah-HartmanFrom: Peter Zijlstra <[email protected]>
[ Upstream commit be8a096521ca1a252bf078b347f96ce94582612e ]
Clang can inline emit_indirect_jump() and then folds constants, which results in:
| vmlinux.o: warning: objtool: emit_bpf_dispatcher()+0x6a4: relocation to !ENDBR: .text.__x86.indirect_thunk+0x40 | vmlinux.o: warning: objtool: emit_bpf_dispatcher()+0x67d: relocation to !ENDBR: .text.__x86.indirect_thunk+0x40 | vmlinux.o: warning: objtool: emit_bpf_tail_call_indirect()+0x386: relocation to !ENDBR: .text.__x86.indirect_thunk+0x20 | vmlinux.o: warning: objtool: emit_bpf_tail_call_indirect()+0x35d: relocation to !ENDBR: .text.__x86.indirect_thunk+0x20
Suppress the optimization such that it must emit a code reference to the __x86_indirect_thunk_array[] base.
--- arch/x86/net/bpf_jit_comp.c | 1 + 1 file changed, 1 insertion(+)
arch/x86/net/bpf_jit_comp.c +1 -0
@@ -398,6 +398,7 @@ static void emit_indirect_jump(u8 **pprog, int reg, u8 *ip)EMIT_LFENCE (); EMIT2(0xFF, 0xE0 + reg); }else if (cpu_feature_enabled (X86_FEATURE_RETPOLINE )) { +OPTIMIZER_HIDE_VAR (reg);emit_jump (&prog, &__x86_indirect_thunk_array[reg], ip); } else#endif
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 172/219 io_uring: zero tag on rsrc removal
In reply to Greg Kroah-HartmanFrom: Pavel Begunkov <[email protected]>
[ Upstream commit 8f0a24801bb44aa58496945aabb904c729176772 ]
Automatically default rsrc tag in io_queue_rsrc_removal(), it's safer than leaving it there and relying on the rest of the code to behave and not use it.
--- fs/io_uring.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
fs/io_uring.c +3 -1
@@ -8536,13 +8536,15 @@ static int io_sqe_file_register(struct io_ring_ctx *ctx, struct file *file,static int io_queue_rsrc_removal (struct io_rsrc_data *data,unsigned idx,struct io_rsrc_node *node,void *rsrc) { +u64 *tag_slot =io_get_tag_slot (data, idx);struct io_rsrc_put *prsrc; prsrc =kzalloc (sizeof (*prsrc),GFP_KERNEL );if (!prsrc)return -ENOMEM ; - prsrc->tag = *io_get_tag_slot (data, idx); + prsrc->tag = *tag_slot; + *tag_slot =0 ; prsrc->rsrc = rsrc;list_add (&prsrc->list, &node->rsrc_list);return 0 ;
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 173/219 io_uring: use nospec annotation for more indexes
In reply to Greg Kroah-HartmanFrom: Pavel Begunkov <[email protected]>
[ Upstream commit 4cdd158be9d09223737df83136a1fb65269d809a ]
There are still several places that using pre array_index_nospec() indexes, fix them up.
--- fs/io_uring.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-)
fs/io_uring.c +5 -6
@@ -8613,7 +8613,7 @@ static int io_close_fixed(struct io_kiocb *req, unsigned int issue_flags)bool needs_lock = issue_flags &IO_URING_F_UNLOCKED ;struct io_fixed_file *file_slot;struct file *file; -int ret, i; +int ret;io_ring_submit_lock (ctx, needs_lock); ret = -ENXIO ;
@@ -8626,8 +8626,8 @@ static int io_close_fixed(struct io_kiocb *req, unsigned int issue_flags)if (ret) goto out; - i =array_index_nospec (offset, ctx->nr_user_files); - file_slot =io_fixed_file_slot (&ctx->file_table, i); + offset =array_index_nospec (offset, ctx->nr_user_files); + file_slot =io_fixed_file_slot (&ctx->file_table, offset); ret = -EBADF ;if (!file_slot->file_ptr) goto out;
@@ -8683,8 +8683,7 @@ static int __io_sqe_files_update(struct io_ring_ctx *ctx,if (file_slot->file_ptr) { file = (struct file *)(file_slot->file_ptr &FFS_MASK ); - err =io_queue_rsrc_removal (data, up->offset + done, - ctx->rsrc_node, file); + err =io_queue_rsrc_removal (data, i, ctx->rsrc_node, file);if (err)break ; file_slot->file_ptr =0 ;
@@ -9357,7 +9356,7 @@ static int __io_sqe_buffers_update(struct io_ring_ctx *ctx, i =array_index_nospec (offset, ctx->nr_user_bufs);if (ctx->user_bufs[i] != ctx->dummy_ubuf) { - err =io_queue_rsrc_removal (ctx->buf_data, offset, + err =io_queue_rsrc_removal (ctx->buf_data, i, ctx->rsrc_node, ctx->user_bufs[i]);if (unlikely (err)) {io_buffer_unmap (ctx, &imu);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 174/219 perf/imx_ddr: Fix undefined behavior due to shift overflowing the constant
In reply to Greg Kroah-HartmanFrom: Borislav Petkov <[email protected]>
[ Upstream commit d02b4dd84e1a90f7f1444d027c0289bf355b0d5a ]
Fix:
In file included from <command-line>:0:0:
In function ‘ddr_perf_counter_enable’,
inlined from ‘ddr_perf_irq_handler’ at drivers/perf/fsl_imx8_ddr_perf.c:651:2:
././include/linux/compiler_types.h:352:38: error: call to ‘__compiletime_assert_729’ \
declared with attribute error: FIELD_PREP: mask is not constant
_compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
...
See https://lore.kernel.org/r/YkwQ6%[email protected] for the gory details as to why it triggers with older gccs only.
--- drivers/perf/fsl_imx8_ddr_perf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/perf/fsl_imx8_ddr_perf.c +1 -1
@@ -29,7 +29,7 @@#define CNTL_OVER_MASK 0xFFFFFFFE#define CNTL_CSV_SHIFT 24 -#define CNTL_CSV_MASK (0xFF << CNTL_CSV_SHIFT) +#define CNTL_CSV_MASK (0xFFU << CNTL_CSV_SHIFT)#define EVENT_CYCLES_ID 0#define EVENT_CYCLES_COUNTER 0
Signature · 9 lines
2.35.1 _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Greg Kroah-Hartman
maintainerPATCH 175/219 mm/secretmem: fix panic when growing a memfd_secret
In reply to Greg Kroah-HartmanFrom: Axel Rasmussen <[email protected]>
commit f9b141f93659e09a52e28791ccbaf69c273b8e92 upstream.
When one tries to grow an existing memfd_secret with ftruncate, one gets a panic [1]. For example, doing the following reliably induces the panic:
fd = memfd_secret();
ftruncate(fd, 10);
ptr = mmap(NULL, 10, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
strcpy(ptr, "123456789");
munmap(ptr, 10);
ftruncate(fd, 20);The basic reason for this is, when we grow with ftruncate, we call down into simple_setattr, and then truncate_inode_pages_range, and eventually we try to zero part of the memory. The normal truncation code does this via the direct map (i.e., it calls page_address() and hands that to memset()).
For memfd_secret though, we specifically don't map our pages via the direct map (i.e. we call set_direct_map_invalid_noflush() on every fault). So the address returned by page_address() isn't useful, and when we try to memset() with it we panic.
This patch avoids the panic by implementing a custom setattr for memfd_secret, which detects resizes specifically (setting the size for the first time works just fine, since there are no existing pages to try to zero), and rejects them with EINVAL.
One could argue growing should be supported, but I think that will require a significantly more lengthy change. So, I propose a minimal fix for the benefit of stable kernels, and then perhaps to extend memfd_secret to support growing in a separate patch.
[1]:
BUG: unable to handle page fault for address: ffffa0a889277028 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD afa01067 P4D afa01067 PUD 83f909067 PMD 83f8bf067 PTE 800ffffef6d88060 Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI CPU: 0 PID: 281 Comm: repro Not tainted 5.17.0-dbg-DEV #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:memset_erms+0x9/0x10 Code: c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 f3 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 <f3> aa 4c 89 c8 c3 90 49 89 fa 40 0f b6 ce 48 b8 01 01 01 01 01 01 RSP: 0018:ffffb932c09afbf0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffda63c4249dc0 RCX: 0000000000000fd8 RDX: 0000000000000fd8 RSI: 0000000000000000 RDI: ffffa0a889277028 RBP: ffffb932c09afc00 R08: 0000000000001000 R09: ffffa0a889277028 R10: 0000000000020023 R11: 0000000000000000 R12: ffffda63c4249dc0 R13: ffffa0a890d70d98 R14: 0000000000000028 R15: 0000000000000fd8 FS: 00007f7294899580(0000) GS:ffffa0af9bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffa0a889277028 CR3: 0000000107ef6006 CR4: 0000000000370ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? zero_user_segments+0x82/0x190 truncate_inode_partial_folio+0xd4/0x2a0 truncate_inode_pages_range+0x380/0x830 truncate_setsize+0x63/0x80 simple_setattr+0x37/0x60 notify_change+0x3d8/0x4d0 do_sys_ftruncate+0x162/0x1d0 __x64_sys_ftruncate+0x1c/0x20 do_syscall_64+0x44/0xa0 entry_SYSCALL_64_after_hwframe+0x44/0xae Modules linked in: xhci_pci xhci_hcd virtio_net net_failover failover virtio_blk virtio_balloon uhci_hcd ohci_pci ohci_hcd evdev ehci_pci ehci_hcd 9pnet_virtio 9p netfs 9pnet CR2: ffffa0a889277028
--- mm/secretmem.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)
mm/secretmem.c +17 -0
@@ -158,6 +158,22 @@ const struct address_space_operations se .isolate_page = secretmem_isolate_page, }; +static int secretmem_setattr (struct user_namespace *mnt_userns, +struct dentry *dentry,struct iattr *iattr) +{ +struct inode *inode =d_inode (dentry); +unsigned int ia_valid = iattr->ia_valid; + +if ((ia_valid &ATTR_SIZE ) && inode->i_size) +return -EINVAL ; + +return simple_setattr (mnt_userns, dentry, iattr); +} + +static const struct inode_operations secretmem_iops = { + .setattr = secretmem_setattr, +}; +static struct vfsmount *secretmem_mnt;static struct file *secretmem_file_create (unsigned long flags)
@@ -177,6 +193,7 @@ static struct file *secretmem_file_creatmapping_set_gfp_mask (inode->i_mapping,GFP_HIGHUSER );mapping_set_unevictable (inode->i_mapping); + inode->i_op = &secretmem_iops; inode->i_mapping->a_ops = &secretmem_aops;/* pretend we are a normal file with zero size */
Greg Kroah-Hartman
maintainerPATCH 176/219 mm, page_alloc: fix build_zonerefs_node()
In reply to Greg Kroah-HartmanFrom: Juergen Gross <[email protected]>
commit e553f62f10d93551eb883eca227ac54d1a4fad84 upstream.
Since commit 6aa303defb74 ("mm, vmscan: only allocate and reclaim from zones with pages managed by the buddy allocator") only zones with free memory are included in a built zonelist. This is problematic when e.g. all memory of a zone has been ballooned out when zonelists are being rebuilt.
The decision whether to rebuild the zonelists when onlining new memory is done based on populated_zone() returning 0 for the zone the memory will be added to. The new zone is added to the zonelists only, if it has free memory pages (managed_zone() returns a non-zero value) after the memory has been onlined. This implies, that onlining memory will always free the added pages to the allocator immediately, but this is not true in all cases: when e.g. running as a Xen guest the onlined new memory will be added only to the ballooned memory list, it will be freed only when the guest is being ballooned up afterwards.
Another problem with using managed_zone() for the decision whether a zone is being added to the zonelists is, that a zone with all memory used will in fact be removed from all zonelists in case the zonelists happen to be rebuilt.
Use populated_zone() when building a zonelist as it has been done before that commit.
There was a report that QubesOS (based on Xen) is hitting this problem. Xen has switched to use the zone device functionality in kernel 5.9 and QubesOS wants to use memory hotplugging for guests in order to be able to start a guest with minimal memory and expand it as needed. This was the report leading to the patch.
--- mm/page_alloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
mm/page_alloc.c +1 -1
@@ -6112,7 +6112,7 @@ static int build_zonerefs_node(pg_data_t do { zone_type--; zone = pgdat->node_zones + zone_type; - if (managed_zone(zone)) { + if (populated_zone(zone)) { zoneref_set_zone(zone, &zonerefs[nr_zones++]); check_highest_zone(zone_type); }
Greg Kroah-Hartman
maintainerPATCH 177/219 mm: fix unexpected zeroed page mapping with zram swap
In reply to Greg Kroah-HartmanFrom: Minchan Kim <[email protected]>
commit e914d8f00391520ecc4495dd0ca0124538ab7119 upstream.
Two processes under CLONE_VM cloning, user process can be corrupted by seeing zeroed page unexpectedly.
CPU A CPU B
do_swap_page do_swap_page
SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path
swap_readpage valid data
swap_slot_free_notify
delete zram entry
swap_readpage zeroed(invalid) data pte_lock
map the *zero data* to userspace pte_unlock
pte_lock
if (!pte_same)
goto out_nomap;
pte_unlock
return and next refault will
read zeroed data
The swap_slot_free_notify is bogus for CLONE_VM case since it doesn't increase the refcount of swap slot at copy_mm so it couldn't catch up whether it's safe or not to discard data from backing device. In the case, only the lock it could rely on to synchronize swap slot freeing is page table lock. Thus, this patch gets rid of the swap_slot_free_notify function. With this patch, CPU A will see correct data.
CPU A CPU B
do_swap_page do_swap_page
SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path
swap_readpage original data pte_lock
map the original data swap_free
swap_range_free
bd_disk->fops->swap_slot_free_notify
swap_readpage read zeroed data
pte_unlock
pte_lock
if (!pte_same)
goto out_nomap;
pte_unlock
return
on next refault will see mapped data by CPU B
The concern of the patch would increase memory consumption since it could keep wasted memory with compressed form in zram as well as uncompressed form in address space. However, most of cases of zram uses no readahead and do_swap_page is followed by swap_free so it will free the compressed form from in zram quickly.
--- mm/page_io.c | 54 ------------------------------------------------------ 1 file changed, 54 deletions(-)
mm/page_io.c +0 -54
@@ -51,54 +51,6 @@ void end_swap_bio_write(struct bio *bio)bio_put (bio); } -static void swap_slot_free_notify (struct page *page) -{ -struct swap_info_struct *sis; -struct gendisk *disk; -swp_entry_t entry; - -/* -* There is no guarantee that the page is in swap cache - the software -* suspend code (at least) uses end_swap_bio_read() against a non- -* swapcache page. So we must check PG_swapcache before proceeding with -* this optimization. -*/ -if (unlikely (!PageSwapCache (page))) -return ; - - sis =page_swap_info (page); -if (data_race (!(sis->flags &SWP_BLKDEV ))) -return ; - -/* -* The swap subsystem performs lazy swap slot freeing, -* expecting that the page will be swapped out again. -* So we can avoid an unnecessary write if the page -* isn't redirtied. -* This is good for real swap storage because we can -* reduce unnecessary I/O and enhance wear-leveling -* if an SSD is used as the as swap device. -* But if in-memory swap device (eg zram) is used, -* this causes a duplicated copy between uncompressed -* data in VM-owned memory and compressed data in -* zram-owned memory. So let's free zram-owned memory -* and make the VM-owned decompressed page *dirty*, -* so the page should be swapped out somewhere again if -* we again wish to reclaim it. -*/ - disk = sis->bdev->bd_disk; - entry.val =page_private (page); -if (disk->fops->swap_slot_free_notify &&__swap_count (entry) ==1 ) { -unsigned long offset; - - offset =swp_offset (entry); - -SetPageDirty (page); - disk->fops->swap_slot_free_notify (sis->bdev, - offset); - } -} -static void end_swap_bio_read (struct bio *bio) {struct page *page =bio_first_page_all (bio);
@@ -114,7 +66,6 @@ static void end_swap_bio_read(struct bio }SetPageUptodate (page); -swap_slot_free_notify (page); out:unlock_page (page);WRITE_ONCE (bio->bi_private,NULL );
@@ -392,11 +343,6 @@ int swap_readpage(struct page *page, booif (sis->flags &SWP_SYNCHRONOUS_IO ) { ret =bdev_read_page (sis->bdev,swap_page_sector (page), page);if (!ret) { -if (trylock_page (page)) { -swap_slot_free_notify (page); -unlock_page (page); - } -count_vm_event (PSWPIN ); goto out; }
Greg Kroah-Hartman
maintainerPATCH 178/219 mm: kmemleak: take a full lowmem check in kmemleak_*_phys()
In reply to Greg Kroah-HartmanFrom: Patrick Wang <[email protected]>
commit 23c2d497de21f25898fbea70aeb292ab8acc8c94 upstream.
The kmemleak_*_phys() apis do not check the address for lowmem's min boundary, while the caller may pass an address below lowmem, which will trigger an oops:
# echo scan > /sys/kernel/debug/kmemleak
Unable to handle kernel paging request at virtual address ff5fffffffe00000
Oops [#1]
Modules linked in:
CPU: 2 PID: 134 Comm: bash Not tainted 5.18.0-rc1-next-20220407 #33
Hardware name: riscv-virtio,qemu (DT)
epc : scan_block+0x74/0x15c
ra : scan_block+0x72/0x15c
epc : ffffffff801e5806 ra : ffffffff801e5804 sp : ff200000104abc30
gp : ffffffff815cd4e8 tp : ff60000004cfa340 t0 : 0000000000000200
t1 : 00aaaaaac23954cc t2 : 00000000000003ff s0 : ff200000104abc90
s1 : ffffffff81b0ff28 a0 : 0000000000000000 a1 : ff5fffffffe01000
a2 : ffffffff81b0ff28 a3 : 0000000000000002 a4 : 0000000000000001
a5 : 0000000000000000 a6 : ff200000104abd7c a7 : 0000000000000005
s2 : ff5fffffffe00ff9 s3 : ffffffff815cd998 s4 : ffffffff815d0e90
s5 : ffffffff81b0ff28 s6 : 0000000000000020 s7 : ffffffff815d0eb0
s8 : ffffffffffffffff s9 : ff5fffffffe00000 s10: ff5fffffffe01000
s11: 0000000000000022 t3 : 00ffffffaa17db4c t4 : 000000000000000f
t5 : 0000000000000001 t6 : 0000000000000000
status: 0000000000000100 badaddr: ff5fffffffe00000 cause: 000000000000000d
scan_gray_list+0x12e/0x1a6
kmemleak_scan+0x2aa/0x57e
kmemleak_write+0x32a/0x40c
full_proxy_write+0x56/0x82
vfs_write+0xa6/0x2a6
ksys_write+0x6c/0xe2
sys_write+0x22/0x2a
ret_from_syscall+0x0/0x2The callers may not quite know the actual address they pass(e.g. from devicetree). So the kmemleak_*_phys() apis should guarantee the address they finally use is in lowmem range, so check the address for lowmem's min boundary.
--- mm/kmemleak.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
mm/kmemleak.c +4 -4
@@ -1132,7 +1132,7 @@ EXPORT_SYMBOL(kmemleak_no_scan);void __ref kmemleak_alloc_phys (phys_addr_t phys,size_t size,int min_count,gfp_t gfp) { -if (!IS_ENABLED (CONFIG_HIGHMEM ) ||PHYS_PFN (phys) < max_low_pfn) +if (PHYS_PFN (phys) >= min_low_pfn &&PHYS_PFN (phys) < max_low_pfn)kmemleak_alloc (__va (phys), size, min_count, gfp); }EXPORT_SYMBOL (kmemleak_alloc_phys);
@@ -1146,7 +1146,7 @@ EXPORT_SYMBOL(kmemleak_alloc_phys);*/ void __ref kmemleak_free_part_phys (phys_addr_t phys,size_t size) { -if (!IS_ENABLED (CONFIG_HIGHMEM ) ||PHYS_PFN (phys) < max_low_pfn) +if (PHYS_PFN (phys) >= min_low_pfn &&PHYS_PFN (phys) < max_low_pfn)kmemleak_free_part (__va (phys), size); }EXPORT_SYMBOL (kmemleak_free_part_phys);
@@ -1158,7 +1158,7 @@ EXPORT_SYMBOL(kmemleak_free_part_phys);*/ void __ref kmemleak_not_leak_phys (phys_addr_t phys) { -if (!IS_ENABLED (CONFIG_HIGHMEM ) ||PHYS_PFN (phys) < max_low_pfn) +if (PHYS_PFN (phys) >= min_low_pfn &&PHYS_PFN (phys) < max_low_pfn)kmemleak_not_leak (__va (phys)); }EXPORT_SYMBOL (kmemleak_not_leak_phys);
@@ -1170,7 +1170,7 @@ EXPORT_SYMBOL(kmemleak_not_leak_phys);*/ void __ref kmemleak_ignore_phys (phys_addr_t phys) { -if (!IS_ENABLED (CONFIG_HIGHMEM ) ||PHYS_PFN (phys) < max_low_pfn) +if (PHYS_PFN (phys) >= min_low_pfn &&PHYS_PFN (phys) < max_low_pfn)kmemleak_ignore (__va (phys)); }EXPORT_SYMBOL (kmemleak_ignore_phys);
Greg Kroah-Hartman
maintainerPATCH 179/219 hugetlb: do not demote poisoned hugetlb pages
In reply to Greg Kroah-HartmanFrom: Mike Kravetz <[email protected]>
commit 5a317412ef884763fdf7aa17f9f3636959d11d8f upstream.
It is possible for poisoned hugetlb pages to reside on the free lists. The huge page allocation routines which dequeue entries from the free lists make a point of avoiding poisoned pages. There is no such check and avoidance in the demote code path.
If a hugetlb page on the is on a free list, poison will only be set in the head page rather then the page with the actual error. If such a page is demoted, then the poison flag may follow the wrong page. A page without error could have poison set, and a page with poison could not have the flag set.
Check for poison before attempting to demote a hugetlb page. Also, return -EBUSY to the caller if only poisoned pages are on the free list.
--- mm/hugetlb.c | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-)
mm/hugetlb.c +10 -7
@@ -3469,7 +3469,6 @@ static int demote_pool_huge_page(struct {int nr_nodes, node;struct page *page; -int rc =0 ;lockdep_assert_held (&hugetlb_lock);
@@ -3480,15 +3479,19 @@ static int demote_pool_huge_page(struct }for_each_node_mask_to_free (h, nr_nodes, node, nodes_allowed) { -if (!list_empty (&h->hugepage_freelists[node])) { - page =list_entry (h->hugepage_freelists[node].next, - struct page, lru); - rc =demote_free_huge_page (h, page); -break ; +list_for_each_entry (page, &h->hugepage_freelists[node], lru) { +if (PageHWPoison (page)) +continue ; + +return demote_free_huge_page (h, page); } } -return rc; +/* +* Only way to get here is if all pages on free lists are poisoned. +* Return -EBUSY so that caller will not retry. +*/ +return -EBUSY ; }#define HSTATE_ATTR_RO (_name) \
Greg Kroah-Hartman
maintainerPATCH 180/219 revert "fs/binfmt_elf: fix PT_LOAD p_align values for loaders"
In reply to Greg Kroah-HartmanFrom: Andrew Morton <[email protected]>
commit 354e923df042a11d1ab8ca06b3ebfab3a018a4ec upstream.
Commit 925346c129da11 ("fs/binfmt_elf: fix PT_LOAD p_align values for loaders") was an attempt to fix regressions due to 9630f0d60fec5f ("fs/binfmt_elf: use PT_LOAD p_align values for static PIE").
But regressionss continue to be reported:
https://lore.kernel.org/lkml/[email protected]/
https://bugzilla.kernel.org/show_bug.cgi?id=215720
https://lkml.kernel.org/r/[email protected]
This patch reverts the fix, so the original can also be reverted.
--- fs/binfmt_elf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/binfmt_elf.c +1 -1
@@ -1117,7 +1117,7 @@ out_free_interp:* without MAP_FIXED nor MAP_FIXED_NOREPLACE). */ alignment =maximum_alignment (elf_phdata, elf_ex->e_phnum); -if (interpreter || alignment >ELF_MIN_ALIGN ) { +if (alignment >ELF_MIN_ALIGN ) { load_bias =ELF_ET_DYN_BASE ;if (current->flags &PF_RANDOMIZE ) load_bias +=arch_mmap_rnd ();
Greg Kroah-Hartman
maintainerPATCH 181/219 revert "fs/binfmt_elf: use PT_LOAD p_align values for static PIE"
In reply to Greg Kroah-HartmanFrom: Andrew Morton <[email protected]>
commit aeb7923733d100b86c6bc68e7ae32913b0cec9d8 upstream.
Despite Mike's attempted fix (925346c129da117122), regressions reports continue:
https://lore.kernel.org/lkml/[email protected]/
https://bugzilla.kernel.org/show_bug.cgi?id=215720
https://lkml.kernel.org/r/[email protected]
So revert this patch.
--- fs/binfmt_elf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
fs/binfmt_elf.c +2 -2
@@ -1116,11 +1116,11 @@ out_free_interp:* independently randomized mmap region (0 load_bias * without MAP_FIXED nor MAP_FIXED_NOREPLACE). */ - alignment =maximum_alignment (elf_phdata, elf_ex->e_phnum); -if (alignment >ELF_MIN_ALIGN ) { +if (interpreter) { load_bias =ELF_ET_DYN_BASE ;if (current->flags &PF_RANDOMIZE ) load_bias +=arch_mmap_rnd (); + alignment =maximum_alignment (elf_phdata, elf_ex->e_phnum);if (alignment) load_bias &= ~(alignment -1 ); elf_flags |=MAP_FIXED_NOREPLACE ;
Greg Kroah-Hartman
maintainerPATCH 182/219 KVM: x86/mmu: Resolve nx_huge_pages when kvm.ko is loaded
In reply to Greg Kroah-HartmanFrom: Sean Christopherson <[email protected]>
commit 1d0e84806047f38027d7572adb4702ef7c09b317 upstream.
Resolve nx_huge_pages to true/false when kvm.ko is loaded, leaving it as -1 is technically undefined behavior when its value is read out by param_get_bool(), as boolean values are supposed to be '0' or '1'.
Alternatively, KVM could define a custom getter for the param, but the auto value doesn't depend on the vendor module in any way, and printing "auto" would be unnecessarily unfriendly to the user.
In addition to fixing the undefined behavior, resolving the auto value also fixes the scenario where the auto value resolves to N and no vendor module is loaded. Previously, -1 would result in Y being printed even though KVM would ultimately disable the mitigation.
Rename the existing MMU module init/exit helpers to clarify that they're invoked with respect to the vendor module, and add comments to document why KVM has two separate "module init" flows.
=========================================================================
UBSAN: invalid-load in kernel/params.c:320:33 load of value 255 is not a valid value for type '_Bool' CPU: 6 PID: 892 Comm: tail Not tainted 5.17.0-rc3+ #799 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dump_stack_lvl+0x34/0x44 ubsan_epilogue+0x5/0x40 __ubsan_handle_load_invalid_value.cold+0x43/0x48 param_get_bool.cold+0xf/0x14 param_attr_show+0x55/0x80 module_attr_show+0x1c/0x30 sysfs_kf_seq_show+0x93/0xc0 seq_read_iter+0x11c/0x450 new_sync_read+0x11b/0x1a0 vfs_read+0xf0/0x190 ksys_read+0x5f/0xe0 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae </TASK> =========================================================================
Message-Id: <[email protected]>
--- arch/x86/include/asm/kvm_host.h | 5 +++-- arch/x86/kvm/mmu/mmu.c | 20 ++++++++++++++++---- arch/x86/kvm/x86.c | 20 ++++++++++++++++++-- 3 files changed, 37 insertions(+), 8 deletions(-)
arch/x86/include/asm/kvm_host.h +3 -2
@@ -1574,8 +1574,9 @@ static inline int kvm_arch_flush_remote_#define kvm_arch_pmi_in_guest (vcpu) \ ((vcpu) && (vcpu)->arch.handling_intr_from_guest) -int kvm_mmu_module_init (void ); -void kvm_mmu_module_exit (void ); +void kvm_mmu_x86_module_init (void ); +int kvm_mmu_vendor_module_init (void ); +void kvm_mmu_vendor_module_exit (void );void kvm_mmu_destroy (struct kvm_vcpu *vcpu);int kvm_mmu_create (struct kvm_vcpu *vcpu);
arch/x86/kvm/mmu/mmu.c +16 -4
@@ -6144,12 +6144,24 @@ static int set_nx_huge_pages(const charreturn 0 ; } -int kvm_mmu_module_init (void ) +/* +* nx_huge_pages needs to be resolved to true/false when kvm.ko is loaded, as +* its default value of -1 is technically undefined behavior for a boolean. +*/ +void kvm_mmu_x86_module_init (void ) { -int ret = -ENOMEM ; -if (nx_huge_pages ==-1 )__set_nx_huge_pages (get_nx_auto_mode ()); +} + +/* +* The bulk of the MMU initialization is deferred until the vendor module is +* loaded as many of the masks/values may be modified by VMX or SVM, i.e. need +* to be reset when a potentially different vendor module is loaded. +*/ +int kvm_mmu_vendor_module_init (void ) +{ +int ret = -ENOMEM ;/* * MMU roles use union aliasing which is, generally speaking, an
@@ -6197,7 +6209,7 @@ void kvm_mmu_destroy(struct kvm_vcpu *vcmmu_free_memory_caches (vcpu); } -void kvm_mmu_module_exit (void ) +void kvm_mmu_vendor_module_exit (void ) {mmu_destroy_caches ();percpu_counter_destroy (&kvm_total_used_mmu_pages);
arch/x86/kvm/x86.c +18 -2
@@ -8846,7 +8846,7 @@ int kvm_arch_init(void *opaque) } kvm_nr_uret_msrs =0 ; - r =kvm_mmu_module_init (); + r =kvm_mmu_vendor_module_init ();if (r) goto out_free_percpu;
@@ -8894,7 +8894,7 @@ void kvm_arch_exit(void)cancel_work_sync (&pvclock_gtod_work);#endif kvm_x86_ops.hardware_enable =NULL ; -kvm_mmu_module_exit (); +kvm_mmu_vendor_module_exit ();free_percpu (user_return_msrs);kmem_cache_destroy (x86_emulator_cache);#ifdef CONFIG_KVM_XEN
@@ -12887,3 +12887,19 @@ EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_vmgexitEXPORT_TRACEPOINT_SYMBOL_GPL (kvm_vmgexit_exit);EXPORT_TRACEPOINT_SYMBOL_GPL (kvm_vmgexit_msr_protocol_enter);EXPORT_TRACEPOINT_SYMBOL_GPL (kvm_vmgexit_msr_protocol_exit); + +static int __init kvm_x86_init (void ) +{ +kvm_mmu_x86_module_init (); +return 0 ; +} +module_init (kvm_x86_init); + +static void __exit kvm_x86_exit(void) +{ +/* +* If module_init() is implemented, module_exit() must also be +* implemented to allow module unload. +*/ +} +module_exit (kvm_x86_exit);
Greg Kroah-Hartman
maintainerPATCH 183/219 KVM: Dont create VM debugfs files outside of the VM directory
In reply to Greg Kroah-HartmanFrom: Oliver Upton <[email protected]>
commit a44a4cc1c969afec97dbb2aedaf6f38eaa6253bb upstream.
Unfortunately, there is no guarantee that KVM was able to instantiate a debugfs directory for a particular VM. To that end, KVM shouldn't even attempt to create new debugfs files in this case. If the specified parent dentry is NULL, debugfs_create_file() will instantiate files at the root of debugfs.
For arm64, it is possible to create the vgic-state file outside of a VM directory, the file is not cleaned up when a VM is destroyed. Nonetheless, the corresponding struct kvm is freed when the VM is destroyed.
Nip the problem in the bud for all possible errant debugfs file creations by initializing kvm->debugfs_dentry to -ENOENT. In so doing, debugfs_create_file() will fail instead of creating the file in the root directory.
--- virt/kvm/kvm_main.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
virt/kvm/kvm_main.c +8 -2
@@ -937,7 +937,7 @@ static void kvm_destroy_vm_debugfs(strucint kvm_debugfs_num_entries = kvm_vm_stats_header.num_desc + kvm_vcpu_stats_header.num_desc; -if (!kvm->debugfs_dentry) +if (IS_ERR (kvm->debugfs_dentry))return ;debugfs_remove_recursive (kvm->debugfs_dentry);
@@ -960,6 +960,12 @@ static int kvm_create_vm_debugfs(structint kvm_debugfs_num_entries = kvm_vm_stats_header.num_desc + kvm_vcpu_stats_header.num_desc; +/* +* Force subsequent debugfs file creations to fail if the VM directory +* is not created. +*/ + kvm->debugfs_dentry =ERR_PTR (-ENOENT ); +if (!debugfs_initialized ())return 0 ;
@@ -5484,7 +5490,7 @@ static void kvm_uevent_notify_change(uns }add_uevent_var (env,"PID=%d" , kvm->userspace_pid); -if (kvm->debugfs_dentry) { +if (!IS_ERR (kvm->debugfs_dentry)) {char *tmp, *p =kmalloc (PATH_MAX ,GFP_KERNEL_ACCOUNT );if (p) {
Re: [PATCH 5.17 183/219] KVM: Dont create VM debugfs files outside of the VM directory
Hi Greg,
Quoted 21 lines · Greg Kroah-Hartman
From: Oliver Upton <[email protected]>
commit
a44a4cc1c969afec97dbb2aedaf6f38eaa6253bbupstream.Unfortunately, there is no guarantee that KVM was able to instantiate a debugfs directory for a particular VM. To that end, KVM shouldn't even attempt to create new debugfs files in this case. If the specified parent dentry is NULL,
debugfs_create_file()will instantiate files at the root of debugfs.For arm64, it is possible to create the vgic-state file outside of a VM directory, the file is not cleaned up when a VM is destroyed. Nonetheless, the corresponding struct kvm is freed when the VM is destroyed.
Nip the problem in the bud for all possible errant debugfs file creations by initializing
kvm->debugfs_dentryto-ENOENT. In so doing,debugfs_create_file()will fail instead of creating the file in the root directory.
Quoted 6 lines
Fixes 929f45e32499 ("kvm: no need to check return value of debugfs_create functions")Signed-off-by Oliver Upton <[email protected]>Signed-off-by Marc Zyngier <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>
Can you drop this patch from stable for the time being? There's a bug in it because KVM does init/destroy awkwardly. Sean working on a fix [1].
[1]: https://lore.kernel.org/kvm/[email protected]/
--
Thanks,
Oliver
Greg Kroah-Hartman
maintainerRe: [PATCH 5.17 183/219] KVM: Dont create VM debugfs files outside of the VM directory
Quoted 32 lines · Oliver Upton
Hi Greg,
Quoted 21 lines · Greg Kroah-Hartman
From: Oliver Upton <[email protected]>
commit
a44a4cc1c969afec97dbb2aedaf6f38eaa6253bbupstream.Unfortunately, there is no guarantee that KVM was able to instantiate a debugfs directory for a particular VM. To that end, KVM shouldn't even attempt to create new debugfs files in this case. If the specified parent dentry is NULL,
debugfs_create_file()will instantiate files at the root of debugfs.For arm64, it is possible to create the vgic-state file outside of a VM directory, the file is not cleaned up when a VM is destroyed. Nonetheless, the corresponding struct kvm is freed when the VM is destroyed.
Nip the problem in the bud for all possible errant debugfs file creations by initializing
kvm->debugfs_dentryto-ENOENT. In so doing,debugfs_create_file()will fail instead of creating the file in the root directory.Quoted 6 lines
Fixes 929f45e32499 ("kvm: no need to check return value of debugfs_create functions")Signed-off-by Oliver Upton <[email protected]>Signed-off-by Marc Zyngier <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>
Quoted 5 lines
Can you drop this patch from stable for the time being? There's a bug in it because KVM does init/destroy awkwardly. Sean working on a fix [1].
Will do, I'll go drop it from everywhere.
greg k-h
Greg Kroah-Hartman
maintainerPATCH 184/219 SUNRPC: Fix NFSDs request deferral on RDMA transports
In reply to Greg Kroah-HartmanFrom: Chuck Lever <[email protected]>
commit 773f91b2cf3f52df0d7508fdbf60f37567cdaee4 upstream.
Trond Myklebust reports an NFSD crash in svc_rdma_sendto(). Further investigation shows that the crash occurred while NFSD was handling a deferred request.
This patch addresses two inter-related issues that prevent request deferral from working correctly for RPC/RDMA requests:
1. Prevent the crash by ensuring that the original svc_rqst::rq_xprt_ctxt value is available when the request is revisited. Otherwise svc_rdma_sendto() does not have a Receive context available with which to construct its reply.
2. Possibly since before commit 71641d99ce03 ("svcrdma: Properly compute .len and .buflen for received RPC Calls"), svc_rdma_recvfrom() did not include the transport header in the returned xdr_buf. There should have been no need for svc_defer() and friends to save and restore that header, as of that commit. This issue is addressed in a backport-friendly way by simply having svc_rdma_recvfrom() set rq_xprt_hlen to zero unconditionally, just as svc_tcp_recvfrom() does. This enables svc_deferred_recv() to correctly reconstruct an RPC message received via RPC/RDMA.
--- include/linux/sunrpc/svc.h | 1 + net/sunrpc/svc_xprt.c | 3 +++ net/sunrpc/xprtrdma/svc_rdma_recvfrom.c | 2 +- 3 files changed, 5 insertions(+), 1 deletion(-)
include/linux/sunrpc/svc.h +1 -0
@@ -412,6 +412,7 @@ struct svc_deferred_req {size_t addrlen;struct sockaddr_storage daddr;/* where reply must come from */ size_t daddrlen; +void *xprt_ctxt;struct cache_deferred_req handle;size_t xprt_hlen;int argslen;
net/sunrpc/svc_xprt.c +3 -0
@@ -1213,6 +1213,8 @@ static struct cache_deferred_req *svc_de dr->daddr = rqstp->rq_daddr; dr->argslen = rqstp->rq_arg.len >>2 ; dr->xprt_hlen = rqstp->rq_xprt_hlen; + dr->xprt_ctxt = rqstp->rq_xprt_ctxt; + rqstp->rq_xprt_ctxt =NULL ;/* back up head to the start of the buffer and copy */ skip = rqstp->rq_arg.len - rqstp->rq_arg.head[0 ].iov_len;
@@ -1251,6 +1253,7 @@ static noinline int svc_deferred_recv(st rqstp->rq_xprt_hlen = dr->xprt_hlen; rqstp->rq_daddr = dr->daddr; rqstp->rq_respages = rqstp->rq_pages; + rqstp->rq_xprt_ctxt = dr->xprt_ctxt;svc_xprt_received (rqstp->rq_xprt);return (dr->argslen<<2 ) - dr->xprt_hlen; }
net/sunrpc/xprtrdma/svc_rdma_recvfrom.c +1 -1
@@ -831,7 +831,7 @@ int svc_rdma_recvfrom(struct svc_rqst *r goto out_err;if (ret ==0 ) goto out_drop; - rqstp->rq_xprt_hlen = ret; + rqstp->rq_xprt_hlen =0 ;if (svc_rdma_is_reverse_direction_reply (xprt, ctxt)) goto out_backchannel;
Greg Kroah-Hartman
maintainerPATCH 185/219 memory: renesas-rpc-if: fix platform-device leak in error path
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit b452dbf24d7d9a990d70118462925f6ee287d135 upstream.
Make sure to free the flash platform device in the event that registration fails during probe.
--- drivers/memory/renesas-rpc-if.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
drivers/memory/renesas-rpc-if.c +9 -1
@@ -651,6 +651,7 @@ static int rpcif_probe(struct platform_dstruct platform_device *vdev;struct device_node *flash;const char *name; +int ret; flash =of_get_next_child (pdev->dev.of_node,NULL );if (!flash) {
@@ -674,7 +675,14 @@ static int rpcif_probe(struct platform_dreturn -ENOMEM ; vdev->dev.parent = &pdev->dev;platform_set_drvdata (pdev, vdev); -return platform_device_add (vdev); + + ret =platform_device_add (vdev); +if (ret) { +platform_device_put (vdev); +return ret; + } + +return 0 ; }static int rpcif_remove (struct platform_device *pdev)
Greg Kroah-Hartman
maintainerPATCH 186/219 gcc-plugins: latent_entropy: use /dev/urandom
In reply to Greg Kroah-HartmanFrom: Jason A. Donenfeld <[email protected]>
commit c40160f2998c897231f8454bf797558d30a20375 upstream.
While the latent entropy plugin mostly doesn't derive entropy from get_random_const() for measuring the call graph, when __latent_entropy is applied to a constant, then it's initialized statically to output from get_random_const(). In that case, this data is derived from a 64-bit seed, which means a buffer of 512 bits doesn't really have that amount of compile-time entropy.
This patch fixes that shortcoming by just buffering chunks of /dev/urandom output and doling it out as requested.
At the same time, it's important that we don't break the use of -frandom-seed, for people who want the runtime benefits of the latent entropy plugin, while still having compile-time determinism. In that case, we detect whether gcc's set_random_seed() has been called by making a call to get_random_seed(noinit=true) in the plugin init function, which is called after set_random_seed() is called but before anything that calls get_random_seed(noinit=false), and seeing if it's zero or not. If it's not zero, we're in deterministic mode, and so we just generate numbers with a basic xorshift prng.
Note that we don't detect if -frandom-seed is being used using the documented local_tick variable, because it's assigned via:
local_tick = (unsigned) tv.tv_sec * 1000 + tv.tv_usec / 1000;
which may well overflow and become -1 on its own, and so isn't
reliable: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105171
[kees: The 256 byte rnd_buf size was chosen based on average (250),
median (64), and std deviation (575) bytes of used entropy for a defconfig x86_64 build]
--- scripts/gcc-plugins/latent_entropy_plugin.c | 44 +++++++++++++++++----------- 1 file changed, 27 insertions(+), 17 deletions(-)
scripts/gcc-plugins/latent_entropy_plugin.c +27 -17
@@ -86,25 +86,31 @@ static struct plugin_info latent_entropy .help = "disable\tturn off latent entropy instrumentation\n", }; -static unsigned HOST_WIDE_INT seed; -/* -* get_random_seed() (this is a GCC function) generates the seed. -* This is a simple random generator without any cryptographic security because -* the entropy doesn't come from here. -*/ +static unsigned HOST_WIDE_INT deterministic_seed; +static unsigned HOST_WIDE_INT rnd_buf[32 ]; +static size_t rnd_idx =ARRAY_SIZE (rnd_buf); +static int urandom_fd =-1 ; +static unsigned HOST_WIDE_INT get_random_const (void ) { -unsigned int i; -unsigned HOST_WIDE_INT ret =0 ; - -for (i =0 ; i <8 *sizeof (ret); i++) { - ret = (ret <<1 ) | (seed &1 ); - seed >>=1 ; -if (ret &1 ) - seed ^=0xD800000000000000ULL ; +if (deterministic_seed) { +unsigned HOST_WIDE_INT w = deterministic_seed; + w ^= w <<13 ; + w ^= w >>7 ; + w ^= w <<17 ; + deterministic_seed = w; +return deterministic_seed; } -return ret; +if (urandom_fd <0 ) { + urandom_fd =open ("/dev/urandom" ,O_RDONLY ); +gcc_assert (urandom_fd >=0 ); + } +if (rnd_idx >=ARRAY_SIZE (rnd_buf)) { +gcc_assert (read (urandom_fd, rnd_buf,sizeof (rnd_buf)) ==sizeof (rnd_buf)); + rnd_idx =0 ; + } +return rnd_buf[rnd_idx++]; }static tree tree_get_random_const (tree type)
@@ -537,8 +543,6 @@ static void latent_entropy_start_unit(votree type, id;int quals; - seed =get_random_seed (false); -if (in_lto_p)return ;
@@ -573,6 +577,12 @@ __visible int plugin_init(struct plugin_const struct plugin_argument *const argv = plugin_info->argv;int i; +/* +* Call get_random_seed() with noinit=true, so that this returns +* 0 in the case where no seed has been passed via -frandom-seed. +*/ + deterministic_seed =get_random_seed (true); +static const struct ggc_root_tab gt_ggc_r_gt_latent_entropy[] = { { .base = &latent_entropy_decl,
Greg Kroah-Hartman
maintainerPATCH 187/219 cifs: verify that tcon is valid before dereference in cifs_kill_sb
In reply to Greg Kroah-HartmanFrom: Ronnie Sahlberg <[email protected]>
commit 8b6c58458ee3206dde345fce327a4cb83e69caf9 upstream.
On umount, cifs_sb->tlink_tree might contain entries that do not represent a valid tcon.
Check the tcon for error before we dereference it.
--- fs/cifs/cifsfs.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
fs/cifs/cifsfs.c +3 -3
@@ -266,10 +266,11 @@ static void cifs_kill_sb(struct super_bl* before we kill the sb. */ if (cifs_sb->root) { - node =rb_first (root); -while (node !=NULL ) { +for (node =rb_first (root); node; node =rb_next (node)) { tlink = rb_entry(node, struct tcon_link, tl_rbnode); tcon =tlink_tcon (tlink); +if (IS_ERR (tcon)) +continue ; cfid = &tcon->crfid;mutex_lock (&cfid->fid_mutex);if (cfid->dentry) {
@@ -277,7 +278,6 @@ static void cifs_kill_sb(struct super_bl cfid->dentry =NULL ; }mutex_unlock (&cfid->fid_mutex); - node =rb_next (node); }/* finally release root dentry */
Greg Kroah-Hartman
maintainerPATCH 188/219 gpio: sim: fix setting and getting multiple lines
In reply to Greg Kroah-HartmanFrom: Bartosz Golaszewski <[email protected]>
commit 3836c73e6a2585561af928c6641d74528a8bdfa4 upstream.
We need to take mask into account in the set/get_multiple() callbacks. Use bitmap_replace() instead of bitmap_copy().
--- drivers/gpio/gpio-sim.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpio/gpio-sim.c +2 -2
@@ -134,7 +134,7 @@ static int gpio_sim_get_multiple(structstruct gpio_sim_chip *chip =gpiochip_get_data (gc);mutex_lock (&chip->lock); -bitmap_copy (bits, chip->value_map, gc->ngpio); +bitmap_replace (bits, bits, chip->value_map, mask, gc->ngpio);mutex_unlock (&chip->lock);return 0 ;
@@ -146,7 +146,7 @@ static void gpio_sim_set_multiple(structstruct gpio_sim_chip *chip =gpiochip_get_data (gc);mutex_lock (&chip->lock); -bitmap_copy (chip->value_map, bits, gc->ngpio); +bitmap_replace (chip->value_map, chip->value_map, bits, mask, gc->ngpio);mutex_unlock (&chip->lock); }
Greg Kroah-Hartman
maintainerPATCH 189/219 ath9k: Properly clear TX status area before reporting to mac80211
In reply to Greg Kroah-HartmanFrom: Toke Høiland-Jørgensen <[email protected]>
commit 037250f0a45cf9ecf5b52d4b9ff8eadeb609c800 upstream.
The ath9k driver was not properly clearing the status area in the ieee80211_tx_info struct before reporting TX status to mac80211. Instead, it was manually filling in fields, which meant that fields introduced later were left as-is.
Conveniently, mac80211 actually provides a helper to zero out the status area, so use that to make sure we zero everything.
The last commit touching the driver function writing the status information seems to have actually been fixing an issue that was also caused by the area being uninitialised; but it only added clearing of a single field instead of the whole struct. That is now redundant, though, so revert that commit and use it as a convenient Fixes tag.
--- drivers/net/wireless/ath/ath9k/xmit.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
drivers/net/wireless/ath/ath9k/xmit.c +2 -3
@@ -2553,6 +2553,8 @@ static void ath_tx_rc_status(struct ath_struct ath_hw *ah = sc->sc_ah;u8 i, tx_rateindex; +ieee80211_tx_info_clear_status (tx_info); +if (txok) tx_info->status.ack_signal = ts->ts_rssi;
@@ -2595,9 +2597,6 @@ static void ath_tx_rc_status(struct ath_ } tx_info->status.rates[tx_rateindex].count = ts->ts_longretry +1 ; - -/* we report airtime in ath_tx_count_airtime(), don't report twice */ - tx_info->status.tx_time =0 ; }static void ath_tx_processq (struct ath_softc *sc,struct ath_txq *txq)
Greg Kroah-Hartman
maintainerPATCH 190/219 ath9k: Fix usage of driver-private space in tx_info
In reply to Greg Kroah-HartmanFrom: Toke Høiland-Jørgensen <[email protected]>
commit 5a6b06f5927c940fa44026695779c30b7536474c upstream.
The ieee80211_tx_info_clear_status() helper also clears the rate counts and the driver-private part of struct ieee80211_tx_info, so using it breaks quite a few other things. So back out of using it, and instead define a ath-internal helper that only clears the area between the status_driver_data and the rates info. Combined with moving the ath_frame_info struct to status_driver_data, this avoids clearing anything we shouldn't be, and so we can keep the existing code for handling the rate information.
While fixing this I also noticed that the setting of tx_info->status.rates[tx_rateindex].count on hardware underrun errors was always immediately overridden by the normal setting of the same fields, so rearrange the code so that the underrun detection actually takes effect.
The new helper could be generalised to a 'memset_between()' helper, but leave it as a driver-internal helper for now since this needs to go to stable.
--- drivers/net/wireless/ath/ath9k/main.c | 2 +- drivers/net/wireless/ath/ath9k/xmit.c | 30 ++++++++++++++++++++---------- 2 files changed, 21 insertions(+), 11 deletions(-)
drivers/net/wireless/ath/ath9k/main.c +1 -1
@@ -839,7 +839,7 @@ static bool ath9k_txq_list_has_key(struccontinue ; txinfo =IEEE80211_SKB_CB (bf->bf_mpdu); - fi = (struct ath_frame_info *)&txinfo->rate_driver_data[0 ]; + fi = (struct ath_frame_info *)&txinfo->status.status_driver_data[0 ];if (fi->keyix == keyix)return true; }
drivers/net/wireless/ath/ath9k/xmit.c +20 -10
@@ -141,8 +141,8 @@ static struct ath_frame_info *get_frame_ {struct ieee80211_tx_info *tx_info =IEEE80211_SKB_CB (skb);BUILD_BUG_ON (sizeof (struct ath_frame_info ) > -sizeof (tx_info->rate_driver_data)); -return (struct ath_frame_info *) &tx_info->rate_driver_data[0 ]; +sizeof (tx_info->status.status_driver_data)); +return (struct ath_frame_info *) &tx_info->status.status_driver_data[0 ]; }static void ath_send_bar (struct ath_atx_tid *tid,u16 seqno)
@@ -2542,6 +2542,16 @@ skip_tx_complete:spin_unlock_irqrestore (&sc->tx.txbuflock, flags); } +static void ath_clear_tx_status (struct ieee80211_tx_info *tx_info) +{ +void *ptr = &tx_info->status; + +memset (ptr +sizeof (tx_info->status.rates),0 , +sizeof (tx_info->status) - +sizeof (tx_info->status.rates) - +sizeof (tx_info->status.status_driver_data)); +} +static void ath_tx_rc_status (struct ath_softc *sc,struct ath_buf *bf,struct ath_tx_status *ts,int nframes,int nbad,int txok)
@@ -2553,7 +2563,7 @@ static void ath_tx_rc_status(struct ath_struct ath_hw *ah = sc->sc_ah;u8 i, tx_rateindex; -ieee80211_tx_info_clear_status (tx_info); +ath_clear_tx_status (tx_info);if (txok) tx_info->status.ack_signal = ts->ts_rssi;
@@ -2569,6 +2579,13 @@ static void ath_tx_rc_status(struct ath_ tx_info->status.ampdu_len = nframes; tx_info->status.ampdu_ack_len = nframes - nbad; + tx_info->status.rates[tx_rateindex].count = ts->ts_longretry +1 ; + +for (i = tx_rateindex +1 ; i < hw->max_rates; i++) { + tx_info->status.rates[i].count =0 ; + tx_info->status.rates[i].idx =-1 ; + } +if ((ts->ts_status &ATH9K_TXERR_FILT ) ==0 && (tx_info->flags &IEEE80211_TX_CTL_NO_ACK ) ==0 ) {/*
@@ -2590,13 +2607,6 @@ static void ath_tx_rc_status(struct ath_ tx_info->status.rates[tx_rateindex].count = hw->max_rate_tries; } - -for (i = tx_rateindex +1 ; i < hw->max_rates; i++) { - tx_info->status.rates[i].count =0 ; - tx_info->status.rates[i].idx =-1 ; - } - - tx_info->status.rates[tx_rateindex].count = ts->ts_longretry +1 ; }static void ath_tx_processq (struct ath_softc *sc,struct ath_txq *txq)
Greg Kroah-Hartman
maintainerPATCH 191/219 btrfs: zoned: activate block group only for extent allocation
In reply to Greg Kroah-HartmanFrom: Naohiro Aota <[email protected]>
commit 760e69c4c2e2f475a812bdd414b62758215ce9cb upstream.
In btrfs_make_block_group(), we activate the allocated block group, expecting that the block group is soon used for allocation. However, the chunk allocation from flush_space() context broke the assumption. There can be a large time gap between the chunk allocation time and the extent allocation time from the chunk.
Activating the empty block groups pre-allocated from flush_space() context can exhaust the active zone counter of a device. Once we use all the active zone counts for empty pre-allocated block groups, we cannot activate new block group for the other things: metadata, tree-log, or data relocation block group. That failure results in a fake -ENOSPC.
This patch introduces CHUNK_ALLOC_FORCE_FOR_EXTENT to distinguish the chunk allocation from find_free_extent(). Now, the new block group is activated only in that context.
--- fs/btrfs/block-group.c | 24 ++++++++++++++++-------- fs/btrfs/block-group.h | 4 ++++ fs/btrfs/extent-tree.c | 2 +- 3 files changed, 21 insertions(+), 9 deletions(-)
fs/btrfs/block-group.c +16 -8
@@ -2479,12 +2479,6 @@ struct btrfs_block_group *btrfs_make_bloreturn ERR_PTR (ret); } -/* -* New block group is likely to be used soon. Try to activate it now. -* Failure is OK for now. -*/ -btrfs_zone_activate (cache); - ret =exclude_super_stripes (cache);if (ret) {/* We may have excluded something, so call this just in case */
@@ -3636,8 +3630,14 @@ int btrfs_chunk_alloc(struct btrfs_transstruct btrfs_block_group *ret_bg;bool wait_for_alloc = false;bool should_alloc = false; +bool from_extent_allocation = false;int ret =0 ; +if (force ==CHUNK_ALLOC_FORCE_FOR_EXTENT ) { + from_extent_allocation = true; + force =CHUNK_ALLOC_FORCE ; + } +/* Don't re-enter if we're already allocating a chunk */ if (trans->allocating_chunk)return -ENOSPC ;
@@ -3730,9 +3730,17 @@ int btrfs_chunk_alloc(struct btrfs_trans ret_bg =do_chunk_alloc (trans, flags); trans->allocating_chunk = false; -if (IS_ERR (ret_bg)) +if (IS_ERR (ret_bg)) { ret =PTR_ERR (ret_bg); -else + }else if (from_extent_allocation) { +/* +* New block group is likely to be used soon. Try to activate +* it now. Failure is OK for now. +*/ +btrfs_zone_activate (ret_bg); + } + +if (!ret)btrfs_put_block_group (ret_bg);spin_lock (&space_info->lock);
fs/btrfs/block-group.h +4 -0
@@ -35,11 +35,15 @@ enum btrfs_discard_state {* the FS with empty chunks * * CHUNK_ALLOC_FORCE means it must try to allocate one +* +* CHUNK_ALLOC_FORCE_FOR_EXTENT like CHUNK_ALLOC_FORCE but called from +* find_free_extent() that also activaes the zone */ enum btrfs_chunk_alloc_enum {CHUNK_ALLOC_NO_FORCE ,CHUNK_ALLOC_LIMITED ,CHUNK_ALLOC_FORCE , +CHUNK_ALLOC_FORCE_FOR_EXTENT , };struct btrfs_caching_control {
fs/btrfs/extent-tree.c +1 -1
@@ -4087,7 +4087,7 @@ static int find_free_extent_update_loop( } ret =btrfs_chunk_alloc (trans, ffe_ctl->flags, -CHUNK_ALLOC_FORCE ); +CHUNK_ALLOC_FORCE_FOR_EXTENT );/* Do not bail out on ENOSPC since we can do more. */ if (ret == -ENOSPC )
Greg Kroah-Hartman
maintainerPATCH 192/219 btrfs: fix root ref counts in error handling in btrfs_get_root_ref
In reply to Greg Kroah-HartmanFrom: Jia-Ju Bai <[email protected]>
commit 168a2f776b9762f4021421008512dd7ab7474df1 upstream.
In btrfs_get_root_ref(), when btrfs_insert_fs_root() fails, btrfs_put_root() can happen for two reasons:
- the root already exists in the tree, in that case it returns the reference obtained in btrfs_lookup_fs_root()
- another error so the cleanup is done in the fail label
Calling btrfs_put_root() unconditionally would lead to double decrement of the root reference possibly freeing it in the second case.
--- fs/btrfs/disk-io.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
fs/btrfs/disk-io.c +3 -2
@@ -1826,9 +1826,10 @@ again: ret =btrfs_insert_fs_root (fs_info, root);if (ret) { -btrfs_put_root (root); -if (ret == -EEXIST ) +if (ret == -EEXIST ) { +btrfs_put_root (root); goto again; + } goto fail; }return root;
Greg Kroah-Hartman
maintainerPATCH 193/219 btrfs: mark resumed async balance as writing
In reply to Greg Kroah-HartmanFrom: Naohiro Aota <[email protected]>
commit a690e5f2db4d1dca742ce734aaff9f3112d63764 upstream.
When btrfs balance is interrupted with umount, the background balance resumes on the next mount. There is a potential deadlock with FS freezing here like as described in commit 26559780b953 ("btrfs: zoned: mark relocation as writing"). Mark the process as sb_writing to avoid it.
--- fs/btrfs/volumes.c | 2 ++ 1 file changed, 2 insertions(+)
fs/btrfs/volumes.c +2 -0
@@ -4467,10 +4467,12 @@ static int balance_kthread(void *data)struct btrfs_fs_info *fs_info = data;int ret =0 ; +sb_start_write (fs_info->sb);mutex_lock (&fs_info->balance_mutex);if (fs_info->balance_ctl) ret =btrfs_balance (fs_info, fs_info->balance_ctl,NULL );mutex_unlock (&fs_info->balance_mutex); +sb_end_write (fs_info->sb);return ret; }
Greg Kroah-Hartman
maintainerPATCH 194/219 ALSA: hda/realtek: Add quirk for Clevo PD50PNT
In reply to Greg Kroah-HartmanFrom: Tim Crawford <[email protected]>
commit 9eb6f5c388060d8cef3c8b616cc31b765e022359 upstream.
Fixes speaker output and headset detection on Clevo PD50PNT.
--- sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+)
sound/pci/hda/patch_realtek.c +1 -0
@@ -2619,6 +2619,7 @@ static const struct snd_pci_quirk alc882SND_PCI_QUIRK (0x1558 ,0x65e1 ,"Clevo PB51[ED][DF]" ,ALC1220_FIXUP_CLEVO_PB51ED_PINS ),SND_PCI_QUIRK (0x1558 ,0x65e5 ,"Clevo PC50D[PRS](?:-D|-G)?" ,ALC1220_FIXUP_CLEVO_PB51ED_PINS ),SND_PCI_QUIRK (0x1558 ,0x65f1 ,"Clevo PC50HS" ,ALC1220_FIXUP_CLEVO_PB51ED_PINS ), +SND_PCI_QUIRK (0x1558 ,0x65f5 ,"Clevo PD50PN[NRT]" ,ALC1220_FIXUP_CLEVO_PB51ED_PINS ),SND_PCI_QUIRK (0x1558 ,0x67d1 ,"Clevo PB71[ER][CDF]" ,ALC1220_FIXUP_CLEVO_PB51ED_PINS ),SND_PCI_QUIRK (0x1558 ,0x67e1 ,"Clevo PB71[DE][CDF]" ,ALC1220_FIXUP_CLEVO_PB51ED_PINS ), SND_PCI_QUIRK(0x1558, 0x67e5, "Clevo PC70D[PRS](?:-D|-G)?", ALC1220_FIXUP_CLEVO_PB51ED_PINS),
Greg Kroah-Hartman
maintainerPATCH 195/219 ALSA: hda/realtek: add quirk for Lenovo Thinkpad X12 speakers
In reply to Greg Kroah-HartmanFrom: Tao Jin <[email protected]>
commit 264fb03497ec1c7841bba872571bcd11beed57a7 upstream.
For this specific device on Lenovo Thinkpad X12 tablet, the verbs were dumped by qemu running a guest OS that init this codec properly. After studying the dump, it turns out that
the same quirk used by the other Lenovo devices can be reused.
The patch was tested working against the mainline kernel.
--- sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+)
sound/pci/hda/patch_realtek.c +1 -0
@@ -9218,6 +9218,7 @@ static const struct snd_pci_quirk alc269SND_PCI_QUIRK (0x17aa ,0x505d ,"Thinkpad" ,ALC298_FIXUP_TPT470_DOCK ),SND_PCI_QUIRK (0x17aa ,0x505f ,"Thinkpad" ,ALC298_FIXUP_TPT470_DOCK ),SND_PCI_QUIRK (0x17aa ,0x5062 ,"Thinkpad" ,ALC298_FIXUP_TPT470_DOCK ), +SND_PCI_QUIRK (0x17aa ,0x508b ,"Thinkpad X12 Gen 1" ,ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS ),SND_PCI_QUIRK (0x17aa ,0x5109 ,"Thinkpad" ,ALC269_FIXUP_LIMIT_INT_MIC_BOOST ),SND_PCI_QUIRK (0x17aa ,0x511e ,"Thinkpad" ,ALC298_FIXUP_TPT470_DOCK ), SND_PCI_QUIRK(0x17aa, 0x511f, "Thinkpad", ALC298_FIXUP_TPT470_DOCK),
Greg Kroah-Hartman
maintainerPATCH 196/219 ALSA: pcm: Test for "silence" field in struct "pcm_format_data"
In reply to Greg Kroah-HartmanFrom: Fabio M. De Francesco <[email protected]>
commit 2f7a26abb8241a0208c68d22815aa247c5ddacab upstream.
Syzbot reports "KASAN: null-ptr-deref Write in
snd_pcm_format_set_silence".[1]
It is due to missing validation of the "silence" field of struct "pcm_format_data" in "pcm_formats" array.
Add a test for valid "pat" and, if it is not so, return -EINVAL.
[1] https://lore.kernel.org/lkml/[email protected]/
--- sound/core/pcm_misc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
sound/core/pcm_misc.c +1 -1
@@ -433,7 +433,7 @@ int snd_pcm_format_set_silence(snd_pcm_freturn 0 ; width = pcm_formats[(INT )format].phys;/* physical width */ pat = pcm_formats[(INT )format].silence; -if (! width) +if (!width || !pat)return -EINVAL ;/* signed or 1 byte data */ if (pcm_formats[(INT )format].signd ==1 || width <=8 ) {
Greg Kroah-Hartman
maintainerPATCH 197/219 nl80211: correctly check NL80211_ATTR_REG_ALPHA2 size
In reply to Greg Kroah-HartmanFrom: Johannes Berg <[email protected]>
commit 6624bb34b4eb19f715db9908cca00122748765d7 upstream.
We need this to be at least two bytes, so we can access alpha2[0] and alpha2[1]. It may be three in case some userspace used NUL-termination since it was NLA_STRING (and we also push it out with NUL-termination).
--- net/wireless/nl80211.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
net/wireless/nl80211.c +2 -1
@@ -519,7 +519,8 @@ static const struct nla_policy nl80211_p .len = IEEE80211_MAX_MESH_ID_LEN }, [NL80211_ATTR_MPATH_NEXT_HOP] = NLA_POLICY_ETH_ADDR_COMPAT, - [NL80211_ATTR_REG_ALPHA2] = { .type = NLA_STRING, .len = 2 }, +/* allow 3 for NUL-termination, we used to declare this NLA_STRING */ + [NL80211_ATTR_REG_ALPHA2] = NLA_POLICY_RANGE(NLA_BINARY, 2, 3), [NL80211_ATTR_REG_RULES] = { .type = NLA_NESTED }, [NL80211_ATTR_BSS_CTS_PROT] = { .type = NLA_U8 },
Greg Kroah-Hartman
maintainerPATCH 198/219 ipv6: fix panic when forwarding a pkt with no in6 dev
In reply to Greg Kroah-HartmanFrom: Nicolas Dichtel <[email protected]>
commit e3fa461d8b0e185b7da8a101fe94dfe6dd500ac0 upstream.
kongweibin reported a kernel panic in ip6_forward() when input interface has no in6 dev associated.
The following tc commands were used to reproduce this panic:
tc qdisc del dev vxlan100 root
tc qdisc add dev vxlan100 root netem corrupt 5%
--- net/ipv6/ip6_output.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/ipv6/ip6_output.c +1 -1
@@ -485,7 +485,7 @@ int ip6_forward(struct sk_buff *skb) goto drop;if (!net->ipv6.devconf_all->disable_policy && - !idev->cnf.disable_policy && + (!idev || !idev->cnf.disable_policy) && !xfrm6_policy_check (NULL ,XFRM_POLICY_FWD , skb)) {__IP6_INC_STATS (net, idev,IPSTATS_MIB_INDISCARDS ); goto drop;
Greg Kroah-Hartman
maintainerPATCH 199/219 drm/amd/display: dont ignore alpha property on pre-multiplied mode
In reply to Greg Kroah-HartmanFrom: Melissa Wen <[email protected]>
commit e4f1541caf60fcbe5a59e9d25805c0b5865e546a upstream.
"Pre-multiplied" is the default pixel blend mode for KMS/DRM, as documented in supported_modes of drm_plane_create_blend_mode_property():
https://cgit.freedesktop.org/drm/drm-misc/tree/drivers/gpu/drm/drm_blend.c
In this mode, both 'pixel alpha' and 'plane alpha' participate in the calculation, as described by the pixel blend mode formula in KMS/DRM documentation:
out.rgb = plane_alpha * fg.rgb +
(1 - (plane_alpha * fg.alpha)) * bg.rgb
Considering the blend config mechanisms we have in the driver so far, the alpha mode that better fits this blend mode is the _PER_PIXEL_ALPHA_COMBINED_GLOBAL_GAIN, where the value for global_gain is the plane alpha (global_alpha).
With this change, alpha property stops to be ignored. It also addresses
v2:
* keep the 8-bit value for global_alpha_value (Nicholas)
* correct the logical ordering for combined global gain (Nicholas)
* apply to dcn10 too (Nicholas)
--- drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 14 +++++++++----- drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c | 14 +++++++++----- 2 files changed, 18 insertions(+), 10 deletions(-)
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c +9 -5
@@ -2520,14 +2520,18 @@ void dcn10_update_mpcc(struct dc *dc, ststruct mpc *mpc = dc->res_pool->mpc;struct mpc_tree *mpc_tree_params = &(pipe_ctx->stream_res.opp->mpc_tree_params); -if (per_pixel_alpha) - blnd_cfg.alpha_mode =MPCC_ALPHA_BLEND_MODE_PER_PIXEL_ALPHA ; -else - blnd_cfg.alpha_mode =MPCC_ALPHA_BLEND_MODE_GLOBAL_ALPHA ; - blnd_cfg.overlap_only = false; blnd_cfg.global_gain =0xff ; +if (per_pixel_alpha && pipe_ctx->plane_state->global_alpha) { + blnd_cfg.alpha_mode =MPCC_ALPHA_BLEND_MODE_PER_PIXEL_ALPHA_COMBINED_GLOBAL_GAIN ; + blnd_cfg.global_gain = pipe_ctx->plane_state->global_alpha_value; + }else if (per_pixel_alpha) { + blnd_cfg.alpha_mode =MPCC_ALPHA_BLEND_MODE_PER_PIXEL_ALPHA ; + }else { + blnd_cfg.alpha_mode =MPCC_ALPHA_BLEND_MODE_GLOBAL_ALPHA ; + } +if (pipe_ctx->plane_state->global_alpha) blnd_cfg.global_alpha = pipe_ctx->plane_state->global_alpha_value;else
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c +9 -5
@@ -2313,14 +2313,18 @@ void dcn20_update_mpcc(struct dc *dc, ststruct mpc *mpc = dc->res_pool->mpc;struct mpc_tree *mpc_tree_params = &(pipe_ctx->stream_res.opp->mpc_tree_params); -if (per_pixel_alpha) - blnd_cfg.alpha_mode =MPCC_ALPHA_BLEND_MODE_PER_PIXEL_ALPHA ; -else - blnd_cfg.alpha_mode =MPCC_ALPHA_BLEND_MODE_GLOBAL_ALPHA ; - blnd_cfg.overlap_only = false; blnd_cfg.global_gain =0xff ; +if (per_pixel_alpha && pipe_ctx->plane_state->global_alpha) { + blnd_cfg.alpha_mode =MPCC_ALPHA_BLEND_MODE_PER_PIXEL_ALPHA_COMBINED_GLOBAL_GAIN ; + blnd_cfg.global_gain = pipe_ctx->plane_state->global_alpha_value; + }else if (per_pixel_alpha) { + blnd_cfg.alpha_mode =MPCC_ALPHA_BLEND_MODE_PER_PIXEL_ALPHA ; + }else { + blnd_cfg.alpha_mode =MPCC_ALPHA_BLEND_MODE_GLOBAL_ALPHA ; + } +if (pipe_ctx->plane_state->global_alpha) blnd_cfg.global_alpha = pipe_ctx->plane_state->global_alpha_value;else
Greg Kroah-Hartman
maintainerPATCH 200/219 drm/amdgpu: Enable gfxoff quirk on MacBook Pro
In reply to Greg Kroah-HartmanFrom: Tomasz Moń <[email protected]>
commit 4593c1b6d159f1e5c35c07a7f125e79e5a864302 upstream.
Enabling gfxoff quirk results in perfectly usable graphical user interface on MacBook Pro (15-inch, 2019) with Radeon Pro Vega 20 4 GB.
Without the quirk, X server is completely unusable as every few seconds there is gpu reset due to ring gfx timeout.
--- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c +2 -0
@@ -1334,6 +1334,8 @@ static const struct amdgpu_gfxoff_quirk { 0x1002, 0x15dd, 0x103c, 0x83e7, 0xd3 },/* GFXOFF is unstable on C6 parts with a VBIOS 113-RAVEN-114 */ { 0x1002, 0x15dd, 0x1002, 0x15dd, 0xc6 }, +/* Apple MacBook Pro (15-inch, 2019) Radeon Pro Vega 20 4 GB */ + { 0x1002, 0x69af, 0x106b, 0x019a, 0xc0 }, { 0, 0, 0, 0, 0 }, };
Greg Kroah-Hartman
maintainerPATCH 201/219 x86/tsx: Use MSR_TSX_CTRL to clear CPUID bits
In reply to Greg Kroah-HartmanFrom: Pawan Gupta <[email protected]>
commit 258f3b8c3210b03386e4ad92b4bd8652b5c1beb3 upstream.
tsx_clear_cpuid() uses MSR_TSX_FORCE_ABORT to clear CPUID.RTM and CPUID.HLE. Not all CPUs support MSR_TSX_FORCE_ABORT, alternatively use MSR_IA32_TSX_CTRL when supported.
[ bp: Document how and why TSX gets disabled. ]
--- arch/x86/kernel/cpu/intel.c | 1 arch/x86/kernel/cpu/tsx.c | 54 ++++++++++++++++++++++++++++++++++++++------ 2 files changed, 48 insertions(+), 7 deletions(-)
arch/x86/kernel/cpu/intel.c +1 -0
@@ -722,6 +722,7 @@ static void init_intel(struct cpuinfo_x8else if (tsx_ctrl_state ==TSX_CTRL_DISABLE )tsx_disable ();else if (tsx_ctrl_state ==TSX_CTRL_RTM_ALWAYS_ABORT ) +/* See comment over that function for more details. */ tsx_clear_cpuid ();split_lock_init ();
arch/x86/kernel/cpu/tsx.c +47 -7
79 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 202/219 x86/tsx: Disable TSX development mode at boot
In reply to Greg Kroah-HartmanFrom: Pawan Gupta <[email protected]>
commit 400331f8ffa3bec5c561417e5eec6848464e9160 upstream.
A microcode update on some Intel processors causes all TSX transactions to always abort by default[*]. Microcode also added functionality to re-enable TSX for development purposes. With this microcode loaded, if tsx=on was passed on the cmdline, and TSX development mode was already enabled before the kernel boot, it may make the system vulnerable to TSX Asynchronous Abort (TAA).
To be on safer side, unconditionally disable TSX development mode during boot. If a viable use case appears, this can be revisited later.
[*]: Intel TSX Disable Update for Selected Processors, doc ID: 643557
[ bp: Drop unstable web link, massage heavily. ]
--- arch/x86/include/asm/msr-index.h | 4 +- arch/x86/kernel/cpu/common.c | 2 + arch/x86/kernel/cpu/cpu.h | 5 +-- arch/x86/kernel/cpu/intel.c | 8 ----- arch/x86/kernel/cpu/tsx.c | 50 +++++++++++++++++++++++++++++++-- tools/arch/x86/include/asm/msr-index.h | 4 +- 6 files changed, 55 insertions(+), 18 deletions(-)
arch/x86/include/asm/msr-index.h +2 -2
@@ -128,9 +128,9 @@#define TSX_CTRL_RTM_DISABLE BIT(0)/* Disable RTM feature */ #define TSX_CTRL_CPUID_CLEAR BIT(1)/* Disable TSX enumeration */ -/* SRBDS support */ #define MSR_IA32_MCU_OPT_CTRL 0x00000123 -#define RNGDS_MITG_DIS BIT(0) +#define RNGDS_MITG_DIS BIT(0)/* SRBDS support */ +#define RTM_ALLOW BIT(1)/* TSX development mode */ #define MSR_IA32_SYSENTER_CS 0x00000174#define MSR_IA32_SYSENTER_ESP 0x00000175
arch/x86/kernel/cpu/common.c +2 -0
@@ -1719,6 +1719,8 @@ void identify_secondary_cpu(struct cpuinvalidate_apic_and_package_id (c);x86_spec_ctrl_setup_ap ();update_srbds_msr (); + +tsx_ap_init (); }static __init int setup_noclflush (char *arg)
arch/x86/kernel/cpu/cpu.h +2 -3
@@ -55,11 +55,10 @@ enum tsx_ctrl_states {extern __ro_after_init enum tsx_ctrl_states tsx_ctrl_state;extern void __init tsx_init (void ); -extern void tsx_enable (void ); -extern void tsx_disable (void ); -extern void tsx_clear_cpuid (void ); +void tsx_ap_init (void );#else static inline void tsx_init (void ) { } +static inline void tsx_ap_init (void ) { }#endif /* CONFIG_CPU_SUP_INTEL */ extern void get_cpu_cap (struct cpuinfo_x86 *c);
arch/x86/kernel/cpu/intel.c +0 -8
@@ -717,14 +717,6 @@ static void init_intel(struct cpuinfo_x8init_intel_misc_features (c); -if (tsx_ctrl_state ==TSX_CTRL_ENABLE ) -tsx_enable (); -else if (tsx_ctrl_state ==TSX_CTRL_DISABLE ) -tsx_disable (); -else if (tsx_ctrl_state ==TSX_CTRL_RTM_ALWAYS_ABORT ) -/* See comment over that function for more details. */ -tsx_clear_cpuid (); -split_lock_init ();bus_lock_init ();
arch/x86/kernel/cpu/tsx.c +47 -3
82 lines not on this page · raw message
tools/arch/x86/include/asm/msr-index.h +2 -2
@@ -128,9 +128,9 @@#define TSX_CTRL_RTM_DISABLE BIT(0)/* Disable RTM feature */ #define TSX_CTRL_CPUID_CLEAR BIT(1)/* Disable TSX enumeration */ -/* SRBDS support */ #define MSR_IA32_MCU_OPT_CTRL 0x00000123 -#define RNGDS_MITG_DIS BIT(0) +#define RNGDS_MITG_DIS BIT(0)/* SRBDS support */ +#define RTM_ALLOW BIT(1)/* TSX development mode */ #define MSR_IA32_SYSENTER_CS 0x00000174#define MSR_IA32_SYSENTER_ESP 0x00000175
Greg Kroah-Hartman
maintainerPATCH 203/219 genirq/affinity: Consider that CPUs on nodes can be unbalanced
In reply to Greg Kroah-HartmanFrom: Rei Yamamoto <[email protected]>
commit 08d835dff916bfe8f45acc7b92c7af6c4081c8a7 upstream.
If CPUs on a node are offline at boot time, the number of nodes is different when building affinity masks for present cpus and when building affinity masks for possible cpus. This causes the following problem:
In the case that the number of vectors is less than the number of nodes there are cases where bits of masks for present cpus are overwritten when building masks for possible cpus.
Fix this by excluding CPUs, which are not part of the current build mask (present/possible).
[ tglx: Massaged changelog and added comment ]
--- kernel/irq/affinity.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
kernel/irq/affinity.c +3 -2
@@ -269,8 +269,9 @@ static int __irq_build_affinity_masks(un*/ if (numvecs <= nodes) {for_each_node_mask (n, nodemsk) { -cpumask_or (&masks[curvec].mask, &masks[curvec].mask, - node_to_cpumask[n]); +/* Ensure that only CPUs which are in both masks are set */ +cpumask_and (nmsk, cpu_mask, node_to_cpumask[n]); +cpumask_or (&masks[curvec].mask, &masks[curvec].mask, nmsk);if (++curvec == last_affv) curvec = firstvec; }
Greg Kroah-Hartman
maintainerPATCH 204/219 tick/nohz: Use WARN_ON_ONCE() to prevent console saturation
In reply to Greg Kroah-HartmanFrom: Paul Gortmaker <[email protected]>
commit 40e97e42961f8c6cc7bd5fe67cc18417e02d78f1 upstream.
While running some testing on code that happened to allow the variable tick_nohz_full_running to get set but with no "possible" NOHZ cores to back up that setting, this warning triggered:
if (unlikely(tick_do_timer_cpu == TICK_DO_TIMER_NONE))
WARN_ON(tick_nohz_full_running);The console was overwhemled with an endless stream of one WARN per tick per core and there was no way to even see what was going on w/o using a serial console to capture it and then trace it back to this.
Change it to WARN_ON_ONCE().
--- kernel/time/tick-sched.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/time/tick-sched.c +1 -1
@@ -186,7 +186,7 @@ static void tick_sched_do_timer(struct t*/ if (unlikely (tick_do_timer_cpu ==TICK_DO_TIMER_NONE )) {#ifdef CONFIG_NO_HZ_FULL -WARN_ON (tick_nohz_full_running); +WARN_ON_ONCE (tick_nohz_full_running);#endif tick_do_timer_cpu = cpu; }
Greg Kroah-Hartman
maintainerPATCH 205/219 ARM: davinci: da850-evm: Avoid NULL pointer dereference
In reply to Greg Kroah-HartmanFrom: Nathan Chancellor <[email protected]>
commit 83a1cde5c74bfb44b49cb2a940d044bb2380f4ea upstream.
With newer versions of GCC, there is a panic in da850_evm_config_emac() when booting multi_v5_defconfig in QEMU under the palmetto-bmc machine:
Unable to handle kernel NULL pointer dereference at virtual address 00000020 pgd = (ptrval) [00000020] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 5.15.0 #1 Hardware name: Generic DT based system PC is at da850_evm_config_emac+0x1c/0x120 LR is at do_one_initcall+0x50/0x1e0
The emac_pdata pointer in soc_info is NULL because davinci_soc_info only gets populated on davinci machines but da850_evm_config_emac() is called on all machines via device_initcall().
Move the rmii_en assignment below the machine check so that it is only dereferenced when running on a supported SoC.
--- arch/arm/mach-davinci/board-da850-evm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
arch/arm/mach-davinci/board-da850-evm.c +3 -1
@@ -1101,11 +1101,13 @@ static int __init da850_evm_config_emac(int ret;u32 val;struct davinci_soc_info *soc_info = &davinci_soc_info; -u8 rmii_en = soc_info->emac_pdata->rmii_en; +u8 rmii_en;if (!machine_is_davinci_da850_evm ())return 0 ; + rmii_en = soc_info->emac_pdata->rmii_en; + cfg_chip3_base =DA8XX_SYSCFG0_VIRT (DA8XX_CFGCHIP3_REG ); val =__raw_readl (cfg_chip3_base);
Greg Kroah-Hartman
maintainerPATCH 206/219 ep93xx: clock: Fix UAF in ep93xx_clk_register_gate()
In reply to Greg Kroah-HartmanFrom: Alexander Sverdlin <[email protected]>
commit 3b68b08885217abd9c57ff9b3bb3eb173eee02a9 upstream.
arch/arm/mach-ep93xx/clock.c:154:2: warning: Use of memory after it is freed [clang-analyzer-unix.Malloc] arch/arm/mach-ep93xx/clock.c:151:2: note: Taking true branch
if (IS_ERR(clk))
^arch/arm/mach-ep93xx/clock.c:152:3: note: Memory is released
kfree(psc);
^~~~~~~~~~arch/arm/mach-ep93xx/clock.c:154:2: note: Use of memory after it is freed
return &psc->hw;
^ ~~~~~~~~
--- arch/arm/mach-ep93xx/clock.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
arch/arm/mach-ep93xx/clock.c +3 -1
@@ -148,8 +148,10 @@ static struct clk_hw *ep93xx_clk_registe psc->lock = &clk_lock; clk =clk_register (NULL , &psc->hw); -if (IS_ERR (clk)) +if (IS_ERR (clk)) {kfree (psc); +return ERR_CAST (clk); + }return &psc->hw; }
Greg Kroah-Hartman
maintainerPATCH 207/219 dm integrity: fix memory corruption when tag_size is less than digest size
In reply to Greg Kroah-HartmanFrom: Mikulas Patocka <[email protected]>
commit 08c1af8f1c13bbf210f1760132f4df24d0ed46d6 upstream.
It is possible to set up dm-integrity in such a way that the "tag_size" parameter is less than the actual digest size. In this situation, a part of the digest beyond tag_size is ignored.
In this case, dm-integrity would write beyond the end of the ic->recalc_tags array and corrupt memory. The corruption happened in integrity_recalc->integrity_sector_checksum->crypto_shash_final.
Fix this corruption by increasing the tags array so that it has enough padding at the end to accomodate the loop in integrity_recalc() being able to write a full digest size for the last member of the tags array.
--- drivers/md/dm-integrity.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/md/dm-integrity.c +5 -2
@@ -4400,6 +4400,7 @@ try_smaller_buffer: }if (ic->internal_hash) { +size_t recalc_tags_size; ic->recalc_wq =alloc_workqueue ("dm-integrity-recalc" ,WQ_MEM_RECLAIM ,1 );if (!ic->recalc_wq ) { ti->error ="Cannot allocate workqueue" ;
@@ -4413,8 +4414,10 @@ try_smaller_buffer: r = -ENOMEM ; goto bad; } - ic->recalc_tags =kvmalloc_array (RECALC_SECTORS >> ic->sb->log2_sectors_per_block, - ic->tag_size,GFP_KERNEL ); + recalc_tags_size = (RECALC_SECTORS >> ic->sb->log2_sectors_per_block) * ic->tag_size; +if (crypto_shash_digestsize (ic->internal_hash) > ic->tag_size) + recalc_tags_size +=crypto_shash_digestsize (ic->internal_hash) - ic->tag_size; + ic->recalc_tags =kvmalloc (recalc_tags_size,GFP_KERNEL );if (!ic->recalc_tags) { ti->error ="Cannot allocate tags for recalculating" ; r = -ENOMEM ;
Greg Kroah-Hartman
maintainerPATCH 208/219 i2c: dev: check return value when calling dev_set_name()
In reply to Greg Kroah-HartmanFrom: Andy Shevchenko <[email protected]>
commit 993eb48fa199b5f476df8204e652eff63dd19361 upstream.
If dev_set_name() fails, the dev_name() is null, check the return value of dev_set_name() to avoid the null-ptr-deref.
--- drivers/i2c/i2c-dev.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-)
drivers/i2c/i2c-dev.c +10 -5
@@ -668,16 +668,21 @@ static int i2cdev_attach_adapter(struct i2c_dev->dev.class = i2c_dev_class; i2c_dev->dev.parent = &adap->dev; i2c_dev->dev.release = i2cdev_dev_release; -dev_set_name (&i2c_dev->dev,"i2c-%d" , adap->nr); + + res =dev_set_name (&i2c_dev->dev,"i2c-%d" , adap->nr); +if (res) + goto err_put_i2c_dev; res =cdev_device_add (&i2c_dev->cdev, &i2c_dev->dev); -if (res) { -put_i2c_dev (i2c_dev, false); -return res; - } +if (res) + goto err_put_i2c_dev;pr_debug ("adapter [%s] registered as minor %d\n" , adap->name, adap->nr);return 0 ; + +err_put_i2c_dev: +put_i2c_dev (i2c_dev, false); +return res; }static int i2cdev_detach_adapter (struct device *dev,void *dummy)
Greg Kroah-Hartman
maintainerPATCH 209/219 Revert "net: dsa: setup master before ports"
In reply to Greg Kroah-HartmanFrom: Vladimir Oltean <[email protected]>
commit 762c2998c9625f642f0d23da7d3f7e4f90665fdf upstream.
This reverts commit 11fd667dac315ea3f2469961f6d2869271a46cae.
dsa_slave_change_mtu() updates the MTU of the DSA master and of the associated CPU port, but only if it detects a change to the master MTU.
The blamed commit in the Fixes: tag below addressed a regression where dsa_slave_change_mtu() would return early and not do anything due to ds->ops->port_change_mtu() not being implemented.
However, that commit also had the effect that the master MTU got set up to the correct value by dsa_master_setup(), but the associated CPU port's MTU did not get updated. This causes breakage for drivers that rely on the ->port_change_mtu() DSA call to account for the tagging overhead on the CPU port, and don't set up the initial MTU during the setup phase.
Things actually worked before because they were in a fragile equilibrium where dsa_slave_change_mtu() was called before dsa_master_setup() was. So dsa_slave_change_mtu() could actually detect a change and update the CPU port MTU too.
Restore the code to the way things used to work by reverting the reorder of dsa_tree_setup_master() and dsa_tree_setup_ports(). That change did not have a concrete motivation going for it anyway, it just looked better.
--- net/dsa/dsa2.c | 23 ++++++++++------------- 1 file changed, 10 insertions(+), 13 deletions(-)
net/dsa/dsa2.c +10 -13
@@ -561,7 +561,6 @@ static void dsa_port_teardown(struct dsastruct devlink_port *dlp = &dp->devlink_port;struct dsa_switch *ds = dp->ds;struct dsa_mac_addr *a, *tmp; -struct net_device *slave;if (!dp->setup)return ;
@@ -583,11 +582,9 @@ static void dsa_port_teardown(struct dsadsa_port_link_unregister_of (dp);break ;case DSA_PORT_TYPE_USER : - slave = dp->slave; - -if (slave) { +if (dp->slave) { +dsa_slave_destroy (dp->slave); dp->slave =NULL ; -dsa_slave_destroy (slave); }break ; }
@@ -1137,17 +1134,17 @@ static int dsa_tree_setup(struct dsa_swiif (err) goto teardown_cpu_ports; - err =dsa_tree_setup_master (dst); + err =dsa_tree_setup_ports (dst);if (err) goto teardown_switches; - err =dsa_tree_setup_ports (dst); + err =dsa_tree_setup_master (dst);if (err) - goto teardown_master; + goto teardown_ports; err =dsa_tree_setup_lags (dst);if (err) - goto teardown_ports; + goto teardown_master; dst->setup = true;
@@ -1155,10 +1152,10 @@ static int dsa_tree_setup(struct dsa_swireturn 0 ; -teardown_ports: -dsa_tree_teardown_ports (dst); teardown_master:dsa_tree_teardown_master (dst); +teardown_ports: +dsa_tree_teardown_ports (dst); teardown_switches:dsa_tree_teardown_switches (dst); teardown_cpu_ports:
@@ -1176,10 +1173,10 @@ static void dsa_tree_teardown(struct dsadsa_tree_teardown_lags (dst); -dsa_tree_teardown_ports (dst); -dsa_tree_teardown_master (dst); +dsa_tree_teardown_ports (dst); +dsa_tree_teardown_switches (dst);dsa_tree_teardown_cpu_ports (dst);
Greg Kroah-Hartman
maintainerPATCH 210/219 smp: Fix offline cpu check in flush_smp_call_function_queue()
In reply to Greg Kroah-HartmanFrom: Nadav Amit <[email protected]>
commit 9e949a3886356fe9112c6f6f34a6e23d1d35407f upstream.
The check in flush_smp_call_function_queue() for callbacks that are sent to offline CPUs currently checks whether the queue is empty.
However, flush_smp_call_function_queue() has just deleted all the callbacks from the queue and moved all the entries into a local list. This checks would only be positive if some callbacks were added in the short time after llist_del_all() was called. This does not seem to be the intention of this check.
Change the check to look at the local list to which the entries were moved instead of the queue from which all the callbacks were just removed.
--- kernel/smp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/smp.c +1 -1
@@ -579,7 +579,7 @@ static void flush_smp_call_function_queu/* There shouldn't be any pending callbacks on an offline CPU. */ if (unlikely (warn_cpu_offline && !cpu_online (smp_processor_id ()) && - !warned && !llist_empty (head))) { + !warned && entry !=NULL )) { warned = true;WARN (1 ,"IPI on offline CPU %d\n" ,smp_processor_id ());
Greg Kroah-Hartman
maintainerPATCH 211/219 dt-bindings: memory: snps,ddrc-3.80a compatible also need interrupts
In reply to Greg Kroah-HartmanFrom: Sherry Sun <[email protected]>
commit 4f9f45d0eb0e7d449bc9294459df79b9c66edfac upstream.
For the snps,ddrc-3.80a compatible, the interrupts property is also required, also order the compatibles by name (s goes before x).
--- Documentation/devicetree/bindings/memory-controllers/synopsys,ddrc-ecc.yaml | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
Documentation/devicetree/bindings/memory-controllers/synopsys,ddrc-ecc.yaml +4 -2
@@ -24,9 +24,9 @@ description: | properties: compatible: enum: + - snps,ddrc-3.80a - xlnx,zynq-ddrc-a05 - xlnx,zynqmp-ddrc-2.40a - - snps,ddrc-3.80a interrupts: maxItems: 1
@@ -43,7 +43,9 @@ allOf: properties: compatible: contains: - const: xlnx,zynqmp-ddrc-2.40a + enum: + - snps,ddrc-3.80a + - xlnx,zynqmp-ddrc-2.40a then: required: - interrupts
Greg Kroah-Hartman
maintainerPATCH 212/219 i2c: pasemi: Wait for write xfers to finish
In reply to Greg Kroah-HartmanFrom: Martin Povišer <[email protected]>
commit bd8963e602c77adc76dbbbfc3417c3cf14fed76b upstream.
Wait for completion of write transfers before returning from the driver. At first sight it may seem advantageous to leave write transfers queued for the controller to carry out on its own time, but there's a couple of issues with it:
* Driver doesn't check for FIFO space.
* The queued writes can complete while the driver is in its I2C read transfer path which means it will get confused by the raising of XEN (the 'transaction ended' signal). This can cause a spurious ENODATA error due to premature reading of the MRXFIFO register.
Adding the wait fixes some unreliability issues with the driver. There's some efficiency cost to it (especially with pasemi_smb_waitready doing its polling), but that will be alleviated once the driver receives interrupt support.
--- drivers/i2c/busses/i2c-pasemi-core.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/i2c/busses/i2c-pasemi-core.c +6 -0
@@ -137,6 +137,12 @@ static int pasemi_i2c_xfer_msg(struct i2TXFIFO_WR (smbus, msg->buf[msg->len-1 ] | (stop ?MTXFIFO_STOP :0 )); + +if (stop) { + err =pasemi_smb_waitready (smbus); +if (err) + goto reset_out; + } }return 0 ;
Greg Kroah-Hartman
maintainerPATCH 213/219 dt-bindings: net: snps: remove duplicate name
In reply to Greg Kroah-HartmanFrom: Dongjin Yang <[email protected]>
commit ce8b3ad1071b764e963d9b08ac34ffddddf12da6 upstream.
snps,dwmac has duplicated name for loongson,ls2k-dwmac and loongson,ls7a-dwmac.
--- Documentation/devicetree/bindings/net/snps,dwmac.yaml | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
Documentation/devicetree/bindings/net/snps,dwmac.yaml +2 -4
@@ -53,20 +53,18 @@ properties: - allwinner,sun8i-r40-gmac - allwinner,sun8i-v3s-emac - allwinner,sun50i-a64-emac - - loongson,ls2k-dwmac - - loongson,ls7a-dwmac - amlogic,meson6-dwmac - amlogic,meson8b-dwmac - amlogic,meson8m2-dwmac - amlogic,meson-gxbb-dwmac - amlogic,meson-axg-dwmac - - loongson,ls2k-dwmac - - loongson,ls7a-dwmac - ingenic,jz4775-mac - ingenic,x1000-mac - ingenic,x1600-mac - ingenic,x1830-mac - ingenic,x2000-mac + - loongson,ls2k-dwmac + - loongson,ls7a-dwmac - rockchip,px30-gmac - rockchip,rk3128-gmac - rockchip,rk3228-gmac
Greg Kroah-Hartman
maintainerPATCH 214/219 timers: Fix warning condition in __run_timers()
In reply to Greg Kroah-HartmanFrom: Anna-Maria Behnsen <[email protected]>
commit c54bc0fc84214b203f7a0ebfd1bd308ce2abe920 upstream.
When the timer base is empty, base::next_expiry is set to base::clk + NEXT_TIMER_MAX_DELTA and base::next_expiry_recalc is false. When no timer is queued until jiffies reaches base::next_expiry value, the warning for not finding any expired timer and base::next_expiry_recalc is false in __run_timers() triggers.
To prevent triggering the warning in this valid scenario base::timers_pending needs to be added to the warning condition.
--- kernel/time/timer.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
kernel/time/timer.c +7 -4
@@ -1722,11 +1722,14 @@ static inline void __run_timers(struct t time_after_eq(jiffies, base->next_expiry)) { levels =collect_expired_timers (base, heads);/* -* The only possible reason for not finding any expired -* timer at this clk is that all matching timers have been -* dequeued. +* The two possible reasons for not finding any expired +* timer at this clk are that all matching timers have been +* dequeued or no timer has been queued since +* base::next_expiry was set to base::clk + +* NEXT_TIMER_MAX_DELTA. */ -WARN_ON_ONCE (!levels && !base->next_expiry_recalc); +WARN_ON_ONCE (!levels && !base->next_expiry_recalc + && base->timers_pending); base->clk++; base->next_expiry =__next_timer_interrupt (base);
Greg Kroah-Hartman
maintainerPATCH 215/219 dma-direct: avoid redundant memory sync for swiotlb
In reply to Greg Kroah-HartmanFrom: Chao Gao <[email protected]>
commit 9e02977bfad006af328add9434c8bffa40e053bb upstream.
When we looked into FIO performance with swiotlb enabled in VM, we found swiotlb_bounce() is always called one more time than expected for each DMA read request.
It turns out that the bounce buffer is copied to original DMA buffer twice after the completion of a DMA request (one is done by in dma_direct_sync_single_for_cpu(), the other by swiotlb_tbl_unmap_single()). But the content in bounce buffer actually doesn't change between the two rounds of copy. So, one round of copy is redundant.
Pass DMA_ATTR_SKIP_CPU_SYNC flag to swiotlb_tbl_unmap_single() to skip the memory copy in it.
This fix increases FIO 64KB sequential read throughput in a guest with swiotlb=force by 5.6%.
--- kernel/dma/direct.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
kernel/dma/direct.h +2 -1
@@ -114,6 +114,7 @@ static inline void dma_direct_unmap_pagedma_direct_sync_single_for_cpu (dev, addr, size, dir);if (unlikely (is_swiotlb_buffer (dev, phys))) - swiotlb_tbl_unmap_single(dev, phys, size, dir, attrs); +swiotlb_tbl_unmap_single (dev, phys, size, dir, + attrs | DMA_ATTR_SKIP_CPU_SYNC); }#endif /* _KERNEL_DMA_DIRECT_H */
Greg Kroah-Hartman
maintainerPATCH 216/219 mm, kfence: support kmem_dump_obj() for KFENCE objects
In reply to Greg Kroah-HartmanFrom: Marco Elver <[email protected]>
commit 2dfe63e61cc31ee59ce951672b0850b5229cd5b0 upstream.
Calling kmem_obj_info() via kmem_dump_obj() on KFENCE objects has been producing garbage data due to the object not actually being maintained by SLAB or SLUB.
Fix this by implementing __kfence_obj_info() that copies relevant information to struct kmem_obj_info when the object was allocated by KFENCE; this is called by a common kmem_obj_info(), which also calls the slab/slub/slob specific variant now called __kmem_obj_info().
For completeness, kmem_dump_obj() now displays if the object was allocated by KFENCE.
--- include/linux/kfence.h | 24 ++++++++++++++++++++++++ mm/kfence/core.c | 21 --------------------- mm/kfence/kfence.h | 21 +++++++++++++++++++++ mm/kfence/report.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++ mm/slab.c | 2 +- mm/slab.h | 2 +- mm/slab_common.c | 9 +++++++++ mm/slob.c | 2 +- mm/slub.c | 2 +- 9 files changed, 105 insertions(+), 25 deletions(-)
include/linux/kfence.h +24 -0
@@ -204,6 +204,22 @@ static __always_inline __must_check bool*/ bool __must_check kfence_handle_page_fault (unsigned long addr,bool is_write,struct pt_regs *regs); +#ifdef CONFIG_PRINTK +struct kmem_obj_info ; +/** +* __kfence_obj_info() - fill kmem_obj_info struct +* @kpp: kmem_obj_info to be filled +* @object: the object +* +* Return: +* * false - not a KFENCE object +* * true - a KFENCE object, filled @kpp +* +* Copies information to @kpp for KFENCE objects. +*/ +bool __kfence_obj_info (struct kmem_obj_info *kpp,void *object,struct slab *slab); +#endif +#else /* CONFIG_KFENCE */ static inline bool is_kfence_address (const void *addr) {return false; }
@@ -221,6 +237,14 @@ static inline bool __must_check kfence_hreturn false; } +#ifdef CONFIG_PRINTK +struct kmem_obj_info ; +static inline bool __kfence_obj_info (struct kmem_obj_info *kpp,void *object,struct slab *slab) +{ +return false; +} +#endif +#endif #endif /* _LINUX_KFENCE_H */
mm/kfence/core.c +0 -21
@@ -222,27 +222,6 @@ static bool kfence_unprotect(unsigned loreturn !KFENCE_WARN_ON (!kfence_protect_page (ALIGN_DOWN (addr,PAGE_SIZE ), false)); } -static inline struct kfence_metadata *addr_to_metadata (unsigned long addr) -{ -long index; - -/* The checks do not affect performance; only called from slow-paths. */ - -if (!is_kfence_address ((void *)addr)) -return NULL ; - -/* -* May be an invalid index if called with an address at the edge of -* __kfence_pool, in which case we would report an "invalid access" -* error. -*/ - index = (addr - (unsigned long )__kfence_pool) / (PAGE_SIZE *2 ) -1 ; -if (index <0 || index >=CONFIG_KFENCE_NUM_OBJECTS ) -return NULL ; - -return &kfence_metadata[index]; -} -static inline unsigned long metadata_to_pageaddr (const struct kfence_metadata *meta) {unsigned long offset = (meta - kfence_metadata +1 ) *PAGE_SIZE *2 ;
mm/kfence/kfence.h +21 -0
@@ -96,6 +96,27 @@ struct kfence_metadata {extern struct kfence_metadata kfence_metadata[CONFIG_KFENCE_NUM_OBJECTS ]; +static inline struct kfence_metadata *addr_to_metadata (unsigned long addr) +{ +long index; + +/* The checks do not affect performance; only called from slow-paths. */ + +if (!is_kfence_address ((void *)addr)) +return NULL ; + +/* +* May be an invalid index if called with an address at the edge of +* __kfence_pool, in which case we would report an "invalid access" +* error. +*/ + index = (addr - (unsigned long )__kfence_pool) / (PAGE_SIZE *2 ) -1 ; +if (index <0 || index >=CONFIG_KFENCE_NUM_OBJECTS ) +return NULL ; + +return &kfence_metadata[index]; +} +/* KFENCE error types for report generation. */ enum kfence_error_type {KFENCE_ERROR_OOB ,/* Detected a out-of-bounds access. */
mm/kfence/report.c +47 -0
50 lines not on this page · raw message
mm/slab.c +1 -1
@@ -3650,7 +3650,7 @@ EXPORT_SYMBOL(__kmalloc_node_track_calle#endif /* CONFIG_NUMA */ #ifdef CONFIG_PRINTK -void kmem_obj_info (struct kmem_obj_info *kpp,void *object,struct slab *slab) +void __kmem_obj_info (struct kmem_obj_info *kpp,void *object,struct slab *slab) {struct kmem_cache *cachep;unsigned int objnr;
mm/slab.h +1 -1
@@ -851,7 +851,7 @@ struct kmem_obj_info {void *kp_stack[KS_ADDRS_COUNT ]; void *kp_free_stack[KS_ADDRS_COUNT]; }; -void kmem_obj_info (struct kmem_obj_info *kpp,void *object,struct slab *slab); +void __kmem_obj_info (struct kmem_obj_info *kpp,void *object,struct slab *slab);#endif #ifdef CONFIG_HAVE_HARDENED_USERCOPY_ALLOCATOR
mm/slab_common.c +9 -0
@@ -555,6 +555,13 @@ bool kmem_valid_obj(void *object) }EXPORT_SYMBOL_GPL (kmem_valid_obj); +static void kmem_obj_info (struct kmem_obj_info *kpp,void *object,struct slab *slab) +{ +if (__kfence_obj_info (kpp, object, slab)) +return ; +__kmem_obj_info (kpp, object, slab); +} +/** * kmem_dump_obj - Print available slab provenance information * @object: slab object for which to find provenance information.
@@ -590,6 +597,8 @@ void kmem_dump_obj(void *object)pr_cont (" slab%s %s" , cp, kp.kp_slab_cache->name); else pr_cont(" slab%s", cp); +if (is_kfence_address (object)) +pr_cont (" (kfence)" );if (kp.kp_objp)pr_cont (" start %px" , kp.kp_objp);if (kp.kp_data_offset)
mm/slob.c +1 -1
@@ -463,7 +463,7 @@ out: }#ifdef CONFIG_PRINTK -void kmem_obj_info (struct kmem_obj_info *kpp,void *object,struct slab *slab) +void __kmem_obj_info (struct kmem_obj_info *kpp,void *object,struct slab *slab) { kpp->kp_ptr = object; kpp->kp_slab = slab;
mm/slub.c +1 -1
@@ -4322,7 +4322,7 @@ int __kmem_cache_shutdown(struct kmem_ca }#ifdef CONFIG_PRINTK -void kmem_obj_info (struct kmem_obj_info *kpp,void *object,struct slab *slab) +void __kmem_obj_info (struct kmem_obj_info *kpp,void *object,struct slab *slab) {void *base;int __maybe_unused i;
Greg Kroah-Hartman
maintainerPATCH 217/219 drm/i915: Sunset igpu legacy mmap support based on GRAPHICS_VER_FULL
In reply to Greg Kroah-HartmanFrom: Matt Roper <[email protected]>
commit 1acb34e7dd7720a1fff00cbd4d000ec3219dc9d6 upstream.
The intent of the version check in the mmap ioctl was to maintain support for existing platforms (i.e., ADL/RPL and earlier), but drop support on all future igpu platforms. As we've seen on the dgpu side, the hardware teams are using a more fine-grained numbering system for IP version numbers these days, so it's possible the version number associated with our next igpu could be some form of "12.xx" rather than 13 or higher. Comparing against the full ver.release number will ensure the intent of the check is maintained no matter what numbering the hardware teams settle on.
--- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/i915/gem/i915_gem_mman.c +1 -1
@@ -67,7 +67,7 @@ i915_gem_mmap_ioctl(struct drm_device *d* mmap ioctl is disallowed for all discrete platforms, * and for all platforms with GRAPHICS_VER > 12. */ -if (IS_DGFX (i915) ||GRAPHICS_VER (i915) >12 ) +if (IS_DGFX (i915) ||GRAPHICS_VER_FULL (i915) >IP_VER (12 ,0 ))return -EOPNOTSUPP ;if (args->flags & ~(I915_MMAP_WC ))
Greg Kroah-Hartman
maintainerPATCH 218/219 cpu/hotplug: Remove the cpu member of cpuhp_cpu_state
In reply to Greg Kroah-HartmanFrom: Steven Price <[email protected]>
commit b7ba6d8dc3569e49800ef0136799f26f43e237e8 upstream.
Currently the setting of the 'cpu' member of struct cpuhp_cpu_state in cpuhp_create() is too late as it is used earlier in _cpu_up().
If kzalloc_node() in __smpboot_create_thread() fails then the rollback will be done with st->cpu==0 causing CPU0 to be erroneously set to be dying, causing the scheduler to get mightily confused and throw its toys out of the pram.
However the cpu number is actually available directly, so simply remove the 'cpu' member and avoid the problem in the first place.
--- kernel/cpu.c | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-)
kernel/cpu.c +18 -18
@@ -70,7 +70,6 @@ struct cpuhp_cpu_state {bool rollback;bool single;bool bringup; -int cpu;struct hlist_node *node;struct hlist_node *last;enum cpuhp_state cb_state;
@@ -474,7 +473,7 @@ static inline bool cpu_smt_allowed(unsig#endif static inline enum cpuhp_state -cpuhp_set_state (struct cpuhp_cpu_state *st,enum cpuhp_state target) +cpuhp_set_state (int cpu,struct cpuhp_cpu_state *st,enum cpuhp_state target) {enum cpuhp_state prev_state = st->state;bool bringup = st->state < target;
@@ -485,14 +484,15 @@ cpuhp_set_state(struct cpuhp_cpu_state * st->target = target; st->single = false; st->bringup = bringup; -if (cpu_dying (st->cpu) != !bringup) -set_cpu_dying (st->cpu, !bringup); +if (cpu_dying (cpu) != !bringup) +set_cpu_dying (cpu, !bringup);return prev_state; }static inline void -cpuhp_reset_state (struct cpuhp_cpu_state *st,enum cpuhp_state prev_state) +cpuhp_reset_state (int cpu,struct cpuhp_cpu_state *st, +enum cpuhp_state prev_state) {bool bringup = !st->bringup;
@@ -519,8 +519,8 @@ cpuhp_reset_state(struct cpuhp_cpu_state } st->bringup = bringup; -if (cpu_dying (st->cpu) != !bringup) -set_cpu_dying (st->cpu, !bringup); +if (cpu_dying (cpu) != !bringup) +set_cpu_dying (cpu, !bringup); }/* Regular hotplug invocation of the AP hotplug thread */
@@ -540,15 +540,16 @@ static void __cpuhp_kick_ap(struct cpuhpwait_for_ap_thread (st, st->bringup); } -static int cpuhp_kick_ap (struct cpuhp_cpu_state *st,enum cpuhp_state target) +static int cpuhp_kick_ap (int cpu,struct cpuhp_cpu_state *st, +enum cpuhp_state target) {enum cpuhp_state prev_state;int ret; - prev_state =cpuhp_set_state (st, target); + prev_state =cpuhp_set_state (cpu, st, target);__cpuhp_kick_ap (st);if ((ret = st->result)) { -cpuhp_reset_state (st, prev_state); +cpuhp_reset_state (cpu, st, prev_state);__cpuhp_kick_ap (st); }
@@ -580,7 +581,7 @@ static int bringup_wait_for_ap(unsignedif (st->target <=CPUHP_AP_ONLINE_IDLE )return 0 ; -return cpuhp_kick_ap (st, st->target); +return cpuhp_kick_ap (cpu, st, st->target); }static int bringup_cpu (unsigned int cpu)
@@ -703,7 +704,7 @@ static int cpuhp_up_callbacks(unsigned i ret, cpu,cpuhp_get_step (st->state)->name, st->state); -cpuhp_reset_state (st, prev_state); +cpuhp_reset_state (cpu, st, prev_state);if (can_rollback_cpu (st))WARN_ON (cpuhp_invoke_callback_range (false, cpu, st, prev_state));
@@ -720,7 +721,6 @@ static void cpuhp_create(unsigned int cpinit_completion (&st->done_up);init_completion (&st->done_down); - st->cpu = cpu; }static int cpuhp_should_run (unsigned int cpu)
@@ -874,7 +874,7 @@ static int cpuhp_kick_ap_work(unsigned icpuhp_lock_release (true);trace_cpuhp_enter (cpu, st->target, prev_state, cpuhp_kick_ap_work); - ret =cpuhp_kick_ap (st, st->target); + ret =cpuhp_kick_ap (cpu, st, st->target);trace_cpuhp_exit (cpu, st->state, prev_state, ret);return ret;
@@ -1106,7 +1106,7 @@ static int cpuhp_down_callbacks(unsigned ret, cpu,cpuhp_get_step (st->state)->name, st->state); -cpuhp_reset_state (st, prev_state); +cpuhp_reset_state (cpu, st, prev_state);if (st->state < prev_state) WARN_ON(cpuhp_invoke_callback_range(true, cpu, st,
@@ -1133,7 +1133,7 @@ static int __ref _cpu_down(unsigned int cpuhp_tasks_frozen = tasks_frozen; - prev_state =cpuhp_set_state (st, target); + prev_state =cpuhp_set_state (cpu, st, target);/* * If the current CPU state is in the range of the AP hotplug thread, * then we need to kick the thread.
@@ -1164,7 +1164,7 @@ static int __ref _cpu_down(unsigned int ret =cpuhp_down_callbacks (cpu, st, target);if (ret && st->state < prev_state) {if (st->state ==CPUHP_TEARDOWN_CPU ) { -cpuhp_reset_state (st, prev_state); +cpuhp_reset_state (cpu, st, prev_state);__cpuhp_kick_ap (st); }else {WARN (1 ,"DEAD callback error for CPU%d" , cpu);
@@ -1351,7 +1351,7 @@ static int _cpu_up(unsigned int cpu, int cpuhp_tasks_frozen = tasks_frozen; -cpuhp_set_state (st, target); +cpuhp_set_state (cpu, st, target);/* * If the current CPU state is in the range of the AP hotplug thread, * then we need to kick the thread once more.
Greg Kroah-Hartman
maintainerPATCH 219/219 ax25: Fix UAF bugs in ax25 timers
In reply to Greg Kroah-HartmanFrom: Duoming Zhou <[email protected]>
commit 82e31755e55fbcea6a9dfaae5fe4860ade17cbc0 upstream.
There are race conditions that may lead to UAF bugs in ax25_heartbeat_expiry(), ax25_t1timer_expiry(), ax25_t2timer_expiry(), ax25_t3timer_expiry() and ax25_idletimer_expiry(), when we call ax25_release() to deallocate ax25_dev.
One of the UAF bugs caused by ax25_release() is shown below:
(Thread 1) | (Thread 2)
ax25_dev_device_up() //(1) |
... | ax25_kill_by_device()
ax25_bind() //(2) |
ax25_connect() | ...
ax25_std_establish_data_link() |
ax25_start_t1timer() | ax25_dev_device_down() //(3)
mod_timer(&ax25->t1timer,..) |
| ax25_release()
(wait a time) | ...
| ax25_dev_put(ax25_dev) //(4)FREE
ax25_t1timer_expiry() |
ax25->ax25_dev->values[..] //USE| ...
... |We increase the refcount of ax25_dev in position (1) and (2), and decrease the refcount of ax25_dev in position (3) and (4). The ax25_dev will be freed in position (4) and be used in ax25_t1timer_expiry().
The fail log is shown below:
==============================================================
[ 106.116942] BUG: KASAN: use-after-free in ax25_t1timer_expiry+0x1c/0x60 [ 106.116942] Read of size 8 at addr ffff88800bda9028 by task swapper/0/0 [ 106.116942] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.17.0-06123-g0905eec574 [ 106.116942] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-14 [ 106.116942] Call Trace: ... [ 106.116942] ax25_t1timer_expiry+0x1c/0x60 [ 106.116942] call_timer_fn+0x122/0x3d0 [ 106.116942] __run_timers.part.0+0x3f6/0x520 [ 106.116942] run_timer_softirq+0x4f/0xb0 [ 106.116942] __do_softirq+0x1c2/0x651
...
This patch adds del_timer_sync() in ax25_release(), which could ensure that all timers stop before we deallocate ax25_dev.
--- net/ax25/af_ax25.c | 5 +++++ 1 file changed, 5 insertions(+)
net/ax25/af_ax25.c +5 -0
@@ -1053,6 +1053,11 @@ static int ax25_release(struct socket *sax25_destroy_socket (ax25); }if (ax25_dev) { +del_timer_sync (&ax25->timer); +del_timer_sync (&ax25->t1timer); +del_timer_sync (&ax25->t2timer); +del_timer_sync (&ax25->t3timer); +del_timer_sync (&ax25->idletimer);dev_put_track (ax25_dev->dev, &ax25_dev->dev_tracker);ax25_dev_put (ax25_dev); }
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.17.4 release. There are 219 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, 20 Apr 2022 12:11:14 +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.17.4-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.17.y
and the diffstat can be found below.thanks,
greg k-h
Tested rc1 against the Fedora build system (aarch64, armv7, ppc64le, s390x, x86_64), and boot tested x86_64. No regressions noted.
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.17.4 release. There are 219 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, 20 Apr 2022 12:11:14 +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.17.4-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.17.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 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.17.4 release. There are 219 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, 20 Apr 2022 12:11:14 +0000. Anything received after that time might be too late.
Build results:
total: 155 pass: 155 fail: 0 Qemu test results: total: 489 pass: 489 fail: 0
Guenter
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.17.4 release. There are 219 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, 20 Apr 2022 12:11:14 +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.17.4-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.17.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 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.17.4 release. There are 219 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, 20 Apr 2022 12:11:14 +0000. Anything received after that time might be too late.
Hi Greg,
5.17.4-rc1 tested.
Run tested on:
- Allwinner H6 (Tanix TX6)
- Intel Tiger Lake x86_64 (nuc11 i7-1165G7)
In addition - build tested for:
- Allwinner A64
- Allwinner H3
- Allwinner H5
- NXP iMX6
- NXP iMX8
- Qualcomm Dragonboard
- Rockchip RK3288
- Rockchip RK3328
- Rockchip RK3399pro
- Samsung Exynos
--
Rudi
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.17.4 release. There are 219 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, 20 Apr 2022 12:11:14 +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.17.4-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.17.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.435 [sec]
# Running sched/pipe benchmark...
# Executed 1000000 pipe operations between two processes
Total time: 8.614 [sec]
8.614146 usecs/op
116088 ops/secThanks
-Zan
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.17.4 release. There are 219 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, 20 Apr 2022 12:11:14 +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.17.4-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.17.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.17.4-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.17.y
* git commit: 12e5bd3d067695aa29a9780ccff9fa9d1e761337
* git describe: v5.17.3-223-g12e5bd3d0676
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.17.y/build/v5.17.3-223-g12e5bd3d0676
## Test Regressions (compared to v5.17.3-8-g8a239d5c59a8) No test regressions found.
## Metric Regressions (compared to v5.17.3-8-g8a239d5c59a8) No metric regressions found.
## Test Fixes (compared to v5.17.3-8-g8a239d5c59a8) No metric fixes found.
## Metric Fixes (compared to v5.17.3-8-g8a239d5c59a8) No metric fixes found.
## Test result summary
total: 90780, pass: 78715, fail: 220, skip: 11125, xfail: 720
## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 296 total, 293 passed, 3 failed
* arm64: 47 total, 47 passed, 0 failed
* i386: 44 total, 40 passed, 4 failed
* mips: 41 total, 38 passed, 3 failed
* parisc: 14 total, 14 passed, 0 failed
* powerpc: 65 total, 56 passed, 9 failed
* riscv: 32 total, 27 passed, 5 failed
* s390: 26 total, 23 passed, 3 failed
* sh: 26 total, 24 passed, 2 failed
* sparc: 14 total, 14 passed, 0 failed
* x86_64: 47 total, 47 passed, 0 failed
## Test suites summary
* fwts
* igt-gpu-tools
* 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-te[
* 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
* rcutorture
* ssuite
* v4l2-compliance
* vdso
--
Linaro LKFT
https://lkft.linaro.org
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.17.4 release. There are 219 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, 20 Apr 2022 12:11:14 +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.17.4-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.17.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.17.4 release. There are 219 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, 20 Apr 2022 12:11:14 +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.17.4-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.17.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v5.17:
10 builds: 10 pass, 0 fail
28 boots: 28 pass, 0 fail
130 tests: 130 pass, 0 failLinux version: 5.17.4-rc1-g12e5bd3d0676
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 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.17.4 release. There are 219 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Quoted 8 lines
Responses should be made by Wed, 20 Apr 2022 12:11:14 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.17.4-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.17.y
and the diffstat can be found below.
openSUSE configs¹⁾ all green.
¹⁾ armv6hl armv7hl arm64 i386 ppc64 ppc64le riscv64 s390x x86_64
Signature · 2 lines
js suse labs