[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <95f17f84-f172-417c-fe7e-ca0a07b205fb@intel.com>
Date: Wed, 3 May 2023 09:44:50 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: "Kirill A. Shutemov" <kirill@...temov.name>,
Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
linux-kernel@...r.kernel.org, kirill.shutemov@...ux.intel.com,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: [GIT PULL] x86/mm for 6.4
On 5/3/23 09:38, Linus Torvalds wrote:
>> Why does it do that "shift-by-63" game there, instead of making
>> tlbstate_untag_mask just have bit #63 always set?
> And it turns out that bit #63 really _is_ always set, so I think the
> solution to this all is to remove the sign games in untag_addr()
> entirely.
Yes, there are only two possible values right now, both of which have
bit 63 set:
LAM off: mm->context.untag_mask = -1UL;
LAM on: mm->context.untag_mask = ~GENMASK(62, 57);
> Untagging a kernel address will "corrupt" it, but it will stay a
> kernel address (well, it will stay a "high bit set" address), which is
> all we care about anyway.
>
> If somebody actually tries to untag a kernel address, that would be a
> bug anyway, as far as I can tell.
Is it a bug? The do_madvise() path, for instance, is passing a value in
there that came right from userspace.
> So I'm going to just remove the 'sign' games entirely. They are
> completely broken in 'untagged_addr_remote()', they _used_ to be
> completely broken in 'untagged_addr()', and it looks like it's all
> unnecessary.
Yes, it looks completely superfluous.
Powered by blists - more mailing lists