From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751801AbdKYXTc (ORCPT ); Sat, 25 Nov 2017 18:19:32 -0500 Received: from mx1.redhat.com ([209.132.183.28]:44310 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751252AbdKYXTb (ORCPT ); Sat, 25 Nov 2017 18:19:31 -0500 Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: References: <26247.1511533324@warthog.procyon.org.uk> <23134.1511649343@warthog.procyon.org.uk> To: Linus Torvalds Cc: dhowells@redhat.com, linux-afs@lists.infradead.org, linux-fsdevel , Linux Kernel Mailing List Subject: Re: [GIT PULL] afs: Fixes MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25483.1511651969.1@warthog.procyon.org.uk> Date: Sat, 25 Nov 2017 23:19:29 +0000 Message-ID: <25484.1511651969@warthog.procyon.org.uk> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Sat, 25 Nov 2017 23:19:31 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Linus Torvalds wrote: > However, even when you do that, the page can be writable in other > mappings. At least fork(), for example, only clears the dirty bit, > doesn't mark it write-protected. I assumed the rmap walk done by page_mkclean() would take care of that but I'm not really clear on what the code does. > I just hope that the inconsistency isn't fatal to the afs client or > server code. For example, if you retry writes forever when a checksum > were to not match the data, that would be bad. Shouldn't be a problem for the the in-Linux client. Data is copied into sk_bufs preparatory to doing further things to it like checksumming, encryption or transmission (actually, in future, I would like to use the encryption process to save on the copy, but this shouldn't bother that either). AFAIK, the servers are all userspace jobs that don't let anyone else touch their storage so that they can maintain correctness on the data version number of each vnode. > so I just wanted to bring this up as a potential issue, not > necessarily as a big problem. Thanks. David