On 2019-10-04 18:20:41 [+0200], Uladzislau Rezki wrote: > On Fri, Oct 04, 2019 at 05:37:28PM +0200, Sebastian Andrzej Siewior wrote: > > If you post something that is related to PREEMPT_RT please keep tglx and > > me in Cc. > > > > On 2019-10-03 11:09:06 [+0200], Daniel Wagner wrote: > > > Replace preempt_enable() and preempt_disable() with the vmap_area_lock > > > spin_lock instead. Calling spin_lock() with preempt disabled is > > > illegal for -rt. Furthermore, enabling preemption inside the > > > > Looking at it again, I have reasonable doubt that this > > preempt_disable() is needed. > > > The intention was to preload a current CPU with one extra object in > non-atomic context, thus to use GFP_KERNEL permissive parameters. I.e. > that allows us to avoid any allocation(if we stay on the same CPU) > when we are in atomic context do splitting. You could have been migrated to another CPU before the first preempt_disable(). You could have been migrated to another CPU while memory has been allocated. I don't really see the point of that preempt_disable() besides keeping debug code quiet. > If we have migrate_disable/enable, then, i think preempt_enable/disable > should be replaced by it and not the way how it has been proposed > in the patch. I don't think this patch is appropriate for upstream. Sebastian
