On 05/09/2017 04:23 AM, Greg Kurz wrote:
> On Fri, 5 May 2017 12:01:55 -0500
> Eric Blake <ebl...@redhat.com> wrote:
>
>> On 05/05/2017 09:37 AM, Greg Kurz wrote:
>>> All paths in the virtfs directory now start with "./" (except the virtfs
>>> root itself which is exactly ".").
>>>
>>> We hence don't need to skip leading '/' characters anymore, nor to handle
>>> the empty path case. Also, since virtfs will only ever be supported on
>>> linux+glibc hosts, we can use strchrnul() and come up with a much simplier
>>> code to walk through the path elements. And we don't need to dup() the
>>> passed directory fd.
>>>
>>> Signed-off-by: Greg Kurz <gr...@kaod.org>
>>> ---
>>> hw/9pfs/9p-local.c | 5 -----
>>> hw/9pfs/9p-util.c | 26 ++++++++++----------------
>>> 2 files changed, 10 insertions(+), 21 deletions(-)
>>>
>>> diff --git a/hw/9pfs/9p-local.c b/hw/9pfs/9p-local.c
>>> index 92262f3c3e37..bb6e296df317 100644
>>> --- a/hw/9pfs/9p-local.c
>>> +++ b/hw/9pfs/9p-local.c
>>> @@ -54,11 +54,6 @@ int local_open_nofollow(FsContext *fs_ctx, const char
>>> *path, int flags,
>>> {
>>> LocalData *data = fs_ctx->private;
>>>
>>> - /* All paths are relative to the path data->mountfd points to */
>>> - while (*path == '/') {
>>> - path++;
>>> - }
>>
>> Is it worth adding any assert()s in place of the deleted code?
>>
>
> The assert() added by this patch ensures that we never pass an empty
> string to relative_openat_nofollow(), which isn't related to this
> hunk of deleted code... so I'm not sure I understand the question :-\I was thinking if it is worth replacing the deleted while() loop with an assert(*path != '/'); to prove that we have already taken care of ensuring a relative path. You're right that you added another assert(*path) elsewhere in the patch, and that one looked fine. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
