linux-kernel - Re: operation ordering during pgd_alloc/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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <4847D4D0.76E4.0078.0@novell.com>
Date:	Thu, 05 Jun 2008 10:58:08 +0100
From:	"Jan Beulich" <jbeulich@...ell.com>
To:	"Jeremy Fitzhardinge" <jeremy@...p.org>
Cc:	"Ingo Molnar" <mingo@...e.hu>, <linux-kernel@...r.kernel.org>
Subject: Re: operation ordering during pgd_alloc/pgd_free

>But I think there's a problem *without* preemption.  
>pmd_prepopulate_pgd() allocates new pmds with GFP_KERNEL, and so it can 
>block, which undermines the precondition of the comment you quote.  This 
>allows an unlisted and unpinned pgd to be missed at save time.  I could 
>just use the freezer unconditionally, but there was some concern about 
>how much time it would take on a busy system.
>
>Alternatively, a different ordering would fix it:
>
>   1. preallocate - but don't install - the pmds
>   2. take pgd_lock
>   3. install pmds into pgd
>   4. insert pgd onto list
>   5. release pgd_lock

... which is precisely what the XenSource tree does.

>> The issue with vmalloc_sync_all() would even go unnoticed, since the
>> patch to unify the pgd_list mechanism with x86-64 removed the
>> BUG_ON() that was meant to trigger on issues like this.
>>   
>
>Is there an inherent reason vmalloc_sync_all can't deal with a partially 
>constructed pgd?  Couldn't it just skip them, as if it wasn't (or 
>rather, not yet) on the list?  In fact, that looks like what it does now.

It could be made so, but it doesn't at present - it exits the inner loop
when vmalloc_sync_one() returns NULL. The intention here is that if
the reference page table has a clear entry at some level, then there
shouldn't be any attempt to look at other page tables' entries mapping
the same va (and because it would be an error if page table other than
the reference one had a clear entry where the reference one didn't,
there was that BUG_ON() that your patch removed). Since the purpose
of vmalloc_sync_all() is to catch partially populated page tables, allowing
it to skip such that are under construction would need a way to
distinguish them from such being fully constructed but out of sync.

Jan

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