All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jaegeuk Kim <jaegeuk@kernel.org>
To: Eric Biggers <ebiggers@kernel.org>
Cc: linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH] f2fs: don't return vmalloc() memory from f2fs_kmalloc()
Date: Thu, 4 Jun 2020 18:15:35 -0700	[thread overview]
Message-ID: <20200605011535.GA102178@google.com> (raw)
In-Reply-To: <20200604210646.GA855@sol.localdomain>

On 06/04, Eric Biggers wrote:
> On Mon, May 18, 2020 at 12:10:16PM -0700, Jaegeuk Kim wrote:
> > On 05/18, Eric Biggers wrote:
> > > On Mon, May 18, 2020 at 11:06:48AM -0700, Jaegeuk Kim wrote:
> > > > On 05/05, Eric Biggers wrote:
> > > > > From: Eric Biggers <ebiggers@google.com>
> > > > > 
> > > > > kmalloc() returns kmalloc'ed memory, and kvmalloc() returns either
> > > > > kmalloc'ed or vmalloc'ed memory.  But the f2fs wrappers, f2fs_kmalloc()
> > > > > and f2fs_kvmalloc(), both return both kinds of memory.
> > > > > 
> > > > > It's redundant to have two functions that do the same thing, and also
> > > > > breaking the standard naming convention is causing bugs since people
> > > > > assume it's safe to kfree() memory allocated by f2fs_kmalloc().  See
> > > > > e.g. the various allocations in fs/f2fs/compress.c.
> > > > > 
> > > > > Fix this by making f2fs_kmalloc() just use kmalloc().  And to avoid
> > > > > re-introducing the allocation failures that the vmalloc fallback was
> > > > > intended to fix, convert the largest allocations to use f2fs_kvmalloc().
> > > > > 
> > > > > Signed-off-by: Eric Biggers <ebiggers@google.com>
> > > > > ---
> > > > >  fs/f2fs/checkpoint.c | 4 ++--
> > > > >  fs/f2fs/f2fs.h       | 8 +-------
> > > > >  fs/f2fs/node.c       | 8 ++++----
> > > > >  3 files changed, 7 insertions(+), 13 deletions(-)
> > > > > 
> > > > > diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
> > > > > index 97b6378554b406..ac5b47f15f5e77 100644
> > > > > --- a/fs/f2fs/checkpoint.c
> > > > > +++ b/fs/f2fs/checkpoint.c
> > > > > @@ -895,8 +895,8 @@ int f2fs_get_valid_checkpoint(struct f2fs_sb_info *sbi)
> > > > >  	int i;
> > > > >  	int err;
> > > > >  
> > > > > -	sbi->ckpt = f2fs_kzalloc(sbi, array_size(blk_size, cp_blks),
> > > > > -				 GFP_KERNEL);
> > > > > +	sbi->ckpt = f2fs_kvzalloc(sbi, array_size(blk_size, cp_blks),
> > > > > +				  GFP_KERNEL);
> > > > >  	if (!sbi->ckpt)
> > > > >  		return -ENOMEM;
> > > > >  	/*
> > > > > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > > > > index d036a31a97e84e..bc4c5b9b1bf14c 100644
> > > > > --- a/fs/f2fs/f2fs.h
> > > > > +++ b/fs/f2fs/f2fs.h
> > > > > @@ -2953,18 +2953,12 @@ static inline bool f2fs_may_extent_tree(struct inode *inode)
> > > > >  static inline void *f2fs_kmalloc(struct f2fs_sb_info *sbi,
> > > > >  					size_t size, gfp_t flags)
> > > > >  {
> > > > > -	void *ret;
> > > > > -
> > > > >  	if (time_to_inject(sbi, FAULT_KMALLOC)) {
> > > > >  		f2fs_show_injection_info(sbi, FAULT_KMALLOC);
> > > > >  		return NULL;
> > > > >  	}
> > > > >  
> > > > > -	ret = kmalloc(size, flags);
> > > > > -	if (ret)
> > > > > -		return ret;
> > > > > -
> > > > > -	return kvmalloc(size, flags);
> > > > > +	return kmalloc(size, flags);
> > > > 
> > > > IIRC, sometimes, we suffered from ENOMEM from kmalloc, as some structures
> > > > depended on the disk capacity. I can't remember exactly which structure tho.
> > > > 
> > > 
> > > I think this patch already addresses that, by changing the large allocations to
> > > use f2fs_kvmalloc().
> > 
> > Hmm, I worried a bit whether it covers every cases.
> > 
> 
> I went through every remaining caller of f2fs_kmalloc() and f2fs_kzalloc().  I
> think we're fine, except for possibly the allocation of blkz_seq in
> init_blkz_info().  How many zones can we expect on a zoned block device?

In the worst case, it can be 16TB / 2MB = 8M entries.

> 
> Other than that, the largest fixed-size allocation is 8536 bytes
> (struct discard_cmd_control).  And the variable-size allocations are all a page
> or less, except for xattr buffers which maybe can be larger, but the VFS uses
> kmalloc() for those too.
> 
> Anyway, f2fs used to allocate megabytes with kmalloc(), so I'm not surprised you
> had issues before.  But that's not a good reason to make *every* caller
> potentially get vmalloc()'ed memory, in the process introducing bugs where
> vmalloc() memory isn't handled correctly.

Thank you for checking all the cases. Let me know, if this is the final version.
I may be able to merge and try to see if somebody will complain later. :P

Thanks,

> 
> - Eric


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

  reply	other threads:[~2020-06-05  1:15 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-05 20:48 [f2fs-dev] [PATCH] f2fs: don't return vmalloc() memory from f2fs_kmalloc() Eric Biggers
2020-05-06  7:43 ` Chao Yu
2020-05-06 18:43   ` Eric Biggers
2020-05-07  3:13     ` Chao Yu
2020-05-15 19:13 ` Eric Biggers
2020-05-18 18:06 ` Jaegeuk Kim
2020-05-18 18:35   ` Eric Biggers
2020-05-18 19:10     ` Jaegeuk Kim
2020-06-04 21:06       ` Eric Biggers
2020-06-05  1:15         ` Jaegeuk Kim [this message]
2020-06-05  4:56           ` Eric Biggers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200605011535.GA102178@google.com \
    --to=jaegeuk@kernel.org \
    --cc=ebiggers@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.