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
prev parent 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).