linux-kernel - Re: [PATCH 01/11] MFD: DA9052 MFD core module v2

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:	Fri, 22 Jul 2011 09:59:39 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Shawn Guo <shawn.guo@...escale.com>,
	ashishj3 <ashish.jangam@...tcummins.com>,
	Dajun <dajun.chen@...semi.com>, sameo@...nedhand.com,
	linaro-dev@...ts.linaro.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 01/11] MFD: DA9052 MFD core module v2

On Thu, Jul 21, 2011 at 10:40:23PM +0200, Arnd Bergmann wrote:
> On Thursday 21 July 2011 16:47:48 Mark Brown wrote:

> > Although the bigger problem is why are these interruptible?  That's
> > very unusual.

> Well, the default should really be to use _interruptible or at least
> _killable with the appropriate error handling, and only use noninterruptible
> locks  in cases where that's not possible.

> In the funtions that Shawn pointed out, there is an error return, so it would
> be possible to do that, but the callers would need to be audited carefully.

We went round this analysis already with the underlying I2C drivers
(which also end up needing to take mutexes and so on) - it really does
work out better to just make the I/O noninterruptible, the I/O is fast
enough to not really be worth interrupting and the handling for actual
I/O errors should normally be sufficiently different to that for user
initiated aborts that it just adds complication.

For example, if the user interrupts while we're in the middle of some
lengthy series of operations or wait what we really want to do is to
tear down the high level thing we're doing in an orderly fashion.  If
we allow the interrupt to be noticed as part of an I/O operation then
what we often end up doing is failing that and we then have to work out
why the I/O failed, if actually happened on a physical level and how we
deal with that.  Usually none of these paths will be well tested.

The overall result is that the system generally becomes more complicated
and less robust.
--
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/