[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ec18001d-7123-4d13-aea7-a28594cd137b@redhat.com>
Date: Mon, 16 Jun 2025 22:28:44 +0200
From: David Hildenbrand <david@...hat.com>
To: Christian Heusel <christian@...sel.eu>,
Naresh Kamboju <naresh.kamboju@...aro.org>
Cc: clang-built-linux <llvm@...ts.linux.dev>,
"open list:KERNEL SELFTEST FRAMEWORK" <linux-kselftest@...r.kernel.org>,
open list <linux-kernel@...r.kernel.org>, lkft-triage@...ts.linaro.org,
Linux Regressions <regressions@...ts.linux.dev>,
Andrew Morton <akpm@...ux-foundation.org>,
Nathan Chancellor <nathan@...nel.org>, Arnd Bergmann <arnd@...db.de>,
Vlastimil Babka <vbabka@...e.cz>, Shuah Khan <shuah@...nel.org>,
Zi Yan <ziy@...dia.com>, lorenzo.stoakes@...cle.com,
Dan Carpenter <dan.carpenter@...aro.org>,
Anders Roxell <anders.roxell@...aro.org>, jackmanb@...gle.com
Subject: Re: clang: selftests/mm gup_longterm error while loading shared
libraries liburing.so.2 cannot open shared object file No such file or
directory
On 16.06.25 21:14, Christian Heusel wrote:
> On 25/06/16 11:02PM, Naresh Kamboju wrote:
>> The following test regressions noticed while running selftests/mm gup_longterm
>> test cases on Dragonboard-845c, Dragonboard-410c, rock-pi-4, qemu-arm64 and
>> qemu-x86_64 this build have required selftest/mm/configs included and toolchain
>> is clang nightly.
>>
>> Regressions found on Dragonboard-845c, Dragonboard-410c, rock-pi-4,
>> qemu-arm64 and qemu-x86_64
>> - selftests mm gup_longterm fails
>>
>> Regression Analysis:
>> - New regression? Yes
>> - Reproducibility? Yes
>>
>> Test regression: selftests mm gup_longterm error while loading shared
>> libraries liburing.so.2 cannot open shared object file No such file or
>> directory
>> Test regression: selftests mm cow error while loading shared
libraries>> liburing.so.2 cannot open shared object file No such file or
directory
>
> These do not really look like kernel regressions, rather like a bug in
> the userspace testing tool 🤔 Could it be that the tests were not
> rebuilt for the new liburing or that the dependency is not installed in
> the test environment?
It looks like the tests were build with liburing around, and then ran
without liburing around.
Note that the file for example has:
#ifdef LOCAL_CONFIG_HAVE_LIBURING
#include <liburing.h>
#endif /* LOCAL_CONFIG_HAVE_LIBURING */
You should be running into similar issues with cow.c, which uses the
exact same approach for detecting+linking liburing.
So seems like something is off in your testing environment?
--
Cheers,
David / dhildenb
Powered by blists - more mailing lists