Re: [patch 0/3] [RFC] kernel/glibc mismatch of "readlink" syscall?

On Friday 31 October 2008 16:02:48 Kai Henningsen wrote:

Am Fri, 24 Oct 2008 17:53:25 -0500

schrieb "Michael Kerrisk" [off-list ref]:

quoted

Hi Daniel,

On Thu, Oct 23, 2008 at 9:50 AM, Daniel Gollub [off-list ref]

wrote:

quoted

EINVAL bufsiz is not positive.

The EINVAL error was added to man-pages-1.18 in 1997 (even though, as
you note, the type was "size_t").  I suspect (this was well before I
had any association with man-pages) that was done to reflect kernel
reality (since one could bypass glibc invoke the syscall directly),
but obviously it is inconsistent with the prototype.

Actually, it's not inconsistent as described, though perhaps that is
unintentional. "Not positive" isn't the same as "negative", as zero
isn't positive either, and zero is certainly a possible value of an
unsigned type

True.

But there is still the problem for the ltp syscall test "readlink03", when 
using the glibc "readlink" interface, by calling readlink with a buffer size 
of "-1".

Calling "-1" seems to be a valid code/error-path in the linux syscall 
"readlink", since there is a check for less-equal zero.

But the less zero, condition can't be reached via the glibc "readlink" 
interface since this would cause fortify-check to fail (when buliding with -
D_FORITFY_SOURCE=2).

To "workaround" the fortify check, by not compiling the testcase with -
D_FORTIFY_SOURCE=2, or trying to test the linux readlink interface by calling 
directly syscall() in the testcase ... both suggestion are just workarounds - 
no real solutions.

We could also just remove the testcase of buffer size "-1".

The problem is still, how to test the "readlink" syscall in LTP?

best regards,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html