linux-kernel - Re: How Not To Use kref (was Re: kdbus: add code for buses, domains and endpoints)

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: <CA+55aFxB=jWGvPH3TMhB=ungOg9TBai5Ak-ma5vChBB-H2AgnQ@mail.gmail.com>
Date:	Fri, 31 Oct 2014 11:00:01 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Linux API <linux-api@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	John Stultz <john.stultz@...aro.org>,
	Arnd Bergmann <arnd@...db.de>, Tejun Heo <tj@...nel.org>,
	Marcel Holtmann <marcel@...tmann.org>,
	Ryan Lortie <desrt@...rt.ca>, hadess@...ess.net,
	David Herrmann <dh.herrmann@...il.com>,
	Djalal Harouni <tixxdz@...ndz.org>,
	Simon McVittie <simon.mcvittie@...labora.co.uk>,
	Daniel Mack <daniel@...que.org>,
	Alban Crequy <alban.crequy@...labora.co.uk>,
	javier.martinez@...labora.co.uk, teg@...m.no
Subject: Re: How Not To Use kref (was Re: kdbus: add code for buses, domains
 and endpoints)

On Thu, Oct 30, 2014 at 4:38 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
>
> If you remove an object from some search structures, taking the lock in
> destructor is Too Fucking Late(tm).  Somebody might have already found
> that puppy and decided to pick it (all under that lock) just as we'd
> got to that point in destructor and blocked there.  Oops...

Ugh, yes. This is a much too common anti-pattern.

> Normally I'd say "just use kref_put_mutex()", but this case is even worse.
> Look:

Yeah the whole "release the structure the lock is in" is another one.

Both of these patterns have happened so many times that I'd love to
have some kind of automated tool to see them, but I suspect it is
*much* too complex to be easily checked for. The lock object debugging
we have only triggers for the case where the freeing actually happens
with the lock still held, which is too late and too hard-to-hit to be
a very useful check.

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