Date: Wed, 07 Nov 2007 19:13:54 -0800 (PST)
Message-Id: <20071107.191354.115487072.davem@davemloft.net>
To: akpm@linux-foundation.org
Cc: paulus@samba.org, lkml@davidb.org, linux-kernel@vger.kernel.org,
       drepper@redhat.com, mtk-manpages@gmx.net
Subject: Re: compat_sys_times() bogus until jiffies >= 0.
From: David Miller <davem@davemloft.net>
In-Reply-To: <20071107190714.9c404e28.akpm@linux-foundation.org>
References: <20071107161853.044b6e8f.akpm@linux-foundation.org>
	<18226.27701.782268.375231@cargo.ozlabs.ibm.com>
	<20071107190714.9c404e28.akpm@linux-foundation.org>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1019
Lines: 25

From: Andrew Morton <akpm@linux-foundation.org>
Date: Wed, 7 Nov 2007 19:07:14 -0800

> It appears that glibc treats all of 0x80000000-0xffffffff as an
> error.

glibc treats it as an error if the system call returns with
the carry condition code set.  At least that's how I've
understood it to work and at a minimum this is how it works
on sparc, ppc, ia64, mips, etc.

The error indication is being created by the system call return path
in the kernel.  It tests for values between -512 and 0, and marks
those as errors unless force_successful_syscall() has been called.

I can't see where x86 is doing this though, so perhaps for x86
glibc does make the negative value check.  But I doubt it is
checking the range 0x80000000-0xffffffff, otherwise mmap() would
be busted.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/