linux-kernel - Re: [linux-next:master] [x86/crc32] 55d1ecceb8: INFO:task_blocked_for_more

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20241227012749.GA87183@sol.localdomain>
Date: Thu, 26 Dec 2024 17:27:49 -0800
From: Eric Biggers <ebiggers@...nel.org>
To: Oliver Sang <oliver.sang@...el.com>
Cc: oe-lkp@...ts.linux.dev, lkp@...el.com, Ard Biesheuvel <ardb@...nel.org>,
	linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org,
	linux-scsi@...r.kernel.org, target-devel@...r.kernel.org
Subject: Re: [linux-next:master] [x86/crc32]  55d1ecceb8:
 INFO:task_blocked_for_more_than#seconds

On Thu, Dec 26, 2024 at 10:29:06AM +0800, Oliver Sang wrote:
> > Thanks.  Unfortunately, the issue does not reproduce for me when following these
> > commands.
> > 
> > The kernel does panic from not being able to find the rootfs, both before and
> > after.  That seems to be caused by the rootfs from the job script not being
> > available on the 01.org server, as indicated by the following output:
> > 
> >     /usr/bin/wget -q --timeout=3600 --tries=1 --local-encoding=UTF-8 https://download.01.org/0day-ci/lkp-qemu/osimage/pkg/quantal-i386-core.cgz/trinity-static-i386-x86_64-f93256fb_2019-08-28.cgz -N -P /home/e/.lkp/cache/osimage/pkg/quantal-i386-core.cgz
> >     Failed to download osimage/pkg/quantal-i386-core.cgz/trinity-static-i386-x86_64-f93256fb_2019-08-28.cgz
> >     cat: '': No such file or directory
> > 
> > It doesn't print the error information from wget, but I checked and it is HTTP
> > error 404 Not Found.  Thus, there seem to be bugs in lkp where (a) it links to a
> > non-existent rootfs, and (b) errors downloading the rootfs are not fatal.
> 
> sorry for this. I just made the upload. the issue should be gone now.
> 

I retried it and the rootfs downloads now.

I still see some error messages during boot which suggest the rootfs is broken:

    ls: cannot access /boot/config-*: No such file or directory
    ...
    mkdir: cannot create directory `/var/lock/lkp-bootstrap.lock': File exists
    ...
    chroot: failed to run command `trinity': Permission denied

Anyway, this all seems unrelated to the reported issue which occurred before
mounting the rootfs, based on the provided dmesg.xz.

In 10 boots the issue still doesn't reproduce for me, following the 'reproduce'
script as closely as possible.  Note: for "gcc-12" I used gcc commit
08f1bd108806 from the gcc-12 release branch, and for QEMU I used v9.1.2.

And I don't think my commit can be the root cause, especially when the x86 CRC32
code is disabled.  So I'm afraid there's nothing I can do here.

- Eric