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

[PATCH] arm64: dts: stratix10: Fix SPI nodes for Stratix10

by thor.thayer＠linux.intel.com

From: Thor Thayer <thor.thayer(a)linux.intel.com> Patch did not apply cleanly to 4.9 and 4.14 stable branches because of additional node properties added after 4.14. So backport patch and cleanup commit 4595299c5eae ("arm64: dts: stratix10: Fix SPI nodes for Stratix10") Remove the unused bus-num node and change num-chipselect to num-cs to match SPI bindings. Cc: stable(a)vger.kernel.org # 4.14.x Cc: stable(a)vger.kernel.org # 4.9.x Fixes: 78cd6a9d8e154 ("arm64: dts: Add base stratix 10 dtsi") Signed-off-by: Thor Thayer <thor.thayer(a)linux.intel.com> Signed-off-by: Dinh Nguyen <dinguyen(a)kernel.org> Signed-off-by: Olof Johansson <olof(a)lixom.net> --- arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi index c2b9bcb0ef61..57f75453ee93 100644 --- a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi +++ b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi @@ -231,8 +231,7 @@ #size-cells = <0>; reg = <0xffda4000 0x1000>; interrupts = <0 101 4>; - num-chipselect = <4>; - bus-num = <0>; + num-cs = <4>; status = "disabled"; }; @@ -242,8 +241,7 @@ #size-cells = <0>; reg = <0xffda5000 0x1000>; interrupts = <0 102 4>; - num-chipselect = <4>; - bus-num = <0>; + num-cs = <4>; status = "disabled"; }; -- 2.7.4

7 years, 1 month

1
0
0 0

FAILED: patch "[PATCH] dm: prevent DAX mounts if not supported" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From dbc626597c39b24cefce09fbd8e9dea85869a801 Mon Sep 17 00:00:00 2001 From: Ross Zwisler <ross.zwisler(a)linux.intel.com> Date: Tue, 26 Jun 2018 16:30:41 -0600 Subject: [PATCH] dm: prevent DAX mounts if not supported Currently device_supports_dax() just checks to see if the QUEUE_FLAG_DAX flag is set on the device's request queue to decide whether or not the device supports filesystem DAX. Really we should be using bdev_dax_supported() like filesystems do at mount time. This performs other tests like checking to make sure the dax_direct_access() path works. We also explicitly clear QUEUE_FLAG_DAX on the DM device's request queue if any of the underlying devices do not support DAX. This makes the handling of QUEUE_FLAG_DAX consistent with the setting/clearing of most other flags in dm_table_set_restrictions(). Now that bdev_dax_supported() explicitly checks for QUEUE_FLAG_DAX, this will ensure that filesystems built upon DM devices will only be able to mount with DAX if all underlying devices also support DAX. Signed-off-by: Ross Zwisler <ross.zwisler(a)linux.intel.com> Fixes: commit 545ed20e6df6 ("dm: add infrastructure for DAX support") Cc: stable(a)vger.kernel.org Acked-by: Dan Williams <dan.j.williams(a)intel.com> Reviewed-by: Toshi Kani <toshi.kani(a)hpe.com> Signed-off-by: Mike Snitzer <snitzer(a)redhat.com> diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c index 938766794c2e..3d0e2c198f06 100644 --- a/drivers/md/dm-table.c +++ b/drivers/md/dm-table.c @@ -885,9 +885,7 @@ EXPORT_SYMBOL_GPL(dm_table_set_type); static int device_supports_dax(struct dm_target *ti, struct dm_dev *dev, sector_t start, sector_t len, void *data) { - struct request_queue *q = bdev_get_queue(dev->bdev); - - return q && blk_queue_dax(q); + return bdev_dax_supported(dev->bdev, PAGE_SIZE); } static bool dm_table_supports_dax(struct dm_table *t) @@ -1907,6 +1905,9 @@ void dm_table_set_restrictions(struct dm_table *t, struct request_queue *q, if (dm_table_supports_dax(t)) blk_queue_flag_set(QUEUE_FLAG_DAX, q); + else + blk_queue_flag_clear(QUEUE_FLAG_DAX, q); + if (dm_table_supports_dax_write_cache(t)) dax_write_cache(t->md->dax_dev, true); diff --git a/drivers/md/dm.c b/drivers/md/dm.c index a3b103e8e3ce..b0dd7027848b 100644 --- a/drivers/md/dm.c +++ b/drivers/md/dm.c @@ -1056,8 +1056,7 @@ static long dm_dax_direct_access(struct dax_device *dax_dev, pgoff_t pgoff, if (len < 1) goto out; nr_pages = min(len, nr_pages); - if (ti->type->direct_access) - ret = ti->type->direct_access(ti, pgoff, nr_pages, kaddr, pfn); + ret = ti->type->direct_access(ti, pgoff, nr_pages, kaddr, pfn); out: dm_put_live_table(md, srcu_idx);

7 years, 1 month

2
1
0 0

[PATCH] MIPS: Fix ioremap() RAM check

by Paul Burton

We currently attempt to check whether a physical address range provided to __ioremap() may be in use by the page allocator by examining the value of PageReserved for each page in the region - lowmem pages not marked reserved are presumed to be in use by the page allocator, and requests to ioremap them fail. The way we check this has been broken since commit 92923ca3aace ("mm: meminit: only set page reserved in the memblock region"), because memblock will typically not have any knowledge of non-RAM pages and therefore those pages will not have the PageReserved flag set. Thus when we attempt to ioremap a region outside of RAM we incorrectly fail believing that the region is RAM that may be in use. In most cases ioremap() on MIPS will take a fast-path to use the unmapped kseg1 or xkphys virtual address spaces and never hit this path, so the only way to hit it is for a MIPS32 system to attempt to ioremap() an address range in lowmem with flags other than _CACHE_UNCACHED. Perhaps the most straightforward way to do this is using ioremap_uncached_accelerated(), which is how the problem was discovered. Fix this by making use of walk_system_ram_range() to test the address range provided to __ioremap() against only RAM pages, rather than all lowmem pages. This means that if we have a lowmem I/O region, which is very common for MIPS systems, we're free to ioremap() address ranges within it. A nice bonus is that the test is no longer limited to lowmem. The approach here matches the way x86 performed the same test after commit c81c8a1eeede ("x86, ioremap: Speed up check for RAM pages") until x86 moved towards a slightly more complicated check using walk_mem_res() for unrelated reasons with commit 0e4c12b45aa8 ("x86/mm, resource: Use PAGE_KERNEL protection for ioremap of memory pages"). Signed-off-by: Paul Burton <paul.burton(a)mips.com> Reported-by: Serge Semin <fancer.lancer(a)gmail.com> Tested-by: Serge Semin <fancer.lancer(a)gmail.com> Fixes: 92923ca3aace ("mm: meminit: only set page reserved in the memblock region") Cc: James Hogan <jhogan(a)kernel.org> Cc: Ralf Baechle <ralf(a)linux-mips.org> Cc: linux-mips(a)linux-mips.org Cc: stable(a)vger.kernel.org # v4.2+ --- arch/mips/mm/ioremap.c | 37 +++++++++++++++++++++++++------------ 1 file changed, 25 insertions(+), 12 deletions(-) diff --git a/arch/mips/mm/ioremap.c b/arch/mips/mm/ioremap.c index 1986e09fb457..1601d90b087b 100644 --- a/arch/mips/mm/ioremap.c +++ b/arch/mips/mm/ioremap.c @@ -9,6 +9,7 @@ #include <linux/export.h> #include <asm/addrspace.h> #include <asm/byteorder.h> +#include <linux/ioport.h> #include <linux/sched.h> #include <linux/slab.h> #include <linux/vmalloc.h> @@ -98,6 +99,20 @@ static int remap_area_pages(unsigned long address, phys_addr_t phys_addr, return error; } +static int __ioremap_check_ram(unsigned long start_pfn, unsigned long nr_pages, + void *arg) +{ + unsigned long i; + + for (i = 0; i < nr_pages; i++) { + if (pfn_valid(start_pfn + i) && + !PageReserved(pfn_to_page(start_pfn + i))) + return 1; + } + + return 0; +} + /* * Generic mapping function (not visible outside): */ @@ -116,8 +131,8 @@ static int remap_area_pages(unsigned long address, phys_addr_t phys_addr, void __iomem * __ioremap(phys_addr_t phys_addr, phys_addr_t size, unsigned long flags) { + unsigned long offset, pfn, last_pfn; struct vm_struct * area; - unsigned long offset; phys_addr_t last_addr; void * addr; @@ -137,18 +152,16 @@ void __iomem * __ioremap(phys_addr_t phys_addr, phys_addr_t size, unsigned long return (void __iomem *) CKSEG1ADDR(phys_addr); /* - * Don't allow anybody to remap normal RAM that we're using.. + * Don't allow anybody to remap RAM that may be allocated by the page + * allocator, since that could lead to races & data clobbering. */ - if (phys_addr < virt_to_phys(high_memory)) { - char *t_addr, *t_end; - struct page *page; - - t_addr = __va(phys_addr); - t_end = t_addr + (size - 1); - - for(page = virt_to_page(t_addr); page <= virt_to_page(t_end); page++) - if(!PageReserved(page)) - return NULL; + pfn = PFN_DOWN(phys_addr); + last_pfn = PFN_DOWN(last_addr); + if (walk_system_ram_range(pfn, last_pfn - pfn + 1, NULL, + __ioremap_check_ram) == 1) { + WARN_ONCE(1, "ioremap on RAM at %pa - %pa\n", + &phys_addr, &last_addr); + return NULL; } /* -- 2.18.0

7 years, 1 month

1
0
0 0

[PATCH v2] dm-zoned: Avoid triggering reclaim from inside dmz_map()

by Bart Van Assche

This patch avoids that lockdep reports the following: ====================================================== WARNING: possible circular locking dependency detected 4.18.0-rc1 #62 Not tainted ------------------------------------------------------ kswapd0/84 is trying to acquire lock: 00000000c313516d (&xfs_nondir_ilock_class){++++}, at: xfs_free_eofblocks+0xa2/0x1e0 but task is already holding lock: 00000000591c83ae (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x5/0x30 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (fs_reclaim){+.+.}: kmem_cache_alloc+0x2c/0x2b0 radix_tree_node_alloc.constprop.19+0x3d/0xc0 __radix_tree_create+0x161/0x1c0 __radix_tree_insert+0x45/0x210 dmz_map+0x245/0x2d0 [dm_zoned] __map_bio+0x40/0x260 __split_and_process_non_flush+0x116/0x220 __split_and_process_bio+0x81/0x180 __dm_make_request.isra.32+0x5a/0x100 generic_make_request+0x36e/0x690 submit_bio+0x6c/0x140 mpage_readpages+0x19e/0x1f0 read_pages+0x6d/0x1b0 __do_page_cache_readahead+0x21b/0x2d0 force_page_cache_readahead+0xc4/0x100 generic_file_read_iter+0x7c6/0xd20 __vfs_read+0x102/0x180 vfs_read+0x9b/0x140 ksys_read+0x55/0xc0 do_syscall_64+0x5a/0x1f0 entry_SYSCALL_64_after_hwframe+0x49/0xbe -> #1 (&dmz->chunk_lock){+.+.}: dmz_map+0x133/0x2d0 [dm_zoned] __map_bio+0x40/0x260 __split_and_process_non_flush+0x116/0x220 __split_and_process_bio+0x81/0x180 __dm_make_request.isra.32+0x5a/0x100 generic_make_request+0x36e/0x690 submit_bio+0x6c/0x140 _xfs_buf_ioapply+0x31c/0x590 xfs_buf_submit_wait+0x73/0x520 xfs_buf_read_map+0x134/0x2f0 xfs_trans_read_buf_map+0xc3/0x580 xfs_read_agf+0xa5/0x1e0 xfs_alloc_read_agf+0x59/0x2b0 xfs_alloc_pagf_init+0x27/0x60 xfs_bmap_longest_free_extent+0x43/0xb0 xfs_bmap_btalloc_nullfb+0x7f/0xf0 xfs_bmap_btalloc+0x428/0x7c0 xfs_bmapi_write+0x598/0xcc0 xfs_iomap_write_allocate+0x15a/0x330 xfs_map_blocks+0x1cf/0x3f0 xfs_do_writepage+0x15f/0x7b0 write_cache_pages+0x1ca/0x540 xfs_vm_writepages+0x65/0xa0 do_writepages+0x48/0xf0 __writeback_single_inode+0x58/0x730 writeback_sb_inodes+0x249/0x5c0 wb_writeback+0x11e/0x550 wb_workfn+0xa3/0x670 process_one_work+0x228/0x670 worker_thread+0x3c/0x390 kthread+0x11c/0x140 ret_from_fork+0x3a/0x50 -> #0 (&xfs_nondir_ilock_class){++++}: down_read_nested+0x43/0x70 xfs_free_eofblocks+0xa2/0x1e0 xfs_fs_destroy_inode+0xac/0x270 dispose_list+0x51/0x80 prune_icache_sb+0x52/0x70 super_cache_scan+0x127/0x1a0 shrink_slab.part.47+0x1bd/0x590 shrink_node+0x3b5/0x470 balance_pgdat+0x158/0x3b0 kswapd+0x1ba/0x600 kthread+0x11c/0x140 ret_from_fork+0x3a/0x50 other info that might help us debug this: Chain exists of: &xfs_nondir_ilock_class --> &dmz->chunk_lock --> fs_reclaim Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(fs_reclaim); lock(&dmz->chunk_lock); lock(fs_reclaim); lock(&xfs_nondir_ilock_class); *** DEADLOCK *** 3 locks held by kswapd0/84: #0: 00000000591c83ae (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x5/0x30 #1: 000000000f8208f5 (shrinker_rwsem){++++}, at: shrink_slab.part.47+0x3f/0x590 #2: 00000000cacefa54 (&type->s_umount_key#43){.+.+}, at: trylock_super+0x16/0x50 stack backtrace: CPU: 7 PID: 84 Comm: kswapd0 Not tainted 4.18.0-rc1 #62 Hardware name: Supermicro Super Server/X10SRL-F, BIOS 2.0 12/17/2015 Call Trace: dump_stack+0x85/0xcb print_circular_bug.isra.36+0x1ce/0x1db __lock_acquire+0x124e/0x1310 lock_acquire+0x9f/0x1f0 down_read_nested+0x43/0x70 xfs_free_eofblocks+0xa2/0x1e0 xfs_fs_destroy_inode+0xac/0x270 dispose_list+0x51/0x80 prune_icache_sb+0x52/0x70 super_cache_scan+0x127/0x1a0 shrink_slab.part.47+0x1bd/0x590 shrink_node+0x3b5/0x470 balance_pgdat+0x158/0x3b0 kswapd+0x1ba/0x600 kthread+0x11c/0x140 ret_from_fork+0x3a/0x50 Reported-by: Masato Suzuki <masato.suzuki(a)wdc.com> Fixes: 4218a9554653 ("dm zoned: use GFP_NOIO in I/O path") Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: Damien Le Moal <Damien.LeMoal(a)wdc.com> Cc: Mikulas Patocka <mpatocka(a)redhat.com> Cc: <stable(a)vger.kernel.org> --- Changes compared to v1: added "Cc: stable" drivers/md/dm-zoned-target.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/md/dm-zoned-target.c b/drivers/md/dm-zoned-target.c index 3c0e45f4dcf5..a44183ff4be0 100644 --- a/drivers/md/dm-zoned-target.c +++ b/drivers/md/dm-zoned-target.c @@ -787,7 +787,7 @@ static int dmz_ctr(struct dm_target *ti, unsigned int argc, char **argv) /* Chunk BIO work */ mutex_init(&dmz->chunk_lock); - INIT_RADIX_TREE(&dmz->chunk_rxtree, GFP_KERNEL); + INIT_RADIX_TREE(&dmz->chunk_rxtree, GFP_NOIO); dmz->chunk_wq = alloc_workqueue("dmz_cwq_%s", WQ_MEM_RECLAIM | WQ_UNBOUND, 0, dev->name); if (!dmz->chunk_wq) { -- 2.17.1

7 years, 1 month

3
2
0 0

[merged] mm-teach-dump_page-to-correctly-output-poisoned-struct-pages.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm: teach dump_page() to correctly output poisoned struct pages has been removed from the -mm tree. Its filename was mm-teach-dump_page-to-correctly-output-poisoned-struct-pages.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Pavel Tatashin <pasha.tatashin(a)oracle.com> Subject: mm: teach dump_page() to correctly output poisoned struct pages If struct page is poisoned, and uninitialized access is detected via PF_POISONED_CHECK(page) dump_page() is called to output the page. But, the dump_page() itself accesses struct page to determine how to print it, and therefore gets into a recursive loop. For example: dump_page() __dump_page() PageSlab(page) PF_POISONED_CHECK(page) VM_BUG_ON_PGFLAGS(PagePoisoned(page), page) dump_page() recursion loop. Link: http://lkml.kernel.org/r/20180702180536.2552-1-pasha.tatashin@oracle.com Fixes: f165b378bbdf ("mm: uninitialized struct page poisoning sanity checking") Signed-off-by: Pavel Tatashin <pasha.tatashin(a)oracle.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/debug.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff -puN mm/debug.c~mm-teach-dump_page-to-correctly-output-poisoned-struct-pages mm/debug.c --- a/mm/debug.c~mm-teach-dump_page-to-correctly-output-poisoned-struct-pages +++ a/mm/debug.c @@ -43,12 +43,25 @@ const struct trace_print_flags vmaflag_n void __dump_page(struct page *page, const char *reason) { + bool page_poisoned = PagePoisoned(page); + int mapcount; + + /* + * If struct page is poisoned don't access Page*() functions as that + * leads to recursive loop. Page*() check for poisoned pages, and calls + * dump_page() when detected. + */ + if (page_poisoned) { + pr_emerg("page:%px is uninitialized and poisoned", page); + goto hex_only; + } + /* * Avoid VM_BUG_ON() in page_mapcount(). * page->_mapcount space in struct page is used by sl[aou]b pages to * encode own info. */ - int mapcount = PageSlab(page) ? 0 : page_mapcount(page); + mapcount = PageSlab(page) ? 0 : page_mapcount(page); pr_emerg("page:%px count:%d mapcount:%d mapping:%px index:%#lx", page, page_ref_count(page), mapcount, @@ -60,6 +73,7 @@ void __dump_page(struct page *page, cons pr_emerg("flags: %#lx(%pGp)\n", page->flags, &page->flags); +hex_only: print_hex_dump(KERN_ALERT, "raw: ", DUMP_PREFIX_NONE, 32, sizeof(unsigned long), page, sizeof(struct page), false); @@ -68,7 +82,7 @@ void __dump_page(struct page *page, cons pr_alert("page dumped because: %s\n", reason); #ifdef CONFIG_MEMCG - if (page->mem_cgroup) + if (!page_poisoned && page->mem_cgroup) pr_alert("page->mem_cgroup:%px\n", page->mem_cgroup); #endif } _ Patches currently in -mm which might be from pasha.tatashin(a)oracle.com are mm-skip-invalid-pages-block-at-a-time-in-zero_resv_unresv.patch sparc64-ng4-memset-32-bits-overflow.patch

7 years, 1 month

1
0
0 0

[merged] mm-hugetlb-yield-when-prepping-struct-pages.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm: hugetlb: yield when prepping struct pages has been removed from the -mm tree. Its filename was mm-hugetlb-yield-when-prepping-struct-pages.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Cannon Matthews <cannonmatthews(a)google.com> Subject: mm: hugetlb: yield when prepping struct pages When booting with very large numbers of gigantic (i.e. 1G) pages, the operations in the loop of gather_bootmem_prealloc, and specifically prep_compound_gigantic_page, takes a very long time, and can cause a softlockup if enough pages are requested at boot. For example booting with 3844 1G pages requires prepping (set_compound_head, init the count) over 1 billion 4K tail pages, which takes considerable time. Add a cond_resched() to the outer loop in gather_bootmem_prealloc() to prevent this lockup. Tested: Booted with softlockup_panic=1 hugepagesz=1G hugepages=3844 and no softlockup is reported, and the hugepages are reported as successfully setup. Link: http://lkml.kernel.org/r/20180627214447.260804-1-cannonmatthews@google.com Signed-off-by: Cannon Matthews <cannonmatthews(a)google.com> Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org> Reviewed-by: Mike Kravetz <mike.kravetz(a)oracle.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: Andres Lagar-Cavilla <andreslc(a)google.com> Cc: Peter Feiner <pfeiner(a)google.com> Cc: Greg Thelen <gthelen(a)google.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(+) diff -puN mm/hugetlb.c~mm-hugetlb-yield-when-prepping-struct-pages mm/hugetlb.c --- a/mm/hugetlb.c~mm-hugetlb-yield-when-prepping-struct-pages +++ a/mm/hugetlb.c @@ -2163,6 +2163,7 @@ static void __init gather_bootmem_preall */ if (hstate_is_gigantic(h)) adjust_managed_page_count(page, 1 << h->order); + cond_resched(); } } _ Patches currently in -mm which might be from cannonmatthews(a)google.com are

7 years, 1 month

1
0
0 0

[merged] userfaultfd-hugetlbfs-fix-userfaultfd_huge_must_wait-pte-access.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: userfaultfd: hugetlbfs: fix userfaultfd_huge_must_wait() pte access has been removed from the -mm tree. Its filename was userfaultfd-hugetlbfs-fix-userfaultfd_huge_must_wait-pte-access.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Janosch Frank <frankja(a)linux.ibm.com> Subject: userfaultfd: hugetlbfs: fix userfaultfd_huge_must_wait() pte access Use huge_ptep_get() to translate huge ptes to normal ptes so we can check them with the huge_pte_* functions. Otherwise some architectures will check the wrong values and will not wait for userspace to bring in the memory. Link: http://lkml.kernel.org/r/20180626132421.78084-1-frankja@linux.ibm.com Fixes: 369cd2121be4 ("userfaultfd: hugetlbfs: userfaultfd_huge_must_wait for hugepmd ranges") Signed-off-by: Janosch Frank <frankja(a)linux.ibm.com> Reviewed-by: David Hildenbrand <david(a)redhat.com> Reviewed-by: Mike Kravetz <mike.kravetz(a)oracle.com> Cc: Andrea Arcangeli <aarcange(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/userfaultfd.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff -puN fs/userfaultfd.c~userfaultfd-hugetlbfs-fix-userfaultfd_huge_must_wait-pte-access fs/userfaultfd.c --- a/fs/userfaultfd.c~userfaultfd-hugetlbfs-fix-userfaultfd_huge_must_wait-pte-access +++ a/fs/userfaultfd.c @@ -222,24 +222,26 @@ static inline bool userfaultfd_huge_must unsigned long reason) { struct mm_struct *mm = ctx->mm; - pte_t *pte; + pte_t *ptep, pte; bool ret = true; VM_BUG_ON(!rwsem_is_locked(&mm->mmap_sem)); - pte = huge_pte_offset(mm, address, vma_mmu_pagesize(vma)); - if (!pte) + ptep = huge_pte_offset(mm, address, vma_mmu_pagesize(vma)); + + if (!ptep) goto out; ret = false; + pte = huge_ptep_get(ptep); /* * Lockless access: we're in a wait_event so it's ok if it * changes under us. */ - if (huge_pte_none(*pte)) + if (huge_pte_none(pte)) ret = true; - if (!huge_pte_write(*pte) && (reason & VM_UFFD_WP)) + if (!huge_pte_write(pte) && (reason & VM_UFFD_WP)) ret = true; out: return ret; _ Patches currently in -mm which might be from frankja(a)linux.ibm.com are

7 years, 1 month

1
0
0 0

[GIT PULL] commits for Linux 4.4

by Sasha Levin

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Greg, Pleae pull commits for Linux 4.4 . I've sent a review request for all commits over a week ago and all comments were addressed. Thanks, Sasha ===== The following changes since commit dc45cafe612ec6960fe728f3260a0b751c73f4aa: Linux 4.4.136 (2018-06-06 16:46:24 +0200) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git tags/for-greg-4.4-20062018 for you to fetch changes up to 340dc6e834545e08109b42402fe692c097446c90: net/sonic: Use dma_mapping_error() (2018-06-07 15:40:15 -0400) - ---------------------------------------------------------------- for-greg-4.4-20062018 - ---------------------------------------------------------------- Eric Dumazet (1): xfrm6: avoid potential infinite loop in _decode_session6() Finn Thain (1): net/sonic: Use dma_mapping_error() Ivan Bornyakov (1): atm: zatm: fix memcmp casting Josh Hill (1): net: qmi_wwan: Add Netgear Aircard 779S Julian Anastasov (1): ipvs: fix buffer overflow with sync daemon and service Paolo Abeni (1): netfilter: ebtables: handle string from userspace with care drivers/atm/zatm.c | 4 ++-- drivers/net/ethernet/natsemi/sonic.c | 2 +- drivers/net/usb/qmi_wwan.c | 1 + net/bridge/netfilter/ebtables.c | 3 ++- net/ipv6/xfrm6_policy.c | 2 +- net/netfilter/ipvs/ip_vs_ctl.c | 21 +++++++++++++++------ 6 files changed, 22 insertions(+), 11 deletions(-) -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE4n5dijQDou9mhzu83qZv95d3LNwFAlsrD2AACgkQ3qZv95d3 LNxa4hAAsH8GdIusq8gBegjlwklVZiCo2zvrWbwohM7Sc1TpuAjLWSVh9iuFRPKn fAAuQYlY3oTDpq/bnje4c+JTnNsjcikDETycZ3diWCiG28c9DjKatsJt/fH9yP/V vAzCboTy38kbizNpXBam6KniZ48qEvFZt2zsYpFL5HzlgHTlBOcOup7iL3P04i1S +v/QCS+OApv0VZR84Nq4mx5ofYILO7ty2xzLCTHHqzLWCEyaX3SbJXBKF5lf3Cu2 WU35HQsnTxKaM3fa7+nSsZu2xkqwNit/xAeAdf0e3ymgBc1G+DezZTJFk/+BbD1N /zWs7AN757Ae6p5HB4eV5KGM5hO8bhqtNuGv6T0eAbqi4MwNclY+J0VCTVbtDrjT bPyJHdfjNc175M2wZDw0HJWWYIHUroQ1Qcao6V9DchVPKtsLd3ICj9sXNNhp1VMo zNLfj9hRcOY/cZtj8tNC6QyoOZX1QBiTGKxDvQbQvmWsrKWQCDOCPHOJh/AycH9a jQYl4+DPMYMFh0ahrrDNBkbmI10Jcg170vQ4CEppRP1zkwbSNtHzfMlp8t2kXXTV uc2rxh/MY2DwBoXqGs6HrxH1Z/A2gcwcu8xqNAGJhaleWQEae2qFQx6eEUKekjhm +EfJIG7v2blVcMLpp06kaAwlIUK4hV2F/Tn9BoQajbBA5Lq9whI= =0hTA -----END PGP SIGNATURE-----

7 years, 1 month

2
2
0 0

[PATCH 4.9] mlxsw: spectrum: Forbid linking of VLAN devices to devices that have uppers

by Ido Schimmel

commit 25cc72a33835ed8a6f53180a822cadab855852ac upstream. Jiri Slaby noticed that the backport of upstream commit 25cc72a33835 ("mlxsw: spectrum: Forbid linking to devices that have uppers") to kernel 4.9.y introduced the same check twice in the same function instead of in two different places. Fix this by relocating one of the checks to its intended place, thus preventing unsupported configurations as described in the original commit. Fixes: 73ee5a73e75f ("mlxsw: spectrum: Forbid linking to devices that have uppers") Signed-off-by: Ido Schimmel <idosch(a)mellanox.com> Reported-by: Jiri Slaby <jslaby(a)suse.cz> --- Greg, I read Documentation/stable_kernel_rules.txt, so I hope the patch is fine. Please let me know if v2 is required. Thanks --- drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c index d50350c7adc4..22a5916e477e 100644 --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c @@ -4187,10 +4187,6 @@ static int mlxsw_sp_netdevice_port_upper_event(struct net_device *dev, if (netif_is_lag_port(dev) && is_vlan_dev(upper_dev) && !netif_is_lag_master(vlan_dev_real_dev(upper_dev))) return -EINVAL; - if (!info->linking) - break; - if (netdev_has_any_upper_dev(upper_dev)) - return -EINVAL; break; case NETDEV_CHANGEUPPER: upper_dev = info->upper_dev; @@ -4566,6 +4562,8 @@ static int mlxsw_sp_netdevice_vport_event(struct net_device *dev, return -EINVAL; if (!info->linking) break; + if (netdev_has_any_upper_dev(upper_dev)) + return -EINVAL; /* We can't have multiple VLAN interfaces configured on * the same port and being members in the same bridge. */ -- 2.14.4

7 years, 1 month

2
4
0 0

FAILED: patch "[PATCH] x86/mce: Fix incorrect "Machine check from unknown source"" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 40c36e2741d7fe1e66d6ec55477ba5fd19c9c5d2 Mon Sep 17 00:00:00 2001 From: Tony Luck <tony.luck(a)intel.com> Date: Fri, 22 Jun 2018 11:54:23 +0200 Subject: [PATCH] x86/mce: Fix incorrect "Machine check from unknown source" message Some injection testing resulted in the following console log: mce: [Hardware Error]: CPU 22: Machine Check Exception: f Bank 1: bd80000000100134 mce: [Hardware Error]: RIP 10:<ffffffffc05292dd> {pmem_do_bvec+0x11d/0x330 [nd_pmem]} mce: [Hardware Error]: TSC c51a63035d52 ADDR 3234bc4000 MISC 88 mce: [Hardware Error]: PROCESSOR 0:50654 TIME 1526502199 SOCKET 0 APIC 38 microcode 2000043 mce: [Hardware Error]: Run the above through 'mcelog --ascii' Kernel panic - not syncing: Machine check from unknown source This confused everybody because the first line quite clearly shows that we found a logged error in "Bank 1", while the last line says "unknown source". The problem is that the Linux code doesn't do the right thing for a local machine check that results in a fatal error. It turns out that we know very early in the handler whether the machine check is fatal. The call to mce_no_way_out() has checked all the banks for the CPU that took the local machine check. If it says we must crash, we can do so right away with the right messages. We do scan all the banks again. This means that we might initially not see a problem, but during the second scan find something fatal. If this happens we print a slightly different message (so I can see if it actually every happens). [ bp: Remove unneeded severity assignment. ] Signed-off-by: Tony Luck <tony.luck(a)intel.com> Signed-off-by: Borislav Petkov <bp(a)suse.de> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: Ashok Raj <ashok.raj(a)intel.com> Cc: Dan Williams <dan.j.williams(a)intel.com> Cc: Qiuxu Zhuo <qiuxu.zhuo(a)intel.com> Cc: linux-edac <linux-edac(a)vger.kernel.org> Cc: stable(a)vger.kernel.org # 4.2 Link: http://lkml.kernel.org/r/52e049a497e86fd0b71c529651def8871c804df0.152728389… diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c index 7e6f51a9d917..e93670d736a6 100644 --- a/arch/x86/kernel/cpu/mcheck/mce.c +++ b/arch/x86/kernel/cpu/mcheck/mce.c @@ -1207,13 +1207,18 @@ void do_machine_check(struct pt_regs *regs, long error_code) lmce = m.mcgstatus & MCG_STATUS_LMCES; /* + * Local machine check may already know that we have to panic. + * Broadcast machine check begins rendezvous in mce_start() * Go through all banks in exclusion of the other CPUs. This way we * don't report duplicated events on shared banks because the first one - * to see it will clear it. If this is a Local MCE, then no need to - * perform rendezvous. + * to see it will clear it. */ - if (!lmce) + if (lmce) { + if (no_way_out) + mce_panic("Fatal local machine check", &m, msg); + } else { order = mce_start(&no_way_out); + } for (i = 0; i < cfg->banks; i++) { __clear_bit(i, toclear); @@ -1289,12 +1294,17 @@ void do_machine_check(struct pt_regs *regs, long error_code) no_way_out = worst >= MCE_PANIC_SEVERITY; } else { /* - * Local MCE skipped calling mce_reign() - * If we found a fatal error, we need to panic here. + * If there was a fatal machine check we should have + * already called mce_panic earlier in this function. + * Since we re-read the banks, we might have found + * something new. Check again to see if we found a + * fatal error. We call "mce_severity()" again to + * make sure we have the right "msg". */ - if (worst >= MCE_PANIC_SEVERITY && mca_cfg.tolerant < 3) - mce_panic("Machine check from unknown source", - NULL, NULL); + if (worst >= MCE_PANIC_SEVERITY && mca_cfg.tolerant < 3) { + mce_severity(&m, cfg->tolerant, &msg, true); + mce_panic("Local fatal machine check!", &m, msg); + } } /*

7 years, 1 month

3
4
0 0

[GIT PULL] commits for Linux 3.18

by Sasha Levin

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Greg, Pleae pull commits for Linux 3.18 . I've sent a review request for all commits over a week ago and all comments were addressed. Thanks, Sasha ===== The following changes since commit b0b357c20ca6171b8ac698351f5202402b7ad7d5: Linux 3.18.112 (2018-05-30 22:08:04 +0200) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git tags/for-greg-3.18-20062018 for you to fetch changes up to b73b55ee0dd09bb24fa6a4fee94b21d97dbc51ba: net/sonic: Use dma_mapping_error() (2018-06-07 15:40:45 -0400) - ---------------------------------------------------------------- for-greg-3.18-20062018 - ---------------------------------------------------------------- Finn Thain (1): net/sonic: Use dma_mapping_error() Ivan Bornyakov (1): atm: zatm: fix memcmp casting Josh Hill (1): net: qmi_wwan: Add Netgear Aircard 779S Paolo Abeni (1): netfilter: ebtables: handle string from userspace with care drivers/atm/zatm.c | 4 ++-- drivers/net/ethernet/natsemi/sonic.c | 2 +- drivers/net/usb/qmi_wwan.c | 1 + net/bridge/netfilter/ebtables.c | 3 ++- 4 files changed, 6 insertions(+), 4 deletions(-) -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE4n5dijQDou9mhzu83qZv95d3LNwFAlsrD34ACgkQ3qZv95d3 LNxyQA//Td2TjwiNv4O7a5DTBTY11L1m/4aM/Sg9AR3yUtykiIfatVi5rAwdKzXl ZBhutqVj7eK7STEyNfvqT0p/qwzoXWQUMSq0BpaH+D6Vfcvo3WNfXSdwODVsYy7D d8N814Libu3zUHj4x+KXp2og8SCKqAYNgyBhd45bnrRUVbq/UQPcZsXqDSUIX6WK RHkGU96VogA/4VEdD8Tiv9wX86L4PTQwve+GpYdxRc6Cc5rAuu3tS1BQgl50nfSU MSgorHcL+RO9wWu/Ij6L1SDOgNfxrk9b9DPt9Jahm5NeF+et5t/vLuJ804osJRYE dbXk6NQ+8EMQmgCOdDKUZhiHjN6ztk2NMsqmQb1z9hsPB+5gmmPMP2vZVA0BUyjl UZVQcRwYC1+s/bOb/uqhvBD4DH5pj76hMMkz10rR8pAvVRCvoBGFU9uwtSlu3gZo 24xHREUUSrpecc61tUq3QyomzlUZUQgyvkU8GnqD+2vhiJfsuyZ33AfjVmwEl+Vn 37qgenBJLBKhXzDxOMqg+xg0mUGo63CQeIx2ERSp3DiTHOElOWJINu5MVZQYKC8w rxSBacxj+5w24IM/OxNpWZ3PAoUSlAAvmkPiQJ5Aavw0StpqvNHN+DElmLf6eVrl 2Q5ZnkFhUOB2xSRkCYpkRhq9GZWGLkWjn4ePToil4z1+X13T6Zs= =mpuV -----END PGP SIGNATURE-----

7 years, 1 month

2
1
0 0

[GIT PULL] commits for Linux 4.14

by Sasha Levin

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Greg, Pleae pull commits for Linux 4.14 . I've sent a review request for all commits over a week ago and all comments were addressed. Thanks, Sasha ===== The following changes since commit 2c6025ebc7fd8e0a8ca785d778dc6ae25225744b: Linux 4.14.48 (2018-06-05 11:42:00 +0200) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git tags/for-greg-4.14-20062018 for you to fetch changes up to 5cca1f6fec1180fca1be5bc6f5068b96832646db: net: usb: cdc_mbim: add flag FLAG_SEND_ZLP (2018-06-06 23:16:01 -0400) - ---------------------------------------------------------------- for-greg-4.14-20062018 - ---------------------------------------------------------------- Alexander Duyck (1): net-sysfs: Fix memory leak in XPS configuration Damien ThÃ©bault (1): net: dsa: b53: Add BCM5389 support Daniele Palmas (1): net: usb: cdc_mbim: add flag FLAG_SEND_ZLP Darrick J. Wong (1): fs: clear writeback errors in inode_init_always David Howells (1): afs: Fix directory permissions check Eric Dumazet (1): xfrm6: avoid potential infinite loop in _decode_session6() Finn Thain (1): net/sonic: Use dma_mapping_error() Hao Wei Tee (1): iwlwifi: pcie: compare with number of IRQs requested for, not number of CPUs Ivan Bornyakov (1): atm: zatm: fix memcmp casting Josh Hill (1): net: qmi_wwan: Add Netgear Aircard 779S JoÃ£o Paulo Rechi Vita (1): platform/x86: asus-wmi: Fix NULL pointer dereference Julian Anastasov (1): ipvs: fix buffer overflow with sync daemon and service Kirill Tkhai (1): kcm: Fix use-after-free caused by clonned sockets Mathieu Xhonneux (1): ipv6: sr: fix memory OOB access in seg6_do_srh_encap/inline Pablo Neira Ayuso (1): netfilter: nft_limit: fix packet ratelimiting Paolo Abeni (1): netfilter: ebtables: handle string from userspace with care Paul Burton (1): sched/core: Require cpu_active() in select_task_rq(), for user tasks Peter Zijlstra (1): sched/core: Fix rules for running on online && !active CPUs Sebastian Ott (1): s390/dasd: use blk_mq_rq_from_pdu for per request data Suresh Reddy (1): be2net: Fix error detection logic for BE3 Taehee Yoo (3): netfilter: nf_tables: fix NULL pointer dereference on nft_ct_helper_obj_dump() netfilter: nft_meta: fix wrong value dereference in nft_meta_set_eval netfilter: nf_tables: increase nft_counters_enabled in nft_chain_stats_replace() Thomas Richter (1): perf test: "Session topology" dumps core on s390 YueHaibing (1): perf bpf: Fix NULL return handling in bpf__prepare_load() Documentation/devicetree/bindings/net/dsa/b53.txt | 1 + drivers/atm/zatm.c | 4 +- drivers/net/dsa/b53/b53_common.c | 13 +++++++ drivers/net/dsa/b53/b53_mdio.c | 5 ++- drivers/net/dsa/b53/b53_priv.h | 1 + drivers/net/ethernet/emulex/benet/be_main.c | 4 +- drivers/net/ethernet/natsemi/sonic.c | 2 +- drivers/net/usb/cdc_mbim.c | 2 +- drivers/net/usb/qmi_wwan.c | 1 + drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 10 ++--- drivers/platform/x86/asus-wmi.c | 23 +++++++----- drivers/s390/block/dasd.c | 7 +++- fs/afs/security.c | 10 ++--- fs/inode.c | 1 + kernel/sched/core.c | 45 ++++++++++++++++------- net/bridge/netfilter/ebtables.c | 3 +- net/core/net-sysfs.c | 6 +-- net/ipv6/seg6_iptunnel.c | 4 +- net/ipv6/xfrm6_policy.c | 2 +- net/kcm/kcmsock.c | 2 +- net/netfilter/ipvs/ip_vs_ctl.c | 21 ++++++++--- net/netfilter/nf_tables_api.c | 4 +- net/netfilter/nft_ct.c | 20 ++++++---- net/netfilter/nft_limit.c | 38 ++++++++++++------- net/netfilter/nft_meta.c | 14 ++++--- tools/perf/tests/topology.c | 30 ++++++++++++--- tools/perf/util/bpf-loader.c | 6 +-- 27 files changed, 183 insertions(+), 96 deletions(-) -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE4n5dijQDou9mhzu83qZv95d3LNwFAlsrD0EACgkQ3qZv95d3 LNykIRAAuOxrTFNkFNHbmF4ETHaQC1RA65ebzaxqTVO1HQUylrdU6XtGijfFfl2Q mLhFk1Om1AYOanQgOO3fPVohS+6lu4M/ld4/gfoVFOOE/Bjc2JsMO9I9OiZ5LCZQ AzToRfu7jjnvmdMhTgM+ek3/OJfDOtD4KskNZV1rjVTnYQbjblk/QonYibTgVsOm BFc5VQyKkUVrnDa+0Zcdbc2OfHSrGYoCsEIus7stBnbjGOR84qIDUTL9vMkDX0Vf 6o6QiwDkcY5sYGf5ob9BL7Bix3axAccA3Rp7Yq1GXglFFB4dwl6HBfAC6+liHTqF 2GvMDLktkZ1d4SGdabAdJahh04LFCQjgg1m7ZR61tzKzxBpu8D7eTiRQ/EPH0qrV Nob6oBoBIy4qk6KnAhPtY04TjDtK9/J6wUbG+rwYj9V5QAknrvT5zVdGsZTeVuEa R2pG6BJU7hAHv+Ndzey6c0ZxBH9fKdz7h/7ioeQGWPbmVGsebJoi+b4f5pOA31Wv 56Ne1IkhWGfCsBZMieBmWVrQrDVLoUk4DqjJW6TNXx5LvdxIDxP//oMy1plQUhS5 Mq7Ln3HKtNAnKSHgHd4RNWcE4kzvbviBxQHvVgdWTIpNTWEHrnz7L6Sh7HE6SWHJ qz2AtGJKCJL8KvmdQgbhtcYor5oOfZLDe1pZzetWLZ4yQnjJCdM= =Fakc -----END PGP SIGNATURE-----

7 years, 1 month

2
1
0 0

[GIT PULL] commits for Linux 4.9

by Sasha Levin

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Greg, Pleae pull commits for Linux 4.9 . I've sent a review request for all commits over a week ago and all comments were addressed. Thanks, Sasha ===== The following changes since commit 3c3d05fc6e6653bdf9f7fb3fb6922b199c7ba3ec: Linux 4.9.107 (2018-06-06 16:44:39 +0200) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git tags/for-greg-4.9-20062018 for you to fetch changes up to e957f7485f14affccc5f60f19dcce3a4f674cc0d: net: usb: cdc_mbim: add flag FLAG_SEND_ZLP (2018-06-07 15:39:36 -0400) - ---------------------------------------------------------------- for-greg-4.9-20062018 - ---------------------------------------------------------------- Damien ThÃ©bault (1): net: dsa: b53: Add BCM5389 support Daniele Palmas (1): net: usb: cdc_mbim: add flag FLAG_SEND_ZLP Eric Dumazet (1): xfrm6: avoid potential infinite loop in _decode_session6() Finn Thain (1): net/sonic: Use dma_mapping_error() Hao Wei Tee (1): iwlwifi: pcie: compare with number of IRQs requested for, not number of CPUs Ivan Bornyakov (1): atm: zatm: fix memcmp casting Josh Hill (1): net: qmi_wwan: Add Netgear Aircard 779S JoÃ£o Paulo Rechi Vita (1): platform/x86: asus-wmi: Fix NULL pointer dereference Julian Anastasov (1): ipvs: fix buffer overflow with sync daemon and service Kirill Tkhai (1): kcm: Fix use-after-free caused by clonned sockets Paolo Abeni (1): netfilter: ebtables: handle string from userspace with care Documentation/devicetree/bindings/net/dsa/b53.txt | 1 + drivers/atm/zatm.c | 4 ++-- drivers/net/dsa/b53/b53_common.c | 13 +++++++++++++ drivers/net/dsa/b53/b53_mdio.c | 5 ++++- drivers/net/dsa/b53/b53_priv.h | 1 + drivers/net/ethernet/natsemi/sonic.c | 2 +- drivers/net/usb/cdc_mbim.c | 2 +- drivers/net/usb/qmi_wwan.c | 1 + drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 10 +++++----- drivers/platform/x86/asus-wmi.c | 23 +++++++++++++---------- net/bridge/netfilter/ebtables.c | 3 ++- net/ipv6/xfrm6_policy.c | 2 +- net/kcm/kcmsock.c | 2 +- net/netfilter/ipvs/ip_vs_ctl.c | 21 +++++++++++++++------ 14 files changed, 61 insertions(+), 29 deletions(-) -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE4n5dijQDou9mhzu83qZv95d3LNwFAlsrD08ACgkQ3qZv95d3 LNz7JhAAlyrbs4NT1tU0ZjZYQ78hQbojWTDyMBQSz1+SIKwey/6Mp7HFizAXghY/ 3f4KECTu8a/5P35Jo7euTy7C3RDKOnHtP2yQENuu4AGe/pivIfqqVsIANmdy+sAi BY2iXJllGYeV8777nE0lm3cQrXnAMWhTsMmwKbJk6gHHx9ueaSRns7tajiD4lXm0 Z+F07jReymaOEvi3bNAKZTSU0swprprXTG9GfKPDyfPdB7fu4J7t+HkWI071mTj+ L1gJdcW5XOPuB1Tmu0ES5rRrFsDYdeUEwFoJBq0TplmOEKSNZO+xLWgTLfRZZ3T2 W6YIM+jOs44MfI4Sy5PDmM1jHwnvyUplOxApfx570F7CiSwU8xyuDwpQZIsNrBPn FrsDIy8X7uLLCN0MG0HMO/0P8RhL2tHKwG9gN/xRPo0fOLhVprABj8fTi3FCQhTU /BYAdmj4s58BuEEPND9swFYx96UTNuVVb47HB0+3FasPmCnGdhiVXb+HSSY6tW1a GNQqpcsUUtVoe4sFgb4s2pqZjnXfepvd4EhsI8cGU4KoTQ/vbwK4OVJS+MrSehoB yi169EwX0jL6ILtLNDBm2SVVcw7ukAEq4aDJRjko+X6xWFZxhnGTnFsZldkOEjld DVDGFhcTyUiGE7wVsnZGANMhHhT2LjtyeGDKpQiFn6lMagp0IM4= =gZsz -----END PGP SIGNATURE-----

7 years, 1 month

2
1
0 0

FAILED: patch "[PATCH] ubi: fastmap: Correctly handle interrupted erasures in EBA" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 781932375ffc6411713ee0926ccae8596ed0261c Mon Sep 17 00:00:00 2001 From: Richard Weinberger <richard(a)nod.at> Date: Mon, 28 May 2018 22:04:32 +0200 Subject: [PATCH] ubi: fastmap: Correctly handle interrupted erasures in EBA Fastmap cannot track the LEB unmap operation, therefore it can happen that after an interrupted erasure the mapping still looks good from Fastmap's point of view, while reading from the PEB will cause an ECC error and confuses the upper layer. Instead of teaching users of UBI how to deal with that, we read back the VID header and check for errors. If the PEB is empty or shows ECC errors we fixup the mapping and schedule the PEB for erasure. Fixes: dbb7d2a88d2a ("UBI: Add fastmap core") Cc: <stable(a)vger.kernel.org> Reported-by: martin bayern <Martinbayern(a)outlook.com> Signed-off-by: Richard Weinberger <richard(a)nod.at> diff --git a/drivers/mtd/ubi/eba.c b/drivers/mtd/ubi/eba.c index 250e30fac61b..593a4f9d97e3 100644 --- a/drivers/mtd/ubi/eba.c +++ b/drivers/mtd/ubi/eba.c @@ -490,6 +490,82 @@ int ubi_eba_unmap_leb(struct ubi_device *ubi, struct ubi_volume *vol, return err; } +#ifdef CONFIG_MTD_UBI_FASTMAP +/** + * check_mapping - check and fixup a mapping + * @ubi: UBI device description object + * @vol: volume description object + * @lnum: logical eraseblock number + * @pnum: physical eraseblock number + * + * Checks whether a given mapping is valid. Fastmap cannot track LEB unmap + * operations, if such an operation is interrupted the mapping still looks + * good, but upon first read an ECC is reported to the upper layer. + * Normaly during the full-scan at attach time this is fixed, for Fastmap + * we have to deal with it while reading. + * If the PEB behind a LEB shows this symthom we change the mapping to + * %UBI_LEB_UNMAPPED and schedule the PEB for erasure. + * + * Returns 0 on success, negative error code in case of failure. + */ +static int check_mapping(struct ubi_device *ubi, struct ubi_volume *vol, int lnum, + int *pnum) +{ + int err; + struct ubi_vid_io_buf *vidb; + + if (!ubi->fast_attach) + return 0; + + vidb = ubi_alloc_vid_buf(ubi, GFP_NOFS); + if (!vidb) + return -ENOMEM; + + err = ubi_io_read_vid_hdr(ubi, *pnum, vidb, 0); + if (err > 0 && err != UBI_IO_BITFLIPS) { + int torture = 0; + + switch (err) { + case UBI_IO_FF: + case UBI_IO_FF_BITFLIPS: + case UBI_IO_BAD_HDR: + case UBI_IO_BAD_HDR_EBADMSG: + break; + default: + ubi_assert(0); + } + + if (err == UBI_IO_BAD_HDR_EBADMSG || err == UBI_IO_FF_BITFLIPS) + torture = 1; + + down_read(&ubi->fm_eba_sem); + vol->eba_tbl->entries[lnum].pnum = UBI_LEB_UNMAPPED; + up_read(&ubi->fm_eba_sem); + ubi_wl_put_peb(ubi, vol->vol_id, lnum, *pnum, torture); + + *pnum = UBI_LEB_UNMAPPED; + } else if (err < 0) { + ubi_err(ubi, "unable to read VID header back from PEB %i: %i", + *pnum, err); + + goto out_free; + } + + err = 0; + +out_free: + ubi_free_vid_buf(vidb); + + return err; +} +#else +static int check_mapping(struct ubi_device *ubi, struct ubi_volume *vol, int lnum, + int *pnum) +{ + return 0; +} +#endif + /** * ubi_eba_read_leb - read data. * @ubi: UBI device description object @@ -522,7 +598,13 @@ int ubi_eba_read_leb(struct ubi_device *ubi, struct ubi_volume *vol, int lnum, return err; pnum = vol->eba_tbl->entries[lnum].pnum; - if (pnum < 0) { + if (pnum >= 0) { + err = check_mapping(ubi, vol, lnum, &pnum); + if (err < 0) + goto out_unlock; + } + + if (pnum == UBI_LEB_UNMAPPED) { /* * The logical eraseblock is not mapped, fill the whole buffer * with 0xFF bytes. The exception is static volumes for which @@ -930,6 +1012,12 @@ int ubi_eba_write_leb(struct ubi_device *ubi, struct ubi_volume *vol, int lnum, return err; pnum = vol->eba_tbl->entries[lnum].pnum; + if (pnum >= 0) { + err = check_mapping(ubi, vol, lnum, &pnum); + if (err < 0) + goto out; + } + if (pnum >= 0) { dbg_eba("write %d bytes at offset %d of LEB %d:%d, PEB %d", len, offset, vol_id, lnum, pnum);

7 years, 1 month

3
2
0 0

FAILED: patch "[PATCH] ubi: fastmap: Correctly handle interrupted erasures in EBA" failed to apply to 3.18-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 3.18-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 781932375ffc6411713ee0926ccae8596ed0261c Mon Sep 17 00:00:00 2001 From: Richard Weinberger <richard(a)nod.at> Date: Mon, 28 May 2018 22:04:32 +0200 Subject: [PATCH] ubi: fastmap: Correctly handle interrupted erasures in EBA Fastmap cannot track the LEB unmap operation, therefore it can happen that after an interrupted erasure the mapping still looks good from Fastmap's point of view, while reading from the PEB will cause an ECC error and confuses the upper layer. Instead of teaching users of UBI how to deal with that, we read back the VID header and check for errors. If the PEB is empty or shows ECC errors we fixup the mapping and schedule the PEB for erasure. Fixes: dbb7d2a88d2a ("UBI: Add fastmap core") Cc: <stable(a)vger.kernel.org> Reported-by: martin bayern <Martinbayern(a)outlook.com> Signed-off-by: Richard Weinberger <richard(a)nod.at> diff --git a/drivers/mtd/ubi/eba.c b/drivers/mtd/ubi/eba.c index 250e30fac61b..593a4f9d97e3 100644 --- a/drivers/mtd/ubi/eba.c +++ b/drivers/mtd/ubi/eba.c @@ -490,6 +490,82 @@ int ubi_eba_unmap_leb(struct ubi_device *ubi, struct ubi_volume *vol, return err; } +#ifdef CONFIG_MTD_UBI_FASTMAP +/** + * check_mapping - check and fixup a mapping + * @ubi: UBI device description object + * @vol: volume description object + * @lnum: logical eraseblock number + * @pnum: physical eraseblock number + * + * Checks whether a given mapping is valid. Fastmap cannot track LEB unmap + * operations, if such an operation is interrupted the mapping still looks + * good, but upon first read an ECC is reported to the upper layer. + * Normaly during the full-scan at attach time this is fixed, for Fastmap + * we have to deal with it while reading. + * If the PEB behind a LEB shows this symthom we change the mapping to + * %UBI_LEB_UNMAPPED and schedule the PEB for erasure. + * + * Returns 0 on success, negative error code in case of failure. + */ +static int check_mapping(struct ubi_device *ubi, struct ubi_volume *vol, int lnum, + int *pnum) +{ + int err; + struct ubi_vid_io_buf *vidb; + + if (!ubi->fast_attach) + return 0; + + vidb = ubi_alloc_vid_buf(ubi, GFP_NOFS); + if (!vidb) + return -ENOMEM; + + err = ubi_io_read_vid_hdr(ubi, *pnum, vidb, 0); + if (err > 0 && err != UBI_IO_BITFLIPS) { + int torture = 0; + + switch (err) { + case UBI_IO_FF: + case UBI_IO_FF_BITFLIPS: + case UBI_IO_BAD_HDR: + case UBI_IO_BAD_HDR_EBADMSG: + break; + default: + ubi_assert(0); + } + + if (err == UBI_IO_BAD_HDR_EBADMSG || err == UBI_IO_FF_BITFLIPS) + torture = 1; + + down_read(&ubi->fm_eba_sem); + vol->eba_tbl->entries[lnum].pnum = UBI_LEB_UNMAPPED; + up_read(&ubi->fm_eba_sem); + ubi_wl_put_peb(ubi, vol->vol_id, lnum, *pnum, torture); + + *pnum = UBI_LEB_UNMAPPED; + } else if (err < 0) { + ubi_err(ubi, "unable to read VID header back from PEB %i: %i", + *pnum, err); + + goto out_free; + } + + err = 0; + +out_free: + ubi_free_vid_buf(vidb); + + return err; +} +#else +static int check_mapping(struct ubi_device *ubi, struct ubi_volume *vol, int lnum, + int *pnum) +{ + return 0; +} +#endif + /** * ubi_eba_read_leb - read data. * @ubi: UBI device description object @@ -522,7 +598,13 @@ int ubi_eba_read_leb(struct ubi_device *ubi, struct ubi_volume *vol, int lnum, return err; pnum = vol->eba_tbl->entries[lnum].pnum; - if (pnum < 0) { + if (pnum >= 0) { + err = check_mapping(ubi, vol, lnum, &pnum); + if (err < 0) + goto out_unlock; + } + + if (pnum == UBI_LEB_UNMAPPED) { /* * The logical eraseblock is not mapped, fill the whole buffer * with 0xFF bytes. The exception is static volumes for which @@ -930,6 +1012,12 @@ int ubi_eba_write_leb(struct ubi_device *ubi, struct ubi_volume *vol, int lnum, return err; pnum = vol->eba_tbl->entries[lnum].pnum; + if (pnum >= 0) { + err = check_mapping(ubi, vol, lnum, &pnum); + if (err < 0) + goto out; + } + if (pnum >= 0) { dbg_eba("write %d bytes at offset %d of LEB %d:%d, PEB %d", len, offset, vol_id, lnum, pnum);

7 years, 1 month

3
2
0 0

Please apply to stable 4.9 kernel

by Juergen Gross

Hi Greg, please apply the attched backported patch to the 4.9 stable tree. Juergen

7 years, 1 month

2
2
0 0

[BACKPORT PATCH] mtd: nand: fix return value check for bad block status

by Abhishek Sahu

commit e9893e6fa932f42c90c4ac5849fa9aa0f0f00a34 upstream. Positive return value from read_oob() is making false BAD blocks. For some of the NAND controllers, OOB bytes will be protected with ECC and read_oob() will return number of bitflips. If there is any bitflip in ECC protected OOB bytes for BAD block status page, then that block is getting treated as BAD. Fixes: c120e75e0e7d ("mtd: nand: use read_oob() instead of cmdfunc() for bad block check") Cc: <stable(a)vger.kernel.org> Signed-off-by: Abhishek Sahu <absahu(a)codeaurora.org> Reviewed-by: Miquel Raynal <miquel.raynal(a)bootlin.com> Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com> [backported to 4.14.y] Signed-off-by: Abhishek Sahu <absahu(a)codeaurora.org> --- This is backported patch for failed patch mentioned in https://www.spinics.net/lists/stable/msg245833.html The failure happened due to file rename. drivers/mtd/nand/nand_base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c index 528e04f..d410de3 100644 --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -440,7 +440,7 @@ static int nand_block_bad(struct mtd_info *mtd, loff_t ofs) for (; page < page_end; page++) { res = chip->ecc.read_oob(mtd, chip, page); - if (res) + if (res < 0) return res; bad = chip->oob_poi[chip->badblockpos]; -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

7 years, 1 month

2
2
0 0

Please apply to stable 4.9 kernel

by Juergen Gross

Hi Greg, please apply the attched backported patch to the 4.9 stable tree. It is needed to boot Xen PV guests (broken since commit c43b4ff972a986c85bdd8dc1aa05fe23b29ef99c which I didn't realize due to my kernel parameters when testing). Juergen

7 years, 1 month

2
1
0 0

stable request for v4.17.x, v4.14.x, v4.9.x, v4.4.x: ARM: dts: imx6q: Use correct SDMA script for SPI5 core

by Sean Nyekjær

Hi Greg, subject "ARM: dts: imx6q: Use correct SDMA script for SPI5 core" commit df07101e1c4a29e820df02f9989a066988b160e6 upstream. Please apply to v4.17.x, v4.14.x, v4.9.x, v4.4.x. I forgot to write CC: <stable(a)vger.kernel.org> in the commit msg. I hope this can go in the stable trees. Please let me know if the commit was in the queue already and I had done everything correctly. :-) BR /Sean

7 years, 1 month

2
1
0 0

Backport request: bfe72442578b to 4.9.y

by Dan Rue

Hi Greg - Please apply bfe72442578b ("net: phy: micrel: fix crash when statistic requested for KSZ9031 phy") to 4.9.y. Since at least 4.9.95 (this was discussed during 4.9.95 release cycle), 'ethtool --phy-statistics eth0' causes a system crash on micrel systems. This is still happening, and this patch fixes the issue. Thanks! Dan

7 years, 1 month

2
1
0 0

[PATCH] cifs: Fix slab-out-of-bounds in send_set_info() on SMB2 ACE setting

by Stefano Brivio

A "small" CIFS buffer is not big enough in general to hold a setacl request for SMB2, and we end up overflowing the buffer in send_set_info(). For instance: # mount.cifs //127.0.0.1/test /mnt/test -o username=test,password=test,nounix,cifsacl # touch /mnt/test/acltest # getcifsacl /mnt/test/acltest REVISION:0x1 CONTROL:0x9004 OWNER:S-1-5-21-2926364953-924364008-418108241-1000 GROUP:S-1-22-2-1001 ACL:S-1-5-21-2926364953-924364008-418108241-1000:ALLOWED/0x0/0x1e01ff ACL:S-1-22-2-1001:ALLOWED/0x0/R ACL:S-1-22-2-1001:ALLOWED/0x0/R ACL:S-1-5-21-2926364953-924364008-418108241-1000:ALLOWED/0x0/0x1e01ff ACL:S-1-1-0:ALLOWED/0x0/R # setcifsacl -a "ACL:S-1-22-2-1004:ALLOWED/0x0/R" /mnt/test/acltest this setacl will cause the following KASAN splat: [ 330.777927] BUG: KASAN: slab-out-of-bounds in send_set_info+0x4dd/0xc20 [cifs] [ 330.779696] Write of size 696 at addr ffff88010d5e2860 by task setcifsacl/1012 [ 330.781882] CPU: 1 PID: 1012 Comm: setcifsacl Not tainted 4.18.0-rc2+ #2 [ 330.783140] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 [ 330.784395] Call Trace: [ 330.784789] dump_stack+0xc2/0x16b [ 330.786777] print_address_description+0x6a/0x270 [ 330.787520] kasan_report+0x258/0x380 [ 330.788845] memcpy+0x34/0x50 [ 330.789369] send_set_info+0x4dd/0xc20 [cifs] [ 330.799511] SMB2_set_acl+0x76/0xa0 [cifs] [ 330.801395] set_smb2_acl+0x7ac/0xf30 [cifs] [ 330.830888] cifs_xattr_set+0x963/0xe40 [cifs] [ 330.840367] __vfs_setxattr+0x84/0xb0 [ 330.842060] __vfs_setxattr_noperm+0xe6/0x370 [ 330.843848] vfs_setxattr+0xc2/0xd0 [ 330.845519] setxattr+0x258/0x320 [ 330.859211] path_setxattr+0x15b/0x1b0 [ 330.864392] __x64_sys_setxattr+0xc0/0x160 [ 330.866133] do_syscall_64+0x14e/0x4b0 [ 330.876631] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 330.878503] RIP: 0033:0x7ff2e507db0a [ 330.880151] Code: 48 8b 0d 89 93 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 bc 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 56 93 2c 00 f7 d8 64 89 01 48 [ 330.885358] RSP: 002b:00007ffdc4903c18 EFLAGS: 00000246 ORIG_RAX: 00000000000000bc [ 330.887733] RAX: ffffffffffffffda RBX: 000055d1170de140 RCX: 00007ff2e507db0a [ 330.890067] RDX: 000055d1170de7d0 RSI: 000055d115b39184 RDI: 00007ffdc4904818 [ 330.892410] RBP: 0000000000000001 R08: 0000000000000000 R09: 000055d1170de7e4 [ 330.894785] R10: 00000000000002b8 R11: 0000000000000246 R12: 0000000000000007 [ 330.897148] R13: 000055d1170de0c0 R14: 0000000000000008 R15: 000055d1170de550 [ 330.901057] Allocated by task 1012: [ 330.902888] kasan_kmalloc+0xa0/0xd0 [ 330.904714] kmem_cache_alloc+0xc8/0x1d0 [ 330.906615] mempool_alloc+0x11e/0x380 [ 330.908496] cifs_small_buf_get+0x35/0x60 [cifs] [ 330.910510] smb2_plain_req_init+0x4a/0xd60 [cifs] [ 330.912551] send_set_info+0x198/0xc20 [cifs] [ 330.914535] SMB2_set_acl+0x76/0xa0 [cifs] [ 330.916465] set_smb2_acl+0x7ac/0xf30 [cifs] [ 330.918453] cifs_xattr_set+0x963/0xe40 [cifs] [ 330.920426] __vfs_setxattr+0x84/0xb0 [ 330.922284] __vfs_setxattr_noperm+0xe6/0x370 [ 330.924213] vfs_setxattr+0xc2/0xd0 [ 330.926008] setxattr+0x258/0x320 [ 330.927762] path_setxattr+0x15b/0x1b0 [ 330.929592] __x64_sys_setxattr+0xc0/0x160 [ 330.931459] do_syscall_64+0x14e/0x4b0 [ 330.933314] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 330.936843] Freed by task 0: [ 330.938588] (stack is not available) [ 330.941886] The buggy address belongs to the object at ffff88010d5e2800 which belongs to the cache cifs_small_rq of size 448 [ 330.946362] The buggy address is located 96 bytes inside of 448-byte region [ffff88010d5e2800, ffff88010d5e29c0) [ 330.950722] The buggy address belongs to the page: [ 330.952789] page:ffffea0004357880 count:1 mapcount:0 mapping:ffff880108fdca80 index:0x0 compound_mapcount: 0 [ 330.955665] flags: 0x17ffffc0008100(slab|head) [ 330.957760] raw: 0017ffffc0008100 dead000000000100 dead000000000200 ffff880108fdca80 [ 330.960356] raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 [ 330.963005] page dumped because: kasan: bad access detected [ 330.967039] Memory state around the buggy address: [ 330.969255] ffff88010d5e2880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 330.971833] ffff88010d5e2900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 330.974397] >ffff88010d5e2980: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc [ 330.976956] ^ [ 330.979226] ffff88010d5e2a00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 330.981755] ffff88010d5e2a80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 330.984225] ================================================================== Fix this by allocating a regular CIFS buffer in smb2_plain_req_init() if the request command is SMB2_SET_INFO. Reported-by: Jianhong Yin <jiyin(a)redhat.com> Fixes: 366ed846df60 ("cifs: Use smb 2 - 3 and cifsacl mount options setacl function") Signed-off-by: Stefano Brivio <sbrivio(a)redhat.com> --- fs/cifs/smb2pdu.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c index 7608c241b1ef..b2fa834da210 100644 --- a/fs/cifs/smb2pdu.c +++ b/fs/cifs/smb2pdu.c @@ -340,7 +340,10 @@ smb2_plain_req_init(__le16 smb2_command, struct cifs_tcon *tcon, return rc; /* BB eventually switch this to SMB2 specific small buf size */ - *request_buf = cifs_small_buf_get(); + if (smb2_command == SMB2_SET_INFO) + *request_buf = cifs_buf_get(); + else + *request_buf = cifs_small_buf_get(); if (*request_buf == NULL) { /* BB should we add a retry in here if not a writepage? */ return -ENOMEM; @@ -3720,7 +3723,7 @@ send_set_info(const unsigned int xid, struct cifs_tcon *tcon, rc = cifs_send_recv(xid, ses, &rqst, &resp_buftype, flags, &rsp_iov); - cifs_small_buf_release(req); + cifs_buf_release(req); rsp = (struct smb2_set_info_rsp *)rsp_iov.iov_base; if (rc != 0) { -- 2.15.1

7 years, 1 month

3
7
0 0

[PATCH v4 2/3] ioremap: Update pgtable free interfaces with addr

by Toshi Kani

From: Chintan Pandya <cpandya(a)codeaurora.org> The following kernel panic was observed on ARM64 platform due to a stale TLB entry. 1. ioremap with 4K size, a valid pte page table is set. 2. iounmap it, its pte entry is set to 0. 3. ioremap the same address with 2M size, update its pmd entry with a new value. 4. CPU may hit an exception because the old pmd entry is still in TLB, which leads to a kernel panic. Commit b6bdb7517c3d ("mm/vmalloc: add interfaces to free unmapped page table") has addressed this panic by falling to pte mappings in the above case on ARM64. To support pmd mappings in all cases, TLB purge needs to be performed in this case on ARM64. Add a new arg, 'addr', to pud_free_pmd_page() and pmd_free_pte_page() so that TLB purge can be added later in seprate patches. [toshi.kani(a)hpe.com: merge changes, rewrite patch description] Fixes: 28ee90fe6048 ("x86/mm: implement free pmd/pte page interfaces") Signed-off-by: Chintan Pandya <cpandya(a)codeaurora.org> Signed-off-by: Toshi Kani <toshi.kani(a)hpe.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: "H. Peter Anvin" <hpa(a)zytor.com> Cc: Will Deacon <will.deacon(a)arm.com> Cc: Joerg Roedel <joro(a)8bytes.org> Cc: <stable(a)vger.kernel.org> --- arch/arm64/mm/mmu.c | 4 ++-- arch/x86/mm/pgtable.c | 12 +++++++----- include/asm-generic/pgtable.h | 8 ++++---- lib/ioremap.c | 4 ++-- 4 files changed, 15 insertions(+), 13 deletions(-) diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c index 493ff75670ff..8ae5d7ae4af3 100644 --- a/arch/arm64/mm/mmu.c +++ b/arch/arm64/mm/mmu.c @@ -977,12 +977,12 @@ int pmd_clear_huge(pmd_t *pmdp) return 1; } -int pud_free_pmd_page(pud_t *pud) +int pud_free_pmd_page(pud_t *pud, unsigned long addr) { return pud_none(*pud); } -int pmd_free_pte_page(pmd_t *pmd) +int pmd_free_pte_page(pmd_t *pmd, unsigned long addr) { return pmd_none(*pmd); } diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c index 1aeb7a5dbce5..fbd14e506758 100644 --- a/arch/x86/mm/pgtable.c +++ b/arch/x86/mm/pgtable.c @@ -723,11 +723,12 @@ int pmd_clear_huge(pmd_t *pmd) /** * pud_free_pmd_page - Clear pud entry and free pmd page. * @pud: Pointer to a PUD. + * @addr: Virtual address associated with pud. * * Context: The pud range has been unmaped and TLB purged. * Return: 1 if clearing the entry succeeded. 0 otherwise. */ -int pud_free_pmd_page(pud_t *pud) +int pud_free_pmd_page(pud_t *pud, unsigned long addr) { pmd_t *pmd; int i; @@ -738,7 +739,7 @@ int pud_free_pmd_page(pud_t *pud) pmd = (pmd_t *)pud_page_vaddr(*pud); for (i = 0; i < PTRS_PER_PMD; i++) - if (!pmd_free_pte_page(&pmd[i])) + if (!pmd_free_pte_page(&pmd[i], addr + (i * PMD_SIZE))) return 0; pud_clear(pud); @@ -750,11 +751,12 @@ int pud_free_pmd_page(pud_t *pud) /** * pmd_free_pte_page - Clear pmd entry and free pte page. * @pmd: Pointer to a PMD. + * @addr: Virtual address associated with pmd. * * Context: The pmd range has been unmaped and TLB purged. * Return: 1 if clearing the entry succeeded. 0 otherwise. */ -int pmd_free_pte_page(pmd_t *pmd) +int pmd_free_pte_page(pmd_t *pmd, unsigned long addr) { pte_t *pte; @@ -770,7 +772,7 @@ int pmd_free_pte_page(pmd_t *pmd) #else /* !CONFIG_X86_64 */ -int pud_free_pmd_page(pud_t *pud) +int pud_free_pmd_page(pud_t *pud, unsigned long addr) { return pud_none(*pud); } @@ -779,7 +781,7 @@ int pud_free_pmd_page(pud_t *pud) * Disable free page handling on x86-PAE. This assures that ioremap() * does not update sync'd pmd entries. See vmalloc_sync_one(). */ -int pmd_free_pte_page(pmd_t *pmd) +int pmd_free_pte_page(pmd_t *pmd, unsigned long addr) { return pmd_none(*pmd); } diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h index f59639afaa39..b081794ba135 100644 --- a/include/asm-generic/pgtable.h +++ b/include/asm-generic/pgtable.h @@ -1019,8 +1019,8 @@ int pud_set_huge(pud_t *pud, phys_addr_t addr, pgprot_t prot); int pmd_set_huge(pmd_t *pmd, phys_addr_t addr, pgprot_t prot); int pud_clear_huge(pud_t *pud); int pmd_clear_huge(pmd_t *pmd); -int pud_free_pmd_page(pud_t *pud); -int pmd_free_pte_page(pmd_t *pmd); +int pud_free_pmd_page(pud_t *pud, unsigned long addr); +int pmd_free_pte_page(pmd_t *pmd, unsigned long addr); #else /* !CONFIG_HAVE_ARCH_HUGE_VMAP */ static inline int p4d_set_huge(p4d_t *p4d, phys_addr_t addr, pgprot_t prot) { @@ -1046,11 +1046,11 @@ static inline int pmd_clear_huge(pmd_t *pmd) { return 0; } -static inline int pud_free_pmd_page(pud_t *pud) +static inline int pud_free_pmd_page(pud_t *pud, unsigned long addr) { return 0; } -static inline int pmd_free_pte_page(pmd_t *pmd) +static inline int pmd_free_pte_page(pmd_t *pmd, unsigned long addr) { return 0; } diff --git a/lib/ioremap.c b/lib/ioremap.c index 54e5bbaa3200..517f5853ffed 100644 --- a/lib/ioremap.c +++ b/lib/ioremap.c @@ -92,7 +92,7 @@ static inline int ioremap_pmd_range(pud_t *pud, unsigned long addr, if (ioremap_pmd_enabled() && ((next - addr) == PMD_SIZE) && IS_ALIGNED(phys_addr + addr, PMD_SIZE) && - pmd_free_pte_page(pmd)) { + pmd_free_pte_page(pmd, addr)) { if (pmd_set_huge(pmd, phys_addr + addr, prot)) continue; } @@ -119,7 +119,7 @@ static inline int ioremap_pud_range(p4d_t *p4d, unsigned long addr, if (ioremap_pud_enabled() && ((next - addr) == PUD_SIZE) && IS_ALIGNED(phys_addr + addr, PUD_SIZE) && - pud_free_pmd_page(pud)) { + pud_free_pmd_page(pud, addr)) { if (pud_set_huge(pud, phys_addr + addr, prot)) continue; }

7 years, 1 month

5
9
0 0

[PATCH] cifs: Fix infinite loop when using hard mount option

by Paulo Alcantara

For every request we send, whether it is SMB1 or SMB2+, we attempt to reconnect tcon (cifs_reconnect_tcon or smb2_reconnect) before carrying out the request. So, while server->tcpStatus != CifsNeedReconnect, we wait for the reconnection to succeed on wait_event_interruptible_timeout(). If it returns, that means that either the condition was evaluated to true, or timeout elapsed, or it was interrupted by a signal. Since we're not handling the case where the process woke up due to a received signal (-ERESTARTSYS), the next call to wait_event_interruptible_timeout() will _always_ fail and we end up looping forever inside either cifs_reconnect_tcon() or smb2_reconnect(). Here's an example of how to trigger that: $ mount.cifs //foo/share /mnt/test -o username=foo,password=foo,vers=1.0,hard (break connection to server before executing bellow cmd) $ stat -f /mnt/test & sleep 140 [1] 2511 $ ps -aux -q 2511 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 2511 0.0 0.0 12892 1008 pts/0 S 12:24 0:00 stat -f /mnt/test $ kill -9 2511 (wait for a while; process is stuck in the kernel) $ ps -aux -q 2511 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 2511 83.2 0.0 12892 1008 pts/0 R 12:24 30:01 stat -f /mnt/test By using 'hard' mount point means that cifs.ko will keep retrying indefinitely, however we must allow the process to be killed otherwise it would hang the system. Signed-off-by: Paulo Alcantara <palcantara(a)suse.de> Cc: stable(a)vger.kernel.org --- fs/cifs/cifssmb.c | 10 ++++++++-- fs/cifs/smb2pdu.c | 18 ++++++++++++------ 2 files changed, 20 insertions(+), 8 deletions(-) diff --git a/fs/cifs/cifssmb.c b/fs/cifs/cifssmb.c index d352da325de3..93408eab92e7 100644 --- a/fs/cifs/cifssmb.c +++ b/fs/cifs/cifssmb.c @@ -157,8 +157,14 @@ cifs_reconnect_tcon(struct cifs_tcon *tcon, int smb_command) * greater than cifs socket timeout which is 7 seconds */ while (server->tcpStatus == CifsNeedReconnect) { - wait_event_interruptible_timeout(server->response_q, - (server->tcpStatus != CifsNeedReconnect), 10 * HZ); + rc = wait_event_interruptible_timeout(server->response_q, + (server->tcpStatus != CifsNeedReconnect), + 10 * HZ); + if (rc < 0) { + cifs_dbg(FYI, "%s: aborting reconnect due to a received" + " signal by the process\n", __func__); + return -ERESTARTSYS; + } /* are we still trying to reconnect? */ if (server->tcpStatus != CifsNeedReconnect) diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c index 810b85787c91..086629b0d59c 100644 --- a/fs/cifs/smb2pdu.c +++ b/fs/cifs/smb2pdu.c @@ -155,7 +155,7 @@ smb2_hdr_assemble(struct smb2_sync_hdr *shdr, __le16 smb2_cmd, static int smb2_reconnect(__le16 smb2_command, struct cifs_tcon *tcon) { - int rc = 0; + int rc; struct nls_table *nls_codepage; struct cifs_ses *ses; struct TCP_Server_Info *server; @@ -166,10 +166,10 @@ smb2_reconnect(__le16 smb2_command, struct cifs_tcon *tcon) * for those three - in the calling routine. */ if (tcon == NULL) - return rc; + return 0; if (smb2_command == SMB2_TREE_CONNECT) - return rc; + return 0; if (tcon->tidStatus == CifsExiting) { /* @@ -212,8 +212,14 @@ smb2_reconnect(__le16 smb2_command, struct cifs_tcon *tcon) return -EAGAIN; } - wait_event_interruptible_timeout(server->response_q, - (server->tcpStatus != CifsNeedReconnect), 10 * HZ); + rc = wait_event_interruptible_timeout(server->response_q, + (server->tcpStatus != CifsNeedReconnect), + 10 * HZ); + if (rc < 0) { + cifs_dbg(FYI, "%s: aborting reconnect due to a received" + " signal by the process\n", __func__); + return -ERESTARTSYS; + } /* are we still trying to reconnect? */ if (server->tcpStatus != CifsNeedReconnect) @@ -231,7 +237,7 @@ smb2_reconnect(__le16 smb2_command, struct cifs_tcon *tcon) } if (!tcon->ses->need_reconnect && !tcon->need_reconnect) - return rc; + return 0; nls_codepage = load_nls_default(); -- 2.18.0

7 years, 1 month

2
1
0 0

Re: [PATCH] ARM64: dts: meson-gxl-s905x-p212: Add phy-supply for usb0

by Neil Armstrong

Hi Stable Maintainers, On 05/06/2018 10:52, Neil Armstrong wrote: > Like LibreTech-CC, the USB0 needs the 5V regulator to be enabled to power the > devices on the P212 Reference Design based boards. > > Fixes: b9f07cb4f41f ("ARM64: dts: meson-gxl-s905x-p212: enable the USB controller") > Signed-off-by: Neil Armstrong <narmstrong(a)baylibre.com> > --- This commit hit Linus master with commit sha d511b3e4087eedbe11c7496c396432b8b7c2d7d9 Can this fix be applied to 4.17 stable kernel ? Thanks, Neil > arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi > index 0cfd701..a1b3101 100644 > --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi > +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi > @@ -189,3 +189,10 @@ > &usb0 { > status = "okay"; > }; > + > +&usb2_phy0 { > + /* > + * HDMI_5V is also used as supply for the USB VBUS. > + */ > + phy-supply = <&hdmi_5v>; > +}; >

7 years, 1 month

2
1
0 0

stable request: Revert "sit: reload iphdr in ipip6_rcv"

by Luca Boccassi

Hello, Please consider backporting to 4.9.y the following commit from DaveM [CC'ed]: f4eb17e1efe538d4da7d574bedb00a8dafcc26b7 ("Revert "sit: reload iphdr in ipip6_rcv"") It cherry-picks cleanly and builds fine. The original commit was introduced and reverted in v4.12-rc5, but only the original made its way into the 4.9 stable release (v4.9.94). It causes a regression: pings to v6 hosts over a SIT tunnel do not work anymore, and the following error appears in dmesg: kernel: sit: non-ECT from 0.0.0.0 with TOS=0xd This was also reported and reverted downstream by Ubuntu: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1772775 Thanks! -- Kind regards, Luca Boccassi

7 years, 1 month

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror