linux-kernel - Re: [PATCH 2.6.20 1/1] fbdev,mm: hecuba/E-Ink fbdev driver

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: <45a44e480702210846u218045bmfe6854fb894d7bbd@mail.gmail.com>
Date:	Wed, 21 Feb 2007 11:46:21 -0500
From:	"Jaya Kumar" <jayakumar.lkml@...il.com>
To:	"Paul Mundt" <lethal@...ux-sh.org>,
	"Jaya Kumar" <jayakumar.lkml@...il.com>,
	"Peter Zijlstra" <a.p.zijlstra@...llo.nl>,
	linux-fbdev-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	jsimmons@...radead.org, Geert.Uytterhoeven@...ycom.com
Subject: Re: [PATCH 2.6.20 1/1] fbdev,mm: hecuba/E-Ink fbdev driver

On 2/20/07, Jaya Kumar <jayakumar.lkml@...il.com> wrote:
> On 2/19/07, Paul Mundt <lethal@...ux-sh.org> wrote:
> > That works for me, though I'd prefer for struct page_list to be done with
> > a scatterlist, then it's trivial to setup from the workqueue context
> > without having to shuffle things around.
> >
>
> Ok. Will check out when implementing.
>

Took  a quick look. If I used scatterlist, I'd still need to build a
list of scatterlist to pass to the driver callback. The alternative
being a preallocated array of scatterlist based on the page count of
the framebuffer, which seems expensive since scatterlist has page,
offset, dma and length.

On a separate note, Peter pointed out that it may be possible to reuse
page->lru instead of using a struct page_list. This would enable
something like:

in mkwrite:
mutex_lock
list_add(page->lru, defio->pagelist)
mutex_unlock

in deferred handler:
mutex_lock
for_each page {
lock_page
mkclean
unlock_page
}
callback(fb_info, pagelist)
for_each page {
list_del
}
mutex_unlock

The advantage of reusing page->lru is that avoids needing the struct
page_list and allocation in mkwrite. Is the above exploitation of
->lru ok with mm folk?

In above, we're iterating over the page list twice. I have to mkclean
before calling the callback to avoid the situation where a touched
page is missed by the callback. I don't see a way around that part.

Thanks,
jaya
-
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/