Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp185726imj; Thu, 14 Feb 2019 18:13:04 -0800 (PST) X-Google-Smtp-Source: AHgI3IZDhHtgcj99Doj8gKSo+Wi4kciUem317QeIU+uzC+wL6IOt3hon4KVKSbdPGzC0cK3bgUxt X-Received: by 2002:a63:ed03:: with SMTP id d3mr2965657pgi.275.1550196783934; Thu, 14 Feb 2019 18:13:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550196783; cv=none; d=google.com; s=arc-20160816; b=WxXmR4FAHkbALGLAAGvpyDxNRNCnuLRTOspLpl/zFLR+XAWGCYYbpdfRB3rSz6qeyE Ulu+vJmLc3tqVDPzDGmZCq2eME0f20ky9UDdfo/ZKYu9Qc9Z3RTRk8o3XtZ+uXgWA9g+ rGbM5Ff0hhoAsCBfgT5ESmwz5Bo4lRKnDQH+RovC/CBA12Kxeap4XFtvNqKfCQkxDSLN vuJ7jlkmyN+4OLkVAABAmNmdlQQm1pvZrKgByrFogg6HXRfj1nbTH9fv4qZFvdLlUtVQ KlRG8v+Fw7wUY6HMd0O3a6HVZp8yNsFVT7P0B4kKffghguSwUPbqyUav9FzWTYzw4L7Y uHXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=014kmWKdZnQ5ek9CQiz5h17iGhQ1vzM21YymOgXgDIs=; b=vE1XyNRLaNQ73vrppbtv1vmcukbOLo7TrT3Qeb1fxX4GoDZxcN3+IwgxTIHZQoMw81 +PBx1kZb/gkdquJKbKvsW2tK9EFYYlWQMk3GaxBjFtFistbyDm8OoyPd0DoiXXdOHOdN x5ub4/CwgJ7cQ90TaUEMY3Ywv68bgd81SbcDYHnNJubh07iJeWJrumBgTP4ya9RqDMZz Qslkyy+mHbsa+D0KcK53CP6JYRiV3hsVBhsY2CfWjICOrOlEhutWqT53FPX0havVmEdU KLnaUcShg5FnhA+AIFbxm8RvdxkkdJS5tt2nX4iJmDAHBUAX6LO+ox6JXMEFcnKDHv3m 3IMA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u20si4065014pgh.147.2019.02.14.18.12.48; Thu, 14 Feb 2019 18:13:03 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2436563AbfBNUaJ (ORCPT + 99 others); Thu, 14 Feb 2019 15:30:09 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:33990 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387975AbfBNUaJ (ORCPT ); Thu, 14 Feb 2019 15:30:09 -0500 Received: from akpm3.svl.corp.google.com (unknown [104.133.8.65]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 9C690AD1; Thu, 14 Feb 2019 20:30:07 +0000 (UTC) Date: Thu, 14 Feb 2019 12:30:02 -0800 From: Andrew Morton To: Michal Hocko Cc: "Huang, Ying" , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Hugh Dickins , "Paul E . McKenney" , Minchan Kim , Johannes Weiner , Tim Chen , Mel Gorman , =?ISO-8859-1?Q?J=E9r=F4me?= Glisse , Andrea Arcangeli , David Rientjes , Rik van Riel , Jan Kara , Dave Jiang , Daniel Jordan , Andrea Parri Subject: Re: [PATCH -mm -V7] mm, swap: fix race between swapoff and some swap operations Message-Id: <20190214123002.b921b680fea07bf5f798df79@linux-foundation.org> In-Reply-To: <20190214143318.GJ4525@dhcp22.suse.cz> References: <20190211083846.18888-1-ying.huang@intel.com> <20190214143318.GJ4525@dhcp22.suse.cz> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 14 Feb 2019 15:33:18 +0100 Michal Hocko wrote: > > Because swapoff() is very rare code path, to make the normal path runs as > > fast as possible, disabling preemption + stop_machine() instead of > > reference count is used to implement get/put_swap_device(). From > > get_swap_device() to put_swap_device(), the preemption is disabled, so > > stop_machine() in swapoff() will wait until put_swap_device() is called. > > > > In addition to swap_map, cluster_info, etc. data structure in the struct > > swap_info_struct, the swap cache radix tree will be freed after swapoff, > > so this patch fixes the race between swap cache looking up and swapoff > > too. > > > > Races between some other swap cache usages protected via disabling > > preemption and swapoff are fixed too via calling stop_machine() between > > clearing PageSwapCache() and freeing swap cache data structure. > > > > Alternative implementation could be replacing disable preemption with > > rcu_read_lock_sched and stop_machine() with synchronize_sched(). > > using stop_machine is generally discouraged. It is a gross > synchronization. This was discussed to death and I think the changelog explains the conclusions adequately. swapoff is super-rare so a stop_machine() in that path is appropriate if its use permits more efficiency in the regular swap code paths. > Besides that, since when do we have this problem? What problem??