linux-kernel - Re: [PATCH RFC] hwspinlock: Don't take software spinlock before hwspinlock

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]

Date:	Sat, 16 May 2015 12:03:19 +0300
From:	Ohad Ben-Cohen <ohad@...ery.com>
To:	Lina Iyer <lina.iyer@...aro.org>
Cc:	"Anna, Suman" <s-anna@...com>,
	Bjorn Andersson <Bjorn.Andersson@...ymobile.com>,
	Andy Gross <agross@...eaurora.org>,
	"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Kumar Gala <galak@...eaurora.org>,
	Jeffrey Hugo <jhugo@...eaurora.org>
Subject: Re: [PATCH RFC] hwspinlock: Don't take software spinlock before hwspinlock

On Mon, May 11, 2015 at 5:46 PM, Lina Iyer <lina.iyer@...aro.org> wrote:
> On Sat, May 09 2015 at 03:25 -0600, Ohad Ben-Cohen wrote:
>> On Fri, May 1, 2015 at 8:07 PM, Lina Iyer <lina.iyer@...aro.org> wrote:
>> Let's discuss whether we really want to expose this functionality
>> under the same hwspinlock API or not.
>>
>> In this new mode, unlike previously, users will now be able to sleep
>> after taking the lock, and others trying to take the lock might poll
>> the hardware for a long period of time without the ability to sleep
>> while waiting for the lock. It almost sounds like you were looking for
>> some hwmutex functionality.
>
> I agree, that it opens up a possiblity that user may sleep after holding
> a hw spinlock.  But really, why should it prevents us from using it as a
> hw mutex, if the need is legitimate?

If we want hw mutex functionality, let's discuss how to expose it.
Exposing it using the existing hw spinlock API might not be ideal, as
users might get confused.

Additionally, there are hardware IP locking blocks out there which
encourage users to sleep while waiting for a lock, by providing
interrupt functionality to wake them up when the lock is freed. So if
we choose to add a hw mutex API it might be used by others in the
future too (though this reason alone is not why we would choose to add
it now of course).

API discussions aside, what do you want to happen in your scenario
while the lock is taken? are you OK with other users spinning on the
lock waiting for it to be released? IIUC that might mean processors
spinning for a non-negligible period of time?

Thanks,
Ohad.
--
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/