Hi Greg,
This was missing in 4.14-stable. Please apply to your queue.
-- Regards Sudip
On 19/07/18 23:09, Sudip Mukherjee wrote:
Hi Greg,
This was missing in 4.14-stable. Please apply to your queue.
-- Regards Sudip
Hi Sudip,
This is correct, seems low-risk, and I don't mind it going ahead. But I'm curious why you're interested in it for v4.14. Mostly, I wonder if the same reason would apply to older kernels as well?
While the bugfix is applicable to v4.14, the nasty X crash on suspend is only on v4.15 and v4.16. I think I left it to other's judgement, as to whether the bugfix would be wanted outside that case.
IIUC, the bugfix could be applied to *three* of the "longterm" kernel lines: 4.14.56, 4.9.113, 4.4.142. Since the commit says this bug was introduced to the single-queue block layer in v4.4, commit 3ef28e8 ("block: generic request_queue reference counting").
Regards Alan******
Hi Alan,
On Fri, Jul 20, 2018 at 09:37:29AM +0100, Alan Jenkins wrote:
On 19/07/18 23:09, Sudip Mukherjee wrote:
Hi Greg,
This was missing in 4.14-stable. Please apply to your queue.
-- Regards Sudip
Hi Sudip,
This is correct, seems low-risk, and I don't mind it going ahead. But I'm curious why you're interested in it for v4.14. Mostly, I wonder if the same reason would apply to older kernels as well?
Well, since I have to use v4.14.y for my dayjob I will like to see all possible fixes landing in 4.14-stable. That makes my dayjob a little easier. :)
While the bugfix is applicable to v4.14, the nasty X crash on suspend is only on v4.15 and v4.16. I think I left it to other's judgement, as to whether the bugfix would be wanted outside that case.
My thought was that since you said "or" in your commit message: "When blk_queue_enter() waits for a queue to unfreeze, or unset the PREEMPT_ONLY flag, do not allow it to be interrupted by a signal", so the fault condition can be when it is waiting on the queue and is interrupted. So even though 'PREEMPT_ONLY' is not there in v4.14.y, we can see the problem just because of getting interrupted while on queue.
Plesase correct me if I was wrong.
IIUC, the bugfix could be applied to *three* of the "longterm" kernel lines: 4.14.56, 4.9.113, 4.4.142. Since the commit says this bug was introduced to the single-queue block layer in v4.4, commit 3ef28e8 ("block: generic request_queue reference counting").
I will send the backport for v4.9.y and v4.4.y also.
-- Regards Sudip
On 20/07/18 11:26, Sudip Mukherjee wrote:
Hi Alan, My thought was that since you said "or" in your commit message: "When blk_queue_enter() waits for a queue to unfreeze, or unset the PREEMPT_ONLY flag, do not allow it to be interrupted by a signal", so the fault condition can be when it is waiting on the queue and is interrupted. So even though 'PREEMPT_ONLY' is not there in v4.14.y, we can see the problem just because of getting interrupted while on queue.
Plesase correct me if I was wrong.
You're absolutely right.
I suppose the original commit message might not be quite as clear when added in 4.14.x, so I had biased against that a bit.
pre-v4.15 doesn't fail the suspend test in the commit message, but a test was added to blktests afterwards, which should exactly cover the "or" part.
https://github.com/osandov/blktests/blob/master/tests/block/016
IIUC, the bugfix could be applied to *three* of the "longterm" kernel lines: 4.14.56, 4.9.113, 4.4.142. Since the commit says this bug was introduced to the single-queue block layer in v4.4, commit 3ef28e8 ("block: generic request_queue reference counting").
I will send the backport for v4.9.y and v4.4.y also.
linux-stable-mirror@lists.linaro.org
-
Alan Jenkins -
Greg Kroah-Hartman -
Sudip Mukherjee