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

[PATCH] kdb: Fix btc (backtrace on each cpu) crash

by Douglas Anderson

Typing 'btc' on kdb doing all sorts of fail. Sometimes it would crash, sometimes display nothing, and sometimes hang. Bisect tracked this down to the commit ad67b74d2469 ("printk: hash addresses printed with %p"), suggesting an obvious fix. The pointer used internally in kdb shouldn't be hashed, so switch it to %px. Fixes: ad67b74d2469 ("printk: hash addresses printed with %p") Cc: stable(a)vger.kernel.org Signed-off-by: Douglas Anderson <dianders(a)chromium.org> --- kernel/debug/kdb/kdb_bt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/debug/kdb/kdb_bt.c b/kernel/debug/kdb/kdb_bt.c index 6ad4a9fcbd6f..7921ae4fca8d 100644 --- a/kernel/debug/kdb/kdb_bt.c +++ b/kernel/debug/kdb/kdb_bt.c @@ -179,14 +179,14 @@ kdb_bt(int argc, const char **argv) kdb_printf("no process for cpu %ld\n", cpu); return 0; } - sprintf(buf, "btt 0x%p\n", KDB_TSK(cpu)); + sprintf(buf, "btt 0x%px\n", KDB_TSK(cpu)); kdb_parse(buf); return 0; } kdb_printf("btc: cpu status: "); kdb_parse("cpu\n"); for_each_online_cpu(cpu) { - sprintf(buf, "btt 0x%p\n", KDB_TSK(cpu)); + sprintf(buf, "btt 0x%px\n", KDB_TSK(cpu)); kdb_parse(buf); touch_nmi_watchdog(); } -- 2.19.1.568.g152ad8e336-goog

6 years, 10 months

3
2
0 0

request for 4.14-stable: f9a1c372299f ("ALSA: usx2y: Fix invalid stream URBs")

by Sudip Mukherjee

Hi Greg, This was not marked for stable but seems it should be in stable. Please apply to your queue of 4.14-stable. -- Regards Sudip

6 years, 10 months

2
1
0 0

request for 4.14-stable: f9ffcb0a21e1 ("media: uvcvideo: Fix driver reference counting")

by Sudip Mukherjee

Hi Greg, This was not marked for stable but seems it should be in stable. Please apply to your queue of 4.14-stable. -- Regards Sudip

6 years, 10 months

2
1
0 0

request for 4.14-stable: 5663d8f9bbe4 ("kvm: x86: fix WARN due to uninitialized guest FPU state")

by Sudip Mukherjee

Hi Greg, This was missing in 4.14-stable. Please apply to your queue. -- Regards Sudip

6 years, 10 months

3
2
0 0

[4.4/4.9/4.14 patch] mtd: spi-nor: Add support for is25wp series chips

by Adrian Bunk

From: Kimmo Rautkoski <ext-kimmo.rautkoski(a)vaisala.com> Added support for is25wp032, is25wp064 and is25wp128. Signed-off-by: Kimmo Rautkoski <ext-kimmo.rautkoski(a)vaisala.com> Reviewed-by: Marek Vasut <marek.vasut(a)gmail.com> Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com> [ Adrian Bunk: Trivial adaption to changed context. ] Signed-off-by: Adrian Bunk <bunk(a)kernel.org> --- drivers/mtd/spi-nor/spi-nor.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c index 19c000722cbc..34ecc12ee3d9 100644 --- a/drivers/mtd/spi-nor/spi-nor.c +++ b/drivers/mtd/spi-nor/spi-nor.c @@ -1005,6 +1005,12 @@ static const struct flash_info spi_nor_ids[] = { /* ISSI */ { "is25cd512", INFO(0x7f9d20, 0, 32 * 1024, 2, SECT_4K) }, + { "is25wp032", INFO(0x9d7016, 0, 64 * 1024, 64, + SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, + { "is25wp064", INFO(0x9d7017, 0, 64 * 1024, 128, + SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, + { "is25wp128", INFO(0x9d7018, 0, 64 * 1024, 256, + SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, /* Macronix */ { "mx25l512e", INFO(0xc22010, 0, 64 * 1024, 1, SECT_4K) }, -- 2.11.0

6 years, 10 months

3
3
0 0

[PATCH 4.18] Revert "mm: slowly shrink slabs with a relatively small number of objects"

by Sasha Levin

This reverts commit 62aad93f09c1952ede86405894df1b22012fd5ab. Which was upstream commit 172b06c32b94 ("mm: slowly shrink slabs with a relatively small number of objects"). The upstream commit was found to cause regressions. While there is a proposed fix upstream, revent this patch from stable trees for now as testing the fix will take some time. Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- mm/vmscan.c | 11 ----------- 1 file changed, 11 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index fc0436407471..03822f86f288 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -386,17 +386,6 @@ static unsigned long do_shrink_slab(struct shrink_control *shrinkctl, delta = freeable >> priority; delta *= 4; do_div(delta, shrinker->seeks); - - /* - * Make sure we apply some minimal pressure on default priority - * even on small cgroups. Stale objects are not only consuming memory - * by themselves, but can also hold a reference to a dying cgroup, - * preventing it from being reclaimed. A dying cgroup with all - * corresponding structures like per-cpu stats and kmem caches - * can be really big, so it may lead to a significant waste of memory. - */ - delta = max_t(unsigned long long, delta, min(freeable, batch_size)); - total_scan += delta; if (total_scan < 0) { pr_err("shrink_slab: %pF negative objects to delete nr=%ld\n", -- 2.17.1

6 years, 10 months

1
1
0 0

[PATCH v4.14-stable] sch_netem: restore skb->dev after dequeuing from the rbtree

by Christoph Paasch

Upstream commit bffa72cf7f9d ("net: sk_buff rbnode reorg") got backported as commit 6b921536f170 ("net: sk_buff rbnode reorg") into the v4.14.x-tree. However, the backport does not include the changes in sch_netem.c We need these, as otherwise the skb->dev pointer is not set when dequeueing from the netem rbtree, resulting in a panic: [ 15.427748] BUG: unable to handle kernel NULL pointer dereference at 00000000000000d0 [ 15.428863] IP: netif_skb_features+0x24/0x230 [ 15.429402] PGD 0 P4D 0 [ 15.429733] Oops: 0000 [#1] SMP PTI [ 15.430169] Modules linked in: [ 15.430614] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.14.77.mptcp #77 [ 15.431497] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.5.1 01/01/2011 [ 15.432568] task: ffff88042db19680 task.stack: ffffc90000070000 [ 15.433356] RIP: 0010:netif_skb_features+0x24/0x230 [ 15.433977] RSP: 0018:ffff88043fd83e70 EFLAGS: 00010286 [ 15.434665] RAX: ffff880429ad80c0 RBX: ffff88042bd0e400 RCX: ffff880429ad8000 [ 15.435585] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88042bd0e400 [ 15.436551] RBP: ffff88042bd0e400 R08: ffff88042a4b6c9c R09: 0000000000000001 [ 15.437485] R10: 0000000000000004 R11: 0000000000000000 R12: ffff88042c700000 [ 15.438393] R13: ffff88042c700000 R14: ffff88042a4b6c00 R15: ffff88042c6bb000 [ 15.439315] FS: 0000000000000000(0000) GS:ffff88043fd80000(0000) knlGS:0000000000000000 [ 15.440314] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 15.441084] CR2: 00000000000000d0 CR3: 000000042c374000 CR4: 00000000000006e0 [ 15.442016] Call Trace: [ 15.442333] <IRQ> [ 15.442596] validate_xmit_skb+0x17/0x270 [ 15.443134] validate_xmit_skb_list+0x38/0x60 [ 15.443698] sch_direct_xmit+0x102/0x190 [ 15.444198] __qdisc_run+0xe3/0x240 [ 15.444671] net_tx_action+0x121/0x140 [ 15.445177] __do_softirq+0xe2/0x224 [ 15.445654] irq_exit+0xbf/0xd0 [ 15.446072] smp_apic_timer_interrupt+0x5d/0x90 [ 15.446654] apic_timer_interrupt+0x7d/0x90 [ 15.447185] </IRQ> [ 15.447460] RIP: 0010:native_safe_halt+0x2/0x10 [ 15.447992] RSP: 0018:ffffc90000073f10 EFLAGS: 00000282 ORIG_RAX: ffffffffffffff10 [ 15.449008] RAX: ffffffff816667d0 RBX: ffffffff820946b0 RCX: 0000000000000000 [ 15.449895] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 15.450768] RBP: ffffffff82026940 R08: 00000004e858e5e1 R09: ffff88042a4b6d58 [ 15.451643] R10: 0000000000000000 R11: 000000d0d56879bb R12: 0000000000000000 [ 15.452478] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 15.453340] ? __sched_text_end+0x2/0x2 [ 15.453835] default_idle+0xf/0x20 [ 15.454259] do_idle+0x170/0x200 [ 15.454653] cpu_startup_entry+0x14/0x20 [ 15.455142] secondary_startup_64+0xa5/0xb0 [ 15.455715] Code: 1f 84 00 00 00 00 00 55 53 48 89 fd 48 83 ec 08 8b 87 bc 00 00 00 48 8b 8f c0 00 00 00 0f b6 97 81 00 00 00 48 8b 77 10 48 01 c8 <48> 8b 9 [ 15.458138] RIP: netif_skb_features+0x24/0x230 RSP: ffff88043fd83e70 [ 15.458933] CR2: 00000000000000d0 [ 15.459352] ---[ end trace 083925903ae60570 ]--- Fixes: 6b921536f170 ("net: sk_buff rbnode reorg") Cc: Stephen Hemminger <stephen(a)networkplumber.org> Cc: Eric Dumazet <edumazet(a)google.com> Cc: Soheil Hassas Yeganeh <soheil(a)google.com> Cc: Wei Wang <weiwan(a)google.com> Cc: Willem de Bruijn <willemb(a)google.com> Signed-off-by: Christoph Paasch <cpaasch(a)apple.com> --- Notes: This patch should only make it into v4.14-stable as that's the only branch where the offending commit has been backported to. net/sched/sch_netem.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/net/sched/sch_netem.c b/net/sched/sch_netem.c index 2a2ab6bfe5d8..3d325b840802 100644 --- a/net/sched/sch_netem.c +++ b/net/sched/sch_netem.c @@ -624,6 +624,10 @@ static struct sk_buff *netem_dequeue(struct Qdisc *sch) skb->next = NULL; skb->prev = NULL; skb->tstamp = netem_skb_cb(skb)->tstamp_save; + /* skb->dev shares skb->rbnode area, + * we need to restore its value. + */ + skb->dev = qdisc_dev(sch); #ifdef CONFIG_NET_CLS_ACT /* -- 2.16.2

6 years, 10 months

4
3
0 0

Automated testing for stable kernel branches?

by Major Hayden

Hello there, I am working on a project at Red Hat where we do quick testing on patches for internal kernels before they merge. The goal is to catch bugs or issues before they merge into kernel trees and avoid situations where kernels need time-consuming bisects when lots of patches are merged at once. We aim to put valuable feedback into a kernel developer's inbox within four hours. Our team has built a pipeline where we merge patches, compile kernels (for various architectures), and run tests on real hardware (various architectures). The current test set is fairly basic and it includes LTP plus some additional open source tests. We are looking to gradually expand those over time as we evaluate which tests provide the most value and find the most problems. We would love to bring this to upstream kernel repositories and we thought that linux-stable might be a good place to start. The developer/maintainer experience would look something like this: 1) Developer submits a patchset 2) Those patches end up in Patchwork 3) We pull patches from patchwork, compile kernels, and test them 4) We reply to the thread on the mailing list with a brief set of results (one time per patchset) Developers do not need to change any existing workflows. We gather the patches, test them, and reply in the appropriate place. Is this something that the linux-stable community and maintainers would find valuable? If so, feel free to ask any questions about our process and we can go over any of those parts in more detail. If not, please let me know anyway! Our team is always looking for ways to improve. :) Thanks a bunch for reading this far and I look forward to hearing from you. -- Major Hayden

6 years, 10 months

3
7
0 0

Re: Regression found (Stop-marking-clocks-as-CLK_IS_CRITICAL)

by Hans de Goede

Hi, On 31-10-18 07:02, Mogens Jensen wrote: > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Tuesday, October 30, 2018 7:10 PM, Hans de Goede <hdegoede(a)redhat.com> wrote: > >> Hi, >> >> On 30-10-18 19:56, Mogens Jensen wrote: >> >>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >>> On Tuesday, October 30, 2018 4:04 PM, Hans de Goede hdegoede(a)redhat.com wrote: >>> >>>> Hi, >>>> On 30-10-18 16:46, Hans de Goede wrote: >>>> >>>>> Hi, >>>>> On 30-10-18 16:04, Pierre-Louis Bossart wrote: >>>>> >>>>>> In addition I am not aware of any baytrail device using plt_clk_0, so moving a common machine driver such a cht_bsw_max98090_ti to use plt_clk0 only would break other devices (e.g. Rambi/Orco). Asking for both clocks to be on might work though, >>>>> >>>>> Ok, so we need to have a DMI based quirk for the Swanky and maybe also >>>>> the clapper to use plt_clk_0 there. Asking for 2 clks if we only need >>>>> one does not seem like a good plan. >>>> >>>> Dean, Mogens, >>>> To write a proper patch for this I'm going to need DMI strings >>>> from your devices. >>>> Can you please run (as normal user): >>>> grep . /sys/class/dmi/id/* 2> /dev/null >>>> And reply with the output of this command? >>>> I have attached the output from a coreboot seabios based clapper. >> >> Thank you. >> >>> Should I still test 0001-ASoC-intel-cht_bsw_max98090_ti-Use-pmc_plt_clk_0-ins.patch with SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH and asoundrc from Dean? There seems to have been some development in the case since that request was made. >> >> Yes please test that, I expect that to also fix things for the >> Clapper, but I need to have that confirmed before submitting a >> patch upstream adding a quirk for the Clapper to use pmc_plt_clk_0 >> instead of pmc_plt_clk_3. >> >> Regards, >> >> Hans >> > Unfortunately I only have access to longterm kernel 4.14 for building/running on this system, and 0001-ASoC-intel-cht_bsw_max98090_ti-Use-pmc_plt_clk_0-ins.patch does not patch against 4.14.78. Can a test patch for 4.14 be created? Can you run (as root): for i in /sys/kernel/debug/clk/pmc_plt_clk_?; do echo -n "$i: "; cat $i/clk_flags; echo; done When running a kernel with working audio? Then I can confirm that the Clapper is also using pmc_plt_clk_0, so that I can fix this for the clapper for 4.18+ I've just checked the 4.14 sources and in 4.14 the SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH driver does not support mclk control yet, so for the 4.14 kernel the only way to fix this is to revert the 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL") commit. Regards, Hans

6 years, 10 months

2
1
0 0

[PATCH] selftests/powerpc: Fix ptrace tm failure

by Breno Leitao

Test ptrace-tm-spd-gpr fails on current kernel (4.19) due to a segmentation fault that happens on the child process prior to setting cptr[2] = 1. This causes the parent process to wait forever at 'while (!pptr[2])' and the test to be killed by the test harness framework by timeout, thus, failing. The segmentation fault happens because of a inline assembly being generated as: 0x10000355c <tm_spd_gpr+492> lfs f0, 0(0) This is reading memory position 0x0 and causing the segmentation fault. This code is being generated by ASM_LOAD_FPR_SINGLE_PRECISION(flt_4), where flt_4 is passed to the inline assembly block as: [flt_4] "r" (&d) Since the inline assembly 'r' constraint means any GPR, gpr0 is being chosen, thus causing this issue when issuing a Load Floating-Point Single instruction. This patch simply changes the constraint to 'b', which specify that this register will be used as base, and r0 is not allowed to be used, avoiding this issue. Other than that, removing flt_2 register from the input operands, since it is not used by the inline assembly code at all. Cc: stable(a)vger.kernel.org Signed-off-by: Breno Leitao <leitao(a)debian.org> --- tools/testing/selftests/powerpc/ptrace/ptrace-tm-spd-gpr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/powerpc/ptrace/ptrace-tm-spd-gpr.c b/tools/testing/selftests/powerpc/ptrace/ptrace-tm-spd-gpr.c index 327fa943c7f3..dbdffa2e2c82 100644 --- a/tools/testing/selftests/powerpc/ptrace/ptrace-tm-spd-gpr.c +++ b/tools/testing/selftests/powerpc/ptrace/ptrace-tm-spd-gpr.c @@ -67,8 +67,8 @@ void tm_spd_gpr(void) "3: ;" : [res] "=r" (result), [texasr] "=r" (texasr) : [gpr_1]"i"(GPR_1), [gpr_2]"i"(GPR_2), [gpr_4]"i"(GPR_4), - [sprn_texasr] "i" (SPRN_TEXASR), [flt_1] "r" (&a), - [flt_2] "r" (&b), [flt_4] "r" (&d) + [sprn_texasr] "i" (SPRN_TEXASR), [flt_1] "b" (&a), + [flt_4] "b" (&d) : "memory", "r5", "r6", "r7", "r8", "r9", "r10", "r11", "r12", "r13", "r14", "r15", "r16", "r17", "r18", "r19", "r20", "r21", "r22", "r23", -- 2.19.0

6 years, 10 months

3
2
0 0

[patch 55/96] kbuild: fix kernel/bounds.c 'W=1' warning

by akpm＠linux-foundation.org

From: Arnd Bergmann <arnd(a)arndb.de> Subject: kbuild: fix kernel/bounds.c 'W=1' warning Building any configuration with 'make W=1' produces a warning: kernel/bounds.c:16:6: warning: no previous prototype for 'foo' [-Wmissing-prototypes] When also passing -Werror, this prevents us from building any other files. Nobody ever calls the function, but we can't make it 'static' either since we want the compiler output. Calling it 'main' instead however avoids the warning, because gcc does not insist on having a declaration for main. Link: http://lkml.kernel.org/r/20181005083313.2088252-1-arnd@arndb.de Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Reported-by: Kieran Bingham <kieran.bingham+renesas(a)ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas(a)ideasonboard.com> Cc: David Laight <David.Laight(a)ACULAB.COM> Cc: Masahiro Yamada <yamada.masahiro(a)socionext.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- kernel/bounds.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/kernel/bounds.c~kbuild-fix-kernel-boundsc-w=1-warning +++ a/kernel/bounds.c @@ -13,7 +13,7 @@ #include <linux/log2.h> #include <linux/spinlock_types.h> -void foo(void) +int main(void) { /* The enum constants to put into include/generated/bounds.h */ DEFINE(NR_PAGEFLAGS, __NR_PAGEFLAGS); @@ -23,4 +23,6 @@ void foo(void) #endif DEFINE(SPINLOCK_SIZE, sizeof(spinlock_t)); /* End of constants */ + + return 0; } _

6 years, 10 months

1
0
0 0

[patch 03/96] mm/hmm: fix race between hmm_mirror_unregister() and mmu_notifier callback

by akpm＠linux-foundation.org

From: Ralph Campbell <rcampbell(a)nvidia.com> Subject: mm/hmm: fix race between hmm_mirror_unregister() and mmu_notifier callback In hmm_mirror_unregister(), mm->hmm is set to NULL and then mmu_notifier_unregister_no_release() is called. That creates a small window where mmu_notifier can call mmu_notifier_ops with mm->hmm equal to NULL. Fix this by first unregistering mmu notifier callbacks and then setting mm->hmm to NULL. Similarly in hmm_register(), set mm->hmm before registering mmu_notifier callbacks so callback functions always see mm->hmm set. Link: http://lkml.kernel.org/r/20181019160442.18723-4-jglisse@redhat.com Signed-off-by: Ralph Campbell <rcampbell(a)nvidia.com> Signed-off-by: Jérôme Glisse <jglisse(a)redhat.com> Reviewed-by: John Hubbard <jhubbard(a)nvidia.com> Reviewed-by: Jérôme Glisse <jglisse(a)redhat.com> Reviewed-by: Balbir Singh <bsingharora(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/hmm.c | 36 +++++++++++++++++++++--------------- 1 file changed, 21 insertions(+), 15 deletions(-) --- a/mm/hmm.c~mm-hmm-fix-race-between-hmm_mirror_unregister-and-mmu_notifier-callback +++ a/mm/hmm.c @@ -91,16 +91,6 @@ static struct hmm *hmm_register(struct m spin_lock_init(&hmm->lock); hmm->mm = mm; - /* - * We should only get here if hold the mmap_sem in write mode ie on - * registration of first mirror through hmm_mirror_register() - */ - hmm->mmu_notifier.ops = &hmm_mmu_notifier_ops; - if (__mmu_notifier_register(&hmm->mmu_notifier, mm)) { - kfree(hmm); - return NULL; - } - spin_lock(&mm->page_table_lock); if (!mm->hmm) mm->hmm = hmm; @@ -108,12 +98,27 @@ static struct hmm *hmm_register(struct m cleanup = true; spin_unlock(&mm->page_table_lock); - if (cleanup) { - mmu_notifier_unregister(&hmm->mmu_notifier, mm); - kfree(hmm); - } + if (cleanup) + goto error; + + /* + * We should only get here if hold the mmap_sem in write mode ie on + * registration of first mirror through hmm_mirror_register() + */ + hmm->mmu_notifier.ops = &hmm_mmu_notifier_ops; + if (__mmu_notifier_register(&hmm->mmu_notifier, mm)) + goto error_mm; return mm->hmm; + +error_mm: + spin_lock(&mm->page_table_lock); + if (mm->hmm == hmm) + mm->hmm = NULL; + spin_unlock(&mm->page_table_lock); +error: + kfree(hmm); + return NULL; } void hmm_mm_destroy(struct mm_struct *mm) @@ -278,12 +283,13 @@ void hmm_mirror_unregister(struct hmm_mi if (!should_unregister || mm == NULL) return; + mmu_notifier_unregister_no_release(&hmm->mmu_notifier, mm); + spin_lock(&mm->page_table_lock); if (mm->hmm == hmm) mm->hmm = NULL; spin_unlock(&mm->page_table_lock); - mmu_notifier_unregister_no_release(&hmm->mmu_notifier, mm); kfree(hmm); } EXPORT_SYMBOL(hmm_mirror_unregister); _

6 years, 10 months

1
0
0 0

[patch 02/96] mm/rmap: map_pte() was not handling private ZONE_DEVICE page properly

by akpm＠linux-foundation.org

From: Ralph Campbell <rcampbell(a)nvidia.com> Subject: mm/rmap: map_pte() was not handling private ZONE_DEVICE page properly Private ZONE_DEVICE pages use a special pte entry and thus are not present. Properly handle this case in map_pte(), it is already handled in check_pte(), the map_pte() part was lost in some rebase most probably. Without this patch the slow migration path can not migrate back to any private ZONE_DEVICE memory to regular memory. This was found after stress testing migration back to system memory. This ultimatly can lead to the CPU constantly page fault looping on the special swap entry. Link: http://lkml.kernel.org/r/20181019160442.18723-3-jglisse@redhat.com Signed-off-by: Ralph Campbell <rcampbell(a)nvidia.com> Signed-off-by: Jérôme Glisse <jglisse(a)redhat.com> Reviewed-by: Balbir Singh <bsingharora(a)gmail.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/page_vma_mapped.c | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) --- a/mm/page_vma_mapped.c~mm-rmap-map_pte-was-not-handling-private-zone_device-page-properly-v3 +++ a/mm/page_vma_mapped.c @@ -21,7 +21,29 @@ static bool map_pte(struct page_vma_mapp if (!is_swap_pte(*pvmw->pte)) return false; } else { - if (!pte_present(*pvmw->pte)) + /* + * We get here when we are trying to unmap a private + * device page from the process address space. Such + * page is not CPU accessible and thus is mapped as + * a special swap entry, nonetheless it still does + * count as a valid regular mapping for the page (and + * is accounted as such in page maps count). + * + * So handle this special case as if it was a normal + * page mapping ie lock CPU page table and returns + * true. + * + * For more details on device private memory see HMM + * (include/linux/hmm.h or mm/hmm.c). + */ + if (is_swap_pte(*pvmw->pte)) { + swp_entry_t entry; + + /* Handle un-addressable ZONE_DEVICE memory */ + entry = pte_to_swp_entry(*pvmw->pte); + if (!is_device_private_entry(entry)) + return false; + } else if (!pte_present(*pvmw->pte)) return false; } } _

6 years, 10 months

1
0
0 0

Re: Regression found (Stop-marking-clocks-as-CLK_IS_CRITICAL)

by Hans de Goede

Hi, On 30-10-18 19:56, Mogens Jensen wrote: > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Tuesday, October 30, 2018 4:04 PM, Hans de Goede <hdegoede(a)redhat.com> wrote: > >> Hi, >> >> On 30-10-18 16:46, Hans de Goede wrote: >> >>> Hi, >>> On 30-10-18 16:04, Pierre-Louis Bossart wrote: >>> >>>> In addition I am not aware of any baytrail device using plt_clk_0, so moving a common machine driver such a cht_bsw_max98090_ti to use plt_clk0 only would break other devices (e.g. Rambi/Orco). Asking for both clocks to be on might work though, >>> >>> Ok, so we need to have a DMI based quirk for the Swanky and maybe also >>> the clapper to use plt_clk_0 there. Asking for 2 clks if we only need >>> one does not seem like a good plan. >> >> Dean, Mogens, >> >> To write a proper patch for this I'm going to need DMI strings >> from your devices. >> >> Can you please run (as normal user): >> >> grep . /sys/class/dmi/id/* 2> /dev/null >> >> And reply with the output of this command? > I have attached the output from a coreboot seabios based clapper. Thank you. > Should I still test 0001-ASoC-intel-cht_bsw_max98090_ti-Use-pmc_plt_clk_0-ins.patch with SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH and asoundrc from Dean? There seems to have been some development in the case since that request was made. Yes please test that, I expect that to also fix things for the Clapper, but I need to have that confirmed before submitting a patch upstream adding a quirk for the Clapper to use pmc_plt_clk_0 instead of pmc_plt_clk_3. Regards, Hans

6 years, 10 months

1
0
0 0

Re: [PATCH] soc: ti: QMSS: Fix usage of irq_set_affinity_hint

by Santosh Shilimkar

Hi Greg, On 10/30/2018 4:11 AM, Marc Zyngier wrote: > The Keystone QMSS driver is pretty damaged, in the sense that it > does things like this: > > irq_set_affinity_hint(irq, to_cpumask(&cpu_map)); > > where cpu_map is a local variable. As we leave the function, this > will point to nowhere-land, and things will end-up badly. > > Instead, let's use a proper cpumask that gets allocated, giving > the driver a chance to actually work with things like irqbalance > as well as have a hypothetical 64bit future. > > Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com> > --- > I found this one by inspection after finding a similar bug in an > unrelated driver. It is only compile-tested. It would probably > a Cc stable, but that's Santosh's decision. Would be able to apply this fix from Marc for stable or it needs to be re-posted with CC to stable ? > > drivers/soc/ti/knav_qmss.h | 4 ++-- > drivers/soc/ti/knav_qmss_acc.c | 10 +++++----- > drivers/soc/ti/knav_qmss_queue.c | 22 +++++++++++++++------- > 3 files changed, 22 insertions(+), 14 deletions(-) > > diff --git a/drivers/soc/ti/knav_qmss.h b/drivers/soc/ti/knav_qmss.h > index 3efc47e82973..bd040c29c4bf 100644 > --- a/drivers/soc/ti/knav_qmss.h > +++ b/drivers/soc/ti/knav_qmss.h > @@ -329,8 +329,8 @@ struct knav_range_ops { > }; > > struct knav_irq_info { > - int irq; > - u32 cpu_map; > + int irq; > + struct cpumask *cpu_mask; > }; > > struct knav_range_info { > diff --git a/drivers/soc/ti/knav_qmss_acc.c b/drivers/soc/ti/knav_qmss_acc.c > index 316e82e46f6c..2f7fb2dcc1d6 100644 > --- a/drivers/soc/ti/knav_qmss_acc.c > +++ b/drivers/soc/ti/knav_qmss_acc.c > @@ -205,18 +205,18 @@ static int knav_range_setup_acc_irq(struct knav_range_info *range, > { > struct knav_device *kdev = range->kdev; > struct knav_acc_channel *acc; > - unsigned long cpu_map; > + struct cpumask *cpu_mask; > int ret = 0, irq; > u32 old, new; > > if (range->flags & RANGE_MULTI_QUEUE) { > acc = range->acc; > irq = range->irqs[0].irq; > - cpu_map = range->irqs[0].cpu_map; > + cpu_mask = range->irqs[0].cpu_mask; > } else { > acc = range->acc + queue; > irq = range->irqs[queue].irq; > - cpu_map = range->irqs[queue].cpu_map; > + cpu_mask = range->irqs[queue].cpu_mask; > } > > old = acc->open_mask; > @@ -239,8 +239,8 @@ static int knav_range_setup_acc_irq(struct knav_range_info *range, > acc->name, acc->name); > ret = request_irq(irq, knav_acc_int_handler, 0, acc->name, > range); > - if (!ret && cpu_map) { > - ret = irq_set_affinity_hint(irq, to_cpumask(&cpu_map)); > + if (!ret && cpu_mask) { > + ret = irq_set_affinity_hint(irq, cpu_mask); > if (ret) { > dev_warn(range->kdev->dev, > "Failed to set IRQ affinity\n"); > diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c > index b5d5673c255c..8b418379272d 100644 > --- a/drivers/soc/ti/knav_qmss_queue.c > +++ b/drivers/soc/ti/knav_qmss_queue.c > @@ -118,19 +118,17 @@ static int knav_queue_setup_irq(struct knav_range_info *range, > struct knav_queue_inst *inst) > { > unsigned queue = inst->id - range->queue_base; > - unsigned long cpu_map; > int ret = 0, irq; > > if (range->flags & RANGE_HAS_IRQ) { > irq = range->irqs[queue].irq; > - cpu_map = range->irqs[queue].cpu_map; > ret = request_irq(irq, knav_queue_int_handler, 0, > inst->irq_name, inst); > if (ret) > return ret; > disable_irq(irq); > - if (cpu_map) { > - ret = irq_set_affinity_hint(irq, to_cpumask(&cpu_map)); > + if (range->irqs[queue].cpu_mask) { > + ret = irq_set_affinity_hint(irq, range->irqs[queue].cpu_mask); > if (ret) { > dev_warn(range->kdev->dev, > "Failed to set IRQ affinity\n"); > @@ -1262,9 +1260,19 @@ static int knav_setup_queue_range(struct knav_device *kdev, > > range->num_irqs++; > > - if (IS_ENABLED(CONFIG_SMP) && oirq.args_count == 3) > - range->irqs[i].cpu_map = > - (oirq.args[2] & 0x0000ff00) >> 8; > + if (IS_ENABLED(CONFIG_SMP) && oirq.args_count == 3) { > + unsigned long mask; > + int bit; > + > + range->irqs[i].cpu_mask = devm_kzalloc(dev, > + cpumask_size(), GFP_KERNEL); > + if (!range->irqs[i].cpu_mask) > + return -ENOMEM; > + > + mask = (oirq.args[2] & 0x0000ff00) >> 8; > + for_each_set_bit(bit, &mask, BITS_PER_LONG) > + cpumask_set_cpu(bit, range->irqs[i].cpu_mask); > + } > } > > range->num_irqs = min(range->num_irqs, range->num_queues); >

6 years, 10 months

3
2
0 0

Re: [PATCH] soc: ti: QMSS: Fix usage of irq_set_affinity_hint

by Santosh Shilimkar

Hi Arnd, Olof, On 10/30/2018 4:11 AM, Marc Zyngier wrote: > The Keystone QMSS driver is pretty damaged, in the sense that it > does things like this: > > irq_set_affinity_hint(irq, to_cpumask(&cpu_map)); > > where cpu_map is a local variable. As we leave the function, this > will point to nowhere-land, and things will end-up badly. > > Instead, let's use a proper cpumask that gets allocated, giving > the driver a chance to actually work with things like irqbalance > as well as have a hypothetical 64bit future. > > Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com> > --- Could you please add this patch to your fixes branch ? FWIW, Acked-by: Santosh Shilimkar <ssantosh(a)kernel.org>

6 years, 10 months

1
0
0 0

[PATCH] usb: dwc3: core: Clean up ULPI device

by Felipe Balbi

From: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> If dwc3_core_init_mode() fails with deferred probe, next probe fails on sysfs with sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:11.0/dwc3.0.auto/dwc3.0.auto.ulpi' To avoid this failure, clean up ULPI device. Cc: <stable(a)vger.kernel.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> --- drivers/usb/dwc3/core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 88c80fcc39f5..fec97465ccac 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -1499,6 +1499,7 @@ static int dwc3_probe(struct platform_device *pdev) err5: dwc3_event_buffers_cleanup(dwc); + dwc3_ulpi_exit(dwc); err4: dwc3_free_scratch_buffers(dwc); -- 2.19.1 --------------------------------------------------------------------- Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

6 years, 10 months

1
1
0 0

[PATCH AUTOSEL 3.18 1/5] sparc: Fix single-pcr perf event counter management.

by Sasha Levin

From: "David S. Miller" <davem(a)davemloft.net> [ Upstream commit cfdc3170d214046b9509183fe9b9544dc644d40b ] It is important to clear the hw->state value for non-stopped events when they are added into the PMU. Otherwise when the event is scheduled out, we won't read the counter because HES_UPTODATE is still set. This breaks 'perf stat' and similar use cases, causing all the events to show zero. This worked for multi-pcr because we make explicit sparc_pmu_start() calls in calculate_multiple_pcrs(). calculate_single_pcr() doesn't do this because the idea there is to accumulate all of the counter settings into the single pcr value. So we have to add explicit hw->state handling there. Like x86, we use the PERF_HES_ARCH bit to track truly stopped events so that we don't accidently start them on a reload. Related to all of this, sparc_pmu_start() is missing a userpage update so add it. Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/sparc/kernel/perf_event.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/arch/sparc/kernel/perf_event.c b/arch/sparc/kernel/perf_event.c index af53c25da2e7..8536532970bb 100644 --- a/arch/sparc/kernel/perf_event.c +++ b/arch/sparc/kernel/perf_event.c @@ -919,6 +919,8 @@ static void read_in_all_counters(struct cpu_hw_events *cpuc) sparc_perf_event_update(cp, &cp->hw, cpuc->current_idx[i]); cpuc->current_idx[i] = PIC_NO_INDEX; + if (cp->hw.state & PERF_HES_STOPPED) + cp->hw.state |= PERF_HES_ARCH; } } } @@ -951,10 +953,12 @@ static void calculate_single_pcr(struct cpu_hw_events *cpuc) enc = perf_event_get_enc(cpuc->events[i]); cpuc->pcr[0] &= ~mask_for_index(idx); - if (hwc->state & PERF_HES_STOPPED) + if (hwc->state & PERF_HES_ARCH) { cpuc->pcr[0] |= nop_for_index(idx); - else + } else { cpuc->pcr[0] |= event_encoding(enc, idx); + hwc->state = 0; + } } out: cpuc->pcr[0] |= cpuc->event[0]->hw.config_base; @@ -980,6 +984,9 @@ static void calculate_multiple_pcrs(struct cpu_hw_events *cpuc) cpuc->current_idx[i] = idx; + if (cp->hw.state & PERF_HES_ARCH) + continue; + sparc_pmu_start(cp, PERF_EF_RELOAD); } out: @@ -1071,6 +1078,8 @@ static void sparc_pmu_start(struct perf_event *event, int flags) event->hw.state = 0; sparc_pmu_enable_event(cpuc, &event->hw, idx); + + perf_event_update_userpage(event); } static void sparc_pmu_stop(struct perf_event *event, int flags) @@ -1363,9 +1372,9 @@ static int sparc_pmu_add(struct perf_event *event, int ef_flags) cpuc->events[n0] = event->hw.event_base; cpuc->current_idx[n0] = PIC_NO_INDEX; - event->hw.state = PERF_HES_UPTODATE; + event->hw.state = PERF_HES_UPTODATE | PERF_HES_STOPPED; if (!(ef_flags & PERF_EF_START)) - event->hw.state |= PERF_HES_STOPPED; + event->hw.state |= PERF_HES_ARCH; /* * If group events scheduling transaction was started, -- 2.17.1

6 years, 10 months

1
4
0 0

[PATCH AUTOSEL 4.4 1/6] sparc: Fix single-pcr perf event counter management.

by Sasha Levin

From: "David S. Miller" <davem(a)davemloft.net> [ Upstream commit cfdc3170d214046b9509183fe9b9544dc644d40b ] It is important to clear the hw->state value for non-stopped events when they are added into the PMU. Otherwise when the event is scheduled out, we won't read the counter because HES_UPTODATE is still set. This breaks 'perf stat' and similar use cases, causing all the events to show zero. This worked for multi-pcr because we make explicit sparc_pmu_start() calls in calculate_multiple_pcrs(). calculate_single_pcr() doesn't do this because the idea there is to accumulate all of the counter settings into the single pcr value. So we have to add explicit hw->state handling there. Like x86, we use the PERF_HES_ARCH bit to track truly stopped events so that we don't accidently start them on a reload. Related to all of this, sparc_pmu_start() is missing a userpage update so add it. Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/sparc/kernel/perf_event.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/arch/sparc/kernel/perf_event.c b/arch/sparc/kernel/perf_event.c index 6596f66ce112..a5d0c2f08110 100644 --- a/arch/sparc/kernel/perf_event.c +++ b/arch/sparc/kernel/perf_event.c @@ -926,6 +926,8 @@ static void read_in_all_counters(struct cpu_hw_events *cpuc) sparc_perf_event_update(cp, &cp->hw, cpuc->current_idx[i]); cpuc->current_idx[i] = PIC_NO_INDEX; + if (cp->hw.state & PERF_HES_STOPPED) + cp->hw.state |= PERF_HES_ARCH; } } } @@ -958,10 +960,12 @@ static void calculate_single_pcr(struct cpu_hw_events *cpuc) enc = perf_event_get_enc(cpuc->events[i]); cpuc->pcr[0] &= ~mask_for_index(idx); - if (hwc->state & PERF_HES_STOPPED) + if (hwc->state & PERF_HES_ARCH) { cpuc->pcr[0] |= nop_for_index(idx); - else + } else { cpuc->pcr[0] |= event_encoding(enc, idx); + hwc->state = 0; + } } out: cpuc->pcr[0] |= cpuc->event[0]->hw.config_base; @@ -987,6 +991,9 @@ static void calculate_multiple_pcrs(struct cpu_hw_events *cpuc) cpuc->current_idx[i] = idx; + if (cp->hw.state & PERF_HES_ARCH) + continue; + sparc_pmu_start(cp, PERF_EF_RELOAD); } out: @@ -1078,6 +1085,8 @@ static void sparc_pmu_start(struct perf_event *event, int flags) event->hw.state = 0; sparc_pmu_enable_event(cpuc, &event->hw, idx); + + perf_event_update_userpage(event); } static void sparc_pmu_stop(struct perf_event *event, int flags) @@ -1370,9 +1379,9 @@ static int sparc_pmu_add(struct perf_event *event, int ef_flags) cpuc->events[n0] = event->hw.event_base; cpuc->current_idx[n0] = PIC_NO_INDEX; - event->hw.state = PERF_HES_UPTODATE; + event->hw.state = PERF_HES_UPTODATE | PERF_HES_STOPPED; if (!(ef_flags & PERF_EF_START)) - event->hw.state |= PERF_HES_STOPPED; + event->hw.state |= PERF_HES_ARCH; /* * If group events scheduling transaction was started, -- 2.17.1

6 years, 10 months

1
5
0 0

[PATCH AUTOSEL 4.9 01/13] bpf: do not blindly change rlimit in reuseport net selftest

by Sasha Levin

From: Eric Dumazet <edumazet(a)google.com> [ Upstream commit 262f9d811c7608f1e74258ceecfe1fa213bdf912 ] If the current process has unlimited RLIMIT_MEMLOCK, we should should leave it as is. Fixes: 941ff6f11c02 ("bpf: fix rlimit in reuseport net selftest") Signed-off-by: John Sperbeck <jsperbeck(a)google.com> Signed-off-by: Eric Dumazet <edumazet(a)google.com> Acked-by: Daniel Borkmann <daniel(a)iogearbox.net> Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- tools/testing/selftests/net/reuseport_bpf.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/tools/testing/selftests/net/reuseport_bpf.c b/tools/testing/selftests/net/reuseport_bpf.c index cad14cd0ea92..b5277106df1f 100644 --- a/tools/testing/selftests/net/reuseport_bpf.c +++ b/tools/testing/selftests/net/reuseport_bpf.c @@ -437,14 +437,19 @@ void enable_fastopen(void) } } -static struct rlimit rlim_old, rlim_new; +static struct rlimit rlim_old; static __attribute__((constructor)) void main_ctor(void) { getrlimit(RLIMIT_MEMLOCK, &rlim_old); - rlim_new.rlim_cur = rlim_old.rlim_cur + (1UL << 20); - rlim_new.rlim_max = rlim_old.rlim_max + (1UL << 20); - setrlimit(RLIMIT_MEMLOCK, &rlim_new); + + if (rlim_old.rlim_cur != RLIM_INFINITY) { + struct rlimit rlim_new; + + rlim_new.rlim_cur = rlim_old.rlim_cur + (1UL << 20); + rlim_new.rlim_max = rlim_old.rlim_max + (1UL << 20); + setrlimit(RLIMIT_MEMLOCK, &rlim_new); + } } static __attribute__((destructor)) void main_dtor(void) -- 2.17.1

6 years, 10 months

1
12
0 0

[PATCH AUTOSEL 4.18 01/33] drm: fix use of freed memory in drm_mode_setcrtc

by Sasha Levin

From: Tomi Valkeinen <tomi.valkeinen(a)ti.com> [ Upstream commit 064253c1c0625efd0362a0b7ecdbe8bee2a2904d ] drm_mode_setcrtc() retries modesetting in case one of the functions it calls returns -EDEADLK. connector_set, mode and fb are freed before retrying, but they are not set to NULL. This can cause drm_mode_setcrtc() to use those variables. For example: On the first try __drm_mode_set_config_internal() returns -EDEADLK. connector_set, mode and fb are freed. Next retry starts, and drm_modeset_lock_all_ctx() returns -EDEADLK, and we jump to 'out'. The code will happily try to release all three again. This leads to crashes of different kinds, depending on the sequence the EDEADLKs happen. Fix this by setting the three variables to NULL at the start of the retry loop. Signed-off-by: Tomi Valkeinen <tomi.valkeinen(a)ti.com> Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180917110054.4053-1-tomi.va… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/drm_crtc.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 98a36e6c69ad..bd207857a964 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -560,9 +560,9 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data, struct drm_mode_crtc *crtc_req = data; struct drm_crtc *crtc; struct drm_plane *plane; - struct drm_connector **connector_set = NULL, *connector; - struct drm_framebuffer *fb = NULL; - struct drm_display_mode *mode = NULL; + struct drm_connector **connector_set, *connector; + struct drm_framebuffer *fb; + struct drm_display_mode *mode; struct drm_mode_set set; uint32_t __user *set_connectors_ptr; struct drm_modeset_acquire_ctx ctx; @@ -591,6 +591,10 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data, mutex_lock(&crtc->dev->mode_config.mutex); drm_modeset_acquire_init(&ctx, DRM_MODESET_ACQUIRE_INTERRUPTIBLE); retry: + connector_set = NULL; + fb = NULL; + mode = NULL; + ret = drm_modeset_lock_all_ctx(crtc->dev, &ctx); if (ret) goto out; -- 2.17.1

6 years, 10 months

1
32
0 0

[PATCH 2/2] selftests/ftrace: Fix synthetic event test to delete event correctly

by Steven Rostedt

From: Masami Hiramatsu <mhiramat(a)kernel.org> Fix the synthetic event test case to remove event correctly. If redirecting command to synthetic_event file without append mode, it cleans up all existing events and execute (parse) the command. This means "delete event" always fails to find the target event. Since previous synthetic event has a bug which doesn't return -ENOENT even if it fails to find the deleting event, this test passed. But fixing that bug, this test fails because this test itself has a bug. This fixes that bug by trying to delete event right after adding an event, and use append mode redirection ('>>') instead of normal redirection ('>'). Link: http://lkml.kernel.org/r/154013452832.25576.2305459545429386517.stgit@devbox Acked-by: Shuah Khan <shuah(a)kernel.org> Acked-by: Tom Zanussi <zanussi(a)linux.intel.com> Tested-by: Tom Zanussi <zanussi(a)linux.intel.com> Cc: Tom Zanussi <zanussi(a)kernel.org> Cc: Tom Zanussi <tom.zanussi(a)linux.intel.com> Cc: Rajvi Jingar <rajvi.jingar(a)intel.com> Cc: Shuah Khan <shuah(a)kernel.org> Cc: stable(a)vger.kernel.org Fixes: f06eec4d0f2c ('selftests: ftrace: Add inter-event hist triggers testcases') Signed-off-by: Masami Hiramatsu <mhiramat(a)kernel.org> Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org> --- .../trigger-synthetic-event-createremove.tc | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/tools/testing/selftests/ftrace/test.d/trigger/inter-event/trigger-synthetic-event-createremove.tc b/tools/testing/selftests/ftrace/test.d/trigger/inter-event/trigger-synthetic-event-createremove.tc index cef11377dcbd..c604438df13b 100644 --- a/tools/testing/selftests/ftrace/test.d/trigger/inter-event/trigger-synthetic-event-createremove.tc +++ b/tools/testing/selftests/ftrace/test.d/trigger/inter-event/trigger-synthetic-event-createremove.tc @@ -35,18 +35,18 @@ fi reset_trigger -echo "Test create synthetic event with an error" -echo 'wakeup_latency u64 lat pid_t pid char' > synthetic_events > /dev/null +echo "Test remove synthetic event" +echo '!wakeup_latency u64 lat pid_t pid char comm[16]' >> synthetic_events if [ -d events/synthetic/wakeup_latency ]; then - fail "Created wakeup_latency synthetic event with an invalid format" + fail "Failed to delete wakeup_latency synthetic event" fi reset_trigger -echo "Test remove synthetic event" -echo '!wakeup_latency u64 lat pid_t pid char comm[16]' > synthetic_events +echo "Test create synthetic event with an error" +echo 'wakeup_latency u64 lat pid_t pid char' > synthetic_events > /dev/null if [ -d events/synthetic/wakeup_latency ]; then - fail "Failed to delete wakeup_latency synthetic event" + fail "Created wakeup_latency synthetic event with an invalid format" fi do_reset -- 2.19.0

6 years, 10 months

1
0
0 0

[PATCH 1/2] tracing: Return -ENOENT if there is no target synthetic event

by Steven Rostedt

From: Masami Hiramatsu <mhiramat(a)kernel.org> Return -ENOENT error if there is no target synthetic event. This notices an operation failure to user as below; # echo 'wakeup_latency u64 lat; pid_t pid;' > synthetic_events # echo '!wakeup' >> synthetic_events sh: write error: No such file or directory Link: http://lkml.kernel.org/r/154013449986.25576.9487131386597290172.stgit@devbox Acked-by: Tom Zanussi <zanussi(a)linux.intel.com> Tested-by: Tom Zanussi <zanussi(a)linux.intel.com> Cc: Shuah Khan <shuah(a)kernel.org> Cc: Rajvi Jingar <rajvi.jingar(a)intel.com> Cc: stable(a)vger.kernel.org Fixes: 4b147936fa50 ('tracing: Add support for 'synthetic' events') Signed-off-by: Masami Hiramatsu <mhiramat(a)kernel.org> Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org> --- kernel/trace/trace_events_hist.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c index d239004aaf29..eb908ef2ecec 100644 --- a/kernel/trace/trace_events_hist.c +++ b/kernel/trace/trace_events_hist.c @@ -1063,8 +1063,10 @@ static int create_synth_event(int argc, char **argv) event = NULL; ret = -EEXIST; goto out; - } else if (delete_event) + } else if (delete_event) { + ret = -ENOENT; goto out; + } if (argc < 2) { ret = -EINVAL; -- 2.19.0

6 years, 10 months

1
0
0 0

[PATCH] serial: sh-sci: Fix could not remove dev_attr_rx_fifo_timeout

by Yoshihiro Shimoda

This patch fixes an issue that the sci_remove() could not remove dev_attr_rx_fifo_timeout because uart_remove_one_port() set the port->port.type to PORT_UNKNOWN. Reported-by: Hiromitsu Yamasaki <hiromitsu.yamasaki.ym(a)renesas.com> Fixes: 5d23188a473d ("serial: sh-sci: make RX FIFO parameters tunable via sysfs") Cc: <stable(a)vger.kernel.org> # v4.11+ Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com> --- drivers/tty/serial/sh-sci.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c index ab3f6e91..3649b83 100644 --- a/drivers/tty/serial/sh-sci.c +++ b/drivers/tty/serial/sh-sci.c @@ -3102,6 +3102,7 @@ static inline int sci_probe_earlyprintk(struct platform_device *pdev) static int sci_remove(struct platform_device *dev) { struct sci_port *port = platform_get_drvdata(dev); + unsigned int type = port->port.type; /* uart_remove_... clears it */ sci_ports_in_use &= ~BIT(port->port.line); uart_remove_one_port(&sci_uart_driver, &port->port); @@ -3112,8 +3113,7 @@ static int sci_remove(struct platform_device *dev) sysfs_remove_file(&dev->dev.kobj, &dev_attr_rx_fifo_trigger.attr); } - if (port->port.type == PORT_SCIFA || port->port.type == PORT_SCIFB || - port->port.type == PORT_HSCIF) { + if (type == PORT_SCIFA || type == PORT_SCIFB || type == PORT_HSCIF) { sysfs_remove_file(&dev->dev.kobj, &dev_attr_rx_fifo_timeout.attr); } -- 1.9.1

6 years, 10 months

2
1
0 0

[PATCH] drm/ast: fixed cursor may disappear sometimes

by Y.C. Chen

From: "Y.C. Chen" <yc_chen(a)aspeedtech.com> Signed-off-by: Y.C. Chen <yc_chen(a)aspeedtech.com> --- drivers/gpu/drm/ast/ast_mode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c index 5e77d45..4e079d4 100644 --- a/drivers/gpu/drm/ast/ast_mode.c +++ b/drivers/gpu/drm/ast/ast_mode.c @@ -1254,7 +1254,7 @@ static int ast_cursor_move(struct drm_crtc *crtc, ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xc7, ((y >> 8) & 0x07)); /* dummy write to fire HWC */ - ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xCB, 0xFF, 0x00); + ast_show_cursor(crtc); return 0; } -- 1.8.3.1

6 years, 10 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror