[<prev] [next>] [day] [month] [year] [list]
Message-ID: <202006041542.0720CB7A@keescook>
Date: Thu, 4 Jun 2020 15:45:46 -0700
From: Kees Cook <keescook@...omium.org>
To: kernel test robot <rong.a.chen@...el.com>
Cc: Al Viro <viro@...iv.linux.org.uk>,
Andrew Morton <akpm@...ux-foundation.org>,
Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
Eric Biggers <ebiggers3@...il.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
linux-fsdevel@...r.kernel.org,
linux-security-module@...r.kernel.org, linux-api@...r.kernel.org,
linux-kernel@...r.kernel.org, lkp@...ts.01.org, ltp@...ts.linux.it
Subject: Re: [exec] 166d03c9ec: ltp.execveat02.fail
On Mon, May 25, 2020 at 05:14:20PM +0800, kernel test robot wrote:
> Greeting,
(Whoops, I missed this in my inbox.)
> <<<test_start>>>
> tag=execveat02 stime=1590373229
> cmdline="execveat02"
> contacts=""
> analysis=exit
> <<<test_output>>>
> tst_test.c:1246: INFO: Timeout per run is 0h 05m 00s
> execveat02.c:64: PASS: execveat() fails as expected: EBADF (9)
> execveat02.c:64: PASS: execveat() fails as expected: EINVAL (22)
> execveat02.c:61: FAIL: execveat() fails unexpectedly, expected: ELOOP: EACCES (13)
> execveat02.c:64: PASS: execveat() fails as expected: ENOTDIR (20)
I will go check on this. Looking at the expected result (ELOOP) I think
this just means the test needs adjustment because it's trying to
double-check for a pathological case, but it seems their test setup
trips the (now earlier) IS_SREG() test. But I'll double-check and report
back!
--
Kees Cook
Powered by blists - more mailing lists