* [PATCH 4.14 02/95] mm, memory_hotplug: do not back off draining pcp free pages from kworker context
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
@ 2017-12-04 15:59 ` Greg Kroah-Hartman
2017-12-04 15:59 ` [PATCH 4.14 03/95] mm, oom_reaper: gather each vma to prevent leaking TLB entry Greg Kroah-Hartman
` (75 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Michal Hocko, Mel Gorman, Tejun Heo,
Andrew Morton, Linus Torvalds
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michal Hocko <mhocko@suse.com>
commit 4b81cb2ff69c8a8e297a147d2eb4d9b5e8d7c435 upstream.
drain_all_pages backs off when called from a kworker context since
commit 0ccce3b92421 ("mm, page_alloc: drain per-cpu pages from workqueue
context") because the original IPI based pcp draining has been replaced
by a WQ based one and the check wanted to prevent from recursion and
inter workers dependencies. This has made some sense at the time
because the system WQ has been used and one worker holding the lock
could be blocked while waiting for new workers to emerge which can be a
problem under OOM conditions.
Since then commit ce612879ddc7 ("mm: move pcp and lru-pcp draining into
single wq") has moved draining to a dedicated (mm_percpu_wq) WQ with a
rescuer so we shouldn't depend on any other WQ activity to make a
forward progress so calling drain_all_pages from a worker context is
safe as long as this doesn't happen from mm_percpu_wq itself which is
not the case because all workers are required to _not_ depend on any MM
locks.
Why is this a problem in the first place? ACPI driven memory hot-remove
(acpi_device_hotplug) is executed from the worker context. We end up
calling __offline_pages to free all the pages and that requires both
lru_add_drain_all_cpuslocked and drain_all_pages to do their job
otherwise we can have dangling pages on pcp lists and fail the offline
operation (__test_page_isolated_in_pageblock would see a page with 0 ref
count but without PageBuddy set).
Fix the issue by removing the worker check in drain_all_pages.
lru_add_drain_all_cpuslocked doesn't have this restriction so it works
as expected.
Link: http://lkml.kernel.org/r/20170828093341.26341-1-mhocko@kernel.org
Fixes: 0ccce3b924212 ("mm, page_alloc: drain per-cpu pages from workqueue context")
Signed-off-by: Michal Hocko <mhocko@suse.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Tejun Heo <tj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/page_alloc.c | 4 ----
1 file changed, 4 deletions(-)
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2487,10 +2487,6 @@ void drain_all_pages(struct zone *zone)
if (WARN_ON_ONCE(!mm_percpu_wq))
return;
- /* Workqueues cannot recurse */
- if (current->flags & PF_WQ_WORKER)
- return;
-
/*
* Do not drain if one is already in progress unless it's specific to
* a zone. Such callers are primarily CMA and memory hotplug and need
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 03/95] mm, oom_reaper: gather each vma to prevent leaking TLB entry
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
2017-12-04 15:59 ` [PATCH 4.14 02/95] mm, memory_hotplug: do not back off draining pcp free pages from kworker context Greg Kroah-Hartman
@ 2017-12-04 15:59 ` Greg Kroah-Hartman
2017-12-04 15:59 ` [PATCH 4.14 04/95] mm, thp: Do not make page table dirty unconditionally in touch_p[mu]d() Greg Kroah-Hartman
` (74 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Wang Nan, Michal Hocko,
David Rientjes, Minchan Kim, Will Deacon, Bob Liu, Ingo Molnar,
Roman Gushchin, Konstantin Khlebnikov, Andrea Arcangeli,
Andrew Morton, Linus Torvalds
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wang Nan <wangnan0@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@huawei.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: David Rientjes <rientjes@google.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Bob Liu <liubo95@huawei.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Roman Gushchin <guro@fb.com>
Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/oom_kill.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -532,7 +532,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 (!can_madv_dontneed_vma(vma))
continue;
@@ -547,11 +546,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,
NULL);
+ 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)),
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 04/95] mm, thp: Do not make page table dirty unconditionally in touch_p[mu]d()
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
2017-12-04 15:59 ` [PATCH 4.14 02/95] mm, memory_hotplug: do not back off draining pcp free pages from kworker context Greg Kroah-Hartman
2017-12-04 15:59 ` [PATCH 4.14 03/95] mm, oom_reaper: gather each vma to prevent leaking TLB entry Greg Kroah-Hartman
@ 2017-12-04 15:59 ` Greg Kroah-Hartman
2017-12-04 15:59 ` [PATCH 4.14 05/95] mm/cma: fix alloc_contig_range ret code/potential leak Greg Kroah-Hartman
` (73 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Kirill A. Shutemov, Michal Hocko,
Hugh Dickins, Linus Torvalds
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
commit a8f97366452ed491d13cf1e44241bc0b5740b1f0 upstream.
Currently, we unconditionally make page table dirty in touch_pmd().
It may result in false-positive can_follow_write_pmd().
We may avoid the situation, if we would only make the page table entry
dirty if caller asks for write access -- FOLL_WRITE.
The patch also changes touch_pud() in the same way.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Hugh Dickins <hughd@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/huge_memory.c | 36 +++++++++++++-----------------------
1 file changed, 13 insertions(+), 23 deletions(-)
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -842,20 +842,15 @@ EXPORT_SYMBOL_GPL(vmf_insert_pfn_pud);
#endif /* CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD */
static void touch_pmd(struct vm_area_struct *vma, unsigned long addr,
- pmd_t *pmd)
+ pmd_t *pmd, int flags)
{
pmd_t _pmd;
- /*
- * We should set the dirty bit only for FOLL_WRITE but for now
- * the dirty bit in the pmd is meaningless. And if the dirty
- * bit will become meaningful and we'll only set it with
- * FOLL_WRITE, an atomic set_bit will be required on the pmd to
- * set the young bit, instead of the current set_pmd_at.
- */
- _pmd = pmd_mkyoung(pmd_mkdirty(*pmd));
+ _pmd = pmd_mkyoung(*pmd);
+ if (flags & FOLL_WRITE)
+ _pmd = pmd_mkdirty(_pmd);
if (pmdp_set_access_flags(vma, addr & HPAGE_PMD_MASK,
- pmd, _pmd, 1))
+ pmd, _pmd, flags & FOLL_WRITE))
update_mmu_cache_pmd(vma, addr, pmd);
}
@@ -884,7 +879,7 @@ struct page *follow_devmap_pmd(struct vm
return NULL;
if (flags & FOLL_TOUCH)
- touch_pmd(vma, addr, pmd);
+ touch_pmd(vma, addr, pmd, flags);
/*
* device mapped pages can only be returned if the
@@ -995,20 +990,15 @@ out:
#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
static void touch_pud(struct vm_area_struct *vma, unsigned long addr,
- pud_t *pud)
+ pud_t *pud, int flags)
{
pud_t _pud;
- /*
- * We should set the dirty bit only for FOLL_WRITE but for now
- * the dirty bit in the pud is meaningless. And if the dirty
- * bit will become meaningful and we'll only set it with
- * FOLL_WRITE, an atomic set_bit will be required on the pud to
- * set the young bit, instead of the current set_pud_at.
- */
- _pud = pud_mkyoung(pud_mkdirty(*pud));
+ _pud = pud_mkyoung(*pud);
+ if (flags & FOLL_WRITE)
+ _pud = pud_mkdirty(_pud);
if (pudp_set_access_flags(vma, addr & HPAGE_PUD_MASK,
- pud, _pud, 1))
+ pud, _pud, flags & FOLL_WRITE))
update_mmu_cache_pud(vma, addr, pud);
}
@@ -1031,7 +1021,7 @@ struct page *follow_devmap_pud(struct vm
return NULL;
if (flags & FOLL_TOUCH)
- touch_pud(vma, addr, pud);
+ touch_pud(vma, addr, pud, flags);
/*
* device mapped pages can only be returned if the
@@ -1407,7 +1397,7 @@ struct page *follow_trans_huge_pmd(struc
page = pmd_page(*pmd);
VM_BUG_ON_PAGE(!PageHead(page) && !is_zone_device_page(page), page);
if (flags & FOLL_TOUCH)
- touch_pmd(vma, addr, pmd);
+ touch_pmd(vma, addr, pmd, flags);
if ((flags & FOLL_MLOCK) && (vma->vm_flags & VM_LOCKED)) {
/*
* We don't mlock() pte-mapped THPs. This way we can avoid
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 05/95] mm/cma: fix alloc_contig_range ret code/potential leak
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (2 preceding siblings ...)
2017-12-04 15:59 ` [PATCH 4.14 04/95] mm, thp: Do not make page table dirty unconditionally in touch_p[mu]d() Greg Kroah-Hartman
@ 2017-12-04 15:59 ` Greg Kroah-Hartman
2017-12-04 15:59 ` [PATCH 4.14 06/95] mm: fix device-dax pud write-faults triggered by get_user_pages() Greg Kroah-Hartman
` (72 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Mike Kravetz, Vlastimil Babka,
Michal Hocko, Johannes Weiner, Joonsoo Kim, Michal Nazarewicz,
Laura Abbott, Mel Gorman, Andrew Morton, Linus Torvalds
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mike Kravetz <mike.kravetz@oracle.com>
commit 63cd448908b5eb51d84c52f02b31b9b4ccd1cb5a upstream.
If the call __alloc_contig_migrate_range() in alloc_contig_range returns
-EBUSY, processing continues so that test_pages_isolated() is called
where there is a tracepoint to identify the busy pages. However, it is
possible for busy pages to become available between the calls to these
two routines. In this case, the range of pages may be allocated.
Unfortunately, the original return code (ret == -EBUSY) is still set and
returned to the caller. Therefore, the caller believes the pages were
not allocated and they are leaked.
Update the comment to indicate that allocation is still possible even if
__alloc_contig_migrate_range returns -EBUSY. Also, clear return code in
this case so that it is not accidentally used or returned to caller.
Link: http://lkml.kernel.org/r/20171122185214.25285-1-mike.kravetz@oracle.com
Fixes: 8ef5849fa8a2 ("mm/cma: always check which page caused allocation failure")
Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Michal Nazarewicz <mina86@mina86.com>
Cc: Laura Abbott <labbott@redhat.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/page_alloc.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -7587,11 +7587,18 @@ int alloc_contig_range(unsigned long sta
/*
* In case of -EBUSY, we'd like to know which page causes problem.
- * So, just fall through. We will check it in test_pages_isolated().
+ * So, just fall through. test_pages_isolated() has a tracepoint
+ * which will report the busy page.
+ *
+ * It is possible that busy pages could become available before
+ * the call to test_pages_isolated, and the range will actually be
+ * allocated. So, if we fall through be sure to clear ret so that
+ * -EBUSY is not accidentally used or returned to caller.
*/
ret = __alloc_contig_migrate_range(&cc, start, end);
if (ret && ret != -EBUSY)
goto done;
+ ret =0;
/*
* Pages from [start, end) are within a MAX_ORDER_NR_PAGES
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 06/95] mm: fix device-dax pud write-faults triggered by get_user_pages()
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (3 preceding siblings ...)
2017-12-04 15:59 ` [PATCH 4.14 05/95] mm/cma: fix alloc_contig_range ret code/potential leak Greg Kroah-Hartman
@ 2017-12-04 15:59 ` Greg Kroah-Hartman
2017-12-04 15:59 ` [PATCH 4.14 07/95] mm, hugetlbfs: introduce ->split() to vm_operations_struct Greg Kroah-Hartman
` (71 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dan Williams, Stephen Rothwell,
Kirill A. Shutemov, Catalin Marinas, David S. Miller,
Dave Hansen, Will Deacon, H. Peter Anvin, Ingo Molnar,
Arnd Bergmann, Andrew Morton, Linus Torvalds
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Williams <dan.j.williams@intel.com>
commit 1501899a898dfb5477c55534bdfd734c046da06d upstream.
Currently only get_user_pages_fast() can safely handle the writable gup
case due to its use of pud_access_permitted() to check whether the pud
entry is writable. In the gup slow path pud_write() is used instead of
pud_access_permitted() and to date it has been unimplemented, just calls
BUG_ON().
kernel BUG at ./include/linux/hugetlb.h:244!
[..]
RIP: 0010:follow_devmap_pud+0x482/0x490
[..]
Call Trace:
follow_page_mask+0x28c/0x6e0
__get_user_pages+0xe4/0x6c0
get_user_pages_unlocked+0x130/0x1b0
get_user_pages_fast+0x89/0xb0
iov_iter_get_pages_alloc+0x114/0x4a0
nfs_direct_read_schedule_iovec+0xd2/0x350
? nfs_start_io_direct+0x63/0x70
nfs_file_direct_read+0x1e0/0x250
nfs_file_read+0x90/0xc0
For now this just implements a simple check for the _PAGE_RW bit similar
to pmd_write. However, this implies that the gup-slow-path check is
missing the extra checks that the gup-fast-path performs with
pud_access_permitted. Later patches will align all checks to use the
'access_permitted' helper if the architecture provides it.
Note that the generic 'access_permitted' helper fallback is the simple
_PAGE_RW check on architectures that do not define the
'access_permitted' helper(s).
[dan.j.williams@intel.com: fix powerpc compile error]
Link: http://lkml.kernel.org/r/151129126165.37405.16031785266675461397.stgit@dwillia2-desk3.amr.corp.intel.com
Link: http://lkml.kernel.org/r/151043109938.2842.14834662818213616199.stgit@dwillia2-desk3.amr.corp.intel.com
Fixes: a00cc7d9dd93 ("mm, x86: add support for PUD-sized transparent hugepages")
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Thomas Gleixner <tglx@linutronix.de> [x86]
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/include/asm/pgtable.h | 6 ++++++
include/asm-generic/pgtable.h | 8 ++++++++
include/linux/hugetlb.h | 8 --------
3 files changed, 14 insertions(+), 8 deletions(-)
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -1093,6 +1093,12 @@ static inline void pmdp_set_wrprotect(st
clear_bit(_PAGE_BIT_RW, (unsigned long *)pmdp);
}
+#define pud_write pud_write
+static inline int pud_write(pud_t pud)
+{
+ return pud_flags(pud) & _PAGE_RW;
+}
+
/*
* clone_pgd_range(pgd_t *dst, pgd_t *src, int count);
*
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -814,6 +814,14 @@ static inline int pmd_write(pmd_t pmd)
#endif /* __HAVE_ARCH_PMD_WRITE */
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
+#ifndef pud_write
+static inline int pud_write(pud_t pud)
+{
+ BUG();
+ return 0;
+}
+#endif /* pud_write */
+
#if !defined(CONFIG_TRANSPARENT_HUGEPAGE) || \
(defined(CONFIG_TRANSPARENT_HUGEPAGE) && \
!defined(CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD))
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -239,14 +239,6 @@ static inline int pgd_write(pgd_t pgd)
}
#endif
-#ifndef pud_write
-static inline int pud_write(pud_t pud)
-{
- BUG();
- return 0;
-}
-#endif
-
#define HUGETLB_ANON_FILE "anon_hugepage"
enum {
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 07/95] mm, hugetlbfs: introduce ->split() to vm_operations_struct
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (4 preceding siblings ...)
2017-12-04 15:59 ` [PATCH 4.14 06/95] mm: fix device-dax pud write-faults triggered by get_user_pages() Greg Kroah-Hartman
@ 2017-12-04 15:59 ` Greg Kroah-Hartman
2017-12-04 15:59 ` [PATCH 4.14 08/95] device-dax: implement ->split() to catch invalid munmap attempts Greg Kroah-Hartman
` (70 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dan Williams, Jeff Moyer,
Andrew Morton, Linus Torvalds
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Williams <dan.j.williams@intel.com>
commit 31383c6865a578834dd953d9dbc88e6b19fe3997 upstream.
Patch series "device-dax: fix unaligned munmap handling"
When device-dax is operating in huge-page mode we want it to behave like
hugetlbfs and fail attempts to split vmas into unaligned ranges. It
would be messy to teach the munmap path about device-dax alignment
constraints in the same (hstate) way that hugetlbfs communicates this
constraint. Instead, these patches introduce a new ->split() vm
operation.
This patch (of 2):
The device-dax interface has similar constraints as hugetlbfs in that it
requires the munmap path to unmap in huge page aligned units. Rather
than add more custom vma handling code in __split_vma() introduce a new
vm operation to perform this vma specific check.
Link: http://lkml.kernel.org/r/151130418135.4029.6783191281930729710.stgit@dwillia2-desk3.amr.corp.intel.com
Fixes: dee410792419 ("/dev/dax, core: file operations and dax-mmap")
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Cc: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/linux/mm.h | 1 +
mm/hugetlb.c | 8 ++++++++
mm/mmap.c | 8 +++++---
3 files changed, 14 insertions(+), 3 deletions(-)
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -367,6 +367,7 @@ enum page_entry_size {
struct vm_operations_struct {
void (*open)(struct vm_area_struct * area);
void (*close)(struct vm_area_struct * area);
+ int (*split)(struct vm_area_struct * area, unsigned long addr);
int (*mremap)(struct vm_area_struct * area);
int (*fault)(struct vm_fault *vmf);
int (*huge_fault)(struct vm_fault *vmf, enum page_entry_size pe_size);
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -3125,6 +3125,13 @@ static void hugetlb_vm_op_close(struct v
}
}
+static int hugetlb_vm_op_split(struct vm_area_struct *vma, unsigned long addr)
+{
+ if (addr & ~(huge_page_mask(hstate_vma(vma))))
+ return -EINVAL;
+ return 0;
+}
+
/*
* We cannot handle pagefaults against hugetlb pages at all. They cause
* handle_mm_fault() to try to instantiate regular-sized pages in the
@@ -3141,6 +3148,7 @@ const struct vm_operations_struct hugetl
.fault = hugetlb_vm_op_fault,
.open = hugetlb_vm_op_open,
.close = hugetlb_vm_op_close,
+ .split = hugetlb_vm_op_split,
};
static pte_t make_huge_pte(struct vm_area_struct *vma, struct page *page,
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2540,9 +2540,11 @@ int __split_vma(struct mm_struct *mm, st
struct vm_area_struct *new;
int err;
- if (is_vm_hugetlb_page(vma) && (addr &
- ~(huge_page_mask(hstate_vma(vma)))))
- return -EINVAL;
+ if (vma->vm_ops && vma->vm_ops->split) {
+ err = vma->vm_ops->split(vma, addr);
+ if (err)
+ return err;
+ }
new = kmem_cache_alloc(vm_area_cachep, GFP_KERNEL);
if (!new)
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 08/95] device-dax: implement ->split() to catch invalid munmap attempts
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (5 preceding siblings ...)
2017-12-04 15:59 ` [PATCH 4.14 07/95] mm, hugetlbfs: introduce ->split() to vm_operations_struct Greg Kroah-Hartman
@ 2017-12-04 15:59 ` Greg Kroah-Hartman
2017-12-04 15:59 ` [PATCH 4.14 09/95] mm: introduce get_user_pages_longterm Greg Kroah-Hartman
` (69 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dan Williams, Jeff Moyer,
Andrew Morton, Linus Torvalds
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Williams <dan.j.williams@intel.com>
commit 9702cffdbf2129516db679e4467db81e1cd287da upstream.
Similar to how device-dax enforces that the 'address', 'offset', and
'len' parameters to mmap() be aligned to the device's fundamental
alignment, the same constraints apply to munmap(). Implement ->split()
to fail munmap calls that violate the alignment constraint.
Otherwise, we later fail VM_BUG_ON checks in the unmap_page_range() path
with crash signatures of the form:
vma ffff8800b60c8a88 start 00007f88c0000000 end 00007f88c0e00000
next (null) prev (null) mm ffff8800b61150c0
prot 8000000000000027 anon_vma (null) vm_ops ffffffffa0091240
pgoff 0 file ffff8800b638ef80 private_data (null)
flags: 0x380000fb(read|write|shared|mayread|maywrite|mayexec|mayshare|softdirty|mixedmap|hugepage)
------------[ cut here ]------------
kernel BUG at mm/huge_memory.c:2014!
[..]
RIP: 0010:__split_huge_pud+0x12a/0x180
[..]
Call Trace:
unmap_page_range+0x245/0xa40
? __vma_adjust+0x301/0x990
unmap_vmas+0x4c/0xa0
unmap_region+0xae/0x120
? __vma_rb_erase+0x11a/0x230
do_munmap+0x276/0x410
vm_munmap+0x6a/0xa0
SyS_munmap+0x1d/0x30
Link: http://lkml.kernel.org/r/151130418681.4029.7118245855057952010.stgit@dwillia2-desk3.amr.corp.intel.com
Fixes: dee410792419 ("/dev/dax, core: file operations and dax-mmap")
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Reported-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/dax/device.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
--- a/drivers/dax/device.c
+++ b/drivers/dax/device.c
@@ -427,9 +427,21 @@ static int dev_dax_fault(struct vm_fault
return dev_dax_huge_fault(vmf, PE_SIZE_PTE);
}
+static int dev_dax_split(struct vm_area_struct *vma, unsigned long addr)
+{
+ struct file *filp = vma->vm_file;
+ struct dev_dax *dev_dax = filp->private_data;
+ struct dax_region *dax_region = dev_dax->region;
+
+ if (!IS_ALIGNED(addr, dax_region->align))
+ return -EINVAL;
+ return 0;
+}
+
static const struct vm_operations_struct dax_vm_ops = {
.fault = dev_dax_fault,
.huge_fault = dev_dax_huge_fault,
+ .split = dev_dax_split,
};
static int dax_mmap(struct file *filp, struct vm_area_struct *vma)
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 09/95] mm: introduce get_user_pages_longterm
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (6 preceding siblings ...)
2017-12-04 15:59 ` [PATCH 4.14 08/95] device-dax: implement ->split() to catch invalid munmap attempts Greg Kroah-Hartman
@ 2017-12-04 15:59 ` Greg Kroah-Hartman
2017-12-04 15:59 ` [PATCH 4.14 10/95] mm: fail get_vaddr_frames() for filesystem-dax mappings Greg Kroah-Hartman
` (68 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dan Williams, Christoph Hellwig,
Doug Ledford, Hal Rosenstock, Inki Dae, Jan Kara,
Jason Gunthorpe, Jeff Moyer, Joonyoung Shim, Kyungmin Park,
Mauro Carvalho Chehab, Mel Gorman, Ross Zwisler, Sean Hefty,
Seung-Woo Kim, Vlastimil Babka, Andrew Morton, Linus Torvalds
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Williams <dan.j.williams@intel.com>
commit 2bb6d2837083de722bfdc369cb0d76ce188dd9b4 upstream.
Patch series "introduce get_user_pages_longterm()", v2.
Here is a new get_user_pages api for cases where a driver intends to
keep an elevated page count indefinitely. This is distinct from usages
like iov_iter_get_pages where the elevated page counts are transient.
The iov_iter_get_pages cases immediately turn around and submit the
pages to a device driver which will put_page when the i/o operation
completes (under kernel control).
In the longterm case userspace is responsible for dropping the page
reference at some undefined point in the future. This is untenable for
filesystem-dax case where the filesystem is in control of the lifetime
of the block / page and needs reasonable limits on how long it can wait
for pages in a mapping to become idle.
Fixing filesystems to actually wait for dax pages to be idle before
blocks from a truncate/hole-punch operation are repurposed is saved for
a later patch series.
Also, allowing longterm registration of dax mappings is a future patch
series that introduces a "map with lease" semantic where the kernel can
revoke a lease and force userspace to drop its page references.
I have also tagged these for -stable to purposely break cases that might
assume that longterm memory registrations for filesystem-dax mappings
were supported by the kernel. The behavior regression this policy
change implies is one of the reasons we maintain the "dax enabled.
Warning: EXPERIMENTAL, use at your own risk" notification when mounting
a filesystem in dax mode.
It is worth noting the device-dax interface does not suffer the same
constraints since it does not support file space management operations
like hole-punch.
This patch (of 4):
Until there is a solution to the dma-to-dax vs truncate problem it is
not safe to allow long standing memory registrations against
filesytem-dax vmas. Device-dax vmas do not have this problem and are
explicitly allowed.
This is temporary until a "memory registration with layout-lease"
mechanism can be implemented for the affected sub-systems (RDMA and
V4L2).
[akpm@linux-foundation.org: use kcalloc()]
Link: http://lkml.kernel.org/r/151068939435.7446.13560129395419350737.stgit@dwillia2-desk3.amr.corp.intel.com
Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Suggested-by: Christoph Hellwig <hch@lst.de>
Cc: Doug Ledford <dledford@redhat.com>
Cc: Hal Rosenstock <hal.rosenstock@gmail.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Jason Gunthorpe <jgg@mellanox.com>
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Sean Hefty <sean.hefty@intel.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/linux/fs.h | 14 +++++++++++
include/linux/mm.h | 13 ++++++++++
mm/gup.c | 64 +++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 91 insertions(+)
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -3175,6 +3175,20 @@ static inline bool vma_is_dax(struct vm_
return vma->vm_file && IS_DAX(vma->vm_file->f_mapping->host);
}
+static inline bool vma_is_fsdax(struct vm_area_struct *vma)
+{
+ struct inode *inode;
+
+ if (!vma->vm_file)
+ return false;
+ if (!vma_is_dax(vma))
+ return false;
+ inode = file_inode(vma->vm_file);
+ if (inode->i_mode == S_IFCHR)
+ return false; /* device-dax */
+ return true;
+}
+
static inline int iocb_flags(struct file *file)
{
int res = 0;
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1368,6 +1368,19 @@ long get_user_pages_locked(unsigned long
unsigned int gup_flags, struct page **pages, int *locked);
long get_user_pages_unlocked(unsigned long start, unsigned long nr_pages,
struct page **pages, unsigned int gup_flags);
+#ifdef CONFIG_FS_DAX
+long get_user_pages_longterm(unsigned long start, unsigned long nr_pages,
+ unsigned int gup_flags, struct page **pages,
+ struct vm_area_struct **vmas);
+#else
+static inline long get_user_pages_longterm(unsigned long start,
+ unsigned long nr_pages, unsigned int gup_flags,
+ struct page **pages, struct vm_area_struct **vmas)
+{
+ return get_user_pages(start, nr_pages, gup_flags, pages, vmas);
+}
+#endif /* CONFIG_FS_DAX */
+
int get_user_pages_fast(unsigned long start, int nr_pages, int write,
struct page **pages);
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1095,6 +1095,70 @@ long get_user_pages(unsigned long start,
}
EXPORT_SYMBOL(get_user_pages);
+#ifdef CONFIG_FS_DAX
+/*
+ * This is the same as get_user_pages() in that it assumes we are
+ * operating on the current task's mm, but it goes further to validate
+ * that the vmas associated with the address range are suitable for
+ * longterm elevated page reference counts. For example, filesystem-dax
+ * mappings are subject to the lifetime enforced by the filesystem and
+ * we need guarantees that longterm users like RDMA and V4L2 only
+ * establish mappings that have a kernel enforced revocation mechanism.
+ *
+ * "longterm" == userspace controlled elevated page count lifetime.
+ * Contrast this to iov_iter_get_pages() usages which are transient.
+ */
+long get_user_pages_longterm(unsigned long start, unsigned long nr_pages,
+ unsigned int gup_flags, struct page **pages,
+ struct vm_area_struct **vmas_arg)
+{
+ struct vm_area_struct **vmas = vmas_arg;
+ struct vm_area_struct *vma_prev = NULL;
+ long rc, i;
+
+ if (!pages)
+ return -EINVAL;
+
+ if (!vmas) {
+ vmas = kcalloc(nr_pages, sizeof(struct vm_area_struct *),
+ GFP_KERNEL);
+ if (!vmas)
+ return -ENOMEM;
+ }
+
+ rc = get_user_pages(start, nr_pages, gup_flags, pages, vmas);
+
+ for (i = 0; i < rc; i++) {
+ struct vm_area_struct *vma = vmas[i];
+
+ if (vma == vma_prev)
+ continue;
+
+ vma_prev = vma;
+
+ if (vma_is_fsdax(vma))
+ break;
+ }
+
+ /*
+ * Either get_user_pages() failed, or the vma validation
+ * succeeded, in either case we don't need to put_page() before
+ * returning.
+ */
+ if (i >= rc)
+ goto out;
+
+ for (i = 0; i < rc; i++)
+ put_page(pages[i]);
+ rc = -EOPNOTSUPP;
+out:
+ if (vmas != vmas_arg)
+ kfree(vmas);
+ return rc;
+}
+EXPORT_SYMBOL(get_user_pages_longterm);
+#endif /* CONFIG_FS_DAX */
+
/**
* populate_vma_page_range() - populate a range of pages in the vma.
* @vma: target vma
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 10/95] mm: fail get_vaddr_frames() for filesystem-dax mappings
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (7 preceding siblings ...)
2017-12-04 15:59 ` [PATCH 4.14 09/95] mm: introduce get_user_pages_longterm Greg Kroah-Hartman
@ 2017-12-04 15:59 ` Greg Kroah-Hartman
2017-12-04 15:59 ` [PATCH 4.14 11/95] v4l2: disable filesystem-dax mapping support Greg Kroah-Hartman
` (67 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dan Williams, Jan Kara, Inki Dae,
Seung-Woo Kim, Joonyoung Shim, Kyungmin Park,
Mauro Carvalho Chehab, Mel Gorman, Vlastimil Babka,
Christoph Hellwig, Doug Ledford, Hal Rosenstock, Jason Gunthorpe,
Jeff Moyer, Ross Zwisler, Sean Hefty, Andrew Morton,
Linus Torvalds
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Williams <dan.j.williams@intel.com>
commit b7f0554a56f21fb3e636a627450a9add030889be upstream.
Until there is a solution to the dma-to-dax vs truncate problem it is
not safe to allow V4L2, Exynos, and other frame vector users to create
long standing / irrevocable memory registrations against filesytem-dax
vmas.
[dan.j.williams@intel.com: add comment for vma_is_fsdax() check in get_vaddr_frames(), per Jan]
Link: http://lkml.kernel.org/r/151197874035.26211.4061781453123083667.stgit@dwillia2-desk3.amr.corp.intel.com
Link: http://lkml.kernel.org/r/151068939985.7446.15684639617389154187.stgit@dwillia2-desk3.amr.corp.intel.com
Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Doug Ledford <dledford@redhat.com>
Cc: Hal Rosenstock <hal.rosenstock@gmail.com>
Cc: Jason Gunthorpe <jgg@mellanox.com>
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Sean Hefty <sean.hefty@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/frame_vector.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
--- a/mm/frame_vector.c
+++ b/mm/frame_vector.c
@@ -53,6 +53,18 @@ int get_vaddr_frames(unsigned long start
ret = -EFAULT;
goto out;
}
+
+ /*
+ * While get_vaddr_frames() could be used for transient (kernel
+ * controlled lifetime) pinning of memory pages all current
+ * users establish long term (userspace controlled lifetime)
+ * page pinning. Treat get_vaddr_frames() like
+ * get_user_pages_longterm() and disallow it for filesystem-dax
+ * mappings.
+ */
+ if (vma_is_fsdax(vma))
+ return -EOPNOTSUPP;
+
if (!(vma->vm_flags & (VM_IO | VM_PFNMAP))) {
vec->got_ref = true;
vec->is_pfns = false;
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 11/95] v4l2: disable filesystem-dax mapping support
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (8 preceding siblings ...)
2017-12-04 15:59 ` [PATCH 4.14 10/95] mm: fail get_vaddr_frames() for filesystem-dax mappings Greg Kroah-Hartman
@ 2017-12-04 15:59 ` Greg Kroah-Hartman
2017-12-04 15:59 ` [PATCH 4.14 12/95] IB/core: disable memory registration of filesystem-dax vmas Greg Kroah-Hartman
` (66 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dan Williams, Jan Kara,
Mauro Carvalho Chehab, Christoph Hellwig, Doug Ledford,
Hal Rosenstock, Inki Dae, Jason Gunthorpe, Jeff Moyer,
Joonyoung Shim, Kyungmin Park, Mel Gorman, Ross Zwisler,
Sean Hefty, Seung-Woo Kim, Vlastimil Babka, Andrew Morton,
Linus Torvalds
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Williams <dan.j.williams@intel.com>
commit b70131de648c2b997d22f4653934438013f407a1 upstream.
V4L2 memory registrations are incompatible with filesystem-dax that
needs the ability to revoke dma access to a mapping at will, or
otherwise allow the kernel to wait for completion of DMA. The
filesystem-dax implementation breaks the traditional solution of
truncate of active file backed mappings since there is no page-cache
page we can orphan to sustain ongoing DMA.
If v4l2 wants to support long lived DMA mappings it needs to arrange to
hold a file lease or use some other mechanism so that the kernel can
coordinate revoking DMA access when the filesystem needs to truncate
mappings.
Link: http://lkml.kernel.org/r/151068940499.7446.12846708245365671207.stgit@dwillia2-desk3.amr.corp.intel.com
Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Reported-by: Jan Kara <jack@suse.cz>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Doug Ledford <dledford@redhat.com>
Cc: Hal Rosenstock <hal.rosenstock@gmail.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Jason Gunthorpe <jgg@mellanox.com>
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Sean Hefty <sean.hefty@intel.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/v4l2-core/videobuf-dma-sg.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/media/v4l2-core/videobuf-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf-dma-sg.c
@@ -185,12 +185,13 @@ static int videobuf_dma_init_user_locked
dprintk(1, "init user [0x%lx+0x%lx => %d pages]\n",
data, size, dma->nr_pages);
- err = get_user_pages(data & PAGE_MASK, dma->nr_pages,
+ err = get_user_pages_longterm(data & PAGE_MASK, dma->nr_pages,
flags, dma->pages, NULL);
if (err != dma->nr_pages) {
dma->nr_pages = (err >= 0) ? err : 0;
- dprintk(1, "get_user_pages: err=%d [%d]\n", err, dma->nr_pages);
+ dprintk(1, "get_user_pages_longterm: err=%d [%d]\n", err,
+ dma->nr_pages);
return err < 0 ? err : -EINVAL;
}
return 0;
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 12/95] IB/core: disable memory registration of filesystem-dax vmas
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (9 preceding siblings ...)
2017-12-04 15:59 ` [PATCH 4.14 11/95] v4l2: disable filesystem-dax mapping support Greg Kroah-Hartman
@ 2017-12-04 15:59 ` Greg Kroah-Hartman
2017-12-04 15:59 ` [PATCH 4.14 13/95] exec: avoid RLIMIT_STACK races with prlimit() Greg Kroah-Hartman
` (65 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dan Williams, Christoph Hellwig,
Jason Gunthorpe, Doug Ledford, Sean Hefty, Hal Rosenstock,
Jeff Moyer, Ross Zwisler, Inki Dae, Jan Kara, Joonyoung Shim,
Kyungmin Park, Mauro Carvalho Chehab, Mel Gorman, Seung-Woo Kim,
Vlastimil Babka, Andrew Morton, Linus Torvalds
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Williams <dan.j.williams@intel.com>
commit 5f1d43de54164dcfb9bfa542fcc92c1e1a1b6c1d upstream.
Until there is a solution to the dma-to-dax vs truncate problem it is
not safe to allow RDMA to create long standing memory registrations
against filesytem-dax vmas.
Link: http://lkml.kernel.org/r/151068941011.7446.7766030590347262502.stgit@dwillia2-desk3.amr.corp.intel.com
Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Reported-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Acked-by: Jason Gunthorpe <jgg@mellanox.com>
Acked-by: Doug Ledford <dledford@redhat.com>
Cc: Sean Hefty <sean.hefty@intel.com>
Cc: Hal Rosenstock <hal.rosenstock@gmail.com>
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/core/umem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -191,7 +191,7 @@ struct ib_umem *ib_umem_get(struct ib_uc
sg_list_start = umem->sg_head.sgl;
while (npages) {
- ret = get_user_pages(cur_base,
+ ret = get_user_pages_longterm(cur_base,
min_t(unsigned long, npages,
PAGE_SIZE / sizeof (struct page *)),
gup_flags, page_list, vma_list);
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 13/95] exec: avoid RLIMIT_STACK races with prlimit()
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (10 preceding siblings ...)
2017-12-04 15:59 ` [PATCH 4.14 12/95] IB/core: disable memory registration of filesystem-dax vmas Greg Kroah-Hartman
@ 2017-12-04 15:59 ` Greg Kroah-Hartman
2017-12-04 15:59 ` [PATCH 4.14 14/95] mm/madvise.c: fix madvise() infinite loop under special circumstances Greg Kroah-Hartman
` (64 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Kees Cook, Ben Hutchings,
Brad Spengler, Serge Hallyn, James Morris, Andy Lutomirski,
Oleg Nesterov, Jiri Slaby, Andrew Morton, Linus Torvalds
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kees Cook <keescook@chromium.org>
commit 04e35f4495dd560db30c25efca4eecae8ec8c375 upstream.
While the defense-in-depth RLIMIT_STACK limit on setuid processes was
protected against races from other threads calling setrlimit(), I missed
protecting it against races from external processes calling prlimit().
This adds locking around the change and makes sure that rlim_max is set
too.
Link: http://lkml.kernel.org/r/20171127193457.GA11348@beast
Fixes: 64701dee4178e ("exec: Use sane stack rlimit under secureexec")
Signed-off-by: Kees Cook <keescook@chromium.org>
Reported-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Reported-by: Brad Spengler <spender@grsecurity.net>
Acked-by: Serge Hallyn <serge@hallyn.com>
Cc: James Morris <james.l.morris@oracle.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/exec.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1340,10 +1340,15 @@ void setup_new_exec(struct linux_binprm
* avoid bad behavior from the prior rlimits. This has to
* happen before arch_pick_mmap_layout(), which examines
* RLIMIT_STACK, but after the point of no return to avoid
- * needing to clean up the change on failure.
+ * races from other threads changing the limits. This also
+ * must be protected from races with prlimit() calls.
*/
+ task_lock(current->group_leader);
if (current->signal->rlim[RLIMIT_STACK].rlim_cur > _STK_LIM)
current->signal->rlim[RLIMIT_STACK].rlim_cur = _STK_LIM;
+ if (current->signal->rlim[RLIMIT_STACK].rlim_max > _STK_LIM)
+ current->signal->rlim[RLIMIT_STACK].rlim_max = _STK_LIM;
+ task_unlock(current->group_leader);
}
arch_pick_mmap_layout(current->mm);
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 14/95] mm/madvise.c: fix madvise() infinite loop under special circumstances
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (11 preceding siblings ...)
2017-12-04 15:59 ` [PATCH 4.14 13/95] exec: avoid RLIMIT_STACK races with prlimit() Greg Kroah-Hartman
@ 2017-12-04 15:59 ` Greg Kroah-Hartman
2017-12-04 15:59 ` [PATCH 4.14 16/95] mm, memcg: fix mem_cgroup_swapout() for THPs Greg Kroah-Hartman
` (63 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, chenjie, guoxuenan, Michal Hocko,
Minchan Kim, zhangyi (F),
Miao Xie, Mike Rapoport, Shaohua Li, Andrea Arcangeli,
Mel Gorman, Kirill A. Shutemov, David Rientjes,
Anshuman Khandual, Rik van Riel, Carsten Otte, Dan Williams,
Andrew Morton, Linus Torvalds
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: chenjie <chenjie6@huawei.com>
commit 6ea8d958a2c95a1d514015d4e29ba21a8c0a1a91 upstream.
MADVISE_WILLNEED has always been a noop for DAX (formerly XIP) mappings.
Unfortunately madvise_willneed() doesn't communicate this information
properly to the generic madvise syscall implementation. The calling
convention is quite subtle there. madvise_vma() is supposed to either
return an error or update &prev otherwise the main loop will never
advance to the next vma and it will keep looping for ever without a way
to get out of the kernel.
It seems this has been broken since introduction. Nobody has noticed
because nobody seems to be using MADVISE_WILLNEED on these DAX mappings.
[mhocko@suse.com: rewrite changelog]
Link: http://lkml.kernel.org/r/20171127115318.911-1-guoxuenan@huawei.com
Fixes: fe77ba6f4f97 ("[PATCH] xip: madvice/fadvice: execute in place")
Signed-off-by: chenjie <chenjie6@huawei.com>
Signed-off-by: guoxuenan <guoxuenan@huawei.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: zhangyi (F) <yi.zhang@huawei.com>
Cc: Miao Xie <miaoxie@huawei.com>
Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
Cc: Shaohua Li <shli@fb.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Carsten Otte <cotte@de.ibm.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/madvise.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -276,15 +276,14 @@ static long madvise_willneed(struct vm_a
{
struct file *file = vma->vm_file;
+ *prev = vma;
#ifdef CONFIG_SWAP
if (!file) {
- *prev = vma;
force_swapin_readahead(vma, start, end);
return 0;
}
if (shmem_mapping(file->f_mapping)) {
- *prev = vma;
force_shm_swapin_readahead(vma, start, end,
file->f_mapping);
return 0;
@@ -299,7 +298,6 @@ static long madvise_willneed(struct vm_a
return 0;
}
- *prev = vma;
start = ((start - vma->vm_start) >> PAGE_SHIFT) + vma->vm_pgoff;
if (end > vma->vm_end)
end = vma->vm_end;
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 16/95] mm, memcg: fix mem_cgroup_swapout() for THPs
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (12 preceding siblings ...)
2017-12-04 15:59 ` [PATCH 4.14 14/95] mm/madvise.c: fix madvise() infinite loop under special circumstances Greg Kroah-Hartman
@ 2017-12-04 15:59 ` Greg Kroah-Hartman
2017-12-04 15:59 ` [PATCH 4.14 17/95] fs/fat/inode.c: fix sb_rdonly() change Greg Kroah-Hartman
` (62 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Shakeel Butt, Johannes Weiner,
Michal Hocko, Huang Ying, Vladimir Davydov, Greg Thelen,
Andrew Morton, Linus Torvalds
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shakeel Butt <shakeelb@google.com>
commit d08afa149acfd00871484ada6dabc3880524cd1c upstream.
Commit d6810d730022 ("memcg, THP, swap: make mem_cgroup_swapout()
support THP") changed mem_cgroup_swapout() to support transparent huge
page (THP).
However the patch missed one location which should be changed for
correctly handling THPs. The resulting bug will cause the memory
cgroups whose THPs were swapped out to become zombies on deletion.
Link: http://lkml.kernel.org/r/20171128161941.20931-1-shakeelb@google.com
Fixes: d6810d730022 ("memcg, THP, swap: make mem_cgroup_swapout() support THP")
Signed-off-by: Shakeel Butt <shakeelb@google.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Huang Ying <ying.huang@intel.com>
Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: Greg Thelen <gthelen@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
mm/memcontrol.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -6044,7 +6044,7 @@ void mem_cgroup_swapout(struct page *pag
memcg_check_events(memcg, page);
if (!mem_cgroup_is_root(memcg))
- css_put(&memcg->css);
+ css_put_many(&memcg->css, nr_entries);
}
/**
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 17/95] fs/fat/inode.c: fix sb_rdonly() change
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (13 preceding siblings ...)
2017-12-04 15:59 ` [PATCH 4.14 16/95] mm, memcg: fix mem_cgroup_swapout() for THPs Greg Kroah-Hartman
@ 2017-12-04 15:59 ` Greg Kroah-Hartman
2017-12-04 15:59 ` [PATCH 4.14 18/95] autofs: revert "autofs: take more care to not update last_used on path walk" Greg Kroah-Hartman
` (61 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, OGAWA Hirofumi, Joe Perches,
David Howells, Andrew Morton, Linus Torvalds
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
commit b6e8e12c0aeb5fbf1bf46c84d58cc93aedede385 upstream.
Commit bc98a42c1f7d ("VFS: Convert sb->s_flags & MS_RDONLY to
sb_rdonly(sb)") converted fat_remount():new_rdonly from a bool to an
int.
However fat_remount() depends upon the compiler's conversion of a
non-zero integer into boolean `true'.
Fix it by switching `new_rdonly' back into a bool.
Link: http://lkml.kernel.org/r/87mv3d5x51.fsf@mail.parknet.co.jp
Fixes: bc98a42c1f7d0f8 ("VFS: Convert sb->s_flags & MS_RDONLY to sb_rdonly(sb)")
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Cc: Joe Perches <joe@perches.com>
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/fat/inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/fat/inode.c
+++ b/fs/fat/inode.c
@@ -779,7 +779,7 @@ static void __exit fat_destroy_inodecach
static int fat_remount(struct super_block *sb, int *flags, char *data)
{
- int new_rdonly;
+ bool new_rdonly;
struct msdos_sb_info *sbi = MSDOS_SB(sb);
*flags |= MS_NODIRATIME | (sbi->options.isvfat ? 0 : MS_NOATIME);
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 18/95] autofs: revert "autofs: take more care to not update last_used on path walk"
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (14 preceding siblings ...)
2017-12-04 15:59 ` [PATCH 4.14 17/95] fs/fat/inode.c: fix sb_rdonly() change Greg Kroah-Hartman
@ 2017-12-04 15:59 ` Greg Kroah-Hartman
2017-12-04 15:59 ` [PATCH 4.14 19/95] autofs: revert "autofs: fix AT_NO_AUTOMOUNT not being honored" Greg Kroah-Hartman
` (60 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ian Kent, NeilBrown, Al Viro,
Colin Walters, David Howells, Ondrej Holy, Andrew Morton,
Linus Torvalds
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ian Kent <raven@themaw.net>
commit 43694d4bf843ddd34519e8e9de983deefeada699 upstream.
While commit 092a53452bb7 ("autofs: take more care to not update
last_used on path walk") helped (partially) resolve a problem where
automounts were not expiring due to aggressive accesses from user space
it has a side effect for very large environments.
This change helps with the expire problem by making the expire more
aggressive but, for very large environments, that means more mount
requests from clients. When there are a lot of clients that can mean
fairly significant server load increases.
It turns out I put the last_used in this position to solve this very
problem and failed to update my own thinking of the autofs expire
policy. So the patch being reverted introduces a regression which
should be fixed.
Link: http://lkml.kernel.org/r/151174729420.6162.1832622523537052460.stgit@pluto.themaw.net
Fixes: 092a53452b ("autofs: take more care to not update last_used on path walk")
Signed-off-by: Ian Kent <raven@themaw.net>
Reviewed-by: NeilBrown <neilb@suse.com>
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Colin Walters <walters@redhat.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Ondrej Holy <oholy@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/autofs4/root.c | 17 ++++++-----------
1 file changed, 6 insertions(+), 11 deletions(-)
--- a/fs/autofs4/root.c
+++ b/fs/autofs4/root.c
@@ -281,8 +281,8 @@ static int autofs4_mount_wait(const stru
pr_debug("waiting for mount name=%pd\n", path->dentry);
status = autofs4_wait(sbi, path, NFY_MOUNT);
pr_debug("mount wait done status=%d\n", status);
- ino->last_used = jiffies;
}
+ ino->last_used = jiffies;
return status;
}
@@ -321,21 +321,16 @@ static struct dentry *autofs4_mountpoint
*/
if (autofs_type_indirect(sbi->type) && d_unhashed(dentry)) {
struct dentry *parent = dentry->d_parent;
+ struct autofs_info *ino;
struct dentry *new;
new = d_lookup(parent, &dentry->d_name);
if (!new)
return NULL;
- if (new == dentry)
- dput(new);
- else {
- struct autofs_info *ino;
-
- ino = autofs4_dentry_ino(new);
- ino->last_used = jiffies;
- dput(path->dentry);
- path->dentry = new;
- }
+ ino = autofs4_dentry_ino(new);
+ ino->last_used = jiffies;
+ dput(path->dentry);
+ path->dentry = new;
}
return path->dentry;
}
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 19/95] autofs: revert "autofs: fix AT_NO_AUTOMOUNT not being honored"
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (15 preceding siblings ...)
2017-12-04 15:59 ` [PATCH 4.14 18/95] autofs: revert "autofs: take more care to not update last_used on path walk" Greg Kroah-Hartman
@ 2017-12-04 15:59 ` Greg Kroah-Hartman
2017-12-04 15:59 ` [PATCH 4.14 20/95] mm/hugetlb: fix NULL-pointer dereference on 5-level paging machine Greg Kroah-Hartman
` (59 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ian Kent, Neil Brown, Al Viro,
David Howells, Colin Walters, Ondrej Holy, Andrew Morton,
Linus Torvalds
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ian Kent <raven@themaw.net>
commit 5d38f049cee1e1c4a7ac55aa79d37d01ddcc3860 upstream.
Commit 42f461482178 ("autofs: fix AT_NO_AUTOMOUNT not being honored")
allowed the fstatat(2) system call to properly honor the AT_NO_AUTOMOUNT
flag but introduced a semantic change.
In order to honor AT_NO_AUTOMOUNT a semantic change was made to the
negative dentry case for stat family system calls in follow_automount().
This changed the unconditional triggering of an automount in this case
to no longer be done and an error returned instead.
This has caused more problems than I expected so reverting the change is
needed.
In a discussion with Neil Brown it was concluded that the automount(8)
daemon can implement this change without kernel modifications. So that
will be done instead and the autofs module documentation updated with a
description of the problem and what needs to be done by module users for
this specific case.
Link: http://lkml.kernel.org/r/151174730120.6162.3848002191530283984.stgit@pluto.themaw.net
Fixes: 42f4614821 ("autofs: fix AT_NO_AUTOMOUNT not being honored")
Signed-off-by: Ian Kent <raven@themaw.net>
Cc: Neil Brown <neilb@suse.com>
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Cc: David Howells <dhowells@redhat.com>
Cc: Colin Walters <walters@redhat.com>
Cc: Ondrej Holy <oholy@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/namei.c | 15 +++------------
include/linux/fs.h | 3 ++-
2 files changed, 5 insertions(+), 13 deletions(-)
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1129,18 +1129,9 @@ static int follow_automount(struct path
* of the daemon to instantiate them before they can be used.
*/
if (!(nd->flags & (LOOKUP_PARENT | LOOKUP_DIRECTORY |
- LOOKUP_OPEN | LOOKUP_CREATE |
- LOOKUP_AUTOMOUNT))) {
- /* Positive dentry that isn't meant to trigger an
- * automount, EISDIR will allow it to be used,
- * otherwise there's no mount here "now" so return
- * ENOENT.
- */
- if (path->dentry->d_inode)
- return -EISDIR;
- else
- return -ENOENT;
- }
+ LOOKUP_OPEN | LOOKUP_CREATE | LOOKUP_AUTOMOUNT)) &&
+ path->dentry->d_inode)
+ return -EISDIR;
if (path->dentry->d_sb->s_user_ns != &init_user_ns)
return -EACCES;
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -3069,7 +3069,8 @@ static inline int vfs_lstat(const char _
static inline int vfs_fstatat(int dfd, const char __user *filename,
struct kstat *stat, int flags)
{
- return vfs_statx(dfd, filename, flags, stat, STATX_BASIC_STATS);
+ return vfs_statx(dfd, filename, flags | AT_NO_AUTOMOUNT,
+ stat, STATX_BASIC_STATS);
}
static inline int vfs_fstat(int fd, struct kstat *stat)
{
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 20/95] mm/hugetlb: fix NULL-pointer dereference on 5-level paging machine
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (16 preceding siblings ...)
2017-12-04 15:59 ` [PATCH 4.14 19/95] autofs: revert "autofs: fix AT_NO_AUTOMOUNT not being honored" Greg Kroah-Hartman
@ 2017-12-04 15:59 ` Greg Kroah-Hartman
2017-12-04 15:59 ` [PATCH 4.14 21/95] btrfs: clear space cache inode generation always Greg Kroah-Hartman
` (58 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Kirill A. Shutemov, Vlastimil Babka,
Michal Hocko, Andrew Morton, Linus Torvalds
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
commit f4f0a3d85b50a65a348e2b8635041d6b30f01deb upstream.
I made a mistake during converting hugetlb code to 5-level paging: in
huge_pte_alloc() we have to use p4d_alloc(), not p4d_offset().
Otherwise it leads to crash -- NULL-pointer dereference in pud_alloc()
if p4d table is not yet allocated.
It only can happen in 5-level paging mode. In 4-level paging mode
p4d_offset() always returns pgd, so we are fine.
Link: http://lkml.kernel.org/r/20171122121921.64822-1-kirill.shutemov@linux.intel.com
Fixes: c2febafc6773 ("mm: convert generic code to 5-level paging")
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/hugetlb.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -4625,7 +4625,9 @@ pte_t *huge_pte_alloc(struct mm_struct *
pte_t *pte = NULL;
pgd = pgd_offset(mm, addr);
- p4d = p4d_offset(pgd, addr);
+ p4d = p4d_alloc(mm, pgd, addr);
+ if (!p4d)
+ return NULL;
pud = pud_alloc(mm, p4d, addr);
if (pud) {
if (sz == PUD_SIZE) {
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 21/95] btrfs: clear space cache inode generation always
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (17 preceding siblings ...)
2017-12-04 15:59 ` [PATCH 4.14 20/95] mm/hugetlb: fix NULL-pointer dereference on 5-level paging machine Greg Kroah-Hartman
@ 2017-12-04 15:59 ` Greg Kroah-Hartman
2017-12-04 15:59 ` [PATCH 4.14 22/95] nfsd: Fix stateid races between OPEN and CLOSE Greg Kroah-Hartman
` (57 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 15:59 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Josef Bacik, David Sterba
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Josef Bacik <jbacik@fb.com>
commit 8e138e0d92c6c9d3d481674fb14e3439b495be37 upstream.
We discovered a box that had double allocations, and suspected the space
cache may be to blame. While auditing the write out path I noticed that
if we've already setup the space cache we will just carry on. This
means that any error we hit after cache_save_setup before we go to
actually write the cache out we won't reset the inode generation, so
whatever was already written will be considered correct, except it'll be
stale. Fix this by _always_ resetting the generation on the block group
inode, this way we only ever have valid or invalid cache.
With this patch I was no longer able to reproduce cache corruption with
dm-log-writes and my bpf error injection tool.
Signed-off-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/extent-tree.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -3526,13 +3526,6 @@ again:
goto again;
}
- /* We've already setup this transaction, go ahead and exit */
- if (block_group->cache_generation == trans->transid &&
- i_size_read(inode)) {
- dcs = BTRFS_DC_SETUP;
- goto out_put;
- }
-
/*
* We want to set the generation to 0, that way if anything goes wrong
* from here on out we know not to trust this cache when we load up next
@@ -3556,6 +3549,13 @@ again:
}
WARN_ON(ret);
+ /* We've already setup this transaction, go ahead and exit */
+ if (block_group->cache_generation == trans->transid &&
+ i_size_read(inode)) {
+ dcs = BTRFS_DC_SETUP;
+ goto out_put;
+ }
+
if (i_size_read(inode) > 0) {
ret = btrfs_check_trunc_cache_free_space(fs_info,
&fs_info->global_block_rsv);
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 22/95] nfsd: Fix stateid races between OPEN and CLOSE
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (18 preceding siblings ...)
2017-12-04 15:59 ` [PATCH 4.14 21/95] btrfs: clear space cache inode generation always Greg Kroah-Hartman
@ 2017-12-04 15:59 ` Greg Kroah-Hartman
2017-12-04 15:59 ` [PATCH 4.14 23/95] nfsd: Fix another OPEN stateid race Greg Kroah-Hartman
` (56 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 15:59 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Trond Myklebust, J. Bruce Fields
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Trond Myklebust <trond.myklebust@primarydata.com>
commit 15ca08d3299682dc49bad73251677b2c5017ef08 upstream.
Open file stateids can linger on the nfs4_file list of stateids even
after they have been closed. In order to avoid reusing such a
stateid, and confusing the client, we need to recheck the
nfs4_stid's type after taking the mutex.
Otherwise, we risk reusing an old stateid that was already closed,
which will confuse clients that expect new stateids to conform to
RFC7530 Sections 9.1.4.2 and 16.2.5 or RFC5661 Sections 8.2.2 and 18.2.4.
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/nfsd/nfs4state.c | 67 +++++++++++++++++++++++++++++++++++++++++++++-------
1 file changed, 59 insertions(+), 8 deletions(-)
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -3512,7 +3512,9 @@ nfsd4_find_existing_open(struct nfs4_fil
/* ignore lock owners */
if (local->st_stateowner->so_is_open_owner == 0)
continue;
- if (local->st_stateowner == &oo->oo_owner) {
+ if (local->st_stateowner != &oo->oo_owner)
+ continue;
+ if (local->st_stid.sc_type == NFS4_OPEN_STID) {
ret = local;
atomic_inc(&ret->st_stid.sc_count);
break;
@@ -3521,6 +3523,52 @@ nfsd4_find_existing_open(struct nfs4_fil
return ret;
}
+static __be32
+nfsd4_verify_open_stid(struct nfs4_stid *s)
+{
+ __be32 ret = nfs_ok;
+
+ switch (s->sc_type) {
+ default:
+ break;
+ case NFS4_CLOSED_STID:
+ case NFS4_CLOSED_DELEG_STID:
+ ret = nfserr_bad_stateid;
+ break;
+ case NFS4_REVOKED_DELEG_STID:
+ ret = nfserr_deleg_revoked;
+ }
+ return ret;
+}
+
+/* Lock the stateid st_mutex, and deal with races with CLOSE */
+static __be32
+nfsd4_lock_ol_stateid(struct nfs4_ol_stateid *stp)
+{
+ __be32 ret;
+
+ mutex_lock(&stp->st_mutex);
+ ret = nfsd4_verify_open_stid(&stp->st_stid);
+ if (ret != nfs_ok)
+ mutex_unlock(&stp->st_mutex);
+ return ret;
+}
+
+static struct nfs4_ol_stateid *
+nfsd4_find_and_lock_existing_open(struct nfs4_file *fp, struct nfsd4_open *open)
+{
+ struct nfs4_ol_stateid *stp;
+ for (;;) {
+ spin_lock(&fp->fi_lock);
+ stp = nfsd4_find_existing_open(fp, open);
+ spin_unlock(&fp->fi_lock);
+ if (!stp || nfsd4_lock_ol_stateid(stp) == nfs_ok)
+ break;
+ nfs4_put_stid(&stp->st_stid);
+ }
+ return stp;
+}
+
static struct nfs4_openowner *
alloc_init_open_stateowner(unsigned int strhashval, struct nfsd4_open *open,
struct nfsd4_compound_state *cstate)
@@ -3565,6 +3613,7 @@ init_open_stateid(struct nfs4_file *fp,
mutex_init(&stp->st_mutex);
mutex_lock(&stp->st_mutex);
+retry:
spin_lock(&oo->oo_owner.so_client->cl_lock);
spin_lock(&fp->fi_lock);
@@ -3589,7 +3638,11 @@ out_unlock:
spin_unlock(&fp->fi_lock);
spin_unlock(&oo->oo_owner.so_client->cl_lock);
if (retstp) {
- mutex_lock(&retstp->st_mutex);
+ /* Handle races with CLOSE */
+ if (nfsd4_lock_ol_stateid(retstp) != nfs_ok) {
+ nfs4_put_stid(&retstp->st_stid);
+ goto retry;
+ }
/* To keep mutex tracking happy */
mutex_unlock(&stp->st_mutex);
stp = retstp;
@@ -4410,9 +4463,7 @@ nfsd4_process_open2(struct svc_rqst *rqs
status = nfs4_check_deleg(cl, open, &dp);
if (status)
goto out;
- spin_lock(&fp->fi_lock);
- stp = nfsd4_find_existing_open(fp, open);
- spin_unlock(&fp->fi_lock);
+ stp = nfsd4_find_and_lock_existing_open(fp, open);
} else {
open->op_file = NULL;
status = nfserr_bad_stateid;
@@ -4426,7 +4477,6 @@ nfsd4_process_open2(struct svc_rqst *rqs
*/
if (stp) {
/* Stateid was found, this is an OPEN upgrade */
- mutex_lock(&stp->st_mutex);
status = nfs4_upgrade_open(rqstp, fp, current_fh, stp, open);
if (status) {
mutex_unlock(&stp->st_mutex);
@@ -5317,7 +5367,6 @@ static void nfsd4_close_open_stateid(str
bool unhashed;
LIST_HEAD(reaplist);
- s->st_stid.sc_type = NFS4_CLOSED_STID;
spin_lock(&clp->cl_lock);
unhashed = unhash_open_stateid(s, &reaplist);
@@ -5357,10 +5406,12 @@ nfsd4_close(struct svc_rqst *rqstp, stru
nfsd4_bump_seqid(cstate, status);
if (status)
goto out;
+
+ stp->st_stid.sc_type = NFS4_CLOSED_STID;
nfs4_inc_and_copy_stateid(&close->cl_stateid, &stp->st_stid);
- mutex_unlock(&stp->st_mutex);
nfsd4_close_open_stateid(stp);
+ mutex_unlock(&stp->st_mutex);
/* put reference from nfs4_preprocess_seqid_op */
nfs4_put_stid(&stp->st_stid);
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 23/95] nfsd: Fix another OPEN stateid race
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (19 preceding siblings ...)
2017-12-04 15:59 ` [PATCH 4.14 22/95] nfsd: Fix stateid races between OPEN and CLOSE Greg Kroah-Hartman
@ 2017-12-04 15:59 ` Greg Kroah-Hartman
2017-12-04 15:59 ` [PATCH 4.14 24/95] nfsd: fix panic in posix_unblock_lock called from nfs4_laundromat Greg Kroah-Hartman
` (55 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Andrew W Elble, Trond Myklebust,
J. Bruce Fields
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Trond Myklebust <trond.myklebust@primarydata.com>
commit d8a1a000555ecd1b824ac1ed6df8fe364dfbbbb0 upstream.
If nfsd4_process_open2() is initialising a new stateid, and yet the
call to nfs4_get_vfs_file() fails for some reason, then we must
declare the stateid closed, and unhash it before dropping the mutex.
Right now, we unhash the stateid after dropping the mutex, and without
changing the stateid type, meaning that another OPEN could theoretically
look it up and attempt to use it.
Reported-by: Andrew W Elble <aweits@rit.edu>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/nfsd/nfs4state.c | 28 +++++++++++++---------------
1 file changed, 13 insertions(+), 15 deletions(-)
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -4452,6 +4452,7 @@ nfsd4_process_open2(struct svc_rqst *rqs
struct nfs4_ol_stateid *stp = NULL;
struct nfs4_delegation *dp = NULL;
__be32 status;
+ bool new_stp = false;
/*
* Lookup file; if found, lookup stateid and check open request,
@@ -4471,11 +4472,19 @@ nfsd4_process_open2(struct svc_rqst *rqs
goto out;
}
+ if (!stp) {
+ stp = init_open_stateid(fp, open);
+ if (!open->op_stp)
+ new_stp = true;
+ }
+
/*
* OPEN the file, or upgrade an existing OPEN.
* If truncate fails, the OPEN fails.
+ *
+ * stp is already locked.
*/
- if (stp) {
+ if (!new_stp) {
/* Stateid was found, this is an OPEN upgrade */
status = nfs4_upgrade_open(rqstp, fp, current_fh, stp, open);
if (status) {
@@ -4483,22 +4492,11 @@ nfsd4_process_open2(struct svc_rqst *rqs
goto out;
}
} else {
- /* stp is returned locked. */
- stp = init_open_stateid(fp, open);
- /* See if we lost the race to some other thread */
- if (stp->st_access_bmap != 0) {
- status = nfs4_upgrade_open(rqstp, fp, current_fh,
- stp, open);
- if (status) {
- mutex_unlock(&stp->st_mutex);
- goto out;
- }
- goto upgrade_out;
- }
status = nfs4_get_vfs_file(rqstp, fp, current_fh, stp, open);
if (status) {
- mutex_unlock(&stp->st_mutex);
+ stp->st_stid.sc_type = NFS4_CLOSED_STID;
release_open_stateid(stp);
+ mutex_unlock(&stp->st_mutex);
goto out;
}
@@ -4507,7 +4505,7 @@ nfsd4_process_open2(struct svc_rqst *rqs
if (stp->st_clnt_odstate == open->op_odstate)
open->op_odstate = NULL;
}
-upgrade_out:
+
nfs4_inc_and_copy_stateid(&open->op_stateid, &stp->st_stid);
mutex_unlock(&stp->st_mutex);
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 24/95] nfsd: fix panic in posix_unblock_lock called from nfs4_laundromat
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (20 preceding siblings ...)
2017-12-04 15:59 ` [PATCH 4.14 23/95] nfsd: Fix another OPEN stateid race Greg Kroah-Hartman
@ 2017-12-04 15:59 ` Greg Kroah-Hartman
2017-12-04 15:59 ` [PATCH 4.14 25/95] crypto: algif_aead - skip SGL entries with NULL page Greg Kroah-Hartman
` (54 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 15:59 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, jlayton, J. Bruce Fields
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Naofumi Honda <honda@math.sci.hokudai.ac.jp>
commit 64ebe12494fd5d193f014ce38e1fd83cc57883c8 upstream.
>From kernel 4.9, my two nfsv4 servers sometimes suffer from
"panic: unable to handle kernel page request"
in posix_unblock_lock() called from nfs4_laundromat().
These panics diseappear if we revert the commit "nfsd: add a LRU list
for blocked locks".
The cause appears to be a typo in nfs4_laundromat(), which is also
present in nfs4_state_shutdown_net().
Fixes: 7919d0a27f1e "nfsd: add a LRU list for blocked locks"
Cc: jlayton@redhat.com
Reveiwed-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/nfsd/nfs4state.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -4732,7 +4732,7 @@ nfs4_laundromat(struct nfsd_net *nn)
spin_unlock(&nn->blocked_locks_lock);
while (!list_empty(&reaplist)) {
- nbl = list_first_entry(&nn->blocked_locks_lru,
+ nbl = list_first_entry(&reaplist,
struct nfsd4_blocked_lock, nbl_lru);
list_del_init(&nbl->nbl_lru);
posix_unblock_lock(&nbl->nbl_lock);
@@ -7152,7 +7152,7 @@ nfs4_state_shutdown_net(struct net *net)
spin_unlock(&nn->blocked_locks_lock);
while (!list_empty(&reaplist)) {
- nbl = list_first_entry(&nn->blocked_locks_lru,
+ nbl = list_first_entry(&reaplist,
struct nfsd4_blocked_lock, nbl_lru);
list_del_init(&nbl->nbl_lru);
posix_unblock_lock(&nbl->nbl_lock);
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 25/95] crypto: algif_aead - skip SGL entries with NULL page
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (21 preceding siblings ...)
2017-12-04 15:59 ` [PATCH 4.14 24/95] nfsd: fix panic in posix_unblock_lock called from nfs4_laundromat Greg Kroah-Hartman
@ 2017-12-04 15:59 ` Greg Kroah-Hartman
2017-12-04 15:59 ` [PATCH 4.14 26/95] crypto: af_alg - remove locking in async callback Greg Kroah-Hartman
` (53 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 15:59 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Stephan Mueller, Herbert Xu
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stephan Mueller <smueller@chronox.de>
commit 8e1fa89aa8bc2870009b4486644e4a58f2e2a4f5 upstream.
The TX SGL may contain SGL entries that are assigned a NULL page. This
may happen if a multi-stage AIO operation is performed where the data
for each stage is pointed to by one SGL entry. Upon completion of that
stage, af_alg_pull_tsgl will assign NULL to the SGL entry.
The NULL cipher used to copy the AAD from TX SGL to the destination
buffer, however, cannot handle the case where the SGL starts with an SGL
entry having a NULL page. Thus, the code needs to advance the start
pointer into the SGL to the first non-NULL entry.
This fixes a crash visible on Intel x86 32 bit using the libkcapi test
suite.
Fixes: 72548b093ee38 ("crypto: algif_aead - copy AAD from src to dst")
Signed-off-by: Stephan Mueller <smueller@chronox.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
crypto/algif_aead.c | 33 ++++++++++++++++++++++++---------
1 file changed, 24 insertions(+), 9 deletions(-)
--- a/crypto/algif_aead.c
+++ b/crypto/algif_aead.c
@@ -101,10 +101,10 @@ static int _aead_recvmsg(struct socket *
struct aead_tfm *aeadc = pask->private;
struct crypto_aead *tfm = aeadc->aead;
struct crypto_skcipher *null_tfm = aeadc->null_tfm;
- unsigned int as = crypto_aead_authsize(tfm);
+ unsigned int i, as = crypto_aead_authsize(tfm);
struct af_alg_async_req *areq;
- struct af_alg_tsgl *tsgl;
- struct scatterlist *src;
+ struct af_alg_tsgl *tsgl, *tmp;
+ struct scatterlist *rsgl_src, *tsgl_src = NULL;
int err = 0;
size_t used = 0; /* [in] TX bufs to be en/decrypted */
size_t outlen = 0; /* [out] RX bufs produced by kernel */
@@ -178,7 +178,22 @@ static int _aead_recvmsg(struct socket *
}
processed = used + ctx->aead_assoclen;
- tsgl = list_first_entry(&ctx->tsgl_list, struct af_alg_tsgl, list);
+ list_for_each_entry_safe(tsgl, tmp, &ctx->tsgl_list, list) {
+ for (i = 0; i < tsgl->cur; i++) {
+ struct scatterlist *process_sg = tsgl->sg + i;
+
+ if (!(process_sg->length) || !sg_page(process_sg))
+ continue;
+ tsgl_src = process_sg;
+ break;
+ }
+ if (tsgl_src)
+ break;
+ }
+ if (processed && !tsgl_src) {
+ err = -EFAULT;
+ goto free;
+ }
/*
* Copy of AAD from source to destination
@@ -194,7 +209,7 @@ static int _aead_recvmsg(struct socket *
*/
/* Use the RX SGL as source (and destination) for crypto op. */
- src = areq->first_rsgl.sgl.sg;
+ rsgl_src = areq->first_rsgl.sgl.sg;
if (ctx->enc) {
/*
@@ -207,7 +222,7 @@ static int _aead_recvmsg(struct socket *
* v v
* RX SGL: AAD || PT || Tag
*/
- err = crypto_aead_copy_sgl(null_tfm, tsgl->sg,
+ err = crypto_aead_copy_sgl(null_tfm, tsgl_src,
areq->first_rsgl.sgl.sg, processed);
if (err)
goto free;
@@ -225,7 +240,7 @@ static int _aead_recvmsg(struct socket *
*/
/* Copy AAD || CT to RX SGL buffer for in-place operation. */
- err = crypto_aead_copy_sgl(null_tfm, tsgl->sg,
+ err = crypto_aead_copy_sgl(null_tfm, tsgl_src,
areq->first_rsgl.sgl.sg, outlen);
if (err)
goto free;
@@ -257,11 +272,11 @@ static int _aead_recvmsg(struct socket *
areq->tsgl);
} else
/* no RX SGL present (e.g. authentication only) */
- src = areq->tsgl;
+ rsgl_src = areq->tsgl;
}
/* Initialize the crypto operation */
- aead_request_set_crypt(&areq->cra_u.aead_req, src,
+ aead_request_set_crypt(&areq->cra_u.aead_req, rsgl_src,
areq->first_rsgl.sgl.sg, used, ctx->iv);
aead_request_set_ad(&areq->cra_u.aead_req, ctx->aead_assoclen);
aead_request_set_tfm(&areq->cra_u.aead_req, tfm);
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 26/95] crypto: af_alg - remove locking in async callback
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (22 preceding siblings ...)
2017-12-04 15:59 ` [PATCH 4.14 25/95] crypto: algif_aead - skip SGL entries with NULL page Greg Kroah-Hartman
@ 2017-12-04 15:59 ` Greg Kroah-Hartman
2017-12-04 15:59 ` [PATCH 4.14 28/95] lockd: lost rollback of set_grace_period() in lockd_down_net() Greg Kroah-Hartman
` (52 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Romain Izard, Stephan Mueller, Herbert Xu
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stephan Mueller <smueller@chronox.de>
commit 7d2c3f54e6f646887d019faa45f35d6fe9fe82ce upstream.
The code paths protected by the socket-lock do not use or modify the
socket in a non-atomic fashion. The actions pertaining the socket do not
even need to be handled as an atomic operation. Thus, the socket-lock
can be safely ignored.
This fixes a bug regarding scheduling in atomic as the callback function
may be invoked in interrupt context.
In addition, the sock_hold is moved before the AIO encrypt/decrypt
operation to ensure that the socket is always present. This avoids a
tiny race window where the socket is unprotected and yet used by the AIO
operation.
Finally, the release of resources for a crypto operation is moved into a
common function of af_alg_free_resources.
Fixes: e870456d8e7c8 ("crypto: algif_skcipher - overhaul memory management")
Fixes: d887c52d6ae43 ("crypto: algif_aead - overhaul memory management")
Reported-by: Romain Izard <romain.izard.pro@gmail.com>
Signed-off-by: Stephan Mueller <smueller@chronox.de>
Tested-by: Romain Izard <romain.izard.pro@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
crypto/af_alg.c | 21 ++++++++++++++-------
crypto/algif_aead.c | 23 ++++++++++++-----------
crypto/algif_skcipher.c | 23 ++++++++++++-----------
include/crypto/if_alg.h | 1 +
4 files changed, 39 insertions(+), 29 deletions(-)
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -1048,6 +1048,18 @@ unlock:
EXPORT_SYMBOL_GPL(af_alg_sendpage);
/**
+ * af_alg_free_resources - release resources required for crypto request
+ */
+void af_alg_free_resources(struct af_alg_async_req *areq)
+{
+ struct sock *sk = areq->sk;
+
+ af_alg_free_areq_sgls(areq);
+ sock_kfree_s(sk, areq, areq->areqlen);
+}
+EXPORT_SYMBOL_GPL(af_alg_free_resources);
+
+/**
* af_alg_async_cb - AIO callback handler
*
* This handler cleans up the struct af_alg_async_req upon completion of the
@@ -1063,18 +1075,13 @@ void af_alg_async_cb(struct crypto_async
struct kiocb *iocb = areq->iocb;
unsigned int resultlen;
- lock_sock(sk);
-
/* Buffer size written by crypto operation. */
resultlen = areq->outlen;
- af_alg_free_areq_sgls(areq);
- sock_kfree_s(sk, areq, areq->areqlen);
- __sock_put(sk);
+ af_alg_free_resources(areq);
+ sock_put(sk);
iocb->ki_complete(iocb, err ? err : resultlen, 0);
-
- release_sock(sk);
}
EXPORT_SYMBOL_GPL(af_alg_async_cb);
--- a/crypto/algif_aead.c
+++ b/crypto/algif_aead.c
@@ -283,12 +283,23 @@ static int _aead_recvmsg(struct socket *
if (msg->msg_iocb && !is_sync_kiocb(msg->msg_iocb)) {
/* AIO operation */
+ sock_hold(sk);
areq->iocb = msg->msg_iocb;
aead_request_set_callback(&areq->cra_u.aead_req,
CRYPTO_TFM_REQ_MAY_BACKLOG,
af_alg_async_cb, areq);
err = ctx->enc ? crypto_aead_encrypt(&areq->cra_u.aead_req) :
crypto_aead_decrypt(&areq->cra_u.aead_req);
+
+ /* AIO operation in progress */
+ if (err == -EINPROGRESS || err == -EBUSY) {
+ /* Remember output size that will be generated. */
+ areq->outlen = outlen;
+
+ return -EIOCBQUEUED;
+ }
+
+ sock_put(sk);
} else {
/* Synchronous operation */
aead_request_set_callback(&areq->cra_u.aead_req,
@@ -300,19 +311,9 @@ static int _aead_recvmsg(struct socket *
&ctx->completion);
}
- /* AIO operation in progress */
- if (err == -EINPROGRESS) {
- sock_hold(sk);
-
- /* Remember output size that will be generated. */
- areq->outlen = outlen;
-
- return -EIOCBQUEUED;
- }
free:
- af_alg_free_areq_sgls(areq);
- sock_kfree_s(sk, areq, areq->areqlen);
+ af_alg_free_resources(areq);
return err ? err : outlen;
}
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -117,6 +117,7 @@ static int _skcipher_recvmsg(struct sock
if (msg->msg_iocb && !is_sync_kiocb(msg->msg_iocb)) {
/* AIO operation */
+ sock_hold(sk);
areq->iocb = msg->msg_iocb;
skcipher_request_set_callback(&areq->cra_u.skcipher_req,
CRYPTO_TFM_REQ_MAY_SLEEP,
@@ -124,6 +125,16 @@ static int _skcipher_recvmsg(struct sock
err = ctx->enc ?
crypto_skcipher_encrypt(&areq->cra_u.skcipher_req) :
crypto_skcipher_decrypt(&areq->cra_u.skcipher_req);
+
+ /* AIO operation in progress */
+ if (err == -EINPROGRESS || err == -EBUSY) {
+ /* Remember output size that will be generated. */
+ areq->outlen = len;
+
+ return -EIOCBQUEUED;
+ }
+
+ sock_put(sk);
} else {
/* Synchronous operation */
skcipher_request_set_callback(&areq->cra_u.skcipher_req,
@@ -137,19 +148,9 @@ static int _skcipher_recvmsg(struct sock
&ctx->completion);
}
- /* AIO operation in progress */
- if (err == -EINPROGRESS) {
- sock_hold(sk);
-
- /* Remember output size that will be generated. */
- areq->outlen = len;
-
- return -EIOCBQUEUED;
- }
free:
- af_alg_free_areq_sgls(areq);
- sock_kfree_s(sk, areq, areq->areqlen);
+ af_alg_free_resources(areq);
return err ? err : len;
}
--- a/include/crypto/if_alg.h
+++ b/include/crypto/if_alg.h
@@ -255,6 +255,7 @@ int af_alg_sendmsg(struct socket *sock,
unsigned int ivsize);
ssize_t af_alg_sendpage(struct socket *sock, struct page *page,
int offset, size_t size, int flags);
+void af_alg_free_resources(struct af_alg_async_req *areq);
void af_alg_async_cb(struct crypto_async_request *_req, int err);
unsigned int af_alg_poll(struct file *file, struct socket *sock,
poll_table *wait);
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 28/95] lockd: lost rollback of set_grace_period() in lockd_down_net()
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (23 preceding siblings ...)
2017-12-04 15:59 ` [PATCH 4.14 26/95] crypto: af_alg - remove locking in async callback Greg Kroah-Hartman
@ 2017-12-04 15:59 ` Greg Kroah-Hartman
2017-12-04 15:59 ` [PATCH 4.14 29/95] s390: revert ELF_ET_DYN_BASE base changes Greg Kroah-Hartman
` (51 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 15:59 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Vasily Averin, J. Bruce Fields
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vasily Averin <vvs@virtuozzo.com>
commit 3a2b19d1ee5633f76ae8a88da7bc039a5d1732aa upstream.
Commit efda760fe95ea ("lockd: fix lockd shutdown race") is incorrect,
it removes lockd_manager and disarm grace_period_end for init_net only.
If nfsd was started from another net namespace lockd_up_net() calls
set_grace_period() that adds lockd_manager into per-netns list
and queues grace_period_end delayed work.
These action should be reverted in lockd_down_net().
Otherwise it can lead to double list_add on after restart nfsd in netns,
and to use-after-free if non-disarmed delayed work will be executed after netns destroy.
Fixes: efda760fe95e ("lockd: fix lockd shutdown race")
Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/lockd/svc.c | 2 ++
1 file changed, 2 insertions(+)
--- a/fs/lockd/svc.c
+++ b/fs/lockd/svc.c
@@ -274,6 +274,8 @@ static void lockd_down_net(struct svc_se
if (ln->nlmsvc_users) {
if (--ln->nlmsvc_users == 0) {
nlm_shutdown_hosts_net(net);
+ cancel_delayed_work_sync(&ln->grace_period_end);
+ locks_end_grace(&ln->lockd_manager);
svc_shutdown_net(serv, net);
dprintk("lockd_down_net: per-net data destroyed; net=%p\n", net);
}
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 29/95] s390: revert ELF_ET_DYN_BASE base changes
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (24 preceding siblings ...)
2017-12-04 15:59 ` [PATCH 4.14 28/95] lockd: lost rollback of set_grace_period() in lockd_down_net() Greg Kroah-Hartman
@ 2017-12-04 15:59 ` Greg Kroah-Hartman
2017-12-04 15:59 ` [PATCH 4.14 30/95] drm: omapdrm: Fix DPI on platforms using the DSI VDDS Greg Kroah-Hartman
` (50 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 15:59 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Martin Schwidefsky
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Martin Schwidefsky <schwidefsky@de.ibm.com>
commit 345f8f34bb473241d62803951c18a844dd705f8d upstream.
This reverts commit a73dc5370e153ac63718d850bddf0c9aa9d871e6.
Reducing the base address for 31-bit PIE executables from
(STACK_TOP/3)*2 to 4MB broke several compat programs which
use -fpie to move the executable out of the lower 16MB.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/s390/include/asm/elf.h | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
--- a/arch/s390/include/asm/elf.h
+++ b/arch/s390/include/asm/elf.h
@@ -194,13 +194,14 @@ struct arch_elf_state {
#define CORE_DUMP_USE_REGSET
#define ELF_EXEC_PAGESIZE PAGE_SIZE
-/*
- * This is the base location for PIE (ET_DYN with INTERP) loads. On
- * 64-bit, this is raised to 4GB to leave the entire 32-bit address
- * space open for things that want to use the area for 32-bit pointers.
- */
-#define ELF_ET_DYN_BASE (is_compat_task() ? 0x000400000UL : \
- 0x100000000UL)
+/* This is the location that an ET_DYN program is loaded if exec'ed. Typical
+ use of this is to invoke "./ld.so someprog" to test out a new version of
+ the loader. We need to make sure that it is out of the way of the program
+ that it will "exec", and that there is sufficient room for the brk. 64-bit
+ tasks are aligned to 4GB. */
+#define ELF_ET_DYN_BASE (is_compat_task() ? \
+ (STACK_TOP / 3 * 2) : \
+ (STACK_TOP / 3 * 2) & ~((1UL << 32) - 1))
/* This yields a mask that user programs can use to figure out what
instruction set this CPU supports. */
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 30/95] drm: omapdrm: Fix DPI on platforms using the DSI VDDS
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (25 preceding siblings ...)
2017-12-04 15:59 ` [PATCH 4.14 29/95] s390: revert ELF_ET_DYN_BASE base changes Greg Kroah-Hartman
@ 2017-12-04 15:59 ` Greg Kroah-Hartman
2017-12-04 15:59 ` [PATCH 4.14 31/95] omapdrm: hdmi4: Correct the SoC revision matching Greg Kroah-Hartman
` (49 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Laurent Pinchart,
H. Nikolaus Schaller, Tomi Valkeinen
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
commit bf25dac38f71d392a31ec074f55cbc941f1eaf1d upstream.
Commit d178e034d565 ("drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature
to dpi code") replaced usage of platform data version with SoC matching
to configure DPI VDDS. The SoC match entries were incorrect, they should
have matched on the machine name instead of the SoC family. Fix it.
The result was observed on OpenPandora with OMAP3530 where the panel only
had the Blue channel and Red&Green were missing. It was not observed on
GTA04 with DM3730.
Fixes: d178e034d565 ("drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature to dpi code")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reported-by: H. Nikolaus Schaller <hns@goldelico.com>
Tested-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/omapdrm/dss/dpi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/omapdrm/dss/dpi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dpi.c
@@ -566,8 +566,8 @@ static int dpi_verify_pll(struct dss_pll
}
static const struct soc_device_attribute dpi_soc_devices[] = {
- { .family = "OMAP3[456]*" },
- { .family = "[AD]M37*" },
+ { .machine = "OMAP3[456]*" },
+ { .machine = "[AD]M37*" },
{ /* sentinel */ }
};
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 31/95] omapdrm: hdmi4: Correct the SoC revision matching
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (26 preceding siblings ...)
2017-12-04 15:59 ` [PATCH 4.14 30/95] drm: omapdrm: Fix DPI on platforms using the DSI VDDS Greg Kroah-Hartman
@ 2017-12-04 15:59 ` Greg Kroah-Hartman
2017-12-04 15:59 ` [PATCH 4.14 32/95] apparmor: fix oops in audit_signal_cb hook Greg Kroah-Hartman
` (48 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Peter Ujfalusi, Laurent Pinchart,
Tomi Valkeinen
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Ujfalusi <peter.ujfalusi@ti.com>
commit 23970e150a0a49f9a966c46e5d22fed06226098f upstream.
I believe the intention of the commit 2c9fc9bf45f8
("drm: omapdrm: Move FEAT_HDMI_* features to hdmi4 driver")
was to identify omap4430 ES1.x, omap4430 ES2.x and other OMAP4 revisions,
like omap4460.
By using family=OMAP4 in the match the code will treat omap4460 ES1.x in a
same way as it would treat omap4430 ES1.x
This breaks HDMI audio on OMAP4460 devices (PandaES for example).
Correct the match rule so we are not going to get false positive match.
Fixes: 2c9fc9bf45f8 ("drm: omapdrm: Move FEAT_HDMI_* features to hdmi4 driver")
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/omapdrm/dss/hdmi4_core.c | 23 +++++++++++++++++------
1 file changed, 17 insertions(+), 6 deletions(-)
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c
@@ -889,25 +889,36 @@ struct hdmi4_features {
bool audio_use_mclk;
};
-static const struct hdmi4_features hdmi4_es1_features = {
+static const struct hdmi4_features hdmi4430_es1_features = {
.cts_swmode = false,
.audio_use_mclk = false,
};
-static const struct hdmi4_features hdmi4_es2_features = {
+static const struct hdmi4_features hdmi4430_es2_features = {
.cts_swmode = true,
.audio_use_mclk = false,
};
-static const struct hdmi4_features hdmi4_es3_features = {
+static const struct hdmi4_features hdmi4_features = {
.cts_swmode = true,
.audio_use_mclk = true,
};
static const struct soc_device_attribute hdmi4_soc_devices[] = {
- { .family = "OMAP4", .revision = "ES1.?", .data = &hdmi4_es1_features },
- { .family = "OMAP4", .revision = "ES2.?", .data = &hdmi4_es2_features },
- { .family = "OMAP4", .data = &hdmi4_es3_features },
+ {
+ .machine = "OMAP4430",
+ .revision = "ES1.?",
+ .data = &hdmi4430_es1_features,
+ },
+ {
+ .machine = "OMAP4430",
+ .revision = "ES2.?",
+ .data = &hdmi4430_es2_features,
+ },
+ {
+ .family = "OMAP4",
+ .data = &hdmi4_features,
+ },
{ /* sentinel */ }
};
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 32/95] apparmor: fix oops in audit_signal_cb hook
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (27 preceding siblings ...)
2017-12-04 15:59 ` [PATCH 4.14 31/95] omapdrm: hdmi4: Correct the SoC revision matching Greg Kroah-Hartman
@ 2017-12-04 15:59 ` Greg Kroah-Hartman
2017-12-04 15:59 ` [PATCH 4.14 33/95] arm64: module-plts: factor out PLT generation code for ftrace Greg Kroah-Hartman
` (47 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Zephaniah E. Loss-Cutler-Hull,
Shuah Khan, Tetsuo Handa, Ivan Kozik, Christian Boltz,
John Johansen
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: John Johansen <john.johansen@canonical.com>
commit b12cbb21586277f72533769832c24cc6c1d60ab3 upstream.
The apparmor_audit_data struct ordering got messed up during a merge
conflict, resulting in the signal integer and peer pointer being in
a union instead of a struct.
For most of the 4.13 and 4.14 life cycle, this was hidden by
commit 651e28c5537a ("apparmor: add base infastructure for socket
mediation") which fixed the apparmor_audit_data struct when its data
was added. When that commit was reverted in -rc7 the signal audit bug
was exposed, and unfortunately it never showed up in any of the
testing until after 4.14 was released. Shaun Khan, Zephaniah
E. Loss-Cutler-Hull filed nearly simultaneous bug reports (with
different oopes, the smaller of which is included below).
Full credit goes to Tetsuo Handa for jumping on this as well and
noticing the audit data struct problem and reporting it.
[ 76.178568] BUG: unable to handle kernel paging request at
ffffffff0eee3bc0
[ 76.178579] IP: audit_signal_cb+0x6c/0xe0
[ 76.178581] PGD 1a640a067 P4D 1a640a067 PUD 0
[ 76.178586] Oops: 0000 [#1] PREEMPT SMP
[ 76.178589] Modules linked in: fuse rfcomm bnep usblp uvcvideo btusb
btrtl btbcm btintel bluetooth ecdh_generic ip6table_filter ip6_tables
xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack
iptable_filter ip_tables x_tables intel_rapl joydev wmi_bmof serio_raw
iwldvm iwlwifi shpchp kvm_intel kvm irqbypass autofs4 algif_skcipher
nls_iso8859_1 nls_cp437 crc32_pclmul ghash_clmulni_intel
[ 76.178620] CPU: 0 PID: 10675 Comm: pidgin Not tainted
4.14.0-f1-dirty #135
[ 76.178623] Hardware name: Hewlett-Packard HP EliteBook Folio
9470m/18DF, BIOS 68IBD Ver. F.62 10/22/2015
[ 76.178625] task: ffff9c7a94c31dc0 task.stack: ffffa09b02a4c000
[ 76.178628] RIP: 0010:audit_signal_cb+0x6c/0xe0
[ 76.178631] RSP: 0018:ffffa09b02a4fc08 EFLAGS: 00010292
[ 76.178634] RAX: ffffa09b02a4fd60 RBX: ffff9c7aee0741f8 RCX:
0000000000000000
[ 76.178636] RDX: ffffffffee012290 RSI: 0000000000000006 RDI:
ffff9c7a9493d800
[ 76.178638] RBP: ffffa09b02a4fd40 R08: 000000000000004d R09:
ffffa09b02a4fc46
[ 76.178641] R10: ffffa09b02a4fcb8 R11: ffff9c7ab44f5072 R12:
ffffa09b02a4fd40
[ 76.178643] R13: ffffffff9e447be0 R14: ffff9c7a94c31dc0 R15:
0000000000000001
[ 76.178646] FS: 00007f8b11ba2a80(0000) GS:ffff9c7afea00000(0000)
knlGS:0000000000000000
[ 76.178648] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 76.178650] CR2: ffffffff0eee3bc0 CR3: 00000003d5209002 CR4:
00000000001606f0
[ 76.178652] Call Trace:
[ 76.178660] common_lsm_audit+0x1da/0x780
[ 76.178665] ? d_absolute_path+0x60/0x90
[ 76.178669] ? aa_check_perms+0xcd/0xe0
[ 76.178672] aa_check_perms+0xcd/0xe0
[ 76.178675] profile_signal_perm.part.0+0x90/0xa0
[ 76.178679] aa_may_signal+0x16e/0x1b0
[ 76.178686] apparmor_task_kill+0x51/0x120
[ 76.178690] security_task_kill+0x44/0x60
[ 76.178695] group_send_sig_info+0x25/0x60
[ 76.178699] kill_pid_info+0x36/0x60
[ 76.178703] SYSC_kill+0xdb/0x180
[ 76.178707] ? preempt_count_sub+0x92/0xd0
[ 76.178712] ? _raw_write_unlock_irq+0x13/0x30
[ 76.178716] ? task_work_run+0x6a/0x90
[ 76.178720] ? exit_to_usermode_loop+0x80/0xa0
[ 76.178723] entry_SYSCALL_64_fastpath+0x13/0x94
[ 76.178727] RIP: 0033:0x7f8b0e58b767
[ 76.178729] RSP: 002b:00007fff19efd4d8 EFLAGS: 00000206 ORIG_RAX:
000000000000003e
[ 76.178732] RAX: ffffffffffffffda RBX: 0000557f3e3c2050 RCX:
00007f8b0e58b767
[ 76.178735] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
000000000000263b
[ 76.178737] RBP: 0000000000000000 R08: 0000557f3e3c2270 R09:
0000000000000001
[ 76.178739] R10: 000000000000022d R11: 0000000000000206 R12:
0000000000000000
[ 76.178741] R13: 0000000000000001 R14: 0000557f3e3c13c0 R15:
0000000000000000
[ 76.178745] Code: 48 8b 55 18 48 89 df 41 b8 20 00 08 01 5b 5d 48 8b
42 10 48 8b 52 30 48 63 48 4c 48 8b 44 c8 48 31 c9 48 8b 70 38 e9 f4 fd
00 00 <48> 8b 14 d5 40 27 e5 9e 48 c7 c6 7d 07 19 9f 48 89 df e8 fd 35
[ 76.178794] RIP: audit_signal_cb+0x6c/0xe0 RSP: ffffa09b02a4fc08
[ 76.178796] CR2: ffffffff0eee3bc0
[ 76.178799] ---[ end trace 514af9529297f1a3 ]---
Fixes: cd1dbf76b23d ("apparmor: add the ability to mediate signals")
Reported-by: Zephaniah E. Loss-Cutler-Hull <warp-spam_kernel@aehallh.com>
Reported-by: Shuah Khan <shuahkh@osg.samsung.com>
Suggested-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Tested-by: Ivan Kozik <ivan@ludios.org>
Tested-by: Zephaniah E. Loss-Cutler-Hull <warp-spam_kernel@aehallh.com>
Tested-by: Christian Boltz <apparmor@cboltz.de>
Tested-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
security/apparmor/include/audit.h | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
--- a/security/apparmor/include/audit.h
+++ b/security/apparmor/include/audit.h
@@ -121,17 +121,19 @@ struct apparmor_audit_data {
/* these entries require a custom callback fn */
struct {
struct aa_label *peer;
- struct {
- const char *target;
- kuid_t ouid;
- } fs;
+ union {
+ struct {
+ const char *target;
+ kuid_t ouid;
+ } fs;
+ int signal;
+ };
};
struct {
struct aa_profile *profile;
const char *ns;
long pos;
} iface;
- int signal;
struct {
int rlim;
unsigned long max;
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 33/95] arm64: module-plts: factor out PLT generation code for ftrace
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (28 preceding siblings ...)
2017-12-04 15:59 ` [PATCH 4.14 32/95] apparmor: fix oops in audit_signal_cb hook Greg Kroah-Hartman
@ 2017-12-04 15:59 ` Greg Kroah-Hartman
2017-12-04 15:59 ` [PATCH 4.14 34/95] arm64: ftrace: emit ftrace-mod.o contents through code Greg Kroah-Hartman
` (46 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 15:59 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Ard Biesheuvel, Will Deacon
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
commit 7e8b9c1d2e2f5f45db7d40b50d14f606097c25de upstream.
To allow the ftrace trampoline code to reuse the PLT entry routines,
factor it out and move it into asm/module.h.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/include/asm/module.h | 44 ++++++++++++++++++++++++++++++++++++++++
arch/arm64/kernel/module-plts.c | 38 +---------------------------------
2 files changed, 46 insertions(+), 36 deletions(-)
--- a/arch/arm64/include/asm/module.h
+++ b/arch/arm64/include/asm/module.h
@@ -45,4 +45,48 @@ extern u64 module_alloc_base;
#define module_alloc_base ((u64)_etext - MODULES_VSIZE)
#endif
+struct plt_entry {
+ /*
+ * A program that conforms to the AArch64 Procedure Call Standard
+ * (AAPCS64) must assume that a veneer that alters IP0 (x16) and/or
+ * IP1 (x17) may be inserted at any branch instruction that is
+ * exposed to a relocation that supports long branches. Since that
+ * is exactly what we are dealing with here, we are free to use x16
+ * as a scratch register in the PLT veneers.
+ */
+ __le32 mov0; /* movn x16, #0x.... */
+ __le32 mov1; /* movk x16, #0x...., lsl #16 */
+ __le32 mov2; /* movk x16, #0x...., lsl #32 */
+ __le32 br; /* br x16 */
+};
+
+static inline struct plt_entry get_plt_entry(u64 val)
+{
+ /*
+ * MOVK/MOVN/MOVZ opcode:
+ * +--------+------------+--------+-----------+-------------+---------+
+ * | sf[31] | opc[30:29] | 100101 | hw[22:21] | imm16[20:5] | Rd[4:0] |
+ * +--------+------------+--------+-----------+-------------+---------+
+ *
+ * Rd := 0x10 (x16)
+ * hw := 0b00 (no shift), 0b01 (lsl #16), 0b10 (lsl #32)
+ * opc := 0b11 (MOVK), 0b00 (MOVN), 0b10 (MOVZ)
+ * sf := 1 (64-bit variant)
+ */
+ return (struct plt_entry){
+ cpu_to_le32(0x92800010 | (((~val ) & 0xffff)) << 5),
+ cpu_to_le32(0xf2a00010 | ((( val >> 16) & 0xffff)) << 5),
+ cpu_to_le32(0xf2c00010 | ((( val >> 32) & 0xffff)) << 5),
+ cpu_to_le32(0xd61f0200)
+ };
+}
+
+static inline bool plt_entries_equal(const struct plt_entry *a,
+ const struct plt_entry *b)
+{
+ return a->mov0 == b->mov0 &&
+ a->mov1 == b->mov1 &&
+ a->mov2 == b->mov2;
+}
+
#endif /* __ASM_MODULE_H */
--- a/arch/arm64/kernel/module-plts.c
+++ b/arch/arm64/kernel/module-plts.c
@@ -11,21 +11,6 @@
#include <linux/module.h>
#include <linux/sort.h>
-struct plt_entry {
- /*
- * A program that conforms to the AArch64 Procedure Call Standard
- * (AAPCS64) must assume that a veneer that alters IP0 (x16) and/or
- * IP1 (x17) may be inserted at any branch instruction that is
- * exposed to a relocation that supports long branches. Since that
- * is exactly what we are dealing with here, we are free to use x16
- * as a scratch register in the PLT veneers.
- */
- __le32 mov0; /* movn x16, #0x.... */
- __le32 mov1; /* movk x16, #0x...., lsl #16 */
- __le32 mov2; /* movk x16, #0x...., lsl #32 */
- __le32 br; /* br x16 */
-};
-
static bool in_init(const struct module *mod, void *loc)
{
return (u64)loc - (u64)mod->init_layout.base < mod->init_layout.size;
@@ -40,33 +25,14 @@ u64 module_emit_plt_entry(struct module
int i = pltsec->plt_num_entries;
u64 val = sym->st_value + rela->r_addend;
- /*
- * MOVK/MOVN/MOVZ opcode:
- * +--------+------------+--------+-----------+-------------+---------+
- * | sf[31] | opc[30:29] | 100101 | hw[22:21] | imm16[20:5] | Rd[4:0] |
- * +--------+------------+--------+-----------+-------------+---------+
- *
- * Rd := 0x10 (x16)
- * hw := 0b00 (no shift), 0b01 (lsl #16), 0b10 (lsl #32)
- * opc := 0b11 (MOVK), 0b00 (MOVN), 0b10 (MOVZ)
- * sf := 1 (64-bit variant)
- */
- plt[i] = (struct plt_entry){
- cpu_to_le32(0x92800010 | (((~val ) & 0xffff)) << 5),
- cpu_to_le32(0xf2a00010 | ((( val >> 16) & 0xffff)) << 5),
- cpu_to_le32(0xf2c00010 | ((( val >> 32) & 0xffff)) << 5),
- cpu_to_le32(0xd61f0200)
- };
+ plt[i] = get_plt_entry(val);
/*
* Check if the entry we just created is a duplicate. Given that the
* relocations are sorted, this will be the last entry we allocated.
* (if one exists).
*/
- if (i > 0 &&
- plt[i].mov0 == plt[i - 1].mov0 &&
- plt[i].mov1 == plt[i - 1].mov1 &&
- plt[i].mov2 == plt[i - 1].mov2)
+ if (i > 0 && plt_entries_equal(plt + i, plt + i - 1))
return (u64)&plt[i - 1];
pltsec->plt_num_entries++;
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 34/95] arm64: ftrace: emit ftrace-mod.o contents through code
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (29 preceding siblings ...)
2017-12-04 15:59 ` [PATCH 4.14 33/95] arm64: module-plts: factor out PLT generation code for ftrace Greg Kroah-Hartman
@ 2017-12-04 15:59 ` Greg Kroah-Hartman
2017-12-04 15:59 ` [PATCH 4.14 35/95] powerpc/powernv: Fix kexec crashes caused by tlbie tracing Greg Kroah-Hartman
` (45 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 15:59 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Ard Biesheuvel, Will Deacon
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
commit be0f272bfc83797f70d44faca86954df62e2bbc0 upstream.
When building the arm64 kernel with both CONFIG_ARM64_MODULE_PLTS and
CONFIG_DYNAMIC_FTRACE enabled, the ftrace-mod.o object file is built
with the kernel and contains a trampoline that is linked into each
module, so that modules can be loaded far away from the kernel and
still reach the ftrace entry point in the core kernel with an ordinary
relative branch, as is emitted by the compiler instrumentation code
dynamic ftrace relies on.
In order to be able to build out of tree modules, this object file
needs to be included into the linux-headers or linux-devel packages,
which is undesirable, as it makes arm64 a special case (although a
precedent does exist for 32-bit PPC).
Given that the trampoline essentially consists of a PLT entry, let's
not bother with a source or object file for it, and simply patch it
in whenever the trampoline is being populated, using the existing
PLT support routines.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/Makefile | 3 ---
arch/arm64/include/asm/module.h | 2 +-
arch/arm64/kernel/Makefile | 3 ---
arch/arm64/kernel/ftrace-mod.S | 18 ------------------
arch/arm64/kernel/ftrace.c | 14 ++++++++------
arch/arm64/kernel/module-plts.c | 12 ++++++++++++
arch/arm64/kernel/module.lds | 1 +
7 files changed, 22 insertions(+), 31 deletions(-)
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -77,9 +77,6 @@ endif
ifeq ($(CONFIG_ARM64_MODULE_PLTS),y)
KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/arm64/kernel/module.lds
-ifeq ($(CONFIG_DYNAMIC_FTRACE),y)
-KBUILD_LDFLAGS_MODULE += $(objtree)/arch/arm64/kernel/ftrace-mod.o
-endif
endif
# Default value
--- a/arch/arm64/include/asm/module.h
+++ b/arch/arm64/include/asm/module.h
@@ -32,7 +32,7 @@ struct mod_arch_specific {
struct mod_plt_sec init;
/* for CONFIG_DYNAMIC_FTRACE */
- void *ftrace_trampoline;
+ struct plt_entry *ftrace_trampoline;
};
#endif
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -63,6 +63,3 @@ extra-y += $(head-y) vmlinux.lds
ifeq ($(CONFIG_DEBUG_EFI),y)
AFLAGS_head.o += -DVMLINUX_PATH="\"$(realpath $(objtree)/vmlinux)\""
endif
-
-# will be included by each individual module but not by the core kernel itself
-extra-$(CONFIG_DYNAMIC_FTRACE) += ftrace-mod.o
--- a/arch/arm64/kernel/ftrace-mod.S
+++ /dev/null
@@ -1,18 +0,0 @@
-/*
- * Copyright (C) 2017 Linaro Ltd <ard.biesheuvel@linaro.org>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include <linux/linkage.h>
-#include <asm/assembler.h>
-
- .section ".text.ftrace_trampoline", "ax"
- .align 3
-0: .quad 0
-__ftrace_trampoline:
- ldr x16, 0b
- br x16
-ENDPROC(__ftrace_trampoline)
--- a/arch/arm64/kernel/ftrace.c
+++ b/arch/arm64/kernel/ftrace.c
@@ -76,7 +76,7 @@ int ftrace_make_call(struct dyn_ftrace *
if (offset < -SZ_128M || offset >= SZ_128M) {
#ifdef CONFIG_ARM64_MODULE_PLTS
- unsigned long *trampoline;
+ struct plt_entry trampoline;
struct module *mod;
/*
@@ -104,22 +104,24 @@ int ftrace_make_call(struct dyn_ftrace *
* is added in the future, but for now, the pr_err() below
* deals with a theoretical issue only.
*/
- trampoline = (unsigned long *)mod->arch.ftrace_trampoline;
- if (trampoline[0] != addr) {
- if (trampoline[0] != 0) {
+ trampoline = get_plt_entry(addr);
+ if (!plt_entries_equal(mod->arch.ftrace_trampoline,
+ &trampoline)) {
+ if (!plt_entries_equal(mod->arch.ftrace_trampoline,
+ &(struct plt_entry){})) {
pr_err("ftrace: far branches to multiple entry points unsupported inside a single module\n");
return -EINVAL;
}
/* point the trampoline to our ftrace entry point */
module_disable_ro(mod);
- trampoline[0] = addr;
+ *mod->arch.ftrace_trampoline = trampoline;
module_enable_ro(mod, true);
/* update trampoline before patching in the branch */
smp_wmb();
}
- addr = (unsigned long)&trampoline[1];
+ addr = (unsigned long)(void *)mod->arch.ftrace_trampoline;
#else /* CONFIG_ARM64_MODULE_PLTS */
return -EINVAL;
#endif /* CONFIG_ARM64_MODULE_PLTS */
--- a/arch/arm64/kernel/module-plts.c
+++ b/arch/arm64/kernel/module-plts.c
@@ -120,6 +120,7 @@ int module_frob_arch_sections(Elf_Ehdr *
unsigned long core_plts = 0;
unsigned long init_plts = 0;
Elf64_Sym *syms = NULL;
+ Elf_Shdr *tramp = NULL;
int i;
/*
@@ -131,6 +132,10 @@ int module_frob_arch_sections(Elf_Ehdr *
mod->arch.core.plt = sechdrs + i;
else if (!strcmp(secstrings + sechdrs[i].sh_name, ".init.plt"))
mod->arch.init.plt = sechdrs + i;
+ else if (IS_ENABLED(CONFIG_DYNAMIC_FTRACE) &&
+ !strcmp(secstrings + sechdrs[i].sh_name,
+ ".text.ftrace_trampoline"))
+ tramp = sechdrs + i;
else if (sechdrs[i].sh_type == SHT_SYMTAB)
syms = (Elf64_Sym *)sechdrs[i].sh_addr;
}
@@ -181,5 +186,12 @@ int module_frob_arch_sections(Elf_Ehdr *
mod->arch.init.plt_num_entries = 0;
mod->arch.init.plt_max_entries = init_plts;
+ if (tramp) {
+ tramp->sh_type = SHT_NOBITS;
+ tramp->sh_flags = SHF_EXECINSTR | SHF_ALLOC;
+ tramp->sh_addralign = __alignof__(struct plt_entry);
+ tramp->sh_size = sizeof(struct plt_entry);
+ }
+
return 0;
}
--- a/arch/arm64/kernel/module.lds
+++ b/arch/arm64/kernel/module.lds
@@ -1,4 +1,5 @@
SECTIONS {
.plt (NOLOAD) : { BYTE(0) }
.init.plt (NOLOAD) : { BYTE(0) }
+ .text.ftrace_trampoline (NOLOAD) : { BYTE(0) }
}
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 35/95] powerpc/powernv: Fix kexec crashes caused by tlbie tracing
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (30 preceding siblings ...)
2017-12-04 15:59 ` [PATCH 4.14 34/95] arm64: ftrace: emit ftrace-mod.o contents through code Greg Kroah-Hartman
@ 2017-12-04 15:59 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 36/95] powerpc/kexec: Fix kexec/kdump in P9 guest kernels Greg Kroah-Hartman
` (44 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Mahesh Salgaonkar, Aneesh Kumar K.V,
Michael Ellerman, Naveen N. Rao
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
commit a3961f824cdbe7eb431254dc7d8f6f6767f474aa upstream.
Rebooting into a new kernel with kexec fails in trace_tlbie() which is
called from native_hpte_clear(). This happens if the running kernel
has CONFIG_LOCKDEP enabled. With lockdep enabled, the tracepoints
always execute few RCU checks regardless of whether tracing is on or
off. We are already in the last phase of kexec sequence in real mode
with HILE_BE set. At this point the RCU check ends up in
RCU_LOCKDEP_WARN and causes kexec to fail.
Fix this by not calling trace_tlbie() from native_hpte_clear().
mpe: It's not safe to call trace points at this point in the kexec
path, even if we could avoid the RCU checks/warnings. The only
solution is to not call them.
Fixes: 0428491cba92 ("powerpc/mm: Trace tlbie(l) instructions")
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Reported-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
Acked-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/mm/hash_native_64.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
--- a/arch/powerpc/mm/hash_native_64.c
+++ b/arch/powerpc/mm/hash_native_64.c
@@ -47,7 +47,8 @@
DEFINE_RAW_SPINLOCK(native_tlbie_lock);
-static inline void __tlbie(unsigned long vpn, int psize, int apsize, int ssize)
+static inline unsigned long ___tlbie(unsigned long vpn, int psize,
+ int apsize, int ssize)
{
unsigned long va;
unsigned int penc;
@@ -100,7 +101,15 @@ static inline void __tlbie(unsigned long
: "memory");
break;
}
- trace_tlbie(0, 0, va, 0, 0, 0, 0);
+ return va;
+}
+
+static inline void __tlbie(unsigned long vpn, int psize, int apsize, int ssize)
+{
+ unsigned long rb;
+
+ rb = ___tlbie(vpn, psize, apsize, ssize);
+ trace_tlbie(0, 0, rb, 0, 0, 0, 0);
}
static inline void __tlbiel(unsigned long vpn, int psize, int apsize, int ssize)
@@ -652,7 +661,7 @@ static void native_hpte_clear(void)
if (hpte_v & HPTE_V_VALID) {
hpte_decode(hptep, slot, &psize, &apsize, &ssize, &vpn);
hptep->v = 0;
- __tlbie(vpn, psize, apsize, ssize);
+ ___tlbie(vpn, psize, apsize, ssize);
}
}
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 36/95] powerpc/kexec: Fix kexec/kdump in P9 guest kernels
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (31 preceding siblings ...)
2017-12-04 15:59 ` [PATCH 4.14 35/95] powerpc/powernv: Fix kexec crashes caused by tlbie tracing Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 40/95] KVM: lapic: Split out x2apic ldr calculation Greg Kroah-Hartman
` (43 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Yilin Zhang, Michael Ellerman,
Balbir Singh, David Gibson
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Ellerman <mpe@ellerman.id.au>
commit 2621e945fbf1d6df5f3f0ba7be5bae3d2cf9b6a5 upstream.
The code that cleans up the IAMR/AMOR before kexec'ing failed to
remember that when we're running as a guest AMOR is not writable, it's
hypervisor privileged.
They symptom is that the kexec stops before entering purgatory and
nothing else is seen on the console. If you examine the state of the
system all threads will be in the 0x700 program check handler.
Fix it by making the write to AMOR dependent on HV mode.
Fixes: 1e2a516e89fc ("powerpc/kexec: Fix radix to hash kexec due to IAMR/AMOR")
Reported-by: Yilin Zhang <yilzhang@redhat.com>
Debugged-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Acked-by: Balbir Singh <bsingharora@gmail.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/kernel/misc_64.S | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/powerpc/kernel/misc_64.S
+++ b/arch/powerpc/kernel/misc_64.S
@@ -623,7 +623,9 @@ BEGIN_FTR_SECTION
* NOTE, we rely on r0 being 0 from above.
*/
mtspr SPRN_IAMR,r0
+BEGIN_FTR_SECTION_NESTED(42)
mtspr SPRN_AMOR,r0
+END_FTR_SECTION_NESTED_IFSET(CPU_FTR_HVMODE, 42)
END_FTR_SECTION_IFSET(CPU_FTR_ARCH_300)
/* save regs for local vars on new stack.
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 40/95] KVM: lapic: Split out x2apic ldr calculation
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (32 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 36/95] powerpc/kexec: Fix kexec/kdump in P9 guest kernels Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 41/95] KVM: lapic: Fixup LDR on load in x2apic Greg Kroah-Hartman
` (42 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dr. David Alan Gilbert, Paolo Bonzini
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dr. David Alan Gilbert <dgilbert@redhat.com>
commit e872fa94662d0644057c7c80b3071bdb9249e5ab upstream.
Split out the ldr calculation from kvm_apic_set_x2apic_id
since we're about to reuse it in the following patch.
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kvm/lapic.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -266,9 +266,14 @@ static inline void kvm_apic_set_ldr(stru
recalculate_apic_map(apic->vcpu->kvm);
}
+static inline u32 kvm_apic_calc_x2apic_ldr(u32 id)
+{
+ return ((id >> 4) << 16) | (1 << (id & 0xf));
+}
+
static inline void kvm_apic_set_x2apic_id(struct kvm_lapic *apic, u32 id)
{
- u32 ldr = ((id >> 4) << 16) | (1 << (id & 0xf));
+ u32 ldr = kvm_apic_calc_x2apic_ldr(id);
WARN_ON_ONCE(id != apic->vcpu->vcpu_id);
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 41/95] KVM: lapic: Fixup LDR on load in x2apic
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (33 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 40/95] KVM: lapic: Split out x2apic ldr calculation Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 42/95] mmc: sdhci: Avoid swiotlb buffer being full Greg Kroah-Hartman
` (41 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Yiqian Wei, Dr. David Alan Gilbert,
Paolo Bonzini
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dr. David Alan Gilbert <dgilbert@redhat.com>
commit 12806ba937382fdfdbad62a399aa2dce65c10fcd upstream.
In x2apic mode the LDR is fixed based on the ID rather
than separately loadable like it was before x2.
When kvm_apic_set_state is called, the base is set, and if
it has the X2APIC_ENABLE flag set then the LDR is calculated;
however that value gets overwritten by the memcpy a few lines
below overwriting it with the value that came from userland.
The symptom is a lack of EOI after loading the state
(e.g. after a QEMU migration) and is due to the EOI bitmap
being wrong due to the incorrect LDR. This was seen with
a Win2016 guest under Qemu with irqchip=split whose USB mouse
didn't work after a VM migration.
This corresponds to RH bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1502591
Reported-by: Yiqian Wei <yiwei@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
[Applied fixup from Liran Alon. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kvm/lapic.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -2201,6 +2201,7 @@ static int kvm_apic_state_fixup(struct k
{
if (apic_x2apic_mode(vcpu->arch.apic)) {
u32 *id = (u32 *)(s->regs + APIC_ID);
+ u32 *ldr = (u32 *)(s->regs + APIC_LDR);
if (vcpu->kvm->arch.x2apic_format) {
if (*id != vcpu->vcpu_id)
@@ -2211,6 +2212,10 @@ static int kvm_apic_state_fixup(struct k
else
*id <<= 24;
}
+
+ /* In x2APIC mode, the LDR is fixed and based on the id */
+ if (set)
+ *ldr = kvm_apic_calc_x2apic_ldr(*id);
}
return 0;
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 42/95] mmc: sdhci: Avoid swiotlb buffer being full
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (34 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 41/95] KVM: lapic: Fixup LDR on load in x2apic Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 43/95] mmc: block: Fix missing blk_put_request() Greg Kroah-Hartman
` (40 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jiri Slaby, Ulf Hansson, Adrian Hunter
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ulf Hansson <ulf.hansson@linaro.org>
commit 250dcd11466e06df64b92520e2c56bdae453581b upstream.
The commit de3ee99b097d ("mmc: Delete bounce buffer handling") deletes the
bounce buffer handling, but also causes the max_req_size for sdhci to be
increased, in case when max_segs == 1. This causes errors for sdhci-pci
Ricoh variant, about the swiotlb buffer to become full.
Fix the issue, by taking IO_TLB_SEGSIZE and IO_TLB_SHIFT into account when
deciding the max_req_size for sdhci.
Reported-by: Jiri Slaby <jslaby@suse.cz>
Fixes: de3ee99b097d ("mmc: Delete bounce buffer handling")
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Jiri Slaby <jslaby@suse.cz>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/host/sdhci.c | 28 ++++++++++++++++++----------
1 file changed, 18 insertions(+), 10 deletions(-)
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -21,6 +21,7 @@
#include <linux/dma-mapping.h>
#include <linux/slab.h>
#include <linux/scatterlist.h>
+#include <linux/swiotlb.h>
#include <linux/regulator/consumer.h>
#include <linux/pm_runtime.h>
#include <linux/of.h>
@@ -3651,22 +3652,29 @@ int sdhci_setup_host(struct sdhci_host *
spin_lock_init(&host->lock);
/*
+ * Maximum number of sectors in one transfer. Limited by SDMA boundary
+ * size (512KiB). Note some tuning modes impose a 4MiB limit, but this
+ * is less anyway.
+ */
+ mmc->max_req_size = 524288;
+
+ /*
* Maximum number of segments. Depends on if the hardware
* can do scatter/gather or not.
*/
- if (host->flags & SDHCI_USE_ADMA)
+ if (host->flags & SDHCI_USE_ADMA) {
mmc->max_segs = SDHCI_MAX_SEGS;
- else if (host->flags & SDHCI_USE_SDMA)
+ } else if (host->flags & SDHCI_USE_SDMA) {
mmc->max_segs = 1;
- else /* PIO */
+ if (swiotlb_max_segment()) {
+ unsigned int max_req_size = (1 << IO_TLB_SHIFT) *
+ IO_TLB_SEGSIZE;
+ mmc->max_req_size = min(mmc->max_req_size,
+ max_req_size);
+ }
+ } else { /* PIO */
mmc->max_segs = SDHCI_MAX_SEGS;
-
- /*
- * Maximum number of sectors in one transfer. Limited by SDMA boundary
- * size (512KiB). Note some tuning modes impose a 4MiB limit, but this
- * is less anyway.
- */
- mmc->max_req_size = 524288;
+ }
/*
* Maximum segment size. Could be one segment with the maximum number
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 43/95] mmc: block: Fix missing blk_put_request()
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (35 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 42/95] mmc: sdhci: Avoid swiotlb buffer being full Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 44/95] mmc: block: Check return value of blk_get_request() Greg Kroah-Hartman
` (39 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Adrian Hunter, Linus Walleij, Ulf Hansson
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adrian Hunter <adrian.hunter@intel.com>
commit 34c089e806793a66e450b11bd167db6047399fcd upstream.
Ensure blk_get_request() is paired with blk_put_request().
Fixes: 0493f6fe5bde ("mmc: block: Move boot partition locking into a driver op")
Fixes: 627c3ccfb46a ("mmc: debugfs: Move block debugfs into block module")
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/core/block.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -207,6 +207,7 @@ static ssize_t power_ro_lock_store(struc
req_to_mmc_queue_req(req)->drv_op = MMC_DRV_OP_BOOT_WP;
blk_execute_rq(mq->queue, NULL, req, 0);
ret = req_to_mmc_queue_req(req)->drv_op_result;
+ blk_put_request(req);
if (!ret) {
pr_info("%s: Locking boot partition ro until next power on\n",
@@ -2321,6 +2322,7 @@ static int mmc_dbg_card_status_get(void
*val = ret;
ret = 0;
}
+ blk_put_request(req);
return ret;
}
@@ -2351,6 +2353,7 @@ static int mmc_ext_csd_open(struct inode
req_to_mmc_queue_req(req)->drv_op_data = &ext_csd;
blk_execute_rq(mq->queue, NULL, req, 0);
err = req_to_mmc_queue_req(req)->drv_op_result;
+ blk_put_request(req);
if (err) {
pr_err("FAILED %d\n", err);
goto out_free;
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 44/95] mmc: block: Check return value of blk_get_request()
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (36 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 43/95] mmc: block: Fix missing blk_put_request() Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 45/95] mmc: core: Do not leave the block driver in a suspended state Greg Kroah-Hartman
` (38 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Adrian Hunter, Linus Walleij, Ulf Hansson
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adrian Hunter <adrian.hunter@intel.com>
commit fb8e456e547ed2c699f64665bd8a3b9bde7b9728 upstream.
blk_get_request() can fail, always check the return value.
Fixes: 0493f6fe5bde ("mmc: block: Move boot partition locking into a driver op")
Fixes: 3ecd8cf23f88 ("mmc: block: move multi-ioctl() to use block layer")
Fixes: 614f0388f580 ("mmc: block: move single ioctl() commands to block requests")
Fixes: 627c3ccfb46a ("mmc: debugfs: Move block debugfs into block module")
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/core/block.c | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -204,6 +204,10 @@ static ssize_t power_ro_lock_store(struc
/* Dispatch locking to the block layer */
req = blk_get_request(mq->queue, REQ_OP_DRV_OUT, __GFP_RECLAIM);
+ if (IS_ERR(req)) {
+ count = PTR_ERR(req);
+ goto out_put;
+ }
req_to_mmc_queue_req(req)->drv_op = MMC_DRV_OP_BOOT_WP;
blk_execute_rq(mq->queue, NULL, req, 0);
ret = req_to_mmc_queue_req(req)->drv_op_result;
@@ -220,7 +224,7 @@ static ssize_t power_ro_lock_store(struc
set_disk_ro(part_md->disk, 1);
}
}
-
+out_put:
mmc_blk_put(md);
return count;
}
@@ -581,6 +585,10 @@ static int mmc_blk_ioctl_cmd(struct mmc_
req = blk_get_request(mq->queue,
idata->ic.write_flag ? REQ_OP_DRV_OUT : REQ_OP_DRV_IN,
__GFP_RECLAIM);
+ if (IS_ERR(req)) {
+ err = PTR_ERR(req);
+ goto cmd_done;
+ }
idatas[0] = idata;
req_to_mmc_queue_req(req)->drv_op = MMC_DRV_OP_IOCTL;
req_to_mmc_queue_req(req)->drv_op_data = idatas;
@@ -644,6 +652,10 @@ static int mmc_blk_ioctl_multi_cmd(struc
req = blk_get_request(mq->queue,
idata[0]->ic.write_flag ? REQ_OP_DRV_OUT : REQ_OP_DRV_IN,
__GFP_RECLAIM);
+ if (IS_ERR(req)) {
+ err = PTR_ERR(req);
+ goto cmd_err;
+ }
req_to_mmc_queue_req(req)->drv_op = MMC_DRV_OP_IOCTL;
req_to_mmc_queue_req(req)->drv_op_data = idata;
req_to_mmc_queue_req(req)->ioc_count = num_of_cmds;
@@ -2315,6 +2327,8 @@ static int mmc_dbg_card_status_get(void
/* Ask the block layer about the card status */
req = blk_get_request(mq->queue, REQ_OP_DRV_IN, __GFP_RECLAIM);
+ if (IS_ERR(req))
+ return PTR_ERR(req);
req_to_mmc_queue_req(req)->drv_op = MMC_DRV_OP_GET_CARD_STATUS;
blk_execute_rq(mq->queue, NULL, req, 0);
ret = req_to_mmc_queue_req(req)->drv_op_result;
@@ -2349,6 +2363,10 @@ static int mmc_ext_csd_open(struct inode
/* Ask the block layer for the EXT CSD */
req = blk_get_request(mq->queue, REQ_OP_DRV_IN, __GFP_RECLAIM);
+ if (IS_ERR(req)) {
+ err = PTR_ERR(req);
+ goto out_free;
+ }
req_to_mmc_queue_req(req)->drv_op = MMC_DRV_OP_GET_EXT_CSD;
req_to_mmc_queue_req(req)->drv_op_data = &ext_csd;
blk_execute_rq(mq->queue, NULL, req, 0);
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 45/95] mmc: core: Do not leave the block driver in a suspended state
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (37 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 44/95] mmc: block: Check return value of blk_get_request() Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 46/95] mmc: block: Ensure that debugfs files are removed Greg Kroah-Hartman
` (37 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Adrian Hunter, Linus Walleij, Ulf Hansson
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adrian Hunter <adrian.hunter@intel.com>
commit ebe7dd45cf49e3b49cacbaace17f9f878f21fbea upstream.
The block driver must be resumed if the mmc bus fails to suspend the card.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/core/bus.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/mmc/core/bus.c
+++ b/drivers/mmc/core/bus.c
@@ -157,6 +157,9 @@ static int mmc_bus_suspend(struct device
return ret;
ret = host->bus_ops->suspend(host);
+ if (ret)
+ pm_generic_resume(dev);
+
return ret;
}
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 46/95] mmc: block: Ensure that debugfs files are removed
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (38 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 45/95] mmc: core: Do not leave the block driver in a suspended state Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 47/95] mmc: core: prepend 0x to pre_eol_info entry in sysfs Greg Kroah-Hartman
` (36 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Adrian Hunter, Linus Walleij, Ulf Hansson
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adrian Hunter <adrian.hunter@intel.com>
commit f9f0da98819503b06b35e61869d18cf3a8cd3323 upstream.
The card is not necessarily being removed, but the debugfs files must be
removed when the driver is removed, otherwise they will continue to exist
after unbinding the card from the driver. e.g.
# echo "mmc1:0001" > /sys/bus/mmc/drivers/mmcblk/unbind
# cat /sys/kernel/debug/mmc1/mmc1\:0001/ext_csd
[ 173.634584] BUG: unable to handle kernel NULL pointer dereference at 0000000000000050
[ 173.643356] IP: mmc_ext_csd_open+0x5e/0x170
A complication is that the debugfs_root may have already been removed, so
check for that too.
Fixes: 627c3ccfb46a ("mmc: debugfs: Move block debugfs into block module")
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/core/block.c | 44 +++++++++++++++++++++++++++++++++++++-------
drivers/mmc/core/debugfs.c | 1 +
2 files changed, 38 insertions(+), 7 deletions(-)
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -119,6 +119,10 @@ struct mmc_blk_data {
struct device_attribute force_ro;
struct device_attribute power_ro_lock;
int area_type;
+
+ /* debugfs files (only in main mmc_blk_data) */
+ struct dentry *status_dentry;
+ struct dentry *ext_csd_dentry;
};
static DEFINE_MUTEX(open_lock);
@@ -2417,7 +2421,7 @@ static const struct file_operations mmc_
.llseek = default_llseek,
};
-static int mmc_blk_add_debugfs(struct mmc_card *card)
+static int mmc_blk_add_debugfs(struct mmc_card *card, struct mmc_blk_data *md)
{
struct dentry *root;
@@ -2427,28 +2431,53 @@ static int mmc_blk_add_debugfs(struct mm
root = card->debugfs_root;
if (mmc_card_mmc(card) || mmc_card_sd(card)) {
- if (!debugfs_create_file("status", S_IRUSR, root, card,
- &mmc_dbg_card_status_fops))
+ md->status_dentry =
+ debugfs_create_file("status", S_IRUSR, root, card,
+ &mmc_dbg_card_status_fops);
+ if (!md->status_dentry)
return -EIO;
}
if (mmc_card_mmc(card)) {
- if (!debugfs_create_file("ext_csd", S_IRUSR, root, card,
- &mmc_dbg_ext_csd_fops))
+ md->ext_csd_dentry =
+ debugfs_create_file("ext_csd", S_IRUSR, root, card,
+ &mmc_dbg_ext_csd_fops);
+ if (!md->ext_csd_dentry)
return -EIO;
}
return 0;
}
+static void mmc_blk_remove_debugfs(struct mmc_card *card,
+ struct mmc_blk_data *md)
+{
+ if (!card->debugfs_root)
+ return;
+
+ if (!IS_ERR_OR_NULL(md->status_dentry)) {
+ debugfs_remove(md->status_dentry);
+ md->status_dentry = NULL;
+ }
+
+ if (!IS_ERR_OR_NULL(md->ext_csd_dentry)) {
+ debugfs_remove(md->ext_csd_dentry);
+ md->ext_csd_dentry = NULL;
+ }
+}
#else
-static int mmc_blk_add_debugfs(struct mmc_card *card)
+static int mmc_blk_add_debugfs(struct mmc_card *card, struct mmc_blk_data *md)
{
return 0;
}
+static void mmc_blk_remove_debugfs(struct mmc_card *card,
+ struct mmc_blk_data *md)
+{
+}
+
#endif /* CONFIG_DEBUG_FS */
static int mmc_blk_probe(struct mmc_card *card)
@@ -2488,7 +2517,7 @@ static int mmc_blk_probe(struct mmc_card
}
/* Add two debugfs entries */
- mmc_blk_add_debugfs(card);
+ mmc_blk_add_debugfs(card, md);
pm_runtime_set_autosuspend_delay(&card->dev, 3000);
pm_runtime_use_autosuspend(&card->dev);
@@ -2514,6 +2543,7 @@ static void mmc_blk_remove(struct mmc_ca
{
struct mmc_blk_data *md = dev_get_drvdata(&card->dev);
+ mmc_blk_remove_debugfs(card, md);
mmc_blk_remove_parts(card, md);
pm_runtime_get_sync(&card->dev);
mmc_claim_host(card->host);
--- a/drivers/mmc/core/debugfs.c
+++ b/drivers/mmc/core/debugfs.c
@@ -314,4 +314,5 @@ err:
void mmc_remove_card_debugfs(struct mmc_card *card)
{
debugfs_remove_recursive(card->debugfs_root);
+ card->debugfs_root = NULL;
}
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 47/95] mmc: core: prepend 0x to pre_eol_info entry in sysfs
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (39 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 46/95] mmc: block: Ensure that debugfs files are removed Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 48/95] mmc: core: prepend 0x to OCR " Greg Kroah-Hartman
` (35 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Bastian Stender, Ulf Hansson
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bastian Stender <bst@pengutronix.de>
commit 80a780a167d9267c72867b806142bd6ec69ba123 upstream.
The sysfs entry "pre_eol_info" was missing the 0x prefix to identify it
as hex formatted.
Fixes: 46bc5c408e4e ("mmc: core: Export device lifetime information through sysfs")
Signed-off-by: Bastian Stender <bst@pengutronix.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/core/mmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -780,7 +780,7 @@ MMC_DEV_ATTR(manfid, "0x%06x\n", card->c
MMC_DEV_ATTR(name, "%s\n", card->cid.prod_name);
MMC_DEV_ATTR(oemid, "0x%04x\n", card->cid.oemid);
MMC_DEV_ATTR(prv, "0x%x\n", card->cid.prv);
-MMC_DEV_ATTR(pre_eol_info, "%02x\n", card->ext_csd.pre_eol_info);
+MMC_DEV_ATTR(pre_eol_info, "0x%02x\n", card->ext_csd.pre_eol_info);
MMC_DEV_ATTR(life_time, "0x%02x 0x%02x\n",
card->ext_csd.device_life_time_est_typ_a,
card->ext_csd.device_life_time_est_typ_b);
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 48/95] mmc: core: prepend 0x to OCR entry in sysfs
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (40 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 47/95] mmc: core: prepend 0x to pre_eol_info entry in sysfs Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 49/95] ACPI / EC: Fix regression related to PM ops support in ECDT device Greg Kroah-Hartman
` (34 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Bastian Stender, Ulf Hansson
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bastian Stender <bst@pengutronix.de>
commit c892b0d81705c566f575e489efc3c50762db1bde upstream.
The sysfs entry "ocr" was missing the 0x prefix to identify it as hex
formatted.
Fixes: 5fb06af7a33b ("mmc: core: Extend sysfs with OCR register")
Signed-off-by: Bastian Stender <bst@pengutronix.de>
[Ulf: Amended change to also cover SD-cards]
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/core/mmc.c | 2 +-
drivers/mmc/core/sd.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -790,7 +790,7 @@ MMC_DEV_ATTR(enhanced_area_offset, "%llu
MMC_DEV_ATTR(enhanced_area_size, "%u\n", card->ext_csd.enhanced_area_size);
MMC_DEV_ATTR(raw_rpmb_size_mult, "%#x\n", card->ext_csd.raw_rpmb_size_mult);
MMC_DEV_ATTR(rel_sectors, "%#x\n", card->ext_csd.rel_sectors);
-MMC_DEV_ATTR(ocr, "%08x\n", card->ocr);
+MMC_DEV_ATTR(ocr, "0x%08x\n", card->ocr);
MMC_DEV_ATTR(cmdq_en, "%d\n", card->ext_csd.cmdq_en);
static ssize_t mmc_fwrev_show(struct device *dev,
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -675,7 +675,7 @@ MMC_DEV_ATTR(manfid, "0x%06x\n", card->c
MMC_DEV_ATTR(name, "%s\n", card->cid.prod_name);
MMC_DEV_ATTR(oemid, "0x%04x\n", card->cid.oemid);
MMC_DEV_ATTR(serial, "0x%08x\n", card->cid.serial);
-MMC_DEV_ATTR(ocr, "%08x\n", card->ocr);
+MMC_DEV_ATTR(ocr, "0x%08x\n", card->ocr);
static ssize_t mmc_dsr_show(struct device *dev,
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 49/95] ACPI / EC: Fix regression related to PM ops support in ECDT device
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (41 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 48/95] mmc: core: prepend 0x to OCR " Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 50/95] eeprom: at24: fix reading from 24MAC402/24MAC602 Greg Kroah-Hartman
` (33 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Luya Tshimbalanga, Lv Zheng,
Rafael J. Wysocki
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lv Zheng <lv.zheng@intel.com>
commit a64a62ce9a380213dc9e192f762266d70c9b40ec upstream.
On platforms (ASUS X550ZE and possibly all ASUS X series) with valid ECDT
EC but invalid DSDT EC, EC PM ops won't be invoked as ECDT EC is not an
ACPI device. Thus the following commit actually removed post-resume
acpi_ec_enable_event() invocation for such platforms, and triggered a
regression on them that after being resumed, EC (actually should be ECDT)
driver stops handling EC events:
Commit: c2b46d679b30c5c0d7eb47a21085943242bdd8dc
Subject: ACPI / EC: Add PM operations to improve event handling for resume process
Notice that the root cause actually is "ECDT is not an ACPI device" rather
than "the timing of acpi_ec_enable_event() invocation", this patch fixes
this issue by enumerating ECDT EC as an ACPI device. Due to the existence
of the noirq stage, the ability of tuning the timing of
acpi_ec_enable_event() invocation is still meaningful.
This patch is a little bit different from the posted fix by moving
acpi_config_boot_ec() from acpi_ec_ecdt_start() to acpi_ec_add() to make
sure that EC event handling won't be stopped as long as the ACPI EC driver
is bound. Thus the following sequence shouldn't disable EC event handling:
unbind,suspend,resume,bind.
Fixes: c2b46d679b30 (ACPI / EC: Add PM operations to improve event handling for resume process)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=196847
Reported-by: Luya Tshimbalanga <luya@fedoraproject.org>
Tested-by: Luya Tshimbalanga <luya@fedoraproject.org>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/acpi/ec.c | 69 ++++++++++++++++++++++++++++----------------
drivers/acpi/internal.h | 1
drivers/acpi/scan.c | 21 +++++++++++++
include/acpi/acpi_bus.h | 1
include/acpi/acpi_drivers.h | 1
5 files changed, 69 insertions(+), 24 deletions(-)
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -1597,32 +1597,41 @@ static int acpi_ec_add(struct acpi_devic
{
struct acpi_ec *ec = NULL;
int ret;
+ bool is_ecdt = false;
+ acpi_status status;
strcpy(acpi_device_name(device), ACPI_EC_DEVICE_NAME);
strcpy(acpi_device_class(device), ACPI_EC_CLASS);
- ec = acpi_ec_alloc();
- if (!ec)
- return -ENOMEM;
- if (ec_parse_device(device->handle, 0, ec, NULL) !=
- AE_CTRL_TERMINATE) {
+ if (!strcmp(acpi_device_hid(device), ACPI_ECDT_HID)) {
+ is_ecdt = true;
+ ec = boot_ec;
+ } else {
+ ec = acpi_ec_alloc();
+ if (!ec)
+ return -ENOMEM;
+ status = ec_parse_device(device->handle, 0, ec, NULL);
+ if (status != AE_CTRL_TERMINATE) {
ret = -EINVAL;
goto err_alloc;
+ }
}
if (acpi_is_boot_ec(ec)) {
- boot_ec_is_ecdt = false;
- /*
- * Trust PNP0C09 namespace location rather than ECDT ID.
- *
- * But trust ECDT GPE rather than _GPE because of ASUS quirks,
- * so do not change boot_ec->gpe to ec->gpe.
- */
- boot_ec->handle = ec->handle;
- acpi_handle_debug(ec->handle, "duplicated.\n");
- acpi_ec_free(ec);
- ec = boot_ec;
- ret = acpi_config_boot_ec(ec, ec->handle, true, false);
+ boot_ec_is_ecdt = is_ecdt;
+ if (!is_ecdt) {
+ /*
+ * Trust PNP0C09 namespace location rather than
+ * ECDT ID. But trust ECDT GPE rather than _GPE
+ * because of ASUS quirks, so do not change
+ * boot_ec->gpe to ec->gpe.
+ */
+ boot_ec->handle = ec->handle;
+ acpi_handle_debug(ec->handle, "duplicated.\n");
+ acpi_ec_free(ec);
+ ec = boot_ec;
+ }
+ ret = acpi_config_boot_ec(ec, ec->handle, true, is_ecdt);
} else
ret = acpi_ec_setup(ec, true);
if (ret)
@@ -1635,8 +1644,10 @@ static int acpi_ec_add(struct acpi_devic
ret = !!request_region(ec->command_addr, 1, "EC cmd");
WARN(!ret, "Could not request EC cmd io port 0x%lx", ec->command_addr);
- /* Reprobe devices depending on the EC */
- acpi_walk_dep_device_list(ec->handle);
+ if (!is_ecdt) {
+ /* Reprobe devices depending on the EC */
+ acpi_walk_dep_device_list(ec->handle);
+ }
acpi_handle_debug(ec->handle, "enumerated.\n");
return 0;
@@ -1692,6 +1703,7 @@ ec_parse_io_ports(struct acpi_resource *
static const struct acpi_device_id ec_device_ids[] = {
{"PNP0C09", 0},
+ {ACPI_ECDT_HID, 0},
{"", 0},
};
@@ -1764,11 +1776,14 @@ static int __init acpi_ec_ecdt_start(voi
* Note: ec->handle can be valid if this function is called after
* acpi_ec_add(), hence the fast path.
*/
- if (boot_ec->handle != ACPI_ROOT_OBJECT)
- handle = boot_ec->handle;
- else if (!acpi_ec_ecdt_get_handle(&handle))
- return -ENODEV;
- return acpi_config_boot_ec(boot_ec, handle, true, true);
+ if (boot_ec->handle == ACPI_ROOT_OBJECT) {
+ if (!acpi_ec_ecdt_get_handle(&handle))
+ return -ENODEV;
+ boot_ec->handle = handle;
+ }
+
+ /* Register to ACPI bus with PM ops attached */
+ return acpi_bus_register_early_device(ACPI_BUS_TYPE_ECDT_EC);
}
#if 0
@@ -2020,6 +2035,12 @@ int __init acpi_ec_init(void)
/* Drivers must be started after acpi_ec_query_init() */
dsdt_fail = acpi_bus_register_driver(&acpi_ec_driver);
+ /*
+ * Register ECDT to ACPI bus only when PNP0C09 probe fails. This is
+ * useful for platforms (confirmed on ASUS X550ZE) with valid ECDT
+ * settings but invalid DSDT settings.
+ * https://bugzilla.kernel.org/show_bug.cgi?id=196847
+ */
ecdt_fail = acpi_ec_ecdt_start();
return ecdt_fail && dsdt_fail ? -ENODEV : 0;
}
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -115,6 +115,7 @@ bool acpi_device_is_present(const struct
bool acpi_device_is_battery(struct acpi_device *adev);
bool acpi_device_is_first_physical_node(struct acpi_device *adev,
const struct device *dev);
+int acpi_bus_register_early_device(int type);
/* --------------------------------------------------------------------------
Device Matching and Notification
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1024,6 +1024,9 @@ static void acpi_device_get_busid(struct
case ACPI_BUS_TYPE_SLEEP_BUTTON:
strcpy(device->pnp.bus_id, "SLPF");
break;
+ case ACPI_BUS_TYPE_ECDT_EC:
+ strcpy(device->pnp.bus_id, "ECDT");
+ break;
default:
acpi_get_name(device->handle, ACPI_SINGLE_NAME, &buffer);
/* Clean up trailing underscores (if any) */
@@ -1304,6 +1307,9 @@ static void acpi_set_pnp_ids(acpi_handle
case ACPI_BUS_TYPE_SLEEP_BUTTON:
acpi_add_id(pnp, ACPI_BUTTON_HID_SLEEPF);
break;
+ case ACPI_BUS_TYPE_ECDT_EC:
+ acpi_add_id(pnp, ACPI_ECDT_HID);
+ break;
}
}
@@ -2049,6 +2055,21 @@ void acpi_bus_trim(struct acpi_device *a
}
EXPORT_SYMBOL_GPL(acpi_bus_trim);
+int acpi_bus_register_early_device(int type)
+{
+ struct acpi_device *device = NULL;
+ int result;
+
+ result = acpi_add_single_object(&device, NULL,
+ type, ACPI_STA_DEFAULT);
+ if (result)
+ return result;
+
+ device->flags.match_driver = true;
+ return device_attach(&device->dev);
+}
+EXPORT_SYMBOL_GPL(acpi_bus_register_early_device);
+
static int acpi_bus_scan_fixed(void)
{
int result = 0;
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -105,6 +105,7 @@ enum acpi_bus_device_type {
ACPI_BUS_TYPE_THERMAL,
ACPI_BUS_TYPE_POWER_BUTTON,
ACPI_BUS_TYPE_SLEEP_BUTTON,
+ ACPI_BUS_TYPE_ECDT_EC,
ACPI_BUS_DEVICE_TYPE_COUNT
};
--- a/include/acpi/acpi_drivers.h
+++ b/include/acpi/acpi_drivers.h
@@ -58,6 +58,7 @@
#define ACPI_VIDEO_HID "LNXVIDEO"
#define ACPI_BAY_HID "LNXIOBAY"
#define ACPI_DOCK_HID "LNXDOCK"
+#define ACPI_ECDT_HID "LNXEC"
/* Quirk for broken IBM BIOSes */
#define ACPI_SMBUS_IBM_HID "SMBUSIBM"
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 50/95] eeprom: at24: fix reading from 24MAC402/24MAC602
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (42 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 49/95] ACPI / EC: Fix regression related to PM ops support in ECDT device Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 51/95] eeprom: at24: correctly set the size for at24mac402 Greg Kroah-Hartman
` (32 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Heiner Kallweit, Bartosz Golaszewski
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Heiner Kallweit <hkallweit1@gmail.com>
commit 644a1f19c6c8393d0c4168a5adf79056da6822eb upstream.
Chip datasheet mentions that word addresses other than the actual
start position of the MAC delivers undefined results. So fix this.
Current implementation doesn't work due to this wrong offset.
Fixes: 0b813658c115 ("eeprom: at24: add support for at24mac series")
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/misc/eeprom/at24.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -365,7 +365,8 @@ static ssize_t at24_eeprom_read_mac(stru
memset(msg, 0, sizeof(msg));
msg[0].addr = client->addr;
msg[0].buf = addrbuf;
- addrbuf[0] = 0x90 + offset;
+ /* EUI-48 starts from 0x9a, EUI-64 from 0x98 */
+ addrbuf[0] = 0xa0 - at24->chip.byte_len + offset;
msg[0].len = 1;
msg[1].addr = client->addr;
msg[1].flags = I2C_M_RD;
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 51/95] eeprom: at24: correctly set the size for at24mac402
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (43 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 50/95] eeprom: at24: fix reading from 24MAC402/24MAC602 Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 52/95] eeprom: at24: check at24_read/write arguments Greg Kroah-Hartman
` (31 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Bartosz Golaszewski, Andy Shevchenko
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bartosz Golaszewski <brgl@bgdev.pl>
commit 5478e478eee3b096b8d998d4ed445da30da2dfbc upstream.
There's an ilog2() expansion in AT24_DEVICE_MAGIC() which rounds down
the actual size of EUI-48 byte array in at24mac402 eeproms to 4 from 6,
making it impossible to read it all.
Fix it by manually adjusting the value in probe().
This patch contains a temporary fix that is suitable for stable
branches. Eventually we'll probably remove the call to ilog2() while
converting the magic values to actual structs.
Fixes: 0b813658c115 ("eeprom: at24: add support for at24mac series")
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/misc/eeprom/at24.c | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -632,6 +632,16 @@ static int at24_probe(struct i2c_client
dev_warn(&client->dev,
"page_size looks suspicious (no power of 2)!\n");
+ /*
+ * REVISIT: the size of the EUI-48 byte array is 6 in at24mac402, while
+ * the call to ilog2() in AT24_DEVICE_MAGIC() rounds it down to 4.
+ *
+ * Eventually we'll get rid of the magic values altoghether in favor of
+ * real structs, but for now just manually set the right size.
+ */
+ if (chip.flags & AT24_FLAG_MAC && chip.byte_len == 4)
+ chip.byte_len = 6;
+
/* Use I2C operations unless we're stuck with SMBus extensions. */
if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
if (chip.flags & AT24_FLAG_ADDR16)
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 52/95] eeprom: at24: check at24_read/write arguments
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (44 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 51/95] eeprom: at24: correctly set the size for at24mac402 Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 53/95] i2c: i801: Fix Failed to allocate irq -2147483648 error Greg Kroah-Hartman
` (30 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Heiner Kallweit, Bartosz Golaszewski
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Heiner Kallweit <hkallweit1@gmail.com>
commit d9bcd462daf34aebb8de9ad7f76de0198bb5a0f0 upstream.
So far we completely rely on the caller to provide valid arguments.
To be on the safe side perform an own sanity check.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/misc/eeprom/at24.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -507,6 +507,9 @@ static int at24_read(void *priv, unsigne
if (unlikely(!count))
return count;
+ if (off + count > at24->chip.byte_len)
+ return -EINVAL;
+
/*
* Read data from chip, protecting against concurrent updates
* from this host, but not from other I2C masters.
@@ -539,6 +542,9 @@ static int at24_write(void *priv, unsign
if (unlikely(!count))
return -EINVAL;
+ if (off + count > at24->chip.byte_len)
+ return -EINVAL;
+
/*
* Write data to chip, protecting against concurrent updates
* from this host, but not from other I2C masters.
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 53/95] i2c: i801: Fix Failed to allocate irq -2147483648 error
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (45 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 52/95] eeprom: at24: check at24_read/write arguments Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 54/95] cxl: Check if vphb exists before iterating over AFU devices Greg Kroah-Hartman
` (29 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Hans de Goede, Jean Delvare, Wolfram Sang
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <hdegoede@redhat.com>
commit 6e0c9507bf51e1517a80ad0ac171e5402528fcef upstream.
On Apollo Lake devices the BIOS does not set up IRQ routing for the i801
SMBUS controller IRQ, so we end up with dev->irq set to IRQ_NOTCONNECTED.
Detect this and do not try to use the irq in this case silencing:
i801_smbus 0000:00:1f.1: Failed to allocate irq -2147483648: -107
BugLink: https://communities.intel.com/thread/114759
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/i2c/busses/i2c-i801.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -1617,6 +1617,9 @@ static int i801_probe(struct pci_dev *de
/* Default timeout in interrupt mode: 200 ms */
priv->adapter.timeout = HZ / 5;
+ if (dev->irq == IRQ_NOTCONNECTED)
+ priv->features &= ~FEATURE_IRQ;
+
if (priv->features & FEATURE_IRQ) {
u16 pcictl, pcists;
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 54/95] cxl: Check if vphb exists before iterating over AFU devices
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (46 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 53/95] i2c: i801: Fix Failed to allocate irq -2147483648 error Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 55/95] bcache: Fix building error on MIPS Greg Kroah-Hartman
` (28 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Vaibhav Jain, Andrew Donnellan,
Frederic Barrat, Michael Ellerman
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
commit 12841f87b7a8ceb3d54f171660f72a86941bfcb3 upstream.
During an eeh a kernel-oops is reported if no vPHB is allocated to the
AFU. This happens as during AFU init, an error in creation of vPHB is
a non-fatal error. Hence afu->phb should always be checked for NULL
before iterating over it for the virtual AFU pci devices.
This patch fixes the kenel-oops by adding a NULL pointer check for
afu->phb before it is dereferenced.
Fixes: 9e8df8a21963 ("cxl: EEH support")
Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Acked-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/misc/cxl/pci.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
--- a/drivers/misc/cxl/pci.c
+++ b/drivers/misc/cxl/pci.c
@@ -2043,6 +2043,9 @@ static pci_ers_result_t cxl_vphb_error_d
/* There should only be one entry, but go through the list
* anyway
*/
+ if (afu->phb == NULL)
+ return result;
+
list_for_each_entry(afu_dev, &afu->phb->bus->devices, bus_list) {
if (!afu_dev->driver)
continue;
@@ -2084,8 +2087,7 @@ static pci_ers_result_t cxl_pci_error_de
* Tell the AFU drivers; but we don't care what they
* say, we're going away.
*/
- if (afu->phb != NULL)
- cxl_vphb_error_detected(afu, state);
+ cxl_vphb_error_detected(afu, state);
}
return PCI_ERS_RESULT_DISCONNECT;
}
@@ -2225,6 +2227,9 @@ static pci_ers_result_t cxl_pci_slot_res
if (cxl_afu_select_best_mode(afu))
goto err;
+ if (afu->phb == NULL)
+ continue;
+
list_for_each_entry(afu_dev, &afu->phb->bus->devices, bus_list) {
/* Reset the device context.
* TODO: make this less disruptive
@@ -2287,6 +2292,9 @@ static void cxl_pci_resume(struct pci_de
for (i = 0; i < adapter->slices; i++) {
afu = adapter->afu[i];
+ if (afu->phb == NULL)
+ continue;
+
list_for_each_entry(afu_dev, &afu->phb->bus->devices, bus_list) {
if (afu_dev->driver && afu_dev->driver->err_handler &&
afu_dev->driver->err_handler->resume)
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 55/95] bcache: Fix building error on MIPS
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (47 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 54/95] cxl: Check if vphb exists before iterating over AFU devices Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 56/95] bcache: only permit to recovery read error when cache device is clean Greg Kroah-Hartman
` (27 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Huacai Chen, Michael Lyle, Jens Axboe
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Huacai Chen <chenhc@lemote.com>
commit cf33c1ee5254c6a430bc1538232b49c3ea13e613 upstream.
This patch try to fix the building error on MIPS. The reason is MIPS
has already defined the PTR macro, which conflicts with the PTR macro
in include/uapi/linux/bcache.h.
[fixed by mlyle: corrected a line-length issue]
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Reviewed-by: Michael Lyle <mlyle@lyle.org>
Signed-off-by: Michael Lyle <mlyle@lyle.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/bcache/alloc.c | 2 +-
drivers/md/bcache/extents.c | 2 +-
drivers/md/bcache/journal.c | 2 +-
include/uapi/linux/bcache.h | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/md/bcache/alloc.c
+++ b/drivers/md/bcache/alloc.c
@@ -480,7 +480,7 @@ int __bch_bucket_alloc_set(struct cache_
if (b == -1)
goto err;
- k->ptr[i] = PTR(ca->buckets[b].gen,
+ k->ptr[i] = MAKE_PTR(ca->buckets[b].gen,
bucket_to_sector(c, b),
ca->sb.nr_this_dev);
--- a/drivers/md/bcache/extents.c
+++ b/drivers/md/bcache/extents.c
@@ -585,7 +585,7 @@ static bool bch_extent_merge(struct btre
return false;
for (i = 0; i < KEY_PTRS(l); i++)
- if (l->ptr[i] + PTR(0, KEY_SIZE(l), 0) != r->ptr[i] ||
+ if (l->ptr[i] + MAKE_PTR(0, KEY_SIZE(l), 0) != r->ptr[i] ||
PTR_BUCKET_NR(b->c, l, i) != PTR_BUCKET_NR(b->c, r, i))
return false;
--- a/drivers/md/bcache/journal.c
+++ b/drivers/md/bcache/journal.c
@@ -507,7 +507,7 @@ static void journal_reclaim(struct cache
continue;
ja->cur_idx = next;
- k->ptr[n++] = PTR(0,
+ k->ptr[n++] = MAKE_PTR(0,
bucket_to_sector(c, ca->sb.d[ja->cur_idx]),
ca->sb.nr_this_dev);
}
--- a/include/uapi/linux/bcache.h
+++ b/include/uapi/linux/bcache.h
@@ -91,7 +91,7 @@ PTR_FIELD(PTR_GEN, 0, 8)
#define PTR_CHECK_DEV ((1 << PTR_DEV_BITS) - 1)
-#define PTR(gen, offset, dev) \
+#define MAKE_PTR(gen, offset, dev) \
((((__u64) dev) << 51) | ((__u64) offset) << 8 | gen)
/* Bkey utility code */
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 56/95] bcache: only permit to recovery read error when cache device is clean
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (48 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 55/95] bcache: Fix building error on MIPS Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 57/95] bcache: recover data from backing when data " Greg Kroah-Hartman
` (26 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Coly Li, Michael Lyle, Arne Wolf,
Kent Overstreet, Nix, Kai Krakow, Eric Wheeler, Junhui Tang,
Jens Axboe
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Coly Li <colyli@suse.de>
commit d59b23795933678c9638fd20c942d2b4f3cd6185 upstream.
When bcache does read I/Os, for example in writeback or writethrough mode,
if a read request on cache device is failed, bcache will try to recovery
the request by reading from cached device. If the data on cached device is
not synced with cache device, then requester will get a stale data.
For critical storage system like database, providing stale data from
recovery may result an application level data corruption, which is
unacceptible.
With this patch, for a failed read request in writeback or writethrough
mode, recovery a recoverable read request only happens when cache device
is clean. That is to say, all data on cached device is up to update.
For other cache modes in bcache, read request will never hit
cached_dev_read_error(), they don't need this patch.
Please note, because cache mode can be switched arbitrarily in run time, a
writethrough mode might be switched from a writeback mode. Therefore
checking dc->has_data in writethrough mode still makes sense.
Changelog:
V4: Fix parens error pointed by Michael Lyle.
v3: By response from Kent Oversteet, he thinks recovering stale data is a
bug to fix, and option to permit it is unnecessary. So this version
the sysfs file is removed.
v2: rename sysfs entry from allow_stale_data_on_failure to
allow_stale_data_on_failure, and fix the confusing commit log.
v1: initial patch posted.
[small change to patch comment spelling by mlyle]
Signed-off-by: Coly Li <colyli@suse.de>
Signed-off-by: Michael Lyle <mlyle@lyle.org>
Reported-by: Arne Wolf <awolf@lenovo.com>
Reviewed-by: Michael Lyle <mlyle@lyle.org>
Cc: Kent Overstreet <kent.overstreet@gmail.com>
Cc: Nix <nix@esperi.org.uk>
Cc: Kai Krakow <hurikhan77@gmail.com>
Cc: Eric Wheeler <bcache@lists.ewheeler.net>
Cc: Junhui Tang <tang.junhui@zte.com.cn>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/bcache/request.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
--- a/drivers/md/bcache/request.c
+++ b/drivers/md/bcache/request.c
@@ -698,8 +698,16 @@ static void cached_dev_read_error(struct
{
struct search *s = container_of(cl, struct search, cl);
struct bio *bio = &s->bio.bio;
+ struct cached_dev *dc = container_of(s->d, struct cached_dev, disk);
- if (s->recoverable) {
+ /*
+ * If cache device is dirty (dc->has_dirty is non-zero), then
+ * recovery a failed read request from cached device may get a
+ * stale data back. So read failure recovery is only permitted
+ * when cache device is clean.
+ */
+ if (s->recoverable &&
+ (dc && !atomic_read(&dc->has_dirty))) {
/* Retry from the backing device: */
trace_bcache_read_retry(s->orig_bio);
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 57/95] bcache: recover data from backing when data is clean
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (49 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 56/95] bcache: only permit to recovery read error when cache device is clean Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 58/95] hwmon: (jc42) optionally try to disable the SMBUS timeout Greg Kroah-Hartman
` (25 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Hua Rui, Michael Lyle, Coly Li, Jens Axboe
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rui Hua <huarui.dev@gmail.com>
commit e393aa2446150536929140739f09c6ecbcbea7f0 upstream.
When we send a read request and hit the clean data in cache device, there
is a situation called cache read race in bcache(see the commit in the tail
of cache_look_up(), the following explaination just copy from there):
The bucket we're reading from might be reused while our bio is in flight,
and we could then end up reading the wrong data. We guard against this
by checking (in bch_cache_read_endio()) if the pointer is stale again;
if so, we treat it as an error (s->iop.error = -EINTR) and reread from
the backing device (but we don't pass that error up anywhere)
It should be noted that cache read race happened under normal
circumstances, not the circumstance when SSD failed, it was counted
and shown in /sys/fs/bcache/XXX/internal/cache_read_races.
Without this patch, when we use writeback mode, we will never reread from
the backing device when cache read race happened, until the whole cache
device is clean, because the condition
(s->recoverable && (dc && !atomic_read(&dc->has_dirty))) is false in
cached_dev_read_error(). In this situation, the s->iop.error(= -EINTR)
will be passed up, at last, user will receive -EINTR when it's bio end,
this is not suitable, and wield to up-application.
In this patch, we use s->read_dirty_data to judge whether the read
request hit dirty data in cache device, it is safe to reread data from
the backing device when the read request hit clean data. This can not
only handle cache read race, but also recover data when failed read
request from cache device.
[edited by mlyle to fix up whitespace, commit log title, comment
spelling]
Fixes: d59b23795933 ("bcache: only permit to recovery read error when cache device is clean")
Signed-off-by: Hua Rui <huarui.dev@gmail.com>
Reviewed-by: Michael Lyle <mlyle@lyle.org>
Reviewed-by: Coly Li <colyli@suse.de>
Signed-off-by: Michael Lyle <mlyle@lyle.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/bcache/request.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
--- a/drivers/md/bcache/request.c
+++ b/drivers/md/bcache/request.c
@@ -698,16 +698,15 @@ static void cached_dev_read_error(struct
{
struct search *s = container_of(cl, struct search, cl);
struct bio *bio = &s->bio.bio;
- struct cached_dev *dc = container_of(s->d, struct cached_dev, disk);
/*
- * If cache device is dirty (dc->has_dirty is non-zero), then
- * recovery a failed read request from cached device may get a
- * stale data back. So read failure recovery is only permitted
- * when cache device is clean.
+ * If read request hit dirty data (s->read_dirty_data is true),
+ * then recovery a failed read request from cached device may
+ * get a stale data back. So read failure recovery is only
+ * permitted when read request hit clean data in cache device,
+ * or when cache read race happened.
*/
- if (s->recoverable &&
- (dc && !atomic_read(&dc->has_dirty))) {
+ if (s->recoverable && !s->read_dirty_data) {
/* Retry from the backing device: */
trace_bcache_read_retry(s->orig_bio);
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 58/95] hwmon: (jc42) optionally try to disable the SMBUS timeout
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (50 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 57/95] bcache: recover data from backing when data " Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 59/95] nvme-pci: add quirk for delay before CHK RDY for WDC SN200 Greg Kroah-Hartman
` (24 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Peter Rosin, Rob Herring, Guenter Roeck
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Rosin <peda@axentia.se>
commit 68615eb01f82256c19e41967bfb3eef902f77033 upstream.
With a nxp,se97 chip on an atmel sama5d31 board, the I2C adapter driver
is not always capable of avoiding the 25-35 ms timeout as specified by
the SMBUS protocol. This may cause silent corruption of the last bit of
any transfer, e.g. a one is read instead of a zero if the sensor chip
times out. This also affects the eeprom half of the nxp-se97 chip, where
this silent corruption was originally noticed. Other I2C adapters probably
suffer similar issues, e.g. bit-banging comes to mind as risky...
The SMBUS register in the nxp chip is not a standard Jedec register, but
it is not special to the nxp chips either, at least the atmel chips
have the same mechanism. Therefore, do not special case this on the
manufacturer, it is opt-in via the device property anyway.
Signed-off-by: Peter Rosin <peda@axentia.se>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Documentation/devicetree/bindings/hwmon/jc42.txt | 4 ++++
drivers/hwmon/jc42.c | 21 +++++++++++++++++++++
2 files changed, 25 insertions(+)
--- a/Documentation/devicetree/bindings/hwmon/jc42.txt
+++ b/Documentation/devicetree/bindings/hwmon/jc42.txt
@@ -34,6 +34,10 @@ Required properties:
- reg: I2C address
+Optional properties:
+- smbus-timeout-disable: When set, the smbus timeout function will be disabled.
+ This is not supported on all chips.
+
Example:
temp-sensor@1a {
--- a/drivers/hwmon/jc42.c
+++ b/drivers/hwmon/jc42.c
@@ -22,6 +22,7 @@
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
+#include <linux/bitops.h>
#include <linux/module.h>
#include <linux/init.h>
#include <linux/slab.h>
@@ -45,6 +46,7 @@ static const unsigned short normal_i2c[]
#define JC42_REG_TEMP 0x05
#define JC42_REG_MANID 0x06
#define JC42_REG_DEVICEID 0x07
+#define JC42_REG_SMBUS 0x22 /* NXP and Atmel, possibly others? */
/* Status bits in temperature register */
#define JC42_ALARM_CRIT_BIT 15
@@ -75,6 +77,9 @@ static const unsigned short normal_i2c[]
#define GT_MANID 0x1c68 /* Giantec */
#define GT_MANID2 0x132d /* Giantec, 2nd mfg ID */
+/* SMBUS register */
+#define SMBUS_STMOUT BIT(7) /* SMBus time-out, active low */
+
/* Supported chips */
/* Analog Devices */
@@ -495,6 +500,22 @@ static int jc42_probe(struct i2c_client
data->extended = !!(cap & JC42_CAP_RANGE);
+ if (device_property_read_bool(dev, "smbus-timeout-disable")) {
+ int smbus;
+
+ /*
+ * Not all chips support this register, but from a
+ * quick read of various datasheets no chip appears
+ * incompatible with the below attempt to disable
+ * the timeout. And the whole thing is opt-in...
+ */
+ smbus = i2c_smbus_read_word_swapped(client, JC42_REG_SMBUS);
+ if (smbus < 0)
+ return smbus;
+ i2c_smbus_write_word_swapped(client, JC42_REG_SMBUS,
+ smbus | SMBUS_STMOUT);
+ }
+
config = i2c_smbus_read_word_swapped(client, JC42_REG_CONFIG);
if (config < 0)
return config;
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 59/95] nvme-pci: add quirk for delay before CHK RDY for WDC SN200
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (51 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 58/95] hwmon: (jc42) optionally try to disable the SMBUS timeout Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 63/95] drm/amdgpu: correct reference clock value on vega10 Greg Kroah-Hartman
` (23 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jeff Lien, Christoph Hellwig
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jeff Lien <jeff.lien@wdc.com>
commit 8c97eeccf0ad8783c057830119467b877bdfced7 upstream.
And increase the existing delay to cover this device as well.
Signed-off-by: Jeff Lien <jeff.lien@wdc.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/nvme/host/nvme.h | 2 +-
drivers/nvme/host/pci.c | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/nvme/host/nvme.h
+++ b/drivers/nvme/host/nvme.h
@@ -108,7 +108,7 @@ static inline struct nvme_request *nvme_
* NVME_QUIRK_DELAY_BEFORE_CHK_RDY quirk enabled. The value (in ms) was
* found empirically.
*/
-#define NVME_QUIRK_DELAY_AMOUNT 2000
+#define NVME_QUIRK_DELAY_AMOUNT 2300
enum nvme_ctrl_state {
NVME_CTRL_NEW,
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -2519,6 +2519,8 @@ static const struct pci_device_id nvme_i
.driver_data = NVME_QUIRK_IDENTIFY_CNS, },
{ PCI_DEVICE(0x1c58, 0x0003), /* HGST adapter */
.driver_data = NVME_QUIRK_DELAY_BEFORE_CHK_RDY, },
+ { PCI_DEVICE(0x1c58, 0x0023), /* WDC SN200 adapter */
+ .driver_data = NVME_QUIRK_DELAY_BEFORE_CHK_RDY, },
{ PCI_DEVICE(0x1c5f, 0x0540), /* Memblaze Pblaze4 adapter */
.driver_data = NVME_QUIRK_DELAY_BEFORE_CHK_RDY, },
{ PCI_DEVICE(0x144d, 0xa821), /* Samsung PM1725 */
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 63/95] drm/amdgpu: correct reference clock value on vega10
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (52 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 59/95] nvme-pci: add quirk for delay before CHK RDY for WDC SN200 Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 65/95] drm/amdgpu: Properly allocate VM invalidate eng v2 Greg Kroah-Hartman
` (22 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Ken Wang, Alex Deucher
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ken Wang <Ken.Wang@amd.com>
commit 76d6172b6fab16455af4b67bb18a3f66011592f8 upstream.
Old value from bringup was wrong.
Signed-off-by: Ken Wang <Ken.Wang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/soc15.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
--- a/drivers/gpu/drm/amd/amdgpu/soc15.c
+++ b/drivers/gpu/drm/amd/amdgpu/soc15.c
@@ -279,10 +279,7 @@ static void soc15_init_golden_registers(
}
static u32 soc15_get_xclk(struct amdgpu_device *adev)
{
- if (adev->asic_type == CHIP_VEGA10)
- return adev->clock.spll.reference_freq/4;
- else
- return adev->clock.spll.reference_freq;
+ return adev->clock.spll.reference_freq;
}
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 65/95] drm/amdgpu: Properly allocate VM invalidate eng v2
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (53 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 63/95] drm/amdgpu: correct reference clock value on vega10 Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 66/95] drm/amdgpu: Remove check which is not valid for certain VBIOS Greg Kroah-Hartman
` (21 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Oak Zeng, Alex Deucher, Christian Konig
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: ozeng <oak.zeng@amd.com>
commit c5066129af4436ab0da8eefe4289774a5409706d upstream.
v1: Properly allocate TLB invalidation engine to avoid conflict.
v2: Added comments to codes
Signed-off-by: Oak Zeng <Oak.Zeng@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Christian Konig <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -395,7 +395,16 @@ static int gmc_v9_0_early_init(void *han
static int gmc_v9_0_late_init(void *handle)
{
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
- unsigned vm_inv_eng[AMDGPU_MAX_VMHUBS] = { 3, 3 };
+ /*
+ * The latest engine allocation on gfx9 is:
+ * Engine 0, 1: idle
+ * Engine 2, 3: firmware
+ * Engine 4~13: amdgpu ring, subject to change when ring number changes
+ * Engine 14~15: idle
+ * Engine 16: kfd tlb invalidation
+ * Engine 17: Gart flushes
+ */
+ unsigned vm_inv_eng[AMDGPU_MAX_VMHUBS] = { 4, 4 };
unsigned i;
for(i = 0; i < adev->num_rings; ++i) {
@@ -408,9 +417,9 @@ static int gmc_v9_0_late_init(void *hand
ring->funcs->vmhub);
}
- /* Engine 17 is used for GART flushes */
+ /* Engine 16 is used for KFD and 17 for GART flushes */
for(i = 0; i < AMDGPU_MAX_VMHUBS; ++i)
- BUG_ON(vm_inv_eng[i] > 17);
+ BUG_ON(vm_inv_eng[i] > 16);
return amdgpu_irq_get(adev, &adev->mc.vm_fault, 0);
}
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 66/95] drm/amdgpu: Remove check which is not valid for certain VBIOS
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (54 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 65/95] drm/amdgpu: Properly allocate VM invalidate eng v2 Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 73/95] drm/tilcdc: Precalculate total frametime in tilcdc_crtc_set_mode() Greg Kroah-Hartman
` (20 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Ken Wang, Alex Deucher
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ken Wang <Ken.Wang@amd.com>
commit ab6613b7eaefe85dadfc86025e901c55d71c0379 upstream.
Fixes vbios fetching on certain headless boards.
Signed-off-by: Ken Wang <Ken.Wang@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 6 ------
1 file changed, 6 deletions(-)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
@@ -59,12 +59,6 @@ static bool check_atom_bios(uint8_t *bio
return false;
}
- tmp = bios[0x18] | (bios[0x19] << 8);
- if (bios[tmp + 0x14] != 0x0) {
- DRM_INFO("Not an x86 BIOS ROM\n");
- return false;
- }
-
bios_header_start = bios[0x48] | (bios[0x49] << 8);
if (!bios_header_start) {
DRM_INFO("Can't locate bios header\n");
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 73/95] drm/tilcdc: Precalculate total frametime in tilcdc_crtc_set_mode()
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (55 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 66/95] drm/amdgpu: Remove check which is not valid for certain VBIOS Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 74/95] drm/radeon: fix atombios on big endian Greg Kroah-Hartman
` (19 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Kevin Hao, Jyri Sarha, Tomi Valkeinen
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jyri Sarha <jsarha@ti.com>
commit ce99f7206c9105851d97202ed08c058af6f11ac4 upstream.
We need the total frame refresh time to check if we are too close to
vertical sync when updating the two framebuffer DMA registers and risk
a collision. This new method is more accurate that the previous that
based on mode's vrefresh value, which itself is inaccurate or may not
even be initialized.
Reported-by: Kevin Hao <kexin.hao@windriver.com>
Fixes: 11abbc9f39e0 ("drm/tilcdc: Set framebuffer DMA address to HW only if CRTC is enabled")
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -24,6 +24,7 @@
#include <linux/completion.h>
#include <linux/dma-mapping.h>
#include <linux/of_graph.h>
+#include <linux/math64.h>
#include "tilcdc_drv.h"
#include "tilcdc_regs.h"
@@ -48,6 +49,7 @@ struct tilcdc_crtc {
unsigned int lcd_fck_rate;
ktime_t last_vblank;
+ unsigned int hvtotal_us;
struct drm_framebuffer *curr_fb;
struct drm_framebuffer *next_fb;
@@ -292,6 +294,12 @@ static void tilcdc_crtc_set_clk(struct d
LCDC_V2_CORE_CLK_EN);
}
+uint tilcdc_mode_hvtotal(const struct drm_display_mode *mode)
+{
+ return (uint) div_u64(1000llu * mode->htotal * mode->vtotal,
+ mode->clock);
+}
+
static void tilcdc_crtc_set_mode(struct drm_crtc *crtc)
{
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
@@ -459,6 +467,9 @@ static void tilcdc_crtc_set_mode(struct
drm_framebuffer_reference(fb);
crtc->hwmode = crtc->state->adjusted_mode;
+
+ tilcdc_crtc->hvtotal_us =
+ tilcdc_mode_hvtotal(&crtc->hwmode);
}
static void tilcdc_crtc_enable(struct drm_crtc *crtc)
@@ -648,7 +659,7 @@ int tilcdc_crtc_update_fb(struct drm_crt
spin_lock_irqsave(&tilcdc_crtc->irq_lock, flags);
next_vblank = ktime_add_us(tilcdc_crtc->last_vblank,
- 1000000 / crtc->hwmode.vrefresh);
+ tilcdc_crtc->hvtotal_us);
tdiff = ktime_to_us(ktime_sub(next_vblank, ktime_get()));
if (tdiff < TILCDC_VBLANK_SAFETY_THRESHOLD_US)
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 74/95] drm/radeon: fix atombios on big endian
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (56 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 73/95] drm/tilcdc: Precalculate total frametime in tilcdc_crtc_set_mode() Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 75/95] drm/panel: simple: Add missing panel_simple_unprepare() calls Greg Kroah-Hartman
` (18 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Roman Kapl, Alex Deucher
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Roman Kapl <rka@sysgo.com>
commit 4f626a4ac8f57ddabf06d03870adab91e463217f upstream.
The function for byteswapping the data send to/from atombios was buggy for
num_bytes not divisible by four. The function must be aware of the fact
that after byte-swapping the u32 units, valid bytes might end up after the
num_bytes boundary.
This patch was tested on kernel 3.12 and allowed us to sucesfully use
DisplayPort on and Radeon SI card. Namely it fixed the link training and
EDID readout.
The function is patched both in radeon and amd drivers, since the functions
and the fixes are identical.
Signed-off-by: Roman Kapl <rka@sysgo.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 38 ++++++++++++---------------
drivers/gpu/drm/radeon/atombios_dp.c | 38 ++++++++++++---------------
2 files changed, 36 insertions(+), 40 deletions(-)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
@@ -1766,34 +1766,32 @@ bool amdgpu_atombios_scratch_need_asic_i
return true;
}
-/* Atom needs data in little endian format
- * so swap as appropriate when copying data to
- * or from atom. Note that atom operates on
- * dw units.
+/* Atom needs data in little endian format so swap as appropriate when copying
+ * data to or from atom. Note that atom operates on dw units.
+ *
+ * Use to_le=true when sending data to atom and provide at least
+ * ALIGN(num_bytes,4) bytes in the dst buffer.
+ *
+ * Use to_le=false when receiving data from atom and provide ALIGN(num_bytes,4)
+ * byes in the src buffer.
*/
void amdgpu_atombios_copy_swap(u8 *dst, u8 *src, u8 num_bytes, bool to_le)
{
#ifdef __BIG_ENDIAN
- u8 src_tmp[20], dst_tmp[20]; /* used for byteswapping */
- u32 *dst32, *src32;
+ u32 src_tmp[5], dst_tmp[5];
int i;
+ u8 align_num_bytes = ALIGN(num_bytes, 4);
- memcpy(src_tmp, src, num_bytes);
- src32 = (u32 *)src_tmp;
- dst32 = (u32 *)dst_tmp;
if (to_le) {
- for (i = 0; i < ((num_bytes + 3) / 4); i++)
- dst32[i] = cpu_to_le32(src32[i]);
- memcpy(dst, dst_tmp, num_bytes);
+ memcpy(src_tmp, src, num_bytes);
+ for (i = 0; i < align_num_bytes / 4; i++)
+ dst_tmp[i] = cpu_to_le32(src_tmp[i]);
+ memcpy(dst, dst_tmp, align_num_bytes);
} else {
- u8 dws = num_bytes & ~3;
- for (i = 0; i < ((num_bytes + 3) / 4); i++)
- dst32[i] = le32_to_cpu(src32[i]);
- memcpy(dst, dst_tmp, dws);
- if (num_bytes % 4) {
- for (i = 0; i < (num_bytes % 4); i++)
- dst[dws+i] = dst_tmp[dws+i];
- }
+ memcpy(src_tmp, src, align_num_bytes);
+ for (i = 0; i < align_num_bytes / 4; i++)
+ dst_tmp[i] = le32_to_cpu(src_tmp[i]);
+ memcpy(dst, dst_tmp, num_bytes);
}
#else
memcpy(dst, src, num_bytes);
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -45,34 +45,32 @@ static char *pre_emph_names[] = {
/***** radeon AUX functions *****/
-/* Atom needs data in little endian format
- * so swap as appropriate when copying data to
- * or from atom. Note that atom operates on
- * dw units.
+/* Atom needs data in little endian format so swap as appropriate when copying
+ * data to or from atom. Note that atom operates on dw units.
+ *
+ * Use to_le=true when sending data to atom and provide at least
+ * ALIGN(num_bytes,4) bytes in the dst buffer.
+ *
+ * Use to_le=false when receiving data from atom and provide ALIGN(num_bytes,4)
+ * byes in the src buffer.
*/
void radeon_atom_copy_swap(u8 *dst, u8 *src, u8 num_bytes, bool to_le)
{
#ifdef __BIG_ENDIAN
- u8 src_tmp[20], dst_tmp[20]; /* used for byteswapping */
- u32 *dst32, *src32;
+ u32 src_tmp[5], dst_tmp[5];
int i;
+ u8 align_num_bytes = ALIGN(num_bytes, 4);
- memcpy(src_tmp, src, num_bytes);
- src32 = (u32 *)src_tmp;
- dst32 = (u32 *)dst_tmp;
if (to_le) {
- for (i = 0; i < ((num_bytes + 3) / 4); i++)
- dst32[i] = cpu_to_le32(src32[i]);
- memcpy(dst, dst_tmp, num_bytes);
+ memcpy(src_tmp, src, num_bytes);
+ for (i = 0; i < align_num_bytes / 4; i++)
+ dst_tmp[i] = cpu_to_le32(src_tmp[i]);
+ memcpy(dst, dst_tmp, align_num_bytes);
} else {
- u8 dws = num_bytes & ~3;
- for (i = 0; i < ((num_bytes + 3) / 4); i++)
- dst32[i] = le32_to_cpu(src32[i]);
- memcpy(dst, dst_tmp, dws);
- if (num_bytes % 4) {
- for (i = 0; i < (num_bytes % 4); i++)
- dst[dws+i] = dst_tmp[dws+i];
- }
+ memcpy(src_tmp, src, align_num_bytes);
+ for (i = 0; i < align_num_bytes / 4; i++)
+ dst_tmp[i] = le32_to_cpu(src_tmp[i]);
+ memcpy(dst, dst_tmp, num_bytes);
}
#else
memcpy(dst, src, num_bytes);
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 75/95] drm/panel: simple: Add missing panel_simple_unprepare() calls
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (57 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 74/95] drm/radeon: fix atombios on big endian Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 76/95] drm/hisilicon: Ensure LDI regs are properly configured Greg Kroah-Hartman
` (17 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jonathan Liu, Thierry Reding
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jonathan Liu <net147@gmail.com>
commit f3621a8eb59a913612c8e6e37d81f16b649f8b6c upstream.
During panel removal or system shutdown panel_simple_disable() is called
which disables the panel backlight but the panel is still powered due to
missing calls to panel_simple_unprepare().
Fixes: d02fd93e2cd8 ("drm/panel: simple - Disable panel on shutdown")
Signed-off-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170807115545.27747-1-net147@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/panel/panel-simple.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -369,6 +369,7 @@ static int panel_simple_remove(struct de
drm_panel_remove(&panel->base);
panel_simple_disable(&panel->base);
+ panel_simple_unprepare(&panel->base);
if (panel->ddc)
put_device(&panel->ddc->dev);
@@ -384,6 +385,7 @@ static void panel_simple_shutdown(struct
struct panel_simple *panel = dev_get_drvdata(dev);
panel_simple_disable(&panel->base);
+ panel_simple_unprepare(&panel->base);
}
static const struct drm_display_mode ampire_am_480272h3tmqw_t01h_mode = {
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 76/95] drm/hisilicon: Ensure LDI regs are properly configured.
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (58 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 75/95] drm/panel: simple: Add missing panel_simple_unprepare() calls Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 78/95] drm/amd/pp: fix typecast error in powerplay Greg Kroah-Hartman
` (16 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Peter Griffin, John Stultz, Xinliang Liu
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Griffin <peter.griffin@linaro.org>
commit a2f042430784d86eb2b7a6d2a869f552da30edba upstream.
This patch fixes the following soft lockup:
BUG: soft lockup - CPU#0 stuck for 23s! [weston:307]
On weston idle-timeout the IP is powered down and reset
asserted. On weston resume we get a massive vblank
IRQ storm due to the LDI registers having lost some state.
This state loss is caused by ade_crtc_atomic_begin() not
calling ade_ldi_set_mode(). With this patch applied
resuming from Weston idle-timeout works well.
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Tested-by: John Stultz <john.stultz@linaro.org>
Reviewed-by: Xinliang Liu <xinliang.liu@linaro.org>
Signed-off-by: Xinliang Liu <xinliang.liu@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -534,9 +534,12 @@ static void ade_crtc_atomic_begin(struct
{
struct ade_crtc *acrtc = to_ade_crtc(crtc);
struct ade_hw_ctx *ctx = acrtc->ctx;
+ struct drm_display_mode *mode = &crtc->state->mode;
+ struct drm_display_mode *adj_mode = &crtc->state->adjusted_mode;
if (!ctx->power_on)
(void)ade_power_up(ctx);
+ ade_ldi_set_mode(acrtc, mode, adj_mode);
}
static void ade_crtc_atomic_flush(struct drm_crtc *crtc,
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 78/95] drm/amd/pp: fix typecast error in powerplay.
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (59 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 76/95] drm/hisilicon: Ensure LDI regs are properly configured Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 79/95] drm/fb_helper: Disable all crtcs when initial setup fails Greg Kroah-Hartman
` (15 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Alex Deucher, Rex Zhu
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rex Zhu <Rex.Zhu@amd.com>
commit 8d8258bdab735d9f3c4b78e091ecfbb2b2b1f2ca upstream.
resulted in unexpected data truncation
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c
@@ -850,9 +850,9 @@ static int init_over_drive_limits(
const ATOM_Tonga_POWERPLAYTABLE *powerplay_table)
{
hwmgr->platform_descriptor.overdriveLimit.engineClock =
- le16_to_cpu(powerplay_table->ulMaxODEngineClock);
+ le32_to_cpu(powerplay_table->ulMaxODEngineClock);
hwmgr->platform_descriptor.overdriveLimit.memoryClock =
- le16_to_cpu(powerplay_table->ulMaxODMemoryClock);
+ le32_to_cpu(powerplay_table->ulMaxODMemoryClock);
hwmgr->platform_descriptor.minOverdriveVDDC = 0;
hwmgr->platform_descriptor.maxOverdriveVDDC = 0;
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 79/95] drm/fb_helper: Disable all crtcs when initial setup fails.
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (60 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 78/95] drm/amd/pp: fix typecast error in powerplay Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 80/95] drm/fsl-dcu: Dont set connector DPMS property Greg Kroah-Hartman
` (14 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Maarten Lankhorst, Thomas Voegtle,
Daniel Vetter
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
commit 52dd06506e9bbc2a37b352df7dfc5468f8da21fd upstream.
Some drivers like i915 start with crtc's enabled, but with deferred
fbcon setup they were no longer disabled as part of fbdev setup.
Headless units could no longer enter pc3 state because the crtc was
still enabled.
Fix this by calling restore_fbdev_mode when we would have called
it otherwise once during initial fbdev setup.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: ca91a2758fce ("drm/fb-helper: Support deferred setup")
Reported-by: Thomas Voegtle <tv@lio96.de>
Tested-by: Thomas Voegtle <tv@lio96.de>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171128111603.62757-1-maarten.lankhorst@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/drm_fb_helper.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1809,6 +1809,10 @@ static int drm_fb_helper_single_fb_probe
if (crtc_count == 0 || sizes.fb_width == -1 || sizes.fb_height == -1) {
DRM_INFO("Cannot find any crtc or sizes\n");
+
+ /* First time: disable all crtc's.. */
+ if (!fb_helper->deferred_setup && !READ_ONCE(fb_helper->dev->master))
+ restore_fbdev_mode(fb_helper);
return -EAGAIN;
}
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 80/95] drm/fsl-dcu: Dont set connector DPMS property
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (61 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 79/95] drm/fb_helper: Disable all crtcs when initial setup fails Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 84/95] include/linux/compiler-clang.h: handle randomizable anonymous structs Greg Kroah-Hartman
` (13 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Laurent Pinchart, Stefan Agner
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
commit daee54263c1202cbdab85c5e15ae30b417602efb upstream.
Since commit 4a97a3da420b ("drm: Don't update property values for atomic
drivers") atomic drivers must not update property values as properties
are read from the state instead. To catch remaining users, the
drm_object_property_set_value() function now throws a warning when
called by atomic drivers on non-immutable properties, and we hit that
warning when creating connectors.
The easy fix is to just remove the drm_object_property_set_value() as it
is used here to set the initial value of the connector's DPMS property
to OFF. The DPMS property applies on top of the connector's state crtc
pointer (initialized to NULL) that is the main connector on/off control,
and should thus default to ON.
Fixes: 4a97a3da420b ("drm: Don't update property values for atomic drivers")
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 5 -----
1 file changed, 5 deletions(-)
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
@@ -102,7 +102,6 @@ static int fsl_dcu_attach_panel(struct f
{
struct drm_encoder *encoder = &fsl_dev->encoder;
struct drm_connector *connector = &fsl_dev->connector.base;
- struct drm_mode_config *mode_config = &fsl_dev->drm->mode_config;
int ret;
fsl_dev->connector.encoder = encoder;
@@ -122,10 +121,6 @@ static int fsl_dcu_attach_panel(struct f
if (ret < 0)
goto err_sysfs;
- drm_object_property_set_value(&connector->base,
- mode_config->dpms_property,
- DRM_MODE_DPMS_OFF);
-
ret = drm_panel_attach(panel, connector);
if (ret) {
dev_err(fsl_dev->dev, "failed to attach panel\n");
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 84/95] include/linux/compiler-clang.h: handle randomizable anonymous structs
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (62 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 80/95] drm/fsl-dcu: Dont set connector DPMS property Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 85/95] IB/core: Do not warn on lid conversions for OPA Greg Kroah-Hartman
` (12 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sandipan Das, David Rientjes,
Kate Stewart, Thomas Gleixner, Naveen N. Rao, Alexei Starovoitov,
Andrew Morton, Linus Torvalds
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sandipan Das <sandipan@linux.vnet.ibm.com>
commit 4ca59b14e588f873795a11cdc77a25c686a29d23 upstream.
The GCC randomize layout plugin can randomize the member offsets of
sensitive kernel data structures. To use this feature, certain
annotations and members are added to the structures which affect the
member offsets even if this plugin is not used.
All of these structures are completely randomized, except for task_struct
which leaves out some of its members. All the other members are wrapped
within an anonymous struct with the __randomize_layout attribute. This is
done using the randomized_struct_fields_start and
randomized_struct_fields_end defines.
When the plugin is disabled, the behaviour of this attribute can vary
based on the GCC version. For GCC 5.1+, this attribute maps to
__designated_init otherwise it is just an empty define but the anonymous
structure is still present. For other compilers, both
randomized_struct_fields_start and randomized_struct_fields_end default
to empty defines meaning the anonymous structure is not introduced at
all.
So, if a module compiled with Clang, such as a BPF program, needs to
access task_struct fields such as pid and comm, the offsets of these
members as recognized by Clang are different from those recognized by
modules compiled with GCC. If GCC 4.6+ is used to build the kernel,
this can be solved by introducing appropriate defines for Clang so that
the anonymous structure is seen when determining the offsets for the
members.
Link: http://lkml.kernel.org/r/20171109064645.25581-1-sandipan@linux.vnet.ibm.com
Signed-off-by: Sandipan Das <sandipan@linux.vnet.ibm.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Kate Stewart <kstewart@linuxfoundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Cc: Alexei Starovoitov <ast@fb.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/linux/compiler-clang.h | 3 +++
1 file changed, 3 insertions(+)
--- a/include/linux/compiler-clang.h
+++ b/include/linux/compiler-clang.h
@@ -16,3 +16,6 @@
* with any version that can compile the kernel
*/
#define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
+
+#define randomized_struct_fields_start struct {
+#define randomized_struct_fields_end };
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 85/95] IB/core: Do not warn on lid conversions for OPA
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (63 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 84/95] include/linux/compiler-clang.h: handle randomizable anonymous structs Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 86/95] IB/hfi1: " Greg Kroah-Hartman
` (11 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Mike Marciniszyn, Don Hiatt,
Dennis Dalessandro, Leon Romanovsky, Doug Ledford
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Don Hiatt <don.hiatt@intel.com>
commit 6588e412fe872ed81f3fb8d9b4561a66ecb763d0 upstream.
On OPA devices the user_mad recv_handler can receive 32Bit LIDs
(e.g. OPA_PERMISSIVE_LID) and it is okay to lose the upper 16 bits
of the LID as this information is obtained elsewhere. Do not issue
a warning when calling ib_lid_be16() in this case by masking out
the upper 16Bits.
[75667.310846] ------------[ cut here ]------------
[75667.316447] WARNING: CPU: 0 PID: 1718 at ./include/rdma/ib_verbs.h:3799 recv_handler+0x15a/0x170 [ib_umad]
[75667.327640] Modules linked in: ib_ipoib hfi1(E) rdmavt(E) rdma_ucm(E) ib_ucm(E) rdma_cm(E) ib_cm(E) iw_cm(E) ib_umad(E) ib_uverbs(E) ib_core(E) libiscsi scsi_transport_iscsi dm_mirror dm_region_hash dm_log dm_mod dax x86_pkg_temp_thermal intel_powerclamp coretemp kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel mei_me ipmi_si iTCO_wdt iTCO_vendor_support crypto_simd ipmi_devintf pcspkr mei sg i2c_i801 glue_helper lpc_ich shpchp ioatdma mfd_core wmi ipmi_msghandler cryptd acpi_power_meter acpi_pad nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c sd_mod mgag200 drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm igb ptp ahci libahci pps_core crc32c_intel libata dca i2c_algo_bit i2c_core [last unloaded: ib_core]
[75667.407704] CPU: 0 PID: 1718 Comm: kworker/0:1H Tainted: G W I E 4.13.0-rc7+ #1
[75667.417310] Hardware name: Intel Corporation S2600WT2/S2600WT2, BIOS SE5C610.86B.01.01.0008.021120151325 02/11/2015
[75667.429555] Workqueue: ib-comp-wq ib_cq_poll_work [ib_core]
[75667.436360] task: ffff88084a718000 task.stack: ffffc9000a424000
[75667.443549] RIP: 0010:recv_handler+0x15a/0x170 [ib_umad]
[75667.450090] RSP: 0018:ffffc9000a427ce8 EFLAGS: 00010286
[75667.456508] RAX: 00000000ffffffff RBX: ffff88085159ce80 RCX: 0000000000000000
[75667.465094] RDX: ffff88085a47b068 RSI: 0000000000000000 RDI: ffff88085159cf00
[75667.473668] RBP: ffffc9000a427d38 R08: 000000000001efc0 R09: ffff88085159ce80
[75667.482228] R10: ffff88085f007480 R11: ffff88084acf20e8 R12: ffff88085a47b020
[75667.490824] R13: ffff881056842e10 R14: ffff881056840200 R15: ffff88104c8d0800
[75667.499390] FS: 0000000000000000(0000) GS:ffff88085f400000(0000) knlGS:0000000000000000
[75667.509028] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[75667.516080] CR2: 00007f9e4b3d9000 CR3: 0000000001c09000 CR4: 00000000001406f0
[75667.524664] Call Trace:
[75667.528044] ? find_mad_agent+0x7c/0x1b0 [ib_core]
[75667.534031] ? ib_mark_mad_done+0x73/0xa0 [ib_core]
[75667.540142] ib_mad_recv_done+0x423/0x9b0 [ib_core]
[75667.546215] __ib_process_cq+0x5d/0xb0 [ib_core]
[75667.552007] ib_cq_poll_work+0x20/0x60 [ib_core]
[75667.557766] process_one_work+0x149/0x360
[75667.562844] worker_thread+0x4d/0x3c0
[75667.567529] kthread+0x109/0x140
[75667.571713] ? rescuer_thread+0x380/0x380
[75667.576775] ? kthread_park+0x60/0x60
[75667.581447] ret_from_fork+0x25/0x30
[75667.586014] Code: 43 4a 0f b6 45 c6 88 43 4b 48 8b 45 b0 48 89 43 4c 48 8b 45 b8 48 89 43 54 8b 45 c0 0f c8 89 43 5c e9 79 ff ff ff e8 16 4e fa e0 <0f> ff e9 42 ff ff ff 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00
[75667.608323] ---[ end trace cf26df27c9597264 ]---
Fixes: 62ede7779904 ("Add OPA extended LID support")
Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Don Hiatt <don.hiatt@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/core/user_mad.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
--- a/drivers/infiniband/core/user_mad.c
+++ b/drivers/infiniband/core/user_mad.c
@@ -229,7 +229,16 @@ static void recv_handler(struct ib_mad_a
packet->mad.hdr.status = 0;
packet->mad.hdr.length = hdr_size(file) + mad_recv_wc->mad_len;
packet->mad.hdr.qpn = cpu_to_be32(mad_recv_wc->wc->src_qp);
- packet->mad.hdr.lid = ib_lid_be16(mad_recv_wc->wc->slid);
+ /*
+ * On OPA devices it is okay to lose the upper 16 bits of LID as this
+ * information is obtained elsewhere. Mask off the upper 16 bits.
+ */
+ if (agent->device->port_immutable[agent->port_num].core_cap_flags &
+ RDMA_CORE_PORT_INTEL_OPA)
+ packet->mad.hdr.lid = ib_lid_be16(0xFFFF &
+ mad_recv_wc->wc->slid);
+ else
+ packet->mad.hdr.lid = ib_lid_be16(mad_recv_wc->wc->slid);
packet->mad.hdr.sl = mad_recv_wc->wc->sl;
packet->mad.hdr.path_bits = mad_recv_wc->wc->dlid_path_bits;
packet->mad.hdr.pkey_index = mad_recv_wc->wc->pkey_index;
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 86/95] IB/hfi1: Do not warn on lid conversions for OPA
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (64 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 85/95] IB/core: Do not warn on lid conversions for OPA Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 87/95] e1000e: fix the use of magic numbers for buffer overrun issue Greg Kroah-Hartman
` (10 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Mike Marciniszyn, Don Hiatt,
Dennis Dalessandro, Leon Romanovsky, Doug Ledford
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Don Hiatt <don.hiatt@intel.com>
commit 4988be5813ff2afdc0d8bfa315ef34a577d3efbf upstream.
On OPA devices opa_local_smp_check will receive 32Bit LIDs when the LID
is Extended. In such cases, it is okay to lose the upper 16 bits of the
LID as this information is obtained elsewhere. Do not issue a warning
when calling ib_lid_cpu16() in this case by masking out the upper 16Bits.
[75920.148985] ------------[ cut here ]------------
[75920.154651] WARNING: CPU: 0 PID: 1718 at ./include/rdma/ib_verbs.h:3788 hfi1_process_mad+0x1c1f/0x1c80 [hfi1]
[75920.166192] Modules linked in: ib_ipoib hfi1(E) rdmavt(E) rdma_ucm(E) ib_ucm(E) rdma_cm(E) ib_cm(E) iw_cm(E) ib_umad(E) ib_uverbs(E) ib_core(E) libiscsi scsi_transport_iscsi dm_mirror dm_region_hash dm_log dm_mod dax x86_pkg_temp_thermal intel_powerclamp coretemp kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel mei_me ipmi_si iTCO_wdt iTCO_vendor_support crypto_simd ipmi_devintf pcspkr mei sg i2c_i801 glue_helper lpc_ich shpchp ioatdma mfd_core wmi ipmi_msghandler cryptd acpi_power_meter acpi_pad nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c sd_mod mgag200 drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm igb ptp ahci libahci pps_core crc32c_intel libata dca i2c_algo_bit i2c_core [last unloaded: ib_core]
[75920.246331] CPU: 0 PID: 1718 Comm: kworker/0:1H Tainted: G W I E 4.13.0-rc7+ #1
[75920.255907] Hardware name: Intel Corporation S2600WT2/S2600WT2, BIOS SE5C610.86B.01.01.0008.021120151325 02/11/2015
[75920.268158] Workqueue: ib-comp-wq ib_cq_poll_work [ib_core]
[75920.274934] task: ffff88084a718000 task.stack: ffffc9000a424000
[75920.282123] RIP: 0010:hfi1_process_mad+0x1c1f/0x1c80 [hfi1]
[75920.288881] RSP: 0018:ffffc9000a427c38 EFLAGS: 00010206
[75920.295265] RAX: 0000000000010001 RBX: ffff8808361420e8 RCX: ffff880837811d80
[75920.303784] RDX: 0000000000000002 RSI: 0000000000007fff RDI: ffff880837811d80
[75920.312302] RBP: ffffc9000a427d38 R08: 0000000000000000 R09: ffff8808361420e8
[75920.320819] R10: ffff88083841f0e8 R11: ffffc9000a427da8 R12: 0000000000000001
[75920.329335] R13: ffff880837810000 R14: 0000000000000000 R15: ffff88084f1a4800
[75920.337849] FS: 0000000000000000(0000) GS:ffff88085f400000(0000) knlGS:0000000000000000
[75920.347450] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[75920.354405] CR2: 00007f9e4b3d9000 CR3: 0000000001c09000 CR4: 00000000001406f0
[75920.362947] Call Trace:
[75920.366257] ? ib_mad_recv_done+0x258/0x9b0 [ib_core]
[75920.372457] ? ib_mad_recv_done+0x258/0x9b0 [ib_core]
[75920.378652] ? __kmalloc+0x1df/0x210
[75920.383229] ib_mad_recv_done+0x305/0x9b0 [ib_core]
[75920.389270] __ib_process_cq+0x5d/0xb0 [ib_core]
[75920.395032] ib_cq_poll_work+0x20/0x60 [ib_core]
[75920.400777] process_one_work+0x149/0x360
[75920.405836] worker_thread+0x4d/0x3c0
[75920.410505] kthread+0x109/0x140
[75920.414681] ? rescuer_thread+0x380/0x380
[75920.419731] ? kthread_park+0x60/0x60
[75920.424406] ret_from_fork+0x25/0x30
[75920.428972] Code: 4c 89 9d 58 ff ff ff 49 89 45 00 66 b8 00 02 49 89 45 08 e8 44 27 89 e0 4c 8b 9d 58 ff ff ff e9 d8 f6 ff ff 0f ff e9 55 e7 ff ff <0f> ff e9 3b e5 ff ff 0f ff 0f 1f 84 00 00 00 00 00 e9 4b e9 ff
[75921.451269] ---[ end trace cf26df27c9597265 ]---
Fixes: 62ede7779904 ("Add OPA extended LID support")
Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Don Hiatt <don.hiatt@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/hw/hfi1/mad.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/infiniband/hw/hfi1/mad.c
+++ b/drivers/infiniband/hw/hfi1/mad.c
@@ -4293,7 +4293,6 @@ static int opa_local_smp_check(struct hf
const struct ib_wc *in_wc)
{
struct hfi1_pportdata *ppd = ppd_from_ibp(ibp);
- u16 slid = ib_lid_cpu16(in_wc->slid);
u16 pkey;
if (in_wc->pkey_index >= ARRAY_SIZE(ppd->pkeys))
@@ -4320,7 +4319,11 @@ static int opa_local_smp_check(struct hf
*/
if (pkey == LIM_MGMT_P_KEY || pkey == FULL_MGMT_P_KEY)
return 0;
- ingress_pkey_table_fail(ppd, pkey, slid);
+ /*
+ * On OPA devices it is okay to lose the upper 16 bits of LID as this
+ * information is obtained elsewhere. Mask off the upper 16 bits.
+ */
+ ingress_pkey_table_fail(ppd, pkey, ib_lid_cpu16(0xFFFF & in_wc->slid));
return 1;
}
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 87/95] e1000e: fix the use of magic numbers for buffer overrun issue
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (65 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 86/95] IB/hfi1: " Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 88/95] md: forbid a RAID5 from having both a bitmap and a journal Greg Kroah-Hartman
` (9 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sasha Neftin, Alexander H Duyck,
Dima Ruinskiy, Raanan Avargil, Aaron Brown, Jeff Kirsher
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sasha Neftin <sasha.neftin@intel.com>
commit c0f4b163a03e73055dd734eaca64b9580e72e7fb upstream.
This is a follow on to commit b10effb92e27 ("fix buffer overrun while the
I219 is processing DMA transactions") to address David Laights concerns
about the use of "magic" numbers. So define masks as well as add
additional code comments to give a better understanding of what needs to
be done to avoid a buffer overrun.
Signed-off-by: Sasha Neftin <sasha.neftin@intel.com>
Reviewed-by: Alexander H Duyck <alexander.h.duyck@intel.com>
Reviewed-by: Dima Ruinskiy <dima.ruinskiy@intel.com>
Reviewed-by: Raanan Avargil <raanan.avargil@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/intel/e1000e/ich8lan.h | 3 ++-
drivers/net/ethernet/intel/e1000e/netdev.c | 9 ++++++---
2 files changed, 8 insertions(+), 4 deletions(-)
--- a/drivers/net/ethernet/intel/e1000e/ich8lan.h
+++ b/drivers/net/ethernet/intel/e1000e/ich8lan.h
@@ -113,7 +113,8 @@
#define NVM_SIZE_MULTIPLIER 4096 /*multiplier for NVMS field */
#define E1000_FLASH_BASE_ADDR 0xE000 /*offset of NVM access regs */
#define E1000_CTRL_EXT_NVMVS 0x3 /*NVM valid sector */
-#define E1000_TARC0_CB_MULTIQ_3_REQ (1 << 28 | 1 << 29)
+#define E1000_TARC0_CB_MULTIQ_3_REQ 0x30000000
+#define E1000_TARC0_CB_MULTIQ_2_REQ 0x20000000
#define PCIE_ICH8_SNOOP_ALL PCIE_NO_SNOOP_ALL
#define E1000_ICH_RAR_ENTRIES 7
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -3030,9 +3030,12 @@ static void e1000_configure_tx(struct e1
ew32(IOSFPC, reg_val);
reg_val = er32(TARC(0));
- /* SPT and KBL Si errata workaround to avoid Tx hang */
- reg_val &= ~BIT(28);
- reg_val |= BIT(29);
+ /* SPT and KBL Si errata workaround to avoid Tx hang.
+ * Dropping the number of outstanding requests from
+ * 3 to 2 in order to avoid a buffer overrun.
+ */
+ reg_val &= ~E1000_TARC0_CB_MULTIQ_3_REQ;
+ reg_val |= E1000_TARC0_CB_MULTIQ_2_REQ;
ew32(TARC(0), reg_val);
}
}
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 88/95] md: forbid a RAID5 from having both a bitmap and a journal.
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (66 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 87/95] e1000e: fix the use of magic numbers for buffer overrun issue Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 89/95] drm/i915: Fix false-positive assert_rpm_wakelock_held in i915_pmic_bus_access_notifier v2 Greg Kroah-Hartman
` (8 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, NeilBrown, Joshua Kinard, Shaohua Li
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: NeilBrown <neilb@suse.com>
commit 230b55fa8d64007339319539f8f8e68114d08529 upstream.
Having both a bitmap and a journal is pointless.
Attempting to do so can corrupt the bitmap if the journal
replay happens before the bitmap is initialized.
Rather than try to avoid this corruption, simply
refuse to allow arrays with both a bitmap and a journal.
So:
- if raid5_run sees both are present, fail.
- if adding a bitmap finds a journal is present, fail
- if adding a journal finds a bitmap is present, fail.
Signed-off-by: NeilBrown <neilb@suse.com>
Tested-by: Joshua Kinard <kumba@gentoo.org>
Acked-by: Joshua Kinard <kumba@gentoo.org>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/bitmap.c | 6 ++++++
drivers/md/md.c | 2 +-
drivers/md/raid5.c | 7 +++++++
3 files changed, 14 insertions(+), 1 deletion(-)
--- a/drivers/md/bitmap.c
+++ b/drivers/md/bitmap.c
@@ -1816,6 +1816,12 @@ struct bitmap *bitmap_create(struct mdde
BUG_ON(file && mddev->bitmap_info.offset);
+ if (test_bit(MD_HAS_JOURNAL, &mddev->flags)) {
+ pr_notice("md/raid:%s: array with journal cannot have bitmap\n",
+ mdname(mddev));
+ return ERR_PTR(-EBUSY);
+ }
+
bitmap = kzalloc(sizeof(*bitmap), GFP_KERNEL);
if (!bitmap)
return ERR_PTR(-ENOMEM);
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -6362,7 +6362,7 @@ static int add_new_disk(struct mddev *md
break;
}
}
- if (has_journal) {
+ if (has_journal || mddev->bitmap) {
export_rdev(rdev);
return -EBUSY;
}
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -7156,6 +7156,13 @@ static int raid5_run(struct mddev *mddev
min_offset_diff = diff;
}
+ if ((test_bit(MD_HAS_JOURNAL, &mddev->flags) || journal_dev) &&
+ (mddev->bitmap_info.offset || mddev->bitmap_info.file)) {
+ pr_notice("md/raid:%s: array cannot have both journal and bitmap\n",
+ mdname(mddev));
+ return -EINVAL;
+ }
+
if (mddev->reshape_position != MaxSector) {
/* Check that we can continue the reshape.
* Difficulties arise if the stripe we would write to
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 89/95] drm/i915: Fix false-positive assert_rpm_wakelock_held in i915_pmic_bus_access_notifier v2
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (67 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 88/95] md: forbid a RAID5 from having both a bitmap and a journal Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 90/95] drm/i915: Re-register PMIC bus access notifier on runtime resume Greg Kroah-Hartman
` (7 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, FKr, Imre Deak, Hans de Goede, Jani Nikula
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <j.w.r.degoede@gmail.com>
commit f4359cedfb43b934f38c50d1604db21333abe57b upstream.
assert_rpm_wakelock_held is triggered from i915_pmic_bus_access_notifier
even though it gets unregistered on (runtime) suspend, this is caused
by a race happening under the following circumstances:
intel_runtime_pm_put does:
atomic_dec(&dev_priv->pm.wakeref_count);
pm_runtime_mark_last_busy(kdev);
pm_runtime_put_autosuspend(kdev);
And pm_runtime_put_autosuspend calls intel_runtime_suspend from
a workqueue, so there is ample of time between the atomic_dec() and
intel_runtime_suspend() unregistering the notifier. If the notifier
gets called in this windowd assert_rpm_wakelock_held falsely triggers
(at this point we're not runtime-suspended yet).
This commit adds disable_rpm_wakeref_asserts and
enable_rpm_wakeref_asserts calls around the
intel_uncore_forcewake_get(FORCEWAKE_ALL) call in
i915_pmic_bus_access_notifier fixing the false-positive WARN_ON.
Changes in v2:
-Reword comment explaining why disabling the wakeref asserts is
ok and necessary
Reported-by: FKr <bugs-freedesktop@ubermail.me>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110150301.9601-2-hdegoede@redhat.com
(cherry picked from commit ce30560c80dead91e98a03d90fb8791e57a9b69d)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/intel_uncore.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1171,8 +1171,15 @@ static int i915_pmic_bus_access_notifier
* bus, which will be busy after this notification, leading to:
* "render: timed out waiting for forcewake ack request."
* errors.
+ *
+ * The notifier is unregistered during intel_runtime_suspend(),
+ * so it's ok to access the HW here without holding a RPM
+ * wake reference -> disable wakeref asserts for the time of
+ * the access.
*/
+ disable_rpm_wakeref_asserts(dev_priv);
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
+ enable_rpm_wakeref_asserts(dev_priv);
break;
case MBI_PMIC_BUS_ACCESS_END:
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 90/95] drm/i915: Re-register PMIC bus access notifier on runtime resume
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (68 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 89/95] drm/i915: Fix false-positive assert_rpm_wakelock_held in i915_pmic_bus_access_notifier v2 Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 91/95] drm/i915/fbdev: Serialise early hotplug events with async fbdev config Greg Kroah-Hartman
` (6 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Imre Deak, Hans de Goede, Jani Nikula
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <j.w.r.degoede@gmail.com>
commit 294cf1af8cf2eb0d1eced377fdfb9a2d3f0e8b42 upstream.
intel_uncore_suspend() unregisters the uncore code's PMIC bus access
notifier and gets called on both normal and runtime suspend.
intel_uncore_resume_early() re-registers the notifier, but only on
normal resume. Add a new intel_uncore_runtime_resume() function which
only re-registers the notifier and call that on runtime resume.
Reported-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114135518.15981-2-hdegoede@redhat.com
(cherry picked from commit bedf4d79c3654921839b62246b0965ddb308b201)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/i915_drv.c | 2 ++
drivers/gpu/drm/i915/intel_uncore.c | 6 ++++++
drivers/gpu/drm/i915/intel_uncore.h | 1 +
3 files changed, 9 insertions(+)
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2591,6 +2591,8 @@ static int intel_runtime_resume(struct d
ret = vlv_resume_prepare(dev_priv, true);
}
+ intel_uncore_runtime_resume(dev_priv);
+
/*
* No point of rolling back things in case of an error, as the best
* we can do is to hope that things will still work (and disable RPM).
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -434,6 +434,12 @@ void intel_uncore_resume_early(struct dr
i915_check_and_clear_faults(dev_priv);
}
+void intel_uncore_runtime_resume(struct drm_i915_private *dev_priv)
+{
+ iosf_mbi_register_pmic_bus_access_notifier(
+ &dev_priv->uncore.pmic_bus_access_nb);
+}
+
void intel_uncore_sanitize(struct drm_i915_private *dev_priv)
{
i915.enable_rc6 = sanitize_rc6_option(dev_priv, i915.enable_rc6);
--- a/drivers/gpu/drm/i915/intel_uncore.h
+++ b/drivers/gpu/drm/i915/intel_uncore.h
@@ -121,6 +121,7 @@ bool intel_uncore_arm_unclaimed_mmio_det
void intel_uncore_fini(struct drm_i915_private *dev_priv);
void intel_uncore_suspend(struct drm_i915_private *dev_priv);
void intel_uncore_resume_early(struct drm_i915_private *dev_priv);
+void intel_uncore_runtime_resume(struct drm_i915_private *dev_priv);
u64 intel_uncore_edram_size(struct drm_i915_private *dev_priv);
void assert_forcewakes_inactive(struct drm_i915_private *dev_priv);
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 91/95] drm/i915/fbdev: Serialise early hotplug events with async fbdev config
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (69 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 90/95] drm/i915: Re-register PMIC bus access notifier on runtime resume Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 92/95] drm/i915/gvt: Correct ADDR_4K/2M/1G_MASK definition Greg Kroah-Hartman
` (5 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Chris Wilson, Lukas Wunner,
Joonas Lahtinen, Daniel Vetter
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chris Wilson <chris@chris-wilson.co.uk>
commit a45b30a6c5db631e2ba680304bd5edd0cd1f9643 upstream.
As both the hotplug event and fbdev configuration run asynchronously, it
is possible for them to run concurrently. If configuration fails, we were
freeing the fbdev causing a use-after-free in the hotplug event.
<7>[ 3069.935211] [drm:intel_fb_initial_config [i915]] Not using firmware configuration
<7>[ 3069.935225] [drm:drm_setup_crtcs] looking for cmdline mode on connector 77
<7>[ 3069.935229] [drm:drm_setup_crtcs] looking for preferred mode on connector 77 0
<7>[ 3069.935233] [drm:drm_setup_crtcs] found mode 3200x1800
<7>[ 3069.935236] [drm:drm_setup_crtcs] picking CRTCs for 8192x8192 config
<7>[ 3069.935253] [drm:drm_setup_crtcs] desired mode 3200x1800 set on crtc 43 (0,0)
<7>[ 3069.935323] [drm:intelfb_create [i915]] no BIOS fb, allocating a new one
<4>[ 3069.967737] general protection fault: 0000 [#1] PREEMPT SMP
<0>[ 3069.977453] ---------------------------------
<4>[ 3069.977457] Modules linked in: i915(+) vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm r8169 mei_me mii prime_numbers mei i2c_hid pinctrl_geminilake pinctrl_intel [last unloaded: i915]
<4>[ 3069.977492] CPU: 1 PID: 15414 Comm: kworker/1:0 Tainted: G U 4.14.0-CI-CI_DRM_3388+ #1
<4>[ 3069.977497] Hardware name: Intel Corp. Geminilake/GLK RVP1 DDR4 (05), BIOS GELKRVPA.X64.0062.B30.1708222146 08/22/2017
<4>[ 3069.977508] Workqueue: events output_poll_execute
<4>[ 3069.977512] task: ffff880177734e40 task.stack: ffffc90001fe4000
<4>[ 3069.977519] RIP: 0010:__lock_acquire+0x109/0x1b60
<4>[ 3069.977523] RSP: 0018:ffffc90001fe7bb0 EFLAGS: 00010002
<4>[ 3069.977526] RAX: 6b6b6b6b6b6b6b6b RBX: 0000000000000282 RCX: 0000000000000000
<4>[ 3069.977530] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880170d4efd0
<4>[ 3069.977534] RBP: ffffc90001fe7c70 R08: 0000000000000001 R09: 0000000000000000
<4>[ 3069.977538] R10: 0000000000000000 R11: ffffffff81899609 R12: ffff880170d4efd0
<4>[ 3069.977542] R13: ffff880177734e40 R14: 0000000000000001 R15: 0000000000000000
<4>[ 3069.977547] FS: 0000000000000000(0000) GS:ffff88017fc80000(0000) knlGS:0000000000000000
<4>[ 3069.977551] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[ 3069.977555] CR2: 00007f7e8b7bcf04 CR3: 0000000003e0f000 CR4: 00000000003406e0
<4>[ 3069.977559] Call Trace:
<4>[ 3069.977565] ? mark_held_locks+0x64/0x90
<4>[ 3069.977571] ? _raw_spin_unlock_irq+0x24/0x50
<4>[ 3069.977575] ? _raw_spin_unlock_irq+0x24/0x50
<4>[ 3069.977579] ? trace_hardirqs_on_caller+0xde/0x1c0
<4>[ 3069.977583] ? _raw_spin_unlock_irq+0x2f/0x50
<4>[ 3069.977588] ? finish_task_switch+0xa5/0x210
<4>[ 3069.977592] ? lock_acquire+0xaf/0x200
<4>[ 3069.977596] lock_acquire+0xaf/0x200
<4>[ 3069.977600] ? __mutex_lock+0x5e9/0x9b0
<4>[ 3069.977604] _raw_spin_lock+0x2a/0x40
<4>[ 3069.977608] ? __mutex_lock+0x5e9/0x9b0
<4>[ 3069.977612] __mutex_lock+0x5e9/0x9b0
<4>[ 3069.977616] ? drm_fb_helper_hotplug_event.part.19+0x16/0xa0
<4>[ 3069.977621] ? drm_fb_helper_hotplug_event.part.19+0x16/0xa0
<4>[ 3069.977625] drm_fb_helper_hotplug_event.part.19+0x16/0xa0
<4>[ 3069.977630] output_poll_execute+0x8d/0x180
<4>[ 3069.977635] process_one_work+0x22e/0x660
<4>[ 3069.977640] worker_thread+0x48/0x3a0
<4>[ 3069.977644] ? _raw_spin_unlock_irqrestore+0x4c/0x60
<4>[ 3069.977649] kthread+0x102/0x140
<4>[ 3069.977653] ? process_one_work+0x660/0x660
<4>[ 3069.977657] ? kthread_create_on_node+0x40/0x40
<4>[ 3069.977662] ret_from_fork+0x27/0x40
<4>[ 3069.977666] Code: 8d 62 f8 c3 49 81 3c 24 e0 fa 3c 82 41 be 00 00 00 00 45 0f 45 f0 83 fe 01 77 86 89 f0 49 8b 44 c4 08 48 85 c0 0f 84 76 ff ff ff <f0> ff 80 38 01 00 00 8b 1d 62 f9 e8 01 45 8b 85 b8 08 00 00 85
<1>[ 3069.977707] RIP: __lock_acquire+0x109/0x1b60 RSP: ffffc90001fe7bb0
<4>[ 3069.977712] ---[ end trace 4ad012eb3af62df7 ]---
In order to keep the dev_priv->ifbdev alive after failure, we have to
avoid the free and leave it empty until we unload the module (which is
less than ideal, but a necessary evil for simplicity). Then we can use
intel_fbdev_sync() to serialise the hotplug event with the configuration.
The serialisation between the two was removed in commit 934458c2c95d
("Revert "drm/i915: Fix races on fbdev""), but the use after free is much
older, commit 366e39b4d2c5 ("drm/i915: Tear down fbdev if initialization
fails")
Fixes: 366e39b4d2c5 ("drm/i915: Tear down fbdev if initialization fails")
Fixes: 934458c2c95d ("Revert "drm/i915: Fix races on fbdev"")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lukas Wunner <lukas@wunner.de>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Lukas Wunner <lukas@wunner.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20171125194155.355-1-chris@chris-wilson.co.uk
(cherry picked from commit ad88d7fc6c032ddfb32b8d496a070ab71de3a64f)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/intel_fbdev.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -694,10 +694,8 @@ static void intel_fbdev_initial_config(v
/* Due to peculiar init order wrt to hpd handling this is separate. */
if (drm_fb_helper_initial_config(&ifbdev->helper,
- ifbdev->preferred_bpp)) {
+ ifbdev->preferred_bpp))
intel_fbdev_unregister(to_i915(ifbdev->helper.dev));
- intel_fbdev_fini(to_i915(ifbdev->helper.dev));
- }
}
void intel_fbdev_initial_config_async(struct drm_device *dev)
@@ -797,7 +795,11 @@ void intel_fbdev_output_poll_changed(str
{
struct intel_fbdev *ifbdev = to_i915(dev)->fbdev;
- if (ifbdev)
+ if (!ifbdev)
+ return;
+
+ intel_fbdev_sync(ifbdev);
+ if (ifbdev->vma)
drm_fb_helper_hotplug_event(&ifbdev->helper);
}
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 92/95] drm/i915/gvt: Correct ADDR_4K/2M/1G_MASK definition
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (70 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 91/95] drm/i915/fbdev: Serialise early hotplug events with async fbdev config Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 16:00 ` [PATCH 4.14 95/95] Revert "x86/entry/64: Add missing irqflags tracing to native_load_gs_index()" Greg Kroah-Hartman
` (4 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Xiong Zhang, Zhenyu Wang
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xiong Zhang <xiong.y.zhang@intel.com>
commit b721b65af4eb46df6a1d9e34b14003225e403565 upstream.
For ADDR_4K_MASK, bit[45..12] should be 1, all other bits
should be 0. The current definition wrongly set bit[46] as 1
also. This path fixes this.
v2: Add commit message, fixes and cc stable.(Zhenyu)
Fixes: 2707e4446688("drm/i915/gvt: vGPU graphics memory virtualization")
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/gvt/gtt.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -311,9 +311,9 @@ static inline int gtt_set_entry64(void *
#define GTT_HAW 46
-#define ADDR_1G_MASK (((1UL << (GTT_HAW - 30 + 1)) - 1) << 30)
-#define ADDR_2M_MASK (((1UL << (GTT_HAW - 21 + 1)) - 1) << 21)
-#define ADDR_4K_MASK (((1UL << (GTT_HAW - 12 + 1)) - 1) << 12)
+#define ADDR_1G_MASK (((1UL << (GTT_HAW - 30)) - 1) << 30)
+#define ADDR_2M_MASK (((1UL << (GTT_HAW - 21)) - 1) << 21)
+#define ADDR_4K_MASK (((1UL << (GTT_HAW - 12)) - 1) << 12)
static unsigned long gen8_gtt_get_pfn(struct intel_gvt_gtt_entry *e)
{
^ permalink raw reply [flat|nested] 90+ messages in thread* [PATCH 4.14 95/95] Revert "x86/entry/64: Add missing irqflags tracing to native_load_gs_index()"
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (71 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 92/95] drm/i915/gvt: Correct ADDR_4K/2M/1G_MASK definition Greg Kroah-Hartman
@ 2017-12-04 16:00 ` Greg Kroah-Hartman
2017-12-04 20:29 ` [PATCH 4.14 00/95] 4.14.4-stable review Shuah Khan
` (3 subsequent siblings)
76 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 16:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Andy Lutomirski, Borislav Petkov,
Brian Gerst, Dave Hansen, Josh Poimboeuf, Linus Torvalds,
Peter Zijlstra, Thomas Gleixner, Ingo Molnar
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
This reverts commit f9a64e23a9da528e7d8aa1bd2c7bb92be4ebb724 which is
commit 0d794d0d018f23fb09c50f6ae26868bd6ae343d6 upstream.
Andy writes:
I think the thing to do is to revert the patch from -stable.
The bug it fixes is very minor, and the regression is that it
made a pre-existing bug in some nearly-undebuggable core resume
code much easier to hit. I don't feel comfortable with a
backport of the latter fix until it has a good long soak in
Linus' tree.
Reported-by: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bpetkov@suse.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/entry/entry_64.S | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -51,19 +51,15 @@ ENTRY(native_usergs_sysret64)
END(native_usergs_sysret64)
#endif /* CONFIG_PARAVIRT */
-.macro TRACE_IRQS_FLAGS flags:req
+.macro TRACE_IRQS_IRETQ
#ifdef CONFIG_TRACE_IRQFLAGS
- bt $9, \flags /* interrupts off? */
+ bt $9, EFLAGS(%rsp) /* interrupts off? */
jnc 1f
TRACE_IRQS_ON
1:
#endif
.endm
-.macro TRACE_IRQS_IRETQ
- TRACE_IRQS_FLAGS EFLAGS(%rsp)
-.endm
-
/*
* When dynamic function tracer is enabled it will add a breakpoint
* to all locations that it is about to modify, sync CPUs, update
@@ -927,13 +923,11 @@ ENTRY(native_load_gs_index)
FRAME_BEGIN
pushfq
DISABLE_INTERRUPTS(CLBR_ANY & ~CLBR_RDI)
- TRACE_IRQS_OFF
SWAPGS
.Lgs_change:
movl %edi, %gs
2: ALTERNATIVE "", "mfence", X86_BUG_SWAPGS_FENCE
SWAPGS
- TRACE_IRQS_FLAGS (%rsp)
popfq
FRAME_END
ret
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: [PATCH 4.14 00/95] 4.14.4-stable review
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (72 preceding siblings ...)
2017-12-04 16:00 ` [PATCH 4.14 95/95] Revert "x86/entry/64: Add missing irqflags tracing to native_load_gs_index()" Greg Kroah-Hartman
@ 2017-12-04 20:29 ` Shuah Khan
2017-12-05 6:25 ` Greg Kroah-Hartman
2017-12-04 21:12 ` Tom Gall
` (2 subsequent siblings)
76 siblings, 1 reply; 90+ messages in thread
From: Shuah Khan @ 2017-12-04 20:29 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, patches, ben.hutchings, lkft-triage,
stable, Shuah Khan
On 12/04/2017 08:59 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.4 release.
> There are 95 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Dec 6 16:00:27 UTC 2017.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: [PATCH 4.14 00/95] 4.14.4-stable review
2017-12-04 20:29 ` [PATCH 4.14 00/95] 4.14.4-stable review Shuah Khan
@ 2017-12-05 6:25 ` Greg Kroah-Hartman
0 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-05 6:25 UTC (permalink / raw)
To: Shuah Khan
Cc: linux-kernel, torvalds, akpm, linux, patches, ben.hutchings,
lkft-triage, stable
On Mon, Dec 04, 2017 at 01:29:42PM -0700, Shuah Khan wrote:
> On 12/04/2017 08:59 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.14.4 release.
> > There are 95 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed Dec 6 16:00:27 UTC 2017.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
>
> Compiled and booted on my test system. No dmesg regressions.
Great, thanks for testing all of these and letting me know.
greg k-h
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH 4.14 00/95] 4.14.4-stable review
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (73 preceding siblings ...)
2017-12-04 20:29 ` [PATCH 4.14 00/95] 4.14.4-stable review Shuah Khan
@ 2017-12-04 21:12 ` Tom Gall
2017-12-05 6:24 ` Greg Kroah-Hartman
2017-12-04 23:46 ` Guenter Roeck
2017-12-05 7:01 ` Naresh Kamboju
76 siblings, 1 reply; 90+ messages in thread
From: Tom Gall @ 2017-12-04 21:12 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, Guenter Roeck, shuahkh, patches,
ben.hutchings, lkft-triage, linux- stable
> On Dec 4, 2017, at 9:59 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 4.14.4 release.
> There are 95 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Dec 6 16:00:27 UTC 2017.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled, booted and ran the following package unit tests without regressions on x86_64
boringssl :
go test target:0/0/5764/5764/5764 PASS
ssl_test : 10 pass
crypto_test : 28 pass
e2fsprogs:
make check : 340 pass
sqlite
make test : 143914 pass
drm
make check : 15 pass
modetest, drmdevice : pass
alsa-lib
make check : 2 pass
bluez
make check : 25 pass
libusb
stress : 4 pass
>
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: [PATCH 4.14 00/95] 4.14.4-stable review
2017-12-04 21:12 ` Tom Gall
@ 2017-12-05 6:24 ` Greg Kroah-Hartman
2017-12-05 21:45 ` Tom Gall
2017-12-06 14:41 ` Sumit Semwal
0 siblings, 2 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-05 6:24 UTC (permalink / raw)
To: Tom Gall
Cc: linux-kernel, torvalds, akpm, Guenter Roeck, shuahkh, patches,
ben.hutchings, lkft-triage, linux- stable
On Mon, Dec 04, 2017 at 03:12:45PM -0600, Tom Gall wrote:
>
>
> > On Dec 4, 2017, at 9:59 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> >
> > This is the start of the stable review cycle for the 4.14.4 release.
> > There are 95 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed Dec 6 16:00:27 UTC 2017.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
>
> Compiled, booted and ran the following package unit tests without regressions on x86_64
>
> boringssl :
> go test target:0/0/5764/5764/5764 PASS
> ssl_test : 10 pass
> crypto_test : 28 pass
> e2fsprogs:
> make check : 340 pass
> sqlite
> make test : 143914 pass
> drm
> make check : 15 pass
> modetest, drmdevice : pass
> alsa-lib
> make check : 2 pass
> bluez
> make check : 25 pass
> libusb
> stress : 4 pass
How do the above tests stress the kernel? Aren't they just
verifications that the source code in the package is correct?
I guess it proves something, but have you ever seen the above regress in
_any_ kernel release?
I know the drm developers have a huge test suite that they use to verify
their kernel changes, why not use that?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH 4.14 00/95] 4.14.4-stable review
2017-12-05 6:24 ` Greg Kroah-Hartman
@ 2017-12-05 21:45 ` Tom Gall
2017-12-06 6:49 ` Greg Kroah-Hartman
2017-12-06 14:41 ` Sumit Semwal
1 sibling, 1 reply; 90+ messages in thread
From: Tom Gall @ 2017-12-05 21:45 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, Guenter Roeck, shuahkh, patches,
ben.hutchings, lkft-triage, linux- stable
> On Dec 5, 2017, at 12:24 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>
> On Mon, Dec 04, 2017 at 03:12:45PM -0600, Tom Gall wrote:
>>
>>
>>> On Dec 4, 2017, at 9:59 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>>>
>>> This is the start of the stable review cycle for the 4.14.4 release.
>>> There are 95 patches in this series, all will be posted as a response
>>> to this one. If anyone has any issues with these being applied, please
>>> let me know.
>>>
>>> Responses should be made by Wed Dec 6 16:00:27 UTC 2017.
>>> Anything received after that time might be too late.
>>>
>>> The whole patch series can be found in one patch at:
>>> kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz
>>> or in the git tree and branch at:
>>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
>>> and the diffstat can be found below.
>>>
>>> thanks,
>>>
>>> greg k-h
>>>
>>
>> Compiled, booted and ran the following package unit tests without regressions on x86_64
>>
>> boringssl :
>> go test target:0/0/5764/5764/5764 PASS
>> ssl_test : 10 pass
>> crypto_test : 28 pass
>> e2fsprogs:
>> make check : 340 pass
>> sqlite
>> make test : 143914 pass
>> drm
>> make check : 15 pass
>> modetest, drmdevice : pass
>> alsa-lib
>> make check : 2 pass
>> bluez
>> make check : 25 pass
>> libusb
>> stress : 4 pass
>
> How do the above tests stress the kernel?
Depends entirely on the package in question.
Sure, of completely no surprise a lot of package unit tests don’t really
do much that’s particularly interesting save to the package itself.
There are sometimes an interesting subset that drives some amount of work in kernel.
That’s the useful stuff.
Take bluez, and it’s use of CONFIG_CRYPTO_USER_API.
> Aren't they just
> verifications that the source code in the package is correct?
So if there’s some useful subset, that’s what I’m looking for.
> I guess it proves something, but have you ever seen the above regress in
> _any_ kernel release?
Past regressions make for a good test.
> I know the drm developers have a huge test suite that they use to verify
> their kernel changes, why not use that?
Good feedback, thanks.
> thanks,
>
> greg k-h
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH 4.14 00/95] 4.14.4-stable review
2017-12-05 21:45 ` Tom Gall
@ 2017-12-06 6:49 ` Greg Kroah-Hartman
2017-12-06 6:51 ` Greg Kroah-Hartman
2017-12-06 18:01 ` Tom Gall
0 siblings, 2 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-06 6:49 UTC (permalink / raw)
To: Tom Gall
Cc: linux-kernel, torvalds, akpm, Guenter Roeck, shuahkh, patches,
ben.hutchings, lkft-triage, linux- stable
On Tue, Dec 05, 2017 at 03:45:07PM -0600, Tom Gall wrote:
>
>
> > On Dec 5, 2017, at 12:24 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> >
> > On Mon, Dec 04, 2017 at 03:12:45PM -0600, Tom Gall wrote:
> >>
> >>
> >>> On Dec 4, 2017, at 9:59 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> >>>
> >>> This is the start of the stable review cycle for the 4.14.4 release.
> >>> There are 95 patches in this series, all will be posted as a response
> >>> to this one. If anyone has any issues with these being applied, please
> >>> let me know.
> >>>
> >>> Responses should be made by Wed Dec 6 16:00:27 UTC 2017.
> >>> Anything received after that time might be too late.
> >>>
> >>> The whole patch series can be found in one patch at:
> >>> kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz
> >>> or in the git tree and branch at:
> >>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
> >>> and the diffstat can be found below.
> >>>
> >>> thanks,
> >>>
> >>> greg k-h
> >>>
> >>
> >> Compiled, booted and ran the following package unit tests without regressions on x86_64
> >>
> >> boringssl :
> >> go test target:0/0/5764/5764/5764 PASS
> >> ssl_test : 10 pass
> >> crypto_test : 28 pass
> >> e2fsprogs:
> >> make check : 340 pass
> >> sqlite
> >> make test : 143914 pass
> >> drm
> >> make check : 15 pass
> >> modetest, drmdevice : pass
> >> alsa-lib
> >> make check : 2 pass
> >> bluez
> >> make check : 25 pass
> >> libusb
> >> stress : 4 pass
> >
> > How do the above tests stress the kernel?
>
> Depends entirely on the package in question.
>
> Sure, of completely no surprise a lot of package unit tests don’t really
> do much that’s particularly interesting save to the package itself.
Then why run those tests? Like sqlite, what kernel functionality does
that exercise that ltp does not?
> There are sometimes an interesting subset that drives some amount of work in kernel.
> That’s the useful stuff.
Is that true with the above list? If so, why are those types of tests
not part of any kernel test suite that I have seen before?
> Take bluez, and it’s use of CONFIG_CRYPTO_USER_API.
Nice, does that cover things that is not in LTP? Should those tests be
added to LTP?
> > Aren't they just
> > verifications that the source code in the package is correct?
>
> So if there’s some useful subset, that’s what I’m looking for.
>
> > I guess it proves something, but have you ever seen the above regress in
> > _any_ kernel release?
>
> Past regressions make for a good test.
You are testing past regressions of the userspace code, not the kernel
here. Why do I care about that? :)
Don't fall down the trap of running code for the sake of running code
(i.e. like that web site that starts with a P) that doesn't actually
test anything that actually matters.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH 4.14 00/95] 4.14.4-stable review
2017-12-06 6:49 ` Greg Kroah-Hartman
@ 2017-12-06 6:51 ` Greg Kroah-Hartman
2017-12-06 18:01 ` Tom Gall
1 sibling, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-06 6:51 UTC (permalink / raw)
To: Tom Gall
Cc: linux-kernel, torvalds, akpm, Guenter Roeck, shuahkh, patches,
ben.hutchings, lkft-triage, linux- stable
On Wed, Dec 06, 2017 at 07:49:49AM +0100, Greg Kroah-Hartman wrote:
> Don't fall down the trap of running code for the sake of running code
> (i.e. like that web site that starts with a P) that doesn't actually
> test anything that actually matters.
I forgot to add:
Especially when there are already so many tests out there that _do_
matter that are not getting run on the stable kernels today.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH 4.14 00/95] 4.14.4-stable review
2017-12-06 6:49 ` Greg Kroah-Hartman
2017-12-06 6:51 ` Greg Kroah-Hartman
@ 2017-12-06 18:01 ` Tom Gall
2017-12-07 7:49 ` Greg Kroah-Hartman
1 sibling, 1 reply; 90+ messages in thread
From: Tom Gall @ 2017-12-06 18:01 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, Guenter Roeck, shuahkh, patches,
ben.hutchings, lkft-triage, linux- stable
> On Dec 6, 2017, at 12:49 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>
> On Tue, Dec 05, 2017 at 03:45:07PM -0600, Tom Gall wrote:
>>
>>
>>> On Dec 5, 2017, at 12:24 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>>>
>>> On Mon, Dec 04, 2017 at 03:12:45PM -0600, Tom Gall wrote:
>>>>
>>>>
>>>>> On Dec 4, 2017, at 9:59 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>>>>>
>>>>> This is the start of the stable review cycle for the 4.14.4 release.
>>>>> There are 95 patches in this series, all will be posted as a response
>>>>> to this one. If anyone has any issues with these being applied, please
>>>>> let me know.
>>>>>
>>>>> Responses should be made by Wed Dec 6 16:00:27 UTC 2017.
>>>>> Anything received after that time might be too late.
>>>>>
>>>>> The whole patch series can be found in one patch at:
>>>>> kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz
>>>>> or in the git tree and branch at:
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
>>>>> and the diffstat can be found below.
>>>>>
>>>>> thanks,
>>>>>
>>>>> greg k-h
>>>>>
>>>>
>>>> Compiled, booted and ran the following package unit tests without regressions on x86_64
>>>>
>>>> boringssl :
>>>> go test target:0/0/5764/5764/5764 PASS
>>>> ssl_test : 10 pass
>>>> crypto_test : 28 pass
>>>> e2fsprogs:
>>>> make check : 340 pass
>>>> sqlite
>>>> make test : 143914 pass
>>>> drm
>>>> make check : 15 pass
>>>> modetest, drmdevice : pass
>>>> alsa-lib
>>>> make check : 2 pass
>>>> bluez
>>>> make check : 25 pass
>>>> libusb
>>>> stress : 4 pass
>>>
>>> How do the above tests stress the kernel?
>>
>> Depends entirely on the package in question.
>>
>> Sure, of completely no surprise a lot of package unit tests don’t really
>> do much that’s particularly interesting save to the package itself.
>
> Then why run those tests? Like sqlite, what kernel functionality does
> that exercise that ltp does not?
Simply it beats on the system.
>> There are sometimes an interesting subset that drives some amount of work in kernel.
>> That’s the useful stuff.
>
> Is that true with the above list? If so, why are those types of tests
> not part of any kernel test suite that I have seen before?
Dunno. Can’t comment on the non-action by others. What we can do is either
harvest (by adding to say LTP) or improve in the
>
>> Take bluez, and it’s use of CONFIG_CRYPTO_USER_API.
>
> Nice, does that cover things that is not in LTP? Should those tests be
> added to LTP?
>
>>> Aren't they just
>>> verifications that the source code in the package is correct?
>>
>> So if there’s some useful subset, that’s what I’m looking for.
>>
>>> I guess it proves something, but have you ever seen the above regress in
>>> _any_ kernel release?
>>
>> Past regressions make for a good test.
>
> You are testing past regressions of the userspace code, not the kernel
> here. Why do I care about that? :)
Like you, I only care things that are testing the kernel. I’m lazy. I’m not
chopping out the things that go far afield, besides it’s not broken nor is it
hurting anything.
> Don't fall down the trap of running code for the sake of running code
> (i.e. like that web site that starts with a P) that doesn't actually
> test anything that actually matters.
Yup entirely agree. No emerge world going on here. 8-b
> thanks,
>
> greg k-h
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH 4.14 00/95] 4.14.4-stable review
2017-12-06 18:01 ` Tom Gall
@ 2017-12-07 7:49 ` Greg Kroah-Hartman
0 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-07 7:49 UTC (permalink / raw)
To: Tom Gall
Cc: linux-kernel, torvalds, akpm, Guenter Roeck, shuahkh, patches,
ben.hutchings, lkft-triage, linux- stable
On Wed, Dec 06, 2017 at 12:01:04PM -0600, Tom Gall wrote:
>
>
> > On Dec 6, 2017, at 12:49 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> >
> > On Tue, Dec 05, 2017 at 03:45:07PM -0600, Tom Gall wrote:
> >>
> >>
> >>> On Dec 5, 2017, at 12:24 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> >>>
> >>> On Mon, Dec 04, 2017 at 03:12:45PM -0600, Tom Gall wrote:
> >>>>
> >>>>
> >>>>> On Dec 4, 2017, at 9:59 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> >>>>>
> >>>>> This is the start of the stable review cycle for the 4.14.4 release.
> >>>>> There are 95 patches in this series, all will be posted as a response
> >>>>> to this one. If anyone has any issues with these being applied, please
> >>>>> let me know.
> >>>>>
> >>>>> Responses should be made by Wed Dec 6 16:00:27 UTC 2017.
> >>>>> Anything received after that time might be too late.
> >>>>>
> >>>>> The whole patch series can be found in one patch at:
> >>>>> kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz
> >>>>> or in the git tree and branch at:
> >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
> >>>>> and the diffstat can be found below.
> >>>>>
> >>>>> thanks,
> >>>>>
> >>>>> greg k-h
> >>>>>
> >>>>
> >>>> Compiled, booted and ran the following package unit tests without regressions on x86_64
> >>>>
> >>>> boringssl :
> >>>> go test target:0/0/5764/5764/5764 PASS
> >>>> ssl_test : 10 pass
> >>>> crypto_test : 28 pass
> >>>> e2fsprogs:
> >>>> make check : 340 pass
> >>>> sqlite
> >>>> make test : 143914 pass
> >>>> drm
> >>>> make check : 15 pass
> >>>> modetest, drmdevice : pass
> >>>> alsa-lib
> >>>> make check : 2 pass
> >>>> bluez
> >>>> make check : 25 pass
> >>>> libusb
> >>>> stress : 4 pass
> >>>
> >>> How do the above tests stress the kernel?
> >>
> >> Depends entirely on the package in question.
> >>
> >> Sure, of completely no surprise a lot of package unit tests don’t really
> >> do much that’s particularly interesting save to the package itself.
> >
> > Then why run those tests? Like sqlite, what kernel functionality does
> > that exercise that ltp does not?
>
> Simply it beats on the system.
There are "real" stress tests you could run if you want to do that. But
I thought you all had a hard time keeping your boards alive, are you
sure you want to stress them? :)
> >> There are sometimes an interesting subset that drives some amount of work in kernel.
> >> That’s the useful stuff.
> >
> > Is that true with the above list? If so, why are those types of tests
> > not part of any kernel test suite that I have seen before?
>
> Dunno. Can’t comment on the non-action by others. What we can do is either
> harvest (by adding to say LTP) or improve in the
I can not parse this sentence :(
> > You are testing past regressions of the userspace code, not the kernel
> > here. Why do I care about that? :)
>
> Like you, I only care things that are testing the kernel. I’m lazy. I’m not
> chopping out the things that go far afield, besides it’s not broken nor is it
> hurting anything.
Are you sure these are "testing" the kernel in any other way than the
existing tests you are running are? Randomly running various userspace
programs is not really a good judge of kernel functionality coverage.
> > Don't fall down the trap of running code for the sake of running code
> > (i.e. like that web site that starts with a P) that doesn't actually
> > test anything that actually matters.
>
> Yup entirely agree. No emerge world going on here. 8-b
'emerge world' is a wonderful test for a compiler, don't knock it, it's
found loads of bugs in the past.
But we aren't testing the compiler, we want to test the kernel, and
really, I don't think the things you ran (with maybe the exception of
the bluez test), do anything more than 'emerge world' would do :)
Why not work to incorporate one of the many tests that we already know
_do_ test different kernel functionality that you are not running before
adding random tests that no one really knows do anything at all?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH 4.14 00/95] 4.14.4-stable review
2017-12-05 6:24 ` Greg Kroah-Hartman
2017-12-05 21:45 ` Tom Gall
@ 2017-12-06 14:41 ` Sumit Semwal
2017-12-06 15:33 ` Greg Kroah-Hartman
1 sibling, 1 reply; 90+ messages in thread
From: Sumit Semwal @ 2017-12-06 14:41 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Tom Gall, LKML, Linus Torvalds, Andrew Morton, Guenter Roeck,
Shuah Khan, patches, Ben Hutchings, lkft-triage, linux- stable
Hi Greg,
On 5 December 2017 at 11:54, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Mon, Dec 04, 2017 at 03:12:45PM -0600, Tom Gall wrote:
>>
>>
>> > On Dec 4, 2017, at 9:59 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>> >
>> > This is the start of the stable review cycle for the 4.14.4 release.
>> > There are 95 patches in this series, all will be posted as a response
>> > to this one. If anyone has any issues with these being applied, please
>> > let me know.
>> >
>> > Responses should be made by Wed Dec 6 16:00:27 UTC 2017.
>> > Anything received after that time might be too late.
>> >
>> > The whole patch series can be found in one patch at:
>> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz
>> > or in the git tree and branch at:
>> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
>> > and the diffstat can be found below.
>> >
>> > thanks,
>> >
>> > greg k-h
>> >
>>
>> Compiled, booted and ran the following package unit tests without regressions on x86_64
>>
>> boringssl :
>> go test target:0/0/5764/5764/5764 PASS
>> ssl_test : 10 pass
>> crypto_test : 28 pass
>> e2fsprogs:
>> make check : 340 pass
>> sqlite
>> make test : 143914 pass
>> drm
>> make check : 15 pass
>> modetest, drmdevice : pass
>> alsa-lib
>> make check : 2 pass
>> bluez
>> make check : 25 pass
>> libusb
>> stress : 4 pass
>
> How do the above tests stress the kernel? Aren't they just
> verifications that the source code in the package is correct?
>
> I guess it proves something, but have you ever seen the above regress in
> _any_ kernel release?
>
> I know the drm developers have a huge test suite that they use to verify
> their kernel changes, why not use that?
Are you referring to the igt-gpu-tools [1]? They also have a CI [2]
that runs these tests, but almost 98% of the tests are i915 specific /
can be only tested on i915 for now. Though I have chatted with Daniel
V a couple of times, and we do see a good scope of collaboration in
getting these tested on ARM as well.
Also, these are drm-specific tests, not testing generic kernel
features per-se. Just my 2 cents here.
>
> thanks,
>
> greg k-h
Best,
Sumit
[1]: https://cgit.freedesktop.org/drm/igt-gpu-tools
[2]: https://intel-gfx-ci.01.org
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH 4.14 00/95] 4.14.4-stable review
2017-12-06 14:41 ` Sumit Semwal
@ 2017-12-06 15:33 ` Greg Kroah-Hartman
2017-12-06 15:39 ` Sumit Semwal
0 siblings, 1 reply; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-06 15:33 UTC (permalink / raw)
To: Sumit Semwal
Cc: Tom Gall, LKML, Linus Torvalds, Andrew Morton, Guenter Roeck,
Shuah Khan, patches, Ben Hutchings, lkft-triage, linux- stable
On Wed, Dec 06, 2017 at 08:11:26PM +0530, Sumit Semwal wrote:
> Hi Greg,
>
> On 5 December 2017 at 11:54, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Mon, Dec 04, 2017 at 03:12:45PM -0600, Tom Gall wrote:
> >>
> >>
> >> > On Dec 4, 2017, at 9:59 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> >> >
> >> > This is the start of the stable review cycle for the 4.14.4 release.
> >> > There are 95 patches in this series, all will be posted as a response
> >> > to this one. If anyone has any issues with these being applied, please
> >> > let me know.
> >> >
> >> > Responses should be made by Wed Dec 6 16:00:27 UTC 2017.
> >> > Anything received after that time might be too late.
> >> >
> >> > The whole patch series can be found in one patch at:
> >> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz
> >> > or in the git tree and branch at:
> >> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
> >> > and the diffstat can be found below.
> >> >
> >> > thanks,
> >> >
> >> > greg k-h
> >> >
> >>
> >> Compiled, booted and ran the following package unit tests without regressions on x86_64
> >>
> >> boringssl :
> >> go test target:0/0/5764/5764/5764 PASS
> >> ssl_test : 10 pass
> >> crypto_test : 28 pass
> >> e2fsprogs:
> >> make check : 340 pass
> >> sqlite
> >> make test : 143914 pass
> >> drm
> >> make check : 15 pass
> >> modetest, drmdevice : pass
> >> alsa-lib
> >> make check : 2 pass
> >> bluez
> >> make check : 25 pass
> >> libusb
> >> stress : 4 pass
> >
> > How do the above tests stress the kernel? Aren't they just
> > verifications that the source code in the package is correct?
> >
> > I guess it proves something, but have you ever seen the above regress in
> > _any_ kernel release?
> >
> > I know the drm developers have a huge test suite that they use to verify
> > their kernel changes, why not use that?
>
> Are you referring to the igt-gpu-tools [1]? They also have a CI [2]
> that runs these tests, but almost 98% of the tests are i915 specific /
> can be only tested on i915 for now. Though I have chatted with Daniel
> V a couple of times, and we do see a good scope of collaboration in
> getting these tested on ARM as well.
Well, you all are testing x86 for the stable trees, right, why can't you
run the i915 tests? :)
> Also, these are drm-specific tests, not testing generic kernel
> features per-se. Just my 2 cents here.
drm-specific things _are_ part of the kernel api, right?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH 4.14 00/95] 4.14.4-stable review
2017-12-06 15:33 ` Greg Kroah-Hartman
@ 2017-12-06 15:39 ` Sumit Semwal
0 siblings, 0 replies; 90+ messages in thread
From: Sumit Semwal @ 2017-12-06 15:39 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Tom Gall, LKML, Linus Torvalds, Andrew Morton, Guenter Roeck,
Shuah Khan, patches, Ben Hutchings, lkft-triage, linux- stable
On 6 December 2017 at 21:03, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Wed, Dec 06, 2017 at 08:11:26PM +0530, Sumit Semwal wrote:
>> Hi Greg,
>>
>> On 5 December 2017 at 11:54, Greg Kroah-Hartman
>> <gregkh@linuxfoundation.org> wrote:
>> > On Mon, Dec 04, 2017 at 03:12:45PM -0600, Tom Gall wrote:
>> >>
>> >>
>> >> > On Dec 4, 2017, at 9:59 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>> >> >
>> >> > This is the start of the stable review cycle for the 4.14.4 release.
>> >> > There are 95 patches in this series, all will be posted as a response
>> >> > to this one. If anyone has any issues with these being applied, please
>> >> > let me know.
>> >> >
>> >> > Responses should be made by Wed Dec 6 16:00:27 UTC 2017.
>> >> > Anything received after that time might be too late.
>> >> >
>> >> > The whole patch series can be found in one patch at:
>> >> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz
>> >> > or in the git tree and branch at:
>> >> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
>> >> > and the diffstat can be found below.
>> >> >
>> >> > thanks,
>> >> >
>> >> > greg k-h
>> >> >
>> >>
>> >> Compiled, booted and ran the following package unit tests without regressions on x86_64
>> >>
>> >> boringssl :
>> >> go test target:0/0/5764/5764/5764 PASS
>> >> ssl_test : 10 pass
>> >> crypto_test : 28 pass
>> >> e2fsprogs:
>> >> make check : 340 pass
>> >> sqlite
>> >> make test : 143914 pass
>> >> drm
>> >> make check : 15 pass
>> >> modetest, drmdevice : pass
>> >> alsa-lib
>> >> make check : 2 pass
>> >> bluez
>> >> make check : 25 pass
>> >> libusb
>> >> stress : 4 pass
>> >
>> > How do the above tests stress the kernel? Aren't they just
>> > verifications that the source code in the package is correct?
>> >
>> > I guess it proves something, but have you ever seen the above regress in
>> > _any_ kernel release?
>> >
>> > I know the drm developers have a huge test suite that they use to verify
>> > their kernel changes, why not use that?
>>
>> Are you referring to the igt-gpu-tools [1]? They also have a CI [2]
>> that runs these tests, but almost 98% of the tests are i915 specific /
>> can be only tested on i915 for now. Though I have chatted with Daniel
>> V a couple of times, and we do see a good scope of collaboration in
>> getting these tested on ARM as well.
>
> Well, you all are testing x86 for the stable trees, right, why can't you
> run the i915 tests? :)
I'll check with the DRM guys, but my guess is the DRM framework itself
is a very fast changing one, and the current i915 tests might not even
apply for the stable kernels. :)
>
>> Also, these are drm-specific tests, not testing generic kernel
>> features per-se. Just my 2 cents here.
>
> drm-specific things _are_ part of the kernel api, right?
True that :)
By writing this, I did want to highlight that the 'large bucket'
wasn't generic features, but a very driver-specific one right now.
>
> thanks,
>
> greg k-h
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH 4.14 00/95] 4.14.4-stable review
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (74 preceding siblings ...)
2017-12-04 21:12 ` Tom Gall
@ 2017-12-04 23:46 ` Guenter Roeck
2017-12-05 6:24 ` Greg Kroah-Hartman
2017-12-05 7:01 ` Naresh Kamboju
76 siblings, 1 reply; 90+ messages in thread
From: Guenter Roeck @ 2017-12-04 23:46 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, shuahkh, patches, ben.hutchings,
lkft-triage, stable
On Mon, Dec 04, 2017 at 04:59:24PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.4 release.
> There are 95 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Dec 6 16:00:27 UTC 2017.
> Anything received after that time might be too late.
>
Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 123 pass: 123 fail: 0
Details are available at http://kerneltests.org/builders.
Guenter
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: [PATCH 4.14 00/95] 4.14.4-stable review
2017-12-04 23:46 ` Guenter Roeck
@ 2017-12-05 6:24 ` Greg Kroah-Hartman
0 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-05 6:24 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-kernel, torvalds, akpm, shuahkh, patches, ben.hutchings,
lkft-triage, stable
On Mon, Dec 04, 2017 at 03:46:31PM -0800, Guenter Roeck wrote:
> On Mon, Dec 04, 2017 at 04:59:24PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.14.4 release.
> > There are 95 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed Dec 6 16:00:27 UTC 2017.
> > Anything received after that time might be too late.
> >
>
> Build results:
> total: 145 pass: 145 fail: 0
> Qemu test results:
> total: 123 pass: 123 fail: 0
>
> Details are available at http://kerneltests.org/builders.
Great, thanks for testing all of these and letting me know.
greg k-h
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH 4.14 00/95] 4.14.4-stable review
2017-12-04 15:59 [PATCH 4.14 00/95] 4.14.4-stable review Greg Kroah-Hartman
` (75 preceding siblings ...)
2017-12-04 23:46 ` Guenter Roeck
@ 2017-12-05 7:01 ` Naresh Kamboju
2017-12-05 7:50 ` Greg Kroah-Hartman
76 siblings, 1 reply; 90+ messages in thread
From: Naresh Kamboju @ 2017-12-05 7:01 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, Guenter Roeck, Shuah Khan, patches,
Ben Hutchings, lkft-triage, linux- stable, Tom Gall
On 4 December 2017 at 21:29, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> This is the start of the stable review cycle for the 4.14.4 release.
> There are 95 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Dec 6 16:00:27 UTC 2017.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.
Summary
------------------------------------------------------------------------
kernel: 4.14.4-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: 95aa1a118d82e935ec7065345cbaff945d4100bf
git describe: v4.14.3-96-g95aa1a118d82
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.3-96-g95aa1a118d82
No regressions (compared to build v4.14.3-96-gc2bf04f2ec62)
Boards, architectures and test suites:
-------------------------------------
hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 39, skip: 14
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 982, skip: 121
* ltp-timers-tests - pass: 12,
juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 38, skip: 14
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 939, skip: 156
* ltp-timers-tests - pass: 12,
x15 - arm
* boot - pass: 20,
* kselftest - pass: 35, skip: 18
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1036, skip: 66
* ltp-timers-tests - pass: 12,
x86_64
* boot - pass: 20,
* kselftest - pass: 54, skip: 13
* libhugetlbfs - pass: 76, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 1
* ltp-fs_bind-tests - pass: 1,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 957, skip: 163
* ltp-timers-tests - pass: 12,
Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports
Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org>
^ permalink raw reply [flat|nested] 90+ messages in thread* Re: [PATCH 4.14 00/95] 4.14.4-stable review
2017-12-05 7:01 ` Naresh Kamboju
@ 2017-12-05 7:50 ` Greg Kroah-Hartman
0 siblings, 0 replies; 90+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-05 7:50 UTC (permalink / raw)
To: Naresh Kamboju
Cc: linux-kernel, torvalds, akpm, Guenter Roeck, Shuah Khan, patches,
Ben Hutchings, lkft-triage, linux- stable, Tom Gall
On Tue, Dec 05, 2017 at 12:31:40PM +0530, Naresh Kamboju wrote:
> On 4 December 2017 at 21:29, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > This is the start of the stable review cycle for the 4.14.4 release.
> > There are 95 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed Dec 6 16:00:27 UTC 2017.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
>
> Results from Linaro’s test farm.
> No regressions on arm64, arm and x86_64.
Thanks for testing all 3 of these releases and letting me know.
greg k-h
^ permalink raw reply [flat|nested] 90+ messages in thread