On Thu, Jul 02, 2015 at 10:50:05AM +0300, Andrey Ryabinin wrote: > >> and see if it triggers. I'm not sure if failing with ENOMEM is the > >> right response (another variant is to sleep there until the pile > >> gets cleaned or until we get killed), and WARN_ON_ONCE() is definitely > >> not for the real work, but it will do for confirming that this is what > >> we are hitting. > > > > Apparently, I'm seeing something else. That WARN_ON_ONCE didn't trigger. Summary for those who'd missed the beginning of the thread: what we are seeing is p9_client_write() issing TWRITE and getting RWRITE in reply (tags match, packets look plausible) with count in RWRITE way more than that in TWRITE. IOW, we are telling the server to write e.g. 93 bytes and are getting told that yes, the write had been successful - all 4096 bytes of it. qemu virtio-9p for server; from my reading of qemu side of things, it can't be sending reply with count greater than that in request. The bug I suspected to be the cause of that is in tag allocation in net/9p/client.c - we could end up wrapping around 2^16 with enough pending requests and that would have triggered that kind of mess. However, Andrey doesn't see that test (tag wraparound in p9_client_prepare_req()) trigger. BTW, was that on the run where debugging printk in p9_client_write() *did* trigger? -- 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
