Hi Greg,
I noticed that 3.18.125 added commit bc07ee33284a ('Revert "drm/i915: Fix mutex->owner inspection race under DEBUG_MUTEXES"'), which states that the reason it can be applied is:
The core fix was applied in
commit a63b03e2d2477586440741677ecac45bcf28d7b1 Author: Chris Wilson chris@chris-wilson.co.uk Date: Tue Jan 6 10:29:35 2015 +0000
mutex: Always clear owner field upon mutex_unlock()
(note the absence of stable@ tag)
so we can now revert our band-aid commit 226e5ae9e5f910 for -next.
but that the commit referenced wasn't also pulled in.
Please consider pulling that one too if you're going to do another 3.18 stable release.
Thanks,
Tom
On Fri, Nov 16, 2018 at 01:22:39PM -0600, Tom Zanussi wrote:
Hi Greg,
I noticed that 3.18.125 added commit bc07ee33284a ('Revert "drm/i915: Fix mutex->owner inspection race under DEBUG_MUTEXES"'), which states that the reason it can be applied is:
The core fix was applied in
commit a63b03e2d2477586440741677ecac45bcf28d7b1 Author: Chris Wilson chris@chris-wilson.co.uk Date: Tue Jan 6 10:29:35 2015 +0000
mutex: Always clear owner field upon mutex_unlock()
(note the absence of stable@ tag)
so we can now revert our band-aid commit 226e5ae9e5f910 for -next.
but that the commit referenced wasn't also pulled in.
Please consider pulling that one too if you're going to do another 3.18 stable release.
Unless someone can ack that commit for stable (since it specifically states it shouldn't be included), I'd rather revert bc07ee33284a - it shouldn't have been merged in to begin with.
-- Thanks, Sasha
On Sat, 2018-11-17 at 08:29 -0500, Sasha Levin wrote:
On Fri, Nov 16, 2018 at 01:22:39PM -0600, Tom Zanussi wrote:
Hi Greg,
I noticed that 3.18.125 added commit bc07ee33284a ('Revert "drm/i915: Fix mutex->owner inspection race under DEBUG_MUTEXES"'), which states that the reason it can be applied is:
The core fix was applied in
commit a63b03e2d2477586440741677ecac45bcf28d7b1 Author: Chris Wilson chris@chris-wilson.co.uk Date: Tue Jan 6 10:29:35 2015 +0000
mutex: Always clear owner field upon mutex_unlock()
(note the absence of stable@ tag)
so we can now revert our band-aid commit 226e5ae9e5f910 for -next.
but that the commit referenced wasn't also pulled in.
Please consider pulling that one too if you're going to do another 3.18 stable release.
Unless someone can ack that commit for stable (since it specifically states it shouldn't be included), I'd rather revert bc07ee33284a - it shouldn't have been merged in to begin with.
Yeah, I agree that probably makes more sense - I think I misinterpreted the meaning of 'note the absence of stable@ tag'.
Thanks,
Tom
linux-stable-mirror@lists.linaro.org