linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Fields Bruce James <bfields@fieldses.org>
To: Trond Myklebust <trondmy@primarydata.com>
Cc: List Linux NFS Mailing <linux-nfs@vger.kernel.org>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Christoph Hellwig <hch@infradead.org>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>
Subject: Re: [PATCH] sunrpc: don't pass on-stack memory to sg_set_buf
Date: Tue, 25 Oct 2016 15:59:30 -0400	[thread overview]
Message-ID: <20161025195930.GB5129@fieldses.org> (raw)
In-Reply-To: <A4086E5B-B808-4828-A25D-4AAB2504EC57@primarydata.com>

On Tue, Oct 25, 2016 at 07:34:43PM +0000, Trond Myklebust wrote:
> 
> > On Oct 25, 2016, at 14:45, J. Bruce Fields <bfields@fieldses.org> wrote:
> > 
> > From: "J. Bruce Fields" <bfields@redhat.com>
> > 
> > As of ac4e97abce9b "scatterlist: sg_set_buf() argument must be in linear
> > mapping", sg_set_buf hits a BUG when make_checksum_v2->xdr_process_buf,
> > among other callers, passes it memory on the stack.
> > 
> > We only need a scatterlist to pass this to the crypto code, and it seems
> > like overkill to require kmalloc'd memory just to encrypt a few bytes,
> > but for now this seems the best fix.
> > 
> > Note many of these callers are in the NFS write paths, so we shouldn't
> > really be allocating GFP_KERNEL.  But we already have other allocations
> > in these code paths.  A larger redesign may be necessary to allow
> > allocations to be done earlier.
> 
> NACK…  I agree that there may already be borkage in RPCSEC_GSS-land, but that’s not a reason to be adding to the pile of things that need to be fixed… The allocations that lie in the RPC client’s encode/decode path do need to be GFP_NOFS….

OK.  Any disadvantage to keeping this patch with just GFP_NOFS
allocations everywhere that might be in the write path?

--b.

  reply	other threads:[~2016-10-25 19:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-25 18:45 [PATCH] sunrpc: don't pass on-stack memory to sg_set_buf J. Bruce Fields
2016-10-25 19:34 ` Trond Myklebust
2016-10-25 19:59   ` Fields Bruce James [this message]
2016-10-25 21:47     ` Trond Myklebust
2016-10-28 13:20       ` Fields Bruce James
2016-10-28 13:22         ` Fields Bruce James

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=20161025195930.GB5129@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=hch@infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    --cc=trondmy@primarydata.com \
    /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).