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 44A69C433EF for ; Fri, 10 Jun 2022 19:57:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9F0998D00DE; Fri, 10 Jun 2022 15:57:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9A02C8D00DC; Fri, 10 Jun 2022 15:57:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 868FB8D00DE; Fri, 10 Jun 2022 15:57:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 77EFE8D00DC for ; Fri, 10 Jun 2022 15:57:08 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 4DCE580FF8 for ; Fri, 10 Jun 2022 19:57:08 +0000 (UTC) X-FDA: 79563384936.16.3C9A94A Received: from mail-ej1-f44.google.com (mail-ej1-f44.google.com [209.85.218.44]) by imf09.hostedemail.com (Postfix) with ESMTP id 64CE6140065 for ; Fri, 10 Jun 2022 19:57:07 +0000 (UTC) Received: by mail-ej1-f44.google.com with SMTP id kq6so42346724ejb.11 for ; Fri, 10 Jun 2022 12:57:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cbo3zuKroI+lcNB8l3G6lMyG5+hX2/wCqhfxWwpR/X8=; b=e1a8+X4a2G8T9dfZsWM/hcMF1VbORV4FgyWhAbnoonR+yibE4kSmap/LSDsz+dipp/ YrpOVVXJJe9pigepdLX44KVYvp16Lb8Jp0p1bCbmNcrypmmLkx2CPWMgpUIYfGECnyVH MEbH5mprQzZ3KzhylqpoHWRRtQ3NbcVyWVuBA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cbo3zuKroI+lcNB8l3G6lMyG5+hX2/wCqhfxWwpR/X8=; b=YNcdPx/eWXG969SufUifSULAlMDsIzHUUpHgK9wdivUqhztkQ+jWebJgQTpEOFGS5V cbZad/SQ/4p8O/zC/UvcFljKdHp0AUilq4xkTelpcYI0H1Gn2kJ418seHnYiACDcvZOE JQylRUnvWmvk8qDRA7Xm7QEVpbw+Vg8IL6O5AJfOynA3FFcO5J6/7SW2uf5nZJ6bkQ0a oTMrDTZKcSE9iU+XxUhDE0QP4SmjRtgyMtEP0LpHB3U6doiIzMnwlaDceANh4E6agmiN KJG6gEs6E6pvu06Nk3F0v2SYaxuEd4FB5F7LAZmfIO6wQmhp2tUEwsEVsNoQjKjOYB7l Qw7Q== X-Gm-Message-State: AOAM532Kt/B41hl/O7Tn3dGM8UiyorMMhDg9JNKyGojJzlw0ZUexDD1P PmEqAvD0CyhSzMGbNlPRMAHIFGjDm+hWk2u5wY4= X-Google-Smtp-Source: ABdhPJwUXNgCpHB1B/+d4Xpyu3076iMft9CU0kDShS5VW6MIAaUkEhI5l3S4yMZyCDr9v/Qlzn5ehQ== X-Received: by 2002:a17:906:1d5:b0:712:3952:afc6 with SMTP id 21-20020a17090601d500b007123952afc6mr1706406ejj.564.1654891025770; Fri, 10 Jun 2022 12:57:05 -0700 (PDT) Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com. [209.85.221.43]) by smtp.gmail.com with ESMTPSA id r6-20020a05640251c600b0043153c9f4d0sm107665edd.11.2022.06.10.12.57.04 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Jun 2022 12:57:05 -0700 (PDT) Received: by mail-wr1-f43.google.com with SMTP id a15so29302475wrh.2 for ; Fri, 10 Jun 2022 12:57:04 -0700 (PDT) X-Received: by 2002:a5d:6da3:0:b0:219:bcdd:97cd with SMTP id u3-20020a5d6da3000000b00219bcdd97cdmr8497919wrs.274.1654891024619; Fri, 10 Jun 2022 12:57:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Linus Torvalds Date: Fri, 10 Jun 2022 12:56:48 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [GIT PULL] Folio fixes for 5.19 To: Matthew Wilcox Cc: linux-fsdevel , Linux-MM , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1654891027; 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=cbo3zuKroI+lcNB8l3G6lMyG5+hX2/wCqhfxWwpR/X8=; b=FzjpHpp6xQxWMZMMEIDG69q2Dz4KXTNOa+s6ie/PggTJIvkGSk83hxBo4FYv9T5IAIW/Ew KAs4V8MnJJyv5eEXb5S5RN3HgCZoX3AQQ8oXHpV/BBv23qMscsSYThkosEixCLVXCoJ+nR iJ1KNOfp/gsoXhUKS5mmRJdzViF8pTw= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=e1a8+X4a; dmarc=none; spf=pass (imf09.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.44 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1654891028; a=rsa-sha256; cv=none; b=PS4jA/z0AC/TPgk8cQGJVH2UtkU5QefhU94bTuUNKtall7Ab0s9xcjXOGQltytNgXc6f2E s3BlpeMRZaaJm/4Vmk3tVNHD8gwDQgGUAhz/tXcsXMGCsoLv4S0+JpbbXmDenC5lW1u2sz JldEn9wNQlQx/45B9uL7Qo2E/SYM4HY= X-Stat-Signature: nyyqe5cbn9ajsrub3yo39meakd11rs3t X-Rspamd-Queue-Id: 64CE6140065 Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=e1a8+X4a; dmarc=none; spf=pass (imf09.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.44 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1654891027-507921 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, Jun 10, 2022 at 12:22 PM Matthew Wilcox wrote: > > - Don't release a folio while it's still locked Ugh. I *hate* this patch. It's just incredibly broken. Yes, I've pulled this, but I have looked at that readahead_folio() function before, and I have despised it before, but this patch really drove home how incredibly broken that function is. Honestly, readahead_folio() returns a folio *AFTER* it has dropped the ref to that folio. That's broken to start with. It's not only really wrong to say "here's a pointer, and by the way, you don't actually hold a ref to it any more". It's doubly broken because it's *very* different from the similarly named readahead_page() that doesn't have that fundamental interface bug. But it's now *extra* broken now that you realize that the dropping of the ref was very very wrong, so you re-get the ref. WTF? As far as I can tell, ALL THE OTHER users of this broken function fall into two categories: (a) they are broken (see the exact same broken pattern in fs/erofs/fscache.c, for example) (b) they only use the thing as a boolean Anyway, I've pulled this, but I really seriously object to that completely mis-designed function. Please send me a follow-up patch that fixes it by just making the *callers* drop the refcount, instead of doing it incorrectly inside readahead_folio(). Alternatively, make "readahead_folio()" just return a boolean - so that the (b) case situation can continue the use this function - and create a new function that just exposes __readahead_folio() without this broken "drop refcount" behavior). Or explain why that "drop and retake ref" isn't (a) completely broken and racy (b) inefficient (c) returning a non-ref'd folio pointer is horribly broken interface to begin with because right now it's just disgusting in so many ways and this bug is just the last drop for me. Linus