Messages in this thread | | | Subject | Linux-2.3.x: new page locking semantics must break NFS. | From | Trond Myklebust <> | Date | 10 Oct 1999 16:49:51 +0200 |
| |
Hi,
I've been spending the past week working on NFS for linux-2.3.x, and have finally gotten round to looking at the new page locking semantics.
It seems to me that the decision to allow readaheads to be performed without the page lock being held must break the NFS client, since it uses the page lock in order to serialize the actual page IO. We rely on the fact that reading in a page locks the page in order to prevent any new asynchronous writebacks being scheduled while the read is going on, and vice-versa.
One solution, would be for the NFS readpage() code to ignore any readahead requests that are not accompanied by a page lock, but the decision to lift the kernel lock around page locks means that the read code can no longer rely on that behaviour (the operation lock page + call inode->i_op->readpage() not being atomic).
Furthermore, the fact that the readpage() call is still required to unlock the page after IO completion is inherently wrong, because of the above fact that readpage() has no way of knowing who locked the page. Unless we make the 'page->owner' debugging field permanent --something that will still break asynchronous IO-- unlocking the page must be done by the generic_file_xxx() function itself.
If the asynchronous networked filesystems are the only ones to have problems, then I suggest that we define a new page flag that can be used by these filesystems to serialize page IO independently of whether the page lock is set or not.
#define PG_IOlock 13
and
#define PageIOLocked(page) (test_bit(PG_IOlock, &(page)->flags)) #define TryIOLockPage(page) (test_and_set_bit(PG_IOlock, &(page)->flags)) #define IOUnlockPage(page) \ do { \ if (!test_and_clear_bit(PG_IOlock, &(page)->flags)) \ PAGE_BUG(); \ wake_up(&(page)->wait); \ } while(0)
Comments?
Cheers, Trond
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |