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: <a781481a0704210911g5921d3fdm8e0983d7d36535b3@mail.gmail.com>
Date:	Sat, 21 Apr 2007 21:41:28 +0530
From:	"Satyam Sharma" <satyam.sharma@...il.com>
To:	"Cedric Le Goater" <clg@...ibm.com>
Cc:	devel@...nvz.org, "Eric W. Biederman" <ebiederm@...ssion.com>,
	Christoph@...p2.linux-foundation.org,
	Holtmann <marcel@...tmann.org>, linux-kernel@...r.kernel.org,
	Hellwig <hch@...radead.org>, containers@...ts.osdl.org,
	Marcel@...p2.linux-foundation.org,
	"Oleg Nesterov" <oleg@...sign.ru>
Subject: Re: [Devel] Re: [PATCH] bluetooth bnep: Convert to kthread API.

Hello,

On 4/20/07, Cedric Le Goater <clg@...ibm.com> wrote:
> Cedric Le Goater wrote:
> > Andrew Morton wrote:
> >> On Thu, 19 Apr 2007 01:58:51 -0600
> >> "Eric W. Biederman" <ebiederm@...ssion.com> wrote:
> >>>
> >>>
> >>> +   task = kthread_run(bnep_session, s, "kbnepd %s", dev->name);
> >> It's unusual to have a kernel thread which has a space in its name.  That
> >> could trip up infufficient-defensive userspace tools.

But all kernel threads are supposed to be only *in-kernel*
implementation details. Isn't a userspace tool whose behaviour relies
on the existence (or even the knowledge of the existence) of any
kernel thread *broken by design*?

> > but we can't just change it, can we ? i could be used by a user space tool
> > to check if the thread is running.

Yes, so although userspace shouldn't be bothering with kernel threads
in the first place, that does not mean that such tools do not exist.
So we'll have to live with this (unfortunate) naming for some time,
till we can get rid of it later.

Which is similar to the habit of some kernel threads in there that
actually *do* want to export the knowledge of their existence (and
even a signals-based interface!) to userspace. Eric did receive some
nacks on his patches that tried to remove the signals business from
kernel threads on this account, but perhaps that too is something that
we could get rid of later (hopefully by that time those using signals
in kernel threads would have realized their folly and shifted to
something else :-)

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