linux-kernel - Re: [PATCH 4/6] drm/i915: Fix lock order reversal in shmem pread path.

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: <1238040193.26771.186.camel@aiko.keithp.com>
Date:	Wed, 25 Mar 2009 21:03:13 -0700
From:	Keith Packard <keithp@...thp.com>
To:	Dave Airlie <airlied@...ux.ie>
Cc:	keithp@...thp.com, Eric Anholt <eric@...olt.net>,
	dri-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/6] drm/i915: Fix lock order reversal in shmem pread
	path.

On Wed, 2009-03-25 at 23:30 +0000, Dave Airlie wrote:
> 
> I've no idea when a fault is likely in the fast case, i.e. will it happen
> usually on the first page etc, because if it happens on the last page and 
> you fallback and restart the whole copy, I would think that would be 
> sub-optimal, granted it could get ugly quick, but this code has already 
> hit a few branches on the tree.

The data in question is presumably 'hot', and so unlikely to be swapped
out. Testing the slow paths doing a complete copy is fairly easy, while
testing partial copies would be considerably more difficult. The
combination of these two seems to encourage a careful and simplistic
slow path.

We can always make it 'faster' in the future, but having it wrong from
the first seems sub-optimal.

-- 
keith.packard@...el.com

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)