All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	cheloha@linux.ibm.com, David Hildenbrand <david@redhat.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	ldufour@linux.ibm.com, Linux-MM <linux-mm@kvack.org>,
	mm-commits@vger.kernel.org, nathanl@linux.ibm.com,
	Oscar Salvador <osalvador@suse.de>,
	Rafael Wysocki <rafael@kernel.org>,
	stable <stable@vger.kernel.org>, Tony Luck <tony.luck@intel.com>
Subject: Re: [patch 8/9] mm: replace memmap_context by meminit_context
Date: Wed, 30 Sep 2020 19:30:38 +0200	[thread overview]
Message-ID: <20200930173038.GZ2277@dhcp22.suse.cz> (raw)
In-Reply-To: <CAHk-=wgGN3drZeV-RZpVn20yZ6tB0PDCgXa=DaD47sRvM16sGw@mail.gmail.com>

On Wed 30-09-20 09:00:26, Linus Torvalds wrote:
> On Tue, Sep 29, 2020 at 1:37 PM Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > 1/3 and 2/3 were cc:stable and 3/3 was not.  As far as I can tell, 3/3
> > is rather theoretical once 2/3 has done its work, so I held it off for
> > the next merge window.
> 
> That's not the problem, holding off is fine.
> 
> The problem is that the commit messages are garbage as a result. They
> were written as a series of three, but the patches weren't _sent_ as a
> series of three.

This part of the commit message is coming from a cover letter and it is
something that would usually go to a merge commit (from a pull request).
With Andrew's worklflow he preserves the information in the first patch
of the series. It is great to have that information around because there
is usually more background and a high level description. 
 
> So if you split up a series like that, you should look at the commit
> mesages and edit them appropriately.

Yeah, in cases like that it is better to just drop that cover letter
part.

I would still argue that all three could have gone in together. The last
patch has not been marked for stable but it is a useful patch on its own
as it drops a really distasteful BUG() on a failure mode. IMHO it
wouldn't be a big deal to postpone sending these during the merge window
as these patches are not addressing a regression for this part merge
window.

Just my 2c
-- 
Michal Hocko
SUSE Labs

  reply	other threads:[~2020-09-30 17:30 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-26  4:17 incoming Andrew Morton
2020-09-26  4:19 ` [patch 1/9] mm, THP, swap: fix allocating cluster for swapfile by mistake Andrew Morton
2020-09-26  4:19 ` [patch 2/9] mm: memcontrol: fix missing suffix of workingset_restore Andrew Morton
2020-09-26  4:19 ` [patch 3/9] mm/gup: fix gup_fast with dynamic page table folding Andrew Morton
2020-09-26  4:19 ` [patch 4/9] mm/migrate: correct thp migration stats Andrew Morton
2020-09-26  4:19 ` [patch 5/9] lib/string.c: implement stpcpy Andrew Morton
2020-09-26  4:19 ` [patch 6/9] lib/memregion.c: include memregion.h Andrew Morton
2020-09-26  4:19 ` [patch 7/9] arch/x86/lib/usercopy_64.c: fix __copy_user_flushcache() cache writeback Andrew Morton
2020-09-26  4:19 ` [patch 8/9] mm: replace memmap_context by meminit_context Andrew Morton
2020-09-26 17:32   ` Linus Torvalds
2020-09-26 17:32     ` Linus Torvalds
2020-09-29  6:55     ` Michal Hocko
2020-09-29 16:28     ` Laurent Dufour
2020-09-29 20:37     ` Andrew Morton
2020-09-30 16:00       ` Linus Torvalds
2020-09-30 16:00         ` Linus Torvalds
2020-09-30 17:30         ` Michal Hocko [this message]
2020-09-26  4:19 ` [patch 9/9] mm: don't rely on system state to detect hot-plug operations Andrew Morton

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=20200930173038.GZ2277@dhcp22.suse.cz \
    --to=mhocko@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=cheloha@linux.ibm.com \
    --cc=david@redhat.com \
    --cc=fenghua.yu@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=ldufour@linux.ibm.com \
    --cc=linux-mm@kvack.org \
    --cc=mm-commits@vger.kernel.org \
    --cc=nathanl@linux.ibm.com \
    --cc=osalvador@suse.de \
    --cc=rafael@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=tony.luck@intel.com \
    --cc=torvalds@linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.