On Thu, 09 Jan 2014 13:39:55 +0800 Weijie Yang <weijie.y...@samsung.com> 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 :( -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
