linux-kernel - Re: [PATCH] x86_64: fix delayed signals

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]

Message-ID: <87lk088v7k.fsf@denkblock.local>
Date:	Fri, 11 Jul 2008 14:24:31 +0200
From:	Elias Oltmanns <eo@...ensachen.de>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Roland McGrath <roland@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Török Edwin <edwintorok@...il.com>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [PATCH] x86_64: fix delayed signals

Ingo Molnar <mingo@...e.hu> wrote:
> * Roland McGrath <roland@...hat.com> wrote:
>
>> On three of the several paths in entry_64.S that call 
>> do_notify_resume() on the way back to user mode, we fail to properly 
>> check again for newly-arrived work that requires another call to 
>> do_notify_resume() before going to user mode.  These paths set the 
>> mask to check only _TIF_NEED_RESCHED, but this is wrong.  The other 
>> paths that lead to do_notify_resume() do this correctly already, and 
>> entry_32.S does it correctly in all cases.
>
> nice find! Roland, is this related to the thread started by Elias 
> Oltmanns yesterday:
>
>     http://lkml.org/lkml/2008/7/10/57
>
> which is also related to the thread started by Edwin Török:
>
>     http://lkml.org/lkml/2008/6/28/50
>
> ? The weight of complains seems to be on the 64-bit side, in those 
> threads 32-bit systems seem to be implicated as well by latencytop. 
> Perhaps the 64-bit delays are related to the bug you fix and we could 
> chalk up the 32-bit delays to IO delays?

Since I'm using a 32-bit machine, this patch isn't going to solve my
particular problem. Still, I'm glad to hear that someone is looking at
the assembly bits related to signal handling right now because that's
precisely the part where I gave up to figure out for myself how signal
handling works in the kernel.

As for delayed signal handling on 32-bit platforms due to heavy disk
I/O, I'm still reluctant to accept that signals should be delayed that
much even though everything else that is not related to disk I/O works
perfectly well. Now that I've seen some documentation for ftrace, I'll
give it a go and try produce some helpful data. However, I'm rather busy
right now and may not be able to do so before next week.

Regards,

Elias
--
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/