linux-kernel - Re: [PATCH 0/3] block: blk_interposer

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: <06b4a10d-5ea5-27e1-af0d-83d5c714996f@kernel.dk>
Date:   Fri, 11 Dec 2020 10:04:20 -0700
From:   Jens Axboe <axboe@...nel.dk>
To:     Hannes Reinecke <hare@...e.de>, Mike Snitzer <snitzer@...hat.com>,
        Sergei Shtepa <sergei.shtepa@...am.com>, hch@....de
Cc:     "johannes.thumshirn@....com" <johannes.thumshirn@....com>,
        "koct9i@...il.com" <koct9i@...il.com>,
        "ming.lei@...hat.com" <ming.lei@...hat.com>,
        "josef@...icpanda.com" <josef@...icpanda.com>,
        "steve@....org" <steve@....org>,
        "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Pavel Tide <Pavel.TIde@...am.com>, dm-devel@...hat.com
Subject: Re: [PATCH 0/3] block: blk_interposer - Block Layer Interposer

On 12/11/20 9:56 AM, Hannes Reinecke wrote:
> On 12/11/20 5:33 PM, Jens Axboe wrote:
>> On 12/11/20 9:30 AM, Mike Snitzer wrote:
>>> While I still think there needs to be a proper _upstream_ consumer of
>>> blk_interposer as a condition of it going in.. I'll let others make the
>>> call.
>>
>> That's an unequivocal rule.
>>
>>> As such, I'll defer to Jens, Christoph and others on whether your
>>> minimalist blk_interposer hook is acceptable in the near-term.
>>
>> I don't think so, we don't do short term bandaids just to plan on
>> ripping that out when the real functionality is there. IMHO, the dm
>> approach is the way to go - it provides exactly the functionality that
>> is needed in an appropriate way, instead of hacking some "interposer"
>> into the core block layer.
>>
> Which is my plan, too.
> 
> I'll be working with the Veeam folks to present a joint patchset 
> (including the DM bits) for the next round.

Just to be clear, core block additions for something that dm will
consume is obviously fine. Adding this as block layer functionality than
then exposes an application API for setting it up, tearing down, etc -
that is definitely NOT

-- 
Jens Axboe