[PATCH] deprecate the tasklist_lock export

[PATCH] deprecate the tasklist_lock export

[Christoph Hellwig]

Drivers have no business looking at the task list and thus using this
lock.  The only possibly modular users left are:

 arch/ia64/kernel/mca.c
 drivers/edac/edac_mc.c
 fs/binfmt_elf.c

which I'll send out fixes for soon.


Signed-off-by: Christoph Hellwig <hch@lst.de>

Index: linux-2.6/Documentation/feature-removal-schedule.txt
===================================================================
--- linux-2.6.orig/Documentation/feature-removal-schedule.txt	2006-02-15 14:03:37.000000000 +0100
+++ linux-2.6/Documentation/feature-removal-schedule.txt	2006-02-15 14:05:37.000000000 +0100
@@ -182,3 +182,14 @@
 	implementation details and provides a higherlevel interface that
 	prevents bugs and code duplication
 Who:	Christoph Hellwig <hch@lst.de>
+
+---------------------------
+
+What:	remove EXPORT_SYMBOL(tasklist_lock)
+When:	August 2006
+Files:	kernel/fork.c
+Why:	tasklist_lock protects the kernel internal task list.  Modules have
+	no business looking at it, and all instances in drivers have been due
+	to use of too-lowlevel APIs.  Having this symbol exported prevents
+	moving to more scalable locking schemes for the task list.
+Who:	Christoph Hellwig <hch@lst.de>

Re: [PATCH] deprecate the tasklist_lock export

[Steven Rostedt]

On Wed, 15 Feb 2006, Christoph Hellwig wrote:

> Drivers have no business looking at the task list and thus using this
> lock.  The only possibly modular users left are:
>
>  arch/ia64/kernel/mca.c
>  drivers/edac/edac_mc.c
>  fs/binfmt_elf.c
>
> which I'll send out fixes for soon.
>

Hmm, I have some debug modules that do use that lock.  Is it possible to
export it only if CONFIG_DEBUG_KERNEL?  If this isn't proper either, it's
no big deal. I'll just make a patch that exports it, and add it to my
kernel before debugging.  I'm just asking to make my life more convenient
:-)

-- Steve

Re: [PATCH] deprecate the tasklist_lock export

[Christoph Hellwig]

On Wed, Feb 15, 2006 at 09:09:36AM -0500, Steven Rostedt wrote:
> Hmm, I have some debug modules that do use that lock.  Is it possible to
> export it only if CONFIG_DEBUG_KERNEL?

That doesn't make a whole lot of sense.  What's your debug module doing?
Should we just put it in the tree as builtin-code under a debug option?

Re: [PATCH] deprecate the tasklist_lock export

[Steven Rostedt]

On Fri, 17 Feb 2006, Christoph Hellwig wrote:

> On Wed, Feb 15, 2006 at 09:09:36AM -0500, Steven Rostedt wrote:
> > Hmm, I have some debug modules that do use that lock.  Is it possible to
> > export it only if CONFIG_DEBUG_KERNEL?
>
> That doesn't make a whole lot of sense.  What's your debug module doing?
> Should we just put it in the tree as builtin-code under a debug option?
>

Nah, It's not worth it.  I have some mutex test modules that search the
tasks to determine what priorities are there and uses that info for
setting the priorities of the threads it creates. Yes, this can be done
from userland as well, but i was being lazy and just wrote eveything in
the module.

So, forget what I asked for and do what you want.  These modules are
really just for testing specific things that I work on and I can find
other ways around it.  Really the easiest thing is to just add the EXPORT
myself since I need to recompile the kernel anyways.

Thanks anyway,

-- Steve

Re: [PATCH] deprecate the tasklist_lock export

[Adrian Bunk]

On Wed, Feb 15, 2006 at 02:07:34PM +0100, Christoph Hellwig wrote:
> Drivers have no business looking at the task list and thus using this
> lock.  The only possibly modular users left are:
> 
>  arch/ia64/kernel/mca.c
>...
>  fs/binfmt_elf.c
> 
> which I'll send out fixes for soon.
>...

These two can't be built modular.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH] deprecate the tasklist_lock export

[Christoph Hellwig]

On Wed, Feb 15, 2006 at 10:48:33PM +0100, Adrian Bunk wrote:
> On Wed, Feb 15, 2006 at 02:07:34PM +0100, Christoph Hellwig wrote:
> > Drivers have no business looking at the task list and thus using this
> > lock.  The only possibly modular users left are:
> > 
> >  arch/ia64/kernel/mca.c
> >...
> >  fs/binfmt_elf.c
> > 
> > which I'll send out fixes for soon.
> >...
> 
> These two can't be built modular.

s390 and sparc64 allows a modular BINFMT_ELF32, which #includes
fs/binfmt_elf.c after redefining various things.  But I suspect the
right fix for this is to disallow building it modular..

For arch/ia64/kernel/mca.c you're right.  Other mca files can be built
modular and need odd symbols aswell, but mca.c is always built in.

Re: [PATCH] deprecate the tasklist_lock export

[Adrian Bunk]

On Fri, Feb 17, 2006 at 12:23:55PM +0100, Christoph Hellwig wrote:
> On Wed, Feb 15, 2006 at 10:48:33PM +0100, Adrian Bunk wrote:
> > On Wed, Feb 15, 2006 at 02:07:34PM +0100, Christoph Hellwig wrote:
> > > Drivers have no business looking at the task list and thus using this
> > > lock.  The only possibly modular users left are:
> > > 
> > >  arch/ia64/kernel/mca.c
> > >...
> > >  fs/binfmt_elf.c
> > > 
> > > which I'll send out fixes for soon.
> > >...
> > 
> > These two can't be built modular.
> 
> s390 and sparc64 allows a modular BINFMT_ELF32, which #includes
> fs/binfmt_elf.c after redefining various things.  But I suspect the
> right fix for this is to disallow building it modular..
>...

Argh, I hate code #include'ing .c files.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH] deprecate the tasklist_lock export

[Olaf Titz]

In article <20060215130734.GA5590@lst.de> you write:
> Drivers have no business looking at the task list and thus using this
> lock.  The only possibly modular users left are:

CIPE is a driver which consists of a kernel module and a userspace
program, where each one of possibly many kernel devices is associated
with exactly one userspace process, and it uses the task list to keep
track of these associations. Is there a recommended other way to
handle such a situation?

Olaf