qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Don't leak file descriptors


From: Blue Swirl
Subject: Re: [Qemu-devel] [PATCH] Don't leak file descriptors
Date: Tue, 17 Nov 2009 22:28:00 +0200

On Tue, Nov 17, 2009 at 11:12 AM, Kevin Wolf <address@hidden> wrote:
> Am 17.11.2009 00:05, schrieb Jamie Lokier:
>> Blue Swirl wrote:
>>> On Mon, Nov 16, 2009 at 2:47 PM, Kevin Wolf <address@hidden> wrote:
>>>> Am 13.11.2009 22:05, schrieb Blue Swirl:
>>>>> On Fri, Nov 13, 2009 at 5:17 PM, Kevin Wolf <address@hidden> wrote:
>>>>>> We're leaking file descriptors to child processes. Set FD_CLOEXEC on file
>>>>>> descriptors that don't need to be passed to children to stop this 
>>>>>> misbehaviour.
>>>>>
>>>>>> -        c = accept(s, (struct sockaddr *)&addr, &addrlen);
>>>>>> +        c = qemu_accept(s, (struct sockaddr *)&addr, &addrlen);
>>>>>
>>>>> Would it be possible to improve the interface so that no casts are
>>>>> needed for the calling code?
>>>>
>>>> How exactly would you do that? The only way I see to do it would be
>>>> using void*, but I'm not sure if this really is an improvement.
>>>
>>> Instead of sockaddr_in vs. sockaddr and the lame casts in between, we
>>> could have QSockAddr which magically works. Or if we only ever use
>>> sockaddr_in, just use that.
>>
>> int qemu_accept(int s, union __attribute__((__transparent_union__)) {
>>                                struct sockaddr *sa;
>>                                struct sockaddr_in *sin;
>>                                struct sockaddr_in6 *sin6;
>>                 } addr, socklen_t len);
>>
>> #define qemu_accept(s, addr) qemu_accept(s, addr, sizeof(*addr))
>>
>> Seems to work. :-)

But on the downside, it's a gcc extension.

> Interesting. I didn't even know that __transparent_union__ exists. Might
> be worth to consider, but the CLOEXEC patch definitely isn't the right
> place to do the conversion.
>
> Blue Swirl, care to do it on top of my patch?

The interface change is clearly out of scope of your patch.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]