On Thu, Apr 16, 2009 at 02:55:15PM +0530, pradeep singh wrote:
> On Thu, Apr 16, 2009 at 9:56 AM, Jeffrey Cao wrote:
> > On 2009-04-16, Jeffrey Cao wrote:
> >> On 2009-04-15, Peter Teoh wrote:
> >>
> >>
> >>> "No process context" actually means that the taskstruct's
> >>> mm_struct->mm is NULL.
On Thu, Apr 16, 2009 at 6:03 AM, pradeep singh
wrote:
> On Wed, Apr 15, 2009 at 6:51 PM, Peter Teoh wrote:
>> Hi Pradeep,
>>
>> On Wed, Apr 15, 2009 at 6:59 AM, pradeep singh
>> wrote:
>>> On Wed, Apr 15, 2009 at 12:20 PM, Peter Teoh
>>> wrote:
>>> [...]
> What I know is that there are onl
On Wed, Apr 15, 2009 at 6:51 PM, Peter Teoh wrote:
> Hi Pradeep,
>
> On Wed, Apr 15, 2009 at 6:59 AM, pradeep singh
> wrote:
>> On Wed, Apr 15, 2009 at 12:20 PM, Peter Teoh wrote:
>> [...]
What I know is that there are only two types of contextes: process, and
interrupt. Hardware inter
On Thu, Apr 16, 2009 at 9:56 AM, Jeffrey Cao wrote:
> On 2009-04-16, Jeffrey Cao wrote:
>> On 2009-04-15, Peter Teoh wrote:
>>
>>
>>> "No process context" actually means that the taskstruct's
>>> mm_struct->mm is NULL. This means that the pagetable CR3 are not
>> That's not correct. mm is NULL
On 2009-04-16, Jeffrey Cao wrote:
> On 2009-04-15, Peter Teoh wrote:
>
>
>> "No process context" actually means that the taskstruct's
>> mm_struct->mm is NULL. This means that the pagetable CR3 are not
> That's not correct. mm is NULL does not mean no porcess context.
> Since all kernel process
On 2009-04-15, Peter Teoh wrote:
> "No process context" actually means that the taskstruct's
> mm_struct->mm is NULL. This means that the pagetable CR3 are not
That's not correct. mm is NULL does not mean no porcess context.
Since all kernel processes/threads share the same upper 1G line addre
Hi Pradeep,
On Wed, Apr 15, 2009 at 6:59 AM, pradeep singh
wrote:
> On Wed, Apr 15, 2009 at 12:20 PM, Peter Teoh wrote:
> [...]
>>> What I know is that there are only two types of contextes: process, and
>>> interrupt. Hardware interrupt handler and deferrable functions(including
>>> softirq and
On Wed, Apr 15, 2009 at 02:50:11PM +0800, Peter Teoh wrote:
> apologized if i get my terminologies wrong, or explanation
> unclear..tried my best.
>
> wellhardware interrupt context is when the hardware IRQ flag is
> still set, which will be turned off (via hardware - not software) w
On Wed, Apr 15, 2009 at 12:20 PM, Peter Teoh wrote:
[...]
>> What I know is that there are only two types of contextes: process, and
>> interrupt. Hardware interrupt handler and deferrable functions(including
>> softirq and tasklete) run in interrupt context.
>>
>
> wellhardware interrupt cont
apologized if i get my terminologies wrong, or explanation
unclear..tried my best.
On Mon, Apr 13, 2009 at 10:36 AM, Jeffrey Cao wrote:
> On 2009-04-12, Peter Teoh wrote:
>> On Sun, Apr 12, 2009 at 11:25 AM, Jeffrey Cao wrote:
>
>> basic concept is that there 3 types of context: proce
On 2009-04-12, Peter Teoh wrote:
> On Sun, Apr 12, 2009 at 11:25 AM, Jeffrey Cao wrote:
> basic concept is that there 3 types of context: process, hardware
> interrupt, and software interrupt.
If you think so, what's the difference between hardware interrupt context and
software interrupt cont
On Sun, Apr 12, 2009 at 11:25 AM, Jeffrey Cao wrote:
> On 2009-03-31, Peter Teoh wrote:
>> sorry, i think i just worked out the logic (correct me if wrong).
>> ksoftirqd does not have any process context, so the input/output of
>> procfs comes / goes to where? therefore, it becomes illegal to
>
On 2009-03-31, Peter Teoh wrote:
> sorry, i think i just worked out the logic (correct me if wrong).
> ksoftirqd does not have any process context, so the input/output of
> procfs comes / goes to where? therefore, it becomes illegal to
> access the procfs interface inside ksoftirqd context (kern
On Tue, Mar 31, 2009 at 4:42 PM, Peter Teoh wrote:
> On Tue, Mar 31, 2009 at 4:00 PM, wrote:
>>> sounds like u need a mutex or semaphore lock. not the spinlock type,
>>> nevertheless, pick your choice:
>>>
>>> c06f5040 T _read_trylock
>>> c06f5028 T _spin_trylock
>>> c06f5154 T _spin_trylock_b
On Tue, Mar 31, 2009 at 4:00 PM, wrote:
>> sounds like u need a mutex or semaphore lock. not the spinlock type,
>> nevertheless, pick your choice:
>>
>> c06f5040 T _read_trylock
>> c06f5028 T _spin_trylock
>> c06f5154 T _spin_trylock_bh
>> c06f5061 T _write_trylock
>> c0444958 T down_read_trylo
> sounds like u need a mutex or semaphore lock. not the spinlock type,
> nevertheless, pick your choice:
>
> c06f5040 T _read_trylock
> c06f5028 T _spin_trylock
> c06f5154 T _spin_trylock_bh
> c06f5061 T _write_trylock
> c0444958 T down_read_trylock
> c0444ec4 T down_trylock
> c0444978 T down_wri
sounds like u need a mutex or semaphore lock. not the spinlock type,
nevertheless, pick your choice:
c06f5040 T _read_trylock
c06f5028 T _spin_trylock
c06f5154 T _spin_trylock_bh
c06f5061 T _write_trylock
c0444958 T down_read_trylock
c0444ec4 T down_trylock
c0444978 T down_write_trylock
c06f4096
Hello,
I am working on a kernel module and need read/write locks of the bh-kind
due to the module needing to process input from a proc-variable. To
avoid deadlocks, I need to use trylock to determine if somebody is
holding the lock or not. Unfortunately, I cannot find a trylock_bh for
the rea
18 matches
Mail list logo
