On 6/1/20 8:30 PM, Sasha Levin wrote:
On Mon, Jun 01, 2020 at 12:22:54PM -0700, Guenter Roeck wrote:
Hi Greg,
On Mon, Jun 01, 2020 at 06:58:35PM +0200, Greg Kroah-Hartman wrote:
On Tue, May 26, 2020 at 09:58:28PM -0700, Guenter Roeck wrote:
Upstream commit 106d45f350c7 ("scsi: zfcp: fix request object use-after-free in send path causing wrong traces") upstream: v5.3-rc1 Fixes: d27a7cb91960 ("zfcp: trace on request for open and close of WKA port") in linux-4.4.y: b5752b0db014 upstream: v4.9-rc1 Affected branches: linux-4.4.y linux-4.9.y linux-4.14.y linux-4.19.y (already applied)
This patch does not apply on those older branches, do you have a working backport?
I am a bit at loss. Right now my script still tells me:
Upstream commit 106d45f350c7 ("scsi: zfcp: fix request object use-after-free in send path causing wrong traces") upstream: v5.3-rc1 Fixes: d27a7cb91960 ("zfcp: trace on request for open and close of WKA port") in linux-4.4.y: b5752b0db014 upstream: v4.9-rc1 Affected branches: linux-4.4.y linux-4.9.y linux-4.14.y linux-4.19.y (already applied)
It only does that if the patch cherry-picks cleanly; otherwise it would report conflicts. I checked and made sure that the patch was indeed applied to my test branches for linux-{4.4,4.9,4.14}.y. I re-applied it, just to be sure, with no problems. I also extracted it with git format-patch and applied it with "git am", without issue.
Same here, so I've queued it up.
What do you use to apply patches ?
*snicker*
https://i.pinimg.com/originals/ab/8f/f8/ab8ff8a51f1c2a9014cd9cc71c6def0a.png
Anyway, my script also tells me:
Upstream commit a33a5d2d16cb ("genirq/generic_pending: Do not lose pending affinity update") upstream: v4.18-rc1 Fixes: 98229aa36caa ("x86/irq: Plug vector cleanup race") in linux-4.4.y: 996c591227d9 upstream: v4.5-rc2 Affected branches: linux-4.4.y (queued) linux-4.9.y (queued) linux-4.14.y
and, indeed, it looks like a33a5d2d16cb is missing in v4.14.y-queue.
I think that Greg's script didn't like a33a5d2d16cb pointing to the wrong "fixes:" commit - 996c591227d9 rather than 98229aa36caa.
Interesting. Makes me wonder how my script found the correct reference. But then why did his script pick it up for 4.4.y and 4.9.y ?
Guenter
On Mon, Jun 01, 2020 at 08:45:19PM -0700, Guenter Roeck wrote:
On 6/1/20 8:30 PM, Sasha Levin wrote:
On Mon, Jun 01, 2020 at 12:22:54PM -0700, Guenter Roeck wrote:
Anyway, my script also tells me:
Upstream commit a33a5d2d16cb ("genirq/generic_pending: Do not lose pending affinity update") upstream: v4.18-rc1 Fixes: 98229aa36caa ("x86/irq: Plug vector cleanup race") in linux-4.4.y: 996c591227d9 upstream: v4.5-rc2 Affected branches: linux-4.4.y (queued) linux-4.9.y (queued) linux-4.14.y
and, indeed, it looks like a33a5d2d16cb is missing in v4.14.y-queue.
I think that Greg's script didn't like a33a5d2d16cb pointing to the wrong "fixes:" commit - 996c591227d9 rather than 98229aa36caa.
Interesting. Makes me wonder how my script found the correct reference.
FWIW, my scripts always try translating any commit id pointed to by a tag into an "upstream commit id". This is mostly helpful with tags pointing to linux-next commits or commits in private trees, but I suppose it's also useful for cases such as the above :)
But then why did his script pick it up for 4.4.y and 4.9.y ?
I can try and guess: Greg's to-do list has an item named "Figure out why I had to apply a33a5d2d16cb manually" :)
linux-stable-mirror@lists.linaro.org
-
Guenter Roeck -
Sasha Levin