Re: cifs.ko page management during reads

[Pavel Shilovsky <piastryyy@gmail.com>]

пн, 12 июл. 2021 г. в 22:41, Steve French <smfrench@gmail.com>:
>
> And don't forget "esize" mount option to allow offload of decryption...
>
> On Tue, Jul 13, 2021, 00:37 Shyam Prasad N <nspmangalore@gmail.com> wrote:
>>
>> 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:

Thanks for taking a look at this.

>>
>> 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

Yes, we read directly into pre-allocated pages. For direct IO we read
into pages supplied by the user and for non-direct IO (including page
IO) we allocate intermediate pages.

>>
>> 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.

Correct. Regardless of whether offloading is used or not there is an extra copy.

>>
>> 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.

Yes.

>>
>> for case 1, can't we read from the socket directly into the mapped
>> pages?

Yes - assuming no signing or encryption, we should be able to read
directly into the mapped pages. But I doubt many people use SMB2
without signing or encryption although there may be some use cases
requiring performance over safety.

>> 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.

Theoretically we may try doing this with signing but we need to make
sure that no one can modify those pages locally which may lead to
signing errors. I don't think today we reconnect an SMB session on
those today but we probably should.

For encryption, we do not know where read data starts in an encrypted
SMB packet, so there is almost no point to read directly because we
would need to shift (copy) the data afterwards anyway.

--
Best regards,
Pavel Shilovsky