linux-cifs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Shyam Prasad N <nspmangalore@gmail.com>
To: Pavel Shilovsky <piastryyy@gmail.com>,
	Steve French <smfrench@gmail.com>,
	CIFS <linux-cifs@vger.kernel.org>
Subject: cifs.ko page management during reads
Date: Tue, 13 Jul 2021 11:07:36 +0530	[thread overview]
Message-ID: <CANT5p=pDrNBRQSHAarXzxTRNF9Lo=-q-hsnbBTHJZue=ggGzXw@mail.gmail.com> (raw)

Hi all,

I'm trying to understand our read path (big picture is to integrate
the new netfs helpers into cifs.ko), and I wanted to get some
understanding about why things are the way they are. @Pavel Shilovsky
I'm guessing that you've worked on most of this code, so hoping that
you'll be able to answer some of these:

1. for cases where both encryption and signing are disabled, it looks
like we read from the socket page-by-page directly into pages and map
those to the inode address space

2. for cases where encryption is enabled, we read the encrypted data
into a set of pages first, then call crypto APIs, which decrypt the
data in-place to the same pages. We then copy out the decrypted data
from these pages into the pages in the address space that are already
mapped.

3. similarly for the signing case, we read the data into a set of
pages first, then verify signature, then copy the pages to the mapped
pages in the inode address space.

for case 1, can't we read from the socket directly into the mapped
pages? for case 2 and 3, instead of allocating temporary pages to read
into, can't we read directly into the pages of the inode address
space? the only risk I see is that if decryption or sign verification
fails, it would overwrite the data that is already present in the page
cache. but I see that as acceptable, because we're reading from the
server, since the data we have in the cache is stale anyways.

Seeking opinions from experts who've worked on this codepath before.
Please correct me if I'm wrong with any of these.

-- 
Regards,
Shyam

             reply	other threads:[~2021-07-13  5:37 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-13  5:37 Shyam Prasad N [this message]
     [not found] ` <CAH2r5mvxj-A3F1tPr9OH1D00bdznVYyx7FzyjLZt=Xq41TCVxw@mail.gmail.com>
2021-07-13 22:58   ` Pavel Shilovsky
2021-07-14  0:15     ` ronnie sahlberg
2021-07-14  6:50       ` Shyam Prasad N
2021-07-14 16:34         ` Pavel Shilovsky

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='CANT5p=pDrNBRQSHAarXzxTRNF9Lo=-q-hsnbBTHJZue=ggGzXw@mail.gmail.com' \
    --to=nspmangalore@gmail.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=piastryyy@gmail.com \
    --cc=smfrench@gmail.com \
    --subject='Re: cifs.ko page management during reads' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).