Not that I'm actually involved any more, but I'd endorse the user_regset
approach and not the new request. On many (most?) machines, it's already
part of the main integer regset (orig_rax et al) and adding another
mechanism is redundant. Using user_regset also means there won't be a word
of
Not that I'm actually involved any more, but I'd endorse the user_regset
approach and not the new request. On many (most?) machines, it's already
part of the main integer regset (orig_rax et al) and adding another
mechanism is redundant. Using user_regset also means there won't be a word
of
That's OK with me. But I'm not really actively involved in kernel
maintenance any more (though happy to answer anything Oleg wants advice on).
Acked-By: Roland McGrath
Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
That's OK with me. But I'm not really actively involved in kernel
maintenance any more (though happy to answer anything Oleg wants advice on).
Acked-By: Roland McGrath rol...@hack.frob.com
Thanks,
Roland
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
> > config COMPAT_VDSO
> > def_bool y
> > prompt "Compat VDSO support"
> > depends on X86_32 || IA32_EMULATION
> > ---help---
> > Map the 32-bit VDSO to the predictable old-style address too.
> >
> > Say N here if you are running a sufficiently
config COMPAT_VDSO
def_bool y
prompt Compat VDSO support
depends on X86_32 || IA32_EMULATION
---help---
Map the 32-bit VDSO to the predictable old-style address too.
Say N here if you are running a sufficiently recent glibc
> I won't argue, but it is not clear to me if this is really useful,
> given that the debugger can read the regs.
I do see the utility of having a consistent machine-independent way to get
the syscall number from userspace. But note that this could be probably
accomplished with just a uapi
I won't argue, but it is not clear to me if this is really useful,
given that the debugger can read the regs.
I do see the utility of having a consistent machine-independent way to get
the syscall number from userspace. But note that this could be probably
accomplished with just a uapi header
The Kconfig text for COMPAT_VDSO suggests that glibc versions prior to
2.3.3 may have relied on the fixed address. I can't find anything in the
libc revision history to explain that (AFAIK the code always used
AT_SYSINFO* since it started using the vDSO at all), but it might have been
something
The Kconfig text for COMPAT_VDSO suggests that glibc versions prior to
2.3.3 may have relied on the fixed address. I can't find anything in the
libc revision history to explain that (AFAIK the code always used
AT_SYSINFO* since it started using the vDSO at all), but it might have been
something
There are other cases that just forward declare 'struct siginfo' and use it
instead of the typedef names (e.g. linux/sched.h).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
There are other cases that just forward declare 'struct siginfo' and use it
instead of the typedef names (e.g. linux/sched.h).
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at
> > Again: has this proposal been reviewed by the glibc maintainers? If
> > so, what was their position on it?
>
> Ard have you talked with them? I would expect it would be welcomed.
> Roland, do you know who would be the right person to ask about this
> for glibc? (patch:
Again: has this proposal been reviewed by the glibc maintainers? If
so, what was their position on it?
Ard have you talked with them? I would expect it would be welcomed.
Roland, do you know who would be the right person to ask about this
for glibc? (patch:
The code needs to be macroized a bit so that compat_binfmt_elf.c will
produce a version that encodes 32-bit values correctly so as to be
compatible with the output of a native 32-bit kernel.
It's doubtful that rolling your own single loop actually performs better
than just calling strlen and
> But, somehow I forgot about compat tasks when we discussed this before.
> Perhaps the code above should do
>
> if (is_compat_task())
> copy_siginfo_to_user32(...);
> else
> copy_siginfo_to_user(...);
>
> ?
compat_binfmt_elf.c will define a separate copy
But, somehow I forgot about compat tasks when we discussed this before.
Perhaps the code above should do
if (is_compat_task())
copy_siginfo_to_user32(...);
else
copy_siginfo_to_user(...);
?
compat_binfmt_elf.c will define a separate copy of this
The code needs to be macroized a bit so that compat_binfmt_elf.c will
produce a version that encodes 32-bit values correctly so as to be
compatible with the output of a native 32-bit kernel.
It's doubtful that rolling your own single loop actually performs better
than just calling strlen and
Other ELF notes have per-machine layouts too. It's far more important to
reduce the total number of ways we have to represent the same information.
On a given machine, we already have a layout and we don't want another.
Debuggers and so forth already know how to handle the per-machine layouts.
Other ELF notes have per-machine layouts too. It's far more important to
reduce the total number of ways we have to represent the same information.
On a given machine, we already have a layout and we don't want another.
Debuggers and so forth already know how to handle the per-machine layouts.
I agree with Oleg. If there is an NT_SIGINFO note, it should contain
exactly the siginfo_t layout and data that we otherwise expose to userland
already. That is, it must match what PTRACE_GETSIGINFO reports, which (I
think) also matches exactly what appears on the stack for a signal
delivery.
I agree with Oleg. If there is an NT_SIGINFO note, it should contain
exactly the siginfo_t layout and data that we otherwise expose to userland
already. That is, it must match what PTRACE_GETSIGINFO reports, which (I
think) also matches exactly what appears on the stack for a signal
delivery.
Thanks for the pointers, guys. It took a while for me to figure out what
got wrong to foul up UML, but the bug and fix are trivial (posting now).
Some of the testing I thought had got done clearly wasn't done, since
PTRACE_SETREGS was 100% busticated for 32-bit processes calling ptrace on
x86_64
Simple typo fix for regression introduced by the user_regset changes.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/x86/kernel/ptrace.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index 7
Sorry I haven't replied in this thread sooner.
I would like to see all the BTS and DS work wait until after 2.6.25.
We have a lot of x86 churn in 2.6.25 already, and I think we'd do
better without adding this wrinkle at the same time.
The low-level implementation pieces should gel a bit more in
Sorry I haven't replied in this thread sooner.
I would like to see all the BTS and DS work wait until after 2.6.25.
We have a lot of x86 churn in 2.6.25 already, and I think we'd do
better without adding this wrinkle at the same time.
The low-level implementation pieces should gel a bit more in
Simple typo fix for regression introduced by the user_regset changes.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/x86/kernel/ptrace.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index 702c33e
Thanks for the pointers, guys. It took a while for me to figure out what
got wrong to foul up UML, but the bug and fix are trivial (posting now).
Some of the testing I thought had got done clearly wasn't done, since
PTRACE_SETREGS was 100% busticated for 32-bit processes calling ptrace on
x86_64
include/asm-x86/desc_64.h should have been removed, but is still in the
tree containing just a newline.
Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
> I've been looking at that, at the same time a bunch of ia32/signal.c
> looks like it can go away.
Yes, I meant the 3 into 1 unification.
Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
I've been looking at that, at the same time a bunch of ia32/signal.c
looks like it can go away.
Yes, I meant the 3 into 1 unification.
Thanks,
Roland
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
include/asm-x86/desc_64.h should have been removed, but is still in the
tree containing just a newline.
Thanks,
Roland
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
> I spent some time read you mail carefully and dig into the code again.
>
> And yes, you are right. It's possible that SA_ONSTACK has been cleared
> before the second signal on the same stack comes.
It's not necessary for SA_ONSTACK to have "been cleared", by which I assume
you mean a sigaction
> You mean the comment?
No, that is trivial and already corrected. I mean the substance of your
most recent patch. I described why I think it is wrong. You did not respond.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
> > Please elaborate on the rationale that justifies this change.
> > I don't see it at all.
>
> I have corrected the comment in the latest patch which has been apllied by
> Ingo.
> Please refer to http://lkml.org/lkml/2008/2/18/575 and
> http://lkml.org/lkml/2008/2/19/119 .
You have yet to
> These patches change the behaviour of programs that longjmp out of a
> signal handler on an alternate stack, don't they?
No, they don't. Shi Weihua's original patch had that problem.
Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
> Shouldn't such programs use sigsetjmp/siglongjmp, which should reset the
> signal stack state?
That is not really related. The distinction doesn't really exist for
programs using the normal API (setjmp is sigsetjmp(,1)). What siglongjmp
guarantees handled is signal mask changes, not
This change looks bogus to me. Before I get to the content, there is a nit
that annoys me. You changed the punctuation in my comment so that it no
longer means what it did, and now the comment is nonsensical. I don't
demand decent English from hackers of any linguistic bent, but please don't
This change looks bogus to me. Before I get to the content, there is a nit
that annoys me. You changed the punctuation in my comment so that it no
longer means what it did, and now the comment is nonsensical. I don't
demand decent English from hackers of any linguistic bent, but please don't
Shouldn't such programs use sigsetjmp/siglongjmp, which should reset the
signal stack state?
That is not really related. The distinction doesn't really exist for
programs using the normal API (setjmp is sigsetjmp(,1)). What siglongjmp
guarantees handled is signal mask changes, not
These patches change the behaviour of programs that longjmp out of a
signal handler on an alternate stack, don't they?
No, they don't. Shi Weihua's original patch had that problem.
Thanks,
Roland
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
Please elaborate on the rationale that justifies this change.
I don't see it at all.
I have corrected the comment in the latest patch which has been apllied by
Ingo.
Please refer to http://lkml.org/lkml/2008/2/18/575 and
http://lkml.org/lkml/2008/2/19/119 .
You have yet to say
You mean the comment?
No, that is trivial and already corrected. I mean the substance of your
most recent patch. I described why I think it is wrong. You did not respond.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
I spent some time read you mail carefully and dig into the code again.
And yes, you are right. It's possible that SA_ONSTACK has been cleared
before the second signal on the same stack comes.
It's not necessary for SA_ONSTACK to have been cleared, by which I assume
you mean a sigaction call
> > > sed -n -e 's/^00*/0/' -e 's/^\([0-9a-fA-F]*\) . \(VDSO[a-zA-Z0-9_]*\)$/ =
> > > 0x;/p' | LC_ALL=C sort > arch/x86/vdso/vdso32-sysenter-syms.lds
> >
> > Also show me the vdso32-sysenter-syms.lds file.
>
> Attached.
The contents of this file are fine. If all the vdso32-*-syms.lds files
look
> I'm poking at it. Something in my cross compiling setup is driving this bit
> screwy:
>
> i686-nm arch/x86/vdso/vdso32-sysenter.so.dbg |
Show me the output of just this.
> sed -n -e 's/^00*/0/' -e 's/^\([0-9a-fA-F]*\) . \(VDSO[a-zA-Z0-9_]*\)$/ =
> 0x;/p' | LC_ALL=C sort >
I'm poking at it. Something in my cross compiling setup is driving this bit
screwy:
i686-nm arch/x86/vdso/vdso32-sysenter.so.dbg |
Show me the output of just this.
sed -n -e 's/^00*/0/' -e 's/^\([0-9a-fA-F]*\) . \(VDSO[a-zA-Z0-9_]*\)$/ =
0x;/p' | LC_ALL=C sort
sed -n -e 's/^00*/0/' -e 's/^\([0-9a-fA-F]*\) . \(VDSO[a-zA-Z0-9_]*\)$/ =
0x;/p' | LC_ALL=C sort arch/x86/vdso/vdso32-sysenter-syms.lds
Also show me the vdso32-sysenter-syms.lds file.
Attached.
The contents of this file are fine. If all the vdso32-*-syms.lds files
look sane, then
> Still trying to track down why, but it works on a toolchain built from
> binutils 2.18 and gcc 4.1.3, but not with a toolchain from binutils 2.17 and
> gcc 4.1.2. And considering where it's failing...
I don't think the vdso magic should require so new a binutils. Please try
to figure out
Still trying to track down why, but it works on a toolchain built from
binutils 2.18 and gcc 4.1.3, but not with a toolchain from binutils 2.17 and
gcc 4.1.2. And considering where it's failing...
I don't think the vdso magic should require so new a binutils. Please try
to figure out which
Perhaps it makes more sense to have vdso_install be a dependency of
modules_install rather than install, since they both put things in /lib/modules.
The installed vdso images are potentially useful for a kernel when you
aren't bothering to build or install any modules, but those images are only
Perhaps it makes more sense to have vdso_install be a dependency of
modules_install rather than install, since they both put things in /lib/modules.
The installed vdso images are potentially useful for a kernel when you
aren't bothering to build or install any modules, but those images are only
I don't have any axe to grind here, I just could not figure out how to get
the samples/ modules built (without resorting to make M=.../samples/foo and
clobbering my source directory). If there is another plan, point me to its
documentation. I can't see the point of the Kconfig option for samples
> Sam, is this ok with the samples intent ? I think as long as we do not
> include them with the kernel image and have a "make samples" to build
> them, it's ok. Having them built upon make modules seems like a good
> idea to me.
I"m not sure what you mean by "with the kernel image".
AFAICT,
Sam, is this ok with the samples intent ? I think as long as we do not
include them with the kernel image and have a make samples to build
them, it's ok. Having them built upon make modules seems like a good
idea to me.
Im not sure what you mean by with the kernel image.
AFAICT, everything
I don't have any axe to grind here, I just could not figure out how to get
the samples/ modules built (without resorting to make M=.../samples/foo and
clobbering my source directory). If there is another plan, point me to its
documentation. I can't see the point of the Kconfig option for samples
-$(CONFIG_SAMPLES)
because there is no other conditional like that in the top-level Makefile
and samples/Makefile already uses obj-$(CONFIG_SAMPLES) as if it expects
always to be included.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
Makefile |5 +
1 files changed, 1 insertions
Good change. Making it global was needed temporarily in between some of
the i387 unification patches, but is unnecessary after the final merge.
Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
Good change. Making it global was needed temporarily in between some of
the i387 unification patches, but is unnecessary after the final merge.
Thanks,
Roland
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo
-$(CONFIG_SAMPLES)
because there is no other conditional like that in the top-level Makefile
and samples/Makefile already uses obj-$(CONFIG_SAMPLES) as if it expects
always to be included.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
Makefile |5 +
1 files changed, 1 insertions(+), 4
> You silently overwrite any user ptrace hw breakpoints right? To do it cleanly
> would still require a reservation frame work.
There was work underway on that before (hw_breakpoint). I'm not entirely
sure you want to use fancy stuff like that in kgdb. It's nice for kgdb to
be as
You silently overwrite any user ptrace hw breakpoints right? To do it cleanly
would still require a reservation frame work.
There was work underway on that before (hw_breakpoint). I'm not entirely
sure you want to use fancy stuff like that in kgdb. It's nice for kgdb to
be as self-contained
>
> * Roland McGrath <[EMAIL PROTECTED]> wrote:
>
> > > LD init/built-in.o
> > > distcc[12023] ERROR: compile (null) on localhost failed
> > > make: *** [vmlinux.o] Error 1
> >
> > That message sure looks to me like it could only
> LD init/built-in.o
> distcc[12023] ERROR: compile (null) on localhost failed
> make: *** [vmlinux.o] Error 1
That message sure looks to me like it could only be a distcc bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
I did not see it with your .config either.
> This fails with clean build. And vdso-syms.lds is not empty.
>
> Contents of ?arch/x86/vdso/vdso-syms.lds:
> VDSO64_PRELINK = 0xff70;
> VDSO64_jiffies = 0xff7004b8;
Odd. The missing symbols come from the same place that
Sam might want to experiment with something like:
stdout_target = $(1) > $(@D)/.tmp_$(@F) && mv -f $(@D)/.tmp_$(@F) $@
cmd_foo = $(call stdout_target,blah | sed s/foo/bar/)
to clean up all the places that would benefit from robust treatment for
output files vs interrupted/erring
> if that file is empty, it might be the effect of a Ctrl-C. I sometimes
> get that on .o files, if i Ctrl-C a highly parallel make -j at the wrong
> moment. (is this expected behavior? It's been like this for a long
> time.)
It is the known situation with the compiler since the dawn of time,
I was not able to reproduce this failure. Those symbols should be defined
by arch/x86/vdso/vdso-syms.lds, a file generated by the build. If that
file is empty in your build, remove it and see if it gets regenerated
properly, or try a clean build. If the problem persists, please send me
your
The makefile magic for installing the 32-bit vdso images on disk
had a little error. Only one line of change would fix that bug.
This does a little more to reduce the error-prone duplication of
this bit of makefile variable magic.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
ar
I was not able to reproduce this failure. Those symbols should be defined
by arch/x86/vdso/vdso-syms.lds, a file generated by the build. If that
file is empty in your build, remove it and see if it gets regenerated
properly, or try a clean build. If the problem persists, please send me
your
The makefile magic for installing the 32-bit vdso images on disk
had a little error. Only one line of change would fix that bug.
This does a little more to reduce the error-prone duplication of
this bit of makefile variable magic.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/x86
Sam might want to experiment with something like:
stdout_target = $(1) $(@D)/.tmp_$(@F) mv -f $(@D)/.tmp_$(@F) $@
cmd_foo = $(call stdout_target,blah | sed s/foo/bar/)
to clean up all the places that would benefit from robust treatment for
output files vs interrupted/erring
if that file is empty, it might be the effect of a Ctrl-C. I sometimes
get that on .o files, if i Ctrl-C a highly parallel make -j at the wrong
moment. (is this expected behavior? It's been like this for a long
time.)
It is the known situation with the compiler since the dawn of time, yes.
LD init/built-in.o
distcc[12023] ERROR: compile (null) on localhost failed
make: *** [vmlinux.o] Error 1
That message sure looks to me like it could only be a distcc bug.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
I did not see it with your .config either.
This fails with clean build. And vdso-syms.lds is not empty.
Contents of ?arch/x86/vdso/vdso-syms.lds:
VDSO64_PRELINK = 0xff70;
VDSO64_jiffies = 0xff7004b8;
Odd. The missing symbols come from the same place that VDSO64_jiffies
* Roland McGrath [EMAIL PROTECTED] wrote:
LD init/built-in.o
distcc[12023] ERROR: compile (null) on localhost failed
make: *** [vmlinux.o] Error 1
That message sure looks to me like it could only be a distcc bug.
ok - but it never occured before.
Maye it's just
It sure didn't look to me like paravirt probably worked. But what do I know?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
> Did you test without CONFIG_PARAVIRT, and CONFIG_PARAVIRT booted both with and
> without the "noreplace-paravirt" parameter?
I did not test CONFIG_PARAVIRT at all. I just fixed what its introduction
had done to break generic x86-64.
Thanks,
Roland
--
To unsubscribe from this list: send the
Did you test without CONFIG_PARAVIRT, and CONFIG_PARAVIRT booted both with and
without the noreplace-paravirt parameter?
I did not test CONFIG_PARAVIRT at all. I just fixed what its introduction
had done to break generic x86-64.
Thanks,
Roland
--
To unsubscribe from this list: send the line
It sure didn't look to me like paravirt probably worked. But what do I know?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
> thanks, applied. I suppose you have a testcase for this that we could try?
This should exit 0 and show "wait status 0xb7f", and does on i386.
On 2.6.24 it exits 1 and shows "wait status 0xb".
Note, on the current tree before [PATCH] x86_64: fix iret exception recovery
that I also posted today,
> > thanks, applied. I suppose you have a testcase for this that we could try?
>
> This should exit 0 and show "wait status 0xb7f", and does on i386.
> On 2.6.24 it exits 1 and shows "wait status 0xb".
To clarify, build the case with -m32 but run on x86_64.
Thanks,
Roland
--
To unsubscribe
thanks, applied. I suppose you have a testcase for this that we could try?
This should exit 0 and show wait status 0xb7f, and does on i386.
On 2.6.24 it exits 1 and shows wait status 0xb.
Note, on the current tree before [PATCH] x86_64: fix iret exception recovery
that I also posted today, this
thanks, applied. I suppose you have a testcase for this that we could try?
This should exit 0 and show wait status 0xb7f, and does on i386.
On 2.6.24 it exits 1 and shows wait status 0xb.
To clarify, build the case with -m32 but run on x86_64.
Thanks,
Roland
--
To unsubscribe from this
Date: Fri Apr 29 09:38:44 2005 -0700
x86: make traps on 'iret' be debuggable in user space
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/x86/kernel/entry_64.S | 25 +++--
1 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/arc
hat use, anyone exercising
the minimum of attention to detail expected of anyone touching this
subtle code would realize it needed to change as well.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/x86/kernel/entry_64.S |3 +--
1 files changed, 1 insertions(+), 2 deletions(
this subtlety from being overlooked again.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/x86/kernel/ptrace.c | 25 +++--
1 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index 96286df..702c33e
this subtlety from being overlooked again.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/x86/kernel/ptrace.c | 25 +++--
1 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index 96286df..702c33e 100644
: Fri Apr 29 09:38:44 2005 -0700
x86: make traps on 'iret' be debuggable in user space
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/x86/kernel/entry_64.S | 25 +++--
1 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kernel/entry_64
the minimum of attention to detail expected of anyone touching this
subtle code would realize it needed to change as well.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/x86/kernel/entry_64.S |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/entry_64.S
Sorry I did not get more into this discussion earlier. I still have not
read through all of the email threads. But I have looked over the current
version of your code now in -mm.
I think this work has a great deal of overlap with the perfmon2 project.
There are two facets that overlap, which
Sorry I did not get more into this discussion earlier. I still have not
read through all of the email threads. But I have looked over the current
version of your code now in -mm.
I think this work has a great deal of overlap with the perfmon2 project.
There are two facets that overlap, which
> On Thu, Jan 24, 2008 at 05:59:33PM -0800, Roland McGrath wrote:
> > + if (pos > 0 || count < sizeof(env))
> > + convert_from_fxsr(, target);
>
> Well, is the generic regset code enforce the need for this now? Can we
> disallow the usage cases where
On Thu, Jan 24, 2008 at 05:59:33PM -0800, Roland McGrath wrote:
+ if (pos 0 || count sizeof(env))
+ convert_from_fxsr(env, target);
Well, is the generic regset code enforce the need for this now? Can we
disallow the usage cases where the user passes smaller target buffer
-by: Suresh Siddha <[EMAIL PROTECTED]>
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/x86/kernel/i387.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c
index 7e354a3..26719bd 100644
--- a/arch/x86/k
-by: Suresh Siddha [EMAIL PROTECTED]
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/x86/kernel/i387.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c
index 7e354a3..26719bd 100644
--- a/arch/x86/kernel/i387.c
+++ b
I agree that RUSAGE_THREAD is fine. (In fact, if you'd pressed me to
remember without looking, I would have assumed we put it in already.)
However, in the implementation, I would keep it cleaner by moving the
identical code from inside the loop under case RUSAGE_SELF into a shared
subfunction,
This adds the RUSAGE_THREAD option for the getrusage system call.
Solaris calls this RUSAGE_LWP and uses the same value (1).
That name is not a natural one for Linux, but we keep it as an alias.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
include/linux/resource.h |2 ++
Oops, I overlooked the use of elf_core_copy_regs in kernel/kexec.c. It
is certainly safe and fine to reintroduce the old macro. Everything
removed in the "x86 user_regset cleanup" patch is purely removing code
and it doesn't hurt to have it back (it's just all unused except for this
kexec nit).
Oops, I overlooked the use of elf_core_copy_regs in kernel/kexec.c. It
is certainly safe and fine to reintroduce the old macro. Everything
removed in the x86 user_regset cleanup patch is purely removing code
and it doesn't hurt to have it back (it's just all unused except for this
kexec nit).
1 - 100 of 1061 matches
Mail list logo
