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