Hi,
I have tested your patch and I can confirm that the error is gone when
running a patched kernel. Thanks for fixing this in such a short
notice.
I am still seeing one very rare failure where the SIGUSR does not
appear to be reported. However, I will need to dig around this a bit
more to make s
On 21 March 2015 at 18:57, Oleg Nesterov wrote:
> On 03/20, Pavel Labath wrote:
>>
>> One difference I see though is that in
>> our test, we are not sending any additional signals to the thread in
>> question (at least we shouldn't be sending them, but we are sending some
>> signals to other threa
On 03/21, Oleg Nesterov wrote:
>
> On 03/20, Pavel Labath wrote:
> >
> > One difference I see though is that in
> > our test, we are not sending any additional signals to the thread in
> > question (at least we shouldn't be sending them, but we are sending some
> > signals to other threads in the s
On 03/20, Pavel Labath wrote:
>
> One difference I see though is that in
> our test, we are not sending any additional signals to the thread in
> question (at least we shouldn't be sending them, but we are sending some
> signals to other threads in the same process). Do you think it could still
> b
Sending again, this time as plain text (I hope)...
On 20 March 2015 at 18:46, Pavel Labath wrote:
>
> Hi,
>
> thanks for the super quick response. :)
>
> I am at home now, so I don't have access to the same machine to run the test.
> I will run it on monday and let you know.
>
> Meanwhile, I hav
Hi Pavel,
let me add lkml, we should not discuss this offlist.
On 03/20, Pavel Labath wrote:
>
> 1) we get a waitpid() notification that the tracee got SIGUSR1
> 2) we do a ptrace(GETSIGINFO) to get more info
> 3) eventually we decide to restart the tracee with PTRACE_CONT, passing it
> SIGUSR1
>
6 matches
Mail list logo
