Re: qcap: Fix compile error when O_CLOEXEC is not defined.

[Alexandre Julliard]

Sebastian Lackner  writes:
> Signed-off-by: Sebastian Lackner
>
> Defining to 0 ensures that it doesn't do any harm. If we don't
> care about ancient systems, we can probably also remove the fcntl call.
> On modern systems, setting CLOEXEC twice (via open and fcntl) shouldn't
> hurt.

I'm too lazy to check, but I'm wondering if passing O_CLOEXEC would
cause the open to fail on an ancient system, and whether we should be
checking for EINVAL and retrying...

qcap: Fix compile error when O_CLOEXEC is not defined.

[Sebastian Lackner]

On 07.03.2017 16:18, Alexandre Julliard wrote:
> Sebastian Lackner  writes:
> > Signed-off-by: Sebastian Lackner
> >
> > Defining to 0 ensures that it doesn't do any harm. If we don't
> > care about ancient systems, we can probably also remove the fcntl call.
> > On modern systems, setting CLOEXEC twice (via open and fcntl) shouldn't
> > hurt.
>
> I'm too lazy to check, but I'm wondering if passing O_CLOEXEC would
> cause the open to fail on an ancient system, and whether we should be
> checking for EINVAL and retrying...

Ideally such ancient systems shouldn't have O_CLOEXEC defined. However,
in practice it seems to depend on the exact device, and we probably
would have to check for EINVAL and retry to be safe. Are you fine with
just using fcntl always (with the risk of having a small race)?

qcap: Fix compile error when O_CLOEXEC is not defined.

[Alexandre Julliard]

Sebastian Lackner  writes:
> On 07.03.2017 16:18, Alexandre Julliard wrote:
> > Sebastian Lackner  writes:
> > > Signed-off-by: Sebastian Lackner
> > >
> > > Defining to 0 ensures that it doesn't do any harm. If we don't
> > > care about ancient systems, we can probably also remove the fcntl call.
> > > On modern systems, setting CLOEXEC twice (via open and fcntl) shouldn't
> > > hurt.
> >
> > I'm too lazy to check, but I'm wondering if passing O_CLOEXEC would
> > cause the open to fail on an ancient system, and whether we should be
> > checking for EINVAL and retrying...
>
> Ideally such ancient systems shouldn't have O_CLOEXEC defined. However,
> in practice it seems to depend on the exact device, and we probably
> would have to check for EINVAL and retry to be safe. Are you fine with
> just using fcntl always (with the risk of having a small race)?

If possible, checking for EINVAL would be preferable. The race is
unlikely to cause issues, but if it does, it would be random failures
that would be painful to track down.