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

[PATCH] blk-wbt: wake up all when we scale up, not down

by Josef Bacik

Tetsuo brought to my attention that I screwed up the scale_up/scale_down helpers when I factored out the rq-qos code. We need to wake up all the waiters when we add slots for requests to make, not when we shrink the slots. Otherwise we'll end up things waiting forever. This was a mistake and simply puts everything back the way it was. cc: stable(a)vger.kernel.org Fixes: a79050434b45 ("blk-rq-qos: refactor out common elements of blk-wbt") eported-by: Tetsuo Handa <penguin-kernel(a)i-love.sakura.ne.jp> Signed-off-by: Josef Bacik <josef(a)toxicpanda.com> --- JENS! I did this on for-4.20/block FYI block/blk-wbt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/block/blk-wbt.c b/block/blk-wbt.c index 8e20a0677dcf..8ac93fcbaa2e 100644 --- a/block/blk-wbt.c +++ b/block/blk-wbt.c @@ -310,6 +310,7 @@ static void scale_up(struct rq_wb *rwb) rq_depth_scale_up(&rwb->rq_depth); calc_wb_limits(rwb); rwb->unknown_cnt = 0; + rwb_wake_all(rwb); rwb_trace_step(rwb, "scale up"); } @@ -318,7 +319,6 @@ static void scale_down(struct rq_wb *rwb, bool hard_throttle) rq_depth_scale_down(&rwb->rq_depth, hard_throttle); calc_wb_limits(rwb); rwb->unknown_cnt = 0; - rwb_wake_all(rwb); rwb_trace_step(rwb, "scale down"); } -- 2.14.3

6 years, 10 months

2
1
0 0

[PATCH] pci: Add a few new IDs for Intel GPU "spurious interrupt" quirk

by Bin Meng

Add more PCI IDs to the Intel GPU "spurious interrupt" quirk table, which are known to break. See commit f67fd55fa96f ("PCI: Add quirk for still enabled interrupts on Intel Sandy Bridge GPUs"), and commit 7c82126a94e6 ("PCI: Add new ID for Intel GPU "spurious interrupt" quirk") for some history. Based on current findings, it is highly possible that all Intel 1st/2nd/3rd generation Core processors' IGD has such quirk. Signed-off-by: Bin Meng <bmeng.cn(a)gmail.com> Cc: <stable(a)vger.kernel.org> # v3.4+ --- drivers/pci/quirks.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 6bc27b7..c0673a7 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -3190,7 +3190,11 @@ static void disable_igfx_irq(struct pci_dev *dev) pci_iounmap(dev, regs); } +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0042, disable_igfx_irq); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0046, disable_igfx_irq); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x004a, disable_igfx_irq); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0102, disable_igfx_irq); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0106, disable_igfx_irq); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x010a, disable_igfx_irq); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0152, disable_igfx_irq); -- 2.7.4

6 years, 10 months

4
12
0 0

Backports that remove FPU lazy-mode deadcode

by Daniel Sangorrin

Hello Greg, This is my 3rd attempt* at sending to you the FPU backported patches that complete the removal of FPU lazy-mode code, documentation and comments. Please apply the next patch before the 4.4.y 3-patch series. - a1dbf52c1a38 ("KVM: x86: remove eager_fpu field of struct kvm_vcpu_arch") [PATCH v3 4.4.y 1/3] x86/fpu: Remove use_eager_fpu() [PATCH v3 4.4.y 2/3] x86/fpu: Remove struct fpu::counter [PATCH v3 4.4.y 3/3] x86/fpu: Finish excising 'eagerfpu' [Note] I already sent to you a patch backported for 4.9.y (please make sure you follow the annotations). https://www.spinics.net/lists/stable/msg247014.html Thanks, Daniel *Sorry if I mess up again. I am going to use the get_maintainer.pl from the upstream kernel because last time I had some "returned e-mails".

6 years, 10 months

2
4
0 0

Backports that remove FPU lazy-mode deadcode for 4.9.y

by Daniel Sangorrin

Hello Greg, Please consider this backport for 4.9.y. It completes the removal of FPU lazy-mode code, documentation and comments. [PATCH v3 4.9] x86/fpu: Remove use_eager_fpu() After applying the patch, please do the following: - cherry-pick: 3913cc350757 ("x86/fpu: Remove struct fpu::counter") - revert: f09a7b0eead7 ("perf: sync up x86/.../cpufeatures.h") - Because the modification in this patch actually belongs to e63650840e8b ("x86/fpu: Finish excising 'eagerfpu'") - cherry-pick: e63650840e8b ("x86/fpu: Finish excising 'eagerfpu'") Thanks, Daniel

6 years, 10 months

3
4
0 0

[PATCH] selinux: fix byte order and alignment issues in policydb.c

by Ondrej Mosnacek

Add missing LE conversions to the Infiniband-related range checks. These were causing a failure to load any policy with an ibendportcon rule on BE systems. Also, the temporary buffers are only guaranteed to be aligned for 32-bit access so use (get/put)_unaligned_be64() for 64-bit accesses. Finally, do not use the 'nodebuf' (u32) buffer where 'buf' (__le32) should be used instead. Tested internally on a ppc64 machine with a RHEL 7 kernel with this patch applied. Cc: Daniel Jurgens <danielj(a)mellanox.com> Cc: Eli Cohen <eli(a)mellanox.com> Cc: James Morris <james.l.morris(a)oracle.com> Cc: Doug Ledford <dledford(a)redhat.com> Cc: <stable(a)vger.kernel.org> # 4.13+ Fixes: a806f7a1616f ("selinux: Create policydb version for Infiniband support") Signed-off-by: Ondrej Mosnacek <omosnace(a)redhat.com> --- security/selinux/ss/policydb.c | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/security/selinux/ss/policydb.c b/security/selinux/ss/policydb.c index f4eadd3f7350..2b310e8f2923 100644 --- a/security/selinux/ss/policydb.c +++ b/security/selinux/ss/policydb.c @@ -37,6 +37,7 @@ #include <linux/errno.h> #include <linux/audit.h> #include <linux/flex_array.h> +#include <asm/unaligned.h> #include "security.h" #include "policydb.h" @@ -2108,7 +2109,7 @@ static int ocontext_read(struct policydb *p, struct policydb_compat_info *info, { int i, j, rc; u32 nel, len; - __le32 buf[3]; + __le32 buf[4]; struct ocontext *l, *c; u32 nodebuf[8]; @@ -2218,20 +2219,20 @@ static int ocontext_read(struct policydb *p, struct policydb_compat_info *info, break; } case OCON_IBPKEY: - rc = next_entry(nodebuf, fp, sizeof(u32) * 4); + rc = next_entry(buf, fp, sizeof(u32) * 4); if (rc) goto out; - c->u.ibpkey.subnet_prefix = be64_to_cpu(*((__be64 *)nodebuf)); + c->u.ibpkey.subnet_prefix = get_unaligned_be64(buf); - if (nodebuf[2] > 0xffff || - nodebuf[3] > 0xffff) { + if (le32_to_cpu(buf[2]) > 0xffff || + le32_to_cpu(buf[3]) > 0xffff) { rc = -EINVAL; goto out; } - c->u.ibpkey.low_pkey = le32_to_cpu(nodebuf[2]); - c->u.ibpkey.high_pkey = le32_to_cpu(nodebuf[3]); + c->u.ibpkey.low_pkey = le32_to_cpu(buf[2]); + c->u.ibpkey.high_pkey = le32_to_cpu(buf[3]); rc = context_read_and_validate(&c->context[0], p, @@ -2249,7 +2250,8 @@ static int ocontext_read(struct policydb *p, struct policydb_compat_info *info, if (rc) goto out; - if (buf[1] > 0xff || buf[1] == 0) { + if (le32_to_cpu(buf[1]) > 0xff || + le32_to_cpu(buf[1]) == 0) { rc = -EINVAL; goto out; } @@ -3105,7 +3107,7 @@ static int ocontext_write(struct policydb *p, struct policydb_compat_info *info, { unsigned int i, j, rc; size_t nel, len; - __le32 buf[3]; + __le32 buf[4]; u32 nodebuf[8]; struct ocontext *c; for (i = 0; i < info->ocon_num; i++) { @@ -3192,12 +3194,12 @@ static int ocontext_write(struct policydb *p, struct policydb_compat_info *info, return rc; break; case OCON_IBPKEY: - *((__be64 *)nodebuf) = cpu_to_be64(c->u.ibpkey.subnet_prefix); + put_unaligned_be64(c->u.ibpkey.subnet_prefix, buf); - nodebuf[2] = cpu_to_le32(c->u.ibpkey.low_pkey); - nodebuf[3] = cpu_to_le32(c->u.ibpkey.high_pkey); + buf[2] = cpu_to_le32(c->u.ibpkey.low_pkey); + buf[3] = cpu_to_le32(c->u.ibpkey.high_pkey); - rc = put_entry(nodebuf, sizeof(u32), 4, fp); + rc = put_entry(buf, sizeof(u32), 4, fp); if (rc) return rc; rc = context_write(p, &c->context[0], fp); -- 2.17.1

6 years, 10 months

1
0
0 0

[for -stable] commit "c82919888064 ath10k: fix scan crash due to incorrect length calculation"

by Brian Norris

Hi Greg / stable maintainer(s), IIUC, this commit is a good candidate for -stable. I just hit the bug on 4.14, because of new vendor firmware that noticed the mismatched length (an internal "assert"), but it seems like this is equally problematic from the kernel side for as long as this code existed [1]: commit c8291988806407e02a01b4b15b4504eafbcc04e0 Author: Zhi Chen <zhichen(a)codeaurora.org> Date: Mon Jun 18 17:00:39 2018 +0300 ath10k: fix scan crash due to incorrect length calculation Thanks, Brian [1] I guess that would be: Fixes: ca996ec56608 ("ath10k: implement wmi-tlv backend") which was in v4.0.

6 years, 10 months

3
2
0 0

request for 4.14-stable: c7cdff0e8647 ("virtio_balloon: fix deadlock on OOM")

by Sudip Mukherjee

Hi Greg, This was not marked for stable but seems it should be in stable. Please apply to your queue of 4.14-stable. And at the same time, there was another later patch which fixed a bug in this patch. Both are attached as a series to this mail. -- Regards Sudip

6 years, 10 months

2
1
0 0

[PATCH stable 4.4 V2 0/6] fix SegmentSmack in stable branch (CVE-2018-5390)

by Mao Wenan

There are five patches to fix CVE-2018-5390 in latest mainline branch, but only two patches exist in stable 4.4 and 3.18: dc6ae4d tcp: detect malicious patterns in tcp_collapse_ofo_queue() 5fbec48 tcp: avoid collapses in tcp_prune_queue() if possible I have tested with stable 4.4 kernel, and found the cpu usage was very high. So I think only two patches can't fix the CVE-2018-5390. test results: with fix patch： 78.2% ksoftirqd withoutfix patch： 90% ksoftirqd Then I try to imitate 72cd43ba(tcp: free batches of packets in tcp_prune_ofo_queue()) to drop at least 12.5 % of sk_rcvbuf to avoid malicious attacks with simple queue instead of RB tree. The result is not very well. After analysing the codes of stable 4.4, and debuging the system, shows that search of ofo_queue(tcp ofo using a simple queue) cost more cycles. So I try to backport "tcp: use an RB tree for ooo receive queue" using RB tree instead of simple queue, then backport Eric Dumazet 5 fixed patches in mainline, good news is that ksoftirqd is turn to about 20%, which is the same with mainline now. Stable 4.4 have already back port two patches, f4a3313d(tcp: avoid collapses in tcp_prune_queue() if possible) 3d4bf93a(tcp: detect malicious patterns in tcp_collapse_ofo_queue()) If we want to change simple queue to RB tree to finally resolve, we should apply previous patch 9f5afeae(tcp: use an RB tree for ooo receive queue.) firstly, but 9f5afeae have many conflicts with 3d4bf93a and f4a3313d, which are part of patch series from Eric in mainline to fix CVE-2018-5390, so I need revert part of patches in stable 4.4 firstly, then apply 9f5afeae, and reapply five patches from Eric. V1->V2: 1) Don't revert 3d4bf93a and f4a3313d firstly, all of 6 patches based on 4.4.155. 2) Add one bug fix patch for RB tree:76f0dcbb5ae1a7c3dbeec13dd98233b8e6b0b32a tcp: fix a stale ooo_last_skb Eric Dumazet (5): tcp: increment sk_drops for dropped rx packets tcp: fix a stale ooo_last_skb after a replace tcp: free batches of packets in tcp_prune_ofo_queue() tcp: call tcp_drop() from tcp_data_queue_ofo() tcp: add tcp_ooo_try_coalesce() helper Yaogong Wang (1): tcp: use an RB tree for ooo receive queue include/linux/skbuff.h | 8 + include/linux/tcp.h | 7 +- include/net/sock.h | 7 + include/net/tcp.h | 2 +- net/core/skbuff.c | 19 +++ net/ipv4/tcp.c | 4 +- net/ipv4/tcp_input.c | 417 +++++++++++++++++++++++++++++------------------ net/ipv4/tcp_ipv4.c | 3 +- net/ipv4/tcp_minisocks.c | 1 - net/ipv6/tcp_ipv6.c | 1 + 10 files changed, 297 insertions(+), 172 deletions(-) -- 1.8.3.1

6 years, 10 months

3
9
0 0

[PATCH 4.4-stable] jffs2: return -ERANGE when xattr buffer is too small

by Hou Tao

Hi Greg, The problem had been fixed by 764a5c6b1fa4 ("xattr handlers: Simplify list operation") in v4.5-rc1, but the modification in that commit may be too much because it modifies all file-systems which implement xattr, so I create a single patch for jffs2 to fix the problem. Which one is your preference ? Hi Andreas, Could you please help review the patch ? Thanks, Tao --- From: Hou Tao <houtao1(a)huawei.com> When a file have multiple xattrs and the passed buffer is smaller than the required size, jffs2_listxattr() should return -ERANGE instead of continue, else Oops may occurs due to memory corruption. Also remove the unnecessary check ("rc < 0"), because xhandle->list(...) will not return an error number. Spotted by generic/377 in xfstests-dev. Signed-off-by: Hou Tao <houtao1(a)huawei.com> --- fs/jffs2/xattr.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/fs/jffs2/xattr.c b/fs/jffs2/xattr.c index 4c2c03663533..8e1427762eeb 100644 --- a/fs/jffs2/xattr.c +++ b/fs/jffs2/xattr.c @@ -1004,12 +1004,14 @@ ssize_t jffs2_listxattr(struct dentry *dentry, char *buffer, size_t size) rc = xhandle->list(xhandle, dentry, buffer + len, size - len, xd->xname, xd->name_len); + if (rc > size - len) { + rc = -ERANGE; + goto out; + } } else { rc = xhandle->list(xhandle, dentry, NULL, 0, xd->xname, xd->name_len); } - if (rc < 0) - goto out; len += rc; } rc = len; --

6 years, 10 months

2
1
0 0

[PATCH] HID: wacom: Work around HID descriptor bug in DTK-2451 and DTH-2452

by Jason Gerecke

The DTK-2451 and DTH-2452 have a buggy HID descriptor which incorrectly contains a Cintiq-like report, complete with pen tilt, rotation, twist, serial number, etc. The hardware doesn't actually support this data but our driver duitifully sets up the device as though it does. To ensure userspace has a correct view of devices without updated firmware, we clean up this incorrect data in wacom_setup_device_quirks. We're also careful to clear the WACOM_QUIRK_TOOLSERIAL flag since its presence causes the driver to wait for serial number information (via wacom_wac_pen_serial_enforce) that never comes, resulting in the pen being non-responsive. Signed-off-by: Jason Gerecke <jason.gerecke(a)wacom.com> Fixes: 8341720642 ("HID: wacom: Queue events with missing type/serial data for later processing") Cc: stable(a)vger.kernel.org # v4.16+ --- drivers/hid/wacom_wac.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c index e0a06be5ef5c..b4b4a30e3982 100644 --- a/drivers/hid/wacom_wac.c +++ b/drivers/hid/wacom_wac.c @@ -3335,6 +3335,7 @@ static void wacom_setup_intuos(struct wacom_wac *wacom_wac) void wacom_setup_device_quirks(struct wacom *wacom) { + struct wacom_wac *wacom_wac = &wacom->wacom_wac; struct wacom_features *features = &wacom->wacom_wac.features; /* The pen and pad share the same interface on most devices */ @@ -3464,6 +3465,25 @@ void wacom_setup_device_quirks(struct wacom *wacom) if (features->type == REMOTE) features->device_type |= WACOM_DEVICETYPE_WL_MONITOR; + + /* HID descriptor for DTK-2451 / DTH-2452 claims to report lots + * of things it shouldn't. Lets fix up the damage... + */ + if (wacom->hdev->product == 0x382 || wacom->hdev->product == 0x37d) { + features->quirks &= ~WACOM_QUIRK_TOOLSERIAL; + __clear_bit(BTN_TOOL_BRUSH, wacom_wac->pen_input->keybit); + __clear_bit(BTN_TOOL_PENCIL, wacom_wac->pen_input->keybit); + __clear_bit(BTN_TOOL_AIRBRUSH, wacom_wac->pen_input->keybit); + __clear_bit(ABS_Z, wacom_wac->pen_input->absbit); + __clear_bit(ABS_DISTANCE, wacom_wac->pen_input->absbit); + __clear_bit(ABS_TILT_X, wacom_wac->pen_input->absbit); + __clear_bit(ABS_TILT_Y, wacom_wac->pen_input->absbit); + __clear_bit(ABS_WHEEL, wacom_wac->pen_input->absbit); + __clear_bit(ABS_MISC, wacom_wac->pen_input->absbit); + __clear_bit(MSC_SERIAL, wacom_wac->pen_input->mscbit); + __clear_bit(EV_MSC, wacom_wac->pen_input->evbit); + } } int wacom_setup_pen_input_capabilities(struct input_dev *input_dev, -- 2.19.1

6 years, 10 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror