Re: [PATCH 1/1] ptrace: make sure do_wait() won't hang afterPTRACE_ATTACH

[Tejun Heo]

Hello, Oleg, Roland.

On Thu, Feb 03, 2011 at 10:44:50PM +0100, Oleg Nesterov wrote:
> On 02/03, Roland McGrath wrote:
> >
> > IMHO this sort of band-aid does not really help the overall situation.
> > It takes something that is intricate and fiddly and just fiddles it a
> > bit more.  Userland will still have to handle older kernels where this
> > behavior is not there.  If userland does anything that relies on this
> > new behavior, then it will have to try somehow to figure out which
> > kernel versions have which behavior and adapt, etc.
> 
> Absolutely agreed.
> 
> As I said, I am not sure this patch makes sense. I only sent it
> because I have to react to the bug report.
> 
> > When the old behaviors are unhelpful like this, I think it is really
> > better to add new mechanisms instead.
> 
> Agreed!
> 
> Can't resist, let me repeat... imho ptrace is unfixable ;)

Hmm... I can't reproduce the problem here, but isn't the problematic
part here the mixing of ptrace and group stop and sliently
transforming group stop into ptrace and ptracer consuming the usual
exit code instead of the ptrace specific one?

Also, I don't agree with the notion that doing something entirely new
would magically solve all the problems.  Improvements are achieved
through evolution.  For ptrace, the situation definitely is aggravated
by the use of wait and weird interaction with group stop, but the
interaction is inherently complex for debugging facility and most
problems won't automatically go away with new interface.

Actually, I think such approach is significantly harmful to
improvements of the existing code base.  Instead of encouraging
investigating the actual problems and making sensible tradeoffs, such
approach discourages making reasonable tradeoffs with the false
expectation that something in the future will magically solve the
problems.  In a lot of cases, there are no unicorns.  Proceeding
forward while managing damage at reasonable level is usually the right
way to go.

That said, well, there always are exceptions and maybe there are some
rainbow farting unicorns in the ptrace land.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/