Paolo, On Tue, Jul 30, 2019 at 10:55:24AM +0200, Paolo Valente wrote: > Hi Guenter, > sorry for the delay (Dolomiti's fault). > > I didn't consider that rq->elv-icq might have been NULL also > because of OOM. Thanks for spotting this issue. > > As for the other places where the return value of bfq_init_rq is used, > unfortunately I think they matter too. Those other places are related > to request merging, which is the alternative destiny of requests > (instead of being just inserted). But, regardless of whether a > request is to be merged or inserted, that request may be destined to a > bfq_queue (possibly merged with a request already in a bfq_queue), and > a NULL return value by bfq_init_rq leads to a crash. I guess you can > reproduce your failure also for the merge case, by generating > sequential, direct I/O with queue depth > 1, and of course by enabling > failslab. > > If my considerations above are correct, do you want to propose a > complete fix yourself? > I had another look into the code. Unfortunately, both bfq_request_merged() and bfq_requests_merged() simply assume that bfq_init_rq() never returns NULL, and don't give me an idea for a path of action if it returns NULL after all. I'll have to pass the problem off to you for a fix. Thanks, Guenter
