All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexandre Ghiti <alex@ghiti.fr>
To: Dmitry Vyukov <dvyukov@google.com>,
	Alexandre Ghiti <alexandre.ghiti@canonical.com>
Cc: syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
	syzbot <syzbot+2c5da6a0a16a0c4f34aa@syzkaller.appspotmail.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Paul Walmsley <paul.walmsley@sifive.com>
Subject: Re: [syzbot] riscv/fixes test error: lost connection to test machine
Date: Sat, 28 May 2022 10:09:52 +0200	[thread overview]
Message-ID: <f2bcc414-aa96-cfcb-4df8-fe66cf47068f@ghiti.fr> (raw)
In-Reply-To: <CACT4Y+ZAazG7UjKE1ZHq72bh4Ve1r3_Hw+zcONYoO1J959sukw@mail.gmail.com>

On 5/27/22 19:12, Dmitry Vyukov wrote:
> On Fri, 27 May 2022 at 19:04, Dmitry Vyukov <dvyukov@google.com> wrote:
>> On Fri, 27 May 2022 at 16:01, Alexandre Ghiti
>> <alexandre.ghiti@canonical.com> wrote:
>>> On Friday, May 27, 2022 at 3:55:24 PM UTC+2 Dmitry Vyukov wrote:
>>>> On Fri, 27 May 2022 at 15:50, Alexandre Ghiti
>>>> <alexand...@canonical.com> wrote:
>>>>> On Friday, May 27, 2022 at 3:02:01 PM UTC+2 Dmitry Vyukov wrote:
>>>>>> On Fri, 27 May 2022 at 14:55, syzbot
>>>>>> <syzbot+2c5da6...@syzkaller.appspotmail.com> wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> syzbot found the following issue on:
>>>>>>>
>>>>>>> HEAD commit: c932edeaf6d6 riscv: dts: microchip: fix gpio1 reg property..
>>>>>>> git tree: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes
>>>>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=1418add5f00000
>>>>>>> kernel config: https://syzkaller.appspot.com/x/.config?x=aa6b5702bdf14a17
>>>>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=2c5da6a0a16a0c4f34aa
>>>>>>> compiler: riscv64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
>>>>>>> userspace arch: riscv64
>>>>>>>
>>>>>>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>>>>>>> Reported-by: syzbot+2c5da6...@syzkaller.appspotmail.com
>>>>>> The CONFIG_KASAN_VMALLOC allows riscv kernel to boot, but now Go
>>>>>> processes started crashing with:
>>>>>>
>>>>>> 1970/01/01 00:06:55 fuzzer started
>>>>>> runtime: lfstack.push invalid packing: node=0xffffff5908a940 cnt=0x1
>>>>>> packed=0xffff5908a9400001 -> node=0xffff5908a940
>>>>>> fatal error: lfstack.push
>>>>>> runtime stack:
>>>>>> runtime.throw({0x30884c, 0xc})
>>>>>> /usr/local/go/src/runtime/panic.go:1198 +0x60
>>>>>> runtime.(*lfstack).push(0xdb3850, 0xffffff5908a940)
>>>>>> /usr/local/go/src/runtime/lfstack.go:30 +0x1a8
>>>>>>
>>>>>> Go runtime tries to shove some data into the upper 16 bits of pointers
>>>>>> assuming they are unused.
>>>>>> However, the original pointer node=0xffffff5908a940 suggest riscv now
>>>>>> has 56-bit users-space address space?
>>>>>
>>>>> Yes, sv57 was merged recently.
>>>>>
>>>>>> Documentation/riscv/vm-layout.rst claims 48-bit pointers:
>>>>>> "
>>>>>> The RISC-V privileged architecture document states that the 64bit addresses
>>>>>> "must have bits 63–48 all equal to bit 47, or else a page-fault exception will
>>>>>> occur.":
>>>>>
>>>>> Thanks for pointing that, I extracted that from the specification before sv57 was specified, I'll fix that.
>>>>>
>>>>> The current kernel code will use sv57 as it is supported and advertised by qemu, and to my knowledge, you can't downgrade to sv48 unless by re-compiling qemu using the following:
>>>>>
>>>>> diff --git a/target/riscv/csr.c b/target/riscv/csr.c
>>>>> index 6dbe9b541f..a64b50ed75 100644
>>>>> --- a/target/riscv/csr.c
>>>>> +++ b/target/riscv/csr.c
>>>>> @@ -637,7 +637,7 @@ static const char valid_vm_1_10_64[16] = {
>>>>> [VM_1_10_MBARE] = 1,
>>>>> [VM_1_10_SV39] = 1,
>>>>> [VM_1_10_SV48] = 1,
>>>>> - [VM_1_10_SV57] = 1
>>>>> + [VM_1_10_SV57] = 0
>>>>> };
>>>>>
>>>>> /* Machine Information Registers */
>>>>>
>>>>>> ...
>>>>>> 0000000000000000 | 0 | 0000003fffffffff | 256 GB |
>>>>>> user-space virtual memory, different per mm
>>>>>> "
>>>> There is no kernel config to force SV48/39, right?
>>>
>>> No, we rely on what the hardware advertises, if it supports sv57, we'll go for sv57, if not, we'll try sv48...etc. I had some patches to force the downgrade by using the device tree but they never got merged though.
>> +original CC list
>>
>> FTR sent Go runtime change to support SV57:
>> https://go-review.googlesource.com/c/go/+/409055
>
>
> Is CONFIG_CMDLINE broken on riscv?
> I am running with:
>
> CONFIG_CMDLINE="earlyprintk=serial net.ifnames=0
> sysctl.kernel.hung_task_all_cpu_backtrace=1 ima_policy=tcb
> nf-conntrack-ftp.ports=20000 nf-conntrack-tftp.ports=20000
> nf-conntrack-sip.ports=20000 nf-conntrack-irc.ports=20000
> nf-conntrack-sane.ports=20000 binder.debug_mask=0
> rcupdate.rcu_expedited=1 no_hash_pointers page_owner=on
> sysctl.vm.nr_hugepages=4 sysctl.vm.nr_overcommit_hugepages=4
> secretmem.enable=1 sysctl.max_rcu_stall_to_panic=1
> msr.allow_writes=off dummy_hcd.num=2 smp.csd_lock_timeout=300000
> watchdog_thresh=165 workqueue.watchdog_thresh=420
> sysctl.net.core.netdev_unregister_timeout_secs=420 panic_on_warn=1"


This command line is 608-character long, but we are still stuck with the 
default COMMAND_LINE_SIZE to 512, I imagine that it is the problem. I 
had proposed a patch last year to bump that to 1024, but it never got 
merged 
https://lore.kernel.org/lkml/CAEn-LTqTXCEC=bXTvGyo8SNL0JMWRKtiSwQB7R=Pc4uhxZUruA@mail.gmail.com/T/#m4b45019dc0f5573f2a50c1f6007c5109fa35efff


>
> But getting BUGs with the default timeout:
> watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/0:4:2039]
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Alexandre Ghiti <alex@ghiti.fr>
To: Dmitry Vyukov <dvyukov@google.com>,
	Alexandre Ghiti <alexandre.ghiti@canonical.com>
Cc: syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
	syzbot <syzbot+2c5da6a0a16a0c4f34aa@syzkaller.appspotmail.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Paul Walmsley <paul.walmsley@sifive.com>
Subject: Re: [syzbot] riscv/fixes test error: lost connection to test machine
Date: Sat, 28 May 2022 10:09:52 +0200	[thread overview]
Message-ID: <f2bcc414-aa96-cfcb-4df8-fe66cf47068f@ghiti.fr> (raw)
In-Reply-To: <CACT4Y+ZAazG7UjKE1ZHq72bh4Ve1r3_Hw+zcONYoO1J959sukw@mail.gmail.com>

On 5/27/22 19:12, Dmitry Vyukov wrote:
> On Fri, 27 May 2022 at 19:04, Dmitry Vyukov <dvyukov@google.com> wrote:
>> On Fri, 27 May 2022 at 16:01, Alexandre Ghiti
>> <alexandre.ghiti@canonical.com> wrote:
>>> On Friday, May 27, 2022 at 3:55:24 PM UTC+2 Dmitry Vyukov wrote:
>>>> On Fri, 27 May 2022 at 15:50, Alexandre Ghiti
>>>> <alexand...@canonical.com> wrote:
>>>>> On Friday, May 27, 2022 at 3:02:01 PM UTC+2 Dmitry Vyukov wrote:
>>>>>> On Fri, 27 May 2022 at 14:55, syzbot
>>>>>> <syzbot+2c5da6...@syzkaller.appspotmail.com> wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> syzbot found the following issue on:
>>>>>>>
>>>>>>> HEAD commit: c932edeaf6d6 riscv: dts: microchip: fix gpio1 reg property..
>>>>>>> git tree: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes
>>>>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=1418add5f00000
>>>>>>> kernel config: https://syzkaller.appspot.com/x/.config?x=aa6b5702bdf14a17
>>>>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=2c5da6a0a16a0c4f34aa
>>>>>>> compiler: riscv64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
>>>>>>> userspace arch: riscv64
>>>>>>>
>>>>>>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>>>>>>> Reported-by: syzbot+2c5da6...@syzkaller.appspotmail.com
>>>>>> The CONFIG_KASAN_VMALLOC allows riscv kernel to boot, but now Go
>>>>>> processes started crashing with:
>>>>>>
>>>>>> 1970/01/01 00:06:55 fuzzer started
>>>>>> runtime: lfstack.push invalid packing: node=0xffffff5908a940 cnt=0x1
>>>>>> packed=0xffff5908a9400001 -> node=0xffff5908a940
>>>>>> fatal error: lfstack.push
>>>>>> runtime stack:
>>>>>> runtime.throw({0x30884c, 0xc})
>>>>>> /usr/local/go/src/runtime/panic.go:1198 +0x60
>>>>>> runtime.(*lfstack).push(0xdb3850, 0xffffff5908a940)
>>>>>> /usr/local/go/src/runtime/lfstack.go:30 +0x1a8
>>>>>>
>>>>>> Go runtime tries to shove some data into the upper 16 bits of pointers
>>>>>> assuming they are unused.
>>>>>> However, the original pointer node=0xffffff5908a940 suggest riscv now
>>>>>> has 56-bit users-space address space?
>>>>>
>>>>> Yes, sv57 was merged recently.
>>>>>
>>>>>> Documentation/riscv/vm-layout.rst claims 48-bit pointers:
>>>>>> "
>>>>>> The RISC-V privileged architecture document states that the 64bit addresses
>>>>>> "must have bits 63–48 all equal to bit 47, or else a page-fault exception will
>>>>>> occur.":
>>>>>
>>>>> Thanks for pointing that, I extracted that from the specification before sv57 was specified, I'll fix that.
>>>>>
>>>>> The current kernel code will use sv57 as it is supported and advertised by qemu, and to my knowledge, you can't downgrade to sv48 unless by re-compiling qemu using the following:
>>>>>
>>>>> diff --git a/target/riscv/csr.c b/target/riscv/csr.c
>>>>> index 6dbe9b541f..a64b50ed75 100644
>>>>> --- a/target/riscv/csr.c
>>>>> +++ b/target/riscv/csr.c
>>>>> @@ -637,7 +637,7 @@ static const char valid_vm_1_10_64[16] = {
>>>>> [VM_1_10_MBARE] = 1,
>>>>> [VM_1_10_SV39] = 1,
>>>>> [VM_1_10_SV48] = 1,
>>>>> - [VM_1_10_SV57] = 1
>>>>> + [VM_1_10_SV57] = 0
>>>>> };
>>>>>
>>>>> /* Machine Information Registers */
>>>>>
>>>>>> ...
>>>>>> 0000000000000000 | 0 | 0000003fffffffff | 256 GB |
>>>>>> user-space virtual memory, different per mm
>>>>>> "
>>>> There is no kernel config to force SV48/39, right?
>>>
>>> No, we rely on what the hardware advertises, if it supports sv57, we'll go for sv57, if not, we'll try sv48...etc. I had some patches to force the downgrade by using the device tree but they never got merged though.
>> +original CC list
>>
>> FTR sent Go runtime change to support SV57:
>> https://go-review.googlesource.com/c/go/+/409055
>
>
> Is CONFIG_CMDLINE broken on riscv?
> I am running with:
>
> CONFIG_CMDLINE="earlyprintk=serial net.ifnames=0
> sysctl.kernel.hung_task_all_cpu_backtrace=1 ima_policy=tcb
> nf-conntrack-ftp.ports=20000 nf-conntrack-tftp.ports=20000
> nf-conntrack-sip.ports=20000 nf-conntrack-irc.ports=20000
> nf-conntrack-sane.ports=20000 binder.debug_mask=0
> rcupdate.rcu_expedited=1 no_hash_pointers page_owner=on
> sysctl.vm.nr_hugepages=4 sysctl.vm.nr_overcommit_hugepages=4
> secretmem.enable=1 sysctl.max_rcu_stall_to_panic=1
> msr.allow_writes=off dummy_hcd.num=2 smp.csd_lock_timeout=300000
> watchdog_thresh=165 workqueue.watchdog_thresh=420
> sysctl.net.core.netdev_unregister_timeout_secs=420 panic_on_warn=1"


This command line is 608-character long, but we are still stuck with the 
default COMMAND_LINE_SIZE to 512, I imagine that it is the problem. I 
had proposed a patch last year to bump that to 1024, but it never got 
merged 
https://lore.kernel.org/lkml/CAEn-LTqTXCEC=bXTvGyo8SNL0JMWRKtiSwQB7R=Pc4uhxZUruA@mail.gmail.com/T/#m4b45019dc0f5573f2a50c1f6007c5109fa35efff


>
> But getting BUGs with the default timeout:
> watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/0:4:2039]
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2022-05-28  8:10 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-27 12:55 [syzbot] riscv/fixes test error: lost connection to test machine syzbot
2022-05-27 12:55 ` syzbot
2022-05-27 13:01 ` Dmitry Vyukov
2022-05-27 13:01   ` Dmitry Vyukov
     [not found]   ` <36f4745f-0e47-4f49-8f4e-ff7544f163d8n@googlegroups.com>
     [not found]     ` <CACT4Y+Zy7wLdeRCa+ZH-swo9ut=U6pEk4rP461QE1m-gT6s-uQ@mail.gmail.com>
     [not found]       ` <a55430c3-a0bc-4af6-b7e2-20f2e0d091b2n@googlegroups.com>
2022-05-27 17:04         ` Dmitry Vyukov
2022-05-27 17:04           ` Dmitry Vyukov
2022-05-27 17:12           ` Dmitry Vyukov
2022-05-27 17:12             ` Dmitry Vyukov
2022-05-28  8:09             ` Alexandre Ghiti [this message]
2022-05-28  8:09               ` Alexandre Ghiti
2022-05-28  8:31               ` Dmitry Vyukov
2022-05-28  8:31                 ` Dmitry Vyukov
     [not found]                 ` <CA+zEjCv+7k-Lu-rhOgXOVptzF9GpLt1K_1GHKnciMrTyenyT9g@mail.gmail.com>
2022-08-04  5:35                   ` Dmitry Vyukov
2022-08-04  5:35                     ` Dmitry Vyukov
2022-05-28  8:03           ` Alexandre Ghiti
2022-05-28  8:03             ` Alexandre Ghiti
2022-05-28  8:26             ` Dmitry Vyukov
2022-05-28  8:26               ` Dmitry Vyukov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f2bcc414-aa96-cfcb-4df8-fe66cf47068f@ghiti.fr \
    --to=alex@ghiti.fr \
    --cc=alexandre.ghiti@canonical.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=dvyukov@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=syzbot+2c5da6a0a16a0c4f34aa@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.