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 ABE10C47DDB for ; Tue, 23 Jan 2024 17:21:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2B60F6B007D; Tue, 23 Jan 2024 12:21:03 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 265F56B007E; Tue, 23 Jan 2024 12:21:03 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1551F6B0080; Tue, 23 Jan 2024 12:21:03 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 01E006B007D for ; Tue, 23 Jan 2024 12:21:02 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id CEDF2120B77 for ; Tue, 23 Jan 2024 17:21:02 +0000 (UTC) X-FDA: 81711241164.21.E757A07 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf13.hostedemail.com (Postfix) with ESMTP id 965E820004 for ; Tue, 23 Jan 2024 17:21:00 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="HtFk/wxX"; dmarc=none; spf=none (imf13.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706030461; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding:in-reply-to: references:dkim-signature; bh=zTQsORFLC6fYhfsfPEKgNKuKiXnrjQDCNN/vaGQwoOc=; b=nK6OErYlyQhN3bjCGzTfOL8yPu3Btewn2VVPipv/+6iaWKyDsxRbFT8DBief0j4oB9JfqA l88L+mDMVdOvdc8nNOH/2BkL96tvaRpPztya/kdjKQJ3mJWvaWlVFQ16m69CW1LQc5XAN4 m94WqPfQDB4BWbRDnUs59vTM26w8jL0= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="HtFk/wxX"; dmarc=none; spf=none (imf13.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706030461; a=rsa-sha256; cv=none; b=ORVaXoXlMi3jSA66JhlKudiqg/AwOI3IEQw79eLzkkTeQy47PjijW5+H40eyKJxjk2E83j 4xHwDFAOFKAZghzGI0Q6DTEca1R5CZZqUlomyo9Idw/WqUhFLJyrth9v82yHm3EIccU8VY Yu1AZ8iKiq2lWB/4zdSOzpOrib7gNL4= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Content-Type:MIME-Version:Message-ID: Subject:To:From:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:In-Reply-To:References; bh=zTQsORFLC6fYhfsfPEKgNKuKiXnrjQDCNN/vaGQwoOc=; b=HtFk/wxXzP3j+1B+UYOoNdpJVC lKb66WmeXCRmhmb61slllPnGtUpZbEqXvKc+PhLaySfvnQjOKBdYgIAUDsWr/cgw64g2fL80FEZGc tPKgJ+2nUN7lU+BkYthbINdNEPNHqdFXeX2P3nOV5ryObtY1reTQ7Jci8zqbmEEXjq7ghNt65n13y SbHatvktIyzyeOh2Nkezoj6cciPDhkjybwL9OPkf4lz/62b2mmchurI+bmrNvo7TkRJ/ZbRiruNIg WT5aSIfZRl7W6B1SuggIdsrNnoAeYZqFAbCBknLpv+Zu5rrygJD1os/Vei31TbKtcSusBVD8Y7aJo OY9HZJfg==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rSKSF-00000003oVe-1WZ9; Tue, 23 Jan 2024 17:20:55 +0000 Date: Tue, 23 Jan 2024 17:20:55 +0000 From: Matthew Wilcox To: Helge Deller , Thomas Zimmermann , Jaya Kumar , Daniel Vetter , linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-mm@kvack.org Subject: fb_defio and page->mapping Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 965E820004 X-Stat-Signature: so51ghp5t94a4m7hkuhzhc38t9es4rpy X-Rspam-User: X-HE-Tag: 1706030460-351635 X-HE-Meta: U2FsdGVkX18WBBCNIIRzWf/pFuhqDUF6jjs4XDELQUE/Y/V5C/WbkQxkY1PMZiMG9HT68H1TLm/PgQwnYwF2DfMh8VyMqgCcv+Fk6TE6DfZZqiVnF6Fbesf5dELsOb4FvgFAN0wnDD8VFqGmx+MhBZbU1xrYdn+mHod9ghGInwrFHJNfP/YhFdhE5auhZi2uMw0HKAvfI/HkSdYiI6tND0zGcPnvAGD1mehGXFpsWeY/fwRwz1rTbFy6xU3IVN5+pqLScF3A67cAcKOuQTbF3tTtV4ExCktRhP6LHRl2n5+z/svs1BNPnQE4F+nId+UBlNGz9yzqLkDqIDt/4WTZWpBXDWNuIrscZBD2AnSJxltutRZUrrlH9b7wFlT4z46ZOJilKdGJ+52u9HONHG2ggeF2ahWjxFVgBBySGcEcsY61aWjO+hTpb7Q9cDAq70dAbHTfxYGB6irbEFudEvdcr1rLnotDdqeOo5hF/CwTJwyF/762MWrUQ27vfSA8QBSdfBn9eny/dUV2iilA+idMg5ckaXuBI5UhUEQWsQy5IznAwo3f3I2PEOSSaoklleaiCsygTYNm9HZx1lEXKFLWOUIFZuJt2GD3o9//pjugrlDLPQ1C1lB4X6p3h+NvM99BaMUI/tLRNTRS8HM+FJYwHOn5Zp2dm/mHu9IQ3300xN86rAmanX2oglV/3IMTi8UEZtsJ2A/pyh4hDZ2hNdw6jz0dEu1NJRyzyC/MtbvrBXM5QMgzaYuSYCKIIuiYAR8UZzOn8JwgHo4BWWUwJVsJe7dmvs34Jnvn0oGCY4pHz4lMXpu0dFjQzOnE5lCudyJlITx0OESRrnVr08VsCyoMd5tvHbqtHk3x5img2gVyyDqHIxBSuhR1FuZCCEtK2g3qmSHx1PUB7WapwtO5XXYpfwYjY7V+/vB6HRsndeg4eeWhb5aXd8N6cs7s22nZlhAoee2QxI0x+izGjW5Yfuj vAsn9XZ4 9Kdr/v5FWBCc846H0GPWHkJtsv9GgU58BwmQDVa4wwn0nrNCZSa97bldnYEq4GhhnTWeB0LZu7dZkrmThuNs2syxSpSmOQdWM4MmHdT96pzA+k44KkZ9USj9ICiJZcbhMB4TJg3ak+jfw/RIiBimsmVeKV6B6110HTmpLy651xxT1d3TAINkzUOyXdQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: We're currently trying to remove page->mapping from the entire kernel. This has me interested in fb_defio and since I made such a mess of it with commits ccf953d8f3d6 / 0b78f8bcf495, I'd like to discuss what to do before diving in. Folios continue to have a mapping. So we can effectively do page_folio(page)->mapping (today that's calling compound_head() to get to the head page; eventually it's a separate allocation). But now I look at commit 56c134f7f1b5, I'm a little scared. Apparently pages are being allocated from shmem and being mapped by fb_deferred_io_fault()? This line: page->mapping = vmf->vma->vm_file->f_mapping; initially appears harmless for shmem files (because that's presumably a noop), but it's only a noop for head pages. If shmem allocates a compound page (ie a 2MB THP today), you'll overlay some information stored in the second and third pages; looks like _entire_mapcount and _deferred_list.prev (but we do shift those fields around without regard to what the fb_defio driver is doing). Even if you've disabled THP today, setting page->mapping to NULL in fb_deferred_io_lastclose() for a shmem page is a really bad idea. I'd like to avoid fb_defio playing with page->mapping at all. As I understand it, the only reason to set page->mapping is so that page_mkclean() works. But there are all kinds of assumptions in page_mkclean() (now essentially folio_mkclean()) that we're dealing with file-backed or anonymous memory. I wonder if we might be better off calling pfn_mkclean_range() for each VMA which maps these allocations? You'd have to keep track of each VMA yourself (I think?) but it would avoid messing with page->mapping. Anyway, I don't know enough about DRM. There might be something unutterably obvious we could do to fix this.