linux-kernel - Re: [PATCH] remove double indirection on tlb parameter to free_pgd

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0805161715390.28836@blonde.site>
Date:	Fri, 16 May 2008 17:31:45 +0100 (BST)
From:	Hugh Dickins <hugh@...itas.com>
To:	Jan Beulich <jbeulich@...ell.com>
cc:	Jeremy Fitzhardinge <jeremy@...p.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Andrea Arcangeli <andrea@...ranet.com>,
	Christoph Lameter <clameter@....com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] remove double indirection on tlb parameter to
 free_pgd_range()& Co

On Fri, 16 May 2008, Jan Beulich wrote:
> 
> If you want to keep and actively use the double indirection, would you

I'd much rather replace it with something better, but it's not easy
to solve all the problems which Ben and I variously wanted to address.

> guarantee current semantics like ->mm and ->fullmm to always be what
> was specified at the start of the operation?

Of course.  The stopping and restarting of those gathers was never
intended to switch mm midstream, and there's that odd way in which
unmap_vmas saves the current value of fullmm to provide to the next
gathering.  Not the nicest interface, I agree; but it's not widespread.

> Verifying this was what
> made me go through that call tree in the first place, and obviously this
> is harder to verify when there is potential for the whole structure
> pointed to to be replaced by another one.

Or, looking at it from the point of a cpu rather than from the point
of view of the call chain, of course not.  Typically the mmu_gather_t
(in that current implementation) is a per-cpu area, and the call chain
may switch over to a different cpu's mmu_gather_t in between stopping
and restarting, and the original cpu's be used for a different mm.

Hugh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/