Add a machanism to see how much of a kernel stack is used. This
allocates zeroed stacks and sees where the lowest non-zero byte is on
process exit. It keeps track of the lowest value and logs values as
they get lower.
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
--
arch/um/Kconfig.debug
For some reason, I was using kmalloc instead of get_free_pages for
kernel stacks.
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
--
include/asm-um/thread_info.h |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
Index: linux-2.6.21-mm/include/asm-um/thread_info.h
On Tue, Jun 19, 2007 at 11:54:22AM -0700, Andrew Morton wrote:
On Tue, 19 Jun 2007 14:42:45 -0400
Jeff Dike [EMAIL PROTECTED] wrote:
Add a machanism to see how much of a kernel stack is used. This
allocates zeroed stacks and sees where the lowest non-zero byte is on
process exit
I recieved from Guido Guenther the patch below to the TUN/TAP driver
which allows group ownerships to be effective.
It seems reasonable to me.
> the attached patches allow tun ownership by group. We found this useful
> since we can then spawn tapX devices on system boot (via
>
I recieved from Guido Guenther the patch below to the TUN/TAP driver
which allows group ownerships to be effective.
It seems reasonable to me.
the attached patches allow tun ownership by group. We found this useful
since we can then spawn tapX devices on system boot (via
[<08058e75>] new_thread_handler+0x62/0x8b
098efffc: [] 0xa55a5a5a
[ jdike - added BUG_TABLE to linker script ]
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
include/asm-um
Add asm-um/paravirt.h so that i386 headers that get pulled into UML
don't cause build failures when they want asm/paravirt.h.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
include/asm-um/paravirt.h |6 ++
1 file changed, 6 insertions(+)
Index: linux-2.6.21-mm/include/asm-um/para
These two are for 2.6.22.
The first switches to the generic BUG support and adds a related build
fix. The second is a build fix for configurations which pull in i386
headers which want paravirt.h.
Jeff
--
Work email - jdike at linux dot intel dot com
-
To
On Fri, Jun 15, 2007 at 11:53:55AM +0530, Arun Raghavan wrote:
> Hello,
> I ran into some compilations problems with UML on the 2.6.22-rc4 kernel.
> The problem turns up because "paravirt.h" is included in a couple of
> headers in asm-i386 without being protected by a "#ifdef CONFIG_PARAVIRT".
>
On Fri, Jun 15, 2007 at 11:53:55AM +0530, Arun Raghavan wrote:
Hello,
I ran into some compilations problems with UML on the 2.6.22-rc4 kernel.
The problem turns up because paravirt.h is included in a couple of
headers in asm-i386 without being protected by a #ifdef CONFIG_PARAVIRT.
I've
Add asm-um/paravirt.h so that i386 headers that get pulled into UML
don't cause build failures when they want asm/paravirt.h.
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
--
include/asm-um/paravirt.h |6 ++
1 file changed, 6 insertions(+)
Index: linux-2.6.21-mm/include/asm-um/paravirt.h
-off-by: Jeff Dike [EMAIL PROTECTED]
--
include/asm-um/bug.h|2 +-
include/asm-um/common.lds.S |2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
Index: linux-2.6.21-mm/include/asm-um/bug.h
===
--- linux-2.6.21
These two are for 2.6.22.
The first switches to the generic BUG support and adds a related build
fix. The second is a build fix for configurations which pull in i386
headers which want paravirt.h.
Jeff
--
Work email - jdike at linux dot intel dot com
-
To
than a pty device since lots of hosts have LEGACY_PTYS
disabled. This had always been failing on such hosts, but silently.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
arch/um/defconfig |2 +-
arch/um/drivers/chan_kern.c | 23 +++
arch/um/d
Cleanup, mostly style violations.
Tidied the includes.
getmaster returns a real errno, which pty_open returns if there's a
problem.
The printks now have severity.
Changed os_* calls to call libc directly.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
arch/um/drivers/pty.c
directly with the userspace
versions of the gfp flags.
kmalloc isn't a real procedure, so I had to essentially copy the
inline wrapper around __kmalloc.
vmalloc also had its own wrapper for no good reason. This is now gone.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
arch/um/d
.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
arch/um/drivers/chan_user.c |2 +-
arch/um/drivers/harddog_user.c |2 +-
arch/um/drivers/net_user.c |2 +-
arch/um/drivers/port_user.c |2 +-
arch/um/drivers/slip_
This patch set is code cleanup, mostly. It can wait until after 2.6.22.
Jeff
-
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
the descriptor is disabled.
register_winch_irq is now much better about cleaning up after an
initialization failure.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
arch/um/drivers/chan_user.c | 70 +---
arch/um/drivers/line.c
On Thu, Jun 14, 2007 at 07:38:33AM +0200, Nick Piggin wrote:
> Get UML to use the generic bug support rather than arch specific one.
Added to my tree, thanks.
Jeff
--
Work email - jdike at linux dot intel dot com
-
To unsubscribe from this list: send the line
On Thu, Jun 14, 2007 at 07:38:33AM +0200, Nick Piggin wrote:
Get UML to use the generic bug support rather than arch specific one.
Added to my tree, thanks.
Jeff
--
Work email - jdike at linux dot intel dot com
-
To unsubscribe from this list: send the line unsubscribe
This patch set is code cleanup, mostly. It can wait until after 2.6.22.
Jeff
-
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
the descriptor is disabled.
register_winch_irq is now much better about cleaning up after an
initialization failure.
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
--
arch/um/drivers/chan_user.c | 70 +---
arch/um/drivers/line.c | 60
directly with the userspace
versions of the gfp flags.
kmalloc isn't a real procedure, so I had to essentially copy the
inline wrapper around __kmalloc.
vmalloc also had its own wrapper for no good reason. This is now gone.
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
--
arch/um/drivers/cow_sys.h
.
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
--
arch/um/drivers/chan_user.c |2 +-
arch/um/drivers/harddog_user.c |2 +-
arch/um/drivers/net_user.c |2 +-
arch/um/drivers/port_user.c |2 +-
arch/um/drivers/slip_user.c
Cleanup, mostly style violations.
Tidied the includes.
getmaster returns a real errno, which pty_open returns if there's a
problem.
The printks now have severity.
Changed os_* calls to call libc directly.
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
--
arch/um/drivers/pty.c | 76
than a pty device since lots of hosts have LEGACY_PTYS
disabled. This had always been failing on such hosts, but silently.
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
--
arch/um/defconfig |2 +-
arch/um/drivers/chan_kern.c | 23 +++
arch/um/drivers
of xterm_open are closer to being right
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
arch/um/drivers/ssl.c |2
arch/um/drivers/stdio_console.c |2
arch/um/drivers/xterm.c | 173
arch/um/drivers/xterm_kern.c
ed-off-by: Eduard-Gabriel Munteanu <[EMAIL PROTECTED]>
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
arch/um/drivers/chan_user.c |8 +++-
arch/um/drivers/mconsole_user.c |5 +++--
arch/um/drivers/ubd_user.c |6 ++
arch/um/drivers/xterm.c |7 ++
These two are for 2.6.22. We have a patch which makes UML boot with
DEBUG_SHIRQ enabled and one which cleans up the xterm driver.
Jeff
--
Work email - jdike at linux dot intel dot com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
These two are for 2.6.22. We have a patch which makes UML boot with
DEBUG_SHIRQ enabled and one which cleans up the xterm driver.
Jeff
--
Work email - jdike at linux dot intel dot com
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
of xterm_open are closer to being right
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
--
arch/um/drivers/ssl.c |2
arch/um/drivers/stdio_console.c |2
arch/um/drivers/xterm.c | 173
arch/um/drivers/xterm_kern.c| 49 +++
arch
-by: Eduard-Gabriel Munteanu [EMAIL PROTECTED]
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
--
arch/um/drivers/chan_user.c |8 +++-
arch/um/drivers/mconsole_user.c |5 +++--
arch/um/drivers/ubd_user.c |6 ++
arch/um/drivers/xterm.c |7 +++
4 files changed, 23
value of
PAGE_SIZE everywhere. It's conceivable that it could be built with a
larger PAGE_SIZE, and use of getpagesize() would break that badly.
PAGE_MASK got the same treatment, as it is closely tied to PAGE_SIZE.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
arch/um/include/common-off
The x86_64 a.out.h got a definition of STACK_TOP_MAX, which interferes
with the UML version. So, just undef it like STACK_TOP.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
include/asm-um/a.out.h |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6.21-mm/include/asm-um/a
These are a couple of UML build fixes for 2.6.22.
Jeff
--
Work email - jdike at linux dot intel dot com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Tue, Jun 12, 2007 at 08:44:37AM +0300, Eduard-Gabriel Munteanu wrote:
> Okay, I don't have an x86_64, sparc64 or something similar, as my
> computer is an x86, so I can't contradict this. If everything is fine on
> such arches, no fix is needed when nothing's broken... though I still
> think
On Tue, Jun 12, 2007 at 08:44:37AM +0300, Eduard-Gabriel Munteanu wrote:
Okay, I don't have an x86_64, sparc64 or something similar, as my
computer is an x86, so I can't contradict this. If everything is fine on
such arches, no fix is needed when nothing's broken... though I still
think
The x86_64 a.out.h got a definition of STACK_TOP_MAX, which interferes
with the UML version. So, just undef it like STACK_TOP.
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
--
include/asm-um/a.out.h |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6.21-mm/include/asm-um/a.out.h
These are a couple of UML build fixes for 2.6.22.
Jeff
--
Work email - jdike at linux dot intel dot com
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
value of
PAGE_SIZE everywhere. It's conceivable that it could be built with a
larger PAGE_SIZE, and use of getpagesize() would break that badly.
PAGE_MASK got the same treatment, as it is closely tied to PAGE_SIZE.
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
--
arch/um/include/common-offsets.h
On Tue, Jun 12, 2007 at 01:39:25AM +0300, Eduard-Gabriel Munteanu wrote:
> The cast isn't done right. Doing "fd = (long) dev_id;" doesn't help,
> since you pass fd to mconsole_get_request() as is. And
> mconsole_get_request() expects an integer:
> int mconsole_get_request(int fd, struct
On Mon, Jun 11, 2007 at 10:39:56PM +0300, Eduard-Gabriel Munteanu wrote:
> No offense, but this is an ugly hack.
I'm not going to defend it too much, but the alternatives don't seem any
better to me.
> What if sizeof(int) != sizeof(long)?
Doesn't matter - the casting will preserve the value.
On Mon, Jun 11, 2007 at 01:01:57AM +0300, Eduard-Gabriel Munteanu wrote:
> DEBUG_SHIRQ generates spurious interrupts, triggering handlers such as
> mconsole_interrupt() or line_interrupt(). They expect data to be
> available to be read from their sockets/pipes, but in the case of
> spurious
On Mon, Jun 11, 2007 at 01:01:57AM +0300, Eduard-Gabriel Munteanu wrote:
DEBUG_SHIRQ generates spurious interrupts, triggering handlers such as
mconsole_interrupt() or line_interrupt(). They expect data to be
available to be read from their sockets/pipes, but in the case of
spurious
On Mon, Jun 11, 2007 at 10:39:56PM +0300, Eduard-Gabriel Munteanu wrote:
No offense, but this is an ugly hack.
I'm not going to defend it too much, but the alternatives don't seem any
better to me.
What if sizeof(int) != sizeof(long)?
Doesn't matter - the casting will preserve the value.
On Tue, Jun 12, 2007 at 01:39:25AM +0300, Eduard-Gabriel Munteanu wrote:
The cast isn't done right. Doing fd = (long) dev_id; doesn't help,
since you pass fd to mconsole_get_request() as is. And
mconsole_get_request() expects an integer:
int mconsole_get_request(int fd, struct mc_request
On Thu, Jun 07, 2007 at 08:09:48AM +0300, Avi Kivity wrote:
> Some extra logic is needed on i386 with >= 4GB. Current code will
> wraparound since gfn_t is 32-bits long, but casting it to 64-bits is not
> the answer since the processor will truncate it back to 32 bits (the
> return value is
On Fri, Jun 08, 2007 at 09:26:01AM -0700, Zach Brown wrote:
> >I don't like it :-)
>
> For a fundamental reason or because it happens to not work yet? :)
The latter - it fails the test that I posted.
Jeff
--
Work email - jdike at linux dot intel dot com
-
To
On Thu, Jun 07, 2007 at 04:27:33PM -0700, Zach Brown wrote:
> On Thu, May 31, 2007 at 02:19:23PM -0400, Jeff Dike wrote:
> > cachemiss_thread should explicitly return 0 or error instead of
> > task_ret_reg(current) (which is -ENOSYS anyway) because
> > async_thread_hel
On Thu, Jun 07, 2007 at 01:10:23PM -0700, Linus Torvalds wrote:
> HOWEVER.
>
> I think we could introduce a *single* new system call, which does
> basically a "run the specified system call with the following flags".
As long as we are considering indirecting system calls, how about
reviving
On Thu, Jun 07, 2007 at 04:27:33PM -0700, Zach Brown wrote:
On Thu, May 31, 2007 at 02:19:23PM -0400, Jeff Dike wrote:
cachemiss_thread should explicitly return 0 or error instead of
task_ret_reg(current) (which is -ENOSYS anyway) because
async_thread_helper is careful to put the return
On Thu, Jun 07, 2007 at 01:10:23PM -0700, Linus Torvalds wrote:
HOWEVER.
I think we could introduce a *single* new system call, which does
basically a run the specified system call with the following flags.
As long as we are considering indirecting system calls, how about
reviving your
On Fri, Jun 08, 2007 at 09:26:01AM -0700, Zach Brown wrote:
I don't like it :-)
For a fundamental reason or because it happens to not work yet? :)
The latter - it fails the test that I posted.
Jeff
--
Work email - jdike at linux dot intel dot com
-
To
On Thu, Jun 07, 2007 at 08:09:48AM +0300, Avi Kivity wrote:
Some extra logic is needed on i386 with = 4GB. Current code will
wraparound since gfn_t is 32-bits long, but casting it to 64-bits is not
the answer since the processor will truncate it back to 32 bits (the
return value is eventually
On Thu, Jun 07, 2007 at 01:29:23PM +1000, Benjamin Herrenschmidt wrote:
> But you use ptrace and don't steal signals with dequeue_signal() on a
> live other task, which is ok.
True. However, with an SMP UML running a threaded app (which is also
threads on the host), if the thread on one CPU gets
On Thu, Jun 07, 2007 at 01:29:23PM +1000, Benjamin Herrenschmidt wrote:
But you use ptrace and don't steal signals with dequeue_signal() on a
live other task, which is ok.
True. However, with an SMP UML running a threaded app (which is also
threads on the host), if the thread on one CPU gets a
On Thu, Jun 07, 2007 at 10:13:42AM +0800, Li, Xin B wrote:
> >-static int rmode_tss_base(struct kvm* kvm)
> >+static unsigned long rmode_tss_base(struct kvm* kvm)
>
> Should use gpa_t instead.
Right you are, I didn't notice that type.
Will fix.
Jeff
--
Work
On Thu, Jun 07, 2007 at 08:43:42AM +1000, Paul Mackerras wrote:
> What Ben was talking about was stealing a synchronous SEGV from a task
> without stopping it, and as Ben says that makes no sense.
> Intercepting a signal and stopping the task is reasonable, and that is
> what ptrace does, and I
The long return value of rmode_tss_base is truncated by its declared
return type of int.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
drivers/kvm/vmx.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: kvm/drivers/kvm
Include linux/kernel.h wherever simple_strtoul is used. This kills a
compile warning in stderr_console.c and potential ones in the other
files.
This also fixes a bunch of style violations in exitcode.c.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
arch/um/drivers/line.c
L_STACK_ORDER and see if the problem
goes away.
As for something sterner, it turns out that Kbuild provides some
support for this. So, drop the previous patch in favor of this one:
Force KERNEL_STACK_ORDER to be at least 1 on UML/x86_64.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
arch/um/Kco
On Wed, Jun 06, 2007 at 12:50:04PM +1000, Benjamin Herrenschmidt wrote:
> Yeah, synchronous signals should probably never be delivered to another
> process, even via signalfd. There's no point delivering a SEGV to
> somebody else :-)
Sure there is. UML does exactly that - intercepting child
On Wed, Jun 06, 2007 at 12:50:04PM +1000, Benjamin Herrenschmidt wrote:
Yeah, synchronous signals should probably never be delivered to another
process, even via signalfd. There's no point delivering a SEGV to
somebody else :-)
Sure there is. UML does exactly that - intercepting child signals
sterner, it turns out that Kbuild provides some
support for this. So, drop the previous patch in favor of this one:
Force KERNEL_STACK_ORDER to be at least 1 on UML/x86_64.
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
--
arch/um/Kconfig |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6.21-mm
Include linux/kernel.h wherever simple_strtoul is used. This kills a
compile warning in stderr_console.c and potential ones in the other
files.
This also fixes a bunch of style violations in exitcode.c.
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
--
arch/um/drivers/line.c |1
The long return value of rmode_tss_base is truncated by its declared
return type of int.
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
--
drivers/kvm/vmx.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: kvm/drivers/kvm/vmx.c
On Thu, Jun 07, 2007 at 08:43:42AM +1000, Paul Mackerras wrote:
What Ben was talking about was stealing a synchronous SEGV from a task
without stopping it, and as Ben says that makes no sense.
Intercepting a signal and stopping the task is reasonable, and that is
what ptrace does, and I assume
On Thu, Jun 07, 2007 at 10:13:42AM +0800, Li, Xin B wrote:
-static int rmode_tss_base(struct kvm* kvm)
+static unsigned long rmode_tss_base(struct kvm* kvm)
Should use gpa_t instead.
Right you are, I didn't notice that type.
Will fix.
Jeff
--
Work email -
On Tue, Jun 05, 2007 at 05:00:01PM -0700, Andrew Morton wrote:
> On Tue, 5 Jun 2007 16:50:55 -0400
> Jeff Dike <[EMAIL PROTECTED]> wrote:
>
> > [ This is 2.6.22 material ]
> >
> > Having KERNEL_STACK_ORDER in defconfig overrides the value provided by
> > Kc
Make the PTRACE_SYSEMU checking more robust. It will make sure that
system call numbers are reported correctly. If there is a problem, it
will disable PTRACE_SYSEMU use and use PTRACE_SYSCALL instead.
This fixes a hang on boot on FC6 hosts with a broken PTRACE_SYSEMU.
Signed-off-by: Jeff Dike
.
In this case, the update will dereference a freed pointer.
To avoid this, I delay the update until processing the next sg
segment, when the request pointer is known to be good.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
arch/um/drivers/ubd_kern.c |6 --
1 file changed, 4 inse
[ This is 2.6.22 material ]
Having KERNEL_STACK_ORDER in defconfig overrides the value provided by
Kconfig, breaking UML/x86_64, which wants 2 page stacks.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
arch/um/defconfig |1 -
1 file changed, 1 deletion(-)
Index: linux-2.6.21-mm/a
.
In this case, the update will dereference a freed pointer.
To avoid this, I delay the update until processing the next sg
segment, when the request pointer is known to be good.
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
--
arch/um/drivers/ubd_kern.c |6 --
1 file changed, 4 insertions
[ This is 2.6.22 material ]
Having KERNEL_STACK_ORDER in defconfig overrides the value provided by
Kconfig, breaking UML/x86_64, which wants 2 page stacks.
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
--
arch/um/defconfig |1 -
1 file changed, 1 deletion(-)
Index: linux-2.6.21-mm/arch/um
Make the PTRACE_SYSEMU checking more robust. It will make sure that
system call numbers are reported correctly. If there is a problem, it
will disable PTRACE_SYSEMU use and use PTRACE_SYSCALL instead.
This fixes a hang on boot on FC6 hosts with a broken PTRACE_SYSEMU.
Signed-off-by: Jeff Dike
On Tue, Jun 05, 2007 at 05:00:01PM -0700, Andrew Morton wrote:
On Tue, 5 Jun 2007 16:50:55 -0400
Jeff Dike [EMAIL PROTECTED] wrote:
[ This is 2.6.22 material ]
Having KERNEL_STACK_ORDER in defconfig overrides the value provided by
Kconfig, breaking UML/x86_64, which wants 2 page
On Mon, Jun 04, 2007 at 10:45:42AM -0700, Zach Brown wrote:
> > Second, security. What happens if a well-written server starts life
> > as root, does some (async) I/O, and setuids to a non-root uid? There
> > will be a bunch of async threads still running as root, with the
> > result that async
Syslets seem like a fundamentally good idea to me, but the current
implementation, using CLONE_THREAD threads, seems like a basic
problem.
First, there are signals. If the app has an interval timer enabled,
every thread will inherit it and you will have 32 threads getting
alarms, which seems
Syslets seem like a fundamentally good idea to me, but the current
implementation, using CLONE_THREAD threads, seems like a basic
problem.
First, there are signals. If the app has an interval timer enabled,
every thread will inherit it and you will have 32 threads getting
alarms, which seems
On Mon, Jun 04, 2007 at 10:45:42AM -0700, Zach Brown wrote:
Second, security. What happens if a well-written server starts life
as root, does some (async) I/O, and setuids to a non-root uid? There
will be a bunch of async threads still running as root, with the
result that async
Fix the stack malloc failure check.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
syslets/async-test-v5/sys.h |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6/syslets/async-test-v5/sys.h
===
---
Fix the stack malloc failure check.
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
--
syslets/async-test-v5/sys.h |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6/syslets/async-test-v5/sys.h
===
--- linux-2.6
On Thu, May 31, 2007 at 03:07:16PM -0700, Zach Brown wrote:
> Can you explain what motivated you to send out this patch?
>
> It used to return 0. It was changed because, unlike the syslet
> syscalls, sys_io_submit() doesn't have a simple 0 value to indicate
> success. The current implementation
cachemiss_thread should explicitly return 0 or error instead of
task_ret_reg(current) (which is -ENOSYS anyway) because
async_thread_helper is careful to put the return value in eax anyway.
On x86_64, it looks like async_child_rip is similarly careful.
Signed-off-by: Jeff Dike <[EMAIL PROTEC
wait-sleep uses the async_exec mechanism to collect timer expirations
and child process wait status. It randomly fires off a number of
sleeps and forks, waiting for them to finish, and firing off something
new to replace anything that finishes.
Signed-off-by: Jeff Dike <[EMAIL PROTEC
aio-read uses the async_exec mechanism to queue reads of pages of a
file. As completions come in, new reads are queued until all pages in
the file have requests queued or finished. When that has happened, it
just waits for the remaining completions to come in.
Signed-off-by: Jeff Dike <[EM
Add a bunch of includes to sys.h and syslet.h to kill off compilation warnings.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
sys.h|7 +++
syslet.h |2 ++
2 files changed, 9 insertions(+)
Index: async-test-v5
aio-read uses the async_exec mechanism to queue reads of pages of a
file. As completions come in, new reads are queued until all pages in
the file have requests queued or finished. When that has happened, it
just waits for the remaining completions to come in.
Signed-off-by: Jeff Dike [EMAIL
Add a bunch of includes to sys.h and syslet.h to kill off compilation warnings.
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
--
sys.h|7 +++
syslet.h |2 ++
2 files changed, 9 insertions(+)
Index: async-test-v5/sys.h
wait-sleep uses the async_exec mechanism to collect timer expirations
and child process wait status. It randomly fires off a number of
sleeps and forks, waiting for them to finish, and firing off something
new to replace anything that finishes.
Signed-off-by: Jeff Dike [EMAIL PROTECTED
cachemiss_thread should explicitly return 0 or error instead of
task_ret_reg(current) (which is -ENOSYS anyway) because
async_thread_helper is careful to put the return value in eax anyway.
On x86_64, it looks like async_child_rip is similarly careful.
Signed-off-by: Jeff Dike [EMAIL PROTECTED
On Thu, May 31, 2007 at 03:07:16PM -0700, Zach Brown wrote:
Can you explain what motivated you to send out this patch?
It used to return 0. It was changed because, unlike the syslet
syscalls, sys_io_submit() doesn't have a simple 0 value to indicate
success. The current implementation
On Fri, May 25, 2007 at 06:35:13PM -0700, Roland McGrath wrote:
> Oops! I overlooked the need to preserve the orig_eax value, though its
> necessity is obvious. This makes me wonder about those previous
> reports that UML was working OK.
The one from me was on x86_64, where PTRACE_SYSEMU isn't
On Fri, May 25, 2007 at 06:35:13PM -0700, Roland McGrath wrote:
Oops! I overlooked the need to preserve the orig_eax value, though its
necessity is obvious. This makes me wonder about those previous
reports that UML was working OK.
The one from me was on x86_64, where PTRACE_SYSEMU isn't an
ubd_add returns 0 when there could actually be an error to report.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
arch/um/drivers/ubd_kern.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.21-mm/arch/um/drivers/ubd_
Make the PTRACE_SYSEMU checking more robust. It will make sure that
system call numbers are reported correctly. If there is a problem, it
will disable PTRACE_SYSEMU use and use PTRACE_SYSCALL instead.
Thanks to Balaji G for helping reproduce this problem.
Signed-off-by: Jeff Dike <[EM
One of them is really more a workaround for a host bug than a UML bug
fix, but it does robustify the early boot checks a bit, and makes UML
boot on current FC6, so it's worth going in 2.6.22.
The other is a trivial error return fix in the ubd driver.
Jeff
--
for each action or refuse to register an IRQ if
there is a mismatched IRQF_DISABLED.
--
Work email - jdike at linux dot intel dot com
Refuse to register an IRQ if it has a mismatched IRQF_DISABLED with
what's already in the IRQ chain.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
kern
On Tue, May 22, 2007 at 11:46:11PM -0700, Roland McGrath wrote:
> (It also works for free on other arch's if you want to #define the
> constants there.)
(Forgot to mention...) sweet
Jeff
--
Work email - jdike at linux dot intel dot com
-
To unsubscribe from this list: send the
801 - 900 of 1742 matches
Mail list logo
