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

[PATCH] mm/memblock: fix potential issue in memblock_search_pfn_nid()

by Wei Yang

memblock_search_pfn_nid() returns the nid and the [start|end]_pfn of the memory region where pfn sits in. While the calculation of start_pfn has potential issue when the regions base is not page aligned. For example, we assume PAGE_SHIFT is 12 and base is 0x1234. Current implementation would return 1 while this is not correct. This patch fixes this by using PFN_UP(). The original commit is commit e76b63f80d93 ("memblock, numa: binary search node id") and merged in v3.12. Signed-off-by: Wei Yang <richard.weiyang(a)gmail.com> Cc: 3.12+ <stable(a)vger.kernel.org> --- * add He Jia in cc * fix the mm mail list address * Cc: 3.12+ --- mm/memblock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/memblock.c b/mm/memblock.c index b6ba6b7adadc..de768307696d 100644 --- a/mm/memblock.c +++ b/mm/memblock.c @@ -1673,7 +1673,7 @@ int __init_memblock memblock_search_pfn_nid(unsigned long pfn, if (mid == -1) return -1; - *start_pfn = PFN_DOWN(type->regions[mid].base); + *start_pfn = PFN_UP(type->regions[mid].base); *end_pfn = PFN_DOWN(type->regions[mid].base + type->regions[mid].size); return type->regions[mid].nid; -- 2.15.1

7 years, 6 months

3
6
0 0

[patch 076/119] mm: hwpoison: disable memory error handling on 1GB hugepage

by akpm＠linux-foundation.org

From: Naoya Horiguchi <n-horiguchi(a)ah.jp.nec.com> Subject: mm: hwpoison: disable memory error handling on 1GB hugepage Recently the following BUG was reported: Injecting memory failure for pfn 0x3c0000 at process virtual address 0x7fe300000000 Memory failure: 0x3c0000: recovery action for huge page: Recovered BUG: unable to handle kernel paging request at ffff8dfcc0003000 IP: gup_pgd_range+0x1f0/0xc20 PGD 17ae72067 P4D 17ae72067 PUD 0 Oops: 0000 [#1] SMP PTI ... CPU: 3 PID: 5467 Comm: hugetlb_1gb Not tainted 4.15.0-rc8-mm1-abc+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-1.fc25 04/01/2014 You can easily reproduce this by calling madvise(MADV_HWPOISON) twice on a 1GB hugepage. This happens because get_user_pages_fast() is not aware of a migration entry on pud that was created in the 1st madvise() event. I think that conversion to pud-aligned migration entry is working, but other MM code walking over page table isn't prepared for it. We need some time and effort to make all this work properly, so this patch avoids the reported bug by just disabling error handling for 1GB hugepage. [n-horiguchi(a)ah.jp.nec.com: v2] Link: http://lkml.kernel.org/r/1517284444-18149-1-git-send-email-n-horiguchi@ah.j… Link: http://lkml.kernel.org/r/1517207283-15769-1-git-send-email-n-horiguchi@ah.j… Signed-off-by: Naoya Horiguchi <n-horiguchi(a)ah.jp.nec.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org> Reviewed-by: Mike Kravetz <mike.kravetz(a)oracle.com> Acked-by: Punit Agrawal <punit.agrawal(a)arm.com> Tested-by: Michael Ellerman <mpe(a)ellerman.id.au> Cc: Anshuman Khandual <khandual(a)linux.vnet.ibm.com> Cc: "Aneesh Kumar K.V" <aneesh.kumar(a)linux.vnet.ibm.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/mm.h | 1 + mm/memory-failure.c | 16 ++++++++++++++++ 2 files changed, 17 insertions(+) diff -puN include/linux/mm.h~mm-hwpoison-disable-memory-error-handling-on-1gb-hugepage include/linux/mm.h --- a/include/linux/mm.h~mm-hwpoison-disable-memory-error-handling-on-1gb-hugepage +++ a/include/linux/mm.h @@ -2613,6 +2613,7 @@ enum mf_action_page_type { MF_MSG_POISONED_HUGE, MF_MSG_HUGE, MF_MSG_FREE_HUGE, + MF_MSG_NON_PMD_HUGE, MF_MSG_UNMAP_FAILED, MF_MSG_DIRTY_SWAPCACHE, MF_MSG_CLEAN_SWAPCACHE, diff -puN mm/memory-failure.c~mm-hwpoison-disable-memory-error-handling-on-1gb-hugepage mm/memory-failure.c --- a/mm/memory-failure.c~mm-hwpoison-disable-memory-error-handling-on-1gb-hugepage +++ a/mm/memory-failure.c @@ -502,6 +502,7 @@ static const char * const action_page_ty [MF_MSG_POISONED_HUGE] = "huge page already hardware poisoned", [MF_MSG_HUGE] = "huge page", [MF_MSG_FREE_HUGE] = "free huge page", + [MF_MSG_NON_PMD_HUGE] = "non-pmd-sized huge page", [MF_MSG_UNMAP_FAILED] = "unmapping failed page", [MF_MSG_DIRTY_SWAPCACHE] = "dirty swapcache page", [MF_MSG_CLEAN_SWAPCACHE] = "clean swapcache page", @@ -1084,6 +1085,21 @@ static int memory_failure_hugetlb(unsign return 0; } + /* + * TODO: hwpoison for pud-sized hugetlb doesn't work right now, so + * simply disable it. In order to make it work properly, we need + * make sure that: + * - conversion of a pud that maps an error hugetlb into hwpoison + * entry properly works, and + * - other mm code walking over page table is aware of pud-aligned + * hwpoison entries. + */ + if (huge_page_size(page_hstate(head)) > PMD_SIZE) { + action_result(pfn, MF_MSG_NON_PMD_HUGE, MF_IGNORED); + res = -EBUSY; + goto out; + } + if (!hwpoison_user_mappings(p, pfn, flags, &head)) { action_result(pfn, MF_MSG_UNMAP_FAILED, MF_IGNORED); res = -EBUSY; _

7 years, 6 months

1
0
0 0

[patch 003/119] lib: fix stall in __bitmap_parselist()

by akpm＠linux-foundation.org

From: Yury Norov <ynorov(a)caviumnetworks.com> Subject: lib: fix stall in __bitmap_parselist() syzbot is catching stalls at __bitmap_parselist() (https://syzkaller.appspot.com/bug?id=ad7e0351fbc90535558514a71cd3edc1168199…). The trigger is unsigned long v = 0; bitmap_parselist("7:,", &v, BITS_PER_LONG); which results in hitting infinite loop at while (a <= b) { off = min(b - a + 1, used_size); bitmap_set(maskp, a, off); a += group_size; } due to used_size == group_size == 0. Link: http://lkml.kernel.org/r/20180404162647.15763-1-ynorov@caviumnetworks.com Fixes: 0a5ce0831d04382a ("lib/bitmap.c: make bitmap_parselist() thread-safe and much faster") Signed-off-by: Yury Norov <ynorov(a)caviumnetworks.com> Reported-by: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> Reported-by: syzbot <syzbot+6887cbb011c8054e8a3d(a)syzkaller.appspotmail.com> Cc: Noam Camus <noamca(a)mellanox.com> Cc: Rasmus Villemoes <linux(a)rasmusvillemoes.dk> Cc: Matthew Wilcox <mawilcox(a)microsoft.com> Cc: Mauro Carvalho Chehab <mchehab(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- lib/bitmap.c | 2 +- lib/test_bitmap.c | 4 ++++ 2 files changed, 5 insertions(+), 1 deletion(-) diff -puN lib/bitmap.c~lib-fix-stall-in-__bitmap_parselist lib/bitmap.c --- a/lib/bitmap.c~lib-fix-stall-in-__bitmap_parselist +++ a/lib/bitmap.c @@ -607,7 +607,7 @@ static int __bitmap_parselist(const char /* if no digit is after '-', it's wrong*/ if (at_start && in_range) return -EINVAL; - if (!(a <= b) || !(used_size <= group_size)) + if (!(a <= b) || group_size == 0 || !(used_size <= group_size)) return -EINVAL; if (b >= nmaskbits) return -ERANGE; diff -puN lib/test_bitmap.c~lib-fix-stall-in-__bitmap_parselist lib/test_bitmap.c --- a/lib/test_bitmap.c~lib-fix-stall-in-__bitmap_parselist +++ a/lib/test_bitmap.c @@ -255,6 +255,10 @@ static const struct test_bitmap_parselis {-EINVAL, "-1", NULL, 8, 0}, {-EINVAL, "-0", NULL, 8, 0}, {-EINVAL, "10-1", NULL, 8, 0}, + {-EINVAL, "0-31:", NULL, 8, 0}, + {-EINVAL, "0-31:0", NULL, 8, 0}, + {-EINVAL, "0-31:0/0", NULL, 8, 0}, + {-EINVAL, "0-31:1/0", NULL, 8, 0}, {-EINVAL, "0-31:10/1", NULL, 8, 0}, }; _

7 years, 6 months

1
0
0 0

[patch 002/119] hugetlbfs: fix bug in pgoff overflow checking

by akpm＠linux-foundation.org

From: Mike Kravetz <mike.kravetz(a)oracle.com> Subject: hugetlbfs: fix bug in pgoff overflow checking This is a fix for a regression in 32 bit kernels caused by an invalid check for pgoff overflow in hugetlbfs mmap setup. The check incorrectly specified that the size of a loff_t was the same as the size of a long. The regression prevents mapping hugetlbfs files at offsets greater than 4GB on 32 bit kernels. On 32 bit kernels conversion from a page based unsigned long can not overflow a loff_t byte offset. Therefore, skip this check if sizeof(unsigned long) != sizeof(loff_t). Link: http://lkml.kernel.org/r/20180330145402.5053-1-mike.kravetz@oracle.com Fixes: 63489f8e8211 ("hugetlbfs: check for pgoff value overflow") Reported-by: Dan Rue <dan.rue(a)linaro.org> Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com> Tested-by: Anders Roxell <anders.roxell(a)linaro.org> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: Yisheng Xie <xieyisheng1(a)huawei.com> Cc: "Kirill A . Shutemov" <kirill.shutemov(a)linux.intel.com> Cc: Nic Losby <blurbdust(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/hugetlbfs/inode.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff -puN fs/hugetlbfs/inode.c~hugetlbfs-fix-bug-in-pgoff-overflow-checking fs/hugetlbfs/inode.c --- a/fs/hugetlbfs/inode.c~hugetlbfs-fix-bug-in-pgoff-overflow-checking +++ a/fs/hugetlbfs/inode.c @@ -138,10 +138,14 @@ static int hugetlbfs_file_mmap(struct fi /* * page based offset in vm_pgoff could be sufficiently large to - * overflow a (l)off_t when converted to byte offset. + * overflow a loff_t when converted to byte offset. This can + * only happen on architectures where sizeof(loff_t) == + * sizeof(unsigned long). So, only check in those instances. */ - if (vma->vm_pgoff & PGOFF_LOFFT_MAX) - return -EINVAL; + if (sizeof(unsigned long) == sizeof(loff_t)) { + if (vma->vm_pgoff & PGOFF_LOFFT_MAX) + return -EINVAL; + } /* must be huge page aligned */ if (vma->vm_pgoff & (~huge_page_mask(h) >> PAGE_SHIFT)) _

7 years, 6 months

1
0
0 0

[patch 001/119] zboot: fix stack protector in compressed boot phase

by akpm＠linux-foundation.org

From: Huacai Chen <chenhc(a)lemote.com> Subject: zboot: fix stack protector in compressed boot phase Call __stack_chk_guard_setup() in decompress_kernel() is too late that stack checking always fails for decompress_kernel() itself. So remove __stack_chk_guard_setup() and initialize __stack_chk_guard before we call decompress_kernel(). Original code comes from ARM but also used for MIPS and SH, so fix them together. If without this fix, compressed booting of these archs will fail because stack checking is enabled by default (>=4.16). Link: http://lkml.kernel.org/r/1522226933-29317-1-git-send-email-chenhc@lemote.com Fixes: 8779657d29c0 ("stackprotector: Introduce CONFIG_CC_STACKPROTECTOR_STRONG") Signed-off-by: Huacai Chen <chenhc(a)lemote.com> Acked-by: James Hogan <jhogan(a)kernel.org> Acked-by: Kees Cook <keescook(a)chromium.org> Acked-by: Rich Felker <dalias(a)libc.org> Cc: Ralf Baechle <ralf(a)linux-mips.org> Cc: Russell King <linux(a)arm.linux.org.uk> Cc: Yoshinori Sato <ysato(a)users.sourceforge.jp> Cc: Ingo Molnar <mingo(a)elte.hu> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- arch/arm/boot/compressed/misc.c | 9 +-------- arch/mips/boot/compressed/decompress.c | 9 +-------- arch/sh/boot/compressed/misc.c | 9 +-------- 3 files changed, 3 insertions(+), 24 deletions(-) diff -puN arch/arm/boot/compressed/misc.c~zboot-fix-stack-protector-in-compressed-boot-phase arch/arm/boot/compressed/misc.c --- a/arch/arm/boot/compressed/misc.c~zboot-fix-stack-protector-in-compressed-boot-phase +++ a/arch/arm/boot/compressed/misc.c @@ -128,12 +128,7 @@ asmlinkage void __div0(void) error("Attempting division by 0!"); } -unsigned long __stack_chk_guard; - -void __stack_chk_guard_setup(void) -{ - __stack_chk_guard = 0x000a0dff; -} +const unsigned long __stack_chk_guard = 0x000a0dff; void __stack_chk_fail(void) { @@ -150,8 +145,6 @@ decompress_kernel(unsigned long output_s { int ret; - __stack_chk_guard_setup(); - output_data = (unsigned char *)output_start; free_mem_ptr = free_mem_ptr_p; free_mem_end_ptr = free_mem_ptr_end_p; diff -puN arch/mips/boot/compressed/decompress.c~zboot-fix-stack-protector-in-compressed-boot-phase arch/mips/boot/compressed/decompress.c --- a/arch/mips/boot/compressed/decompress.c~zboot-fix-stack-protector-in-compressed-boot-phase +++ a/arch/mips/boot/compressed/decompress.c @@ -76,12 +76,7 @@ void error(char *x) #include "../../../../lib/decompress_unxz.c" #endif -unsigned long __stack_chk_guard; - -void __stack_chk_guard_setup(void) -{ - __stack_chk_guard = 0x000a0dff; -} +const unsigned long __stack_chk_guard = 0x000a0dff; void __stack_chk_fail(void) { @@ -92,8 +87,6 @@ void decompress_kernel(unsigned long boo { unsigned long zimage_start, zimage_size; - __stack_chk_guard_setup(); - zimage_start = (unsigned long)(&__image_begin); zimage_size = (unsigned long)(&__image_end) - (unsigned long)(&__image_begin); diff -puN arch/sh/boot/compressed/misc.c~zboot-fix-stack-protector-in-compressed-boot-phase arch/sh/boot/compressed/misc.c --- a/arch/sh/boot/compressed/misc.c~zboot-fix-stack-protector-in-compressed-boot-phase +++ a/arch/sh/boot/compressed/misc.c @@ -104,12 +104,7 @@ static void error(char *x) while(1); /* Halt */ } -unsigned long __stack_chk_guard; - -void __stack_chk_guard_setup(void) -{ - __stack_chk_guard = 0x000a0dff; -} +const unsigned long __stack_chk_guard = 0x000a0dff; void __stack_chk_fail(void) { @@ -130,8 +125,6 @@ void decompress_kernel(void) { unsigned long output_addr; - __stack_chk_guard_setup(); - #ifdef CONFIG_SUPERH64 output_addr = (CONFIG_MEMORY_START + 0x2000); #else _

7 years, 6 months

1
0
0 0

[PATCH v2 2/3] gup: return -EFAULT on access_ok failure

by Michael S. Tsirkin

get_user_pages_fast is supposed to be a faster drop-in equivalent of get_user_pages. As such, callers expect it to return a negative return code when passed an invalid address, and never expect it to return 0 when passed a positive number of pages, since its documentation says: * Returns number of pages pinned. This may be fewer than the number * requested. If nr_pages is 0 or negative, returns 0. If no pages * were pinned, returns -errno. When get_user_pages_fast fall back on get_user_pages this is exactly what happens. Unfortunately the implementation is inconsistent: it returns 0 if passed a kernel address, confusing callers: for example, the following is pretty common but does not appear to do the right thing with a kernel address: ret = get_user_pages_fast(addr, 1, writeable, &page); if (ret < 0) return ret; Change get_user_pages_fast to return -EFAULT when supplied a kernel address to make it match expectations. All caller have been audited for consistency with the documented semantics. Lightly tested. Cc: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Huang Ying <ying.huang(a)intel.com> Cc: Jonathan Corbet <corbet(a)lwn.net> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Thorsten Leemhuis <regressions(a)leemhuis.info> Cc: stable(a)vger.kernel.org Fixes: 5b65c4677a57 ("mm, x86/mm: Fix performance regression in get_user_pages_fast()") Reported-by: syzbot+6304bf97ef436580fede(a)syzkaller.appspotmail.com Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> --- mm/gup.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/mm/gup.c b/mm/gup.c index 6afae32..8f3a064 100644 --- a/mm/gup.c +++ b/mm/gup.c @@ -1806,9 +1806,12 @@ int get_user_pages_fast(unsigned long start, int nr_pages, int write, len = (unsigned long) nr_pages << PAGE_SHIFT; end = start + len; + if (nr_pages <= 0) + return 0; + if (unlikely(!access_ok(write ? VERIFY_WRITE : VERIFY_READ, (void __user *)start, len))) - return 0; + return -EFAULT; if (gup_fast_permitted(start, nr_pages, write)) { local_irq_disable(); -- MST

7 years, 6 months

1
0
0 0

Patch "Bluetooth: hci_bcm: Add 6 new ACPI HIDs" has been added to the 4.16-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Bluetooth: hci_bcm: Add 6 new ACPI HIDs to the 4.16-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: bluetooth-hci_bcm-add-6-new-acpi-hids.patch and it can be found in the queue-4.16 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 4063cafa3b24ff04635bdedc97cd3e4320415065 Mon Sep 17 00:00:00 2001 From: Hans de Goede <hdegoede(a)redhat.com> Date: Fri, 16 Mar 2018 21:28:09 +0100 Subject: Bluetooth: hci_bcm: Add 6 new ACPI HIDs From: Hans de Goede <hdegoede(a)redhat.com> commit 4063cafa3b24ff04635bdedc97cd3e4320415065 upstream. Add 6 new ACPI HIDs to enable bluetooth on devices using these HIDs, I've tested the following HIDs / devices: BCM2E74: Jumper ezPad mini 3 BCM2E83: Acer Iconia Tab8 w1-810 BCM2E90: Meegopad T08 BCM2EAA: Chuwi Vi8 plus (CWI519) The reporter of Red Hat bugzilla 1554835 has tested: BCM2E84: Lenovo Yoga2 The reporter of kernel bugzilla 274481 has tested: BCM2E38: Toshiba Encore Note the Lenovo Yoga2 and Toshiba Encore also needs the earlier patch to treat all Interrupt ACPI resources as active low. Cc: stable(a)vger.kernel.org Buglink: https://bugzilla.kernel.org/attachment.cgi?id=274481 Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1554835 Reported-and-tested-by: Robert R. Howell <rhowell(a)uwyo.edu> Reported-and-tested-by: Christian Herzog <daduke(a)daduke.org> Tested-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/bluetooth/hci_bcm.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/drivers/bluetooth/hci_bcm.c +++ b/drivers/bluetooth/hci_bcm.c @@ -1080,6 +1080,7 @@ static const struct hci_uart_proto bcm_p #ifdef CONFIG_ACPI static const struct acpi_device_id bcm_acpi_match[] = { { "BCM2E1A", (kernel_ulong_t)&acpi_bcm_int_last_gpios }, + { "BCM2E38", (kernel_ulong_t)&acpi_bcm_int_last_gpios }, { "BCM2E39", (kernel_ulong_t)&acpi_bcm_int_last_gpios }, { "BCM2E3A", (kernel_ulong_t)&acpi_bcm_int_last_gpios }, { "BCM2E3D", (kernel_ulong_t)&acpi_bcm_int_last_gpios }, @@ -1092,12 +1093,17 @@ static const struct acpi_device_id bcm_a { "BCM2E67", (kernel_ulong_t)&acpi_bcm_int_last_gpios }, { "BCM2E71", (kernel_ulong_t)&acpi_bcm_int_last_gpios }, { "BCM2E72", (kernel_ulong_t)&acpi_bcm_int_last_gpios }, + { "BCM2E74", (kernel_ulong_t)&acpi_bcm_int_last_gpios }, { "BCM2E7B", (kernel_ulong_t)&acpi_bcm_int_last_gpios }, { "BCM2E7C", (kernel_ulong_t)&acpi_bcm_int_last_gpios }, { "BCM2E7E", (kernel_ulong_t)&acpi_bcm_int_first_gpios }, + { "BCM2E83", (kernel_ulong_t)&acpi_bcm_int_first_gpios }, + { "BCM2E84", (kernel_ulong_t)&acpi_bcm_int_last_gpios }, + { "BCM2E90", (kernel_ulong_t)&acpi_bcm_int_last_gpios }, { "BCM2E95", (kernel_ulong_t)&acpi_bcm_int_first_gpios }, { "BCM2E96", (kernel_ulong_t)&acpi_bcm_int_first_gpios }, { "BCM2EA4", (kernel_ulong_t)&acpi_bcm_int_first_gpios }, + { "BCM2EAA", (kernel_ulong_t)&acpi_bcm_int_first_gpios }, { }, }; MODULE_DEVICE_TABLE(acpi, bcm_acpi_match); Patches currently in stable-queue which might be from hdegoede(a)redhat.com are queue-4.16/bluetooth-hci_bcm-add-6-new-acpi-hids.patch

7 years, 6 months

1
0
0 0

[PATCH] libata: blacklist Micron 500IT SSD with MU01 firmware

by Sudip Mukherjee

While whitelisting Micron M500DC drives, the tweaked blacklist entry enabled queued TRIM from M500IT variants also. But these do not support queued TRIM. And while using those SSDs with the latest kernel we have seen errors and even the partition table getting corrupted. Some part from the dmesg: [ 6.727384] ata1.00: ATA-9: Micron_M500IT_MTFDDAK060MBD, MU01, max UDMA/133 [ 6.727390] ata1.00: 117231408 sectors, multi 16: LBA48 NCQ (depth 31/32), AA [ 6.741026] ata1.00: supports DRM functions and may not be fully accessible [ 6.759887] ata1.00: configured for UDMA/133 [ 6.762256] scsi 0:0:0:0: Direct-Access ATA Micron_M500IT_MT MU01 PQ: 0 ANSI: 5 and then for the error: [ 120.860334] ata1.00: exception Emask 0x1 SAct 0x7ffc0007 SErr 0x0 action 0x6 frozen [ 120.860338] ata1.00: irq_stat 0x40000008 [ 120.860342] ata1.00: failed command: SEND FPDMA QUEUED [ 120.860351] ata1.00: cmd 64/01:00:00:00:00/00:00:00:00:00/a0 tag 0 ncq dma 512 out res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x5 (timeout) [ 120.860353] ata1.00: status: { DRDY } [ 120.860543] ata1: hard resetting link [ 121.166128] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 121.166376] ata1.00: supports DRM functions and may not be fully accessible [ 121.186238] ata1.00: supports DRM functions and may not be fully accessible [ 121.204445] ata1.00: configured for UDMA/133 [ 121.204454] ata1.00: device reported invalid CHS sector 0 [ 121.204541] sd 0:0:0:0: [sda] tag#18 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 [ 121.204546] sd 0:0:0:0: [sda] tag#18 Sense Key : 0x5 [current] [ 121.204550] sd 0:0:0:0: [sda] tag#18 ASC=0x21 ASCQ=0x4 [ 121.204555] sd 0:0:0:0: [sda] tag#18 CDB: opcode=0x93 93 08 00 00 00 00 00 04 28 80 00 00 00 30 00 00 [ 121.204559] print_req_error: I/O error, dev sda, sector 272512 After few reboots with these errors, and the SSD is corrupted. After blacklisting it, the errors are not seen and the SSD does not get corrupted any more. Fixes: 243918be6393 ("libata: Do not blacklist Micron M500DC") Cc: stable(a)vger.kernel.org Signed-off-by: Sudip Mukherjee <sudipm.mukherjee(a)gmail.com> --- drivers/ata/libata-core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index cb789f8..1fb96c6 100644 --- a/drivers/ata/libata-core.c +++ b/drivers/ata/libata-core.c @@ -4539,6 +4539,8 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = { ATA_HORKAGE_NOLPM, }, /* devices that don't properly handle queued TRIM commands */ + { "Micron_M500IT_*", "MU01", ATA_HORKAGE_NO_NCQ_TRIM | + ATA_HORKAGE_ZERO_AFTER_TRIM, }, { "Micron_M500_*", NULL, ATA_HORKAGE_NO_NCQ_TRIM | ATA_HORKAGE_ZERO_AFTER_TRIM, }, { "Crucial_CT*M500*", NULL, ATA_HORKAGE_NO_NCQ_TRIM | -- 2.1.4

7 years, 6 months

2
5
0 0

+ mm-ksm-fix-inconsistent-accounting-of-zero-pages.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/ksm.c: fix inconsistent accounting of zero pages has been added to the -mm tree. Its filename is mm-ksm-fix-inconsistent-accounting-of-zero-pages.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-ksm-fix-inconsistent-accounting… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-ksm-fix-inconsistent-accounting… 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 and is updated there every 3-4 working days ------------------------------------------------------ From: Claudio Imbrenda <imbrenda(a)linux.vnet.ibm.com> Subject: mm/ksm.c: fix inconsistent accounting of zero pages When using KSM with use_zero_pages, we replace anonymous pages containing only zeroes with actual zero pages, which are not anonymous. We need to do proper accounting of the mm counters, otherwise we will get wrong values in /proc and a BUG message in dmesg when tearing down the mm. Link: http://lkml.kernel.org/r/1522931274-15552-1-git-send-email-imbrenda@linux.v… Fixes: e86c59b1b1 ("mm/ksm: improve deduplication of zero pages with colouring") Signed-off-by: Claudio Imbrenda <imbrenda(a)linux.vnet.ibm.com> Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org> Cc: Andrea Arcangeli <aarcange(a)redhat.com> Cc: Minchan Kim <minchan(a)kernel.org> Cc: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: Hugh Dickins <hughd(a)google.com> Cc: Christian Borntraeger <borntraeger(a)de.ibm.com> Cc: Gerald Schaefer <gerald.schaefer(a)de.ibm.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/ksm.c | 7 +++++++ 1 file changed, 7 insertions(+) diff -puN mm/ksm.c~mm-ksm-fix-inconsistent-accounting-of-zero-pages mm/ksm.c --- a/mm/ksm.c~mm-ksm-fix-inconsistent-accounting-of-zero-pages +++ a/mm/ksm.c @@ -1131,6 +1131,13 @@ static int replace_page(struct vm_area_s } else { newpte = pte_mkspecial(pfn_pte(page_to_pfn(kpage), vma->vm_page_prot)); + /* + * We're replacing an anonymous page with a zero page, which is + * not anonymous. We need to do proper accounting otherwise we + * will get wrong values in /proc, and a BUG message in dmesg + * when tearing down the mm. + */ + dec_mm_counter(mm, MM_ANONPAGES); } flush_cache_page(vma, addr, pte_pfn(*ptep)); _ Patches currently in -mm which might be from imbrenda(a)linux.vnet.ibm.com are mm-ksm-fix-interaction-with-thp.patch mm-ksm-fix-inconsistent-accounting-of-zero-pages.patch

7 years, 6 months

1
0
0 0

Patches for stable

by Juergen Gross

Please add the patches: commit 038bac2b02989acf1fc938cedcb7944c02672b9f upstream commit dfc9327ab7c99bc13e12106448615efba833886b upstream commit b17d9d1df3c33a4f1d2bf397e2257aecf9dc56d4 upstream to the 4.15 and 4.16 stable kernels. Those patches are needed to boot Linux as PVH guest on recent Xen. In PVH mode there is no guarantee the kernel can find the RSDP table at the legacy location in low memory, which is a requirement for the kernel to boot successful without those patches. For kernel 4.14 I'll send a slightly modified version of the patches soon. Juergen

7 years, 6 months

5
19
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror