On Sat, Aug 27, 2011 at 09:33:16PM -0700, Roland Dreier wrote: > > Looking at the surrounding code I'd rather fix the reenetrance problem > > by using workqueues properly, that is: > > > > - remove dev->qf_cmd_list and dev->dev_qf_count entirely > > - instead add a work_struct to struct se_cmd > > - use that to queue the cmd directly onto a workqueue > > Fair enough, here's the splice-only fix. As I said, I think this is > definitely for 3.1 since this fixes crashes in practice for me. > > I agree that the queue full stuff needs further fixing, eg I noticed > the code: > > if (atomic_read(&cmd->se_dev->dev_qf_count) != 0) > schedule_work(&cmd->se_dev->qf_work_queue); > > which even with cargo-cult sprinkling of smp_mb__after_atomic_inc() > obviously can't avoid the race where dev_qf_count gets incremented > from 0 to 1 just after the if statement tests it. Yes. Using the workqueue API as intended to queue up individual objects will fi all that. -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
