Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Message-ID: <f2bcc414-aa96-cfcb-4df8-fe66cf47068f@ghiti.fr>
Date:   Sat, 28 May 2022 10:09:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.8.0
Subject: Re: [syzbot] riscv/fixes test error: lost connection to test machine
Content-Language: en-US
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>
References: <000000000000d0437b05dffdd1de@google.com>
 <CACT4Y+Y8DOKJtwhRsyNT7G26C3Fx_oeibpXn43Ks0RtYYdZG3g@mail.gmail.com>
 <36f4745f-0e47-4f49-8f4e-ff7544f163d8n@googlegroups.com>
 <CACT4Y+Zy7wLdeRCa+ZH-swo9ut=U6pEk4rP461QE1m-gT6s-uQ@mail.gmail.com>
 <a55430c3-a0bc-4af6-b7e2-20f2e0d091b2n@googlegroups.com>
 <CACT4Y+ar18tcxx0tOthV0JBrmWsLXtXAjXVFX4sac5k1UGJ7Lw@mail.gmail.com>
 <CACT4Y+ZAazG7UjKE1ZHq72bh4Ve1r3_Hw+zcONYoO1J959sukw@mail.gmail.com>
From:   Alexandre Ghiti <alex@ghiti.fr>
In-Reply-To: <CACT4Y+ZAazG7UjKE1ZHq72bh4Ve1r3_Hw+zcONYoO1J959sukw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

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