riscv failures

[Alexandre Ghiti]

Hi,

syzkaller has been broken for a few weeks on riscv but I can't see the
reason of the failure (I'm getting a "403 Forbidden"). Can you make the
report public? Or point me to the failure reason so that I can fix it?

Thanks,

Alex

[Aleksandr Nogikh]

Hi Alexandre,

Thanks for reaching out!

The riscv instance is up and running now, it's not broken.

The bug you tried to access is a duplicate of
https://syzkaller.appspot.com/bug?extid=353d7b75658a95aa955a (*). It's
very weird that you cannot access it, I have filed
https://github.com/google/syzkaller/issues/5856 to figure out why.

(*) That report is no longer really relevant - it appeared on all
syzbot instances when I tried to re-enable CONFIG_BINDERFS only to
find out that the feature was still broken. I disabled it back shortly
afterwards.

--
Aleksandr

[Alexandre Ghiti]

Hi Aleksandr,

On 24/03/2025 21:47, Aleksandr Nogikh wrote:
> Hi Alexandre,
>
> Thanks for reaching out!
>
> The riscv instance is up and running now, it's not broken.
>
> The bug you tried to access is a duplicate of
> https://syzkaller.appspot.com/bug?extid=353d7b75658a95aa955a (*). It's
> very weird that you cannot access it, I have filed
> https://github.com/google/syzkaller/issues/5856 to figure out why.

Yes it happens often, so thanks for trying to understand what happens,
I'll follow the thread.

>
> (*) That report is no longer really relevant - it appeared on all
> syzbot instances when I tried to re-enable CONFIG_BINDERFS only to
> find out that the feature was still broken. I disabled it back shortly
> afterwards.
>

Thanks for your quick answer,

Alex

[Alexander Potapenko]

Hi Alexandre,

We switched the ci-qemu2-riscv64 instance to
"git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git
for-next", because the "fixes" branch was quite stale and didn't
contain the latest fixes.

However right now syzkaller is failing to SSH into the instance
because of some boot-time problems (see below).
Do you know what could be causing this?

=================================

failed to run ["ssh" "-p" "6080" "-F" "/dev/null" "-o"
"UserKnownHostsFile=/dev/null" "-o" "IdentitiesOnly=yes" "-o"
"BatchMode=yes" "-o" "StrictHostKeyChecking=no" "-o"
"ConnectTimeout=10" "root@localhost" "pwd"]: exit status 255
Connection timed out during banner exchange
Connection to 127.0.0.1 port 6080 timed out

OpenSBI v1.5
____ _____ ____ _____
/ __ \ / ____| _ \_ _|
| | | |_ __ ___ _ __ | (___ | |_) || |
| | | | '_ \ / _ \ '_ \ \___ \| _ < | |
| |__| | |_) | __/ | | |____) | |_) || |_
\____/| .__/ \___|_| |_|_____/|____/_____|
| |
|_|

Platform Name : riscv-virtio,qemu
Platform Features : medeleg
Platform HART Count : 2
Platform IPI Device : aclint-mswi
Platform Timer Device : aclint-mtimer @ 10000000Hz
Platform Console Device : uart8250
Platform HSM Device : ---
Platform PMU Device : ---
Platform Reboot Device : syscon-reboot
Platform Shutdown Device : syscon-poweroff
Platform Suspend Device : ---
Platform CPPC Device : ---
Firmware Base : 0x80000000
Firmware Size : 337 KB
Firmware RW Offset : 0x40000
Firmware RW Size : 81 KB
Firmware Heap Offset : 0x4b000
Firmware Heap Size : 37 KB (total), 2 KB (reserved), 11 KB
(used), 23 KB (free)
Firmware Scratch Size : 4096 B (total), 416 B (used), 3680 B (free)
Runtime SBI Version : 2.0

Domain0 Name : root
Domain0 Boot HART : 0
Domain0 HARTs : 0*,1*
Domain0 Region00 : 0x0000000000100000-0x0000000000100fff M:
(I,R,W) S/U: (R,W)
Domain0 Region01 : 0x0000000010000000-0x0000000010000fff M:
(I,R,W) S/U: (R,W)
Domain0 Region02 : 0x0000000002000000-0x000000000200ffff M:
(I,R,W) S/U: ()
Domain0 Region03 : 0x0000000080040000-0x000000008005ffff M:
(R,W) S/U: ()
Domain0 Region04 : 0x0000000080000000-0x000000008003ffff M:
(R,X) S/U: ()
Domain0 Region05 : 0x000000000c400000-0x000000000c5fffff M:
(I,R,W) S/U: (R,W)
Domain0 Region06 : 0x000000000c000000-0x000000000c3fffff M:
(I,R,W) S/U: (R,W)
Domain0 Region07 : 0x0000000000000000-0xffffffffffffffff M:
() S/U: (R,W,X)
Domain0 Next Address : 0x0000000080200000
Domain0 Next Arg1 : 0x00000000bfe00000
Domain0 Next Mode : S-mode
Domain0 SysReset : yes
Domain0 SysSuspend : yes

Boot HART ID : 0
Boot HART Domain : root
Boot HART Priv Version : v1.12
Boot HART Base ISA : rv64imafdch
Boot HART ISA Extensions : sstc,zicntr,zihpm,zicboz,zicbom,sdtrig,svadu
Boot HART PMP Count : 16
Boot HART PMP Granularity : 2 bits
Boot HART PMP Address Bits: 54
Boot HART MHPM Info : 16 (0x0007fff8)
Boot HART Debug Triggers : 2 triggers
Boot HART MIDELEG : 0x0000000000001666
Boot HART MEDELEG : 0x0000000000f0b509

> --
> You received this message because you are subscribed to the Google Groups "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/syzkaller/CANp29Y5OEhNq_Rbe2cJpM3s99GrSzObzKX%3D%2Bf7mruehff3rWpw%40mail.gmail.com.



--
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Paul Manicle, Liana Sebastian
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg

[Alexandre Ghiti]

Hi Alexander,

On 6/4/25 10:35, Alexander Potapenko wrote:
> Hi Alexandre,
>
> We switched the ci-qemu2-riscv64 instance to
> "git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git
> for-next", because the "fixes" branch was quite stale and didn't
> contain the latest fixes.
>
> However right now syzkaller is failing to SSH into the instance
> because of some boot-time problems (see below).
> Do you know what could be causing this?

Yes, we need both commit dd133162c9cf ("ACPI: platform_profile: Avoid
initializing on non-ACPI platforms") merged in 6.16 and commit
07c9214c790e ("mm/cma: make detection of highmem_start more robust") 
merged in late 6.15.

Can you consider using my fixes branch instead? It will be updated more
frequently. My branch is
https://git.kernel.org/pub/scm/linux/kernel/git/alexghiti/linux.git/log/?h=alex-fixes.

Thanks for reaching out,

Alex

[Marco Elver]

On Wed, 4 Jun 2025 at 13:03, Alexandre Ghiti <al...@ghiti.fr> wrote:
>
> Hi Alexander,
>
> On 6/4/25 10:35, Alexander Potapenko wrote:
> > Hi Alexandre,
> >
> > We switched the ci-qemu2-riscv64 instance to
> > "git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git
> > for-next", because the "fixes" branch was quite stale and didn't
> > contain the latest fixes.
> >
> > However right now syzkaller is failing to SSH into the instance
> > because of some boot-time problems (see below).
> > Do you know what could be causing this?
>
>
> Yes, we need both commit dd133162c9cf ("ACPI: platform_profile: Avoid
> initializing on non-ACPI platforms") merged in 6.16 and commit
> 07c9214c790e ("mm/cma: make detection of highmem_start more robust")
> merged in late 6.15.
>
> Can you consider using my fixes branch instead? It will be updated more
> frequently. My branch is
> https://git.kernel.org/pub/scm/linux/kernel/git/alexghiti/linux.git/log/?h=alex-fixes.

We can only pick one for riscv, and can't keep switching the tree.
The canonical subsystem tree per MAINTAINERS is:
git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git
We thought that for-next should not be continuously broken because it
also receives -next exposure.

So the main question would be: what is the most useful tree to fuzz
for riscv? If you declare that your fixes branch is the latest
up-to-date riscv branch that will be maintained and updated
indefinitely, we can switch (however, it would have been good to see
such a branch in the riscv/linux.git repo). Either way, the choice is
yours.

Thanks,
-- Marco

[Alexandre Ghiti]

Hi Marco,

On 6/5/25 10:49, Marco Elver wrote:
> On Wed, 4 Jun 2025 at 13:03, Alexandre Ghiti <al...@ghiti.fr> wrote:
>> Hi Alexander,
>>
>> On 6/4/25 10:35, Alexander Potapenko wrote:
>>> Hi Alexandre,
>>>
>>> We switched the ci-qemu2-riscv64 instance to
>>> "git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git
>>> for-next", because the "fixes" branch was quite stale and didn't
>>> contain the latest fixes.
>>>
>>> However right now syzkaller is failing to SSH into the instance
>>> because of some boot-time problems (see below).
>>> Do you know what could be causing this?
>>
>> Yes, we need both commit dd133162c9cf ("ACPI: platform_profile: Avoid
>> initializing on non-ACPI platforms") merged in 6.16 and commit
>> 07c9214c790e ("mm/cma: make detection of highmem_start more robust")
>> merged in late 6.15.
>>
>> Can you consider using my fixes branch instead? It will be updated more
>> frequently. My branch is
>> https://git.kernel.org/pub/scm/linux/kernel/git/alexghiti/linux.git/log/?h=alex-fixes.
> We can only pick one for riscv, and can't keep switching the tree.
> The canonical subsystem tree per MAINTAINERS is:
> git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git
> We thought that for-next should not be continuously broken because it
> also receives -next exposure.

Sorry about this situation, unfortunately it's out of my control,
hopefully that will change some time soon, but for now I'm only a "R:"
in MAINTAINERS...

> So the main question would be: what is the most useful tree to fuzz
> for riscv? If you declare that your fixes branch is the latest
> up-to-date riscv branch that will be maintained and updated
> indefinitely, we can switch (however, it would have been good to see
> such a branch in the riscv/linux.git repo). Either way, the choice is
> yours.

I can guarantee that my branch will be uptodate, no worries about that
so if you can switch, it would be nice.

Sorry about for this mess and thanks,

Alex


>
> Thanks,
> -- Marco

[Marco Elver]

What's the defacto state of the main RISCV tree? Is it broken,
unmaintained, abandoned?

> > So the main question would be: what is the most useful tree to fuzz
> > for riscv? If you declare that your fixes branch is the latest
> > up-to-date riscv branch that will be maintained and updated
> > indefinitely, we can switch (however, it would have been good to see
> > such a branch in the riscv/linux.git repo). Either way, the choice is
> > yours.
>
>
> I can guarantee that my branch will be uptodate, no worries about that
> so if you can switch, it would be nice.
>
> Sorry about for this mess and thanks,

Understood - but I'd like to understand why it's not possible to
update for-next (which would also benefit -next) with the necessary
patches that would unbreak syzbot RISCV fuzzing. This is the normal
process - is the process broken, or are the patches still under
review?