Re: smp_processor_id warning in megasas driver on 3.19.3

[James Bottomley <James.Bottomley@HansenPartnership.com>]

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@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 <mingo@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.

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