Re: lib/errno.c

From: Chase Venters
Date: Tue Aug 01 2006 - 16:23:43 EST

On Tue, 1 Aug 2006, Chase Venters wrote:

I'm curious if there's a reason we're still carrying "lib/errno.c". The string "errno" is used pretty heavily but from a grep glance it seems any users define it locally (and indeed, the concurrency issues with a global 'errno' symbol mean it would be worthless except during boot, or maybe under BKL).

OK, I think I figured out why it's still there -- an old bit of legacy that is now a hack to deal with _syscall macros? I'm guessing here, so it would be nice if someone told me if I'm on the right track:

1. linux/unistd.h defines the extern for errno (perhaps for old export to user-space?)
2. lib/errno.c defines the variable itself
3. __syscall_return sets errno, probably for the benefit of old user-space

I'm wondering if we should drop lib/errno.c, #ifndef __KERNEL__ around the extern in unistd.h, and then fix up __syscall_return in include/asm-*/unistd.h to have two versions -- one when in __KERNEL__ that doesn't muck with errno, and one when not that does?

Alternatively / additionally, investigate changing execve() callers to use sys_execve() or do_execve(), rather than pounding back in through an interrupt?

Having a global 'errno' in the kernel just seems wrong -- if someone were to include unistd.h and then decide to use an 'int errno' in some function, then proceeds to forget to declare it on the stack, the code would build and leave a nice race condition hiding out.

Would a patch along these lines be acceptable, or is there something I am missing?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at