All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Joe Perches <joe@perches.com>, "Yan, Zheng" <ukernel@gmail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	ceph-devel <ceph-devel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Ilya Dryomov <idryomov@gmail.com>, Zheng Yan <zyan@redhat.com>,
	Sage Weil <sage@redhat.com>,
	agruenba@redhat.com
Subject: Re: [PATCH 1/3] lib/vsprintf: add snprintf_noterm
Date: Sat, 15 Jun 2019 07:08:41 -0400	[thread overview]
Message-ID: <ef030ba8553a8bc81fde998df4bd927bfba17537.camel@kernel.org> (raw)
In-Reply-To: <75c8f066c3aa2e20db2e1554a4d28c20b2952724.camel@perches.com>

On Fri, 2019-06-14 at 19:58 -0700, Joe Perches wrote:
> On Sat, 2019-06-15 at 10:41 +0800, Yan, Zheng wrote:
> > On Fri, Jun 14, 2019 at 9:48 PM Jeff Layton <jlayton@kernel.org> wrote:
> > > The getxattr interface returns a length after filling out the value
> > > buffer, and the convention with xattrs is to not NULL terminate string
> > > data.
> > > 
> > > CephFS implements some virtual xattrs by using snprintf to fill the
> > > buffer, but that always NULL terminates the string. If userland sends
> > > down a buffer that is just the right length to hold the text without
> > > termination then we end up truncating the value.
> > > 
> > > Factor the formatting piece of vsnprintf into a separate helper
> > > function, and have vsnprintf call that and then do the NULL termination
> > > afterward. Then add a snprintf_noterm function that calls the new helper
> > > to populate the string but skips the termination.
> 
> Is this function really necessary enough to add
> the additional stack use to the generic case?
> 

The only alternative I saw was to allocate an extra buffer in the
callers, call snprintf to populate that and then copy the result into
the destination buffer sans termination. I really would like to avoid
that here.

Does breaking this code out into a helper add any significant stack
usage? I didn't see it that way, but I am quite concerned about not
slowing down the generic vsnprintf routine.

> Why not add have this function call vsnprintf
> and then terminate the string separately?
> 

I don't quite follow what you're suggesting here. vsnprintf is what does
the termination today, and we need a function that doesn't do that.

-- 
Jeff Layton <jlayton@kernel.org>


  reply	other threads:[~2019-06-15 11:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-14 13:46 [PATCH 0/3] ceph: don't NULL terminate virtual xattr values Jeff Layton
2019-06-14 13:46 ` [PATCH 1/3] lib/vsprintf: add snprintf_noterm Jeff Layton
2019-06-15  2:41   ` Yan, Zheng
2019-06-15  2:58     ` Joe Perches
2019-06-15 11:08       ` Jeff Layton [this message]
2019-06-15 10:58     ` Jeff Layton
2019-06-14 13:46 ` [PATCH 2/3] ceph: don't NULL terminate virtual xattr strings Jeff Layton
2019-06-14 13:46 ` [PATCH 3/3] ceph: return -ERANGE if virtual xattr value didn't fit in buffer Jeff Layton
2019-06-14 16:56 ` [PATCH 0/3] ceph: don't NULL terminate virtual xattr values Andreas Gruenbacher

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=ef030ba8553a8bc81fde998df4bd927bfba17537.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=agruenba@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=ceph-devel@vger.kernel.org \
    --cc=idryomov@gmail.com \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sage@redhat.com \
    --cc=ukernel@gmail.com \
    --cc=zyan@redhat.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 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.