Hi David, On Thu, 2020-03-05 at 13:38 +0000, David Laight wrote: > From: zanussi@xxxxxxxxxx > > Sent: 27 February 2020 14:34 > > [ Upstream commit 140d7f54a5fff02898d2ca9802b39548bf7455f1 ] > > > > If user task changes the CPU affinity mask of a running task it > > will > > dispatch migration request if the current CPU is no longer allowed. > > This > > might happen shortly before a task enters a migrate_disable() > > section. > > Upon leaving the migrate_disable() section, the task will notice > > that > > the current CPU is no longer allowed and will will dispatch its own > > migration request to move it off the current CPU. > > While invoking __schedule() the first migration request will be > > processed and the task returns on the "new" CPU with "arg.done = > > 0". Its > > own migration request will be processed shortly after and will > > result in > > memory corruption if the stack memory, designed for request, was > > used > > otherwise in the meantime. > > > > Spin until the migration request has been processed if it was > > accepted. > > What happens if the process changing the affinity mask is running > at a higher RT priority than that of the task being changed and > the new mask requires it run on the same cpu? > > David > This patch, 'sched: migrate_enable: Use per-cpu cpu_stop_work', removes the busy wait and is queued for the next update: https://lore.kernel.org/linux-rt-users/20200203173732.ldbgbpwao7xm23mm@xxxxxxxxxxxxx/T/#mf19a8af38ac4ea0cc01775835e9d715f175f0b7b Thanks, Tom > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, > MK1 1PT, UK > Registration No: 1397386 (Wales) >
