linux-kernel - Re: [PATCH] block/laptop_mode: Convert timers to use timer

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]

Date:   Thu, 5 Oct 2017 21:23:10 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Jens Axboe <axboe@...nel.dk>
cc:     Kees Cook <keescook@...omium.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Michal Hocko <mhocko@...e.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Jan Kara <jack@...e.cz>, Johannes Weiner <hannes@...xchg.org>,
        Nicholas Piggin <npiggin@...il.com>,
        Vladimir Davydov <vdavydov.dev@...il.com>,
        Matthew Wilcox <mawilcox@...rosoft.com>,
        Jeff Layton <jlayton@...hat.com>, linux-block@...r.kernel.org,
        Linux-MM <linux-mm@...ck.org>
Subject: Re: [PATCH] block/laptop_mode: Convert timers to use timer_setup()

On Thu, 5 Oct 2017, Jens Axboe wrote:
> On 10/05/2017 11:49 AM, Kees Cook wrote:
> > Yes, totally true. tglx and I ended up meeting face-to-face at the
> > Kernel Recipes conference and we solved some outstanding design issues
> > with the conversion. The timing meant the new API went into -rc3,
> > which seemed better than missing an entire release cycle, or carrying
> > deltas against maintainer trees that would drift. (This is actually my
> > second massive refactoring of these changes...)
> 
> Honestly, I think the change should have waited for 4.15 in that case.
> Why the rush? It wasn't ready for the merge window.

Come on. You know very well that a prerequisite for global changes which is
not yet used in Linus tree can get merged post merge windew in order to
avoid massive inter maintainer tree dependencies. We've done that before.

There are only a few options we have for such global changes:

   - Delay everything for a full release and keep hunting the ever changing
     code and the new users of old interfaces, which is a pain in the
     butt. I know what I'm talking about.

   - Apply everything in a central tree, which is prone to merge conflicts
     in next when maintainer trees contain changes in the same area. So
     getting it through the maintainers is the best option for this kind of
     stuff.

   - Create a separate branch for other maintainers to pull, which I did
     often enough in the past to avoid merge dependencies.  I decided not
     to offer that branch this time, because it would be been necessary to
     pull it into a gazillion of trees. So we decided that Linus tree as a
     dependency is good enough.

     Just for the record:

     Last time I did this for block you did not complain, that you got
     something based on -rc3 from me because you wanted to have these
     changes in your tree so you could apply the depending multi-queue
     patches. tip irq/for-block exists for a reason.

     So what's the difference to pull -rc3 this time? Nothing, just the
     fact that you are not interested in the change.

     So please stop this hypocritical ranting right here.

Thanks,

	tglx