linux-stable.git/drivers, branch v5.19.4

scsi: ufs: ufs-mediatek: Fix build error and type mismatch

2022-08-25T09:45:54+00:00

commit f54912b228a8df6c0133e31bc75628677bb8c6e5 upstream.

If CONFIG_PM_SLEEP is not set.

make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-, will fail:

drivers/ufs/host/ufs-mediatek.c: In function ‘ufs_mtk_vreg_fix_vcc’:
drivers/ufs/host/ufs-mediatek.c:688:46: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 4 has type ‘long unsigned int’ [-Wformat=]
    snprintf(vcc_name, MAX_VCC_NAME, "vcc-opt%u", res.a1);
                                             ~^   ~~~~~~
                                             %lu
drivers/ufs/host/ufs-mediatek.c: In function ‘ufs_mtk_system_suspend’:
drivers/ufs/host/ufs-mediatek.c:1371:8: error: implicit declaration of function ‘ufshcd_system_suspend’; did you mean ‘ufs_mtk_system_suspend’? [-Werror=implicit-function-declaration]
  ret = ufshcd_system_suspend(dev);
        ^~~~~~~~~~~~~~~~~~~~~
        ufs_mtk_system_suspend
drivers/ufs/host/ufs-mediatek.c: In function ‘ufs_mtk_system_resume’:
drivers/ufs/host/ufs-mediatek.c:1386:9: error: implicit declaration of function ‘ufshcd_system_resume’; did you mean ‘ufs_mtk_system_resume’? [-Werror=implicit-function-declaration]
  return ufshcd_system_resume(dev);
         ^~~~~~~~~~~~~~~~~~~~
         ufs_mtk_system_resume
cc1: some warnings being treated as errors

The declaration of func "ufshcd_system_suspend()" depends on
CONFIG_PM_SLEEP, so the function wrapper ufs_mtk_system_suspend() should
wrapped by CONFIG_PM_SLEEP too.

Link: https://lore.kernel.org/r/20220619115432.205504-1-renzhijie2@huawei.com
Fixes: 3fd23b8dfb54 ("scsi: ufs: ufs-mediatek: Fix the timing of configuring device regulators")
Reported-by: Hulk Robot 
Reviewed-by: Stanley Chu 
Signed-off-by: Ren Zhijie 
Signed-off-by: Martin K. Petersen 
[only take the suspend/resume portion of the commit - gregkh]
Signed-off-by: Greg Kroah-Hartman

video: fbdev: i740fb: Check the argument of i740_calc_vclk()

2022-08-25T09:45:53+00:00

[ Upstream commit 40bf722f8064f50200b8c4f8946cd625b441dda9 ]

Since the user can control the arguments of the ioctl() from the user
space, under special arguments that may result in a divide-by-zero bug.

If the user provides an improper 'pixclock' value that makes the argumet
of i740_calc_vclk() less than 'I740_RFREQ_FIX', it will cause a
divide-by-zero bug in:
    drivers/video/fbdev/i740fb.c:353 p_best = min(15, ilog2(I740_MAX_VCO_FREQ / (freq / I740_RFREQ_FIX)));

The following log can reveal it:

divide error: 0000 [#1] PREEMPT SMP KASAN PTI
RIP: 0010:i740_calc_vclk drivers/video/fbdev/i740fb.c:353 [inline]
RIP: 0010:i740fb_decode_var drivers/video/fbdev/i740fb.c:646 [inline]
RIP: 0010:i740fb_set_par+0x163f/0x3b70 drivers/video/fbdev/i740fb.c:742
Call Trace:
 fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1034
 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110
 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189

Fix this by checking the argument of i740_calc_vclk() first.

Signed-off-by: Zheyu Ma 
Signed-off-by: Helge Deller 
Signed-off-by: Sasha Levin

venus: pm_helpers: Fix warning in OPP during probe

2022-08-25T09:45:53+00:00

[ Upstream commit 1d95af02f23031c2e1cca7607c514b86ce85bc6e ]

Fix the following WARN triggered during Venus driver probe on
5.19.0-rc8-next-20220728:

 WARNING: CPU: 7 PID: 339 at drivers/opp/core.c:2471 dev_pm_opp_set_config+0x49c/0x610
 Modules linked in: qcom_spmi_adc5 rtc_pm8xxx qcom_spmi_adc_tm5 leds_qcom_lpg led_class_multicolor
  qcom_pon qcom_vadc_common venus_core(+) qcom_spmi_temp_alarm v4l2_mem2mem videobuf2_v4l2 msm(+)
  videobuf2_common crct10dif_ce spi_geni_qcom snd_soc_sm8250 i2c_qcom_geni gpu_sched
  snd_soc_qcom_common videodev qcom_q6v5_pas soundwire_qcom drm_dp_aux_bus qcom_stats
  drm_display_helper qcom_pil_info soundwire_bus snd_soc_lpass_va_macro mc qcom_q6v5
  phy_qcom_snps_femto_v2 qcom_rng snd_soc_lpass_macro_common snd_soc_lpass_wsa_macro
  lpass_gfm_sm8250 slimbus qcom_sysmon qcom_common qcom_glink_smem qmi_helpers
  qcom_wdt mdt_loader socinfo icc_osm_l3 display_connector
  drm_kms_helper qnoc_sm8250 drm fuse ip_tables x_tables ipv6
 CPU: 7 PID: 339 Comm: systemd-udevd Not tainted 5.19.0-rc8-next-20220728 #4
 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : dev_pm_opp_set_config+0x49c/0x610
 lr : dev_pm_opp_set_config+0x58/0x610
 sp : ffff8000093c3710
 x29: ffff8000093c3710 x28: ffffbca3959d82b8 x27: ffff8000093c3d00
 x26: ffffbca3959d8e08 x25: ffff4396cac98118 x24: ffff4396c0e24810
 x23: ffff4396c4272c40 x22: ffff4396c0e24810 x21: ffff8000093c3810
 x20: ffff4396cac36800 x19: ffff4396cac96800 x18: 0000000000000000
 x17: 0000000000000003 x16: ffffbca3f4edf198 x15: 0000001cba64a858
 x14: 0000000000000180 x13: 000000000000017e x12: 0000000000000000
 x11: 0000000000000002 x10: 0000000000000a60 x9 : ffff8000093c35c0
 x8 : ffff4396c4273700 x7 : ffff43983efca6c0 x6 : ffff43983efca640
 x5 : 00000000410fd0d0 x4 : ffff4396c4272c40 x3 : ffffbca3f5d1e008
 x2 : 0000000000000000 x1 : ffff4396c2421600 x0 : ffff4396cac96860
 Call trace:
  dev_pm_opp_set_config+0x49c/0x610
  devm_pm_opp_set_config+0x18/0x70
  vcodec_domains_get+0xb8/0x1638 [venus_core]
  core_get_v4+0x1d8/0x218 [venus_core]
  venus_probe+0xf4/0x468 [venus_core]
  platform_probe+0x68/0xd8
  really_probe+0xbc/0x2a8
  __driver_probe_device+0x78/0xe0
  driver_probe_device+0x3c/0xf0
  __driver_attach+0x70/0x120
  bus_for_each_dev+0x70/0xc0
  driver_attach+0x24/0x30
  bus_add_driver+0x150/0x200
  driver_register+0x64/0x120
  __platform_driver_register+0x28/0x38
  qcom_venus_driver_init+0x24/0x1000 [venus_core]
  do_one_initcall+0x54/0x1c8
  do_init_module+0x44/0x1d0
  load_module+0x16c8/0x1aa0
  __do_sys_finit_module+0xbc/0x110
  __arm64_sys_finit_module+0x20/0x30
  invoke_syscall+0x44/0x108
  el0_svc_common.constprop.0+0xcc/0xf0
  do_el0_svc+0x2c/0xb8
  el0_svc+0x2c/0x88
  el0t_64_sync_handler+0xb8/0xc0
  el0t_64_sync+0x18c/0x190
  qcom-venus: probe of aa00000.video-codec failed with error -16

The fix is re-ordering the code related to OPP core. The OPP core
expects all configuration options to be provided before the OPP
table is added.

Reported-by: Linux Kernel Functional Testing 
Suggested-by: Viresh Kumar 
Signed-off-by: Stanimir Varbanov 
Signed-off-by: Viresh Kumar 
Signed-off-by: Sasha Levin

iommu/io-pgtable-arm-v7s: Add a quirk to allow pgtable PA up to 35bit

2022-08-25T09:45:48+00:00

[ Upstream commit bfdd231374181254742c5e2faef0bef2d30c0ee4 ]

Single memory zone feature will remove ZONE_DMA32 and ZONE_DMA and
cause pgtable PA size larger than 32bit.

Since Mediatek IOMMU hardware support at most 35bit PA in pgtable,
so add a quirk to allow the PA of pgtables support up to bit35.

Signed-off-by: Ning Li 
Signed-off-by: Yunfei Wang 
Reviewed-by: Robin Murphy 
Acked-by: Will Deacon 
Link: https://lore.kernel.org/r/20220630092927.24925-2-yf.wang@mediatek.com
Signed-off-by: Joerg Roedel 
Signed-off-by: Sasha Levin

vfio: Clear the caps->buf to NULL after free

2022-08-25T09:45:48+00:00

[ Upstream commit 6641085e8d7b3f061911517f79a2a15a0a21b97b ]

On buffer resize failure, vfio_info_cap_add() will free the buffer,
report zero for the size, and return -ENOMEM.  As additional
hardening, also clear the buffer pointer to prevent any chance of a
double free.

Signed-off-by: Schspa Shi 
Reviewed-by: Cornelia Huck 
Link: https://lore.kernel.org/r/20220629022948.55608-1-schspa@gmail.com
Signed-off-by: Alex Williamson 
Signed-off-by: Sasha Levin

tty: serial: Fix refcount leak bug in ucc_uart.c

2022-08-25T09:45:48+00:00

[ Upstream commit d24d7bb2cd947676f9b71fb944d045e09b8b282f ]

In soc_info(), of_find_node_by_type() will return a node pointer
with refcount incremented. We should use of_node_put() when it is
not used anymore.

Acked-by: Timur Tabi 
Signed-off-by: Liang He 
Link: https://lore.kernel.org/r/20220618060850.4058525-1-windhl@126.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

drivers:md:fix a potential use-after-free bug

2022-08-25T09:45:47+00:00

[ Upstream commit 104212471b1c1817b311771d817fb692af983173 ]

In line 2884, "raid5_release_stripe(sh);" drops the reference to sh and
may cause sh to be released. However, sh is subsequently used in lines
2886 "if (sh->batch_head && sh != sh->batch_head)". This may result in an
use-after-free bug.

It can be fixed by moving "raid5_release_stripe(sh);" to the bottom of
the function.

Signed-off-by: Wentao_Liang 
Signed-off-by: Song Liu 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin

nvmet-tcp: fix lockdep complaint on nvmet_tcp_wq flush during queue teardown

2022-08-25T09:45:47+00:00

[ Upstream commit 533d2e8b4d5e4c89772a0adce913525fb86cbbee ]

We probably need nvmet_tcp_wq to have MEM_RECLAIM as we are
sending/receiving for the socket from works on this workqueue.
Also this eliminates lockdep complaints:
--
[ 6174.010200] workqueue: WQ_MEM_RECLAIM
nvmet-wq:nvmet_tcp_release_queue_work [nvmet_tcp] is flushing
!WQ_MEM_RECLAIM nvmet_tcp_wq:nvmet_tcp_io_work [nvmet_tcp]
[ 6174.010216] WARNING: CPU: 20 PID: 14456 at kernel/workqueue.c:2628
check_flush_dependency+0x110/0x14c

Reported-by: Yi Zhang 
Signed-off-by: Sagi Grimberg 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin

md/raid5: Make logic blocking check consistent with logic that blocks

2022-08-25T09:45:47+00:00

[ Upstream commit 6e3f50d30af847bebce072182bd735e90a294c6a ]

The check in raid5_make_request differs very slightly from the logic
that causes it to block lower down. This likely does not cause a bug
as the check is fuzzy anyway (as reshape may move on between the first
check and the subsequent check). However, make it consistent so it can
be cleaned up in a subsequent patch.

The condition which causes the schedule is:

 !(mddev->reshape_backwards ? logical_sector < conf->reshape_progress :
   logical_sector >= conf->reshape_progress) &&
  (mddev->reshape_backwards ? logical_sector < conf->reshape_safe :
   logical_sector >= conf->reshape_safe)

The condition that causes the early bailout is made to match this.

Signed-off-by: Logan Gunthorpe 
Signed-off-by: Song Liu 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin

md: Notify sysfs sync_completed in md_reap_sync_thread()

2022-08-25T09:45:47+00:00

[ Upstream commit 9973f0fa7d20269fe6fefe6333997fb5914449c1 ]

The mdadm test 07layouts randomly produces a kernel hung task deadlock.
The deadlock is caused by the suspend_lo/suspend_hi files being set by
the mdadm background process during reshape and not being cleared
because the process hangs. (Leaving aside the issue of the fragility of
freezing kernel tasks by buggy userspace processes...)

When the background mdadm process hangs it, is waiting (without a
timeout) on a change to the sync_completed file signalling that the
reshape has completed. The process is woken up a couple times when
the reshape finishes but it is woken up before MD_RECOVERY_RUNNING
is cleared so sync_completed_show() reports 0 instead of "none".

To fix this, notify the sysfs file in md_reap_sync_thread() after
MD_RECOVERY_RUNNING has been cleared. This wakes up mdadm and causes
it to continue and write to suspend_lo/suspend_hi to allow IO to
continue.

Signed-off-by: Logan Gunthorpe 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Song Liu 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin