> Just one question, this patch also changes utrace_report_death:
>
> @@ -1714,6 +1705,7 @@ void utrace_report_death
> utrace->death = 1;
> utrace->report = 0;
> utrace->interrupt = 0;
> + splice_attaching(utrace);
>
> But, afaics, we ne
On 09/04, Roland McGrath wrote:
>
> Please review commit 04852f3. I added a separate flag to guarantee
> start_report() notices pending attaches without using TIF_NOTIFY_RESUME.
Yes, the new flag looks nice! But please see 2 patches I'll send in a
minute.
Just one question, this patch also chan
> Not sure this makes real sense, but perhaps it would be tidier to
> check QUIESCE in utrace_resume.
I think the theory was that getting there without it set would be very
unlikely. That wasn't really true with the report-on-attach behavior.
But it should be without that (read on). OTOH, the bi
Not sure this makes real sense, but perhaps it would be tidier to
check QUIESCE in utrace_resume.
I wonder if we still have reasons to set ->report + TIF_NOTIFY_RESUME
in utrace_add_engine(). Looks like this is not needed now, but I am
not sure.
Signed-off-by: Oleg Nesterov
---
kernel/utrace.c
