On Fri, 24 Nov 2017 15:55:02 +0000, Vincent Pelletier
<plr.vincent@xxxxxxxxx> wrote:
> write(6, "bla\n", 4) = -1 EINTR (Interrupted system call)
> --- SIGQUIT {si_signo=SIGQUIT, si_code=SI_USER, si_pid=1931, si_uid=1000} ---
I discovered this is not the whole truth: it is not the interruption
itself which causes the issue, it is rather deallocating stuff as the
process is headed toward exiting which triggers the issue. Looks like
strace does not have time to print before things go south.
Compared to my original code, I then did 2 changes:
- Call io_destroy before closing any endpoint file.
This (alone, at least) does not improve the situation
- Cancelling AIO transfers before closing AIO context, itself happening
before closing any endpoint file.
This avoided the panic. Doing so, I noticed io_cancel returns -115,
aka -EINPROGRESS. But calling it a second time on the same transfer
then fails with -EINVAL, so it seems cancellation did succeed (not
very familiar with AIO). Maybe this confuses usb_f_fs.ko ?
Not sure why in original code I thought I should destroy AIO context
after closing endpoints (does not look right). I would expect it to
succeed, though, and not find any AIO transfer to cancel by that time.
Checking the first traceback in my first mail, am I right to read it as
io_destroy being the cause of AIO getting cancelled ?
[ 382.230770] ffs_aio_cancel+0x37/0x60 [usb_f_fs]
[ 382.230798] kiocb_cancel+0x31/0x40
[ 382.230822] free_ioctx_users+0x4d/0xd0 <- io_destroy, kernel-side ?
[ 382.230858] percpu_ref_switch_to_atomic_rcu+0x10a/0x130
[ 382.230881] ? percpu_ref_exit+0x40/0x40
[ 382.230904] rcu_process_callbacks+0x2b3/0x440
[ 382.230965] __do_softirq+0xf8/0x26b <- syscall entry point ?
Meaning closing the endpoints in userland left AIO requests behind...
Is this valid ?
Regards,
--
Vincent Pelletier
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
