Olof,
On Sun, Jun 24, 2012 at 4:54 PM, Olof Johansson <o...@lixom.net> wrote: > I'm not sure this is safe to do. The lock is dropped for the prepare > side, but in that case we can be sure that the above code can't come > in and unprepare at the same time since there is per definition a > request on the queue at that time. I spent a bunch of time staring at the code and I'm pretty sure that there's no race and that the code is safe (if not super obvious). Specifically there should be only one instance of spi_pump_messages() running at a time per master. That's because it's a kthread work function. ...so we can't possibly get a prepare in the middle of the unprepare when prepare is called because the only caller to prepare/unprepare is spi_pump_messages(). I can't comment on whether it's better to do something like add a workqueue (which might be more obvious / less fragile) or just to add a comment. I will let others comment on that. :) -Doug ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general