tty: Only hangup once
PATCH 1/1 tty: Only hangup once
Instrumented testing shows a tty can be hungup multiple times [1]. Although concurrent hangups are properly serialized, multiple hangups for the same tty should be prevented.
If tty has already been HUPPED, abort hangup. Note it is not necessary to cleanup file *redirect on subsequent hangups, as only TIOCCONS can set that value and ioctls are disabled after hangup.
[1]
Test performed by simulating a concurrent async hangup via tty_hangup() with a sync hangup via tty_vhangup(), while __tty_hangup() was instrumented with:
drivers/tty/tty_io.c +2 -0
@@ -629,6 +629,8 @@ static void __tty_hangup(struct tty_struct *tty, int exit_session)tty_lock (tty); +WARN_ON (test_bit (TTY_HUPPED , &tty->flags)); +/* some functions below drop BTM, so we need this bit */ set_bit (TTY_HUPPING , &tty->flags);
Test result:
WARNING: at /home/peter/src/kernels/mainline/drivers/tty/tty_io.c:632 __tty_hangup+0x459/0x460() Modules linked in: ip6table_filter ip6_tables ebtable_nat <...snip...> CPU: 6 PID: 1197 Comm: kworker/6:2 Not tainted 3.10.0-0+rfcomm-xeon #0+rfcomm Hardware name: Dell Inc. Precision WorkStation T5400 /0RW203, BIOS A11 04/30/2012 Workqueue: events do_tty_hangup 0000000000000009 ffff8802b16d7d18 ffffffff816b553e ffff8802b16d7d58 ffffffff810407e0 ffff880254f95c00 ffff880254f95c00 ffff8802bfd92b00 ffff8802bfd96b00 ffff880254f95e40 0000000000000180 ffff8802b16d7d68 Call Trace: [<ffffffff816b553e>] dump_stack+0x19/0x1b [<ffffffff810407e0>] warn_slowpath_common+0x70/0xa0 [<ffffffff8104082a>] warn_slowpath_null+0x1a/0x20 [<ffffffff813fb279>] __tty_hangup+0x459/0x460 [<ffffffff8107409c>] ? finish_task_switch+0xbc/0xe0 [<ffffffff813fb297>] do_tty_hangup+0x17/0x20 [<ffffffff8105fd6f>] process_one_work+0x16f/0x450 [<ffffffff8106007c>] process_scheduled_works+0x2c/0x40 [<ffffffff8106060a>] worker_thread+0x26a/0x380 [<ffffffff810603a0>] ? rescuer_thread+0x310/0x310 [<ffffffff810698a0>] kthread+0xc0/0xd0 [<ffffffff816b0000>] ? destroy_compound_page+0x65/0x92 [<ffffffff810697e0>] ? kthread_create_on_node+0x130/0x130 [<ffffffff816c495c>] ret_from_fork+0x7c/0xb0 [<ffffffff810697e0>] ? kthread_create_on_node+0x130/0x130 ---[ end trace 98d9f01536cf411e ]--- --- drivers/tty/tty_io.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/tty/tty_io.c +5 -0
@@ -629,6 +629,11 @@ static void __tty_hangup(struct tty_struct *tty, int exit_session)tty_lock (tty); +if (test_bit (TTY_HUPPED , &tty->flags)) { +tty_unlock (tty); +return ; + } +/* some functions below drop BTM, so we need this bit */ set_bit (TTY_HUPPING , &tty->flags);
Signature · 1 line
1.8.1.2
Greg Kroah-Hartman
maintainerQuoted 65 lines · Peter Hurley
Instrumented testing shows a tty can be hungup multiple times [1]. Although concurrent hangups are properly serialized, multiple hangups for the same tty should be prevented.
If tty has already been HUPPED, abort hangup. Note it is not necessary to cleanup file *redirect on subsequent hangups, as only TIOCCONS can set that value and ioctls are disabled after hangup.
Signed-off-by Peter Hurley <[email protected]>[1]
Test performed by simulating a concurrent async hangup viatty_hangup()with a sync hangup viatty_vhangup(), while__tty_hangup()was instrumented with:drivers/tty/tty_io.c +2
-0@@ -629,6 +629,8 @@ static void __tty_hangup(struct tty_struct *tty, int exit_session)tty_lock (tty); +WARN_ON (test_bit (TTY_HUPPED , &tty->flags)); +/* some functions below drop BTM, so we need this bit */ set_bit (TTY_HUPPING , &tty->flags);Test result:
WARNING: at /home/peter/src/kernels/mainline/drivers/tty/tty_io.c:632 __tty_hangup+0x459/0x460() Modules linked in: ip6table_filter ip6_tables ebtable_nat <...snip...> CPU: 6 PID: 1197 Comm: kworker/6:2 Not tainted 3.10.0-0+rfcomm-xeon #0+rfcomm Hardware name: Dell Inc. Precision WorkStation T5400 /0RW203, BIOS A11 04/30/2012 Workqueue: events do_tty_hangup 0000000000000009 ffff8802b16d7d18 ffffffff816b553e ffff8802b16d7d58 ffffffff810407e0 ffff880254f95c00 ffff880254f95c00 ffff8802bfd92b00 ffff8802bfd96b00 ffff880254f95e40 0000000000000180 ffff8802b16d7d68 Call Trace: [<ffffffff816b553e>] dump_stack+0x19/0x1b [<ffffffff810407e0>] warn_slowpath_common+0x70/0xa0 [<ffffffff8104082a>] warn_slowpath_null+0x1a/0x20 [<ffffffff813fb279>] __tty_hangup+0x459/0x460 [<ffffffff8107409c>] ? finish_task_switch+0xbc/0xe0 [<ffffffff813fb297>] do_tty_hangup+0x17/0x20 [<ffffffff8105fd6f>] process_one_work+0x16f/0x450 [<ffffffff8106007c>] process_scheduled_works+0x2c/0x40 [<ffffffff8106060a>] worker_thread+0x26a/0x380 [<ffffffff810603a0>] ? rescuer_thread+0x310/0x310 [<ffffffff810698a0>] kthread+0xc0/0xd0 [<ffffffff816b0000>] ? destroy_compound_page+0x65/0x92 [<ffffffff810697e0>] ? kthread_create_on_node+0x130/0x130 [<ffffffff816c495c>] ret_from_fork+0x7c/0xb0 [<ffffffff810697e0>] ? kthread_create_on_node+0x130/0x130 ---[ end trace 98d9f01536cf411e ]--- --- drivers/tty/tty_io.c | 5 +++++ 1 file changed, 5 insertions(+)drivers/tty/tty_io.c +0
-0
drivers/tty/tty_io.c static void __tty_hangup(struct tty_struct *tty, int exit_session) · line 638
Quoted 10 lines
drivers/tty/tty_io.c +5
-0@@ -629,6 +629,11 @@ static void __tty_hangup(struct tty_struct *tty, int exit_session)tty_lock (tty); +if (test_bit (TTY_HUPPED , &tty->flags)) { +tty_unlock (tty); +return ; + } +/* some functions below drop BTM, so we need this bit */ set_bit (TTY_HUPPING , &tty->flags);
A diff inside the changelog entry of a diff is going to cause havoc :)
I'll go edit this to make it not complain...
thanks,
greg k-h
Quoted 1 line · Greg Kroah-Hartman
A diff inside the changelog entry of a diff is going to cause havoc :)
Right, sorry :) Won't happen again.
Quoted 1 line
I'll go edit this to make it not complain...
Thanks,
Peter Hurley
Quoted 67 lines · On Wed, 31 Jul 2013 14:05:45 -0400 Peter Hurley <[email protected]>…
Instrumented testing shows a tty can be hungup multiple times [1]. Although concurrent hangups are properly serialized, multiple hangups for the same tty should be prevented.
If tty has already been HUPPED, abort hangup. Note it is not necessary to cleanup file *redirect on subsequent hangups, as only TIOCCONS can set that value and ioctls are disabled after hangup.
Signed-off-by Peter Hurley <[email protected]>[1]
Test performed by simulating a concurrent async hangup viatty_hangup()with a sync hangup viatty_vhangup(), while__tty_hangup()was instrumented with:drivers/tty/tty_io.c +2
-0@@ -629,6 +629,8 @@ static void __tty_hangup(struct tty_struct *tty, int exit_session)tty_lock (tty ); +WARN_ON (test_bit (TTY_HUPPED , &tty->flags)); +/* some functions below drop BTM, so we need this bit */ set_bit (TTY_HUPPING , &tty->flags);Test result:
WARNING: at /home/peter/src/kernels/mainline/drivers/tty/tty_io.c:632 __tty_hangup+0x459/0x460() Modules linked in: ip6table_filter ip6_tables ebtable_nat <...snip...> CPU: 6 PID: 1197 Comm: kworker/6:2 Not tainted 3.10.0-0+rfcomm-xeon #0+rfcomm Hardware name: Dell Inc. Precision WorkStation T5400 /0RW203, BIOS A11 04/30/2012 Workqueue: events do_tty_hangup 0000000000000009 ffff8802b16d7d18 ffffffff816b553e ffff8802b16d7d58 ffffffff810407e0 ffff880254f95c00 ffff880254f95c00 ffff8802bfd92b00 ffff8802bfd96b00 ffff880254f95e40 0000000000000180 ffff8802b16d7d68 Call Trace: [<ffffffff816b553e>] dump_stack+0x19/0x1b [<ffffffff810407e0>] warn_slowpath_common+0x70/0xa0 [<ffffffff8104082a>] warn_slowpath_null+0x1a/0x20 [<ffffffff813fb279>] __tty_hangup+0x459/0x460 [<ffffffff8107409c>] ? finish_task_switch+0xbc/0xe0 [<ffffffff813fb297>] do_tty_hangup+0x17/0x20 [<ffffffff8105fd6f>] process_one_work+0x16f/0x450 [<ffffffff8106007c>] process_scheduled_works+0x2c/0x40 [<ffffffff8106060a>] worker_thread+0x26a/0x380 [<ffffffff810603a0>] ? rescuer_thread+0x310/0x310 [<ffffffff810698a0>] kthread+0xc0/0xd0 [<ffffffff816b0000>] ? destroy_compound_page+0x65/0x92 [<ffffffff810697e0>] ? kthread_create_on_node+0x130/0x130 [<ffffffff816c495c>] ret_from_fork+0x7c/0xb0 [<ffffffff810697e0>] ? kthread_create_on_node+0x130/0x130 ---[ end trace 98d9f01536cf411e ]--- --- drivers/tty/tty_io.c | 5 +++++ 1 file changed, 5 insertions(+)drivers/tty/tty_io.c +0
-0@@ -629,6 +629,11 @@ static void __tty_hangup(struct tty_struct *tty, int exit_session)
drivers/tty/tty_io.c static void __tty_hangup(struct tty_struct *tty, · line 639
Quoted 10 lines
drivers/tty/tty_io.c +5
-0tty_lock (tty); +if (test_bit (TTY_HUPPED , &tty->flags)) { +tty_unlock (tty); +return ; + } +/* some functions below drop BTM, so we need this bit */ set_bit (TTY_HUPPING , &tty->flags);
After upgrading to kernel 3.12 I noticed one issue with tmux software. The easiest way to reproduce will be:
1. Start tmux session as root.
2. Connect via ssh and use "tmux attach" to attach to the running session.
3. Kill ssh client.
You can notice that shell (zsh in my case) and "tmux attach" are still remains in process' list. That didn't happen in previous kernels. I've tried to bisect this in kernel sources and found commit cb50e5235b8ae5aa0fe422eaaa8e444024c5bd98 which contains this exact patch. I have not enough experience to investigate more so most likely I will not find anything more. But it will be good if someone more experienced will have a look at it.
Quoted 7 lines
After upgrading to kernel 3.12 I noticed one issue with tmux software. The easiest way to reproduce will be:
1. Start tmux session as root.
2. Connect via ssh and use "tmux attach" to attach to the running session.
3. Kill ssh client.
Quoted 7 lines
You can notice that shell (zsh in my case) and "tmux attach" are still remains in process' list. That didn't happen in previous kernels. I've tried to bisect this in kernel sources and found commit
cb50e5235b8ae5aa0fe422eaaa8e444024c5bd98which contains this exact patch. I have not enough experience to investigate more so most likely I will not find anything more. But it will be good if someone more experienced will have a look at it.
The patch should be reverted. The submission gives no reason that the patch was required - it just adds code and optimises a path that doesn't need optimising anyway.
It's theoretically true you only need one hangup, unfortunately however I think it has to be the *last* hangup not the first or there are races between the tty code and the process group handling.
Alan
Quoted 6 lines · One Thousand Gnomes
Quoted 6 lines
After upgrading to kernel 3.12 I noticed one issue with tmux software. The easiest way to reproduce will be:
1. Start tmux session as root.
2. Connect via ssh and use "tmux attach" to attach to the running session.
3. Kill ssh client.
Heorhi,
Thanks for the report.
Quoted 2 lines
Quoted 2 lines
You can notice that shell (zsh in my case) and "tmux attach" are still remains in process' list. That didn't happen in previous kernels.
This may have been a bug in previous kernels.
The tmux(1) man page has this to say:
Each session is persistent and will survive accidental disconnection (such as ssh(1) connection timeout) or intentional detaching (with the `C-b d' key strokes). tmux may be reattached using:
$ tmux attach
I'll confirm with tmux author(s) what the intended behavior is.
Quoted 9 lines
Quoted 5 lines
I've tried to bisect this in kernel sources and found commit
cb50e5235b8ae5aa0fe422eaaa8e444024c5bd98which contains this exact patch. I have not enough experience to investigate more so most likely I will not find anything more. But it will be good if someone more experienced will have a look at it.The patch should be reverted. The submission gives no reason that the patch was required - it just adds code and optimises a path that doesn't need optimising anyway.
Alan,
This patch isn't about optimizing; it's about guaranteeing the line discipline and a tty driver that ops->hangup() will only occur once for any given tty.
Quoted 3 lines
It's theoretically true you only need one hangup, unfortunately however I think it has to be the *last* hangup not the first or there are races between the tty code and the process group handling.
I doubt this is caused by a race condition; the first hangup would do most of the destruction regardless, and a second hangup can't really race with the first because of the tty_lock() held for most of the hangup.
In any event, it's worth discovering what state a subsequent hangup can effect that the first hangup left incomplete. I'll look into it.
Regards,
Peter Hurley
Quoted 8 lines · Peter Hurley
Quoted 6 lines · One Thousand Gnomes
Quoted 6 lines
After upgrading to kernel 3.12 I noticed one issue with tmux software. The easiest way to reproduce will be:
1. Start tmux session as root.
2. Connect via ssh and use "tmux attach" to attach to the running session.
3. Kill ssh client.
Quoted 6 lines
Heorhi,
Thanks for the report.
Quoted 2 lines
Quoted 2 lines
You can notice that shell (zsh in my case) and "tmux attach" are still remains in process' list. That didn't happen in previous kernels.
Heorhi,
I could not reproduce this behavior with zsh or bash.
In case I misunderstood, the steps I took to reproduce were,
[On ssh server machine running 3.12]
1. Add 'set-option -g default-shell /usr/bin/zsh' to /etc/tmux.conf 2a. In terminal window, 'sudo tmux'
- also tried -
2b. At root login on tty2, 'tmux'
Successfully starts tmux session. Then,
[On ssh client machine]
1. 'ssh user@server'
2. 'sudo tmux attach'
3. Switch to 2nd terminal window,
4. ps -ef | grep ssh
5. kill $pid_from_step4
This *did not* leave the 'tmux attach' process alive.
Is zsh your login shell as well? Maybe that's the required component to reproduce the behavior you've observed.
Regards,
Peter Hurley
Quoted 17 lines · On Mon, 18 Nov 2013 15:32:59 -0500 Peter Hurley <[email protected]>…
Quoted 8 lines · Peter Hurley
Quoted 6 lines · One Thousand Gnomes
Quoted 6 lines
After upgrading to kernel 3.12 I noticed one issue with tmux software. The easiest way to reproduce will be:
1. Start tmux session as root.
2. Connect via ssh and use "tmux attach" to attach to the running session.
3. Kill ssh client.Quoted 7 lines
Heorhi,
Thanks for the report.
Quoted 3 lines
Quoted 3 lines
You can notice that shell (zsh in my case) and "tmux attach" are still remains in process' list. That didn't happen in previous kernels.
Quoted 8 lines
Heorhi,
I could not reproduce this behavior with zsh or bash.
In case I misunderstood, the steps I took to reproduce were,
[On ssh server machine running 3.12]
1. Add 'set-option -g default-shell/usr/bin/zsh' to/etc/tmux.conf
This is really not necessary. I also reproduced it with bash.
Quoted 13 lines
2a. In terminal window, 'sudo tmux'
- also tried -
2b. At root login on tty2, 'tmux'Successfully starts tmux session. Then,
[On ssh client machine]
1. 'ssh user@server'
2. 'sudo tmux attach'
3. Switch to 2nd terminal window,
4. ps -ef | grep ssh
5. kill $pid_from_step4
Quoted 7 lines
This *did not* leave the 'tmux attach' process alive.
Is zsh your login shell as well? Maybe that's the required component to reproduce the behavior you've observed.
Regards,
Peter Hurley
Thank you for your attention.
I tried to reproduce it exactly as you did and notice strange thing. You use "sudo tmux attach" and tmux client uses the terminal created for regular user and those works good.
But if you will use "ssh root@server" (you can use localhost too) the "tmux attach" will use terminal created from root (i checked this with lsof and ls -al /dev/pts) and behavior is different. Are terminals created for root is somehow different from those created for regular users?
If you can't use root ssh login I will try to reproduce it's for sudo by mixing some kind of dtach and tmux but it will be very unclear at the end.
Heorhi
Quoted 63 lines · Heorhi Valakhanovich
Quoted 17 lines · On Mon, 18 Nov 2013 15:32:59 -0500 Peter Hurley <[email protected]>…
Quoted 8 lines · Peter Hurley
Quoted 6 lines · One Thousand Gnomes
Quoted 6 lines
After upgrading to kernel 3.12 I noticed one issue with tmux software. The easiest way to reproduce will be:
1. Start tmux session as root.
2. Connect via ssh and use "tmux attach" to attach to the running session.
3. Kill ssh client.Quoted 7 lines
Heorhi,
Thanks for the report.
Quoted 3 lines
Quoted 3 lines
You can notice that shell (zsh in my case) and "tmux attach" are still remains in process' list. That didn't happen in previous kernels.
Quoted 8 lines
Heorhi,
I could not reproduce this behavior with zsh or bash.
In case I misunderstood, the steps I took to reproduce were,
[On ssh server machine running 3.12]
1. Add 'set-option -g default-shell/usr/bin/zsh' to/etc/tmux.confThis is really not necessary. I also reproduced it with bash.
Quoted 13 lines
2a. In terminal window, 'sudo tmux'
- also tried -
2b. At root login on tty2, 'tmux'Successfully starts tmux session. Then,
[On ssh client machine]
1. 'ssh user@server'
2. 'sudo tmux attach'
3. Switch to 2nd terminal window,
4. ps -ef | grep ssh
5. kill $pid_from_step4Quoted 7 lines
This *did not* leave the 'tmux attach' process alive.
Is zsh your login shell as well? Maybe that's the required component to reproduce the behavior you've observed.
Regards,
Peter HurleyThank you for your attention.
I tried to reproduce it exactly as you did and notice strange thing. You use "sudo tmux attach" and tmux client uses the terminal created for regular user and those works good.But if you will use "ssh root@server" (you can use localhost too) the "tmux attach" will use terminal created from root (i checked this with lsof and ls -al
/dev/pts) and behavior is different. Are terminals created for root is somehow different from those created for regular users?
Quoted 3 lines
If you can't use root ssh login I will try to reproduce it's for sudo by mixing some kind of dtach and tmux but it will be very unclear at the end.
Thanks for the additional testing; yes, the "ssh root@server" is the crucial difference. I was able to reproduce the problem immediately.
Before sshd execs a new root shell, it hangs up and then re-opens the current tty as a security measure. Because the tty state was not being reset, the subsequent re-open could not be hung up.
Would you please test the patch below and confirm the fix?
--->%---
Subject: [PATCH] tty: Reset hupped state on open
A common security idiom is to hangup the current tty (via vhangup()) after forking but before execing a root shell. This hangs up any existing opens which other processes may have and ensures subsequent opens have the necessary permissions to open the root shell tty/pty.
Reset the TTY_HUPPED state after the driver has successfully returned the opened tty (perform the reset while the tty is locked to avoid racing with concurrent hangups).
--- drivers/tty/tty_io.c | 1 + 1 file changed, 1 insertion(+)
drivers/tty/tty_io.c +1 -0
@@ -2086,6 +2086,7 @@ retry_open: filp->f_op = &tty_fops; goto retry_open; } +clear_bit (TTY_HUPPED , &tty->flags);tty_unlock (tty);
Signature · 1 line
1.8.1.2
Quoted 25 lines · On Tue, 19 Nov 2013 08:46:27 -0500 Peter Hurley <[email protected]>…
Would you please test the patch below and confirm the fix?
--->%---
Subject: [PATCH] tty: Reset hupped state on openA common security idiom is to hangup the current tty (via
vhangup()) after forking but before execing a root shell. This hangs up any existing opens which other processes may have and ensures subsequent opens have the necessary permissions to open the root shell tty/pty.Reset the
TTY_HUPPEDstate after the driver has successfully returned the opened tty (perform the reset while the tty is locked to avoid racing with concurrent hangups).Reported-by Heorhi Valakhanovich <[email protected]>Signed-off-by Peter Hurley <[email protected]>--- drivers/tty/tty_io.c | 1 + 1 file changed, 1 insertion(+)drivers/tty/tty_io.c +0
-0
drivers/tty/tty_io.c retry_open: · line 2092
Quoted 7 lines
drivers/tty/tty_io.c +1
-0@@ -2086,6 +2086,7 @@ retry_open: filp->f_op = &tty_fops; goto retry_open; } +clear_bit (TTY_HUPPED , &tty->flags);tty_unlock (tty);
It looks like this patch works. It solves my problem. Thanks. Will wait for such fix in mainline.
Heorhi.
Greg KH
maintainerQuoted 23 lines · Heorhi Valakhanovich
Quoted 20 lines · On Tue, 19 Nov 2013 08:46:27 -0500 Peter Hurley <[email protected]>…
Would you please test the patch below and confirm the fix?
--->%---
Subject: [PATCH] tty: Reset hupped state on openA common security idiom is to hangup the current tty (via
vhangup()) after forking but before execing a root shell. This hangs up any existing opens which other processes may have and ensures subsequent opens have the necessary permissions to open the root shell tty/pty.Reset the
TTY_HUPPEDstate after the driver has successfully returned the opened tty (perform the reset while the tty is locked to avoid racing with concurrent hangups).Reported-by Heorhi Valakhanovich <[email protected]>Signed-off-by Peter Hurley <[email protected]>--- drivers/tty/tty_io.c | 1 + 1 file changed, 1 insertion(+)
Quoted 15 lines
drivers/tty/tty_io.c retry_open: · line 2092
Quoted 12 lines
drivers/tty/tty_io.c +1
-0@@ -2086,6 +2086,7 @@ retry_open: filp->f_op = &tty_fops; goto retry_open; } +clear_bit (TTY_HUPPED , &tty->flags);tty_unlock (tty);It looks like this patch works. It solves my problem. Thanks. Will wait for such fix in mainline.
I'll queue this up after 3.13-rc1 is out.
It should be backported to 3.12, and any other kernels?
thanks,
greg k-h
Quoted 1 line · Greg KH
It should be backported to 3.12, and any other kernels?
Greg,
This patch should apply cleanly to 3.12.
The first commit to rely on the correct TTY_HUPPED state was commit 36697529b5bbe36911e39a6309e7a7c9250d280a,
'tty: Replace ldisc locking with ldisc_sem'
which was introduced in the 3.12 cycle.
Regards,
Peter Hurley
PS - Did you receive 'n_tty: Fix echo overrun tail computation'? I saw it didn't make 3.12.1.
Greg KH
maintainerQuoted 12 lines · Peter Hurley
Quoted 1 line · Greg KH
It should be backported to 3.12, and any other kernels?
Greg,
This patch should apply cleanly to 3.12.
The first commit to rely on the correct
TTY_HUPPEDstate was commit36697529b5bbe36911e39a6309e7a7c9250d280a,
'tty: Replace ldisc locking withldisc_sem'
which was introduced in the 3.12 cycle.
Quoted 5 lines
Regards,
Peter HurleyPS - Did you receive '
n_tty: Fix echo overrun tail computation'? I saw it didn't make 3.12.1.
Yes, I got it, I can't apply anything to my trees until 3.13-rc1 is out, and because it's not in Linus's tree yet, I can't apply it to a stable tree. So give us a few weeks, don't worry, it's not lost.
greg k-h
Quoted 9 lines
I doubt this is caused by a race condition; the first hangup would do most of the destruction regardless, and a second hangup can't really race with the first because of the
tty_lock()held for most of the hangup.In any event, it's worth discovering what state a subsequent hangup can effect that the first hangup left incomplete. I'll look into it.
Regards,
Peter Hurley
disassociate_ctty races with tty_hangup.
tty->pgrp is only protected by ctrl_lock
See no_tty and the FIXME note. Sorry the FIXME wasn't clearer.
Alan