[PATCH] nss_files: Fix re-reading of long lines [BZ #18991]

[Florian Weimer]

On 09/01/2017 08:04 PM, Florian Weimer wrote:
> This fixes the line skipping due to an insufficient read buffer size.
> 
> However, if the line length is sufficiently close to the buffer size, so
> that it does not leave enough room for the aliases pointer array, then
> we can get a very late ERANGE error in the line parser.  This will still
> result in a skipped line.  I think this means that bug 18991 is not a
> regression, strictly speaking.
> 
> The test case actually catches this, but only 64-bit architectures, due
> to the way the buffer sizes work out.

I think I found a way to salvage this approach.  If parse_line fails
with ERANGE, we need to seek back to the start of the line.  We can do
this because we know the exact length of the line in bytes at this point.

I added further testing with different name counts, so that both buffer
management errors should be covered on both 32-bit and 64-bit
architectures now.

I was curious how the additional lseek system calls due to the proactive
ftello call in __libc_readline_unlock would affect performance.  It
seems that they do not matter.  I benchmarked getpwnam_r in three
different ways: first user (root), a user roughly 10,000 entries down,
and a non-existing user with an /etc/passwd containing about 20,000
entries.  For root, there was no statistically significant difference.
For the other cases, the new approach is about 2% to 3% faster,
presumably due to the more efficient implementation of
__libc_readline_unlocked.  (There were no ERANGE errors involved in this
test; in case of ERANGE, performance is shot anyway.)

Thanks,
Florian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: files.patch
Type: text/x-patch
Size: 14092 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20170902/8bac7bee/attachment.bin>