On Fri, Dec 15, 2006 at 10:53:18AM -0800, Chen, Kenneth W wrote:
> Christoph Hellwig wrote on Friday, December 15, 2006 2:44 AM
> > So we're doing the sync_page_range once in __generic_file_aio_write
> > with i_mutex held.
> >
> >
> > > mutex_lock(>i_mutex);
> > > - ret =
On Fri, Dec 15, 2006 at 10:53:18AM -0800, Chen, Kenneth W wrote:
Christoph Hellwig wrote on Friday, December 15, 2006 2:44 AM
So we're doing the sync_page_range once in __generic_file_aio_write
with i_mutex held.
mutex_lock(inode-i_mutex);
- ret =
Christoph Hellwig wrote on Friday, December 15, 2006 2:44 AM
> So we're doing the sync_page_range once in __generic_file_aio_write
> with i_mutex held.
>
>
> > mutex_lock(>i_mutex);
> > - ret = __generic_file_aio_write_nolock(iocb, iov, nr_segs,
> > - >ki_pos);
> > +
> +ssize_t
> +__generic_file_aio_write(struct kiocb *iocb, const struct iovec *iov,
> + unsigned long nr_segs, loff_t pos)
I'd still call this generic_file_aio_write_nolock.
> + loff_t *ppos = >ki_pos;
I'd rather use iocb->ki_pos directly in the few
+ssize_t
+__generic_file_aio_write(struct kiocb *iocb, const struct iovec *iov,
+ unsigned long nr_segs, loff_t pos)
I'd still call this generic_file_aio_write_nolock.
+ loff_t *ppos = iocb-ki_pos;
I'd rather use iocb-ki_pos directly in the few
Christoph Hellwig wrote on Friday, December 15, 2006 2:44 AM
So we're doing the sync_page_range once in __generic_file_aio_write
with i_mutex held.
mutex_lock(inode-i_mutex);
- ret = __generic_file_aio_write_nolock(iocb, iov, nr_segs,
- iocb-ki_pos);
+ ret =
Andrew Morton wrote on Tuesday, December 12, 2006 2:40 AM
> On Tue, 12 Dec 2006 16:18:32 +0300
> Dmitriy Monakhov <[EMAIL PROTECTED]> wrote:
>
> > >> but according to filemaps locking rules: mm/filemap.c:77
> > >> ..
> > >> * ->i_mutex(generic_file_buffered_write)
> > >> *
Andrew Morton <[EMAIL PROTECTED]> writes:
> On Tue, 12 Dec 2006 16:18:32 +0300
> Dmitriy Monakhov <[EMAIL PROTECTED]> wrote:
>
>> >> but according to filemaps locking rules: mm/filemap.c:77
>> >> ..
>> >> * ->i_mutex (generic_file_buffered_write)
>> >> *->mmap_sem
On Tue, 12 Dec 2006 16:18:32 +0300
Dmitriy Monakhov <[EMAIL PROTECTED]> wrote:
> >> but according to filemaps locking rules: mm/filemap.c:77
> >> ..
> >> * ->i_mutex (generic_file_buffered_write)
> >> *->mmap_sem (fault_in_pages_readable->do_page_fault)
> >>
Andrew Morton <[EMAIL PROTECTED]> writes:
> On Tue, 12 Dec 2006 15:20:52 +0300
> Dmitriy Monakhov <[EMAIL PROTECTED]> wrote:
>
>> > XFS (at least) can call generic_file_direct_write() with i_mutex not held.
>> > And vmtruncate() expects i_mutex to be held.
>> >
>> > I guess a suitable solution
On Tue, 12 Dec 2006 15:20:52 +0300
Dmitriy Monakhov <[EMAIL PROTECTED]> wrote:
> > XFS (at least) can call generic_file_direct_write() with i_mutex not held.
> > And vmtruncate() expects i_mutex to be held.
> >
> > I guess a suitable solution would be to push this problem back up to the
> >
Andrew Morton <[EMAIL PROTECTED]> writes:
> On Mon, 11 Dec 2006 16:34:27 +0300
> Dmitriy Monakhov <[EMAIL PROTECTED]> wrote:
>
>> OpenVZ team has discovered error inside generic_file_direct_write()
>> If generic_file_direct_IO() has fail (ENOSPC condition) it may have
>> instantiated
>> a few
Andrew Morton [EMAIL PROTECTED] writes:
On Mon, 11 Dec 2006 16:34:27 +0300
Dmitriy Monakhov [EMAIL PROTECTED] wrote:
OpenVZ team has discovered error inside generic_file_direct_write()
If generic_file_direct_IO() has fail (ENOSPC condition) it may have
instantiated
a few blocks outside
On Tue, 12 Dec 2006 15:20:52 +0300
Dmitriy Monakhov [EMAIL PROTECTED] wrote:
XFS (at least) can call generic_file_direct_write() with i_mutex not held.
And vmtruncate() expects i_mutex to be held.
I guess a suitable solution would be to push this problem back up to the
callers: let
Andrew Morton [EMAIL PROTECTED] writes:
On Tue, 12 Dec 2006 15:20:52 +0300
Dmitriy Monakhov [EMAIL PROTECTED] wrote:
XFS (at least) can call generic_file_direct_write() with i_mutex not held.
And vmtruncate() expects i_mutex to be held.
I guess a suitable solution would be to push
On Tue, 12 Dec 2006 16:18:32 +0300
Dmitriy Monakhov [EMAIL PROTECTED] wrote:
but according to filemaps locking rules: mm/filemap.c:77
..
* -i_mutex (generic_file_buffered_write)
*-mmap_sem (fault_in_pages_readable-do_page_fault)
..
I'm confused
Andrew Morton [EMAIL PROTECTED] writes:
On Tue, 12 Dec 2006 16:18:32 +0300
Dmitriy Monakhov [EMAIL PROTECTED] wrote:
but according to filemaps locking rules: mm/filemap.c:77
..
* -i_mutex (generic_file_buffered_write)
*-mmap_sem
Andrew Morton wrote on Tuesday, December 12, 2006 2:40 AM
On Tue, 12 Dec 2006 16:18:32 +0300
Dmitriy Monakhov [EMAIL PROTECTED] wrote:
but according to filemaps locking rules: mm/filemap.c:77
..
* -i_mutex(generic_file_buffered_write)
*-mmap_sem
On Tue, 12 Dec 2006 12:22:14 +0300
Dmitriy Monakhov <[EMAIL PROTECTED]> wrote:
> >> @@ -2041,6 +2041,14 @@ generic_file_direct_write(struct kiocb *
> >>mark_inode_dirty(inode);
> >>}
> >>*ppos = end;
> >> + } else if (written < 0) {
> >> +
Andrew Morton <[EMAIL PROTECTED]> writes:
> On Mon, 11 Dec 2006 16:34:27 +0300
> Dmitriy Monakhov <[EMAIL PROTECTED]> wrote:
>
>> OpenVZ team has discovered error inside generic_file_direct_write()
>> If generic_file_direct_IO() has fail (ENOSPC condition) it may have
>> instantiated
>> a few
On Mon, 11 Dec 2006 16:34:27 +0300
Dmitriy Monakhov <[EMAIL PROTECTED]> wrote:
> OpenVZ team has discovered error inside generic_file_direct_write()
> If generic_file_direct_IO() has fail (ENOSPC condition) it may have
> instantiated
> a few blocks outside i_size. And fsck will complain about
I guess you forgot to add Andrew on CC.
Thanks,
Kirill
> OpenVZ team has discovered error inside generic_file_direct_write()
> If generic_file_direct_IO() has fail (ENOSPC condition) it may have
> instantiated
> a few blocks outside i_size. And fsck will complain about wrong i_size
> (ext2,
OpenVZ team has discovered error inside generic_file_direct_write()
If generic_file_direct_IO() has fail (ENOSPC condition) it may have instantiated
a few blocks outside i_size. And fsck will complain about wrong i_size
(ext2, ext3 and reiserfs interpret i_size and biggest block difference as
OpenVZ team has discovered error inside generic_file_direct_write()
If generic_file_direct_IO() has fail (ENOSPC condition) it may have instantiated
a few blocks outside i_size. And fsck will complain about wrong i_size
(ext2, ext3 and reiserfs interpret i_size and biggest block difference as
I guess you forgot to add Andrew on CC.
Thanks,
Kirill
OpenVZ team has discovered error inside generic_file_direct_write()
If generic_file_direct_IO() has fail (ENOSPC condition) it may have
instantiated
a few blocks outside i_size. And fsck will complain about wrong i_size
(ext2, ext3 and
On Mon, 11 Dec 2006 16:34:27 +0300
Dmitriy Monakhov [EMAIL PROTECTED] wrote:
OpenVZ team has discovered error inside generic_file_direct_write()
If generic_file_direct_IO() has fail (ENOSPC condition) it may have
instantiated
a few blocks outside i_size. And fsck will complain about wrong
Andrew Morton [EMAIL PROTECTED] writes:
On Mon, 11 Dec 2006 16:34:27 +0300
Dmitriy Monakhov [EMAIL PROTECTED] wrote:
OpenVZ team has discovered error inside generic_file_direct_write()
If generic_file_direct_IO() has fail (ENOSPC condition) it may have
instantiated
a few blocks outside
On Tue, 12 Dec 2006 12:22:14 +0300
Dmitriy Monakhov [EMAIL PROTECTED] wrote:
@@ -2041,6 +2041,14 @@ generic_file_direct_write(struct kiocb *
mark_inode_dirty(inode);
}
*ppos = end;
+ } else if (written 0) {
+ loff_t isize =
28 matches
Mail list logo
