linux-kernel - Re: [PATCH 2.6.21] cramfs: add cramfs Linear XIP

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 8 Jun 2007 21:36:07 +0200
From:	Jörn Engel <joern@...ybastard.org>
To:	carsteno@...ibm.com
Cc:	Christoph Hellwig <hch@...radead.org>,
	Jared Hulbert <jaredeh@...il.com>,
	Nick Piggin <nickpiggin@...oo.com.au>,
	Andrew Morton <akpm@...ux-foundation.org>,
	richard.griffiths@...driver.com,
	Richard Griffiths <res07ml0@...izon.net>,
	Linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2.6.21] cramfs: add cramfs Linear XIP

Whenever writes/erases to the device happen, the device driver would
need to call a function like

/**
 * unmap_page_range - remove all mapping to the given range of an address space
 * @mapping - the address space in question
 * @start_index - index of the first page in the range
 * @no_pages - number of pages to get unmapped
 *
 * Returns 0 on success or a negative errno value.
 */
int unmap_page_range(struct address_space *mapping, loff_t start_index,
		loff_t no_pages);

or implement something equivalent itself.  Your filesystem callback
looks like it would be just that, although I may be misreading you.

On Fri, 8 June 2007 21:04:17 +0200, Carsten Otte wrote:
> I think it needs to work like this:
> - temporary references (for read/write syscalls and friends) get 
> retrieved via get_xip_page and returned again via to-be-invented 
> put_page/page_cache_release

Either that or using standard mtd->read() and mtd->write() calls.  I see
some advantages to mtd->write() in particular, as the device driver
needs some notification to trigger unmap_page_range() before the actual
write and chip state transitions happen.  mtd->write() seems much easier
than something like

mtd->pre_write()
get_xip_page()
...
put_page()
mtd->post_write()

If get_xip_page() only has userland consumers all the locking can be
kept inside device drivers.

> - permanent references (for mapping to userland) get retrieved via 
> get_xip_page and don't get returned until unmap

Yep.

> - the device driver can access page->count via a helper function 
> provided by mm. This way, it can identify which pages are in use.

One of us is confused here.  The driver would have to check page->count
for a large range of pages, usually the whole chip.  And it would have
to tear down every single mapping before starting to write.  Is that
possible and desirable to do with page->count?  Unsure.

> - In order to get references back, the device driver can call a 
> callback provided by the file system. A default implementation will go 
> to filemap_xip.c. This callback would use rmap to find all mappings, 
> and unmap the page via xip_file_unmap()[mm/filemap_xip.c].

Jörn

-- 
Time? What's that? Time is only worth what you do with it.
-- Theo de Raadt
-
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/