linux-kernel - Re: [PATCH] radeon: use vmalloc instead of kmalloc

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:	Tue, 23 Jun 2009 21:42:30 +1000
From:	Dave Airlie <airlied@...il.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Jerome Glisse <jglisse@...hat.com>, dri-devel@...ts.sf.net,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] radeon: use vmalloc instead of kmalloc

On Tue, Jun 23, 2009 at 9:35 PM, Peter Zijlstra<peterz@...radead.org> wrote:
> On Mon, 2009-06-22 at 19:26 +0200, Jerome Glisse wrote:
>> We don't need to allocated contiguous pages in cs codepath
>> so use vmalloc instead.
>
> Best would be to not require >PAGE_SIZE allocations at all of course.

It gets messy when you have copy from user and spinlocks, it would be nice
to just parse the userspace PAGE_SIZE at a time, but it would mean dropping
a lock we probably need to hold.

> But barring that, it would be great to have something like:
>
>  ptr = kmalloc(size, GFP_KERNEL | __GFP_NOWARN);
>  if (!ptr)
>    ptr = vmalloc(size);

we have a drm_calloc_large workaround already for the Intel driver which also
need this.
>
> Also, how long do these allocations live? vmalloc space can be quite
> limited (i386) and it can fragment too.

Only an ioctl lifetime so they aren't that bad. We however do have some vmaps
that might be quite large, mainly the fbcon framebuffer (up to 8MB in
some cases)

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