@“Peter_Viscarola_(OSR)” said:
The IO manager will give you a pinned and locked MDL of the buffer AT THAT INSTANT, but a femtosecond later something could change the underlying buffer the MDL points to and invalidate it (such as the process being torn down due to the OS terminating it or the user terminating it) and if you access it after that then BSOD.
That, sir, is also grossly incorrect.
Consider, if you will, that even if the process gets torn down, it can’t exit cleanly until the IRP has completed, and the pages once locked will have their reference counts incremented in the PFN. In short, once locked, those pages aren’t going anywhere. Direct I/O… is entirely reliable. As it better be, considering is the method used throughout the storage stack.
Umm … not quite …
To put this into context, I was explaining to the OP why there was a danger of a BSOD occurring with a DIRECT_OUT call pinning and locking the usermode memory, as if that would somehow freeze the memory in place, nice and safe and secure. I was giving an example of several instances when that assumption would be incorrect (although they happen rarely) to hopefully encourage him to choose a safer way to move data from usermode to kernelmode.
You are correct, once those pages are locked they aren’t going anywhere but note the loophole here; until the IRP has completed. If that IRP gets marked as completed by something other than the driver that received the buffer (a scenario which indeed you yourself wrote about some time ago [https://www.osronline.com/article.cfm^article=72.htm], or if the calling thread is unloaded by the OS as part of a teardown, or if it is just taking too darn long to complete [https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/canceling-irps]) then a DIRECT_X buffer is left flying in the wind. Many things can complete an IRP; a filter driver in the stack, an exception handler in a library someplace, the OS tearing down a thread/ process, an IRP timeout, you just don’t know if that IRP is going to get completed behind the driver’s back and therein lies the danger I was attempting to communicate to the OP.
The OS itself will attempt to cancel outstanding IRP’s in a teardown or a timeout (hence the whole idea behind a cancel callback) to prevent a denial of service of the OS … consider that I had a service that did three things: called into a driver with a METHOD_DIRECT and used overlapped IO, had another thread that dereferenced a null function pointer and was set up to auto-restart. That’s all the service does all day … call the driver, pin and lock a buffer, crash, restart. If the OS did not have a way to cleanse the outstanding IRP it would eventually exhaust the PTE table with all of those pinned and locked buffers, create all kinds of memory sandbars with what remained and essentially become unusable over a period of time … which isn’t quite the user experience that MS wants, so they will cancel outstanding IRP’s when possible in that situation. The called driver, of course, knows nothing of this drama, all that it knows is that it’s working with a block of pinned and locked memory that it would like to write into and has an IRP that needs to be completed. Hilarity will ensue when the driver attempts to access that memory of course, as when it attempts to complete the IRP …
That was the point: memory from userland is always dangerous to use no matter how many locks and pins and such you have on it. @Burns mentioned that it’s very hard to get RDMA right because of that and he’s quite correct: only QLogic and Mellanox were able to pull that trick off, and if you go back a few decades (oy!) to messages I posted here you know exactly why the QLogic driver was one of the few ones to get it right …
Mr. @craig_howard …. While I applaud your desire to help your colleagues here, you might consider taking a step back to reinforce your Windows architectural knowledge before offering too much more assistance on topics where you don’t have definitive knowledge and personal experience.
People generally respond to questions on an online forum for one of three reasons; a) they have some personal experience with a topic that they would like to share, b) they like to make themselves heard as the all-knowing, omniscient expert looking down from on high or c) they are looking for that answer themselves. It’s generally really easy to tell which is which from the signal to noise ratio: folks who reply back with links or examples are in camp a), folks who reply back with statements like “you insufferable idiot, you have no idea of what you’re talking about, go crawl back to where you came from and bother us no more with this twaddle!” fall into camp b) and you will sometimes have folks sometimes reply back with c).
As I am by no means an omniscient expert who goes golfing with God on Sundays but have had a fair amount of time in the saddle over my 40+ years of working with OS internals, 35+ of which with Windows (all the way back to Windows 1.0) I do have some vague and general knowledge and personal experience in some topics mentioned here … that said, I definitely fall into camp a) on topics of which I’ve run into and usually camp c) and am always looking to learn a bit more, even if I have to wade through all of the camp b) replies to find those camp a) nuggets (although this list is much nicer now than it was in the mid 2000’s when the signal to noise ratio was nearly zero) …
When I post something incorrect or misleading by all means I would like that information corrected (but use links and code samples, not invectives and diatribe) so that two people can learn, the OP and me …
Peter
