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
