[libvirt] [PATCH 2/3] virtestmock: Mock stat() properly

Peter Krempa pkrempa at redhat.com
Fri May 20 12:29:28 UTC 2016


On Wed, May 18, 2016 at 15:39:11 +0200, Michal Privoznik wrote:
> There is a lot to explain, but I try to make it as short as
> possible. I'd start by pasting some parts of sys/stat.h:
> 
> extern int stat (const char *__restrict __file,
> 		 struct stat *__restrict __buf) __THROW __nonnull ((1, 2));
> 
> extern int __REDIRECT_NTH (stat, (const char *__restrict __file,
> 				  struct stat *__restrict __buf), stat64)
>      __nonnull ((1, 2));
> 
> #  define stat stat64
> 
> __extern_inline int
> __NTH (stat (const char *__path, struct stat *__statbuf))
> {
>   return __xstat (_STAT_VER, __path, __statbuf);
> }
> 
> Only one of these is effective at once, due to some usage of
> #ifdefs. Nevertheless, it allows you to create a picture about
> the mess we are dealing with in here. So, basically, while
> compiling or linking stat() in our code can be transformed into
> some other func. Or a dragon.
> Now, if you read stat(2) manpage, esp. "C library/kernel
> differences" section, you'll learn that glibc uses some tricks
> for older applications to work. I haven't gotten around actual
> code that does this, but based on my observations, if 'stat'
> symbol is found, glibc assumes it's dealing with ancient
> application. Unfortunately, it can be just ours stat coming from
> our mock. Therefore, calling stat() from a test will end up in
> our mock. But since glibc is not exposing the symbol anymore, our
> call of real_stat() will SIGSEGV immediately as the pointer to
> function is NULL. Therefore, we should expose only those symbols
> we know glibc has.
> 
> Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
> ---
>  cfg.mk              |  3 ++
>  configure.ac        |  1 +
>  tests/virtestmock.c | 97 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 101 insertions(+)
> 
> diff --git a/cfg.mk b/cfg.mk
> index c0aba57..c19f615 100644
> --- a/cfg.mk
> +++ b/cfg.mk
> @@ -1296,3 +1296,6 @@ exclude_file_name_regexp--sc_prohibit_not_strneq = \
>  
>  exclude_file_name_regexp--sc_prohibit_dt_without_code = \
>    ^docs/(newapi\.xsl|(apps|contact)\.html\.in)$$
> +
> +exclude_file_name_regexp--sc_prohibit_always-defined_macros = \
> +  ^tests/virtestmock.c$$
> diff --git a/configure.ac b/configure.ac
> index 378069d..7eb9847 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -332,6 +332,7 @@ AC_CHECK_HEADERS([pwd.h regex.h sys/un.h \
>    libtasn1.h sys/ucred.h sys/mount.h])
>  dnl Check whether endian provides handy macros.
>  AC_CHECK_DECLS([htole64], [], [], [[#include <endian.h>]])
> +AC_CHECK_FUNCS([stat stat64 __xstat __xstat64 lstat lstat64 __lxstat __lxstat64])
>  
>  dnl We need to decide at configure time if libvirt will use real atomic
>  dnl operations ("lock free") or emulated ones with a mutex.
> diff --git a/tests/virtestmock.c b/tests/virtestmock.c
> index 54669ba..8c3c0b8 100644
> --- a/tests/virtestmock.c
> +++ b/tests/virtestmock.c
> @@ -34,13 +34,33 @@
>  #include "viralloc.h"
>  #include "virfile.h"
>  
> +/* stat can be a macro as follows:
> + *
> + *   #define stat stat64
> + *
> + * This wouldn't fly with our mock. Make sure that the macro (and
> + * all its friends) are undefined. We don't want anybody mangling
> + * our code. */
> +#undef stat
> +#undef stat64
> +#undef __xstat
> +#undef __xstat64
> +#undef lstat
> +#undef lstat64
> +#undef __lxstat
> +#undef __lxstat64
> +
>  static int (*real_open)(const char *path, int flags, ...);
>  static FILE *(*real_fopen)(const char *path, const char *mode);
>  static int (*real_access)(const char *path, int mode);
>  static int (*real_stat)(const char *path, struct stat *sb);
> +static int (*real_stat64)(const char *path, struct stat64 *sb);

If you don't have the function you probably don't have the data type so
this might not work properly still. Since you don't care what's in the
data you might try to use void pointers.

>  static int (*real___xstat)(int ver, const char *path, struct stat *sb);
> +static int (*real___xstat64)(int ver, const char *path, struct stat64 *sb);
>  static int (*real_lstat)(const char *path, struct stat *sb);
> +static int (*real_lstat64)(const char *path, struct stat64 *sb);
>  static int (*real___lxstat)(int ver, const char *path, struct stat *sb);
> +static int (*real___lxstat64)(int ver, const char *path, struct stat64 *sb);
>  
>  static const char *progname;
>  const char *output;
> @@ -56,7 +76,9 @@ static void init_syms(void)
>      VIR_MOCK_REAL_INIT(fopen);
>      VIR_MOCK_REAL_INIT(access);
>      VIR_MOCK_REAL_INIT_ALT(stat, __xstat);
> +    VIR_MOCK_REAL_INIT_ALT(stat64, __xstat64);
>      VIR_MOCK_REAL_INIT_ALT(lstat, __lxstat);
> +    VIR_MOCK_REAL_INIT_ALT(lstat64, __lxstat64);
>  }
>  
>  static void
> @@ -187,6 +209,27 @@ int access(const char *path, int mode)
>      return real_access(path, mode);
>  }
>  
> +/* Okay, the following ifdef rain forest may look messy at a
> + * first glance. But here's the thing: during run time linking of
> + * a binary, stat() may not be acutally needing symbol stat. It
> + * might as well not had been stat() in the first place (see the
> + * reasoning at the beginning of this file). However, if we would
> + * expose stat symbol here, we will poison the well and trick
> + * dynamic linker into thinking we are some old binary that still
> + * uses the symbol. So whenever code from upper layers calls
> + * stat(), the control would get here, but real_stat can actually
> + * be a NULL pointer because newer glibc have __xstat instead.
> + * Worse, it can have __xstat64 instead __xstat.
> + *
> + * Anyway, these ifdefs are there to implement the following
> + * preference function:
> + *
> + * stat < stat64 < __xstat < __xstat64

HAVE_XSTAT implies HAVE_STAT
HAVE_XSTAT64 implies HAVE_STAT64

and if you have the 64 version it usually replaces the normal version
via a macro or via __REDIRECT_NTH directive.

Part of the preference function you described is thus invalid:

stat64 < __xstat

> + *
> + * It's the same story with lstat.
> + * Also, I feel sorry for you that you had to read this.
> + */
> +#if defined(HAVE_STAT) && !defined(HAVE___XSTAT)
>  int stat(const char *path, struct stat *sb)
>  {
>      init_syms();
> @@ -195,7 +238,20 @@ int stat(const char *path, struct stat *sb)
>  
>      return real_stat(path, sb);
>  }
> +#endif
>  
> +#if defined(HAVE_STAT64) && !defined(HAVE___XSTAT64)
> +int stat64(const char *path, struct stat64 *sb)
> +{
> +    init_syms();
> +
> +    checkPath(path);
> +
> +    return real_stat64(path, sb);
> +}
> +#endif
> +
> +#if defined(HAVE___XSTAT) && !defined(HAVE___XSTAT64)
>  int
>  __xstat(int ver, const char *path, struct stat *sb)
>  {
> @@ -205,7 +261,21 @@ __xstat(int ver, const char *path, struct stat *sb)
>  
>      return real___xstat(ver, path, sb);
>  }
> +#endif
>  
> +#if defined(HAVE___XSTAT64)
> +int
> +__xstat64(int ver, const char *path, struct stat64 *sb)
> +{
> +    init_syms();
> +
> +    checkPath(path);
> +
> +    return real___xstat64(ver, path, sb);
> +}
> +#endif

Anyways. This stuff made my brain hurt. I think we need to find out
whether void pointers are okay for the possibly missing struct stat64.

Otherwise if it fixes the stuff I'm okay with pushing this then.

Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20160520/a2fe08ce/attachment-0001.sig>


More information about the libvir-list mailing list