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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 1 Feb 2021 18:08:03 +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 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 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