On Tue, 25 Feb 2025 at 18:45, Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote:
>
> Are you saying that the PTE dirty bit controls whether the CPU flushes
> cache back to memory? That isn't how I understand CPUs to work.
No, I'm saying that dropping the dirty bit drops information.
Yes, yes, we have the SW-dirty bit, and hopefully that is indeed
always set, but the way we test for "is this page dirty and needs
writeback" is literally to test *both*.
return pte_flags(pte) & _PAGE_DIRTY_BITS;
> I don't understand why the dirty bit needs to be saved. At least in
> the vfree() case, we're freeing the memory so any unflushed writes to
> it may as well disappear. But I don't know all the circumstances in
> which these functions are called.
I'm not saying that it needs to be saved.
But I *am* saying that it needs to be explained why dropping it is fine.
And I am also saying that your explanation for why it should be
cleared makes no sense, since two out of three cases also cleared
_PAGE_PRESENT, at which point the whole shadow stack issue is
completely irrelevant.
So please explain *why* clearing PAGE_DIRTY is ok. Don't bring up
issues like the shadow stack setting that is irrelevant for at least
two of the cases that you changed.
If all of these are purely used for vmalloc() or direct mappings, then
*that* is a valid explanation ("we don't care about dirty bits on
kernel mappings"), for example.
Linus
|