linux-kernel - Re: [PATCH 10/10] blkcg: implement BPF_PROG_TYPE_IO

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: <20190614145239.GA538958@devbig004.ftw2.facebook.com>
Date:   Fri, 14 Jun 2019 07:52:39 -0700
From:   Tejun Heo <tj@...nel.org>
To:     Quentin Monnet <quentin.monnet@...ronome.com>
Cc:     axboe@...nel.dk, newella@...com, clm@...com, josef@...icpanda.com,
        dennisz@...com, lizefan@...wei.com, hannes@...xchg.org,
        linux-kernel@...r.kernel.org, linux-block@...r.kernel.org,
        kernel-team@...com, cgroups@...r.kernel.org, ast@...nel.org,
        daniel@...earbox.net, kafai@...com, songliubraving@...com,
        yhs@...com, bpf@...r.kernel.org
Subject: Re: [PATCH 10/10] blkcg: implement BPF_PROG_TYPE_IO_COST

Hello, Quentin.

On Fri, Jun 14, 2019 at 12:32:09PM +0100, Quentin Monnet wrote:
> Please make sure to update the documentation and bash
> completion when adding the new type to bpftool. You
> probably want something like the diff below.

Thank you so much.  Will incorporate them.  Just in case, while it's
noted in the head message, I lost the RFC marker while prepping this
patch.  It isn't yet clear whether we'd really need custom cost
functions and this patch is included more as a proof of concept.  If
it turns out that this is beneficial enough, the followings need to be
answered.

* Is block ioctl the right mechanism to attach these programs?

* Are there more parameters that need to be exposed to the programs?

* It'd be great to have efficient access to per-blockdev and
  per-blockdev-cgroup-pair storages available to these programs so
  that they can keep track of history.  What'd be the best of way of
  doing that considering the fact that these programs will be called
  per each IO and the overhead can add up quickly?

Thanks.

-- 
tejun