linux-kernel - Re: [RFC 1/6] mailbox: add core framework

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: <1765844.1kjKsO2Rzo@wuerfel>
Date:	Tue, 11 Feb 2014 09:35:01 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Courtney Cavin <courtney.cavin@...ymobile.com>
Cc:	Rob Herring <robherring2@...il.com>,
	Josh Cartwright <joshc@...eaurora.org>,
	"s-anna@...com" <s-anna@...com>,
	Rob Herring <rob.herring@...xeda.com>,
	"Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
	Mark Langsdorf <mark.langsdorf@...xeda.com>,
	Tony Lindgren <tony@...mide.com>,
	"omar.ramirez@...itl.com" <omar.ramirez@...itl.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Rob Landley <rob@...dley.net>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC 1/6] mailbox: add core framework

On Monday 10 February 2014 16:23:48 Courtney Cavin wrote:

> While I'm not sure the dislike of notifiers entirely justifies not using
> them here, where they seem to make sense, I can understand that they
> might not fully implement what we need to expose.

I think we need to look at a few more examples of things that people
want to with the framework to come up with a good interface. It's
possible that we end up with multiple alternative notification
methods, but it would be good to come up with one that works well
for everyone.

> Regarding handlers running in IRQ context: currently the API is designed
> to do just that.  From the use-cases I've found, most message handlers
> simply queue something to happen at a later point.  This is logical, as
> the callback will be async, so you'll need to swap contexts or add locks
> in your consumer anyway.

Right. You may also have some handlers that need to run with extreme
latency constraints, so we need at least the option of getting the
callback from hardirq context, or possibly from softirq/tasklet
as in the dmaengine case.

> The dma engine is large and confused, so I'm not sure entirely which
> part you are refering to.  I've looked at having async completion going
> both ways, but what I see every time is code complication in both the
> adapter and in the consumers in the simple use-case.  It doesn't really
> make sense to make an API which makes things so generic that it becomes
> hard to use.  What I tried to follow here when designing the API was
> what I saw in the actual implementations, not what was future-proof:
> 	- Message receive callbacks may be called from IRQ context
> 	- Message send implementations may sleep

I can imagine cases where you want to send messages from softirq
context, or from the same context in which you received the incoming
mail, so it would be good to have the API flexible enough to deal
with that. As a first step, always allowing send to sleep seems
fine. Alternatively, we could have a 'sync' flag in the send
API, to choose between "arrange this message to be sent out as
soon as possible, but don't sleep" and "send this message and
make sure it has arrived at the other end" as you do now.

> What I can do is try to alleviate implementation efforts of future
> requirements--as honestly, we can't really say exactly what they are--by
> turning the messages into structs themselves, so at a later point flags,
> ack callbacks, and rainbows can be added.  I can then stop using
> notifiers, and re-invent that functionality with a mbox_ prefix.

I don't think there is a point in reimplementing notifiers under a
different name. The question is rather how we want to deal with
the 'multiple listener' case. If this case is the exception rather
than the rule, I'd prefer making the callback API handle only
single listeners and adding higher-level abstractions for the
cases where we do need multiple listeners, but it really depends
on what people need.

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