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: Mon, 10 Jan 2022 17:25:15 +0100 From: Michal Hocko <mhocko@...e.com> To: Vlastimil Babka <vbabka@...e.cz> Cc: Yu Zhao <yuzhao@...gle.com>, Andrew Morton <akpm@...ux-foundation.org>, Linus Torvalds <torvalds@...ux-foundation.org>, Andi Kleen <ak@...ux.intel.com>, Catalin Marinas <catalin.marinas@....com>, Dave Hansen <dave.hansen@...ux.intel.com>, Hillf Danton <hdanton@...a.com>, Jens Axboe <axboe@...nel.dk>, Jesse Barnes <jsbarnes@...gle.com>, Johannes Weiner <hannes@...xchg.org>, Jonathan Corbet <corbet@....net>, Matthew Wilcox <willy@...radead.org>, Mel Gorman <mgorman@...e.de>, Michael Larabel <Michael@...haellarabel.com>, Rik van Riel <riel@...riel.com>, Will Deacon <will@...nel.org>, Ying Huang <ying.huang@...el.com>, linux-arm-kernel@...ts.infradead.org, linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org, linux-mm@...ck.org, page-reclaim@...gle.com, x86@...nel.org, Konstantin Kharlamov <Hi-Angel@...dex.ru> Subject: Re: [PATCH v6 6/9] mm: multigenerational lru: aging On Mon 10-01-22 17:01:07, Vlastimil Babka wrote: > On 1/10/22 16:01, Michal Hocko wrote: > > On Thu 06-01-22 17:12:18, Michal Hocko wrote: > >> On Tue 04-01-22 13:22:25, Yu Zhao wrote: > >> > +static struct lru_gen_mm_walk *alloc_mm_walk(void) > >> > +{ > >> > + if (!current->reclaim_state || !current->reclaim_state->mm_walk) > >> > + return kvzalloc(sizeof(struct lru_gen_mm_walk), GFP_KERNEL); > > > > One thing I have overlooked completely. You cannot really use GFP_KERNEL > > allocation here because the reclaim context can be constrained (e.g. > > GFP_NOFS). This allocation will not do any reclaim as it is PF_MEMALLOC > > but I suspect that the lockdep will complain anyway. > > > > Also kvmalloc is not really great here. a) vmalloc path is never > > executed for small objects and b) we do not really want to make a > > dependency between vmalloc and the reclaim (by vmalloc -> reclaim -> > > vmalloc). > > > > Even if we rule out vmalloc and look at kmalloc alone. Is this really > > safe? I do not see any recursion prevention in the SL.B code. Maybe this > > just happens to work but the dependency should be really documented so > > that future SL.B changes won't break the whole scheme. > > Slab implementations drop all locks before calling into page allocator (thus > possibly reclaim) so slab itself should be fine and I don't expect it to > change. But we could eventually reach the page allocator recursively again, > that's true and not great. Thanks for double checking. If recursion is really intended and something SL.B allocators should support then this is definitely worth documenting so that a subtle change won't break in the future. -- Michal Hocko SUSE Labs
Powered by blists - more mailing lists