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: <alpine.LFD.2.00.1002261241100.4245@localhost.localdomain>
Date:	Fri, 26 Feb 2010 12:55:57 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Rafał Miłecki <zajec5@...il.com>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	DRI <dri-devel@...ts.sourceforge.net>
Subject: Re: [PATCH][RFC] time: add wait_interruptible_timeout macro to sleep
 (w. timeout) until wake_up

On Fri, 26 Feb 2010, Rafał Miłecki wrote:

> Forwarding to ppl I could often notice in git log time.h

And how is this related to time.h ?
 
> 
> ---------- Wiadomość przekazana dalej ----------
> From: Rafał Miłecki <zajec5@...il.com>
> Date: 21 lutego 2010 15:10
> Subject: [PATCH][RFC] time: add wait_interruptible_timeout macro to
> sleep (w. timeout) until wake_up
> To: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
> dri-devel@...ts.sourceforge.net
> CC: Rafał Miłecki <zajec5@...il.com>
> 
> 
> Signed-off-by: Rafał Miłecki <zajec5@...il.com>
> ---
> We try to implement some PM in radeon KMS and we need to sync with VLBANK for
> reclocking engine/memory. The easiest and cleanest way seems to be sleeping in
> timer handler just before reclocking. Then our IRQ handler calls wake_up and we

Sleeping in the timer handler ? In which context runs this timer handler ?

> continue reclocking.
> 
> As you see our sleeping is condition-less, we just wait for waking up queue.

Your sleep is not condition-less at all. See below.
 
> We hope this waking will happen from IRQ handler, but for less-happy case we
> also use some timeout (this will probably cause some single corruption, but
> we can live with it).
> 
> Following macro is soemthing that seems to work fine for us, but instead
> introducing this to radeon KMS only, I'd like to propose adding this to whole
> wait.h. Do you this it's something we should place there? Can someone take this
> patch for me? Or maybe you find this rather useless and we should keep this
> marco locally?

You better delete it right away. It's broken and racy. 

If the interrupt happens right before you enqueue to the wake queue,
then you miss it. The old interruptible_sleep_on_timeout() was
replaced by the event wait functions which have a condition exaclty to
avoid that race.

And you have a condition: Did an interrupt happen?

Thanks,

	tglx

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ