linux-kernel - Re: [Intel-gfx] [PATCH 01/13] drm/i915: fall through pwrite_gtt

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:	Sun, 20 Nov 2011 19:09:18 -0800
From:	Ben Widawsky <ben@...dawsk.net>
To:	Daniel Vetter <daniel.vetter@...ll.ch>
Cc:	intel-gfx <intel-gfx@...ts.freedesktop.org>,
	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 01/13] drm/i915: fall through
 pwrite_gtt_slow to the shmem slow path

On Sun,  6 Nov 2011 20:13:48 +0100
Daniel Vetter <daniel.vetter@...ll.ch> wrote:

> The gtt_pwrite slowpath grabs the userspace memory with
> get_user_pages. This will not work for non-page backed memory, like a
> gtt mmapped gem object. Hence fall throuh to the shmem paths if we hit
> -EFAULT in the gtt paths.
> 
> Now the shmem paths have exactly the same problem, but this way we
> only need to rearrange the code in one write path.
> 
> v2: v1 accidentaly falls back to shmem pwrite for phys objects. Fixed.
> 
> Signed-Off-by: Daniel Vetter <daniel.vetter@...ll.ch>

It would be nice if there was some way to notify users that pwriting a
gtt mmapped address can be really damn slow. That's also the one
behavior change this patch introduces. It's possible that some SW was
expecting to get a, "fast path" and would deal with the -EFAULT if it
didn't get it.

Presumably subsequent patches in this series fix this up further, so
instead of figuring out all the failure conditions pwrite can cause,
let's just go with
Acked-by: Ben Widawsky <ben@...dawsk.net>
--
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/