linux-kernel - Re: Why can't we sleep in an ISR?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4649E680.9020102@cfl.rr.com>
Date:	Tue, 15 May 2007 12:57:36 -0400
From:	Phillip Susi <psusi@....rr.com>
To:	Dong Feng <middle.fengdong@...il.com>
CC:	pradeep singh <2500.pradeep@...il.com>,
	Bahadir Balban <bahadir.balban@...il.com>,
	Learning Linux <learninglinux4@...il.com>,
	kernelnewbies@...linux.org, linux-newbie@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: Why can't we sleep in an ISR?

Dong Feng wrote:
>> Doesn't it run in current process's context ?
>>
> 
> No. I think the concept of process context is a higher-level logical
> concept. Though the interrupt share stack with the interrupted
> process, in my opinion it logically does not share the context with
> the process.

No, the term context here has a specific meaning.  It refers to those 
things which flow from the current pointer, including the virtual memory 
space, file descriptor table, current uid, and so forth.  Because the 
current pointer is not changed on entry to an ISR, the ISR is executing 
in the context of the interrupted process, and thus uses that process' 
virtual memory, etc.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/