This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Add UNSUPPORTED check in elf/tst-pldd.
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Stefan Liebler <stli at linux dot ibm dot com>, Florian Weimer <fweimer at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Tue, 3 Sep 2019 10:34:06 -0300
- Subject: Re: [PATCH] Add UNSUPPORTED check in elf/tst-pldd.
- References: <fbb0d1e8-4f39-59ed-801c-d53e14d0320a@linux.ibm.com> <d70954b6-e749-5546-bcfd-509a597b8a14@linaro.org> <877e6yiqsn.fsf@oldenburg2.str.redhat.com> <3b9cb5e4-7c9a-c9a4-449e-43ba98a6ad01@linaro.org> <32961942-e67b-c356-a92d-b6e45c8aaf9d@linux.ibm.com> <87blw9fxrp.fsf@oldenburg2.str.redhat.com> <1d419974-c973-c4c1-f1cd-4bbbf8b074f8@linux.ibm.com> <87tva08ijw.fsf@oldenburg2.str.redhat.com> <c6ca1eba-bb9f-c4da-b65c-56f53a04a5f6@linaro.org> <158c26d5-a6cc-37a9-2b23-dc8a45f52217@linux.ibm.com>
On 03/09/2019 03:30, Stefan Liebler wrote:
> On 9/2/19 9:37 PM, Adhemerval Zanella wrote:
>>
>>
>> On 29/08/2019 05:47, Florian Weimer wrote:
>>> * Stefan Liebler:
>>>
>>>> On 8/28/19 11:24 AM, Florian Weimer wrote:
>>>>> * Stefan Liebler:
>>>>>
>>>>>> static void
>>>>>> target_process (void *arg)
>>>>>> {
>>>>>> + if (ptrace_scope == 1)
>>>>>> + {
>>>>>> + /* YAMA is configured to "restricted ptrace".
>>>>>> + Disable the restriction for this subprocess. */
>>>>>> + support_ptrace_process_set_ptracer_any ();
>>>>>> + }
>>>>>> +
>>>>>> pause ();
>>>>>> }
>>>>>
>>>>> I think this has a race condition if pldd attaches to the process before
>>>>> the support_ptrace_process_set_ptracer_any call. I have no idea how
>>>>> hard it is in practice to hit this race. It should be possible to use a
>>>>> process-shared barrier or some other form of synchronization to avoid
>>>>> this issue.
>>>>>
>>>>> Thanks,
>>>>> Florian
>>>>>
>>>>
>>>> I've added a synchronization with stdatomic.h on a shared memory mapping.
>>>> I've not used pthread* functions as I don't want to link against
>>>> libpthread.so. Then further adjustments are needed.
>>>>
>>>> Or should I just restrict the test ptrace_scope 0 as Adhemerval has
>>>> proposed in his post?
>>>
>>> Is it possible to create a process tree like this?
>>>
>>>
>>> parent (performs output checks)
>>> subprocess 1 (becomes pldd via execve)
>>> subprocess 2
>>>
>>> If you execve pldd from subprocess 1, wouldn't subprocess 2 in its
>>> ptrace scope for ptrace_scope < 2?
>>
>> Do we really need that ad-hoc support on tst-pldd to make it support
>> ptrace_scope 1?
>>
>> I don't oppose the support Stefan has added on latest iteration to
>> make it work, but this is a lot of code to support a very specific
>> scenario...
>>
> As there are systems where ptrace_scope is configured to 1 by default, we should adjust the testcase as the FAIL is misleading.
> (I've just recognized that Steve Ellcey had also seen this FAIL: https://www.sourceware.org/ml/libc-alpha/2019-07/msg00618.html)
>
> The minimum change should be to detect ptrace_scope == 1 and mark the test as UNSUPPORTED. Or we change a bit more and let the test also run in this scenario. (Either by support_ptrace_process_set_ptracer_any or adjusting the subprocess-tree)
Yes, my initial suggestion was just to make it as UNSUPPORTED for ptrace_scope >= 1.
But I do not oppose adjusting it to run on ptrace_scope 1, it is just that
the required hackery lead to make it somewhat as complex than the test itself.