Re: [spi-devel-general] [patch 2.6.15-rc5-mm2] SPI, priority inversion tweak

From: Vitaly Wool <vwool@ru.mvista.com>
To: David Brownell <david-b@pacbell.net>
Cc: Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org,
	spi-devel-general@lists.sourceforge.net
Subject: Re: [spi-devel-general] [patch 2.6.15-rc5-mm2] SPI, priority inversion tweak
Date: Wed, 14 Dec 2005 09:47:22 +0300	[thread overview]
Message-ID: <439FBFFA.2070804@ru.mvista.com> (raw)
In-Reply-To: <200512131028.49291.david-b@pacbell.net>

Hmm...

>-	down(&lock);
>+	/* ... unless someone else is using the pre-allocated buffer */
>+	if (down_trylock(&lock)) {
>+		local_buf = kmalloc(SPI_BUFSIZ, GFP_KERNEL);
>+		if (!local_buf)
>+			return -ENOMEM;
>+	} else
>+		local_buf = buf;
>+
>  
>
Okay, so suppose we have two controller drivers working in two threads 
and calling write_then_read in such a way that the one called later has 
to allocate a new buffer. Suppose also that both controller drivers are 
working in PIO mode. In this situation you have one redundant kmalloc 
and two redundant memcpy's, not speaking about overhead brought up by 
mutexes. Bad!
So I still can't say I'm accepting this approach.

Worth mentioning is that the approach I propose is free from this drawback.

Vitaly