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  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, 26 Nov 2020 14:37:15 +0100
From:   SeongJae Park <sjpark@...zon.com>
To:     Shakeel Butt <shakeelb@...gle.com>
CC:     SeongJae Park <sjpark@...zon.com>,
        SeongJae Park <sjpark@...zon.de>,
        <Jonathan.Cameron@...wei.com>,
        Andrea Arcangeli <aarcange@...hat.com>, <acme@...nel.org>,
        <alexander.shishkin@...ux.intel.com>, <amit@...nel.org>,
        <benh@...nel.crashing.org>, <brendan.d.gregg@...il.com>,
        Brendan Higgins <brendanhiggins@...gle.com>,
        Qian Cai <cai@....pw>,
        Colin Ian King <colin.king@...onical.com>,
        Jonathan Corbet <corbet@....net>,
        "David Hildenbrand" <david@...hat.com>, <dwmw@...zon.com>,
        Marco Elver <elver@...gle.com>, "Du, Fan" <fan.du@...el.com>,
        <foersleo@...zon.de>, "Greg Thelen" <gthelen@...gle.com>,
        Ian Rogers <irogers@...gle.com>, <jolsa@...hat.com>,
        "Kirill A. Shutemov" <kirill@...temov.name>,
        Mark Rutland <mark.rutland@....com>,
        Mel Gorman <mgorman@...e.de>, Minchan Kim <minchan@...nel.org>,
        Ingo Molnar <mingo@...hat.com>, <namhyung@...nel.org>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        Rik van Riel <riel@...riel.com>,
        David Rientjes <rientjes@...gle.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Mike Rapoport <rppt@...nel.org>, <sblbir@...zon.com>,
        Shuah Khan <shuah@...nel.org>, <sj38.park@...il.com>,
        <snu@...zon.de>, Vlastimil Babka <vbabka@...e.cz>,
        Vladimir Davydov <vdavydov.dev@...il.com>,
        Yang Shi <yang.shi@...ux.alibaba.com>,
        Huang Ying <ying.huang@...el.com>, <zgf574564920@...il.com>,
        <linux-damon@...zon.com>, Linux MM <linux-mm@...ck.org>,
        <linux-doc@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v22 07/18] mm/page_idle: Avoid interferences from concurrent users

On Wed, 25 Nov 2020 07:30:27 -0800 Shakeel Butt <shakeelb@...gle.com> wrote:

> On Tue, Oct 20, 2020 at 2:06 AM SeongJae Park <sjpark@...zon.com> wrote:
> >
> > From: SeongJae Park <sjpark@...zon.de>
> >
> > Concurrent Idle Page Tracking users can interfere each other because the
> > interface doesn't provide a central rule for synchronization between the
> > users.  Users could implement their own synchronization rule, but even
> > in that case, applications developed by different users would not know
> > how to synchronize with others.  To help this situation, this commit
> > introduces a centralized synchronization infrastructure of Idle Page
> > Tracking.
> >
> > In detail, this commit introduces a mutex lock for Idle Page Tracking,
> > called 'page_idle_lock'.  It is exposed to user space via a new bool
> > sysfs file, '/sys/kernel/mm/page_idle/lock'.  By writing to and reading
> > from the file, users can hold/release and read status of the mutex.
> > Writes to the Idle Page Tracking 'bitmap' file fails if the lock is not
> > held, while reads of the file can be done regardless of the lock status.
> >
> > Note that users could still interfere each other if they abuse this
> > locking rule.  Nevertheless, this change will let them notice the rule.
> >
> > Signed-off-by: SeongJae Park <sjpark@...zon.de>
> 
> I don't think this is allowed. I mean returning to user space with
> held mutex and other processes can unlock it. I don't think mutex is
> what you need. Or more importantly is this really an issue?
> 

In a separate call, I and Shakeel agreed on that this is trying to fix an issue
that aren't proved real.  So I will drop this patch in next version of the
patchset.  We can restore this patch or find better fix later if the problem
comes out in real.


Thanks,
SeongJae Park

Powered by blists - more mailing lists