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 34ED1C47071 for ; Thu, 16 Nov 2023 05:05:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5EBC96B0410; Thu, 16 Nov 2023 00:05:15 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 59C2C6B0411; Thu, 16 Nov 2023 00:05:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 48B556B0412; Thu, 16 Nov 2023 00:05:15 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 3B0926B0410 for ; Thu, 16 Nov 2023 00:05:15 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id F388F120ABC for ; Thu, 16 Nov 2023 05:05:14 +0000 (UTC) X-FDA: 81462628548.26.56AF11F Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf18.hostedemail.com (Postfix) with ESMTP id BECAF1C0008 for ; Thu, 16 Nov 2023 05:05:12 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=aacNsqxh; dmarc=none; spf=none (imf18.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=1700111113; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Yl2SkyZs6uI/0pe9AfsD9HLwWMslWsjY3s28vGnjUts=; b=vbDwxtjJRFzABF9UdaXeWorpYCXnMSI0M8PHs/EnPih/ZwB1rU+3Wka7P2cWoZfulMZN+x roUXnufaCr5JCjzid5Bm+hMtAHw1Yp7AHK2Y/9dDKD8qV5IbiMyGZDxrFy79bR8RVrSMsf 7eE0BPok94JWHy5TJ/X6um9WrpYP5xs= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=aacNsqxh; dmarc=none; spf=none (imf18.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=1700111113; a=rsa-sha256; cv=none; b=zmHMTfWrA234r2GyvjSScVA8pIxEgVBCBnsHIEcFws7rizePkBHXPw0AGrv2uy96Jd1WJI C3aZRm65q5DyskpLyshPKYVE8AtfeVXdVZYkGUamQZfXu5tULr/pYPVKw63GOJnoSJf8Sv iyUAGNipDnn5kRlX4mOpeqVL9pv5Zds= 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=Yl2SkyZs6uI/0pe9AfsD9HLwWMslWsjY3s28vGnjUts=; b=aacNsqxhN99G4fJVbgKJN8idkR JEaXhgQ/9JLpwOOiO3W79Utx7jQeSZeg7oSduCOc3UYHDRP0AodotcJv3tKiCCDpMV2GSaBLRj+CD yv2KmTEVQePSiMZDFRxoRfHdMKAYLvAxiK8+/Ixs4WdinT6E2kzMVqsYlQtNm79/YVD67JN4IJuye ni1G7NlKEz5Zhl+pKx0qgUYDyHxIYgIgv9gTM+SfwkF/lgpp9Plkahe99GAszdjzsqC6Tp0AOC4DR /B79Z6fXDIsI4qOHND+GE3Kn8SFSh4CjIUE4A+GYjviFbcsxfR2evjMIx99Y5TlWrcxp+irVMzlna WqVMWdQg==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1r3UYv-000xIT-MU; Thu, 16 Nov 2023 05:05:09 +0000 Date: Thu, 16 Nov 2023 05:05:09 +0000 From: Matthew Wilcox To: Qu Wenruo Cc: Linux Memory Management List , Linux FS Devel , "linux-btrfs@vger.kernel.org" Subject: Re: Mixed page compact code and (higher order) folios for filemap Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Stat-Signature: diks79cpzr1x5dsb3dnog54mmkpuuzez X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: BECAF1C0008 X-HE-Tag: 1700111112-222778 X-HE-Meta: U2FsdGVkX18AlvyIPXc1co0WmOLNdW8MiUscsw1RbQ/WW5OWWaUsz1eZxuKd9rbXn8PnyJe4H+3w6G9OZk21jq/sEPI3ATMcn9yUM6TJvgDROJGTIMmNoa29d9R+UjqItWTgecO2zldVZzJjHyvzasxNCLfKUP88tAUU0gAM0Vy9wlvB/oyiKTZylHn/MKGSgdsUAmDTIr/Uh4LRlYa/4lCaRnzj5N78+1G6WwIKUUkR+Ks3i6J/yDPEWy7t/gUY4kW8IKDlFb5i9Z590VRG/imPCRjKGslvQtyc/ArCNPBOxFjNBPu2kOaP3BPx4wpRKtgbV3wc5nJsCHju5AIfn6QAJe61c4Gv/zGLXsGLb1coIi033+8MGQDBbevumi4msuolAP9gF1LOwzeZM/SPuaGm1LxqxpJuEoehTC2Pm3wl+b7wKn0h9GmOUN6Jg8ly5GeRdWlL/w2Qo9/xY3cIomg06r2DDWBKO+m7Eu1Ru42v2Mf9WJZc6PLoAA4IDqVpgjxz3YuRdJfU64Cr6FN1vvWXMBJWaXXZDPv3U4DGLKL80Td+6NzTPutdOKqtAXWfFV43KbpZwQit+jDhb0M19ITRCakT5DdexKv753Sr0HzDEy8cFyYI4vd9Dnchxb8mEsiBtCUuO9Mhmco9ECgRMZ7tklH83vEnD7XgsGWT0d3bzfpLP0B8nXE0Mg+PeEnQYHfyoVvjV8q6Z3QQRaQB8OZeKYZ6uMP8B+XA7CkpikgnhA8SumjHkPIOFJ3MbctSNGAkUKiY4Ja1uAHBlaRE4Uka52aRwTaUwy7yAFjydyvES+gjOjs1znPm6MeXTG9+2PyXURFohgTauqEBxQhDdY5xGGER1MzHmWlct0VAXzuAV4/7+9PquN87onil/cxmUZ3zfo9CwB3038bSaQo+Zi0BXCIK2NBdli9Ut2qk1kXTBSjYU694mGlf4MLMOsoJS3mz/sY3BoqR6e6PhyS oI5dIjvq dbaNDeGYRx+7Wzt1lBngRSX2oboSN0qelsX4ZkwHxgvl5jVj9SWyATo1YaTZZwF0UKnDmHTPoJWrOtaldopIwqQUaH9lYDhc9NTy/XOx+w7RfaKFYslmzXnpYGjkBXQRt9La4yDCQttJBUb3zjOnVOvKeZY13SnxwANbc1tB46vQ/S6LJGEFnyC9YPQ== 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: List-Subscribe: List-Unsubscribe: On Thu, Nov 16, 2023 at 02:11:00PM +1030, Qu Wenruo wrote: > E.g. if I allocated a folio with order 2, attached some private data to > the folio, then call filemap_add_folio(). > > Later some one called find_lock_page() and hit the 2nd page of that folio. > > I believe the regular IO is totally fine, but what would happen for the > page->private of that folio? > Would them all share the same value of the folio_attach_private()? Or > some different values? Well, there's no magic ... If you call find_lock_page(), you get back the precise page. If you call page_folio() on that page, you get back the folio that you stored. If you then dereference folio->private, you get the pointer that you passed to folio_attach_private(). If you dereference page->private, *that is a bug*. You might get NULL, you might get garbage. Just like dereferencing page->index or page->mapping on tail pages. page_private() will also do the wrong thing (we could fix that to embed a call to page_folio() ... it hasn't been necessary before now, but if it'll help convert btrfs, then let's do it).