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, 27 Apr 2016 19:53:21 +0900 From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp> To: Michal Hocko <mhocko@...nel.org>, linux-mm@...ck.org Cc: Andrew Morton <akpm@...ux-foundation.org>, Dave Chinner <david@...morbit.com>, "Theodore Ts'o" <tytso@....edu>, Chris Mason <clm@...com>, Jan Kara <jack@...e.cz>, LKML <linux-kernel@...r.kernel.org>, Michal Hocko <mhocko@...e.com> Subject: Re: [PATCH 1/2] mm: add PF_MEMALLOC_NOFS On 2016/04/26 20:56, Michal Hocko wrote: > Not only this is easier to understand and maintain because there are > much less problematic contexts than specific allocation requests, this > also helps code paths where FS layer interacts with other layers (e.g. > crypto, security modules, MM etc...) and there is no easy way to convey > the allocation context between the layers. > You arrived at what I wished at http://lkml.kernel.org/r/201503172305.DIH52162.FOFMFOVJHLOtQS@I-love.SAKURA.ne.jp (i.e. not CONFIG_DEBUG_* but always enabled). > Introduce PF_MEMALLOC_NOFS task specific flag and memalloc_nofs_{save,restore} > API to control the scope. This is basically copying > memalloc_noio_{save,restore} API we have for other restricted allocation > context GFP_NOIO. > > Xfs has already had a similar functionality as PF_FSTRANS so let's just > give it a more generic name and make it usable for others as well and > move the GFP_NOFS context tracking to the page allocator. Xfs has its > own accessor functions but let's keep them for now to reduce this patch > as minimum. > > This patch shouldn't introduce any functional changes. Xfs code paths > preserve their semantic. kmem_flags_convert() doesn't need to evaluate > the flag anymore because it is the page allocator to care about the > flag. memalloc_noio_flags is renamed to current_gfp_context because it > now cares about both PF_MEMALLOC_NOFS and PF_MEMALLOC_NOIO contexts. > > Let's hope that filesystems will drop direct GFP_NOFS (resp. ~__GFP_FS) > usage as much and possible and only use a properly documented > memalloc_nofs_{save,restore} checkpoints where they are appropriate. Is the story simple enough to monotonically replace GFP_NOFS/GFP_NOIO with GFP_KERNEL after memalloc_no{fs,io}_{save,restore} are inserted? We sometimes delegate some operations to somebody else. Don't we need to convey PF_MEMALLOC_NOFS/PF_MEMALLOC_NOIO flags to APIs which interact with other threads?
Powered by blists - more mailing lists