Path: news.mitre.org!blanket.mitre.org!philabs!newsjunkie.ans.net!newsfeeds.ans.net!news-was.dfn.de!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news-peer.sprintlink.net!news-backup-east.sprintlink.net!news-in-east.sprintlink.net!news.sprintlink.net!Sprint!209.90.0.8!alpha.sky.net!newshub.cts.com!newsfeed.cts.com!cmkrnl!jeh From: jeh@cmkrnl.com (Jamie Hanrahan) Newsgroups: comp.os.ms-windows.programmer.nt.kernel-mode Subject: Re: KeInsertQueueDpc bug on SMP systems? Message-ID: <1998Jan16.112633.8417@cmkrnl> Date: 16 Jan 98 11:26:33 PST References: <69lhm3$q2r$1@decius.ultra.net> <34c187ba.96744578@news.alt.net> <34c9871c.163669671@news.alt.net> Organization: Kernel Mode Systems, San Diego, CA Lines: 35 In article <34c9871c.163669671@news.alt.net>, tony@ercolano.com (Anthony V. Ercolano) writes: > Jamie, I honestly don't remember the layout of a DPC object. Does it > just have a LIST_ENTRY in it or is there also a boolean that denotes > whether the DPC object is already queued? > > What I did not see in Jim's analysis of the working of > KeInsertQueueDpc was the check that MUST be there to determine if the > object was already queued. Is that done via a boolean or does the > kernel just check whether the LIST_ENTRY in the DPC is empty? It isn't a boolean, it's a field called Lock. When the DPC object is on the queue this field points to the per-CPU DPC spinlock in the processor control region (PCR). When it is not on the queue this field is NULL. Stepping through the machine code on an MP system shows them testing this field for NULL and, a little later, setting it to the address of the per-CPU DPC spinlock. Alas they do not seem to do an atomic test-and-modify of the Lock field. It is therefore possible for two CPUs to get past the "Lock field is NULL" test at the same time. Bummer. Our workaround for now is to be aware of designs that *might* queue try to queue the same DPC object more than once, and provide our own MP-safe code that avoids trying it. (Dammit, if you people don't stop posting such interesting questions, I am NEVER going to get this book finished!) --- Jamie Hanrahan, Kernel Mode Systems, San Diego CA Internet: jeh@cmkrnl.com (JH645) CompuServe: 74140,2055 drivers, internals, networks, applications, and training for VMS and Windows NT NT driver FAQ, links, and other information: http://www.cmkrnl.com/ If you post a reply in news, please don't e-mail it too.