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
| ||
|
Date: Thu, 5 Nov 2015 09:56:07 +0900 From: Minchan Kim <minchan@...nel.org> To: Andy Lutomirski <luto@...capital.net> Cc: Hugh Dickins <hughd@...gle.com>, Andrew Morton <akpm@...ux-foundation.org>, Michael Kerrisk <mtk.manpages@...il.com>, Michal Hocko <mhocko@...e.cz>, "linux-mm@...ck.org" <linux-mm@...ck.org>, KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>, "Kirill A. Shutemov" <kirill@...temov.name>, Rik van Riel <riel@...hat.com>, Johannes Weiner <hannes@...xchg.org>, Linux API <linux-api@...r.kernel.org>, Jason Evans <je@...com>, Shaohua Li <shli@...nel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, yalin wang <yalin.wang2010@...il.com>, Daniel Micay <danielmicay@...il.com>, Mel Gorman <mgorman@...e.de> Subject: Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE) On Wed, Nov 04, 2015 at 04:42:37PM -0800, Andy Lutomirski wrote: > On Wed, Nov 4, 2015 at 4:13 PM, Minchan Kim <minchan@...nel.org> wrote: > > On Tue, Nov 03, 2015 at 07:41:35PM -0800, Andy Lutomirski wrote: > >> On Nov 3, 2015 5:30 PM, "Minchan Kim" <minchan@...nel.org> wrote: > >> > > >> > Linux doesn't have an ability to free pages lazy while other OS already > >> > have been supported that named by madvise(MADV_FREE). > >> > > >> > The gain is clear that kernel can discard freed pages rather than swapping > >> > out or OOM if memory pressure happens. > >> > > >> > Without memory pressure, freed pages would be reused by userspace without > >> > another additional overhead(ex, page fault + allocation + zeroing). > >> > > >> > >> [...] > >> > >> > > >> > How it works: > >> > > >> > When madvise syscall is called, VM clears dirty bit of ptes of the range. > >> > If memory pressure happens, VM checks dirty bit of page table and if it > >> > found still "clean", it means it's a "lazyfree pages" so VM could discard > >> > the page instead of swapping out. Once there was store operation for the > >> > page before VM peek a page to reclaim, dirty bit is set so VM can swap out > >> > the page instead of discarding. > >> > >> What happens if you MADV_FREE something that's MAP_SHARED or isn't > >> ordinary anonymous memory? There's a long history of MADV_DONTNEED on > >> such mappings causing exploitable problems, and I think it would be > >> nice if MADV_FREE were obviously safe. > > > > It filter out VM_LOCKED|VM_HUGETLB|VM_PFNMAP and file-backed vma and MAP_SHARED > > with vma_is_anonymous. > > > >> > >> Does this set the write protect bit? > > > > No. > > > >> > >> What happens on architectures without hardware dirty tracking? For > >> that matter, even on architecture with hardware dirty tracking, what > >> happens in multithreaded processes that have the dirty TLB state > >> cached in a different CPU's TLB? > >> > >> Using the dirty bit for these semantics scares me. This API creates a > >> page that can have visible nonzero contents and then can > >> asynchronously and magically zero itself thereafter. That makes me > >> nervous. Could we use the accessed bit instead? Then the observable > > > > Access bit is used by aging algorithm for reclaim. In addition, > > we have supported clear_refs feacture. > > IOW, it could be reset anytime so it's hard to use marker for > > lazy freeing at the moment. > > > > That's unfortunate. I think that the ABI would be much nicer if it > used the accessed bit. > > In any case, shouldn't the aging algorithm be irrelevant here? A > MADV_FREE page that isn't accessed can be discarded, whereas we could > hopefully just say that a MADV_FREE page that is accessed gets moved > to whatever list holds recently accessed pages and also stops being a > candidate for discarding due to MADV_FREE? I meant if we use access bit as indicator for lazy-freeing page, we could discard valid page which is never hinted by MADV_FREE but just doesn't mark access bit in page table by aging algorithm. > > >> > >> > + if (!PageDirty(page) && (flags & TTU_FREE)) { > >> > + /* It's a freeable page by MADV_FREE */ > >> > + dec_mm_counter(mm, MM_ANONPAGES); > >> > + goto discard; > >> > + } > >> > >> Does something clear TTU_FREE the next time the page gets marked clean? > > > > Sorry, I don't understand. Could you elaborate it more? > > I don't fully understand how TTU_FREE ends up being set here, but, if > the page is dirtied by user code and then cleaned later by the kernel, > what prevents TTU_FREE from being incorrectly set here? Kernel shouldn't make the page clean without writeback(ie, swapout) if the page has valid data. > > > --Andy > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@...ck.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: <a href=mailto:"dont@...ck.org"> email@...ck.org </a> -- 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/
Powered by blists - more mailing lists