5.17.14-rc1 review
Subsystems (3)
Greg Kroah-Hartman
maintainerPATCH 694/772 drm/bridge: analogix_dp: Grab runtime PM reference for DP-AUX
In reply to Greg Kroah-HartmanFrom: Brian Norris <[email protected]>
commit 8fb6c44fe8468f92ac7b8bbfcca4404a4e88645f upstream.
If the display is not enable()d, then we aren't holding a runtime PM reference here. Thus, it's easy to accidentally cause a hang, if user space is poking around at /dev/drm_dp_aux0 at the "wrong" time.
Let's get a runtime PM reference, and check that we "see" the panel. Don't force any panel power-up, etc., because that can be intrusive, and that's not what other drivers do (see drivers/gpu/drm/bridge/ti-sn65dsi86.c and drivers/gpu/drm/bridge/parade-ps8640.c.)
--- drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c +12 -1
@@ -1632,8 +1632,19 @@ static ssize_t analogix_dpaux_transfer(s struct drm_dp_aux_msg *msg) {struct analogix_dp_device *dp =to_dp (aux); +int ret; -return analogix_dp_transfer (dp, msg); +pm_runtime_get_sync (dp->dev); + + ret =analogix_dp_detect_hpd (dp); +if (ret) + goto out; + + ret =analogix_dp_transfer (dp, msg); +out: +pm_runtime_put (dp->dev); + +return ret; } struct analogix_dp_device *
Greg Kroah-Hartman
maintainerPATCH 695/772 drm/i915/dsi: fix VBT send packet port selection for ICL+
In reply to Greg Kroah-HartmanFrom: Jani Nikula <[email protected]>
commit 0ea917819d12fed41ea4662cc26ffa0060a5c354 upstream.
The VBT send packet port selection was never updated for ICL+ where the 2nd link is on port B instead of port C as in VLV+ DSI.
First, single link DSI needs to use the configured port instead of relying on the VBT sequence block port. Remove the hard-coded port C check here and make it generic. For reference, see commit f915084edc5a ("drm/i915: Changes related to the sequence port no for") for the original VLV specific fix.
Second, the sequence block port number is either 0 or 1, where 1 indicates the 2nd link. Remove the hard-coded port C here for 2nd link. (This could be a "find second set bit" on DSI ports, but just check the two possible options.)
Third, sanity check the result with a warning to avoid a NULL pointer dereference.
--- drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 33 ++++++++++++++++++--------- 1 file changed, 22 insertions(+), 11 deletions(-)
drivers/gpu/drm/i915/display/intel_dsi_vbt.c +22 -11
@@ -122,9 +122,25 @@ struct i2c_adapter_lookup {#define ICL_GPIO_DDPA_CTRLCLK_2 8#define ICL_GPIO_DDPA_CTRLDATA_2 9 -static enum port intel_dsi_seq_port_to_port (u8 port) +static enum port intel_dsi_seq_port_to_port (struct intel_dsi *intel_dsi, +u8 seq_port) { -return port ?PORT_C :PORT_A ; +/* +* If single link DSI is being used on any port, the VBT sequence block +* send packet apparently always has 0 for the port. Just use the port +* we have configured, and ignore the sequence block port. +*/ +if (hweight8 (intel_dsi->ports) ==1 ) +return ffs (intel_dsi->ports) -1 ; + +if (seq_port) { +if (intel_dsi->ports &PORT_B ) +return PORT_B ; +else if (intel_dsi->ports &PORT_C ) +return PORT_C ; + } + +return PORT_A ; } static const u8 *mipi_exec_send_packet(struct intel_dsi *intel_dsi,
@@ -146,15 +162,10 @@ static const u8 *mipi_exec_send_packet(s seq_port = (flags >>MIPI_PORT_SHIFT ) &3 ; -/* For DSI single link on Port A & C, the seq_port value which is -* parsed from Sequence Block#53 of VBT has been set to 0 -* Now, read/write of packets for the DSI single link on Port A and -* Port C will based on the DVO port from VBT block 2. -*/ -if (intel_dsi->ports == (1 <<PORT_C )) - port =PORT_C ; -else - port =intel_dsi_seq_port_to_port (seq_port); + port =intel_dsi_seq_port_to_port (intel_dsi, seq_port); + +if (drm_WARN_ON (&dev_priv->drm, !intel_dsi->dsi_hosts[port])) + goto out; dsi_device = intel_dsi->dsi_hosts[port]->device;if (!dsi_device) {
Greg Kroah-Hartman
maintainerPATCH 696/772 md: fix an incorrect NULL check in does_sb_need_changing
In reply to Greg Kroah-HartmanFrom: Xiaomeng Tong <[email protected]>
commit fc8738343eefc4ea8afb6122826dea48eacde514 upstream.
The bug is here:
if (!rdev)
The list iterator value 'rdev' will *always* be set and non-NULL by rdev_for_each(), so it is incorrect to assume that the iterator value will be NULL if the list is empty or no element found. Otherwise it will bypass the NULL check and lead to invalid memory access passing the check.
To fix the bug, use a new variable 'iter' as the list iterator, while using the original variable 'rdev' as a dedicated pointer to point to the found element.
--- drivers/md/md.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
drivers/md/md.c +5 -3
@@ -2629,14 +2629,16 @@ static void sync_sbs(struct mddev *mddevstatic bool does_sb_need_changing (struct mddev *mddev) { -struct md_rdev *rdev; +struct md_rdev *rdev =NULL , *iter;struct mdp_superblock_1 *sb;int role;/* Find a good rdev */ -rdev_for_each (rdev, mddev) -if ((rdev->raid_disk >=0 ) && !test_bit (Faulty, &rdev->flags)) +rdev_for_each (iter, mddev) +if ((iter->raid_disk >=0 ) && !test_bit (Faulty, &iter->flags)) { + rdev = iter;break ; + }/* No good device found. */ if (!rdev)
Greg Kroah-Hartman
maintainerPATCH 697/772 md: fix an incorrect NULL check in md_reload_sb
In reply to Greg Kroah-HartmanFrom: Xiaomeng Tong <[email protected]>
commit 64c54d9244a4efe9bc6e9c98e13c4bbb8bb39083 upstream.
The bug is here:
if (!rdev || rdev->desc_nr != nr) {The list iterator value 'rdev' will *always* be set and non-NULL by rdev_for_each_rcu(), so it is incorrect to assume that the iterator value will be NULL if the list is empty or no element found (In fact, it will be a bogus pointer to an invalid struct object containing the HEAD). Otherwise it will bypass the check and lead to invalid memory access passing the check.
To fix the bug, use a new variable 'iter' as the list iterator, while using the original variable 'pdev' as a dedicated pointer to point to the found element.
--- drivers/md/md.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
drivers/md/md.c +6 -4
@@ -9794,16 +9794,18 @@ static int read_rdev(struct mddev *mddevvoid md_reload_sb (struct mddev *mddev,int nr) { -struct md_rdev *rdev; +struct md_rdev *rdev =NULL , *iter;int err;/* Find the rdev */ -rdev_for_each_rcu (rdev, mddev) { -if (rdev->desc_nr == nr) +rdev_for_each_rcu (iter, mddev) { +if (iter->desc_nr == nr) { + rdev = iter;break ; + } } -if (!rdev || rdev->desc_nr != nr) { +if (!rdev) {pr_warn ("%s: %d Could not find rdev with nr %d\n" , __func__, __LINE__, nr);return ; }
Greg Kroah-Hartman
maintainerPATCH 698/772 mtd: cfi_cmdset_0002: Move and rename chip_check/chip_ready/chip_good_for_write
In reply to Greg Kroah-HartmanFrom: Tokunori Ikegami <[email protected]>
commit 083084df578a8bdb18334f69e7b32d690aaa3247 upstream.
This is a preparation patch for the S29GL064N buffer writes fix. There is no functional change.
--- drivers/mtd/chips/cfi_cmdset_0002.c | 95 ++++++++++++------------------------ 1 file changed, 32 insertions(+), 63 deletions(-)
drivers/mtd/chips/cfi_cmdset_0002.c +32 -63
@@ -802,21 +802,25 @@ static struct mtd_info *cfi_amdstd_setup }/* -* Return true if the chip is ready. +* Return true if the chip is ready and has the correct value. * * Ready is one of: read mode, query mode, erase-suspend-read mode (in any * non-suspended sector) and is indicated by no toggle bits toggling. * +* Error are indicated by toggling bits or bits held with the wrong value, +* or with bits toggling. +* * Note that anything more complicated than checking if no bits are toggling * (including checking DQ5 for an error status) is tricky to get working * correctly and is therefore not done (particularly with interleaved chips * as each chip must be checked independently of the others). */ static int __xipram chip_ready(struct map_info *map, struct flchip *chip, -unsigned long addr) +unsigned long addr,map_word *expected) {struct cfi_private *cfi = map->fldrv_priv;map_word d, t; +int ret;if (cfi_use_status_reg (cfi)) {map_word ready =CMD (CFI_SR_DRB );
@@ -826,57 +830,20 @@ static int __xipram chip_ready(struct ma*/ cfi_send_gen_cmd (0x70 , cfi->addr_unlock1, chip->start, map, cfi, cfi->device_type,NULL ); - d =map_read (map, addr); + t =map_read (map, addr); -return map_word_andequal (map, d, ready, ready); +return map_word_andequal (map, t, ready, ready); } d =map_read (map, addr); t =map_read (map, addr); -return map_word_equal (map, d, t); -} - -/* -* Return true if the chip is ready and has the correct value. -* -* Ready is one of: read mode, query mode, erase-suspend-read mode (in any -* non-suspended sector) and it is indicated by no bits toggling. -* -* Error are indicated by toggling bits or bits held with the wrong value, -* or with bits toggling. -* -* Note that anything more complicated than checking if no bits are toggling -* (including checking DQ5 for an error status) is tricky to get working -* correctly and is therefore not done (particularly with interleaved chips -* as each chip must be checked independently of the others). -* -*/ -static int __xipram chip_good(struct map_info *map, struct flchip *chip, -unsigned long addr,map_word expected) -{ -struct cfi_private *cfi = map->fldrv_priv; -map_word oldd, curd; - -if (cfi_use_status_reg (cfi)) { -map_word ready =CMD (CFI_SR_DRB ); - -/* -* For chips that support status register, check device -* ready bit -*/ -cfi_send_gen_cmd (0x70 , cfi->addr_unlock1, chip->start, map, cfi, - cfi->device_type,NULL ); - curd =map_read (map, addr); - -return map_word_andequal (map, curd, ready, ready); - } + ret =map_word_equal (map, d, t); - oldd =map_read (map, addr); - curd =map_read (map, addr); +if (!ret || !expected) +return ret; -return map_word_equal (map, oldd, curd) && -map_word_equal (map, curd, expected); +return map_word_equal (map, t, *expected); }static int get_chip (struct map_info *map,struct flchip *chip,unsigned long adr,int mode)
@@ -893,7 +860,7 @@ static int get_chip(struct map_info *mapcase FL_STATUS :for (;;) { -if (chip_ready (map, chip, adr)) +if (chip_ready (map, chip, adr,NULL ))break ;if (time_after (jiffies, timeo)) {
@@ -932,7 +899,7 @@ static int get_chip(struct map_info *map chip->state =FL_ERASE_SUSPENDING ; chip->erase_suspended =1 ;for (;;) { -if (chip_ready (map, chip, adr)) +if (chip_ready (map, chip, adr,NULL ))break ;if (time_after (jiffies, timeo)) {
@@ -1463,7 +1430,7 @@ static int do_otp_lock(struct map_info */* wait for chip to become ready */ timeo = jiffies +msecs_to_jiffies (2 );for (;;) { -if (chip_ready (map, chip, adr)) +if (chip_ready (map, chip, adr,NULL ))break ;if (time_after (jiffies, timeo)) {
@@ -1695,11 +1662,11 @@ static int __xipram do_write_oneword_onc }/* -* We check "time_after" and "!chip_good" before checking -* "chip_good" to avoid the failure due to scheduling. +* We check "time_after" and "!chip_ready" before checking +* "chip_ready" to avoid the failure due to scheduling. */ if (time_after (jiffies, timeo) && - !chip_good (map, chip, adr, datum)) { + !chip_ready (map, chip, adr, &datum)) {xip_enable (map, chip, adr);printk (KERN_WARNING "MTD %s(): software timeout\n" , __func__);xip_disable (map, chip, adr);
@@ -1707,7 +1674,7 @@ static int __xipram do_write_oneword_oncbreak ; } -if (chip_good (map, chip, adr, datum)) { +if (chip_ready (map, chip, adr, &datum)) {if (cfi_check_err_status (map, chip, adr)) ret = -EIO ;break ;
@@ -1975,18 +1942,18 @@ static int __xipram do_write_buffer_wait }/* -* We check "time_after" and "!chip_good" before checking -* "chip_good" to avoid the failure due to scheduling. +* We check "time_after" and "!chip_ready" before checking +* "chip_ready" to avoid the failure due to scheduling. */ if (time_after (jiffies, timeo) && - !chip_good (map, chip, adr, datum)) { + !chip_ready (map, chip, adr, &datum)) {pr_err ("MTD %s(): software timeout, address:0x%.8lx.\n" , __func__, adr); ret = -EIO ;break ; } -if (chip_good (map, chip, adr, datum)) { +if (chip_ready (map, chip, adr, &datum)) {if (cfi_check_err_status (map, chip, adr)) ret = -EIO ;break ;
@@ -2195,7 +2162,7 @@ static int cfi_amdstd_panic_wait(struct* If the driver thinks the chip is idle, and no toggle bits * are changing, then the chip is actually idle for sure. */ -if (chip->state ==FL_READY &&chip_ready (map, chip, adr)) +if (chip->state ==FL_READY &&chip_ready (map, chip, adr,NULL ))return 0 ;/*
@@ -2212,7 +2179,7 @@ static int cfi_amdstd_panic_wait(struct/* wait for the chip to become ready */ for (i =0 ; i <jiffies_to_usecs (timeo); i++) { -if (chip_ready (map, chip, adr)) +if (chip_ready (map, chip, adr,NULL ))return 0 ;udelay (1 );
@@ -2276,13 +2243,13 @@ retry:map_write (map, datum, adr);for (i =0 ; i <jiffies_to_usecs (uWriteTimeout); i++) { -if (chip_ready (map, chip, adr)) +if (chip_ready (map, chip, adr,NULL ))break ;udelay (1 ); } -if (!chip_good (map, chip, adr, datum) || +if (!chip_ready (map, chip, adr, &datum) ||cfi_check_err_status (map, chip, adr)) {/* reset on all failures. */ map_write (map,CMD (0xF0 ), chip->start);
@@ -2424,6 +2391,7 @@ static int __xipram do_erase_chip(structDECLARE_WAITQUEUE (wait, current);int ret;int retry_cnt =0 ; +map_word datum =map_word_ff (map); adr = cfi->addr_unlock1;
@@ -2478,7 +2446,7 @@ static int __xipram do_erase_chip(struct chip->erase_suspended =0 ; } -if (chip_good (map, chip, adr,map_word_ff (map))) { +if (chip_ready (map, chip, adr, &datum)) {if (cfi_check_err_status (map, chip, adr)) ret = -EIO ;break ;
@@ -2523,6 +2491,7 @@ static int __xipram do_erase_oneblock(stDECLARE_WAITQUEUE (wait, current);int ret;int retry_cnt =0 ; +map_word datum =map_word_ff (map); adr += chip->start;
@@ -2577,7 +2546,7 @@ static int __xipram do_erase_oneblock(st chip->erase_suspended =0 ; } -if (chip_good (map, chip, adr,map_word_ff (map))) { +if (chip_ready (map, chip, adr, &datum)) {if (cfi_check_err_status (map, chip, adr)) ret = -EIO ;break ;
@@ -2771,7 +2740,7 @@ static int __maybe_unused do_ppb_xxlock(*/ timeo = jiffies +msecs_to_jiffies (2000 );/* 2s max (un)locking */ for (;;) { -if (chip_ready (map, chip, adr)) +if (chip_ready (map, chip, adr,NULL ))break ;if (time_after (jiffies, timeo)) {
Greg Kroah-Hartman
maintainerPATCH 699/772 mtd: cfi_cmdset_0002: Use chip_ready() for write on S29GL064N
In reply to Greg Kroah-HartmanFrom: Tokunori Ikegami <[email protected]>
commit 0a8e98305f63deaf0a799d5cf5532cc83af035d1 upstream.
Since commit dfeae1073583("mtd: cfi_cmdset_0002: Change write buffer to check correct value") buffered writes fail on S29GL064N. This is because, on S29GL064N, reads return 0xFF at the end of DQ polling for write completion, where as, chip_good() check expects actual data written to the last location to be returned post DQ polling completion. Fix is to revert to using chip_good() for S29GL064N which only checks for DQ lines to settle down to determine write completion.
--- drivers/mtd/chips/cfi_cmdset_0002.c | 42 +++++++++++++++++++++++++++++------- include/linux/mtd/cfi.h | 1 2 files changed, 35 insertions(+), 8 deletions(-)
drivers/mtd/chips/cfi_cmdset_0002.c +34 -8
@@ -59,6 +59,10 @@#define CFI_SR_WBASB BIT(3)#define CFI_SR_SLSB BIT(1) +enum cfi_quirks { +CFI_QUIRK_DQ_TRUE_DATA =BIT (0 ), +}; +static int cfi_amdstd_read (struct mtd_info *,loff_t ,size_t ,size_t *,u_char *);static int cfi_amdstd_write_words (struct mtd_info *,loff_t ,size_t ,size_t *,const u_char *);#if !FORCE_WORD_WRITE
@@ -436,6 +440,15 @@ static void fixup_s29ns512p_sectors(stru mtd->name); } +static void fixup_quirks (struct mtd_info *mtd) +{ +struct map_info *map = mtd->priv; +struct cfi_private *cfi = map->fldrv_priv; + +if (cfi->mfr ==CFI_MFR_AMD && cfi->id ==0x0c01 ) + cfi->quirks |=CFI_QUIRK_DQ_TRUE_DATA ; +} +/* Used to fix CFI-Tables of chips without Extended Query Tables */ static struct cfi_fixup cfi_nopri_fixup_table[] = { {CFI_MFR_SST ,0x234a , fixup_sst39vf },/* SST39VF1602 */
@@ -474,6 +487,7 @@ static struct cfi_fixup cfi_fixup_table[ #if !FORCE_WORD_WRITE { CFI_MFR_ANY, CFI_ID_ANY, fixup_use_write_buffers }, #endif + { CFI_MFR_ANY, CFI_ID_ANY, fixup_quirks }, { 0, 0, NULL } }; static struct cfi_fixup jedec_fixup_table[] = {
@@ -846,6 +860,18 @@ static int __xipram chip_ready(struct mareturn map_word_equal (map, t, *expected); } +static int __xipram chip_good(struct map_info *map, struct flchip *chip, +unsigned long addr,map_word *expected) +{ +struct cfi_private *cfi = map->fldrv_priv; +map_word *datum = expected; + +if (cfi->quirks &CFI_QUIRK_DQ_TRUE_DATA ) + datum =NULL ; + +return chip_ready (map, chip, addr, datum); +} +static int get_chip (struct map_info *map,struct flchip *chip,unsigned long adr,int mode) {DECLARE_WAITQUEUE (wait, current);
@@ -1662,11 +1688,11 @@ static int __xipram do_write_oneword_onc }/* -* We check "time_after" and "!chip_ready" before checking -* "chip_ready" to avoid the failure due to scheduling. +* We check "time_after" and "!chip_good" before checking +* "chip_good" to avoid the failure due to scheduling. */ if (time_after (jiffies, timeo) && - !chip_ready (map, chip, adr, &datum)) { + !chip_good (map, chip, adr, &datum)) {xip_enable (map, chip, adr);printk (KERN_WARNING "MTD %s(): software timeout\n" , __func__);xip_disable (map, chip, adr);
@@ -1674,7 +1700,7 @@ static int __xipram do_write_oneword_oncbreak ; } -if (chip_ready (map, chip, adr, &datum)) { +if (chip_good (map, chip, adr, &datum)) {if (cfi_check_err_status (map, chip, adr)) ret = -EIO ;break ;
@@ -1942,18 +1968,18 @@ static int __xipram do_write_buffer_wait }/* -* We check "time_after" and "!chip_ready" before checking -* "chip_ready" to avoid the failure due to scheduling. +* We check "time_after" and "!chip_good" before checking +* "chip_good" to avoid the failure due to scheduling. */ if (time_after (jiffies, timeo) && - !chip_ready (map, chip, adr, &datum)) { + !chip_good (map, chip, adr, &datum)) {pr_err ("MTD %s(): software timeout, address:0x%.8lx.\n" , __func__, adr); ret = -EIO ;break ; } -if (chip_ready (map, chip, adr, &datum)) { +if (chip_good (map, chip, adr, &datum)) {if (cfi_check_err_status (map, chip, adr)) ret = -EIO ;break ;
include/linux/mtd/cfi.h +1 -0
@@ -286,6 +286,7 @@ struct cfi_private {map_word sector_erase_cmd;unsigned long chipshift;/* Because they're of the same type */ const char *im_name;/* inter_module name for cmdset_setup */ +unsigned long quirks;struct flchip chips[];/* per-chip data structure for each chip */ };
Greg Kroah-Hartman
maintainerPATCH 700/772 media: coda: Fix reported H264 profile
In reply to Greg Kroah-HartmanFrom: Nicolas Dufresne <[email protected]>
commit 7110c08ea71953a7fc342f0b76046f72442cf26c upstream.
The CODA960 manual states that ASO/FMO features of baseline are not supported, so for this reason this driver should only report constrained baseline support.
This fixes negotiation issue with constrained baseline content on GStreamer 1.17.1.
ASO/FMO features are unsupported for the encoder and untested for the decoder because there is currently no userspace support. Neither GStreamer parsers nor FFMPEG parsers support ASO/FMO.
--- drivers/media/platform/coda/coda-common.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/media/platform/coda/coda-common.c +3 -3
@@ -2352,8 +2352,8 @@ static void coda_encode_ctrls(struct cod V4L2_CID_MPEG_VIDEO_H264_CHROMA_QP_INDEX_OFFSET, -12, 12, 1, 0);v4l2_ctrl_new_std_menu (&ctx->ctrls, &coda_ctrl_ops,V4L2_CID_MPEG_VIDEO_H264_PROFILE , -V4L2_MPEG_VIDEO_H264_PROFILE_BASELINE ,0x0 , -V4L2_MPEG_VIDEO_H264_PROFILE_BASELINE ); +V4L2_MPEG_VIDEO_H264_PROFILE_CONSTRAINED_BASELINE ,0x0 , +V4L2_MPEG_VIDEO_H264_PROFILE_CONSTRAINED_BASELINE );if (ctx->dev->devtype->product ==CODA_HX4 || ctx->dev->devtype->product ==CODA_7541 ) { v4l2_ctrl_new_std_menu(&ctx->ctrls, &coda_ctrl_ops,
@@ -2434,7 +2434,7 @@ static void coda_decode_ctrls(struct cod ctx->h264_profile_ctrl =v4l2_ctrl_new_std_menu (&ctx->ctrls, &coda_ctrl_ops,V4L2_CID_MPEG_VIDEO_H264_PROFILE ,V4L2_MPEG_VIDEO_H264_PROFILE_HIGH , - ~((1 <<V4L2_MPEG_VIDEO_H264_PROFILE_BASELINE ) | + ~((1 <<V4L2_MPEG_VIDEO_H264_PROFILE_CONSTRAINED_BASELINE ) | (1 <<V4L2_MPEG_VIDEO_H264_PROFILE_MAIN ) | (1 <<V4L2_MPEG_VIDEO_H264_PROFILE_HIGH )),V4L2_MPEG_VIDEO_H264_PROFILE_HIGH );
Greg Kroah-Hartman
maintainerPATCH 701/772 media: coda: Add more H264 levels for CODA960
In reply to Greg Kroah-HartmanFrom: Nicolas Dufresne <[email protected]>
commit eb2fd187abc878a2dfad46902becb74963473c7d upstream.
Add H264 level 1.0, 4.1, 4.2 to the list of supported formats. While the hardware does not fully support these levels, it does support most of them. The constraints on frame size and pixel formats already cover the limitation.
This fixes negotiation of level on GStreamer 1.17.1.
--- drivers/media/platform/coda/coda-common.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
drivers/media/platform/coda/coda-common.c +6 -3
@@ -2367,12 +2367,15 @@ static void coda_encode_ctrls(struct codif (ctx->dev->devtype->product ==CODA_960 ) {v4l2_ctrl_new_std_menu (&ctx->ctrls, &coda_ctrl_ops,V4L2_CID_MPEG_VIDEO_H264_LEVEL , -V4L2_MPEG_VIDEO_H264_LEVEL_4_0 , - ~((1 <<V4L2_MPEG_VIDEO_H264_LEVEL_2_0 ) | +V4L2_MPEG_VIDEO_H264_LEVEL_4_2 , + ~((1 <<V4L2_MPEG_VIDEO_H264_LEVEL_1_0 ) | + (1 <<V4L2_MPEG_VIDEO_H264_LEVEL_2_0 ) | (1 <<V4L2_MPEG_VIDEO_H264_LEVEL_3_0 ) | (1 <<V4L2_MPEG_VIDEO_H264_LEVEL_3_1 ) | (1 <<V4L2_MPEG_VIDEO_H264_LEVEL_3_2 ) | - (1 <<V4L2_MPEG_VIDEO_H264_LEVEL_4_0 )), + (1 <<V4L2_MPEG_VIDEO_H264_LEVEL_4_0 ) | + (1 <<V4L2_MPEG_VIDEO_H264_LEVEL_4_1 ) | + (1 <<V4L2_MPEG_VIDEO_H264_LEVEL_4_2 )),V4L2_MPEG_VIDEO_H264_LEVEL_4_0 ); } v4l2_ctrl_new_std(&ctx->ctrls, &coda_ctrl_ops,
Greg Kroah-Hartman
maintainerPATCH 702/772 ima: remove the IMA_TEMPLATE Kconfig option
In reply to Greg Kroah-HartmanFrom: GUO Zihua <[email protected]>
commit 891163adf180bc369b2f11c9dfce6d2758d2a5bd upstream.
The original 'ima' measurement list template contains a hash, defined as 20 bytes, and a null terminated pathname, limited to 255 characters. Other measurement list templates permit both larger hashes and longer pathnames. When the "ima" template is configured as the default, a new measurement list template (ima_template=) must be specified before specifying a larger hash algorithm (ima_hash=) on the boot command line.
To avoid this boot command line ordering issue, remove the legacy "ima" template configuration option, allowing it to still be specified on the boot command line.
The root cause of this issue is that during the processing of ima_hash, we would try to check whether the hash algorithm is compatible with the template. If the template is not set at the moment we do the check, we check the algorithm against the configured default template. If the default template is "ima", then we reject any hash algorithm other than sha1 and md5.
For example, if the compiled default template is "ima", and the default algorithm is sha1 (which is the current default). In the cmdline, we put in "ima_hash=sha256 ima_template=ima-ng". The expected behavior would be that ima starts with ima-ng as the template and sha256 as the hash algorithm. However, during the processing of "ima_hash=", "ima_template=" has not been processed yet, and hash_setup would check the configured hash algorithm against the compiled default: ima, and reject sha256. So at the end, the hash algorithm that is actually used will be sha1.
With template "ima" removed from the configured default, we ensure that the default tempalte would at least be "ima-ng" which allows for basically any hash algorithm.
This change would not break the algorithm compatibility checks for IMA.
--- security/integrity/ima/Kconfig | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-)
security/integrity/ima/Kconfig +6 -8
@@ -69,10 +69,9 @@ choice hash, defined as 20 bytes, and a null terminated pathname, limited to 255 characters. The 'ima-ng' measurement list template permits both larger hash digests and longer - pathnames. + pathnames. The configured default template can be replaced + by specifying "ima_template=" on the boot command line. - config IMA_TEMPLATE - bool "ima" config IMA_NG_TEMPLATE bool "ima-ng (default)" config IMA_SIG_TEMPLATE
@@ -82,7 +81,6 @@ endchoice config IMA_DEFAULT_TEMPLATE string depends on IMA - default "ima" if IMA_TEMPLATE default "ima-ng" if IMA_NG_TEMPLATE default "ima-sig" if IMA_SIG_TEMPLATE
@@ -102,19 +100,19 @@ choice config IMA_DEFAULT_HASH_SHA256 bool "SHA256" - depends on CRYPTO_SHA256=y && !IMA_TEMPLATE + depends on CRYPTO_SHA256=y config IMA_DEFAULT_HASH_SHA512 bool "SHA512" - depends on CRYPTO_SHA512=y && !IMA_TEMPLATE + depends on CRYPTO_SHA512=y config IMA_DEFAULT_HASH_WP512 bool "WP512" - depends on CRYPTO_WP512=y && !IMA_TEMPLATE + depends on CRYPTO_WP512=y config IMA_DEFAULT_HASH_SM3 bool "SM3" - depends on CRYPTO_SM3=y && !IMA_TEMPLATE + depends on CRYPTO_SM3=y endchoice config IMA_DEFAULT_HASH
Greg Kroah-Hartman
maintainerPATCH 703/772 Kconfig: Add option for asm goto w/ tied outputs to workaround clang-13 bug
In reply to Greg Kroah-HartmanFrom: Sean Christopherson <[email protected]>
commit 1aa0e8b144b6474c4914439d232d15bfe883636b upstream.
Add a config option to guard (future) usage of asm_volatile_goto() that includes "tied outputs", i.e. "+" constraints that specify both an input and output parameter. clang-13 has a bug[1] that causes compilation of such inline asm to fail, and KVM wants to use a "+m" constraint to implement a uaccess form of CMPXCHG[2]. E.g. the test code fails with
<stdin>:1:29: error: invalid operand in inline asm: '.long (${1:l}) - .'
int foo(int *x) { asm goto (".long (%l[bar]) - .\n": "+m"(*x) ::: bar); return *x; bar: return 0; }
^
<stdin>:1:29: error: unknown token in expression
<inline asm>:1:9: note: instantiated into assembly here
.long () - .
^2 errors generated.
on clang-13, but passes on gcc (with appropriate asm goto support). The bug is fixed in clang-14, but won't be backported to clang-13 as the changes are too invasive/risky.
gcc also had a similar bug[3], fixed in gcc-11, where gcc failed to account for its behavior of assigning two numbers to tied outputs (one for input, one for output) when evaluating symbolic references.
[1] https://github.com/ClangBuiltLinux/linux/issues/1512
[2] https://lore.kernel.org/all/YfMruK8%[email protected]
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98096
Message-Id: <[email protected]>
--- init/Kconfig | 5 +++++ 1 file changed, 5 insertions(+)
init/Kconfig +5 -0
@@ -77,6 +77,11 @@ config CC_HAS_ASM_GOTO_OUTPUT depends on CC_HAS_ASM_GOTO def_bool $(success,echo 'int foo(int x) { asm goto ("": "=r"(x) ::: bar); return x; bar: return 0; }' | $(CC) -x c - -c -o /dev/null) +config CC_HAS_ASM_GOTO_TIED_OUTPUT + depends on CC_HAS_ASM_GOTO_OUTPUT + # Detect buggy gcc and clang, fixed in gcc-11 clang-14. + def_bool $(success,echo 'int foo(int *x) { asm goto (".long (%l[bar]) - .\n": "+m"(*x) ::: bar); return *x; bar: return 0; }' | $CC -x c - -c -o /dev/null) + config TOOLS_SUPPORT_RELR def_bool $(success,env "CC=$(CC)" "LD=$(LD)" "NM=$(NM)" "OBJCOPY=$(OBJCOPY)" $(srctree)/scripts/tools-support-relr.sh)
Greg Kroah-Hartman
maintainerPATCH 704/772 lib/string_helpers: fix not adding strarray to devices resource list
In reply to Greg Kroah-HartmanFrom: Puyou Lu <[email protected]>
commit cd290a9839cee2f6641558877e707bd373c8f6f1 upstream.
Add allocated strarray to device's resource list. This is a must to automatically release strarray when the device disappears.
Without this fix we have a memory leak in the few drivers which use devm_kasprintf_strarray().
--- lib/string_helpers.c | 3 +++ 1 file changed, 3 insertions(+)
lib/string_helpers.c +3 -0
@@ -757,6 +757,9 @@ char **devm_kasprintf_strarray(struct dereturn ERR_PTR (-ENOMEM ); } + ptr->n = n; +devres_add (dev, ptr); +return ptr->array; }EXPORT_SYMBOL_GPL (devm_kasprintf_strarray);
Greg Kroah-Hartman
maintainerPATCH 705/772 RDMA/hfi1: Fix potential integer multiplication overflow errors
In reply to Greg Kroah-HartmanFrom: Dennis Dalessandro <[email protected]>
commit f93e91a0372c922c20d5bee260b0f43b4b8a1bee upstream.
When multiplying of different types, an overflow is possible even when storing the result in a larger type. This is because the conversion is done after the multiplication. So arithmetic overflow and thus in incorrect value is possible.
Correct an instance of this in the inter packet delay calculation. Fix by ensuring one of the operands is u64 which will promote the other to u64 as well ensuring no overflow.
--- drivers/infiniband/hw/hfi1/init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/infiniband/hw/hfi1/init.c +1 -1
@@ -489,7 +489,7 @@ void set_link_ipg(struct hfi1_pportdatau16 shift, mult;u64 src;u32 current_egress_rate;/* Mbits /sec */ -u32 max_pkt_time; +u64 max_pkt_time;/* * max_pkt_time is the maximum packet egress time in units * of the fabric clock period 1/(805 MHz).
Greg Kroah-Hartman
maintainerPATCH 706/772 mmc: core: Allows to override the timeout value for ioctl() path
In reply to Greg Kroah-HartmanFrom: Bean Huo <[email protected]>
commit 23e09be254f95a5b75cd87f91a4014f3b46dda3f upstream.
Occasionally, user-land applications initiate longer timeout values for certain commands through ioctl() system call. But so far we are still using a fixed timeout of 10 seconds in mmc_poll_for_busy() on the ioctl() path, even if a custom timeout is specified in the userspace application. This patch allows custom timeout values to override this default timeout values on the ioctl path.
--- drivers/mmc/core/block.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/mmc/core/block.c +4 -4
@@ -609,11 +609,11 @@ static int __mmc_blk_ioctl_cmd(struct mmif (idata->rpmb || (cmd.flags &MMC_RSP_R1B ) ==MMC_RSP_R1B ) {/* -* Ensure RPMB/R1B command has completed by polling CMD13 -* "Send Status". +* Ensure RPMB/R1B command has completed by polling CMD13 "Send Status". Here we +* allow to override the default timeout value if a custom timeout is specified. */ - err =mmc_poll_for_busy (card,MMC_BLK_TIMEOUT_MS , false, -MMC_BUSY_IO ); + err =mmc_poll_for_busy (card, idata->ic.cmd_timeout_ms ? :MMC_BLK_TIMEOUT_MS , + false,MMC_BUSY_IO ); }return err;
Greg Kroah-Hartman
maintainerPATCH 707/772 csky: patch_text: Fixup last cpu should be master
In reply to Greg Kroah-HartmanFrom: Guo Ren <[email protected]>
commit 8c4d16471e2babe9bdfe41d6ef724526629696cb upstream.
These patch_text implementations are using stop_machine_cpuslocked infrastructure with atomic cpu_count. The original idea: When the master CPU patch_text, the others should wait for it. But current implementation is using the first CPU as master, which couldn't guarantee the remaining CPUs are waiting. This patch changes the last CPU as the master to solve the potential risk.
--- arch/csky/kernel/probes/kprobes.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/csky/kernel/probes/kprobes.c +1 -1
@@ -30,7 +30,7 @@ static int __kprobes patch_text_cb(voidstruct csky_insn_patch *param = priv;unsigned int addr = (unsigned int )param->addr; -if (atomic_inc_return (¶m->cpu_count) ==1 ) { +if (atomic_inc_return (¶m->cpu_count) ==num_online_cpus ()) { *(u16 *) addr =cpu_to_le16 (param->opcode);dcache_wb_range (addr, addr +2 );atomic_inc (¶m->cpu_count);
Greg Kroah-Hartman
maintainerPATCH 708/772 irqchip/armada-370-xp: Do not touch Performance Counter Overflow on A375, A38x, A39x
In reply to Greg Kroah-HartmanFrom: Pali Rohár <[email protected]>
commit a3d66a76348daf559873f19afc912a2a7c2ccdaf upstream.
Register ARMADA_370_XP_INT_FABRIC_MASK_OFFS is Armada 370 and XP specific and on new Armada platforms it has different meaning. It does not configure Performance Counter Overflow interrupt masking. So do not touch this register on non-A370/XP platforms (A375, A38x and A39x).
--- drivers/irqchip/irq-armada-370-xp.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
drivers/irqchip/irq-armada-370-xp.c +10 -1
@@ -308,7 +308,16 @@ static inline int armada_370_xp_msi_initstatic void armada_xp_mpic_perf_init (void ) { -unsigned long cpuid =cpu_logical_map (smp_processor_id ()); +unsigned long cpuid; + +/* +* This Performance Counter Overflow interrupt is specific for +* Armada 370 and XP. It is not available on Armada 375, 38x and 39x. +*/ +if (!of_machine_is_compatible ("marvell,armada-370-xp" )) +return ; + + cpuid =cpu_logical_map (smp_processor_id ());/* Enable Performance Counter Overflow interrupts */ writel(ARMADA_370_XP_INT_CAUSE_PERF(cpuid),
Greg Kroah-Hartman
maintainerPATCH 709/772 irqchip: irq-xtensa-mx: fix initial IRQ affinity
In reply to Greg Kroah-HartmanFrom: Max Filippov <[email protected]>
commit a255ee29252066d621df5d6b420bf534c6ba5bc0 upstream.
When irq-xtensa-mx chip is used in non-SMP configuration its irq_set_affinity callback is not called leaving IRQ affinity set empty. As a result IRQ delivery does not work in that configuration. Initialize IRQ affinity of the xtensa MX interrupt distributor to CPU 0 for all external IRQ lines.
--- drivers/irqchip/irq-xtensa-mx.c | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-)
drivers/irqchip/irq-xtensa-mx.c +14 -4
@@ -151,14 +151,25 @@ static struct irq_chip xtensa_mx_irq_chi .irq_set_affinity = xtensa_mx_irq_set_affinity, }; +static void __init xtensa_mx_init_common (struct irq_domain *root_domain) +{ +unsigned int i; + +irq_set_default_host (root_domain); +secondary_init_irq (); + +/* Initialize default IRQ routing to CPU 0 */ +for (i =0 ; i <XCHAL_NUM_EXTINTERRUPTS ; ++i) +set_er (1 ,MIROUT (i)); +} +int __init xtensa_mx_init_legacy (struct device_node *interrupt_parent) {struct irq_domain *root_domain =irq_domain_add_legacy (NULL ,NR_IRQS -1 ,1 ,0 , &xtensa_mx_irq_domain_ops, &xtensa_mx_irq_chip); -irq_set_default_host (root_domain); -secondary_init_irq (); +xtensa_mx_init_common (root_domain);return 0 ; }
@@ -168,8 +179,7 @@ static int __init xtensa_mx_init(structstruct irq_domain *root_domain =irq_domain_add_linear (np,NR_IRQS , &xtensa_mx_irq_domain_ops, &xtensa_mx_irq_chip); -irq_set_default_host (root_domain); -secondary_init_irq (); +xtensa_mx_init_common (root_domain);return 0 ; }IRQCHIP_DECLARE (xtensa_mx_irq_chip,"cdns,xtensa-mx" , xtensa_mx_init);
Greg Kroah-Hartman
maintainerPATCH 710/772 thermal: devfreq_cooling: use local ops instead of global ops
In reply to Greg Kroah-HartmanFrom: Kant Fan <[email protected]>
commit b947769b8f778db130aad834257fcaca25df2edc upstream.
Fix access illegal address problem in following condition:
There are multiple devfreq cooling devices in system, some of them has EM model but others do not. Energy model ops such as state2power will append to global devfreq_cooling_ops when the cooling device with EM model is registered. It makes the cooling device without EM model also use devfreq_cooling_ops after appending when registered later by of_devfreq_cooling_register_power() or of_devfreq_cooling_register().
The IPA governor regards the cooling devices without EM model as a power actor, because they also have energy model ops, and will access illegal address at dfc->em_pd when execute cdev->ops->get_requested_power, cdev->ops->state2power or cdev->ops->power2state.
--- drivers/thermal/devfreq_cooling.c | 25 ++++++++++++++++++------- 1 file changed, 18 insertions(+), 7 deletions(-)
drivers/thermal/devfreq_cooling.c +18 -7
@@ -358,21 +358,28 @@ of_devfreq_cooling_register_power(structstruct thermal_cooling_device *cdev;struct device *dev = df->dev.parent;struct devfreq_cooling_device *dfc; +struct thermal_cooling_device_ops *ops;char *name;int err, num_opps; - dfc =kzalloc (sizeof (*dfc),GFP_KERNEL ); -if (!dfc) + ops =kmemdup (&devfreq_cooling_ops,sizeof (*ops),GFP_KERNEL ); +if (!ops)return ERR_PTR (-ENOMEM ); + dfc =kzalloc (sizeof (*dfc),GFP_KERNEL ); +if (!dfc) { + err = -ENOMEM ; + goto free_ops; + } + dfc->devfreq = df; dfc->em_pd =em_pd_get (dev);if (dfc->em_pd) { - devfreq_cooling_ops.get_requested_power = + ops->get_requested_power = devfreq_cooling_get_requested_power; - devfreq_cooling_ops.state2power = devfreq_cooling_state2power; - devfreq_cooling_ops.power2state = devfreq_cooling_power2state; + ops->state2power = devfreq_cooling_state2power; + ops->power2state = devfreq_cooling_power2state; dfc->power_ops = dfc_power;
@@ -407,8 +414,7 @@ of_devfreq_cooling_register_power(structif (!name) goto remove_qos_req; - cdev =thermal_of_cooling_device_register (np, name, dfc, - &devfreq_cooling_ops); + cdev =thermal_of_cooling_device_register (np, name, dfc, ops);kfree (name);if (IS_ERR (cdev)) {
@@ -429,6 +435,8 @@ free_table:kfree (dfc->freq_table); free_dfc:kfree (dfc); +free_ops: +kfree (ops);return ERR_PTR (err); }
@@ -510,11 +518,13 @@ EXPORT_SYMBOL_GPL(devfreq_cooling_em_regvoid devfreq_cooling_unregister (struct thermal_cooling_device *cdev) {struct devfreq_cooling_device *dfc; +const struct thermal_cooling_device_ops *ops;struct device *dev;if (IS_ERR_OR_NULL (cdev))return ; + ops = cdev->ops; dfc = cdev->devdata; dev = dfc->devfreq->dev.parent;
@@ -525,5 +535,6 @@ void devfreq_cooling_unregister(struct tkfree (dfc->freq_table);kfree (dfc); +kfree (ops); }EXPORT_SYMBOL_GPL (devfreq_cooling_unregister);
Greg Kroah-Hartman
maintainerPATCH 711/772 mt76: fix use-after-free by removing a non-RCU wcid pointer
In reply to Greg Kroah-HartmanFrom: Felix Fietkau <[email protected]>
commit 51fb1278aa57ae0fc54adaa786e1965362bed4fb upstream.
Fixes an issue caught by KASAN about use-after-free in mt76_txq_schedule by protecting mtxq->wcid with rcu_lock between mt76_txq_schedule and sta_info_[alloc, free].
[18853.876689] ================================================================== [18853.876751] BUG: KASAN: use-after-free in mt76_txq_schedule+0x204/0xaf8 [mt76] [18853.876773] Read of size 8 at addr ffffffaf989a2138 by task mt76-tx phy0/883 [18853.876786] [18853.876810] CPU: 5 PID: 883 Comm: mt76-tx phy0 Not tainted 5.10.100-fix-510-56778d365941-kasan #5 0b01fbbcf41a530f52043508fec2e31a4215
[18853.876840] Call trace: [18853.876861] dump_backtrace+0x0/0x3ec [18853.876878] show_stack+0x20/0x2c [18853.876899] dump_stack+0x11c/0x1ac [18853.876918] print_address_description+0x74/0x514 [18853.876934] kasan_report+0x134/0x174 [18853.876948] __asan_report_load8_noabort+0x44/0x50 [18853.876976] mt76_txq_schedule+0x204/0xaf8 [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2] [18853.877002] mt76_txq_schedule_all+0x2c/0x48 [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2] [18853.877030] mt7921_tx_worker+0xa0/0x1cc [mt7921_common f0875ebac9d7b4754e1010549e7db50fbd90a047] [18853.877054] __mt76_worker_fn+0x190/0x22c [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2] [18853.877071] kthread+0x2f8/0x3b8 [18853.877087] ret_from_fork+0x10/0x30 [18853.877098] [18853.877112] Allocated by task 941: [18853.877131] kasan_save_stack+0x38/0x68 [18853.877147] __kasan_kmalloc+0xd4/0xfc [18853.877163] kasan_kmalloc+0x10/0x1c [18853.877177] __kmalloc+0x264/0x3c4 [18853.877294] sta_info_alloc+0x460/0xf88 [mac80211] [18853.877410] ieee80211_prep_connection+0x204/0x1ee0 [mac80211] [18853.877523] ieee80211_mgd_auth+0x6c4/0xa4c [mac80211] [18853.877635] ieee80211_auth+0x20/0x2c [mac80211] [18853.877733] rdev_auth+0x7c/0x438 [cfg80211] [18853.877826] cfg80211_mlme_auth+0x26c/0x390 [cfg80211] [18853.877919] nl80211_authenticate+0x6d4/0x904 [cfg80211] [18853.877938] genl_rcv_msg+0x748/0x93c [18853.877954] netlink_rcv_skb+0x160/0x2a8 [18853.877969] genl_rcv+0x3c/0x54 [18853.877985] netlink_unicast_kernel+0x104/0x1ec [18853.877999] netlink_unicast+0x178/0x268 [18853.878015] netlink_sendmsg+0x3cc/0x5f0 [18853.878030] sock_sendmsg+0xb4/0xd8 [18853.878043] ____sys_sendmsg+0x2f8/0x53c [18853.878058] ___sys_sendmsg+0xe8/0x150 [18853.878071] __sys_sendmsg+0xc4/0x1f4 [18853.878087] __arm64_compat_sys_sendmsg+0x88/0x9c [18853.878101] el0_svc_common+0x1b4/0x390 [18853.878115] do_el0_svc_compat+0x8c/0xdc [18853.878131] el0_svc_compat+0x10/0x1c [18853.878146] el0_sync_compat_handler+0xa8/0xcc [18853.878161] el0_sync_compat+0x188/0x1c0 [18853.878171] [18853.878183] Freed by task 10927: [18853.878200] kasan_save_stack+0x38/0x68 [18853.878215] kasan_set_track+0x28/0x3c [18853.878228] kasan_set_free_info+0x24/0x48 [18853.878244] __kasan_slab_free+0x11c/0x154 [18853.878259] kasan_slab_free+0x14/0x24 [18853.878273] slab_free_freelist_hook+0xac/0x1b0 [18853.878287] kfree+0x104/0x390 [18853.878402] sta_info_free+0x198/0x210 [mac80211] [18853.878515] __sta_info_destroy_part2+0x230/0x2d4 [mac80211] [18853.878628] __sta_info_flush+0x300/0x37c [mac80211] [18853.878740] ieee80211_set_disassoc+0x2cc/0xa7c [mac80211] [18853.878851] ieee80211_mgd_deauth+0x4a4/0x10a0 [mac80211] [18853.878962] ieee80211_deauth+0x20/0x2c [mac80211] [18853.879057] rdev_deauth+0x7c/0x438 [cfg80211] [18853.879150] cfg80211_mlme_deauth+0x274/0x414 [cfg80211] [18853.879243] cfg80211_mlme_down+0xe4/0x118 [cfg80211] [18853.879335] cfg80211_disconnect+0x218/0x2d8 [cfg80211] [18853.879427] __cfg80211_leave+0x17c/0x240 [cfg80211] [18853.879519] cfg80211_leave+0x3c/0x58 [cfg80211] [18853.879611] wiphy_suspend+0xdc/0x200 [cfg80211] [18853.879628] dpm_run_callback+0x58/0x408 [18853.879642] __device_suspend+0x4cc/0x864 [18853.879658] async_suspend+0x34/0xf4 [18853.879673] async_run_entry_fn+0xe0/0x37c [18853.879689] process_one_work+0x508/0xb98 [18853.879702] worker_thread+0x7f4/0xcd4 [18853.879717] kthread+0x2f8/0x3b8 [18853.879731] ret_from_fork+0x10/0x30 [18853.879741] [18853.879757] The buggy address belongs to the object at ffffffaf989a2000 [18853.879757] which belongs to the cache kmalloc-8k of size 8192 [18853.879774] The buggy address is located 312 bytes inside of [18853.879774] 8192-byte region [ffffffaf989a2000, ffffffaf989a4000) [18853.879787] The buggy address belongs to the page: [18853.879807] page:000000004bda2a59 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1d89a0 [18853.879823] head:000000004bda2a59 order:3 compound_mapcount:0 compound_pincount:0 [18853.879839] flags: 0x8000000000010200(slab|head) [18853.879857] raw: 8000000000010200 ffffffffbc89e208 ffffffffb7fb5208 ffffffaec000cc80 [18853.879873] raw: 0000000000000000 0000000000010001 00000001ffffffff 0000000000000000 [18853.879885] page dumped because: kasan: bad access detected [18853.879896] [18853.879907] Memory state around the buggy address: [18853.879922] ffffffaf989a2000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [18853.879935] ffffffaf989a2080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [18853.879948] >ffffffaf989a2100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [18853.879961] ^ [18853.879973] ffffffaf989a2180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [18853.879986] ffffffaf989a2200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [18853.879998] ==================================================================
--- drivers/net/wireless/mediatek/mt76/mac80211.c | 2 +- drivers/net/wireless/mediatek/mt76/mt76.h | 2 +- drivers/net/wireless/mediatek/mt76/mt7603/main.c | 2 +- drivers/net/wireless/mediatek/mt76/mt7615/main.c | 2 +- drivers/net/wireless/mediatek/mt76/mt76x02_util.c | 4 +++- drivers/net/wireless/mediatek/mt76/mt7915/main.c | 2 +- drivers/net/wireless/mediatek/mt76/mt7921/main.c | 2 +- drivers/net/wireless/mediatek/mt76/tx.c | 9 ++++----- 8 files changed, 13 insertions(+), 12 deletions(-)
drivers/net/wireless/mediatek/mt76/mac80211.c +1 -1
@@ -1266,7 +1266,7 @@ mt76_sta_add(struct mt76_dev *dev, struccontinue ; mtxq = (struct mt76_txq *)sta->txq[i]->drv_priv; - mtxq->wcid = wcid; + mtxq->wcid = wcid->idx; }ewma_signal_init (&wcid->rssi);
drivers/net/wireless/mediatek/mt76/mt76.h +1 -1
@@ -267,7 +267,7 @@ struct mt76_wcid { };struct mt76_txq { -struct mt76_wcid *wcid; +u16 wcid;u16 agg_ssn;bool send_bar;
drivers/net/wireless/mediatek/mt76/mt7603/main.c +1 -1
@@ -75,7 +75,7 @@ mt7603_add_interface(struct ieee80211_hwmt7603_wtbl_init (dev, idx, mvif->idx, bc_addr); mtxq = (struct mt76_txq *)vif->txq->drv_priv; - mtxq->wcid = &mvif->sta.wcid; + mtxq->wcid = idx;rcu_assign_pointer (dev->mt76.wcid[idx], &mvif->sta.wcid); out:
drivers/net/wireless/mediatek/mt76/mt7615/main.c +1 -1
@@ -234,7 +234,7 @@ static int mt7615_add_interface(struct ircu_assign_pointer (dev->mt76.wcid[idx], &mvif->sta.wcid);if (vif->txq) { mtxq = (struct mt76_txq *)vif->txq->drv_priv; - mtxq->wcid = &mvif->sta.wcid; + mtxq->wcid = idx; } ret =mt7615_mcu_add_dev_info (phy, vif, true);
drivers/net/wireless/mediatek/mt76/mt76x02_util.c +3 -1
@@ -292,7 +292,8 @@ mt76x02_vif_init(struct mt76x02_dev *devmt76_packet_id_init (&mvif->group_wcid); mtxq = (struct mt76_txq *)vif->txq->drv_priv; - mtxq->wcid = &mvif->group_wcid; +rcu_assign_pointer (dev->mt76.wcid[MT_VIF_WCID (idx)], &mvif->group_wcid); + mtxq->wcid =MT_VIF_WCID (idx); }int
@@ -345,6 +346,7 @@ void mt76x02_remove_interface(struct ieestruct mt76x02_vif *mvif = (struct mt76x02_vif *)vif->drv_priv; dev->mt76.vif_mask &= ~BIT (mvif->idx); +rcu_assign_pointer (dev->mt76.wcid[mvif->group_wcid.idx],NULL );mt76_packet_id_flush (&dev->mt76, &mvif->group_wcid); }EXPORT_SYMBOL_GPL (mt76x02_remove_interface);
drivers/net/wireless/mediatek/mt76/mt7915/main.c +1 -1
@@ -245,7 +245,7 @@ static int mt7915_add_interface(struct ircu_assign_pointer (dev->mt76.wcid[idx], &mvif->sta.wcid);if (vif->txq) { mtxq = (struct mt76_txq *)vif->txq->drv_priv; - mtxq->wcid = &mvif->sta.wcid; + mtxq->wcid = idx; } if (vif->type != NL80211_IFTYPE_AP &&
drivers/net/wireless/mediatek/mt76/mt7921/main.c +1 -1
@@ -329,7 +329,7 @@ static int mt7921_add_interface(struct ircu_assign_pointer (dev->mt76.wcid[idx], &mvif->sta.wcid);if (vif->txq) { mtxq = (struct mt76_txq *)vif->txq->drv_priv; - mtxq->wcid = &mvif->sta.wcid; + mtxq->wcid = idx; } out:
drivers/net/wireless/mediatek/mt76/tx.c +4 -5
@@ -436,12 +436,11 @@ mt76_txq_stopped(struct mt76_queue *q)static int mt76_txq_send_burst (struct mt76_phy *phy,struct mt76_queue *q, -struct mt76_txq *mtxq) +struct mt76_txq *mtxq,struct mt76_wcid *wcid) {struct mt76_dev *dev = phy->dev;struct ieee80211_txq *txq =mtxq_to_txq (mtxq);enum mt76_txq_id qid =mt76_txq_get_qid (txq); -struct mt76_wcid *wcid = mtxq->wcid;struct ieee80211_tx_info *info;struct sk_buff *skb;int n_frames =1 ;
@@ -521,8 +520,8 @@ mt76_txq_schedule_list(struct mt76_phy *break ; mtxq = (struct mt76_txq *)txq->drv_priv; - wcid = mtxq->wcid; -if (wcid &&test_bit (MT_WCID_FLAG_PS , &wcid->flags)) + wcid =rcu_dereference (dev->wcid[mtxq->wcid]); +if (!wcid ||test_bit (MT_WCID_FLAG_PS , &wcid->flags))continue ;spin_lock_bh (&q->lock);
@@ -541,7 +540,7 @@ mt76_txq_schedule_list(struct mt76_phy * }if (!mt76_txq_stopped (q)) - n_frames =mt76_txq_send_burst (phy, q, mtxq); + n_frames =mt76_txq_send_burst (phy, q, mtxq, wcid);spin_unlock_bh (&q->lock);
Greg Kroah-Hartman
maintainerPATCH 712/772 cfg80211: declare MODULE_FIRMWARE for regulatory.db
In reply to Greg Kroah-HartmanFrom: Dimitri John Ledkov <[email protected]>
commit 7bc7981eeebe1b8e603ad2ffc5e84f4df76920dd upstream.
Add MODULE_FIRMWARE declarations for regulatory.db and regulatory.db.p7s such that userspace tooling can discover and include these files.
--- net/wireless/reg.c | 4 ++++ 1 file changed, 4 insertions(+)
net/wireless/reg.c +4 -0
@@ -807,6 +807,8 @@ static int __init load_builtin_regdb_keyreturn 0 ; } +MODULE_FIRMWARE ("regulatory.db.p7s" ); +static bool regdb_has_valid_signature (const u8 *data,unsigned int size) {const struct firmware *sig;
@@ -1078,6 +1080,8 @@ static void regdb_fw_cb(const struct firrelease_firmware (fw); } +MODULE_FIRMWARE ("regulatory.db" ); +static int query_regdb_file (const char *alpha2) {ASSERT_RTNL ();
Greg Kroah-Hartman
maintainerPATCH 713/772 mac80211: upgrade passive scan to active scan on DFS channels after beacon rx
In reply to Greg Kroah-HartmanFrom: Felix Fietkau <[email protected]>
commit b041b7b9de6e1d4362de855ab90f9d03ef323edd upstream.
In client mode, we can't connect to hidden SSID APs or SSIDs not advertised in beacons on DFS channels, since we're forced to passive scan. Fix this by sending out a probe request immediately after the first beacon, if active scan was requested by the user.
--- net/mac80211/ieee80211_i.h | 5 +++++ net/mac80211/scan.c | 20 ++++++++++++++++++++ 2 files changed, 25 insertions(+)
net/mac80211/ieee80211_i.h +5 -0
@@ -1128,6 +1128,9 @@ struct tpt_led_trigger {* a scan complete for an aborted scan. * @SCAN_HW_CANCELLED: Set for our scan work function when the scan is being * cancelled. +* @SCAN_BEACON_WAIT: Set whenever we're passive scanning because of radar/no-IR +* and could send a probe request after receiving a beacon. +* @SCAN_BEACON_DONE: Beacon received, we can now send a probe request */ enum {SCAN_SW_SCANNING ,
@@ -1136,6 +1139,8 @@ enum {SCAN_COMPLETED ,SCAN_ABORTED ,SCAN_HW_CANCELLED , +SCAN_BEACON_WAIT , + SCAN_BEACON_DONE, };/**
net/mac80211/scan.c +20 -0
@@ -281,6 +281,16 @@ void ieee80211_scan_rx(struct ieee80211_if (likely (!sdata1 && !sdata2))return ; +if (test_and_clear_bit (SCAN_BEACON_WAIT , &local->scanning)) { +/* +* we were passive scanning because of radar/no-IR, but +* the beacon/proberesp rx gives us an opportunity to upgrade +* to active scan +*/ +set_bit (SCAN_BEACON_DONE , &local->scanning); +ieee80211_queue_delayed_work (&local->hw, &local->scan_work,0 ); + } +if (ieee80211_is_probe_resp (mgmt->frame_control)) {struct cfg80211_scan_request *scan_req;struct cfg80211_sched_scan_request *sched_scan_req;
@@ -787,6 +797,8 @@ static int __ieee80211_start_scan(struct IEEE80211_CHAN_RADAR)) || !req->n_ssids) { next_delay = IEEE80211_PASSIVE_CHANNEL_TIME; + if (req->n_ssids) + set_bit(SCAN_BEACON_WAIT, &local->scanning); } else {ieee80211_scan_state_send_probe (local, &next_delay); next_delay =IEEE80211_CHANNEL_TIME ;
@@ -998,6 +1010,8 @@ set_channel: !scan_req->n_ssids) { *next_delay =IEEE80211_PASSIVE_CHANNEL_TIME ; local->next_scan_state =SCAN_DECISION ; +if (scan_req->n_ssids) +set_bit (SCAN_BEACON_WAIT , &local->scanning);return ; }
@@ -1090,6 +1104,8 @@ void ieee80211_scan_work(struct work_str goto out; } +clear_bit (SCAN_BEACON_WAIT , &local->scanning); +/* * as long as no delay is required advance immediately * without scheduling a new work
@@ -1100,6 +1116,10 @@ void ieee80211_scan_work(struct work_str goto out_complete; } +if (test_and_clear_bit (SCAN_BEACON_DONE , &local->scanning) && + local->next_scan_state ==SCAN_DECISION ) + local->next_scan_state =SCAN_SEND_PROBE ; +switch (local->next_scan_state) {case SCAN_DECISION :/* if no more bands/channels left, complete scan */
Greg Kroah-Hartman
maintainerPATCH 714/772 um: virtio_uml: Fix broken device handling in time-travel
In reply to Greg Kroah-HartmanFrom: Johannes Berg <[email protected]>
commit af9fb41ed315ce95f659f0b10b4d59a71975381d upstream.
If a device implementation crashes, virtio_uml will mark it as dead by calling virtio_break_device() and scheduling the work that will remove it.
This still seems like the right thing to do, but it's done directly while reading the message, and if time-travel is used, this is in the time-travel handler, outside of the normal Linux machinery. Therefore, we cannot acquire locks or do normal "linux-y" things because e.g. lockdep will be confused about the context.
Move handling this situation out of the read function and into the actual IRQ handler and response handling instead, so that in the case of time-travel we don't call it in the wrong context.
Chances are the system will still crash immediately, since the device implementation crashing may also cause the time- travel controller to go down, but at least all of that now happens without strange warnings from lockdep.
--- arch/um/drivers/virtio_uml.c | 33 +++++++++++++++++++++++---------- 1 file changed, 23 insertions(+), 10 deletions(-)
arch/um/drivers/virtio_uml.c +23 -10
@@ -63,6 +63,7 @@ struct virtio_uml_device { u8 config_changed_irq:1;uint64_t vq_irq_vq_map; +int recv_rc; };struct virtio_uml_vq_info {
@@ -148,14 +149,6 @@ static int vhost_user_recv(struct virtio rc =vhost_user_recv_header (fd, msg); -if (rc == -ECONNRESET && vu_dev->registered) { -struct virtio_uml_platform_data *pdata; - - pdata = vu_dev->pdata; - -virtio_break_device (&vu_dev->vdev); -schedule_work (&pdata->conn_broken_wk); - }if (rc)return rc; size = msg->header.size;
@@ -164,6 +157,21 @@ static int vhost_user_recv(struct virtioreturn full_read (fd, &msg->payload, size, false); } +static void vhost_user_check_reset (struct virtio_uml_device *vu_dev, +int rc) +{ +struct virtio_uml_platform_data *pdata = vu_dev->pdata; + +if (rc != -ECONNRESET ) +return ; + +if (!vu_dev->registered) +return ; + +virtio_break_device (&vu_dev->vdev); +schedule_work (&pdata->conn_broken_wk); +} +static int vhost_user_recv_resp (struct virtio_uml_device *vu_dev,struct vhost_user_msg *msg,size_t max_payload_size)
@@ -171,8 +179,10 @@ static int vhost_user_recv_resp(struct vint rc =vhost_user_recv (vu_dev, vu_dev->sock, msg, max_payload_size, true); -if (rc) +if (rc) { +vhost_user_check_reset (vu_dev, rc);return rc; + }if (msg->header.flags != (VHOST_USER_FLAG_REPLY |VHOST_USER_VERSION ))return -EPROTO ;
@@ -369,6 +379,7 @@ static irqreturn_t vu_req_read_message(ssizeof (msg.msg.payload) + sizeof(msg.extra_payload)); + vu_dev->recv_rc = rc;if (rc)return IRQ_NONE ;
@@ -412,7 +423,9 @@ static irqreturn_t vu_req_interrupt(intif (!um_irq_timetravel_handler_used ()) ret =vu_req_read_message (vu_dev,NULL ); -if (vu_dev->vq_irq_vq_map) { +if (vu_dev->recv_rc) { +vhost_user_check_reset (vu_dev, vu_dev->recv_rc); + }else if (vu_dev->vq_irq_vq_map) {struct virtqueue *vq;virtio_device_for_each_vq ((&vu_dev->vdev), vq) {
Greg Kroah-Hartman
maintainerPATCH 715/772 um: Use asm-generic/dma-mapping.h
In reply to Greg Kroah-HartmanFrom: Johannes Berg <[email protected]>
commit 365719035526e8eda214a1cedb2e1c96e969a0d7 upstream.
If DMA (PCI over virtio) is enabled, then some drivers may enable CONFIG_DMA_OPS as well, and then we pull in the x86 definition of get_arch_dma_ops(), which uses the dma_ops symbol, which isn't defined.
Since we don't have real DMA ops nor any kind of IOMMU fix this in the simplest possible way: pull in the asm-generic file instead of inheriting the x86 one. It's not clear why those drivers that do (e.g. VDPA) "select DMA_OPS", and if they'd even work with this, but chances are nobody will be wanting to do that anyway, so fixing the build failure is good enough.
--- arch/um/include/asm/Kbuild | 1 + 1 file changed, 1 insertion(+)
arch/um/include/asm/Kbuild +1 -0
@@ -4,6 +4,7 @@ generic-y += bug.h generic-y += compat.h generic-y += current.h generic-y += device.h +generic-y += dma-mapping.h generic-y += emergency-restart.h generic-y += exec.h generic-y += extable.h
Greg Kroah-Hartman
maintainerPATCH 716/772 um: chan_user: Fix winch_tramp() return value
In reply to Greg Kroah-HartmanFrom: Johannes Berg <[email protected]>
commit 57ae0b67b747031bc41fb44643aa5344ab58607e upstream.
The previous fix here was only partially correct, it did result in returning a proper error value in case of error, but it also clobbered the pid that we need to return from this function (not just zero for success).
As a result, it returned 0 here, but later this is treated as a pid and used to kill the process, but since it's now 0 we kill(0, SIGKILL), which makes UML kill itself rather than just the helper thread.
Fix that and make it more obvious by using a separate variable for the pid.
--- arch/um/drivers/chan_user.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
arch/um/drivers/chan_user.c +5 -4
@@ -220,7 +220,7 @@ static int winch_tramp(int fd, struct tt unsigned long *stack_out) {struct winch_data data; -int fds[2 ], n, err; +int fds[2 ], n, err, pid;char c; err =os_pipe (fds,1 ,1 );
@@ -238,8 +238,9 @@ static int winch_tramp(int fd, struct tt* problem with /dev/net/tun, which if held open by this * thread, prevents the TUN/TAP device from being reused. */ - err =run_helper_thread (winch_thread, &data,CLONE_FILES , stack_out); -if (err <0 ) { + pid =run_helper_thread (winch_thread, &data,CLONE_FILES , stack_out); +if (pid <0 ) { + err = pid;printk (UM_KERN_ERR "fork of winch_thread failed - errno = %d\n" , -err); goto out_close;
@@ -263,7 +264,7 @@ static int winch_tramp(int fd, struct tt goto out_close; } -return err; +return pid; out_close:close (fds[1 ]);
Greg Kroah-Hartman
maintainerPATCH 717/772 um: Fix out-of-bounds read in LDT setup
In reply to Greg Kroah-HartmanFrom: Vincent Whitchurch <[email protected]>
commit 2a4a62a14be1947fa945c5c11ebf67326381a568 upstream.
syscall_stub_data() expects the data_count parameter to be the number of longs, not bytes.
==================================================================
BUG: KASAN: stack-out-of-bounds in syscall_stub_data+0x70/0xe0 Read of size 128 at addr 000000006411f6f0 by task swapper/1 CPU: 0 PID: 1 Comm: swapper Not tainted 5.18.0+ #18 Call Trace: show_stack.cold+0x166/0x2a7 __dump_stack+0x3a/0x43 dump_stack_lvl+0x1f/0x27 print_report.cold+0xdb/0xf81 kasan_report+0x119/0x1f0 kasan_check_range+0x3a3/0x440 memcpy+0x52/0x140 syscall_stub_data+0x70/0xe0 write_ldt_entry+0xac/0x190 init_new_ldt+0x515/0x960 init_new_context+0x2c4/0x4d0 mm_init.constprop.0+0x5ed/0x760 mm_alloc+0x118/0x170 0x60033f48 do_one_initcall+0x1d7/0x860 0x60003e7b kernel_init+0x6e/0x3d4 new_thread_handler+0x1e7/0x2c0 The buggy address belongs to stack of task swapper/1 and is located at offset 64 in frame: init_new_ldt+0x0/0x960
This frame has 2 objects:
[32, 40) 'addr'
[64, 80) 'desc'
==================================================================
--- arch/x86/um/ldt.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
arch/x86/um/ldt.c +4 -2
@@ -23,9 +23,11 @@ static long write_ldt_entry(struct mm_id {long res;void *stub_addr; + +BUILD_BUG_ON (sizeof (*desc) %sizeof (long )); + res =syscall_stub_data (mm_idp, (unsigned long *)desc, - (sizeof (*desc) +sizeof (long ) -1 ) & - ~(sizeof (long ) -1 ), +sizeof (*desc) /sizeof (long ), addr, &stub_addr);if (!res) { unsigned long args[] = { func,
Greg Kroah-Hartman
maintainerPATCH 718/772 kexec_file: drop weak attribute from arch_kexec_apply_relocations[_add]
In reply to Greg Kroah-HartmanFrom: Naveen N. Rao <[email protected]>
commit 3e35142ef99fe6b4fe5d834ad43ee13cca10a2dc upstream.
Since commit d1bcae833b32f1 ("ELF: Don't generate unused section symbols") [1], binutils (v2.36+) started dropping section symbols that it thought were unused. This isn't an issue in general, but with kexec_file.c, gcc is placing kexec_arch_apply_relocations[_add] into a separate .text.unlikely section and the section symbol ".text.unlikely" is being dropped. Due to this, recordmcount is unable to find a non-weak symbol in .text.unlikely to generate a relocation record against.
Address this by dropping the weak attribute from these functions. Instead, follow the existing pattern of having architectures #define the name of the function they want to override in their headers.
[1] https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=d1bcae833b32f1
--- arch/s390/include/asm/kexec.h | 10 +++++++++ arch/x86/include/asm/kexec.h | 8 +++++++ include/linux/kexec.h | 46 ++++++++++++++++++++++++++++++++++-------- kernel/kexec_file.c | 34 ------------------------------- 4 files changed, 56 insertions(+), 42 deletions(-)
arch/s390/include/asm/kexec.h +10 -0
@@ -9,6 +9,8 @@#ifndef _S390_KEXEC_H#define _S390_KEXEC_H +#include <linux/module.h> +#include <asm/processor.h> #include <asm/page.h> #include <asm/setup.h>
@@ -83,4 +85,12 @@ struct kimage_arch {extern const struct kexec_file_ops s390_kexec_image_ops;extern const struct kexec_file_ops s390_kexec_elf_ops; +#ifdef CONFIG_KEXEC_FILE +struct purgatory_info ; +int arch_kexec_apply_relocations_add (struct purgatory_info *pi, +Elf_Shdr *section, +const Elf_Shdr *relsec, +const Elf_Shdr *symtab); +#define arch_kexec_apply_relocations_add arch_kexec_apply_relocations_add +#endif #endif /*_S390_KEXEC_H */
arch/x86/include/asm/kexec.h +8 -0
@@ -186,6 +186,14 @@ extern int arch_kexec_post_alloc_pages(vextern void arch_kexec_pre_free_pages (void *vaddr,unsigned int pages);#define arch_kexec_pre_free_pages arch_kexec_pre_free_pages +#ifdef CONFIG_KEXEC_FILE +struct purgatory_info ; +int arch_kexec_apply_relocations_add (struct purgatory_info *pi, +Elf_Shdr *section, +const Elf_Shdr *relsec, +const Elf_Shdr *symtab); +#define arch_kexec_apply_relocations_add arch_kexec_apply_relocations_add +#endif #endif typedef void crash_vmclear_fn (void );
include/linux/kexec.h +38 -8
58 lines not on this page · raw message
kernel/kexec_file.c +0 -34
@@ -109,40 +109,6 @@ int __weak arch_kexec_kernel_verify_sig(#endif /* -* arch_kexec_apply_relocations_add - apply relocations of type RELA -* @pi: Purgatory to be relocated. -* @section: Section relocations applying to. -* @relsec: Section containing RELAs. -* @symtab: Corresponding symtab. -* -* Return: 0 on success, negative errno on error. -*/ -int __weak -arch_kexec_apply_relocations_add (struct purgatory_info *pi,Elf_Shdr *section, -const Elf_Shdr *relsec,const Elf_Shdr *symtab) -{ -pr_err ("RELA relocation unsupported.\n" ); -return -ENOEXEC ; -} - -/* -* arch_kexec_apply_relocations - apply relocations of type REL -* @pi: Purgatory to be relocated. -* @section: Section relocations applying to. -* @relsec: Section containing RELs. -* @symtab: Corresponding symtab. -* -* Return: 0 on success, negative errno on error. -*/ -int __weak -arch_kexec_apply_relocations (struct purgatory_info *pi,Elf_Shdr *section, -const Elf_Shdr *relsec,const Elf_Shdr *symtab) -{ -pr_err ("REL relocation unsupported.\n" ); -return -ENOEXEC ; -} - -/* * Free up memory used by kernel, initrd, and command line. This is temporary * memory allocation which is not needed any more after these buffers have * been loaded into separate segments and have been copied elsewhere.
Greg Kroah-Hartman
maintainerPATCH 719/772 ftrace: Clean up hash direct_functions on register failures
In reply to Greg Kroah-HartmanFrom: Song Liu <[email protected]>
commit 7d54c15cb89a29a5f59e5ffc9ee62e6591769ef1 upstream.
We see the following GPF when register_ftrace_direct fails:
[ ] general protection fault, probably for non-canonical address \
0x200000000000010: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI
[...]
[ ] RIP: 0010:ftrace_find_rec_direct+0x53/0x70
[ ] Code: 48 c1 e0 03 48 03 42 08 48 8b 10 31 c0 48 85 d2 74 [...] [ ] RSP: 0018:ffffc9000138bc10 EFLAGS: 00010206
[ ] RAX: 0000000000000000 RBX: ffffffff813e0df0 RCX: 000000000000003b [ ] RDX: 0200000000000000 RSI: 000000000000000c RDI: ffffffff813e0df0 [ ] RBP: ffffffffa00a3000 R08: ffffffff81180ce0 R09: 0000000000000001 [ ] R10: ffffc9000138bc18 R11: 0000000000000001 R12: ffffffff813e0df0 [ ] R13: ffffffff813e0df0 R14: ffff888171b56400 R15: 0000000000000000 [ ] FS: 00007fa9420c7780(0000) GS:ffff888ff6a00000(0000) knlGS:000000000 [ ] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ ] CR2: 000000000770d000 CR3: 0000000107d50003 CR4: 0000000000370ee0 [ ] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ ] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ ] Call Trace:
[ ] <TASK> [ ] register_ftrace_direct+0x54/0x290 [ ] ? render_sigset_t+0xa0/0xa0 [ ] bpf_trampoline_update+0x3f5/0x4a0 [ ] ? 0xffffffffa00a3000 [ ] bpf_trampoline_link_prog+0xa9/0x140 [ ] bpf_tracing_prog_attach+0x1dc/0x450 [ ] bpf_raw_tracepoint_open+0x9a/0x1e0 [ ] ? find_held_lock+0x2d/0x90 [ ] ? lock_release+0x150/0x430 [ ] __sys_bpf+0xbd6/0x2700 [ ] ? lock_is_held_type+0xd8/0x130 [ ] __x64_sys_bpf+0x1c/0x20 [ ] do_syscall_64+0x3a/0x80 [ ] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ ] RIP: 0033:0x7fa9421defa9
[ ] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 9 f8 [...] [ ] RSP: 002b:00007ffed743bd78 EFLAGS: 00000246 ORIG_RAX: 0000000000000141 [ ] RAX: ffffffffffffffda RBX: 00000000069d2480 RCX: 00007fa9421defa9 [ ] RDX: 0000000000000078 RSI: 00007ffed743bd80 RDI: 0000000000000011 [ ] RBP: 00007ffed743be00 R08: 0000000000bb7270 R09: 0000000000000000 [ ] R10: 00000000069da210 R11: 0000000000000246 R12: 0000000000000001 [ ] R13: 00007ffed743c4b0 R14: 00000000069d2480 R15: 0000000000000001 [ ] </TASK>
[ ] Modules linked in: klp_vm(OK)
[ ] ---[ end trace 0000000000000000 ]---
One way to trigger this is:
1. load a livepatch that patches kernel function xxx;
2. run bpftrace -e 'kfunc:xxx {}', this will fail (expected for now);
3. repeat #2 => gpf.
This is because the entry is added to direct_functions, but not removed. Fix this by remove the entry from direct_functions when register_ftrace_direct fails.
Also remove the last trailing space from ftrace.c, so we don't have to worry about it anymore.
--- kernel/trace/ftrace.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
kernel/trace/ftrace.c +2 -3
@@ -4448,7 +4448,7 @@ int ftrace_func_mapper_add_ip(struct ftr* @ip: The instruction pointer address to remove the data from * * Returns the data if it is found, otherwise NULL. -* Note, if the data pointer is used as the data itself, (see +* Note, if the data pointer is used as the data itself, (see * ftrace_func_mapper_find_ip(), then the return value may be meaningless, * if the data pointer was set to zero. */
@@ -5151,8 +5151,6 @@ int register_ftrace_direct(unsigned long goto out_unlock; ret =ftrace_set_filter_ip (&direct_ops, ip,0 ,0 ); -if (ret) -remove_hash_entry (direct_functions, entry);if (!ret && !(direct_ops.flags &FTRACE_OPS_FL_ENABLED )) { ret =register_ftrace_function (&direct_ops);
@@ -5161,6 +5159,7 @@ int register_ftrace_direct(unsigned long }if (ret) { +remove_hash_entry (direct_functions, entry);kfree (entry);if (!direct->count) {list_del_rcu (&direct->next);
Greg Kroah-Hartman
maintainerPATCH 720/772 ksmbd: fix outstanding credits related bugs
In reply to Greg Kroah-HartmanFrom: Hyunchul Lee <[email protected]>
commit 376b9133826865568167b4091ef92a68c4622b87 upstream.
outstanding credits must be initialized to 0,
because it means the sum of credits consumed by
in-flight requests.
And outstanding credits must be compared with
total credits in smb2_validate_credit_charge(),
because total credits are the sum of credits
granted by ksmbd.
This patch fix the following error,
while frametest with Windows clients:
Limits exceeding the maximum allowable outstanding requests, given : 128, pending : 8065
--- fs/ksmbd/connection.c | 2 +- fs/ksmbd/smb2misc.c | 2 +- fs/ksmbd/smb_common.c | 4 +++- 3 files changed, 5 insertions(+), 3 deletions(-)
fs/ksmbd/connection.c +1 -1
@@ -62,7 +62,7 @@ struct ksmbd_conn *ksmbd_conn_alloc(voidatomic_set (&conn->req_running,0 );atomic_set (&conn->r_count,0 ); conn->total_credits =1 ; - conn->outstanding_credits =1 ; + conn->outstanding_credits =0 ;init_waitqueue_head (&conn->req_running_q);INIT_LIST_HEAD (&conn->conns_list);
fs/ksmbd/smb2misc.c +1 -1
@@ -338,7 +338,7 @@ static int smb2_validate_credit_charge(s ret =1 ; } -if ((u64 )conn->outstanding_credits + credit_charge > conn->vals->max_credits) { +if ((u64 )conn->outstanding_credits + credit_charge > conn->total_credits) {ksmbd_debug (SMB ,"Limits exceeding the maximum allowable outstanding requests, given : %u, pending : %u\n" , credit_charge, conn->outstanding_credits); ret =1 ;
fs/ksmbd/smb_common.c +3 -1
@@ -140,8 +140,10 @@ int ksmbd_verify_smb_message(struct ksmb hdr = work->request_buf;if (*(__le32 *)hdr->Protocol ==SMB1_PROTO_NUMBER && - hdr->Command ==SMB_COM_NEGOTIATE ) + hdr->Command ==SMB_COM_NEGOTIATE ) { + work->conn->outstanding_credits++;return 0 ; + }return -EINVAL ; }
Greg Kroah-Hartman
maintainerPATCH 721/772 iommu/msm: Fix an incorrect NULL check on list iterator
In reply to Greg Kroah-HartmanFrom: Xiaomeng Tong <[email protected]>
commit 8b9ad480bd1dd25f4ff4854af5685fa334a2f57a upstream.
The bug is here:
if (!iommu || iommu->dev->of_node != spec->np) {The list iterator value 'iommu' will *always* be set and non-NULL by list_for_each_entry(), so it is incorrect to assume that the iterator value will be NULL if the list is empty or no element is found (in fact, it will point to a invalid structure object containing HEAD).
To fix the bug, use a new value 'iter' as the list iterator, while use the old value 'iommu' as a dedicated variable to point to the found one, and remove the unneeded check for 'iommu->dev->of_node != spec->np' outside the loop.
--- drivers/iommu/msm_iommu.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
drivers/iommu/msm_iommu.c +7 -4
@@ -615,16 +615,19 @@ static void insert_iommu_master(struct dstatic int qcom_iommu_of_xlate (struct device *dev,struct of_phandle_args *spec) { -struct msm_iommu_dev *iommu; +struct msm_iommu_dev *iommu =NULL , *iter;unsigned long flags;int ret =0 ;spin_lock_irqsave (&msm_iommu_lock, flags); -list_for_each_entry (iommu, &qcom_iommu_devices, dev_node) -if (iommu->dev->of_node == spec->np) +list_for_each_entry (iter, &qcom_iommu_devices, dev_node) { +if (iter->dev->of_node == spec->np) { + iommu = iter;break ; + } + } -if (!iommu || iommu->dev->of_node != spec->np) { +if (!iommu) { ret = -ENODEV ; goto fail; }
Greg Kroah-Hartman
maintainerPATCH 722/772 iommu/dma: Fix iova map result check bug
In reply to Greg Kroah-HartmanFrom: Yunfei Wang <[email protected]>
commit a3884774d731f03d3a3dd4fb70ec2d9341ceb39d upstream.
The data type of the return value of the iommu_map_sg_atomic is ssize_t, but the data type of iova size is size_t, e.g. one is int while the other is unsigned int.
When iommu_map_sg_atomic return value is compared with iova size, it will force the signed int to be converted to unsigned int, if iova map fails and iommu_map_sg_atomic return error code is less than 0, then (ret < iova_len) is false, which will to cause not do free iova, and the master can still successfully get the iova of map fail, which is not expected.
Therefore, we need to check the return value of iommu_map_sg_atomic in two cases according to whether it is less than 0.
--- drivers/iommu/dma-iommu.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/iommu/dma-iommu.c +4 -3
@@ -772,6 +772,7 @@ static struct page **__iommu_dma_alloc_nunsigned int count, min_size, alloc_sizes = domain->pgsize_bitmap;struct page **pages;dma_addr_t iova; +ssize_t ret;if (static_branch_unlikely (&iommu_deferred_attach_enabled) &&iommu_deferred_attach (dev, domain))
@@ -809,8 +810,8 @@ static struct page **__iommu_dma_alloc_narch_dma_prep_coherent (sg_page (sg), sg->length); } -if (iommu_map_sg_atomic (domain, iova, sgt->sgl, sgt->orig_nents, ioprot) - < size) + ret =iommu_map_sg_atomic (domain, iova, sgt->sgl, sgt->orig_nents, ioprot); +if (ret <0 || ret < size) goto out_free_sg; sgt->sgl->dma_address = iova;
@@ -1207,7 +1208,7 @@ static int iommu_dma_map_sg(struct devic* implementation - it knows better than we do. */ ret =iommu_map_sg_atomic (domain, iova, sg, nents, prot); -if (ret < iova_len) +if (ret <0 || ret < iova_len) goto out_free_iova;return __finalise_sg (dev, sg, nents, iova);
Greg Kroah-Hartman
maintainerPATCH 723/772 Revert "mm/cma.c: remove redundant cma_mutex lock"
In reply to Greg Kroah-HartmanFrom: Dong Aisheng <[email protected]>
commit 60a60e32cf91169840abcb4a80f0b0df31708ba7 upstream.
This reverts commit a4efc174b382fcdb which introduced a regression issue that when there're multiple processes allocating dma memory in parallel by calling dma_alloc_coherent(), it may fail sometimes as follows:
Error log:
cma: cma_alloc: linux,cma: alloc failed, req-size: 148 pages, ret: -16
cma: number of available pages:
3@125+20@172+12@236+4@380+32@736+17@2287+23@2473+20@36076+99@40477+108@40852+44@41108+20@41196+108@41364+108@41620+ 108@42900+108@43156+483@44061+1763@45341+1440@47712+20@49324+20@49388+5076@49452+2304@55040+35@58141+20@58220+20@58284+ 7188@58348+84@66220+7276@66452+227@74525+6371@75549=> 33161 free of 81920 total pages
When issue happened, we saw there were still 33161 pages (129M) free CMA memory and a lot available free slots for 148 pages in CMA bitmap that we want to allocate.
When dumping memory info, we found that there was also ~342M normal memory, but only 1352K CMA memory left in buddy system while a lot of pageblocks were isolated.
Memory info log:
Normal free:351096kB min:30000kB low:37500kB high:45000kB reserved_highatomic:0KB
active_anon:98060kB inactive_anon:98948kB active_file:60864kB inactive_file:31776kB unevictable:0kB writepending:0kB present:1048576kB managed:1018328kB mlocked:0kB bounce:0kB free_pcp:220kB local_pcp:192kB free_cma:1352kB lowmem_reserve[]: 0 0 0 Normal: 78*4kB (UECI) 1772*8kB (UMECI) 1335*16kB (UMECI) 360*32kB (UMECI) 65*64kB (UMCI) 36*128kB (UMECI) 16*256kB (UMCI) 6*512kB (EI) 8*1024kB (UEI) 4*2048kB (MI) 8*4096kB (EI) 8*8192kB (UI) 3*16384kB (EI) 8*32768kB (M) = 489288kB
The root cause of this issue is that since commit a4efc174b382 ("mm/cma.c:
remove redundant cma_mutex lock"), CMA supports concurrent memory allocation. It's possible that the memory range process A trying to alloc has already been isolated by the allocation of process B during memory migration.
The problem here is that the memory range isolated during one allocation by start_isolate_page_range() could be much bigger than the real size we want to alloc due to the range is aligned to MAX_ORDER_NR_PAGES.
Taking an ARMv7 platform with 1G memory as an example, when MAX_ORDER_NR_PAGES is big (e.g. 32M with max_order 14) and CMA memory is relatively small (e.g. 128M), there're only 4 MAX_ORDER slot, then it's very easy that all CMA memory may have already been isolated by other processes when one trying to allocate memory using dma_alloc_coherent(). Since current CMA code will only scan one time of whole available CMA memory, then dma_alloc_coherent() may easy fail due to contention with other processes.
This patch simply falls back to the original method that using cma_mutex to make alloc_contig_range() run sequentially to avoid the issue.
--- mm/cma.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
mm/cma.c +3 -1
@@ -37,6 +37,7 @@struct cma cma_areas[MAX_CMA_AREAS ];unsigned cma_area_count; +static DEFINE_MUTEX (cma_mutex);phys_addr_t cma_get_base (const struct cma *cma) {
@@ -471,9 +472,10 @@ struct page *cma_alloc(struct cma *cma,spin_unlock_irq (&cma->lock); pfn = cma->base_pfn + (bitmap_no << cma->order_per_bit); +mutex_lock (&cma_mutex); ret =alloc_contig_range (pfn, pfn + count,MIGRATE_CMA ,GFP_KERNEL | (no_warn ? __GFP_NOWARN :0 )); - +mutex_unlock (&cma_mutex);if (ret ==0 ) { page =pfn_to_page (pfn);break ;
Greg Kroah-Hartman
maintainerPATCH 724/772 mm/page_alloc: always attempt to allocate at least one page during bulk allocation
In reply to Greg Kroah-HartmanFrom: Mel Gorman <[email protected]>
commit c572e4888ad1be123c1516ec577ad30a700bbec4 upstream.
Peter Pavlisko reported the following problem on kernel bugzilla 216007.
When I try to extract an uncompressed tar archive (2.6 milion files, 760.3 GiB in size) on newly created (empty) XFS file system, after first low tens of gigabytes extracted the process hangs in iowait indefinitely. One CPU core is 100% occupied with iowait, the other CPU core is idle (on 2-core Intel Celeron G1610T).
It was bisected to c9fa563072e1 ("xfs: use alloc_pages_bulk_array() for buffers") but XFS is only the messenger. The problem is that nothing is waking kswapd to reclaim some pages at a time the PCP lists cannot be refilled until some reclaim happens. The bulk allocator checks that there are some pages in the array and the original intent was that a bulk allocator did not necessarily need all the requested pages and it was best to return as quickly as possible.
This was fine for the first user of the API but both NFS and XFS require the requested number of pages be available before making progress. Both could be adjusted to call the page allocator directly if a bulk allocation fails but it puts a burden on users of the API. Adjust the semantics to attempt at least one allocation via __alloc_pages() before returning so kswapd is woken if necessary.
It was reported via bugzilla that the patch addressed the problem and that the tar extraction completed successfully. This may also address bug 215975 but has yet to be confirmed.
--- mm/page_alloc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
mm/page_alloc.c +2 -2
@@ -5305,8 +5305,8 @@ unsigned long __alloc_pages_bulk(gfp_t g page =__rmqueue_pcplist (zone,0 , ac.migratetype, alloc_flags, pcp, pcp_list);if (unlikely (!page)) { -/* Try and get at least one page */ -if (!nr_populated) +/* Try and allocate at least one page */ +if (!nr_account) goto failed_irq;break ; }
Greg Kroah-Hartman
maintainerPATCH 725/772 nodemask.h: fix compilation error with GCC12
In reply to Greg Kroah-HartmanFrom: Christophe de Dinechin <[email protected]>
commit 37462a920392cb86541650a6f4121155f11f1199 upstream.
With gcc version 12.0.1 20220401 (Red Hat 12.0.1-0), building with defconfig results in the following compilation error:
| CC mm/swapfile.o | mm/swapfile.c: In function `setup_swap_info': | mm/swapfile.c:2291:47: error: array subscript -1 is below array bounds | of `struct plist_node[]' [-Werror=array-bounds] | 2291 | p->avail_lists[i].prio = 1; | | ~~~~~~~~~~~~~~^~~ | In file included from mm/swapfile.c:16: | ./include/linux/swap.h:292:27: note: while referencing `avail_lists' | 292 | struct plist_node avail_lists[]; /* | | ^~~~~~~~~~~
This is due to the compiler detecting that the mask in node_states[__state] could theoretically be zero, which would lead to first_node() returning -1 through find_first_bit.
I believe that the warning/error is legitimate. I first tried adding a test to check that the node mask is not emtpy, since a similar test exists in the case where MAX_NUMNODES == 1.
However, adding the if statement causes other warnings to appear in for_each_cpu_node_but, because it introduces a dangling else ambiguity. And unfortunately, GCC is not smart enough to detect that the added test makes the case where (node) == -1 impossible, so it still complains with the same message.
This is why I settled on replacing that with a harmless, but relatively useless (node) >= 0 test. Based on the warning for the dangling else, I also decided to fix the case where MAX_NUMNODES == 1 by moving the condition inside the for loop. It will still only be tested once. This ensures that the meaning of an else following for_each_node_mask or derivatives would not silently have a different meaning depending on the configuration.
--- include/linux/nodemask.h | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-)
include/linux/nodemask.h +6 -7
@@ -375,14 +375,13 @@ static inline void __nodes_fold(nodemask }#if MAX_NUMNODES >1 -#define for_each_node_mask (node, mask) \ - for ((node) = first_node(mask); \ - (node) < MAX_NUMNODES; \ - (node) = next_node((node), (mask))) +#define for_each_node_mask (node, mask) \ + for ((node) = first_node(mask); \ + (node >= 0) && (node) < MAX_NUMNODES; \ + (node) = next_node((node), (mask)))#else /* MAX_NUMNODES == 1 */ -#define for_each_node_mask (node, mask) \ - if (!nodes_empty(mask)) \ - for ((node) = 0; (node) < 1; (node)++) +#define for_each_node_mask (node, mask) \ + for ((node) = 0; (node) < 1 && !nodes_empty(mask); (node)++)#endif /* MAX_NUMNODES */ /*
Greg Kroah-Hartman
maintainerPATCH 726/772 hugetlb: fix huge_pmd_unshare address update
In reply to Greg Kroah-HartmanFrom: Mike Kravetz <[email protected]>
commit 48381273f8734d28ef56a5bdf1966dd8530111bc upstream.
The routine huge_pmd_unshare() is passed a pointer to an address associated with an area which may be unshared. If unshare is successful this address is updated to 'optimize' callers iterating over huge page addresses. For the optimization to work correctly, address should be updated to the last huge page in the unmapped/unshared area. However, in the common case where the passed address is PUD_SIZE aligned, the address is incorrectly updated to the address of the preceding huge page. That wastes CPU cycles as the unmapped/unshared range is scanned twice.
--- mm/hugetlb.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
mm/hugetlb.c +8 -1
@@ -6557,7 +6557,14 @@ int huge_pmd_unshare(struct mm_struct *mpud_clear (pud);put_page (virt_to_page (ptep));mm_dec_nr_pmds (mm); - *addr =ALIGN (*addr,HPAGE_SIZE *PTRS_PER_PTE ) -HPAGE_SIZE ; +/* +* This update of passed address optimizes loops sequentially +* processing addresses in increments of huge page size (PMD_SIZE +* in this case). By clearing the pud, a PUD_SIZE area is unmapped. +* Update address to the 'last page' in the cleared area so that +* calling loop can move to first page past this area. +*/ + *addr |=PUD_SIZE -PMD_SIZE ;return 1 ; }
Greg Kroah-Hartman
maintainerPATCH 727/772 mm/memremap: fix missing call to untrack_pfn() in pagemap_range()
In reply to Greg Kroah-HartmanFrom: Miaohe Lin <[email protected]>
commit a04e1928e2ead144dc2f369768bc0a0f3110af89 upstream.
We forget to call untrack_pfn() to pair with track_pfn_remap() when range is not allowed to hotplug. Fix it by jump err_kasan.
--- mm/memremap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
mm/memremap.c +1 -1
@@ -228,7 +228,7 @@ static int pagemap_range(struct dev_pageif (!mhp_range_allowed (range->start,range_len (range), !is_private)) { error = -EINVAL ; - goto err_pfn_remap; + goto err_kasan; }mem_hotplug_begin ();
Greg Kroah-Hartman
maintainerPATCH 728/772 xtensa/simdisk: fix proc_read_simdisk()
In reply to Greg Kroah-HartmanFrom: Yi Yang <[email protected]>
commit b011946d039d66bbc7102137e98cc67e1356aa87 upstream.
The commit a69755b18774 ("xtensa simdisk: switch to proc_create_data()") split read operation into two parts, first retrieving the path when it's non-null and second retrieving the trailing '\n'. However when the path is non-null the first simple_read_from_buffer updates ppos, and the second simple_read_from_buffer returns 0 if ppos is greater than 1 (i.e. almost always). As a result reading from that proc file is almost always empty.
Fix it by making a temporary copy of the path with the trailing '\n' and using simple_read_from_buffer on that copy.
--- arch/xtensa/platforms/iss/simdisk.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-)
arch/xtensa/platforms/iss/simdisk.c +12 -6
@@ -211,12 +211,18 @@ static ssize_t proc_read_simdisk(structstruct simdisk *dev =pde_data (file_inode (file));const char *s = dev->filename;if (s) { -ssize_t n =simple_read_from_buffer (buf, size, ppos, - s,strlen (s)); -if (n <0 ) -return n; - buf += n; - size -= n; +ssize_t len =strlen (s); +char *temp =kmalloc (len +2 ,GFP_KERNEL ); + +if (!temp) +return -ENOMEM ; + + len =scnprintf (temp, len +2 ,"%s\n" , s); + len =simple_read_from_buffer (buf, size, ppos, + temp, len); + +kfree (temp); +return len; }return simple_read_from_buffer (buf, size, ppos,"\n" ,1 ); }
Greg Kroah-Hartman
maintainerPATCH 729/772 rtl818x: Prevent using not initialized queues
In reply to Greg Kroah-HartmanFrom: Alexander Wetzel <[email protected]>
commit 746285cf81dc19502ab238249d75f5990bd2d231 upstream.
Using not existing queues can panic the kernel with rtl8180/rtl8185 cards. Ignore the skb priority for those cards, they only have one tx queue. Pierre Asselin ([email protected]) reported the kernel crash in the Gentoo forum:
https://forums.gentoo.org/viewtopic-t-1147832-postdays-0-postorder-asc-start-25.html
He also confirmed that this patch fixes the issue. In summary this happened:
After updating wpa_supplicant from 2.9 to 2.10 the kernel crashed with a "divide error: 0000" when connecting to an AP. Control port tx now tries to use IEEE80211_AC_VO for the priority, which wpa_supplicants starts to use in 2.10.
Since only the rtl8187se part of the driver supports QoS, the priority of the skb is set to IEEE80211_AC_BE (2) by mac80211 for rtl8180/rtl8185 cards.
rtl8180 is then unconditionally reading out the priority and finally crashes on drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c line 544 without this patch:
idx = (ring->idx + skb_queue_len(&ring->queue)) % ring->entries
"ring->entries" is zero for rtl8180/rtl8185 cards, tx_ring[2] never got initialized.
--- drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c +6 -2
@@ -460,8 +460,10 @@ static void rtl8180_tx(struct ieee80211_struct rtl8180_priv *priv = dev->priv;struct rtl8180_tx_ring *ring;struct rtl8180_tx_desc *entry; +unsigned int prio =0 ;unsigned long flags; -unsigned int idx, prio, hw_prio; +unsigned int idx, hw_prio; +dma_addr_t mapping;u32 tx_flags;u8 rc_flags;
@@ -470,7 +472,9 @@ static void rtl8180_tx(struct ieee80211_/* do arithmetic and then convert to le16 */ u16 frame_duration =0 ; - prio =skb_get_queue_mapping (skb); +/* rtl8180/rtl8185 only has one useable tx queue */ +if (dev->queues >IEEE80211_AC_BK ) + prio =skb_get_queue_mapping (skb); ring = &priv->tx_ring[prio]; mapping = dma_map_single(&priv->pdev->dev, skb->data, skb->len,
Greg Kroah-Hartman
maintainerPATCH 730/772 ASoC: rt5514: Fix event generation for "DSP Voice Wake Up" control
In reply to Greg Kroah-HartmanFrom: Mark Brown <[email protected]>
commit 4213ff556740bb45e2d9ff0f50d056c4e7dd0921 upstream.
The driver has a custom put function for "DSP Voice Wake Up" which does not generate event notifications on change, instead returning 0. Since we already exit early in the case that there is no change this can be fixed by unconditionally returning 1 at the end of the function.
--- sound/soc/codecs/rt5514.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
sound/soc/codecs/rt5514.c +1 -1
@@ -419,7 +419,7 @@ static int rt5514_dsp_voice_wake_up_put( } } -return 0 ; +return 1 ; }static const struct snd_kcontrol_new rt5514_snd_controls[] = {
Greg Kroah-Hartman
maintainerPATCH 731/772 carl9170: tx: fix an incorrect use of list iterator
In reply to Greg Kroah-HartmanFrom: Xiaomeng Tong <[email protected]>
commit 54a6f29522da3c914da30e50721dedf51046449a upstream.
If the previous list_for_each_entry_continue_rcu() don't exit early (no goto hit inside the loop), the iterator 'cvif' after the loop will be a bogus pointer to an invalid structure object containing the HEAD (&ar->vif_list). As a result, the use of 'cvif' after that will lead to a invalid memory access (i.e., 'cvif->id': the invalid pointer dereference when return back to/after the callsite in the carl9170_update_beacon()).
The original intention should have been to return the valid 'cvif' when found in list, NULL otherwise. So just return NULL when no entry found, to fix this bug.
--- drivers/net/wireless/ath/carl9170/tx.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/net/wireless/ath/carl9170/tx.c +3 -0
@@ -1558,6 +1558,9 @@ static struct carl9170_vif_info *carl917 goto out; } }while (ar->beacon_enabled && i--); + +/* no entry found in list */ +return NULL ; } out:
Greg Kroah-Hartman
maintainerPATCH 732/772 stm: ltdc: fix two incorrect NULL checks on list iterator
In reply to Greg Kroah-HartmanFrom: Xiaomeng Tong <[email protected]>
commit 2e6c86be0e57079d1fb6c7c7e5423db096d0548a upstream.
The two bugs are here:
if (encoder) {
if (bridge && bridge->timings)The list iterator value 'encoder/bridge' will *always* be set and non-NULL by drm_for_each_encoder()/list_for_each_entry(), so it is incorrect to assume that the iterator value will be NULL if the list is empty or no element is found.
To fix the bug, use a new variable '*_iter' as the list iterator, while use the old variable 'encoder/bridge' as a dedicated pointer to point to the found element.
--- drivers/gpu/drm/stm/ltdc.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-)
drivers/gpu/drm/stm/ltdc.c +10 -6
@@ -528,8 +528,8 @@ static void ltdc_crtc_mode_set_nofb(strustruct drm_device *ddev = crtc->dev;struct drm_connector_list_iter iter;struct drm_connector *connector =NULL ; -struct drm_encoder *encoder =NULL ; -struct drm_bridge *bridge =NULL ; +struct drm_encoder *encoder =NULL , *en_iter; +struct drm_bridge *bridge =NULL , *br_iter;struct drm_display_mode *mode = &crtc->state->adjusted_mode;u32 hsync, vsync, accum_hbp, accum_vbp, accum_act_w, accum_act_h;u32 total_width, total_height;
@@ -538,15 +538,19 @@ static void ltdc_crtc_mode_set_nofb(struint ret;/* get encoder from crtc */ -drm_for_each_encoder (encoder, ddev) -if (encoder->crtc == crtc) +drm_for_each_encoder (en_iter, ddev) +if (en_iter->crtc == crtc) { + encoder = en_iter;break ; + }if (encoder) {/* get bridge from encoder */ -list_for_each_entry (bridge, &encoder->bridge_chain, chain_node) -if (bridge->encoder == encoder) +list_for_each_entry (br_iter, &encoder->bridge_chain, chain_node) +if (br_iter->encoder == encoder) { + bridge = br_iter;break ; + }/* Get the connector from encoder */ drm_connector_list_iter_begin (ddev, &iter);
Greg Kroah-Hartman
maintainerPATCH 733/772 bcache: improve multithreaded bch_btree_check()
In reply to Greg Kroah-HartmanFrom: Coly Li <[email protected]>
commit 622536443b6731ec82c563aae7807165adbe9178 upstream.
Commit 8e7102273f59 ("bcache: make bch_btree_check() to be multithreaded") makes bch_btree_check() to be much faster when checking all btree nodes during cache device registration. But it isn't in ideal shap yet, still can be improved.
This patch does the following thing to improve current parallel btree nodes check by multiple threads in bch_btree_check(),
- Add read lock to root node while checking all the btree nodes with multiple threads. Although currently it is not mandatory but it is good to have a read lock in code logic.
- Remove local variable 'char name[32]', and generate kernel thread name string directly when calling kthread_run().
- Allocate local variable "struct btree_check_state check_state" on the stack and avoid unnecessary dynamic memory allocation for it.
- Reduce BCH_BTR_CHKTHREAD_MAX from 64 to 12 which is enough indeed.
- Increase check_state->started to count created kernel thread after it succeeds to create.
- When wait for all checking kernel threads to finish, use wait_event() to replace wait_event_interruptible().
With this change, the code is more clear, and some potential error conditions are avoided.
--- drivers/md/bcache/btree.c | 58 ++++++++++++++++++++-------------------------- drivers/md/bcache/btree.h | 2 - 2 files changed, 27 insertions(+), 33 deletions(-)
drivers/md/bcache/btree.c +26 -32
@@ -2006,8 +2006,7 @@ int bch_btree_check(struct cache_set *c)int i;struct bkey *k =NULL ;struct btree_iter iter; -struct btree_check_state *check_state; -char name[32 ]; +struct btree_check_state check_state;/* check and mark root node keys */ for_each_key_filter (&c->root->keys, k, &iter, bch_ptr_invalid)
@@ -2018,63 +2017,58 @@ int bch_btree_check(struct cache_set *c)if (c->root->level ==0 )return 0 ; - check_state =kzalloc (sizeof (struct btree_check_state ),GFP_KERNEL ); -if (!check_state) -return -ENOMEM ; - - check_state->c = c; - check_state->total_threads =bch_btree_chkthread_nr (); - check_state->key_idx =0 ; -spin_lock_init (&check_state->idx_lock); -atomic_set (&check_state->started,0 ); -atomic_set (&check_state->enough,0 ); -init_waitqueue_head (&check_state->wait); + check_state.c = c; + check_state.total_threads =bch_btree_chkthread_nr (); + check_state.key_idx =0 ; +spin_lock_init (&check_state.idx_lock); +atomic_set (&check_state.started,0 ); +atomic_set (&check_state.enough,0 ); +init_waitqueue_head (&check_state.wait); +rw_lock (0 , c->root, c->root->level);/* * Run multiple threads to check btree nodes in parallel, -* if check_state->enough is non-zero, it means current +* if check_state.enough is non-zero, it means current * running check threads are enough, unncessary to create * more. */ -for (i =0 ; i < check_state->total_threads; i++) { -/* fetch latest check_state->enough earlier */ +for (i =0 ; i < check_state.total_threads; i++) { +/* fetch latest check_state.enough earlier */ smp_mb__before_atomic (); -if (atomic_read (&check_state->enough)) +if (atomic_read (&check_state.enough))break ; - check_state->infos[i].result =0 ; - check_state->infos[i].state = check_state; -snprintf (name,sizeof (name),"bch_btrchk[%u]" , i); -atomic_inc (&check_state->started); + check_state.infos[i].result =0 ; + check_state.infos[i].state = &check_state; - check_state->infos[i].thread = + check_state.infos[i].thread =kthread_run (bch_btree_check_thread, - &check_state->infos[i], - name); -if (IS_ERR (check_state->infos[i].thread)) { + &check_state.infos[i], +"bch_btrchk[%d]" , i); +if (IS_ERR (check_state.infos[i].thread)) {pr_err ("fails to run thread bch_btrchk[%d]\n" , i);for (--i; i >=0 ; i--) -kthread_stop (check_state->infos[i].thread); +kthread_stop (check_state.infos[i].thread); ret = -ENOMEM ; goto out; } +atomic_inc (&check_state.started); }/* * Must wait for all threads to stop. */ -wait_event_interruptible (check_state->wait, -atomic_read (&check_state->started) ==0 ); +wait_event (check_state.wait,atomic_read (&check_state.started) ==0 ); -for (i =0 ; i < check_state->total_threads; i++) { -if (check_state->infos[i].result) { - ret = check_state->infos[i].result; +for (i =0 ; i < check_state.total_threads; i++) { +if (check_state.infos[i].result) { + ret = check_state.infos[i].result; goto out; } } out: -kfree (check_state); +rw_unlock (0 , c->root);return ret; }
drivers/md/bcache/btree.h +1 -1
@@ -226,7 +226,7 @@ struct btree_check_info {int result; }; -#define BCH_BTR_CHKTHREAD_MAX 64 +#define BCH_BTR_CHKTHREAD_MAX 12struct btree_check_state {struct cache_set *c;int total_threads;
Greg Kroah-Hartman
maintainerPATCH 734/772 bcache: improve multithreaded bch_sectors_dirty_init()
In reply to Greg Kroah-HartmanFrom: Coly Li <[email protected]>
commit 4dc34ae1b45fe26e772a44379f936c72623dd407 upstream.
Commit b144e45fc576 ("bcache: make bch_sectors_dirty_init() to be multithreaded") makes bch_sectors_dirty_init() to be much faster when counting dirty sectors by iterating all dirty keys in the btree. But it isn't in ideal shape yet, still can be improved.
This patch does the following changes to improve current parallel dirty keys iteration on the btree,
- Add read lock to root node when multiple threads iterating the btree, to prevent the root node gets split by I/Os from other registered bcache devices.
- Remove local variable "char name[32]" and generate kernel thread name string directly when calling kthread_run().
- Allocate "struct bch_dirty_init_state state" directly on stack and avoid the unnecessary dynamic memory allocation for it.
- Decrease BCH_DIRTY_INIT_THRD_MAX from 64 to 12 which is enough indeed.
- Increase &state->started to count created kernel thread after it succeeds to create.
- When wait for all dirty key counting threads to finish, use wait_event() to replace wait_event_interruptible().
With the above changes, the code is more clear, and some potential error conditions are avoided.
--- drivers/md/bcache/writeback.c | 60 ++++++++++++++++-------------------------- drivers/md/bcache/writeback.h | 2 - 2 files changed, 25 insertions(+), 37 deletions(-)
drivers/md/bcache/writeback.c +24 -36
@@ -945,10 +945,10 @@ void bch_sectors_dirty_init(struct bcachstruct btree_iter iter;struct sectors_dirty_init op;struct cache_set *c = d->c; -struct bch_dirty_init_state *state; -char name[32 ]; +struct bch_dirty_init_state state;/* Just count root keys if no leaf node */ +rw_lock (0 , c->root, c->root->level);if (c->root->level ==0 ) {bch_btree_op_init (&op.op,-1 ); op.inode = d->id;
@@ -958,54 +958,42 @@ void bch_sectors_dirty_init(struct bcachfor_each_key_filter (&c->root->keys, k, &iter, bch_ptr_invalid)sectors_dirty_init_fn (&op.op, c->root, k); +rw_unlock (0 , c->root);return ; } - state =kzalloc (sizeof (struct bch_dirty_init_state ),GFP_KERNEL ); -if (!state) { -pr_warn ("sectors dirty init failed: cannot allocate memory\n" ); -return ; - } + state.c = c; + state.d = d; + state.total_threads =bch_btre_dirty_init_thread_nr (); + state.key_idx =0 ; +spin_lock_init (&state.idx_lock); +atomic_set (&state.started,0 ); +atomic_set (&state.enough,0 ); +init_waitqueue_head (&state.wait); - state->c = c; - state->d = d; - state->total_threads =bch_btre_dirty_init_thread_nr (); - state->key_idx =0 ; -spin_lock_init (&state->idx_lock); -atomic_set (&state->started,0 ); -atomic_set (&state->enough,0 ); -init_waitqueue_head (&state->wait); - -for (i =0 ; i < state->total_threads; i++) { -/* Fetch latest state->enough earlier */ +for (i =0 ; i < state.total_threads; i++) { +/* Fetch latest state.enough earlier */ smp_mb__before_atomic (); -if (atomic_read (&state->enough)) +if (atomic_read (&state.enough))break ; - state->infos[i].state = state; -atomic_inc (&state->started); -snprintf (name,sizeof (name),"bch_dirty_init[%d]" , i); - - state->infos[i].thread = -kthread_run (bch_dirty_init_thread, - &state->infos[i], - name); -if (IS_ERR (state->infos[i].thread)) { + state.infos[i].state = &state; + state.infos[i].thread = +kthread_run (bch_dirty_init_thread, &state.infos[i], +"bch_dirtcnt[%d]" , i); +if (IS_ERR (state.infos[i].thread)) {pr_err ("fails to run thread bch_dirty_init[%d]\n" , i);for (--i; i >=0 ; i--) -kthread_stop (state->infos[i].thread); +kthread_stop (state.infos[i].thread); goto out; } +atomic_inc (&state.started); } -/* -* Must wait for all threads to stop. -*/ -wait_event_interruptible (state->wait, -atomic_read (&state->started) ==0 ); - out: -kfree (state); +/* Must wait for all threads to stop. */ +wait_event (state.wait,atomic_read (&state.started) ==0 ); +rw_unlock (0 , c->root); }void bch_cached_dev_writeback_init (struct cached_dev *dc)
drivers/md/bcache/writeback.h +1 -1
@@ -20,7 +20,7 @@#define BCH_WRITEBACK_FRAGMENT_THRESHOLD_MID 57#define BCH_WRITEBACK_FRAGMENT_THRESHOLD_HIGH 64 -#define BCH_DIRTY_INIT_THRD_MAX 64 +#define BCH_DIRTY_INIT_THRD_MAX 12/* * 14 (16384ths) is chosen here as something that each backing device * should be a reasonable fraction of the share, and not to blow up
Greg Kroah-Hartman
maintainerPATCH 735/772 bcache: remove incremental dirty sector counting for bch_sectors_dirty_init()
In reply to Greg Kroah-HartmanFrom: Coly Li <[email protected]>
commit 80db4e4707e78cb22287da7d058d7274bd4cb370 upstream.
After making bch_sectors_dirty_init() being multithreaded, the existing incremental dirty sector counting in bch_root_node_dirty_init() doesn't release btree occupation after iterating 500000 (INIT_KEYS_EACH_TIME) bkeys. Because a read lock is added on btree root node to prevent the btree to be split during the dirty sectors counting, other I/O requester has no chance to gain the write lock even restart bcache_btree().
That is to say, the incremental dirty sectors counting is incompatible to the multhreaded bch_sectors_dirty_init(). We have to choose one and drop another one.
In my testing, with 512 bytes random writes, I generate 1.2T dirty data and a btree with 400K nodes. With single thread and incremental dirty sectors counting, it takes 30+ minites to register the backing device. And with multithreaded dirty sectors counting, the backing device registration can be accomplished within 2 minutes.
The 30+ minutes V.S. 2- minutes difference makes me decide to keep multithreaded bch_sectors_dirty_init() and drop the incremental dirty sectors counting. This is what this patch does.
But INIT_KEYS_EACH_TIME is kept, in sectors_dirty_init_fn() the CPU will be released by cond_resched() after every INIT_KEYS_EACH_TIME keys iterated. This is to avoid the watchdog reports a bogus soft lockup warning.
--- drivers/md/bcache/writeback.c | 39 ++++++++++++--------------------------- 1 file changed, 12 insertions(+), 27 deletions(-)
drivers/md/bcache/writeback.c +12 -27
@@ -802,13 +802,11 @@ static int bch_writeback_thread(void *ar/* Init */ #define INIT_KEYS_EACH_TIME 500000 -#define INIT_KEYS_SLEEP_MS 100struct sectors_dirty_init {struct btree_op op;unsigned int inode;size_t count; -struct bkey start; }; static int sectors_dirty_init_fn(struct btree_op *_op, struct btree *b,
@@ -824,11 +822,8 @@ static int sectors_dirty_init_fn(struct KEY_START(k), KEY_SIZE(k)); op->count++; -if (atomic_read (&b->c->search_inflight) && - !(op->count %INIT_KEYS_EACH_TIME )) { -bkey_copy_key (&op->start, k); -return -EAGAIN ; - } +if (!(op->count %INIT_KEYS_EACH_TIME )) +cond_resched ();return MAP_CONTINUE ; }
@@ -843,24 +838,16 @@ static int bch_root_node_dirty_init(strubch_btree_op_init (&op.op,-1 ); op.inode = d->id; op.count =0 ; - op.start =KEY (op.inode,0 ,0 ); -do { - ret =bcache_btree (map_keys_recurse, - k, - c->root, - &op.op, - &op.start, - sectors_dirty_init_fn, -0 ); -if (ret == -EAGAIN ) -schedule_timeout_interruptible ( -msecs_to_jiffies (INIT_KEYS_SLEEP_MS )); -else if (ret <0 ) { -pr_warn ("sectors dirty init failed, ret=%d!\n" , ret); -break ; - } - }while (ret == -EAGAIN ); + ret =bcache_btree (map_keys_recurse, + k, + c->root, + &op.op, + &KEY (op.inode,0 ,0 ), + sectors_dirty_init_fn, +0 ); +if (ret <0 ) +pr_warn ("sectors dirty init failed, ret=%d!\n" , ret);return ret; }
@@ -904,7 +891,6 @@ static int bch_dirty_init_thread(void *a goto out; } skip_nr--; -cond_resched (); }if (p) {
@@ -914,7 +900,6 @@ static int bch_dirty_init_thread(void *a p =NULL ; prev_idx = cur_idx; -cond_resched (); } out:
@@ -953,11 +938,11 @@ void bch_sectors_dirty_init(struct bcachbch_btree_op_init (&op.op,-1 ); op.inode = d->id; op.count =0 ; - op.start =KEY (op.inode,0 ,0 );for_each_key_filter (&c->root->keys, k, &iter, bch_ptr_invalid)sectors_dirty_init_fn (&op.op, c->root, k); +rw_unlock (0 , c->root);return ; }
Greg Kroah-Hartman
maintainerPATCH 736/772 bcache: avoid journal no-space deadlock by reserving 1 journal bucket
In reply to Greg Kroah-HartmanFrom: Coly Li <[email protected]>
commit 32feee36c30ea06e38ccb8ae6e5c44c6eec790a6 upstream.
The journal no-space deadlock was reported time to time. Such deadlock can happen in the following situation.
When all journal buckets are fully filled by active jset with heavy write I/O load, the cache set registration (after a reboot) will load all active jsets and inserting them into the btree again (which is called journal replay). If a journaled bkey is inserted into a btree node and results btree node split, new journal request might be triggered. For example, the btree grows one more level after the node split, then the root node record in cache device super block will be upgrade by bch_journal_meta() from bch_btree_set_root(). But there is no space in journal buckets, the journal replay has to wait for new journal bucket to be reclaimed after at least one journal bucket replayed. This is one example that how the journal no-space deadlock happens.
The solution to avoid the deadlock is to reserve 1 journal bucket in run time, and only permit the reserved journal bucket to be used during cache set registration procedure for things like journal replay. Then the journal space will never be fully filled, there is no chance for journal no-space deadlock to happen anymore.
This patch adds a new member "bool do_reserve" in struct journal, it is inititalized to 0 (false) when struct journal is allocated, and set to 1 (true) by bch_journal_space_reserve() when all initialization done in run_cache_set(). In the run time when journal_reclaim() tries to allocate a new journal bucket, free_journal_buckets() is called to check whether there are enough free journal buckets to use. If there is only 1 free journal bucket and journal->do_reserve is 1 (true), the last bucket is reserved and free_journal_buckets() will return 0 to indicate no free journal bucket. Then journal_reclaim() will give up, and try next time to see whetheer there is free journal bucket to allocate. By this method, there is always 1 jouranl bucket reserved in run time.
During the cache set registration, journal->do_reserve is 0 (false), so the reserved journal bucket can be used to avoid the no-space deadlock.
--- drivers/md/bcache/journal.c | 31 ++++++++++++++++++++++++++----- drivers/md/bcache/journal.h | 2 ++ drivers/md/bcache/super.c | 1 + 3 files changed, 29 insertions(+), 5 deletions(-)
drivers/md/bcache/journal.c +26 -5
@@ -407,6 +407,11 @@ err:return ret; } +void bch_journal_space_reserve (struct journal *j) +{ + j->do_reserve = true; +} +/* Journalling */ static void btree_flush_write (struct cache_set *c)
@@ -625,12 +630,30 @@ static void do_journal_discard(struct ca } } +static unsigned int free_journal_buckets (struct cache_set *c) +{ +struct journal *j = &c->journal; +struct cache *ca = c->cache; +struct journal_device *ja = &c->cache->journal; +unsigned int n; + +/* In case njournal_buckets is not power of 2 */ +if (ja->cur_idx >= ja->discard_idx) + n = ca->sb.njournal_buckets + ja->discard_idx - ja->cur_idx; +else + n = ja->discard_idx - ja->cur_idx; + +if (n > (1 + j->do_reserve)) +return n - (1 + j->do_reserve); + +return 0 ; +} +static void journal_reclaim (struct cache_set *c) {struct bkey *k = &c->journal.key;struct cache *ca = c->cache;uint64_t last_seq; -unsigned int next;struct journal_device *ja = &ca->journal;atomic_t p__maybe_unused ;
@@ -653,12 +676,10 @@ static void journal_reclaim(struct cacheif (c->journal.blocks_free) goto out; - next = (ja->cur_idx +1 ) % ca->sb.njournal_buckets; -/* No space available on this device */ -if (next == ja->discard_idx) +if (!free_journal_buckets (c)) goto out; - ja->cur_idx = next; + ja->cur_idx = (ja->cur_idx +1 ) % ca->sb.njournal_buckets; k->ptr[0 ] =MAKE_PTR (0 ,bucket_to_sector (c, ca->sb.d[ja->cur_idx]), ca->sb.nr_this_dev);
drivers/md/bcache/journal.h +2 -0
@@ -105,6 +105,7 @@ struct journal {spinlock_t lock;spinlock_t flush_write_lock;bool btree_flushing; +bool do_reserve;/* used when waiting because the journal was full */ struct closure_waitlist wait;struct closure io;
@@ -182,5 +183,6 @@ int bch_journal_replay(struct cache_setvoid bch_journal_free (struct cache_set *c);int bch_journal_alloc (struct cache_set *c); +void bch_journal_space_reserve (struct journal *j);#endif /* _BCACHE_JOURNAL_H */
drivers/md/bcache/super.c +1 -0
@@ -2131,6 +2131,7 @@ static int run_cache_set(struct cache_seflash_devs_run (c); +bch_journal_space_reserve (&c->journal);set_bit (CACHE_SET_RUNNING , &c->flags);return 0 ; err:
Greg Kroah-Hartman
maintainerPATCH 737/772 serial: pch: dont overwrite xmit->buf[0] by x_char
In reply to Greg Kroah-HartmanFrom: Jiri Slaby <[email protected]>
commit d9f3af4fbb1d955bbaf872d9e76502f6e3e803cb upstream.
When x_char is to be sent, the TX path overwrites whatever is in the circular buffer at offset 0 with x_char and sends it using pch_uart_hal_write(). I don't understand how this was supposed to work if xmit->buf[0] already contained some character. It must have been lost.
Remove this whole pop_tx_x() concept and do the work directly in the callers. (Without printing anything using dev_dbg().)
--- drivers/tty/serial/pch_uart.c | 27 +++++++-------------------- 1 file changed, 7 insertions(+), 20 deletions(-)
drivers/tty/serial/pch_uart.c +7 -20
@@ -624,22 +624,6 @@ static int push_rx(struct eg20t_port *prreturn 0 ; } -static int pop_tx_x (struct eg20t_port *priv,unsigned char *buf) -{ -int ret =0 ; -struct uart_port *port = &priv->port; - -if (port->x_char) { -dev_dbg (priv->port.dev,"%s:X character send %02x (%lu)\n" , - __func__, port->x_char, jiffies); - buf[0 ] = port->x_char; - port->x_char =0 ; - ret =1 ; - } - -return ret; -} -static int dma_push_rx (struct eg20t_port *priv,int size) {int room;
@@ -889,9 +873,10 @@ static unsigned int handle_tx(struct eg2 fifo_size =max (priv->fifo_size,1 ); tx_empty =1 ; -if (pop_tx_x (priv, xmit->buf)) { -pch_uart_hal_write (priv, xmit->buf,1 ); +if (port->x_char) { +pch_uart_hal_write (priv, &port->x_char,1 ); port->icount.tx++; + port->x_char =0 ; tx_empty =0 ; fifo_size--; }
@@ -946,9 +931,11 @@ static unsigned int dma_handle_tx(struct } fifo_size =max (priv->fifo_size,1 ); -if (pop_tx_x (priv, xmit->buf)) { -pch_uart_hal_write (priv, xmit->buf,1 ); + +if (port->x_char) { +pch_uart_hal_write (priv, &port->x_char,1 ); port->icount.tx++; + port->x_char =0 ; fifo_size--; }
Greg Kroah-Hartman
maintainerPATCH 738/772 tilcdc: tilcdc_external: fix an incorrect NULL check on list iterator
In reply to Greg Kroah-HartmanFrom: Xiaomeng Tong <[email protected]>
commit 8b917cbe38e9b0d002492477a9fc2bfee2412ce4 upstream.
The bug is here:
if (!encoder) {The list iterator value 'encoder' will *always* be set and non-NULL by list_for_each_entry(), so it is incorrect to assume that the iterator value will be NULL if the list is empty or no element is found.
To fix the bug, use a new variable 'iter' as the list iterator, while use the original variable 'encoder' as a dedicated pointer to point to the found element.
--- drivers/gpu/drm/tilcdc/tilcdc_external.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
drivers/gpu/drm/tilcdc/tilcdc_external.c +5 -3
@@ -60,11 +60,13 @@ struct drm_connector *tilcdc_encoder_finint tilcdc_add_component_encoder (struct drm_device *ddev) {struct tilcdc_drm_private *priv = ddev->dev_private; -struct drm_encoder *encoder; +struct drm_encoder *encoder =NULL , *iter; -list_for_each_entry (encoder, &ddev->mode_config.encoder_list, head) -if (encoder->possible_crtcs & (1 << priv->crtc->index)) +list_for_each_entry (iter, &ddev->mode_config.encoder_list, head) +if (iter->possible_crtcs & (1 << priv->crtc->index)) { + encoder = iter;break ; + }if (!encoder) {dev_err (ddev->dev,"%s: No suitable encoder found\n" , __func__);
Greg Kroah-Hartman
maintainerPATCH 739/772 gma500: fix an incorrect NULL check on list iterator
In reply to Greg Kroah-HartmanFrom: Xiaomeng Tong <[email protected]>
commit bdef417d84536715145f6dc9cc3275c46f26295a upstream.
The bug is here:
return crtc;
The list iterator value 'crtc' will *always* be set and non-NULL by list_for_each_entry(), so it is incorrect to assume that the iterator value will be NULL if the list is empty or no element is found.
To fix the bug, return 'crtc' when found, otherwise return NULL.
--- drivers/gpu/drm/gma500/psb_intel_display.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/gpu/drm/gma500/psb_intel_display.c +4 -3
@@ -535,14 +535,15 @@ void psb_intel_crtc_init(struct drm_devistruct drm_crtc *psb_intel_get_crtc_from_pipe (struct drm_device *dev,int pipe) { -struct drm_crtc *crtc =NULL ; +struct drm_crtc *crtc;list_for_each_entry (crtc, &dev->mode_config.crtc_list, head) {struct gma_crtc *gma_crtc =to_gma_crtc (crtc); +if (gma_crtc->pipe == pipe) -break ; +return crtc; } -return crtc; +return NULL ; }int gma_connector_clones (struct drm_device *dev,int type_mask)
Greg Kroah-Hartman
maintainerPATCH 740/772 arm64: dts: qcom: ipq8074: fix the sleep clock frequency
In reply to Greg Kroah-HartmanFrom: Kathiravan T <[email protected]>
commit f607dd767f5d6800ffbdce5b99ba81763b023781 upstream.
Sleep clock frequency should be 32768Hz. Lets fix it.
--- arch/arm64/boot/dts/qcom/ipq8074.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm64/boot/dts/qcom/ipq8074.dtsi +1 -1
@@ -13,7 +13,7 @@ clocks { sleep_clk: sleep_clk { compatible = "fixed-clock"; - clock-frequency = <32000>; + clock-frequency = <32768>; #clock-cells = <0>; };
Greg Kroah-Hartman
maintainerPATCH 741/772 arm64: tegra: Add missing DFLL reset on Tegra210
In reply to Greg Kroah-HartmanFrom: Diogo Ivo <[email protected]>
commit 0017f2c856e21bb900be88469e15dac4f41f4065 upstream.
Commit 4782c0a5dd88 ("clk: tegra: Don't deassert reset on enabling clocks") removed deassertion of reset lines when enabling peripheral clocks. This breaks the initialization of the DFLL driver which relied on this behaviour.
In order to be able to fix this, add the corresponding reset to the DT. Tested on Google Pixel C.
--- arch/arm64/boot/dts/nvidia/tegra210.dtsi | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
arch/arm64/boot/dts/nvidia/tegra210.dtsi +3 -2
@@ -1366,8 +1366,9 @@ <&tegra_car TEGRA210_CLK_DFLL_REF>, <&tegra_car TEGRA210_CLK_I2C5>; clock-names = "soc", "ref", "i2c"; - resets = <&tegra_car TEGRA210_RST_DFLL_DVCO>; - reset-names = "dvco"; + resets = <&tegra_car TEGRA210_RST_DFLL_DVCO>, + <&tegra_car 155>; + reset-names = "dvco", "dfll"; #clock-cells = <0>; clock-output-names = "dfllCPU_out"; status = "disabled";
Greg Kroah-Hartman
maintainerPATCH 742/772 clk: tegra: Add missing reset deassertion
In reply to Greg Kroah-HartmanFrom: Diogo Ivo <[email protected]>
commit 23a43cc437e747473d5f8f98b4fe189fb5c433b7 upstream.
Commit 4782c0a5dd88 ("clk: tegra: Don't deassert reset on enabling clocks") removed deassertion of reset lines when enabling peripheral clocks. This breaks the initialization of the DFLL driver which relied on this behaviour.
Fix this problem by adding explicit deassert/assert requests to the driver. Tested on Google Pixel C.
--- drivers/clk/tegra/clk-dfll.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)
drivers/clk/tegra/clk-dfll.c +12 -0
@@ -271,6 +271,7 @@ struct tegra_dfll {struct clk *ref_clk;struct clk *i2c_clk;struct clk *dfll_clk; +struct reset_control *dfll_rst;struct reset_control *dvco_rst;unsigned long ref_rate;unsigned long i2c_clk_rate;
@@ -1464,6 +1465,7 @@ static int dfll_init(struct tegra_dfll *return -EINVAL ; } +reset_control_deassert (td->dfll_rst);reset_control_deassert (td->dvco_rst); ret =clk_prepare (td->ref_clk);
@@ -1509,6 +1511,7 @@ di_err1:clk_unprepare (td->ref_clk);reset_control_assert (td->dvco_rst); +reset_control_assert (td->dfll_rst);return ret; }
@@ -1530,6 +1533,7 @@ int tegra_dfll_suspend(struct device *de }reset_control_assert (td->dvco_rst); +reset_control_assert (td->dfll_rst);return 0 ; }
@@ -1548,6 +1552,7 @@ int tegra_dfll_resume(struct device *dev {struct tegra_dfll *td =dev_get_drvdata (dev); +reset_control_deassert (td->dfll_rst);reset_control_deassert (td->dvco_rst);pm_runtime_get_sync (td->dev);
@@ -1951,6 +1956,12 @@ int tegra_dfll_register(struct platform_ td->soc = soc; + td->dfll_rst =devm_reset_control_get_optional (td->dev,"dfll" ); +if (IS_ERR (td->dfll_rst)) { +dev_err (td->dev,"couldn't get dfll reset\n" ); +return PTR_ERR (td->dfll_rst); + } + td->dvco_rst =devm_reset_control_get (td->dev,"dvco" );if (IS_ERR (td->dvco_rst)) {dev_err (td->dev,"couldn't get dvco reset\n" );
@@ -2087,6 +2098,7 @@ struct tegra_dfll_soc_data *tegra_dfll_uclk_unprepare (td->i2c_clk);reset_control_assert (td->dvco_rst); +reset_control_assert (td->dfll_rst);return td->soc; }
Greg Kroah-Hartman
maintainerPATCH 743/772 phy: qcom-qmp: fix struct clk leak on probe errors
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit f0a4bc38a12f5a0cc5ad68670d9480e91e6a94df upstream.
Make sure to release the pipe clock reference in case of a late probe error (e.g. probe deferral).
--- drivers/phy/qualcomm/phy-qcom-qmp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/phy/qualcomm/phy-qcom-qmp.c +1 -1
@@ -5890,7 +5890,7 @@ int qcom_qmp_phy_create(struct device *d* all phys that don't need this. */ snprintf (prop_name,sizeof (prop_name),"pipe%d" , id); - qphy->pipe_clk =of_clk_get_by_name (np, prop_name); + qphy->pipe_clk =devm_get_clk_from_child (dev, np, prop_name);if (IS_ERR (qphy->pipe_clk)) {if (cfg->type ==PHY_TYPE_PCIE || cfg->type ==PHY_TYPE_USB3 ) {
Greg Kroah-Hartman
maintainerPATCH 744/772 ARM: dts: s5pv210: Remove spi-cs-high on panel in Aries
In reply to Greg Kroah-HartmanFrom: Jonathan Bakker <[email protected]>
commit 096f58507374e1293a9e9cff8a1ccd5f37780a20 upstream.
Since commit 766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors"), the panel has been blank due to an inverted CS GPIO. In order to correct this, drop the spi-cs-high from the panel SPI device.
--- arch/arm/boot/dts/s5pv210-aries.dtsi | 1 - 1 file changed, 1 deletion(-)
arch/arm/boot/dts/s5pv210-aries.dtsi +0 -1
@@ -564,7 +564,6 @@ reset-gpios = <&mp05 5 GPIO_ACTIVE_LOW>; vdd3-supply = <&ldo7_reg>; vci-supply = <&ldo17_reg>; - spi-cs-high; spi-max-frequency = <1200000>; pinctrl-names = "default";
Greg Kroah-Hartman
maintainerPATCH 745/772 ARM: pxa: maybe fix gpio lookup tables
In reply to Greg Kroah-HartmanFrom: Arnd Bergmann <[email protected]>
commit 2672a4bff6c03a20d5ae460a091f67ee782c3eff upstream.
Quoted 1 line
From inspection I found a couple of GPIO lookups that are
listed with device "gpio-pxa", but actually have a number from a different gpio controller.
Try to rectify that here, with a guess of what the actual device name is.
--- arch/arm/mach-pxa/cm-x300.c | 8 ++++---- arch/arm/mach-pxa/magician.c | 2 +- arch/arm/mach-pxa/tosa.c | 4 ++-- 3 files changed, 7 insertions(+), 7 deletions(-)
arch/arm/mach-pxa/cm-x300.c +4 -4
@@ -354,13 +354,13 @@ static struct platform_device cm_x300_spstatic struct gpiod_lookup_table cm_x300_spi_gpiod_table = { .dev_id ="spi_gpio" , .table = { -GPIO_LOOKUP ("gpio-pxa" ,GPIO_LCD_SCL , +GPIO_LOOKUP ("pca9555.1" ,GPIO_LCD_SCL -GPIO_LCD_BASE ,"sck" ,GPIO_ACTIVE_HIGH ), -GPIO_LOOKUP ("gpio-pxa" ,GPIO_LCD_DIN , +GPIO_LOOKUP ("pca9555.1" ,GPIO_LCD_DIN -GPIO_LCD_BASE ,"mosi" ,GPIO_ACTIVE_HIGH ), -GPIO_LOOKUP ("gpio-pxa" ,GPIO_LCD_DOUT , +GPIO_LOOKUP ("pca9555.1" ,GPIO_LCD_DOUT -GPIO_LCD_BASE ,"miso" ,GPIO_ACTIVE_HIGH ), -GPIO_LOOKUP ("gpio-pxa" ,GPIO_LCD_CS , +GPIO_LOOKUP ("pca9555.1" ,GPIO_LCD_CS -GPIO_LCD_BASE ,"cs" ,GPIO_ACTIVE_HIGH ), { }, },
arch/arm/mach-pxa/magician.c +1 -1
@@ -681,7 +681,7 @@ static struct platform_device bq24022 =static struct gpiod_lookup_table bq24022_gpiod_table = { .dev_id ="gpio-regulator" , .table = { -GPIO_LOOKUP ("gpio-pxa" ,EGPIO_MAGICIAN_BQ24022_ISET2 , +GPIO_LOOKUP ("htc-egpio-0" ,EGPIO_MAGICIAN_BQ24022_ISET2 -MAGICIAN_EGPIO_BASE ,NULL ,GPIO_ACTIVE_HIGH ),GPIO_LOOKUP ("gpio-pxa" , GPIO30_MAGICIAN_BQ24022_nCHARGE_EN,"enable" ,GPIO_ACTIVE_LOW ),
arch/arm/mach-pxa/tosa.c +2 -2
@@ -296,9 +296,9 @@ static struct gpiod_lookup_table tosa_mc .table = {GPIO_LOOKUP ("gpio-pxa" , TOSA_GPIO_nSD_DETECT,"cd" ,GPIO_ACTIVE_LOW ), -GPIO_LOOKUP ("gpio-pxa" ,TOSA_GPIO_SD_WP , +GPIO_LOOKUP ("sharp-scoop.0" ,TOSA_GPIO_SD_WP -TOSA_SCOOP_GPIO_BASE ,"wp" ,GPIO_ACTIVE_LOW ), -GPIO_LOOKUP ("gpio-pxa" ,TOSA_GPIO_PWR_ON , +GPIO_LOOKUP ("sharp-scoop.0" ,TOSA_GPIO_PWR_ON -TOSA_SCOOP_GPIO_BASE , "power", GPIO_ACTIVE_HIGH), { }, },
Greg Kroah-Hartman
maintainerPATCH 746/772 ceph: fix decoding of client session messages flags
In reply to Greg Kroah-HartmanFrom: Luís Henriques <[email protected]>
commit ea16567f11018e2f58e72b667b0c803ff92b8153 upstream.
The cephfs kernel client started to show the message:
ceph: mds0 session blocklisted
when mounting a filesystem. This is due to the fact that the session messages are being incorrectly decoded: the skip needs to take into account the 'len'.
While there, fixed some whitespaces too.
--- fs/ceph/mds_client.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-)
fs/ceph/mds_client.c +9 -5
@@ -3378,13 +3378,17 @@ static void handle_session(struct ceph_m }if (msg_version >=5 ) { -u32 flags; -/* version >= 4, struct_v, struct_cv, len, metric_spec */ -ceph_decode_skip_n (&p, end,2 +sizeof (u32) *2 , bad); +u32 flags, len; + +/* version >= 4 */ +ceph_decode_skip_16 (&p, end, bad);/* struct_v, struct_cv */ +ceph_decode_32_safe (&p, end, len, bad);/* len */ +ceph_decode_skip_n (&p, end, len, bad);/* metric_spec */ +/* version >= 5, flags */ -ceph_decode_32_safe (&p, end, flags, bad); +ceph_decode_32_safe (&p, end, flags, bad);if (flags &CEPH_SESSION_BLOCKLISTED ) { -pr_warn ("mds%d session blocklisted\n" , session->s_mds); +pr_warn ("mds%d session blocklisted\n" , session->s_mds); blocklisted = true; } }
Greg Kroah-Hartman
maintainerPATCH 747/772 SMB3: EBADF/EIO errors in rename/open caused by race condition in smb2_compound_op
In reply to Greg Kroah-HartmanFrom: Steve French <[email protected]>
commit 0a55cf74ffb5d004b93647e4389096880ce37d6b upstream.
There is a race condition in smb2_compound_op:
after_close:
num_rqst++;
if (cfile) {
cifsFileInfo_put(cfile); // sends SMB2_CLOSE to the server
cfile = NULL;This is triggered by smb2_query_path_info operation that happens during revalidate_dentry. In smb2_query_path_info, get_readable_path is called to load the cfile, increasing the reference counter. If in the meantime, this reference becomes the very last, this call to cifsFileInfo_put(cfile) will trigger a SMB2_CLOSE request sent to the server just before sending this compound request – and so then the compound request fails either with EBADF/EIO depending on the timing at the server, because the handle is already closed.
In the first scenario, the race seems to be happening between smb2_query_path_info triggered by the rename operation, and between “cleanup” of asynchronous writes – while fsync(fd) likely waits for the asynchronous writes to complete, releasing the writeback structures can happen after the close(fd) call. So the EBADF/EIO errors will pop up if the timing is such that:
1) There are still outstanding references after close(fd) in the writeback structures
2) smb2_query_path_info successfully fetches the cfile, increasing the refcounter by 1
3) All writeback structures release the same cfile, reducing refcounter to 1
4) smb2_compound_op is called with that cfile
In the second scenario, the race seems to be similar – here open triggers the smb2_query_path_info operation, and if all other threads in the meantime decrease the refcounter to 1 similarly to the first scenario, again SMB2_CLOSE will be sent to the server just before issuing the compound request. This case is harder to reproduce.
See https://bugzilla.samba.org/show_bug.cgi?id=15051
--- fs/cifs/smb2inode.c | 2 -- 1 file changed, 2 deletions(-)
fs/cifs/smb2inode.c +0 -2
@@ -362,8 +362,6 @@ smb2_compound_op(const unsigned int xid, num_rqst++;if (cfile) { -cifsFileInfo_put (cfile); - cfile =NULL ; rc = compound_send_recv(xid, ses, server, flags, num_rqst - 2, &rqst[1], &resp_buftype[1],
Greg Kroah-Hartman
maintainerPATCH 748/772 docs/conf.py: Cope with removal of language=None in Sphinx 5.0.0
In reply to Greg Kroah-HartmanFrom: Akira Yokosawa <[email protected]>
commit 627f01eab93d8671d4e4afee9b148f9998d20e7c upstream.
One of the changes in Sphinx 5.0.0 [1] says [sic]:
5.0.0 final
- #10474: language does not accept None as it value. The default value of language becomes to 'en' now.
[1]: https://www.sphinx-doc.org/en/master/changes.html#release-5-0-0-released-may-30-2022
It results in a new warning from Sphinx 5.0.0 [sic]:
WARNING: Invalid configuration value found: 'language = None'. Update your configuration to a valid langauge code. Falling back to 'en' (English).
Silence the warning by using 'en'.
It works with all the Sphinx versions required for building kernel documentation (1.7.9 or later).
--- Documentation/conf.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Documentation/conf.py +1 -1
@@ -161,7 +161,7 @@ finally: # # This is also used if you do content translation via gettext catalogs. # Usually you set "language" from the command line for these cases. -language = None +language = 'en' # There are two options for replacing |today|: either, you set today to some # non-false value, then it is used:
Greg Kroah-Hartman
maintainerPATCH 749/772 dt-bindings: gpio: altera: correct interrupt-cells
In reply to Greg Kroah-HartmanFrom: Dinh Nguyen <[email protected]>
commit 3a21c3ac93aff7b4522b152399df8f6a041df56d upstream.
update documentation to correctly state the interrupt-cells to be 2.
--- Documentation/devicetree/bindings/gpio/gpio-altera.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
Documentation/devicetree/bindings/gpio/gpio-altera.txt +3 -2
@@ -9,8 +9,9 @@ Required properties: - The second cell is reserved and is currently unused. - gpio-controller : Marks the device node as a GPIO controller. - interrupt-controller: Mark the device node as an interrupt controller -- #interrupt-cells : Should be 1. The interrupt type is fixed in the hardware. +- #interrupt-cells : Should be 2. The interrupt type is fixed in the hardware. - The first cell is the GPIO offset number within the GPIO controller. + - The second cell is the interrupt trigger type and level flags. - interrupts: Specify the interrupt. - altr,interrupt-type: Specifies the interrupt trigger type the GPIO hardware is synthesized. This field is required if the Altera GPIO controller
@@ -38,6 +39,6 @@ gpio_altr: gpio@ff200000 { altr,interrupt-type = <IRQ_TYPE_EDGE_RISING>; #gpio-cells = <2>; gpio-controller; - #interrupt-cells = <1>; + #interrupt-cells = <2>; interrupt-controller; };
Greg Kroah-Hartman
maintainerPATCH 750/772 vdpasim: allow to enable a vq repeatedly
In reply to Greg Kroah-HartmanFrom: Eugenio Pérez <[email protected]>
commit 242436973831aa97e8ce19533c6c912ea8def31b upstream.
Code must be resilient to enable a queue many times.
At the moment the queue is resetting so it's definitely not the expected behavior.
v2: set vq->ready = 0 at disable.
Message-Id: <[email protected]>
--- drivers/vdpa/vdpa_sim/vdpa_sim.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/vdpa/vdpa_sim/vdpa_sim.c +4 -1
@@ -353,11 +353,14 @@ static void vdpasim_set_vq_ready(struct {struct vdpasim *vdpasim =vdpa_to_sim (vdpa);struct vdpasim_virtqueue *vq = &vdpasim->vqs[idx]; +bool old_ready;spin_lock (&vdpasim->lock); + old_ready = vq->ready; vq->ready = ready; -if (vq->ready) +if (vq->ready && !old_ready) {vdpasim_queue_ready (vdpasim, idx); + }spin_unlock (&vdpasim->lock); }
Greg Kroah-Hartman
maintainerPATCH 751/772 blk-iolatency: Fix inflight count imbalances and IO hangs on offline
In reply to Greg Kroah-HartmanFrom: Tejun Heo <[email protected]>
commit 8a177a36da6c54c98b8685d4f914cb3637d53c0d upstream.
iolatency needs to track the number of inflight IOs per cgroup. As this tracking can be expensive, it is disabled when no cgroup has iolatency configured for the device. To ensure that the inflight counters stay balanced, iolatency_set_limit() freezes the request_queue while manipulating the enabled counter, which ensures that no IO is in flight and thus all counters are zero.
Unfortunately, iolatency_set_limit() isn't the only place where the enabled counter is manipulated. iolatency_pd_offline() can also dec the counter and trigger disabling. As this disabling happens without freezing the q, this can easily happen while some IOs are in flight and thus leak the counts.
This can be easily demonstrated by turning on iolatency on an one empty cgroup while IOs are in flight in other cgroups and then removing the cgroup. Note that iolatency shouldn't have been enabled elsewhere in the system to ensure that removing the cgroup disables iolatency for the whole device.
The following keeps flipping on and off iolatency on sda:
echo +io > /sys/fs/cgroup/cgroup.subtree_control while true; do
mkdir -p /sys/fs/cgroup/test
echo '8:0 target=100000' > /sys/fs/cgroup/test/io.latency sleep 1
rmdir /sys/fs/cgroup/test
sleep 1
done
and there's concurrent fio generating direct rand reads:
fio --name test --filename=/dev/sda --direct=1 --rw=randread \
--runtime=600 --time_based --iodepth=256 --numjobs=4 --bs=4kwhile monitoring with the following drgn script:
while True:
for css in css_for_each_descendant_pre(prog['blkcg_root'].css.address_of_()):
for pos in hlist_for_each(container_of(css, 'struct blkcg', 'css').blkg_list):
blkg = container_of(pos, 'struct blkcg_gq', 'blkcg_node')
pd = blkg.pd[prog['blkcg_policy_iolatency'].plid]
if pd.value_() == 0:
continue
iolat = container_of(pd, 'struct iolatency_grp', 'pd') inflight = iolat.rq_wait.inflight.counter.value_()
if inflight:
print(f'inflight={inflight} {disk_name(blkg.q.disk).decode("utf-8")} '
f'{cgroup_path(css.cgroup).decode("utf-8")}')
time.sleep(1)
The monitoring output looks like the following:
inflight=1 sda /user.slice
inflight=1 sda /user.slice
...
inflight=14 sda /user.slice
inflight=13 sda /user.slice
inflight=17 sda /user.slice
inflight=15 sda /user.slice
inflight=18 sda /user.slice
inflight=17 sda /user.slice
inflight=20 sda /user.slice
inflight=19 sda /user.slice <- fio stopped, inflight stuck at 19 inflight=19 sda /user.slice
inflight=19 sda /user.slice
If a cgroup with stuck inflight ends up getting throttled, the throttled IOs will never get issued as there's no completion event to wake it up leading to an indefinite hang.
This patch fixes the bug by unifying enable handling into a work item which is automatically kicked off from iolatency_set_min_lat_nsec() which is called from both iolatency_set_limit() and iolatency_pd_offline() paths. Punting to a work item is necessary as iolatency_pd_offline() is called under spinlocks while freezing a request_queue requires a sleepable context.
This also simplifies the code reducing LOC sans the comments and avoids the unnecessary freezes which were happening whenever a cgroup's latency target is newly set or cleared.
--- block/blk-iolatency.c | 122 ++++++++++++++++++++++++++------------------------ 1 file changed, 64 insertions(+), 58 deletions(-)
block/blk-iolatency.c +64 -58
@@ -87,7 +87,17 @@ struct iolatency_grp;struct blk_iolatency {struct rq_qos rqos;struct timer_list timer; -atomic_t enabled; + +/* +* ->enabled is the master enable switch gating the throttling logic and +* inflight tracking. The number of cgroups which have iolat enabled is +* tracked in ->enable_cnt, and ->enable is flipped on/off accordingly +* from ->enable_work with the request_queue frozen. For details, See +* blkiolatency_enable_work_fn(). +*/ +bool enabled; +atomic_t enable_cnt; +struct work_struct enable_work; };static inline struct blk_iolatency *BLKIOLATENCY (struct rq_qos *rqos)
@@ -95,11 +105,6 @@ static inline struct blk_iolatency *BLKI return container_of(rqos, struct blk_iolatency, rqos); } -static inline bool blk_iolatency_enabled (struct blk_iolatency *blkiolat) -{ -return atomic_read (&blkiolat->enabled) >0 ; -} -struct child_latency_info {spinlock_t lock;
@@ -464,7 +469,7 @@ static void blkcg_iolatency_throttle(strstruct blkcg_gq *blkg = bio->bi_blkg;bool issue_as_root =bio_issue_as_root_blkg (bio); -if (!blk_iolatency_enabled (blkiolat)) +if (!blkiolat->enabled)return ;while (blkg && blkg->parent) {
@@ -594,7 +599,6 @@ static void blkcg_iolatency_done_bio(stru64 window_start;u64 now;bool issue_as_root =bio_issue_as_root_blkg (bio); -bool enabled = false;int inflight =0 ; blkg = bio->bi_blkg;
@@ -605,8 +609,7 @@ static void blkcg_iolatency_done_bio(strif (!iolat)return ; - enabled =blk_iolatency_enabled (iolat->blkiolat); -if (!enabled) +if (!iolat->blkiolat->enabled)return ; now =ktime_to_ns (ktime_get ());
@@ -645,6 +648,7 @@ static void blkcg_iolatency_exit(structstruct blk_iolatency *blkiolat =BLKIOLATENCY (rqos);del_timer_sync (&blkiolat->timer); +flush_work (&blkiolat->enable_work);blkcg_deactivate_policy (rqos->q, &blkcg_policy_iolatency);kfree (blkiolat); }
@@ -716,6 +720,44 @@ next:rcu_read_unlock (); } +/** +* blkiolatency_enable_work_fn - Enable or disable iolatency on the device +* @work: enable_work of the blk_iolatency of interest +* +* iolatency needs to keep track of the number of in-flight IOs per cgroup. This +* is relatively expensive as it involves walking up the hierarchy twice for +* every IO. Thus, if iolatency is not enabled in any cgroup for the device, we +* want to disable the in-flight tracking. +* +* We have to make sure that the counting is balanced - we don't want to leak +* the in-flight counts by disabling accounting in the completion path while IOs +* are in flight. This is achieved by ensuring that no IO is in flight by +* freezing the queue while flipping ->enabled. As this requires a sleepable +* context, ->enabled flipping is punted to this work function. +*/ +static void blkiolatency_enable_work_fn (struct work_struct *work) +{ + struct blk_iolatency *blkiolat = container_of(work, struct blk_iolatency, + enable_work); +bool enabled; + +/* +* There can only be one instance of this function running for @blkiolat +* and it's guaranteed to be executed at least once after the latest +* ->enabled_cnt modification. Acting on the latest ->enable_cnt is +* sufficient. +* +* Also, we know @blkiolat is safe to access as ->enable_work is flushed +* in blkcg_iolatency_exit(). +*/ + enabled =atomic_read (&blkiolat->enable_cnt); +if (enabled != blkiolat->enabled) { +blk_mq_freeze_queue (blkiolat->rqos.q); + blkiolat->enabled = enabled; +blk_mq_unfreeze_queue (blkiolat->rqos.q); + } +} +int blk_iolatency_init (struct request_queue *q) {struct blk_iolatency *blkiolat;
@@ -741,17 +783,15 @@ int blk_iolatency_init(struct request_qu }timer_setup (&blkiolat->timer, blkiolatency_timer_fn,0 ); +INIT_WORK (&blkiolat->enable_work, blkiolatency_enable_work_fn);return 0 ; } -/* -* return 1 for enabling iolatency, return -1 for disabling iolatency, otherwise -* return 0. -*/ -static int iolatency_set_min_lat_nsec (struct blkcg_gq *blkg,u64 val) +static void iolatency_set_min_lat_nsec (struct blkcg_gq *blkg,u64 val) {struct iolatency_grp *iolat =blkg_to_lat (blkg); +struct blk_iolatency *blkiolat = iolat->blkiolat;u64 oldval = iolat->min_lat_nsec; iolat->min_lat_nsec = val;
@@ -759,13 +799,15 @@ static int iolatency_set_min_lat_nsec(st iolat->cur_win_nsec =min_t (u64, iolat->cur_win_nsec,BLKIOLATENCY_MAX_WIN_SIZE ); -if (!oldval && val) -return 1 ; +if (!oldval && val) { +if (atomic_inc_return (&blkiolat->enable_cnt) ==1 ) +schedule_work (&blkiolat->enable_work); + }if (oldval && !val) {blkcg_clear_delay (blkg); -return -1 ; +if (atomic_dec_return (&blkiolat->enable_cnt) ==0 ) +schedule_work (&blkiolat->enable_work); } -return 0 ; }static void iolatency_clear_scaling (struct blkcg_gq *blkg)
@@ -797,7 +839,6 @@ static ssize_t iolatency_set_limit(strucu64 lat_val =0 ;u64 oldval;int ret; -int enable =0 ; ret =blkg_conf_prep (blkcg, &blkcg_policy_iolatency, buf, &ctx);if (ret)
@@ -832,41 +873,12 @@ static ssize_t iolatency_set_limit(struc blkg = ctx.blkg; oldval = iolat->min_lat_nsec; - enable =iolatency_set_min_lat_nsec (blkg, lat_val); -if (enable) { -if (!blk_get_queue (blkg->q)) { - ret = -ENODEV ; - goto out; - } - -blkg_get (blkg); - } - -if (oldval != iolat->min_lat_nsec) { +iolatency_set_min_lat_nsec (blkg, lat_val); +if (oldval != iolat->min_lat_nsec)iolatency_clear_scaling (blkg); - } - ret =0 ; out:blkg_conf_finish (&ctx); -if (ret ==0 && enable) { -struct iolatency_grp *tmp =blkg_to_lat (blkg); -struct blk_iolatency *blkiolat = tmp->blkiolat; - -blk_mq_freeze_queue (blkg->q); - -if (enable ==1 ) -atomic_inc (&blkiolat->enabled); -else if (enable ==-1 ) -atomic_dec (&blkiolat->enabled); -else -WARN_ON_ONCE (1 ); - -blk_mq_unfreeze_queue (blkg->q); - -blkg_put (blkg); -blk_put_queue (blkg->q); - }return ret ?: nbytes; }
@@ -1007,14 +1019,8 @@ static void iolatency_pd_offline(struct {struct iolatency_grp *iolat =pd_to_lat (pd);struct blkcg_gq *blkg =lat_to_blkg (iolat); -struct blk_iolatency *blkiolat = iolat->blkiolat; -int ret; - ret =iolatency_set_min_lat_nsec (blkg,0 ); -if (ret ==1 ) -atomic_inc (&blkiolat->enabled); -if (ret ==-1 ) -atomic_dec (&blkiolat->enabled); +iolatency_set_min_lat_nsec (blkg,0 );iolatency_clear_scaling (blkg); }
Greg Kroah-Hartman
maintainerPATCH 752/772 coresight: core: Fix coresight device probe failure issue
In reply to Greg Kroah-HartmanFrom: Mao Jinlong <[email protected]>
commit 8c1d3f79d9ca48e406b78e90e94cf09a8c076bf2 upstream.
It is possibe that probe failure issue happens when the device and its child_device's probe happens at the same time. In coresight_make_links, has_conns_grp is true for parent, but has_conns_grp is false for child device as has_conns_grp is set to true in coresight_create_conns_sysfs_group. The probe of parent device will fail at this condition. Add has_conns_grp check for child device before make the links and make the process from device_register to connection_create be atomic to avoid this probe failure issue.
--- drivers/hwtracing/coresight/coresight-core.c | 33 ++++++++++++++++++--------- 1 file changed, 22 insertions(+), 11 deletions(-)
drivers/hwtracing/coresight/coresight-core.c +22 -11
@@ -1382,7 +1382,7 @@ static int coresight_fixup_device_conns(continue ; conn->child_dev =coresight_find_csdev_by_fwnode (conn->child_fwnode); -if (conn->child_dev) { +if (conn->child_dev && conn->child_dev->has_conns_grp) { ret =coresight_make_links (csdev, conn, conn->child_dev);if (ret)
@@ -1574,6 +1574,7 @@ struct coresight_device *coresight_regisint nr_refcnts =1 ;atomic_t *refcnts =NULL ;struct coresight_device *csdev; +bool registered = false; csdev =kzalloc (sizeof (*csdev),GFP_KERNEL );if (!csdev) {
@@ -1594,7 +1595,8 @@ struct coresight_device *coresight_regis refcnts =kcalloc (nr_refcnts,sizeof (*refcnts),GFP_KERNEL );if (!refcnts) { ret = -ENOMEM ; - goto err_free_csdev; +kfree (csdev); + goto err_out; } csdev->refcnt = refcnts;
@@ -1619,6 +1621,13 @@ struct coresight_device *coresight_regis csdev->dev.fwnode =fwnode_handle_get (dev_fwnode (desc->dev));dev_set_name (&csdev->dev,"%s" , desc->name); +/* +* Make sure the device registration and the connection fixup +* are synchronised, so that we don't see uninitialised devices +* on the coresight bus while trying to resolve the connections. +*/ +mutex_lock (&coresight_mutex); + ret =device_register (&csdev->dev);if (ret) {put_device (&csdev->dev);
@@ -1626,7 +1635,7 @@ struct coresight_device *coresight_regis* All resources are free'd explicitly via * coresight_device_release(), triggered from put_device(). */ - goto err_out; + goto out_unlock; } if (csdev->type == CORESIGHT_DEV_TYPE_SINK ||
@@ -1641,11 +1650,11 @@ struct coresight_device *coresight_regis* from put_device(), which is in turn called from * function device_unregister(). */ - goto err_out; + goto out_unlock; } } - -mutex_lock (&coresight_mutex); +/* Device is now registered */ + registered = true; ret =coresight_create_conns_sysfs_group (csdev);if (!ret)
@@ -1655,16 +1664,18 @@ struct coresight_device *coresight_regisif (!ret && cti_assoc_ops && cti_assoc_ops->add) cti_assoc_ops->add (csdev); +out_unlock:mutex_unlock (&coresight_mutex); -if (ret) { +/* Success */ +if (!ret) +return csdev; + +/* Unregister the device if needed */ +if (registered) {coresight_unregister (csdev);return ERR_PTR (ret); } -return csdev; - -err_free_csdev: -kfree (csdev); err_out:/* Cleanup the connection information */ coresight_release_platform_data (NULL , desc->pdata);
Greg Kroah-Hartman
maintainerPATCH 753/772 phy: qcom-qmp: fix reset-controller leak on probe errors
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit 4d2900f20edfe541f75756a00deeb2ffe7c66bc1 upstream.
Make sure to release the lane reset controller in case of a late probe error (e.g. probe deferral).
Note that due to the reset controller being defined in devicetree in "lane" child nodes, devm_reset_control_get_exclusive() cannot be used directly.
--- drivers/phy/qualcomm/phy-qcom-qmp.c | 9 +++++++++ 1 file changed, 9 insertions(+)
drivers/phy/qualcomm/phy-qcom-qmp.c +9 -0
@@ -5818,6 +5818,11 @@ static const struct phy_ops qcom_qmp_pci .owner = THIS_MODULE, }; +static void qcom_qmp_reset_control_put (void *data) +{ +reset_control_put (data); +} +static int qcom_qmp_phy_create (struct device *dev,struct device_node *np,int id,void __iomem *serdes,const struct qmp_phy_cfg *cfg)
@@ -5912,6 +5917,10 @@ int qcom_qmp_phy_create(struct device *ddev_err (dev,"failed to get lane%d reset\n" , id);return PTR_ERR (qphy->lane_rst); } + ret =devm_add_action_or_reset (dev, qcom_qmp_reset_control_put, + qphy->lane_rst); +if (ret) +return ret; }if (cfg->type ==PHY_TYPE_UFS || cfg->type ==PHY_TYPE_PCIE )
Greg Kroah-Hartman
maintainerPATCH 754/772 net: ipa: fix page free in ipa_endpoint_trans_release()
In reply to Greg Kroah-HartmanFrom: Alex Elder <[email protected]>
commit 155c0c90bca918de6e4327275dfc1d97fd604115 upstream.
Currently the (possibly compound) page used for receive buffers are freed using __free_pages(). But according to this comment above the definition of that function, that's wrong:
If you want to use the page's reference count to decide when to free the allocation, you should allocate a compound page, and use put_page() instead of __free_pages().
Convert the call to __free_pages() in ipa_endpoint_trans_release() to use put_page() instead.
--- drivers/net/ipa/ipa_endpoint.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ipa/ipa_endpoint.c +1 -1
@@ -1402,7 +1402,7 @@ void ipa_endpoint_trans_release(struct istruct page *page = trans->data;if (page) -__free_pages (page,get_order (IPA_RX_BUFFER_SIZE )); +put_page (page); } }
Greg Kroah-Hartman
maintainerPATCH 755/772 net: ipa: fix page free in ipa_endpoint_replenish_one()
In reply to Greg Kroah-HartmanFrom: Alex Elder <[email protected]>
commit 70132763d5d2e94cd185e3aa92ac6a3ba89068fa upstream.
Currently the (possibly compound) pages used for receive buffers are freed using __free_pages(). But according to this comment above the definition of that function, that's wrong:
If you want to use the page's reference count to decide when to free the allocation, you should allocate a compound page, and use put_page() instead of __free_pages().
Convert the call to __free_pages() in ipa_endpoint_replenish_one() to use put_page() instead.
--- drivers/net/ipa/ipa_endpoint.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ipa/ipa_endpoint.c +1 -1
@@ -1062,7 +1062,7 @@ static int ipa_endpoint_replenish_one(st err_trans_free:gsi_trans_free (trans); err_free_pages: -__free_pages (page,get_order (IPA_RX_BUFFER_SIZE )); +put_page (page);return -ENOMEM ; }
Greg Kroah-Hartman
maintainerPATCH 756/772 kseltest/cgroup: Make test_stress.sh work if run interactively
In reply to Greg Kroah-HartmanFrom: Waiman Long <[email protected]>
commit 213adc63dfbcdff9a0c19ec1f2681fda9c05cf6d upstream.
Commit 54de76c01239 ("kselftest/cgroup: fix test_stress.sh to use OUTPUT dir") changes the test_core command path from . to $OUTPUT. However, variable OUTPUT may not be defined if the command is run interactively. Fix that by using ${OUTPUT:-.} to cover both cases.
--- tools/testing/selftests/cgroup/test_stress.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/testing/selftests/cgroup/test_stress.sh +1 -1
@@ -1,4 +1,4 @@ #!/bin/bash # SPDX-License-Identifier: GPL-2.0 -./with_stress.sh -s subsys -s fork ${OUTPUT}/test_core +./with_stress.sh -s subsys -s fork ${OUTPUT:-.}/test_core
Greg Kroah-Hartman
maintainerPATCH 757/772 perf evlist: Extend arch_evsel__must_be_in_group to support hybrid systems
In reply to Greg Kroah-HartmanFrom: Zhengjun Xing <[email protected]>
commit e69a5c010246ca6a87c4e6f13d0a291954bdece8 upstream.
For the hybrid system, the "slots" event changes to "cpu_core/slots/", need extend API arch_evsel__must_be_in_group() to support hybrid systems.
In the origin code, for hybrid system event "cpu_core/slots/", the output of the API arch_evsel__must_be_in_group() is "false" (in fact,it should be "true"). Currently only one API evsel__remove_from_group() calls it. In evsel__remove_from_group(), it adds the second condition to check, so the output of evsel__remove_from_group() still is correct. That's the reason why there isn't an instant error. I'd like to fix the issue found in API arch_evsel__must_be_in_group() in case someone else using the function in the other place.
--- tools/perf/arch/x86/util/evsel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/perf/arch/x86/util/evsel.c +1 -1
@@ -38,6 +38,6 @@ bool arch_evsel__must_be_in_group(constreturn false;return evsel->name && - (!strcasecmp (evsel->name,"slots" ) || + (strcasestr (evsel->name,"slots" ) ||strcasestr (evsel->name,"topdown" )); }
Greg Kroah-Hartman
maintainerPATCH 758/772 list: test: Add a test for list_is_head()
In reply to Greg Kroah-HartmanFrom: David Gow <[email protected]>
commit 37dc573c0a547e1aed0c9abb480fab797bd3833f upstream.
list_is_head() was added recently[1], and didn't have a KUnit test. The implementation is trivial, so it's not a particularly exciting test, but it'd be nice to get back to full coverage of the list functions.
--- lib/list-test.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)
lib/list-test.c +19 -0
@@ -234,6 +234,24 @@ static void list_test_list_bulk_move_taiKUNIT_EXPECT_EQ (test, i,2 ); } +static void list_test_list_is_head (struct kunit *test) +{ +struct list_head a, b, c; + +/* Two lists: [a] -> b, [c] */ +INIT_LIST_HEAD (&a); +INIT_LIST_HEAD (&c); +list_add_tail (&b, &a); + +KUNIT_EXPECT_TRUE_MSG (test,list_is_head (&a, &a), +"Head element of same list" ); +KUNIT_EXPECT_FALSE_MSG (test,list_is_head (&a, &b), +"Non-head element of same list" ); +KUNIT_EXPECT_FALSE_MSG (test,list_is_head (&a, &c), +"Head element of different list" ); +} + +static void list_test_list_is_first (struct kunit *test) {struct list_head a, b;
@@ -710,6 +728,7 @@ static struct kunit_case list_test_casesKUNIT_CASE (list_test_list_move),KUNIT_CASE (list_test_list_move_tail),KUNIT_CASE (list_test_list_bulk_move_tail), +KUNIT_CASE (list_test_list_is_head),KUNIT_CASE (list_test_list_is_first),KUNIT_CASE (list_test_list_is_last), KUNIT_CASE(list_test_list_empty),
Greg Kroah-Hartman
maintainerPATCH 759/772 Revert "random: use static branch for crng_ready()"
In reply to Greg Kroah-HartmanFrom: "Jason A. Donenfeld" <[email protected]>
This reverts upstream commit f5bda35fba615ace70a656d4700423fa6c9bebee from stable. It's not essential and will take some time during 5.19 to work out properly.
--- drivers/char/random.c | 12 ++---------- 1 file changed, 2 insertions(+), 10 deletions(-)
drivers/char/random.c +2 -10
@@ -79,8 +79,7 @@ static enum {CRNG_EARLY =1 ,/* At least POOL_EARLY_BITS collected */ CRNG_READY = 2 /* Fully initialized with POOL_READY_BITS collected */ } crng_init__read_mostly =CRNG_EMPTY ; -static DEFINE_STATIC_KEY_FALSE (crng_is_ready); -#define crng_ready () (static_branch_likely(&crng_is_ready) || crng_init >= CRNG_READY) +#define crng_ready () (likely(crng_init >= CRNG_READY))/* Various types of waiters for crng_init->CRNG_READY transition. */ static DECLARE_WAIT_QUEUE_HEAD (crng_init_wait);static struct fasync_struct *fasync;
@@ -110,11 +109,6 @@ bool rng_is_initialized(void) }EXPORT_SYMBOL (rng_is_initialized); -static void __cold crng_set_ready (struct work_struct *work) -{ -static_branch_enable (&crng_is_ready); -} -/* Used by wait_for_random_bytes(), and considered an entropy collector, below. */ static void try_to_generate_entropy (void );
@@ -268,7 +262,7 @@ static void crng_reseed(void) ++next_gen;WRITE_ONCE (base_crng.generation, next_gen);WRITE_ONCE (base_crng.birth, jiffies); -if (!static_branch_likely (&crng_is_ready)) +if (!crng_ready ()) crng_init =CRNG_READY ;spin_unlock_irqrestore (&base_crng.lock, flags);memzero_explicit (key,sizeof (key));
@@ -711,7 +705,6 @@ static void extract_entropy(void *buf, sstatic void __cold _credit_init_bits (size_t bits) { -static struct execute_work set_ready;unsigned int new, orig, add;unsigned long flags;
@@ -727,7 +720,6 @@ static void __cold _credit_init_bits(sizif (orig <POOL_READY_BITS && new >=POOL_READY_BITS ) {crng_reseed ();/* Sets crng_init to CRNG_READY under base_crng.lock. */ -execute_in_process_context (crng_set_ready, &set_ready);process_random_ready_list ();wake_up_interruptible (&crng_init_wait);kill_fasync (&fasync,SIGIO ,POLL_IN );
Greg Kroah-Hartman
maintainerPATCH 760/772 staging: r8188eu: delete rtw_wx_read/write32()
In reply to Greg Kroah-HartmanFrom: Dan Carpenter <[email protected]>
commit 4d0cc9e0e53e9946d7b8dc58279c62dfa7a2191b upstream.
These debugging tools let you call:
status = usb_control_msg_recv/send(udev, 0, REALTEK_USB_VENQT_CMD_REQ, REALTEK_USB_VENQT_READ/WRITE, value, REALTEK_USB_VENQT_CMD_IDX, io_buf, size, RTW_USB_CONTROL_MSG_TIMEOUT, GFP_KERNEL);
with a user controlled "value" in the 0-0xffff range. It's not a valid API.
--- drivers/staging/r8188eu/os_dep/ioctl_linux.c | 92 --------------------------- 1 file changed, 2 insertions(+), 90 deletions(-)
drivers/staging/r8188eu/os_dep/ioctl_linux.c +2 -90
@@ -1969,94 +1969,6 @@ static int rtw_wx_get_nick(struct net_dereturn 0 ; } -static int rtw_wx_read32 (struct net_device *dev, -struct iw_request_info *info, -union iwreq_data *wrqu,char *extra) -{ -struct adapter *padapter; -struct iw_point *p; -u16 len; -u32 addr; -u32 data32; -u32 bytes; -u8 *ptmp; -int ret; - - padapter = (struct adapter *)rtw_netdev_priv (dev); - p = &wrqu->data; - len = p->length; - ptmp =memdup_user (p->pointer, len); -if (IS_ERR (ptmp)) -return PTR_ERR (ptmp); - - bytes =0 ; - addr =0 ; -sscanf (ptmp,"%d,%x" , &bytes, &addr); - -switch (bytes) { -case 1 : - data32 =rtw_read8 (padapter, addr); -sprintf (extra,"0x%02X" , data32); -break ; -case 2 : - data32 =rtw_read16 (padapter, addr); -sprintf (extra,"0x%04X" , data32); -break ; -case 4 : - data32 =rtw_read32 (padapter, addr); -sprintf (extra,"0x%08X" , data32); -break ; -default : -DBG_88E (KERN_INFO "%s: usage> read [bytes],[address(hex)]\n" , __func__); - ret = -EINVAL ; - goto err_free_ptmp; - } -DBG_88E (KERN_INFO "%s: addr = 0x%08X data =%s\n" , __func__, addr, extra); - -kfree (ptmp); -return 0 ; - -err_free_ptmp: -kfree (ptmp); -return ret; -} - -static int rtw_wx_write32 (struct net_device *dev, -struct iw_request_info *info, -union iwreq_data *wrqu,char *extra) -{ -struct adapter *padapter = (struct adapter *)rtw_netdev_priv (dev); - -u32 addr; -u32 data32; -u32 bytes; - - bytes =0 ; - addr =0 ; - data32 =0 ; -sscanf (extra,"%d,%x,%x" , &bytes, &addr, &data32); - -switch (bytes) { -case 1 : -rtw_write8 (padapter, addr, (u8 )data32); -DBG_88E (KERN_INFO "%s: addr = 0x%08X data = 0x%02X\n" , __func__, addr, (u8 )data32); -break ; -case 2 : -rtw_write16 (padapter, addr, (u16 )data32); -DBG_88E (KERN_INFO "%s: addr = 0x%08X data = 0x%04X\n" , __func__, addr, (u16 )data32); -break ; -case 4 : -rtw_write32 (padapter, addr, data32); -DBG_88E (KERN_INFO "%s: addr = 0x%08X data = 0x%08X\n" , __func__, addr, data32); -break ; -default : -DBG_88E (KERN_INFO "%s: usage> write [bytes],[address(hex)],[data(hex)]\n" , __func__); -return -EINVAL ; - } - -return 0 ; -} -static int rtw_wx_read_rf (struct net_device *dev,struct iw_request_info *info,union iwreq_data *wrqu,char *extra)
@@ -4267,8 +4179,8 @@ static const struct iw_priv_args rtw_pri };static iw_handler rtw_private_handler[] = { -rtw_wx_write32,/* 0x00 */ -rtw_wx_read32,/* 0x01 */ +NULL ,/* 0x00 */ +NULL ,/* 0x01 */ NULL ,/* 0x02 */ NULL ,/* 0x03 */ /* for MM DTV platform */
Greg Kroah-Hartman
maintainerPATCH 761/772 RDMA/hns: Remove the num_cqc_timer variable
In reply to Greg Kroah-HartmanFrom: Yixing Liu <[email protected]>
commit db5dfbf5b201df65c1f5332c4d9d5e7c2f42396b upstream.
The bt number of cqc_timer of HIP09 increases compared with that of HIP08. Therefore, cqc_timer_bt_num and num_cqc_timer do not match. As a result, the driver may fail to allocate cqc_timer. So the driver needs to uniquely uses cqc_timer_bt_num to represent the bt number of cqc_timer.
--- drivers/infiniband/hw/hns/hns_roce_device.h | 1 - drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 3 +-- drivers/infiniband/hw/hns/hns_roce_hw_v2.h | 2 +- drivers/infiniband/hw/hns/hns_roce_main.c | 2 +- 4 files changed, 3 insertions(+), 5 deletions(-)
drivers/infiniband/hw/hns/hns_roce_device.h +0 -1
@@ -721,7 +721,6 @@ struct hns_roce_caps {u32 num_pi_qps;u32 reserved_qps;int num_qpc_timer; -int num_cqc_timer;u32 num_srqs;u32 max_wqes;u32 max_srq_wrs;
drivers/infiniband/hw/hns/hns_roce_hw_v2.c +1 -2
@@ -1965,7 +1965,7 @@ static void set_default_caps(struct hns_ caps->num_mtpts =HNS_ROCE_V2_MAX_MTPT_NUM ; caps->num_pds =HNS_ROCE_V2_MAX_PD_NUM ; caps->num_qpc_timer =HNS_ROCE_V2_MAX_QPC_TIMER_NUM ; - caps->num_cqc_timer =HNS_ROCE_V2_MAX_CQC_TIMER_NUM ; + caps->cqc_timer_bt_num =HNS_ROCE_V2_MAX_CQC_TIMER_BT_NUM ; caps->max_qp_init_rdma =HNS_ROCE_V2_MAX_QP_INIT_RDMA ; caps->max_qp_dest_rdma =HNS_ROCE_V2_MAX_QP_DEST_RDMA ;
@@ -2261,7 +2261,6 @@ static int hns_roce_query_pf_caps(struct caps->max_rq_sg =roundup_pow_of_two (caps->max_rq_sg); caps->max_extend_sg =le32_to_cpu (resp_a->max_extend_sg); caps->num_qpc_timer =le16_to_cpu (resp_a->num_qpc_timer); - caps->num_cqc_timer =le16_to_cpu (resp_a->num_cqc_timer); caps->max_srq_sges =le16_to_cpu (resp_a->max_srq_sges); caps->max_srq_sges =roundup_pow_of_two (caps->max_srq_sges); caps->num_aeq_vectors = resp_a->num_aeq_vectors;
drivers/infiniband/hw/hns/hns_roce_hw_v2.h +1 -1
@@ -41,7 +41,7 @@#define HNS_ROCE_V2_MAX_SRQ_WR 0x8000#define HNS_ROCE_V2_MAX_SRQ_SGE 64#define HNS_ROCE_V2_MAX_CQ_NUM 0x100000 -#define HNS_ROCE_V2_MAX_CQC_TIMER_NUM 0x100 +#define HNS_ROCE_V2_MAX_CQC_TIMER_BT_NUM 0x100#define HNS_ROCE_V2_MAX_SRQ_NUM 0x100000#define HNS_ROCE_V2_MAX_CQE_NUM 0x400000#define HNS_ROCE_V2_MAX_RQ_SGE_NUM 64
drivers/infiniband/hw/hns/hns_roce_main.c +1 -1
@@ -737,7 +737,7 @@ static int hns_roce_init_hem(struct hns_ ret =hns_roce_init_hem_table (hr_dev, &hr_dev->cqc_timer_table,HEM_TYPE_CQC_TIMER , hr_dev->caps.cqc_timer_entry_sz, - hr_dev->caps.num_cqc_timer,1 ); + hr_dev->caps.cqc_timer_bt_num,1 );if (ret) {dev_err (dev,"Failed to init CQC timer memory, aborting.\n" );
Greg Kroah-Hartman
maintainerPATCH 762/772 RDMA/rxe: Generate a completion for unsupported/invalid opcode
In reply to Greg Kroah-HartmanFrom: Xiao Yang <[email protected]>
commit 2f917af777011c88e977b9b9a5d00b280d3a59ce upstream.
Current rxe_requester() doesn't generate a completion when processing an unsupported/invalid opcode. If rxe driver doesn't support a new opcode (e.g. RDMA Atomic Write) and RDMA library supports it, an application using the new opcode can reproduce this issue. Fix the issue by calling "goto err;".
--- drivers/infiniband/sw/rxe/rxe_req.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/infiniband/sw/rxe/rxe_req.c +1 -1
@@ -661,7 +661,7 @@ next_wqe: opcode =next_opcode (qp, wqe, wqe->wr.opcode);if (unlikely (opcode <0 )) { wqe->status =IB_WC_LOC_QP_OP_ERR ; - goto exit; + goto err; } mask = rxe_opcode[opcode].mask;
Greg Kroah-Hartman
maintainerPATCH 763/772 MIPS: IP27: Remove incorrect `cpu_has_fpu override
In reply to Greg Kroah-HartmanFrom: Maciej W. Rozycki <[email protected]>
commit 424c3781dd1cb401857585331eaaa425a13f2429 upstream.
Remove unsupported forcing of cpu_has_fpu' to 1, which makes the nofpu' kernel parameter non-functional, and also causes a link error:
ld: arch/mips/kernel/traps.o: in function `trap_init':
./arch/mips/include/asm/msa.h:(.init.text+0x348): undefined reference to `handle_fpe'
ld: ./arch/mips/include/asm/msa.h:(.init.text+0x354): undefined reference to `handle_fpe'
ld: ./arch/mips/include/asm/msa.h:(.init.text+0x360): undefined reference to `handle_fpe'
where the CONFIG_MIPS_FP_SUPPORT configuration option has been disabled.
--- arch/mips/include/asm/mach-ip27/cpu-feature-overrides.h | 1 - 1 file changed, 1 deletion(-)
arch/mips/include/asm/mach-ip27/cpu-feature-overrides.h +0 -1
@@ -26,7 +26,6 @@#define cpu_has_3k_cache 0#define cpu_has_4k_cache 1#define cpu_has_tx39_cache 0 -#define cpu_has_fpu 1#define cpu_has_nofpuex 0#define cpu_has_32fpr 1#define cpu_has_counter 1
Greg Kroah-Hartman
maintainerPATCH 764/772 MIPS: IP30: Remove incorrect `cpu_has_fpu override
In reply to Greg Kroah-HartmanFrom: Maciej W. Rozycki <[email protected]>
commit f44b3e74c33fe04defeff24ebcae98c3bcc5b285 upstream.
Remove unsupported forcing of cpu_has_fpu' to 1, which makes the nofpu' kernel parameter non-functional, and also causes a link error:
ld: arch/mips/kernel/traps.o: in function `trap_init':
./arch/mips/include/asm/msa.h:(.init.text+0x348): undefined reference to `handle_fpe'
ld: ./arch/mips/include/asm/msa.h:(.init.text+0x354): undefined reference to `handle_fpe'
ld: ./arch/mips/include/asm/msa.h:(.init.text+0x360): undefined reference to `handle_fpe'
where the CONFIG_MIPS_FP_SUPPORT configuration option has been disabled.
--- arch/mips/include/asm/mach-ip30/cpu-feature-overrides.h | 1 - 1 file changed, 1 deletion(-)
arch/mips/include/asm/mach-ip30/cpu-feature-overrides.h +0 -1
@@ -29,7 +29,6 @@#define cpu_has_3k_cache 0#define cpu_has_4k_cache 1#define cpu_has_tx39_cache 0 -#define cpu_has_fpu 1#define cpu_has_nofpuex 0#define cpu_has_32fpr 1#define cpu_has_counter 1
Greg Kroah-Hartman
maintainerPATCH 765/772 ext4: only allow test_dummy_encryption when supported
In reply to Greg Kroah-HartmanFrom: Eric Biggers <[email protected]>
commit 5f41fdaea63ddf96d921ab36b2af4a90ccdb5744 upstream.
Make the test_dummy_encryption mount option require that the encrypt feature flag be already enabled on the filesystem, rather than automatically enabling it. Practically, this means that "-O encrypt" will need to be included in MKFS_OPTIONS when running xfstests with the test_dummy_encryption mount option. (ext4/053 also needs an update.)
Moreover, as long as the preconditions for test_dummy_encryption are being tightened anyway, take the opportunity to start rejecting it when !CONFIG_FS_ENCRYPTION rather than ignoring it.
The motivation for requiring the encrypt feature flag is that:
- Having the filesystem auto-enable feature flags is problematic, as it bypasses the usual sanity checks. The specific issue which came up recently is that in kernel versions where ext4 supports casefold but not encrypt+casefold (v5.1 through v5.10), the kernel will happily add the encrypt flag to a filesystem that has the casefold flag, making it unmountable -- but only for subsequent mounts, not the initial one. This confused the casefold support detection in xfstests, causing generic/556 to fail rather than be skipped.
- The xfstests-bld test runners (kvm-xfstests et al.) already use the required mkfs flag, so they will not be affected by this change. Only users of test_dummy_encryption alone will be affected. But, this option has always been for testing only, so it should be fine to require that the few users of this option update their test scripts.
- f2fs already requires it (for its equivalent feature flag).
--- fs/ext4/ext4.h | 6 ----- fs/ext4/super.c | 60 +++++++++++++++++++++++++++++++++++--------------------- 2 files changed, 38 insertions(+), 28 deletions(-)
fs/ext4/ext4.h +0 -6
@@ -1438,12 +1438,6 @@ struct ext4_super_block {#ifdef __KERNEL__ -#ifdef CONFIG_FS_ENCRYPTION -#define DUMMY_ENCRYPTION_ENABLED (sbi) ((sbi)->s_dummy_enc_policy.policy != NULL) -#else -#define DUMMY_ENCRYPTION_ENABLED (sbi) (0) -#endif -/* Number of quota types we support */ #define EXT4_MAXQUOTAS 3
fs/ext4/super.c +38 -22
93 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 766/772 fs: add two trivial lookup helpers
In reply to Greg Kroah-HartmanFrom: Christian Brauner <[email protected]>
commit 00675017e0aeba5305665c52ded4ddce6a4c0231 upstream.
Similar to the addition of lookup_one() add a version of lookup_one_unlocked() and lookup_one_positive_unlocked() that take idmapped mounts into account. This is required to port overlay to support idmapped base layers.
--- fs/namei.c | 70 ++++++++++++++++++++++++++++++++++++++++++-------- include/linux/namei.h | 6 ++++ 2 files changed, 66 insertions(+), 10 deletions(-)
fs/namei.c +60 -10
@@ -2768,7 +2768,8 @@ struct dentry *lookup_one(struct user_naEXPORT_SYMBOL (lookup_one);/** -* lookup_one_len_unlocked - filesystem helper to lookup single pathname component +* lookup_one_unlocked - filesystem helper to lookup single pathname component +* @mnt_userns: idmapping of the mount the lookup is performed from * @name: pathname component to lookup * @base: base directory to lookup from * @len: maximum length @len should be interpreted to
@@ -2779,14 +2780,15 @@ EXPORT_SYMBOL(lookup_one);* Unlike lookup_one_len, it should be called without the parent * i_mutex held, and will take the i_mutex itself if necessary. */ -struct dentry *lookup_one_len_unlocked (const char *name, -struct dentry *base,int len) +struct dentry *lookup_one_unlocked (struct user_namespace *mnt_userns, +const char *name,struct dentry *base, +int len) {struct qstr this;int err;struct dentry *ret; - err =lookup_one_common (&init_user_ns, name, base, len, &this); + err =lookup_one_common (mnt_userns, name, base, len, &this);if (err)return ERR_PTR (err);
@@ -2795,6 +2797,59 @@ struct dentry *lookup_one_len_unlocked(c ret =lookup_slow (&this, base,0 );return ret; } +EXPORT_SYMBOL (lookup_one_unlocked); + +/** +* lookup_one_positive_unlocked - filesystem helper to lookup single +* pathname component +* @mnt_userns: idmapping of the mount the lookup is performed from +* @name: pathname component to lookup +* @base: base directory to lookup from +* @len: maximum length @len should be interpreted to +* +* This helper will yield ERR_PTR(-ENOENT) on negatives. The helper returns +* known positive or ERR_PTR(). This is what most of the users want. +* +* Note that pinned negative with unlocked parent _can_ become positive at any +* time, so callers of lookup_one_unlocked() need to be very careful; pinned +* positives have >d_inode stable, so this one avoids such problems. +* +* Note that this routine is purely a helper for filesystem usage and should +* not be called by generic code. +* +* The helper should be called without i_mutex held. +*/ +struct dentry *lookup_one_positive_unlocked (struct user_namespace *mnt_userns, +const char *name, +struct dentry *base,int len) +{ +struct dentry *ret =lookup_one_unlocked (mnt_userns, name, base, len); + +if (!IS_ERR (ret) &&d_flags_negative (smp_load_acquire (&ret->d_flags))) { +dput (ret); + ret =ERR_PTR (-ENOENT ); + } +return ret; +} +EXPORT_SYMBOL (lookup_one_positive_unlocked); + +/** +* lookup_one_len_unlocked - filesystem helper to lookup single pathname component +* @name: pathname component to lookup +* @base: base directory to lookup from +* @len: maximum length @len should be interpreted to +* +* Note that this routine is purely a helper for filesystem usage and should +* not be called by generic code. +* +* Unlike lookup_one_len, it should be called without the parent +* i_mutex held, and will take the i_mutex itself if necessary. +*/ +struct dentry *lookup_one_len_unlocked (const char *name, +struct dentry *base,int len) +{ +return lookup_one_unlocked (&init_user_ns, name, base, len); +}EXPORT_SYMBOL (lookup_one_len_unlocked);/*
@@ -2808,12 +2863,7 @@ EXPORT_SYMBOL(lookup_one_len_unlocked);struct dentry *lookup_positive_unlocked (const char *name,struct dentry *base,int len) { -struct dentry *ret =lookup_one_len_unlocked (name, base, len); -if (!IS_ERR (ret) &&d_flags_negative (smp_load_acquire (&ret->d_flags))) { -dput (ret); - ret =ERR_PTR (-ENOENT ); - } -return ret; +return lookup_one_positive_unlocked (&init_user_ns, name, base, len); }EXPORT_SYMBOL (lookup_positive_unlocked);
include/linux/namei.h +6 -0
@@ -69,6 +69,12 @@ extern struct dentry *lookup_one_len(conextern struct dentry *lookup_one_len_unlocked (const char *,struct dentry *,int );extern struct dentry *lookup_positive_unlocked (const char *,struct dentry *,int );struct dentry *lookup_one (struct user_namespace *,const char *,struct dentry *,int ); +struct dentry *lookup_one_unlocked (struct user_namespace *mnt_userns, +const char *name,struct dentry *base, +int len); +struct dentry *lookup_one_positive_unlocked (struct user_namespace *mnt_userns, +const char *name, +struct dentry *base,int len);extern int follow_down_one (struct path *);extern int follow_down (struct path *);
Greg Kroah-Hartman
maintainerPATCH 767/772 exportfs: support idmapped mounts
In reply to Greg Kroah-HartmanFrom: Christian Brauner <[email protected]>
commit 3a761d72fa62eec8913e45d29375344f61706541 upstream.
Make the two locations where exportfs helpers check permission to lookup a given inode idmapped mount aware by switching it to the lookup_one() helper. This is a bugfix for the open_by_handle_at() system call which doesn't take idmapped mounts into account currently. It's not tied to a specific commit so we'll just Cc stable.
In addition this is required to support idmapped base layers in overlay. The overlay filesystem uses exportfs to encode and decode file handles for its index=on mount option and when nfs_export=on.
--- fs/exportfs/expfs.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
fs/exportfs/expfs.c +3 -2
@@ -145,7 +145,7 @@ static struct dentry *reconnect_one(struif (err) goto out_err;dprintk ("%s: found name: %s\n" , __func__, nbuf); - tmp =lookup_one_len_unlocked (nbuf, parent,strlen (nbuf)); + tmp =lookup_one_unlocked (mnt_user_ns (mnt), nbuf, parent,strlen (nbuf));if (IS_ERR (tmp)) {dprintk ("%s: lookup failed: %d\n" , __func__,PTR_ERR (tmp)); err =PTR_ERR (tmp);
@@ -525,7 +525,8 @@ exportfs_decode_fh_raw(struct vfsmount * }inode_lock (target_dir->d_inode); - nresult =lookup_one_len (nbuf, target_dir,strlen (nbuf)); + nresult =lookup_one (mnt_user_ns (mnt), nbuf, + target_dir,strlen (nbuf));if (!IS_ERR (nresult)) {if (unlikely (nresult->d_inode != result->d_inode)) {dput (nresult);
Greg Kroah-Hartman
maintainerPATCH 768/772 fs/ntfs3: Fix invalid free in log_replay
In reply to Greg Kroah-HartmanFrom: Namjae Jeon <[email protected]>
commit f26967b9f7a830e228bb13fb41bd516ddd9d789d upstream.
log_read_rst() returns ENOMEM error when there is not enough memory. In this case, if info is returned without initialization,
it attempts to kfree the uninitialized info->r_page pointer. This patch moves the memset initialization code to before log_read_rst() is called.
--- fs/ntfs3/fslog.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
fs/ntfs3/fslog.c +3 -3
@@ -1185,8 +1185,6 @@ static int log_read_rst(struct ntfs_logif (!r_page)return -ENOMEM ; -memset (info,0 ,sizeof (struct restart_info )); -/* Determine which restart area we are looking for. */ if (first) { vbo =0 ;
@@ -3791,10 +3789,11 @@ int log_replay(struct ntfs_inode *ni, boif (!log)return -ENOMEM ; +memset (&rst_info,0 ,sizeof (struct restart_info )); + log->ni = ni; log->l_size = l_size; log->one_page_buf =kmalloc (page_size,GFP_NOFS ); -if (!log->one_page_buf) { err = -ENOMEM ; goto out;
@@ -3842,6 +3841,7 @@ int log_replay(struct ntfs_inode *ni, boif (rst_info.vbo) goto check_restart_area; +memset (&rst_info2,0 ,sizeof (struct restart_info )); err =log_read_rst (log, l_size, false, &rst_info2);/* Determine which restart area to use. */
Greg Kroah-Hartman
maintainerPATCH 769/772 md: Dont set mddev private to NULL in raid0 pers->free
In reply to Greg Kroah-HartmanFrom: Xiao Ni <[email protected]>
commit 0f2571ad7a30ff6b33cde142439f9378669f8b4f upstream.
In normal stop process, it does like this:
do_md_stop
|
__md_stop (pers->free(); mddev->private=NULL)
| md_free (free mddev)__md_stop sets mddev->private to NULL after pers->free. The raid device will be stopped and mddev memory is free. But in reshape, it doesn't free the mddev and mddev will still be used in new raid.
In reshape, it first sets mddev->private to new_pers and then runs old_pers->free(). Now raid0 sets mddev->private to NULL in raid0_free. The new raid can't work anymore. It will panic when dereference mddev->private because of NULL pointer dereference.
It can panic like this:
[63010.814972] kernel BUG at drivers/md/raid10.c:928! [63010.819778] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [63010.825011] CPU: 3 PID: 44437 Comm: md0_resync Kdump: loaded Not tainted 5.14.0-86.el9.x86_64 #1 [63010.833789] Hardware name: Dell Inc. PowerEdge R6415/07YXFK, BIOS 1.15.0 09/11/2020 [63010.841440] RIP: 0010:raise_barrier+0x161/0x170 [raid10] [63010.865508] RSP: 0018:ffffc312408bbc10 EFLAGS: 00010246 [63010.870734] RAX: 0000000000000000 RBX: ffffa00bf7d39800 RCX: 0000000000000000 [63010.877866] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffa00bf7d39800 [63010.884999] RBP: 0000000000000000 R08: fffffa4945e74400 R09: 0000000000000000 [63010.892132] R10: ffffa00eed02f798 R11: 0000000000000000 R12: ffffa00bbc435200 [63010.899266] R13: ffffa00bf7d39800 R14: 0000000000000400 R15: 0000000000000003 [63010.906399] FS: 0000000000000000(0000) GS:ffffa00eed000000(0000) knlGS:0000000000000000 [63010.914485] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [63010.920229] CR2: 00007f5cfbe99828 CR3: 0000000105efe000 CR4: 00000000003506e0 [63010.927363] Call Trace: [63010.929822] ? bio_reset+0xe/0x40 [63010.933144] ? raid10_alloc_init_r10buf+0x60/0xa0 [raid10] [63010.938629] raid10_sync_request+0x756/0x1610 [raid10] [63010.943770] md_do_sync.cold+0x3e4/0x94c [63010.947698] md_thread+0xab/0x160 [63010.951024] ? md_write_inc+0x50/0x50 [63010.954688] kthread+0x149/0x170 [63010.957923] ? set_kthread_struct+0x40/0x40 [63010.962107] ret_from_fork+0x22/0x30
Removing the code that sets mddev->private to NULL in raid0 can fix problem.
--- drivers/md/raid0.c | 1 - 1 file changed, 1 deletion(-)
drivers/md/raid0.c +0 -1
@@ -361,7 +361,6 @@ static void free_conf(struct mddev *mddekfree (conf->strip_zone);kfree (conf->devlist);kfree (conf); - mddev->private =NULL ; }static void raid0_free (struct mddev *mddev,void *priv)
Greg Kroah-Hartman
maintainerPATCH 770/772 md: fix double free of io_acct_set bioset
In reply to Greg Kroah-HartmanFrom: Xiao Ni <[email protected]>
commit 42b805af102471f53e3c7867b8c2b502ea4eef7e upstream.
Now io_acct_set is alloc and free in personality. Remove the codes that free io_acct_set in md_free and md_stop.
--- drivers/md/md.c | 4 ---- 1 file changed, 4 deletions(-)
drivers/md/md.c +0 -4
@@ -5600,8 +5600,6 @@ static void md_free(struct kobject *ko)bioset_exit (&mddev->bio_set);bioset_exit (&mddev->sync_set); -if (mddev->level !=1 && mddev->level !=10 ) -bioset_exit (&mddev->io_acct_set);kfree (mddev); }
@@ -6288,8 +6286,6 @@ void md_stop(struct mddev *mddev)__md_stop (mddev);bioset_exit (&mddev->bio_set);bioset_exit (&mddev->sync_set); -if (mddev->level !=1 && mddev->level !=10 ) -bioset_exit (&mddev->io_acct_set); }EXPORT_SYMBOL_GPL (md_stop);
Greg Kroah-Hartman
maintainerPATCH 771/772 md: bcache: check the return value of kzalloc() in detached_dev_do_request()
In reply to Greg Kroah-HartmanFrom: Jia-Ju Bai <[email protected]>
commit 40f567bbb3b0639d2ec7d1c6ad4b1b018f80cf19 upstream.
The function kzalloc() in detached_dev_do_request() can fail, so its return value should be checked.
--- drivers/md/bcache/request.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/md/bcache/request.c +6 -0
@@ -1107,6 +1107,12 @@ static void detached_dev_do_request(stru* which would call closure_get(&dc->disk.cl) */ ddip =kzalloc (sizeof (struct detached_dev_io_private ),GFP_NOIO ); +if (!ddip) { + bio->bi_status =BLK_STS_RESOURCE ; + bio->bi_end_io (bio); +return ; + } + ddip->d = d;/* Count on the bcache device */ ddip->orig_bdev = orig_bdev;
Greg Kroah-Hartman
maintainerPATCH 772/772 tty: n_gsm: Fix packet data hex dump output
In reply to Greg Kroah-HartmanFrom: Tony Lindgren <[email protected]>
commit 925ea0fa5277c1e6bb9e51955ef34eea9736c3d7 upstream.
The module param debug for n_gsm uses KERN_INFO level, but the hexdump now uses KERN_DEBUG level. This started after commit 091cb0994edd ("lib/hexdump: make print_hex_dump_bytes() a nop on !DEBUG builds"). We now use dynamic_hex_dump() unless DEBUG is set.
This causes no packets to be seen with modprobe n_gsm debug=0x1f unlike earlier. Let's fix this by adding gsm_hex_dump_bytes() that calls print_hex_dump() with KERN_INFO to match what n_gsm is doing with the other debug related output.
--- drivers/tty/n_gsm.c | 31 +++++++++++++++++++++++-------- 1 file changed, 23 insertions(+), 8 deletions(-)
drivers/tty/n_gsm.c +23 -8
@@ -444,6 +444,25 @@ static u8 gsm_encode_modem(const structreturn modembits; } +static void gsm_hex_dump_bytes (const char *fname,const u8 *data, +unsigned long len) +{ +char *prefix; + +if (!fname) { +print_hex_dump (KERN_INFO ,"" ,DUMP_PREFIX_NONE ,16 ,1 , data, len, + true); +return ; + } + + prefix =kasprintf (GFP_KERNEL ,"%s: " , fname); +if (!prefix) +return ; +print_hex_dump (KERN_INFO , prefix,DUMP_PREFIX_OFFSET ,16 ,1 , data, len, + true); +kfree (prefix); +} +/** * gsm_print_packet - display a frame for debug * @hdr: header to print before decode
@@ -508,7 +527,7 @@ static void gsm_print_packet(const charelse pr_cont ("(F)" ); -print_hex_dump_bytes ("" ,DUMP_PREFIX_NONE , data, dlen); +gsm_hex_dump_bytes (NULL , data, dlen); }
@@ -698,9 +717,7 @@ static void gsm_data_kick(struct gsm_mux }if (debug &4 ) -print_hex_dump_bytes ("gsm_data_kick: " , -DUMP_PREFIX_OFFSET , - gsm->txframe, len); +gsm_hex_dump_bytes (__func__, gsm->txframe, len);if (gsmld_output (gsm, gsm->txframe, len) <=0 )break ;/* FIXME: Can eliminate one SOF in many more cases */
@@ -2448,8 +2465,7 @@ static int gsmld_output(struct gsm_mux *return -ENOSPC ; }if (debug &4 ) -print_hex_dump_bytes ("gsmld_output: " ,DUMP_PREFIX_OFFSET , - data, len); +gsm_hex_dump_bytes (__func__, data, len);return gsm->tty->ops->write (gsm->tty, data, len); }
@@ -2525,8 +2541,7 @@ static void gsmld_receive_buf(struct ttychar flags =TTY_NORMAL ;if (debug &4 ) -print_hex_dump_bytes ("gsmld_receive: " ,DUMP_PREFIX_OFFSET , - cp, count); +gsm_hex_dump_bytes (__func__, cp, count);for (; count; count--, cp++) {if (fp)
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.17.14 release. There are 772 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 Thu, 09 Jun 2022 16:48:02 +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.14-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
Hi Greg,
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.17.14 release. There are 772 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 Thu, 09 Jun 2022 16:48:02 +0000. Anything received after that time might be too late.
Build test (gcc version 11.3.1 20220606):
mips: 60 configs -> no failure
arm: 99 configs -> no failure
arm64: 3 configs -> no failurex86_64: 4 configs -> no failure
alpha allmodconfig -> no failure
csky allmodconfig -> no failure
powerpc allmodconfig -> no failure
riscv allmodconfig -> no failure
s390 allmodconfig -> no failure
xtensa allmodconfig -> no failure
Boot test:x86_64: Booted on my test laptop. No regression.x86_64: Booted on qemu. No regression. [1]
arm64: Booted on rpi4b (4GB model). No regression. [2]
mips: Booted on ci20 board. No regression. [3]
[1]. https://openqa.qa.codethink.co.uk/tests/1290
[2]. https://openqa.qa.codethink.co.uk/tests/1294
[3]. https://openqa.qa.codethink.co.uk/tests/1296
--
Regards
Sudip
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.17.14 release. There are 772 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 Thu, 09 Jun 2022 16:48:02 +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.14-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.
Regressions found on qemu_x86_64:
- kunit/kasan [1]
Regressions found on qemu_i386:
- kunit/kfence [2]
- kunit/test_out_of_bounds_read
We will bisect and let you know more details about this reported problem.
[1] https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.17.y/build/v5.17.13-773-gd0f9b2818e1e/testrun/10038101/suite/kunit/test/kasan/details/
[2] https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.17.y/build/v5.17.13-773-gd0f9b2818e1e/testrun/10038215/suite/kunit/test/kfence/details/
## Build
* kernel: 5.17.14-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.17.y
* git commit: d0f9b2818e1e4d43847e10d6e5310a0c653cb18f
* git describe: v5.17.13-773-gd0f9b2818e1e
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.17.y/build/v5.17.13-773-gd0f9b2818e1e
## Test Regressions (compared to v5.17.11-188-g8eb69e8f0d45) Regressions found on qemu_x86_64:
- kunit/kasan [1]
Regressions found on qemu_i386:
- kunit/kfence [2]
- kunit/test_out_of_bounds_read
## Metric Regressions (compared to v5.17.11-188-g8eb69e8f0d45) No metric regressions found.
## Test Fixes (compared to v5.17.11-188-g8eb69e8f0d45) No test fixes found.
## Metric Fixes (compared to v5.17.11-188-g8eb69e8f0d45) No metric fixes found.
## Test result summary
total: 134591, pass: 121555, fail: 447, skip: 11730, xfail: 859
## Build Summary
* arm: 17 total, 14 passed, 3 failed
* arm64: 20 total, 20 passed, 0 failed
* i386: 17 total, 12 passed, 5 failed
* mips: 4 total, 1 passed, 3 failed
* parisc: 2 total, 2 passed, 0 failed
* powerpc: 5 total, 2 passed, 3 failed
* riscv: 5 total, 5 passed, 0 failed
* s390: 5 total, 2 passed, 3 failed
* sh: 2 total, 0 passed, 2 failed
* sparc: 2 total, 2 passed, 0 failed
* x86_64: 20 total, 20 passed, 0 failed
## Test suites summary
* fwts
* kunit
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-cap_bounds-tests
* ltp-commands
* ltp-commands-tests
* ltp-containers
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests
* ltp-fcntl-locktests-tests
* ltp-filecaps
* ltp-filecaps-tests
* ltp-fs
* ltp-fs-tests
* ltp-fs_bind
* ltp-fs_bind-tests
* ltp-fs_perms_simple
* ltp-fs_perms_simple-tests
* ltp-fsx
* ltp-fsx-tests
* ltp-hugetlb
* ltp-hugetlb-tests
* ltp-io
* ltp-io-tests
* ltp-ipc
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* packetdrill
* perf
* rcutorture
* ssuite
* v4l2-compliance
* vdso
--
Linaro LKFT
https://lkft.linaro.org
Quoted 24 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.17.14 release. There are 772 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 Thu, 09 Jun 2022 16:48:02 +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.14-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.
Quoted 8 lines
Regressions found on
qemu_x86_64:
- kunit/kasan [1]Regressions found on
qemu_i386:
- kunit/kfence [2]
- kunit/test_out_of_bounds_readWe will bisect and let you know more details about this reported problem.
The bisect script pointed me to this commit and reverted and tested and confirmed.
commit 1883088ed4a0d5cc9cea500ca4e89a354ab32c11
Author: Jia-Ju Bai <[email protected]> Date: Fri May 27 23:28:18 2022 +0800
md: bcache: check the return value of kzalloc() in detached_dev_do_request()
commit 40f567bbb3b0639d2ec7d1c6ad4b1b018f80cf19 upstream.
The function kzalloc() in detached_dev_do_request() can fail, so its return value should be checked.
bcache devices")
drivers/md/bcache/request.c +0 -0
@@ -1107,6 +1107,12 @@ static void detached_dev_do_request(struct
bcache_device *d, struct bio *bio,
* which would call closure_get(&dc->disk.cl)
*/
ddip = kzalloc(sizeof(struct detached_dev_io_private), GFP_NOIO);
+ if (!ddip) {
+ bio->bi_status = BLK_STS_RESOURCE;
+ bio->bi_end_io(bio);
+ return;
+ }
+
ddip->d = d;
/* Count on the bcache device */
ddip->orig_bdev = orig_bdev;Quoted 108 lines
[1] https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.17.y/build/v5.17.13-773-gd0f9b2818e1e/testrun/10038101/suite/kunit/test/kasan/details/
[2] https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.17.y/build/v5.17.13-773-gd0f9b2818e1e/testrun/10038215/suite/kunit/test/kfence/details/## Build
* kernel: 5.17.14-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.17.y
* git commit:d0f9b2818e1e4d43847e10d6e5310a0c653cb18f
* git describe: v5.17.13-773-gd0f9b2818e1e
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.17.y/build/v5.17.13-773-gd0f9b2818e1e## Test Regressions (compared to v5.17.11-188-g8eb69e8f0d45) Regressions found on
qemu_x86_64:
- kunit/kasan [1]Regressions found on
qemu_i386:
- kunit/kfence [2]
- kunit/test_out_of_bounds_read## Metric Regressions (compared to v5.17.11-188-g8eb69e8f0d45) No metric regressions found.
## Test Fixes (compared to v5.17.11-188-g8eb69e8f0d45) No test fixes found.
## Metric Fixes (compared to v5.17.11-188-g8eb69e8f0d45) No metric fixes found.
## Test result summary
total: 134591, pass: 121555, fail: 447, skip: 11730, xfail: 859## Build Summary
* arm: 17 total, 14 passed, 3 failed
* arm64: 20 total, 20 passed, 0 failed
* i386: 17 total, 12 passed, 5 failed
* mips: 4 total, 1 passed, 3 failed
* parisc: 2 total, 2 passed, 0 failed
* powerpc: 5 total, 2 passed, 3 failed
* riscv: 5 total, 5 passed, 0 failed
* s390: 5 total, 2 passed, 3 failed
* sh: 2 total, 0 passed, 2 failed
* sparc: 2 total, 2 passed, 0 failed
*x86_64: 20 total, 20 passed, 0 failed## Test suites summary
* fwts
* kunit
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-cap_bounds-tests
* ltp-commands
* ltp-commands-tests
* ltp-containers
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests
* ltp-fcntl-locktests-tests
* ltp-filecaps
* ltp-filecaps-tests
* ltp-fs
* ltp-fs-tests
* ltp-fs_bind
* ltp-fs_bind-tests
* ltp-fs_perms_simple
* ltp-fs_perms_simple-tests
* ltp-fsx
* ltp-fsx-tests
* ltp-hugetlb
* ltp-hugetlb-tests
* ltp-io
* ltp-io-tests
* ltp-ipc
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* packetdrill
* perf
* rcutorture
* ssuite
* v4l2-compliance
* vdso--
Linaro LKFT
https://lkft.linaro.org
Quoted 28 lines · Naresh Kamboju
Quoted 27 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.17.14 release. There are 772 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 Thu, 09 Jun 2022 16:48:02 +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.14-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.
Regressions found on
qemu_x86_64:
- kunit/kasan [1]
Quoted 9 lines
Quoted 5 lines
Regressions found on
qemu_i386:
- kunit/kfence [2]
- kunit/test_out_of_bounds_readWe will bisect and let you know more details about this reported problem.
The bisect script pointed me to this commit and reverted and tested and confirmed.
I see the same error messages after enabling CONFIG_KFENCE_KUNIT_TEST, but it doesn't go away after removing the patch below. That patch also seems to be completely unrelated to the error.
I also see the same problem in the mainline kernel. I suspect that something is wrong with CONFIG_KFENCE_KUNIT_TEST.
Guenter
Quoted 149 lines
commit
1883088ed4a0d5cc9cea500ca4e89a354ab32c11Author: Jia-Ju Bai <[email protected]> Date: Fri May 27 23:28:18 2022 +0800md: bcache: check the return value of
kzalloc()indetached_dev_do_request()commit
40f567bbb3b0639d2ec7d1c6ad4b1b018f80cf19upstream.The function
kzalloc()indetached_dev_do_request()can fail, so its return value should be checked.Fixes bc082a55d25c ("bcache: fix inaccurate io state for detachedbcache devices")
Reported-by TOTE Robot <[email protected]>Signed-off-by Jia-Ju Bai <[email protected]>Signed-off-by Coly Li <[email protected]>Signed-off-by Jens Axboe <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>drivers/md/bcache/request.c +6
-0@@ -1107,6 +1107,12 @@ static void detached_dev_do_request(structbcache_device *d, struct bio *bio, * which would call closure_get(&dc->disk.cl) */ ddip =kzalloc (sizeof (struct detached_dev_io_private ),GFP_NOIO ); +if (!ddip) { + bio->bi_status =BLK_STS_RESOURCE ; + bio->bi_end_io (bio); +return ; + } + ddip->d = d;/* Count on the bcache device */ ddip->orig_bdev = orig_bdev;Quoted 108 lines
[1] https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.17.y/build/v5.17.13-773-gd0f9b2818e1e/testrun/10038101/suite/kunit/test/kasan/details/
[2] https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.17.y/build/v5.17.13-773-gd0f9b2818e1e/testrun/10038215/suite/kunit/test/kfence/details/## Build
* kernel: 5.17.14-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.17.y
* git commit:d0f9b2818e1e4d43847e10d6e5310a0c653cb18f
* git describe: v5.17.13-773-gd0f9b2818e1e
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.17.y/build/v5.17.13-773-gd0f9b2818e1e## Test Regressions (compared to v5.17.11-188-g8eb69e8f0d45) Regressions found on
qemu_x86_64:
- kunit/kasan [1]Regressions found on
qemu_i386:
- kunit/kfence [2]
- kunit/test_out_of_bounds_read## Metric Regressions (compared to v5.17.11-188-g8eb69e8f0d45) No metric regressions found.
## Test Fixes (compared to v5.17.11-188-g8eb69e8f0d45) No test fixes found.
## Metric Fixes (compared to v5.17.11-188-g8eb69e8f0d45) No metric fixes found.
## Test result summary
total: 134591, pass: 121555, fail: 447, skip: 11730, xfail: 859## Build Summary
* arm: 17 total, 14 passed, 3 failed
* arm64: 20 total, 20 passed, 0 failed
* i386: 17 total, 12 passed, 5 failed
* mips: 4 total, 1 passed, 3 failed
* parisc: 2 total, 2 passed, 0 failed
* powerpc: 5 total, 2 passed, 3 failed
* riscv: 5 total, 5 passed, 0 failed
* s390: 5 total, 2 passed, 3 failed
* sh: 2 total, 0 passed, 2 failed
* sparc: 2 total, 2 passed, 0 failed
*x86_64: 20 total, 20 passed, 0 failed## Test suites summary
* fwts
* kunit
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-cap_bounds-tests
* ltp-commands
* ltp-commands-tests
* ltp-containers
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests
* ltp-fcntl-locktests-tests
* ltp-filecaps
* ltp-filecaps-tests
* ltp-fs
* ltp-fs-tests
* ltp-fs_bind
* ltp-fs_bind-tests
* ltp-fs_perms_simple
* ltp-fs_perms_simple-tests
* ltp-fsx
* ltp-fsx-tests
* ltp-hugetlb
* ltp-hugetlb-tests
* ltp-io
* ltp-io-tests
* ltp-ipc
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* packetdrill
* perf
* rcutorture
* ssuite
* v4l2-compliance
* vdso--
Linaro LKFT
https://lkft.linaro.org
Hi!
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
This is the start of the stable review cycle for the 5.17.14 release. There are 772 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 Thu, 09 Jun 2022 16:48:02 +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.14-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.
...
Quoted 4 lines
Quoted 1 line
We will bisect and let you know more details about this reported problem.
The bisect script pointed me to this commit and reverted and tested and confirmed.
Can you add some printks into that? Because I'm pretty sure this patch does not break anything. (It should not fix much, either.)
Quoted 11 lines
commit
1883088ed4a0d5cc9cea500ca4e89a354ab32c11
Author: Jia-Ju Bai <[email protected]>md: bcache: check the return value of
kzalloc()indetached_dev_do_request()commit
40f567bbb3b0639d2ec7d1c6ad4b1b018f80cf19upstream.The function
kzalloc()indetached_dev_do_request()can fail, so its return value should be checked.Fixes bc082a55d25c ("bcache: fix inaccurate io state for detached
...
Quoted 14 lines
+++
b/drivers/md/bcache/request.c(quoted diff) +6
-0@@ -1107,6 +1107,12 @@ static void detached_dev_do_request(struct bcache_device *d, struct bio *bio, * which would call closure_get(&dc->disk.cl) */ ddip = kzalloc(sizeof(struct detached_dev_io_private), GFP_NOIO); + if (!ddip) { + bio->bi_status = BLK_STS_RESOURCE; + bio->bi_end_io(bio); + return; + } + ddip->d = d; /* Count on the bcache device */
Quoted 2 lines
ddip->orig_bdev = orig_bdev;
So... for patch to make any difference, memory allocation has to fail and ddip has to be NULL.
Before the patch, it would oops in "ddip->d = d;". With the patch, you do some kind of error handling. Even if it is buggy, it should not do more harm than immediate oops.
Best regards,
Pavel
Signature · 2 lines
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Quoted 62 lines
2022年6月18日 18:49,Pavel Machek <[email protected]> 写道:
Hi!
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
This is the start of the stable review cycle for the 5.17.14 release. There are 772 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 Thu, 09 Jun 2022 16:48:02 +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.14-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....
Quoted 4 lines
Quoted 1 line
We will bisect and let you know more details about this reported problem.
The bisect script pointed me to this commit and reverted and tested and confirmed.
Can you add some printks into that? Because I'm pretty sure this patch does not break anything. (It should not fix much, either.)
Quoted 11 lines
commit
1883088ed4a0d5cc9cea500ca4e89a354ab32c11
Author: Jia-Ju Bai <[email protected]>md: bcache: check the return value of
kzalloc()indetached_dev_do_request()commit
40f567bbb3b0639d2ec7d1c6ad4b1b018f80cf19upstream.The function
kzalloc()indetached_dev_do_request()can fail, so its return value should be checked.Fixes bc082a55d25c ("bcache: fix inaccurate io state for detached...
Quoted 14 lines
+++
b/drivers/md/bcache/request.c(quoted diff) +6
-0@@ -1107,6 +1107,12 @@ static void detached_dev_do_request(struct bcache_device *d, struct bio *bio, * which would call closure_get(&dc->disk.cl) */ ddip = kzalloc(sizeof(struct detached_dev_io_private), GFP_NOIO); + if (!ddip) { + bio->bi_status = BLK_STS_RESOURCE; + bio->bi_end_io(bio); + return; + } + ddip->d = d; /* Count on the bcache device */Quoted 2 lines
ddip->orig_bdev = orig_bdev;So... for patch to make any difference, memory allocation has to fail and ddip has to be NULL.
Quoted 3 lines
Before the patch, it would oops in "
ddip->d= d;". With the patch, you do some kind of error handling. Even if it is buggy, it should not do more harm than immediate oops.
I just receive this single email and don’t have any idea for the context and what the problem is. Where can I see the whole conversation?
BTW, maybe commit 7d6b902ea0e0 (“bcache: memset on stack variables in bch_btree_check() and bch_sectors_dirty_init()”) is necessary, how about trying to add it in?
Coly Li
Hi!
Quoted 23 lines
Quoted 23 lines
Quoted 1 line
Fixes bc082a55d25c ("bcache: fix inaccurate io state for detached...
Quoted 14 lines
+++
b/drivers/md/bcache/request.c(quoted diff) +6
-0@@ -1107,6 +1107,12 @@ static void detached_dev_do_request(struct bcache_device *d, struct bio *bio, * which would call closure_get(&dc->disk.cl) */ ddip = kzalloc(sizeof(struct detached_dev_io_private), GFP_NOIO); + if (!ddip) { + bio->bi_status = BLK_STS_RESOURCE; + bio->bi_end_io(bio); + return; + } + ddip->d = d; /* Count on the bcache device */Quoted 2 lines
ddip->orig_bdev = orig_bdev;So... for patch to make any difference, memory allocation has to fail and ddip has to be NULL.
Quoted 6 lines
Quoted 3 lines
Before the patch, it would oops in "
ddip->d= d;". With the patch, you do some kind of error handling. Even if it is buggy, it should not do more harm than immediate oops.I just receive this single email and don’t have any idea for the context and what the problem is. Where can I see the whole conversation?
Discussion happened on [email protected] mailing lists, archives should be easily available. Copy went to lkml, too.
Best regards,
Pavel
Signature · 1 line
People of Russia, stop Putin before his war on Ukraine escalates.
Quoted 33 lines
2022年6月18日 19:37,Pavel Machek <[email protected]> 写道:
Hi!
Quoted 27 lines
Quoted 26 lines
Quoted 1 line
Fixes bc082a55d25c ("bcache: fix inaccurate io state for detached...
Quoted 14 lines
+++
b/drivers/md/bcache/request.c(quoted diff) +6
-0@@ -1107,6 +1107,12 @@ static void detached_dev_do_request(struct bcache_device *d, struct bio *bio, * which would call closure_get(&dc->disk.cl) */ ddip = kzalloc(sizeof(struct detached_dev_io_private), GFP_NOIO); + if (!ddip) { + bio->bi_status = BLK_STS_RESOURCE; + bio->bi_end_io(bio); + return; + } + ddip->d = d; /* Count on the bcache device */Quoted 2 lines
ddip->orig_bdev = orig_bdev;So... for patch to make any difference, memory allocation has to fail and ddip has to be NULL.
Before the patch, it would oops in "
ddip->d= d;". With the patch, you do some kind of error handling. Even if it is buggy, it should not do more harm than immediate oops.
Quoted 5 lines
Quoted 2 lines
I just receive this single email and don’t have any idea for the context and what the problem is. Where can I see the whole conversation?
Discussion happened on [email protected] mailing lists, archives should be easily available. Copy went to lkml, too.
Hi Pavel and Greg,
Thanks for the hint, I see the context. I cannot tell the direct reason of the kfence regression, but it is worthy to have this patch in,
- commit 7d6b902ea0e0 ("bcache: memset on stack variables in bch_btree_check() and bch_sectors_dirty_init()”)
I am not sure whether it is directly related to the kfence issue, it corrects potential unexpected stack state in some condition. Hope it may help a bit.
Thanks.
Coly Li
Greg Kroah-Hartman
maintainerQuoted 39 lines · Coly Li
Quoted 33 lines
2022年6月18日 19:37,Pavel Machek <[email protected]> 写道:
Hi!
Quoted 27 lines
Quoted 26 lines
Quoted 1 line
Fixes bc082a55d25c ("bcache: fix inaccurate io state for detached...
Quoted 14 lines
+++
b/drivers/md/bcache/request.c(quoted diff) +6
-0@@ -1107,6 +1107,12 @@ static void detached_dev_do_request(struct bcache_device *d, struct bio *bio, * which would call closure_get(&dc->disk.cl) */ ddip = kzalloc(sizeof(struct detached_dev_io_private), GFP_NOIO); + if (!ddip) { + bio->bi_status = BLK_STS_RESOURCE; + bio->bi_end_io(bio); + return; + } + ddip->d = d; /* Count on the bcache device */Quoted 2 lines
ddip->orig_bdev = orig_bdev;So... for patch to make any difference, memory allocation has to fail and ddip has to be NULL.
Before the patch, it would oops in "
ddip->d= d;". With the patch, you do some kind of error handling. Even if it is buggy, it should not do more harm than immediate oops.Quoted 5 lines
Quoted 2 lines
I just receive this single email and don’t have any idea for the context and what the problem is. Where can I see the whole conversation?
Discussion happened on [email protected] mailing lists, archives should be easily available. Copy went to lkml, too.
Quoted 6 lines
Hi Pavel and Greg,
Thanks for the hint, I see the context. I cannot tell the direct reason of the kfence regression, but it is worthy to have this patch in,
- commit7d6b902ea0e0("bcache: memset on stack variables inbch_btree_check()and bch_sectors_dirty_init()”)I am not sure whether it is directly related to the kfence issue, it corrects potential unexpected stack state in some condition. Hope it may help a bit.
Added where?
confused,
greg k-h
Quoted 46 lines
2022年6月20日 18:10,Greg Kroah-Hartman <[email protected]> 写道:
Quoted 41 lines · Coly Li
Quoted 33 lines
2022年6月18日 19:37,Pavel Machek <[email protected]> 写道:
Hi!
Quoted 27 lines
Quoted 26 lines
Quoted 1 line
Fixes bc082a55d25c ("bcache: fix inaccurate io state for detached...
Quoted 14 lines
+++
b/drivers/md/bcache/request.c(quoted diff) +6
-0@@ -1107,6 +1107,12 @@ static void detached_dev_do_request(struct bcache_device *d, struct bio *bio, * which would call closure_get(&dc->disk.cl) */ ddip = kzalloc(sizeof(struct detached_dev_io_private), GFP_NOIO); + if (!ddip) { + bio->bi_status = BLK_STS_RESOURCE; + bio->bi_end_io(bio); + return; + } + ddip->d = d; /* Count on the bcache device */Quoted 2 lines
ddip->orig_bdev = orig_bdev;So... for patch to make any difference, memory allocation has to fail and ddip has to be NULL.
Before the patch, it would oops in "
ddip->d= d;". With the patch, you do some kind of error handling. Even if it is buggy, it should not do more harm than immediate oops.Quoted 5 lines
Quoted 2 lines
I just receive this single email and don’t have any idea for the context and what the problem is. Where can I see the whole conversation?
Discussion happened on [email protected] mailing lists, archives should be easily available. Copy went to lkml, too.
Hi Pavel and Greg,
Quoted 8 lines
Quoted 4 lines
Thanks for the hint, I see the context. I cannot tell the direct reason of the kfence regression, but it is worthy to have this patch in,
- commit7d6b902ea0e0("bcache: memset on stack variables inbch_btree_check()and bch_sectors_dirty_init()”)I am not sure whether it is directly related to the kfence issue, it corrects potential unexpected stack state in some condition. Hope it may help a bit.
Added where?
confused,
I will post the patch to stable list for specific version. Thanks.
Coly Li
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.17.14 release. There are 772 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 Thu, 09 Jun 2022 16:48:02 +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.14-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.14 release. There are 772 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 Thu, 09 Jun 2022 16:48:02 +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.14-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
5.17.14-rc1 Successfully Compiled and booted on my Raspberry PI 4b (8g) (bcm2711)
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.17.14 release. There are 772 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 Thu, 09 Jun 2022 16:48:02 +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.14-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
Regression on RISC-V RV64 (HiFive Unmatched).
An Oops occurs when an NFS file system is mounted.
[ 98.244615] FS-Cache: Loaded
[ 99.311566] NFS: Registering the id_resolver key type
[ 99.311621] Key type id_resolver registered
[ 99.311626] Key type id_legacy registered
[ 99.469053] Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000000
[ 99.479039] Oops [#1]
[ 99.481246] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace fscache netfs nvme_fabrics sunrpc binfmt_misc nls_iso8859_1 da9063_onkey lm90 at24 uio_pdrv_genirq uio sch_fq_codel dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua ipmi_devintf ipmi_msghandler drm backlight ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear rtc_da9063 da9063_regulator mscc macsec nvme macb xhci_pci nvme_core xhci_pci_renesas i2c_ocores phylink [ 99.532427] CPU: 2 PID: 889 Comm: mount.nfs Not tainted 5.17.13 #1
[ 99.538572] Hardware name: SiFive HiFive Unmatched A00 (DT)
[ 99.544133] epc : nfs_fattr_init+0x1e/0x48 [nfs]
[ 99.549059] ra : _nfs41_proc_get_locations+0xb4/0x128 [nfsv4]
[ 99.555877] epc : ffffffff02332e76 ra : ffffffff023c076c sp : ffffffc894793960
[ 99.563084] gp : ffffffff81a2ed00 tp : ffffffd896180000 t0 : ffffffd887720000
[ 99.570294] t1 : ffffffff81a9c110 t2 : ffffffff81003c04 s0 : ffffffc894793970
[ 99.577503] s1 : ffffffd887700000 a0 : 0000000000000000 a1 : ffffffd883de3d80
[ 99.584721] a2 : ffffffd887700000 a3 : ffffffc704608a00 a4 : ffffffff0236aa28
[ 99.591924] a5 : ffffffff02410cf8 a6 : ffffffff0240fc00 a7 : 0000000000000006
[ 99.599134] s2 : ffffffd885df6000 s3 : ffffffc8947939c8 s4 : ffffffc894793998
[ 99.606343] s5 : ffffffd881a9f000 s6 : ffffffc704608a00 s7 : ffffffff021c7db8
[ 99.613552] s8 : ffffffff0240fd50 s9 : 0000000000000cc0 s10: 0000003fd7d2e260
[ 99.620762] s11: 0000000000016700 t3 : 0000000000000020 t4 : 0000000000000001
[ 99.627971] t5 : ffffffdbffdde088 t6 : ffffffdbffdde0a8
[ 99.633266] status: 0000000200000120 badaddr: 0000000000000000 cause: 000000000000000f
[ 99.641236] ---[ end trace 0000000000000000 ]---
Manually bisected to this commit:
NFSv4: Fix free of uninitialized nfs4_label on referral lookup.
Greg Kroah-Hartman
maintainerQuoted 68 lines · Ron Economos
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.17.14 release. There are 772 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 Thu, 09 Jun 2022 16:48:02 +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.14-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
Regression on RISC-V RV64 (HiFive Unmatched).
An Oops occurs when an NFS file system is mounted.
[ 98.244615] FS-Cache: Loaded
[ 99.311566] NFS: Registering theid_resolverkey type
[ 99.311621] Key typeid_resolverregistered
[ 99.311626] Key typeid_legacyregistered
[ 99.469053] Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000000
[ 99.479039] Oops [#1]
[ 99.481246] Modules linked in:rpcsec_gss_krb5auth_rpcgssnfsv4 nfs lockd grace fscache netfsnvme_fabricssunrpcbinfmt_miscnls_iso8859_1da9063_onkeylm90 at24uio_pdrv_genirquiosch_fq_codeldm_multipathscsi_dh_rdacscsi_dh_emcscsi_dh_aluaipmi_devintfipmi_msghandlerdrm backlightip_tablesx_tablesautofs4 btrfsblake2b_genericzstd_compressraid10 raid456async_raid6_recovasync_memcpyasync_pqasync_xorasync_txxorraid6_pqlibcrc32c raid1 raid0 multipath linearrtc_da9063da9063_regulatormscc macsec nvme macbxhci_pcinvme_corexhci_pci_renesasi2c_ocoresphylink
[ 99.532427] CPU: 2 PID: 889 Comm: mount.nfs Not tainted 5.17.13 #1 [ 99.538572] Hardware name: SiFive HiFive Unmatched A00 (DT)
[ 99.544133] epc :nfs_fattr_init+0x1e/0x48[nfs]
[ 99.549059] ra :_nfs41_proc_get_locations+0xb4/0x128[nfsv4] [ 99.555877] epc :ffffffff02332e76ra :ffffffff023c076csp :ffffffc894793960
[ 99.563084] gp :ffffffff81a2ed00tp :ffffffd896180000t0 :ffffffd887720000
[ 99.570294] t1 :ffffffff81a9c110t2 :ffffffff81003c04s0 :ffffffc894793970
[ 99.577503] s1 :ffffffd887700000a0 : 0000000000000000 a1 :ffffffd883de3d80
[ 99.584721] a2 :ffffffd887700000a3 :ffffffc704608a00a4 :ffffffff0236aa28
[ 99.591924] a5 :ffffffff02410cf8a6 :ffffffff0240fc00a7 :
0000000000000006
[ 99.599134] s2 :ffffffd885df6000s3 :ffffffc8947939c8s4 :ffffffc894793998
[ 99.606343] s5 :ffffffd881a9f000s6 :ffffffc704608a00s7 :ffffffff021c7db8
[ 99.613552] s8 :ffffffff0240fd50s9 :0000000000000cc0s10:0000003fd7d2e260
[ 99.620762] s11: 0000000000016700 t3 : 0000000000000020 t4 :
0000000000000001
[ 99.627971] t5 :ffffffdbffdde088t6 :ffffffdbffdde0a8
[ 99.633266] status: 0000000200000120 badaddr: 0000000000000000 cause:000000000000000f
[ 99.641236] ---[ end trace 0000000000000000 ]---
Quoted 6 lines
Manually bisected to this commit:
NFSv4: Fix free of uninitialized
nfs4_labelon referral lookup.
That's odd you see this here on 5.17, but NOT on 5.18 with the same commit merged there. I'll drop this from 5.17 and as this will probably be the last (or next to last) 5.17 kernel release, not worry too much about it.
thanks,
greg k-h
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.17.14 release. There are 772 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 Thu, 09 Jun 2022 16:48:02 +0000. Anything received after that time might be too late.
Build results:
total: 158 pass: 158 fail: 0 Qemu test results: total: 489 pass: 489 fail: 0
I see a new boot warning in some arm qemu tests, but that is related to enabling CONFIG_KFENCE and not a new problem. v5.17.y and v5.18.y are affected.
[ 8.157727] ------------[ cut here ]------------ [ 8.157843] WARNING: CPU: 0 PID: 0 at kernel/smp.c:894 smp_call_function_many_cond+0x38c/0x3a4 [ 8.158289] Modules linked in: [ 8.158489] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.17.14-rc1-00773-gd0f9b2818e1e #1 [ 8.158564] Hardware name: ARM-Versatile Express [ 8.158730] unwind_backtrace from show_stack+0x10/0x14 [ 8.158802] show_stack from dump_stack_lvl+0x50/0x6c [ 8.158835] dump_stack_lvl from __warn+0xd0/0x19c [ 8.158863] __warn from warn_slowpath_fmt+0x5c/0xb4 [ 8.158890] warn_slowpath_fmt from smp_call_function_many_cond+0x38c/0x3a4 [ 8.158919] smp_call_function_many_cond from smp_call_function+0x3c/0x50 [ 8.158947] smp_call_function from set_memory_valid+0x74/0x94 [ 8.158975] set_memory_valid from kfence_guarded_free+0x280/0x4b4 [ 8.159005] kfence_guarded_free from kmem_cache_free+0x2f4/0x394 [ 8.159032] kmem_cache_free from rcu_core+0x358/0xc34 [ 8.159062] rcu_core from __do_softirq+0xf0/0x41c [ 8.159101] __do_softirq from irq_exit+0xa4/0xd4 [ 8.159127] irq_exit from __irq_svc+0x50/0x68
Guenter
Hi Guenter,
Quoted 16 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.17.14 release. There are 772 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 Thu, 09 Jun 2022 16:48:02 +0000. Anything received after that time might be too late.
Build results:
total: 158 pass: 158 fail: 0 Qemu test results: total: 489 pass: 489 fail: 0
Quoted 5 lines
Tested-by Guenter Roeck <[email protected]>I see a new boot warning in some arm qemu tests, but that is related to enabling
CONFIG_KFENCEand not a new problem. v5.17.y and v5.18.y are affected.
In LKFT we have been noticing this warning on the mainline, Linux-next, 5.18 and 5.17 on qemu-arm, and on x15 devices intermittently.
Quoted 19 lines
[ 8.157727] ------------[ cut here ]------------ [ 8.157843] WARNING: CPU: 0 PID: 0 at kernel/smp.c:894 smp_call_function_many_cond+0x38c/0x3a4 [ 8.158289] Modules linked in: [ 8.158489] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.17.14-rc1-00773-gd0f9b2818e1e #1 [ 8.158564] Hardware name: ARM-Versatile Express [ 8.158730] unwind_backtrace from show_stack+0x10/0x14 [ 8.158802] show_stack from dump_stack_lvl+0x50/0x6c [ 8.158835] dump_stack_lvl from __warn+0xd0/0x19c [ 8.158863] __warn from warn_slowpath_fmt+0x5c/0xb4 [ 8.158890] warn_slowpath_fmt from smp_call_function_many_cond+0x38c/0x3a4 [ 8.158919] smp_call_function_many_cond from smp_call_function+0x3c/0x50 [ 8.158947] smp_call_function from set_memory_valid+0x74/0x94 [ 8.158975] set_memory_valid from kfence_guarded_free+0x280/0x4b4 [ 8.159005] kfence_guarded_free from kmem_cache_free+0x2f4/0x394 [ 8.159032] kmem_cache_free from rcu_core+0x358/0xc34 [ 8.159062] rcu_core from __do_softirq+0xf0/0x41c [ 8.159101] __do_softirq from irq_exit+0xa4/0xd4 [ 8.159127] irq_exit from __irq_svc+0x50/0x68
Quoted 1 line
Guenter
[ 0.000000] Linux version 5.19.0-rc1 (tuxmake@tuxmake) (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP @1654710061 [ 0.000000] CPU: ARMv7 Processor [412fc0f2] revision 2 (ARMv7), cr=10c5387d [ 0.000000] CPU: div instructions available: patching division code <trim> [ 0.000000] kfence: initialized - using 2097152 bytes for 255 objects at 0x(ptrval)-0x(ptrval) [ 0.000000] ------------[ cut here ]------------ [ 0.000000] WARNING: CPU: 0 PID: 0 at lib/refcount.c:25 kobject_get+0x9c/0xa0 [ 0.000000] refcount_t: addition on 0; use-after-free. [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.19.0-rc1 #1 [ 0.000000] Hardware name: Generic DRA74X (Flattened Device Tree) [ 0.000000] unwind_backtrace from show_stack+0x18/0x1c [ 0.000000] show_stack from dump_stack_lvl+0x58/0x70 [ 0.000000] dump_stack_lvl from __warn+0xd4/0x14c [ 0.000000] __warn from warn_slowpath_fmt+0x98/0xbc [ 0.000000] warn_slowpath_fmt from kobject_get+0x9c/0xa0 [ 0.000000] kobject_get from of_node_get+0x1c/0x24 [ 0.000000] of_node_get from of_fwnode_get+0x3c/0x48 [ 0.000000] of_fwnode_get from fwnode_full_name_string+0x34/0xa0 [ 0.000000] fwnode_full_name_string from device_node_string+0x5fc/0x6c8 [ 0.000000] device_node_string from pointer+0x38c/0x5b0 [ 0.000000] pointer from vsnprintf+0x22c/0x3cc [ 0.000000] vsnprintf from vprintk_store+0x114/0x43c [ 0.000000] vprintk_store from vprintk_emit+0x78/0x2ac [ 0.000000] vprintk_emit from vprintk_default+0x28/0x30 [ 0.000000] vprintk_default from _printk+0x30/0x54 [ 0.000000] _printk from of_node_release+0x124/0x12c [ 0.000000] of_node_release from kobject_put+0xc4/0x294 [ 0.000000] kobject_put from ti_dt_clocks_register+0x284/0x32c [ 0.000000] ti_dt_clocks_register from dra7xx_dt_clk_init+0x18/0x11c [ 0.000000] dra7xx_dt_clk_init from omap5_realtime_timer_init+0x10/0x21c [ 0.000000] omap5_realtime_timer_init from start_kernel+0x558/0x718 [ 0.000000] start_kernel from 0x0 [ 0.000000] ---[ end trace 0000000000000000 ]--- [ 0.000000] ------------[ cut here ]------------ [ 0.000000] WARNING: CPU: 0 PID: 0 at lib/refcount.c:28 fwnode_full_name_string+0x8c/0xa0 [ 0.000000] refcount_t: underflow; use-after-free. [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 5.19.0-rc1 #1 [ 0.000000] Hardware name: Generic DRA74X (Flattened Device Tree) <trim> [ 0.000000] OF: ERROR: Bad of_node_put() on /ocp/interconnect@4a000000/segment@0/target-module@8000/cm_core@0/clock@c00/clock@0 [ 0.000000] ------------[ cut here ]------------ <trim> [ 7.246032] ------------[ cut here ]------------ [ 7.246063] WARNING: CPU: 1 PID: 0 at kernel/smp.c:913 smp_call_function_many_cond+0x3a0/0x3b0 [ 7.259399] Modules linked in: [ 7.262481] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G W 5.19.0-rc1 #1 [ 7.270202] Hardware name: Generic DRA74X (Flattened Device Tree) [ 7.276336] unwind_backtrace from show_stack+0x18/0x1c [ 7.281585] show_stack from dump_stack_lvl+0x58/0x70 [ 7.286682] dump_stack_lvl from __warn+0xd4/0x14c [ 7.291503] __warn from warn_slowpath_fmt+0x64/0xbc [ 7.296508] warn_slowpath_fmt from smp_call_function_many_cond+0x3a0/0x3b0 [ 7.303527] smp_call_function_many_cond from smp_call_function+0x34/0x3c [ 7.310363] smp_call_function from set_memory_valid+0x7c/0x9c [ 7.316223] set_memory_valid from kfence_guarded_free+0x284/0x4b0 [ 7.322448] kfence_guarded_free from kmem_cache_free+0x3a0/0x484 [ 7.328582] kmem_cache_free from rcu_core+0x2c0/0x964 [ 7.333770] rcu_core from __do_softirq+0x168/0x400 [ 7.338684] __do_softirq from irq_exit+0xc0/0xf0 [ 7.343414] irq_exit from call_with_stack+0x18/0x20 [ 7.348419] call_with_stack from __irq_svc+0x9c/0xb8 [ 7.353515] Exception stack(0xf0045f40 to 0xf0045f88) [ 7.358581] 5f40: 00001770 00000000 fe600000 00000000 c2165260 c29e1500 c1f09f50 c1f09fb0 [ 7.366821] 5f60: c1e95b28 c2163ad4 00000000 00000000 00000000 f0045f90 c0335434 c030983c [ 7.375030] 5f80: 600e0013 ffffffff [ 7.378540] __irq_svc from arch_cpu_idle+0x28/0x44 [ 7.383453] arch_cpu_idle from default_idle_call+0x50/0xd0 [ 7.389068] default_idle_call from do_idle+0x224/0x2cc [ 7.394348] do_idle from cpu_startup_entry+0x20/0x24 [ 7.399414] cpu_startup_entry from secondary_start_kernel+0x13c/0x15c [ 7.405975] secondary_start_kernel from 0x80302180 [ 7.410919] ---[ end trace 0000000000000000 ]---
you may refer to this warning log on the mainline.
- Naresh