linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Sean Fu <fxinrong@gmail.com>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>,
	linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] xfs: Use kmem_zalloc for bp->b_pages.
Date: Mon, 11 Mar 2019 08:53:55 +1100	[thread overview]
Message-ID: <20190310215355.GC23020@dastard> (raw)
In-Reply-To: <20190310050608.dtidrfuqepze6uoh@linux-xjtn>

On Sun, Mar 10, 2019 at 01:07:32PM +0800, Sean Fu wrote:
> On Sat, Mar 09, 2019 at 09:32:30AM -0800, Darrick J. Wong wrote:
> > On Sat, Mar 09, 2019 at 11:36:36PM +0800, Sean Fu wrote:
> > > Change the allocation of bp->b_pages to use kmem_zalloc instead of
> > > kmem_alloc.
> > > Remove unnecessary memset for bp->b_pages.
> > >
> > > This reduces text size by 42 bytes.
> > > Before:
> > >    text	   data	    bss	    dec	    hex	filename
> > >   23335	    588	      8	  23931	   5d7b	./fs/xfs/xfs_buf.o
> > > After:
> > >    text	   data	    bss	    dec	    hex	filename
> > >   23293	    588	      8	  23889	   5d51	./fs/xfs/xfs_buf.o
> > >
> > > Signed-off-by: Sean Fu <fxinrong@gmail.com>
> > > ---
> > >  fs/xfs/xfs_buf.c | 3 +--
> > >  1 file changed, 1 insertion(+), 2 deletions(-)
> > >
> > > diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c
> > > index 4f5f2ff3f70f..be4f740b97c1 100644
> > > --- a/fs/xfs/xfs_buf.c
> > > +++ b/fs/xfs/xfs_buf.c
> > > @@ -289,12 +289,11 @@ _xfs_buf_get_pages(
> > >  		if (page_count <= XB_PAGES) {
> > >  			bp->b_pages = bp->b_page_array;
> > >  		} else {
> > > -			bp->b_pages = kmem_alloc(sizeof(struct page *) *
> > > +			bp->b_pages = kmem_zalloc(sizeof(struct page *) *
> > >  						 page_count, KM_NOFS);
> > >  			if (bp->b_pages == NULL)
> > >  				return -ENOMEM;
> > >  		}
> > > -		memset(bp->b_pages, 0, sizeof(struct page *) * page_count);
> >
> > Does this leave b_pages uninitialized in the page_count <= XB_PAGES
> > case?
> bp is allocated by kmem_zone_zalloc, But i will take a deep look at xfs_buf_associate_memory.

We can (and do) reuse buffers with different memory buffers via
xfs_buf_associate_memory() (e.g. see the split log buffer code in
xlog_sync()].

I'd prefer that we leave the explicit memset here for this re-use
case - leaving the page pointer array with stale page pointers (even
though beyond b_page_count) means any page array overrun turns into
a memory corruption (via access of a stale page) rather than a NULL
pointer dereference and immediate fail.

IMO, a small decrease in binary size is not worth changing the
failure behaviour from a definite, immediate fail to a random memory
corruption failure some time in the future...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

      reply	other threads:[~2019-03-10 21:54 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-09 15:36 [PATCH] xfs: Use kmem_zalloc for bp->b_pages Sean Fu
2019-03-09 17:32 ` Darrick J. Wong
2019-03-10  5:07   ` Sean Fu
2019-03-10 21:53     ` Dave Chinner [this message]

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=20190310215355.GC23020@dastard \
    --to=david@fromorbit.com \
    --cc=darrick.wong@oracle.com \
    --cc=fxinrong@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).