Hi Rohith, Thanks for catching the problem and proposing the patch! I think there is a problem with just removing server->total_read updates inside decrypt_raw_data(): The same function is used in receive_encrypted_standard() which then calls cifs_handle_standard(). The latter uses server->total_read in at least two places: in server->ops->check_message and cifs_dump_mem(). There may be other places in the code that assume server->total_read to be correct. I would avoid simply removing this in all code paths and would rather make a more specific fix for the offloaded reads. -- Best regards, Pavel Shilovsky чт, 8 окт. 2020 г. в 13:36, Steve French <smfrench@xxxxxxxxx>: > > Fixed up 2 small checkpatch warnings and merged into cifs-2.6.git for-next > > On Thu, Oct 8, 2020 at 9:40 AM Rohith Surabattula > <rohiths.msft@xxxxxxxxx> wrote: > > > > Hi All, > > > > With the "esize" mount option, I observed data corruption and cifs > > reconnects during performance tests. > > > > TCP server info field server->total_read is modified parallely by > > demultiplex thread and decrypt offload worker thread. server->total_read > > is used in calculation to discard the remaining data of PDU which is > > not read into memory. > > > > Because of parallel modification, “server->total_read” value got > > corrupted and instead of discarding the remaining data, it discarded > > some valid data from the next PDU. > > > > server->total_read field is already updated properly during read from > > socket. So, no need to update the same field again after decryption. > > > > Regards, > > Rohith > > > > -- > Thanks, > > Steve
