linux-kernel - Re: [PATCH] lockdep: lock_set_subclass

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]

Date:	Fri, 1 Aug 2008 12:24:43 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	David Miller <davem@...emloft.net>, mingo@...e.hu,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org
Subject: Re: [PATCH] lockdep: lock_set_subclass - reset a held lock's
 subclass

On Fri, 1 Aug 2008, Jeremy Fitzhardinge wrote:
> 
> I have a function traversing a pagetable in vaddr order (low to high), taking
> pte locks as it builds up batches of pte page updates.  When the batch is
> issued, it releases all the locks, and won't end up holding more than ~16 at a
> time.

Hmm. 

With hashed locks, that is _not_ safe in general. Now, it may well be safe 
in your case, so I'm not going to say you have a bug, but even if you do 
them in vaddr order, the thing is, we don't guarantee that the _locks_ are 
ordered in virtual address order.

Right now, I think the pte locks are either a single one per mm (in which 
case I assume you don't take any lock at all), or it's a lock that is 
embedded in the pmd page iirc.

What if you have pmd sharing through some shared area being mapped at two 
different processes at different addresses? Yeah, I don't think we share 
pmd's at all (except if you use hugetables and for the kernel), but it's 
one of those things where subtle changes in how the pte lock allocation 
could cause problems.

Eg, I could easily see somebody doing the pte lock as a hash over not just 
the address, but the "struct mm" pointer too. At which point different 
parts of the address space might even share the PTE lock, and you'd get 
deadlocks even without any ABBA behavior, just because the pte lock might 
be A B C A or something inside the same process.

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