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 AED18CD37AE for ; Fri, 15 Sep 2023 22:48:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 33CF98D0047; Fri, 15 Sep 2023 18:48:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2C9BB8D003B; Fri, 15 Sep 2023 18:48:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1125D8D0047; Fri, 15 Sep 2023 18:48:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id EC9B28D003B for ; Fri, 15 Sep 2023 18:48:58 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id BBC1F160817 for ; Fri, 15 Sep 2023 22:48:58 +0000 (UTC) X-FDA: 81240323556.24.83AE265 Received: from mail-yw1-f178.google.com (mail-yw1-f178.google.com [209.85.128.178]) by imf10.hostedemail.com (Postfix) with ESMTP id F1E9AC0004 for ; Fri, 15 Sep 2023 22:48:56 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=IPEhJHlO; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf10.hostedemail.com: domain of hughd@google.com designates 209.85.128.178 as permitted sender) smtp.mailfrom=hughd@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694818137; 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=Kq86mg3eRdpsafcpXL3Gsx54l0Vjtu7ZVdR51WnNflM=; b=Sux5fZb8Cj9o72xWxOyLdLSvsI/5qxp6uZbl0deGhgRh1Ahwqd7IOrKYr4i/d/snyeP0xd YHYksop3TfwLjbP60t0gA1ce6X1W1ZK2i/brTdpUI1SgwJJ9iZ9uwbtMHI+YB+7nC8yM7Q 0+Kb+CjkFRKR2810B6cR2nIsPSNEyow= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=IPEhJHlO; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf10.hostedemail.com: domain of hughd@google.com designates 209.85.128.178 as permitted sender) smtp.mailfrom=hughd@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694818137; a=rsa-sha256; cv=none; b=p5xhhnd1zQZko6MynLPR/hwaBb084vLpJ06JxBz0NJhmG8mdqdao8kMuYsjJCJrhuM0iAh +WL3mndXxeJhhdufLvLGW4+sF2ufH38/lEnnz5NYtUCQPgRiI+/yaHrAZb45b9bWAzkLJC 63Y1VOn1V8bkjFooAbcwLEA+YFlVOYw= Received: by mail-yw1-f178.google.com with SMTP id 00721157ae682-58dce1f42d6so51202547b3.0 for ; Fri, 15 Sep 2023 15:48:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1694818136; x=1695422936; darn=kvack.org; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=Kq86mg3eRdpsafcpXL3Gsx54l0Vjtu7ZVdR51WnNflM=; b=IPEhJHlO2G65XlDJ0FgzicW9UOol1car4uXaPZWUhadTK0Oe0Xw6lF8IkdGf5PHV0S SPgZae4jbw5P+lHZSB39G35RZoVxAbyvYyzBjvH+q8cfxgkUCob2PBieYdzTrQs3jc80 eMOLcmjDuaDGRaOv9vYIrWqfGTZbkvgzXAyJ3FlpkMSCIxKujdyExkD3ZvfRqA6x1LEB 7lwqZ/1wrfKuIpKXP4Etkiz5CKWvsFDbFo1jJ/JMBuOod4jeG2ALEBw9oKmu0XvUjx9C CZ79PTf+ZsppiZyeJAJ0e01KRMvz64x0555sK/B1XVcPzhF5Rlq+bZgd5gfRhyI6/x+F wDow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694818136; x=1695422936; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Kq86mg3eRdpsafcpXL3Gsx54l0Vjtu7ZVdR51WnNflM=; b=N9kdRnQzcE2k6yVJZoq15ySFNcRUaf4ktbfuXpt4TY0/6Mo3VCf5hsxuC3MawxxcJz r/GAAKkUGWQO5+Du+L6tqrKMzUyxgqaKn9w3IQB2xuZyD8Frk802kPS90QY2BgKB7KN/ Q8XxjfAdSwseYoAFvPVLMQ6YbTwrh8QPsLM/ebsrKF+ORbb/n6DccJtoOryvRW3VMpsN +qDBIvD3oxJdCW9RKGMlZhG4emy9gNSoCSNP703MdxSbyABMr6sapDaKicIK5LKYo2v6 EWQS9O5TrO6lq523O30GgNU1iTF4hASMc5ZvnB/jLmAFrHv5OreVfni/WAyU88/gn9jy 7PMw== X-Gm-Message-State: AOJu0YxMEfzFSNtT6eIrVcnfFogljmftylHue/2xIxTDADXghfGZJ6b7 kjkntc1BQ56cxYeKxjoqVKEg8w== X-Google-Smtp-Source: AGHT+IGV8EQmN5iciBjKTh6qnafWh9qWiM4wQiJhWZJkGYYDZqNaPa1xjuzUpW3/8KCcC5Nt80/rUQ== X-Received: by 2002:a81:6c4c:0:b0:56d:4d1e:74ab with SMTP id h73-20020a816c4c000000b0056d4d1e74abmr7022615ywc.23.1694818136008; Fri, 15 Sep 2023 15:48:56 -0700 (PDT) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id z13-20020a81a24d000000b0054f9e7fed7asm1092349ywg.137.2023.09.15.15.48.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Sep 2023 15:48:54 -0700 (PDT) Date: Fri, 15 Sep 2023 15:48:46 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@ripple.attlocal.net To: Matthew Wilcox cc: Hugh Dickins , Jens Axboe , Andrew Morton , "Kirill A . Shutemov" , Hannes Reineke , David Hildenbrand , John Hubbard , linux-mm@kvack.org, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] block: Remove special-casing of compound pages In-Reply-To: Message-ID: <1fa6119e-6e5-5e8-21d8-571814f6a99e@google.com> References: <20230814144100.596749-1-willy@infradead.org> <94635da5-ce28-a8fb-84e3-7a9f5240fe6a@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: F1E9AC0004 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: gq1joi914fj9f8c876d7zfkcqtddcybj X-HE-Tag: 1694818136-689739 X-HE-Meta: U2FsdGVkX1/q8WTT2+SaZa2jcyMqHRmlnGHIHtKrtArlhQUA7INSEfv9s/xh/JomVUMzuWC7sKOgrnXZU4JjfgJ0ITO3oFxaSaWnuR0qbBh8hmr5oeYmSMhpPQWLzcVIc8rNzknugnAJE0cDQyXmzTbTobUtLJmFb4PI2iofN6682pAbOi0TnlopILoorbgmRepoCEEpYxU0UUYSnSeE3NTbvSOoD6lIweC5rKBwfIogHzS2w/8K4Ap257BChl82lL8Wsng0093J3NV9Z08H19ImNIVWPch+77jgoeOrDQM6wpSp/elC2vHoYPNGYRL/6EeyJ0seKtFE2rS8Sqh+z4q4VlRghXIwFvJ2tcq3PSCxa1A2uIJeLVqZ+jOQc5dE2GRg/iqY7Hyn/waiJY2Uj8DX/ZQR/3FCP5BxKDEUVDHNgCxzMpucUdVKNfAD5z//7eKUXF5+ZKXG6EhByr6s2dYwaqwcFhOZFkS5fWMddl3WZn4KucGLKTPyJ8PkoHyoOUhWVV6y+9mnQyj7JJoCEFbolGKK/+7cePF1ynqG5RFjc4Vco6dZ8dZBD3yetbC8TeqexlkP68Z14J7CBOjs56rBsEl5VeY2zMtl2wYChvRvj3KQjlbHEgGO9vqsAbiFSH+H+99q80jr7T7zsLqBjxnTE0XIMCJSl+YFlPioS3Wzg/lhA1Urb5ZFqYwX//v3hpv1FCN0C1vA4OnrpsVwANHgJFEYxjkvROQiAoF9KA2avj18US1TeJqiWSdXP6U9cIg7Na3YB5wIT2lnSURm+s8rGN+JWnoQBdjiFiuKVjpUQD0Mk4H+tSEuNEJXB7pUXPlei97jB1nGsj+YC4BT5rkrUMZrgTCWbZ+j+NZhlZUKkKlEVrjXqDiUPLUL4DJQsPGm0PW/l4RzQ0kdbxsx+BZ67QWPSDtjJ5ySlVudTMhiTxPJ/PaIVDeM3lYFK5I58HTJDrw5GZmsMoRIwJG 32tGswCL LW2MzGZyoFsWG2E/MKeAIaeQX1/IhSsAVEZ/EJTRiOuFC8RTRv8gqrf+llcEAeDvtlfgPBE7Aty1I8Bhdvg+8JpyNoNmj+KzisixOt3+qol7SdXp50Gd0NfkWLMRCA5/6kfNpDS/a/UMiW/cVx8TyhoVhE9wtc5N3YllnXtlhbdDTlvt4zJWQltZ5SpCVXT61CVqRA+RK31JoLvY+aW7E2yOO55JMXHGUhf5eyuFRWaCD6Y0vz6Ue91xT3RUivJ3+KyfuxbL467NcuRFjfYNOKnEDy0oIYgjk9j8HfNu4diU1Xp6EbwjMFbLSssVzqYLi4D6yusueXWmAaNY0VulSJj9rF2XEJIyueU41eAOQTIPULRo= 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 Fri, 15 Sep 2023, Matthew Wilcox wrote: > On Wed, Aug 16, 2023 at 01:27:17PM -0700, Hugh Dickins wrote: > > > This problem predates the folio work; it could for example have been > > > triggered by mmaping a THP in tmpfs and using that as the target of an > > > O_DIRECT read. > > > > > > Fixes: 800d8c63b2e98 ("shmem: add huge pages support") > > > > No. It's a good catch, but bug looks specific to the folio work to me. > > > > Almost all shmem pages are dirty from birth, even as soon as they are > > brought back from swap; so it is not necessary to re-mark them dirty. > > > > The exceptions are pages allocated to holes when faulted: so you did > > get me worried as to whether khugepaged could collapse a pmd-ful of > > those into a THP without marking the result as dirty. > > > > But no, in v6.5-rc6 the collapse_file() success path has > > if (is_shmem) > > folio_mark_dirty(folio); > > and in v5.10 the same appears as > > if (is_shmem) > > set_page_dirty(new_page); > > > > (IIRC, that or marking pmd dirty was missed from early shmem THP > > support, but fairly soon corrected, and backported to stable then. > > I have a faint memory of versions which assembled pmd_dirty from > > collected pte_dirtys.) > > > > And the !is_shmem case is for CONFIG_READ_ONLY_THP_FOR_FS: writing > > into those pages, by direct IO or whatever, is already prohibited. > > > > It's dem dirty (or not dirty) folios dat's the trouble! > > Thanks for the correction! Could it happen with anon THP? > They're not kept dirty from birth ... are they? Anon pages, THP or other, are not marked dirty from birth, right. But nor are they considered for freeing without writeout: shrink_folio_list() does add_to_swap() on them without considering dirtiness, and add_to_swap() does an unconditional folio_mark_dirty(). Well, not quite unconditional: it is conditional on allocating swap, but shrink_folio_list() just reactivates when swap is not allocated. So, I see no opportunity for data loss there. When it's read back from swap later on, the folio will be left clean while it matches swap: I haven't bothered to recheck the latest details of what happens when it's CoWed, or the swap is deleted, those details won't matter given the behavior above. But might there be a direct IO problem while that anon folio (large or small) remains clean in swapcache, when reclaim's pageout() might be liable to free it without rewriting? There ought not to be: get_user_pages()/follow_page_pte() have taken care of that for many years with the FOLL_TOUCH+FOLL_WRITE if (flags & FOLL_TOUCH) { if ((flags & FOLL_WRITE) && !pte_dirty(pte) && !PageDirty(page)) set_page_dirty(page); and follow_trans_huge_pmd() dirties the pmd when FOLL_TOUCH+FOLL_WRITE. I forget why follow_page_pte() prefers to dirty page rather than pte, but either approach should be good enough to avoid the data loss. However, I don't see equivalent FOLL_TOUCH+FOLL_WRITE code where get_user_pages_fast() goes its fast route; nor pin_user_pages_fast() used by lib/iov_iter.c; and it looks odd that pin_user_pages_remote() and pin_user_pages_unlocked() use FOLL_TOUCH but pin_user_pages() not. Problem? Not particularly for anon or for large, but for any? Or not a problem because of final set_page_dirty() or folio_mark_dirty() on release - only a problem while that PageCompound check remains? (Of course filesystems hate behind-the-back dirtying for other reasons, that they may lose the data without proper notice: separate discussion we'd better not get back into here.) I've spent much longer trying to answer this than I could afford, expect no more from me, back to you and GUP+PIN experts. Hugh