linux-kernel - Re: [PATCH 34/49] gma500: the GEM and GTT code is device independant

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:	Fri, 8 Jul 2011 09:38:59 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Hugh Dickins <hughd@...gle.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>, greg@...ah.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 34/49] gma500: the GEM and GTT code is device
 independant

> As example, below is the patch where I updated drm/i915 to be ready
> for the changeover.  They set __GFP_RECLAIMABLE on the mapping because
> they've got a way to discard unpinned object pages when memory is tight;
> and sometimes add in __GFP_NORETRY|__GFP_NOWARN when allocating.
> 
> I'm guessing you'd just want to use shmem_read_mapping_page() throughout,
> after initializing mapping with the appropriate flags (GFP_HIGHUSER_MOVABLE
> is fs/inode.c's default: maybe your pages aren't easily movable and you'd
> better say GFP_HIGHUSER, or maybe you have reason to need GFP_KERNEL).

I need the pages in the low 4GB ideally and have no way to release them
if they are pinned. For the usage pattern I have that's not a problem.

At the moment the 4G isn't a problem either as you can't attach enough
memory to cause problems to any of these devices.

What I don't entirely understand from your change is what stops another
user task with the shmemfs file handle open from doing something else
which changes the mapping flags, or is it guaranteed that only the
mapping owner gets to play ?

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