On Mon, 2014-09-15 at 10:21 +0100, Daniel P. Berrange wrote:
> On Sun, Sep 14, 2014 at 06:35:19PM +0100, Ian Campbell wrote:
> > On Wed, 2014-09-10 at 12:20 +0200, Michal Privoznik wrote:
> > >
> > > +/*
> > > + * Workaround older glibc. While kernel may support the setns
> > > + * syscall, the g
On Sun, Sep 14, 2014 at 06:35:19PM +0100, Ian Campbell wrote:
> On Wed, 2014-09-10 at 12:20 +0200, Michal Privoznik wrote:
> >
> > +/*
> > + * Workaround older glibc. While kernel may support the setns
> > + * syscall, the glibc wrapper might not exist. If that's the
> > + * case, use our own.
>
On Wed, 2014-09-10 at 12:20 +0200, Michal Privoznik wrote:
>
> +/*
> + * Workaround older glibc. While kernel may support the setns
> + * syscall, the glibc wrapper might not exist. If that's the
> + * case, use our own.
> + */
> +#ifndef __NR_setns
> +# if defined(__x86_64__)
> +# define __NR_s
>From time to time weird bugreports occur on the list, e.g [1].
Even though the kernel supports setns syscall, there's an older
glibc in the system that misses a wrapper over the syscall.
Hence, after the configure phase we think there's no setns
support in the system, which is obviously wrong. On
