linux-kernel - Re: [git patches] two warning fixes

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: <20070718184101.1d31db9c.akpm@linux-foundation.org>
Date:	Wed, 18 Jul 2007 18:41:01 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	Jeff Garzik <jeff@...zik.org>, Andi Kleen <ak@...e.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>, adaplas@...il.com,
	linux-fbdev-devel@...ts.sourceforge.net
Subject: Re: [git patches] two warning fixes

On Thu, 19 Jul 2007 11:19:05 +1000
Benjamin Herrenschmidt <benh@...nel.crashing.org> wrote:

> In general, I share paulus point of view here that forcing us to test
> all those result code from sysfs file creation functions is just a major
> PITA and adds bloat all over the kernel. There are many many cases where
> the "obvious" thing of erroring out is actually not good policy. In many
> cases, the failure to create some random sysfs file shouldn't prevent
> the driver from operating, because the consequences of doing the later
> are worse than the consequences of not having that sysfs file in the
> first place. 

The only reason why the sysfs creation would fail is a kernel bug,
so the consequence of your proposal is in fact unfixed kernel bugs.

Plus, of course, a driver which doesn't offer the interfaces which
it is supposed to offer.

Now, we can talk about making those sysfs core functions generate warnings
themselves, and we can talk about generating new wrappers around them which
generate warnings and which return void, then migrating code over to use
those.

And we can also talk about blithely ignoring these errors and not telling
anyone about our bugs, but nobody should listen to such scandalous ideas.
-
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/