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] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 29 Jan 2015 07:57:21 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	David Miller <davem@...emloft.net>
Cc:	hch@....de, netdev@...r.kernel.org
Subject: Re: [PATCH] net: remove sock_iocb

On Wed, Jan 28, 2015 at 11:22:11PM -0800, David Miller wrote:
> From: Christoph Hellwig <hch@....de>
> Date: Wed, 28 Jan 2015 18:04:53 +0100
> 
> > The sock_iocb structure is allocate on stack for each read/write-like
> > operation on sockets, and contains various fields of which only the
> > embedded msghdr and sometimes a pointer to the scm_cookie is ever used.
> > Get rid of the sock_iocb and put a msghdr directly on the stack and pass
> > the scm_cookie explicitly to netlink_mmap_sendmsg.
> > 
> > Signed-off-by: Christoph Hellwig <hch@....de>
> 
> Looks good, applied, thanks.

You know, that's getting _really_ interesting.  The thing is, now
there's only one ->sendmsg() instance using iocb argument at all,
and it's a really weird one.  TIPC.  Which only compares it with
NULL, and that - to tell the normal calls (== done by sock_sendmsg()
et.al.) from tipc_{accept,connect}()-generated ones.  And the way
it's used is
        if (iocb)
                lock_sock(sk);
in tipc_send_stream().  IOW, "tipc_accept() and tipc_connect() would like
to use the guts of tipc_send_stream(), but they are already holding the
socket locked; let's just pass NULL iocb (which net/socket.c never does)
to tell it to leave the fucking lock alone, thank you very much".

And no ->recvmsg() are using iocb at all now.  How about we take the
guts of tipc_send_stream() into a helper function and have tipc_accept/connect
use _that_?  Then we could drop iocb argument completely and for ->sendmsg()
it would be the difference between 4 and 3 arguments, which has interesting
effects on certain register-starved architectures...

While we are at it, size (both for sendmsg and recvmsg) is always equal to
iov_iter_count(&msg->msg_iter), so that's not the only redundant argument
there...

Comments?
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ