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
| ||
|
Date: Sat, 09 Jun 2007 09:55:15 +0200 From: Carsten Otte <cotte@...ibm.com> To: Jörn Engel <joern@...ybastard.org> CC: carsteno@...ibm.com, 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 Jörn Engel wrote: > 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. No. That's how the callback could look alike. > 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. Hmmh. We won't need mtd->pre_write(), because the file system's get_xip_page aop will have to ask mtd for the address anyway similar to the way ext2_get_xip_page does call bdev_ops->direct_access. If that call would pass the information whether the future access is read-only or read+write, the device driver could do its housekeeping. I think we should also cover put_page() plus mtd->post_write() inside a put_xip_page() address space operation provided by the fs. This way calls are balanced, and we have stuff in a single place rather then duplicating code. The fs could rely on a generic implementation in filemap_xip in case it does'nt need to do its own magic here. >> - 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. That point was indeed confusing. Let my try again: The only way, how an initial reference to a page can be retrieved, is from the driver by using a bdev_ops->direct_access alike call. The driver has to be able to check, if all references have been returned. That would be done in three steps: 1. stop handing out new references 2. use the unmap_page_range callback to get references for page table entries back 3. check if other (temporary) references are still handed out, wait until they get returned. Using a helper function to look into page->count is a possible implementation for #3. And because the page->count cannot get changed while noone has a reference, I don't see a race condition in looping over all pages and checking page->count. This implementation has an advantage, if the device driver wants to make sure that a small page range is not accessed. If the device driver needs to ensure that there are no references to any page on the enitre flash media, it might use a global counter to count the sum of references and save looping over all pages. so long, Carsten - 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/
Powered by blists - more mailing lists