linux-kernel - DRM lock ordering fix series

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <1238017510-26784-1-git-send-email-eric@anholt.net>
Date:	Wed, 25 Mar 2009 14:45:04 -0700
From:	Eric Anholt <eric@...olt.net>
To:	linux-kernel@...r.kernel.org
Cc:	dri-devel@...ts.sourceforge.net
Subject: DRM lock ordering fix series

Here's hopefully the final attempt at the lock ordering fix for GEM.  The
problem was introduced in .29 with the GTT mapping support.  We hashed out
a few potential fixes on the mailing list and at OSTS.  Peter's plan was
to use get_user_pages, but it has significant CPU overhead (10% cost to text
rendering, though part of that is due to some dumb userland code.  But it's
dumb userland code we're all running).  Linus's plan was to just try the
atomic copy_from_user and see if it succeeds, then fall back to allocating
space and copying in to the kernel since it'll "never" happen.  Except that
we can't allocate as much as a user may try to copy in in kernel space, so
we'd have had to break up the write into multiple passes dropping the lock
in between, and I wasn't comfortable with that.

So, this time, I try the optimistic Linus path, and if not, fall back to the
slow Peter Zijlstra path.   It seems to be working, and I forced the
slow paths and tested each case against some regression tests I have, so I
think it's good to go.  But I'd love some Reviewed-bys on the ones that are
missing it, because this morning I had to fix 9 bugs in 60 LOC, and that's
just what I caught with testcases.

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