On Wed, 2015-04-08 at 11:26 -0700, Andy Lutomirski wrote: > On Wed, Apr 8, 2015 at 11:17 AM, James Bottomley > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, 2015-04-08 at 10:59 -0700, Andy Lutomirski wrote: > >> This is a regression somewhere between 3.15 and 3.19.3. Let me know > >> if more diagnostics would be helpful. > > > > It's not a regression. Likely someone turned on additional warnings. > > So the problem is that the warning is incorrect: the use of > > smp_processor_id() isn't pre-empt unsafe. The driver is using it as a > > hint as to which queue it should be using, so it doesn't matter if > > pre-empt schedules the driver thread away from that CPU. > > The warning goes a long way back. For example, this change from 2005 > seems to have refactored it: > > commit 39c715b71740c4a78ba4769fb54826929bac03cb > Author: Ingo Molnar <mingo@xxxxxxx> > Date: Tue Jun 21 17:14:34 2005 -0700 > > [PATCH] smp_processor_id() cleanup > > > > > > I presume the warning is because whoever added it thinks that you should > > be using the get/put cpu API, which would be wholly inappropriate here > > because we don't want to bind the thread, we just want a hint about the > > queue. > > Would raw_smp_processor_id be a good compromise? I'm testing a patch > right now and, if it works, I can send it and cc stable. Anything that doesn't dump the warning would be fine. Of course, the current queue selection smp_processor_id() % instance->msix_vectors Is a bit suboptimal anyway, so perhaps avago would like to fix it more elegantly. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
