Re: utrace_ptrace && task->ptrace

2009-08-08 Thread Christoph Hellwig
On Fri, Aug 07, 2009 at 02:19:10PM -0700, Piet Delaney wrote: > Roland McGrath wrote: > > >Only a few arch's overload ->ptrace for private purposes, and I don't > >foresee any problem getting those fixed up soon. (The parisc maintainer is > >doing it already. I think xtensa might have something

Re: utrace_ptrace && task->ptrace

2009-08-07 Thread Roland McGrath
> I thought I check on xtensa having something on deck. > I'd like to test it if possible to avoid surprises and > if it's not ready, and needs to be, then to include this > while submitting SMP changes in the not too distant future. Sorry, that was a dim recollection of mine and it appears to hav

Re: utrace_ptrace && task->ptrace

2009-08-07 Thread Piet Delaney
Roland McGrath wrote: Only a few arch's overload ->ptrace for private purposes, and I don't foresee any problem getting those fixed up soon. (The parisc maintainer is doing it already. I think xtensa might have something on deck. I can do the arm changes if anybody will ever review and merge

Re: utrace_ptrace && task->ptrace

2009-08-05 Thread Christoph Hellwig
On Tue, Aug 04, 2009 at 06:09:11PM -0700, Roland McGrath wrote: > > I agree, CONFIG_UTRACE_PTRACE should die. But what about !CONFIG_UTRACE > > case? What should we do with arches which doesn't use tracehooks or > > play with ptrace internals? > > AIUI hch wants to have ptrace rely on utrace. Tho

Re: utrace_ptrace && task->ptrace

2009-08-04 Thread Roland McGrath
> Actually the very first "for utrace-devel only" version should be just > your utrace-ptrace.patch + attach/detach fixes. Not that I can verify > this, but I hope that ptrace_utrace_ops's methods are more or less right. > (but of course, we should recheck them as much is possible). The utrace_ops

Re: utrace_ptrace && task->ptrace

2009-08-04 Thread Oleg Nesterov
On 08/03, Roland McGrath wrote: > > > So. For the first version of CONFIG_PTRACE_UTRACE I'd suggest to use > > ->ptrace to keep the single bit, PT_PTRACED (well, PT_PTRACE_CAP too). > > All other PT_ bits should go into engine->data. > > Ok. Actually the very first "for utrace-devel only" version

Re: utrace_ptrace && task->ptrace

2009-08-03 Thread Roland McGrath
> > Not "some", just that one, right? > > Not just one. tracehook_tracer_task, tracehook_notify_jctl. Ah. tracer_task is an outlier we can think about separately a little later. The notify_jctl case is another in the same bag of wait/SIGCHLD things that I had in mind. > The problem is, I can't

utrace_ptrace && task->ptrace

2009-08-03 Thread Oleg Nesterov
On 07/24, Roland McGrath wrote: > > > For example, wait_consider_task(). Even some tracehooks, say, > > tracehook_notify_death() need task_is_ptraced(). > > Not "some", just that one, right? Not just one. tracehook_tracer_task, tracehook_notify_jctl. But, > So these are all really the same one >