smb/server: use MSG_EOR for async interim response

Two kernel_sendmsg() calls can still use the same TCP skb if the first skb
can take more data. This can happen when ksmbd sends two SMB2 responses
very close to each other.

Without MSG_EOR, TCP can append the next sendmsg data to the previous skb.
Then STATUS_PENDING and the later response can be put into the same TCP
skb. MSG_EOR marks the skb as end of record, so TCP will not collapse the
next sendmsg data into it.

Example:

  smbtorture //${server_ip}/export -U${username}%${password} smb2.compound_async.write_write

  Client request:

    Write Request Len:64 Off:0, File: compound_async_write_write; Write Request Len:64 Off:64

  Before this patch, server responses:

    Write Response, File: compound_async_write_write
    Write Response
      SMB2, STATUS_PENDING, Write Response, MessageId 7
      SMB2, Write Response, MessageId 7

  After this patch:

    Write Response, File: compound_async_write_write
    Write Response, Error: STATUS_PENDING
    Write Response

Signed-off-by: ChenXiaoSong <chenxiaosong@kylinos.cn>
Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>

0 files changed, 0 insertions, 0 deletions