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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Sun, 25 Dec 2016 11:00:49 +1000
From:   Nicholas Piggin <>
To:     Hugh Dickins <>
Cc:     Dave Hansen <>,
        Linus Torvalds <>,
        Bob Peterson <>,
        Linux Kernel Mailing List <>,,,,,,
        Mel Gorman <>
Subject: Re: [PATCH 1/2] mm: Use owner_priv bit for PageSwapCache, valid
 when PageSwapBacked

On Thu, 22 Dec 2016 11:55:28 -0800 (PST)
Hugh Dickins <> wrote:

> On Thu, 22 Dec 2016, Nicholas Piggin wrote:
> I agree with every word of that changelog ;)
> And I'll stamp this with
> Acked-by: Hugh Dickins <>

Thanks Hugh.
> The thing that Peter remembers I commented on (which 0day caught too),
> was to remove PG_swapcache from PAGE_FLAGS_CHECK_AT_FREE: you've done
> that now, so this is good.  (Note in passing: wouldn't it be good to
> add PG_waiters to PAGE_FLAGS_CHECK_AT_FREE in the 2/2?)
> Though I did yesterday notice a few more problematic uses of
> PG_swapcache, which you'll probably need to refine to exclude
> other uses of PG_owner_priv_1; though no great hurry for those,
> so not necessarily in this same patch.  Do your own grep, but
> fs/proc/page.c derives its KPF_SWAPCACHE from PG_swapcache,
> needs refining.
> kernel/kexec_core.c says VMCOREINFO_NUMBER(PG_swapcache):
> I haven't looked into what that's about, it will probably just
> have to be commented as now including other uses of the same bit.
> mm/memory-failure.c has an error_states[] table that involves
> testing PG_swapcache as "sc", but looks as if it can be changed
> to factor in "swapbacked" too.

I've added the swapbacked check to mm/memory-failure.c, the others look
like they're just dealing with bit number, so not much to do about it
really. I also just made the migration case more explicit, seeing as the
others are.

Hopefully that doesn't negate your ack because I'm adding that too.


Powered by blists - more mailing lists