linux-kernel - Re: [PATCH] kthread: saa7134-tvaudio.c

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: <m1k64rf9om.fsf@ebiederm.dsl.xmission.com>
Date:	Tue, 29 Aug 2006 16:39:53 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Andrew Morton <akpm@...l.org>
Cc:	Sukadev Bhattiprolu <sukadev@...ibm.com>,
	video4linux-list@...hat.com,
	Mauro Carvalho Chehab <mchehab@...radead.org>,
	kraxel@...esex.org, Containers@...ts.osdl.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] kthread: saa7134-tvaudio.c

Andrew Morton <akpm@...l.org> writes:

> So in general, yes, the driver should be converted to the kthread API -
> this is a requirement for virtualisation, but I forget why, and that's the
> "standard" way of doing it.

With the kthread api new kernel threads are started as children of keventd
in well defined circumstances.  If you don't do this kernel threads
can wind up sharing weird parts of a parent process's resources and
locking resources in the kernel long past the time when they are
actually used by anything a user space process can kill.

We have actually witnessed this problem with the kernels filesystem mount
namespace.  Mostly daemonize in the kernel unshares everything that
could be a problem but the problem is sufficiently subtle it makes
more sense to the change kernel threads.  So these weird and subtle
dependencies go away.

So in essence the container work needs the new kthread api for the
same reasons everyone else does it is just more pronounced in that
case.

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