From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B9951C28CF5 for ; Wed, 26 Jan 2022 11:57:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DBC5F6B0072; Wed, 26 Jan 2022 06:57:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D42626B0074; Wed, 26 Jan 2022 06:57:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C0A3A6B0075; Wed, 26 Jan 2022 06:57:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0225.hostedemail.com [216.40.44.225]) by kanga.kvack.org (Postfix) with ESMTP id B14706B0072 for ; Wed, 26 Jan 2022 06:57:27 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 59110824C429 for ; Wed, 26 Jan 2022 11:57:27 +0000 (UTC) X-FDA: 79072288134.04.119E96E Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf06.hostedemail.com (Postfix) with ESMTP id C302818000D for ; Wed, 26 Jan 2022 11:57:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1643198246; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=w6RnHqBRXKKY9foSrt7oGpZU3YcqPco8hnhwfG4iwHA=; b=i4G4WZ0tirLMAHvFJriEFdW6HM+JgVi0y//VVEaYaDrCO3UfeZ0NbkT1BKGn5voFL0j5UA lcv9VIEGcApAKREO4KhqQub4zjO8RWavIparQcd6EOXjHh5xE1AZ+RHoiAXvNwobgq1XlR Ss+ggWc4Ev+4cQoZOpvYFOul5n5zPlg= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-330-HTAl0C4bN_-GPlCoOLk-Xw-1; Wed, 26 Jan 2022 06:57:25 -0500 X-MC-Unique: HTAl0C4bN_-GPlCoOLk-Xw-1 Received: by mail-wm1-f72.google.com with SMTP id c16-20020a1c9a10000000b0034dd409329eso3170940wme.3 for ; Wed, 26 Jan 2022 03:57:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:organization:subject :in-reply-to:content-transfer-encoding; bh=w6RnHqBRXKKY9foSrt7oGpZU3YcqPco8hnhwfG4iwHA=; b=f8NavUe5TcJ7eCTFDaUw3qAw6CRVvrkuHNrBb+3XufyiW6mvl1Fro2xMZbdaW/FslP mQV2o3M7lzeuP2DOhdOn/H8KKyQIIgKZHWZUMZqg2/W9M/jtVg+D4LQjh09/mTO7qpC6 s67hIMufXn253C2pZqlZiRxFog7JN34GokC0Lxy9gCMEiiQ68XanAP/rWPTeVXRLPIcU Q/Fd/kKH+v9xxIvi29Ko2jJiTUbjx1UCZqAp0OK7+E5Y57q0ysJLLYAsVYh3WMBxANee /VlzblyJFGzaH7dt37Kg4eAR/llr7UAa8BLIp0j0XZQYVCBKRI5uuOP0vE+3M8Siiv4X Wv3A== X-Gm-Message-State: AOAM532TQOdLbP5YqShgfYshCn1txIlr4v6t2GPxbopK7IKlTZykUpq1 BLgkoASOIfhC0eivXR+qJldoFUA+mnYl/9FSPp3tpBfUtjpURacglaKKZ63uIknqbW8DgOS6U37 snz6SGzXWy0k= X-Received: by 2002:a1c:4d1a:: with SMTP id o26mr6951706wmh.147.1643198243813; Wed, 26 Jan 2022 03:57:23 -0800 (PST) X-Google-Smtp-Source: ABdhPJxFqWDLyjsg3RrLRRoSoX6kG2G3W4KJXWCYT79Oj2x6eCRVWsW/D6F8N8lsymC4hoPPnF9nLw== X-Received: by 2002:a1c:4d1a:: with SMTP id o26mr6951692wmh.147.1643198243564; Wed, 26 Jan 2022 03:57:23 -0800 (PST) Received: from ?IPV6:2003:cb:c709:2700:cdd8:dcb0:2a69:8783? (p200300cbc7092700cdd8dcb02a698783.dip0.t-ipconnect.de. [2003:cb:c709:2700:cdd8:dcb0:2a69:8783]) by smtp.gmail.com with ESMTPSA id g7sm3923134wmq.28.2022.01.26.03.57.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 26 Jan 2022 03:57:23 -0800 (PST) Message-ID: <5b4e2c29-8f1a-5a68-d243-a30467cc02d4@redhat.com> Date: Wed, 26 Jan 2022 12:57:22 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 To: Jann Horn Cc: Yang Shi , kirill.shutemov@linux.intel.com, willy@infradead.org, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org References: <20220120202805.3369-1-shy828301@gmail.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [v2 PATCH] fs/proc: task_mmu.c: don't read mapcount for migration entry In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: nil X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: C302818000D X-Stat-Signature: cjs7rznyhaw1hcbjfhiuf5fmewjzgxrk Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=i4G4WZ0t; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf06.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com X-HE-Tag: 1643198246-794338 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 26.01.22 12:48, Jann Horn wrote: > On Wed, Jan 26, 2022 at 12:38 PM David Hildenbrand wrote: >> On 26.01.22 12:29, Jann Horn wrote: >>> On Wed, Jan 26, 2022 at 11:51 AM David Hildenbrand wrote: >>>> On 20.01.22 21:28, Yang Shi wrote: >>>>> The syzbot reported the below BUG: >>>>> >>>>> kernel BUG at include/linux/page-flags.h:785! > [...] >>>>> RIP: 0010:PageDoubleMap include/linux/page-flags.h:785 [inline] >>>>> RIP: 0010:__page_mapcount+0x2d2/0x350 mm/util.c:744 > [...] >>>> Does this point at the bigger issue that reading the mapcount without >>>> having the page locked is completely unstable? >>> >>> (See also https://lore.kernel.org/all/CAG48ez0M=iwJu=Q8yUQHD-+eZDg6ZF8QCF86Sb=CN1petP=Y0Q@mail.gmail.com/ >>> for context.) >> >> Thanks for the pointer. >> >>> >>> I'm not sure what you mean by "unstable". Do you mean "the result is >>> not guaranteed to still be valid when the call returns", "the result >>> might not have ever been valid", or "the call might crash because the >>> page's state as a compound page is unstable"? >> >> A little bit of everything :) > [...] >>> In case you mean "the result might not have ever been valid": >>> Yes, even with this patch applied, in theory concurrent THP splits >>> could cause us to count some page mappings twice. Arguably that's not >>> entirely correct. >> >> Yes, the snapshot is not atomic and, thereby, unreliable. That what I >> mostly meant as "unstable". >> >>> >>> In case you mean "the call might crash because the page's state as a >>> compound page could concurrently change": >> >> I think that's just a side-product of the snapshot not being "correct", >> right? > > I guess you could see it that way? The way I look at it is that > page_mapcount() is designed to return a number that's at least as high > as the number of mappings (rarely higher due to races), and using > page_mapcount() on an unlocked page is legitimate if you're fine with > the rare double-counting of references. In my view, the problem here > is: > > There are different types of references to "struct page" - some of > them allow you to call page_mapcount(), some don't. And in particular, > get_page() doesn't give you a reference that can be used with > page_mapcount(), but locking a (real, non-migration) PTE pointing to > the page does give you such a reference. I assume the point is that as long as the page cannot be unmapped because you block it from getting unmapped (PT lock), the compound page cannot get split. As long as the page cannot get unmapped from that page table you should have at least a mapcount of 1. But yeah, using the mapcount of a page that is not even mapped (migration entry) is clearly wrong. To summarize: reading the mapcount on an unlocked page will easily return a wrong result and the result should not be relied upon. reading the mapcount of a migration entry is dangerous and certainly wrong. -- Thanks, David / dhildenb