Re: [GIT PULL] Block fixes for 5.2-rc4

[Paolo Valente <paolo.valente@linaro.org>]

[-- Attachment #1: Type: text/plain, Size: 3233 bytes --]



> Il giorno 10 giu 2019, alle ore 12:15, Jens Axboe <axboe@kernel.dk> ha scritto:
> 
> On 6/9/19 10:06 AM, Linus Torvalds wrote:
>> On Sat, Jun 8, 2019 at 11:00 PM Jens Axboe <axboe@kernel.dk> wrote:
>>> 
>>> FWIW, the concept/idea goes back a few months and was discussed with
>>> the cgroup folks. But I totally agree that the implementation could
>>> have been cleaner, especially at this point in time.
>>> 
>>> I'm fine with you reverting those two patches for 5.2 if you want to,
>>> and the BFQ folks can do this more cleanly for 5.3.
>> 
>> I don't think the code is _broken_, and I don't think the link_name
>> thing is wrong. So no point in reverting unless we see more issues.
>> 
>> I just wish it had been done differently, both from the patch details
>> standpoint, but also in making sure the cgroup people were aware (and
>> maybe they were, but it certainly didn't show up in the commit).
>> 
>> So I think an incremental patch like the attached would make the code
>> easier to understand (I really do mis-like random boolean flags being
>> passed around that change behavior in undocumented and non-obvious
>> ways), but I'd also want to make sure that Tejun & co are all on board
>> and know about it..
>> 
>> I'm sure this happens a lot, but during the rc series I just end up
>> *looking* at details like this a lot more, when I see changes outside
>> of a subsystem directory.
>> 
>> Tejun&co, we're talking about commit 54b7b868e826 ("cgroup: let a
>> symlink too be created with a cftype file") which didn't have any sign
>> of you guys being aware of it or having acked it.
> 
> I talked to Tejun about this offline, and he's not a huge fan of the
> symlink. So let's revert this for now, and Paolo can do this properly
> for 5.3 instead.
> 

Hi all,
we'd be ok with implementing this the right way, but what's the point
in spending further hours on a solution not liked by Tejun?  Here's
what happened so far:
1) General solution allowing multiple entities to share common files:
   rejected by Tejun.
2) Simple replacement bfq.weight -> weight, after the only entity
   using that name, cfq, has gone: rejected by Jens because it is a
   disruptive change of the interface.
3) Symlink, proposed by Johannes: maybe rejected by Tejun.

Tejun, could you please tell us whether you may accept the last
option?  This option may be associated with deprecating the explicit
use of bfq.weight (I don't know of anybody who wants to use this
confusing name).  So, in a few releases we could finally drop this
bfq.weight and turn the symlink back into an actual interface file.

I'm running out of options, apart from giving up.

Thanks,
Paolo

> Sorry for the confusion! Please pull the below.
> 
> 
>  git://git.kernel.dk/linux-block.git tags/for-linus-20190610
> 
> 
> ----------------------------------------------------------------
> Jens Axboe (1):
>      cgroup/bfq: revert bfq.weight symlink change
> 
> block/bfq-cgroup.c          |  6 ++----
> include/linux/cgroup-defs.h |  3 ---
> kernel/cgroup/cgroup.c      | 33 ++++-----------------------------
> 3 files changed, 6 insertions(+), 36 deletions(-)
> 
> --
> Jens Axboe


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]