Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2861338imm; Sun, 29 Jul 2018 05:13:08 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcyXZH0TYg29ygt/SEa+JBwNgnhAAK+B0W2siq9ou0JrscwiXUDEEasTYOS9uXRyIVfolZd X-Received: by 2002:a63:1126:: with SMTP id g38-v6mr12490865pgl.122.1532866388192; Sun, 29 Jul 2018 05:13:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532866388; cv=none; d=google.com; s=arc-20160816; b=f5jqp+Lba38+ehUIwQ9N2xzI4W1wWXZ3P8UKeZD8rItpH3L/vzu2FazWQi00VFAGQu DxlZkuTjadJQ1wruJKJFAJt+xc3Mhi6fENjCrHyZxpiX8WSk3CRwlCmd0X46n8DOazF9 Zh5POrdHqxGVNmQ9+5aODw8VX1GIw3vadH8BZBOAxPag4LQ1V/OCQQPLEEXy2Cp6ivFj wFs8mzvd8fjeyj1QyOsAQR+X4ZaOiJaC4+U4cEcMLE5GZjQNAPFq/TdA+4tZC9Yqa9Br HCZBLLbBgKA5jg0Snk/RDao3ucFqVU9IScwKrk0np+O22MsB7fJe0ywNHv7SJdPODJKi voew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:in-reply-to:date :cc:to:from:subject:message-id:arc-authentication-results; bh=Y24ilow9jh9561s8Jit8ycLrkDT/0PyW5wK2K+6i6NE=; b=SHgwTz+4JFXmooyMiwgw3By+SWl1rTgTIwsrvHQidxbYSRojWjevRfVhKXV4O9g+N1 pdprVvBMZD7CL9pCLG3NGEEBoYt5B/Tzd2UQRqEmXUNv8sZhlwIZrZg1iZBFVgo6iclc gBtqs4bTDzjXyZkvw3OfJ953fCAgHGnsZSxcQ+d5fxDpo8DWgUPjQjvaqYcWQwEjmHRU 9A0KBeyS+T15kwJ/4tAvqzttEfc83elhgcFQG9N6GkrEcyTDVHcW2Xy2DwrAYAuH6NNc guBKmMEySHzMeJtVMjcLzZzbyqEvO1PdCAmTFiu+ZuBj/EB3CSLyBua23bUcMHP0SM/a ozKQ== 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 z13-v6si9186212pfc.118.2018.07.29.05.12.51; Sun, 29 Jul 2018 05:13:08 -0700 (PDT) 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 S1726452AbeG2NmR (ORCPT + 99 others); Sun, 29 Jul 2018 09:42:17 -0400 Received: from shelob.surriel.com ([96.67.55.147]:46958 "EHLO shelob.surriel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726336AbeG2NmR (ORCPT ); Sun, 29 Jul 2018 09:42:17 -0400 Received: from imladris.surriel.com ([96.67.55.152]) by shelob.surriel.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fjkYJ-0004zH-OG; Sun, 29 Jul 2018 08:11:59 -0400 Message-ID: <1532866319.28585.12.camel@surriel.com> Subject: Re: [PATCH 10/10] mm,sched: conditionally skip lazy TLB mm refcounting From: Rik van Riel To: Andy Lutomirski Cc: LKML , kernel-team , Peter Zijlstra , X86 ML , Vitaly Kuznetsov , Ingo Molnar , Mike Galbraith , Dave Hansen , will.daecon@arm.com, Catalin Marinas , Benjamin Herrenschmidt Date: Sun, 29 Jul 2018 08:11:59 -0400 In-Reply-To: References: <20180728215357.3249-1-riel@surriel.com> <20180728215357.3249-11-riel@surriel.com> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-jPUjgOFaXwY+aPEJEyBz" X-Mailer: Evolution 3.26.6 (3.26.6-1.fc27) Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-jPUjgOFaXwY+aPEJEyBz Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 2018-07-28 at 21:21 -0700, Andy Lutomirski wrote: > On Sat, Jul 28, 2018 at 2:53 PM, Rik van Riel > wrote: > > Conditionally skip lazy TLB mm refcounting. When an architecture > > has > > CONFIG_ARCH_NO_ACTIVE_MM_REFCOUNTING enabled, an mm that is used in > > lazy TLB mode anywhere will get shot down from exit_mmap, and there > > in no need to incur the cache line bouncing overhead of refcounting > > a lazy TLB mm. >=20 > Unless I've misunderstood something, this patch results in idle tasks > whose active_mm has been freed still having active_mm pointing at > freed memory.=20 Patch 9/10 is supposed to ensure that the lazy TLB CPUs get switched to init_mm before an mm is freed. No CPU should ever have its active_mm pointing at a freed mm. Your message made me re-read the code, and now I realize that leave_mm does not actually do that. Looking at the other callers of leave_mm, I might not be the only one surprised by that; xen_drop_mm_ref comes to mind. I guess I should some code to leave_mm to have it actually clear active_mm and call the conditional refcount drop helper function. Does that clear up the confusion? --=20 All Rights Reversed. --=-jPUjgOFaXwY+aPEJEyBz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEKR73pCCtJ5Xj3yADznnekoTE3oMFAltdrw8ACgkQznnekoTE 3oNpnwf/egonoGu2+wuvX0k2JIE5dU8FQJQtQTVhPucY1/BjG0pfT4vSVcV9kYs9 I6glsUA+12cV2O6tghL3W3SwvaxzrltjVohdbj1fec+JiE+FUG76VjNkreMPpTas BB2vGYEPruBlqllMuOTG+ZfhORIxzAQxb8CxlqlB6T1CrIigdSn7Iynk75oaw5fZ BBk72RV88OJaQEvQc7+iOvJzhu/Z4KTWnmtsZGJ90OA5OIvisDso9+4CHT/N4OB4 6dKBHEQx72d0Xkw/zwWnT6ac0YbbHu0Rudj732v/OIIPkRbhY+HpNH5Z+I0i0qaG QmRbBHdpWfs/4iAar4aG+3d4YqVFxA== =hxfm -----END PGP SIGNATURE----- --=-jPUjgOFaXwY+aPEJEyBz--