RE: [PATCH] [SCSI] mpt2sas : Fix unsafe using smp_processor_id() in preemptible

["Moore, Eric" <Eric.Moore@xxxxxxx>]

 Jan Schmidt suggested using raw_smp_processor_id()  back in February, see this: http://marc.info/?t=132974687100003&r=1&w=2

Alex Shi recently suggested using preempt_disable() and preempt_enable() to solve the same issue, see this: http://marc.info/?t=133274303900003&r=1&w=2

I believe the stack traces are there in both email discussion, they occur when CONFIG_DEBUG_PREEMPT is enabled.

I would rather go with the solution giving the best performance.   James Bottomley is there on the discussion with  Jan Schmidt, he suggested using get_cpu() and put_cpu().

Eric
________________________________________
From: Matthew Wilcox [matthew@xxxxxx]
Sent: Tuesday, April 17, 2012 9:14 PM
To: Nandigama, Nagalakshmi
Cc: stable@xxxxxxxxxxxxxxx; linux-scsi@xxxxxxxxxxxxxxx; Prakash, Sathya; Moore, Eric; jejb@xxxxxxxxxx
Subject: Re: [PATCH] [SCSI] mpt2sas : Fix unsafe using smp_processor_id()       in preemptible

On Tue, Apr 17, 2012 at 11:25:04AM +0530, nagalakshmi.nandigama@xxxxxxx wrote:
> When CONFIG_DEBUG_PREEMPT is enabled, bug is observed in the smp_processor_id().
> This is because smp_processor_id() is not called in preempt safe condition.
>
> To fix this issue, use raw_smp_processor_id instead of smp_processor_id.

Just so we're clear, "fix this issue" really means "paper over the warning".

 * NOTE: raw_smp_processor_id() is for internal use only
 * (smp_processor_id() is the preferred variant), but in rare
 * instances it might also be used to turn off false positives
 * (i.e. smp_processor_id() use that the debugging code reports but
 * which use for some reason is legal). Don't use this to hack around
 * the warning message, as your code might not work under PREEMPT.

As far as I can tell, it's called under a lock already so should be
non-preemptable ... can you share the backtrace you get?

> Signed-off-by: Nagalakshmi Nandigama <nagalakshmi.nandigama@xxxxxxx>
> CC: stable@xxxxxxxxxxxxxxx
> ---
>
> diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c b/drivers/scsi/mpt2sas/mpt2sas_base.c
> index 272fab7..b010be0 100644
> --- a/drivers/scsi/mpt2sas/mpt2sas_base.c
> +++ b/drivers/scsi/mpt2sas/mpt2sas_base.c
> @@ -1792,7 +1792,7 @@ static inline void _base_writeq(__u64 b, volatile void __iomem *addr,
>  static inline u8
>  _base_get_msix_index(struct MPT2SAS_ADAPTER *ioc)
>  {
> -     return ioc->cpu_msix_table[smp_processor_id()];
> +     return ioc->cpu_msix_table[raw_smp_processor_id()];
>  }
>
>  /**
> --
> 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

--
Matthew Wilcox                          Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
--
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