Re: 2.3.6-pre1 posted

On Tue, 22 Jul 2008 09:53:16 +0300
"Tikka, Sami" <[email protected]> wrote:

> The reason I asked about the flags used in memory allocation was we had a
> problem on a customer machine where xp_malloc was returning NULL in the reply
> message buffer allocation. We also tried GFP_KERNEL and kernel complained
> about holding locks while calling kmalloc. Eventually we fixed it with: 
> 
> --- orig/dazuko_core.c
> +++ mod/dazuko_core.c
> @@ -3231,7 +3231,7 @@
>         if (request->reply_buffer_size > 0)
>         {
>                 /* allocate reply text buffer */
> -               request->reply_buffer = (char
> *)call_xp_malloc(request->reply_buffer_size + 1);
> +               request->reply_buffer = (char
> *)call_xp_bigmalloc(request->reply_buffer_size + 1);
>                 if (request->reply_buffer == NULL)
>                 {
>                         error = XP_ERROR_FAULT;
> @@ -3313,7 +3313,7 @@
>                         call_xp_free(request->buffer);
>  
>                 if (request->reply_buffer != NULL)
> -                       call_xp_free(request->reply_buffer);
> +                       call_xp_bigfree(request->reply_buffer);
>  
>                 call_xp_free(request);
>         }
> 
> Where xp_bigmalloc was defined with
> 
> inline void *xp_bigmalloc(size_t size)
> {
>         return vmalloc(size);
> }
> 
> We used xp_bigmalloc because we had it in our dazuko for other purposes.
> Namely, we have implemented a scan result cache in dazuko. We haven't yet
> contributed it but will soon.

Hi,

generally it is a bad idea to use GFP_ATOMIC for all allocations like dazuko did.
GFP_ATOMIC should be used only when it is really necessary, like in the irq
where you can not block. With GFP_ATOMIC kernel has limited possibilities how to get
memory(pages) for your allocation. So there is much bigger possibility that the
allocation fails.

-FH