Am Freitag, 5. Dezember 2014, 22:51:51 schrieb Stephan Mueller: Hi Herbert, > > > +static struct proto_ops algif_aead_ops = { > > > + .family = PF_ALG, > > > + > > > + .connect = sock_no_connect, > > > + .socketpair = sock_no_socketpair, > > > + .getname = sock_no_getname, > > > + .ioctl = sock_no_ioctl, > > > + .listen = sock_no_listen, > > > + .shutdown = sock_no_shutdown, > > > + .getsockopt = sock_no_getsockopt, > > > + .mmap = sock_no_mmap, > > > + .bind = sock_no_bind, > > > + .accept = sock_no_accept, > > > + > > > + .release = af_alg_release, > > > + .sendmsg = aead_sendmsg, > > > + .sendpage = aead_sendpage, > > > + .recvmsg = aead_recvmsg, > > > + .poll = aead_poll, > > > + .setsockopt = aead_setsockopt, > > > > No it should go into the parent setsockopt. Perhaps add a setsockopt > > to af_alg_type in order to keep this out of the generic code. > > I was thinking about that for quite a while. My thought for the current > approach was that the actual cipher operation happens in the child FD (i.e. > after accept). AAD is delivered to that FD. Therefore, I thought that the > size of the AAD can be specific to that operational FD. > > If we move it to the parent setsockopt, all child FDs have the same AAD > size. If you think that this is the right course of action, I can surely > implement that. > > Would you please be so kind and help me understand when some operations are > intended for the parent FD and when for the child FD? While implementing that request, I thought about setting the auth size as part of the msg control in sendmsg instead of setsockopt. This would save us a system call and thus CPU cycles. Thus may I propose that instead of using setsockopt, ALG_SET_AEAD_AUTHSIZE should be added to af_alg_cmsg_send the same way as ALG_SET_AEAD_ASSOCLEN. Along that line, wouldn't it make sense to get rid of the setsockopt in general and move even setting the key into the msg control and thus into af_alg_cmsg_send? I understand that this is a change to the user space API. Thanks -- Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html