linux-kernel - Re: [PATCH update6] drivers: add LCD support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 2 Nov 2006 11:13:11 -0800
From:	Andrew Morton <akpm@...l.org>
To:	"Miguel Ojeda" <maxextreme@...il.com>
Cc:	Franck <vagabon.xyz@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH update6] drivers: add LCD support

On Thu, 2 Nov 2006 14:44:56 +0000
"Miguel Ojeda" <maxextreme@...il.com> wrote:

> > Sorry for the short/fast question. I'm wondering how does the cache
> > behave here. You have 2 virtual addresses that point to the same
> > location in physical RAM: kernel frame buffer which has a kernel
> > virtual address and the vma you're returning when an application mmap
> > the device. This last address is a user virtual address and is
> > different from the first one.
> >
> > Now let's say that some of the kernel frame buffer data are in the
> > data cache and never be invalidate during this example. The
> 
> Sorry, I don't understand what do you mean with this sentence.

Some CPU architectures experience what Documentation/cachetlb.txt calls
"virtual aliasing in the data cache".

If you map the same physical page at virtual address A1 and also at another
virtual address A2 then writes to address A1 do not necessarily appear
correctly at address A2.  This because the write to A1 is stuck in the CPU
cache and the CPU hardware doesn't know that read from A2 is accessing the
same page.

The solutions to this are:

a) add lots of flushing everywhere (see Documentation/cachetlb.txt, I
   guess) (this documentation is maddening: it uses the term "flush" for
   both writeback and for invalidation.  In this context,
   flush==writeback).

b) If you select the correct virtual addresses for A1 and A2 (ie: ensure
   that the mmap() handler returns an address which correlates with the
   page's kernel address) then apparently the aliasing goes away.

   So, for example, if the kernel's view of the page is at 0xd0102000
   then you make sure that userspace's address for the page is at
   0xnnn02000 (for some length of nnn).

   I don't know what the mmap handler has to do to arrange for this to
   happen.

c) add `depends on x86' to your Kconfig ;)

davem and rmk are (amongst others) the guys for this stuff.  afaik it isn't
documented anywhere.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/