Patch 4b433924b275 ("scsi: sd_zbc: Fix potential memory leak") was added in
4.16 and 4.15 stable but did not make it to long term stable 4.14 (as far as I
can tell).
Patch ccce20fc7968 ("scsi: sd_zbc: Avoid that resetting a zone fails
sporadically") is included in 4.16 but does not apply to 4.15 stable nor to
4.14 long term stable and requires extensive modifications.
This small series provides a backport of both patches against 4.14. Please
consider these patches for inclusion in this long term stable kernel.
Bart Van Assche (1):
scsi: sd_zbc: Avoid that resetting a zone fails sporadically
Damien Le Moal (1):
scsi: sd_zbc: Fix potential memory leak
drivers/scsi/sd_zbc.c | 128 +++++++++++++++++++++++++-----------------
1 file changed, 76 insertions(+), 52 deletions(-)
Changes from v1:
* Fixed upstream commit reference in the first patch commit message
--
2.17.0
On Mon, Jun 04, 2018 at 04:11:03PM -0700, Kevin Hilman wrote:
> kernelci.org bot <bot(a)kernelci.org> writes:
>
> > Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.1…
> > Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.14.y/kernel/v4.14.47-53…
> >
> > Tree: stable-rc
> > Branch: linux-4.14.y
> > Git Describe: v4.14.47-53-g721adf61fde2
> > Git Commit: 721adf61fde28b9a87a95e45ecf3f5a325e7c76f
> > Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > Tested: 56 unique boards, 23 SoC families, 14 builds out of 185
> >
> > Boot Regressions Detected:
> >
> > arm64:
> >
> > defconfig:
> > meson-gxl-s905x-khadas-vim:
> > lab-baylibre: failing since 39 days (last pass: v4.14.26-140-g2a1700a4929f - first fail: v4.14.36-184-g3cd53e436ee2)
> >
> > Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.)
>
> TL;DR; All is well.
>
> The failing board is having a power supply issue and has been taken
> offline for repair. Since the same board is passing fine in another
> lab, it can be ignored.
Thanks for the updates on this, and the 4.9 board breakage.
greg k-h
On Mon, Jun 4, 2018 at 8:33 AM, Thomas Gleixner <tglx(a)linutronix.de> wrote:
> The case that interrupt affinity setting fails with -EBUSY can be handled
> in the kernel completely by using the already available generic pending
> infrastructure.
>
> If a irq_chip::set_affinity() fails with -EBUSY, handle it like the
> interrupts for which irq_chip::set_affinity() can only be invoked from
> interrupt context. Copy the new affinity mask to irq_desc::pending_mask and
> set the affinity pending bit. The next raised interrupt for the affected
> irq will check the pending bit and try to set the new affinity from the
> handler. This avoids that -EBUSY is returned when an affinity change is
> requested from user space and the previous change has not been cleaned
> up. The new affinity will take effect when the next interrupt is raised
> from the device.
>
> Fixes: dccfe3147b42 ("x86/vector: Simplify vector move cleanup")
> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
> Cc: stable(a)vger.kernel.org
Tested-by: Song Liu <songliubraving(a)fb.com>
> ---
> kernel/irq/manage.c | 37 +++++++++++++++++++++++++++++++++++--
> 1 file changed, 35 insertions(+), 2 deletions(-)
>
> --- a/kernel/irq/manage.c
> +++ b/kernel/irq/manage.c
> @@ -204,6 +204,39 @@ int irq_do_set_affinity(struct irq_data
> return ret;
> }
>
> +#ifdef CONFIG_GENERIC_PENDING_IRQ
> +static inline int irq_set_affinity_pending(struct irq_data *data,
> + const struct cpumask *dest)
> +{
> + struct irq_desc *desc = irq_data_to_desc(data);
> +
> + irqd_set_move_pending(data);
> + irq_copy_pending(desc, dest);
> + return 0;
> +}
> +#else
> +static inline int irq_set_affinity_pending(struct irq_data *data,
> + const struct cpumask *dest)
> +{
> + return -EBUSY;
> +}
> +#endif
> +
> +static int irq_try_set_affinity(struct irq_data *data,
> + const struct cpumask *dest, bool force)
> +{
> + int ret = irq_do_set_affinity(data, dest, force);
> +
> + /*
> + * In case that the underlying vector management is busy and the
> + * architecture supports the generic pending mechanism then utilize
> + * this to avoid returning an error to user space.
> + */
> + if (ret == -EBUSY && !force)
> + ret = irq_set_affinity_pending(data, dest);
> + return ret;
> +}
> +
> int irq_set_affinity_locked(struct irq_data *data, const struct cpumask *mask,
> bool force)
> {
> @@ -214,8 +247,8 @@ int irq_set_affinity_locked(struct irq_d
> if (!chip || !chip->irq_set_affinity)
> return -EINVAL;
>
> - if (irq_can_move_pcntxt(data)) {
> - ret = irq_do_set_affinity(data, mask, force);
> + if (irq_can_move_pcntxt(data) && !irqd_is_setaffinity_pending(data)) {
> + ret = irq_try_set_affinity(data, mask, force);
> } else {
> irqd_set_move_pending(data);
> irq_copy_pending(desc, mask);
>
>
On Mon, Jun 4, 2018 at 8:33 AM, Thomas Gleixner <tglx(a)linutronix.de> wrote:
> apic_ack_edge() is explicitely for handling interrupt affinity cleanup when
> interrupt remapping is not available or disable.
>
> Remapped interrupts and also some of the platform specific special
> interrupts, e.g. UV, invoke ack_APIC_irq() directly.
>
> To address the issue of failing an affinity update with -EBUSY the delayed
> affinity mechanism can be reused, but ack_APIC_irq() does not handle
> that. Adding this to ack_APIC_irq() is not possible, because that function
> is also used for exceptions and directly handled interrupts like IPIs.
>
> Create a new function, which just contains the conditional invocation of
> irq_move_irq() and the final ack_APIC_irq(). Making the invocation of
> irq_move_irq() conditional avoids the out of line call if the pending bit
> is not set.
>
> Reuse the new function in apic_ack_edge().
>
> Preparatory change for the real fix
>
> Fixes: dccfe3147b42 ("x86/vector: Simplify vector move cleanup")
> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
> Cc: stable(a)vger.kernel.org
Tested-by: Song Liu <songliubraving(a)fb.com>
> ---
> arch/x86/include/asm/apic.h | 2 ++
> arch/x86/kernel/apic/vector.c | 10 ++++++++--
> 2 files changed, 10 insertions(+), 2 deletions(-)
>
> --- a/arch/x86/include/asm/apic.h
> +++ b/arch/x86/include/asm/apic.h
> @@ -436,6 +436,8 @@ static inline void apic_set_eoi_write(vo
>
> #endif /* CONFIG_X86_LOCAL_APIC */
>
> +extern void apic_ack_irq(struct irq_data *data);
> +
> static inline void ack_APIC_irq(void)
> {
> /*
> --- a/arch/x86/kernel/apic/vector.c
> +++ b/arch/x86/kernel/apic/vector.c
> @@ -809,11 +809,17 @@ static int apic_retrigger_irq(struct irq
> return 1;
> }
>
> +void apic_ack_irq(struct irq_data *irqd)
> +{
> + if (unlikely(irqd_is_setaffinity_pending(irqd)))
> + irq_move_irq(irqd);
> + ack_APIC_irq();
> +}
> +
> void apic_ack_edge(struct irq_data *irqd)
> {
> irq_complete_move(irqd_cfg(irqd));
> - irq_move_irq(irqd);
> - ack_APIC_irq();
> + apic_ack_irq(irqd);
> }
>
> static struct irq_chip lapic_controller = {
>
>
On Mon, Jun 4, 2018 at 8:33 AM, Thomas Gleixner <tglx(a)linutronix.de> wrote:
> The generic pending interrupt mechanism moves interrupts from the interrupt
> handler on the original target CPU to the new destination CPU. This is
> required for x86 and ia64 due to the way the interrupt delivery and
> acknowledge works if the interrupts are not remapped.
>
> However that update can fail for various reasons. Some of them are valid
> reasons to discard the pending update, but the case, when the previous move
> has not been fully cleaned up is not a legit reason to fail.
>
> Check the return value of irq_do_set_affinity() for -EBUSY, which indicates
> a pending cleanup, and rearm the pending move in the irq dexcriptor so it's
> tried again when the next interrupt arrives.
>
> Fixes: 996c591227d9 ("x86/irq: Plug vector cleanup race")
> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
> Cc: stable(a)vger.kernel.org
Tested-by: Song Liu <songliubraving(a)fb.com>
> ---
> kernel/irq/migration.c | 24 ++++++++++++++++++------
> 1 file changed, 18 insertions(+), 6 deletions(-)
>
> --- a/kernel/irq/migration.c
> +++ b/kernel/irq/migration.c
> @@ -38,17 +38,18 @@ bool irq_fixup_move_pending(struct irq_d
> void irq_move_masked_irq(struct irq_data *idata)
> {
> struct irq_desc *desc = irq_data_to_desc(idata);
> - struct irq_chip *chip = desc->irq_data.chip;
> + struct irq_data *data = &desc->irq_data;
> + struct irq_chip *chip = data->chip;
>
> - if (likely(!irqd_is_setaffinity_pending(&desc->irq_data)))
> + if (likely(!irqd_is_setaffinity_pending(data)))
> return;
>
> - irqd_clr_move_pending(&desc->irq_data);
> + irqd_clr_move_pending(data);
>
> /*
> * Paranoia: cpu-local interrupts shouldn't be calling in here anyway.
> */
> - if (irqd_is_per_cpu(&desc->irq_data)) {
> + if (irqd_is_per_cpu(data)) {
> WARN_ON(1);
> return;
> }
> @@ -73,9 +74,20 @@ void irq_move_masked_irq(struct irq_data
> * For correct operation this depends on the caller
> * masking the irqs.
> */
> - if (cpumask_any_and(desc->pending_mask, cpu_online_mask) < nr_cpu_ids)
> - irq_do_set_affinity(&desc->irq_data, desc->pending_mask, false);
> + if (cpumask_any_and(desc->pending_mask, cpu_online_mask) < nr_cpu_ids) {
> + int ret;
>
> + ret = irq_do_set_affinity(data, desc->pending_mask, false);
> + /*
> + * If the there is a cleanup pending in the underlying
> + * vector management, reschedule the move for the next
> + * interrupt. Leave desc->pending_mask intact.
> + */
> + if (ret == -EBUSY) {
> + irqd_set_move_pending(data);
> + return;
> + }
> + }
> cpumask_clear(desc->pending_mask);
> }
>
>
>
On Mon, Jun 4, 2018 at 8:33 AM, Thomas Gleixner <tglx(a)linutronix.de> wrote:
> Several people observed the WARN_ON() in irq_matrix_free() which triggers
> when the caller tries to free an vector which is not in the allocation
> range. Song provided the trace information which allowed to decode the root
> cause.
>
> The rework of the vector allocation mechanism failed to preserve a sanity
> check, which prevents setting a new target vector/CPU when the previous
> affinity change has not fully completed.
>
> As a result a half finished affinity change can be overwritten, which can
> cause the leak of a irq descriptor pointer on the previous target CPU and
> double enqueue of the hlist head into the cleanup lists of two or more
> CPUs. After one CPU cleaned up its vector the next CPU will invoke the
> cleanup handler with vector 0, which triggers the out of range warning in
> the matrix allocator.
>
> Prevent this by checking the apic_data of the interrupt whether the
> move_in_progress flag is false and the hlist node is not hashed. Return
> -EBUSY if not.
>
> This prevents the damage and restores the behaviour before the vector
> allocation rework, but due to other changes in that area it also widens the
> chance that user space can observe -EBUSY. In theory this should be fine,
> but actually not all user space tools handle -EBUSY correctly. Addressing
> that is not part of this fix, but will be addressed in follow up patches.
>
> Fixes: 69cde0004a4b ("x86/vector: Use matrix allocator for vector assignment")
> Reported-by: Dmitry Safonov <0x7f454c46(a)gmail.com>
> Reported-by: Tariq Toukan <tariqt(a)mellanox.com>
> Reported-by: Song Liu <liu.song.a23(a)gmail.com>
> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
> Cc: stable(a)vger.kernel.org
Thanks Thomas!
This patch alone fixes my test: ethtool -L in a loop.
I also run the same test for the full set, and it works well.
Tested-by: Song Liu <songliubraving(a)fb.com>
> ---
> arch/x86/kernel/apic/vector.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> --- a/arch/x86/kernel/apic/vector.c
> +++ b/arch/x86/kernel/apic/vector.c
> @@ -235,6 +235,15 @@ static int allocate_vector(struct irq_da
> if (vector && cpu_online(cpu) && cpumask_test_cpu(cpu, dest))
> return 0;
>
> + /*
> + * Careful here. @apicd might either have move_in_progress set or
> + * be enqueued for cleanup. Assigning a new vector would either
> + * leave a stale vector on some CPU around or in case of a pending
> + * cleanup corrupt the hlist.
> + */
> + if (apicd->move_in_progress || !hlist_unhashed(&apicd->clist))
> + return -EBUSY;
> +
> vector = irq_matrix_alloc(vector_matrix, dest, resvd, &cpu);
> if (vector > 0)
> apic_update_vector(irqd, vector, cpu);
>
>
Decided to add Enric's commit because it is also a bug fix instead
of modifying Chris commit.
Chris Chiu (1):
tpm: self test failure should not cause suspend to fail
Enric Balletbo i Serra (1):
tpm: do not suspend/resume if power stays on
drivers/char/tpm/tpm-chip.c | 12 ++++++++++++
drivers/char/tpm/tpm-interface.c | 7 +++++++
drivers/char/tpm/tpm.h | 1 +
3 files changed, 20 insertions(+)
--
v2: moved the check from tpm_of.c to tpm-chip.c as in v4.4 chip is
unreachable otherwise. I did compilation test now with BuildRoot
for power arch.
2.17.0
The patch titled
Subject: mm/huge_memory.c: __split_huge_page() use atomic ClearPageDirty()
has been removed from the -mm tree. Its filename was
mm-huge_memoryc-__split_huge_page-use-atomic-clearpagedirty.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Hugh Dickins <hughd(a)google.com>
Subject: mm/huge_memory.c: __split_huge_page() use atomic ClearPageDirty()
Swapping load on huge=always tmpfs (with khugepaged tuned up to be very
eager, but I'm not sure that is relevant) soon hung uninterruptibly,
waiting for page lock in shmem_getpage_gfp()'s find_lock_entry(), most
often when "cp -a" was trying to write to a smallish file. Debug showed
that the page in question was not locked, and page->mapping NULL by now,
but page->index consistent with having been in a huge page before.
Reproduced in minutes on a 4.15 kernel, even with 4.17's 605ca5ede764
("mm/huge_memory.c: reorder operations in __split_huge_page_tail()") added
in; but took hours to reproduce on a 4.17 kernel (no idea why).
The culprit proved to be the __ClearPageDirty() on tails beyond i_size in
__split_huge_page(): the non-atomic __bitoperation may have been safe when
4.8's baa355fd3314 ("thp: file pages support for split_huge_page()")
introduced it, but liable to erase PageWaiters after 4.10's 62906027091f
("mm: add PageWaiters indicating tasks are waiting for a page bit").
Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1805291841070.3197@eggly.anvils
Fixes: 62906027091f ("mm: add PageWaiters indicating tasks are waiting for a page bit")
Signed-off-by: Hugh Dickins <hughd(a)google.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
Cc: Konstantin Khlebnikov <khlebnikov(a)yandex-team.ru>
Cc: Nicholas Piggin <npiggin(a)gmail.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/huge_memory.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN mm/huge_memory.c~mm-huge_memoryc-__split_huge_page-use-atomic-clearpagedirty mm/huge_memory.c
--- a/mm/huge_memory.c~mm-huge_memoryc-__split_huge_page-use-atomic-clearpagedirty
+++ a/mm/huge_memory.c
@@ -2431,7 +2431,7 @@ static void __split_huge_page(struct pag
__split_huge_page_tail(head, i, lruvec, list);
/* Some pages can be beyond i_size: drop them from page cache */
if (head[i].index >= end) {
- __ClearPageDirty(head + i);
+ ClearPageDirty(head + i);
__delete_from_page_cache(head + i, NULL);
if (IS_ENABLED(CONFIG_SHMEM) && PageSwapBacked(head))
shmem_uncharge(head->mapping->host, 1);
_
Patches currently in -mm which might be from hughd(a)google.com are
Hi Doug and Jason,
We have two more late breaking fix up patches. The DMA_RTAIL fix is the more
serious of the two. I realize we are at the tail end of 4.17 so I would not be
against holding off till 4.18 for these, but if there is another rdma
pull request we may want to tack these on.
---
Kaike Wan (1):
IB/hfi1: Ensure VL index is within bounds
Mike Marciniszyn (1):
IB/hfi1: Fix user context tail allocation for DMA_RTAIL
drivers/infiniband/hw/hfi1/chip.c | 8 ++++----
drivers/infiniband/hw/hfi1/file_ops.c | 2 +-
drivers/infiniband/hw/hfi1/init.c | 9 ++++-----
drivers/infiniband/hw/hfi1/sdma.c | 12 +++---------
4 files changed, 12 insertions(+), 19 deletions(-)
--
-Denny
There are pros and cons of dealing with tools in the kernel directory.
The pros are the fact that development happens fast, and new features
can be added to the kernel and the tools at the same times. The cons
are when dealing with backported kernel patches, it can be necessary to
backport parts of the tool changes as well.
For 4.9.y so far, we have backported individual patches. That quickly
breaks down when there are minor differences between how backports were
handled, so grabbing 40+ patch long series can be difficult, not
impossible, but really frustrating to attempt.
To help mitigate this mess, this patch series works to sync up the
objtool code with the version that is currently in 4.14.47. This
required a number of objtool old patches to be backported, a single big
"sync the world" patch, and a lot of include file updates to get
everything all working properly as well as some minor fixes for build
warnings.
And at the end of this series, is a set of backported objtool patches
for gcc-8 that was the main reason this whole patch series was created.
They applied just fine, being the identical version that goes into the
4.14.y stable tree, so it feels like the backport was successful.
This has survivied my limited testing, and as the codebase is identical
to 4.14.47, I'm pretty comfortable dropping this big change in here in
4.9.y. Hopefully all goes well...
If anyone has any objections to this patch series, or finds anything I
messed up on, please let me know.
thanks,
greg k-h
Arnaldo Carvalho de Melo (11):
tools include: Introduce linux/compiler-gcc.h
tools include: Adopt __compiletime_error
tools include: Introduce atomic_cmpxchg_{relaxed,release}()
tools include: Add UINT_MAX def to kernel.h
tools include: Adopt kernel's refcount.h
tools include uapi: Grab copies of stat.h and fcntl.h
tools include: Introduce linux/bug.h, from the kernel sources
tools include: Adopt __same_type() and __must_be_array() from the
kernel
tools include: Move ARRAY_SIZE() to linux/kernel.h
tools include: Drop ARRAY_SIZE() definition from linux/hashtable.h
tools include: Include missing headers for fls() and types in
linux/log2.h
Greg Kroah-Hartman (4):
objtool: sync up with the 4.14.47 version of objtool
perf/tools: header file sync up
objtool: header file sync-up
x86/xen: Add unwind hint annotations to xen_setup_gdt
Jiri Olsa (3):
tools lib: Add for_each_clear_bit macro
perf tools: Force fixdep compilation at the start of the build
perf tools: Move headers check into bash script
Josh Poimboeuf (8):
objtool: Improve detection of BUG() and other dead ends
objtool: Move checking code to check.c
objtool: Support GCC 8's cold subfunctions
objtool: Support GCC 8 switch tables
objtool: Detect RIP-relative switch table references
objtool: Detect RIP-relative switch table references, part 2
objtool: Fix "noreturn" detection for recursive sibling calls
objtool, x86: Add several functions and files to the objtool whitelist
Matthew Wilcox (2):
tools: add more bitmap functions
radix tree test suite: Remove types.h
Michael S. Tsirkin (1):
tools: enable endian checks for all sparse builds
arch/x86/crypto/Makefile | 2 +
arch/x86/crypto/sha1-mb/Makefile | 2 +
arch/x86/crypto/sha256-mb/Makefile | 2 +
arch/x86/include/asm/orc_types.h | 107 +
arch/x86/include/asm/unwind_hints.h | 103 +
arch/x86/kernel/Makefile | 1 +
arch/x86/kernel/acpi/Makefile | 2 +
arch/x86/kernel/kprobes/opt.c | 9 +-
arch/x86/kernel/reboot.c | 2 +
arch/x86/kernel/vmlinux.lds.S | 1 +
arch/x86/kvm/svm.c | 2 +
arch/x86/kvm/vmx.c | 3 +
arch/x86/lib/msr-reg.S | 8 +-
arch/x86/net/Makefile | 2 +
arch/x86/platform/efi/Makefile | 1 +
arch/x86/power/Makefile | 2 +
arch/x86/xen/Makefile | 3 +
arch/x86/xen/enlighten.c | 5 +-
include/linux/compiler-gcc.h | 13 +-
kernel/kexec_core.c | 4 +-
tools/arch/arm/include/uapi/asm/kvm.h | 13 +
tools/arch/arm64/include/uapi/asm/kvm.h | 6 +
tools/arch/powerpc/include/uapi/asm/kvm.h | 1 +
tools/arch/s390/include/uapi/asm/kvm.h | 5 +-
tools/arch/x86/include/asm/cpufeatures.h | 44 +-
.../arch/x86/include/asm/disabled-features.h | 7 +-
.../arch/x86/include/asm/required-features.h | 3 +-
tools/include/asm-generic/bitops.h | 1 +
tools/include/asm-generic/bitops/__ffz.h | 12 +
tools/include/asm-generic/bitops/find.h | 28 +
tools/include/linux/atomic.h | 6 +
tools/include/linux/bitmap.h | 26 +
tools/include/linux/bitops.h | 5 +
tools/include/linux/bug.h | 10 +
tools/include/linux/compiler-gcc.h | 21 +
tools/include/linux/compiler.h | 23 +-
tools/include/linux/hashtable.h | 4 -
tools/include/linux/kernel.h | 7 +
tools/include/linux/log2.h | 3 +
tools/include/linux/refcount.h | 151 ++
tools/include/linux/spinlock.h | 5 +
tools/include/linux/types.h | 5 +-
tools/include/uapi/asm-generic/mman-common.h | 5 +
tools/include/uapi/linux/bpf.h | 51 +
tools/include/uapi/linux/fcntl.h | 67 +
tools/include/uapi/linux/stat.h | 45 +
tools/lib/find_bit.c | 25 +
tools/objtool/Build | 4 +
.../Documentation/stack-validation.txt | 195 +-
tools/objtool/Makefile | 35 +-
tools/objtool/arch.h | 66 +-
tools/objtool/arch/x86/Build | 10 +-
tools/objtool/arch/x86/decode.c | 407 ++-
.../arch/x86/{insn => include/asm}/inat.h | 2 +-
.../x86/{insn => include/asm}/inat_types.h | 0
.../arch/x86/{insn => include/asm}/insn.h | 2 +-
.../objtool/arch/x86/include/asm/orc_types.h | 107 +
tools/objtool/arch/x86/{insn => lib}/inat.c | 2 +-
tools/objtool/arch/x86/{insn => lib}/insn.c | 4 +-
.../arch/x86/{insn => lib}/x86-opcode-map.txt | 0
.../x86/{insn => tools}/gen-insn-attr-x86.awk | 0
tools/objtool/builtin-check.c | 1297 +---------
tools/objtool/builtin-orc.c | 68 +
tools/objtool/builtin.h | 6 +
tools/objtool/cfi.h | 55 +
tools/objtool/check.c | 2209 +++++++++++++++++
tools/objtool/check.h | 82 +
tools/objtool/elf.c | 326 ++-
tools/objtool/elf.h | 23 +-
tools/objtool/objtool.c | 12 +-
tools/objtool/orc.h | 30 +
tools/objtool/orc_dump.c | 213 ++
tools/objtool/orc_gen.c | 221 ++
tools/objtool/special.c | 6 +-
tools/objtool/sync-check.sh | 29 +
tools/objtool/warn.h | 10 +
tools/perf/MANIFEST | 6 +
tools/perf/Makefile.perf | 144 +-
.../arch/x86/entry/syscalls/syscall_64.tbl | 7 +-
tools/perf/check-headers.sh | 61 +
tools/perf/util/util.h | 2 -
81 files changed, 4802 insertions(+), 1692 deletions(-)
create mode 100644 arch/x86/include/asm/orc_types.h
create mode 100644 arch/x86/include/asm/unwind_hints.h
create mode 100644 tools/include/asm-generic/bitops/__ffz.h
create mode 100644 tools/include/linux/bug.h
create mode 100644 tools/include/linux/compiler-gcc.h
create mode 100644 tools/include/linux/refcount.h
create mode 100644 tools/include/linux/spinlock.h
create mode 100644 tools/include/uapi/linux/fcntl.h
create mode 100644 tools/include/uapi/linux/stat.h
rename tools/objtool/arch/x86/{insn => include/asm}/inat.h (99%)
rename tools/objtool/arch/x86/{insn => include/asm}/inat_types.h (100%)
rename tools/objtool/arch/x86/{insn => include/asm}/insn.h (99%)
create mode 100644 tools/objtool/arch/x86/include/asm/orc_types.h
rename tools/objtool/arch/x86/{insn => lib}/inat.c (99%)
rename tools/objtool/arch/x86/{insn => lib}/insn.c (99%)
rename tools/objtool/arch/x86/{insn => lib}/x86-opcode-map.txt (100%)
rename tools/objtool/arch/x86/{insn => tools}/gen-insn-attr-x86.awk (100%)
create mode 100644 tools/objtool/builtin-orc.c
create mode 100644 tools/objtool/cfi.h
create mode 100644 tools/objtool/check.c
create mode 100644 tools/objtool/check.h
create mode 100644 tools/objtool/orc.h
create mode 100644 tools/objtool/orc_dump.c
create mode 100644 tools/objtool/orc_gen.c
create mode 100644 tools/objtool/sync-check.sh
create mode 100644 tools/perf/check-headers.sh
--
2.17.1
The patch
ASoC: dapm: delete dapm_kcontrol_data paths list before freeing it
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From ff2faf1289c1f81b5b26b9451dd1c2006aac8db8 Mon Sep 17 00:00:00 2001
From: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org>
Date: Mon, 4 Jun 2018 12:13:26 +0100
Subject: [PATCH] ASoC: dapm: delete dapm_kcontrol_data paths list before
freeing it
dapm_kcontrol_data is freed as part of dapm_kcontrol_free(), leaving the
paths pointer dangling in the list.
This leads to system crash when we try to unload and reload sound card.
I hit this bug during ADSP crash/reboot test case on Dragon board DB410c.
Without this patch, on SLAB Poisoning enabled build, kernel crashes with
"BUG kmalloc-128 (Tainted: G W ): Poison overwritten"
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Cc: stable(a)vger.kernel.org
---
sound/soc/soc-dapm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index 1e9a36389667..36a39ba30226 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -433,6 +433,8 @@ static int dapm_kcontrol_data_alloc(struct snd_soc_dapm_widget *widget,
static void dapm_kcontrol_free(struct snd_kcontrol *kctl)
{
struct dapm_kcontrol_data *data = snd_kcontrol_chip(kctl);
+
+ list_del(&data->paths);
kfree(data->wlist);
kfree(data);
}
--
2.17.0