On 6/28/19 4:44 PM, Christoph Hellwig wrote: > On Fri, Jun 28, 2019 at 07:30:49AM +0000, Damien Le Moal wrote: >> >> Yes, indeed. However, removing the gfp_flags from report_zones method >> would limit possibilities to only GFP_NOIO or GFP_KERNEL (default >> vmalloc). What if the caller is an FS and needs GFP_NOFS, or any other >> reclaim flags ? Handling all possibilities does not seem reasonable. >> Handling only GFP_KERNEL and GFP_IO is easy, but that would mean that >> the caller of blkdev_report_zones would need to do itself calls to >> whatever memalloc_noXX_save/restore() it needs. Is that OK ? > > I think it is ok. The only real possibily is noio anyway as far as > I can tell. > >> >> Currently, blkdev_report_zones() uses only either GFP_KERNEL (general >> case, fs, dm and user ioctl), or GFP_NOIO for revalidate, disk scan and >> dm-zoned error path. So removing the flag from the report zones method >> while keeping it in the block layer API to distinguished these cases is >> simple, but I am not sure if that will not pause problems for some >> users. Thoughts ? > > I'd kill it from the block layer API and require the caller to set > the per-task flag. If I understood the mm maintainers correctly the > long term plan is to kill of GFP_NOFS and GFP_NOIO flowly and just rely > on the contexts. OK. Got it. Easy then. However, doing everything in this patch will make the patch quite big as nullblk and dm also need changes. Should I kill the gfp_mask argument in a separate patch before this one ? -- Damien Le Moal Western Digital Research
