From: Paul Eggert <eggert@cs.ucla.edu>
To: Adhemerval Zanella <adhemerval.zanella@linaro.org>,
libc-alpha@sourceware.org
Cc: Xiaoming Ni <nixiaoming@huawei.com>
Subject: Re: [PATCH 3/3] linux: Optimize realpath stack usage
Date: Mon, 10 Aug 2020 14:25:53 -0700 [thread overview]
Message-ID: <1508cae6-9f47-1885-2fb0-e257f906b82a@cs.ucla.edu> (raw)
In-Reply-To: <20200810204856.2111211-3-adhemerval.zanella@linaro.org>
On 8/10/20 1:48 PM, Adhemerval Zanella wrote:
> Regarding syscalls usage, for a sucessful path without symlinks it
> trades 2 syscalls (getcwd/lstat) for 5 (openat, readlink, fstat, stat,
> and close).
Thanks for looking into this.
There's no need for the new __resolve_path function to call __lstat64. It does
that only to determine whether the file is a symlink or a directory, and it can
do the former with __readlink (which it's gonna do already) and the latter by
going into the next iteration and seeing whether it gets NOTDIR. Avoiding
__lstat64 means we don't have to worry about irrelevant EOVERFLOW hassles.
In the Linux __realpath_system, the code should be prepared for the /proc
syscall to fail because /proc is not mounted. It can fall back on __resolve_path
in that case. The code should be prepared for the fstat64 to fail due to
EOVERFLOW. And I'm not quite getting why the code is comparing fstat64's result
to stat64's result -- perhaps explain this in a comment and how EOVERFLOW is
dealt with?
next prev parent reply other threads:[~2020-08-10 21:25 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-10 20:48 [PATCH 1/3] stdlib: Use fixed buffer size for realpath (BZ #26241) Adhemerval Zanella
2020-08-10 20:48 ` [PATCH 2/3] stdlib: Enforce PATH_MAX on allocated realpath buffer Adhemerval Zanella
2020-08-11 8:26 ` Florian Weimer
2020-08-11 9:54 ` Andreas Schwab
2020-08-11 10:24 ` Florian Weimer
2020-08-11 15:05 ` Adhemerval Zanella
2020-08-11 15:37 ` Paul Eggert
2020-08-11 18:29 ` Florian Weimer
2020-08-11 9:48 ` Andreas Schwab
2020-08-10 20:48 ` [PATCH 3/3] linux: Optimize realpath stack usage Adhemerval Zanella
2020-08-10 21:25 ` Paul Eggert [this message]
2020-08-11 14:14 ` Adhemerval Zanella
2020-08-11 15:18 ` Adhemerval Zanella
2020-08-11 15:52 ` Paul Eggert
2020-08-11 19:01 ` Adhemerval Zanella
2020-08-11 16:46 ` Andreas Schwab
2020-08-17 14:00 ` Dmitry V. Levin
2020-08-17 15:13 ` Andreas Schwab
2020-08-17 16:17 ` Dmitry V. Levin
2020-08-11 9:46 ` Andreas Schwab
2020-08-11 0:32 ` [PATCH 1/3] stdlib: Use fixed buffer size for realpath (BZ #26241) Matt Turner
2020-08-11 3:00 ` Xiaoming Ni
2020-08-11 14:57 ` Adhemerval Zanella
2020-08-12 1:38 ` Xiaoming Ni
2020-08-12 23:04 ` Adhemerval Zanella
2020-08-13 20:29 ` Adhemerval Zanella
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=1508cae6-9f47-1885-2fb0-e257f906b82a@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=adhemerval.zanella@linaro.org \
--cc=libc-alpha@sourceware.org \
--cc=nixiaoming@huawei.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 read-only IMAP folder(s) and NNTP newsgroup(s).