linux-kernel - Re: blk-mq: allow passing in an external queue mapping V3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1c3794ac-4890-adf4-e953-3d57ab545cd2@fb.com>
Date:   Thu, 15 Sep 2016 08:44:44 -0600
From:   Jens Axboe <axboe@...com>
To:     Christoph Hellwig <hch@....de>
CC:     Keith Busch <keith.busch@...el.com>, <tglx@...utronix.de>,
        <agordeev@...hat.com>, <linux-block@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: blk-mq: allow passing in an external queue mapping V3

On 09/15/2016 08:42 AM, Christoph Hellwig wrote:
> On Thu, Sep 15, 2016 at 08:34:42AM -0600, Jens Axboe wrote:
>> I was going to ask about splitting it, but that looks fine, I can pull
>> that in.
>>
>> The series looks fine to me. My only real concern is giving drivers the
>> flexibility to define mappings, I don't want that to evolve into drivers
>> (again) doing stupid things wrt mappings. As long as we keep it strictly
>> as a tunnel for passing mappings defined by the (previous blk-mq) core
>> code, then that's fine.
>
> So my earlier versions just passed in the affinity mask and left
> all the mapping in the core.  This doesn't really work anymore with
> the sibling aware code so I had to add a method.  That being said there
> are some drivers that might want slightly different mappings.
>
> For example skd (if converted to blk-mq) has MSI-X vectors for it's up
> to four queues, but it also has MSI-X vectors for misc book keeping
> before those, so we'd need a version of our PCI mapping that adds an
> offset to add to queue number when assining the MSI-X vectors.
>
> That being said I structured the map_queues interface so it can't do
> anything crazy - it can just build up the cpu to queue mapping array
> so there isn't exactly a whole lot of crazy things a driver could do.

By crazy, I mean even things like thinking it knows better and defining
mappings differently just because it can. But I'm not too worried about
it, it's just something to watch for that we didn't have to care about
before, as the mappings were completely mandated by the core code.

-- 
Jens Axboe