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 X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 51E05C33CB6 for ; Wed, 22 Jan 2020 06:13:03 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 180702465A for ; Wed, 22 Jan 2020 06:13:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="OQ8zA9MD" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 180702465A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8EB406B0003; Wed, 22 Jan 2020 01:13:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 89BAF6B0005; Wed, 22 Jan 2020 01:13:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7B0E76B0007; Wed, 22 Jan 2020 01:13:02 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0226.hostedemail.com [216.40.44.226]) by kanga.kvack.org (Postfix) with ESMTP id 64CE56B0003 for ; Wed, 22 Jan 2020 01:13:02 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 2E065248C for ; Wed, 22 Jan 2020 06:13:02 +0000 (UTC) X-FDA: 76404252204.27.woman08_54a17c626635f X-HE-Tag: woman08_54a17c626635f X-Filterd-Recvd-Size: 3733 Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by imf15.hostedemail.com (Postfix) with ESMTP for ; Wed, 22 Jan 2020 06:13:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579673580; 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=m9Qrc1hfBsH0AmAxE/zKcZWB088YD/ANA/bpl7vjqAI=; b=OQ8zA9MDlJg/+GLswRQJJj0MR83E+XB5HWwi9fzjwy6M8QFloSGVaUyU3zBOhYJqAq58Ri wOB1B2H+OXFPcqw2ITS9HNienxdPuUSeabv9xv+49+8NpmfLEJwm2ckLqe9LxMvBB0N0ga Ue/5VtOJqTBt0TYbW14VxzwWaaqwgg0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-7-CsAYPkPCOL21plJ58PJWyA-1; Wed, 22 Jan 2020 01:12:56 -0500 X-MC-Unique: CsAYPkPCOL21plJ58PJWyA-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 2BE988017CC; Wed, 22 Jan 2020 06:12:55 +0000 (UTC) Received: from redhat.com (ovpn-112-7.rdu2.redhat.com [10.10.112.7]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 49895860EB; Wed, 22 Jan 2020 06:12:53 +0000 (UTC) Date: Tue, 21 Jan 2020 22:09:51 -0800 From: Jerome Glisse To: Gao Xiang Cc: lsf-pc@lists.linux-foundation.org, Andrea Arcangeli , linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org, linux-mm@kvack.org Subject: Re: [LSF/MM/BPF TOPIC] Generic page write protection Message-ID: <20200122060951.GA77704@redhat.com> References: <20200122023222.75347-1-jglisse@redhat.com> <20200122042832.GA6542@hsiangkao-HP-ZHAN-66-Pro-G1> <20200122052118.GE76712@redhat.com> <20200122055219.GC6542@hsiangkao-HP-ZHAN-66-Pro-G1> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20200122055219.GC6542@hsiangkao-HP-ZHAN-66-Pro-G1> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Content-Transfer-Encoding: quoted-printable 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, Jan 22, 2020 at 01:52:26PM +0800, Gao Xiang wrote: > On Tue, Jan 21, 2020 at 09:21:18PM -0800, Jerome Glisse wrote: >=20 > >=20 > >=20 > > The block device code only need the mapping on io error and they are > > different strategy depending on individual fs. fs using buffer_head > > can easily be updated. For other they are different solution and they > > can be updated one at a time with tailor solution. >=20 > If I did't misunderstand, how about post-processing fs code without > some buffer_head but page->private used as another way rather than > a pointer? (Yes, some alternative ways exist such as hacking struct > bio_vec...) The ultimate answer is that page write protection will not be allow for some filesystem (that's how the patchset is designed in fact so that things can be merge piecemeal). But they are many way to solve the io error reporting and that's one of the thing i would like to get input on. >=20 > I wonder the final plan on this from the community, learn new rule > and adapt my code anyway.. But in my opinion, such reserve way > (page->mapping likewise) is helpful in many respects, I'm not sure > we could totally get around all cases without it elegantly... I still need to go read what it is you are trying to achieve. But i do not see any reason to remove page->mapping Cheers, J=E9r=F4me