I think I see what you are saying... it seems like we have always just freed them and to heck with whatever was waiting on them. Maybe in all the places I detect something bad, set the return code and goto out, perhaps I should also jamb the bad return code into op->downcall.status and goto wakeup intead of out? Our infant fuzzer isn't really up to making test errors show up there, I'd probably have to put some test weirdo stuff in the userspace part that does the writev to make some test failures... -Mike On Fri, Jan 22, 2016 at 12:08 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > On Fri, Jan 22, 2016 at 11:59:40AM -0500, Mike Marshall wrote: >> Hi Al... >> >> I moved a tiny bit of your work around so it would compile, but I booted a >> kernel from it, and ran some tests, it seems to work OK... doing this >> work from home makes me remember writing cobol programs on a >> silent 700... my co-workers are helping me look at >> wait_for_cancellation_downcall... we recently made some >> improvements there based on some problems we were >> having in production with our out-of-tree Frankenstein >> module... I'm glad you are also looking there. > > BTW, what should happen to requests that got a buggered response in > orangefs_devreq_write_iter()? As it is, you just free them and to hell > with whatever might've been waiting on them; that's easy to fix, but > what about the submitter? Should we let it time out/simulate an error > properly returned by daemon/something else? -- 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
