Which version/branches is this for ? Given the author, I'm assuming it is for the -rt branches and also for 4.12 .. but I'd like a confirmation of that.
Bruce On 2018-07-20 4:13 AM, [email protected] wrote:
From: Sebastian Andrzej Siewior <[email protected]> commit 97731753d44d5efcb95b994dc952c0e8195b3e96 upstream This patch reverts commit c7f26ccfb2c3 ("mm/vmstat.c: fix vmstat_update() preemption BUG"). Steven saw a "using smp_processor_id() in preemptible" message and added a preempt_disable() section around it to keep it quiet. This is not the right thing to do it does not fix the real problem. vmstat_update() is invoked by a kworker on a specific CPU. This worker it bound to this CPU. The name of the worker was "kworker/1:1" so it should have been a worker which was bound to CPU1. A worker which can run on any CPU would have a `u' before the first digit. smp_processor_id() can be used in a preempt-enabled region as long as the task is bound to a single CPU which is the case here. If it could run on an arbitrary CPU then this is the problem we have an should seek to resolve. Not only this smp_processor_id() must not be migrated to another CPU but also refresh_cpu_vm_stats() which might access wrong per-CPU variables. Not to mention that other code relies on the fact that such a worker runs on one specific CPU only. Therefore I revert that commit and we should look instead what broke the affinity mask of the kworker. Cc: Steven J. Hill <[email protected]> Cc: Tejun Heo <[email protected]> Cc: Andrew Morton <[email protected]> Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]> Backport this to fix following serious crash for preempt-rt kernel BUG: scheduling while atomic: kworker/3:1/91/0x00000002 Preemption disabled at: [<ffffffff8437c37d>] vmstat_update+0x2d/0xb0 CPU: 3 PID: 91 Comm: kworker/3:1 Not tainted 4.14.48-rt29-yocto-preempt-rt #1 Hardware name: Intel Corporation Broadwell Client platform/Basking Ridge, BIOS BDW-E2R1.86C.0118.R01.1503110618 03/11/2015 Workqueue: mm_percpu_wq vmstat_update Call Trace: dump_stack+0x4f/0x6b ? vmstat_update+0x2d/0xb0 __schedule_bug.cold.24+0x7d/0x9a __schedule+0x45a/0x6c0 ? task_blocks_on_rt_mutex+0x173/0x300 schedule+0x3d/0xd0 rt_spin_lock_slowlock_locked+0x118/0x2a0 rt_spin_lock_slowlock+0x48/0x60 rt_spin_lock+0x3f/0x50 queue_delayed_work_on+0x63/0x100 vmstat_update+0x6e/0xb0 process_one_work+0x1c3/0x430 worker_thread+0x32/0x440 kthread+0x127/0x140 ? process_one_work+0x430/0x430 ? kthread_create_on_node+0x40/0x40 ret_from_fork+0x35/0x40 Signed-off-by: He Zhe <[email protected]> --- mm/vmstat.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/mm/vmstat.c b/mm/vmstat.c index 84fd6eb..0d17b8f 100644 --- a/mm/vmstat.c +++ b/mm/vmstat.c @@ -1782,11 +1782,9 @@ static void vmstat_update(struct work_struct *w) * to occur in the future. Keep on running the * update worker thread. */ - preempt_disable(); queue_delayed_work_on(smp_processor_id(), mm_percpu_wq, this_cpu_ptr(&vmstat_work), round_jiffies_relative(sysctl_stat_interval)); - preempt_enable(); } }
-- _______________________________________________ linux-yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/linux-yocto
