- Linux-stable-mirror - lists.linaro.org

Patch "zd1211rw: fix NULL-deref at probe" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled zd1211rw: fix NULL-deref at probe to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: zd1211rw-fix-null-deref-at-probe.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sun Mar 18 16:55:33 CET 2018 From: Johan Hovold <johan(a)kernel.org> Date: Mon, 13 Mar 2017 13:44:21 +0100 Subject: zd1211rw: fix NULL-deref at probe From: Johan Hovold <johan(a)kernel.org> [ Upstream commit ca260ece6a57dc7d751e0685f51fa2c55d851873 ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer or accessing memory beyond the endpoint array should a malicious device lack the expected endpoints. Fixes: a1030e92c150 ("[PATCH] zd1211rw: Convert installer CDROM device into WLAN device") Cc: Daniel Drake <dsd(a)gentoo.org> Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/zydas/zd1211rw/zd_usb.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/net/wireless/zydas/zd1211rw/zd_usb.c +++ b/drivers/net/wireless/zydas/zd1211rw/zd_usb.c @@ -1278,6 +1278,9 @@ static int eject_installer(struct usb_in u8 bulk_out_ep; int r; + if (iface_desc->desc.bNumEndpoints < 2) + return -ENODEV; + /* Find bulk out endpoint */ for (r = 1; r >= 0; r--) { endpoint = &iface_desc->endpoint[r].desc; Patches currently in stable-queue which might be from johan(a)kernel.org are queue-4.9/zd1211rw-fix-null-deref-at-probe.patch

7 years, 4 months

1
0
0 0

Patch "x86/mm: Make mmap(MAP_32BIT) work correctly" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/mm: Make mmap(MAP_32BIT) work correctly to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-mm-make-mmap-map_32bit-work-correctly.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sun Mar 18 16:55:33 CET 2018 From: Dmitry Safonov <dsafonov(a)virtuozzo.com> Date: Mon, 6 Mar 2017 17:17:20 +0300 Subject: x86/mm: Make mmap(MAP_32BIT) work correctly From: Dmitry Safonov <dsafonov(a)virtuozzo.com> [ Upstream commit 3e6ef9c80946f781fc25e8490c9875b1d2b61158 ] mmap(MAP_32BIT) is broken due to the dependency on the TIF_ADDR32 thread flag. For 64bit applications MAP_32BIT will force legacy bottom-up allocations and the 1GB address space restriction even if the application issued a compat syscall, which should not be subject of these restrictions. For 32bit applications, which issue 64bit syscalls the newly introduced mmap base separation into 64-bit and compat bases changed the behaviour because now a 64-bit mapping is returned, but due to the TIF_ADDR32 dependency MAP_32BIT is ignored. Before the separation a 32-bit mapping was returned, so the MAP_32BIT handling was irrelevant. Replace the check for TIF_ADDR32 with a check for the compat syscall. That solves both the 64-bit issuing a compat syscall and the 32-bit issuing a 64-bit syscall problems. [ tglx: Massaged changelog ] Signed-off-by: Dmitry Safonov <dsafonov(a)virtuozzo.com> Cc: 0x7f454c46(a)gmail.com Cc: linux-mm(a)kvack.org Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Cyrill Gorcunov <gorcunov(a)openvz.org> Cc: Borislav Petkov <bp(a)suse.de> Cc: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com> Link: http://lkml.kernel.org/r/20170306141721.9188-5-dsafonov@virtuozzo.com Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/sys_x86_64.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/arch/x86/kernel/sys_x86_64.c +++ b/arch/x86/kernel/sys_x86_64.c @@ -100,7 +100,7 @@ out: static void find_start_end(unsigned long flags, unsigned long *begin, unsigned long *end) { - if (!test_thread_flag(TIF_ADDR32) && (flags & MAP_32BIT)) { + if (!in_compat_syscall() && (flags & MAP_32BIT)) { /* This is usually used needed to map code in small model, so it needs to be in the first 31bit. Limit it to that. This means we need to move the @@ -175,7 +175,7 @@ arch_get_unmapped_area_topdown(struct fi return addr; /* for MAP_32BIT mappings we force the legacy mmap base */ - if (!test_thread_flag(TIF_ADDR32) && (flags & MAP_32BIT)) + if (!in_compat_syscall() && (flags & MAP_32BIT)) goto bottomup; /* requesting a specific address */ Patches currently in stable-queue which might be from dsafonov(a)virtuozzo.com are queue-4.9/x86-mm-make-mmap-map_32bit-work-correctly.patch

7 years, 4 months

1
0
0 0

Patch "x86/mce: Init some CPU features early" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/mce: Init some CPU features early to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-mce-init-some-cpu-features-early.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sun Mar 18 16:55:33 CET 2018 From: Yazen Ghannam <Yazen.Ghannam(a)amd.com> Date: Wed, 15 Mar 2017 12:30:55 -0500 Subject: x86/mce: Init some CPU features early From: Yazen Ghannam <Yazen.Ghannam(a)amd.com> [ Upstream commit 5204bf17031b69fa5faa4dc80a9dc1e2446d74f9 ] When the MCA banks in __mcheck_cpu_init_generic() are polled for leftover errors logged during boot or from the previous boot, its required to have CPU features detected sufficiently so that the reading out and handling of those early errors is done correctly. If those features are not available, the decoding may miss some information and get incomplete errors logged. For example, on SMCA systems the MCA_IPID and MCA_SYND registers are not logged and MCA_ADDR is not masked appropriately. To cure that, do a subset of the basic feature detection early while the rest happens in its usual place in __mcheck_cpu_init_vendor(). Signed-off-by: Yazen Ghannam <Yazen.Ghannam(a)amd.com> Cc: Tony Luck <tony.luck(a)intel.com> Cc: linux-edac <linux-edac(a)vger.kernel.org> Cc: x86-ml <x86(a)kernel.org> Link: http://lkml.kernel.org/r/1489599055-20756-1-git-send-email-Yazen.Ghannam@am… [ Massage commit message and simplify. ] Signed-off-by: Borislav Petkov <bp(a)suse.de> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/cpu/mcheck/mce.c | 30 ++++++++++++++++++------------ 1 file changed, 18 insertions(+), 12 deletions(-) --- a/arch/x86/kernel/cpu/mcheck/mce.c +++ b/arch/x86/kernel/cpu/mcheck/mce.c @@ -1695,30 +1695,35 @@ static int __mcheck_cpu_ancient_init(str return 0; } -static void __mcheck_cpu_init_vendor(struct cpuinfo_x86 *c) +/* + * Init basic CPU features needed for early decoding of MCEs. + */ +static void __mcheck_cpu_init_early(struct cpuinfo_x86 *c) { - switch (c->x86_vendor) { - case X86_VENDOR_INTEL: - mce_intel_feature_init(c); - mce_adjust_timer = cmci_intel_adjust_timer; - break; - - case X86_VENDOR_AMD: { + if (c->x86_vendor == X86_VENDOR_AMD) { mce_flags.overflow_recov = !!cpu_has(c, X86_FEATURE_OVERFLOW_RECOV); mce_flags.succor = !!cpu_has(c, X86_FEATURE_SUCCOR); mce_flags.smca = !!cpu_has(c, X86_FEATURE_SMCA); - /* - * Install proper ops for Scalable MCA enabled processors - */ if (mce_flags.smca) { msr_ops.ctl = smca_ctl_reg; msr_ops.status = smca_status_reg; msr_ops.addr = smca_addr_reg; msr_ops.misc = smca_misc_reg; } - mce_amd_feature_init(c); + } +} +static void __mcheck_cpu_init_vendor(struct cpuinfo_x86 *c) +{ + switch (c->x86_vendor) { + case X86_VENDOR_INTEL: + mce_intel_feature_init(c); + mce_adjust_timer = cmci_intel_adjust_timer; + break; + + case X86_VENDOR_AMD: { + mce_amd_feature_init(c); break; } @@ -1804,6 +1809,7 @@ void mcheck_cpu_init(struct cpuinfo_x86 machine_check_vector = do_machine_check; + __mcheck_cpu_init_early(c); __mcheck_cpu_init_generic(); __mcheck_cpu_init_vendor(c); __mcheck_cpu_init_clear_banks(); Patches currently in stable-queue which might be from Yazen.Ghannam(a)amd.com are queue-4.9/x86-mce-init-some-cpu-features-early.patch

7 years, 4 months

1
0
0 0

Patch "x86/mce: Handle broadcasted MCE gracefully with kexec" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/mce: Handle broadcasted MCE gracefully with kexec to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-mce-handle-broadcasted-mce-gracefully-with-kexec.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sun Mar 18 16:55:33 CET 2018 From: Xunlei Pang <xlpang(a)redhat.com> Date: Mon, 13 Mar 2017 10:50:19 +0100 Subject: x86/mce: Handle broadcasted MCE gracefully with kexec From: Xunlei Pang <xlpang(a)redhat.com> [ Upstream commit 5bc329503e8191c91c4c40836f062ef771d8ba83 ] When we are about to kexec a crash kernel and right then and there a broadcasted MCE fires while we're still in the first kernel and while the other CPUs remain in a holding pattern, the #MC handler of the first kernel will timeout and then panic due to never completing MCE synchronization. Handle this in a similar way as to when the CPUs are offlined when that broadcasted MCE happens. [ Boris: rewrote commit message and comments. ] Suggested-by: Borislav Petkov <bp(a)alien8.de> Signed-off-by: Xunlei Pang <xlpang(a)redhat.com> Signed-off-by: Borislav Petkov <bp(a)suse.de> Acked-by: Tony Luck <tony.luck(a)intel.com> Cc: Naoya Horiguchi <n-horiguchi(a)ah.jp.nec.com> Cc: kexec(a)lists.infradead.org Cc: linux-edac <linux-edac(a)vger.kernel.org> Link: http://lkml.kernel.org/r/1487857012-9059-1-git-send-email-xlpang@redhat.com Link: http://lkml.kernel.org/r/20170313095019.19351-1-bp@alien8.de Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/include/asm/reboot.h | 1 + arch/x86/kernel/cpu/mcheck/mce.c | 18 ++++++++++++++++-- arch/x86/kernel/reboot.c | 5 +++-- 3 files changed, 20 insertions(+), 4 deletions(-) --- a/arch/x86/include/asm/reboot.h +++ b/arch/x86/include/asm/reboot.h @@ -15,6 +15,7 @@ struct machine_ops { }; extern struct machine_ops machine_ops; +extern int crashing_cpu; void native_machine_crash_shutdown(struct pt_regs *regs); void native_machine_shutdown(void); --- a/arch/x86/kernel/cpu/mcheck/mce.c +++ b/arch/x86/kernel/cpu/mcheck/mce.c @@ -48,6 +48,7 @@ #include <asm/tlbflush.h> #include <asm/mce.h> #include <asm/msr.h> +#include <asm/reboot.h> #include "mce-internal.h" @@ -1081,9 +1082,22 @@ void do_machine_check(struct pt_regs *re * on Intel. */ int lmce = 1; + int cpu = smp_processor_id(); - /* If this CPU is offline, just bail out. */ - if (cpu_is_offline(smp_processor_id())) { + /* + * Cases where we avoid rendezvous handler timeout: + * 1) If this CPU is offline. + * + * 2) If crashing_cpu was set, e.g. we're entering kdump and we need to + * skip those CPUs which remain looping in the 1st kernel - see + * crash_nmi_callback(). + * + * Note: there still is a small window between kexec-ing and the new, + * kdump kernel establishing a new #MC handler where a broadcasted MCE + * might not get handled properly. + */ + if (cpu_is_offline(cpu) || + (crashing_cpu != -1 && crashing_cpu != cpu)) { u64 mcgstatus; mcgstatus = mce_rdmsrl(MSR_IA32_MCG_STATUS); --- a/arch/x86/kernel/reboot.c +++ b/arch/x86/kernel/reboot.c @@ -769,10 +769,11 @@ void machine_crash_shutdown(struct pt_re #endif +/* This is the CPU performing the emergency shutdown work. */ +int crashing_cpu = -1; + #if defined(CONFIG_SMP) -/* This keeps a track of which one is crashing cpu. */ -static int crashing_cpu; static nmi_shootdown_cb shootdown_callback; static atomic_t waiting_for_crash_ipi; Patches currently in stable-queue which might be from xlpang(a)redhat.com are queue-4.9/rtmutex-fix-pi-chain-order-integrity.patch queue-4.9/x86-mce-handle-broadcasted-mce-gracefully-with-kexec.patch

7 years, 4 months

1
0
0 0

Patch "wil6210: fix protection against connections during reset" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled wil6210: fix protection against connections during reset to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: wil6210-fix-protection-against-connections-during-reset.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sun Mar 18 16:55:33 CET 2018 From: Hamad Kadmany <qca_hkadmany(a)qca.qualcomm.com> Date: Wed, 5 Apr 2017 14:58:08 +0300 Subject: wil6210: fix protection against connections during reset From: Hamad Kadmany <qca_hkadmany(a)qca.qualcomm.com> [ Upstream commit b819447dfc4bd120c9d6cd8521252d544fce8fe7 ] Existing code that ignores connection events during reset flow will never take effect since it locks the same mutex taken by the reset flow. In addition, in case of unsolicited disconnect events ignore those as well since device is about to get reset. Signed-off-by: Hamad Kadmany <qca_hkadmany(a)qca.qualcomm.com> Signed-off-by: Maya Erez <qca_merez(a)qca.qualcomm.com> Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/ath/wil6210/wmi.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) --- a/drivers/net/wireless/ath/wil6210/wmi.c +++ b/drivers/net/wireless/ath/wil6210/wmi.c @@ -501,16 +501,16 @@ static void wmi_evt_connect(struct wil62 assoc_resp_ielen = 0; } - mutex_lock(&wil->mutex); if (test_bit(wil_status_resetting, wil->status) || !test_bit(wil_status_fwready, wil->status)) { wil_err(wil, "status_resetting, cancel connect event, CID %d\n", evt->cid); - mutex_unlock(&wil->mutex); /* no need for cleanup, wil_reset will do that */ return; } + mutex_lock(&wil->mutex); + if ((wdev->iftype == NL80211_IFTYPE_STATION) || (wdev->iftype == NL80211_IFTYPE_P2P_CLIENT)) { if (!test_bit(wil_status_fwconnecting, wil->status)) { @@ -608,6 +608,13 @@ static void wmi_evt_disconnect(struct wi wil->sinfo_gen++; + if (test_bit(wil_status_resetting, wil->status) || + !test_bit(wil_status_fwready, wil->status)) { + wil_err(wil, "status_resetting, cancel disconnect event\n"); + /* no need for cleanup, wil_reset will do that */ + return; + } + mutex_lock(&wil->mutex); wil6210_disconnect(wil, evt->bssid, reason_code, true); mutex_unlock(&wil->mutex); Patches currently in stable-queue which might be from qca_hkadmany(a)qca.qualcomm.com are queue-4.9/wil6210-fix-protection-against-connections-during-reset.patch

7 years, 4 months

1
0
0 0

Patch "wil6210: fix memory access violation in wil_memcpy_from/toio_32" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled wil6210: fix memory access violation in wil_memcpy_from/toio_32 to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: wil6210-fix-memory-access-violation-in-wil_memcpy_from-toio_32.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sun Mar 18 16:55:33 CET 2018 From: Dedy Lansky <qca_dlansky(a)qca.qualcomm.com> Date: Wed, 5 Apr 2017 14:58:11 +0300 Subject: wil6210: fix memory access violation in wil_memcpy_from/toio_32 From: Dedy Lansky <qca_dlansky(a)qca.qualcomm.com> [ Upstream commit 0f6edfe2bbbb59d161580cb4870fcc46f5490f85 ] In case count is not multiple of 4, there is a read access in wil_memcpy_toio_32() from outside src buffer boundary. In wil_memcpy_fromio_32(), in case count is not multiple of 4, there is a write access to outside dst io memory boundary. Fix these issues with proper handling of the last 1 to 4 copied bytes. Signed-off-by: Dedy Lansky <qca_dlansky(a)qca.qualcomm.com> Signed-off-by: Maya Erez <qca_merez(a)qca.qualcomm.com> Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/ath/wil6210/main.c | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) --- a/drivers/net/wireless/ath/wil6210/main.c +++ b/drivers/net/wireless/ath/wil6210/main.c @@ -129,9 +129,15 @@ void wil_memcpy_fromio_32(void *dst, con u32 *d = dst; const volatile u32 __iomem *s = src; - /* size_t is unsigned, if (count%4 != 0) it will wrap */ - for (count += 4; count > 4; count -= 4) + for (; count >= 4; count -= 4) *d++ = __raw_readl(s++); + + if (unlikely(count)) { + /* count can be 1..3 */ + u32 tmp = __raw_readl(s); + + memcpy(d, &tmp, count); + } } void wil_memcpy_fromio_halp_vote(struct wil6210_priv *wil, void *dst, @@ -148,8 +154,16 @@ void wil_memcpy_toio_32(volatile void __ volatile u32 __iomem *d = dst; const u32 *s = src; - for (count += 4; count > 4; count -= 4) + for (; count >= 4; count -= 4) __raw_writel(*s++, d++); + + if (unlikely(count)) { + /* count can be 1..3 */ + u32 tmp = 0; + + memcpy(&tmp, s, count); + __raw_writel(tmp, d); + } } void wil_memcpy_toio_halp_vote(struct wil6210_priv *wil, Patches currently in stable-queue which might be from qca_dlansky(a)qca.qualcomm.com are queue-4.9/wil6210-fix-memory-access-violation-in-wil_memcpy_from-toio_32.patch

7 years, 4 months

1
0
0 0

Patch "vxlan: vxlan dev should inherit lowerdev's gso_max_size" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled vxlan: vxlan dev should inherit lowerdev's gso_max_size to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: vxlan-vxlan-dev-should-inherit-lowerdev-s-gso_max_size.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sun Mar 18 16:55:33 CET 2018 From: Felix Manlunas <felix.manlunas(a)cavium.com> Date: Wed, 29 Mar 2017 17:56:43 -0700 Subject: vxlan: vxlan dev should inherit lowerdev's gso_max_size From: Felix Manlunas <felix.manlunas(a)cavium.com> [ Upstream commit d6acfeb17d030bb3907e77c048b0e7783ad8e5a9 ] vxlan dev currently ignores lowerdev's gso_max_size, which adversely affects TSO performance of liquidio if it's the lowerdev. Egress TCP packets' skb->len often exceed liquidio's advertised gso_max_size. This may happen on other NIC drivers. Fix it by assigning lowerdev's gso_max_size to that of vxlan dev. Might as well do likewise for gso_max_segs. Single flow TSO throughput of liquidio as lowerdev (using iperf3): Before the patch: 139 Mbps After the patch : 8.68 Gbps Percent increase: 6,144 % Signed-off-by: Felix Manlunas <felix.manlunas(a)cavium.com> Signed-off-by: Satanand Burla <satananda.burla(a)cavium.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/vxlan.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/drivers/net/vxlan.c +++ b/drivers/net/vxlan.c @@ -2912,6 +2912,11 @@ static int vxlan_dev_configure(struct ne return -EINVAL; } + if (lowerdev) { + dev->gso_max_size = lowerdev->gso_max_size; + dev->gso_max_segs = lowerdev->gso_max_segs; + } + if (conf->mtu) { err = __vxlan_change_mtu(dev, lowerdev, dst, conf->mtu, false); if (err) Patches currently in stable-queue which might be from felix.manlunas(a)cavium.com are queue-4.9/vxlan-vxlan-dev-should-inherit-lowerdev-s-gso_max_size.patch

7 years, 4 months

1
0
0 0

Patch "video/hdmi: Allow "empty" HDMI infoframes" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled video/hdmi: Allow "empty" HDMI infoframes to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: video-hdmi-allow-empty-hdmi-infoframes.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sun Mar 18 16:55:33 CET 2018 From: "Ville Syrjälä" <ville.syrjala(a)linux.intel.com> Date: Mon, 13 Nov 2017 19:04:18 +0200 Subject: video/hdmi: Allow "empty" HDMI infoframes From: "Ville Syrjälä" <ville.syrjala(a)linux.intel.com> [ Upstream commit 593f4b19a094c4426bd1e1e3cbab87a48bd13c71 ] HDMI 2.0 Appendix F suggest that we should keep sending the infoframe when switching from 3D to 2D mode, even if the infoframe isn't strictly necessary (ie. not needed to transmit the VIC or stereo information). This is a workaround against some sinks that fail to realize that they should switch from 3D to 2D mode when the source stop transmitting the infoframe. v2: Handle unpack() as well Pull the length calculation into a helper Cc: Shashank Sharma <shashank.sharma(a)intel.com> Cc: Andrzej Hajda <a.hajda(a)samsung.com> Cc: Thierry Reding <thierry.reding(a)gmail.com> Cc: Hans Verkuil <hans.verkuil(a)cisco.com> Cc: linux-media(a)vger.kernel.org Reviewed-by: Andrzej Hajda <a.hajda(a)samsung.com> #v1 Signed-off-by: Ville SyrjÃ¤lÃ¤ <ville.syrjala(a)linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171113170427.4150-2-ville.s… Reviewed-by: Shashank Sharma <shashank.sharma(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/video/hdmi.c | 51 +++++++++++++++++++++++++++++++-------------------- 1 file changed, 31 insertions(+), 20 deletions(-) --- a/drivers/video/hdmi.c +++ b/drivers/video/hdmi.c @@ -321,6 +321,17 @@ int hdmi_vendor_infoframe_init(struct hd } EXPORT_SYMBOL(hdmi_vendor_infoframe_init); +static int hdmi_vendor_infoframe_length(const struct hdmi_vendor_infoframe *frame) +{ + /* for side by side (half) we also need to provide 3D_Ext_Data */ + if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF) + return 6; + else if (frame->vic != 0 || frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID) + return 5; + else + return 4; +} + /** * hdmi_vendor_infoframe_pack() - write a HDMI vendor infoframe to binary buffer * @frame: HDMI infoframe @@ -341,19 +352,11 @@ ssize_t hdmi_vendor_infoframe_pack(struc u8 *ptr = buffer; size_t length; - /* empty info frame */ - if (frame->vic == 0 && frame->s3d_struct == HDMI_3D_STRUCTURE_INVALID) - return -EINVAL; - /* only one of those can be supplied */ if (frame->vic != 0 && frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID) return -EINVAL; - /* for side by side (half) we also need to provide 3D_Ext_Data */ - if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF) - frame->length = 6; - else - frame->length = 5; + frame->length = hdmi_vendor_infoframe_length(frame); length = HDMI_INFOFRAME_HEADER_SIZE + frame->length; @@ -372,14 +375,16 @@ ssize_t hdmi_vendor_infoframe_pack(struc ptr[5] = 0x0c; ptr[6] = 0x00; - if (frame->vic) { - ptr[7] = 0x1 << 5; /* video format */ - ptr[8] = frame->vic; - } else { + if (frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID) { ptr[7] = 0x2 << 5; /* video format */ ptr[8] = (frame->s3d_struct & 0xf) << 4; if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF) ptr[9] = (frame->s3d_ext_data & 0xf) << 4; + } else if (frame->vic) { + ptr[7] = 0x1 << 5; /* video format */ + ptr[8] = frame->vic; + } else { + ptr[7] = 0x0 << 5; /* video format */ } hdmi_infoframe_set_checksum(buffer, length); @@ -1161,7 +1166,7 @@ hdmi_vendor_any_infoframe_unpack(union h if (ptr[0] != HDMI_INFOFRAME_TYPE_VENDOR || ptr[1] != 1 || - (ptr[2] != 5 && ptr[2] != 6)) + (ptr[2] != 4 && ptr[2] != 5 && ptr[2] != 6)) return -EINVAL; length = ptr[2]; @@ -1189,16 +1194,22 @@ hdmi_vendor_any_infoframe_unpack(union h hvf->length = length; - if (hdmi_video_format == 0x1) { - hvf->vic = ptr[4]; - } else if (hdmi_video_format == 0x2) { + if (hdmi_video_format == 0x2) { + if (length != 5 && length != 6) + return -EINVAL; hvf->s3d_struct = ptr[4] >> 4; if (hvf->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF) { - if (length == 6) - hvf->s3d_ext_data = ptr[5] >> 4; - else + if (length != 6) return -EINVAL; + hvf->s3d_ext_data = ptr[5] >> 4; } + } else if (hdmi_video_format == 0x1) { + if (length != 5) + return -EINVAL; + hvf->vic = ptr[4]; + } else { + if (length != 4) + return -EINVAL; } return 0; Patches currently in stable-queue which might be from ville.syrjala(a)linux.intel.com are queue-4.9/drm-defer-disabling-the-vblank-irq-until-the-next-interrupt-for-instant-off.patch queue-4.9/video-hdmi-allow-empty-hdmi-infoframes.patch queue-4.9/drm-edid-set-eld-connector-type-in-drm_edid_to_eld.patch

7 years, 4 months

1
0
0 0

Patch "video: ARM CLCD: fix dma allocation size" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled video: ARM CLCD: fix dma allocation size to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: video-arm-clcd-fix-dma-allocation-size.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sun Mar 18 16:55:33 CET 2018 From: Liam Beguin <lbeguin(a)tycoint.com> Date: Fri, 7 Apr 2017 17:03:24 +0200 Subject: video: ARM CLCD: fix dma allocation size From: Liam Beguin <lbeguin(a)tycoint.com> [ Upstream commit 9a1c779e6b06855e41099caa6f15b3b584dfa88c ] This patch forces the frambuffer size to be aligned on kernel pages. During the board startup, the splash screed did appear; the "ts_test" program or our application were not able to start. The following error message was reported: error: failed to map framebuffer device to memory. LinuxFB: driver cannot connect The issue was discovered, on the LPC32xx platform, during the migration of the LCD definition from the board file to the device tree. Signed-off-by: Liam Beguin <lbeguin(a)tycoint.com> Signed-off-by: Sylvain Lemieux <slemieux(a)tycoint.com> Cc: Vladimir Zapolskiy <vz(a)mleia.com> Cc: Russell King <linux(a)armlinux.org.uk> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/video/fbdev/amba-clcd.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/video/fbdev/amba-clcd.c +++ b/drivers/video/fbdev/amba-clcd.c @@ -892,8 +892,8 @@ static int clcdfb_of_dma_setup(struct cl if (err) return err; - framesize = fb->panel->mode.xres * fb->panel->mode.yres * - fb->panel->bpp / 8; + framesize = PAGE_ALIGN(fb->panel->mode.xres * fb->panel->mode.yres * + fb->panel->bpp / 8); fb->fb.screen_base = dma_alloc_coherent(&fb->dev->dev, framesize, &dma, GFP_KERNEL); if (!fb->fb.screen_base) Patches currently in stable-queue which might be from lbeguin(a)tycoint.com are queue-4.9/video-arm-clcd-fix-dma-allocation-size.patch

7 years, 4 months

1
0
0 0

Patch "vfio/spapr_tce: Check kzalloc() return when preregistering memory" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled vfio/spapr_tce: Check kzalloc() return when preregistering memory to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: vfio-spapr_tce-check-kzalloc-return-when-preregistering-memory.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Sun Mar 18 16:55:33 CET 2018 From: Alexey Kardashevskiy <aik(a)ozlabs.ru> Date: Mon, 27 Mar 2017 14:23:40 +1100 Subject: vfio/spapr_tce: Check kzalloc() return when preregistering memory From: Alexey Kardashevskiy <aik(a)ozlabs.ru> [ Upstream commit 3393af24b665cb0aea7353b05e522b03ab1e7d73 ] This adds missing checking for kzalloc() return value. Fixes: 4b6fad7097f8 ("powerpc/mm/iommu, vfio/spapr: Put pages on VFIO container shutdown") Signed-off-by: Alexey Kardashevskiy <aik(a)ozlabs.ru> Reviewed-by: David Gibson <david(a)gibson.dropbear.id.au> Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/vfio/vfio_iommu_spapr_tce.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/drivers/vfio/vfio_iommu_spapr_tce.c +++ b/drivers/vfio/vfio_iommu_spapr_tce.c @@ -195,6 +195,11 @@ static long tce_iommu_register_pages(str return ret; tcemem = kzalloc(sizeof(*tcemem), GFP_KERNEL); + if (!tcemem) { + mm_iommu_put(container->mm, mem); + return -ENOMEM; + } + tcemem->mem = mem; list_add(&tcemem->next, &container->prereg_list); Patches currently in stable-queue which might be from aik(a)ozlabs.ru are queue-4.9/vfio-spapr_tce-check-kzalloc-return-when-preregistering-memory.patch queue-4.9/vfio-powerpc-spapr_tce-enforce-iommu-type-compatibility-check.patch

7 years, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror