linux-kernel - Re: [PATCH 3/3] omap: add hwspinlock device

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: <AANLkTi=G_OM806-10Z_objj30Tats_RM4oiP=xKWUOnR@mail.gmail.com>
Date:	Fri, 22 Oct 2010 13:16:06 +0200
From:	Ohad Ben-Cohen <ohad@...ery.com>
To:	"Kamoolkar, Mugdha" <mugdha@...com>
Cc:	Kevin Hilman <khilman@...prootsystems.com>,
	"Krishnamoorthy, Balaji T" <balajitk@...com>,
	"Kamat, Nishant" <nskamat@...com>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	Greg KH <greg@...ah.com>, Tony Lindgren <tony@...mide.com>,
	"Cousson, Benoit" <b-cousson@...com>,
	Grant Likely <grant.likely@...retlab.ca>,
	"Kanigeri, Hari" <h-kanigeri2@...com>,
	"Anna, Suman" <s-anna@...com>
Subject: Re: [PATCH 3/3] omap: add hwspinlock device

On Fri, Oct 22, 2010 at 11:59 AM, Kamoolkar, Mugdha <mugdha@...com> wrote:
>> From: Ohad Ben-Cohen [mailto:ohad@...ery.com]
>> I agree.
>>
>> But we seem to have this sort of problem anyway:
>>
...
> That is true. Perhaps we should consider adding a software
> implementation over HW spinlocks.

Yes, this is probably inevitable.

It would also be useful for the user space implementation of TI's
RingIO and FrameQueue protocols coming in Syslink 3.0, which will also
not be able to directly use the hwspinlock because of the same
reasons.

This layer would maintain the owner of each (virtual) lock in a
non-cacheable shared memory entry, together with the id of the
hwspinlock that would protect that 'owner' entry.

This way we no longer need to use predefined hwspinlocks (the id of
the hwspinlock is announced in the shared memory entry). So we can
ditch the _request_specific() API, and we can move to arch_initcall
(just to beat the current race with i2c-omap).

> We were anyway considering doing this,
> because the number of hw spinlocks available for our usage are not
> sufficient when we look at multi-channel use-cases.

Sure, this layer can provide any number of locks over a single
hwspinlock (with the obvious price of hwspinlock contention).
--
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/