Re: [PATCH 2.6-git] SPI core refresh

[Mark Underwood <basicmark@yahoo.com>]

--- vitalhome@rbcmail.ru wrote:

> Mark,
> 
> > > >I still do not see why you are stating this.  Why do you say this?
> > > > 
> > > >
> > > Due to possible priority inversion problems in David's core.
> > 
> > Which you still haven't proven, in fact you now seem to be changing your mind and saying 
> > that
> > there might be a problem if an adapter driver was implemented badly although I still 
> > don't see how
> > this could happen (the priority inversion I mean not the badly implemented driver ;).
> 
> Truly admiring your deep understanding of the real-time technology, I should remind you 
> that within the real-time conditions almost each event may happen and may not happen, for 
> instance, two calls from different context to the same funtion may happen at the same or 
> almost the same time, and may not happen that way. Therefore I used the word "possible". 
> Hope I clarified that a bit for you.
> 
> Please also see my previous emails for the explanation of how priority inversion can 
> happen. This is not gonna be a rare case, BTW.

Vitaly, 
 
First, please can you not change the CC list in the midle of a thread. 
 
Second, I studied real-time OS's at university and even started to write my  own RTOS so I do know
the basic's of real-time technology. My problem wasn't understanding what you meant, just which
part of the code you where referring to :(. 
 
OK, looking through the code after a cup of coffe I can see the problem you are pointing out,
thank you :), for some reason I thought that that code was protected by a spin_lock :/. 
 
How to fix this? 
 
David, how would you feel about adding a NOT_DMAABLE flag in the spi_message structure? This
helper routine could then use this thus solving the one buffer to many callers problem (well
moving into the adapter driver, but as that serialise's transfers anyway I think this would remove
the priority inversion problem, Vitaly?) 
 
The other solution is to do a kmalloc for each caller (would could try to be smart and only do
that if the buffer is being used). 
 
Let me know, if noone else is interested in fixing this then I'll do it and send a patch. 
 
Mark

> 
> Vitaly
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 



		
___________________________________________________________ 
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com