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 970CFC433EF for ; Tue, 8 Mar 2022 08:37:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F2DEF8D0002; Tue, 8 Mar 2022 03:37:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EDC548D0001; Tue, 8 Mar 2022 03:37:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DA3D68D0002; Tue, 8 Mar 2022 03:37:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0216.hostedemail.com [216.40.44.216]) by kanga.kvack.org (Postfix) with ESMTP id CAA348D0001 for ; Tue, 8 Mar 2022 03:37:24 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 82E5BA8354 for ; Tue, 8 Mar 2022 08:37:24 +0000 (UTC) X-FDA: 79220564808.28.0433CC5 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf28.hostedemail.com (Postfix) with ESMTP id 05D32C0002 for ; Tue, 8 Mar 2022 08:37:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1646728643; 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=sjh+4BkQ3gG8RT83kzIqOaASDTboCinxDi5X/XejdlA=; b=B6b44PRK2T/wUkg39Yt7645KrfiMPsdH2+yvdTMRRA9zmwhc0YD4cTgg6W2tnO/390pIzd evoUcBjqJqwd0/A1W3lq1DWIECuNmlAeujDdx4GkjmZQPF9ljQL3CeElECwsRnd6LPCyEM DMdMwKWD7QbUUfAT5d7inIc7gMrO/DA= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-183--MvOt67nMOSUuLkgoifszQ-1; Tue, 08 Mar 2022 03:37:22 -0500 X-MC-Unique: -MvOt67nMOSUuLkgoifszQ-1 Received: by mail-wm1-f71.google.com with SMTP id j42-20020a05600c1c2a00b00381febe402eso889137wms.0 for ; Tue, 08 Mar 2022 00:37:22 -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:subject :content-language:from:to:cc:references:organization:in-reply-to :content-transfer-encoding; bh=sjh+4BkQ3gG8RT83kzIqOaASDTboCinxDi5X/XejdlA=; b=V5Jm7ld2I9N7YsI6bqig7+SEi97v5lAURsVpL7yac0UHXnjtH2Sekc4NUO031Sh4rI s2Qwp0l16Dc9W/LdwuBrFgO+xO1iJ+9riHf3+Gusre12La+X7W/Scfn5Cz6NZ8a3SJ5O 6WDMjp0nacTHQ5KmTBe1oflxwn6Kl/NqDt5Ay6z22pYWT9FfwgKuvrFfXItWAk9168O0 bkh75pDthXtgvLqLdE7du257zCdpAREv4rVl5Gz5Y8I1PDGrKUvJTjWaV7FxhWP3ay0U 33xATHvBe/Dgnr5oZ9+/SA+MrNIoMa9HuK+JEDM1yC3jnQjK25K8eu9Mo3WM+0YtOr74 Ldzg== X-Gm-Message-State: AOAM532aAD5J6O6tuwHKHdtF/aAVaVNfkNyzvLHP+h/EcwRA8k98RlM7 h3zuoX/9/nqRHMzYKT/4jlm2e8xvwdTH2l9tlVQl+Z9R89dyQXOsqokWZY5eSflpUQzUJFhNznI Uv5eIdUL0z0Q= X-Received: by 2002:adf:816e:0:b0:1e4:ad2b:cb24 with SMTP id 101-20020adf816e000000b001e4ad2bcb24mr11691846wrm.521.1646728641211; Tue, 08 Mar 2022 00:37:21 -0800 (PST) X-Google-Smtp-Source: ABdhPJxQBcKwzF57N6Un53kSGSzGI325n+/ccxVjmElkscP1Yxr8gOMMyOEXhFd7RHE7TuddTgn6PQ== X-Received: by 2002:adf:816e:0:b0:1e4:ad2b:cb24 with SMTP id 101-20020adf816e000000b001e4ad2bcb24mr11691826wrm.521.1646728640945; Tue, 08 Mar 2022 00:37:20 -0800 (PST) Received: from ?IPV6:2003:cb:c708:b000:acda:b420:16aa:6b67? (p200300cbc708b000acdab42016aa6b67.dip0.t-ipconnect.de. [2003:cb:c708:b000:acda:b420:16aa:6b67]) by smtp.gmail.com with ESMTPSA id h36-20020a05600c49a400b00382aa0b1619sm1525859wmp.45.2022.03.08.00.37.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Mar 2022 00:37:20 -0800 (PST) Message-ID: <2266e1a8-ac79-94a1-b6e2-47475e5986c5@redhat.com> Date: Tue, 8 Mar 2022 09:37:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: Buffered I/O broken on s390x with page faults disabled (gfs2) From: David Hildenbrand To: Linus Torvalds , Andreas Gruenbacher Cc: Alexander Viro , linux-s390 , Linux-MM , linux-fsdevel , linux-btrfs References: Organization: Red Hat 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: 05D32C0002 X-Stat-Signature: uxfiqeeg8fs6dax1ic1d31mdoh841cim X-Rspam-User: Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=B6b44PRK; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf28.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com X-Rspamd-Server: rspam03 X-HE-Tag: 1646728643-956547 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 09:21, David Hildenbrand wrote: > On 08.03.22 00:18, Linus Torvalds wrote: >> On Mon, Mar 7, 2022 at 2:52 PM Andreas Gruenbacher wrote: >>> >>> After generic_file_read_iter() returns a short or empty read, we fault >>> in some pages with fault_in_iov_iter_writeable(). This succeeds, but >>> the next call to generic_file_read_iter() returns -EFAULT and we're >>> not making any progress. >> >> Since this is s390-specific, I get the very strong feeling that the >> >> fault_in_iov_iter_writeable -> >> fault_in_safe_writeable -> >> __get_user_pages_locked -> >> __get_user_pages >> >> path somehow successfully finds the page, despite it not being >> properly accessible in the page tables. > > As raised offline already, I suspect > > shrink_active_list() > ->page_referenced() > ->page_referenced_one() > ->ptep_clear_flush_young_notify() > ->ptep_clear_flush_young() > > which results on s390x in: > > static inline pte_t pte_mkold(pte_t pte) > { > pte_val(pte) &= ~_PAGE_YOUNG; > pte_val(pte) |= _PAGE_INVALID; > return pte; > } > > static inline int ptep_test_and_clear_young(struct vm_area_struct *vma, > unsigned long addr, pte_t *ptep) > { > pte_t pte = *ptep; > > pte = ptep_xchg_direct(vma->vm_mm, addr, ptep, pte_mkold(pte)); > return pte_young(pte); > } > > > _PAGE_INVALID is the actual HW bit, _PAGE_PRESENT is a > pure SW bit. AFAIU, pte_present() still holds: > > static inline int pte_present(pte_t pte) > { > /* Bit pattern: (pte & 0x001) == 0x001 */ > return (pte_val(pte) & _PAGE_PRESENT) != 0; > } > > > pte_mkyoung() will revert that action: > > static inline pte_t pte_mkyoung(pte_t pte) > { > pte_val(pte) |= _PAGE_YOUNG; > if (pte_val(pte) & _PAGE_READ) > pte_val(pte) &= ~_PAGE_INVALID; > return pte; > } > > > and pte_modify() will adjust it properly again: > > /* > * The following pte modification functions only work if > * pte_present() is true. Undefined behaviour if not.. > */ > static inline pte_t pte_modify(pte_t pte, pgprot_t newprot) > { > pte_val(pte) &= _PAGE_CHG_MASK; > pte_val(pte) |= pgprot_val(newprot); > /* > * newprot for PAGE_NONE, PAGE_RO, PAGE_RX, PAGE_RW and PAGE_RWX > * has the invalid bit set, clear it again for readable, young pages > */ > if ((pte_val(pte) & _PAGE_YOUNG) && (pte_val(pte) & _PAGE_READ)) > pte_val(pte) &= ~_PAGE_INVALID; > /* > * newprot for PAGE_RO, PAGE_RX, PAGE_RW and PAGE_RWX has the page > * protection bit set, clear it again for writable, dirty pages > */ > if ((pte_val(pte) & _PAGE_DIRTY) && (pte_val(pte) & _PAGE_WRITE)) > pte_val(pte) &= ~_PAGE_PROTECT; > return pte; > } > > > > Which leaves me wondering if there is a way in GUP whereby > we would lookup that page and not clear _PAGE_INVALID, > resulting in GUP succeeding but faults via the MMU still > faulting on _PAGE_INVALID. follow_page_pte() has this piece of code: if (flags & FOLL_TOUCH) { if ((flags & FOLL_WRITE) && !pte_dirty(pte) && !PageDirty(page)) set_page_dirty(page); /* * pte_mkyoung() would be more correct here, but atomic care * is needed to avoid losing the dirty bit: it is easier to use * mark_page_accessed(). */ mark_page_accessed(page); } Which at least to me suggests that, although the page is marked accessed and GUP succeeds, that the PTE might still have _PAGE_INVALID set after we succeeded GUP. On s390x, there is no HW dirty bit, so we might just be able to do a proper pte_mkyoung() here instead of the mark_page_accessed(). -- Thanks, David / dhildenb