Re: [PATCH]: uClinux (MMU-less) patches against 2.5.28

[David Woodhouse <dwmw2@infradead.org>]

>  Also a page can be locked because another I/O read is pending on it
> (ie its already in someone elses read/page in handling and currently
> has invalid data). 

If it has invalid data, then it's not an XIP page -- it's in RAM. XIP pages 
are either present or not present because the chip is otherwise occupied -- 
in neither case do they need to be locked for I/O. 

> You would need to be sure we never ended up with deadlocks for any case 
> where we have  
> 	process 1 copying page X from flash 2 to flash 1 page Y
> 	process 2 copying page Y from flash 1 to flash 2 page X
> With jffs2 and temporary buffering I guess it works out.  

Buffering is required for other reasons, and it's what saves us here. The 
thing that'll do the 'write lock' on the flash is the raw flash write 
operation, and that can't take a userspace pointer, it takes a kernel 
pointer. So we were buffering anyway (yes we could have locked it down and 
used it directly but we don't). 

So you get process 1 doing copy_from_user which reads from flash 2, then
passing the buffer into the write function for flash 1. And process 2 doing 
the converse. Each drops the read lock before getting a write lock -- in 
fact the page was never _locked_, it could be paged back out again to allow 
writes to happen between each byte that copy_from_user() fetched.

--
dwmw2