linux-kernel - Re: ext3 IO latency measurements (was: Linux 2.6.29)

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 26 Mar 2009 13:44:53 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Theodore Tso <tytso@....edu>, Jan Kara <jack@...e.cz>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Arjan van de Ven <arjan@...radead.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Nick Piggin <npiggin@...e.de>,
	Jens Axboe <jens.axboe@...cle.com>,
	David Rees <drees76@...il.com>, Jesper Krogh <jesper@...gh.cc>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Roland McGrath <roland@...hat.com>
Subject: Re: ext3 IO latency measurements (was: Linux 2.6.29)


* Theodore Tso <tytso@....edu> wrote:

> >   while :; do
> >     date
> >     make mrproper      2>/dev/null >/dev/null
> >     make defconfig     2>/dev/null >/dev/null
> >     make -j32 bzImage  2>/dev/null >/dev/null
> >   done &
>          ^^
> 
> So there would have been nothing to ^C; I assume you were running 
> this with a variant that didn't have the ampersand, which would 
> have run the whole shell pipeline in a detached background 
> process?

That was just the example - the real script did not go into the 
background so it was Ctrl-C-able. I've attached it.

> In any case, the workaround for this is to ^Z the script, and then 
> "kill %" it.
> 
> I'm pretty sure this is actually a bash problem.  When you send a 
> Ctrl-C, it sends a SIGINT to all of the members of the tty's 
> foreground process group.  Under some circumstances, bash sets the 
> signal handler for SIGINT to be SIGIGN.  I haven't looked at this 
> super closely (it would require diving into the bash sources), but 
> you can see it if you attach an strace to the bash shell driving a 
> script such as
> 
> #!/bin/bash
> 
> while /bin/true; do
>       date
>       sleep 60
> done &
> 
> If you do a "ps axo pid,ppid,pgrp,args", you'll see that the bash 
> and the sleep 60 have the same process group.  If you emulate 
> hitting ^C by sending a SIGINT to pid of the shell, you'll see 
> that it ignores it.  Sleep also seems to be ignoring the SIGINT 
> when run in the background; but it does honor SIGINT in the 
> foreground --- I didn't have time to dig into that.
> 
> In any case, bash appears to SIGIGN the INT signal if there is a 
> child process running, and only takes the ^C if bash itself is 
> actually "running" the shell script.  For example, if you run the 
> command "date;sleep 10;date;sleep 10;date", the ^C only interrupts 
> the sleep command.  It doesn't stop the series of commands which 
> bash is running.

It happens all the time - and it does look like a Bash bug. I 
reported it to the Bash maintainer one or two years ago. He said
he does not see it as he's using MacOS X. Can dig into archives if 
needed.

	Ingo

View attachment "compile-test" of type "text/plain" (322 bytes)