Re: [PATCH 1 of 2] block_page_mkwrite() Implementation V2

2007-05-16 Thread David Chinner
On Wed, May 16, 2007 at 11:19:29AM +0100, David Howells wrote: > > However, page_mkwrite() isn't told which bit of the page is going to be > written to. This means it has to ask prepare_write() to make sure the whole > page is filled in. In other words, offset and to must be equal (in AFS I set

Re: [PATCH 1 of 2] block_page_mkwrite() Implementation V2

2007-05-16 Thread Nick Piggin
David Howells wrote: Nick Piggin <[EMAIL PROTECTED]> wrote: Dave is using prepare_write here to ensure blocks are allocated in the given range. The filesystem's ->nopage function must ensure it is uptodate before allowing it to be mapped. Which is fine... assuming it's called. For blockdev

Re: [PATCH 1 of 2] block_page_mkwrite() Implementation V2

2007-05-16 Thread David Howells
David Woodhouse <[EMAIL PROTECTED]> wrote: > Really? Is it _really_ going to be modified? Well, generic_file_buffered_write() doesn't check the success of the copy before calling commit_write(), presumably because it uses fault_in_pages_readable() first. David - To unsubscribe from this list: se

Re: [PATCH 1 of 2] block_page_mkwrite() Implementation V2

2007-05-16 Thread David Howells
Nick Piggin <[EMAIL PROTECTED]> wrote: > Dave is using prepare_write here to ensure blocks are allocated in the > given range. The filesystem's ->nopage function must ensure it is uptodate > before allowing it to be mapped. Which is fine... assuming it's called. For blockdev-based filesystems, t

Re: [PATCH 1 of 2] block_page_mkwrite() Implementation V2

2007-05-16 Thread Chris Mason
On Wed, May 16, 2007 at 11:04:11PM +1000, Nick Piggin wrote: > Chris Mason wrote: > >On Wed, May 16, 2007 at 08:09:19PM +0800, David Woodhouse wrote: > > > >>On Wed, 2007-05-16 at 11:19 +0100, David Howells wrote: > >> > >>>The start and end points passed to block_prepare_write() delimit the > >>>

Re: [PATCH 1 of 2] block_page_mkwrite() Implementation V2

2007-05-16 Thread Nick Piggin
Chris Mason wrote: On Wed, May 16, 2007 at 08:09:19PM +0800, David Woodhouse wrote: On Wed, 2007-05-16 at 11:19 +0100, David Howells wrote: The start and end points passed to block_prepare_write() delimit the region of the page that is going to be modified. This means that prepare_write() do

Re: [PATCH 1 of 2] block_page_mkwrite() Implementation V2

2007-05-16 Thread Chris Mason
On Wed, May 16, 2007 at 08:09:19PM +0800, David Woodhouse wrote: > On Wed, 2007-05-16 at 11:19 +0100, David Howells wrote: > > The start and end points passed to block_prepare_write() delimit the region > > of > > the page that is going to be modified. This means that prepare_write() > > doesn't

Re: [PATCH 1 of 2] block_page_mkwrite() Implementation V2

2007-05-16 Thread David Woodhouse
On Wed, 2007-05-16 at 11:19 +0100, David Howells wrote: > The start and end points passed to block_prepare_write() delimit the region of > the page that is going to be modified. This means that prepare_write() > doesn't need to fill it in if the page is not up to date. Really? Is it _really_ goi

Re: [PATCH 1 of 2] block_page_mkwrite() Implementation V2

2007-05-16 Thread Nick Piggin
David Howells wrote: David Chinner <[EMAIL PROTECTED]> wrote: + ret = block_prepare_write(page, 0, end, get_block); As I understand the way prepare_write() works, this is incorrect. I think it is actually OK. The start and end points passed to block_prepare_write() delimit the re

Re: [PATCH 1 of 2] block_page_mkwrite() Implementation V2

2007-05-16 Thread David Howells
David Chinner <[EMAIL PROTECTED]> wrote: > + ret = block_prepare_write(page, 0, end, get_block); As I understand the way prepare_write() works, this is incorrect. The start and end points passed to block_prepare_write() delimit the region of the page that is going to be modified. This means

Re: [PATCH 1 of 2] block_page_mkwrite() Implementation V2

2007-03-19 Thread Nick Piggin
Christoph Hellwig wrote: On Mon, Mar 19, 2007 at 09:11:31PM +1100, Nick Piggin wrote: I've got the patches in -mm now. I hope they will get merged when the the next window opens. I didn't submit the ->page_mkwrite conversion yet, because I didn't have any callers to look at. It is is slightly

Re: [PATCH 1 of 2] block_page_mkwrite() Implementation V2

2007-03-19 Thread Christoph Hellwig
On Mon, Mar 19, 2007 at 09:11:31PM +1100, Nick Piggin wrote: > I've got the patches in -mm now. I hope they will get merged when the > the next window opens. > > I didn't submit the ->page_mkwrite conversion yet, because I didn't > have any callers to look at. It is is slightly less trivial than f

Re: [PATCH 1 of 2] block_page_mkwrite() Implementation V2

2007-03-19 Thread Nick Piggin
Nick Piggin wrote: David Chinner wrote: On Mon, Mar 19, 2007 at 05:37:03PM +1100, Nick Piggin wrote: David Chinner wrote: +block_page_mkwrite(struct vm_area_struct *vma, struct page *page, + get_block_t get_block) +{ +struct inode *inode = vma->vm_file->f_path.dentry->d_inod

Re: [PATCH 1 of 2] block_page_mkwrite() Implementation V2

2007-03-19 Thread Nick Piggin
Christoph Hellwig wrote: On Mon, Mar 19, 2007 at 10:30:08AM +1100, David Chinner wrote: Generic page_mkwrite functionality. Filesystems that make use of the VM ->page_mkwrite() callout will generally use the same core code to implement it. There are several tricky truncate-related issues that

Re: [PATCH 1 of 2] block_page_mkwrite() Implementation V2

2007-03-19 Thread Nick Piggin
David Chinner wrote: On Mon, Mar 19, 2007 at 05:37:03PM +1100, Nick Piggin wrote: David Chinner wrote: +block_page_mkwrite(struct vm_area_struct *vma, struct page *page, + get_block_t get_block) +{ + struct inode *inode = vma->vm_file->f_path.dentry->d_inode; +

Re: [PATCH 1 of 2] block_page_mkwrite() Implementation V2

2007-03-19 Thread Christoph Hellwig
On Mon, Mar 19, 2007 at 10:30:08AM +1100, David Chinner wrote: > > Generic page_mkwrite functionality. > > Filesystems that make use of the VM ->page_mkwrite() callout will generally > use > the same core code to implement it. There are several tricky truncate-related > issues that we need to de

Re: [PATCH 1 of 2] block_page_mkwrite() Implementation V2

2007-03-19 Thread David Chinner
On Mon, Mar 19, 2007 at 05:37:03PM +1100, Nick Piggin wrote: > David Chinner wrote: > > > >+/* > >+ * block_page_mkwrite() is not allowed to change the file size as it gets > >+ * called from a page fault handler when a page is first dirtied. Hence > >we must > >+ * be careful to check for EOF co

Re: [PATCH 1 of 2] block_page_mkwrite() Implementation V2

2007-03-18 Thread Nick Piggin
David Chinner wrote: Generic page_mkwrite functionality. Filesystems that make use of the VM ->page_mkwrite() callout will generally use the same core code to implement it. There are several tricky truncate-related issues that we need to deal with here as we cannot take the i_mutex as we normall

[PATCH 1 of 2] block_page_mkwrite() Implementation V2

2007-03-18 Thread David Chinner
Generic page_mkwrite functionality. Filesystems that make use of the VM ->page_mkwrite() callout will generally use the same core code to implement it. There are several tricky truncate-related issues that we need to deal with here as we cannot take the i_mutex as we normally would for these path