[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131121170434.GA6745@order.stressinduktion.org>
Date: Thu, 21 Nov 2013 18:04:34 +0100
From: Hannes Frederic Sowa <hannes@...essinduktion.org>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: Vlad Yasevich <vyasevich@...il.com>, netdev@...r.kernel.org,
davem@...emloft.net
Subject: Re: [PATCH] net: rework recvmsg handler msg_name and msg_namelen logic
On Thu, Nov 21, 2013 at 07:00:14AM -0800, Eric Dumazet wrote:
> On Thu, 2013-11-21 at 09:52 -0500, Vlad Yasevich wrote:
> > On 11/20/2013 07:38 PM, Hannes Frederic Sowa wrote:
> > > diff --git a/include/linux/net.h b/include/linux/net.h
> > > index b292a04..4bcee94 100644
> > > --- a/include/linux/net.h
> > > +++ b/include/linux/net.h
> > > @@ -164,6 +164,14 @@ struct proto_ops {
> > > #endif
> > > int (*sendmsg) (struct kiocb *iocb, struct socket *sock,
> > > struct msghdr *m, size_t total_len);
> > > + /* Notes for implementing recvmsg:
> > > + * ===============================
> > > + * msg->msg_namelen should get updated by the recvmsg handlers
> > > + * iff msg_name != NULL. It is by default 0 to prevent
> > > + * returning uninitialized memory to user space. The recvfrom
> > > + * handlers can assume that msg.msg_name is either NULL or has
> > > + * a minimum size of sizeof(struct sockaddr_storage).
> > ^^^^^^^
> >
> > You meant "maximum", right?
>
> He meant : A protocol can safely assume there are sizeof(struct
> sockaddr_storage) bytes available.
Yes, exactly. Apparently it seems to does cause confusion as I wrote it. Maybe I should
reword it?
--
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