linux-kernel - Re: [PATCH] export kernel call get_task

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1303513182.13457.134.camel@localhost>
Date:	Fri, 22 Apr 2011 15:59:42 -0700
From:	J Freyensee <james_p_freyensee@...ux.intel.com>
To:	Greg KH <gregkh@...e.de>
Cc:	akpm@...ux-foundation.org, rientjes@...gle.com,
	linux-kernel@...r.kernel.org, suhail.ahmed@...el.com,
	christophe.guerard@...el.com
Subject: Re: [PATCH] export kernel call get_task_comm().

On Fri, 2011-04-22 at 15:43 -0700, Greg KH wrote:
> On Fri, Apr 22, 2011 at 03:35:44PM -0700, james_p_freyensee@...ux.intel.com wrote:
> > From: J Freyensee <james_p_freyensee@...ux.intel.com>
> > 
> > This allows drivers who call this function to be compiled modularly.
> > Otherwise, a driver who is interested in this type of functionality
> > has to implement their own get_task_comm() call, causing code
> > duplication in the Linux source tree.
> > 
> > Signed-off-by: J Freyensee <james_p_freyensee@...ux.intel.com>
> 
> I think the goal is for the cleanup to happen now, to justify the
> addition of the exported symbol.  Without that, there is no need to
> export the symbol now at all, as who knows when your driver will be
> accepted.
> 
> Or, just wait and make it part of your driver patch series, like you did
> before, no need to get it accepted now, right?
>

Well, at some point a few people like Alan Cox and Arjan VdV would like
to see this work on it's way to Linus's tree.

I'll do whatever is best and easiest for you and will bring a close to
my submission attempts.  I can also just go into the Kconfig where the
pti driver is configured and just make the selection bool, yes or no,
and not make it an option to compile this modularly.  Then I'll drop
this patch all together.  This is the whole reason why I'm making this
change.  I don't have to have the pti driver as a module, just more
convenient.  And within the fs/exec.c it states reads to 'current->comm'
without a lock is safe.

> thanks,
> 
> greg k-h


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