[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: kmalloc within IRQ lock

To: Kernel Newbies <kernelnewbies@xxxxxxxxxxxx>
Subject: RE: kmalloc within IRQ lock
From: Guillaume Thouvenin <guillaume.thouvenin@xxxxxxxxxx>
Date: Fri, 7 May 2004 10:37:57 +0200
In-reply-to: <950B6B3FADEC484C8D0AE17EEE55E1FA30FAEF@draco.analogic.com>
List-archive: <http://mail.nl.linux.org/kernelnewbies/>
List-help: <mailto:ecartis@nl.linux.org?Subject=help>
List-id: <kernelnewbies.nl.linux.org>
List-owner: <mailto:riel@nl.linux.org>
List-post: <mailto:kernelnewbies@nl.linux.org>
List-software: Ecartis version 1.0.0
List-subscribe: <mailto:kernelnewbies-request@nl.linux.org?Subject=subscribe>
List-unsubscribe: <mailto:kernelnewbies-request@nl.linux.org?Subject=unsubscribe>
References: <950B6B3FADEC484C8D0AE17EEE55E1FA30FAEF@draco.analogic.com>
Sender: kernelnewbies-bounce@xxxxxxxxxxxx
User-agent: Internet Messaging Program (IMP) 3.1

Selon "Prokopenko, Konstantyn" <kproko@xxxxxxxxxxxx>:

> Well, in theory you can generate dead-lock cituation. kmalloc with
> GFP_KERNEL flag in low memory condition
> can put "current" user to sleep waiting for swap daemon to free pages. I
> think I don't need to explain further what could happen if you have IRQ lock
> around it.... It looks like a time bomb :)..

Is it the same for kfree?

Guillaume

--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
FAQ:           http://kernelnewbies.org/faq/

References:
- RE: kmalloc within IRQ lock
  - From: Prokopenko, Konstantyn

Prev by Date: Re: Proc read function and long output
Next by Date: RE: kmalloc within IRQ lock
Previous by thread: RE: kmalloc within IRQ lock
Next by thread: RE: kmalloc within IRQ lock
Index(es):
- Date
- Thread