linux-kernel - Re: lockdep: how to tell it multiple pte locks is OK?

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <C2543D65-1241-47E6-8C06-BF6E4F73E19A@goop.org>
Date:	Sun, 7 Oct 2007 10:17:47 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: lockdep: how to tell it multiple pte locks is OK?

On Oct 7, 2007, at 9:58 AM, Arjan van de Ven wrote:

> On Sat, 06 Oct 2007 23:31:33 -0700
>
>> I'm presume I'm the first person to try holding multiple pte locks at
>> once, so there's no existing locking order for these locks.  I'm
>> always traversing and locking the pagetable in virtual address order
>> (and this seems like a sane-enough rule for anyone else who wants to
>> hold multiple pte locks).
>
> I'm not sure that's a valid assumption in light of things like sharing
> pagetables between processes etc etc..
> (granted, that one is out of tree right now but I still hope it'll go
> in some day:)

Well, yes, but that will take some thought about how split pte locks  
will work anyway (or more specifically, fork will probably just end  
up reusing the pte pages and avoid the need to do any cross-pagetable  
pte locking anyway, though I guess that will be deferred to COW  
handling).

So are you saying I should pass up the opportunity to optimise a  
relatively hot path (fork/exec/exit) because it will need some  
further thought if/when shared ptes get implemented?  Doesn't seem  
like a good tradeoff...

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