linux-kernel - Re: [PATCH v2] IB/core: remove dead code

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] [day] [month] [year] [list]

Message-ID: <5756C8A2.5060305@lightbits.io>
Date:	Tue, 7 Jun 2016 16:14:10 +0300
From:	Sagi Grimberg <sagi@...htbits.io>
To:	Christoph Hellwig <hch@...radead.org>,
	Sagi Grimberg <sagi@...htbits.io>
Cc:	Sudip Mukherjee <sudipm.mukherjee@...il.com>,
	Doug Ledford <dledford@...hat.com>,
	Sean Hefty <sean.hefty@...el.com>,
	Hal Rosenstock <hal.rosenstock@...il.com>,
	linux-kernel@...r.kernel.org, linux-rdma@...r.kernel.org,
	leon@...nel.org, Max Gurtovoy <maxg@...lanox.com>
Subject: Re: [PATCH v2] IB/core: remove dead code

>> Actually it looks like the data-integrity insert/strip operation
>> (where protection sg list does not exist) is broken.
>>
>> It looks that the protection scatterlist should be done only if
>> prot_sg_count was provided...
>>
>> I don't have access to mlx5 devices at the moment (still waiting
>> to get some...)

Hey Christoph,

> I've reported the brokenness in the existing iSER code when I started
> working on signature MR support in the generic API.  As no one helped
> managed to figure out the issue or how it should operate I clone the
> existing semantics, even given I knew they are broken.

There are two modes for the insert/strip operation, one is with PI on
memory and without on the wire (which is useful when having a target
working against legacy initiators), and one is with PI on the wire but
not in memory. You reported that the latter was broken (the less
useful case) and my understanding is that it was a result of
the target<->isert interaction. The last time I used the first mode
it worked fine.

I'll try to get my hands on some mlx5 devices soon and have a look into
this. I still want to change the API so it will hide all this noise from
the consumer but I need to find some spare cycles for it.

In the meantime, CC'ing Max from Mellanox and maybe he can check if
PI insert/strip are still alive.

Cheers,
Sagi.