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:	Tue, 8 Feb 2011 12:35:35 -0800 (PST)
From:	james_p_freyensee@...ux.intel.com
To:	"Christoph Hellwig" <hch@...radead.org>
Cc:	james_p_freyensee@...ux.intel.com,
	"Christoph Hellwig" <hch@...radead.org>, gregkh@...e.de,
	linux-kernel@...r.kernel.org, suhail.ahmed@...el.com
Subject: Re: [PATCH 01/12] export kernel call get_task_comm()

> On Tue, Feb 08, 2011 at 11:44:16AM -0800,
> james_p_freyensee@...ux.intel.com wrote:
>> That is originally what I did, but after talking with Greg KH, Arjan
>> vdv,
>> and Alan Cox I made this patch instead.
>
> Care to explain why exactly?
>
>

If I can jog my own memory as this was a while ago...

Well for starters, Arjan van de Ven first suggested it, and I trust his
judgement because of his Linux kernel experience.

But looking at the code, the kernel function get_task_comm() provides a
level of safety with a lock, so the global resource 'current' can be used
without someone else trying to use it at the same time.  And using this
function facilitates code reuse which is something Greg KH was trying to
point out to me at the time:

http://lists.meego.com/pipermail/meego-kernel/2010-October/000823.html

In fact, I remember finding existing, accepted drivers in the kernel that
wrote their own locks before accessing current (I quickly just now found
block/dfdb/drbd_main.c as an example), so Greg is making a valid point
about code reuse.  So not exporting get_task_comm() encourages code
locking re-write of every driver that wants to access 'current'.

In that email, Greg clearly reminded me my goal is to get my work into the
kernel.  Thus, I listened to their advice and made this patch.
--
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