--- /dev/null
+From 4ea77014af0d6205b05503d1c7aac6eace11d473 Mon Sep 17 00:00:00 2001
+From: zhongjiang <zhongjiang@huawei.com>
+Date: Mon, 10 Jul 2017 15:52:57 -0700
+Subject: kernel/signal.c: avoid undefined behaviour in kill_something_info
+
+From: zhongjiang <zhongjiang@huawei.com>
+
+commit 4ea77014af0d6205b05503d1c7aac6eace11d473 upstream.
+
+When running kill(72057458746458112, 0) in userspace I hit the following
+issue.
+
+ UBSAN: Undefined behaviour in kernel/signal.c:1462:11
+ negation of -2147483648 cannot be represented in type 'int':
+ CPU: 226 PID: 9849 Comm: test Tainted: G B ---- ------- 3.10.0-327.53.58.70.x86_64_ubsan+ #116
+ Hardware name: Huawei Technologies Co., Ltd. RH8100 V3/BC61PBIA, BIOS BLHSV028 11/11/2014
+ Call Trace:
+ dump_stack+0x19/0x1b
+ ubsan_epilogue+0xd/0x50
+ __ubsan_handle_negate_overflow+0x109/0x14e
+ SYSC_kill+0x43e/0x4d0
+ SyS_kill+0xe/0x10
+ system_call_fastpath+0x16/0x1b
+
+Add code to avoid the UBSAN detection.
+
+[akpm@linux-foundation.org: tweak comment]
+Link: http://lkml.kernel.org/r/1496670008-59084-1-git-send-email-zhongjiang@huawei.com
+Signed-off-by: zhongjiang <zhongjiang@huawei.com>
+Cc: Oleg Nesterov <oleg@redhat.com>
+Cc: Michal Hocko <mhocko@kernel.org>
+Cc: Vlastimil Babka <vbabka@suse.cz>
+Cc: Xishi Qiu <qiuxishi@huawei.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/signal.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/kernel/signal.c
++++ b/kernel/signal.c
+@@ -1435,6 +1435,10 @@ static int kill_something_info(int sig,
+ return ret;
+ }
+
++ /* -INT_MIN is undefined. Exclude this case to avoid a UBSAN warning */
++ if (pid == INT_MIN)
++ return -ESRCH;
++
+ read_lock(&tasklist_lock);
+ if (pid != -1) {
+ ret = __kill_pgrp_info(sig, info,
--- /dev/null
+From 322579dcc865b94b47345ad1b6002ad167f85405 Mon Sep 17 00:00:00 2001
+From: Tejun Heo <tj@kernel.org>
+Date: Tue, 8 May 2018 14:21:56 -0700
+Subject: libata: Blacklist some Sandisk SSDs for NCQ
+
+From: Tejun Heo <tj@kernel.org>
+
+commit 322579dcc865b94b47345ad1b6002ad167f85405 upstream.
+
+Sandisk SSDs SD7SN6S256G and SD8SN8U256G are regularly locking up
+regularly under sustained moderate load with NCQ enabled. Blacklist
+for now.
+
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Reported-by: Dave Jones <davej@codemonkey.org.uk>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/ata/libata-core.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/ata/libata-core.c
++++ b/drivers/ata/libata-core.c
+@@ -4188,6 +4188,10 @@ static const struct ata_blacklist_entry
+ /* https://bugzilla.kernel.org/show_bug.cgi?id=15573 */
+ { "C300-CTFDDAC128MAG", "0001", ATA_HORKAGE_NONCQ, },
+
++ /* Some Sandisk SSDs lock up hard with NCQ enabled. Reported on
++ SD7SN6S256G and SD8SN8U256G */
++ { "SanDisk SD[78]SN*G", NULL, ATA_HORKAGE_NONCQ, },
++
+ /* devices which puke on READ_NATIVE_MAX */
+ { "HDS724040KLSA80", "KFAOA20N", ATA_HORKAGE_BROKEN_HPA, },
+ { "WDC WD3200JD-00KLB0", "WD-WCAMR1130137", ATA_HORKAGE_BROKEN_HPA },
affs_lookup-close-a-race-with-affs_remove_link.patch
aio-fix-io_destroy-2-vs.-lookup_ioctx-race.patch
do-d_instantiate-unlock_new_inode-combinations-safely.patch
+libata-blacklist-some-sandisk-ssds-for-ncq.patch
+xen-swiotlb-fix-the-check-condition-for-xen_swiotlb_free_coherent.patch
+kernel-signal.c-avoid-undefined-behaviour-in-kill_something_info.patch
--- /dev/null
+From 4855c92dbb7b3b85c23e88ab7ca04f99b9677b41 Mon Sep 17 00:00:00 2001
+From: Joe Jin <joe.jin@oracle.com>
+Date: Thu, 17 May 2018 12:33:28 -0700
+Subject: xen-swiotlb: fix the check condition for xen_swiotlb_free_coherent
+
+From: Joe Jin <joe.jin@oracle.com>
+
+commit 4855c92dbb7b3b85c23e88ab7ca04f99b9677b41 upstream.
+
+When run raidconfig from Dom0 we found that the Xen DMA heap is reduced,
+but Dom Heap is increased by the same size. Tracing raidconfig we found
+that the related ioctl() in megaraid_sas will call dma_alloc_coherent()
+to apply memory. If the memory allocated by Dom0 is not in the DMA area,
+it will exchange memory with Xen to meet the requiment. Later drivers
+call dma_free_coherent() to free the memory, on xen_swiotlb_free_coherent()
+the check condition (dev_addr + size - 1 <= dma_mask) is always false,
+it prevents calling xen_destroy_contiguous_region() to return the memory
+to the Xen DMA heap.
+
+This issue introduced by commit 6810df88dcfc2 "xen-swiotlb: When doing
+coherent alloc/dealloc check before swizzling the MFNs.".
+
+Signed-off-by: Joe Jin <joe.jin@oracle.com>
+Tested-by: John Sobecki <john.sobecki@oracle.com>
+Reviewed-by: Rzeszutek Wilk <konrad.wilk@oracle.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/xen/swiotlb-xen.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/xen/swiotlb-xen.c
++++ b/drivers/xen/swiotlb-xen.c
+@@ -366,7 +366,7 @@ xen_swiotlb_free_coherent(struct device
+ * physical address */
+ phys = xen_bus_to_phys(dev_addr);
+
+- if (((dev_addr + size - 1 > dma_mask)) ||
++ if (((dev_addr + size - 1 <= dma_mask)) ||
+ range_straddles_page_boundary(phys, size))
+ xen_destroy_contiguous_region(phys, order);
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
