From: Jens Axboe <axboe@kernel.dk>
To: Kees Cook <keescook@chromium.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Michal Hocko <mhocko@suse.com>,
Andrew Morton <akpm@linux-foundation.org>,
Jan Kara <jack@suse.cz>, Johannes Weiner <hannes@cmpxchg.org>,
Nicholas Piggin <npiggin@gmail.com>,
Vladimir Davydov <vdavydov.dev@gmail.com>,
Matthew Wilcox <mawilcox@microsoft.com>,
Jeff Layton <jlayton@redhat.com>,
linux-block@vger.kernel.org, Linux-MM <linux-mm@kvack.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] block/laptop_mode: Convert timers to use timer_setup()
Date: Thu, 5 Oct 2017 12:56:23 -0600 [thread overview]
Message-ID: <57556968-319c-b259-d8a7-164e6e6600a8@kernel.dk> (raw)
In-Reply-To: <CAGXu5j+g6PoJ_e_CVNt-QWrtfA+TZt1=0MExbZygSffMt7yK6A@mail.gmail.com>
On 10/05/2017 12:49 PM, Kees Cook wrote:
> On Thu, Oct 5, 2017 at 11:26 AM, Jens Axboe <axboe@kernel.dk> wrote:
>> 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.
>
> My understanding from my discussion with tglx was that if the API
> change waiting for 4.15, then the conversions would have to wait until
> 4.16. With most conversions only depending on the new API, it seemed
> silly to wait another whole release when the work is just waiting to
> be merged.
Right, it would have shifted everything a release. But that's how we do
things! If something isn't ready _before_ the merge window, let alone
talking -rc3 time, then it gets to wait unless it's fixing a regression
introduced in the merge window. Or if you can argue that it's a really
critical fix, sure, it can be squeezed in.
I'm puzzled why anyone would think that this is any different. What I'm
hearing here is that "I didn't want to wait, and my change is more
important than others", as an argument for why this should be treated
any differently.
I'm not saying the change is bad, it looks trivial, from_timer()
discussion aside. But it's not a critical fix, by any stretch of the
imagination, and neither are the driver conversions. With this
additionally causing extra problems because of the timing, that's just
further proof that it should have waited.
> But yes, timing was not ideal. I did try to get it in earlier, but I
> think tglx was busy with other concerns.
So it should have waited...
--
Jens Axboe
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-10-05 18:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-05 0:49 Kees Cook
2017-10-05 14:56 ` Jens Axboe
2017-10-05 17:49 ` Kees Cook
2017-10-05 18:26 ` Jens Axboe
2017-10-05 18:49 ` Kees Cook
2017-10-05 18:56 ` Jens Axboe [this message]
2017-10-05 19:23 ` Thomas Gleixner
2017-10-05 19:41 ` Jens Axboe
2017-10-05 19:49 ` Jens Axboe
2017-10-05 21:53 ` Thomas Gleixner
2017-10-05 22:07 ` Jens Axboe
2017-10-05 22:58 ` Kees Cook
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57556968-319c-b259-d8a7-164e6e6600a8@kernel.dk \
--to=axboe@kernel.dk \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=jack@suse.cz \
--cc=jlayton@redhat.com \
--cc=keescook@chromium.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mawilcox@microsoft.com \
--cc=mhocko@suse.com \
--cc=npiggin@gmail.com \
--cc=tglx@linutronix.de \
--cc=vdavydov.dev@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox