Am Donnerstag, 16. März 2017, 10:08:23 CET schrieb Herbert Xu:
Hi Herbert,
> On Thu, Mar 16, 2017 at 09:55:17AM +0100, Stephan Müller wrote:
> > With this approach I thought that the while loop could be a thing of the
> > past, considering that this is also the approach taken in
> > skcipher_recvmsg_async that is present in the current upstream code base.
>
> The reason there is a limit is so that user-space doesn't pin down
> unlimited amounts of memory. How is this addressed under your
> scheme?
sock_kmalloc limits the number of SG tables that we can manage. On my system,
sock_kmalloc has 20480 bytes at its disposal as the limiting factor.
As this concept for limiting the impact of user space on kernel memory is used
in the current upstream skcipher_recvmsg_async, I simply re-used that
approach:
while (iov_iter_count(&msg->msg_iter)) {
struct skcipher_async_rsgl *rsgl;
...
rsgl = kmalloc(sizeof(*rsgl), GFP_KERNEL);
...
Note I use sock_kmalloc instead of the currently existing kmalloc to ensure
such limitation.
Also, please note that this approach is identical to the currently used code
in algif_aead:aead_recvmsg_sync. This implementation led be to belief that
this my new code would be appropriate in this case, too.
Ciao
Stephan
