linux-kernel - Re: [failures] mm-vmscan-remove-unnecessary-lruvec-adding.patch removed from -mm tree

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <792CE873-A64B-4FA6-A258-A8B6B951E698@lca.pw>
Date:   Fri, 6 Mar 2020 21:27:41 -0500
From:   Qian Cai <cai@....pw>
To:     Alex Shi <alex.shi@...ux.alibaba.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>, aarcange@...hat.com,
        daniel.m.jordan@...cle.com, hannes@...xchg.org, hughd@...gle.com,
        khlebnikov@...dex-team.ru, kirill@...temov.name,
        kravetz@...ibm.com, mhocko@...nel.org, mm-commits@...r.kernel.org,
        tj@...nel.org, vdavydov.dev@...il.com, willy@...radead.org,
        yang.shi@...ux.alibaba.com
Subject: Re: [failures] mm-vmscan-remove-unnecessary-lruvec-adding.patch
 removed from -mm tree



> On Mar 6, 2020, at 6:58 AM, Alex Shi <alex.shi@...ux.alibaba.com> wrote:
> 
> 
> 
> 在 2020/3/6 下午5:04, Alex Shi 写道:
>> 
>> 
>> 在 2020/3/6 上午11:32, Qian Cai 写道:
>>> 
>>>> On Mar 5, 2020, at 9:50 PM, akpm@...ux-foundation.org wrote:
>>>> 
>>>> 
>>>> The patch titled
>>>>    Subject: mm/vmscan: remove unnecessary lruvec adding
>>>> has been removed from the -mm tree.  Its filename was
>>>>    mm-vmscan-remove-unnecessary-lruvec-adding.patch
>>>> 
>>>> This patch was dropped because it had testing failures
>>> Andrew, do you have more information about this failure? I hit a bug
>>> here under memory pressure and am wondering if this is related
>>> which might save me some time digging…
>>> 
>>> [ 4389.727184][ T6600] mem_cgroup_update_lru_size(00000000bb31aaed, 0, -7): lru_size -1
>> 
>> This bug seems failed due to a update_lru_size() missing or misplace, but
>> what's I changed on this patch seems unlike to cause this bug.
>> 
>> Anyway, Qian, could you do me a favor to remove this patch and try again?
> 
> Compare to this patch's change, the 'c8cba0cc2a80 mm/thp: narrow lru locking' is more
> likely bad. Maybe it's due to lru unlock was moved before ClearPageCompound() from
> before remap_page(head); guess this unlock should be move after ClearPageCompound or
> move back to origin place.

I can only confirmed that after reverted those 6 patches, I am no long be able to reproduce it.

> 
> But I still can not reproduce this bug. Awkward!
> 
> Alex
> 
> ---
> line 2605 mm/huge_memory.c:
>        spin_unlock_irqrestore(&pgdat->lru_lock, flags);
> 
>        ClearPageCompound(head);
> 
>        split_page_owner(head, HPAGE_PMD_ORDER);
> 
>        /* See comment in __split_huge_page_tail() */
>        if (PageAnon(head)) {
>                /* Additional pin to swap cache */
>                if (PageSwapCache(head)) {
>                        page_ref_add(head, 2);
>                        xa_unlock(&swap_cache->i_pages);
>                } else {
>                        page_ref_inc(head);
>                }
>        } else {
>                /* Additional pin to page cache */
>                page_ref_add(head, 2);
>                xa_unlock(&head->mapping->i_pages);
>        }
> 
>        remap_page(head);