On Sat, Mar 08 2014 at 7:24pm -0500,
Jens Axboe <axboe@xxxxxxxxx> wrote:
On 2014-03-08 15:09, Mike Snitzer wrote:
On Sat, Mar 08 2014 at 4:33pm -0500,
Hannes Reinecke <hare@xxxxxxx> wrote:
On 03/08/2014 07:13 PM, Mike Snitzer wrote:
The patch I made wasn't in the context of 'recently upstreamed
I'm calm.. was just a bit frustrated. But this isn't a big deal.
I'll make an effort to reach out to relevant people sooner when
similar stuff is reported against recently upstreamed code. Would be
cool if you did the same. I can relate to needing to have the distro
vendor hat on (first needing to determine/answer "is this issue
specific to our hacked distro kernel?", etc).
code', it was due to a backport Jan Kara did for our next distro
kernels (3.12-based).
"3.12-based" means nothing given all the backporting for SLES, much like
"3.10-based" means nothing in the context of RHEL7.
The only way this fix is applicable is in the context of "recently
upstreamed code", commit 1874198 ("blk-mq: rework flush sequencing
logic") went upstream for v3.14-rc3.
Jens, please feel free to queue this tested fix for 3.14-rc:
Thanks Mike, queued up.
Thanks.
Also queued up the list addition reversal change.
I had a look at what you queued, thing is commit 1874198 replaced code
in blk_kick_flush() that did use list_add_tail(). So getting back to
the way the original code was (before 1874198) would need something
like the following patch.
But it isn't clear to me why we'd have the duality of front vs tail
additions for flushes. Maybe Christoph knows?