[Intel-wired-lan] [PATCH v3 10/16] fm10k: prevent race condition of __FM10K_SERVICE_SCHED

Singh, Krishneil K krishneil.k.singh at intel.com
Mon Sep 18 17:15:34 UTC 2017



> -----Original Message-----
> From: Intel-wired-lan [mailto:intel-wired-lan-bounces at osuosl.org] On Behalf
> Of Jacob Keller
> Sent: Monday, July 10, 2017 1:23 PM
> To: jtkirhse at osuosl.org; Intel Wired LAN <intel-wired-lan at lists.osuosl.org>
> Cc: jekeller at osuosl.org
> Subject: [Intel-wired-lan] [PATCH v3 10/16] fm10k: prevent race condition of
> __FM10K_SERVICE_SCHED
> 
> Although very unlikely, it is possible that cancel_work_sync() may stop
> the service_task before it actually started. In this case, the
> __FM10K_SERVICE_SCHED bit will never be cleared. This results in the
> service task being unable to reschedule in the future. Add a helper
> function which sets the service disable bit, waits for the service task
> to stop and clears the schedule bit, thus avoiding the race condition.
> We know the schedule bit is safe to clear because the cancel_work_sync()
> guarantees the service task is not running.
> 
> Add a helper function also to restart the service task, for symmetry.
> This is not strictly needed but helps the mental model of how to stop
> and start the service task.
> 
> This race could only happen in fm10k_suspend/fm10k_resume as this is the
> only place where the service task is actually restarted. Thus,
> suspend/resume testing would be ideal. However, note that the chance of
> this happening is very slim as the service event is scheduled for
> immediate execution, and you would have to trigger a suspend at almost
> the exact same time as the service task was scheduled.
> 
> Signed-off-by: Jacob Keller <jacob.e.keller at intel.com>
> ---

Tested-by: Krishneil Singh  <krishneil.k.singh at intel.com>



More information about the Intel-wired-lan mailing list