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 - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
