linux-kernel - Re: [PATCH] list: add more extensive double add check

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:   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