Re: arm64 syzbot instances
From: Dmitry Vyukov <dvyukov@google.com>
Date: 2021-03-11 17:26:22
Also in:
lkml
On Thu, Mar 11, 2021 at 2:30 PM Arnd Bergmann [off-list ref] wrote:
On Thu, Mar 11, 2021 at 12:38 PM Dmitry Vyukov [off-list ref] wrote:quoted
The instances found few arm64-specific issues that we have not observed on other instances:I've had a brief look at these: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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel