> Il giorno 07 feb 2018, alle ore 11:27, Paolo Valente <paolo.valente@xxxxxxxxxx> ha scritto: > > > >> Il giorno 07 feb 2018, alle ore 11:15, Mike Galbraith <efault@xxxxxx> ha scritto: >> >> On Wed, 2018-02-07 at 10:45 +0100, Paolo Valente wrote: >>> >>>> Il giorno 07 feb 2018, alle ore 10:23, Mike Galbraith <efault@xxxxxx> ha scritto: >>>> >>>> On Wed, 2018-02-07 at 10:08 +0100, Paolo Valente wrote: >>>>> >>>>> The first piece of information I need is whether this failure happens >>>>> even without "BFQ hierarchical scheduling support". >>>> >>>> I presume you mean BFQ_GROUP_IOSCHED, which I do not have enabled. >>>> >>> >>> Great (so to speak), this saves us one step. >>> >>> So, here's my next request for help: please apply the attached patch >>> (compressed to preserve it from my email client) and retry. It adds >>> several anomaly checks. I hope I have not added any false-positive >>> check. >> >> kernel BUG at block/bfq-iosched.c:4742! >> >> 4742 BUG_ON(!(rq->rq_flags & RQF_ELVPRIV)); > > Oh my, this is as crazy as, fortunately, easy to fix. The problem is > that this is easy to fix in bfq, but increases the doubts I have > expressed in my cover letter: is it ok that, in blk-mq, the functions > of an elevator may get invoked, without control, on requests that do > not belong to that elevator? > > Anyway, two requests, Mike, if you haven't had enough already: > > 1. Could you paste a stack trace for this OOPS, just to understand how we > get there? > > 2. Could you please turn that BUG_ON into: > if (!(rq->rq_flags & RQF_ELVPRIV)) > return; > and see what happens? > Hi Oleksandr, Holger, before I prepare a V2 candidate patch, could you please test my instrumentation patch too, with the above change made. For your convenience, I have attached a compressed archive with both the instrumentation patch and a patch making the above change. Crossing my fingers, Paolo
Attachment:
patches.zip
Description: Zip archive
> Thanks a lot, > Paolo
