| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <515ADC96.7090908@synopsys.com> Date: Tue, 2 Apr 2013 18:56:46 +0530 From: Vineet Gupta <Vineet.Gupta1@...opsys.com> To: Peter Hurley <peter@...leysoftware.com> CC: lkml <linux-kernel@...r.kernel.org>, <linux-serial@...r.kernel.org>, "Ingo Molnar" <mingo@...nel.org>, Peter Zijlstra <peterz@...radead.org>, Jiri Slaby <jslaby@...e.cz> Subject: Re: n_tty_write() going into schedule but NOT coming out On 04/01/2013 08:40 PM, Peter Hurley wrote: > On Mon, 2013-04-01 at 19:27 +0530, Vineet Gupta wrote: >> Hi, >> >> Any thoughts: I observe the same issue even with CONFIG_PREEMPT and >> CONFIG_PREEMPT_COUNT >> >> -Vineet >> >> On 03/30/2013 06:05 PM, Vineet Gupta wrote: >>> Hi, >>> >>> I've been stress testing ARC Linux 3.8 (same happens for 3.9-rc3 as well). The >>> setup has 3 telnet sessions, each running find . -name "*" in a loop. >>> The platform is a FPGA @ 80 MHz, running a single core ARC700 so kernel .config >>> has !SMP and PREEMPT_NONE. >>> >>> After ~10 mins of run, I see that one of the telnet session gets stuck (and later >>> the 2nd one as well), while system is still alive, 3rd telnet is running find merrily. >>> >>> [ARCLinux]$ ps >>> .... >>> 7 root 0:00 inetd >>> 62 root 0:00 -/bin/sh >>> 64 root 1:34 telnetd -i -l /bin/sh >>> 65 root 0:00 /bin/sh >>> 75 root 1:47 telnetd -i -l /bin/sh >>> 76 root 0:00 /bin/sh >>> 79 root 0:53 telnetd -i -l /bin/sh >>> 80 root 0:00 /bin/sh >>> 281 root 0:00 find / -name * <--- stuck >>> 358 root 0:03 find / -name * <--- stuck >>> 377 root 0:00 find / -name * >>> 378 root 0:00 ps >>> >>> Hung find task is sitting in the schedule() call in n_tty_write() >>> >>> [ARCLinux]$ cat /proc/281/stack >>> [<8065945e>] n_tty_write+0x23a/0x424 >>> [<80655cd4>] tty_write+0x1ac/0x2d4 >>> [<805976ba>] vfs_write+0x92/0x110 >>> [<80597816>] sys_write+0x4e/0x88 >>> [<8050e780>] ret_from_system_call+0x0/0x4 > Likely the writer is stuck because the receive buffer is full and the > reader is hung. What are the respective shells and telnetd doing? I've added a couple of printk's around that schedule() call and in one pathetic case all 3 find tasks never return: S 0 58 47 1768 488 0:0 00:00 00:03:50 telnetd -i -l /bin/sh S 0 59 58 1768 520 pts0 00:00 00:00:01 /bin/sh S 0 61 47 1768 488 0:0 00:00 00:03:45 telnetd -i -l /bin/sh S 0 62 61 1768 528 pts1 00:00 00:00:01 /bin/sh S 0 65 47 1768 488 0:0 00:00 00:03:23 telnetd -i -l /bin/sh S 0 66 65 1776 528 pts2 00:00 00:00:01 /bin/sh S 0 833 66 1840 488 pts2 00:58 00:00:01 find / -name * <-- S 0 871 62 1832 480 pts1 01:01 00:00:00 find / -name * <-- S 0 881 59 1840 488 pts0 01:01 00:00:02 find / -name * <-- ---> 833 8e21c580 <--- 833 8e21c580 ---> 833 8e21c580 ---> 871 8e21c840 <--- 871 8e21c840 ---> 871 8e21c840 ---> 881 8e21c2c0 <--- 881 8e21c2c0 ---> 881 8e21c2c0 I don't undersand how the receive buffer full/empty is coming into play - that schedule() call is not a wait queue or something, it's an unconditional yield, expecting sched to unconditionally return at some point - unless ofcourse - that itself relies on some buffer r/w ISR semantics triggering an ISR, which makes the task runnable again causing schdule() to return. -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists