This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v4 0/3] Fix {recv,send}{m}msg standard compliance (BZ#16919)
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: libc-alpha at sourceware dot org
- Date: Tue, 24 May 2016 16:09:14 -0300
- Subject: Re: [PATCH v4 0/3] Fix {recv,send}{m}msg standard compliance (BZ#16919)
- Authentication-results: sourceware.org; auth=none
- References: <1459175641-12520-1-git-send-email-adhemerval dot zanella at linaro dot org> <56FE7CDD dot 2070109 at linaro dot org> <5705545A dot 5020109 at linaro dot org> <5718D3B1 dot 4030704 at linaro dot org>
If no one has any more objection for these patches I plan to commit it.
On 21/04/2016 10:20, Adhemerval Zanella wrote:
> Ping.
>
> On 06-04-2016 15:24, Adhemerval Zanella wrote:
>> Ping.
>>
>> On 01-04-2016 10:51, Adhemerval Zanella wrote:
>>> Joseph,
>>>
>>> Besides the comment in first patch from the set do you have any more
>>> upcoming comments or regards about the changes?
>>>
>>> On 28-03-2016 11:33, Adhemerval Zanella wrote:
>>>>
>>>> 1. Current sendmsg fix does not handle larger msg_control neither
>>>> pads the cmsghdr associated. The problem with this approach
>>>> is to accomplish a complete fix it will require to allocate
>>>> a limited buffer, copying the incoming struct and zero pad.
>>>> Although it tend to work it also add some limitation of total
>>>> msg_control length.
>>>> The general usage for such facily is passing file descriptors
>>>> and permissions between processes over unix sockets so it might
>>>> be factible to use a large stack allocated buffer (1024, 2048
>>>> or large) and return ENOMEM for larger buffers.
>>>
>>> This is the only remaining issue for bz16919 which this patch does
>>> not address directly, but I am intend to send an upcoming patch to
>>> get some discussion if the idea is the best approach.
>>>