On Wed, Apr 8, 2015 at 11:17 AM, James Bottomley
<james.bottom...@hansenpartnership.com> 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 <mi...@elte.hu>
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.
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
