2011-02-02 05:44:40

by Roland McGrath

[permalink] [raw]
Subject: Re: [PATCH 06/10] signal: fix premature completion of group stop when interfered by ptrace

> I have plans on separate out ptrace related stuff from task_struct so
> that they're allocate iff they're used which will save some tens of
> bytes on the task struct, so there at least is a plan to compensate
> for the added cruft.

My, that sounds familiar. Oleg and I have pursued that before, though
not in exactly the same context. It sure gets complicated quickly in
the corners. But we would still like to see it get done one way or
another.

> > But I'm not entirely convinced that we'll really need them when we
> > conclude on fully cleaning up the whole picture.
>
> I really don't know at this point. I tried to make it share one of
> the related fields but there needs to be a per-task field which is
> protected by siglock and there currently isn't any, so...

My point was that I am not yet convinced we'll need any new bookkeeping of
that sort once we fully work out the group-stop interactions. We're still
discussing that in the other threads. So we'll see where that goes.


Thanks,
Roland


2011-02-02 10:56:38

by Tejun Heo

[permalink] [raw]
Subject: Re: [PATCH 06/10] signal: fix premature completion of group stop when interfered by ptrace

Hello,

On Tue, Feb 01, 2011 at 09:44:05PM -0800, Roland McGrath wrote:
> > I have plans on separate out ptrace related stuff from task_struct so
> > that they're allocate iff they're used which will save some tens of
> > bytes on the task struct, so there at least is a plan to compensate
> > for the added cruft.
>
> My, that sounds familiar. Oleg and I have pursued that before, though
> not in exactly the same context. It sure gets complicated quickly in
> the corners. But we would still like to see it get done one way or
> another.

Yeap, I have mostly working code. It was necessary to allow nesting,
so...

> > > But I'm not entirely convinced that we'll really need them when we
> > > conclude on fully cleaning up the whole picture.
> >
> > I really don't know at this point. I tried to make it share one of
> > the related fields but there needs to be a per-task field which is
> > protected by siglock and there currently isn't any, so...
>
> My point was that I am not yet convinced we'll need any new bookkeeping of
> that sort once we fully work out the group-stop interactions. We're still
> discussing that in the other threads. So we'll see where that goes.

Yeah, sure.

Thanks.

--
tejun