From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 3 Feb 2014 20:14:01 -0800 (PST) From: Hugh Dickins To: Andrew Morton cc: Weijie Yang , hughd@google.com, Minchan Kim , shli@kernel.org, Bob Liu , weijie.yang.kh@gmail.com, Seth Jennings , Heesub Shin , mquzik@redhat.com, Linux-MM , linux-kernel , stable@vger.kernel.org Subject: Re: [PATCH 2/8] mm/swap: fix race on swap_info reuse between swapoff and swapon In-Reply-To: <20140203152925.89360139306d143f5360fa07@linux-foundation.org> Message-ID: References: <000d01cf1b47$f12e11f0$d38a35d0$%yang@samsung.com> <20140203152340.b28bb35698ee75615eb23041@linux-foundation.org> <20140203152925.89360139306d143f5360fa07@linux-foundation.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: On Mon, 3 Feb 2014, Andrew Morton wrote: > On Mon, 3 Feb 2014 15:23:40 -0800 Andrew Morton wrote: > > On Mon, 27 Jan 2014 18:03:04 +0800 Weijie Yang 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. > > > > > > This patch is just for a rare scenario, aim to correct of code. > > > > I believe that > > http://ozlabs.org/~akpm/mmots/broken-out/mm-swap-fix-race-on-swap_info-reuse-between-swapoff-and-swapon.patch > > makes this patch redundant? > > > > oop, hang on. This patch *is* a stealth-updated version of > http://ozlabs.org/~akpm/mmots/broken-out/mm-swap-fix-race-on-swap_info-reuse-between-swapoff-and-swapon.patch. > > Undocumented removals of si->swap_map have been added. What's going on > there? > > I think I'll stick with the original patch for now. If you see > additional optimisations or changes, let's address that separately? Correct decision, thanks: I explained in an answer when Acking the previous version why I dislike this version (it would prevent you from watching the slow progress of swapoff). Hugh