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

[Linux-stable-mirror] [PATCH v2 2/3] blk-mq-debugfs: Also show requests that have not yet been started

by Bart Van Assche

When debugging e.g. the SCSI timeout handler it is important that requests that have not yet been started or that already have completed are also reported through debugfs. Fixes: commit 2720bab50258 ("blk-mq-debugfs: Show busy requests") Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: Ming Lei <ming.lei(a)redhat.com> Cc: Christoph Hellwig <hch(a)lst.de> Cc: Hannes Reinecke <hare(a)suse.com> Cc: Johannes Thumshirn <jthumshirn(a)suse.de> Cc: Martin K. Petersen <martin.petersen(a)oracle.com> Cc: stable(a)vger.kernel.org --- block/blk-mq-debugfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/block/blk-mq-debugfs.c b/block/blk-mq-debugfs.c index f7db73f1698e..886b37163f17 100644 --- a/block/blk-mq-debugfs.c +++ b/block/blk-mq-debugfs.c @@ -409,7 +409,7 @@ static void hctx_show_busy_rq(struct request *rq, void *data, bool reserved) const struct show_busy_params *params = data; if (blk_mq_map_queue(rq->q, rq->mq_ctx->cpu) == params->hctx && - test_bit(REQ_ATOM_STARTED, &rq->atomic_flags)) + list_empty(&rq->queuelist)) __blk_mq_debugfs_rq_show(params->m, list_entry_rq(&rq->queuelist)); } -- 2.15.0

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] + autofs-fix-careless-error-in-recent-commit.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: autofs: fix careless error in recent commit has been added to the -mm tree. Its filename is autofs-fix-careless-error-in-recent-commit.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/autofs-fix-careless-error-in-recen… and later at http://ozlabs.org/~akpm/mmotm/broken-out/autofs-fix-careless-error-in-recen… 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/SubmitChecklist when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: NeilBrown <neilb(a)suse.com> Subject: autofs: fix careless error in recent commit ecc0c469f277 ("autofs: don't fail mount for transient error") was meant to replace an 'if' with a 'switch', but instead added the 'switch' leaving the case in place. Link: http://lkml.kernel.org/r/87zi6wstmw.fsf@notabene.neil.brown.name Fixes: ecc0c469f277 ("autofs: don't fail mount for transient error") Reported-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk> Signed-off-by: NeilBrown <neilb(a)suse.com> Cc: Ian Kent <raven(a)themaw.net> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/autofs4/waitq.c | 1 - 1 file changed, 1 deletion(-) diff -puN fs/autofs4/waitq.c~autofs-fix-careless-error-in-recent-commit fs/autofs4/waitq.c --- a/fs/autofs4/waitq.c~autofs-fix-careless-error-in-recent-commit +++ a/fs/autofs4/waitq.c @@ -170,7 +170,6 @@ static void autofs4_notify_daemon(struct mutex_unlock(&sbi->wq_mutex); - if (autofs4_write(sbi, pipe, &pkt, pktsz)) switch (ret = autofs4_write(sbi, pipe, &pkt, pktsz)) { case 0: break; _ Patches currently in -mm which might be from neilb(a)suse.com are autofs-fix-careless-error-in-recent-commit.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] UFS utilities

by Bean Huo (beanhuo)

Hi, all Is there someone knows if exists one utilis dedicated to UFS device, rather than SCSI utils? I have tried sg3-utils, but it is not convenient for the embedded ARM-based system. And also it doesn't support several UFS special command. If we don't have this kind of tool for UFS, is it necessary for us to develop a ufs-utils? I need your every expert's inputs and suggestions. Thanks in advance. //Bean Huo

7 years, 10 months

4
5
0 0

[Linux-stable-mirror] + stringh-work-around-for-increased-stack-usage.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: string.h: workaround for increased stack usage has been added to the -mm tree. Its filename is stringh-work-around-for-increased-stack-usage.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/stringh-work-around-for-increased-… and later at http://ozlabs.org/~akpm/mmotm/broken-out/stringh-work-around-for-increased-… 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/SubmitChecklist when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Arnd Bergmann <arnd(a)arndb.de> Subject: string.h: workaround for increased stack usage The hardened strlen() function causes rather large stack usage in at least one file in the kernel, in particular when CONFIG_KASAN is enabled: drivers/media/usb/em28xx/em28xx-dvb.c: In function 'em28xx_dvb_init': drivers/media/usb/em28xx/em28xx-dvb.c:2062:1: error: the frame size of 3256 bytes is larger than 204 bytes [-Werror=frame-larger-than=] Analyzing this problem led to the discovery that gcc fails to merge the stack slots for the i2c_board_info[] structures after we strlcpy() into them, due to the 'noreturn' attribute on the source string length check. I reported this as a gcc bug, but it is unlikely to get fixed for gcc-8, since it is relatively easy to work around, and it gets triggered rarely. An earlier workaround I did added an empty inline assembly statement before the call to fortify_panic(), which works surprisingly well, but is really ugly and unintuitive. This is a new approach to the same problem, this time addressing it by not calling the 'extern __real_strnlen()' function for string constants where __builtin_strlen() is a compile-time constant and therefore known to be safe. We do this by checking if the last character in the string is a compile-time constant '\0'. If it is, we can assume that strlen() of the string is also constant. As a side-effect, this should also improve the object code output for any other call of strlen() on a string constant. Link: http://lkml.kernel.org/r/20171205215143.3085755-1-arnd@arndb.de Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82365 Link: https://patchwork.kernel.org/patch/9980413/ Link: https://patchwork.kernel.org/patch/9974047/ Fixes: 6974f0c4555 ("include/linux/string.h: add the option of fortified string.h functions") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Cc: Kees Cook <keescook(a)chromium.org> Cc: Mauro Carvalho Chehab <mchehab(a)kernel.org> Cc: Dmitry Vyukov <dvyukov(a)google.com> Cc: Alexander Potapenko <glider(a)google.com> Cc: Andrey Ryabinin <aryabinin(a)virtuozzo.com> Cc: Daniel Micay <danielmicay(a)gmail.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Martin Wilck <mwilck(a)suse.com> Cc: Dan Williams <dan.j.williams(a)intel.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/string.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff -puN include/linux/string.h~stringh-work-around-for-increased-stack-usage include/linux/string.h --- a/include/linux/string.h~stringh-work-around-for-increased-stack-usage +++ a/include/linux/string.h @@ -259,7 +259,8 @@ __FORTIFY_INLINE __kernel_size_t strlen( { __kernel_size_t ret; size_t p_size = __builtin_object_size(p, 0); - if (p_size == (size_t)-1) + if (p_size == (size_t)-1 || + (__builtin_constant_p(p[p_size - 1]) && p[p_size - 1] == '\0')) return __builtin_strlen(p); ret = strnlen(p, p_size); if (p_size <= ret) _ Patches currently in -mm which might be from arnd(a)arndb.de are stringh-work-around-for-increased-stack-usage.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] [PATCH] string.h: work around for increased stack usage

by Arnd Bergmann

The hardened strlen() function causes rather large stack usage in at least one file in the kernel, in particular when CONFIG_KASAN is enabled: drivers/media/usb/em28xx/em28xx-dvb.c: In function 'em28xx_dvb_init': drivers/media/usb/em28xx/em28xx-dvb.c:2062:1: error: the frame size of 3256 bytes is larger than 204 bytes [-Werror=frame-larger-than=] Analyzing this problem led to the discovery that gcc fails to merge the stack slots for the i2c_board_info[] structures after we strlcpy() into them, due to the 'noreturn' attribute on the source string length check. I reported this as a gcc bug, but it is unlikely to get fixed for gcc-8, since it is relatively easy to work around, and it gets triggered rarely. An earlier workaround I did added an empty inline assembly statement before the call to fortify_panic(), which works surprisingly well, but is really ugly and unintuitive. This is a new approach to the same problem, this time addressing it by not calling the 'extern __real_strnlen()' function for string constants where __builtin_strlen() is a compile-time constant and therefore known to be safe. We do this by checking if the last character in the string is a compile-time constant '\0'. If it is, we can assume that strlen() of the string is also constant. As a side-effect, this should also improve the object code output for any other call of strlen() on a string constant. Cc: stable(a)vger.kernel.org Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82365 Link: https://patchwork.kernel.org/patch/9980413/ Link: https://patchwork.kernel.org/patch/9974047/ Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- v3: don't use an asm barrier but use a constant string change. Aside from two other patches for drivers/media that I sent last week, this should fix all stack frames above 2KB, once all three are merged, I'll send the patch to re-enable the warning. --- include/linux/string.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/linux/string.h b/include/linux/string.h index 410ecf17de3c..e5cc3f27f6e0 100644 --- a/include/linux/string.h +++ b/include/linux/string.h @@ -259,7 +259,8 @@ __FORTIFY_INLINE __kernel_size_t strlen(const char *p) { __kernel_size_t ret; size_t p_size = __builtin_object_size(p, 0); - if (p_size == (size_t)-1) + if (p_size == (size_t)-1 || + (__builtin_constant_p(p[p_size - 1]) && p[p_size - 1] == '\0')) return __builtin_strlen(p); ret = strnlen(p, p_size); if (p_size <= ret) -- 2.9.0

7 years, 10 months

2
1
0 0

[Linux-stable-mirror] [PATCH rdma-rc 2/4] IB/core: Don't enforce PKey security on SMI MADs

by Leon Romanovsky

From: Daniel Jurgens <danielj(a)mellanox.com> Per the infiniband spec an SMI MAD can have any PKey. Checking the pkey on SMI MADs is not necessary, and it seems that some older adapters using the mthca driver don't follow the convention of using the default PKey, resulting in false denials, or errors querying the PKey cache. SMI MAD security is still enforced, only agents allowed to manage the subnet are able to receive or send SMI MADs. Reported-by: Chris Blake <chrisrblake93(a)gmail.com> Cc: <stable(a)vger.kernel.org> # v4.12 Fixes: 47a2b338fe63 ("IB/core: Enforce security on management datagrams") Signed-off-by: Daniel Jurgens <danielj(a)mellanox.com> Reviewed-by: Parav Pandit <parav(a)mellanox.com> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> --- drivers/infiniband/core/security.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/infiniband/core/security.c b/drivers/infiniband/core/security.c index a337386652b0..feafdb961c48 100644 --- a/drivers/infiniband/core/security.c +++ b/drivers/infiniband/core/security.c @@ -739,8 +739,11 @@ int ib_mad_enforce_security(struct ib_mad_agent_private *map, u16 pkey_index) if (!rdma_protocol_ib(map->agent.device, map->agent.port_num)) return 0; - if (map->agent.qp->qp_type == IB_QPT_SMI && !map->agent.smp_allowed) - return -EACCES; + if (map->agent.qp->qp_type == IB_QPT_SMI) { + if (!map->agent.smp_allowed) + return -EACCES; + return 0; + } return ib_security_pkey_access(map->agent.device, map->agent.port_num, -- 2.15.1

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] [PATCH rdma-rc 1/4] IB/core: Bound check alternate path port number

by Leon Romanovsky

From: Daniel Jurgens <danielj(a)mellanox.com> The alternate port number is used as an array index in the IB security implementation, invalid values can result in a kernel panic. Cc: <stable(a)vger.kernel.org> # v4.12 Fixes: d291f1a65232 ("IB/core: Enforce PKey security on QPs") Signed-off-by: Daniel Jurgens <danielj(a)mellanox.com> Reviewed-by: Parav Pandit <parav(a)mellanox.com> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> --- drivers/infiniband/core/uverbs_cmd.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/infiniband/core/uverbs_cmd.c b/drivers/infiniband/core/uverbs_cmd.c index 16d55710b116..d0202bb176a4 100644 --- a/drivers/infiniband/core/uverbs_cmd.c +++ b/drivers/infiniband/core/uverbs_cmd.c @@ -1971,6 +1971,12 @@ static int modify_qp(struct ib_uverbs_file *file, goto release_qp; } + if ((cmd->base.attr_mask & IB_QP_ALT_PATH) && + !rdma_is_port_valid(qp->device, cmd->base.alt_port_num)) { + ret = -EINVAL; + goto release_qp; + } + attr->qp_state = cmd->base.qp_state; attr->cur_qp_state = cmd->base.cur_qp_state; attr->path_mtu = cmd->base.path_mtu; -- 2.15.1

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] FAILED: patch "[PATCH] mm/page_ext.c: check if page_ext is not prepared" 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 e492080e640c2d1235ddf3441cae634cfffef7e1 Mon Sep 17 00:00:00 2001 From: Jaewon Kim <jaewon31.kim(a)samsung.com> Date: Wed, 15 Nov 2017 17:39:07 -0800 Subject: [PATCH] mm/page_ext.c: check if page_ext is not prepared online_page_ext() and page_ext_init() allocate page_ext for each section, but they do not allocate if the first PFN is !pfn_present(pfn) or !pfn_valid(pfn). Then section->page_ext remains as NULL. lookup_page_ext checks NULL only if CONFIG_DEBUG_VM is enabled. For a valid PFN, __set_page_owner will try to get page_ext through lookup_page_ext. Without CONFIG_DEBUG_VM lookup_page_ext will misuse NULL pointer as value 0. This incurrs invalid address access. This is the panic example when PFN 0x100000 is not valid but PFN 0x13FC00 is being used for page_ext. section->page_ext is NULL, get_entry returned invalid page_ext address as 0x1DFA000 for a PFN 0x13FC00. To avoid this panic, CONFIG_DEBUG_VM should be removed so that page_ext will be checked at all times. Unable to handle kernel paging request at virtual address 01dfa014 ------------[ cut here ]------------ Kernel BUG at ffffff80082371e0 [verbose debug info unavailable] Internal error: Oops: 96000045 [#1] PREEMPT SMP Modules linked in: PC is at __set_page_owner+0x48/0x78 LR is at __set_page_owner+0x44/0x78 __set_page_owner+0x48/0x78 get_page_from_freelist+0x880/0x8e8 __alloc_pages_nodemask+0x14c/0xc48 __do_page_cache_readahead+0xdc/0x264 filemap_fault+0x2ac/0x550 ext4_filemap_fault+0x3c/0x58 __do_fault+0x80/0x120 handle_mm_fault+0x704/0xbb0 do_page_fault+0x2e8/0x394 do_mem_abort+0x88/0x124 Pre-4.7 kernels also need commit f86e4271978b ("mm: check the return value of lookup_page_ext for all call sites"). Link: http://lkml.kernel.org/r/20171107094131.14621-1-jaewon31.kim@samsung.com Fixes: eefa864b701d ("mm/page_ext: resurrect struct page extending code for debugging") Signed-off-by: Jaewon Kim <jaewon31.kim(a)samsung.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Minchan Kim <minchan(a)kernel.org> Cc: Joonsoo Kim <js1304(a)gmail.com> Cc: <stable(a)vger.kernel.org> [depends on f86e427197, see above] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> diff --git a/mm/page_ext.c b/mm/page_ext.c index 4f0367d472c4..2c16216c29b6 100644 --- a/mm/page_ext.c +++ b/mm/page_ext.c @@ -125,7 +125,6 @@ struct page_ext *lookup_page_ext(struct page *page) struct page_ext *base; base = NODE_DATA(page_to_nid(page))->node_page_ext; -#if defined(CONFIG_DEBUG_VM) /* * The sanity checks the page allocator does upon freeing a * page can reach here before the page_ext arrays are @@ -134,7 +133,6 @@ struct page_ext *lookup_page_ext(struct page *page) */ if (unlikely(!base)) return NULL; -#endif index = pfn - round_down(node_start_pfn(page_to_nid(page)), MAX_ORDER_NR_PAGES); return get_entry(base, index); @@ -199,7 +197,6 @@ struct page_ext *lookup_page_ext(struct page *page) { unsigned long pfn = page_to_pfn(page); struct mem_section *section = __pfn_to_section(pfn); -#if defined(CONFIG_DEBUG_VM) /* * The sanity checks the page allocator does upon freeing a * page can reach here before the page_ext arrays are @@ -208,7 +205,6 @@ struct page_ext *lookup_page_ext(struct page *page) */ if (!section->page_ext) return NULL; -#endif return get_entry(section->page_ext, pfn); }

7 years, 10 months

5
16
0 0

[Linux-stable-mirror] [PATCH] btrfs: Handle btrfs_set_extent_delalloc failure

by Nikolay Borisov

This function was introduced by 247e743cbe6e ("Btrfs: Use async helpers to deal with pages that have been improperly dirtied") and it didn't do any error handling then. This function might very well fail in ENOMEM situation, yet it's not handled, this could lead to inconsistent state. So let's handle the failure by setting the mapping error bit. Signed-off-by: Nikolay Borisov <nborisov(a)suse.com> Cc: stable(a)vger.kernel.org --- fs/btrfs/inode.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 993061f83067..7a5a46fefdb4 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -2098,8 +2098,15 @@ static void btrfs_writepage_fixup_worker(struct btrfs_work *work) goto out; } - btrfs_set_extent_delalloc(inode, page_start, page_end, 0, &cached_state, - 0); + ret = btrfs_set_extent_delalloc(inode, page_start, page_end, 0, + &cached_state, 0); + if (ret) { + mapping_set_error(page->mapping, ret); + end_extent_writepage(page, ret, page_start, page_end); + ClearPageChecked(page); + goto out; + } + ClearPageChecked(page); set_page_dirty(page); btrfs_delalloc_release_extents(BTRFS_I(inode), PAGE_SIZE); -- 2.7.4

7 years, 10 months

2
1
0 0

Re: [Linux-stable-mirror] Patch "bcache: only permit to recovery read error when cache device is clean" has been added to the 4.9-stable tree

by Greg KH

On Mon, Nov 27, 2017 at 09:35:02AM -0800, Michael Lyle wrote: > On Mon, Nov 27, 2017 at 9:01 AM, Jens Axboe <axboe(a)kernel.dk> wrote: > > > On 11/27/2017 09:45 AM, Eddie Chapman wrote: > > > On 27/11/17 16:06, gregkh(a)linuxfoundation.org wrote: > > >> > > >> This is a note to let you know that I've just added the patch titled > > >> > > >> bcache: only permit to recovery read error when cache device is > > clean > > > > > > > Hi Greg, > > > > > > This patch is an important fix for a possible data corruption issue, but > > > it also introduces a bug that can produce read errors under certain > > > circumstances. The issue introduced by this patch is not as severe as > > > the issue it fixes, but can lead to e.g. upper layer fs remounting read > > > only. In my environment upper layer handled it badly and indirectly > > > resulted in data loss (not directly bcache's fault of course). > > > > > > Michael Lyle CC'd the stable list with a follow up fix for the issue > > > introduced by this patch, on 24th Nov, subject "bcache: recover data > > > from backing when data is clean". > > > > > > However, the followup fix is not in Linus' tree yet, only in Michael's. > > > I guess that means you can't pick it up yet. Never-the-less I felt it > > > important to point this out here. > > > > It's commit e393aa2446150536929140739f09c6ecbcbea7f0 in my tree and will > > go upstream shortly - but yes, probably should not add this one, before > > both can be pulled in. > > > Thanks everyone for the quick reply on this. I agree. Ok, I've dropped this patch from all of the stable queues for now. thanks, greg k-h

7 years, 10 months

3
5
0 0

[Linux-stable-mirror] Patch "mm, oom_reaper: gather each vma to prevent leaking TLB entry" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mm, oom_reaper: gather each vma to prevent leaking TLB entry to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mm-oom_reaper-gather-each-vma-to-prevent-leaking-tlb-entry.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 687cb0884a714ff484d038e9190edc874edcf146 Mon Sep 17 00:00:00 2001 From: Wang Nan <wangnan0(a)huawei.com> Date: Wed, 29 Nov 2017 16:09:58 -0800 Subject: mm, oom_reaper: gather each vma to prevent leaking TLB entry From: Wang Nan <wangnan0(a)huawei.com> commit 687cb0884a714ff484d038e9190edc874edcf146 upstream. tlb_gather_mmu(&tlb, mm, 0, -1) means gathering the whole virtual memory space. In this case, tlb->fullmm is true. Some archs like arm64 doesn't flush TLB when tlb->fullmm is true: commit 5a7862e83000 ("arm64: tlbflush: avoid flushing when fullmm == 1"). Which causes leaking of tlb entries. Will clarifies his patch: "Basically, we tag each address space with an ASID (PCID on x86) which is resident in the TLB. This means we can elide TLB invalidation when pulling down a full mm because we won't ever assign that ASID to another mm without doing TLB invalidation elsewhere (which actually just nukes the whole TLB). I think that means that we could potentially not fault on a kernel uaccess, because we could hit in the TLB" There could be a window between complete_signal() sending IPI to other cores and all threads sharing this mm are really kicked off from cores. In this window, the oom reaper may calls tlb_flush_mmu_tlbonly() to flush TLB then frees pages. However, due to the above problem, the TLB entries are not really flushed on arm64. Other threads are possible to access these pages through TLB entries. Moreover, a copy_to_user() can also write to these pages without generating page fault, causes use-after-free bugs. This patch gathers each vma instead of gathering full vm space. In this case tlb->fullmm is not true. The behavior of oom reaper become similar to munmapping before do_exit, which should be safe for all archs. Link: http://lkml.kernel.org/r/20171107095453.179940-1-wangnan0@huawei.com Fixes: aac453635549 ("mm, oom: introduce oom reaper") Signed-off-by: Wang Nan <wangnan0(a)huawei.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Acked-by: David Rientjes <rientjes(a)google.com> Cc: Minchan Kim <minchan(a)kernel.org> Cc: Will Deacon <will.deacon(a)arm.com> Cc: Bob Liu <liubo95(a)huawei.com> Cc: Ingo Molnar <mingo(a)kernel.org> Cc: Roman Gushchin <guro(a)fb.com> Cc: Konstantin Khlebnikov <khlebnikov(a)yandex-team.ru> Cc: Andrea Arcangeli <aarcange(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> [backported to 4.9 stable tree] Signed-off-by: Michal Hocko <mhocko(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- mm/oom_kill.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) --- a/mm/oom_kill.c +++ b/mm/oom_kill.c @@ -524,7 +524,6 @@ static bool __oom_reap_task_mm(struct ta */ set_bit(MMF_UNSTABLE, &mm->flags); - tlb_gather_mmu(&tlb, mm, 0, -1); for (vma = mm->mmap ; vma; vma = vma->vm_next) { if (is_vm_hugetlb_page(vma)) continue; @@ -546,11 +545,13 @@ static bool __oom_reap_task_mm(struct ta * we do not want to block exit_mmap by keeping mm ref * count elevated without a good reason. */ - if (vma_is_anonymous(vma) || !(vma->vm_flags & VM_SHARED)) + if (vma_is_anonymous(vma) || !(vma->vm_flags & VM_SHARED)) { + tlb_gather_mmu(&tlb, mm, vma->vm_start, vma->vm_end); unmap_page_range(&tlb, vma, vma->vm_start, vma->vm_end, &details); + tlb_finish_mmu(&tlb, vma->vm_start, vma->vm_end); + } } - tlb_finish_mmu(&tlb, 0, -1); pr_info("oom_reaper: reaped process %d (%s), now anon-rss:%lukB, file-rss:%lukB, shmem-rss:%lukB\n", task_pid_nr(tsk), tsk->comm, K(get_mm_counter(mm, MM_ANONPAGES)), Patches currently in stable-queue which might be from wangnan0(a)huawei.com are queue-4.9/mm-oom_reaper-gather-each-vma-to-prevent-leaking-tlb-entry.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/amdgpu: Use unsigned ring indices in amdgpu_queue_mgr_map" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/amdgpu: Use unsigned ring indices in amdgpu_queue_mgr_map to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-amdgpu-use-unsigned-ring-indices-in-amdgpu_queue_mgr_map.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From fa7c7939b4bf112cd06ba166b739244077898990 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Michel=20D=C3=A4nzer?= <michel.daenzer(a)amd.com> Date: Wed, 22 Nov 2017 15:55:21 +0100 Subject: drm/amdgpu: Use unsigned ring indices in amdgpu_queue_mgr_map MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Michel Dänzer <michel.daenzer(a)amd.com> commit fa7c7939b4bf112cd06ba166b739244077898990 upstream. This matches the corresponding UAPI fields. Treating the ring index as signed could result in accessing random unrelated memory if the MSB was set. Fixes: effd924d2f3b ("drm/amdgpu: untie user ring ids from kernel ring ids v6") Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Michel Dänzer <michel.daenzer(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_queue_mgr.c | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h @@ -697,7 +697,7 @@ int amdgpu_queue_mgr_fini(struct amdgpu_ struct amdgpu_queue_mgr *mgr); int amdgpu_queue_mgr_map(struct amdgpu_device *adev, struct amdgpu_queue_mgr *mgr, - int hw_ip, int instance, int ring, + u32 hw_ip, u32 instance, u32 ring, struct amdgpu_ring **out_ring); /* --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_queue_mgr.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_queue_mgr.c @@ -63,7 +63,7 @@ static int amdgpu_update_cached_map(stru static int amdgpu_identity_map(struct amdgpu_device *adev, struct amdgpu_queue_mapper *mapper, - int ring, + u32 ring, struct amdgpu_ring **out_ring) { switch (mapper->hw_ip) { @@ -121,7 +121,7 @@ static enum amdgpu_ring_type amdgpu_hw_i static int amdgpu_lru_map(struct amdgpu_device *adev, struct amdgpu_queue_mapper *mapper, - int user_ring, + u32 user_ring, struct amdgpu_ring **out_ring) { int r, i, j; @@ -208,7 +208,7 @@ int amdgpu_queue_mgr_fini(struct amdgpu_ */ int amdgpu_queue_mgr_map(struct amdgpu_device *adev, struct amdgpu_queue_mgr *mgr, - int hw_ip, int instance, int ring, + u32 hw_ip, u32 instance, u32 ring, struct amdgpu_ring **out_ring) { int r, ip_num_rings; Patches currently in stable-queue which might be from michel.daenzer(a)amd.com are queue-4.14/drm-amdgpu-use-unsigned-ring-indices-in-amdgpu_queue_mgr_map.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] Patch "usbip: tools: Install all headers needed for libusbip development" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usbip: tools: Install all headers needed for libusbip development to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usbip-tools-install-all-headers-needed-for-libusbip-development.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Dec 5 18:18:39 CET 2017 From: Ben Hutchings <ben(a)decadent.org.uk> Date: Sun, 1 Oct 2017 02:18:37 +0100 Subject: usbip: tools: Install all headers needed for libusbip development From: Ben Hutchings <ben(a)decadent.org.uk> [ Upstream commit c15562c0dcb2c7f26e891923b784cf1926b8c833 ] usbip_host_driver.h now depends on several additional headers, which need to be installed along with it. Fixes: 021aed845303 ("staging: usbip: userspace: migrate usbip_host_driver ...") Fixes: 3391ba0e2792 ("usbip: tools: Extract generic code to be shared with ...") Signed-off-by: Ben Hutchings <ben(a)decadent.org.uk> Acked-by: Shuah Khan <shuahkh(a)osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/usb/usbip/Makefile.am | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/tools/usb/usbip/Makefile.am +++ b/tools/usb/usbip/Makefile.am @@ -1,6 +1,7 @@ SUBDIRS := libsrc src includedir = @includedir@/usbip include_HEADERS := $(addprefix libsrc/, \ - usbip_common.h vhci_driver.h usbip_host_driver.h) + usbip_common.h vhci_driver.h usbip_host_driver.h \ + list.h sysfs_utils.h usbip_host_common.h) dist_man_MANS := $(addprefix doc/, usbip.8 usbipd.8) Patches currently in stable-queue which might be from ben(a)decadent.org.uk are queue-3.18/usbip-tools-install-all-headers-needed-for-libusbip-development.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] Patch "tipc: fix cleanup at module unload" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled tipc: fix cleanup at module unload to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: tipc-fix-cleanup-at-module-unload.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Dec 5 18:18:39 CET 2017 From: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan(a)ericsson.com> Date: Tue, 24 Jan 2017 13:00:48 +0100 Subject: tipc: fix cleanup at module unload From: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan(a)ericsson.com> [ Upstream commit 35e22e49a5d6a741ebe7f2dd280b2052c3003ef7 ] In tipc_server_stop(), we iterate over the connections with limiting factor as server's idr_in_use. We ignore the fact that this variable is decremented in tipc_close_conn(), leading to premature exit. In this commit, we iterate until the we have no connections left. Acked-by: Ying Xue <ying.xue(a)windriver.com> Acked-by: Jon Maloy <jon.maloy(a)ericsson.com> Tested-by: John Thompson <thompa.atl(a)gmail.com> Signed-off-by: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan(a)ericsson.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/tipc/server.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) --- a/net/tipc/server.c +++ b/net/tipc/server.c @@ -579,14 +579,12 @@ int tipc_server_start(struct tipc_server void tipc_server_stop(struct tipc_server *s) { struct tipc_conn *con; - int total = 0; int id; spin_lock_bh(&s->idr_lock); - for (id = 0; total < s->idr_in_use; id++) { + for (id = 0; s->idr_in_use; id++) { con = idr_find(&s->conn_idr, id); if (con) { - total++; spin_unlock_bh(&s->idr_lock); tipc_close_conn(con); spin_lock_bh(&s->idr_lock); Patches currently in stable-queue which might be from parthasarathy.bhuvaragan(a)ericsson.com are queue-3.18/tipc-fix-cleanup-at-module-unload.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] Patch "vti6: fix device register to report IFLA_INFO_KIND" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled vti6: fix device register to report IFLA_INFO_KIND to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: vti6-fix-device-register-to-report-ifla_info_kind.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Dec 5 18:18:39 CET 2017 From: David Forster <dforster(a)brocade.com> Date: Fri, 6 Jan 2017 10:27:59 +0000 Subject: vti6: fix device register to report IFLA_INFO_KIND From: David Forster <dforster(a)brocade.com> [ Upstream commit 93e246f783e6bd1bc64fdfbfe68b18161f69b28e ] vti6 interface is registered before the rtnl_link_ops block is attached. As a result the resulting RTM_NEWLINK is missing IFLA_INFO_KIND. Re-order attachment of rtnl_link_ops block to fix. Signed-off-by: Dave Forster <dforster(a)brocade.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/ipv6/ip6_vti.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/net/ipv6/ip6_vti.c +++ b/net/ipv6/ip6_vti.c @@ -172,12 +172,12 @@ static int vti6_tnl_create2(struct net_d struct vti6_net *ip6n = net_generic(net, vti6_net_id); int err; + dev->rtnl_link_ops = &vti6_link_ops; err = register_netdevice(dev); if (err < 0) goto out; strcpy(t->parms.name, dev->name); - dev->rtnl_link_ops = &vti6_link_ops; dev_hold(dev); vti6_tnl_link(ip6n, t); Patches currently in stable-queue which might be from dforster(a)brocade.com are queue-3.18/vti6-fix-device-register-to-report-ifla_info_kind.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] Patch "sysrq : fix Show Regs call trace on ARM" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sysrq : fix Show Regs call trace on ARM to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: sysrq-fix-show-regs-call-trace-on-arm.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Dec 5 18:18:39 CET 2017 From: Jibin Xu <jibin.xu(a)windriver.com> Date: Sun, 10 Sep 2017 20:11:42 -0700 Subject: sysrq : fix Show Regs call trace on ARM From: Jibin Xu <jibin.xu(a)windriver.com> [ Upstream commit b00bebbc301c8e1f74f230dc82282e56b7e7a6db ] When kernel configuration SMP,PREEMPT and DEBUG_PREEMPT are enabled, echo 1 >/proc/sys/kernel/sysrq echo p >/proc/sysrq-trigger kernel will print call trace as below: sysrq: SysRq : Show Regs BUG: using __this_cpu_read() in preemptible [00000000] code: sh/435 caller is __this_cpu_preempt_check+0x18/0x20 Call trace: [<ffffff8008088e80>] dump_backtrace+0x0/0x1d0 [<ffffff8008089074>] show_stack+0x24/0x30 [<ffffff8008447970>] dump_stack+0x90/0xb0 [<ffffff8008463950>] check_preemption_disabled+0x100/0x108 [<ffffff8008463998>] __this_cpu_preempt_check+0x18/0x20 [<ffffff80084c9194>] sysrq_handle_showregs+0x1c/0x40 [<ffffff80084c9c7c>] __handle_sysrq+0x12c/0x1a0 [<ffffff80084ca140>] write_sysrq_trigger+0x60/0x70 [<ffffff8008251e00>] proc_reg_write+0x90/0xd0 [<ffffff80081f1788>] __vfs_write+0x48/0x90 [<ffffff80081f241c>] vfs_write+0xa4/0x190 [<ffffff80081f3354>] SyS_write+0x54/0xb0 [<ffffff80080833f0>] el0_svc_naked+0x24/0x28 This can be seen on a common board like an r-pi3. This happens because when echo p >/proc/sysrq-trigger, get_irq_regs() is called outside of IRQ context, if preemption is enabled in this situation,kernel will print the call trace. Since many prior discussions on the mailing lists have made it clear that get_irq_regs either just returns NULL or stale data when used outside of IRQ context,we simply avoid calling it outside of IRQ context. Signed-off-by: Jibin Xu <jibin.xu(a)windriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/sysrq.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) --- a/drivers/tty/sysrq.c +++ b/drivers/tty/sysrq.c @@ -237,8 +237,10 @@ static void sysrq_handle_showallcpus(int * architecture has no support for it: */ if (!trigger_all_cpu_backtrace()) { - struct pt_regs *regs = get_irq_regs(); + struct pt_regs *regs = NULL; + if (in_irq()) + regs = get_irq_regs(); if (regs) { printk(KERN_INFO "CPU%d:\n", smp_processor_id()); show_regs(regs); @@ -257,7 +259,10 @@ static struct sysrq_key_op sysrq_showall static void sysrq_handle_showregs(int key) { - struct pt_regs *regs = get_irq_regs(); + struct pt_regs *regs = NULL; + + if (in_irq()) + regs = get_irq_regs(); if (regs) show_regs(regs); perf_event_print_debug(); Patches currently in stable-queue which might be from jibin.xu(a)windriver.com are queue-3.18/sysrq-fix-show-regs-call-trace-on-arm.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] Patch "spi: sh-msiof: Fix DMA transfer size check" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled spi: sh-msiof: Fix DMA transfer size check to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: spi-sh-msiof-fix-dma-transfer-size-check.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Dec 5 18:18:39 CET 2017 From: Hiromitsu Yamasaki <hiromitsu.yamasaki.ym(a)renesas.com> Date: Thu, 2 Nov 2017 10:32:36 +0100 Subject: spi: sh-msiof: Fix DMA transfer size check From: Hiromitsu Yamasaki <hiromitsu.yamasaki.ym(a)renesas.com> [ Upstream commit 36735783fdb599c94b9c86824583df367c65900b ] DMA supports 32-bit words only, even if BITLEN1 of SITMDR2 register is 16bit. Fixes: b0d0ce8b6b91 ("spi: sh-msiof: Add DMA support") Signed-off-by: Hiromitsu Yamasaki <hiromitsu.yamasaki.ym(a)renesas.com> Signed-off-by: Simon Horman <horms+renesas(a)verge.net.au> Acked-by: Geert Uytterhoeven <geert+renesas(a)glider.be> Acked-by: Dirk Behme <dirk.behme(a)de.bosch.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/spi/spi-sh-msiof.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/spi/spi-sh-msiof.c +++ b/drivers/spi/spi-sh-msiof.c @@ -818,7 +818,7 @@ static int sh_msiof_transfer_one(struct break; copy32 = copy_bswap32; } else if (bits <= 16) { - if (l & 1) + if (l & 3) break; copy32 = copy_wswap32; } else { Patches currently in stable-queue which might be from hiromitsu.yamasaki.ym(a)renesas.com are queue-3.18/spi-sh-msiof-fix-dma-transfer-size-check.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] Patch "perf test attr: Fix ignored test case result" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled perf test attr: Fix ignored test case result to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: perf-test-attr-fix-ignored-test-case-result.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Dec 5 18:18:39 CET 2017 From: Thomas Richter <tmricht(a)linux.vnet.ibm.com> Date: Wed, 13 Sep 2017 10:12:09 +0200 Subject: perf test attr: Fix ignored test case result From: Thomas Richter <tmricht(a)linux.vnet.ibm.com> [ Upstream commit 22905582f6dd4bbd0c370fe5732c607452010c04 ] Command perf test -v 16 (Setup struct perf_event_attr test) always reports success even if the test case fails. It works correctly if you also specify -F (for don't fork). root@s35lp76 perf]# ./perf test -v 16 15: Setup struct perf_event_attr : --- start --- running './tests/attr/test-record-no-delay' [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.002 MB /tmp/tmp4E1h7R/perf.data (1 samples) ] expected task=0, got 1 expected precise_ip=0, got 3 expected wakeup_events=1, got 0 FAILED './tests/attr/test-record-no-delay' - match failure test child finished with 0 ---- end ---- Setup struct perf_event_attr: Ok The reason for the wrong error reporting is the return value of the system() library call. It is called in run_dir() file tests/attr.c and returns the exit status, in above case 0xff00. This value is given as parameter to the exit() function which can only handle values 0-0xff. The child process terminates with exit value of 0 and the parent does not detect any error. This patch corrects the error reporting and prints the correct test result. Signed-off-by: Thomas-Mich Richter <tmricht(a)linux.vnet.ibm.com> Acked-by: Jiri Olsa <jolsa(a)kernel.org> Cc: Heiko Carstens <heiko.carstens(a)de.ibm.com> Cc: Hendrik Brueckner <brueckner(a)linux.vnet.ibm.com> Cc: Martin Schwidefsky <schwidefsky(a)de.ibm.com> Cc: Thomas-Mich Richter <tmricht(a)linux.vnet.ibm.com> LPU-Reference: 20170913081209.39570-2-tmricht(a)linux.vnet.ibm.com Link: http://lkml.kernel.org/n/tip-rdube6rfcjsr1nzue72c7lqn@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/perf/tests/attr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/tools/perf/tests/attr.c +++ b/tools/perf/tests/attr.c @@ -150,7 +150,7 @@ static int run_dir(const char *d, const snprintf(cmd, 3*PATH_MAX, PYTHON " %s/attr.py -d %s/attr/ -p %s %.*s", d, d, perf, vcnt, v); - return system(cmd); + return system(cmd) ? TEST_FAIL : TEST_OK; } int test__attr(void) Patches currently in stable-queue which might be from tmricht(a)linux.vnet.ibm.com are queue-3.18/perf-test-attr-fix-ignored-test-case-result.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] Patch "serial: 8250_fintek: Fix rs485 disablement on invalid ioctl()" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled serial: 8250_fintek: Fix rs485 disablement on invalid ioctl() to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: serial-8250_fintek-fix-rs485-disablement-on-invalid-ioctl.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Dec 5 18:18:39 CET 2017 From: Lukas Wunner <lukas(a)wunner.de> Date: Sat, 28 Oct 2017 11:35:49 +0200 Subject: serial: 8250_fintek: Fix rs485 disablement on invalid ioctl() From: Lukas Wunner <lukas(a)wunner.de> [ Upstream commit 3236a965486ba0c6043cf2c7b51943d8b382ae29 ] This driver's ->rs485_config callback checks if SER_RS485_RTS_ON_SEND and SER_RS485_RTS_AFTER_SEND have the same value. If they do, it means the user has passed in invalid data with the TIOCSRS485 ioctl() since RTS must have a different polarity when sending and when not sending. In this case, rs485 mode is not enabled (the RS485_URA bit is not set in the RS485 Enable Register) and this is supposed to be signaled back to the user by clearing the SER_RS485_ENABLED bit in struct serial_rs485 ... except a missing tilde character is preventing that from happening. Fixes: 28e3fb6c4dce ("serial: Add support for Fintek F81216A LPC to 4 UART") Cc: Ricardo Ribalda Delgado <ricardo.ribalda(a)gmail.com> Cc: "Ji-Ze Hong (Peter Hong)" <hpeter(a)gmail.com> Signed-off-by: Lukas Wunner <lukas(a)wunner.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/8250/8250_fintek.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/tty/serial/8250/8250_fintek.c +++ b/drivers/tty/serial/8250/8250_fintek.c @@ -118,7 +118,7 @@ static int fintek_8250_rs4850_config(str if ((!!(rs485->flags & SER_RS485_RTS_ON_SEND)) == (!!(rs485->flags & SER_RS485_RTS_AFTER_SEND))) - rs485->flags &= SER_RS485_ENABLED; + rs485->flags &= ~SER_RS485_ENABLED; else config |= RS485_URA; Patches currently in stable-queue which might be from lukas(a)wunner.de are queue-3.18/serial-8250_fintek-fix-rs485-disablement-on-invalid-ioctl.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] Patch "NFSv4: Fix client recovery when server reboots multiple times" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled NFSv4: Fix client recovery when server reboots multiple times to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: nfsv4-fix-client-recovery-when-server-reboots-multiple-times.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Dec 5 18:18:39 CET 2017 From: Trond Myklebust <trond.myklebust(a)primarydata.com> Date: Fri, 13 Jan 2017 13:31:32 -0500 Subject: NFSv4: Fix client recovery when server reboots multiple times From: Trond Myklebust <trond.myklebust(a)primarydata.com> [ Upstream commit c6180a6237174f481dc856ed6e890d8196b6f0fb ] If the server reboots multiple times, the client should rely on the server to tell it that it cannot reclaim state as per section 9.6.3.4 in RFC7530 and section 8.4.2.1 in RFC5661. Currently, the client is being to conservative, and is assuming that if the server reboots while state recovery is in progress, then it must ignore state that was not recovered before the reboot. Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/nfs/nfs4state.c | 1 - 1 file changed, 1 deletion(-) --- a/fs/nfs/nfs4state.c +++ b/fs/nfs/nfs4state.c @@ -1650,7 +1650,6 @@ static int nfs4_recovery_handle_error(st break; case -NFS4ERR_STALE_CLIENTID: set_bit(NFS4CLNT_LEASE_EXPIRED, &clp->cl_state); - nfs4_state_clear_reclaim_reboot(clp); nfs4_state_start_reclaim_reboot(clp); break; case -NFS4ERR_EXPIRED: Patches currently in stable-queue which might be from trond.myklebust(a)primarydata.com are queue-3.18/nfsv4-fix-client-recovery-when-server-reboots-multiple-times.patch queue-3.18/nfs-don-t-take-a-reference-on-fl-fl_file-for-lock-operation.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] Patch "net: sctp: fix array overrun read on sctp_timer_tbl" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: sctp: fix array overrun read on sctp_timer_tbl to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-sctp-fix-array-overrun-read-on-sctp_timer_tbl.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Dec 5 18:18:39 CET 2017 From: Colin Ian King <colin.king(a)canonical.com> Date: Fri, 20 Jan 2017 13:01:57 +0000 Subject: net: sctp: fix array overrun read on sctp_timer_tbl From: Colin Ian King <colin.king(a)canonical.com> [ Upstream commit 0e73fc9a56f22f2eec4d2b2910c649f7af67b74d ] The comparison on the timeout can lead to an array overrun read on sctp_timer_tbl because of an off-by-one error. Fix this by using < instead of <= and also compare to the array size rather than SCTP_EVENT_TIMEOUT_MAX. Fixes CoverityScan CID#1397639 ("Out-of-bounds read") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/sctp/debug.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/net/sctp/debug.c +++ b/net/sctp/debug.c @@ -166,7 +166,7 @@ static const char *const sctp_timer_tbl[ /* Lookup timer debug name. */ const char *sctp_tname(const sctp_subtype_t id) { - if (id.timeout <= SCTP_EVENT_TIMEOUT_MAX) + if (id.timeout < ARRAY_SIZE(sctp_timer_tbl)) return sctp_timer_tbl[id.timeout]; return "unknown_timer"; } Patches currently in stable-queue which might be from colin.king(a)canonical.com are queue-3.18/net-sctp-fix-array-overrun-read-on-sctp_timer_tbl.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] Patch "nfs: Don't take a reference on fl->fl_file for LOCK operation" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled nfs: Don't take a reference on fl->fl_file for LOCK operation to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: nfs-don-t-take-a-reference-on-fl-fl_file-for-lock-operation.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Dec 5 18:18:39 CET 2017 From: Benjamin Coddington <bcodding(a)redhat.com> Date: Thu, 5 Jan 2017 10:20:16 -0500 Subject: nfs: Don't take a reference on fl->fl_file for LOCK operation From: Benjamin Coddington <bcodding(a)redhat.com> [ Upstream commit 4b09ec4b14a168bf2c687e1f598140c3c11e9222 ] I have reports of a crash that look like __fput() was called twice for a NFSv4.0 file. It seems possible that the state manager could try to reclaim a lock and take a reference on the fl->fl_file at the same time the file is being released if, during the close(), a signal interrupts the wait for outstanding IO while removing locks which then skips the removal of that lock. Since 83bfff23e9ed ("nfs4: have do_vfs_lock take an inode pointer") has removed the need to traverse fl->fl_file->f_inode in nfs4_lock_done(), taking that reference is no longer necessary. Signed-off-by: Benjamin Coddington <bcodding(a)redhat.com> Reviewed-by: Jeff Layton <jlayton(a)redhat.com> Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/nfs/nfs4proc.c | 3 --- 1 file changed, 3 deletions(-) --- a/fs/nfs/nfs4proc.c +++ b/fs/nfs/nfs4proc.c @@ -38,7 +38,6 @@ #include <linux/mm.h> #include <linux/delay.h> #include <linux/errno.h> -#include <linux/file.h> #include <linux/string.h> #include <linux/ratelimit.h> #include <linux/printk.h> @@ -5544,7 +5543,6 @@ static struct nfs4_lockdata *nfs4_alloc_ p->server = server; atomic_inc(&lsp->ls_count); p->ctx = get_nfs_open_context(ctx); - get_file(fl->fl_file); memcpy(&p->fl, fl, sizeof(p->fl)); return p; out_free_seqid: @@ -5634,7 +5632,6 @@ static void nfs4_lock_release(void *call nfs_free_seqid(data->arg.lock_seqid); nfs4_put_lock_state(data->lsp); put_nfs_open_context(data->ctx); - fput(data->fl.fl_file); kfree(data); dprintk("%s: done!\n", __func__); } Patches currently in stable-queue which might be from bcodding(a)redhat.com are queue-3.18/nfs-don-t-take-a-reference-on-fl-fl_file-for-lock-operation.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] Patch "net/appletalk: Fix kernel memory disclosure" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net/appletalk: Fix kernel memory disclosure to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-appletalk-fix-kernel-memory-disclosure.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Dec 5 18:18:39 CET 2017 From: Vlad Tsyrklevich <vlad(a)tsyrklevich.net> Date: Mon, 9 Jan 2017 20:57:48 +0700 Subject: net/appletalk: Fix kernel memory disclosure From: Vlad Tsyrklevich <vlad(a)tsyrklevich.net> [ Upstream commit ce7e40c432ba84da104438f6799d460a4cad41bc ] ipddp_route structs contain alignment padding so kernel heap memory is leaked when they are copied to user space in ipddp_ioctl(SIOCFINDIPDDPRT). Change kmalloc() to kzalloc() to clear that memory. Signed-off-by: Vlad Tsyrklevich <vlad(a)tsyrklevich.net> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/appletalk/ipddp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/appletalk/ipddp.c +++ b/drivers/net/appletalk/ipddp.c @@ -191,7 +191,7 @@ static netdev_tx_t ipddp_xmit(struct sk_ */ static int ipddp_create(struct ipddp_route *new_rt) { - struct ipddp_route *rt = kmalloc(sizeof(*rt), GFP_KERNEL); + struct ipddp_route *rt = kzalloc(sizeof(*rt), GFP_KERNEL); if (rt == NULL) return -ENOMEM; Patches currently in stable-queue which might be from vlad(a)tsyrklevich.net are queue-3.18/net-appletalk-fix-kernel-memory-disclosure.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] Patch "net: fec: fix multicast filtering hardware setup" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: fec: fix multicast filtering hardware setup to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-fec-fix-multicast-filtering-hardware-setup.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Dec 5 18:18:39 CET 2017 From: Rui Sousa <rui.sousa(a)nxp.com> Date: Mon, 13 Feb 2017 10:01:25 +0800 Subject: net: fec: fix multicast filtering hardware setup From: Rui Sousa <rui.sousa(a)nxp.com> [ Upstream commit 01f8902bcf3ff124d0aeb88a774180ebcec20ace ] Fix hardware setup of multicast address hash: - Never clear the hardware hash (to avoid packet loss) - Construct the hash register values in software and then write once to hardware Signed-off-by: Rui Sousa <rui.sousa(a)nxp.com> Signed-off-by: Fugang Duan <fugang.duan(a)nxp.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/freescale/fec_main.c | 23 +++++++++-------------- 1 file changed, 9 insertions(+), 14 deletions(-) --- a/drivers/net/ethernet/freescale/fec_main.c +++ b/drivers/net/ethernet/freescale/fec_main.c @@ -2793,6 +2793,7 @@ static void set_multicast_list(struct ne struct netdev_hw_addr *ha; unsigned int i, bit, data, crc, tmp; unsigned char hash; + unsigned int hash_high = 0, hash_low = 0; if (ndev->flags & IFF_PROMISC) { tmp = readl(fep->hwp + FEC_R_CNTRL); @@ -2815,11 +2816,7 @@ static void set_multicast_list(struct ne return; } - /* Clear filter and add the addresses in hash register - */ - writel(0, fep->hwp + FEC_GRP_HASH_TABLE_HIGH); - writel(0, fep->hwp + FEC_GRP_HASH_TABLE_LOW); - + /* Add the addresses in hash register */ netdev_for_each_mc_addr(ha, ndev) { /* calculate crc32 value of mac address */ crc = 0xffffffff; @@ -2837,16 +2834,14 @@ static void set_multicast_list(struct ne */ hash = (crc >> (32 - HASH_BITS)) & 0x3f; - if (hash > 31) { - tmp = readl(fep->hwp + FEC_GRP_HASH_TABLE_HIGH); - tmp |= 1 << (hash - 32); - writel(tmp, fep->hwp + FEC_GRP_HASH_TABLE_HIGH); - } else { - tmp = readl(fep->hwp + FEC_GRP_HASH_TABLE_LOW); - tmp |= 1 << hash; - writel(tmp, fep->hwp + FEC_GRP_HASH_TABLE_LOW); - } + if (hash > 31) + hash_high |= 1 << (hash - 32); + else + hash_low |= 1 << hash; } + + writel(hash_high, fep->hwp + FEC_GRP_HASH_TABLE_HIGH); + writel(hash_low, fep->hwp + FEC_GRP_HASH_TABLE_LOW); } /* Set a MAC change in hardware. */ Patches currently in stable-queue which might be from rui.sousa(a)nxp.com are queue-3.18/net-fec-fix-multicast-filtering-hardware-setup.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] Patch "mm: avoid returning VM_FAULT_RETRY from ->page_mkwrite handlers" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mm: avoid returning VM_FAULT_RETRY from ->page_mkwrite handlers to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mm-avoid-returning-vm_fault_retry-from-page_mkwrite-handlers.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Dec 5 18:18:39 CET 2017 From: Jan Kara <jack(a)suse.cz> Date: Wed, 8 Feb 2017 14:30:53 -0800 Subject: mm: avoid returning VM_FAULT_RETRY from ->page_mkwrite handlers From: Jan Kara <jack(a)suse.cz> [ Upstream commit 0911d0041c22922228ca52a977d7b0b0159fee4b ] Some ->page_mkwrite handlers may return VM_FAULT_RETRY as its return code (GFS2 or Lustre can definitely do this). However VM_FAULT_RETRY from ->page_mkwrite is completely unhandled by the mm code and results in locking and writeably mapping the page which definitely is not what the caller wanted. Fix Lustre and block_page_mkwrite_ret() used by other filesystems (notably GFS2) to return VM_FAULT_NOPAGE instead which results in bailing out from the fault code, the CPU then retries the access, and we fault again effectively doing what the handler wanted. Link: http://lkml.kernel.org/r/20170203150729.15863-1-jack@suse.cz Signed-off-by: Jan Kara <jack(a)suse.cz> Reported-by: Al Viro <viro(a)ZenIV.linux.org.uk> Reviewed-by: Jinshan Xiong <jinshan.xiong(a)intel.com> Cc: Matthew Wilcox <willy(a)infradead.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/lustre/lustre/llite/llite_mmap.c | 4 +--- include/linux/buffer_head.h | 4 +--- 2 files changed, 2 insertions(+), 6 deletions(-) --- a/drivers/staging/lustre/lustre/llite/llite_mmap.c +++ b/drivers/staging/lustre/lustre/llite/llite_mmap.c @@ -407,15 +407,13 @@ static int ll_page_mkwrite(struct vm_are result = VM_FAULT_LOCKED; break; case -ENODATA: + case -EAGAIN: case -EFAULT: result = VM_FAULT_NOPAGE; break; case -ENOMEM: result = VM_FAULT_OOM; break; - case -EAGAIN: - result = VM_FAULT_RETRY; - break; default: result = VM_FAULT_SIGBUS; break; --- a/include/linux/buffer_head.h +++ b/include/linux/buffer_head.h @@ -236,12 +236,10 @@ static inline int block_page_mkwrite_ret { if (err == 0) return VM_FAULT_LOCKED; - if (err == -EFAULT) + if (err == -EFAULT || err == -EAGAIN) return VM_FAULT_NOPAGE; if (err == -ENOMEM) return VM_FAULT_OOM; - if (err == -EAGAIN) - return VM_FAULT_RETRY; /* -ENOSPC, -EDQUOT, -EIO ... */ return VM_FAULT_SIGBUS; } Patches currently in stable-queue which might be from jack(a)suse.cz are queue-3.18/mm-avoid-returning-vm_fault_retry-from-page_mkwrite-handlers.patch

7 years, 10 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror