Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp32453pxb; Wed, 13 Jan 2021 22:21:58 -0800 (PST) X-Google-Smtp-Source: ABdhPJxS3KvAA9ri4IaFHs3WWjnNxZSltt5Q4D7Mq8DAx0FzWXmeblGBC5f75r7KrKbQcktO7ZzY X-Received: by 2002:aa7:d1c2:: with SMTP id g2mr4705874edp.8.1610605317948; Wed, 13 Jan 2021 22:21:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610605317; cv=none; d=google.com; s=arc-20160816; b=d1vzQXSPsQj7ui7rNgmrY8JorR6OMv3dZzvCc2K37/tvlbDps9d+SRHVtMzpmWVlRj qjzcmb3gasvTLla/eQLJYcO6N/2Ii+CDw45KqIQF3dYM6gsd0b4NAwn68Rl83gpciu8R NG3bbtBar7SQRkGYO08iEM8AP653/JsOeCXun1563vCLFzZauvxWQMO6rJrM07y5QnE2 gRtNCjQ7WptQH8XYXJfb1RWTcBNbnP7kftGDeDf0T2i7KCMlKwOH/ALFxiqARpyNPzkj QYWy3tKYG0Ra4avFwLGY/AdGCgrZ+fvK9Fuh3AKjQdojQMkhRC2Kb2hqGzsE63Ktu3lx dtZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=V6f56GHlvX+30vh+DfZsExZ/lVAivzj42R6p1vKO9YA=; b=V52wZLeeyTEht/Lqt5rpFEii2Z3Xj+ao0JRJKK/8Pf/jj1rqMinCiR6KuP1ZXR5Bmf oC9ZZ3vF+D5BR52x3Zpfnes4vjQ55joNwrsojAy6RbFRwD7PASvducDLbSyflt/eKbZd rZfbVOQ6wkr3NiQaezLBAj39Sv9C7sQ7MlUGFIYHNxEDBFI9NBDJwdt4a6b/p+ULhxhX 4MLHohEr1SXXnZPWPdg87bBV6PhCRyg5HB+URNuuisSapgyKMzWrricCd81xJ5RGxtAX +qWEjcMSF6VS1T0faH9PhSSR0hEd9Kb3aiCE+Yq18g1LhgU1Evm07VjtnHkL3Jw9LBxN MTNA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=1VxNfJeY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u10si2002549ejr.222.2021.01.13.22.21.34; Wed, 13 Jan 2021 22:21:57 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=1VxNfJeY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726031AbhANGTA (ORCPT + 99 others); Thu, 14 Jan 2021 01:19:00 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44092 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726039AbhANGS7 (ORCPT ); Thu, 14 Jan 2021 01:18:59 -0500 Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 433DFC061794 for ; Wed, 13 Jan 2021 22:18:19 -0800 (PST) Received: by mail-ej1-x630.google.com with SMTP id q22so6568715eja.2 for ; Wed, 13 Jan 2021 22:18:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=V6f56GHlvX+30vh+DfZsExZ/lVAivzj42R6p1vKO9YA=; b=1VxNfJeYo2SCW48DoIhJXUv4ZH/NwkAwPSchXiBWcyb0pHcnoyYSzydSAPwShL9/w+ LsvaAe7mF6uXUVEFgv5fSiXdCtUeZ3JEhabsZ1Ccl7uxjM2smFWVoo+HEHwyfNwaow7L 8S9JJletV2OtIkQzBQrT4j7RXy0gfBR2aSiYdcTGriyLkQBsMghrRWwKrTSSGixJta+E JTAaiD6v8ePqVmOmR6wmW6fYZrqwpxpMlS8fPgie+k9CvynrC5o/6nbXAQHkMjMi+pv1 tC0vWVPGaRdnesbjLjoyy6C8l2CbwOBjauh1Df9fiTLBZSzOFVKd8W/XZmcJvLwD0bkw qoOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=V6f56GHlvX+30vh+DfZsExZ/lVAivzj42R6p1vKO9YA=; b=JxzvXMjz+Q9kr9dHNfw1XI9tssLJSVVA5s0XdUQ9UCsHFIjpg/f3q7Iib06ThRPCPM j6ThjAAherpmCNixlsM5cIAR5zOdJ0VcnHvGtPb6DXytPw3gAIR9QRUACQ6l9PhaevQ6 aX+ni/+O2EtppDt/9CZDLaqct1l71Mhe11I3l2GOxxZO1veVtRmObftq1+/2jspcDNjV zLJD27wtj5LGqQ5Fl4H05qysBlxpsjvcU5xHhhNei1F/e5oDIIuZ9Qoll7bc8H0sc6Wh 1XMjtxhOYVtN9tvqIbLB7NtBCV9OtEhumD0RlMY8ULufP46FVbn9J5/Nq7Oe6QtWgRBL S+3w== X-Gm-Message-State: AOAM533IceDUW2eN9Iu+N06+yd1sUG+ax0eJi/3aJvxcYQ7GyhEmROR/ eqxYHA5jt4kleGYOIyQ/Dh3/e+BmQBzE+Mjwq/TJbQ== X-Received: by 2002:a17:906:a29a:: with SMTP id i26mr4116106ejz.45.1610605097907; Wed, 13 Jan 2021 22:18:17 -0800 (PST) MIME-Version: 1.0 References: <161058499000.1840162.702316708443239771.stgit@dwillia2-desk3.amr.corp.intel.com> <161058501210.1840162.8108917599181157327.stgit@dwillia2-desk3.amr.corp.intel.com> <20210114014944.GA16873@hori.linux.bs1.fc.nec.co.jp> In-Reply-To: <20210114014944.GA16873@hori.linux.bs1.fc.nec.co.jp> From: Dan Williams Date: Wed, 13 Jan 2021 22:18:09 -0800 Message-ID: Subject: Re: [PATCH v4 4/5] mm: Fix page reference leak in soft_offline_page() To: =?UTF-8?B?SE9SSUdVQ0hJIE5BT1lBKOWggOWPoyDnm7TkuZ8p?= Cc: "akpm@linux-foundation.org" , Naoya Horiguchi , Michal Hocko , David Hildenbrand , Oscar Salvador , "stable@vger.kernel.org" , "linux-mm@kvack.org" , "linux-nvdimm@lists.01.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 13, 2021 at 5:50 PM HORIGUCHI NAOYA(=E5=A0=80=E5=8F=A3=E3=80=80= =E7=9B=B4=E4=B9=9F) wrote: > > On Wed, Jan 13, 2021 at 04:43:32PM -0800, Dan Williams wrote: > > The conversion to move pfn_to_online_page() internal to > > soft_offline_page() missed that the get_user_pages() reference taken by > > the madvise() path needs to be dropped when pfn_to_online_page() fails. > > Note the direct sysfs-path to soft_offline_page() does not perform a > > get_user_pages() lookup. > > > > When soft_offline_page() is handed a pfn_valid() && > > !pfn_to_online_page() pfn the kernel hangs at dax-device shutdown due t= o > > a leaked reference. > > > > Fixes: feec24a6139d ("mm, soft-offline: convert parameter to pfn") > > Cc: Andrew Morton > > Cc: Naoya Horiguchi > > Cc: Michal Hocko > > Reviewed-by: David Hildenbrand > > Reviewed-by: Oscar Salvador > > Cc: > > Signed-off-by: Dan Williams > > I'm OK if we don't have any other better approach, but the proposed chang= es > make code a little messy, and I feel that get_user_pages() might be the > right place to fix. Is get_user_pages() expected to return struct page wi= th > holding refcount for offline valid pages? I thought that such pages are > only used by drivers for dax-devices, but that might be wrong. Can I ask = for > a little more explanation from this perspective? The motivation for ZONE_DEVICE is to allow get_user_pages() for "offline" p= fns. soft_offline_page() wants to only operate on "online" pfns. get_user_pages() on a dax-mapping returns an "offline" ZONE_DEVICE page. When pfn_to_online_page() fails the get_user_pages() reference needs to be dropped. To be honest I dislike the entire flags based scheme for communicating the fact that page reference obtained by madvise needs to be dropped later. I'd rather pass a non-NULL 'struct page *' than redo pfn_to_page() conversions in the leaf functions, but that's a much larger change.