Re: [PATCH v3 2/2] tests: Workaroud for buggy glibc in ipc_msg test on ppc64

[Dmitry V. Levin]

On Tue, Sep 13, 2016 at 02:56:44AM +0300, Eugene Syromyatnikov wrote:
> glibc before 2.23 (glibc-2.22-122-gbe48165? to be more precise) tried to 
> access
> data pointed by third argument of msgctl call on 64-bit PowerPC which led to
> segmentataion fault (instead of EFAULT from kernel).
[...]
> +/*
> + * Before glibc-2.22-122-gbe48165, ppc64 code tried to retrieve data 
> provided in
> + * third argument of msgctl call (in case of IPC_SET cmd) which led to
> + * segmentation fault.
> + */
> +#if !(defined BROKEN_GLIBC)
> +# if defined __GLIBC__ && defined POWERPC && defined POWERPC64
> +#  if !(defined __GLIBC_MINOR__) || \
> +((__GLIBC__ << 16) + __GLIBC_MINOR__ < (2 << 16) + 23)
> +#   define BROKEN_GLIBC 1
> +#  endif
> +# endif /* __GLIBC__ && _powerpc__ && __ppc64__ */
> +#endif /* !BROKEN_GLIBC */
> +
> +#ifndef BROKEN_GLIBC
> +# define BROKEN_GLIBC 0
> +#endif
> +
>  static int id = -1;
>  
>  static void
> @@ -58,7 +76,9 @@ main(void)
>   static const key_t bogus_key = (key_t) 0xeca86420fdb97531ULL;
>   static const int bogus_msgid = 0xfdb97531;
>   static const int bogus_cmd = 0xdeadbeef;
> +#if !BROKEN_GLIBC
>   static void * const bogus_addr = (void *) -1L;
> +#endif
>   static const int bogus_flags = 0xface1e55 & ~IPC_CREAT;
>  
>   assert(msgget(bogus_key, bogus_flags) == -1);
> @@ -81,9 +101,11 @@ main(void)
>   printf("msgctl\\(%d, (IPC_64\\|)?%#x /\\* MSG_\\?\\?\\? \\*/, NULL\\) "
>   "+= %s\n", bogus_msgid, bogus_cmd, sprintrc_grep(-1));
>  
> +#if !BROKEN_GLIBC
>   assert(msgctl(bogus_msgid, IPC_SET, bogus_addr) == -1);
>   printf("msgctl\\(%d, (IPC_64\\|)?IPC_SET, %p\\) += %s\n",
>   bogus_msgid, bogus_addr, sprintrc_grep(-1));
> +#endif
>  
>   if (msgctl(id, IPC_STAT, ))
>   perror_msg_and_skip("msgctl IPC_STAT");

It isn't correct to blame glibc for being buggy if it dereferences
the bogus pointer passed to msgctl.
Could you rename BROKEN_GLIBC to e.g. SKIP_TEST_BOGUS_ADDR, please?

On Tue, Sep 13, 2016 at 09:32:11AM +0200, Andreas Schwab wrote:
> On Sep 13 2016, Eugene Syromyatnikov wrote:
> 
> > glibc before 2.23 (glibc-2.22-122-gbe48165? to be more precise) tried to 
> > access
> > data pointed by third argument of msgctl call on 64-bit PowerPC which led to
> > segmentataion fault (instead of EFAULT from kernel).
> 
> Which is a perfectly valid thing to do, as passing an invalid pointer to
> msgctl (the libc function) invokes undefined behaviour.  If you want to
> test the kernel behaviour you need to talk to the kernel directly.

To be honest, I don't quite like the idea of reimplementing complex
arch-specific syscall wrappers just for the sake of strace tests.
Well, not yet.


-- 
ldv


pgpwISMa0QGsp.pgp
Description: PGP signature
--
___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: [PATCH v3 2/2] tests: Workaroud for buggy glibc in ipc_msg test on ppc64

[Andreas Schwab]

On Sep 13 2016, Eugene Syromyatnikov 
 wrote:

> On Tue, Sep 13, 2016 at 7:32 AM, Andreas Schwab 
>  wrote:
>> On Sep 13 2016, Eugene Syromyatnikov 
>>  
>> wrote:
>>
>>> glibc before 2.23 (glibc-2.22-122-gbe48165? to be more precise) tried to 
>>> access
>>> data pointed by third argument of msgctl call on 64-bit PowerPC which led to
>>> segmentataion fault (instead of EFAULT from kernel).
>>
>> Which is a perfectly valid thing to do, as passing an invalid pointer to
>> msgctl (the libc function) invokes undefined behaviour.  If you want to
>> test the kernel behaviour you need to talk to the kernel directly.
> Well, http://man7.org/linux/man-pages/man2/msgctl.2.html documents
> this case as EFAULT (and I assume it documents glibc wrapper since it
> usually does so and kernel interface is architecture-dependent).

Section 2 manpages document the kernel syscalls.  You can never count on
EFAULT unless talking to the kernel directly.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

--
___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: [PATCH v3 2/2] tests: Workaroud for buggy glibc in ipc_msg test on ppc64

[Eugene Syromyatnikov]

On Tue, Sep 13, 2016 at 7:32 AM, Andreas Schwab  wrote:
> On Sep 13 2016, Eugene Syromyatnikov 
>  wrote:
>
>> glibc before 2.23 (glibc-2.22-122-gbe48165? to be more precise) tried to 
>> access
>> data pointed by third argument of msgctl call on 64-bit PowerPC which led to
>> segmentataion fault (instead of EFAULT from kernel).
>
> Which is a perfectly valid thing to do, as passing an invalid pointer to
> msgctl (the libc function) invokes undefined behaviour.  If you want to
> test the kernel behaviour you need to talk to the kernel directly.
Well, http://man7.org/linux/man-pages/man2/msgctl.2.html documents
this case as EFAULT (and I assume it documents glibc wrapper since it
usually does so and kernel interface is architecture-dependent).

> Andreas.
>
> --
> Andreas Schwab, SUSE Labs, sch...@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."
>
> --
> ___
> Strace-devel mailing list
> Strace-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/strace-devel



-- 
Eugene "eSyr" Syromyatnikov
mailto:evg...@gmail.com
xmpp:eSyr@jabber.{ru|org}

--
___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: [PATCH v3 2/2] tests: Workaroud for buggy glibc in ipc_msg test on ppc64

[Andreas Schwab]

On Sep 13 2016, Eugene Syromyatnikov 
 wrote:

> glibc before 2.23 (glibc-2.22-122-gbe48165? to be more precise) tried to 
> access
> data pointed by third argument of msgctl call on 64-bit PowerPC which led to
> segmentataion fault (instead of EFAULT from kernel).

Which is a perfectly valid thing to do, as passing an invalid pointer to
msgctl (the libc function) invokes undefined behaviour.  If you want to
test the kernel behaviour you need to talk to the kernel directly.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

--
___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel