remap_file_pages - Bug with _PAGE_PROTNONE - is it used in current kernels?
I've been hitting a bug on a patch I'm working on and have considered (and more or less tested with good results) doing this change:
-#define pte_present(x) ((x).pte_low & (_PAGE_PRESENT | _PAGE_PROTNONE)) +#define pte_present(x) ((x).pte_low & (_PAGE_PRESENT))
(and the corresponding thing on other architecture).
In general, the question is whether __P000 and __S000 in protection_map are ever used except for MAP_POPULATE, and even then if they work well.
I'm seeking for objections to this change and/or anything I'm missing.
This bug showed up while porting remap_file_pages protection support to 2.6.16-rc3. It always existed but couldn't trigger before the PageReserved changes.
Consider a _PAGE_PROTNONE pte, which has then pte_pfn(pte) == 0 (with remap_file_pages you need them to exist). Obviously pte_pfn(pte) on such a PTE doesn't make sense, but since pte_present(pte) gives true the code doesn't know that.
Consider a call to munmap on this range. We get to zap_pte_range() which (in condensed source code):
zap_pte_range()
...
if (pte_present(ptent)) {
//This test is passed
struct page *page = vm_normal_page(vma, addr, ptent);
//Now page points to page 0 - which is wrong, page should be NULL
page_remove_rmap(page);//Which doesn't make any sense.
//If mem_map[0] wasn't mapped we hit a BUG now, if it was we'll hit it later - //i.e. negative page_mapcount().
Now, since this code doesn't work in this situation, I wonder whether PROTNONE is indeed used anywhere in the code *at the moment*, since faults on pages mapped as such are handled with SIGSEGV.
The only possible application, which is only possible in 2.6 and not in 2.4 where _PAGE_PROTNONE still exists, is mmap(MAP_POPULATE) with prot == PROT_NONE.
Instead I need to make use of PROTNONE, so the handling of it may need changes. In particular, I wonder about why:
#define pte_present(x) ((x).pte_low & (_PAGE_PRESENT | _PAGE_PROTNONE))
I see why that _PAGE_PROTNONE can make sense, but in the above code it doesn't.
Signature · 18 lines
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Quoted 6 lines · Blaisorblade
I've been hitting a bug on a patch I'm working on and have considered (and more or less tested with good results) doing this change:
(quoted diff) +1
-1-#define pte_present(x) ((x).pte_low & (_PAGE_PRESENT | _PAGE_PROTNONE)) +#define pte_present(x) ((x).pte_low & (_PAGE_PRESENT))
Quoted 6 lines
(and the corresponding thing on other architecture).
In general, the question is whether
__P000and__S000inprotection_mapare ever used except forMAP_POPULATE, and even then if they work well.I'm seeking for objections to this change and/or anything I'm missing.
Objection, your honor.
Quoted 8 lines
This bug showed up while porting
remap_file_pagesprotection support to 2.6.16-rc3. It always existed but couldn't trigger before the PageReserved changes.Consider a
_PAGE_PROTNONEpte, which has thenpte_pfn(pte)== 0 (withremap_file_pagesyou need them to exist). Obviouslypte_pfn(pte)on such a PTE doesn't make sense, but sincepte_present(pte)gives true the code doesn't know that.
I didn't fully understand you there, but I think you've got it the wrong way round: _PAGE_PROTNONE is included in the pte_present() test precisely because there is a valid page there, pfn is set (it might be pfn 0, yes, but much more likely to be pfn non-0).
I've never used PROT_NONE myself (beyond testing), but I think the traditional way it's used is this: mmap(,,PROT_READ|PROT_WRITE,,,), initialize the pages of that mapping, then mprotect(,,PROT_NONE) - which retains all those pages but make them generate SIGSEGVs - so the app can detect accesses and decide if it wants to do something special with them, other than the obvious mprotect(,,PROT_READ) or whatever.
PROT_NONE gives you a way of holding the page present (unlike munmap), yet failing access. And since those pages remain present, they do need to be freed later when you get to zap_pte_range. They are normal pages, but user access to them has been restricted.
Hugh
Quoted 29 lines
Consider a call to munmap on this range. We get to
zap_pte_range()which (in condensed source code):
zap_pte_range()
...if (pte_present(ptent)) { //This test is passed struct page *page = vm_normal_page(vma, addr, ptent); //Now page points to page 0 - which is wrong, page should be NULL page_remove_rmap(page);//Which doesn't make any sense.
//If mem_map[0] wasn't mapped we hit a BUG now, if it was we'll hit it later - //i.e. negativepage_mapcount().Now, since this code doesn't work in this situation, I wonder whether PROTNONE is indeed used anywhere in the code *at the moment*, since faults on pages mapped as such are handled with SIGSEGV.
The only possible application, which is only possible in 2.6 and not in 2.4 where
_PAGE_PROTNONEstill exists, ismmap(MAP_POPULATE)with prot ==PROT_NONE.Instead I need to make use of PROTNONE, so the handling of it may need changes. In particular, I wonder about why:
#define
pte_present(x)((x).pte_low & (_PAGE_PRESENT|_PAGE_PROTNONE))I see why that
_PAGE_PROTNONEcan make sense, but in the above code it doesn't.
Quoted 7 lines · Hugh Dickins
Quoted 6 lines · Blaisorblade
I've been hitting a bug on a patch I'm working on and have considered (and more or less tested with good results) doing this change:
(quoted diff) +1
-1-#define pte_present(x) ((x).pte_low & (_PAGE_PRESENT | _PAGE_PROTNONE)) +#define pte_present(x) ((x).pte_low & (_PAGE_PRESENT))
Quoted 8 lines
Quoted 6 lines
(and the corresponding thing on other architecture).
In general, the question is whether
__P000and__S000inprotection_mapare ever used except forMAP_POPULATE, and even then if they work well.I'm seeking for objections to this change and/or anything I'm missing.
Objection, your honor.
English humor :-) ?
Quoted 13 lines
I didn't fully understand you there, but I think you've got it the wrong way round:
_PAGE_PROTNONEis included in thepte_present()test precisely because there is a valid page there, pfn is set (it might be pfn 0, yes, but much more likely to be pfn non-0).I've never used
PROT_NONEmyself (beyond testing), but I think the traditional way it's used is this:mmap(,,PROT_READ|PROT_WRITE,,,), initialize the pages of that mapping, thenmprotect(,,PROT_NONE)- which retains all those pages but make them generate SIGSEGVs - so the app can detect accesses and decide if it wants to do something special with them, other than the obviousmprotect(,,PROT_READ)or whatever.
Quoted 4 lines
PROT_NONEgives you a way of holding the page present (unlike munmap), yet failing access. And since those pages remain present, they do need to be freed later when you get tozap_pte_range. They are normal pages, but user access to them has been restricted.
Ok, thanks for the explaination.
The bug is born from the patched install_file_pte(). Before there was no need to store the protection bits, now it's needed.
So, it sets a pte_file PTE containing no page, and on PROT_NONE it uses _PAGE_PROTNONE|_PAGE_FILE.
Indeed, what I've actually coded and tested was safer, but I wanted to know if it could be simpler (and faster). For i386 it should be (I've re-tested only UML so far):
-#define pte_present(x) ((x).pte_low & (_PAGE_PRESENT | _PAGE_PROTNONE)) +#define pte_present(x) (((x).pte_low & _PAGE_PRESENT) || \
+ (((x).pte_low & (_PAGE_PROTNONE|_PAGE_FILE)) == _PAGE_PROTNONE))
--- linux-2.6.git.orig/include/asm-um/pgtable.h
+++ linux-2.6.git/include/asm-um/pgtable.h
@@
-#define pte_present(x) pte_get_bits(x, (_PAGE_PRESENT | _PAGE_PROTNONE)) +#define pte_present(x) (pte_get_bits(x, (_PAGE_PRESENT)) || (pte_get_bits(x, (_PAGE_PROTNONE)) && !pte_file(x)))
Signature · 18 lines
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>