From: David Howells <dhowells@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: dhowells@redhat.com, linux-afs@lists.infradead.org,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] afs: Fixes
Date: Sat, 25 Nov 2017 23:19:29 +0000 [thread overview]
Message-ID: <25484.1511651969@warthog.procyon.org.uk> (raw)
In-Reply-To: <CA+55aFzHMTdqefmtxcKjiGDC=HsKiimfuDQxZZ-hbu-6f1nL3g@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> 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
next prev parent reply other threads:[~2017-11-25 23:19 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-24 14:22 David Howells
2017-11-25 18:05 ` Linus Torvalds
2017-11-25 22:35 ` David Howells
2017-11-25 22:48 ` Dave Chinner
2017-11-25 22:55 ` Linus Torvalds
2017-11-25 23:19 ` David Howells [this message]
-- strict thread matches above, loose matches on Subject: below --
2020-10-29 14:07 [GIT PULL] afs fixes David Howells
2020-10-29 17:31 ` pr-tracker-bot
2020-04-13 14:50 [GIT PULL] afs: Fixes David Howells
2020-04-13 15:13 ` David Howells
2020-04-14 19:05 ` pr-tracker-bot
2019-08-22 13:10 David Howells
2019-08-22 18:30 ` pr-tracker-bot
2019-08-14 14:18 David Howells
2019-08-14 22:35 ` pr-tracker-bot
2019-08-14 14:15 David Howells
2019-06-26 13:39 [GIT PULL] AFS fixes David Howells
2019-06-28 0:45 ` pr-tracker-bot
2019-06-26 8:50 David Howells
2019-06-26 13:38 ` David Howells
2019-04-18 9:17 [GIT PULL] afs: Fixes David Howells
2019-04-18 15:20 ` pr-tracker-bot
2018-05-14 21:25 David Howells
2017-03-17 15:29 [GIT PULL] AFS fixes David Howells
2017-03-17 19:23 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=25484.1511651969@warthog.procyon.org.uk \
--to=dhowells@redhat.com \
--cc=linux-afs@lists.infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome