lkml.org 
[lkml]   [2021]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: arm64 syzbot instances
On Thu, Mar 11, 2021 at 2:30 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Thu, Mar 11, 2021 at 12:38 PM Dmitry Vyukov <dvyukov@google.com> wrote:
> >
> > The instances found few arm64-specific issues that we have not
> > observed on other instances:
>
> I've had a brief look at these:
>
> > https://syzkaller.appspot.com/bug?id=1d22a2cc3521d5cf6b41bd6b825793c2015f861f
>
> This one doesn't seem arm64 specific at all. While the KASAN report has shown
> up on arm64, the link to
> https://syzkaller.appspot.com/bug?id=aa8808729c0a3540e6a29f0d45394665caf79dca
> seems to be for x86 machines running into the same problem.

You are right. It's probably a consequence of some configs being enabled.
I think we need to enable CONFIG_FW_LOADER_USER_HELPER on x86_64
upstream instances as well.


> Looking deeper into the log, I see that fw_load_sysfs_fallback() finds
> an existing
> list entry on the global "pending_fw_head" list, which seems to have been freed
> earlier (the allocation listed here is not for a firmware load, so presumably it
> was recycled in the meantime). The log shows that this is the second time that
> loading the regulatory database failed in that run, so my guess is that it was
> the first failed load that left the freed firmware private data on the
> list, but I
> don't see how that happened.

Can it be as simple as: fw_load_sysfs_fallback adds fw to the pending
list, but then returns with an error w/o removing it from the list?
There are some errors checks after that:
https://elixir.bootlin.com/linux/v5.12-rc2/source/drivers/base/firmware_loader/fallback.c#L536
and it seems that the caller deletes fw in this case:
https://elixir.bootlin.com/linux/v5.12-rc2/source/drivers/base/firmware_loader/main.c#L839

\
 
 \ /
  Last update: 2021-03-11 18:27    [W:1.715 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site