linux-kernel - Re: [External] Re: [PATCH v2 0/6] Fix some bugs about HugeTLB code

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 11:10:21 +0100
From:   David Hildenbrand <david@...hat.com>
To:     Muchun Song <songmuchun@...edance.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 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).

-- 
Thanks,

David / dhildenb