linux-kernel - Re: [PATCH 2/2] block, bfq: delete "bfq" prefix from cgroup filenames

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: <20190917213209.GK3084169@devbig004.ftw2.facebook.com>
Date:   Tue, 17 Sep 2019 14:32:09 -0700
From:   Tejun Heo <tj@...nel.org>
To:     Paolo Valente <paolo.valente@...aro.org>
Cc:     Jens Axboe <axboe@...nel.dk>, linux-block@...r.kernel.org,
        linux-kernel@...r.kernel.org, ulf.hansson@...aro.org,
        linus.walleij@...aro.org, bfq-iosched@...glegroups.com,
        oleksandr@...alenko.name, cgroups@...r.kernel.org,
        Angelo Ruocco <angeloruocco90@...il.com>
Subject: Re: [PATCH 2/2] block, bfq: delete "bfq" prefix from cgroup filenames

Hello,

On Tue, Sep 17, 2019 at 06:51:48PM +0200, Paolo Valente wrote:
> When bfq was merged into mainline, there were two I/O schedulers that
> implemented the proportional-share policy: bfq for blk-mq and cfq for
> legacy blk. bfq's interface files in the blkio/io controller have the
> same names as cfq. But the cgroups interface doesn't allow two
> entities to use the same name for their files, so for bfq we had to
> prepend the "bfq" prefix to each of its files. However no legacy code
> uses these modified file names. This naming also causes confusion, as,
> e.g., in [1].
> 
> Now cfq has gone with legacy blk, so there is no need any longer for
> these prefixes in (the never used) bfq names. In view of this fact, this
> commit removes these prefixes, thereby enabling legacy code to truly
> use the proportional share policy in blk-mq.

So, I wrote the iocost switching patch and don't have a strong
interest in whether bfq prefix should get dropped or not.  However, I
gotta point out that flipping interface this way is way out of the
norm.

In the previous release cycle, the right thing to do was dropping the
bfq prefix but that wasn't possible because bfq's interface wasn't
compatible at that point and didn't made to be compatible in time.
Non-obviously different interface with the same name is a lot worse
than giving it a new name, so the only acceptable course of action at
that point was keeping the bfq prefix.

Now that the interface has already been published in a released
kernel, dropping the prefix would be something extremely unusual as
there would already be users who will be affected by the interface
flip-flop.  We sometimes do change interfaces but I'm having a
difficult time seeing the overriding rationales in this case.

Thanks.

-- 
tejun