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: Wed, 4 Nov 2015 16:42:37 -0800 From: Andy Lutomirski <luto@...capital.net> To: Minchan Kim <minchan@...nel.org> 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 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? >> >> > + 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? --Andy -- 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