Patchwork [v2] kmod: Handle undefined O_CLOEXEC

Close-on-exec seems to be unsuported on some architectures like CentOS 5.8
and thus causing some packages to fail to build successfully. Future kernel
version will probably fix this, but for now this patch works around this
problem.

Signed-off-by: Radu Moisan <radu.moisan@intel.com>
---
 meta/recipes-kernel/kmod/kmod.inc                  |    3 +-
 .../Handle-unsupported-close-on-exec-flag.patch    |   60 ++++++++++++++++++++
 2 files changed, 62 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-kernel/kmod/kmod/Handle-unsupported-close-on-exec-flag.patch

Radu Moisan <radu.moisan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
writes:

> Close-on-exec seems to be unsuported on some architectures like CentOS 5.8
> and thus causing some packages to fail to build successfully. 

Have you verified that making O_CLOEXEC a noop does not break the
applications?


Enrico

As far as kmod package is concerned O_CLOEXEC is used in constructs like 
"O_RDONLY|O_CLOEXEC". O_CLOEXEC can be used (is defined) starting with 
Linux kernel ?2.6.23 and glibc ?2.7 case in which the patch does not 
logically changing anything. However, prior Linux kernel ?2.6.23 
O_CLOEXEC is not defined (the case for CentOS 5.8 - kernel 2.6.18) and 
using it in code will cause build errors. My patch provides a workaround 
for those distributions that do not have O_CLOEXEC define, just to be 
able to build stuff. I have not tested on CentOS 5.8 if the applications 
are not broken in some way, but that's not in the scope of this patch. 
If something does indeed break, then a totally different patch is 
required, targeting a backport of kmod for kernel older than 2.6.23.

Radu

On 07/23/2012 05:34 PM, Enrico Scholz wrote:
> Radu Moisan <radu.moisan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> writes:
>
>> Close-on-exec seems to be unsuported on some architectures like CentOS 5.8
>> and thus causing some packages to fail to build successfully.
> Have you verified that making O_CLOEXEC a noop does not break the
> applications?
>
>
> Enrico
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

On Tue, Jul 24, 2012 at 12:37 AM, Radu Moisan <radu.moisan@intel.com> wrote:
> I have not tested on CentOS 5.8 if the applications are not broken in some
> way, but that's not in the scope of this patch. If something does indeed
> break, then a totally different patch is required, targeting a backport of
> kmod for kernel older than 2.6.23.

Personally, I'd rather see the build fail than have the tools behave
incorrectly in some inexplicable way. If you haven't tested it, the
patch shouldn't go in.

On 24 July 2012 14:27, Chris Larson <clarson@kergoth.com> wrote:
> On Tue, Jul 24, 2012 at 12:37 AM, Radu Moisan <radu.moisan@intel.com> wrote:
>> I have not tested on CentOS 5.8 if the applications are not broken in some
>> way, but that's not in the scope of this patch. If something does indeed
>> break, then a totally different patch is required, targeting a backport of
>> kmod for kernel older than 2.6.23.
>
> Personally, I'd rather see the build fail than have the tools behave
> incorrectly in some inexplicable way. If you haven't tested it, the
> patch shouldn't go in.

I was curious...

There are two commits in kmod where the cloexec changes were made:

http://git.profusion.mobi/cgit.cgi/kmod.git/log/?qt=grep&q=cloexec

The changes were a simple addition of the O_CLOEXEC flag, so this
patch is simply the union of those two commits.  A release of kmod
that doesn't require O_CLOEXEC has the same behaviour as this patch.
The problem O_CLOEXEC is solving isn't possible to solve cleanly
without it.  Using an older version of kmod instead of patching kmod
to work on older systems would result in more bugs and less features
for no win.

Ross

On Tue, Jul 24, 2012 at 8:40 AM, Burton, Ross <ross.burton@intel.com> wrote:
> On 24 July 2012 14:27, Chris Larson <clarson@kergoth.com> wrote:
>> On Tue, Jul 24, 2012 at 12:37 AM, Radu Moisan <radu.moisan@intel.com> wrote:
>>> I have not tested on CentOS 5.8 if the applications are not broken in some
>>> way, but that's not in the scope of this patch. If something does indeed
>>> break, then a totally different patch is required, targeting a backport of
>>> kmod for kernel older than 2.6.23.
>>
>> Personally, I'd rather see the build fail than have the tools behave
>> incorrectly in some inexplicable way. If you haven't tested it, the
>> patch shouldn't go in.
>
> I was curious...
>
> There are two commits in kmod where the cloexec changes were made:
>
> http://git.profusion.mobi/cgit.cgi/kmod.git/log/?qt=grep&q=cloexec
>
> The changes were a simple addition of the O_CLOEXEC flag, so this
> patch is simply the union of those two commits.  A release of kmod
> that doesn't require O_CLOEXEC has the same behaviour as this patch.
> The problem O_CLOEXEC is solving isn't possible to solve cleanly
> without it.  Using an older version of kmod instead of patching kmod
> to work on older systems would result in more bugs and less features
> for no win.

Was there any conclusion on this? I'm seeing the same problems. This
would only effect kmod-native (unless the target was using the older
stuff as well which is uncommon at this point).

Looking the commit that adds this as a dep:

commit f22cf1bedf2aa7fb41f98d6165401eb8a8bad17d
Author: Khem Raj <raj.khem@gmail.com>
Date:   Tue Jan 31 00:35:02 2012 -0800

    image.bbclass,kernel.bbclass: Use kmod-native instead of
module-init-tools-cross

We are just using depmod from this recipe for the kernel build, which
is a non-threaded user of this libraries built within kmod - therefore
we should not encounter any issues [1](after reading what O_CLOEXEC
does) with this patch except that it should only be applied to -native
builds. Also, if issues do present themselves they will be during the
build and not later at runtime so we can identify any issues that
arise.

So in summary, the patch should (IMO) be:

SRC_URI_append_virtclass-native =
"file://Handle-unsupported-close-on-exec-flag.patch"

Thoughts?

[1] http://lwn.net/Articles/249006/

-M

On Wed, Aug 15, 2012 at 11:37 AM, McClintock Matthew-B29882
<B29882@freescale.com> wrote:
> On Tue, Jul 24, 2012 at 8:40 AM, Burton, Ross <ross.burton@intel.com> wrote:
>> On 24 July 2012 14:27, Chris Larson <clarson@kergoth.com> wrote:
>>> On Tue, Jul 24, 2012 at 12:37 AM, Radu Moisan <radu.moisan@intel.com> wrote:
>>>> I have not tested on CentOS 5.8 if the applications are not broken in some
>>>> way, but that's not in the scope of this patch. If something does indeed
>>>> break, then a totally different patch is required, targeting a backport of
>>>> kmod for kernel older than 2.6.23.
>>>
>>> Personally, I'd rather see the build fail than have the tools behave
>>> incorrectly in some inexplicable way. If you haven't tested it, the
>>> patch shouldn't go in.
>>
>> I was curious...
>>
>> There are two commits in kmod where the cloexec changes were made:
>>
>> http://git.profusion.mobi/cgit.cgi/kmod.git/log/?qt=grep&q=cloexec
>>
>> The changes were a simple addition of the O_CLOEXEC flag, so this
>> patch is simply the union of those two commits.  A release of kmod
>> that doesn't require O_CLOEXEC has the same behaviour as this patch.
>> The problem O_CLOEXEC is solving isn't possible to solve cleanly
>> without it.  Using an older version of kmod instead of patching kmod
>> to work on older systems would result in more bugs and less features
>> for no win.
>
> Was there any conclusion on this? I'm seeing the same problems. This
> would only effect kmod-native (unless the target was using the older
> stuff as well which is uncommon at this point).

For what it's worth, we applied this in our layer and things do seem
to work fine with this applied. It was either this or what we did
before (reverted the switch to kmod-native and retained
module-init-tools-cross), as we require CentOS5/RHEL5 support still.