July 2022 - Linux-stable-mirror

[PATCH net 1/2] ip: fix dflt addr selection for connected nexthop

by Nicolas Dichtel

When a nexthop is added, without a gw address, the default scope was set to 'host'. Thus, when a source address is selected, 127.0.0.1 may be chosen but rejected when the route is used. When using a route without a nexthop id, the scope can be configured in the route, thus the problem doesn't exist. To explain more deeply: when a user creates a nexthop, it cannot specify the scope. To create it, the function nh_create_ipv4() calls fib_check_nh() with scope set to 0. fib_check_nh() calls fib_check_nh_nongw() wich was setting scope to 'host'. Then, nh_create_ipv4() calls fib_info_update_nhc_saddr() with scope set to 'host'. The src addr is chosen before the route is inserted. When a 'standard' route (ie without a reference to a nexthop) is added, fib_create_info() calls fib_info_update_nhc_saddr() with the scope set by the user. iproute2 set the scope to 'link' by default. Here is a way to reproduce the problem: ip netns add foo ip -n foo link set lo up ip netns add bar ip -n bar link set lo up sleep 1 ip -n foo link add name eth0 type dummy ip -n foo link set eth0 up ip -n foo address add 192.168.0.1/24 dev eth0 ip -n foo link add name veth0 type veth peer name veth1 netns bar ip -n foo link set veth0 address 00:09:c0:26:05:82 ip -n foo link set veth0 arp off ip -n foo link set veth0 up ip -n bar link set veth1 address 00:09:c0:26:05:82 ip -n bar link set veth1 arp off ip -n bar link set veth1 up ip -n bar address add 192.168.1.1/32 dev veth1 ip -n bar route add default dev veth1 ip -n foo nexthop add id 1 dev veth0 ip -n foo route add 192.168.1.1 nhid 1 Try to get/use the route: > $ ip -n foo route get 192.168.1.1 > RTNETLINK answers: Invalid argument > $ ip netns exec foo ping -c1 192.168.1.1 > ping: connect: Invalid argument Try without nexthop group (iproute2 sets scope to 'link' by dflt): ip -n foo route del 192.168.1.1 ip -n foo route add 192.168.1.1 dev veth0 Try to get/use the route: > $ ip -n foo route get 192.168.1.1 > 192.168.1.1 dev veth0 src 192.168.0.1 uid 0 > cache > $ ip netns exec foo ping -c1 192.168.1.1 > PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. > 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.039 ms > > --- 192.168.1.1 ping statistics --- > 1 packets transmitted, 1 received, 0% packet loss, time 0ms > rtt min/avg/max/mdev = 0.039/0.039/0.039/0.000 ms CC: stable(a)vger.kernel.org Fixes: 597cfe4fc339 ("nexthop: Add support for IPv4 nexthops") Reported-by: Edwin Brossette <edwin.brossette(a)6wind.com> Signed-off-by: Nicolas Dichtel <nicolas.dichtel(a)6wind.com> --- net/ipv4/fib_semantics.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c index a57ba23571c9..20177ecf5bdd 100644 --- a/net/ipv4/fib_semantics.c +++ b/net/ipv4/fib_semantics.c @@ -1230,7 +1230,7 @@ static int fib_check_nh_nongw(struct net *net, struct fib_nh *nh, nh->fib_nh_dev = in_dev->dev; dev_hold_track(nh->fib_nh_dev, &nh->fib_nh_dev_tracker, GFP_ATOMIC); - nh->fib_nh_scope = RT_SCOPE_HOST; + nh->fib_nh_scope = RT_SCOPE_LINK; if (!netif_carrier_ok(nh->fib_nh_dev)) nh->fib_nh_flags |= RTNH_F_LINKDOWN; err = 0; -- 2.33.0

2 years, 6 months

2
2
0 0

[PATCH v2] usb: typec: add missing uevent when partner support PD

by Linyu Yuan

System like Android allow user control power role from UI, it is possible to implement application base on typec uevent to refresh UI, but found there is chance that UI show different state from typec attribute file. In typec_set_pwr_opmode(), when partner support PD, there is no uevent send to user space which cause the problem. Fix it by sending uevent notification when change power mode to PD. Fixes: bdecb33af34f ("usb: typec: API for controlling USB Type-C Multiplexers") Cc: stable(a)vger.kernel.org Signed-off-by: Linyu Yuan <quic_linyyuan(a)quicinc.com> --- v2: (v1 https://lore.kernel.org/linux-usb/1656637315-31229-1-git-send-email-quic_li…) fix review comment from Greg, add Fixes tag, improve commit description. drivers/usb/typec/class.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c index bbc46b1..3da94f712 100644 --- a/drivers/usb/typec/class.c +++ b/drivers/usb/typec/class.c @@ -1851,6 +1851,7 @@ void typec_set_pwr_opmode(struct typec_port *port, partner->usb_pd = 1; sysfs_notify(&partner_dev->kobj, NULL, "supports_usb_power_delivery"); + kobject_uevent(&partner_dev->kobj, KOBJ_CHANGE); } put_device(partner_dev); } -- 2.7.4

2 years, 6 months

2
1
0 0

[PATCH v3] xen/gntdev: Ignore failure to unmap INVALID_GRANT_HANDLE

by Demi Marie Obenour

The error paths of gntdev_mmap() can call unmap_grant_pages() even though not all of the pages have been successfully mapped. This will trigger the WARN_ON()s in __unmap_grant_pages_done(). The number of warnings can be very large; I have observed thousands of lines of warnings in the systemd journal. Avoid this problem by only warning on unmapping failure if the handle being unmapped is not INVALID_GRANT_HANDLE. The handle field of any page that was not successfully mapped will be INVALID_GRANT_HANDLE, so this catches all cases where unmapping can legitimately fail. Suggested-by: Juergen Gross <jgross(a)suse.com> Cc: stable(a)vger.kernel.org Signed-off-by: Demi Marie Obenour <demi(a)invisiblethingslab.com> Fixes: dbe97cff7dd9 ("xen/gntdev: Avoid blocking in unmap_grant_pages()") --- drivers/xen/gntdev.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) Changes since v2: - Use unmap_ops instead of kunmap_ops in the first WARN_ON Changes since v1: - Explicitly check for a status other than GNTST_okay instead of implicitly checking that it is nonzero. - Avoid wrapping a line as within a comparison, as this makes the code hard to read. diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c index 4b56c39f766d4da68570d08d963f6ef40c8d9c37..84b143eef395b1585f3a8c0fdcb301ce9fbc52ec 100644 --- a/drivers/xen/gntdev.c +++ b/drivers/xen/gntdev.c @@ -396,13 +396,15 @@ static void __unmap_grant_pages_done(int result, unsigned int offset = data->unmap_ops - map->unmap_ops; for (i = 0; i < data->count; i++) { - WARN_ON(map->unmap_ops[offset+i].status); + WARN_ON(map->unmap_ops[offset + i].status != GNTST_okay && + map->unmap_ops[offset + i].handle != INVALID_GRANT_HANDLE); pr_debug("unmap handle=%d st=%d\n", map->unmap_ops[offset+i].handle, map->unmap_ops[offset+i].status); map->unmap_ops[offset+i].handle = INVALID_GRANT_HANDLE; if (use_ptemod) { - WARN_ON(map->kunmap_ops[offset+i].status); + WARN_ON(map->kunmap_ops[offset + i].status != GNTST_okay && + map->kunmap_ops[offset + i].handle != INVALID_GRANT_HANDLE); pr_debug("kunmap handle=%u st=%d\n", map->kunmap_ops[offset+i].handle, map->kunmap_ops[offset+i].status); -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab

2 years, 6 months

3
3
0 0

Re: [PATCH 5.18 000/112] 5.18.11-rc1 review

by sixpack13

hallo Greg 5.18.11-rc1 compiles, boots and runs here on x86_64 (Intel i5-11400, Fedora 36) Thanks Tested-by: sixpack13(a)online.de

2 years, 6 months

2
1
0 0

[PATCH v3] fs/ntfs: fix BUG_ON of ntfs_read_block()

by xu xin

As the bug description at https://lore.kernel.org/lkml/20220623033635.973929-1-xu.xin16@zte.com.cn/ attckers can use this bug to crash the system. So to avoid panic, remove the BUG_ON, and use ntfs_warning to output a warning to the syslog and return ERR. Cc: stable(a)vger.kernel.org Cc: Songyi Zhang <zhang.songyi(a)zte.com.cn> Cc: Yang Yang <yang.yang29(a)zte.com.cn> Cc: Jiang Xuexin<jiang.xuexin(a)zte.com.cn> Cc: Zhang wenya<zhang.wenya1(a)zte.com.cn> Reported-by: Zeal Robot <zealci(a)zte.com.cn> Signed-off-by: xu xin <xu.xin16(a)zte.com.cn> --- Changelog for v3: - Use IS_ERR_OR_NULL to check runlist.rl in ntfs_read_block - Modify ntfs error log. Changelog for v2: - Use ntfs_warning instead of WARN(). - Add the tag Cc: stable(a)vger.kernel.org. --- fs/ntfs/aops.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/fs/ntfs/aops.c b/fs/ntfs/aops.c index 5f4fb6ca6f2e..b9421552686a 100644 --- a/fs/ntfs/aops.c +++ b/fs/ntfs/aops.c @@ -183,7 +183,14 @@ static int ntfs_read_block(struct page *page) vol = ni->vol; /* $MFT/$DATA must have its complete runlist in memory at all times. */ - BUG_ON(!ni->runlist.rl && !ni->mft_no && !NInoAttr(ni)); + if (IS_ERR_OR_NULL(ni->runlist.rl) && !ni->mft_no && !NInoAttr(ni)) { + ntfs_error(vol->sb, "Runlist of $MFT/$DATA is not cached. " + "$MFT is corrupt."); + unlock_page(page); + if (IS_ERR(ni->runlist.rl)) + return PTR_ERR(ni->runlist.rl); + return -EFAULT; + } blocksize = vol->sb->s_blocksize; blocksize_bits = vol->sb->s_blocksize_bits; -- 2.25.1

2 years, 6 months

1
0
0 0

[PATCH v5 2/2] powerpc/kvm: don't crash on missing rng, and use darn

by Jason A. Donenfeld

On POWER8 systems that don't have ibm,power-rng available, a guest that ignores the KVM_CAP_PPC_HWRNG flag and calls H_RANDOM anyway will dereference a NULL pointer. And on machines with darn instead of ibm,power-rng, H_RANDOM won't work at all. This patch kills two birds with one stone, by routing H_RANDOM calls to ppc_md.get_random_seed, and doing the real mode check inside of it. Cc: stable(a)vger.kernel.org # v4.1+ Cc: Michael Ellerman <mpe(a)ellerman.id.au> Tested-by: Sachin Sant <sachinp(a)linux.ibm.com> Fixes: e928e9cb3601 ("KVM: PPC: Book3S HV: Add fast real-mode H_RANDOM implementation.") Signed-off-by: Jason A. Donenfeld <Jason(a)zx2c4.com> --- arch/powerpc/include/asm/archrandom.h | 5 ---- arch/powerpc/kvm/book3s_hv_builtin.c | 7 +++--- arch/powerpc/platforms/powernv/rng.c | 34 +++++++-------------------- 3 files changed, 12 insertions(+), 34 deletions(-) diff --git a/arch/powerpc/include/asm/archrandom.h b/arch/powerpc/include/asm/archrandom.h index 11d4815841ab..3af27bb84a3d 100644 --- a/arch/powerpc/include/asm/archrandom.h +++ b/arch/powerpc/include/asm/archrandom.h @@ -38,12 +38,7 @@ static inline bool __must_check arch_get_random_seed_int(unsigned int *v) #endif /* CONFIG_ARCH_RANDOM */ #ifdef CONFIG_PPC_POWERNV -int pnv_hwrng_present(void); int pnv_get_random_long(unsigned long *v); -int pnv_get_random_real_mode(unsigned long *v); -#else -static inline int pnv_hwrng_present(void) { return 0; } -static inline int pnv_get_random_real_mode(unsigned long *v) { return 0; } #endif #endif /* _ASM_POWERPC_ARCHRANDOM_H */ diff --git a/arch/powerpc/kvm/book3s_hv_builtin.c b/arch/powerpc/kvm/book3s_hv_builtin.c index 799d40c2ab4f..3abaef5f9ac2 100644 --- a/arch/powerpc/kvm/book3s_hv_builtin.c +++ b/arch/powerpc/kvm/book3s_hv_builtin.c @@ -19,7 +19,7 @@ #include <asm/interrupt.h> #include <asm/kvm_ppc.h> #include <asm/kvm_book3s.h> -#include <asm/archrandom.h> +#include <asm/machdep.h> #include <asm/xics.h> #include <asm/xive.h> #include <asm/dbell.h> @@ -176,13 +176,14 @@ EXPORT_SYMBOL_GPL(kvmppc_hcall_impl_hv_realmode); int kvmppc_hwrng_present(void) { - return pnv_hwrng_present(); + return ppc_md.get_random_seed != NULL; } EXPORT_SYMBOL_GPL(kvmppc_hwrng_present); long kvmppc_rm_h_random(struct kvm_vcpu *vcpu) { - if (pnv_get_random_real_mode(&vcpu->arch.regs.gpr[4])) + if (ppc_md.get_random_seed && + ppc_md.get_random_seed(&vcpu->arch.regs.gpr[4])) return H_SUCCESS; return H_HARDWARE; diff --git a/arch/powerpc/platforms/powernv/rng.c b/arch/powerpc/platforms/powernv/rng.c index b5cd82eab9b3..196aa70fe043 100644 --- a/arch/powerpc/platforms/powernv/rng.c +++ b/arch/powerpc/platforms/powernv/rng.c @@ -29,15 +29,6 @@ struct pnv_rng { static DEFINE_PER_CPU(struct pnv_rng *, pnv_rng); -int pnv_hwrng_present(void) -{ - struct pnv_rng *rng; - - rng = get_cpu_var(pnv_rng); - put_cpu_var(rng); - return rng != NULL; -} - static unsigned long rng_whiten(struct pnv_rng *rng, unsigned long val) { unsigned long parity; @@ -58,17 +49,6 @@ static unsigned long rng_whiten(struct pnv_rng *rng, unsigned long val) return val; } -int pnv_get_random_real_mode(unsigned long *v) -{ - struct pnv_rng *rng; - - rng = raw_cpu_read(pnv_rng); - - *v = rng_whiten(rng, __raw_rm_readq(rng->regs_real)); - - return 1; -} - static int pnv_get_random_darn(unsigned long *v) { unsigned long val; @@ -105,12 +85,14 @@ int pnv_get_random_long(unsigned long *v) { struct pnv_rng *rng; - rng = get_cpu_var(pnv_rng); - - *v = rng_whiten(rng, in_be64(rng->regs)); - - put_cpu_var(rng); - + if (mfmsr() & MSR_DR) { + rng = get_cpu_var(pnv_rng); + *v = rng_whiten(rng, in_be64(rng->regs)); + put_cpu_var(rng); + } else { + rng = raw_cpu_read(pnv_rng); + *v = rng_whiten(rng, __raw_rm_readq(rng->regs_real)); + } return 1; } EXPORT_SYMBOL_GPL(pnv_get_random_long); -- 2.35.1

2 years, 6 months

1
0
0 0

[PATCH] PCI/AER: Iterate over error counters instead of error strings

by Mohamed Khalfella

PCI AER stats counters sysfs attributes need to iterate over stats counters instead of stats names. Also, added a build time check to make sure all counters have entries in strings array. Fixes: 0678e3109a3c ("PCI/AER: Simplify __aer_print_error()") Cc: stable(a)vger.kernel.org Reported-by: Meeta Saggi <msaggi(a)purestorage.com> Signed-off-by: Mohamed Khalfella <mkhalfella(a)purestorage.com> Reviewed-by: Meeta Saggi <msaggi(a)purestorage.com> Reviewed-by: Eric Badger <ebadger(a)purestorage.com> --- drivers/pci/pcie/aer.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c index 9fa1f97e5b27..ce99a6d44786 100644 --- a/drivers/pci/pcie/aer.c +++ b/drivers/pci/pcie/aer.c @@ -533,7 +533,7 @@ static const char *aer_agent_string[] = { u64 *stats = pdev->aer_stats->stats_array; \ size_t len = 0; \ \ - for (i = 0; i < ARRAY_SIZE(strings_array); i++) { \ + for (i = 0; i < ARRAY_SIZE(pdev->aer_stats->stats_array); i++) {\ if (strings_array[i]) \ len += sysfs_emit_at(buf, len, "%s %llu\n", \ strings_array[i], \ @@ -1342,6 +1342,11 @@ static int aer_probe(struct pcie_device *dev) struct device *device = &dev->device; struct pci_dev *port = dev->port; + BUILD_BUG_ON(ARRAY_SIZE(aer_correctable_error_string) < + AER_MAX_TYPEOF_COR_ERRS); + BUILD_BUG_ON(ARRAY_SIZE(aer_uncorrectable_error_string) < + AER_MAX_TYPEOF_UNCOR_ERRS); + /* Limit to Root Ports or Root Complex Event Collectors */ if ((pci_pcie_type(port) != PCI_EXP_TYPE_RC_EC) && (pci_pcie_type(port) != PCI_EXP_TYPE_ROOT_PORT)) -- 2.29.0

2 years, 6 months

2
7
0 0

[PATCH v2] drm/amd/display: Ignore First MST Sideband Message Return Error

by Rodrigo Siqueira

From: Fangzhi Zuo <Jerry.Zuo(a)amd.com> [why] The first MST sideband message returns AUX_RET_ERROR_HPD_DISCON on a certain Intel platform. Aux transaction is considered a failure if HPD unexpectedly pulled low. The actual aux transaction success in such case, hence do not return an error. Several Dell Intel-based Precision systems had this issue, for example, Precision 3260 and 3460. [how] Not returning error when AUX_RET_ERROR_HPD_DISCON detected on the first sideband message. Changes since v1: * Add two missing products Cc: Harry Wentland <harry.wentland(a)amd.com> Cc: Mario Limonciello <mario.limonciello(a)amd.com> Cc: Qian Fu <Qian.Fu(a)dell.com> Cc: stable(a)vger.kernel.org Signed-off-by: Fangzhi Zuo <Jerry.Zuo(a)amd.com> --- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 +++++++++++++++++++ .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 8 +++++ .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 17 +++++++++++ 3 files changed, 54 insertions(+) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index de1c139ae279..3c7f6920f71f 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -72,6 +72,7 @@ #include <linux/pci.h> #include <linux/firmware.h> #include <linux/component.h> +#include <linux/dmi.h> #include <drm/drm_atomic.h> #include <drm/drm_atomic_uapi.h> @@ -1400,6 +1401,31 @@ static bool dm_should_disable_stutter(struct pci_dev *pdev) return false; } +static const struct dmi_system_id hpd_disconnect_quirk_table[] = { + { + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."), + DMI_MATCH(DMI_PRODUCT_NAME, "Precision 3660"), + DMI_MATCH(DMI_PRODUCT_NAME, "Precision 3260"), + DMI_MATCH(DMI_PRODUCT_NAME, "Precision 3460"), + }, + }, + {} +}; + +void retrieve_dmi_info(struct amdgpu_display_manager *dm) +{ + const struct dmi_system_id *dmi_id; + + dm->aux_hpd_discon_quirk = false; + + dmi_id = dmi_first_match(hpd_disconnect_quirk_table); + if (dmi_id) { + dm->aux_hpd_discon_quirk = true; + DRM_INFO("aux_hpd_discon_quirk attached\n"); + } +} + static int amdgpu_dm_init(struct amdgpu_device *adev) { struct dc_init_data init_data; @@ -1528,6 +1554,9 @@ static int amdgpu_dm_init(struct amdgpu_device *adev) init_data.flags.enable_mipi_converter_optimization = true; INIT_LIST_HEAD(&adev->dm.da_list); + + retrieve_dmi_info(&adev->dm); + /* Display Core create. */ adev->dm.dc = dc_create(&init_data); diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h index e04e6b3f609f..33d66d4897dc 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h @@ -547,6 +547,14 @@ struct amdgpu_display_manager { * last successfully applied backlight values. */ u32 actual_brightness[AMDGPU_DM_MAX_NUM_EDP]; + + /** + * @aux_hpd_discon_quirk: + * + * quirk for hpd discon while aux is on-going. + * occurred on certain intel platform + */ + bool aux_hpd_discon_quirk; }; enum dsc_clock_force_state { diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c index 8237029cedf5..168d5676b657 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c @@ -56,6 +56,8 @@ static ssize_t dm_dp_aux_transfer(struct drm_dp_aux *aux, ssize_t result = 0; struct aux_payload payload; enum aux_return_code_type operation_result; + struct amdgpu_device *adev; + struct ddc_service *ddc; if (WARN_ON(msg->size > 16)) return -E2BIG; @@ -74,6 +76,21 @@ static ssize_t dm_dp_aux_transfer(struct drm_dp_aux *aux, result = dc_link_aux_transfer_raw(TO_DM_AUX(aux)->ddc_service, &payload, &operation_result); + /* + * w/a on certain intel platform where hpd is unexpected to pull low during + * 1st sideband message transaction by return AUX_RET_ERROR_HPD_DISCON + * aux transaction is succuess in such case, therefore bypass the error + */ + ddc = TO_DM_AUX(aux)->ddc_service; + adev = ddc->ctx->driver_context; + if (adev->dm.aux_hpd_discon_quirk) { + if (msg->address == DP_SIDEBAND_MSG_DOWN_REQ_BASE && + operation_result == AUX_RET_ERROR_HPD_DISCON) { + result = 0; + operation_result = AUX_RET_SUCCESS; + } + } + if (payload.write && result >= 0) result = msg->size; -- 2.37.0

2 years, 6 months

2
1
0 0

[PATCH] drm/amd/display: Ignore First MST Sideband Message Return Error

by Rodrigo Siqueira

From: Fangzhi Zuo <Jerry.Zuo(a)amd.com> [why] The first MST sideband message returns AUX_RET_ERROR_HPD_DISCON on a certain Intel platform. Aux transaction is considered a failure if HPD unexpectedly pulled low. The actual aux transaction success in such case, hence do not return an error. Several Dell Intel-based Precision systems had this issue, for example, Precision 3260 and 3460. [how] Not returning error when AUX_RET_ERROR_HPD_DISCON detected on the first sideband message. Cc: Harry Wentland <harry.wentland(a)amd.com> Cc: Mario Limonciello <mario.limonciello(a)amd.com> Cc: Qian Fu <Qian.Fu(a)dell.com> Cc: stable(a)vger.kernel.org Signed-off-by: Fangzhi Zuo <Jerry.Zuo(a)amd.com> --- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 27 +++++++++++++++++++ .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 8 ++++++ .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 17 ++++++++++++ 3 files changed, 52 insertions(+) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index de1c139ae279..e0af3d003b5c 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -72,6 +72,7 @@ #include <linux/pci.h> #include <linux/firmware.h> #include <linux/component.h> +#include <linux/dmi.h> #include <drm/drm_atomic.h> #include <drm/drm_atomic_uapi.h> @@ -1400,6 +1401,29 @@ static bool dm_should_disable_stutter(struct pci_dev *pdev) return false; } +static const struct dmi_system_id hpd_disconnect_quirk_table[] = { + { + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."), + DMI_MATCH(DMI_PRODUCT_NAME, "Precision 3660"), + }, + }, + {} +}; + +void retrieve_dmi_info(struct amdgpu_display_manager *dm) +{ + const struct dmi_system_id *dmi_id; + + dm->aux_hpd_discon_quirk = false; + + dmi_id = dmi_first_match(hpd_disconnect_quirk_table); + if (dmi_id) { + dm->aux_hpd_discon_quirk = true; + DRM_INFO("aux_hpd_discon_quirk attached\n"); + } +} + static int amdgpu_dm_init(struct amdgpu_device *adev) { struct dc_init_data init_data; @@ -1528,6 +1552,9 @@ static int amdgpu_dm_init(struct amdgpu_device *adev) init_data.flags.enable_mipi_converter_optimization = true; INIT_LIST_HEAD(&adev->dm.da_list); + + retrieve_dmi_info(&adev->dm); + /* Display Core create. */ adev->dm.dc = dc_create(&init_data); diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h index e04e6b3f609f..33d66d4897dc 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h @@ -547,6 +547,14 @@ struct amdgpu_display_manager { * last successfully applied backlight values. */ u32 actual_brightness[AMDGPU_DM_MAX_NUM_EDP]; + + /** + * @aux_hpd_discon_quirk: + * + * quirk for hpd discon while aux is on-going. + * occurred on certain intel platform + */ + bool aux_hpd_discon_quirk; }; enum dsc_clock_force_state { diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c index 8237029cedf5..168d5676b657 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c @@ -56,6 +56,8 @@ static ssize_t dm_dp_aux_transfer(struct drm_dp_aux *aux, ssize_t result = 0; struct aux_payload payload; enum aux_return_code_type operation_result; + struct amdgpu_device *adev; + struct ddc_service *ddc; if (WARN_ON(msg->size > 16)) return -E2BIG; @@ -74,6 +76,21 @@ static ssize_t dm_dp_aux_transfer(struct drm_dp_aux *aux, result = dc_link_aux_transfer_raw(TO_DM_AUX(aux)->ddc_service, &payload, &operation_result); + /* + * w/a on certain intel platform where hpd is unexpected to pull low during + * 1st sideband message transaction by return AUX_RET_ERROR_HPD_DISCON + * aux transaction is succuess in such case, therefore bypass the error + */ + ddc = TO_DM_AUX(aux)->ddc_service; + adev = ddc->ctx->driver_context; + if (adev->dm.aux_hpd_discon_quirk) { + if (msg->address == DP_SIDEBAND_MSG_DOWN_REQ_BASE && + operation_result == AUX_RET_ERROR_HPD_DISCON) { + result = 0; + operation_result = AUX_RET_SUCCESS; + } + } + if (payload.write && result >= 0) result = msg->size; -- 2.37.0

2 years, 6 months

2
1
0 0

+ hugetlb-fix-memoryleak-in-hugetlb_mcopy_atomic_pte.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: hugetlb: fix memoryleak in hugetlb_mcopy_atomic_pte has been added to the -mm mm-hotfixes-unstable branch. Its filename is hugetlb-fix-memoryleak-in-hugetlb_mcopy_atomic_pte.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Miaohe Lin <linmiaohe(a)huawei.com> Subject: hugetlb: fix memoryleak in hugetlb_mcopy_atomic_pte Date: Sat, 9 Jul 2022 17:26:29 +0800 When alloc_huge_page fails, *pagep is set to NULL without put_page first. So the hugepage indicated by *pagep is leaked. Link: https://lkml.kernel.org/r/20220709092629.54291-1-linmiaohe@huawei.com Fixes: 8cc5fcbb5be8 ("mm, hugetlb: fix racy resv_huge_pages underflow on UFFDIO_COPY") Signed-off-by: Miaohe Lin <linmiaohe(a)huawei.com> Acked-by: Muchun Song <songmuchun(a)bytedance.com> Cc: Mike Kravetz <mike.kravetz(a)oracle.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/hugetlb.c | 1 + 1 file changed, 1 insertion(+) --- a/mm/hugetlb.c~hugetlb-fix-memoryleak-in-hugetlb_mcopy_atomic_pte +++ a/mm/hugetlb.c @@ -5952,6 +5952,7 @@ int hugetlb_mcopy_atomic_pte(struct mm_s page = alloc_huge_page(dst_vma, dst_addr, 0); if (IS_ERR(page)) { + put_page(*pagep); ret = -ENOMEM; *pagep = NULL; goto out; _ Patches currently in -mm which might be from linmiaohe(a)huawei.com are hugetlb-fix-memoryleak-in-hugetlb_mcopy_atomic_pte.patch mm-page_alloc-minor-clean-up-for-memmap_init_compound.patch mm-mmapc-fix-missing-call-to-vm_unacct_memory-in-mmap_region.patch filemap-minor-cleanup-for-filemap_write_and_wait_range.patch mm-huge_memory-use-flush_pmd_tlb_range-in-move_huge_pmd.patch mm-huge_memory-access-vm_page_prot-with-read_once-in-remove_migration_pmd.patch mm-huge_memory-fix-comment-of-__pud_trans_huge_lock.patch mm-huge_memory-use-helper-touch_pud-in-huge_pud_set_accessed.patch mm-huge_memory-use-helper-touch_pmd-in-huge_pmd_set_accessed.patch mm-huge_memory-rename-mmun_start-to-haddr-in-remove_migration_pmd.patch mm-huge_memory-use-helper-function-vma_lookup-in-split_huge_pages_pid.patch mm-huge_memory-use-helper-macro-__attr_rw.patch mm-huge_memory-fix-comment-in-zap_huge_pud.patch mm-huge_memory-check-pmd_present-first-in-is_huge_zero_pmd.patch mm-huge_memory-try-to-free-subpage-in-swapcache-when-possible.patch mm-huge_memory-minor-cleanup-for-split_huge_pages_all.patch mm-huge_memory-fix-comment-of-page_deferred_list.patch mm-huge_memory-correct-comment-of-prep_transhuge_page.patch mm-huge_memory-comment-the-subtly-logic-in-__split_huge_pmd.patch mm-huge_memory-use-helper-macro-is_err_or_null-in-split_huge_pages_pid.patch

2 years, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror July 2022