linux-kernel - Re: [PATCH 0/4] Remove the type-unclear target id concept

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]

Date:   Wed, 26 Jan 2022 16:37:13 +0000
From:   SeongJae Park <sj@...nel.org>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     SeongJae Park <sj@...nel.org>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/4] Remove the type-unclear target id concept

On Thu, 30 Dec 2021 18:20:59 -0800 Andrew Morton <akpm@...ux-foundation.org> wrote:

> On Thu, 30 Dec 2021 10:07:19 +0000 SeongJae Park <sj@...nel.org> wrote:
> 
> > DAMON asks each monitoring target ('struct damon_target') to have one
> > 'unsigned long' integer called 'id', which should be unique among the
> > targets of same monitoring context.  Meaning of it is, however, totally
> > up to the monitoring primitives that registered to the monitoring
> > context.  For example, the virtual address spaces monitoring primitives
> > treats the id as a 'struct pid' pointer.
> > 
> > This makes the code flexible but ugly, not well-documented, and
> > type-unsafe[1].  Also, identification of each target can be done via its
> > index.  For the reason, this patchset removes the concept and uses clear
> > type definition.
> 
> Thanks.  This doesn't appear to be urgent, so I'll park it until after 5.17-rc1.

Just for a remind.  I confirmed this patchset is cleanly applicable on the
latest -next tree.


Thanks,
SJ