On 09/08/2023 07:03, Nilesh Javali wrote:
Furthermore, for the instance where the calltrace is reported, above,
there is no mention of why it is indeed safe to use
raw_smp_processor_id() and why the warning from smp_processor_id() can
be ignored.
Thanks for the review.
This patch aims to silent the warning message in case CONFIG_DEBUG_PREEMPT is turned on by
any user reporting an issue.
For qla2xxx driver it is not critical to have accurate CPU ID which would momentarily cause
performance hit for the thread that pre-empted.
I doubt that the driver needs to check the current CPU so often, if at
all. But I don't know the driver well, so can't say more.
Apart from that, according to description of queue_work():
"We queue the work to the CPU on which it was submitted, but if the CPU
dies it can be processed by another CPU."
So isn't something like
queue_work_on(raw_smp_processor_id(), ha->wq, &qpair->q_work) same as
queue_work(ha->wq, &qpair->q_work)?
I see that queue_work() already has the raw_smp_processor_id() call.
Thanks,
John