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: <20220228162514.4111-1-sj@kernel.org>
Date:   Mon, 28 Feb 2022 16:25:14 +0000
From:   SeongJae Park <sj@...nel.org>
To:     xhao@...ux.alibaba.com
Cc:     SeongJae Park <sj@...nel.org>, akpm@...ux-foundation.org,
        corbet@....net, skhan@...uxfoundation.org, rientjes@...gle.com,
        gregkh@...uxfoundation.org, linux-damon@...zon.com,
        linux-mm@...ck.org, linux-doc@...r.kernel.org,
        linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 05/13] mm/damon/sysfs: Support the physical address space monitoring

On Tue, 1 Mar 2022 00:11:12 +0800 xhao@...ux.alibaba.com wrote:

> 
> On 2/28/22 4:13 PM, SeongJae Park wrote:
> > This commit makes DAMON sysfs interface supports the physical address
> > space monitoring.  Specifically, this commit adds support of the initial
> > monitoring regions set feature by adding 'regions' directory under each
> > target directory and makes context operations file to receive 'paddr' in
> > addition to 'vaddr'.
> >
> > As a result, the files hierarchy becomes as below:
> >
> >      /sys/kernel/mm/damon/admin
> >      │ kdamonds/nr_kdamonds
> >      │ │ 0/state,pid
> >      │ │ │ contexts/nr_contexts
> >      │ │ │ │ 0/operations
> >      │ │ │ │ │ monitoring_attrs/
> >      │ │ │ │ │ │ intervals/sample_us,aggr_us,update_us
> >      │ │ │ │ │ │ nr_regions/min,max
> >      │ │ │ │ │ targets/nr_targets
> >      │ │ │ │ │ │ 0/pid_target
> >      │ │ │ │ │ │ │ regions/nr_regions    <- NEW DIRECTORY
> >      │ │ │ │ │ │ │ │ 0/start,end
> >      │ │ │ │ │ │ │ │ ...
> >      │ │ │ │ │ │ ...
> >      │ │ │ │ ...
> >      │ │ ...
> >
> > Signed-off-by: SeongJae Park <sj@...nel.org>
> > ---
> >   mm/damon/sysfs.c | 276 ++++++++++++++++++++++++++++++++++++++++++++++-
> >   1 file changed, 271 insertions(+), 5 deletions(-)
> >
> > diff --git a/mm/damon/sysfs.c b/mm/damon/sysfs.c
> > index 9221c93db6cc..968a4ba8e81b 100644
> > --- a/mm/damon/sysfs.c
> > +++ b/mm/damon/sysfs.c
> > @@ -113,12 +113,220 @@ static struct kobj_type damon_sysfs_ul_range_ktype = {
> >   	.default_groups = damon_sysfs_ul_range_groups,
> >   };
> >   
> > +/*
> > + * init region directory
> > + */
> > +
> > +struct damon_sysfs_region {
> > +	struct kobject kobj;
> > +	unsigned long start;
> > +	unsigned long end;
> > +};
> > +
> > +static struct damon_sysfs_region *damon_sysfs_region_alloc(
> > +		unsigned long start,
> > +		unsigned long end)
> > +{
> > +	struct damon_sysfs_region *region = kmalloc(sizeof(*region),
> > +			GFP_KERNEL);
> > +
> > +	if (!region)
> > +		return NULL;
> > +	region->kobj = (struct kobject){};
> > +	region->start = start;
> > +	region->end = end;
> > +	return region;
> > +}
> > +
> 
> The interface "start" and "end" have the same problems
> 
> [root@...k03395 0]# echo 100 > start
> [root@...k03395 0]# echo 10 > end
> [root@...k03395 0]# cat end
> 10
> [root@...k03395 0]# cat start
> 100

As mentioned on the above answer[1], this is an intended behavior, so I don't
think a fix is needed.

[1] https://lore.kernel.org/linux-mm/20220228162318.4046-1-sj@kernel.org/


Thanks,
SJ

[...]
> -- 
> Best Regards!
> Xin Hao
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ