linux-kernel - Re: [PATCH] proc/kpageflags: add KPF

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] [day] [month] [year] [list]

Message-Id: <20180220160034.db7a3122c44e274ef562002e@linux-foundation.org>
Date:   Tue, 20 Feb 2018 16:00:34 -0800
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Konstantin Khlebnikov <khlebnikov@...dex-team.ru>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Naoya Horiguchi <n-horiguchi@...jp.nec.com>,
        Michal Hocko <mhocko@...e.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Nicholas Piggin <npiggin@...il.com>
Subject: Re: [PATCH] proc/kpageflags: add KPF_WAITERS

On Sat, 17 Feb 2018 11:14:10 +0300 Konstantin Khlebnikov <khlebnikov@...dex-team.ru> wrote:

> On 17.02.2018 02:57, Andrew Morton wrote:
> > On Sun, 11 Feb 2018 13:36:41 +0300 Konstantin Khlebnikov <khlebnikov@...dex-team.ru> wrote:
> > 
> >> KPF_WAITERS indicates tasks are waiting for a page lock or writeback.
> >> This might be false-positive, in this case next unlock will clear it.
> > 
> > Well, kpageflags is full of potential false-positives.  Or do you think
> > this flag is especially vulnerable?
> > 
> > In other words, under what circumstances will we have KPF_WAITERS set
> > when PG_locked and PG-writeback are clear?
> 
> Looks like lock_page() - unlock_page() shouldn't leave longstanding
> false-positive: last unlock_page() must clear PG_waiters.
> 
> But I've seen them. Probably that was from  wait_on_page_writeback():
> it test PG_writeback, set PG_waiters under queue lock unconditionally
> and then test PG_writeback again before sleep - and might exit
> without wakeup i.e. without clearing PG_waiters.
> 
> This could be fixed with extra check for in wait_on_page_bit_common()
> under queue lock.
>
> ...
>
> This bit tells which page or оffset in file is actually wanted
> by somebody in the system. That's another way to track where major
> faults or writeback blocks something. We don't have to record flow
> of events - snapshot of page-flags will show where contention is.
> 

Please send a v2 and let's get all this info into the changelog?