From: Hannes Frederic Sowa <hannes@stressinduktion.org>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Joe Perches <joe@perches.com>,
netdev@vger.kernel.org, davem@davemloft.net
Subject: Re: [PATCH] net: rework recvmsg handler msg_name and msg_namelen logic
Date: Thu, 21 Nov 2013 02:23:03 +0100 [thread overview]
Message-ID: <20131121012303.GC32587@order.stressinduktion.org> (raw)
In-Reply-To: <1384996730.10637.28.camel@edumazet-glaptop2.roam.corp.google.com>
On Wed, Nov 20, 2013 at 05:18:50PM -0800, Eric Dumazet wrote:
> On Thu, 2013-11-21 at 02:07 +0100, Hannes Frederic Sowa wrote:
> > On Wed, Nov 20, 2013 at 05:02:40PM -0800, Joe Perches wrote:
> > > On Thu, 2013-11-21 at 01:38 +0100, Hannes Frederic Sowa wrote:
> > > > This patch now always passes msg->msg_namelen as 0. recvmsg handlers must
> > > > set msg_namelen to the proper size <= sizeof(struct sockaddr_storage)
> > > > to return msg_name to the user.
> > > []
> > > > This change does not alter the user visible error logic as we ignore
> > > > msg_namelen as long as msg_name is NULL.
> > > >
> > > > Also remove two unnecessary curly brackets in ___sys_recvmsg and change
> > > > comments to netdev style.
> > >
> > > Perhaps take the opportunity to remove the unnecessary casts of
> > > struct msghdr.msg_name as it's a void *.
> > >
> > > And there's one other oddity about setting a known NULL to NULL.
> > >
> > > Maybe fix in a follow-on patch?
> >
> > No, that is easily done in this one. I'll send a v2 shortly.
> >
> > Thanks!
> >
>
> In move_addr_to_user() there is this strange test :
>
> if (len > klen)
> len = klen;
> if (len < 0 || len > sizeof(struct sockaddr_storage))
> return -EINVAL;
>
> I would suggest to instead use :
>
> if (len < 0)
> return -EINVAL;
> BUG_ON(len > sizeof(struct sockaddr_storage));
>
> To catch if some protocols are using more than 128 bytes.
>
> We can then remove the BUG_ON() later.
I actually started adding a handful BUILD_BUG_ONs on my branch as I don't know
if we will catch all corner-cases at runtime by the users and planed that for
net-next. But it is better to get such a check in as early as possible, so
I'll include it in v2.
Thanks!
next prev parent reply other threads:[~2013-11-21 1:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-21 0:38 [PATCH] net: rework recvmsg handler msg_name and msg_namelen logic Hannes Frederic Sowa
2013-11-21 1:02 ` Joe Perches
2013-11-21 1:07 ` Hannes Frederic Sowa
2013-11-21 1:18 ` Eric Dumazet
2013-11-21 1:23 ` Hannes Frederic Sowa [this message]
2013-11-21 14:52 ` Vlad Yasevich
2013-11-21 15:00 ` Eric Dumazet
2013-11-21 17:04 ` Hannes Frederic Sowa
2013-11-21 17:57 ` David Miller
2013-11-22 6:45 ` Hannes Frederic Sowa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131121012303.GC32587@order.stressinduktion.org \
--to=hannes@stressinduktion.org \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=joe@perches.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.