[PATCH 1/2] fix O_CLOEXEC related build problems with kernel versions < 2.6.23

[Ralf Friedl]

Eugene Rudoy wrote:
> Do not use O_CLOEXEC flags (available since 2.6.23),
> use close_on_exec_on provided by libbb instead (like everywhere else)
>
> Signed-off-by: Eugene Rudoy <gene.devel at gmail.com>
> ---
>   miscutils/time.c          | 6 ++++--
>   modutils/modprobe-small.c | 3 ++-
>   modutils/modutils.c       | 3 ++-
>   3 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/modutils/modprobe-small.c b/modutils/modprobe-small.c
> index a94b0b9a6..e782d687d 100644
> --- a/modutils/modprobe-small.c
> +++ b/modutils/modprobe-small.c
> @@ -270,8 +270,9 @@ static int load_module(const char *fname, const char *options)
>   	r = 1;
>   # ifdef __NR_finit_module
>   	{
> -		int fd = open(fname, O_RDONLY | O_CLOEXEC);
> +		int fd = open(fname, O_RDONLY);
>   		if (fd >= 0) {
> +			close_on_exec_on(fd);
>   			r = finit_module(fd, options, 0) != 0;
>   			close(fd);
>   		}
> diff --git a/modutils/modutils.c b/modutils/modutils.c
> index 6f7cd9721..9f73d676c 100644
> --- a/modutils/modutils.c
> +++ b/modutils/modutils.c
> @@ -215,8 +215,9 @@ int FAST_FUNC bb_init_module(const char *filename, const char *options)
>   	 */
>   # ifdef __NR_finit_module
>   	{
> -		int fd = open(filename, O_RDONLY | O_CLOEXEC);
> +		int fd = open(filename, O_RDONLY);
>   		if (fd >= 0) {
> +			close_on_exec_on(fd);
>   			rc = finit_module(fd, options, 0) != 0;
>   			close(fd);
>   			if (rc == 0)
What is the purpose of O_CLOEXEC here? In both cases, we try to open a 
file. If the file is opened, we use the finit_module syscall and 
immediately close the file.  Is there a danger that finit_module might 
exec something and the file needs to be closed if that happens?
Specifying O_CLOEXEC as a parameter to open just changes the value of 
the constant, although loading a large value like O_CLOEXEC needs an 
extra instruction on MIPS, but this adds an additional function call, so 
is it really needed?