On Fri, 2019-12-06 at 15:21 +0100, Daniel Wagner wrote:
> In case the kernel configuration is UP is, the migrate_disable member
> in task_struct is missing.
>
> linux/lib/smp_processor_id.c: In function ‘check_preemption_disabled’:
> linux/lib/smp_processor_id.c:26:13: error: ‘struct task_struct’ has no
> member named ‘migrate_disable’
> 26 | if (current->migrate_disable)
> | ^~
>
> Fixes: 425c5b38779a ("sched: Lazy migrate_disable processing")
> Cc: Scott Wood <swood@xxxxxxxxxx>
> Cc: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx>
> Signed-off-by: Daniel Wagner <dwagner@xxxxxxx>
> ---
> lib/smp_processor_id.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/lib/smp_processor_id.c b/lib/smp_processor_id.c
> index 5f2618d346c4..a914f73e3652 100644
> --- a/lib/smp_processor_id.c
> +++ b/lib/smp_processor_id.c
> @@ -23,8 +23,10 @@ unsigned int check_preemption_disabled(const char
> *what1, const char *what2)
> * Kernel threads bound to a single CPU can safely use
> * smp_processor_id():
> */
> +#if defined(CONFIG_SMP) && defined(CONFIG_PREEMPT_RT_BASE)
> if (current->migrate_disable)
> goto out;
> +#endif
Won't this give false positives on UP with CONFIG_PREEMPT_RT_BASE and
CONFIG_DEBUG_PREEMPT? If we have CONFIG_SCHED_DEBUG then we can still check
migrate_disable. Without that, we don't have enough information to tell
whether it's safe to do smp_processor_id() and would have to skip
check_preemption_disabled() entirely.
-Scott
