On Fri, Dec 21, 2007 at 08:36:40PM -0800, David Miller wrote:
> From: Andi Kleen <[EMAIL PROTECTED]>
> Date: Sat, 22 Dec 2007 02:53:11 +0100
>
> > > And to handle potentially ambiguous cases we, for a long time, have
> > > the force_successful_syscall_return() arch hook.
> >
> > Ah I see what
On Fri, Dec 21, 2007 at 08:36:40PM -0800, David Miller wrote:
From: Andi Kleen [EMAIL PROTECTED]
Date: Sat, 22 Dec 2007 02:53:11 +0100
And to handle potentially ambiguous cases we, for a long time, have
the force_successful_syscall_return() arch hook.
Ah I see what you mean now.
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Sat, 22 Dec 2007 02:53:11 +0100
> > And to handle potentially ambiguous cases we, for a long time, have
> > the force_successful_syscall_return() arch hook.
>
> Ah I see what you mean now.
>
> Thanks for the clarification.
Thanks for continuing to
> And to handle potentially ambiguous cases we, for a long time, have
> the force_successful_syscall_return() arch hook.
Ah I see what you mean now.
Thanks for the clarification.
Ok that could be in theory made to work yes. The migration would
probably be ugly though (how would glibc figure
> I'm suggesting that you set the condition codes based upon whether
> there is an error or not.
And the only way the syscall code could find out if there is an error is by
checking err < 0 && err >= -4096 like glibc (except for the compat
syscall on 64bit kernel case)
Or rewrite all code that
From: David Miller <[EMAIL PROTECTED]>
Date: Fri, 21 Dec 2007 17:41:24 -0800 (PST)
> I'm suggesting that you set the condition codes based upon whether
> there is an error or not. That is the critical thing x86 doesn't do
> that all the other platforms do.
And if you still don't get it, I'm
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Sat, 22 Dec 2007 01:42:02 +0100
> David Miller <[EMAIL PROTECTED]> writes:
>
> > Only on x86 platforms. Sparc, IA64, MIPS, powerpc, etc. all get this
> > case right.
>
> Do they for 32bit kernels or for 64bit userland?
Both. This is not a compat
David Miller <[EMAIL PROTECTED]> writes:
> Only on x86 platforms. Sparc, IA64, MIPS, powerpc, etc. all get this
> case right.
Do they for 32bit kernels or for 64bit userland?
> Yes it's another unfortunate side effect of how error status is
> indicated for x86 system calls.
Maybe I'm dense,
David Miller [EMAIL PROTECTED] writes:
Only on x86 platforms. Sparc, IA64, MIPS, powerpc, etc. all get this
case right.
Do they for 32bit kernels or for 64bit userland?
Yes it's another unfortunate side effect of how error status is
indicated for x86 system calls.
Maybe I'm dense, but
From: Andi Kleen [EMAIL PROTECTED]
Date: Sat, 22 Dec 2007 01:42:02 +0100
David Miller [EMAIL PROTECTED] writes:
Only on x86 platforms. Sparc, IA64, MIPS, powerpc, etc. all get this
case right.
Do they for 32bit kernels or for 64bit userland?
Both. This is not a compat issue.
Yes
From: David Miller [EMAIL PROTECTED]
Date: Fri, 21 Dec 2007 17:41:24 -0800 (PST)
I'm suggesting that you set the condition codes based upon whether
there is an error or not. That is the critical thing x86 doesn't do
that all the other platforms do.
And if you still don't get it, I'm saying
I'm suggesting that you set the condition codes based upon whether
there is an error or not.
And the only way the syscall code could find out if there is an error is by
checking err 0 err = -4096 like glibc (except for the compat
syscall on 64bit kernel case)
Or rewrite all code that
And to handle potentially ambiguous cases we, for a long time, have
the force_successful_syscall_return() arch hook.
Ah I see what you mean now.
Thanks for the clarification.
Ok that could be in theory made to work yes. The migration would
probably be ugly though (how would glibc figure out
From: Andi Kleen [EMAIL PROTECTED]
Date: Sat, 22 Dec 2007 02:53:11 +0100
And to handle potentially ambiguous cases we, for a long time, have
the force_successful_syscall_return() arch hook.
Ah I see what you mean now.
Thanks for the clarification.
Thanks for continuing to insist it's
From: Michael Kerrisk <[EMAIL PROTECTED]>
Date: Thu, 20 Dec 2007 12:36:52 +0100
> Some testing just now shows me that lseek() on /dev/mem suffers similar
> problems when seeking to bytes 0xf001 through to 0x.
Only on x86 platforms. Sparc, IA64, MIPS, powerpc, etc. all get this
case
David, Andrew, Paul,
A late coda to this thread, but I'll just note some changes I'm making to
the man page (which I'd like you to review -- please see below), and note a
few other points.
Andrew, you asked about what happens for x86 with the -1 to -4095 return
for other syscalls. At least two
David, Andrew, Paul,
A late coda to this thread, but I'll just note some changes I'm making to
the man page (which I'd like you to review -- please see below), and note a
few other points.
Andrew, you asked about what happens for x86 with the -1 to -4095 return
for other syscalls. At least two
From: Michael Kerrisk [EMAIL PROTECTED]
Date: Thu, 20 Dec 2007 12:36:52 +0100
Some testing just now shows me that lseek() on /dev/mem suffers similar
problems when seeking to bytes 0xf001 through to 0x.
Only on x86 platforms. Sparc, IA64, MIPS, powerpc, etc. all get this
case
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Friesen wrote:
>> A possible remedy is to return the ticks since process start time, which
>> delays the wrap around much further. POSIX only demands consistency
>> within the same process.
>
> This would be an interesting solution.
>
> The
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Friesen wrote:
A possible remedy is to return the ticks since process start time, which
delays the wrap around much further. POSIX only demands consistency
within the same process.
This would be an interesting solution.
The man page
On Thursday 08 November 2007 03:07, Andrew Morton wrote:
> > On Thu, 8 Nov 2007 12:53:57 +1100 Paul Mackerras <[EMAIL PROTECTED]> wrote:
> > Andrew Morton writes:
> >
> > > Given all this stuff, the return value from sys_times() doesn't seem a
> > > particularly useful or reliable kernel
On Thursday 08 November 2007 02:09, David Miller wrote:
> > I think the best thing would be to ignore any error from copy_to_user
> > and always return the number of clock ticks. We should call
> > force_successful_syscall_return, and glibc on x86 should be taught not
> > to interpret negative
Andreas Schwab wrote:
A possible remedy is to return the ticks since process start time, which
delays the wrap around much further. POSIX only demands consistency
within the same process.
This would be an interesting solution.
The man page for linux states that the return code is time since
David Miller <[EMAIL PROTECTED]> writes:
> I agree with this analysis.
>
> The Linux man page for times() explicitly lists (clock_t) -1 as a
> return value meaning error.
>
> So even if we did make some effort to return errors "properly" (via
> force_successful_syscall_return() et al.) userspace
David Miller writes:
> On x86 only. We could use force_successful_syscall_return()
> to make sure the condition codes get set correctly on
> other platforms.
>
> But even in that case we'd still be broken when the return
> value is exactly -1 and that's what the application is going
> to
David Miller writes:
On x86 only. We could use force_successful_syscall_return()
to make sure the condition codes get set correctly on
other platforms.
But even in that case we'd still be broken when the return
value is exactly -1 and that's what the application is going
to compare
David Miller [EMAIL PROTECTED] writes:
I agree with this analysis.
The Linux man page for times() explicitly lists (clock_t) -1 as a
return value meaning error.
So even if we did make some effort to return errors properly (via
force_successful_syscall_return() et al.) userspace would still
Andreas Schwab wrote:
A possible remedy is to return the ticks since process start time, which
delays the wrap around much further. POSIX only demands consistency
within the same process.
This would be an interesting solution.
The man page for linux states that the return code is time since
On Thursday 08 November 2007 02:09, David Miller wrote:
I think the best thing would be to ignore any error from copy_to_user
and always return the number of clock ticks. We should call
force_successful_syscall_return, and glibc on x86 should be taught not
to interpret negative values as
On Thursday 08 November 2007 03:07, Andrew Morton wrote:
On Thu, 8 Nov 2007 12:53:57 +1100 Paul Mackerras [EMAIL PROTECTED] wrote:
Andrew Morton writes:
Given all this stuff, the return value from sys_times() doesn't seem a
particularly useful or reliable kernel interface.
I
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Wed, 7 Nov 2007 23:09:16 -0800
> I don't think that's a big problem? This syscall can (oddly) return any
> 32-bit (64-bit) number and a smart application developer (after saying wtf)
> would realise that he just can't check for errors and have
> On Wed, 07 Nov 2007 22:25:30 -0800 (PST) David Miller <[EMAIL PROTECTED]>
> wrote:
> From: Andrew Morton <[EMAIL PROTECTED]>
> Date: Wed, 7 Nov 2007 21:20:05 -0800
>
> > Yup. But userspace will already have a fit if either the start or end time
> > advanced into the
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Wed, 7 Nov 2007 21:20:05 -0800
> Yup. But userspace will already have a fit if either the start or end time
> advanced into the glibc-thought-that-was-an-error range.
On x86 only. We could use force_successful_syscall_return()
to make sure the
From: Paul Mackerras <[EMAIL PROTECTED]>
Date: Thu, 8 Nov 2007 16:15:51 +1100
> David Miller writes:
>
> > 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 0x8000-0x, otherwise
From: Paul Mackerras <[EMAIL PROTECTED]>
Date: Thu, 8 Nov 2007 15:59:12 +1100
> Not on powerpc. On powerpc the error indication is carried separately
> in a condition register bit. So a force_successful_syscall_return()
> call will make glibc automatically do the right thing without any
> glibc
> On Thu, 8 Nov 2007 16:36:08 +1100 Paul Mackerras <[EMAIL PROTECTED]> wrote:
> Andrew Morton writes:
>
> > Yup. But userspace will already have a fit if either the start or end time
> > advanced into the glibc-thought-that-was-an-error range.
>
> Not nearly as much of a fit. The effect on x86
On Wed, Nov 07, 2007 at 03:28:33PM -0800, Andrew Morton wrote:
On Wed, 7 Nov 2007 14:47:22 -0800 David Brown <[EMAIL PROTECTED]> wrote:
will return '-1' to user space and set the negated clock_t value to errno.
At minimum, perhaps it should return a sane errno value.
RETURN VALUE
Andrew Morton writes:
> Yup. But userspace will already have a fit if either the start or end time
> advanced into the glibc-thought-that-was-an-error range.
Not nearly as much of a fit. The effect on x86 is that values between
-4095 and -1 are reported as -1, so the end-start difference will
> On Thu, 8 Nov 2007 15:59:12 +1100 Paul Mackerras <[EMAIL PROTECTED]> wrote:
> Andrew Morton writes:
>
> > "the latter" is what my protopatch does isn't it? It wraps at 0x7fff.
> > It appears that glibc treats all of 0x8000-0x as an error.
>
> Not on powerpc. On powerpc the
David Miller writes:
> 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 0x8000-0x, otherwise mmap() would
> be busted.
At least for the INTERNAL_SYSCALL macro in glibc, the error check
Andrew Morton writes:
> "the latter" is what my protopatch does isn't it? It wraps at 0x7fff.
> It appears that glibc treats all of 0x8000-0x as an error.
Not on powerpc. On powerpc the error indication is carried separately
in a condition register bit. So a
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Wed, 7 Nov 2007 19:07:14 -0800
> It appears that glibc treats all of 0x8000-0x 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
> On Thu, 8 Nov 2007 12:53:57 +1100 Paul Mackerras <[EMAIL PROTECTED]> wrote:
> Andrew Morton writes:
>
> > Given all this stuff, the return value from sys_times() doesn't seem a
> > particularly useful or reliable kernel interface.
>
> I think the best thing would be to ignore any error from
From: Paul Mackerras <[EMAIL PROTECTED]>
Date: Thu, 8 Nov 2007 12:53:57 +1100
> Andrew Morton writes:
>
> > Given all this stuff, the return value from sys_times() doesn't seem a
> > particularly useful or reliable kernel interface.
>
> I think the best thing would be to ignore any error from
Andrew Morton writes:
> Given all this stuff, the return value from sys_times() doesn't seem a
> particularly useful or reliable kernel interface.
I think the best thing would be to ignore any error from copy_to_user
and always return the number of clock ticks. We should call
> On Thu, 08 Nov 2007 01:54:40 +0100 Andreas Schwab <[EMAIL PROTECTED]> wrote:
> Andrew Morton <[EMAIL PROTECTED]> writes:
>
> > diff -puN kernel/compat.c~a kernel/compat.c
> > --- a/kernel/compat.c~a
> > +++ a/kernel/compat.c
> > @@ -162,7 +162,8 @@ asmlinkage long compat_sys_times(struct
> >
> On Wed, 07 Nov 2007 16:50:22 -0800 (PST) David Miller <[EMAIL PROTECTED]>
> wrote:
> From: Andrew Morton <[EMAIL PROTECTED]>
> Date: Wed, 7 Nov 2007 15:28:33 -0800
>
> > Perhaps this is a bug in glibc: it is interpreting the times() return value
> > in the same way as other syscalls.
>
> The
Andrew Morton <[EMAIL PROTECTED]> writes:
> diff -puN kernel/compat.c~a kernel/compat.c
> --- a/kernel/compat.c~a
> +++ a/kernel/compat.c
> @@ -162,7 +162,8 @@ asmlinkage long compat_sys_times(struct
> if (copy_to_user(tbuf, , sizeof(tmp)))
> return -EFAULT;
>
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Wed, 7 Nov 2007 15:28:33 -0800
> Perhaps this is a bug in glibc: it is interpreting the times() return value
> in the same way as other syscalls.
The problem is more likely that we are failing to
invoke force_successful_syscall_return() here.
> On Wed, 7 Nov 2007 15:28:33 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Wed, 7 Nov 2007 14:47:22 -0800 David Brown <[EMAIL PROTECTED]> wrote:
> > compat_sys_times() has bogus return until jiffies is >= 0. I discovered
> > this running LTP within 5 minutes of booting.
> >
> > The
> On Wed, 7 Nov 2007 14:47:22 -0800 David Brown <[EMAIL PROTECTED]> wrote:
> compat_sys_times() has bogus return until jiffies is >= 0. I discovered
> this running LTP within 5 minutes of booting.
>
> The return result
>
> return compat_jiffies_to_clock_t(jiffies);
>
> will return '-1'
On Wed, 7 Nov 2007 14:47:22 -0800 David Brown [EMAIL PROTECTED] wrote:
compat_sys_times() has bogus return until jiffies is = 0. I discovered
this running LTP within 5 minutes of booting.
The return result
return compat_jiffies_to_clock_t(jiffies);
will return '-1' to user space
On Thu, 8 Nov 2007 15:59:12 +1100 Paul Mackerras [EMAIL PROTECTED] wrote:
Andrew Morton writes:
the latter is what my protopatch does isn't it? It wraps at 0x7fff.
It appears that glibc treats all of 0x8000-0x as an error.
Not on powerpc. On powerpc the error
Andrew Morton writes:
Yup. But userspace will already have a fit if either the start or end time
advanced into the glibc-thought-that-was-an-error range.
Not nearly as much of a fit. The effect on x86 is that values between
-4095 and -1 are reported as -1, so the end-start difference will be
From: Andrew Morton [EMAIL PROTECTED]
Date: Wed, 7 Nov 2007 19:07:14 -0800
It appears that glibc treats all of 0x8000-0x 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
From: Paul Mackerras [EMAIL PROTECTED]
Date: Thu, 8 Nov 2007 12:53:57 +1100
Andrew Morton writes:
Given all this stuff, the return value from sys_times() doesn't seem a
particularly useful or reliable kernel interface.
I think the best thing would be to ignore any error from
On Wed, 07 Nov 2007 22:25:30 -0800 (PST) David Miller [EMAIL PROTECTED]
wrote:
From: Andrew Morton [EMAIL PROTECTED]
Date: Wed, 7 Nov 2007 21:20:05 -0800
Yup. But userspace will already have a fit if either the start or end time
advanced into the glibc-thought-that-was-an-error range.
From: Paul Mackerras [EMAIL PROTECTED]
Date: Thu, 8 Nov 2007 16:15:51 +1100
David Miller writes:
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 0x8000-0x, otherwise mmap() would
On Thu, 8 Nov 2007 16:36:08 +1100 Paul Mackerras [EMAIL PROTECTED] wrote:
Andrew Morton writes:
Yup. But userspace will already have a fit if either the start or end time
advanced into the glibc-thought-that-was-an-error range.
Not nearly as much of a fit. The effect on x86 is that
On Wed, 7 Nov 2007 15:28:33 -0800 Andrew Morton [EMAIL PROTECTED] wrote:
On Wed, 7 Nov 2007 14:47:22 -0800 David Brown [EMAIL PROTECTED] wrote:
compat_sys_times() has bogus return until jiffies is = 0. I discovered
this running LTP within 5 minutes of booting.
The return result
Andrew Morton writes:
Given all this stuff, the return value from sys_times() doesn't seem a
particularly useful or reliable kernel interface.
I think the best thing would be to ignore any error from copy_to_user
and always return the number of clock ticks. We should call
From: Andrew Morton [EMAIL PROTECTED]
Date: Wed, 7 Nov 2007 15:28:33 -0800
Perhaps this is a bug in glibc: it is interpreting the times() return value
in the same way as other syscalls.
The problem is more likely that we are failing to
invoke force_successful_syscall_return() here.
Otherwise
Andrew Morton [EMAIL PROTECTED] writes:
diff -puN kernel/compat.c~a kernel/compat.c
--- a/kernel/compat.c~a
+++ a/kernel/compat.c
@@ -162,7 +162,8 @@ asmlinkage long compat_sys_times(struct
if (copy_to_user(tbuf, tmp, sizeof(tmp)))
return -EFAULT;
On Wed, 07 Nov 2007 16:50:22 -0800 (PST) David Miller [EMAIL PROTECTED]
wrote:
From: Andrew Morton [EMAIL PROTECTED]
Date: Wed, 7 Nov 2007 15:28:33 -0800
Perhaps this is a bug in glibc: it is interpreting the times() return value
in the same way as other syscalls.
The problem is more
On Thu, 08 Nov 2007 01:54:40 +0100 Andreas Schwab [EMAIL PROTECTED] wrote:
Andrew Morton [EMAIL PROTECTED] writes:
diff -puN kernel/compat.c~a kernel/compat.c
--- a/kernel/compat.c~a
+++ a/kernel/compat.c
@@ -162,7 +162,8 @@ asmlinkage long compat_sys_times(struct
if
On Wed, Nov 07, 2007 at 03:28:33PM -0800, Andrew Morton wrote:
On Wed, 7 Nov 2007 14:47:22 -0800 David Brown [EMAIL PROTECTED] wrote:
will return '-1' to user space and set the negated clock_t value to errno.
At minimum, perhaps it should return a sane errno value.
RETURN VALUE
From: Paul Mackerras [EMAIL PROTECTED]
Date: Thu, 8 Nov 2007 15:59:12 +1100
Not on powerpc. On powerpc the error indication is carried separately
in a condition register bit. So a force_successful_syscall_return()
call will make glibc automatically do the right thing without any
glibc
From: Andrew Morton [EMAIL PROTECTED]
Date: Wed, 7 Nov 2007 21:20:05 -0800
Yup. But userspace will already have a fit if either the start or end time
advanced into the glibc-thought-that-was-an-error range.
On x86 only. We could use force_successful_syscall_return()
to make sure the
On Thu, 8 Nov 2007 12:53:57 +1100 Paul Mackerras [EMAIL PROTECTED] wrote:
Andrew Morton writes:
Given all this stuff, the return value from sys_times() doesn't seem a
particularly useful or reliable kernel interface.
I think the best thing would be to ignore any error from copy_to_user
From: Andrew Morton [EMAIL PROTECTED]
Date: Wed, 7 Nov 2007 23:09:16 -0800
I don't think that's a big problem? This syscall can (oddly) return any
32-bit (64-bit) number and a smart application developer (after saying wtf)
would realise that he just can't check for errors and have correctly
Andrew Morton writes:
the latter is what my protopatch does isn't it? It wraps at 0x7fff.
It appears that glibc treats all of 0x8000-0x as an error.
Not on powerpc. On powerpc the error indication is carried separately
in a condition register bit. So a
David Miller writes:
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 0x8000-0x, otherwise mmap() would
be busted.
At least for the INTERNAL_SYSCALL macro in glibc, the error check is:
72 matches
Mail list logo
