> I just don’t like having long-term pending IOCTLs
Why?
d
Bent from my phone
From: Jamey Kirbymailto:xxxxx
Sent: ?1/?16/?2015 8:11 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: Re: Re: Re: [ntdev] Re: [ntdev] User kernel communication via existing kernel objects
>> The classic example is: Are you using the handle from the user-mode app to signal the driver to do the unmap operation?
No, the driver has a watchdog thread. The thread calls KeWaitForSingleObject() on the EPROCESS of the app. When the app terminates or exits, the driver satisfies the wait and does the proper tear-down.
I tinkered with “Big Hanging DIrect IO” model. I just don’t like having long-term pending IOCTLs.
On Fri, Jan 16, 2015 at 10:06 AM, > wrote:
Not in my experience. You have to be aware of the problems of signaling the same event multiple times, you have to ensure that the writer and the reader are not attempting to read/write the same area simultaneously. It all LOOKS magical and wonderful once you get it to work, but it’s also very easy to break when you make changes.
And then there’s the problem of having that shared section, and how you tear it down. We have debated this many, many, many, many times here on NTDEV. I have, after a long struggle, become a believer that shared memory sections mapped back into user space are evil, due to security and issues with tear down. The classic example is: Are you usign the handle from the user-mode app to signal the driver to do the unmap operation? If so, What, precisely, is your plan to handle the case when somebody calls DuplicateHandle on that handle?
If you really want to use a shared memory scheme and not an inverted call, there IS one really terrific way to “get all the benefits of shared memory without the pain”… and that is to use what we call a “Big Hanging Direct I/O” – In this model, the app allocates the shared memory buffer and sends an IOCTL (using direct I/O) with the OutBuffer pointing to the entirety of this buffer. The driver keeps this IOCTL in progress until the app exists. Voila! Shared mapping.
Peter
OSR
@OSRDrivers
—
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
–
Jamey Kirby
Disrupting the establishment since 1964
This is a personal email account and as such, emails are not subject to archiving. Nothing else really matters.
— NTDEV is sponsored by OSR Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See http://www.osr.com/careers For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>