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 9C4A2C433F5 for ; Mon, 10 Jan 2022 13:37:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F105B6B0075; Mon, 10 Jan 2022 08:37:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EBFB56B0078; Mon, 10 Jan 2022 08:37:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DAE7E6B007B; Mon, 10 Jan 2022 08:37:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0102.hostedemail.com [216.40.44.102]) by kanga.kvack.org (Postfix) with ESMTP id CB2B06B0075 for ; Mon, 10 Jan 2022 08:37:19 -0500 (EST) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 8303B8E3FF for ; Mon, 10 Jan 2022 13:37:19 +0000 (UTC) X-FDA: 79014478998.21.05849FF Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf01.hostedemail.com (Postfix) with ESMTP id F099B40007 for ; Mon, 10 Jan 2022 13:37:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=4wR6hrOJgs+X6kKk9+UhCE6lJrlz1SxlJAZof4WK/t0=; b=P7j/zTCAD0FbAREoR6HCZlOov3 5nLtOzCxOa7TeZ0E4/VTBu9clkGt3hSpYfm0ETOgd1Adt2KU3yfaYre8E6LLUwHrIkrSTYscLDBVN 0h0N96DW6dwC9svxZZEVt3j4pFhZZABuMYbQ4QdcgrMrPE3XFdViUUIFCeZIcLcuGdVE6MuyOXuLl utNXfONFU9EwP8ltAzVkPygTkSwzKioqMocEXABoJxqs4glfgPyFwcTYxHfcYNwygtaaXLOu/Gqv1 Q8FiID8B4eDmbI70J5k397RQ1JnSPweGlxkQzm7kgOjRsZNuWTweiW8vwGk2NQR28wGzacmyDvN+e dexLbQ4g==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1n6urJ-002SWS-PY; Mon, 10 Jan 2022 13:37:13 +0000 Date: Mon, 10 Jan 2022 13:37:13 +0000 From: Matthew Wilcox To: Christoph Hellwig Cc: linux-mm@kvack.org, John Hubbard , William Kucharski , linux-kernel@vger.kernel.org, Jason Gunthorpe , Mike Kravetz Subject: Re: [PATCH v2 06/28] gup: Fix some contiguous memmap assumptions Message-ID: References: <20220110042406.499429-1-willy@infradead.org> <20220110042406.499429-7-willy@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="P7j/zTCA"; dmarc=none; spf=none (imf01.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: F099B40007 X-Stat-Signature: hw8q8qxiqn9cb6tkmixcp1eci18m8sad X-HE-Tag: 1641821838-893094 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 Mon, Jan 10, 2022 at 12:29:58AM -0800, Christoph Hellwig wrote: > On Mon, Jan 10, 2022 at 04:23:44AM +0000, Matthew Wilcox (Oracle) wrote: > > Several functions in gup.c assume that a compound page has virtually > > contiguous page structs. This isn't true for SPARSEMEM configs unless > > SPARSEMEM_VMEMMAP is also set. Fix them by using nth_page() instead of > > plain pointer arithmetic. > > So is this an actualy bug that need a Fixes tag, or do all architectures > that support THP and sparsemem use SPARSEMEM_VMEMMAP? As far as I can tell (and I am by no means an expert in this area), this problem only affects pages of order MAX_ORDER or higher. That is, somebody using regular 2MB hugepages on x86 won't see a problem, whether they're using VMEMMAP or not. It only starts to become a problem for 1GB hugepages. Since THPs are (currently) only allocated from the page allocator, it's never a problem for THPs, only hugetlbfs. Correcting the places which can't see a 1GB page is just defense against copy-and-paste programming. So I'll defer to Mike -- does this ever affect real systems and thus warrant a backport? I know this doesn't affect UEK because we enable SPARSEMEM_VMEMMAP. > > + page = nth_page(head, (addr & (sz-1)) >> PAGE_SHIFT); > > Would be nice to fix the indeation for sz - 1 while you're at it. Done.