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, 7 Jan 2021 18:16:14 +0800
From:   Muchun Song <songmuchun@...edance.com>
To:     David Hildenbrand <david@...hat.com>
Cc:     Mike Kravetz <mike.kravetz@...cle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Naoya Horiguchi <n-horiguchi@...jp.nec.com>,
        Andi Kleen <ak@...ux.intel.com>, mhocko@...e.cz,
        Linux Memory Management List <linux-mm@...ck.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [External] Re: [PATCH v2 0/6] Fix some bugs about HugeTLB code

On Thu, Jan 7, 2021 at 6:10 PM David Hildenbrand <david@...hat.com> wrote:
>
> On 07.01.21 10:40, Muchun Song wrote:
> > On Thu, Jan 7, 2021 at 5:30 PM David Hildenbrand <david@...hat.com> wrote:
> >>
> >> On 06.01.21 09:47, Muchun Song wrote:
> >>> This patch series aims to fix some bugs and add some improvements.
> >>>
> >>> Changelog since v1 -> v2:
> >>>   - Export set_page_huge_active() in patch #2 to fix.
> >>>   - Using head[3].mapping to indicate the page is freed in patch #3.
> >>>   - Flush @free_hpage_work in patch #4.
> >>>
> >>> Muchun Song (6):
> >>>   mm: migrate: do not migrate HugeTLB page whose refcount is one
> >>>   mm: hugetlbfs: fix cannot migrate the fallocated HugeTLB page
> >>>   mm: hugetlb: fix a race between freeing and dissolving the page
> >>>   mm: hugetlb: add return -EAGAIN for dissolve_free_huge_page
> >>>   mm: hugetlb: fix a race between isolating and freeing page
> >>>   mm: hugetlb: remove VM_BUG_ON_PAGE from page_huge_active
> >>>
> >>>  fs/hugetlbfs/inode.c    |  3 ++-
> >>>  include/linux/hugetlb.h |  2 ++
> >>>  mm/hugetlb.c            | 69 +++++++++++++++++++++++++++++++++++++++++++------
> >>>  mm/migrate.c            |  6 +++++
> >>>  4 files changed, 71 insertions(+), 9 deletions(-)
> >>>
> >>
> >> Repeating my question regarding ccing stable on selected fixes.
> >>
> >
> > Just add a CC tag in the commit log of the fix patches? Right?
> > Sorry, I'm a novice about this. Thanks.
>
> Sure, here is some information:
>
> https://www.kernel.org/doc/html/v4.10/process/stable-kernel-rules.html
>
> Applicable patches should be moved to the beginning of the series.
>
> Add "Cc: stable@...r.kernel.org" similar to "Fixes:" to the respective
> patches. In the ideal case, indicate the applicable earliest stable
> release where it applies.
>
> E.g., take a look at (random commit)
>
> commit 20b329129009caf1c646152abe09b697227e1c37
> Author: Bob Peterson <rpeterso@...hat.com>
> Date:   Wed Nov 18 08:54:31 2020 -0500
>
>     gfs2: Fix regression in freeze_go_sync
> ...
>     Fixes: 541656d3a513 ("gfs2: freeze should work on read-only mounts")
>     Cc: stable@...r.kernel.org # v5.8+
> ...
>
>
> Consequently, actually cc when sending out these patches (e.g., let "git
> send-email" do it automatically).

Great! Very thanks.

>
> --
> Thanks,
>
> David / dhildenb
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ