[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yh4+Fjs2yhbWux9C@iweiny-desk3>
Date: Tue, 1 Mar 2022 07:39:02 -0800
From: Ira Weiny <ira.weiny@...el.com>
To: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
Cc: "hpa@...or.com" <hpa@...or.com>,
"Williams, Dan J" <dan.j.williams@...el.com>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"Yu, Fenghua" <fenghua.yu@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V8 30/44] mm/pkeys: Test setting a PKS key in a custom
fault callback
On Mon, Jan 31, 2022 at 04:55:47PM -0800, Edgecombe, Rick P wrote:
> On Thu, 2022-01-27 at 09:54 -0800, ira.weiny@...el.com wrote:
> > Add a test which does this.
> >
> > $ echo 5 > /sys/kernel/debug/x86/run_pks
> > $ cat /sys/kernel/debug/x86/run_pks
> > PASS
>
> Hmm, when I run this on qemu TCG, I get:
>
> root@(none):/# echo 5 > /sys/kernel/debug/x86/run_pks
> [ 29.438159] pks_test: Failed to see the callback
> root@(none):/# cat /sys/kernel/debug/x86/run_pks
> FAIL
>
> I think it's a problem with the test though. The generated code is not
> expecting fault_callback_ctx.callback_seen to get changed in the
> exception. The following fixed it for me:
>
> diff --git a/lib/pks/pks_test.c b/lib/pks/pks_test.c
> index 1528df0bb283..d979d2afe921 100644
> --- a/lib/pks/pks_test.c
> +++ b/lib/pks/pks_test.c
> @@ -570,6 +570,7 @@ static bool run_fault_clear_test(void)
> /* fault */
> memcpy(test_page, ctx->data, 8);
>
> + barrier();
> if (!fault_callback_ctx.callback_seen) {
> pr_err("Failed to see the callback\n");
> rc = false;
>
> But, I wonder if volatile is also needed on the read to be fully
> correct. I usually have to consult the docs when I deal with that
> stuff...
I was not able to reproduce this. However, I've done a lot of reading and I
think you are correct that the barrier is needed. I thought WRITE_ONCE was
sufficient and I had used it in other calls but I missed it here.
As part of the test rework I've added a call to barrier() for all the tests.
In addition I've simplified, and hopefully clarified, which variables are
being shared with the fault handler.
Thanks for the testing and review!
Ira
Powered by blists - more mailing lists