Re: [PATCH] ecryptfs: streamline offset formatting in ecryptfs_derive_iv

[Thorsten Blum <thorsten.blum@linux.dev>]

On Sun, Mar 29, 2026 at 03:05:05PM -0700, Eric Biggers wrote:
> On Sun, Mar 29, 2026 at 11:23:25PM +0200, Thorsten Blum wrote:
> > Use the number of characters written by scnprintf() to zero-pad the
> > remaining bytes, instead of clearing the buffer first and then writing
> > the offset.
> [...]
> > +	size_t len;
> [...]
> >  	memcpy(src, crypt_stat->root_iv, crypt_stat->iv_bytes);
> > -	memset((src + crypt_stat->iv_bytes), 0, 16);
> > -	snprintf((src + crypt_stat->iv_bytes), 16, "%lld", offset);
> > +	len = scnprintf(src + crypt_stat->iv_bytes, 16, "%lld", offset) + 1;
> > +	memset(src + crypt_stat->iv_bytes + len, 0, 16 - len);
> 
> This isn't exactly "streamlining" the code.  memset(p, 0, 16) tends to
> get compiled into just two instructions.  In contrast, a variable-length
> memset tends to be several instructions to set up, plus a call
> instruction, and the instructions inside memset() itself.  scnprintf()
> is also a few more instructions than snprintf().
> 
> So I'd say the old version is more "streamlined", actually.  Granted,
> the difference is probably only a few cycles, but it sounds like the
> motivation for this patch is that you assumed the new version is faster?

I meant "streamline" as in write bytes once.

Maybe we should just zero-initialize the 32 bytes in 'src' instead and
keep snprintf(). That removes the need to keep track of 'len' and also
gets rid of the explicit memset(0).