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: <20070227122446.8c64f3e7.akpm@linux-foundation.org>
Date:	Tue, 27 Feb 2007 12:24:46 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Inaky Perez-Gonzalez <inaky@...ux.intel.com>
Cc:	hch@...radead.org, arjan@...radead.org, mingo@...hat.com,
	linux-kernel@...r.kernel.org
Subject: Re: [patch 0/2] semaphores: add down_interruptible_timeout() and
 asm-generic/semaphore.h

> On Mon, 26 Feb 2007 16:54:17 -0800 Inaky Perez-Gonzalez <inaky@...ux.intel.com> wrote:
> On Monday 26 February 2007 16:33, Christoph Hellwig wrote:
> > On Mon, Feb 26, 2007 at 04:13:38PM -0800, inaky@...ux.intel.com wrote:
> > > Introduce down_interruptible_timeout() using timers to make the waiter
> > > stop waiting by simulating a signal (see first patch for more
> > > details). As well introduce asm-generic/semaphore.h and make other
> > > architectures use it too.
> >
> > What do you want this for?  Do you really need a full counting semaphore
> > or do you actually want a mutex?
> 
> Yeah, I need semaphore. This is a hw register that says when the hw
> is ready to accept a new command. Code that wants to send commands has
> to down the semaphore and then send it. When hw is ready to get a new
> command, it sends and IRQ and the IRQ up()s the semaphore. 
> 
> Now, we don't want to hang on that down() forever if the hw spaces out.
> If we get a timeout, we can try recovery actions (like resetting it,
> for sake of being polite). 
>

This is a very common pattern - for example, shoving characters down a uart
or a parport.  Nobody else has needed to invent new locking infrastructure
to do such things and I'd prefer not to do so now.

Can you not do things more conventionally within that driver?  Use
waitqueues for sleeping with timeout, use a spinlock for serialisation
against the device registers.  There are squillions of examples in
drivers/*, surely.
-
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ