linux-kernel - Re: [PATCH] x86: mcheck: call put_device on device

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:	Sat, 30 Nov 2013 13:08:27 +0100
From:	Borislav Petkov <bp@...en8.de>
To:	Levente Kurusa <levex@...ux.com>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Tony Luck <tony.luck@...el.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	EDAC <linux-edac@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86: mcheck: call put_device on device_register failure

On Sat, Nov 30, 2013 at 12:44:59PM +0100, Levente Kurusa wrote:
> Yes, I saw that as well. By that I meant that by doing some identifier
> searches for device_register and then checking whether they call
> put_device and have device_release registered. Also, I wonder if it
> would be beneficial to have a generic device_release? Most of the
> drivers I quickly swept through only call kfree(). Wouldn't a generic
> one save some space?

Again, I wouldn't waste my time with hypothetical issues which never
happen - there are many other, real issues which would rather need
attention than what-if ones.

About saving space, that could be worth a try. If you can actually do
that and show numbers to back it up, I'm sure people will have a look.
And if you can't show any space savings, you'll still have learned stuff
along the way.

But don't ask me about whether it makes sense to have a generic
device_release - I'm no driver core and am not even trying. You could
try to answer that question yourself, btw. :)

> Yes, I do that daily usually, but most of the time I only get some
> uninitialized warnings. :-)

You can always try to understand why such warnings get issued and maybe
even fix them if they're legit and the compiler is right. Also, look
through git log for examples how others have fixed such warnings.

For example, sometimes changing code flow instead of simply shutting
up the variable is much better. But in order to do that, you'd need to
understand the code first and try to change it so that it doesn't break
and the warning disappears. This is a very good way, IMO, to get to
really understand what the code does and learn from others.

Another good exercise is trying to boot those random kernels with kvm -
that can catch a bunch of issues too.

The save-space experiment you can also quickly test with kvm. By now you
probably are catching my drift: testing kernels with kvm is awesome! :-)

> What does that do? Never heard of it yet.

Well, you can have a look: scripts/Makefile.build

:-)

Good luck!

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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/