* Re: [LTP] [RFC PATCH] API: Allow testing of kernel features in development
From: Cyril Hrubis @ 2022-01-05 15:57 UTC (permalink / raw)
To: Richard Palethorpe; +Cc: ltp
In-Reply-To: <20211221113042.21357-1-rpalethorpe@suse.com>
Hi!
> Add an unstable kernel ABI flag and a runtest file for unstable
> tests. This means we can add tests which are likely to be broken by
> changes in the kernel ABI. Without disrupting LTP releases which are
> required to be stable.
>
> Users who require stability can filter the tests with this flag
> or not schedule the unstable runtest file(s).
>
> Signed-off-by: Richard Palethorpe <rpalethorpe@suse.com>
> ---
>
> How about adding this to the fanotify22 patch?
>
> include/tst_test.h | 12 ++++++++++++
> lib/tst_test.c | 6 ++++++
> runtest/syscalls-unstable | 3 +++
> 3 files changed, 21 insertions(+)
> create mode 100644 runtest/syscalls-unstable
>
> diff --git a/include/tst_test.h b/include/tst_test.h
> index 450ddf086..ff31e972e 100644
> --- a/include/tst_test.h
> +++ b/include/tst_test.h
> @@ -174,6 +174,18 @@ struct tst_test {
> int skip_in_lockdown:1;
> int skip_in_compat:1;
>
> + /*
> + * Test is for a feature that has not been added to the stable
> + * kernel ABI. That is, it's for a feature only available in
> + * linux-next, an RC or some other development branch.
> + *
> + * This string should be set to some text describing the
> + * kernel branch and version the test was developed
> + * against. e.g. "5.16 RC2", "linux-next-20211220",
> + * "net-next".
> + */
> + const char *const unstable_abi_version;
I would rather call this 'remove_after_release' or 'remove_after_kernel_release' but that is very minor.
> /*
> * The skip_filesystem is a NULL terminated list of filesystems the
> * test does not support. It can also be used to disable whole class of
> diff --git a/lib/tst_test.c b/lib/tst_test.c
> index 9b51bb5be..babb250d0 100644
> --- a/lib/tst_test.c
> +++ b/lib/tst_test.c
> @@ -1013,6 +1013,12 @@ static void do_setup(int argc, char *argv[])
> if (!tst_test)
> tst_brk(TBROK, "No tests to run");
>
> + if (tst_test->unstable_abi_version) {
> + tst_res(TINFO,
> + "This test was developed against pre-release kernel: %s",
> + tst_test->unstable_abi_version);
> + }
> +
> if (tst_test->tconf_msg)
> tst_brk(TCONF, "%s", tst_test->tconf_msg);
>
> diff --git a/runtest/syscalls-unstable b/runtest/syscalls-unstable
> new file mode 100644
> index 000000000..a87284afe
> --- /dev/null
> +++ b/runtest/syscalls-unstable
> @@ -0,0 +1,3 @@
> +# Tests for kernel features which are not finalized
> +
> +fanotify22 fanotify22
I would be even tempted to add this to the default syscalls runtest file
but render the test resultless, e.g. replace the tst_res() and tst_brk()
handlers in tst_res.c so that it will print only INFO messages.
--
Cyril Hrubis
chrubis@suse.cz
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: dsp: mediatek: add mt8195 dsp document
From: Daniel Baluta @ 2022-01-05 15:53 UTC (permalink / raw)
To: YC Hung
Cc: Mark Brown, Takashi Iwai, Rob Herring, matthias.bgg, Linux-ALSA,
linux-mediatek, linux-arm-kernel, Linux Kernel Mailing List,
Devicetree List, Daniel Baluta, trevor.wu, allen-kh.cheng,
Cezary Rojewski
In-Reply-To: <20220103043202.6524-1-yc.hung@mediatek.com>
On Mon, Jan 3, 2022 at 1:00 PM YC Hung <yc.hung@mediatek.com> wrote:
>
> From: "YC Hung" <yc.hung@mediatek.com>
>
> This patch adds mt8195 dsp document. The dsp is used for Sound Open
> Firmware driver node. It includes registers, clocks, memory regions,
> and mailbox for dsp.
>
> Signed-off-by: yc.hung <yc.hung@mediatek.com>
The code patch should be created against original source code from
Rob's tree. Here it seems the patch is against v2.
This isn't going to work! Because when Rob will try to apply the patch
it will fail since he doesn't have (and doesnt need to have)
your previous versions.
So, please keep the changes history (that's a good thing!) but always
rebase your patch on maintainer's tree.
> ---
> Changes since v2:
> Remove useless watchdog interrupt.
> Add commit message more detail description.
>
> Changes since v1:
> Rename yaml file name as mediatek,mt8195-dsp.yaml
> Refine descriptions for mailbox, memory-region and drop unused labels
> in examples.
> ---
> ---
> .../devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml | 12 ------------
> 1 file changed, 12 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml b/Documentation/devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml
> index bde763191d86..779daa786739 100644
> --- a/Documentation/devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml
> +++ b/Documentation/devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml
> @@ -27,14 +27,6 @@ properties:
> - const: cfg
> - const: sram
>
> - interrupts:
> - items:
> - - description: watchdog interrupt
> -
> - interrupt-names:
> - items:
> - - const: wdt
> -
> clocks:
> items:
> - description: mux for audio dsp clock
> @@ -75,8 +67,6 @@ required:
> - compatible
> - reg
> - reg-names
> - - interrupts
> - - interrupt-names
> - clocks
> - clock-names
> - memory-region
> @@ -95,8 +85,6 @@ examples:
> reg = <0x10803000 0x1000>,
> <0x10840000 0x40000>;
> reg-names = "cfg", "sram";
> - interrupts = <GIC_SPI 694 IRQ_TYPE_LEVEL_HIGH 0>;
> - interrupt-names = "wdt";
> clocks = <&topckgen 10>, //CLK_TOP_ADSP
> <&clk26m>,
> <&topckgen 107>, //CLK_TOP_AUDIO_LOCAL_BUS
> --
> 2.18.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: dsp: mediatek: add mt8195 dsp document
From: Daniel Baluta @ 2022-01-05 15:53 UTC (permalink / raw)
To: YC Hung
Cc: Devicetree List, Linux-ALSA, allen-kh.cheng, Cezary Rojewski,
Takashi Iwai, Rob Herring, Linux Kernel Mailing List, Mark Brown,
linux-mediatek, trevor.wu, matthias.bgg, Daniel Baluta,
linux-arm-kernel
In-Reply-To: <20220103043202.6524-1-yc.hung@mediatek.com>
On Mon, Jan 3, 2022 at 1:00 PM YC Hung <yc.hung@mediatek.com> wrote:
>
> From: "YC Hung" <yc.hung@mediatek.com>
>
> This patch adds mt8195 dsp document. The dsp is used for Sound Open
> Firmware driver node. It includes registers, clocks, memory regions,
> and mailbox for dsp.
>
> Signed-off-by: yc.hung <yc.hung@mediatek.com>
The code patch should be created against original source code from
Rob's tree. Here it seems the patch is against v2.
This isn't going to work! Because when Rob will try to apply the patch
it will fail since he doesn't have (and doesnt need to have)
your previous versions.
So, please keep the changes history (that's a good thing!) but always
rebase your patch on maintainer's tree.
> ---
> Changes since v2:
> Remove useless watchdog interrupt.
> Add commit message more detail description.
>
> Changes since v1:
> Rename yaml file name as mediatek,mt8195-dsp.yaml
> Refine descriptions for mailbox, memory-region and drop unused labels
> in examples.
> ---
> ---
> .../devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml | 12 ------------
> 1 file changed, 12 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml b/Documentation/devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml
> index bde763191d86..779daa786739 100644
> --- a/Documentation/devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml
> +++ b/Documentation/devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml
> @@ -27,14 +27,6 @@ properties:
> - const: cfg
> - const: sram
>
> - interrupts:
> - items:
> - - description: watchdog interrupt
> -
> - interrupt-names:
> - items:
> - - const: wdt
> -
> clocks:
> items:
> - description: mux for audio dsp clock
> @@ -75,8 +67,6 @@ required:
> - compatible
> - reg
> - reg-names
> - - interrupts
> - - interrupt-names
> - clocks
> - clock-names
> - memory-region
> @@ -95,8 +85,6 @@ examples:
> reg = <0x10803000 0x1000>,
> <0x10840000 0x40000>;
> reg-names = "cfg", "sram";
> - interrupts = <GIC_SPI 694 IRQ_TYPE_LEVEL_HIGH 0>;
> - interrupt-names = "wdt";
> clocks = <&topckgen 10>, //CLK_TOP_ADSP
> <&clk26m>,
> <&topckgen 107>, //CLK_TOP_AUDIO_LOCAL_BUS
> --
> 2.18.0
>
^ permalink raw reply
* Re: [PATCH 0/8] Support btime and other NFSv4 specific attributes
From: bfields @ 2022-01-05 15:54 UTC (permalink / raw)
To: Ondrej Valousek
Cc: Trond Myklebust, trondmy@kernel.org, linux-nfs@vger.kernel.org,
anna.schumaker@netapp.com
In-Reply-To: <DU2PR10MB5096501FB8A162D18CF1F1F2E14B9@DU2PR10MB5096.EURPRD10.PROD.OUTLOOK.COM>
On Wed, Jan 05, 2022 at 03:40:19PM +0000, Ondrej Valousek wrote:
>
> >> - AFAIK support for RFC8276 in NFS (only version 4.2) server is since kernel 5.9, right? NFS client supports these as well?
> >> - The patches below implements the feature in both, nfs client AND server, right?
>
> > Client only.
>
> Right, but then it will be only useful if we use non-linux based NFS server right?
>
> I mean simply:
> 1. $ stat /tmp/foo.txt --> shows birth date
> 2. # exportfs \*/tmp
> 3. # mount 127.0.0.1:/tmp /mnt
> 4. $ stat /mnt/foo.txt --> no birth date shown
Right.
Fixing that's likely just a few lines of code added to
fs/nfsd/nfs4xdr.c:nfsd4_encode_fattr(). Patches welcome.
--b.
^ permalink raw reply
* INFO: rcu detected stall in devkmsg_read
From: Sabri N. Ferreiro @ 2022-01-05 15:54 UTC (permalink / raw)
To: Petr Mladek, Sergey Senozhatsky, Steven Rostedt, John Ogness,
Kees Cook, Anton Vorontsov, Colin Cross, Tony Luck, linux-kernel
Cc: mosesfonscqf75
Hi,
When using Syzkaller to fuzz the Linux kernel, it triggers the following crash.
HEAD commit: a7904a538933 Linux 5.16-rc6
git tree: upstream
console output: https://paste.ubuntu.com/p/mdfS9m5C74/
kernel config: https://docs.google.com/document/d/1w94kqQ4ZSIE6BW-5WIhqp4_Zh7XTPH57L5OF2Xb6O6o/view
If you fix this issue, please add the following tag to the commit:
Reported-by: Yuheng Shen <mosesfonscqf75@gmail.com>
Sorry for my lack of this crash reproducer, I hope the symbolic report
will help you.
R13: 00007ffd0a4a0e08 R14: 000055d71ee2c958 R15: 0005d4cd3d2ed07c
</TASK>
Call Trace:
<IRQ>
x86_pmu_stop+0x11b/0x320 root/fuzz/kernel/5.16/arch/x86/events/core.c:1597
rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
x86_pmu_del+0x1a5/0x5b0 root/fuzz/kernel/5.16/arch/x86/events/core.c:1636
rcu: 1-....: (108 ticks this GP) idle=459/1/0x4000000000000000
softirq=39414/39414 fqs=4592
(detected by 3, t=21002 jiffies, g=40973, q=19739)
event_sched_out.part.0+0x1ea/0x820
root/fuzz/kernel/5.16/kernel/events/core.c:2285
Sending NMI from CPU 3 to CPUs 1:
NMI backtrace for cpu 1
CPU: 1 PID: 121 Comm: systemd-journal Not tainted 5.16.0-rc6 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:preempt_count_add+0x7/0x140
root/fuzz/kernel/5.16/kernel/sched/core.c:5422
Code: df 03 00 48 89 ef e8 68 81 04 00 48 8b 3d b1 ca b8 03 48 89 ee
5d e9 a8 2b 44 00 0f 1f 84 00 00 00 00 00 48 c7 c0 c0 ef 6d 92 <55> 48
ba 00 00 00 00 00 fc ff df 48 89 c1 53 83 e0 07 89 fb 48 c1
RSP: 0018:ffff8881f7289868 EFLAGS: 00000046
RAX: ffffffff926defc0 RBX: 1ffff1103ee5130e RCX: ffffffff8e253c25
RDX: ffff8881082bd3c0 RSI: 0000000000000000 RDI: 0000000000000001
RBP: ffffffff9269e980 R08: 0000000000000001 R09: ffffffff9269e30e
R10: fffffbfff24d3c61 R11: 0000000000000001 R12: ffff8881f7289940
R13: 0000000000014f2e R14: 0000000000014f2e R15: ffff8881f7289ad0
FS: 00007f3f4e83c8c0(0000) GS:ffff8881f7280000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f3f4a04b000 CR3: 0000000108138000 CR4: 0000000000350ee0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400
Call Trace:
<IRQ>
__raw_spin_lock
root/fuzz/kernel/5.16/./include/linux/spinlock_api_smp.h:132 [inline]
_raw_spin_lock+0x5e/0xd0 root/fuzz/kernel/5.16/kernel/locking/spinlock.c:154
console_lock_spinning_enable
root/fuzz/kernel/5.16/kernel/printk/printk.c:1776 [inline]
console_unlock+0x28e/0x8e0 root/fuzz/kernel/5.16/kernel/printk/printk.c:2708
vprintk_emit+0xf8/0x230 root/fuzz/kernel/5.16/kernel/printk/printk.c:2245
vprintk+0x69/0x80 root/fuzz/kernel/5.16/kernel/printk/printk_safe.c:50
_printk+0xba/0xed root/fuzz/kernel/5.16/kernel/printk/printk.c:2266
printk_stack_address
root/fuzz/kernel/5.16/arch/x86/kernel/dumpstack.c:72 [inline]
show_trace_log_lvl+0x263/0x2ca
root/fuzz/kernel/5.16/arch/x86/kernel/dumpstack.c:282
ex_handler_wrmsr_unsafe root/fuzz/kernel/5.16/arch/x86/mm/extable.c:87 [inline]
fixup_exception+0x3bb/0x690 root/fuzz/kernel/5.16/arch/x86/mm/extable.c:150
__exc_general_protection
root/fuzz/kernel/5.16/arch/x86/kernel/traps.c:601 [inline]
exc_general_protection+0xed/0x2e0
root/fuzz/kernel/5.16/arch/x86/kernel/traps.c:562
asm_exc_general_protection+0x1e/0x30
root/fuzz/kernel/5.16/./arch/x86/include/asm/idtentry.h:562
RIP: 0010:__wrmsr
root/fuzz/kernel/5.16/./arch/x86/include/asm/msr.h:103 [inline]
RIP: 0010:native_write_msr
root/fuzz/kernel/5.16/./arch/x86/include/asm/msr.h:160 [inline]
RIP: 0010:wrmsrl root/fuzz/kernel/5.16/./arch/x86/include/asm/msr.h:281 [inline]
RIP: 0010:x86_pmu_disable_event
root/fuzz/kernel/5.16/arch/x86/events/amd/../perf_event.h:1138
[inline]
RIP: 0010:amd_pmu_disable_event+0x83/0x280
root/fuzz/kernel/5.16/arch/x86/events/amd/core.c:639
Code: 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 e0 01
00 00 48 8b ab 78 01 00 00 4c 89 e2 44 89 e0 48 c1 ea 20 89 e9 <0f> 30
66 90 e8 34 4a 38 00 e8 2f 4a 38 00 48 8d bb 94 01 00 00 48
RSP: 0018:ffff8881f7289df8 EFLAGS: 00010016
RAX: 0000000000110076 RBX: ffff88810e915c88 RCX: 00000000c0010200
RDX: 0000000000000100 RSI: ffffffff90e07480 RDI: ffff88810e915e00
RBP: 00000000c0010200 R08: 0000000000000000 R09: ffff8881f72a19e7
R10: ffffed103ee5433c R11: 0000000000000001 R12: 0000010000110076
R13: 0000000000000000 R14: ffff8881f72a17e0 R15: ffff88810e915e14
x86_pmu_stop+0x11b/0x320 root/fuzz/kernel/5.16/arch/x86/events/core.c:1597
x86_pmu_del+0x1a5/0x5b0 root/fuzz/kernel/5.16/arch/x86/events/core.c:1636
event_sched_out.part.0+0x1ea/0x820
root/fuzz/kernel/5.16/kernel/events/core.c:2285
event_sched_out root/fuzz/kernel/5.16/kernel/events/core.c:2354 [inline]
__perf_remove_from_context+0x5c6/0x750
root/fuzz/kernel/5.16/kernel/events/core.c:2352
event_function+0x216/0x310 root/fuzz/kernel/5.16/kernel/events/core.c:253
remote_function root/fuzz/kernel/5.16/kernel/events/core.c:91 [inline]
remote_function+0x110/0x190 root/fuzz/kernel/5.16/kernel/events/core.c:71
flush_smp_call_function_queue+0x162/0x4f0
root/fuzz/kernel/5.16/kernel/smp.c:628
__sysvec_call_function_single+0x62/0x200
root/fuzz/kernel/5.16/arch/x86/kernel/smp.c:248
sysvec_call_function_single+0x89/0xc0
root/fuzz/kernel/5.16/arch/x86/kernel/smp.c:243
</IRQ>
<TASK>
asm_sysvec_call_function_single+0x12/0x20
root/fuzz/kernel/5.16/./arch/x86/include/asm/idtentry.h:646
RIP: 0010:bytes_is_nonzero root/fuzz/kernel/5.16/mm/kasan/generic.c:85 [inline]
RIP: 0010:memory_is_nonzero
root/fuzz/kernel/5.16/mm/kasan/generic.c:102 [inline]
RIP: 0010:memory_is_poisoned_n
root/fuzz/kernel/5.16/mm/kasan/generic.c:128 [inline]
RIP: 0010:memory_is_poisoned
root/fuzz/kernel/5.16/mm/kasan/generic.c:159 [inline]
RIP: 0010:check_region_inline
root/fuzz/kernel/5.16/mm/kasan/generic.c:180 [inline]
RIP: 0010:kasan_check_range+0x18e/0x1e0
root/fuzz/kernel/5.16/mm/kasan/generic.c:189
Code: 07 48 39 d0 7d 87 41 bb 01 00 00 00 5b 5d 44 89 d8 41 5c c3 48
85 d2 74 ed 48 01 ea eb 09 48 83 c0 01 48 39 d0 74 df 80 38 00 <74> f2
e9 32 ff ff ff 41 bb 01 00 00 00 44 89 d8 c3 48 29 c3 48 89
RSP: 0018:ffff888108c07b68 EFLAGS: 00000246
RAX: fffffbfff22dc768 RBX: fffffbfff22dc769 RCX: ffffffff8e254b5c
RDX: fffffbfff22dc769 RSI: 0000000000000008 RDI: ffffffff916e3b40
RBP: fffffbfff22dc768 R08: 0000000000000000 R09: ffffffff916e3b47
R10: fffffbfff22dc768 R11: 0000000000000001 R12: ffffffff916e3b40
R13: ffff888108c07c30 R14: ffff888108c07c50 R15: ffffffff916e3b20
instrument_atomic_read
root/fuzz/kernel/5.16/./include/linux/instrumented.h:71 [inline]
atomic_long_read
root/fuzz/kernel/5.16/./include/linux/atomic/atomic-instrumented.h:1183
[inline]
prb_first_seq root/fuzz/kernel/5.16/kernel/printk/printk_ringbuffer.c:1833
[inline]
_prb_read_valid+0x48c/0x660
root/fuzz/kernel/5.16/kernel/printk/printk_ringbuffer.c:1881
prb_read_valid+0x75/0xa0
root/fuzz/kernel/5.16/kernel/printk/printk_ringbuffer.c:1929
devkmsg_read+0x158/0x680 root/fuzz/kernel/5.16/kernel/printk/printk.c:730
vfs_read+0x13c/0x4c0 root/fuzz/kernel/5.16/fs/read_write.c:479
ksys_read+0x100/0x210 root/fuzz/kernel/5.16/fs/read_write.c:619
do_syscall_x64 root/fuzz/kernel/5.16/arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3b/0x90 root/fuzz/kernel/5.16/arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f3f4ddcd210
Code: 73 01 c3 48 8b 0d 98 7d 20 00 f7 d8 64 89 01 48 83 c8 ff c3 66
0f 1f 44 00 00 83 3d b9 c1 20 00 00 75 10 b8 00 00 00 00 0f 05 <48> 3d
01 f0 ff ff 73 31 c3 48 83 ec 08 e8 4e fc ff ff 48 89 04 24
RSP: 002b:00007ffd0a49e438 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
RAX: ffffffffffffffda RBX: 00007ffd0a4a0eb0 RCX: 00007f3f4ddcd210
RDX: 0000000000002000 RSI: 00007ffd0a49ecb0 RDI: 0000000000000009
RBP: 0000000000000000 R08: 000000000000e000 R09: 0000000000000007
R10: 0000000000000002 R11: 0000000000000246 R12: 00007ffd0a49ecb0
R13: 00007ffd0a4a0e08 R14: 000055d71ee2c958 R15: 0005d4cd3d2ed07c
</TASK>
event_sched_out root/fuzz/kernel/5.16/kernel/events/core.c:2354 [inline]
__perf_remove_from_context+0x5c6/0x750
root/fuzz/kernel/5.16/kernel/events/core.c:2352
event_function+0x216/0x310 root/fuzz/kernel/5.16/kernel/events/core.c:253
remote_function root/fuzz/kernel/5.16/kernel/events/core.c:91 [inline]
remote_function+0x110/0x190 root/fuzz/kernel/5.16/kernel/events/core.c:71
flush_smp_call_function_queue+0x162/0x4f0
root/fuzz/kernel/5.16/kernel/smp.c:628
__sysvec_call_function_single+0x62/0x200
root/fuzz/kernel/5.16/arch/x86/kernel/smp.c:248
sysvec_call_function_single+0x89/0xc0
root/fuzz/kernel/5.16/arch/x86/kernel/smp.c:243
</IRQ>
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: dsp: mediatek: add mt8195 dsp document
From: Daniel Baluta @ 2022-01-05 15:53 UTC (permalink / raw)
To: YC Hung
Cc: Mark Brown, Takashi Iwai, Rob Herring, matthias.bgg, Linux-ALSA,
linux-mediatek, linux-arm-kernel, Linux Kernel Mailing List,
Devicetree List, Daniel Baluta, trevor.wu, allen-kh.cheng,
Cezary Rojewski
In-Reply-To: <20220103043202.6524-1-yc.hung@mediatek.com>
On Mon, Jan 3, 2022 at 1:00 PM YC Hung <yc.hung@mediatek.com> wrote:
>
> From: "YC Hung" <yc.hung@mediatek.com>
>
> This patch adds mt8195 dsp document. The dsp is used for Sound Open
> Firmware driver node. It includes registers, clocks, memory regions,
> and mailbox for dsp.
>
> Signed-off-by: yc.hung <yc.hung@mediatek.com>
The code patch should be created against original source code from
Rob's tree. Here it seems the patch is against v2.
This isn't going to work! Because when Rob will try to apply the patch
it will fail since he doesn't have (and doesnt need to have)
your previous versions.
So, please keep the changes history (that's a good thing!) but always
rebase your patch on maintainer's tree.
> ---
> Changes since v2:
> Remove useless watchdog interrupt.
> Add commit message more detail description.
>
> Changes since v1:
> Rename yaml file name as mediatek,mt8195-dsp.yaml
> Refine descriptions for mailbox, memory-region and drop unused labels
> in examples.
> ---
> ---
> .../devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml | 12 ------------
> 1 file changed, 12 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml b/Documentation/devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml
> index bde763191d86..779daa786739 100644
> --- a/Documentation/devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml
> +++ b/Documentation/devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml
> @@ -27,14 +27,6 @@ properties:
> - const: cfg
> - const: sram
>
> - interrupts:
> - items:
> - - description: watchdog interrupt
> -
> - interrupt-names:
> - items:
> - - const: wdt
> -
> clocks:
> items:
> - description: mux for audio dsp clock
> @@ -75,8 +67,6 @@ required:
> - compatible
> - reg
> - reg-names
> - - interrupts
> - - interrupt-names
> - clocks
> - clock-names
> - memory-region
> @@ -95,8 +85,6 @@ examples:
> reg = <0x10803000 0x1000>,
> <0x10840000 0x40000>;
> reg-names = "cfg", "sram";
> - interrupts = <GIC_SPI 694 IRQ_TYPE_LEVEL_HIGH 0>;
> - interrupt-names = "wdt";
> clocks = <&topckgen 10>, //CLK_TOP_ADSP
> <&clk26m>,
> <&topckgen 107>, //CLK_TOP_AUDIO_LOCAL_BUS
> --
> 2.18.0
>
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: dsp: mediatek: add mt8195 dsp document
From: Daniel Baluta @ 2022-01-05 15:53 UTC (permalink / raw)
To: YC Hung
Cc: Mark Brown, Takashi Iwai, Rob Herring, matthias.bgg, Linux-ALSA,
linux-mediatek, linux-arm-kernel, Linux Kernel Mailing List,
Devicetree List, Daniel Baluta, trevor.wu, allen-kh.cheng,
Cezary Rojewski
In-Reply-To: <20220103043202.6524-1-yc.hung@mediatek.com>
On Mon, Jan 3, 2022 at 1:00 PM YC Hung <yc.hung@mediatek.com> wrote:
>
> From: "YC Hung" <yc.hung@mediatek.com>
>
> This patch adds mt8195 dsp document. The dsp is used for Sound Open
> Firmware driver node. It includes registers, clocks, memory regions,
> and mailbox for dsp.
>
> Signed-off-by: yc.hung <yc.hung@mediatek.com>
The code patch should be created against original source code from
Rob's tree. Here it seems the patch is against v2.
This isn't going to work! Because when Rob will try to apply the patch
it will fail since he doesn't have (and doesnt need to have)
your previous versions.
So, please keep the changes history (that's a good thing!) but always
rebase your patch on maintainer's tree.
> ---
> Changes since v2:
> Remove useless watchdog interrupt.
> Add commit message more detail description.
>
> Changes since v1:
> Rename yaml file name as mediatek,mt8195-dsp.yaml
> Refine descriptions for mailbox, memory-region and drop unused labels
> in examples.
> ---
> ---
> .../devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml | 12 ------------
> 1 file changed, 12 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml b/Documentation/devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml
> index bde763191d86..779daa786739 100644
> --- a/Documentation/devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml
> +++ b/Documentation/devicetree/bindings/dsp/mediatek,mt8195-dsp.yaml
> @@ -27,14 +27,6 @@ properties:
> - const: cfg
> - const: sram
>
> - interrupts:
> - items:
> - - description: watchdog interrupt
> -
> - interrupt-names:
> - items:
> - - const: wdt
> -
> clocks:
> items:
> - description: mux for audio dsp clock
> @@ -75,8 +67,6 @@ required:
> - compatible
> - reg
> - reg-names
> - - interrupts
> - - interrupt-names
> - clocks
> - clock-names
> - memory-region
> @@ -95,8 +85,6 @@ examples:
> reg = <0x10803000 0x1000>,
> <0x10840000 0x40000>;
> reg-names = "cfg", "sram";
> - interrupts = <GIC_SPI 694 IRQ_TYPE_LEVEL_HIGH 0>;
> - interrupt-names = "wdt";
> clocks = <&topckgen 10>, //CLK_TOP_ADSP
> <&clk26m>,
> <&topckgen 107>, //CLK_TOP_AUDIO_LOCAL_BUS
> --
> 2.18.0
>
^ permalink raw reply
* Re: [PATCH v4 2/2] watchdog: Add watchdog driver for Sunplus SP7021
From: Guenter Roeck @ 2022-01-05 15:53 UTC (permalink / raw)
To: xt.hu[胡先韬], Christophe JAILLET
Cc: wim@linux-watchdog.org, p.zabel@pengutronix.de,
linux-kernel@vger.kernel.org, linux-watchdog@vger.kernel.org,
devicetree@vger.kernel.org, Wells Lu 呂芳騰,
qinjian[覃健], Rob Herring
In-Reply-To: <17803809bef1499fb051cf79fc3c7245@cqplus1.com>
On 12/30/21 6:50 PM, xt.hu[胡先韬] wrote:
> Hi Chrustophe,
>
> Thanks for your respond.
>
> Best Regards,
> Xiantao
>> -----Original Message-----
>> From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
>> To: Xiantao Hu <xt.hu@cqplus1.com>,
>> wim@linux-watchdog.org, p.zabel@pengutronix.de,
>> linux-kernel@vger.kernel.org, linux-watchdog@vger.kernel.org,
>> linux@roeck-us.net, robh+dt@kernel.org,
>> devicetree@vger.kernel.org
>> Cc: wells.lu@sunplus.com, qinjian@cqplus1.com
>> Subject: Re: [PATCH v4 2/2] watchdog: Add watchdog driver for Sunplus SP7021
>> Date: Wed, 29 Dec 2021 10:39:08 +0100 [thread overview]
>> Message-ID: <0b102fa0-cbfc-a97e-8e7f-cce8146450bc@wanadoo.fr> (raw)
>> In-Reply-To: <20211229054308.63168-3-xt.hu@cqplus1.com>
>>
>> ...
>>
>>> +static int sp_wdt_probe(struct platform_device *pdev)
>>> +{
>>> + struct device *dev = &pdev->dev;
>>> + struct sp_wdt_priv *priv;
>>> + int err;
>>> +
>>> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
>>> + if (!priv)
>>> + return -ENOMEM;
>>> +
>>> + priv->clk = devm_clk_get(dev, NULL);
>>> + if (IS_ERR(priv->clk)) {
>>> + dev_err(dev, "Can't find clock source\n");
>>> + return PTR_ERR(priv->clk);
>>> + }
>>> +
>>> + err = clk_prepare_enable(priv->clk);
>>> + if (err) {
>>> + dev_err(dev, "Clock can't be enabled correctly\n");
>>> + return err;
>>> + }
>>> +
>>> + /* The timer and watchdog shared the STC reset */
>>> + priv->rstc = devm_reset_control_get_shared(dev, NULL);
>>> + if (!IS_ERR(priv->rstc))
>>> + reset_control_deassert(priv->rstc);
>>> +
>>> + err = devm_add_action_or_reset(dev, sp_reset_control_assert,
>>> + priv->rstc);
>>> + if (err)
>>> + return err;
>> This looks odd.
>> We could undo something that was not done. (if IS_ERR(priv->rstc))
>> This is also not really consistent with what is done in suspedn/resume.
>> In these functions, we don't check for IS_ERR(priv->rstc).
>>
>
> Here I refer to mt7621_wdt.c. I'm sure I need deassert reset to reset
> watchdog register value when driver probe. accordingly I assert reset
> in devm_add_action_or_reset() to ensure that the registers of watchdog
> can't be operated after module remove.
>
You are missing the point here. This is called even after
devm_reset_control_get_shared() failed, and it is called even though
the reset was not yet deasserted. The above code should be called after
(and only after) deasserting the reset.
>>> +
>>> + err = devm_add_action_or_reset(dev, sp_clk_disable_unprepare,
>>> + priv->clk);
>>> + if (err)
>>> + return err;
>> Shouldn't this be just after clk_prepare_enable()?
>
> I tested the order of execution of the added functions which is similar to
> push and pop. First in, last out. I think I should disable clock last.
>
Correct. That is why you have to call devm_add_action_or_reset on disable_unprepare
first, because on driver removal the devm_ cleanup will be called in reverse order.
Guenter
^ permalink raw reply
* Re: [PATCH net-next v4 3/8] net/funeth: probing and netdev ops
From: Dimitris Michailidis @ 2022-01-05 15:52 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: davem, netdev, Andrew Lunn
In-Reply-To: <20220104180739.572a80ac@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
On Tue, Jan 4, 2022 at 6:07 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Mon, 3 Jan 2022 22:46:52 -0800 Dimitris Michailidis wrote:
> > This is the first part of the Fungible ethernet driver. It deals with
> > device probing, net_device creation, and netdev ops.
>
> > +static int fun_xdp_setup(struct net_device *dev, struct netdev_bpf *xdp)
> > +{
> > + struct bpf_prog *old_prog, *prog = xdp->prog;
> > + struct funeth_priv *fp = netdev_priv(dev);
> > + bool reconfig;
> > + int rc, i;
> > +
> > + /* XDP uses at most one buffer */
> > + if (prog && dev->mtu > XDP_MAX_MTU) {
> > + netdev_err(dev, "device MTU %u too large for XDP\n", dev->mtu);
> > + NL_SET_ERR_MSG_MOD(xdp->extack,
> > + "Device MTU too large for XDP");
> > + return -EINVAL;
> > + }
> > +
> > + reconfig = netif_running(dev) && (!!fp->xdp_prog ^ !!prog);
> > + if (reconfig) {
> > + rc = funeth_close(dev);
>
> Please rework runtime reconfig to not do the close and then open thing.
> This will prevent users from reconfiguring their NICs at runtime.
> You should allocate the resources first, then take the datapath down,
> reconfigure, swap and free the old resources.
I imagine you have in mind something like nfp_net_ring_reconfig() but that
doesn't work as well here. We have the linux part of the data path (ring memory,
interrupts, etc) and the device part, handled by FW. I can't clone the device
portion for a quick swap during downtime. Since it involves messages to FW
updating the device portion is by far the bulk of the work and it needs to be
during the downtime. Doing Linux allocations before downtime offers little
improvement I think.
There is ongoing work for FW to be able to modify live queues. When that
is available I expect this function will be able to move in and out of XDP with
no downtime.
> > + if (rc) {
> > + NL_SET_ERR_MSG_MOD(xdp->extack,
> > + "Failed to reconfigure Rx queues.");
> > + return rc;
> > + }
> > + }
> > +
> > + dev->max_mtu = prog ? XDP_MAX_MTU : FUN_MAX_MTU;
> > + fp->num_xdpqs = prog ? num_online_cpus() : 0;
> > + old_prog = xchg(&fp->xdp_prog, prog);
> > +
> > + if (reconfig) {
> > + rc = funeth_open(dev);
> > + if (rc) {
> > + NL_SET_ERR_MSG_MOD(xdp->extack,
> > + "Failed to reconfigure Rx queues.");
> > + dev->max_mtu = old_prog ? XDP_MAX_MTU : FUN_MAX_MTU;
> > + fp->num_xdpqs = old_prog ? num_online_cpus() : 0;
> > + xchg(&fp->xdp_prog, old_prog);
> > + return rc;
> > + }
> > + } else if (netif_running(dev)) {
> > + struct funeth_rxq **rxqs = rtnl_dereference(fp->rxqs);
> > +
> > + for (i = 0; i < dev->real_num_rx_queues; i++)
> > + WRITE_ONCE(rxqs[i]->xdp_prog, prog);
> > + }
> > +
> > + if (old_prog)
> > + bpf_prog_put(old_prog);
> > + return 0;
> > +}
>
>
> > +static int fun_create_netdev(struct fun_ethdev *ed, unsigned int portid)
> > +{
> > + struct fun_dev *fdev = &ed->fdev;
> > + struct net_device *netdev;
> > + unsigned int ntx, nrx;
> > + struct funeth_priv *fp;
>
> rev xmas tree
OK
> > + int rc;
>
> > +static void fun_destroy_netdev(struct net_device *netdev)
> > +{
> > + if (likely(netdev)) {
>
> defensive programming?
Looks that way but I'd rather have this function work with any input.
> try to avoid wrapping the entire function in an if condition,
> return early instead.
Will do.
> > + struct funeth_priv *fp = netdev_priv(netdev);
> > +
> > + if (fp->dl_port.devlink) {
> > + devlink_port_type_clear(&fp->dl_port);
> > + devlink_port_unregister(&fp->dl_port);
> > + }
> > + unregister_netdev(netdev);
> > + fun_ktls_cleanup(fp);
> > + fun_free_stats_area(fp);
> > + fun_free_rss(fp);
> > + fun_port_destroy(netdev);
> > + free_netdev(netdev);
> > + }
> > +}
>
>
> > + if ((notif->link_state | notif->missed_events) & FUN_PORT_FLAG_MAC_DOWN)
> > + netif_carrier_off(netdev);
> > + if (notif->link_state & FUN_PORT_FLAG_NH_DOWN)
> > + netif_dormant_on(netdev);
> > + if (notif->link_state & FUN_PORT_FLAG_NH_UP)
> > + netif_dormant_off(netdev);
>
> What does this do?
FW may get exclusive access to the ports in some cases and during those times
host traffic isn't serviced. Changing a port to dormant is its way of
telling the host
the port is unavailable though it has link up.
>
> > + if (notif->link_state & FUN_PORT_FLAG_MAC_UP)
> > + netif_carrier_on(netdev);
> > +
> > + write_seqcount_end(&fp->link_seq);
> > + fun_report_link(netdev);
> > +}
>
> > +static int funeth_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> > +{
> > + struct devlink *devlink;
> > + struct fun_ethdev *ed;
> > + struct fun_dev *fdev;
> > + int rc;
> > +
> > + struct fun_dev_params aqreq = {
> > + .cqe_size_log2 = ilog2(ADMIN_CQE_SIZE),
> > + .sqe_size_log2 = ilog2(ADMIN_SQE_SIZE),
> > + .cq_depth = ADMIN_CQ_DEPTH,
> > + .sq_depth = ADMIN_SQ_DEPTH,
> > + .rq_depth = ADMIN_RQ_DEPTH,
> > + .min_msix = 2, /* 1 Rx + 1 Tx */
> > + .event_cb = fun_event_cb,
> > + .serv_cb = fun_service_cb,
> > + };
>
> no empty lines between variable declarations, you can make this the
> first variable instead since it has longest lines
OK
> > + devlink = fun_devlink_alloc(&pdev->dev);
> > + if (!devlink) {
> > + dev_err(&pdev->dev, "devlink alloc failed\n");
> > + return -ENOMEM;
> > + }
>
> > +static void __funeth_remove(struct pci_dev *pdev)
> > +{
> > + struct fun_dev *fdev = pci_get_drvdata(pdev);
> > + struct devlink *devlink;
> > + struct fun_ethdev *ed;
> > +
> > + if (!fdev)
> > + return;
>
> defensive programming, please remove
OK
> > + ed = to_fun_ethdev(fdev);
> > + devlink = priv_to_devlink(ed);
> > + fun_devlink_unregister(devlink);
> > +
> > +#ifdef CONFIG_PCI_IOV
> > + funeth_sriov_configure(pdev, 0);
> > +#endif
> > +
> > + fun_serv_stop(fdev);
> > + fun_destroy_ports(ed);
> > + fun_dev_disable(fdev);
> > +
> > + fun_devlink_free(devlink);
> > +}
> > +
> > +static void funeth_remove(struct pci_dev *pdev)
> > +{
> > + __funeth_remove(pdev);
> > +}
> > +
> > +static void funeth_shutdown(struct pci_dev *pdev)
> > +{
> > + __funeth_remove(pdev);
> > +}
>
> Why the two identical wrappers?
I've dropped them both and removed __ from __funeth_remove.
> > +static struct pci_driver funeth_driver = {
> > + .name = KBUILD_MODNAME,
> > + .id_table = funeth_id_table,
> > + .probe = funeth_probe,
> > + .remove = funeth_remove,
> > + .shutdown = funeth_shutdown,
> > + .sriov_configure = funeth_sriov_configure,
> > +};
> > +
> > +static int __init funeth_init(void)
> > +{
> > + int ret;
> > +
> > + ret = pci_register_driver(&funeth_driver);
> > + if (ret) {
> > + pr_err("%s pci_register_driver failed ret %d\n",
> > + KBUILD_MODNAME, ret);
>
> not worth it, plus you have unnecessary parenthesis here
>
> you can remove the print and use module_pci_driver()
OK.
>
> > + }
> > + return ret;
> > +}
> > +
> > +static void __exit funeth_exit(void)
> > +{
> > + pci_unregister_driver(&funeth_driver);
> > +}
> > +
> > +module_init(funeth_init);
> > +module_exit(funeth_exit);
>
>
^ permalink raw reply
* Re: [syzbot] WARNING in signalfd_cleanup
From: Eric Biggers @ 2022-01-05 15:52 UTC (permalink / raw)
To: Jens Axboe, Pavel Begunkov, io-uring
Cc: Eric Dumazet, syzbot, changbin.du, Daniel Borkmann, David Miller,
Heiner Kallweit, Jakub Kicinski, linux-fsdevel, LKML, netdev,
syzkaller-bugs, Al Viro, Yajun Deng
In-Reply-To: <CANn89iK3tP3rANSWM7_=imMeMcUknT0U2GyfA9W4v12ad6_PkQ@mail.gmail.com>
[+io_uring list and maintainers]
This appears to be the known bug in io_uring where it doesn't POLLFREE
notifications. See previous discussion:
https://lore.kernel.org/all/4a472e72-d527-db79-d46e-efa9d4cad5bb@kernel.dk/
On Wed, Jan 05, 2022 at 07:42:10AM -0800, 'Eric Dumazet' via syzkaller-bugs wrote:
> On Wed, Jan 5, 2022 at 7:37 AM syzbot
> <syzbot+5426c7ed6868c705ca14@syzkaller.appspotmail.com> wrote:
> >
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit: 6b8d4927540e Add linux-next specific files for 20220104
> > git tree: linux-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=159d88e3b00000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=45c9bbbf2ae8e3d3
> > dashboard link: https://syzkaller.appspot.com/bug?extid=5426c7ed6868c705ca14
> > compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=117be65db00000
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15a75c8db00000
> >
>
> C repro looks legit, point to an io_uring issue.
>
> > The issue was bisected to:
>
> Please ignore the bisection.
>
> >
> > commit e4b8954074f6d0db01c8c97d338a67f9389c042f
> > Author: Eric Dumazet <edumazet@google.com>
> > Date: Tue Dec 7 01:30:37 2021 +0000
> >
> > netlink: add net device refcount tracker to struct ethnl_req_info
> >
> > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=12bca4e3b00000
> > final oops: https://syzkaller.appspot.com/x/report.txt?x=11bca4e3b00000
> > console output: https://syzkaller.appspot.com/x/log.txt?x=16bca4e3b00000
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+5426c7ed6868c705ca14@syzkaller.appspotmail.com
> > Fixes: e4b8954074f6 ("netlink: add net device refcount tracker to struct ethnl_req_info")
> >
> > ------------[ cut here ]------------
> > WARNING: CPU: 0 PID: 3604 at kernel/sched/wait.c:245 __wake_up_pollfree+0x40/0x50 kernel/sched/wait.c:246
> > Modules linked in:
> > CPU: 0 PID: 3604 Comm: syz-executor714 Not tainted 5.16.0-rc8-next-20220104-syzkaller #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> > RIP: 0010:__wake_up_pollfree+0x40/0x50 kernel/sched/wait.c:245
> > Code: f3 ff ff 48 8d 6b 40 48 b8 00 00 00 00 00 fc ff df 48 89 ea 48 c1 ea 03 80 3c 02 00 75 11 48 8b 43 40 48 39 c5 75 03 5b 5d c3 <0f> 0b 5b 5d c3 48 89 ef e8 13 d8 69 00 eb e5 cc 48 c1 e7 06 48 63
> > RSP: 0018:ffffc90001aaf9f8 EFLAGS: 00010083
> > RAX: ffff88801cd623f0 RBX: ffff88801bec8048 RCX: 0000000000000000
> > RDX: 1ffff110037d9011 RSI: 0000000000000004 RDI: 0000000000000001
> > RBP: ffff88801bec8088 R08: 0000000000000000 R09: ffff88801bec804b
> > R10: ffffed10037d9009 R11: 0000000000000000 R12: ffff88801bec8040
> > R13: ffff88801e029d40 R14: dffffc0000000000 R15: ffff88807eb50000
> > FS: 00005555573ad300(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 00000000200000c0 CR3: 000000001e5e4000 CR4: 00000000003506f0
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > Call Trace:
> > <TASK>
> > wake_up_pollfree include/linux/wait.h:271 [inline]
> > signalfd_cleanup+0x42/0x60 fs/signalfd.c:38
> > __cleanup_sighand kernel/fork.c:1596 [inline]
> > __cleanup_sighand+0x72/0xb0 kernel/fork.c:1593
> > __exit_signal kernel/exit.c:159 [inline]
> > release_task+0xc02/0x17e0 kernel/exit.c:200
> > wait_task_zombie kernel/exit.c:1117 [inline]
> > wait_consider_task+0x2fa6/0x3b80 kernel/exit.c:1344
> > do_wait_thread kernel/exit.c:1407 [inline]
> > do_wait+0x6ca/0xce0 kernel/exit.c:1524
> > kernel_wait4+0x14c/0x260 kernel/exit.c:1687
> > __do_sys_wait4+0x13f/0x150 kernel/exit.c:1715
> > do_syscall_x64 arch/x86/entry/common.c:50 [inline]
> > do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
> > entry_SYSCALL_64_after_hwframe+0x44/0xae
> > RIP: 0033:0x7facd6682386
> > Code: 0f 1f 40 00 31 c9 e9 09 00 00 00 66 0f 1f 84 00 00 00 00 00 49 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 11 b8 3d 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 5a c3 90 48 83 ec 28 89 54 24 14 48 89 74 24
> > RSP: 002b:00007ffdb91adef8 EFLAGS: 00000246 ORIG_RAX: 000000000000003d
> > RAX: ffffffffffffffda RBX: 000000000000c646 RCX: 00007facd6682386
> > RDX: 0000000040000001 RSI: 00007ffdb91adf14 RDI: 00000000ffffffff
> > RBP: 0000000000000f17 R08: 0000000000000032 R09: 00007ffdb91ec080
> > R10: 0000000000000000 R11: 0000000000000246 R12: 431bde82d7b634db
> > R13: 00007ffdb91adf14 R14: 0000000000000000 R15: 0000000000000000
> > </TASK>
> >
> >
> > ---
> > This report is generated by a bot. It may contain errors.
> > See https://goo.gl/tpsmEJ for more information about syzbot.
> > syzbot engineers can be reached at syzkaller@googlegroups.com.
> >
> > syzbot will keep track of this issue. See:
> > https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> > syzbot can test patches for this issue, for details see:
> > https://goo.gl/tpsmEJ#testing-patches
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/CANn89iK3tP3rANSWM7_%3DimMeMcUknT0U2GyfA9W4v12ad6_PkQ%40mail.gmail.com.
^ permalink raw reply
* Re: [PATCH v5 4/6] drm/i915: Use vma resources for async unbinding
From: Matthew Auld @ 2022-01-05 15:52 UTC (permalink / raw)
To: Thomas Hellström, intel-gfx, dri-devel
In-Reply-To: <20220104125132.35179-5-thomas.hellstrom@linux.intel.com>
On 04/01/2022 12:51, Thomas Hellström wrote:
> Implement async (non-blocking) unbinding by not syncing the vma before
> calling unbind on the vma_resource.
> Add the resulting unbind fence to the object's dma_resv from where it is
> picked up by the ttm migration code.
> Ideally these unbind fences should be coalesced with the migration blit
> fence to avoid stalling the migration blit waiting for unbind, as they
> can certainly go on in parallel, but since we don't yet have a
> reasonable data structure to use to coalesce fences and attach the
> resulting fence to a timeline, we defer that for now.
>
> Note that with async unbinding, even while the unbind waits for the
> preceding bind to complete before unbinding, the vma itself might have been
> destroyed in the process, clearing the vma pages. Therefore we can
> only allow async unbinding if we have a refcounted sg-list and keep a
> refcount on that for the vma resource pages to stay intact until
> binding occurs. If this condition is not met, a request for an async
> unbind is diverted to a sync unbind.
>
> v2:
> - Use a separate kmem_cache for vma resources for now to isolate their
> memory allocation and aid debugging.
> - Move the check for vm closed to the actual unbinding thread. Regardless
> of whether the vm is closed, we need the unbind fence to properly wait
> for capture.
> - Clear vma_res::vm on unbind and update its documentation.
> v4:
> - Take cache coloring into account when searching for vma resources
> pending unbind. (Matthew Auld)
> v5:
> - Fix timeout and error check in i915_vma_resource_bind_dep_await().
> - Avoid taking a reference on the object for async binding if
> async unbind capable.
> - Fix braces around a single-line if statement.
>
> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
<snip>
> @@ -434,12 +439,30 @@ int i915_vma_bind(struct i915_vma *vma,
>
> bind_flags &= ~vma_flags;
> if (bind_flags == 0) {
> - kfree(vma_res);
> + i915_vma_resource_free(vma_res);
> return 0;
> }
>
> GEM_BUG_ON(!atomic_read(&vma->pages_count));
>
> + /* Wait for or await async unbinds touching our range */
> + if (work && bind_flags & vma->vm->bind_async_flags)
> + ret = i915_vma_resource_bind_dep_await(vma->vm,
> + &work->base.chain,
> + vma->node.start,
> + vma->node.size,
> + true,
> + GFP_NOWAIT |
> + __GFP_RETRY_MAYFAIL |
> + __GFP_NOWARN);
> + else
> + ret = i915_vma_resource_bind_dep_sync(vma->vm, vma->node.start,
> + vma->node.size, true);
> + if (ret) {
> + i915_vma_resource_free(vma_res);
> + return ret;
> + }
> +
> if (vma->resource || !vma_res) {
> /* Rebinding with an additional I915_VMA_*_BIND */
> GEM_WARN_ON(!vma_flags);
> @@ -452,9 +475,11 @@ int i915_vma_bind(struct i915_vma *vma,
> if (work && bind_flags & vma->vm->bind_async_flags) {
> struct dma_fence *prev;
>
> - work->vma = vma;
> + work->vma_res = i915_vma_resource_get(vma->resource);
> work->cache_level = cache_level;
> work->flags = bind_flags;
> + if (vma->obj->mm.rsgt)
> + work->rsgt = i915_refct_sgt_get(vma->obj->mm.rsgt);
Hmmm, at a glance I would have expected this to use the vma->pages. I
think with the GGTT the vma will often create its own sg layout which !=
obj->mm.sgt. IIUC the async unbind will still call vma_unbind_pages
which might nuke the vma sgt? Or is something else going on here?
^ permalink raw reply
* Re: [Intel-gfx] [PATCH v5 4/6] drm/i915: Use vma resources for async unbinding
From: Matthew Auld @ 2022-01-05 15:52 UTC (permalink / raw)
To: Thomas Hellström, intel-gfx, dri-devel
In-Reply-To: <20220104125132.35179-5-thomas.hellstrom@linux.intel.com>
On 04/01/2022 12:51, Thomas Hellström wrote:
> Implement async (non-blocking) unbinding by not syncing the vma before
> calling unbind on the vma_resource.
> Add the resulting unbind fence to the object's dma_resv from where it is
> picked up by the ttm migration code.
> Ideally these unbind fences should be coalesced with the migration blit
> fence to avoid stalling the migration blit waiting for unbind, as they
> can certainly go on in parallel, but since we don't yet have a
> reasonable data structure to use to coalesce fences and attach the
> resulting fence to a timeline, we defer that for now.
>
> Note that with async unbinding, even while the unbind waits for the
> preceding bind to complete before unbinding, the vma itself might have been
> destroyed in the process, clearing the vma pages. Therefore we can
> only allow async unbinding if we have a refcounted sg-list and keep a
> refcount on that for the vma resource pages to stay intact until
> binding occurs. If this condition is not met, a request for an async
> unbind is diverted to a sync unbind.
>
> v2:
> - Use a separate kmem_cache for vma resources for now to isolate their
> memory allocation and aid debugging.
> - Move the check for vm closed to the actual unbinding thread. Regardless
> of whether the vm is closed, we need the unbind fence to properly wait
> for capture.
> - Clear vma_res::vm on unbind and update its documentation.
> v4:
> - Take cache coloring into account when searching for vma resources
> pending unbind. (Matthew Auld)
> v5:
> - Fix timeout and error check in i915_vma_resource_bind_dep_await().
> - Avoid taking a reference on the object for async binding if
> async unbind capable.
> - Fix braces around a single-line if statement.
>
> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
<snip>
> @@ -434,12 +439,30 @@ int i915_vma_bind(struct i915_vma *vma,
>
> bind_flags &= ~vma_flags;
> if (bind_flags == 0) {
> - kfree(vma_res);
> + i915_vma_resource_free(vma_res);
> return 0;
> }
>
> GEM_BUG_ON(!atomic_read(&vma->pages_count));
>
> + /* Wait for or await async unbinds touching our range */
> + if (work && bind_flags & vma->vm->bind_async_flags)
> + ret = i915_vma_resource_bind_dep_await(vma->vm,
> + &work->base.chain,
> + vma->node.start,
> + vma->node.size,
> + true,
> + GFP_NOWAIT |
> + __GFP_RETRY_MAYFAIL |
> + __GFP_NOWARN);
> + else
> + ret = i915_vma_resource_bind_dep_sync(vma->vm, vma->node.start,
> + vma->node.size, true);
> + if (ret) {
> + i915_vma_resource_free(vma_res);
> + return ret;
> + }
> +
> if (vma->resource || !vma_res) {
> /* Rebinding with an additional I915_VMA_*_BIND */
> GEM_WARN_ON(!vma_flags);
> @@ -452,9 +475,11 @@ int i915_vma_bind(struct i915_vma *vma,
> if (work && bind_flags & vma->vm->bind_async_flags) {
> struct dma_fence *prev;
>
> - work->vma = vma;
> + work->vma_res = i915_vma_resource_get(vma->resource);
> work->cache_level = cache_level;
> work->flags = bind_flags;
> + if (vma->obj->mm.rsgt)
> + work->rsgt = i915_refct_sgt_get(vma->obj->mm.rsgt);
Hmmm, at a glance I would have expected this to use the vma->pages. I
think with the GGTT the vma will often create its own sg layout which !=
obj->mm.sgt. IIUC the async unbind will still call vma_unbind_pages
which might nuke the vma sgt? Or is something else going on here?
^ permalink raw reply
* [PATCH] Revert "net: usb: r8152: Add MAC passthrough support for more Lenovo Docks"
From: Aaron Ma @ 2022-01-05 15:51 UTC (permalink / raw)
To: aaron.ma, kuba, henning.schild, linux-usb, netdev, linux-kernel
Cc: davem, hayeswang, tiwai
This reverts commit f77b83b5bbab53d2be339184838b19ed2c62c0a5.
This change breaks multiple usb to ethernet dongles attached on Lenovo
USB hub.
Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
---
drivers/net/usb/r8152.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index f9877a3e83ac..4a02f33f0643 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -9603,9 +9603,12 @@ static int rtl8152_probe(struct usb_interface *intf,
netdev->hw_features &= ~NETIF_F_RXCSUM;
}
- if (udev->parent &&
- le16_to_cpu(udev->parent->descriptor.idVendor) == VENDOR_ID_LENOVO) {
- tp->lenovo_macpassthru = 1;
+ if (le16_to_cpu(udev->descriptor.idVendor) == VENDOR_ID_LENOVO) {
+ switch (le16_to_cpu(udev->descriptor.idProduct)) {
+ case DEVICE_ID_THINKPAD_THUNDERBOLT3_DOCK_GEN2:
+ case DEVICE_ID_THINKPAD_USB_C_DOCK_GEN2:
+ tp->lenovo_macpassthru = 1;
+ }
}
if (le16_to_cpu(udev->descriptor.bcdDevice) == 0x3011 && udev->serial &&
--
2.30.2
^ permalink raw reply related
* Re: [PATCH 08/11] PCI: mvebu: Use child_ops API
From: Pali Rohár @ 2022-01-05 15:49 UTC (permalink / raw)
To: Rob Herring
Cc: Lorenzo Pieralisi, Bjorn Helgaas, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King, PCI,
linux-kernel@vger.kernel.org, linux-arm-kernel
In-Reply-To: <CAL_Jsq+1hoAUVOzyOGZ1vVMsChhHJJpzk5HNU4Gi=Luy_8LArA@mail.gmail.com>
On Wednesday 05 January 2022 09:41:51 Rob Herring wrote:
> > @@ -347,6 +375,11 @@ static int mvebu_pcie_hw_wr_conf(struct mvebu_pcie_port *port,
> > return PCIBIOS_SUCCESSFUL;
> > }
> >
> > +static struct pci_ops mvebu_pcie_child_ops = {
> > + .read = mvebu_pcie_child_rd_conf,
> > + .write = mvebu_pcie_child_wr_conf,
> > +};
> > +
> > /*
> > * Remove windows, starting from the largest ones to the smallest
> > * ones.
> > @@ -862,25 +895,12 @@ static int mvebu_pcie_wr_conf(struct pci_bus *bus, u32 devfn,
> > {
> > struct mvebu_pcie *pcie = bus->sysdata;
> > struct mvebu_pcie_port *port;
> > - int ret;
> >
> > port = mvebu_pcie_find_port(pcie, bus, devfn);
> > if (!port)
> > return PCIBIOS_DEVICE_NOT_FOUND;
>
> It would be nice to go from 'bus' to 'bridge' ptr directly, but I
> still had this in my version. I guess a standard RP struct as part of
> decoupling host bridges from RPs would solve this issue.
Hello!
The problem is somewhere else. This driver is misusing bus 0 for doing
non-transparent bus-bridging between multiple PCI domains by registering
roots ports across all domains into domain 0, bus 0. All details are
in this my patch which documents this strange driver behavior:
https://lore.kernel.org/linux-pci/20211125124605.25915-12-pali@kernel.org/
So the correct solution is is split these multidomain mixing and then
every domain would have exactly one root port (as it is designed in HW).
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/1] builtin/pull.c: use config value of autostash
From: Johannes Schindelin @ 2022-01-05 15:50 UTC (permalink / raw)
To: John Cai; +Cc: git, Tilman Vogel, Philippe Blain
In-Reply-To: <20220104214522.10692-2-johncai86@gmail.com>
Hi John,
On Tue, 4 Jan 2022, John Cai wrote:
> Reported-by: "Tilman Vogel" <tilman.vogel@web.de>
> Co-authored-by: "Philippe Blain" <levraiphilippeblain@gmail.com>
> Signed-Off-by: "John Cai" <johncai86@gmail.com>
We spell the 'o' in 'Signed-off-by' with a lower-case 'o'. That's what
`git commit -s` does automatically.
Was this the problem why you stopped using GitGitGadget? It would also
have helped you avoid the frowned-upon cover letter for single patch
contributions.
The entire point of GitGitGadget is to _not_ force contributors to know
about all these things.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 08/11] PCI: mvebu: Use child_ops API
From: Pali Rohár @ 2022-01-05 15:49 UTC (permalink / raw)
To: Rob Herring
Cc: Lorenzo Pieralisi, Bjorn Helgaas, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King, PCI,
linux-kernel@vger.kernel.org, linux-arm-kernel
In-Reply-To: <CAL_Jsq+1hoAUVOzyOGZ1vVMsChhHJJpzk5HNU4Gi=Luy_8LArA@mail.gmail.com>
On Wednesday 05 January 2022 09:41:51 Rob Herring wrote:
> > @@ -347,6 +375,11 @@ static int mvebu_pcie_hw_wr_conf(struct mvebu_pcie_port *port,
> > return PCIBIOS_SUCCESSFUL;
> > }
> >
> > +static struct pci_ops mvebu_pcie_child_ops = {
> > + .read = mvebu_pcie_child_rd_conf,
> > + .write = mvebu_pcie_child_wr_conf,
> > +};
> > +
> > /*
> > * Remove windows, starting from the largest ones to the smallest
> > * ones.
> > @@ -862,25 +895,12 @@ static int mvebu_pcie_wr_conf(struct pci_bus *bus, u32 devfn,
> > {
> > struct mvebu_pcie *pcie = bus->sysdata;
> > struct mvebu_pcie_port *port;
> > - int ret;
> >
> > port = mvebu_pcie_find_port(pcie, bus, devfn);
> > if (!port)
> > return PCIBIOS_DEVICE_NOT_FOUND;
>
> It would be nice to go from 'bus' to 'bridge' ptr directly, but I
> still had this in my version. I guess a standard RP struct as part of
> decoupling host bridges from RPs would solve this issue.
Hello!
The problem is somewhere else. This driver is misusing bus 0 for doing
non-transparent bus-bridging between multiple PCI domains by registering
roots ports across all domains into domain 0, bus 0. All details are
in this my patch which documents this strange driver behavior:
https://lore.kernel.org/linux-pci/20211125124605.25915-12-pali@kernel.org/
So the correct solution is is split these multidomain mixing and then
every domain would have exactly one root port (as it is designed in HW).
^ permalink raw reply
* [kbd] Characters '<', '>' etc. with German layout
From: R. Diez @ 2022-01-05 15:49 UTC (permalink / raw)
To: kbd
In-Reply-To: <288cad40-8cbb-33af-85a5-3ee651eed3f1.ref@yahoo.de>
Hi all:
I am using Ubuntu 20.04.4, with the MATE Desktop Environment, on a Lenovo ThinkPad T440s laptop.
I believe that the right keyboard model for this laptop is a "Lenovo (previously IBM)", "IBM Space Saver".
On xkeycaps, I think the right model is "IBM", "ThinkPad 770".
I have 2 keyboard layouts installed: Spanish and German, and I am having difficulty typing some common ASCII characters like '<', '>', the pipe symbol '|', etc. That is very annoying when working on a shell console.
When using the Spanish layout, I can get '<' and '>' by holding the right Alt key and one of the shift keys, and then pressing 'x' or 'z' (it may be 'y', because 'y' and 'z' and swapped on German keyboards).
However, when using the German layout, the same key combinations generate some Unicode variant of '<' and '>', namely '‹' and '›', which the shell does not recognise as redirection indicators.
I haven't managed to type the pipe symbol ('|') yet with the German layout, so I am constantly switching layouts.
Is there an easy way to fix these annoyances? Or do I have to learn how to create my own keyboard layouts?
I am completely unfamiliar with Linux keyboard support. Is the kbd project the right place to ask at all?
Thanks in advance,
rdiez
^ permalink raw reply
* [Intel-wired-lan] [next-queue, v2] i40e: Remove unused RX realloc stat
From: Joe Damato @ 2022-01-05 15:49 UTC (permalink / raw)
To: intel-wired-lan
After commit 1a557afc4dd5 ("i40e: Refactor receive routine"),
rx_stats.realloc_count is no longer being incremented, so remove it.
The debugfs string was left, but hardcoded to 0. This is intended to
prevent breaking any existing code / scripts that are parsing debugfs
for i40e.
Fixes: 1a557afc4dd5 ("i40e: Refactor receive routine")
Signed-off-by: Joe Damato <jdamato@fastly.com>
---
v1 -> v2: Fix commit message to include one-line SHA summary. Patch is now
based on next-queue.
---
drivers/net/ethernet/intel/i40e/i40e_debugfs.c | 3 +--
drivers/net/ethernet/intel/i40e/i40e_txrx.h | 1 -
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
index 1e57cc8..90fff05 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
@@ -275,9 +275,8 @@ static void i40e_dbg_dump_vsi_seid(struct i40e_pf *pf, int seid)
rx_ring->rx_stats.alloc_page_failed,
rx_ring->rx_stats.alloc_buff_failed);
dev_info(&pf->pdev->dev,
- " rx_rings[%i]: rx_stats: realloc_count = %lld, page_reuse_count = %lld\n",
+ " rx_rings[%i]: rx_stats: realloc_count = 0, page_reuse_count = %lld\n",
i,
- rx_ring->rx_stats.realloc_count,
rx_ring->rx_stats.page_reuse_count);
dev_info(&pf->pdev->dev,
" rx_rings[%i]: size = %i\n",
diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.h b/drivers/net/ethernet/intel/i40e/i40e_txrx.h
index fd22e2f..324699e 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.h
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.h
@@ -298,7 +298,6 @@ struct i40e_rx_queue_stats {
u64 alloc_page_failed;
u64 alloc_buff_failed;
u64 page_reuse_count;
- u64 realloc_count;
u64 page_alloc_count;
u64 page_waive_count;
u64 page_busy_count;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] drivers/hwmon: remove redundant res variable
From: Guenter Roeck @ 2022-01-05 15:48 UTC (permalink / raw)
To: cgel.zte, jdelvare; +Cc: linux-hwmon, linux-kernel, Minghao Chi, Zeal Robot
In-Reply-To: <20220104112818.602025-1-chi.minghao@zte.com.cn>
On 1/4/22 3:28 AM, cgel.zte@gmail.com wrote:
> From: Minghao Chi <chi.minghao@zte.com.cn>
>
> Return value from inb_p() directly instead
> of taking this in another redundant variable.
>
> Reported-by: Zeal Robot <zealci@zte.com.cn>
> Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn>
> Signed-off-by: CGEL ZTE <cgel.zte@gmail.com>
Please do not send me such patches. The subject starts with the wrong tag
(it should have been "hwmon: (nct6683)", it is misleading (the variable is
not redundant; if anything it is unnecessary), and the patch itself adds
zero value. The submitter may have had a reason for using a variable,
may it be personal style or ease of adding a debug statement when testing.
There is no valid reason for changing such code.
Guenter
> ---
> drivers/hwmon/nct6683.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/hwmon/nct6683.c b/drivers/hwmon/nct6683.c
> index 6a9f420e7d32..ab02e967f73d 100644
> --- a/drivers/hwmon/nct6683.c
> +++ b/drivers/hwmon/nct6683.c
> @@ -495,13 +495,10 @@ static inline long in_from_reg(u16 reg, u8 src)
>
> static u16 nct6683_read(struct nct6683_data *data, u16 reg)
> {
> - int res;
> -
> outb_p(0xff, data->addr + EC_PAGE_REG); /* unlock */
> outb_p(reg >> 8, data->addr + EC_PAGE_REG);
> outb_p(reg & 0xff, data->addr + EC_INDEX_REG);
> - res = inb_p(data->addr + EC_DATA_REG);
> - return res;
> + return inb_p(data->addr + EC_DATA_REG);
> }
>
> static u16 nct6683_read16(struct nct6683_data *data, u16 reg)
>
^ permalink raw reply
* Re: [PATCH 1/4] drm/i915: don't call free_mmap_offset when purging
From: Thomas Hellström @ 2022-01-05 15:46 UTC (permalink / raw)
To: Matthew Auld, intel-gfx; +Cc: dri-devel
In-Reply-To: <20220105145835.142950-1-matthew.auld@intel.com>
On Wed, 2022-01-05 at 14:58 +0000, Matthew Auld wrote:
> The TTM backend is in theory the only user here(also purge should
> only
> be called once we have dropped the pages), where it is setup at
> object
> creation and is only removed once the object is destroyed. Also
> resetting the node here might be iffy since the ttm fault handler
> uses the stored fake offset to determine the page offset within the
> pages
> array.
>
> This also blows up in the dontneed-before-mmap test, since the
> expectation is that the vma_node will live on, until the object is
> destroyed:
>
> <2> [749.062902] kernel BUG at
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c:943!
> <4> [749.062923] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
> <4> [749.062928] CPU: 0 PID: 1643 Comm: gem_madvise Tainted: G U
> W 5.16.0-rc8-CI-CI_DRM_11046+ #1
> <4> [749.062933] Hardware name: Gigabyte Technology Co., Ltd. GB-Z390
> Garuda/GB-Z390 Garuda-CF, BIOS IG1c 11/19/2019
> <4> [749.062937] RIP: 0010:i915_ttm_mmap_offset.cold.35+0x5b/0x5d
> [i915]
> <4> [749.063044] Code: 00 48 c7 c2 a0 23 4e a0 48 c7 c7 26 df 4a a0
> e8 95 1d d0 e0 bf 01 00 00 00 e8 8b ec cf e0 31 f6 bf 09 00 00 00 e8
> 5f 30 c0 e0 <0f> 0b 48 c7 c1 24 4b 56 a0 ba 5b 03 00 00 48 c7 c6 c0
> 23 4e a0 48
> <4> [749.063052] RSP: 0018:ffffc90002ab7d38 EFLAGS: 00010246
> <4> [749.063056] RAX: 0000000000000240 RBX: ffff88811f2e61c0 RCX:
> 0000000000000006
> <4> [749.063060] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
> 0000000000000009
> <4> [749.063063] RBP: ffffc90002ab7e58 R08: 0000000000000001 R09:
> 0000000000000001
> <4> [749.063067] R10: 000000000123d0f8 R11: ffffc90002ab7b20 R12:
> ffff888112a1a000
> <4> [749.063071] R13: 0000000000000004 R14: ffff88811f2e61c0 R15:
> ffff888112a1a000
> <4> [749.063074] FS: 00007f6e5fcad500(0000)
> GS:ffff8884ad600000(0000) knlGS:0000000000000000
> <4> [749.063078] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> <4> [749.063081] CR2: 00007efd264e39f0 CR3: 0000000115fd6005 CR4:
> 00000000003706f0
> <4> [749.063085] Call Trace:
> <4> [749.063087] <TASK>
> <4> [749.063089] __assign_mmap_offset+0x41/0x300 [i915]
> <4> [749.063171] __assign_mmap_offset_handle+0x159/0x270 [i915]
> <4> [749.063248] ? i915_gem_dumb_mmap_offset+0x70/0x70 [i915]
> <4> [749.063325] drm_ioctl_kernel+0xae/0x140
> <4> [749.063330] drm_ioctl+0x201/0x3d0
> <4> [749.063333] ? i915_gem_dumb_mmap_offset+0x70/0x70 [i915]
> <4> [749.063409] ? do_user_addr_fault+0x200/0x670
> <4> [749.063415] __x64_sys_ioctl+0x6d/0xa0
> <4> [749.063419] do_syscall_64+0x3a/0xb0
> <4> [749.063423] entry_SYSCALL_64_after_hwframe+0x44/0xae
> <4> [749.063428] RIP: 0033:0x7f6e5f100317
>
> Testcase: igt@gem_madvise@dontneed-before-mmap
> Fixes: cf3e3e86d779 ("drm/i915: Use ttm mmap handling for ttm bo's.")
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> ---
> drivers/gpu/drm/i915/gem/i915_gem_pages.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> index 89b70f5cde7a..9f429ed6e78a 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> @@ -161,7 +161,6 @@ int i915_gem_object_pin_pages_unlocked(struct
> drm_i915_gem_object *obj)
> /* Immediately discard the backing storage */
> int i915_gem_object_truncate(struct drm_i915_gem_object *obj)
> {
> - drm_gem_free_mmap_offset(&obj->base);
What happens if a non-ttm shmem system object gets truncated from the
shrinker and then tries to use the above mmap offset?
/Thomas
> if (obj->ops->truncate)
> return obj->ops->truncate(obj);
>
^ permalink raw reply
* Re: [Intel-gfx] [PATCH 1/4] drm/i915: don't call free_mmap_offset when purging
From: Thomas Hellström @ 2022-01-05 15:46 UTC (permalink / raw)
To: Matthew Auld, intel-gfx; +Cc: dri-devel
In-Reply-To: <20220105145835.142950-1-matthew.auld@intel.com>
On Wed, 2022-01-05 at 14:58 +0000, Matthew Auld wrote:
> The TTM backend is in theory the only user here(also purge should
> only
> be called once we have dropped the pages), where it is setup at
> object
> creation and is only removed once the object is destroyed. Also
> resetting the node here might be iffy since the ttm fault handler
> uses the stored fake offset to determine the page offset within the
> pages
> array.
>
> This also blows up in the dontneed-before-mmap test, since the
> expectation is that the vma_node will live on, until the object is
> destroyed:
>
> <2> [749.062902] kernel BUG at
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c:943!
> <4> [749.062923] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
> <4> [749.062928] CPU: 0 PID: 1643 Comm: gem_madvise Tainted: G U
> W 5.16.0-rc8-CI-CI_DRM_11046+ #1
> <4> [749.062933] Hardware name: Gigabyte Technology Co., Ltd. GB-Z390
> Garuda/GB-Z390 Garuda-CF, BIOS IG1c 11/19/2019
> <4> [749.062937] RIP: 0010:i915_ttm_mmap_offset.cold.35+0x5b/0x5d
> [i915]
> <4> [749.063044] Code: 00 48 c7 c2 a0 23 4e a0 48 c7 c7 26 df 4a a0
> e8 95 1d d0 e0 bf 01 00 00 00 e8 8b ec cf e0 31 f6 bf 09 00 00 00 e8
> 5f 30 c0 e0 <0f> 0b 48 c7 c1 24 4b 56 a0 ba 5b 03 00 00 48 c7 c6 c0
> 23 4e a0 48
> <4> [749.063052] RSP: 0018:ffffc90002ab7d38 EFLAGS: 00010246
> <4> [749.063056] RAX: 0000000000000240 RBX: ffff88811f2e61c0 RCX:
> 0000000000000006
> <4> [749.063060] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
> 0000000000000009
> <4> [749.063063] RBP: ffffc90002ab7e58 R08: 0000000000000001 R09:
> 0000000000000001
> <4> [749.063067] R10: 000000000123d0f8 R11: ffffc90002ab7b20 R12:
> ffff888112a1a000
> <4> [749.063071] R13: 0000000000000004 R14: ffff88811f2e61c0 R15:
> ffff888112a1a000
> <4> [749.063074] FS: 00007f6e5fcad500(0000)
> GS:ffff8884ad600000(0000) knlGS:0000000000000000
> <4> [749.063078] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> <4> [749.063081] CR2: 00007efd264e39f0 CR3: 0000000115fd6005 CR4:
> 00000000003706f0
> <4> [749.063085] Call Trace:
> <4> [749.063087] <TASK>
> <4> [749.063089] __assign_mmap_offset+0x41/0x300 [i915]
> <4> [749.063171] __assign_mmap_offset_handle+0x159/0x270 [i915]
> <4> [749.063248] ? i915_gem_dumb_mmap_offset+0x70/0x70 [i915]
> <4> [749.063325] drm_ioctl_kernel+0xae/0x140
> <4> [749.063330] drm_ioctl+0x201/0x3d0
> <4> [749.063333] ? i915_gem_dumb_mmap_offset+0x70/0x70 [i915]
> <4> [749.063409] ? do_user_addr_fault+0x200/0x670
> <4> [749.063415] __x64_sys_ioctl+0x6d/0xa0
> <4> [749.063419] do_syscall_64+0x3a/0xb0
> <4> [749.063423] entry_SYSCALL_64_after_hwframe+0x44/0xae
> <4> [749.063428] RIP: 0033:0x7f6e5f100317
>
> Testcase: igt@gem_madvise@dontneed-before-mmap
> Fixes: cf3e3e86d779 ("drm/i915: Use ttm mmap handling for ttm bo's.")
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> ---
> drivers/gpu/drm/i915/gem/i915_gem_pages.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> index 89b70f5cde7a..9f429ed6e78a 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> @@ -161,7 +161,6 @@ int i915_gem_object_pin_pages_unlocked(struct
> drm_i915_gem_object *obj)
> /* Immediately discard the backing storage */
> int i915_gem_object_truncate(struct drm_i915_gem_object *obj)
> {
> - drm_gem_free_mmap_offset(&obj->base);
What happens if a non-ttm shmem system object gets truncated from the
shrinker and then tries to use the above mmap offset?
/Thomas
> if (obj->ops->truncate)
> return obj->ops->truncate(obj);
>
^ permalink raw reply
* Re: [PATCH v2 2/2] PCI: designware-ep: Fix the access to DBI/iATU registers before enabling controller
From: Manivannan Sadhasivam @ 2022-01-05 15:46 UTC (permalink / raw)
To: Kunihiko Hayashi
Cc: Lorenzo Pieralisi, Kishon Vijay Abraham I, Jingoo Han,
Gustavo Pimentel, Rob Herring, Krzysztof Wilczyński,
Bjorn Helgaas, Xiaowei Bao, Om Prakash Singh, Vidya Sagar,
linux-pci, linux-kernel
In-Reply-To: <f4037b9c-9957-8d4c-d2e0-63bb53d5e7ee@socionext.com>
On Wed, Jan 05, 2022 at 07:43:04PM +0900, Kunihiko Hayashi wrote:
> Hi Kishon, Lorenzo,
>
> Thank you and sorry for late reply.
>
> On 2021/12/06 20:23, Lorenzo Pieralisi wrote:
> > On Fri, Dec 03, 2021 at 10:36:00AM +0530, Kishon Vijay Abraham I wrote:
> > > Hi Kunihiko,
> > >
> > > On 01/09/21 10:46 am, Kunihiko Hayashi wrote:
> > > > The driver using core_init_notifier, e.g. pcie-tegra194.c, runs
> > according
> > > > to the following sequence:
> > > >
> > > > probe()
> > > > dw_pcie_ep_init()
> > > >
> > > > bind()
> > > > dw_pcie_ep_start()
> > > > enable_irq()
> > > >
> > > > (interrupt occurred)
> > > > handler()
> > > > [enable controller]
> > > > dw_pcie_ep_init_complete()
> > > > dw_pcie_ep_init_notify()
> > > >
> > > > After receiving an interrupt from RC, the handler enables the
> > controller
> > > > and the controller registers can be accessed.
> > > > So accessing the registers should do in dw_pcie_ep_init_complete().
> > > >
> > > > Currently dw_pcie_ep_init() has functions dw_iatu_detect() and
> > > > dw_pcie_ep_find_capability() that include accesses to DWC registers.
> > > > As a result, accessing the registers before enabling the controller,
> > > > the access will fail.
> > > >
> > > > The function dw_pcie_ep_init() shouldn't have any access to DWC
> > registers
> > > > if the controller is enabled after calling bind(). This moves access
> > codes
> > > > to DBI/iATU registers and depending variables from dw_pcie_ep_init()
> > to
> > > > dw_pcie_ep_init_complete().
> > >
> > > Ideally pci_epc_create() should be the last step by the controller
> > > driver before handing the control to the core EPC framework. Since
> > > after this step the EPC framework can start invoking the epc_ops.
> > >
> > > Here more stuff is being added to dw_pcie_ep_init_complete() which is
> > > required for epc_ops and this could result in aborts for platforms
> > > which does not add core_init_notifier.
> >
> > This patch needs rework, I will mark the series as "Changes requested".
>
> I understand that relocation of dwc register accesses isn't appropriate,
> but I couldn't think of any other rework to dwc, and I confirmed
> pcie-qcom-ep driver using core_init_notifier.
>
> In pcie-qcom-ep driver, probe() enables clock and deasserts reset first,
> and when PERST# interrupt arrives, the handler enables clock and deasserts
> reset again. So, dw_pcie_ep_init() can access DBI registers.
>
Yes, only since dw_pcie_ep_init() carries out the DBI accesses, we have enabled
clocks and PHY. Moving the DBI accesses to init_complete() removes the need of
enabling the resources redundantly.
Thanks,
Mani
> In pcie-tegra194 driver, I think the issue will be solved if probe() also
> handles clock and reset control. However, the driver has other register
> access between core_clk, core_apb_rst, and core_rst controls.
> I think that it's appropriate to leave this fix to the developer at this
> point.
>
> As this patch series, I'll resend 1/2 patch only and expect pcie-tegra194
> driver to be fixed.
>
> Thank you,
>
> ---
> Best Regards
> Kunihiko Hayashi
^ permalink raw reply
* Re: Bug#1003095: /usr/bin/script: hangs when child doesn't read input fast enough
From: Karel Zak @ 2022-01-05 15:45 UTC (permalink / raw)
To: Chris Hofstaedtler, 1003095, util-linux
In-Reply-To: <20220104173124.lv2fyxuxuvc34jdo@tarta.nabijaczleweli.xyz>
On Tue, Jan 04, 2022 at 06:31:24PM +0100, наб wrote:
> Control: tags -1 + upstream
>
> On Tue, Jan 04, 2022 at 05:24:54PM +0100, Chris Hofstaedtler wrote:
> > * наб <nabijaczleweli@nabijaczleweli.xyz> [220104 00:06]:
> > > (This, at least, responds to ^\, but it also seems to function
> > > slightly differently. Also, this is a race and you're more
> > > likely to lose it under strace. The loopy thing seems
> > > like it's pretty good at hitting it 100% of the time.)
> As an additional note, because it's a race, if you're using bash,
> script < some-photo.jpeg
> also hangs, because setup takes long enough.
>
> > 1) is this Debian-specific or already present upstream?
> Debian doesn't patch script.c at all, so this is an upstream bug.
>
> > 2) did this work with previous versions of util-linux?
> The oldest one I fould from the site at Homepage: in d/control is
> "util-linux-ng 2.13", dated 19.1.2012. It's much closer to the original
> 4.4BSD-Lite implementation and still forks twice. As expected, testing
> reveals it does not have the bug.
>
> Performing a simple manual bisect across the versions available therein
> reveals that 2.25 is the first broken version. (Though, skimming the
> source, with a slightly different code path (select(2)?), since it still
> double-forks and is not so hard-stuck so as to be immune to ^\.)
>
> The first version that does get hard-stuck (because it forks once
> and only uses poll) is 2.27.
Resolve the problem with the signal should be simple. Now it
ignores all when it write to the master. Something like:
diff --git a/lib/pty-session.c b/lib/pty-session.c
index 6f038e1c5..84ea33860 100644
--- a/lib/pty-session.c
+++ b/lib/pty-session.c
@@ -292,7 +292,20 @@ static int write_output(char *obuf, ssize_t bytes)
static int write_to_child(struct ul_pty *pty, char *buf, size_t bufsz)
{
- return write_all(pty->master, buf, bufsz);
+ sigset_t set, org;
+ int rc;
+
+ sigemptyset(&set);
+ sigemptyset(&org);
+ sigaddset(&set, SIGINT);
+ sigaddset(&set, SIGTERM);
+
+ sigprocmask(SIG_UNBLOCK, &set, &org);
+
+ rc = write_all(pty->master, buf, bufsz);
+
+ sigprocmask(SIG_SETMASK, &org, NULL);
+ return rc;
}
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply related
* INFO: rcu detected stall in stack_trace_save
From: Sabri N. Ferreiro @ 2022-01-05 15:45 UTC (permalink / raw)
To: Dmitry Vyukov, Andrew Morton, Marco Elver, linux-kernel; +Cc: mosesfonscqf75
Hi,
When using Syzkaller to fuzz the Linux kernel, it triggers the following crash.
HEAD commit: a7904a538933 Linux 5.16-rc6
git tree: upstream
console output:
https://docs.google.com/document/d/1CeOHXK07uAJbzcKN7tb9FCt8BIBgrAC1EKx7jDJe_CQ/view
kernel config: https://docs.google.com/document/d/1w94kqQ4ZSIE6BW-5WIhqp4_Zh7XTPH57L5OF2Xb6O6o/view
If you fix this issue, please add the following tag to the commit:
Reported-by: Yuheng Shen <mosesfonscqf75@gmail.com>
Sorry for my lack of this crash reproducer, I hope the symbolic report
will help you.
RAX: 0000000000000000 RBX: ffff88810f62f6f0 RCX: ffffffff9b677838
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88810f62f702
RBP: ffff8881019698c0 R08: 0000000000000001 R09: ffff888133450da3
R10: ffffed102668a1b4 R11: 0000000000000001 R12: dffffc0000000000
rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
R13: ffff8881019698c2 R14: ffffed1021ec5ee0 R15: 000000000000000c
rcu: 0-....: (1 GPs behind) idle=b55/1/0x4000000000000000
softirq=89695/89700 fqs=4237
(detected by 3, t=21002 jiffies, g=110645, q=63240)
Sending NMI from CPU 3 to CPUs 0:
mapping_get_entry root/fuzz/kernel/5.16/mm/filemap.c:1843 [inline]
__filemap_get_folio+0x116/0x670 root/fuzz/kernel/5.16/mm/filemap.c:1905
NMI backtrace for cpu 0
CPU: 0 PID: 497 Comm: syz-executor.11 Not tainted 5.16.0-rc6 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:arch_atomic_try_cmpxchg
root/fuzz/kernel/5.16/./arch/x86/include/asm/atomic.h:202 [inline]
RIP: 0010:atomic_try_cmpxchg_acquire
root/fuzz/kernel/5.16/./include/linux/atomic/atomic-instrumented.h:513
[inline]
RIP: 0010:queued_spin_lock
root/fuzz/kernel/5.16/./include/asm-generic/qspinlock.h:82 [inline]
RIP: 0010:do_raw_spin_lock
root/fuzz/kernel/5.16/./include/linux/spinlock.h:185 [inline]
RIP: 0010:__raw_spin_lock
root/fuzz/kernel/5.16/./include/linux/spinlock_api_smp.h:134 [inline]
RIP: 0010:_raw_spin_lock+0x90/0xd0
root/fuzz/kernel/5.16/kernel/locking/spinlock.c:154
Code: c7 44 24 20 00 00 00 00 e8 5d b3 d2 fd be 04 00 00 00 48 8d 7c
24 20 e8 4e b3 d2 fd ba 01 00 00 00 8b 44 24 20 f0 0f b1 55 00 <75> 29
48 b8 00 00 00 00 00 fc ff df 48 c7 04 03 00 00 00 00 48 8b
RSP: 0018:ffff8881f72090d0 EFLAGS: 00000046
RAX: 0000000000000000 RBX: 1ffff1103ee4121a RCX: ffffffff9d0e0282
RDX: 0000000000000001 RSI: 0000000000000004 RDI: ffff8881f72090f0
RBP: ffffffff9ee9e980 R08: 0000000000000001 R09: ffff8881f72090f3
R10: ffffed103ee4121e R11: 0000000000000001 R12: ffff8881f72091a0
R13: 000000000000f487 R14: 000000000000f487 R15: ffff8881f7209330
FS: 0000555556d33940(0000) GS:ffff8881f7200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000555556d3d078 CR3: 000000010627c000 CR4: 0000000000350ef0
Call Trace:
<IRQ>
console_lock_spinning_enable
root/fuzz/kernel/5.16/kernel/printk/printk.c:1776 [inline]
console_unlock+0x28e/0x8e0 root/fuzz/kernel/5.16/kernel/printk/printk.c:2708
vprintk_emit+0xf8/0x230 root/fuzz/kernel/5.16/kernel/printk/printk.c:2245
vprintk+0x69/0x80 root/fuzz/kernel/5.16/kernel/printk/printk_safe.c:50
_printk+0xba/0xed root/fuzz/kernel/5.16/kernel/printk/printk.c:2266
printk_stack_address
root/fuzz/kernel/5.16/arch/x86/kernel/dumpstack.c:72 [inline]
show_trace_log_lvl+0x263/0x2ca
root/fuzz/kernel/5.16/arch/x86/kernel/dumpstack.c:282
ex_handler_wrmsr_unsafe root/fuzz/kernel/5.16/arch/x86/mm/extable.c:87 [inline]
fixup_exception+0x3bb/0x690 root/fuzz/kernel/5.16/arch/x86/mm/extable.c:150
__exc_general_protection
root/fuzz/kernel/5.16/arch/x86/kernel/traps.c:601 [inline]
exc_general_protection+0xed/0x2e0
root/fuzz/kernel/5.16/arch/x86/kernel/traps.c:562
asm_exc_general_protection+0x1e/0x30
root/fuzz/kernel/5.16/./arch/x86/include/asm/idtentry.h:562
RIP: 0010:__wrmsr
root/fuzz/kernel/5.16/./arch/x86/include/asm/msr.h:103 [inline]
RIP: 0010:native_write_msr
root/fuzz/kernel/5.16/./arch/x86/include/asm/msr.h:160 [inline]
RIP: 0010:wrmsrl root/fuzz/kernel/5.16/./arch/x86/include/asm/msr.h:281 [inline]
RIP: 0010:x86_pmu_disable_event
root/fuzz/kernel/5.16/arch/x86/events/amd/../perf_event.h:1138
[inline]
RIP: 0010:amd_pmu_disable_event+0x83/0x280
root/fuzz/kernel/5.16/arch/x86/events/amd/core.c:639
Code: 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 e0 01
00 00 48 8b ab 78 01 00 00 4c 89 e2 44 89 e0 48 c1 ea 20 89 e9 <0f> 30
66 90 e8 34 4a 38 00 e8 2f 4a 38 00 48 8d bb 94 01 00 00 48
RSP: 0018:ffff8881f7209650 EFLAGS: 00010016
RAX: 0000000000130076 RBX: ffff88810ccbe9c0 RCX: 00000000c0010204
RDX: 0000000000000100 RSI: ffffffff9d607480 RDI: ffff88810ccbeb38
RBP: 00000000c0010204 R08: 0000000000000000 R09: ffff8881f72219e7
R10: ffffed103ee4433c R11: 0000000000000001 R12: 0000010000130076
R13: 0000000000000002 R14: ffff8881f72217e0 R15: ffff88810ccbeb4c
x86_pmu_stop+0x11b/0x320 root/fuzz/kernel/5.16/arch/x86/events/core.c:1597
perf_adjust_freq_unthr_context
root/fuzz/kernel/5.16/kernel/events/core.c:4089 [inline]
perf_event_task_tick+0x4ba/0xb20
root/fuzz/kernel/5.16/kernel/events/core.c:4216
scheduler_tick+0x145/0x2e0 root/fuzz/kernel/5.16/kernel/sched/core.c:5253
update_process_times+0x165/0x1d0 root/fuzz/kernel/5.16/kernel/time/timer.c:1790
tick_sched_handle+0x10f/0x150
root/fuzz/kernel/5.16/kernel/time/tick-sched.c:226
tick_sched_timer+0x163/0x1c0
root/fuzz/kernel/5.16/kernel/time/tick-sched.c:1428
__run_hrtimer root/fuzz/kernel/5.16/kernel/time/hrtimer.c:1685 [inline]
__hrtimer_run_queues+0x3bd/0x810
root/fuzz/kernel/5.16/kernel/time/hrtimer.c:1749
hrtimer_interrupt+0x2f3/0x700 root/fuzz/kernel/5.16/kernel/time/hrtimer.c:1811
local_apic_timer_interrupt
root/fuzz/kernel/5.16/arch/x86/kernel/apic/apic.c:1086 [inline]
__sysvec_apic_timer_interrupt+0x114/0x360
root/fuzz/kernel/5.16/arch/x86/kernel/apic/apic.c:1103
sysvec_apic_timer_interrupt+0x3b/0xc0
root/fuzz/kernel/5.16/arch/x86/kernel/apic/apic.c:1097
asm_sysvec_apic_timer_interrupt+0x12/0x20
root/fuzz/kernel/5.16/./arch/x86/include/asm/idtentry.h:638
RIP: 0010:on_stack
root/fuzz/kernel/5.16/./arch/x86/include/asm/stacktrace.h:56 [inline]
RIP: 0010:__unwind_start
root/fuzz/kernel/5.16/arch/x86/kernel/unwind_orc.c:710 [inline]
RIP: 0010:__unwind_start+0x51f/0x790
root/fuzz/kernel/5.16/arch/x86/kernel/unwind_orc.c:637
Code: 8e 18 01 00 00 41 8b 07 85 c0 0f 84 91 fd ff ff 41 80 7d 00 00
0f 85 0f 01 00 00 41 80 3c 24 00 49 8b 47 08 0f 85 0e 01 00 00 <49> 8b
57 10 48 39 c3 72 b3 48 39 d3 73 ae 48 8d 4b 08 48 39 ca 72
RSP: 0018:ffff8881f7209a58 EFLAGS: 00000246
RAX: ffff8881f7202000 RBX: ffff8881f7209b40 RCX: 0000000000000000
RDX: dffffc0000000000 RSI: ffff8881f7209a78 RDI: 0000000000000001
RBP: dffffc0000000000 R08: ffffffff9e823b6e R09: ffffffff9e823b72
R10: ffffed103ee41362 R11: 000000000002c03e R12: ffffed103ee41357
R13: ffffed103ee41356 R14: ffff8881f7209af0 R15: ffff8881f7209aa8
unwind_start root/fuzz/kernel/5.16/./arch/x86/include/asm/unwind.h:64 [inline]
arch_stack_walk+0x5f/0xf0 root/fuzz/kernel/5.16/arch/x86/kernel/stacktrace.c:24
stack_trace_save+0x8c/0xc0 root/fuzz/kernel/5.16/kernel/stacktrace.c:122
kasan_save_stack+0x1e/0x50 root/fuzz/kernel/5.16/mm/kasan/common.c:38
kasan_set_track+0x21/0x30 root/fuzz/kernel/5.16/mm/kasan/common.c:46
kasan_set_free_info+0x20/0x30 root/fuzz/kernel/5.16/mm/kasan/generic.c:370
____kasan_slab_free root/fuzz/kernel/5.16/mm/kasan/common.c:366 [inline]
____kasan_slab_free root/fuzz/kernel/5.16/mm/kasan/common.c:328 [inline]
__kasan_slab_free+0xeb/0x120 root/fuzz/kernel/5.16/mm/kasan/common.c:374
kasan_slab_free root/fuzz/kernel/5.16/./include/linux/kasan.h:235 [inline]
slab_free_hook root/fuzz/kernel/5.16/mm/slub.c:1723 [inline]
slab_free_freelist_hook root/fuzz/kernel/5.16/mm/slub.c:1749 [inline]
slab_free root/fuzz/kernel/5.16/mm/slub.c:3513 [inline]
kmem_cache_free+0x84/0x290 root/fuzz/kernel/5.16/mm/slub.c:3530
rcu_do_batch root/fuzz/kernel/5.16/kernel/rcu/tree.c:2506 [inline]
rcu_core+0x56e/0x1780 root/fuzz/kernel/5.16/kernel/rcu/tree.c:2741
__do_softirq+0x1a5/0x5a8 root/fuzz/kernel/5.16/kernel/softirq.c:558
invoke_softirq root/fuzz/kernel/5.16/kernel/softirq.c:432 [inline]
__irq_exit_rcu root/fuzz/kernel/5.16/kernel/softirq.c:637 [inline]
irq_exit_rcu+0xc0/0x170 root/fuzz/kernel/5.16/kernel/softirq.c:649
sysvec_apic_timer_interrupt+0x8e/0xc0
root/fuzz/kernel/5.16/arch/x86/kernel/apic/apic.c:1097
</IRQ>
<TASK>
asm_sysvec_apic_timer_interrupt+0x12/0x20
root/fuzz/kernel/5.16/./arch/x86/include/asm/idtentry.h:638
RIP: 0010:xas_load+0x9a/0x1a0 root/fuzz/kernel/5.16/lib/xarray.c:238
Code: 00 76 db e8 28 20 52 ff 41 0f b6 06 49 8d 6d fe 84 c0 74 06 0f
8e b1 00 00 00 48 89 e8 0f b6 53 10 48 c1 e8 03 42 0f b6 04 20 <84> c0
74 06 0f 8e df 00 00 00 44 0f b6 7d 00 44 38 fa 77 a0 e8 ed
RSP: 0018:ffff88810f62f638 EFLAGS: 00000216
RAX: 0000000000000000 RBX: ffff88810f62f6f0 RCX: ffffffff9b677838
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88810f62f702
RBP: ffff8881019698c0 R08: 0000000000000001 R09: ffff888133450da3
R10: ffffed102668a1b4 R11: 0000000000000001 R12: dffffc0000000000
R13: ffff8881019698c2 R14: ffffed1021ec5ee0 R15: 000000000000000c
mapping_get_entry root/fuzz/kernel/5.16/mm/filemap.c:1843 [inline]
__filemap_get_folio+0x116/0x670 root/fuzz/kernel/5.16/mm/filemap.c:1905
pagecache_get_page+0x28/0x100 root/fuzz/kernel/5.16/mm/folio-compat.c:125
find_get_page_flags
root/fuzz/kernel/5.16/./include/linux/pagemap.h:445 [inline]
__find_get_block_slow root/fuzz/kernel/5.16/fs/buffer.c:202 [inline]
__find_get_block root/fuzz/kernel/5.16/fs/buffer.c:1308 [inline]
__find_get_block+0x32e/0x7a0 root/fuzz/kernel/5.16/fs/buffer.c:1302
__getblk_gfp+0x28/0x70 root/fuzz/kernel/5.16/fs/buffer.c:1330
sb_getblk root/fuzz/kernel/5.16/./include/linux/buffer_head.h:327 [inline]
ext4_getblk+0x1aa/0x5f0 root/fuzz/kernel/5.16/fs/ext4/inode.c:854
ext4_bread+0x29/0x170 root/fuzz/kernel/5.16/fs/ext4/inode.c:900
__ext4_read_dirblock+0x30/0xd30 root/fuzz/kernel/5.16/fs/ext4/namei.c:116
htree_dirblock_to_tree+0x185/0xb30 root/fuzz/kernel/5.16/fs/ext4/namei.c:1028
ext4_htree_fill_tree+0x2e1/0xb20 root/fuzz/kernel/5.16/fs/ext4/namei.c:1160
ext4_dx_readdir root/fuzz/kernel/5.16/fs/ext4/dir.c:598 [inline]
ext4_readdir+0x148a/0x28d0 root/fuzz/kernel/5.16/fs/ext4/dir.c:142
iterate_dir+0x4d3/0x640 root/fuzz/kernel/5.16/fs/readdir.c:65
__do_sys_getdents64 root/fuzz/kernel/5.16/fs/readdir.c:369 [inline]
__se_sys_getdents64 root/fuzz/kernel/5.16/fs/readdir.c:354 [inline]
__x64_sys_getdents64+0x12f/0x270 root/fuzz/kernel/5.16/fs/readdir.c:354
do_syscall_x64 root/fuzz/kernel/5.16/arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3b/0x90 root/fuzz/kernel/5.16/arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f107ef3584b
Code: eb b5 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 81
fa ff ff ff 7f b8 ff ff ff 7f 48 0f 47 d0 b8 d9 00 00 00 0f 05 <48> 3d
00 f0 ff ff 77 05 c3 0f 1f 40 00 48 c7 c2 bc ff ff ff f7 d8
RSP: 002b:00007ffebf4b1e28 EFLAGS: 00000293 ORIG_RAX: 00000000000000d9
RAX: ffffffffffffffda RBX: 0000555556d35070 RCX: 00007f107ef3584b
RDX: 0000000000008000 RSI: 0000555556d35070 RDI: 0000000000000003
RBP: ffffffffffffffbc R08: 0000000000000030 R09: 000000000000007c
R10: 00007f107f001520 R11: 0000000000000293 R12: 0000555556d35044
R13: 0000000000000016 R14: 0000555556d35040 R15: 00007ffebf4b2ff0
</TASK>
^ permalink raw reply
* Re: [PATCH] ALSA: hda/realtek: Add quirk for Legion Y9000X 2020
From: Takashi Iwai @ 2022-01-05 15:43 UTC (permalink / raw)
To: Baole Fang
Cc: moderated list:SOUND, Kailang Yang, Jeremy Szu, open list,
Elia Devito, Takashi Iwai, Werner Sembach, Hui Wang, Sami Loone,
gregkh, Cameron Berkenpas
In-Reply-To: <20220105140856.4855-1-fbl718@163.com>
On Wed, 05 Jan 2022 15:08:54 +0100,
Baole Fang wrote:
>
> Legion Y9000X 2020 has a speaker, but the speaker doesn't work.
> This can be fixed by applying alc285_fixup_ideapad_s740_coef
> to fix the speaker's coefficients.
> Besides, to support the transition between the speaker and the headphone,
> alc287_fixup_legion_15imhg05_speakers needs to be run.
>
> Signed-off-by: Baole Fang <fbl718@163.com>
Thanks, applied now (with Cc to stable).
Takashi
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.