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 9C468C433F5 for ; Wed, 9 Mar 2022 20:57:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1ED3B8D0002; Wed, 9 Mar 2022 15:57:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 19BF48D0001; Wed, 9 Mar 2022 15:57:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 064D48D0002; Wed, 9 Mar 2022 15:57:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0157.hostedemail.com [216.40.44.157]) by kanga.kvack.org (Postfix) with ESMTP id EA2DA8D0001 for ; Wed, 9 Mar 2022 15:57:48 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id ADFFC8249980 for ; Wed, 9 Mar 2022 20:57:48 +0000 (UTC) X-FDA: 79226059416.25.F1F6CAE Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf26.hostedemail.com (Postfix) with ESMTP id 117E514000D for ; Wed, 9 Mar 2022 20:57:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1646859467; 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=xw6hw1HS79I7piNNK9ZnlZMSG43eCGoaiA/W2f4I5E0=; b=If8jyOiU+JaDOLnvzRlKG4f4EfktQNNqqSNYqgkzRsQcMWkp3L2J7vMGL6zlEfB7Kz3iSH hMPuFDMoG3yDWP7gDUzxsDX5iydpTUIksC2EGYMC/od+4H9vTfoeX3c2GFIQB7rE+wPtL4 DR64kbssyToIDTstVlRKwwHreiG0n/k= 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-504-AdElkf7cOK-ImjK4ZCPNMA-1; Wed, 09 Mar 2022 15:57:46 -0500 X-MC-Unique: AdElkf7cOK-ImjK4ZCPNMA-1 Received: by mail-wm1-f72.google.com with SMTP id l2-20020a1ced02000000b0038482a47e7eso3094356wmh.5 for ; Wed, 09 Mar 2022 12:57:46 -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=xw6hw1HS79I7piNNK9ZnlZMSG43eCGoaiA/W2f4I5E0=; b=C88AXZ+0Lj4SE70D4JA6Id9DpK4XNSUMni5NiaKunGyasIbTjk5d4H/MjYcFCVvSLa ckPr6mBM0pQnZ69DMmodk3eZxDXg4aJigUzAOEdjN6Yw9Ix7+fwxePtCcDr5tjhHQY62 ynNoJ2/5x6vXp1PuQkSBitLrvKOx0SDKXSmRvYJDjJfLZBAFmQW0J/t4GMt8upmdIybi 1P+XPoVRw8W72xKnRJs7Nyu99G2enEF8MT+rwJBfj1PhVcstvkFGXbkaV7TGW7IeadT1 RX4SHmGMZ9tlAl2KRpk4VA0CAv0TZkDO+SInlzur2Zrre0RWCrBo0XAre1a5hqjjGOOB A5pw== X-Gm-Message-State: AOAM531VKPwLqpt8r7r+4qCJqri94NvUFezhkm7iBZ9VQV+38at95XV1 soggEiA/miHlYulfbCR21ebct2z91juawJOWIV3to/CVpBIw4Ua/6JK6pkqDb+Lcppa674XHGcP ZaKKG2on/MJ96vShXvRJYkTW5ZN0= X-Received: by 2002:a05:600c:4a12:b0:389:9c7d:5917 with SMTP id c18-20020a05600c4a1200b003899c7d5917mr997965wmp.0.1646859464894; Wed, 09 Mar 2022 12:57:44 -0800 (PST) X-Google-Smtp-Source: ABdhPJwkBn5sHebB/8AskukJ70ApHkZsY22IFF92X45WXzmERVLwWMLiZIb0VspQbtQmg8kWGP6WnrmcmRq5iZFnoK0= X-Received: by 2002:a05:600c:4a12:b0:389:9c7d:5917 with SMTP id c18-20020a05600c4a1200b003899c7d5917mr997951wmp.0.1646859464684; Wed, 09 Mar 2022 12:57:44 -0800 (PST) MIME-Version: 1.0 References: <20220309184238.1583093-1-agruenba@redhat.com> In-Reply-To: From: Andreas Gruenbacher Date: Wed, 9 Mar 2022 21:57:32 +0100 Message-ID: Subject: Re: Buffered I/O broken on s390x with page faults disabled (gfs2) To: Linus Torvalds , Filipe Manana Cc: Catalin Marinas , David Hildenbrand , 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: 117E514000D X-Stat-Signature: 9jg7kofp9i5qc1d8zhtmkdayjm5xyit8 Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=If8jyOiU; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf26.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: 1646859467-676450 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 Wed, Mar 9, 2022 at 8:08 PM Linus Torvalds wrote: > On Wed, Mar 9, 2022 at 10:42 AM Andreas Gruenbacher wrote: > > From what I took from the previous discussion, probing at a sub-page > > granularity won't be necessary for bytewise copying: when the address > > we're trying to access is poisoned, fault_in_*() will fail; when we get > > a short result, that will take us to the poisoned address in the next > > iteration. > > Sadly, that isn't actually the case. > > It's not the case for GUP (that page aligns things), and it's not the > case for fault_in_writeable() itself (that also page aligns things). As long as the fault_in_*() functions probe the exact start address, they will detect when that address is poisoned. They can advance page-wise after that and it doesn't matter if they skip poisoned addresses. When the memory range is then accessed, that may fail at a poisoned address. The next call to fault_in_*() will be with that poisoned address as the start address. So it's the unaligned probing at the start in the fault_in_*() functions that's essential, and fault_in_readable(), fault_in_writeable(), and fault_in_safe_writeable() now all do that probing. > But more importantly, it's not actually the case for the *users* > either. Not all of the users are byte-stream oriented, and I think it > was btrfs that had a case of "copy a struct at the beginning of the > stream". And if that copy failed, it wouldn't advance by as many bytes > as it got - it would require that struct to be all fetched, and start > from the beginning. > > So we do need to probe at least a minimum set of bytes. Probably a > fairly small minimum, but still... There are only a few users like that, and they can be changed to pass back the actual address that fails so that that address can be probed instead of probing every 128 bytes of the entire buffer on arm64. Thanks, Andreas