Interesting that implies that we submitted some kind of async IO, and
the IO must have completed and free(io). This implies that the io->req
count is getting out of sync with the world. A quick eyeball says we are
handling them right, but something is exploding. To try and confirm
this is correct I have built a test kernel with a debugging patch
applied. This bumps the io->req from 1 (the pending report for the
submission of the IO) to 100. If the theory is right the io->req should
go to 99 or fewer. If that occurs we should be able to detect it and
report the type of the IO in flight. I also have tried to correct for
it in the case where that is possible.
Would you be able to test the kernel at the below URL and let me know
what you see in dmesg. If the detection triggers we should see
"fuse_direct_IO: io->reg would have gone negative" messages, and I would
be interested in the content of those when it occurs:
http://people.canonical.com/~apw/lp1505948-wily/
Builds will be there shortly. Please report any results back here.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1505948
Title:
Memory arena corruption with FUSE (was Memory allocation failure
crashes kernel hard, presumably related to FUSE)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1505948/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
