> 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- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jul 30 2002 - 14:00:24 EST