linux-kernel - Re: [PATCH 1/9] mm: add generic adaptive large memory allocation APIs

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: <1273824214.5605.3625.camel@twins>
Date:	Fri, 14 May 2010 10:03:34 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Changli Gao <xiaosuo@...il.com>
Cc:	akpm@...ux-foundation.org, Hoang-Nam Nguyen <hnguyen@...ibm.com>,
	Christoph Raisch <raisch@...ibm.com>,
	Roland Dreier <rolandd@...co.com>,
	Sean Hefty <sean.hefty@...el.com>,
	Hal Rosenstock <hal.rosenstock@...il.com>,
	Divy Le Ray <divy@...lsio.com>,
	"James E.J. Bottomley" <James.Bottomley@...e.de>,
	Theodore Ts'o <tytso@....edu>,
	Andreas Dilger <adilger@....com>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Paul Menage <menage@...gle.com>,
	Li Zefan <lizf@...fujitsu.com>, linux-rdma@...r.kernel.org,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	linux-scsi@...r.kernel.org, linux-ext4@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
	containers@...ts.linux-foundation.org,
	Eric Dumazet <eric.dumazet@...il.com>,
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Subject: Re: [PATCH 1/9] mm: add generic adaptive large memory allocation
 APIs

On Thu, 2010-05-13 at 22:08 +0800, Changli Gao wrote:
> > NAK, I really utterly dislike that inatomic argument. The alloc side
> > doesn't function in atomic context either. Please keep the thing
> > symmetric in that regards.
> >
> 
> There are some users, who release memory in atomic context. for
> example: fs/file.c: fdmem. 

urgh, but yeah, aside from not using vmalloc to allocate fd tables one
needs to deal with this.

But if that is the only one, I'd let them do the workqueue thing that's
already there. If there really are more people wanting to do this, then
maybe add: kvfree_atomic().
--
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/