All of lore.kernel.org
 help / color / mirror / Atom feed
From: Franck Bui-Huu <vagabon.xyz@gmail.com>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: linux-mips@linux-mips.org
Subject: Re: flush_kernel_dcache_page() not needed ?
Date: Mon, 03 Sep 2007 17:36:16 +0200	[thread overview]
Message-ID: <46DC29F0.3060200@gmail.com> (raw)
In-Reply-To: <20070903.225239.61509667.anemo@mba.ocn.ne.jp>

Atsushi Nemoto wrote:
> On Fri, 31 Aug 2007 14:25:03 +0200, Franck Bui-Huu <vagabon.xyz@gmail.com> wrote:
>> I noticed that there's currently (v2.6.23-rc4) no implementation
>> of this function even for mips CPUs that have dcache aliasing.
>>
>> Could anybody explain why ?
> 
> Maybe because the API was not called by anybody until 2.6.23-rc1 :)
> 

But this function has been introduced since commit
5a3a5a98b6422d05c39eaa32c8b3f83840c7b768 ([PATCH] Add
flush_kernel_dcache_page() API) which had been merged during 2.6.16
merge window. So it's more than one year now...

Basically it gives a default implementation for all architectures. The
problem here is that this implementation may be boggus for
architectures that have dcache aliasing issue.

The sad thing is that the kernel will silently compile this default
implementation. At least, it could have showed a big fat warning
during the building process.

> Now copy_strings() calls this and I'm wondering we should implement or
> not.  It seems the kernel works fine for me without the API...
 
Do you use a cpu with dcache aliasing issue ?

> Do you have any problem due to luck of the API?

No, but looking at copy_strings(), I think we can have some trouble.

BTW, do you recall flush_anon_page() and fuse bug ? It seems the same
here...

		Franck

  reply	other threads:[~2007-09-03 15:36 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-31 12:25 flush_kernel_dcache_page() not needed ? Franck Bui-Huu
2007-08-31 14:50 ` Markus Gothe
2007-08-31 15:04   ` Franck Bui-Huu
2007-08-31 23:42   ` Ralf Baechle
2007-09-02 21:12     ` Markus Gothe
2007-08-31 14:54 ` Markus Gothe
2007-09-03 13:52 ` Atsushi Nemoto
2007-09-03 15:36   ` Franck Bui-Huu [this message]
2007-09-03 15:54     ` Atsushi Nemoto
2007-09-04 12:46       ` Franck Bui-Huu
2007-09-04 13:54         ` Atsushi Nemoto
2007-09-04 14:05           ` Franck Bui-Huu
2007-09-04 14:16             ` Atsushi Nemoto
2007-09-04 14:17               ` Franck Bui-Huu
2007-09-05 15:33         ` Atsushi Nemoto
2007-09-07  9:00           ` Franck Bui-Huu
2007-09-14  8:32           ` Franck Bui-Huu
2007-09-14 14:29             ` Atsushi Nemoto
2007-09-14 15:47               ` Franck Bui-Huu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46DC29F0.3060200@gmail.com \
    --to=vagabon.xyz@gmail.com \
    --cc=anemo@mba.ocn.ne.jp \
    --cc=linux-mips@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.