| Message ID | 20231208151022.156273-1-aleksandr.mikhalitsyn@canonical.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | fs: super: use GFP_KERNEL instead of GFP_USER for super block allocation | expand |
On Fri 08-12-23 16:10:22, Alexander Mikhalitsyn wrote: > There is no reason to use a GFP_USER flag for struct super_block allocation > in the alloc_super(). Instead, let's use GFP_KERNEL for that. > > From the memory management perspective, the only difference between > GFP_USER and GFP_KERNEL is that GFP_USER allocations are tied to a cpuset, > while GFP_KERNEL ones are not. > > There is no real issue and this is not a candidate to go to the stable, > but let's fix it for a consistency sake. > > Cc: Jan Kara <jack@suse.cz> > Cc: Alexander Viro <viro@zeniv.linux.org.uk> > Cc: Christian Brauner <brauner@kernel.org> > Cc: linux-fsdevel@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com> Yeah, since we allocate other filesystem objects with GFP_KERNEL as well I agree. Feel free to add: Reviewed-by: Jan Kara <jack@suse.cz> Honza > diff --git a/fs/super.c b/fs/super.c > index 076392396e72..6fe482371633 100644 > --- a/fs/super.c > +++ b/fs/super.c > @@ -323,7 +323,7 @@ static void destroy_unused_super(struct super_block *s) > static struct super_block *alloc_super(struct file_system_type *type, int flags, > struct user_namespace *user_ns) > { > - struct super_block *s = kzalloc(sizeof(struct super_block), GFP_USER); > + struct super_block *s = kzalloc(sizeof(struct super_block), GFP_KERNEL); > static const struct super_operations default_op; > int i; > > -- > 2.34.1 >
On Fri, 08 Dec 2023 16:10:22 +0100, Alexander Mikhalitsyn wrote: > There is no reason to use a GFP_USER flag for struct super_block allocation > in the alloc_super(). Instead, let's use GFP_KERNEL for that. > > >From the memory management perspective, the only difference between > GFP_USER and GFP_KERNEL is that GFP_USER allocations are tied to a cpuset, > while GFP_KERNEL ones are not. > > [...] Applied to the vfs.misc branch of the vfs/vfs.git tree. Patches in the vfs.misc branch should appear in linux-next soon. Please report any outstanding bugs that were missed during review in a new review to the original patch series allowing us to drop it. It's encouraged to provide Acked-bys and Reviewed-bys even though the patch has now been applied. If possible patch trailers will be updated. Note that commit hashes shown below are subject to change due to rebase, trailer updates or similar. If in doubt, please check the listed branch. tree: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git branch: vfs.misc [1/1] fs: super: use GFP_KERNEL instead of GFP_USER for super block allocation https://git.kernel.org/vfs/vfs/c/b91dbdebd653
diff --git a/fs/super.c b/fs/super.c index 076392396e72..6fe482371633 100644 --- a/fs/super.c +++ b/fs/super.c @@ -323,7 +323,7 @@ static void destroy_unused_super(struct super_block *s) static struct super_block *alloc_super(struct file_system_type *type, int flags, struct user_namespace *user_ns) { - struct super_block *s = kzalloc(sizeof(struct super_block), GFP_USER); + struct super_block *s = kzalloc(sizeof(struct super_block), GFP_KERNEL); static const struct super_operations default_op; int i;
There is no reason to use a GFP_USER flag for struct super_block allocation in the alloc_super(). Instead, let's use GFP_KERNEL for that. From the memory management perspective, the only difference between GFP_USER and GFP_KERNEL is that GFP_USER allocations are tied to a cpuset, while GFP_KERNEL ones are not. There is no real issue and this is not a candidate to go to the stable, but let's fix it for a consistency sake. Cc: Jan Kara <jack@suse.cz> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Christian Brauner <brauner@kernel.org> Cc: linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com> --- fs/super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)