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-next>] [day] [month] [year] [list]
Date:	Tue, 31 Jul 2007 19:55:27 +0400
From:	Alexey Dobriyan <adobriyan@...ru>
To:	akpm@...l.org, torvalds@...l.org
Cc:	linux-kernel@...r.kernel.org, herbert@...dor.apana.org.au
Subject: WARN_ON() which sometimes sucks

It started when I tried to write

	WARN_ON(m->seq_ops_allocated);

in today's "[PATCH] single_open/seq_release leak diagnostics¹.
Suprisingly compiler told me piss off with:

	  CC      fs/seq_file.o
	fs/seq_file.c: In function 'seq_release':
	fs/seq_file.c:285: error: 'typeof' applied to a bit-field

Well, duh! Earlier versions of WARN_ON allowed that until commit
684f978347deb42d180373ac4c427f82ef963171² which added typeof().

OK, nobody noticed that WARN_ON(bitfield) stopped working. But I
question the rationale of that commit:

	Letting WARN_ON/WARN_ON_ONCE return the condition means that you could
	do

	if (WARN_ON(blah)) {
	        handle_impossible_case
	}

	Rather than

	if (unlikely(blah)) {
	        WARN_ON(1)
	        handle_impossible_case
	}

I think that second case is more clear and immediately understandable.
If folks agree, I'll send revert so that WARN_ON(var), WARN_ON(ptr),
WARN_ON(bitfield) and WARN_ON(condition) work as expected.

¹ http://marc.info/?l=linux-kernel&m=118588389612083&w=2
²

tree db9025d8c6b267565c7110e09b16193957186a48
parent 6299a2dec89d22940e36832f15c0addfb77e6910
author Herbert Xu <herbert@...dor.apana.org.au> 1159520346 -0700
committer Linus Torvalds <torvalds@...osdl.org> 1159546686 -0700

[PATCH] Let WARN_ON/WARN_ON_ONCE return the condition

Letting WARN_ON/WARN_ON_ONCE return the condition means that you could do

if (WARN_ON(blah)) {
	handle_impossible_case
}

Rather than

if (unlikely(blah)) {
	WARN_ON(1)
	handle_impossible_case
}

I checked all the newly added WARN_ON_ONCE users and none of them test the
return status so we can still change it.

[akpm@...l.org: warning fix]
[akpm@...l.org: build fix]
Signed-off-by: Herbert Xu <herbert@...dor.apana.org.au>
Cc: Ingo Molnar <mingo@...e.hu>
Signed-off-by: Andrew Morton <akpm@...l.org>
Signed-off-by: Linus Torvalds <torvalds@...l.org>

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ