Hi,
After doing BK pull last night INIT gets stuck in do_tty_hangup after
executing rc.sysinit. Was booting fine with pull from 2 days ago...
Anyone else seeing this?
I suspect pidhash patch because it touched tty_io.c, but I have not tried
reverting it as it is getting too late here... So I apologize in advance
if I am pointing finger at the innocent ;)
--
Dmitry
On Fri, Sep 03, 2004 at 02:04:11AM -0500, Dmitry Torokhov wrote:
> After doing BK pull last night INIT gets stuck in do_tty_hangup after
> executing rc.sysinit. Was booting fine with pull from 2 days ago...
> Anyone else seeing this?
> I suspect pidhash patch because it touched tty_io.c, but I have not tried
> reverting it as it is getting too late here... So I apologize in advance
> if I am pointing finger at the innocent ;)
Well, I was excited about blowing away 100B from each task but am now
a bit concerned about the semantic impact of the refcounting part of it.
It's unclear what pins an ID while a tty has a reference to it without
the reference counting; Kirill, could you answer this?
-- wli
--- ./include/linux/pid.h.pid2 2004-09-03 11:52:27.510664040 +0400
+++ ./include/linux/pid.h 2004-09-03 11:40:33.616192496 +0400
@@ -46,10 +46,10 @@ extern void switch_exec_pids(struct task
do {
#define while_each_task_pid(who, type, task) \
- task = pid_task((task)->pids[type].pid_list.next,\
- type); \
- prefetch((task)->pids[type].pid_list.next); \
- } while (hlist_unhashed(&(task)->pids[type].pid_chain));\
+ } while (task = pid_task((task)->pids[type].pid_list.next,\
+ type), \
+ prefetch((task)->pids[type].pid_list.next), \
+ hlist_unhashed(&(task)->pids[type].pid_chain)); \
} \
#endif /* _LINUX_PID_H */
>>After doing BK pull last night INIT gets stuck in do_tty_hangup after
>>executing rc.sysinit. Was booting fine with pull from 2 days ago...
>>Anyone else seeing this?
>>I suspect pidhash patch because it touched tty_io.c, but I have not tried
>>reverting it as it is getting too late here... So I apologize in advance
>>if I am pointing finger at the innocent ;)
>
>
> Well, I was excited about blowing away 100B from each task but am now
> a bit concerned about the semantic impact of the refcounting part of it.
> It's unclear what pins an ID while a tty has a reference to it without
> the reference counting; Kirill, could you answer this?
stop.
tty doesn't hold reference to ID neither in my patch nor in the original
kernel.
tty only knows session ID and wants to traverse all tasks with such ID.
if task dies it calls detach_pid() and it won't be found in such a loop.
No reference counting is required.
The problem was in loop. Or more exactly my
do_each_task_pid()/while_each_task_pid() macros were incompatible with
continue statement inside. It was really foolish error. Like the most are...
Kirill
At some point in the past, Dmitry Torokhov wrote:
>> Well, I was excited about blowing away 100B from each task but am now
>> a bit concerned about the semantic impact of the refcounting part of it.
>> It's unclear what pins an ID while a tty has a reference to it without
>> the reference counting; Kirill, could you answer this?
On Fri, Sep 03, 2004 at 12:09:10PM +0400, Kirill Korotaev wrote:
> stop.
> tty doesn't hold reference to ID neither in my patch nor in the original
> kernel.
> tty only knows session ID and wants to traverse all tasks with such ID.
> if task dies it calls detach_pid() and it won't be found in such a loop.
> No reference counting is required.
> The problem was in loop. Or more exactly my
> do_each_task_pid()/while_each_task_pid() macros were incompatible with
> continue statement inside. It was really foolish error. Like the most are...
Well, that sounds easy enough to deal with. I suppose the reference
counting argument is that the refcounting is on the tty by the tasks
and not vice-versa, and disassociate_ctty() cleans up the SID reference.
-- wli
On Friday 03 September 2004 03:00 am, Kirill Korotaev wrote:
> > After doing BK pull last night INIT gets stuck in do_tty_hangup after
> > executing rc.sysinit. Was booting fine with pull from 2 days ago...
> >
> > Anyone else seeing this?
> >
> > I suspect pidhash patch because it touched tty_io.c, but I have not tried
> > reverting it as it is getting too late here... So I apologize in advance
> > if I am pointing finger at the innocent ;)
>
> Oops, you are right. These do_each_task_pid()/while_each_task_pid() do
> loop 4ever with 'continue' inside.
> Strange, that I haven't faced the problem on my machine before sending
> the patch... :(
>
> Sorry for the inconvinience. Patch is inside.
I see that the patch is already in the kernel proper. Just for the record the
patch fixes my problem and the box boots fine. Thanks, Kirill!
--
Dmitry