linux-kernel - Re: [PATCH] Extend list debugging to cover hlists

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: <20080502163941.e2afd851.akpm@linux-foundation.org>
Date:	Fri, 2 May 2008 16:39:41 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Matthew Wilcox <matthew@....cx>
Cc:	torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
	davej@...hat.com
Subject: Re: [PATCH] Extend list debugging to cover hlists

On Fri, 2 May 2008 17:17:27 -0600
Matthew Wilcox <matthew@....cx> wrote:

> On Fri, May 02, 2008 at 04:14:03PM -0700, Andrew Morton wrote:
> > linux-next is a better tree against which to prepare 2.6.x+1 patches.
> 
> Is there a reason to wait for 2.6.x+1?  People are having problems today
> with corrupt hlists.

dunno, really.  Merging it would bust git-sched and linux-next, which is of
course solveable, but a hassle.  If there are bugs in there then linux-next
and -mm testing will pick up some of them.  Mainline testing would pick up
more.  Is that delta worth it?  dunno, really.

Experience tells us that decent testing of new debug infrastructure
(especially that which goes BUG) before it goes mainline is a good idea.

<looks at the patch>

diff --git a/include/linux/list.h b/include/linux/list.h
> index 08cf4f6..a325d9f 100644
> --- a/include/linux/list.h
> +++ b/include/linux/list.h
> @@ -714,10 +714,17 @@ static inline int hlist_empty(const struct hlist_head *h)
>  	return !h->first;
>  }
>  
> +#ifdef CONFIG_DEBUG_LIST
> +extern void hlist_check(struct hlist_node *n);
> +#else
> +#define hlist_check(n)		do { } while (0)

a static inline would be better.

- It matches the other version, which is aesthetically pleasing

- It provides type-checking when CONFIG_DEBUG_LIST=n


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/