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 AD2A9C433EF for ; Thu, 10 Mar 2022 17:13:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 20FF68D0002; Thu, 10 Mar 2022 12:13:15 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1BEF98D0001; Thu, 10 Mar 2022 12:13:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 05FF78D0002; Thu, 10 Mar 2022 12:13:15 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id EBD8F8D0001 for ; Thu, 10 Mar 2022 12:13:14 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id C1380808D3 for ; Thu, 10 Mar 2022 17:13:14 +0000 (UTC) X-FDA: 79229122308.02.8474559 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf19.hostedemail.com (Postfix) with ESMTP id 21CE31A001A for ; Thu, 10 Mar 2022 17:13:13 +0000 (UTC) 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-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-443-CalME4MZPeq4rH18XD_CqA-1; Thu, 10 Mar 2022 12:13:11 -0500 X-MC-Unique: CalME4MZPeq4rH18XD_CqA-1 Received: by mail-wr1-f69.google.com with SMTP id a11-20020adffb8b000000b001efe754a488so1910245wrr.13 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=dbyCLfOCBfdHaICHNJu1+6lm+NJmK4PPU/wED4TlbvwoTePpi45vA2ZMNGjoF/MWux Y99mEwwokgVkpfepIM3SpvHyjU+V/um3k/GvGNsmBgSx90VQlfXNblFgHAUa7BjX08dh nLqojPOTdp9GiQAigthcJVMUGSktCCFz0K7S9bHxaHidVwU21w7+Q+sa4CvzD/ePVzRv BXLt/eGHxto5ibxNdk/V3CmmgC5axfJWJsrSXHzBc8GwTHfy86/qcYIhFmKbaN+q1JA3 3Ko2einAgFAjz/W/jtV3fA63blEveONM5GpACQl8pt5tBGTEStASKcNcnmslvBPVTL4D 2S+A== X-Gm-Message-State: AOAM532A3qkqUFXX2ZOLeVMNwMiF9vM5s3Bx9h3J4PGN3zfFahHK98+K SgoaP0vm9VAk/siQFPCvtZWx2b9JB/watvR+l0YEdSqxsFUTGclprhFXViScotafnnB4AoWLGbX NH/rGBrJPDbU= X-Received: by 2002:a05:6000:1683:b0:1f1:eb7c:be70 with SMTP id y3-20020a056000168300b001f1eb7cbe70mr4261147wrd.129.1646932390259; 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 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: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 21CE31A001A X-Stat-Signature: 35zhotxk6gajmgbhrpbjeip3g795ct5t X-Rspam-User: Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="dlpHnE/4"; spf=none (imf19.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam07 X-HE-Tag: 1646932393-668386 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 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