linux-kernel - Re: [PATCH -v3 2/8] lib, Make gen

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Wed, 27 Oct 2010 11:17:41 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Huang Ying <ying.huang@...el.com>
Cc:	Len Brown <lenb@...nel.org>, linux-kernel@...r.kernel.org,
	Andi Kleen <andi@...stfloor.org>, linux-acpi@...r.kernel.org
Subject: Re: [PATCH -v3 2/8] lib, Make gen_pool memory allocator lock-less

> --- a/lib/genalloc.c
> +++ b/lib/genalloc.c
> @@ -1,8 +1,8 @@
>  /*
> - * Basic general purpose allocator for managing special purpose memory
> - * not managed by the regular kmalloc/kfree interface.
> - * Uses for this includes on-device special memory, uncached memory
> - * etc.
> + * Basic general purpose allocator for managing special purpose
> + * memory, for example, memory that is not managed by the regular
> + * kmalloc/kfree interface.  Uses for this includes on-device special
> + * memory, uncached memory etc.

I think we need some more description here about the locklessness:

How about adding to the comment:

This version of the allocator supports lockless operation.

This makes it safe to use in NMI handlers and other special unblockable
contexts that could otherwise deadlock on locks.  This is implemented by 
using atomic operations and retries on any conflicts. 
The disadvantage is that there may be livelocks in extreme cases.  

The lockless operation only works if there is enough memory
available. If new memory is added to the pool a lock has to 
be still taken. So any user relying on locklessness has to ensure
that sufficient memory is preallocated.

The basic atomic operation of this allocator is cmpxchg on long. 
On architectures that don't support cmpxchg natively a fallback
is used. If the fallback uses locks it may not be safe to use
it in NMI contexts on these architectures.

> +/**
> + * gen_pool_for_each_chunk - iterate over chunks of generic memory pool
> + * @chunk:	the struct gen_pool_chunk * to use as a loop cursor
> + * @pool:	the generic memory pool
> + */

I believe that's not safe in a lockless context right?
Should note that.

> +#define gen_pool_for_each_chunk(chunk, pool)			\
> +	list_for_each_entry(chunk, &pool->chunks, next_chunk)
> +

-Andi

-- 
ak@...ux.intel.com -- Speaking for myself only.
--
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/