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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id ED29FC433FE for ; Thu, 10 Mar 2022 17:13:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241261AbiCJROP (ORCPT ); Thu, 10 Mar 2022 12:14:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43888 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234954AbiCJROP (ORCPT ); Thu, 10 Mar 2022 12:14:15 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id EFC0517E35D for ; Thu, 10 Mar 2022 09:13:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1646932392; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=K0g7kEPpgKBPzdK7oqMjhrzrQPzP1oj31vajQi/QH0g=; b=dlpHnE/4VqpQfLD0xbXP+TWM67zGWfxPibSvjDKrAdzm3wDf2VrKPTmemLnIy74ktXaFYC dqGAkVszIY7L4ZwH4lxTdH1l3KNSkUqrkWH6D4cIL1/5xjzFtodmQ5gUX+JgY3cImA1ZwW IySKhkmk+APR/MKyZdsTXQF1bg22frI= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-135-68wFkrn4OJOcBPClBKb8Jg-1; Thu, 10 Mar 2022 12:13:11 -0500 X-MC-Unique: 68wFkrn4OJOcBPClBKb8Jg-1 Received: by mail-wm1-f70.google.com with SMTP id 10-20020a1c020a000000b0037fae68fcc2so4312285wmc.8 for ; Thu, 10 Mar 2022 09:13:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:organization:subject :in-reply-to:content-transfer-encoding; bh=K0g7kEPpgKBPzdK7oqMjhrzrQPzP1oj31vajQi/QH0g=; b=TpDGs2U9nnBWkPPbFmkJeud5yrpfTVagYqQixQQxWoYBGp3oxOnbEncKlyOE8un06L Gai2Ylabw+C42YZyrqkCXUXWpXOhAlEyY5wgeZORoW2fFM6RM8FyP4lO2xpr3pj3+CmR tN3spc8HbB6kaGIrFgWGbKTk8fMh3j95ypj+ypaPtTydhzkLSuYCKMjcskiQOrrNb1ii QH4MLAT7F9gXNIqXcwu3W+RfJ+eTpxiN2pb/BkGRx1NfYenA/aR16ag7rOeST/ciApJt tOpAilvwvHQ7yhC/0wuvIUwlYA89G4D4nWqbQ3zC4fOBDVUdAYmAzWkxZSbhL6r67cUV KVJw== X-Gm-Message-State: AOAM530m02JAsJyqlPYfXBIs3sZUs++5lPpzYpX1aC+O1cscRCrl9ogi H3GN1I1zjgeDoNQxqGPyNVhi9PEZLqfPr6SgjHlNAMrJ0TL+hxQ9vkCuATC5sdXIjD0/RJp2MhG gXiEwBWcltcG4EkQkRKB/UQ== X-Received: by 2002:a05:6000:1683:b0:1f1:eb7c:be70 with SMTP id y3-20020a056000168300b001f1eb7cbe70mr4261148wrd.129.1646932390256; Thu, 10 Mar 2022 09:13:10 -0800 (PST) X-Google-Smtp-Source: ABdhPJw3SkTi3yW7UBBeX1DEMnFy33opyiuGAlZsjFfPFWjJgPjyUpAftbHJ/wJhhj/ZTUEnc+Lavw== X-Received: by 2002:a05:6000:1683:b0:1f1:eb7c:be70 with SMTP id y3-20020a056000168300b001f1eb7cbe70mr4261126wrd.129.1646932389931; Thu, 10 Mar 2022 09:13:09 -0800 (PST) Received: from ?IPV6:2003:cb:c708:6100:d527:e3ca:6293:8440? (p200300cbc7086100d527e3ca62938440.dip0.t-ipconnect.de. [2003:cb:c708:6100:d527:e3ca:6293:8440]) by smtp.gmail.com with ESMTPSA id j15-20020a5d564f000000b0020371faf04fsm4545238wrw.67.2022.03.10.09.13.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Mar 2022 09:13:09 -0800 (PST) Message-ID: <02b20949-82aa-665a-71ea-5a67c1766785@redhat.com> Date: Thu, 10 Mar 2022 18:13:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.2 Content-Language: en-US To: Linus Torvalds Cc: Andreas Gruenbacher , Alexander Viro , linux-s390 , Linux-MM , linux-fsdevel , linux-btrfs References: From: David Hildenbrand Organization: Red Hat Subject: Re: Buffered I/O broken on s390x with page faults disabled (gfs2) In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-s390@vger.kernel.org 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 pactice. Not sure how we could return that information the best way to the caller ("the currently faulted in/present page ends at address X"). For the time being, the idea LGTM. -- Thanks, David / dhildenb