From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: "Bill O'Donnell" <billodo@redhat.com>, linux-xfs@vger.kernel.org
Subject: Re: [PATCH] xfs: assure zeroed memory buffers for certain kmem allocations
Date: Mon, 16 Sep 2019 14:30:59 -0700 [thread overview]
Message-ID: <20190916213059.GO2229799@magnolia> (raw)
In-Reply-To: <5f1bcfbd-f16b-6d8a-416d-3a0639b9c7fe@sandeen.net>
On Mon, Sep 16, 2019 at 04:24:40PM -0500, Eric Sandeen wrote:
> On 9/16/19 10:35 AM, Bill O'Donnell wrote:
> > Guarantee zeroed memory buffers for cases where potential memory
> > leak to disk can occur. In these cases, kmem_alloc is used and
> > doesn't zero the buffer, opening the possibility of information
> > leakage to disk.
> >
> > Introduce a xfs_buf_flag, _XBF_KMZ, to indicate a request for a zeroed
> > buffer, and use existing infrastucture (xfs_buf_allocate_memory) to
> > obtain the already zeroed buffer from kernel memory.
> >
> > This solution avoids the performance issue that would occur if a
> > wholesale change to replace kmem_alloc with kmem_zalloc was done.
> >
> > Signed-off-by: Bill O'Donnell <billodo@redhat.com>
>
> I think this can probably be further optimized by not obtaining zeroed
> memory when we're about to fill the buffer from disk as the very
> next step.
>
> (in this case, xfs_buf_read_map calls xfs_buf_get_map and then immediately
> reads the buffer from disk with _xfs_buf_read) xfs_buf_read_map adds
> XBF_READ to the flags during this process.
>
> So I wonder if this can be simplified/optimized by just checking for XBF_READ
> in xfs_buf_allocate_memory's flags, and if it's not set, then request
> zeroed memory, because that indicates a buffer we'll be filling in from
> memory and subsequently writing to disk.
I was wondering that ("Why can't we allocate a zeroed buffer only for
the get_buf case so that we don't have to do that for the read_buf
case?") too. Once you do that then you can then remove all the explicit
memset calls too.
> -Eric
>
> > ---
> > fs/xfs/xfs_buf.c | 8 ++++++--
> > fs/xfs/xfs_buf.h | 4 +++-
> > 2 files changed, 9 insertions(+), 3 deletions(-)
> >
> > diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c
> > index 120ef99d09e8..916a3f782950 100644
> > --- a/fs/xfs/xfs_buf.c
> > +++ b/fs/xfs/xfs_buf.c
> > @@ -345,16 +345,19 @@ xfs_buf_allocate_memory(
> > unsigned short page_count, i;
> > xfs_off_t start, end;
> > int error;
> > + uint kmflag_mask = 0;
> >
> > /*
> > * for buffers that are contained within a single page, just allocate
> > * the memory from the heap - there's no need for the complexity of
> > * page arrays to keep allocation down to order 0.
> > */
> > + if (flags & _XBF_KMZ)
> > + kmflag_mask |= KM_ZERO;
> > size = BBTOB(bp->b_length);
> > if (size < PAGE_SIZE) {
> > int align_mask = xfs_buftarg_dma_alignment(bp->b_target);
> > - bp->b_addr = kmem_alloc_io(size, align_mask, KM_NOFS);
> > + bp->b_addr = kmem_alloc_io(size, align_mask, KM_NOFS | kmflag_mask);
Does this overflow 80 columns?
--D
> > if (!bp->b_addr) {
> > /* low memory - use alloc_page loop instead */
> > goto use_alloc_page;
> > @@ -391,7 +394,7 @@ xfs_buf_allocate_memory(
> > struct page *page;
> > uint retries = 0;
> > retry:
> > - page = alloc_page(gfp_mask);
> > + page = alloc_page(gfp_mask | kmflag_mask);
> > if (unlikely(page == NULL)) {
> > if (flags & XBF_READ_AHEAD) {
> > bp->b_page_count = i;
> > @@ -683,6 +686,7 @@ xfs_buf_get_map(
> > struct xfs_buf *new_bp;
> > int error = 0;
> >
> > + flags |= _XBF_KMZ;
> > error = xfs_buf_find(target, map, nmaps, flags, NULL, &bp);
> >
> > switch (error) {
> > diff --git a/fs/xfs/xfs_buf.h b/fs/xfs/xfs_buf.h
> > index f6ce17d8d848..416ff588240a 100644
> > --- a/fs/xfs/xfs_buf.h
> > +++ b/fs/xfs/xfs_buf.h
> > @@ -38,6 +38,7 @@
> > #define _XBF_PAGES (1 << 20)/* backed by refcounted pages */
> > #define _XBF_KMEM (1 << 21)/* backed by heap memory */
> > #define _XBF_DELWRI_Q (1 << 22)/* buffer on a delwri queue */
> > +#define _XBF_KMZ (1 << 23)/* zeroed buffer required */
> >
> > typedef unsigned int xfs_buf_flags_t;
> >
> > @@ -54,7 +55,8 @@ typedef unsigned int xfs_buf_flags_t;
> > { XBF_UNMAPPED, "UNMAPPED" }, /* ditto */\
> > { _XBF_PAGES, "PAGES" }, \
> > { _XBF_KMEM, "KMEM" }, \
> > - { _XBF_DELWRI_Q, "DELWRI_Q" }
> > + { _XBF_DELWRI_Q, "DELWRI_Q" }, \
> > + { _XBF_KMZ, "KMEM_Z" }
> >
> >
> > /*
> >
next prev parent reply other threads:[~2019-09-16 21:31 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-16 15:35 [PATCH] xfs: assure zeroed memory buffers for certain kmem allocations Bill O'Donnell
2019-09-16 21:24 ` Eric Sandeen
2019-09-16 21:30 ` Darrick J. Wong [this message]
2019-09-16 21:32 ` Bill O'Donnell
2019-09-16 21:54 ` Dave Chinner
2019-09-18 15:47 ` [PATCH v2] " Bill O'Donnell
2019-09-18 16:32 ` Darrick J. Wong
2019-09-18 22:11 ` Bill O'Donnell
2019-09-19 15:01 ` [PATCH v3] " Bill O'Donnell
2019-09-19 17:03 ` Christoph Hellwig
2019-09-19 17:20 ` Bill O'Donnell
2019-09-19 17:38 ` Christoph Hellwig
2019-09-20 14:59 ` Eric Sandeen
2019-09-24 4:13 ` Dave Chinner
2019-09-19 21:01 ` [PATCH v4] " Bill O'Donnell
2019-09-24 5:47 ` Darrick J. Wong
2019-09-24 15:17 ` Darrick J. Wong
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=20190916213059.GO2229799@magnolia \
--to=darrick.wong@oracle.com \
--cc=billodo@redhat.com \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@sandeen.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox