Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5702
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 283/283
On Tue, Feb 03, 2015 at 12:14:18PM +0100, Daniel Vetter wrote:
> On Tue, Feb 03, 2015 at 11:00:56AM +, Chris Wilson wrote:
> > On Tue, Feb 03, 2015 at 11:49:00AM +0100, Daniel Vetter wrote:
> > > You can _never_ assert that a lock is not held, except in some very
> > > restricted corner cases w
On Tue, Feb 03, 2015 at 11:00:56AM +, Chris Wilson wrote:
> On Tue, Feb 03, 2015 at 11:49:00AM +0100, Daniel Vetter wrote:
> > You can _never_ assert that a lock is not held, except in some very
> > restricted corner cases where it's guranteed that your code is running
> > single-threade (e.g.
On Tue, Feb 03, 2015 at 10:50:27AM +, Chris Wilson wrote:
> On Tue, Feb 03, 2015 at 11:49:00AM +0100, Daniel Vetter wrote:
> > Aside: It is possible to check whether a given task doesn't hold a
> > lock, but only when lockdep is enabled, using the lockdep_assert_held
> > stuff.
>
> Bah. That's
On Tue, Feb 03, 2015 at 11:49:00AM +0100, Daniel Vetter wrote:
> You can _never_ assert that a lock is not held, except in some very
> restricted corner cases where it's guranteed that your code is running
> single-threade (e.g. driver load before you've published any pointers
> leading to that loc
On Tue, Feb 03, 2015 at 11:49:00AM +0100, Daniel Vetter wrote:
> Aside: It is possible to check whether a given task doesn't hold a
> lock, but only when lockdep is enabled, using the lockdep_assert_held
> stuff.
Bah. That's what I said, but a certain Daniel insists on using WARN_ON().
-Chris
--
You can _never_ assert that a lock is not held, except in some very
restricted corner cases where it's guranteed that your code is running
single-threade (e.g. driver load before you've published any pointers
leading to that lock).
In addition the early return breaks a bunch of testcases since wit
