Re: [uml-devel] fsx-linux loosing mmap() writes under memory pressure

2009-03-05 Thread Nick Piggin
On Thursday 05 March 2009 21:05:16 Jan Kara wrote: On Thu 05-03-09 13:55:43, Nick Piggin wrote: On Thursday 05 March 2009 04:50:31 Jan Kara wrote: On Wed 04-03-09 16:55:35, Jan Kara wrote: On Wed 04-03-09 15:51:09, Jan Kara wrote: first, I'd like to point out that this has

Re: [uml-devel] fsx-linux loosing mmap() writes under memory pressure

2009-03-04 Thread Nick Piggin
On Thursday 05 March 2009 04:50:31 Jan Kara wrote: On Wed 04-03-09 16:55:35, Jan Kara wrote: On Wed 04-03-09 15:51:09, Jan Kara wrote: first, I'd like to point out that this has happened under UML so it can be just some obscure bug in that architecture but I belive it's worth

Re: [uml-devel] [PATCH 4/6] UML - free() wrapper should call libc free

2007-05-01 Thread Nick Piggin
Jeff Dike wrote: The libc free wrapper wasn't correctly detecting buffers obtained with malloc(). This is now done by seeing if the page was reserved. This is the case for memory which is left aside for libc and isn't given to the page allocator. If we free a pointer in a reserved page, it

[uml-devel] Re: [patch 18/39] remap_file_pages protection support: add VM_FAULT_SIGSEGV

2005-08-15 Thread Nick Piggin
Russell King wrote: On Fri, Aug 12, 2005 at 08:21:45PM +0200, [EMAIL PROTECTED] wrote: @@ -632,10 +632,11 @@ static inline int page_mapped(struct pag * Used to decide whether a process gets delivered SIGBUS or * just gets major/minor fault counters bumped up. */ -#define VM_FAULT_OOM (-1)

[uml-devel] Re: [RFC] (How to) Let idle CPUs sleep

2005-05-09 Thread Nick Piggin
Srivatsa Vaddagiri wrote: On Sun, May 08, 2005 at 02:14:23PM +1000, Nick Piggin wrote: Yeah probably something around that order of magnitude. I suspect there will fast be a point where either you'll get other timers going off more frequently, and / or you simply get very quickly diminishing

Re: [uml-devel] [patch 02/12] uml: cpu_relax fix

2005-03-23 Thread Nick Piggin
Blaisorblade wrote: On Wednesday 23 March 2005 18:09, Bodo Stroesser wrote: [EMAIL PROTECTED] wrote: Use rep_nop instead of barrier for cpu_relax, following $(SUBARCH)'s doing that (i.e. i386 and x86_64). IIRC, Jeff had the idea, to use sched_yield() for this (from a discussion on #uml). Hmm,

[uml-devel] Re: [PATCH] fix wait_task_inactive race (was Re: Race condition in ptrace)

2005-02-05 Thread Nick Piggin
Ingo Molnar wrote: * Nick Piggin [EMAIL PROTECTED] wrote: When a task is put to sleep, it is dequeued from the runqueue while it is still running. The problem is that the runqueue lock can be dropped and retaken in schedule() before the task actually schedules off, and wait_task_inactive did

[uml-devel] Re: [PATCH] fix wait_task_inactive race (was Re: Race condition in ptrace)

2005-02-05 Thread Nick Piggin
Nick Piggin wrote: Ingo Molnar wrote: * Nick Piggin [EMAIL PROTECTED] wrote: When a task is put to sleep, it is dequeued from the runqueue while it is still running. The problem is that the runqueue lock can be dropped and retaken in schedule() before the task actually schedules off

[uml-devel] [PATCH] fix wait_task_inactive race (was Re: Race condition in ptrace)

2005-02-05 Thread Nick Piggin
Nick Piggin wrote: Something like the following (untested) extension of Bodo's work could be the minimal fix for 2.6.11. As I've said though, I'd consider it a hack and prefer to do something about the locking. That could be done after 2.6.11 though. Depends how you feel. I think this is the right

[uml-devel] Re: Race condition in ptrace

2005-02-04 Thread Nick Piggin
Andrew Morton wrote: Nick Piggin [EMAIL PROTECTED] wrote: Bodo Stroesser wrote: Nick Piggin wrote: Bodo Stroesser wrote: I don't see how this could help because AFAIKS, child-saving is only set and cleared while the runqueue is locked. And the same runqueue lock is taken by wait_task_inactive

[uml-devel] Re: Race condition in ptrace

2005-02-03 Thread Nick Piggin
Bodo Stroesser wrote: Working with the new UML skas0 mode on my Xeon HT host, sporadically I saw some processes on UML segfaulting. In all cases, I could track this down to be caused by a gs segment register, that had the wrong contents. This again is caused by a problem in the host linux: A