linux-kernel - Re: [PATCH 2.6.19-rc1 full] 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]

Message-ID: <45461890.2000007@grupopie.com>
Date:	Mon, 30 Oct 2006 15:21:52 +0000
From:	Paulo Marques <pmarques@...popie.com>
To:	Miguel Ojeda <maxextreme@...il.com>
CC:	Franck <vagabon.xyz@...il.com>, akpm@...l.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2.6.19-rc1 full] drivers: add LCD support

Miguel Ojeda wrote:
>[...]
>> In this case, if nothing was ever written to the display, the CPU usage
>> would be _zero_ (as it should), and it would work nicely with dynticks
>> and such.
> 
> Hum, interesting. But what happens if...
> 
> 1. For example, the userspace app maps the fb (nopage is called, dirty
> flag set, timer created), and then the app doesn't use the fb. The
> timer will refresh the LCD, without anything new to refresh, so we are
> wasting CPU time. After refreshing, the driver clears the dirty flag
> and unmap the buffer.
> 
> 2. After some seconds, the userspace app decides to write the buffer.
> As it is not mmaped anymore, it will simply get a segmentation fault,
> right? AFAIK nopage() is not called again because we have destroyed
> the mmapping information, and Linux can't know what are the nopage()
> ops to call to.

No, this is not the sequence I thought of at all. I don't remember the 
exact API functions you need to call (I have to read LDD3 again ;), but 
if the hardware supports it, there must be a way. The plan is something 
like:

  - at mmap time you return a pointer to something that is not actually 
mapped, and do nothing else

  - when userspace actually writes to that area, you get a page fault, 
and nopage is called. At this point you map the page, and set the dirty 
state. All other writes from userspace until the timer completes are 
done without faulting.

  - when the timer completes, you unmap the page so that the next access 
will generate a fault again

As I said, I don't remember the exact details, but this should be doable.

-- 
Paulo Marques - www.grupopie.com

"The face of a child can say it all, especially the
mouth part of the face."
-
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/