linux-kernel - Re: [PATCH v34 00/13] Introduce Data Access MONitor (DAMON)

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]

Message-Id: <20210806114801.6958-1-sjpark@amazon.de>
Date:   Fri,  6 Aug 2021 11:48:01 +0000
From:   SeongJae Park <sj38.park@...il.com>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     SeongJae Park <sj38.park@...il.com>,
        Shakeel Butt <shakeelb@...gle.com>,
        SeongJae Park <sjpark@...zon.de>, Jonathan.Cameron@...wei.com,
        amit@...nel.org, Jonathan Corbet <corbet@....net>,
        David Hildenbrand <david@...hat.com>, dwmw@...zon.com,
        foersleo@...zon.de, Greg Thelen <gthelen@...gle.com>,
        jgowans@...zon.com, mheyne@...zon.de,
        David Rientjes <rientjes@...gle.com>, sieberf@...zon.com,
        Vlastimil Babka <vbabka@...e.cz>, linux-damon@...zon.com,
        Linux MM <linux-mm@...ck.org>, linux-doc@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>, Wei Xu <weixugc@...gle.com>,
        Paul Turner <pjt@...gle.com>, Yu Zhao <yuzhao@...gle.com>,
        Dave Hansen <dave.hansen@...el.com>
Subject: Re: [PATCH v34 00/13] Introduce Data Access MONitor (DAMON)

From: SeongJae Park <sjpark@...zon.de>

On Thu, 5 Aug 2021 17:03:44 -0700 Andrew Morton <akpm@...ux-foundation.org> wrote:

> On Wed, 28 Jul 2021 08:36:43 +0000 SeongJae Park <sj38.park@...il.com> wrote:
> 
> > > DAMON does not expose stable APIs at the moment, so these can
> > > be changed later if needed. I think it is ok to merge DAMON for some
> > > exposure. However I do want to make this clear that the solution space
> > > is not complete. The solution of system level monitoring is still
> > > needed which can be a future extension to DAMON or more generalized
> > > Multigen LRU.
> > 
> > Agreed.  We have lots more works to do.  Some of those are already posted as
> > RFC patchsets[1,2,3,4].  I promise I will happily do the works.  But, how dare
> > could only I get all the fun?  I'd like to do that together with others in this
> > great community.  One major purpose of this patchset is thus providing a
> > flexible framework for such collaboration.  The virtual address space
> > monitoring, which this patchset provides in addition to the framework, is also
> > for real-world usages, though.
> > 
> > Now all the patches have at least one 'Reviewed-by:' or 'Acked-by:' tags.  We
> > didn't find serious problems since v26[5], which was posted about four months
> > ago. so I'm thinking this patchset has passed the minimum qualification.  If
> > you think there are more things to be done before this patchset is merged in
> > the -mm tree or mainline, please let me know.  If not, Andrew, I'd like you to
> > consider merging this patchset into '-mm' tree.
> 
> Shall take a look.  With some trepidation.
> 
> 1-2 years from now someone will pop up with a massive patchset
> implementing some monitoring scheme and we'll say "why didn't you use
> DAMON" and they'll say "it's unsuitable for <reasons>".

Agreed.  And I personally believe merging this in will help avoiding such
situation, because the someone will be able to easily find the developer who is
responsible to convince the person.  I will happily and definitely do my best
for that.

> 
> I would like to see more thought/design go into how DAMON could be
> modified to address Shakeel's other three requirements.  At least to
> the point where we can confidently say "yes, we will be able to do
> this".  Are you able to drive this discussion along please?

Sure.  I will describe my plan for convincing Shakeel's usages in detail as a
reply to this mail.


Thanks,
SeongJae Park