[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <c2a6d31f-173b-4d08-b377-e31748f33443@app.fastmail.com>
Date: Thu, 06 Apr 2023 15:21:26 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Petr Vorel" <pvorel@...e.cz>
Cc: "Naresh Kamboju" <naresh.kamboju@...aro.org>,
"open list" <linux-kernel@...r.kernel.org>,
"LTP List" <ltp@...ts.linux.it>, llvm@...ts.linux.dev,
chrubis <chrubis@...e.cz>,
"Nathan Chancellor" <nathan@...nel.org>,
"Anders Roxell" <anders.roxell@...aro.org>,
Daniel Díaz <daniel.diaz@...aro.org>,
"Benjamin Copeland" <ben.copeland@...aro.org>,
"Tudor Cretu" <tudor.cretu@....com>
Subject: Re: LTP: list of failures on 32bit and compat mode
On Thu, Apr 6, 2023, at 15:17, Petr Vorel wrote:
>> On Thu, Apr 6, 2023, at 14:48, Petr Vorel wrote:
>> >> On Thu, Apr 6, 2023, at 12:56, Petr Vorel wrote:
> Thanks! I've just searched in musl as well, because it didn't make sense to me
> it'd be a code for LTP.
>
> "to catch the fault on ltp" I wonder if it's not actually musl bug.
No, musl is fine here. The problem is that ltp passes an invalid pointer,
expecting to get -EFAULT from the kernel when that faults in
copy_to_user().
There is nothing wrong with musl sanitizing the data behind that
pointer, but then you get a signal instead of the EFAULT error.
Arnd
Powered by blists - more mailing lists