Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 19 Apr 2013 20:55:30 +0800
From:      Julian Elischer <julian@freebsd.org>
To:        Carl Shapiro <carl.shapiro@gmail.com>
Cc:        Konstantin Belousov <kostikbel@gmail.com>, FreeBSD Hackers <freebsd-hackers@freebsd.org>
Subject:   Re: MADV_FREE and wait4 EFAULT
Message-ID:  <51713EC2.4030401@freebsd.org>
In-Reply-To: <CANVK_QgRBO5ZU=NHCr1XTvtxYpWk6LjWEv8Q-70mY6CzqHO2TA@mail.gmail.com>
References:  <CANVK_QgKRkpzWjA=H2u2HTp_vpxFhNLBGTVuFZmMEpBLTbzeaA@mail.gmail.com> <20130417082143.GW2930@kib.kiev.ua> <CANVK_QgRBO5ZU=NHCr1XTvtxYpWk6LjWEv8Q-70mY6CzqHO2TA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 4/19/13 5:51 AM, Carl Shapiro wrote:
> On Wed, Apr 17, 2013 at 1:21 AM, Konstantin Belousov <kostikbel@gmail.com>wrote:
>
>> Did you ensured with e.g. ktrace and procstat -v that your assumptions
>> hold, i.e. the addresses supplied as wait4(2) arguments are valid ?
>> Please provide the minimal test case demonstrating the behaviour.
>>
> Yes.  I instrumented my code to check for a wait4 failure, print the
> addresses of the status and rusage arguments, and dump the contents of
> /proc/curproc/map.  The addresses of the status and rusage arguments are
> always in the range of a mapping and marked as read write.
>
> I have yet to distill the failure to a minimal test case.  The test case I
> do have is the test harness for the Go language.  After running for about
> 45 minutes I can observe a failure.  I have been working to produce
> something smaller and faster.
>
>
>> MADV_FREE should only result in the possible lost of the previous
>> content of the page, not in the faulting of the page access. From the
>> inspection of the code, I do not see how MADV_FREE could result in
>> the memory address becoming invalid.
>>
> I see.  What has lead us to believe this might be an issue with page faults
> is that writing zeroes to the page with memset before passing it to wait4
> makes the error go away.
>
> Do you have any advice about how one might go about instrumenting wait4 to
> generate more information about a failed copyout?  Are tools such as dtrace
> useful in these situations or might it be too invasive?  Because of the
> protracted test cycle and my lack of knowledge in this area, conducting
> experiments is quite painful at the moment.

looks like a great example of something that dtrace should be able to 
help with.
basically you can do a speculative dump of the stuff going on before 
the copyout
and just store it in the case where the copyout fails.

I'm just learning getting my dtrace training wheels but I think it may 
be able to give you what you need.




>
> Thanks,
>
> Carl
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
>
>




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51713EC2.4030401>