linux-kernel - Re: PTE access rules & abstraction

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: <1222296784.8277.126.camel@pasglop>
Date:	Thu, 25 Sep 2008 08:53:04 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Hugh Dickins <hugh@...itas.com>,
	Linux Memory Management List <linux-mm@...ck.org>,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Nick Piggin <npiggin@...e.de>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Peter Chubb <peterc@...ato.unsw.edu.au>
Subject: Re: PTE access rules & abstraction

> Yes, that sounds fine in principle, but the practise gets tricky.  The
> trouble with that kind of interface is that it can be fairly heavyweight
> unless you amortise the cost of the transaction setup/commit with
> multiple operations.

I agree. Anyway, I'm sure if we get everybody around the same table, we
can find something, maybe not that high level, but a better set of
accessors that fits all needs with a more precise semantic. Anyway, I'll
see if I can come up with ideas later that we can discuss.

It's also all inline so it does give us flexibility in having things
compile down to nothing on archs where they aren't needed.

> Are you using the lazy_mmu hooks we put in, or something else?

Yes. We used to do it differently but it was actually racy in a subtle
way, and I switched it to use your lazy_mmu hooks a while ago.

> Likely; it's one of those overused generic words.  The specific meaning
> I'm using is "we can roll a bunch of updates into a single hypercall". 
> Operations which do atomic RMW  or fetch-set are typically not batchable
> because the caller wants the result *now* and can't wait for a deferred
> result.

Right. For us it's mostly about flushing the hash entries, though there
is no fundamental difference I believe here, it's about updating a
cache, whether it's the TLB, our hash table, hypervisor shadows, etc...
and we -should- be able to find a more sensible common ground.

Cheers,
Ben.

--
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/