On Jan 19, 2011, at 7:46 PM, Wengang Wang wrote:
> On 11-01-19 11:09, Chuck Lever wrote:
>>
>> On Jan 19, 2011, at 7:53 AM, Wengang Wang wrote:
>>
>>> I got the crash when test with fio + (ctrl-C). The panic info is like this:
>>>
>>> ------------[ cut here ]------------
>>> kernel BUG at fs/aio.c:558!
>>> invalid opcode: 0000 [#1] SMP
>>> last sysfs file: /sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size
>>> CPU 0
>>> Modules linked in: netconsole(U) configfs(U) hidp(U) l2cap(U) bluetooth(U) rfkill(U) ipv6(U) nfs(U) lockd(U) fscache(U) nfs_acl(U) auth_rpcgss(U) sunrpc(U) cpufreq_ondemand(U) acpi_cpufreq(U) freq_table(U) dm_multipath(U) sbs(U) sbshc(U) lp(U) snd_hda_codec_analog(U) snd_hda_intel(U) snd_hda_codec(U) snd_hwdep(U) snd_seq_dummy(U) snd_seq_oss(U) i915(U) snd_seq_midi_event(U) snd_seq(U) snd_seq_device(U) snd_pcm_oss(U) drm_kms_helper(U) snd_mixer_oss(U) drm(U) tg3(U) snd_pcm(U) snd_timer(U) snd(U) parport_pc(U) i2c_algo_bit(U) i2c_i801(U) serio_raw(U) parport(U) iTCO_wdt(U) shpchp(U) soundcore(U) video(U) i2c_core(U) dcdbas(U) iTCO_vendor_support(U) snd_page_alloc(U) pcspkr(U) output(U) pata_acpi(U) ata_piix(U) ata_generic(U) uhci_hcd(U) ohci_hcd(U) ehci_hcd(U) [last unloaded: netconsole]
>>> Pid: 3112, comm: fio Tainted: G W 2.6.32.21 #3 OptiPlex 745
>>> RIP: 0010:[<ffffffff8114eb30>] [<ffffffff8114eb30>] __aio_put_req+0x6e/0x150
>>> RSP: 0018:ffff88006cd7be38 EFLAGS: 00010092
>>> RAX: 0000000000000038 RBX: ffff880078f2b9c0 RCX: 0000000000007da3
>>> RDX: 0000000000000000 RSI: 0000000000000082 RDI: 0000000000000046
>>> RBP: ffff88006cd7be58 R08: 0000000000000001 R09: 0000000000000020
>>> R10: ffff88006cd7bdb8 R11: 0000000000000001 R12: ffff880078f2b9c0
>>> R13: ffff880037ef3e40 R14: ffff880037ef3e40 R15: 0000000000000000
>>> FS: 0000000042eb4940(0063) GS:ffff880001c00000(0000) knlGS:0000000000000000
>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> CR2: 00007fa172484000 CR3: 000000006ce48000 CR4: 00000000000006f0
>>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>>> Process fio (pid: 3112, threadinfo ffff88006cd7a000, task ffff88007a7de040)
>>> Stack:
>>> ffff880037ef3e40 ffff880037ef3e40 ffff880078f2b9c0 ffff88006cd7bf40
>>> <0> ffff88006cd7be88 ffffffff8114ec3d ffff88006bc11ed0 ffff880078f2b9c0
>>> <0> ffff88006bc11ed0 ffff880078f2b9c0 ffff88006cd7bf78 ffffffff81150a15
>>> Call Trace:
>>> [<ffffffff8114ec3d>] aio_put_req+0x2b/0x43
>>> [<ffffffff81150a15>] sys_io_submit+0x56a/0x6f1
>>> [<ffffffff81011db2>] system_call_fastpath+0x16/0x1b
>>> Code: 7f 45 81 e8 a9 8d f0 ff e8 32 6d ec ff 83 7b 18 00 7d 1c 48 89 da 48 c7 c6 58 7f 45 81 48 c7 c7 d4 b1 5d 81 31 c0 e8 86 8d f0 ff <0f> 0b eb fe 74 07 31 c0 e9 cd 00 00 00 4c 8d a3 d8 00 00 00 48
>>> RIP [<ffffffff8114eb30>] __aio_put_req+0x6e/0x150
>>> RSP <ffff88006cd7be38>
>>> ---[ end trace 52431c8b3d9e71ba ]---
>>> Kernel panic - not syncing: Fatal exception
>>>
>>> The number 558 should be 552 in original codes. It is the
>>> BUG_ON(req->ki_users < 0);
>>> in __aio_put_req().
>>>
>>> My analysis is(correct me):
>>> In the sys_io_submit path, the vfs doesn't hope the FS under ground drop the
>>> ki_users in "error" case. The error is -ERESTARTSYS, in my test, instead of
>>> -EIOCBQUEUED. But seems the nfs drops ki_users in error case as well as
>>> in successful cases too.
>>>
>>> So my first attempt is coming for discussion.
>>> Basically, it makes nfs don't drop(actually it gets then puts) ki_users in error
>>> cases.
>>> Let the nfs_direct_req.error records the error from get_user_pages() and
>>> rpc_run_task() in nfs_direct_read/write path, assuming both the two function
>>> returns all error they hit.
>>
>> Yes, get_user_pages() is invoked in both the read and write path, and returns -ERESTARTSYS when a signal is pending. It can return other errors as well, but -ERESTARTSYS seems to be by far the common case.
>>
>>> And in nfs_direct_complete(), if error occured(per
>>> nfs_direct_req.error), take another ref on kiocb->ki_users. (and then drop it in
>>> aio_complete in existing codes).
>>
>> Reporting error codes via dreq.error is probably a good change for async I/O.
>>
>> The open-coded equivalent of "aio get iocb" is probably not what we want, however. By my reading of this logic, nfs_direct_write_schedule_iovec() returns a non-zero value in this case, so nfs_direct_complete() is skipped altogether. I think your new code would never be executed.
>
> Yes, it's the tricky place. :)
> Actually the nfs_direct_complete() is alled in
> nfs_direct_read/write_schedule_iovec() like:
>
> if (put_dreq(dreq))
> nfs_direct_complete(dreq);
>
> It does not depend on any return value. And yes, it's here, in error case, it's
> last ref on ki_users.
>
> I have tested the fix with a dump_stack() showing that it really take place. The
> stack is like:
>
> Call Trace:
> [<c0505dff>] ? __aio_put_req+0x47/0x12a
> [<c0506c1d>] ? aio_complete+0x148/0x181
> [<f93efb25>] ? nfs_direct_complete+0x23/0x3a [nfs]
> [<f93efe81>] ? nfs_direct_write_complete+0x345/0x34d [nfs]
> [<c04a986f>] ? mempool_free_slab+0x13/0x15
> [<c04a986f>] ? mempool_free_slab+0x13/0x15
> [<c04a98ed>] ? mempool_free+0x67/0x6e
> [<f93f0530>] ? nfs_file_direct_write+0x529/0x58d [nfs]
> [<f93e907d>] ? nfs_file_write+0x4d/0x145 [nfs]
> [<c0505bf1>] ? aio_rw_vect_retry+0x72/0x127
> [<f93e9030>] ? nfs_file_write+0x0/0x145 [nfs]
> [<c0506cd0>] ? aio_run_iocb+0x7a/0x15c
> [<c04400b0>] ? try_acquire_console_sem+0x12/0x4b
> [<c0505b7f>] ? aio_rw_vect_retry+0x0/0x127
> [<c042d55d>] ? kmap_atomic_prot+0x132/0x152
> [<c042d3d7>] ? __kunmap_atomic+0x8e/0xc7
> [<c042d55d>] ? kmap_atomic_prot+0x132/0x152
> [<c077a1d5>] ? printk+0x14/0x17
> [<c050768f>] ? do_io_submit+0x44c/0x5e1
> [<c050783c>] ? sys_io_submit+0x18/0x1a
> [<c077c335>] ? syscall_call+0x7/0xb
>
> And also I have a printk just before increasing the ki_users by 1, and
> that shows.
My mistake, I conflated nfs_direct_wait() and nfs_direct_complete(). ENOCOFFEE
>>
>> Currently I agree with Nick: nfs_file_direct_{read,write}() are returning the wrong error codes for asynchronous I/O. Thus the generic aio logic will try to complete a second time NFS I/O that has already failed.
>
> -ERESTARTSYS could be a wrong error codes? For my test case, I kicked
> ctrl+c, I think -ERESTARTSYS is the correct error number. correct me?
Yes, get_user_pages() returns -ERESTARTSYS after a ^C, when it detects a pending signal.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
