Re: [PATCH 1/4] ptrace: temporary revert the recent ptrace/jobctl rework
On 06/21/2011 10:25 AM, Oleg Nesterov wrote: OK, I won't argue. So we need to rework utrace/ptrace in 3.0, then we should do this again in 3.1. I'll try to do something. I have a thought here, I'm not familiar enough with utrace internals to know whether it is a good one or not. Originally, implementing ptrace via utrace was optional - if I remember correctly there was a define that turned it off and on. One of the good things about implementing ptrace-via-utrace is that they co-existed well - you could ptrace a process that you were also using utrace on. If I remember correctly, during one of the utrace reviews, making ptrace-via-utrace optional was requested to be removed. Now with the recent ptrace changes, still implementing ptrace-via-utrace will take some work. OK, so here's my (hacky) idea: (1) Forget ptrace-via-utrace. Have utrace be a separate thing. This way the recent ptrace changes won't matter. (2) But, what about ptrace co-existing well with utrace? Make them mutually exclusive - a ptraced-process can't be utraced and a utraced-process can't be ptraced. Assuming the above is a semi-reasonable idea, it might be a lot less work than updating the ptrace-via-utrace code to handle the new ptrace changes. -- David Smith dsm...@redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax)
Re: [PATCH 1/4] ptrace: temporary revert the recent ptrace/jobctl rework
OK, so here's my (hacky) idea: (1) Forget ptrace-via-utrace. Have utrace be a separate thing. This way the recent ptrace changes won't matter. (2) But, what about ptrace co-existing well with utrace? Make them mutually exclusive - a ptraced-process can't be utraced and a utraced-process can't be ptraced. We had this situation before for a while. It has the substantial downside that e.g. you cannot do any system-wide systemtap tracing without making all strace and gdb use impossible. Assuming the above is a semi-reasonable idea, it might be a lot less work than updating the ptrace-via-utrace code to handle the new ptrace changes. That's for Oleg to say. (Sorry, Oleg. ;-) Thanks, Roland
Re: [PATCH 1/4] ptrace: temporary revert the recent ptrace/jobctl rework
On Tue, Jun 21, 2011 at 05:25:19PM +0200, Oleg Nesterov wrote: I understand. Once again, it was supposed to be a temporary solution until fedora switches to 3.1. And the reverted code does not make the real difference so far, the user-visible changes are minor. Yeah, I understand, it just looks bad for us. OK, I won't argue. So we need to rework utrace/ptrace in 3.0, then we should do this again in 3.1. I'll try to do something. I don't think worrying about 3.0 is necessary... it won't ship in anything, and we should be well on our way to 3.1 by the time we branch F-16 in 5 weeks, focusing effort there seems more sensible. (Rawhide will be changing awfully rapidly in the mean time anyway.) --Kyle
