From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Carlos O'Donell" Subject: Re: futex wait failure Date: Tue, 23 Mar 2010 17:32:11 -0400 Message-ID: <119aab441003231432nefa1848u86a9313fc1e45a5f@mail.gmail.com> References: <20100307171207.GA22856@hiauly1.hia.nrc.ca> <20100307203230.CAC964E77@hiauly1.hia.nrc.ca> <20100311032049.GA14312@hiauly1.hia.nrc.ca> <20100311135418.GA22698@bombadil.infradead.org> <20100311224044.GA18789@hiauly1.hia.nrc.ca> <20100313020647.GA26384@hiauly1.hia.nrc.ca> <20100315011024.GA7309@hiauly1.hia.nrc.ca> <119aab441003160449n11cf5272qb9d15fa97625dd7d@mail.gmail.com> <20100321181935.GA19525@hiauly1.hia.nrc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Cc: Kyle McMartin , deller@gmx.de, linux-parisc@vger.kernel.org To: John David Anglin Return-path: In-Reply-To: <20100321181935.GA19525@hiauly1.hia.nrc.ca> List-ID: List-Id: linux-parisc.vger.kernel.org On Sun, Mar 21, 2010 at 2:19 PM, John David Anglin wrote: > One thought that has crossed my mind is that the memory pages allocat= ed > for the stack region used by the thread are somehow getting interchan= ged > between parent and child by the fork operation. =A0This happens fairl= y > late as both the parent and thread are executing post fork at the tim= e > this happens. =A0Possibly, this is part of the bug. > > I have looked at entry.S and pacache.S quite a bit and it's not obvio= us > how this could happen, although I must admit to not fully understandi= ng > the tmp alias code. =A0I tend to think the bug is in the core mm code= =2E > > I see a few cleanups to entry.S. =A0We didn't kill the misnamed macro= s > (DEP, DEPI and EXTR) for example. =A0But I don't think these are the = problem. I can't get minifail2 to fail, how are you choosing which stack address to watch for corruption? Are you looking at the child's new stack created by mmap? Are you looking at the parent's stack? I found one bug in the hppa vfork() function call, which in the case of error, would fail to propagate the error correctly. Fixing that and will check it in. It doesn't account for the vfork/execve problems though, since in this case vfork completes but execve crashes. I also have some patches for asm-offsets.c, and entry.S to comment some of the code better. I'll send those to Kyle after cleanup. Cheers, Carlos. -- To unsubscribe from this list: send the line "unsubscribe linux-parisc"= in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html