![]() | |||||||||||||
Messages in this thread |
On Fri, Dec 06, 2002 at 04:01:24PM -0800, Andrew Morton wrote: > One way to address this could be to find a way of making the > pages present, but still cause a fault on first access. Then > have a special-case fastpath in the fault handler to really wipe > the page just before it is used. I don't know how though - maybe > _PAGE_USER? All of the problems there have to do with accounting which pieces of the page are zeroed. The PTE's map the same size areas (MMUPAGE_SIZE stays 4KB)... So after a partial zero we end up with a struct page pointing at MMUPAGE_COUNT mmupages, and a PTE pointing at the one that's been zeroed and not a whole lot of flag bits left to keep track of which pieces are initialized. How about a single PG_zero flag and map out which bits of the thing are already zeroed in page->private? (basically the swapcache can be considered the owning fs and it then then uses page->private for those shenanigans). On Fri, Dec 06, 2002 at 04:01:24PM -0800, Andrew Morton wrote: > get_user_pages() would need attention too - you don't want to > allow the user to perform O_DIRECT writes of uninitialised > pages to their files... Well, I'm not sure how that would happen. fs io should deal with kernel PAGE_SIZE-sized units so we're dealing with anonymous memory only. O_DIRECT if we perform a write would only find the part of the page mapped by a PTE, which must have been pre-zeroed prior to being mapped. Reads seem to be in equally good shape. Perhaps it's more of "this is yet another things to audit when dealing with it"; I'll admit that the audit needed for this thing is somewhat large. Bill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-03-22 12:31 [W:0.300 / U:0.000 seconds] ©2003-2008 Jasper Spaans | |||||||||||||