FYI: RIP: 0010:[<ffffffff8122f04f>] [<ffffffff8122f04f>] cfq_free_io_context+0x18/0x34

[Michał Piotrowski]

W dniu 24 września 2010 15:28 użytkownik Michał Piotrowski
<mkkp4x4 at gmail.com> napisał:
> 2010/9/24 Chuck Ebbert <cebbert at redhat.com>:
>> On Thu, 23 Sep 2010 13:06:25 +0200
>> Michał Piotrowski <mkkp4x4 at gmail.com> wrote:
>>
>>> RIP: 0010:[<ffffffff8122f04f>]  [<ffffffff8122f04f>]
>>> cfq_free_io_context+0x18/0x34

No luck with this bug so far, but I noticed something else

------------[ cut here ]------------
WARNING: at fs/fs-writeback.c:78 inode_to_bdi+0x62/0x6d()
Hardware name:
Dirtiable inode bdi default != sb bdi ecryptfs
Modules linked in: cbc cryptd aes_x86_64 aes_generic ecb ecryptfs
smsc47m192 hwmon_vid coretemp nf_conntrack_netbios_ns ip6t_REJECT
nf_conntrack_ipv6 ip6table
_filter ip6_tables ipv6 iTCO_wdt iTCO_vendor_support i2c_i801 r8169
mii serio_raw sata_sil i915 drm_kms_helper drm i2c_algo_bit i2c_core
video output [last un
loaded: scsi_wait_scan]
Pid: 1393, comm: mc Not tainted 2.6.35.6-33.rc1.fc13.x86_64 #1
Call Trace:
 [<ffffffff8104d490>] warn_slowpath_common+0x85/0x9d
 [<ffffffff8104d54b>] warn_slowpath_fmt+0x46/0x48
 [<ffffffff81132527>] inode_to_bdi+0x62/0x6d
 [<ffffffff81132f7a>] __mark_inode_dirty+0xc1/0x12b
 [<ffffffffa01d1871>] ecryptfs_write_lower+0x9b/0xae [ecryptfs]
 [<ffffffffa01d2711>] ecryptfs_write_metadata+0x200/0x258 [ecryptfs]
 [<ffffffffa01cf3e4>] ecryptfs_create+0x23b/0x2a7 [ecryptfs]
 [<ffffffff8112048b>] vfs_create+0x70/0x92
 [<ffffffff81121125>] do_last+0x293/0x5b8
 [<ffffffff81122d20>] do_filp_open+0x217/0x5fe
 [<ffffffff812205c3>] ? might_fault+0x21/0x23
 [<ffffffff8112bb72>] ? alloc_fd+0x7b/0x124
 [<ffffffff811157a6>] do_sys_open+0x63/0x10f
 [<ffffffff81115885>] sys_open+0x20/0x22
 [<ffffffff81009c72>] system_call_fastpath+0x16/0x1b
---[ end trace 33fc98bd38e19cc2 ]---
------------[ cut here ]------------

This is 2.6.35.6-33.rc1.fc13.x86_64

Once I have copied 10 files to /home/samba4 there are five such errors.

Also, I noticed that simle "grep -R something ." on my tmpfs is a lot
faster on this kernel than on 2.6.35.5-29. Namely:
- on 2.6.35.6-33 it takes 2 to 3 seconds
- on 2.6.35.5-29 it was 8 to 10 seconds

Of course, this acceleration makes me very happy - this will shorten
the time the task up to 3 days. But I wonder why it is so - I do not
see any changes related to tmpfs.

Regards,
Michal