netdev - Re: [PATCH 10/11] nvmet-tcp: add NVMe over TCP target driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 19 Nov 2018 15:18:05 -0800 (PST)
From:   David Miller <davem@...emloft.net>
To:     sagi@...mberg.me
Cc:     sagi@...htbitslabs.com, linux-block@...r.kernel.org,
        netdev@...r.kernel.org, keith.busch@...el.com, hch@....de,
        linux-nvme@...ts.infradead.org
Subject: Re: [PATCH 10/11] nvmet-tcp: add NVMe over TCP target driver

From: Sagi Grimberg <sagi@...mberg.me>
Date: Mon, 19 Nov 2018 15:14:44 -0800

> Also, looking a bit closer there is a slight difference between the
> copy vs. the copy_and_csum variants. copy allows for a short_copy if
> we copy less than we expect while the csum faults it. I'm thinking
> that the copy_and_hash variant should also fault? Although I'm not
> sure I understand the fault entirely as csum is supposed to be
> cumulative, any insight?

When we are writing and signal an error, sockets have this recurring
pattern where we return immediately the amount of bytes successfully
transferred.  Then on the next sendmsg() call we give the error.

I don't know if that is what is influencing the behavior here or not
but it could be.