netdev - Re: net: Remove iocb argument from sendmsg and recvmsg

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: <550068B7.8080403@intel.com>
Date:	Wed, 11 Mar 2015 09:09:27 -0700
From:	Tadeusz Struk <tadeusz.struk@...el.com>
To:	David Miller <davem@...emloft.net>
CC:	ying.xue@...driver.com, herbert@...dor.apana.org.au, hch@....de,
	viro@...IV.linux.org.uk, netdev@...r.kernel.org,
	linux-crypto@...r.kernel.org
Subject: Re: net: Remove iocb argument from sendmsg and recvmsg

On 03/10/2015 09:02 PM, David Miller wrote:
> 
> Because of the way you quoted the patch, it looked like a list posting
> looping back to the list again, because of the "List-ID: " email header.
> 
> Therefore your posting was blocked and you'll have to resend your posting
> in a way such that this doesn't happen.
> 
Oops, sorry, here it is.

Hi,
After couple of attempts to implement an user space interface to crypto HW that would meet our performance requirements, and after discussion with Herbert, we have come to conclusion that using AF_ALG sockets and AIO interface is the way to go.
Unfortunately it looks like AIO operations will no longer be supported on sockets because of the commit 1b784140474e4fc94281a49e96c67d29df0efbde.
My question is why do we want to abandon AIO support in the socket layer? Is it not worth keeping it for scenarios like this?
Do we have any alternative?
Here is the mentioned patch.

https://patchwork.kernel.org/patch/5971491/

Regards,
Tadeusz
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html