May 2018 - Linux-stable-mirror

Re: [PATCH] usb: dwc2: fix the incorrect bitmaps for the ports of multi_tt hub

by Doug Anderson

Hi, On Mon, May 21, 2018 at 3:12 AM, William Wu <william.wu(a)rock-chips.com> wrote: > The dwc2_get_ls_map() use ttport to reference into the > bitmap if we're on a multi_tt hub. But the bitmaps index > from 0 to (hub->maxchild - 1), while the ttport index from > 1 to hub->maxchild. This will cause invalid memory access > when the number of ttport is hub->maxchild. > > Without this patch, I can easily meet a Kernel panic issue > if connect a low-speed USB mouse with the max port of FE2.1 > multi-tt hub (1a40:0201) on rk3288 platform. > > Signed-off-by: William Wu <william.wu(a)rock-chips.com> > --- > drivers/usb/dwc2/hcd_queue.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/usb/dwc2/hcd_queue.c b/drivers/usb/dwc2/hcd_queue.c > index d7c3d6c..9c55d1a 100644 > --- a/drivers/usb/dwc2/hcd_queue.c > +++ b/drivers/usb/dwc2/hcd_queue.c > @@ -383,7 +383,7 @@ static unsigned long *dwc2_get_ls_map(struct dwc2_hsotg *hsotg, > /* Get the map and adjust if this is a multi_tt hub */ > map = qh->dwc_tt->periodic_bitmaps; > if (qh->dwc_tt->usb_tt->multi) > - map += DWC2_ELEMENTS_PER_LS_BITMAP * qh->ttport; > + map += DWC2_ELEMENTS_PER_LS_BITMAP * (qh->ttport - 1); Oops, thanks for the fix. Fixes: 9f9f09b048f5 ("usb: dwc2: host: Totally redo the microframe scheduler") Cc: stable(a)vger.kernel.org Reviewed-by: Douglas Anderson <dianders(a)chromium.org> -Doug

6 years, 1 month

1
0
0 0

+ mm-devm_memremap_pages-handle-errors-allocating-final-devres-action.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm, devm_memremap_pages: handle errors allocating final devres action has been added to the -mm tree. Its filename is mm-devm_memremap_pages-handle-errors-allocating-final-devres-action.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-devm_memremap_pages-handle-erro… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-devm_memremap_pages-handle-erro… 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: Dan Williams <dan.j.williams(a)intel.com> Subject: mm, devm_memremap_pages: handle errors allocating final devres action The last step before devm_memremap_pages() returns success is to allocate a release action to tear the entire setup down. However, the result from devm_add_action() is not checked. Checking the error also means that we need to handle the fact that the percpu_ref may not be killed by the time devm_memremap_pages_release() runs. Add a new state flag for this case. Link: http://lkml.kernel.org/r/152694212460.5484.13180030631810166467.stgit@dwill… Fixes: e8d513483300 ("memremap: change devm_memremap_pages interface...") Signed-off-by: Dan Williams <dan.j.williams(a)intel.com> Cc: Christoph Hellwig <hch(a)lst.de> Cc: "Jérôme Glisse" <jglisse(a)redhat.com> Cc: Logan Gunthorpe <logang(a)deltatee.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/memremap.h | 1 + kernel/memremap.c | 8 ++++++-- 2 files changed, 7 insertions(+), 2 deletions(-) diff -puN include/linux/memremap.h~mm-devm_memremap_pages-handle-errors-allocating-final-devres-action include/linux/memremap.h --- a/include/linux/memremap.h~mm-devm_memremap_pages-handle-errors-allocating-final-devres-action +++ a/include/linux/memremap.h @@ -115,6 +115,7 @@ struct dev_pagemap { dev_page_free_t page_free; struct vmem_altmap altmap; bool altmap_valid; + bool registered; struct resource res; struct percpu_ref *ref; struct device *dev; diff -puN kernel/memremap.c~mm-devm_memremap_pages-handle-errors-allocating-final-devres-action kernel/memremap.c --- a/kernel/memremap.c~mm-devm_memremap_pages-handle-errors-allocating-final-devres-action +++ a/kernel/memremap.c @@ -296,7 +296,7 @@ static void devm_memremap_pages_release( for_each_device_pfn(pfn, pgmap) put_page(pfn_to_page(pfn)); - if (percpu_ref_tryget_live(pgmap->ref)) { + if (pgmap->registered && percpu_ref_tryget_live(pgmap->ref)) { dev_WARN(dev, "%s: page mapping is still live!\n", __func__); percpu_ref_put(pgmap->ref); } @@ -418,7 +418,11 @@ void *devm_memremap_pages(struct device percpu_ref_get(pgmap->ref); } - devm_add_action(dev, devm_memremap_pages_release, pgmap); + error = devm_add_action_or_reset(dev, devm_memremap_pages_release, + pgmap); + if (error) + return ERR_PTR(error); + pgmap->registered = true; return __va(res->start); _ Patches currently in -mm which might be from dan.j.williams(a)intel.com are mm-devm_memremap_pages-mark-devm_memremap_pages-export_symbol_gpl.patch mm-devm_memremap_pages-handle-errors-allocating-final-devres-action.patch mm-hmm-use-devm-semantics-for-hmm_devmem_add-remove.patch mm-hmm-replace-hmm_devmem_pages_create-with-devm_memremap_pages.patch mm-hmm-mark-hmm_devmem_add-add_resource-export_symbol_gpl.patch

6 years, 1 month

1
0
0 0

RE: [PATCH] mtd: rawnand: micron: Fix support for on-die ECC

by Bean Huo (beanhuo)

Hi, Boris Sorry for the later as for I am in a long vacation. Here how the SR should behave: the status register is updated after each array operation and can be cleared with a reset command. After a read operation the status register bit0 will report the ECC status of the read until a different array operation is performed (erase/program/read) or a reset occurs. The status register bit1 will report the status of the time before last time operation. So, this bit can report a fail (value 1) even if the very last operation was successful (bit0=0 bit1=1). //beanhuo > >--- >Peter, Bean, > >Can you confirm this behavior, or ask someone in Micron who can confirm it? >Also, if a RESET is actually needed, it would be good to update the datasheet >accordingly. And if that's not the case, can you explain why the >NAND_STATUS_FAIL bit is stuck and how to clear it (I tried a 0x00 command, >A.K.A. READ STATUS EXIT, but it does not clear this bit, ERASE and PROGRAM >seem to clear the bit, but that's clearly not the kind of operation I can do >when the user asks for a READ)? > >Thanks, > >Boris

6 years, 1 month

1
0
0 0

[PATCH] dmaengine: ensure dmaengine helpers check valid callback

by Fabrizio Castro

From: Vinod Koul <vinod.koul(a)intel.com> commit 757d12e5849be549076901b0d33c60d5f360269c upstream. dmaengine has various device callbacks and exposes helper functions to invoke these. These helpers should check if channel, device and callback is valid or not before invoking them. Reported-by: Jon Hunter <jonathanh(a)nvidia.com> Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> [fabrizio: cherry-pick to 4.4] Signed-off-by: Fabrizio Castro <fabrizio.castro(a)bp.renesas.com> Signed-off-by: Jianming Qiao <jianming.qiao(a)bp.renesas.com> --- Hello Greg, while backporting commit 757d12e5849be549076901b0d33c60d5f360269c to the CIP kernel Ben recommended to send the same patch to you for 4.4 stable. I hope the format of the commit is the one you expect (reference to the upstream commit, version to cherry-pick the patch to, and Signed-off-by tags). Thanks, Fab include/linux/dmaengine.h | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h index c47c68e..a16d185 100644 --- a/include/linux/dmaengine.h +++ b/include/linux/dmaengine.h @@ -767,6 +767,9 @@ static inline struct dma_async_tx_descriptor *dmaengine_prep_slave_single( sg_dma_address(&sg) = buf; sg_dma_len(&sg) = len; + if (!chan || !chan->device || !chan->device->device_prep_slave_sg) + return NULL; + return chan->device->device_prep_slave_sg(chan, &sg, 1, dir, flags, NULL); } @@ -775,6 +778,9 @@ static inline struct dma_async_tx_descriptor *dmaengine_prep_slave_sg( struct dma_chan *chan, struct scatterlist *sgl, unsigned int sg_len, enum dma_transfer_direction dir, unsigned long flags) { + if (!chan || !chan->device || !chan->device->device_prep_slave_sg) + return NULL; + return chan->device->device_prep_slave_sg(chan, sgl, sg_len, dir, flags, NULL); } @@ -786,6 +792,9 @@ static inline struct dma_async_tx_descriptor *dmaengine_prep_rio_sg( enum dma_transfer_direction dir, unsigned long flags, struct rio_dma_ext *rio_ext) { + if (!chan || !chan->device || !chan->device->device_prep_slave_sg) + return NULL; + return chan->device->device_prep_slave_sg(chan, sgl, sg_len, dir, flags, rio_ext); } @@ -796,6 +805,9 @@ static inline struct dma_async_tx_descriptor *dmaengine_prep_dma_cyclic( size_t period_len, enum dma_transfer_direction dir, unsigned long flags) { + if (!chan || !chan->device || !chan->device->device_prep_dma_cyclic) + return NULL; + return chan->device->device_prep_dma_cyclic(chan, buf_addr, buf_len, period_len, dir, flags); } @@ -804,6 +816,9 @@ static inline struct dma_async_tx_descriptor *dmaengine_prep_interleaved_dma( struct dma_chan *chan, struct dma_interleaved_template *xt, unsigned long flags) { + if (!chan || !chan->device || !chan->device->device_prep_interleaved_dma) + return NULL; + return chan->device->device_prep_interleaved_dma(chan, xt, flags); } @@ -811,7 +826,7 @@ static inline struct dma_async_tx_descriptor *dmaengine_prep_dma_memset( struct dma_chan *chan, dma_addr_t dest, int value, size_t len, unsigned long flags) { - if (!chan || !chan->device) + if (!chan || !chan->device || !chan->device->device_prep_dma_memset) return NULL; return chan->device->device_prep_dma_memset(chan, dest, value, @@ -824,6 +839,9 @@ static inline struct dma_async_tx_descriptor *dmaengine_prep_dma_sg( struct scatterlist *src_sg, unsigned int src_nents, unsigned long flags) { + if (!chan || !chan->device || !chan->device->device_prep_dma_sg) + return NULL; + return chan->device->device_prep_dma_sg(chan, dst_sg, dst_nents, src_sg, src_nents, flags); } -- 2.7.4

6 years, 1 month

2
1
0 0

[PATCH ghak82] audit: Fix wrong task in comparison of session ID

by Ondrej Mosnacek

The audit_filter_rules() function in auditsc.c compared the session ID with the credentials of the current task, while it should use the credentials of the task given to audit_filter_rules() as a parameter (tsk). GitHub issue: https://github.com/linux-audit/audit-kernel/issues/82 Fixes: 8fae47705685 ("audit: add support for session ID user filter") Cc: stable(a)vger.kernel.org Signed-off-by: Ondrej Mosnacek <omosnace(a)redhat.com> --- kernel/auditsc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/auditsc.c b/kernel/auditsc.c index ec38e4d97c23..6d577a34b16b 100644 --- a/kernel/auditsc.c +++ b/kernel/auditsc.c @@ -513,7 +513,7 @@ static int audit_filter_rules(struct task_struct *tsk, result = audit_gid_comparator(cred->fsgid, f->op, f->gid); break; case AUDIT_SESSIONID: - sessionid = audit_get_sessionid(current); + sessionid = audit_get_sessionid(tsk); result = audit_comparator(sessionid, f->op, f->val); break; case AUDIT_PERS: -- 2.17.0

6 years, 1 month

3
4
0 0

[merged] mm-dont-allow-deferred-pages-with-need_per_cpu_km.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm: don't allow deferred pages with NEED_PER_CPU_KM has been removed from the -mm tree. Its filename was mm-dont-allow-deferred-pages-with-need_per_cpu_km.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: don't allow deferred pages with NEED_PER_CPU_KM It is unsafe to do virtual to physical translations before mm_init() is called if struct page is needed in order to determine the memory section number (see SECTION_IN_PAGE_FLAGS). This is because only in mm_init() we initialize struct pages for all the allocated memory when deferred struct pages are used. My recent fix c9e97a1997 ("mm: initialize pages on demand during boot") exposed this problem, because it greatly reduced number of pages that are initialized before mm_init(), but the problem existed even before my fix, as Fengguang Wu found. Below is a more detailed explanation of the problem. We initialize struct pages in four places: 1. Early in boot a small set of struct pages is initialized to fill the first section, and lower zones. 2. During mm_init() we initialize "struct pages" for all the memory that is allocated, i.e reserved in memblock. 3. Using on-demand logic when pages are allocated after mm_init call (when memblock is finished) 4. After smp_init() when the rest free deferred pages are initialized. The problem occurs if we try to do va to phys translation of a memory between steps 1 and 2. Because we have not yet initialized struct pages for all the reserved pages, it is inherently unsafe to do va to phys if the translation itself requires access of "struct page" as in case of this combination: CONFIG_SPARSE && !CONFIG_SPARSE_VMEMMAP The following path exposes the problem: start_kernel() trap_init() setup_cpu_entry_areas() setup_cpu_entry_area(cpu) get_cpu_gdt_paddr(cpu) per_cpu_ptr_to_phys(addr) pcpu_addr_to_page(addr) virt_to_page(addr) pfn_to_page(__pa(addr) >> PAGE_SHIFT) We disable this path by not allowing NEED_PER_CPU_KM with deferred struct pages feature. The problems are discussed in these threads: http://lkml.kernel.org/r/20180418135300.inazvpxjxowogyge@wfg-t540p.sh.intel… http://lkml.kernel.org/r/20180419013128.iurzouiqxvcnpbvz@wfg-t540p.sh.intel… http://lkml.kernel.org/r/20180426202619.2768-1-pasha.tatashin@oracle.com Link: http://lkml.kernel.org/r/20180515175124.1770-1-pasha.tatashin@oracle.com Fixes: 3a80a7fa7989 ("mm: meminit: initialise a subset of struct pages if CONFIG_DEFERRED_STRUCT_PAGE_INIT is set") Signed-off-by: Pavel Tatashin <pasha.tatashin(a)oracle.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org> Cc: Steven Sistare <steven.sistare(a)oracle.com> Cc: Daniel Jordan <daniel.m.jordan(a)oracle.com> Cc: Mel Gorman <mgorman(a)techsingularity.net> Cc: Fengguang Wu <fengguang.wu(a)intel.com> Cc: Dennis Zhou <dennisszhou(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/Kconfig | 1 + 1 file changed, 1 insertion(+) diff -puN mm/Kconfig~mm-dont-allow-deferred-pages-with-need_per_cpu_km mm/Kconfig --- a/mm/Kconfig~mm-dont-allow-deferred-pages-with-need_per_cpu_km +++ a/mm/Kconfig @@ -636,6 +636,7 @@ config DEFERRED_STRUCT_PAGE_INIT default n depends on NO_BOOTMEM depends on !FLATMEM + depends on !NEED_PER_CPU_KM help Ordinarily all struct pages are initialised during early boot in a single thread. On very large machines this can take a considerable _ Patches currently in -mm which might be from pasha.tatashin(a)oracle.com are sparc64-ng4-memset-32-bits-overflow.patch

6 years, 1 month

1
0
0 0

[merged] radix-tree-fix-multi-order-iteration-race.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: radix tree: fix multi-order iteration race has been removed from the -mm tree. Its filename was radix-tree-fix-multi-order-iteration-race.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Ross Zwisler <ross.zwisler(a)linux.intel.com> Subject: radix tree: fix multi-order iteration race Fix a race in the multi-order iteration code which causes the kernel to hit a GP fault. This was first seen with a production v4.15 based kernel (4.15.6-300.fc27.x86_64) utilizing a DAX workload which used order 9 PMD DAX entries. The race has to do with how we tear down multi-order sibling entries when we are removing an item from the tree. Remember for example that an order 2 entry looks like this: struct radix_tree_node.slots[] = [entry][sibling][sibling][sibling] where 'entry' is in some slot in the struct radix_tree_node, and the three slots following 'entry' contain sibling pointers which point back to 'entry.' When we delete 'entry' from the tree, we call : radix_tree_delete() radix_tree_delete_item() __radix_tree_delete() replace_slot() replace_slot() first removes the siblings in order from the first to the last, then at then replaces 'entry' with NULL. This means that for a brief period of time we end up with one or more of the siblings removed, so: struct radix_tree_node.slots[] = [entry][NULL][sibling][sibling] This causes an issue if you have a reader iterating over the slots in the tree via radix_tree_for_each_slot() while only under rcu_read_lock()/rcu_read_unlock() protection. This is a common case in mm/filemap.c. The issue is that when __radix_tree_next_slot() => skip_siblings() tries to skip over the sibling entries in the slots, it currently does so with an exact match on the slot directly preceding our current slot. Normally this works: V preceding slot struct radix_tree_node.slots[] = [entry][sibling][sibling][sibling] ^ current slot This lets you find the first sibling, and you skip them all in order. But in the case where one of the siblings is NULL, that slot is skipped and then our sibling detection is interrupted: V preceding slot struct radix_tree_node.slots[] = [entry][NULL][sibling][sibling] ^ current slot This means that the sibling pointers aren't recognized since they point all the way back to 'entry', so we think that they are normal internal radix tree pointers. This causes us to think we need to walk down to a struct radix_tree_node starting at the address of 'entry'. In a real running kernel this will crash the thread with a GP fault when you try and dereference the slots in your broken node starting at 'entry'. We fix this race by fixing the way that skip_siblings() detects sibling nodes. Instead of testing against the preceding slot we instead look for siblings via is_sibling_entry() which compares against the position of the struct radix_tree_node.slots[] array. This ensures that sibling entries are properly identified, even if they are no longer contiguous with the 'entry' they point to. Link: http://lkml.kernel.org/r/20180503192430.7582-6-ross.zwisler@linux.intel.com Fixes: 148deab223b2 ("radix-tree: improve multiorder iterators") Signed-off-by: Ross Zwisler <ross.zwisler(a)linux.intel.com> Reported-by: CR, Sapthagirish <sapthagirish.cr(a)intel.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: Christoph Hellwig <hch(a)lst.de> Cc: Dan Williams <dan.j.williams(a)intel.com> Cc: Dave Chinner <david(a)fromorbit.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- lib/radix-tree.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff -puN lib/radix-tree.c~radix-tree-fix-multi-order-iteration-race lib/radix-tree.c --- a/lib/radix-tree.c~radix-tree-fix-multi-order-iteration-race +++ a/lib/radix-tree.c @@ -1612,11 +1612,9 @@ static void set_iter_tags(struct radix_t static void __rcu **skip_siblings(struct radix_tree_node **nodep, void __rcu **slot, struct radix_tree_iter *iter) { - void *sib = node_to_entry(slot - 1); - while (iter->index < iter->next_index) { *nodep = rcu_dereference_raw(*slot); - if (*nodep && *nodep != sib) + if (*nodep && !is_sibling_entry(iter->node, *nodep)) return slot; slot++; iter->index = __radix_tree_iter_add(iter, 1); @@ -1631,7 +1629,7 @@ void __rcu **__radix_tree_next_slot(void struct radix_tree_iter *iter, unsigned flags) { unsigned tag = flags & RADIX_TREE_ITER_TAG_MASK; - struct radix_tree_node *node = rcu_dereference_raw(*slot); + struct radix_tree_node *node; slot = skip_siblings(&node, slot, iter); _ Patches currently in -mm which might be from ross.zwisler(a)linux.intel.com are

6 years, 1 month

1
0
0 0

[merged] lib-test_bitmapc-fix-bitmap-optimisation-tests-to-report-errors-correctly.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: lib/test_bitmap.c: fix bitmap optimisation tests to report errors correctly has been removed from the -mm tree. Its filename was lib-test_bitmapc-fix-bitmap-optimisation-tests-to-report-errors-correctly.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Matthew Wilcox <mawilcox(a)microsoft.com> Subject: lib/test_bitmap.c: fix bitmap optimisation tests to report errors correctly I had neglected to increment the error counter when the tests failed, which made the tests noisy when they fail, but not actually return an error code. Link: http://lkml.kernel.org/r/20180509114328.9887-1-mpe@ellerman.id.au Fixes: 3cc78125a081 ("lib/test_bitmap.c: add optimisation tests") Signed-off-by: Matthew Wilcox <mawilcox(a)microsoft.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Reported-by: Michael Ellerman <mpe(a)ellerman.id.au> Tested-by: Michael Ellerman <mpe(a)ellerman.id.au> Reviewed-by: Kees Cook <keescook(a)chromium.org> Cc: Yury Norov <ynorov(a)caviumnetworks.com> Cc: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Cc: Geert Uytterhoeven <geert(a)linux-m68k.org> Cc: <stable(a)vger.kernel.org> [4.13+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- lib/test_bitmap.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff -puN lib/test_bitmap.c~lib-test_bitmapc-fix-bitmap-optimisation-tests-to-report-errors-correctly lib/test_bitmap.c --- a/lib/test_bitmap.c~lib-test_bitmapc-fix-bitmap-optimisation-tests-to-report-errors-correctly +++ a/lib/test_bitmap.c @@ -331,23 +331,32 @@ static void noinline __init test_mem_opt unsigned int start, nbits; for (start = 0; start < 1024; start += 8) { - memset(bmap1, 0x5a, sizeof(bmap1)); - memset(bmap2, 0x5a, sizeof(bmap2)); for (nbits = 0; nbits < 1024 - start; nbits += 8) { + memset(bmap1, 0x5a, sizeof(bmap1)); + memset(bmap2, 0x5a, sizeof(bmap2)); + bitmap_set(bmap1, start, nbits); __bitmap_set(bmap2, start, nbits); - if (!bitmap_equal(bmap1, bmap2, 1024)) + if (!bitmap_equal(bmap1, bmap2, 1024)) { printk("set not equal %d %d\n", start, nbits); - if (!__bitmap_equal(bmap1, bmap2, 1024)) + failed_tests++; + } + if (!__bitmap_equal(bmap1, bmap2, 1024)) { printk("set not __equal %d %d\n", start, nbits); + failed_tests++; + } bitmap_clear(bmap1, start, nbits); __bitmap_clear(bmap2, start, nbits); - if (!bitmap_equal(bmap1, bmap2, 1024)) + if (!bitmap_equal(bmap1, bmap2, 1024)) { printk("clear not equal %d %d\n", start, nbits); - if (!__bitmap_equal(bmap1, bmap2, 1024)) + failed_tests++; + } + if (!__bitmap_equal(bmap1, bmap2, 1024)) { printk("clear not __equal %d %d\n", start, nbits); + failed_tests++; + } } } } _ Patches currently in -mm which might be from mawilcox(a)microsoft.com are idr-fix-invalid-ptr-dereference-on-item-delete.patch slab-__gfp_zero-is-incompatible-with-a-constructor.patch s390-use-_refcount-for-pgtables.patch mm-split-page_type-out-from-_mapcount.patch mm-mark-pages-in-use-for-page-tables.patch mm-switch-s_mem-and-slab_cache-in-struct-page.patch mm-move-private-union-within-struct-page.patch mm-move-_refcount-out-of-struct-page-union.patch mm-combine-first-three-unions-in-struct-page.patch mm-use-page-deferred_list.patch mm-move-lru-union-within-struct-page.patch mm-combine-lru-and-main-union-in-struct-page.patch mm-improve-struct-page-documentation.patch mm-add-pt_mm-to-struct-page.patch mm-add-hmm_data-to-struct-page.patch slabslub-remove-rcu_head-size-checks.patch slub-remove-kmem_cache-reserved.patch slub-remove-reserved-file-from-sysfs.patch mm-distinguish-vmalloc-pages.patch ida-remove-simple_ida_lock.patch

6 years, 1 month

1
0
0 0

Please include following patches to 4.4/4.9/4.14

by Nikolay Borisov

Hello Greg, Here are trivial backports for upstream commit, which is tagged as stable: 02a3307aa9c2 ("btrfs: fix reading stale metadata blocks after degraded raid1 mounts") Regards, Nikolay

6 years, 1 month

2
8
0 0

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

by Sudip Mukherjee

From: Sudip Mukherjee <sudipm.mukherjee(a)gmail.com> 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: Martin K. Petersen <martin.petersen(a)oracle.com> Cc: stable(a)vger.kernel.org Signed-off-by: Sudip Mukherjee <sudipm.mukherjee(a)gmail.com> --- This is a resend of v1. v2 was blacklisting all Micron SSDs but Martin has confirmed that only M500IT with MU01 firmware is affected. 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 eaf0f42f6f28..cdcd55cb2a9a 100644 --- a/drivers/ata/libata-core.c +++ b/drivers/ata/libata-core.c @@ -4554,6 +4554,8 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = { { "SanDisk SD7UB3Q*G1001", NULL, 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.11.0

6 years, 1 month

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2018