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 9D2F3C433F5 for ; Thu, 10 Mar 2022 18:00:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2ED308D0003; Thu, 10 Mar 2022 13:00:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 29C458D0001; Thu, 10 Mar 2022 13:00:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 164F48D0003; Thu, 10 Mar 2022 13:00:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0051.hostedemail.com [216.40.44.51]) by kanga.kvack.org (Postfix) with ESMTP id 076DA8D0001 for ; Thu, 10 Mar 2022 13:00:49 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id AA7D18249980 for ; Thu, 10 Mar 2022 18:00:48 +0000 (UTC) X-FDA: 79229242176.17.F36C4A3 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf10.hostedemail.com (Postfix) with ESMTP id 3225EC002E for ; Thu, 10 Mar 2022 18:00:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1646935246; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=TDJX0xDz3mzKMSilMItog0LpILbVyzwdCnzO5jpxac8=; b=IZUgXCVX4OVc2TP27mnf4bHGTs9q9vaqXRhsRPz3AJPcvR/4i4dZcVEYPvio8rZ8F0vTED C50h/ITUc/W2fg2+cMJGXPBFk0T/Bk7pB246S7t68X3TbuuKuxAWuvq6fOn1O2crdHk1yb cPxraiTTnNOJbMQCBv4C4mDaENbYnRk= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-250-3f3uN3QPOemN9rtsN8PM0A-1; Thu, 10 Mar 2022 13:00:45 -0500 X-MC-Unique: 3f3uN3QPOemN9rtsN8PM0A-1 Received: by mail-wm1-f72.google.com with SMTP id m34-20020a05600c3b2200b0038115c73361so2335516wms.5 for ; Thu, 10 Mar 2022 10:00:44 -0800 (PST) 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=TDJX0xDz3mzKMSilMItog0LpILbVyzwdCnzO5jpxac8=; b=JD9B4NtQ0Bijti5CtA+fEgKV+qWprlj+shComLk6zgvP+RuVTmFfCCA45DA/QaXdND N0LFk0ooK78E5QRmztOuUwj0NBrfAC1RZXyLBkvKA7WKchJLiQL0cfWZp1p+ayf9XMF1 yH6I8MSCJh2x2IcnA2bPuWy0FlDhKjOaJb8eCviTW+Hu2v25o3a0Xp0zm+XR3Ffdg2a2 wzVFYOqKaFeDGFrWzhz3xQTQHu1oYWUhF6QvZSmgca35SmL8K10MrRTxM4qf2b8IJA37 xLGMYIDWtfrr3SmUT5QZsDt6M1hAaoPDzKQiMhovyftIXcBZgpoQmbxUZTmnXI0IuKTb iGzA== X-Gm-Message-State: AOAM532BH+wWvJbFmBXQ72ZO2qdnGWLscWxIlkvhA0a764ekI1IG1BwH MMcz5NhawtnnXH5FSsywmUOIUWo693w639ShAqNz2GJnEmo55MhW1wzrULor+8fg7Oo1PafokBw Jb7wn70LMfxE8fXJGbUEqqBzFCRk= X-Received: by 2002:a05:6000:10c6:b0:1f1:e562:bee2 with SMTP id b6-20020a05600010c600b001f1e562bee2mr4462488wrx.654.1646935243571; Thu, 10 Mar 2022 10:00:43 -0800 (PST) X-Google-Smtp-Source: ABdhPJw6h+yWNd0DE//pCGjzqYuSv/FVk6BVA6aiZwKiI0R6R6JjBtjKjPJy8mCZVuV3axvW4bM3405mckF+LKcT5DI= X-Received: by 2002:a05:6000:10c6:b0:1f1:e562:bee2 with SMTP id b6-20020a05600010c600b001f1e562bee2mr4462478wrx.654.1646935243378; Thu, 10 Mar 2022 10:00:43 -0800 (PST) MIME-Version: 1.0 References: <02b20949-82aa-665a-71ea-5a67c1766785@redhat.com> In-Reply-To: <02b20949-82aa-665a-71ea-5a67c1766785@redhat.com> From: Andreas Gruenbacher Date: Thu, 10 Mar 2022 19:00:31 +0100 Message-ID: Subject: Re: Buffered I/O broken on s390x with page faults disabled (gfs2) To: David Hildenbrand Cc: Linus Torvalds , Alexander Viro , linux-s390 , Linux-MM , linux-fsdevel , linux-btrfs X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 3225EC002E X-Stat-Signature: p6muw5su5h53pypf8335mpgt199iusfm Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=IZUgXCVX; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf10.hostedemail.com: domain of agruenba@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=agruenba@redhat.com X-HE-Tag: 1646935246-85044 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 Thu, Mar 10, 2022 at 6:13 PM David Hildenbrand wrote: > > On 08.03.22 20:27, Linus Torvalds wrote: > > On Tue, Mar 8, 2022 at 9:40 AM Linus Torvalds > > wrote: > >> > >> Hmm. The futex code actually uses "fixup_user_fault()" for this case. > >> Maybe fault_in_safe_writeable() should do that? > > > > .. paging all the bits back in, I'm reminded that one of the worries > > was "what about large areas". > > > > But I really think that the solution should be that we limit the size > > of fault_in_safe_writeable() to just a couple of pages. > > > > Even if you were to fault in gigabytes, page-out can undo it anyway, > > so there is no semantic reason why that function should ever do more > > than a few pages to make sure. There's already even a comment about > > how there's no guarantee that the pages will stay. > > > > Side note: the current GUP-based fault_in_safe_writeable() is buggy in > > another way anyway: it doesn't work right for stack extending > > accesses. > > > > So I think the fix for this all might be something like the attached > > (TOTALLY UNTESTED)! > > > > Comments? Andreas, mind (carefully - maybe it is totally broken and > > does unspeakable acts to your pets) testing this? > > I'm late to the party, I agree with the "stack extending accesses" issue > and that using fixup_user_fault() looks "cleaner" than FOLL_TOUCH. > > > I'm just going to point out that fixup_user_fault() on a per-page basis > is sub-optimal, especially when dealing with something that's PMD- or > PUD-mapped (THP, hugetlb, ...). In contrast, GUP is optimized for that. > > So that might be something interesting to look into optimizing in the > future, if relevant in practice. Not sure how we could return that > information the best way to the caller ("the currently faulted > in/present page ends at address X"). Yes, this applies to fault_in_iov_iter_readable() as well, as it is based on fault_in_readable(). It's probably not a super urgent optimization as the buffers faulted in are immediately accessed. Thanks, Andreas > For the time being, the idea LGTM. > > -- > Thanks, > > David / dhildenb >