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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 327C8C433EF for ; Mon, 29 Nov 2021 18:42:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=HZzPmTk+WPKxi9kr1E0YZ+jskhPHVWPdD+n3PmYHO80=; b=4kBbReiAhh8Yh+ Axc7usDxXMOmawfCWay7PX2Y0NyDcqijiPCh1cxOEjbR7apmFIrmYsf8tR71m8KnSRKsf2Gj6s4w2 1y8Q3qVzafXcbQ5AjXZEABeYYwVbqGLI/8ScoN9JC0nQCsBspDLo7nlaU92WTFN5HPUt67IgeFGkK AnECjW12+mtwQ6bIAkVGaQgZQBTMLPcD1IB4s1j7GIMBy8p0cfJYmTDRN5bEy62OJUbRZlB3ssYMo 6kn8vgOYPuR70hpHaz8iecTW0xki1eD+MKnV/xbTlfUhz/QpCoJXV+f62mmvE1K16NWYH7ILEjiBr cgzAfEf7FVasP1ayCecQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mrlaH-001q6P-6E; Mon, 29 Nov 2021 18:41:01 +0000 Received: from mail-ed1-x530.google.com ([2a00:1450:4864:20::530]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mrlaD-001q5P-OT for linux-arm-kernel@lists.infradead.org; Mon, 29 Nov 2021 18:40:59 +0000 Received: by mail-ed1-x530.google.com with SMTP id e3so76024928edu.4 for ; Mon, 29 Nov 2021 10:40:57 -0800 (PST) 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=7TgPSN7BGol1Tl+v3cbObp6eM3owptNkUS6MUKapLgk=; b=dDhGyayvTiVZ54M7kQkeYpixbZJ21FDA4H+XgW5qfma9xVodQ+ykL0UVDfVCnj3oGS XCxC3zzyDIbY203VjKnyF4PRo5sWL2wGeRMysXQpu6w6X3f1ZKzEOJPs+7uJC0mulw3W kWegC2qcRszmcWmuLJGCfK9FiXD9y5MpmqsEo= 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=7TgPSN7BGol1Tl+v3cbObp6eM3owptNkUS6MUKapLgk=; b=pWI1FXaU72AUP+OtWcs0NgdM65OwiK55CwOOGtIVSxkap2GoX405G4ro7t9oJ1nYrI oz3iGENVre6nmGfx42VKWv3eDzVv4y2mRqa/OpDHq1afA4PngHRNTuhCnf62qlWaQRw8 Mp/RchaEJLajqLcj0QsIuAZ7tngx4AsEHJc5CQ0TPcIYdUmUYzoFDvpMeCW1X24ccL+I Zc96erErbTL8Jp8XbpmYi+znYFHrmORX35BmytZEiGcSsHdaprQbDKHxfVWVbRvdiXCc CI0qUyvfQA1qGAM+wwgaPJc9RgUzvU8FVt1glKqYttIEgNufuvZNUrbWilvAuTs87jxG W6+Q== X-Gm-Message-State: AOAM532qgg00lnOD1703JaRezhHR3Mnzvge4zvxKHuk57+Jcoj6BZv5N M3dqPPiJGpyXkCmjn3zJ6VFqnRO5HuDdanP86sU= X-Google-Smtp-Source: ABdhPJwTpIlBuHySfsXibEgO2SeRb56hXdMW/L5+8mqALeO7jrdM16KPoc1dnWHRJt5oAMvu2Ww9MQ== X-Received: by 2002:a17:907:7250:: with SMTP id ds16mr61946172ejc.54.1638211256031; Mon, 29 Nov 2021 10:40:56 -0800 (PST) Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com. [209.85.221.43]) by smtp.gmail.com with ESMTPSA id y17sm10675553edd.31.2021.11.29.10.40.54 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 29 Nov 2021 10:40:55 -0800 (PST) Received: by mail-wr1-f43.google.com with SMTP id a18so38947651wrn.6 for ; Mon, 29 Nov 2021 10:40:54 -0800 (PST) X-Received: by 2002:adf:f8c3:: with SMTP id f3mr35865238wrq.495.1638211254717; Mon, 29 Nov 2021 10:40:54 -0800 (PST) MIME-Version: 1.0 References: <20211124192024.2408218-1-catalin.marinas@arm.com> <20211124192024.2408218-4-catalin.marinas@arm.com> <20211127123958.588350-1-agruenba@redhat.com> In-Reply-To: From: Linus Torvalds Date: Mon, 29 Nov 2021 10:40:38 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 3/3] btrfs: Avoid live-lock in search_ioctl() on hardware with sub-page faults To: Catalin Marinas Cc: Andreas Gruenbacher , Matthew Wilcox , Josef Bacik , David Sterba , Al Viro , Andrew Morton , Will Deacon , linux-fsdevel , LKML , Linux ARM , linux-btrfs X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211129_104057_829251_2EFB9B70 X-CRM114-Status: GOOD ( 20.27 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Nov 29, 2021 at 7:36 AM Catalin Marinas wrote: > > That's what this series does when it probes the whole range in > fault_in_writeable(). The main reason was that it's more efficient to do > a read than a write on a large range (the latter dirtying the cache > lines). The more this thread goes on, the more I'm starting to think that we should just make "fault_in_writable()" (and readable, of course) only really work on the beginning of the area. Not just for the finer-granularity pointer color probing, but for the page probing too. I'm looking at our current fault_in_writeable(), and I'm going (a) it uses __put_user() without range checks, which is really not great (b) it looks like a disaster from another standpoint: essentially user-controlled loop size with no limit checking, no preemption, and no check for fatal signals. Now, (a) should be fixed with a access_ok() or similar. And (b) can easily be fixed multiple ways, with one option simply just being adding a can_resched() call and checking for fatal signals. But faulting in the whole region is actually fundamentally wrong in low-memory situations - the beginning of the region might be swapped out by the time we get to the end. That's unlikely to be a problem in real life, but it's an example of how it's simply not conceptually sensible. So I do wonder why we don't just say "fault_in_writable will fault in _at_most_ X bytes", and simply limit the actual fault-in size to something reasonable. That solves _all_ the problems. It solves the lack of preemption and fatal signals (by virtue of just limiting the amount of work we do). It solves the low memory situation. And it solves the "excessive dirty cachelines" case too. Of course, we want to have some minimum bytes we fault in too, but that minimum range might well be "we guarantee at least a full page worth of data" (and in practice make it a couple of pages). It's not like fault_in_writeable() avoids page faults or anything like that - it just moves them around. So there's really very little reason to fault in a large range, and there are multiple reasons _not_ to do it. Hmm? Linus _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel