[pso] [tema1][win] IRQL_NOT_LESS_OR_EQUAL

Sat Apr 4 03:14:43 EEST 2009

> 

>Any ideas de ce apare?
>

Da.

Cand ai spinlockul acquired tot codul din interioul spinlockului trebuie sa
fie NON PAGED.  Nu se poate rezolva nici un page fault, nici macar functiile
pe care le apelezi nu au voie sa fie pageable. Vezi documentatia in MSDN la
functiile pe care le apelezi ti se va da IRQLul la care sunt apelabile. De
asemenea nu poti face un wait decat cu wait interval 0. 

Ratiunile sunt urmatoarele: pentru a rezolva un page fault, trebuie sa se
genereze o intrerupere software pentru ca Memory Managerul sa genereze un
PagingRead, cu care I/O managerul sa citeasca din page file memoria
solicitata sa o puna in RAM. Pentru asta codul tau trebuie preemptat in tot
acest timp. Dispatcherul din NT ruleaza la IRQL 2 (DISPATCH LEVEL). Tocmai
pentru acest motiv intreruperea nu se va fi executat, si deci dispatcherul
nu poate chema MM pentru a rezolva PageFaultul, ceea ce duce intr-o
recurenta infinita si eventual vezi BLUE. Deci codul care ruleaza la DPC
level (2) nu trebuie sa page faulteze, pentru ca dispatcherul nu poate intra
in actiune. Exact aceleasi sunt si ratiunile pentru care nu poti face un
wait pe un dispatcher object. Dispatcherul nu poate intrerupe threadul tau.
Poti face starvation la systemul de operare lejer tinand doar un spinlock J.
Un thread indiferent de prioritatea lui nu poate fi intrerupt de alt thread
daca are IRQL 2 = DISPATCH_LEVEL.

Inca o chestie, sper ca nu faci ceva de genul:

Acquire()

Work_with_list();

Status = Call_Nt_Read_File();

Release()

Daca da, scoate Call_Nt_Read_File()  de acolo. Pentru a face un read,
sistemul de operare fiind asincron, trebuie sa poata pune un APC in coada
threadului curent si din nou nu este posibil. De fapt functia nu poate fi
apelata decat la PASSIVE_LEVEL. Functia ZwReadFile ca si NtReadFile este
pageable, deci functia insasi poate fi in pagefile cand o apelezi.

NTSTATUS 
  ZwReadFile(
    IN HANDLE  FileHandle,
    IN HANDLE  Event  OPTIONAL,
    IN PIO_APC_ROUTINE  ApcRoutine  OPTIONAL,
    IN PVOID  ApcContext  OPTIONAL,
    OUT PIO_STATUS_BLOCK  IoStatusBlock,
    OUT PVOID  Buffer,
    IN ULONG  Length,
    IN PLARGE_INTEGER  ByteOffset  OPTIONAL,
    IN PULONG  Key  OPTIONAL
    );

Vezi APC context si APC routine.

Callers of ZwReadFile must be running at IRQL = PASSIVE_LEVEL and with APCs
enabled.

Poti da disable la normal kernel  apc intrand intr-un guraded region, sau
intr-un critical section, insa nu vei da disable special kernel APC. Pentru
asta tre sa ai IRQL 1 (APC_LEVEL). De ce ai vrea sa faci asta ? Din diverse
motive, si ratiuni in care iti gandesti codul. Btw singurul special kernel
APC din windows este cel generat de functia IoCompleteRequest care pune un
APC in coada threadului ce a generat Irpul pentru I/O manager
Irp->Tail->Overlay.Thread parca, care este un PETHREAD, cel caruia i se va
genera APCul. Daca threadul e la IRQL = APC_LEVEL, adios generare de APC.

Sper ca iti este mai clar acum. Daca tot nu reusesti sa vezi care e pbema,
da-mi te rog dumpul de la !analyze -v si codul din interiorul spinlockului.

Succes in continuare Alexandra.

Ce pacat ca se face cursul asta in cateva saptamani pentru DOUA sisteme de
operare si se vrea atata de la el, absurditate toatala din punctul meu de
vedere. Eventually din cauza asta nu o sa se poate ramane cu mare lucru. O
spun din experienta personala, nu trebuie neeaparat sa fie cazul. 

Eu unul nu pot pricepe arhitectura a doua sisteme de operare sa scriu si
device drivere, cod kernel, si sa scriu si corect. De ex nici un sample de
laborator nu respecta Windows Driver Model (WDM) plus, ca se apeleaza la
chestii undocumented la greu, (vezi prima tema), in loc sa se puna accent pe
partea practica, si care este ceruta in joburile de acest fel. 

Scopul didactic dupa parerea mea nu este scuza aprofundarii si executarii de
cod nedocumentat in kernel in special hookare de apeluri de system si pot da
zeci de motive de ce nu. As fi preferat sa ramana un subiect teoretic. Decat
sa fie asa mai bine s-ar renunta la predarea pentru Windows, pentru ca se
pare, ca la fel ca la orice materie din facultate este tratata net inferior
de cum este tratata dezvoltarea pe linux, unix, stiti despre ce vbesc,
situatie total paradoxala din punctul meu de vedere. 

Intelegerea unei arhitecturi, felul cum codul tau face parte din sistemul de
operare, cum interactioneaza cu el, conventiile fiecarui sistem de operare
pentru executare de cod, implementarea intreruperilor, si un intreg
executive, necesita timp, si acel timp, care nu este, si care mai este si
umplut de chestii absolut inutile (KeServiceDescriptorTable stuff). As
prefera sa invat sa scriu un minifilter driver, legacy file system, legacy
file system filter, sau drivere care interactioneaza cu perifericele, gen
cel tema 2, orice practic de care as putea sa ma folosesc mai departe, dar
doar atat tot semestrul.  Cele mai populare drivere sunt cele de FileSystem
lately (over internet, over lan, in the cloud) in industrie, si tema 4 este
evitata pe windows J de ce nu ma mira.

Teme complexe intr-un timp scurt  + licenta + lucruri care nu se invata de
la o saptamana la alta, transforma materia dintr-una in care ai putea sa
iesi un technology expert intr-o cursa, gen: hai sa fac cumva sa trec si de
PSO si sa uit cat mai rpd de el. Plain old sad...

Nu mi-o luati in nume de rau, doar vreau sa spun care e parerea mea.

Cu respect,

Bercea Gabriel 342 C2

Mobile contact:  (+40)0740049634

eMail: gamitech at gmail.com

From: pso-bounces at cursuri.cs.pub.ro [mailto:pso-bounces at cursuri.cs.pub.ro]
On Behalf Of alexandra gherghina
Sent: Friday, April 03, 2009 11:39 PM
To: Proiectarea Sistemelor de Operare
Subject: [pso] [tema1][win] IRQL_NOT_LESS_OR_EQUAL

Salut!
Am un BSOD cu IRQL_NOT_LESS_OR_EQUAL, cu read. Intre spinlock acq si release
am doar o cautare intr-o lista. Any ideas de ce apare?
Multumesc!
Alexandra

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cursuri.cs.pub.ro/pipermail/pso/attachments/20090404/747fd43e/attachment-0001.htm>