On Wed, 25 Jul 2018 14:37:58 +0800 "[email protected]" <[email protected]> wrote:
> From: zhaowuyun <[email protected]> > > issue is that there are two processes A and B, A is kworker/u16:8 > normal priority, B is AudioTrack, RT priority, they are on the > same CPU 3. > > The task A preempted by task B in the moment > after __delete_from_swap_cache(page) and before swapcache_free(swap). > > The task B does __read_swap_cache_async in the do {} while loop, it > will never find the page from swapper_space because the page is removed > by the task A, and it will never sucessfully in swapcache_prepare because > the entry is EEXIST. > > The task B then stuck in the loop infinitely because it is a RT task, > no one can preempt it. > > so need to disable preemption until the swapcache_free executed. Yes, right, sorry, I must have merged cbab0e4eec299 in my sleep. cond_resched() is a no-op in the presence of realtime policy threads and using to attempt to yield to a different thread it in this fashion is broken. Disabling preemption on the other side of the race should fix things, but it's using a bandaid to plug the leakage from the earlier bandaid. The proper way to coordinate threads is to use a sleeping lock, such as a mutex, or some other wait/wakeup mechanism. And once that's done, we can hopefully eliminate the do loop from __read_swap_cache_async(). That also services ENOMEM from radix_tree_insert(), but __add_to_swap_cache() appears to handle that OK and we shouldn't just loop around retrying the insert and the radix_tree_preload() should ensure that radix_tree_insert() never fails anyway. Unless we're calling __read_swap_cache_async() with screwy gfp_flags from somewhere.
