linux-kernel - Scheduling issue with signal handling

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-next>] [day] [month] [year] [list]

Message-ID: <87wsju88b1.fsf@denkblock.local>
Date:	Thu, 10 Jul 2008 10:14:42 +0200
From:	Elias Oltmanns <eo@...ensachen.de>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	linux-kernel@...r.kernel.org
Subject: Scheduling issue with signal handling

Hi there,

in another thread [1] we've discussed something which, after some
testing, I now believe to be a problem related to scheduling /
preemption.

Here is the problem: If there is heavy disk I/O in the background,
signals sent to an I/O related process interactively by pressing Ctrl+Z
or Ctrl+C are sometimes processed quite sluggishly. I can pretty
reliably reproduce this using a test case provided by the original
reporter [1] (on a uniprocessor if that's of any consequence). The
problem has been verified to exist at least since 2.6.19 but it's become
much easier to observe and thus attracted attention since 2.6.25 because
pressing Ctrl+Z or Ctrl+C is now acknowledged by printing ^Z or ^C to
the terminal, respectively. As a result, the user gets slightly
irritated and possibly impatient when pressing Ctrl+Z repeatedly or just
holding down these keys generates a string like
^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z
but the shell prompt doesn't appear for up to a few seconds.

By sprinkling some printk()s all over the place, I've managed to
establish the following sequence of events taking place in the event of
delayed signal handling as described above:
The first Ctrl+Z event enqueues a SIGTSTP signal which eventually
results in a call to kick_process(). For some reason though, the signal
isn't handled straight away but remains on the queue for some time.
Consequently, subsequent Ctrl+Z events result in echoing another ^Z to
the terminal but everything related to sending a signal is skipped (and
rightly so) because the kernel detects that a SIGTSTP is still pending.
Eventually, get_signal_to_deliver() dequeues the SIGTSTP signal and the
shell propt appears.

My question is this: Even under high disk I/O pressure, the threads
dealing with I/O to the terminal evidently still get their turn as
indicated by the sequence of ^Z appearing on screen. Why is it then,
that the threads which are meant to process the SIGTSTP or SIGINT signals
aren't scheduled for some seconds and is there a way to change this?

Please let me know if there is anything I can try to investigate this
any further or if you need further information.

Thanks in advance,

Elias

[1] http://lkml.org/lkml/2008/6/28/50
--
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/