From: Steve Rago <sar@nec-labs.com>
To: David Miller <davem@davemloft.net>
Cc: <luto@amacapital.net>, <netdev@vger.kernel.org>,
<mtk.manpages@gmail.com>, <ebiederm@xmission.com>
Subject: Re: bug in passing file descriptors
Date: Mon, 7 Oct 2013 15:17:24 -0400 [thread overview]
Message-ID: <525308C4.1030007@nec-labs.com> (raw)
In-Reply-To: <20131007.151233.2237348893254566536.davem@davemloft.net>
On 10/07/2013 03:12 PM, David Miller wrote:
> From: Steve Rago <sar@nec-labs.com>
> Date: Mon, 7 Oct 2013 15:06:02 -0400
>
>> Maybe. So a client expecting to receive x bytes of control
>> information should make sure their buffer is at least CMSG_SPACE(x)
>> bytes long instead of CMSG_LEN(x) bytes long, because you feel
>> compelled to copy the final padding from kernel space to user space?
>> Seems wrong to me. IMHO, the final padding should only come into play
>> when calculating where the next header should begin.
>
> Yes, all control messages must be aligned to, and be of a length of a
> multiple of, "sizeof(long)".
>
> This is the only correct way to program control messages.
>
Except when sizeof(long) can change and you need to maintain binary compatibility with older applications. x86 comes to
mind as a relevant example: used to be 32 bits, but is 64 now.
Steve
next prev parent reply other threads:[~2013-10-07 19:17 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-07 18:27 bug in passing file descriptors Steve Rago
2013-10-07 18:44 ` Andy Lutomirski
2013-10-07 19:06 ` Steve Rago
2013-10-07 19:12 ` David Miller
2013-10-07 19:17 ` Steve Rago [this message]
2013-10-07 19:42 ` David Miller
2013-10-07 20:29 ` Steve Rago
2013-10-07 21:32 ` David Miller
2013-10-07 22:55 ` Andi Kleen
2013-10-08 14:32 ` Steve Rago
2013-10-08 16:02 ` Andy Lutomirski
2013-10-08 16:18 ` Steve Rago
2013-10-08 16:41 ` Andi Kleen
2013-10-08 16:51 ` Steve Rago
2013-10-09 14:07 ` Steve Rago
2013-10-08 8:43 ` David Laight
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=525308C4.1030007@nec-labs.com \
--to=sar@nec-labs.com \
--cc=davem@davemloft.net \
--cc=ebiederm@xmission.com \
--cc=luto@amacapital.net \
--cc=mtk.manpages@gmail.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.