search for: generic_file_aio_read

...ffff80063922>] __wait_on_bit_lock+0x36/0x66 [<ffffffff8003f980>] __lock_page+0x5e/0x64 [<ffffffff800a34d5>] wake_bit_function+0x0/0x23 [<ffffffff8000c425>] do_generic_mapping_read+0x1df/0x359 [<ffffffff8000d251>] file_read_actor+0x0/0x159 [<ffffffff8000c6eb>] __generic_file_aio_read+0x14c/0x198 [<ffffffff80016eb7>] generic_file_aio_read+0x36/0x3b [<ffffffff8000cf39>] do_sync_read+0xc7/0x104 [<ffffffff800a34a7>] autoremove_wake_function+0x0/0x2e [<ffffffff80063002>] thread_return+0x62/0xfe [<ffffffff8000b721>] vfs_read+0xcb/0x171 [<fffffff...

..., Signed-off-by: Josef Bacik <josef@redhat.com> --- mm/filemap.c | 36 +++++++++++++++++++++++++++++++----- 1 files changed, 31 insertions(+), 5 deletions(-) diff --git a/mm/filemap.c b/mm/filemap.c index 140ebda..829ac9c 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -1263,7 +1263,7 @@ generic_file_aio_read(struct kiocb *iocb, const struct iovec *iov, { struct file *filp = iocb->ki_filp; ssize_t retval; - unsigned long seg; + unsigned long seg = 0; size_t count; loff_t *ppos = &iocb->ki_pos; @@ -1290,21 +1290,47 @@ generic_file_aio_read(struct kiocb *iocb, const struct iovec *iov,...

..., Signed-off-by: Josef Bacik <josef@redhat.com> --- mm/filemap.c | 36 +++++++++++++++++++++++++++++++----- 1 files changed, 31 insertions(+), 5 deletions(-) diff --git a/mm/filemap.c b/mm/filemap.c index 140ebda..829ac9c 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -1263,7 +1263,7 @@ generic_file_aio_read(struct kiocb *iocb, const struct iovec *iov, { struct file *filp = iocb->ki_filp; ssize_t retval; - unsigned long seg; + unsigned long seg = 0; size_t count; loff_t *ppos = &iocb->ki_pos; @@ -1290,21 +1290,47 @@ generic_file_aio_read(struct kiocb *iocb, const struct iovec *iov,...

...ry->d_name.name, nr_segs); + filp->f_path.dentry->d_name.name, pos); if (!inode) { @@ -2583,7 +2576,7 @@ static ssize_t ocfs2_file_aio_read(struct kiocb *iocb, * * Take and drop the meta data lock to update inode fields * like i_size. This allows the checks down below - * generic_file_aio_read() a chance of actually working. + * generic_file_read_iter() a chance of actually working. */ ret = ocfs2_inode_lock_atime(inode, filp->f_path.mnt, &lock_level); if (ret < 0) { @@ -2592,13 +2585,13 @@ static ssize_t ocfs2_file_aio_read(struct kiocb *iocb, } ocfs2_inode_unlock(...

...ry->d_name.name, nr_segs); + filp->f_path.dentry->d_name.name, pos); if (!inode) { @@ -2587,7 +2580,7 @@ static ssize_t ocfs2_file_aio_read(struct kiocb *iocb, * * Take and drop the meta data lock to update inode fields * like i_size. This allows the checks down below - * generic_file_aio_read() a chance of actually working. + * generic_file_read_iter() a chance of actually working. */ ret = ocfs2_inode_lock_atime(inode, filp->f_vfsmnt, &lock_level); if (ret < 0) { @@ -2596,13 +2589,13 @@ static ssize_t ocfs2_file_aio_read(struct kiocb *iocb, } ocfs2_inode_unlock(in...

...001faefd70 ffff88001e025280 0000000000000021 0000000000001000 [ 14.640174] ffff88001f9d5e00 ffffea000070ebc0 ffff88001faefe58 ffffffff8110a1ca [ 14.640174] ffff88001f9d5e10 ffff88001faefe90 ffff88001faefea0 0000000000000000 [ 14.640174] Call Trace: [ 14.640174] [<ffffffff8110a1ca>] generic_file_aio_read+0x2ca/0x700 [ 14.640174] [<ffffffff811a11f6>] blkdev_aio_read+0x46/0x70 [ 14.640174] [<ffffffff8116c355>] do_sync_read+0x55/0x90 [ 14.640174] [<ffffffff8116c9e0>] vfs_read+0x90/0x160 [ 14.640174] [<ffffffff8116d4e4>] SyS_read+0x44/0xa0 [ 14.640174] [<ffffff...

Hello list, I just got this ominous bug on my machine, that has already been seen several times: http://lists.xensource.com/archives/html/xen-devel/2006-01/msg00180.html The machine is very similar, it''s a machine with two dual-core opterons, running one of the latest xen-3.0.3-unstable (20060926 hypervisor, and a vanilla 2.6.18 + xen patch from Fedora from 20060915). This machine was

...t;ffffffffa026e9c3>] ocfs2_direct_IO+0x73/0x80 [ocfs2] [Fri Oct 18 10:52:28 2013] [<ffffffffa026eae0>] ? ocfs2_dio_end_io+0x110/0x110 [ocfs2] [Fri Oct 18 10:52:28 2013] [<ffffffffa026e9d0>] ? ocfs2_direct_IO+0x80/0x80 [ocfs2] [Fri Oct 18 10:52:28 2013] [<ffffffff81146e2b>] generic_file_aio_read+0x6bb/0x720 [Fri Oct 18 10:52:28 2013] [<ffffffff8172168e>] ? _raw_spin_lock+0xe/0x20 [Fri Oct 18 10:52:28 2013] [<ffffffffa02843db>] ? __ocfs2_cluster_unlock.isra.32+0x9b/0xe0 [ocfs2] [Fri Oct 18 10:52:28 2013] [<ffffffffa02847a9>] ? ocfs2_inode_unlock+0xb9/0x130 [ocfs2] [Fr...

A user has encountered a NULL pointer kernel oops in btrfs when encountering media errors. The problem has been identified as an unhandled NULL pointer returned from find_get_page(). This modification simply checks for a NULL page, and returns with an error if found (the extent_range_uptodate() function returns 1 on errors). After testing this patch, the user reported that the error with the

...bf10d>] sync_page_killable+0x9/0x30 [<ffffffff814e7a2f>] __wait_on_bit_lock+0x41/0x8a [<ffffffff810bf040>] __lock_page_killable+0x61/0x68 [<ffffffff8106486b>] ? wake_bit_function+0x0/0x2e [<ffffffff8103e0af>] ? __might_sleep+0x3d/0x127 [<ffffffff810c0b1f>] generic_file_aio_read+0x3db/0x594 [<ffffffff810763f0>] ? __lock_acquire+0x9a5/0x1767 [<ffffffff8100fd52>] ? check_events+0x12/0x20 [<ffffffff810f8e16>] do_sync_read+0xe3/0x120 [<ffffffff81064837>] ? autoremove_wake_function+0x0/0x34 [<ffffffff811d8da4>] ? selinux_file_permission+0...

...- a/fs/btrfs/file.c +++ b/fs/btrfs/file.c @@ -1197,6 +1197,7 @@ static int btrfs_file_mmap(struct file *filp, struct vm_area_struct *vma) const struct file_operations btrfs_file_operations = { .llseek = generic_file_llseek, .read = do_sync_read, + .write = do_sync_write, .aio_read = generic_file_aio_read, .splice_read = generic_file_splice_read, .aio_write = btrfs_file_aio_write, -- 1.6.5.2 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

I'm pleased to see that the new release has full support for asynchronous I/O. I was surprised, though, since I thought that the aio bug in the 2.4 kernels couldn't be fixed without breaking binary compatibility. Was there a special fix for this in the RHEL3 update 4 kernel? Anyway, thanks for all your efforts. We're looking forward to testing aio with the new version next week.

...90.284314] [<c11cebae>] ? release_sock+0xf/0x89 [154590.284319] [<c108d3c5>] ? __do_page_cache_readahead+0x98/0x16b [154590.284323] [<c108d4ac>] ? ra_submit+0x14/0x18 [154590.284327] [<c108d78d>] ? page_cache_sync_readahead+0x3e/0x44 [154590.284332] [<c10887c3>] ? generic_file_aio_read+0x21f/0x57f [154590.284351] [<c10b2e19>] ? do_sync_read+0xc0/0x107 [154590.284359] [<c1043cc6>] ? autoremove_wake_function+0x0/0x2d [154590.284366] [<c10b5fdb>] ? sys_fstat64+0x1e/0x23 [154590.284374] [<c11021b4>] ? security_file_permission+0xc/0xd [154590.284378] [<...

...jgs kernel: [<ffffffff81075633>] ondemand_readahead+0xf1/0xf8 Mar 30 12:26:39 jgs kernel: [<ffffffff8106f03a>] do_generic_mapping_read+0x126/0x3f7 Mar 30 12:26:39 jgs kernel: [<ffffffff8106e796>] file_read_actor+0x0/0x18a Mar 30 12:26:39 jgs kernel: [<ffffffff810707d1>] generic_file_aio_read+0x11d/0x160 Mar 30 12:26:39 jgs kernel: [<ffffffff81097810>] do_sync_read+0xc9/0x10c Mar 30 12:26:39 jgs kernel: [<ffffffff810a547d>] vfs_test_lock+0x2e/0x32 Mar 30 12:26:39 jgs kernel: [<ffffffff81047ce9>] autoremove_wake_function+0x0/0x2e Mar 30 12:26:39 jgs kernel: [<fff...

...I have tried different things to find out exactly what is the issue, but haven''t quite found it yet. Here''s some stuff I got from latencytop, not sure if would be helpful: 4969.1ms sys_mmap_pgoff syscall_call (chrome) 1139.9ms sync_page sync_page_killable __lock_page_killable generic_file_aio_read do_sync_read vfs_read sys_read sysenter_do_call (chrome) 431.9ms sync_page wait_on_page_bit read_extent_buffer_pages btree_read_extent_buffer_pages read_tree_block read_block_for_search btrfs_search_slot lookup_inline_extent_backref __btrfs_free_extent run_clustered_refs btrfs_run_delayed_refs btr...

My log says suddenly: Dec 14 02:35:16 hp1 kernel: [1492482.232822] o2net: no longer connected to node hp2 (num 1) at 192.168.1.2:7777 Dec 14 02:35:18 hp1 kernel: [1492483.960150] BUG: soft lockup - CPU#1 stuck for 61s! [kvm:32398] I have no idea what happens here and why - but the result are a lot of problems with virtual machines. Viele Gr??e Andreas Rittershofer -- Hier k?nnte keine

..., Signed-off-by: Josef Bacik <josef@redhat.com> --- mm/filemap.c | 36 +++++++++++++++++++++++++++++++----- 1 files changed, 31 insertions(+), 5 deletions(-) diff --git a/mm/filemap.c b/mm/filemap.c index 140ebda..829ac9c 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -1263,7 +1263,7 @@ generic_file_aio_read(struct kiocb *iocb, const struct iovec *iov, { struct file *filp = iocb->ki_filp; ssize_t retval; - unsigned long seg; + unsigned long seg = 0; size_t count; loff_t *ppos = &iocb->ki_pos; @@ -1290,21 +1290,47 @@ generic_file_aio_read(struct kiocb *iocb, const struct iovec *iov,...

This may or may not be ext3 related but I am trying to find any pointers which might help me. I got a number of HP Proliant DL380 g5 with a P400 controller and also two qla2400 cards. The OS is RedHat EL4 U5 x86_64. Every time during reboot these systems panic after the last umount and I believe before the cciss driver is getting unloaded. The last messages I am able to see are: md: stopping

...g: `kmem_cache_t' is deprecated (declared at include/linux/slab.h:17) /data/images/keymaker/home/accountadmin/ocfs2-1.2.6/fs/ocfs2/aio.c: In function `ocfs2_file_aio_read': /data/images/keymaker/home/accountadmin/ocfs2-1.2.6/fs/ocfs2/aio.c:281: warning: passing arg 2 of `generic_file_aio_read' from incompatible pointer type /data/images/keymaker/home/accountadmin/ocfs2-1.2.6/fs/ocfs2/aio.c: In function `ocfs2_file_aio_write': /data/images/keymaker/home/accountadmin/ocfs2-1.2.6/fs/ocfs2/aio.c:381: warning: passing arg 4 of `generic_file_aio_write_nolock' m...

...cfs2_inode_lock_with_page+0x1f/0x5f Apr 20 17:31:52 um-fe-1 [ 9123.585958] [<ffffffffa032311f>] ? :ocfs2:ocfs2_readpage+0x7e/0x33f Apr 20 17:31:52 um-fe-1 [ 9123.585958] [<ffffffff80270eef>] ? find_get_page+0x4a/0x54 Apr 20 17:31:52 um-fe-1 [ 9123.585958] [<ffffffff80272bdc>] ? generic_file_aio_read+0x31f/0x4a9 Apr 20 17:31:52 um-fe-1 [ 9123.585958] [<ffffffffa0337182>] ? :ocfs2:ocfs2_file_aio_read+0x282/0x395 Apr 20 17:31:52 um-fe-1 [ 9123.585958] [<ffffffff8020bf79>] ? sysret_signal+0x2b/0x45 Apr 20 17:31:52 um-fe-1 [ 9123.585958] [<ffffffff8029ad13>] ? do_sync_read+0xc9...