linux-kernel - Re: [PATCH percpu/for-3.17 1/2] percpu: implement percpu

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]

Message-Id: <20140731150328.d2b57d5f6d7aafa33f5ad979@linux-foundation.org>
Date:	Thu, 31 Jul 2014 15:03:28 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Tejun Heo <tj@...nel.org>
Cc:	linux-kernel@...r.kernel.org, Jens Axboe <axboe@...nel.dk>,
	Vivek Goyal <vgoyal@...hat.com>
Subject: Re: [PATCH percpu/for-3.17 1/2] percpu: implement percpu_pool

On Fri, 18 Jul 2014 16:08:04 -0400 Tejun Heo <tj@...nel.org> wrote:

> percpu allocator requires sleepable context for allocations.  Most use
> cases are fine with the requirement but blk-throttle currently
> implements its own asynchronous allocation mechanism to allow
> initiating allocation from atomic contexts and there are expected to
> be more similar use cases.
> 
> It'd be best to make percpu allocator take GFP mask like other
> allocators but its entanglement with kernel virtual address management
> makes it very cumbersome.  Also, percpu allocations from atomic
> contexts are likely to remain highly restricted.
> 
> This patch implements a simple asynchronous allocation pool, named
> percpu_pool, which can be used from any context and is refilled
> automatically.  A pool is initialized with the size and alignment of
> the percpu areas to serve and the low an high watermarks.  When the
> number of cached areas fall below the low watermark, a work item is
> kicked off to fill it up to the high mark.  A pool can be statically
> defined and can be manually filled and emptied.

I don't think we should add facilities such as this.  Because if we do,
people will use them and thereby make the kernel less reliable, for
obvious reasons.

It would be better to leave the nasty hack localized within
blk-throttle.c and hope that someone finds a way of fixing it.

--
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/