[lkml]   [2018]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: usercopy whitelist woe in scsi_sense_cache

> Il giorno 20 apr 2018, alle ore 22:23, Kees Cook <> ha scritto:
> On Thu, Apr 19, 2018 at 2:32 AM, Paolo Valente <> wrote:
>> I'm missing something here. When the request gets completed in the
>> first place, the hook bfq_finish_requeue_request gets called, and that
>> hook clears both ->elv.priv elements (as the request has a non-null
>> elv.icq). So, when bfq gets the same request again, those elements
>> must be NULL. What am I getting wrong?
>> I have some more concern on this point, but I'll stick to this for the
>> moment, to not create more confusion.
> I don't know the "how", I only found the "what". :)

Got it, although I think you did much more than that ;)

Anyway, my reply was exactly to a (Jens') detailed description of the
how. And my concern is that there seems to be an inconsistency in
that description. In addition, Jens is proposing a patch basing on
that description. But, if this inconsistency is not solved, that
patch may eliminate the symptom at hand, but it may not fix the real
cause, or may even contribute to bury it deeper.

> If you want, grab
> the reproducer VM linked to earlier in this thread; it'll hit the
> problem within about 30 seconds of running the reproducer.

Yep. Actually, I've been investigating this kind of failure, in
different incarnations, for months now. In this respect, other
examples are the srp-test failures reported by Bart, e.g., here [1].
According to my analysis, the cause of the problem is somewhere in
blk-mq, outside bfq. Unfortunately, I didn't make it to find where it
exactly is, mainly because of my limited expertise on blk-mq
internals. So I have asked for any kind of help and suggestions to
Jens, Mike and any other knowledgeable guy. Probably those help
requests got somehow lost on those threads, but your results, Kees,
and the analysis that followed from Jens seems now to be carrying us
to the solution of the not-so-recent issue. Time will tell.



> -Kees
> --
> Kees Cook
> Pixel Security

 \ /
  Last update: 2018-04-21 10:44    [W:0.076 / U:0.352 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site