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]
Date:   Wed, 11 Mar 2020 11:14:06 -0700
From:   Sai Praneeth Prakhya <sai.praneeth.prakhya@...el.com>
To:     Reinette Chatre <reinette.chatre@...el.com>, shuah@...nel.org,
        linux-kselftest@...r.kernel.org
Cc:     tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
        tony.luck@...el.com, babu.moger@....com, james.morse@....com,
        ravi.v.shankar@...el.com, fenghua.yu@...el.com, x86@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH V1 09/13] selftests/resctrl: Modularize fill_buf for new
 CAT test case

HI Reinette,

On Wed, 2020-03-11 at 11:10 -0700, Reinette Chatre wrote:
> Hi Sai,
> 
> On 3/11/2020 10:45 AM, Sai Praneeth Prakhya wrote:
> > On Wed, 2020-03-11 at 08:44 -0700, Reinette Chatre wrote:
> > > On 3/10/2020 6:04 PM, Sai Praneeth Prakhya wrote:
> > > > On Tue, 2020-03-10 at 14:59 -0700, Reinette Chatre wrote:
> > > > > On 3/6/2020 7:40 PM, Sai Praneeth Prakhya wrote:
> > > > > > Currently fill_buf (in-built benchmark) runs as a separate process
> > > > > > a
> > > > > > 
> > 

[SNIP]

> > > Maintaining the end pointer is unusual. The start of the buffer and the
> > > size are known properties that the end of the buffer can be computed
> > > from. Not a problem, it just seems inconsistent that some of the buffer
> > > functions operate on the start pointer and size while others operate on
> > > the start pointer and end pointer.
> > 
> > Ok.. makes sense. I will try to make it consistent by using endptr all the
> > time. One advantage of using endptr is that we could just compute endptr
> > once
> > and use it when needed by passing it as variable (will try to not make it
> > global variable).
> 
> This may add unnecessary complexity because from what I can tell some of
> those calls require buffer size and this would then require needing to
> recompute the buffer size based on the start and end pointers. Do you
> really need the end pointer? Can you not just use the start pointer and
> buffer size?

Ok.. makes sense. Will use buffer size.

Regards,
Sai

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ