| To: | Atsushi Nemoto <anemo@mba.ocn.ne.jp> |
|---|---|
| Subject: | Re: flush_kernel_dcache_page() not needed ? |
| From: | Franck Bui-Huu <vagabon.xyz@gmail.com> |
| Date: | Fri, 07 Sep 2007 11:00:04 +0200 |
| Cc: | linux-mips@linux-mips.org |
| Dkim-signature: | v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=9KVJqN9EDqTeivmn9wys5BLitwMfxK4aATbe4HONg4M=; b=af1Gnx+XZSoLBhsNTTs+/0I8z6pIcaAjeSWU4mSdEc6OK55E+rUBlh1uaeYaPSxh+LwO2E2vp/YBNnVAn0wApuXtcGeSZQkSq2KvW/FqQUv6CYAZHzz7Wu5p3OjoCCzZmExyNZ0aMO+NvUi/u8agVlVTHZOf97/wsmyxRjyA1eM= |
| Domainkey-signature: | a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=U/SusDcvCnkZ/G8VXu7Ylf5JrKhKZasanvZggALKTbuuBG7Zallje3oKlu1VURjMpHssyBfvBs4Qh7PcIP801OUxAFf3QYPAGS+K0RrfWvTK9pFlY2XeU4T+A4oOI8ZM/oCEn91zjSoe+nBeVuqzbmE5UpFMqU9Tel3s8Ch+ccQ= |
| In-reply-to: | <20070906.003320.25909195.anemo@mba.ocn.ne.jp> |
| Original-recipient: | rfc822;linux-mips@linux-mips.org |
| References: | <46DC29F0.3060200@gmail.com> <20070904.005400.52128244.anemo@mba.ocn.ne.jp> <46DD53BE.2070004@gmail.com> <20070906.003320.25909195.anemo@mba.ocn.ne.jp> |
| Sender: | linux-mips-bounce@linux-mips.org |
| User-agent: | Thunderbird 2.0.0.5 (X11/20070719) |
Atsushi Nemoto wrote:
> On Tue, 04 Sep 2007 14:46:54 +0200, Franck Bui-Huu <vagabon.xyz@gmail.com>
> wrote:
>> One thing you might want to try is:
>>
>> $ echo 0 > /proc/sys/kernel/randomize_va_space
>>
>> and see if your system still works fine. This command should avoid a
>> data cache flush when moving the stack around. See shift_arg_pages().
>>
>> With this, maybe you could give this testcase a try:
>>
>> $ /bin/echo "`seq 10000`" > seq.txt
>>
>> and see if seq.txt is correct. This command should pass to echo (not
>> the bash builtin one) a long argument that should fill your
>> dcache.
>
> I tried this and everything worked fine with/without the
> flush_kernel_dcache_page() ;)
>
>> That said the execve syscall code is quite 'hairy' and it may not be
>> suprising that after this syscall the dcache has been completly
>> flushed and thus make the problem disappear.
>
> Yes, there is an yet another path to "flush all dcache".
>
> do_execve()
> copy_strings()
> flush_kernel_dcache_page()
> search_binary_handler()
> load_elf_binary()
> flush_old_exec()
> exec_mmap()
> mmput()
> exit_mmap()
> flush_cache_mm()
> r4k_blast_dcache()
>
> Anyway, the implementation of flush_kernel_dcache_page() is very
> simple so that we can believe it works correctly without any testcase.
> Too optimistic? :)
god only knows ;)
Franck
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH][MIPS][7/7] AR7: ethernet, Geert Uytterhoeven |
|---|---|
| Next by Date: | Processor cores for FPGAs... any recommendations?, Stuart Longland |
| Previous by Thread: | Re: flush_kernel_dcache_page() not needed ?, Atsushi Nemoto |
| Next by Thread: | Re: flush_kernel_dcache_page() not needed ?, Franck Bui-Huu |
| Indexes: | [Date] [Thread] [Top] [All Lists] |