Bug 490876 - init hang and zombie invasion due to tty block
init hang and zombie invasion due to tty block
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.3
All Linux
low Severity medium
: rc
: ---
Assigned To: Aristeu Rozanski
Red Hat Kernel QE team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-18 08:21 EDT by Konstantin Khorenko
Modified: 2017-02-28 07:59 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-06-02 09:16:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch to prevent init hang and zombie invasion (4.79 KB, patch)
2009-03-18 08:21 EDT, Konstantin Khorenko
no flags Details | Diff

  None (edit)
Description Konstantin Khorenko 2009-03-18 08:21:14 EDT
Created attachment 335690 [details]
patch to prevent init hang and zombie invasion

OpenVZ linux kernel team reports about the init's ability to hang in zombie state.

kernel 2.6.18-128.1.1

testcase:
* rhel5
* at virtual terminal:
* ( sleep 3 ; init u ) & yes
* press scroll-lock
* wait 3 seconds
  
Actual results:
# cat /proc/29595/status
Name:   init
State:  Z (zombie)
...

# ps -p 29595
  PID TTY          TIME CMD
29595 ?        00:00:00 init <defunct>

Expected results:
no hang in zombie state

Additional info:
This is fixed by mainstream commit 9c1729db3 in v2.6.23 by Alan Cox <alan@redhat.com>

original comment:
Prevent an O_NDELAY writer from blocking when a tty write is blocked by the tty atomic writer mutex

Without this a tty write could block if a previous blocking tty write was
in progress on the same tty and blocked by a line discipline or hardware
event.  Originally found and reported by Dave Johnson.

Signed-off-by: Alan Cox <alan@redhat.com>
Acked-by: Dave Johnson <djohnson+linux-kernel@sw.starentnetworks.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Backported patch attached.
Please, apply.
Comment 1 Mauro Carvalho Chehab 2009-03-30 12:35:55 EDT
I tried to reprocude it here on x86_64 without success. Could you please provide more details about your tests?
Comment 2 Konstantin Khorenko 2009-06-04 09:56:30 EDT
Hi. Sorry for being silent for so long.
i rechecked the reproducer and it again worked for me.

i did exactly that steps that are written in comment 1:
1) get a RHEL5 node (my kernel was 2.6.18-128.1.1).
   i mean a hardware node, not a virtual box, etc.
2) go to text mode (init 3). Login.
3) execute following command:
   # ( sleep 3 ; init u ) & yes
4) Right after you pressed enter executing the command above, press "Scroll Lock" and do not release it for 5 seconds.
5) Then go to another virtual text console and check init processes via ps. i've got:
[root@ts76 ~]# ps axf |grep init
    1 ?        Ss     0:00 init [3]
 3691 pts/0    S+     0:00          \_ grep init
 3640 ?        Z      0:00 [init] <defunct>

Please, let me know if it helps to trigger the issue or not.

Thank you.
Comment 6 RHEL Product and Program Management 2014-03-07 07:46:32 EST
This bug/component is not included in scope for RHEL-5.11.0 which is the last RHEL5 minor release. This Bugzilla will soon be CLOSED as WONTFIX (at the end of RHEL5.11 development phase (Apr 22, 2014)). Please contact your account manager or support representative in case you need to escalate this bug.
Comment 7 RHEL Product and Program Management 2014-06-02 09:16:22 EDT
Thank you for submitting this request for inclusion in Red Hat Enterprise Linux 5. We've carefully evaluated the request, but are unable to include it in RHEL5 stream. If the issue is critical for your business, please provide additional business justification through the appropriate support channels (https://access.redhat.com/site/support).
Comment 8 Konstantin Khorenko 2017-02-28 07:59:06 EST
needinfo?(khorenko@sw.ru)

i believe the issue can be safely buried.

Note You need to log in before you can comment on or make changes to this bug.