[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <69a1443e73dc1c10a23cf0632a507c01eece9760.camel@intel.com>
Date: Tue, 11 Feb 2025 18:29:26 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "Zhao, Yan Y" <yan.y.zhao@...el.com>
CC: "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "pbonzini@...hat.com"
<pbonzini@...hat.com>, "seanjc@...gle.com" <seanjc@...gle.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] KVM: selftests: Wait mprotect_ro_done before write to RO
in mmu_stress_test
On Tue, 2025-02-11 at 09:42 +0800, Yan Zhao wrote:
> > Is this a fix for the intermittent failure we saw on the v6.13-rc3 based kvm
> > branch? Funnily, I can't seem to reproduce it anymore, with or without this
> > fix.
> Hmm, it can be reproduced in my SPR (non TDX) almost every time.
> It depends on the timing when mprotect(PROT_READ) is completed done.
>
> Attached the detailed error log in my machine at the bottom.
I must be getting lucky on timing. BTW, in the above I actually meant on either
the new or old *kernel*.
>
> > On the fix though, doesn't this remove the coverage of writing to a region
> > that
> > is in the process of being made RO? I'm thinking about warnings, etc that
> > may
> > trigger intermittently based on bugs with a race component. I don't know if
> > we
> > could fix the test and still leave the write while the "mprotect(PROT_READ)
> > is
> > underway". It seems to be deliberate.
> Write before "mprotect(PROT_READ)" has been tested in stage 0.
> Not sure it's deliberate to test write in the process of being made RO.
> If it is, maybe we could make the fix by writing to RO memory a second time
> after mprotect_ro_done is true:
That could work if it's desirable to maintain the testing. I would mention the
reduced scope in the log at least. Maybe Sean will chime in.
Also, I think it needs:
Fixes: b6c304aec648 ("KVM: selftests: Verify KVM correctly handles
mprotect(PROT_READ)")
Powered by blists - more mailing lists