On Sat, Jan 11, 2014 at 9:11 AM, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > On Thu, 09 Jan 2014 13:39:55 +0800 Weijie Yang <weijie.yang@xxxxxxxxxxx> wrote: > >> swapoff clear swap_info's SWP_USED flag prematurely and free its resources >> after that. A concurrent swapon will reuse this swap_info while its previous >> resources are not cleared completely. >> >> These late freed resources are: >> - p->percpu_cluster >> - swap_cgroup_ctrl[type] >> - block_device setting >> - inode->i_flags &= ~S_SWAPFILE >> >> This patch clear SWP_USED flag after all its resources freed, so that swapon >> can reuse this swap_info by alloc_swap_info() safely. >> >> ... >> >> --- a/mm/swapfile.c >> +++ b/mm/swapfile.c >> @@ -1922,7 +1922,6 @@ SYSCALL_DEFINE1(swapoff, const char __user *, specialfile) >> p->swap_map = NULL; >> cluster_info = p->cluster_info; >> p->cluster_info = NULL; >> - p->flags = 0; >> frontswap_map = frontswap_map_get(p); >> spin_unlock(&p->lock); >> spin_unlock(&swap_lock); >> @@ -1948,6 +1947,16 @@ SYSCALL_DEFINE1(swapoff, const char __user *, specialfile) >> mutex_unlock(&inode->i_mutex); >> } >> filp_close(swap_file, NULL); >> + >> + /* >> + * clear SWP_USED flag after all resources freed >> + * so that swapon can reuse this swap_info in alloc_swap_info() safely >> + * it is ok to not hold p->lock after we cleared its SWP_WRITEOK >> + */ >> + spin_lock(&swap_lock); >> + p->flags = 0; >> + spin_unlock(&swap_lock); >> + >> err = 0; >> atomic_inc(&proc_poll_event); >> wake_up_interruptible(&proc_poll_wait); > > I didn't look too closely, but this patch might also address the race > which Krzysztof addressed with > http://ozlabs.org/~akpm/mmots/broken-out/swap-fix-setting-page_size-blocksize-during-swapoff-swapon-race.patch. > Can we please check that out? > > I do prefer fixing all these swapon-vs-swapoff races with some large, > simple, wide-scope exclusion scheme. Perhaps SWP_USED is that scheme. > > An alternative would be to add another mutex and just make sys_swapon() > and sys_swapoff() 100% exclusive. But that is plastering yet another > lock over this mess to hide the horrors which lurk within :( > Hi, Andrew. Thanks for your suggestion. I checked Krzysztof's patch, it use the global swapon_mutex to protect race condition among swapon, swapoff and swap_start(). It is a kind of correct method, but a heavy method. I will try to resend a patchset to make lock usage in swapfile.c clear and fine grit -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html