On Fri, Nov 19, 2021 at 10:14:38AM +1100, NeilBrown wrote: > On Thu, 18 Nov 2021, Matthew Wilcox wrote: > > Surely this should be gfpflags_allow_blocking() instead of poking about > > in the innards of gfp flags? > > Possibly. Didn't know about gfpflags_allow_blocking(). From a quick > grep in the kernel, a whole lot of other people don't know about it > either, though clearly some do. > > Maybe we should reaname "__GFP_DIRECT_RECLAIM" to > "__GFP_ALLOW_BLOCKING", because that is what most users seems to care > about. I tend towards the school of thought that the __GFP flags should make sense to the implementation and users should use either GFP_ or functions. When we see users adding or subtracting __GFP flags, that's a problem. > If not, then we probably want a gfpflags_without_block() function that > removes that flag, as lots of code wants to do that - and using the flag > for one, and an inline for the other is not consistent. It's not a _lot_ of code ... block/bio.c drivers/net/ethernet/mellanox/mlx4/icm.c drivers/vhost/net.c fs/btrfs/disk-io.c fs/btrfs/volumes.c fs/erofs/zdata.c fs/fscache/cookie.c fs/fscache/page.c kernel/cgroup/cgroup.c net/core/skbuff.c net/core/sock.c net/netlink/af_netlink.c (excluding mm -- if mm wants to meddle with GFP flags, that's fine) I think a lot of these are probably misguided, eg the filesystems should probably be using GFP_NOFS to prevent recursion.
