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 for Android: free password hash cracker in your pocket

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

Message-ID: <0de07d6d-ed90-df0e-5710-1f5cdddd6187@grimberg.me>
Date:   Mon, 19 Nov 2018 15:24:13 -0800
From:   Sagi Grimberg <sagi@...mberg.me>
To:     David Miller <davem@...emloft.net>
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


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

That makes sense... Does recvmsg() have the same semantics? this is the
rx path where we copy fragments to an iter..

If so, I guess that it makes sense that we fault and not allow short
copies as we have an incomplete csum in this case...

I'm wandering how we can consolidate the code paths together with this
subtle difference? Perhaps a short_copy flag?