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: <YBgnyWrp16WB1JGQ@smile.fi.intel.com>
Date:   Mon, 1 Feb 2021 18:09:45 +0200
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Christian König 
        <ckoenig.leichtzumerken@...il.com>
Cc:     mojha@...eaurora.org, jkosina@...e.cz, cezary.rojewski@...el.com,
        neilb@...e.com, b00073877@....edu, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] list: add more extensive double add check

On Mon, Feb 01, 2021 at 06:08:03PM +0200, Andy Shevchenko wrote:
> On Mon, Feb 01, 2021 at 02:52:51PM +0100, Christian König wrote:
> > Adding the same element to a linked list multiple times
> > seems to be a rather common programming mistake. To debug
> > those I've more than once written some code to check a
> > linked list for duplicates.
> > 
> > Since re-inventing the wheel over and over again is a bad
> > idea this patch tries to add some common code which allows
> > to check linked lists for duplicates while adding new
> > elements.
> > 
> > When list debugging is enabled we currently already check
> > the previous and next element if they are identical to the
> > new one. This patch now adds a configuration option to
> > check N elements before and after the desired position.
> > 
> > By default we still only test one item since testing more
> > means quite a large CPU overhead. This can be overwritten
> > on a per C file bases by defining DEBUG_LIST_DOUBLE_ADD
> > before including list.h.
> 
> I'm not sure it is a good idea. Currently the implementation is *generic*.
> You are customizing it w/o letting caller know.
> 
> Create a derivative implementation and name it exlist (exclusive list) and use
> whenever it makes sense.

And make depth is a runtime parameter available for user.

> And I think if you are still pushing to modify generic one the default must be
> 0 in order not altering current behaviour.
> 
> > A new kunit test is also added to the existing list tests
> > which intentionally triggers the debug functionality.

-- 
With Best Regards,
Andy Shevchenko


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ