[PATCH 1/4] proc: proc_get_inode should get module only once

[PATCH 1/4] proc: proc_get_inode should get module only once

[Denis V. Lunev]

Any file under /proc/net opened more than once leaked the refcounter
on the module it belongs to.

The problem is that module_get is called for each file opening while
module_put is called only when /proc inode is destroyed. So, lets put
module counter if we are dealing with already initialised inode.

Signed-off-by: Denis V. Lunev <den@openvz.org>
Cc: David Miller <davem@davemloft.net>
Cc: Patrick McHardy <kaber@trash.net>
Acked-by: Pavel Emelyanov <xemul@openvz.org>
Acked-by: Robert Olsson <robert.olsson@its.uu.se>
Acked-by: Eric W. Biederman <ebiederm@xmission.com>
---
 fs/proc/inode.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/fs/proc/inode.c b/fs/proc/inode.c
index 6f4e8dc..b08d100 100644
--- a/fs/proc/inode.c
+++ b/fs/proc/inode.c
@@ -425,7 +425,8 @@ struct inode *proc_get_inode(struct super_block *sb, unsigned int ino,
 			}
 		}
 		unlock_new_inode(inode);
-	}
+	} else
+	       module_put(de->owner);
 	return inode;
 
 out_ino:
-- 
1.5.3.rc5

[PATCH 2/4] pktgen: make sure that pktgen_thread_worker has been executed

[Denis V. Lunev]

The following courruption can happen during pktgen stop:
list_del corruption. prev->next should be ffff81007e8a5e70, but was 6b6b6b6b6b6b6b6b
kernel BUG at lib/list_debug.c:67!
      :pktgen:pktgen_thread_worker+0x374/0x10b0
      ? autoremove_wake_function+0x0/0x40
      ? _spin_unlock_irqrestore+0x42/0x80
      ? :pktgen:pktgen_thread_worker+0x0/0x10b0
      kthread+0x4d/0x80
      child_rip+0xa/0x12
      ? restore_args+0x0/0x30
      ? kthread+0x0/0x80
      ? child_rip+0x0/0x12
RIP  list_del+0x48/0x70

The problem is that pktgen_thread_worker can not be executed if kthread_stop
has been called too early. Insert a completion on the normal initialization
path to make sure that pktgen_thread_worker will gain the control for sure.

Signed-off-by: Denis V. Lunev <den@openvz.org>
Cc: Patrick McHardy <kaber@trash.net>
Cc: Robert Olsson <robert.olsson@its.uu.se>
Cc: Ben Greear <greearb@candelatech.com>
Acked-by: Alexey Dobriyan <adobriyan@openvz.org>
---
 net/core/pktgen.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 8dca211..fdf5377 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -390,6 +390,7 @@ struct pktgen_thread {
 	int cpu;
 
 	wait_queue_head_t queue;
+	struct completion start_done;
 };
 
 #define REMOVE 1
@@ -3414,6 +3415,7 @@ static int pktgen_thread_worker(void *arg)
 	BUG_ON(smp_processor_id() != cpu);
 
 	init_waitqueue_head(&t->queue);
+	complete(&t->start_done);
 
 	pr_debug("pktgen: starting pktgen/%d:  pid=%d\n", cpu, task_pid_nr(current));
 
@@ -3615,6 +3617,7 @@ static int __init pktgen_create_thread(int cpu)
 	INIT_LIST_HEAD(&t->if_list);
 
 	list_add_tail(&t->th_list, &pktgen_threads);
+	init_completion(&t->start_done);
 
 	p = kthread_create(pktgen_thread_worker, t, "kpktgend_%d", cpu);
 	if (IS_ERR(p)) {
@@ -3639,6 +3642,7 @@ static int __init pktgen_create_thread(int cpu)
 	}
 
 	wake_up_process(p);
+	wait_for_completion(&t->start_done);
 
 	return 0;
 }
-- 
1.5.3.rc5

[PATCH 2/4] pktgen: make sure that pktgen_thread_worker has been executed

[Robert Olsson]

Denis V. Lunev writes:

 > The problem is that pktgen_thread_worker can not be executed if kthread_stop
 > has been called too early. Insert a completion on the normal initialization
 > path to make sure that pktgen_thread_worker will gain the control for sure.


 Yes how about if we move the wait_for_completion() to pg_cleanup before
 we remove the threads. And move the complete() last in pktgen_thread_worker. 
 This completion would sync with both start and stop.

 Cheers.
					--ro


 > diff --git a/net/core/pktgen.c b/net/core/pktgen.c
 > index 8dca211..fdf5377 100644
 > --- a/net/core/pktgen.c
 > +++ b/net/core/pktgen.c
 > @@ -390,6 +390,7 @@ struct pktgen_thread {
 >  	int cpu;
 >  
 >  	wait_queue_head_t queue;
 > +	struct completion start_done;
 >  };
 >  
 >  #define REMOVE 1
 > @@ -3414,6 +3415,7 @@ static int pktgen_thread_worker(void *arg)
 >  	BUG_ON(smp_processor_id() != cpu);
 >  
 >  	init_waitqueue_head(&t->queue);
 > +	complete(&t->start_done);
 >  
 >  	pr_debug("pktgen: starting pktgen/%d:  pid=%d\n", cpu, task_pid_nr(current));
 >  
 > @@ -3615,6 +3617,7 @@ static int __init pktgen_create_thread(int cpu)
 >  	INIT_LIST_HEAD(&t->if_list);
 >  
 >  	list_add_tail(&t->th_list, &pktgen_threads);
 > +	init_completion(&t->start_done);
 >  
 >  	p = kthread_create(pktgen_thread_worker, t, "kpktgend_%d", cpu);
 >  	if (IS_ERR(p)) {
 > @@ -3639,6 +3642,7 @@ static int __init pktgen_create_thread(int cpu)
 >  	}
 >  
 >  	wake_up_process(p);
 > +	wait_for_completion(&t->start_done);
 >  
 >  	return 0;
 >  }
 > -- 
 > 1.5.3.rc5

Re: [PATCH 2/4] pktgen: make sure that pktgen_thread_worker has been executed

[Denis V. Lunev]

On Tue, 2008-05-20 at 20:30 +0200, Robert Olsson wrote:
> Denis V. Lunev writes:
> 
>  > The problem is that pktgen_thread_worker can not be executed if kthread_stop
>  > has been called too early. Insert a completion on the normal initialization
>  > path to make sure that pktgen_thread_worker will gain the control for sure.
> 
> 
>  Yes how about if we move the wait_for_completion() to pg_cleanup before
>  we remove the threads. And move the complete() last in pktgen_thread_worker. 
>  This completion would sync with both start and stop.
> 
>  Cheers.
> 					--ro

you can't. The idea is to have a checkpoint _before_ khread_stop.
Currently you have a race between


static int kthread(void *_create)
{
   ...
   if (!kthread_should_stop())
       pktgen_thread_worker();
   ...
}

and kthread_stop. If kthread_stop will be called _before_ the control
goes inside pktgen_thread_worker you'll OOPS.

Regards,
	Den

Re: [PATCH 2/4] pktgen: make sure that pktgen_thread_worker has been executed

[Robert Olsson]

Denis V. Lunev writes:

 > static int kthread(void *_create)
 > {
 >    ...
 >    if (!kthread_should_stop())
 >        pktgen_thread_worker();
 >    ...
 > }
 > 
 > and kthread_stop. If kthread_stop will be called _before_ the control
 > goes inside pktgen_thread_worker you'll OOPS.

 For some reason my tests survives here... but agree the completion syncing
 gives better control.

 Cheers
						--ro

Re: [PATCH 2/4] pktgen: make sure that pktgen_thread_worker has been executed

[David Miller]

From: "Denis V. Lunev" <den@openvz.org>
Date: Tue, 20 May 2008 13:59:47 +0400

> The following courruption can happen during pktgen stop:
> list_del corruption. prev->next should be ffff81007e8a5e70, but was 6b6b6b6b6b6b6b6b
> kernel BUG at lib/list_debug.c:67!
>       :pktgen:pktgen_thread_worker+0x374/0x10b0
>       ? autoremove_wake_function+0x0/0x40
>       ? _spin_unlock_irqrestore+0x42/0x80
>       ? :pktgen:pktgen_thread_worker+0x0/0x10b0
>       kthread+0x4d/0x80
>       child_rip+0xa/0x12
>       ? restore_args+0x0/0x30
>       ? kthread+0x0/0x80
>       ? child_rip+0x0/0x12
> RIP  list_del+0x48/0x70
> 
> The problem is that pktgen_thread_worker can not be executed if kthread_stop
> has been called too early. Insert a completion on the normal initialization
> path to make sure that pktgen_thread_worker will gain the control for sure.
> 
> Signed-off-by: Denis V. Lunev <den@openvz.org>
> Cc: Patrick McHardy <kaber@trash.net>
> Cc: Robert Olsson <robert.olsson@its.uu.se>
> Cc: Ben Greear <greearb@candelatech.com>
> Acked-by: Alexey Dobriyan <adobriyan@openvz.org>

Patch applied, thanks a lot Denis!

[PATCH 3/4] modules: proper cleanup of kobject without CONFIG_SYSFS

[Denis V. Lunev]

kobject: '<NULL>' (ffffffffa0104050): is not initialized, yet kobject_put() is being called.
------------[ cut here ]------------
WARNING: at /home/den/src/linux-netns26/lib/kobject.c:583 kobject_put+0x53/0x55()
Modules linked in: ipv6 nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs ide_cd_mod cdrom button [last unloaded: pktgen]
comm: rmmod Tainted: G        W 2.6.26-rc3 #585
Call Trace:
  [<ffffffff802359ab>] warn_on_slowpath+0x58/0x7a
  [<ffffffff80236aca>] ? printk+0x67/0x69
  [<ffffffff80236aca>] ? printk+0x67/0x69
  [<ffffffff80324289>] kobject_put+0x53/0x55
  [<ffffffff8025e2ee>] free_module+0x87/0xfa
  [<ffffffff8025fee5>] sys_delete_module+0x178/0x1e1
  [<ffffffff804b1e70>] ? lockdep_sys_exit_thunk+0x35/0x67
  [<ffffffff804b1dff>] ? trace_hardirqs_on_thunk+0x35/0x3a
  [<ffffffff8020c0bb>] system_call_after_swapgs+0x7b/0x80
---[ end trace 8f5aafa7f6406cf8 ]---

mod->mkobj.kobj is not initialized without CONFIG_SYSFS. Do not call
kobject_put in this case.

Signed-off-by: Denis V. Lunev <den@openvz.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Kay Sievers <kay.sievers@vrfy.org>
---
 kernel/module.c |   16 ++++++++++++++--
 1 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/kernel/module.c b/kernel/module.c
index e6daf9a..5f80478 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1337,7 +1337,19 @@ out_unreg:
 	kobject_put(&mod->mkobj.kobj);
 	return err;
 }
-#endif
+
+static void mod_sysfs_fini(struct module *mod)
+{
+	kobject_put(&mod->mkobj.kobj);
+}
+
+#else /* CONFIG_SYSFS */
+
+static void mod_sysfs_fini(struct module *mod)
+{
+}
+
+#endif /* CONFIG_SYSFS */
 
 static void mod_kobject_remove(struct module *mod)
 {
@@ -1345,7 +1357,7 @@ static void mod_kobject_remove(struct module *mod)
 	module_param_sysfs_remove(mod);
 	kobject_put(mod->mkobj.drivers_dir);
 	kobject_put(mod->holders_dir);
-	kobject_put(&mod->mkobj.kobj);
+	mod_sysfs_fini(mod);
 }
 
 /*
-- 
1.5.3.rc5

Re: [PATCH 3/4] modules: proper cleanup of kobject without CONFIG_SYSFS

[Rusty Russell]

On Tuesday 20 May 2008 19:59:48 Denis V. Lunev wrote:
> kobject: '<NULL>' (ffffffffa0104050): is not initialized, yet kobject_put()

Thanks Denis.

This patch masks a deeper problem; looks like you can't load any modules with 
CONFIG_SYSFS=n:

kernel/module.c:
int mod_sysfs_init(struct module *mod)
{
	int err;
	struct kobject *kobj;

	if (!module_sysfs_initialized) {
		printk(KERN_ERR "%s: module sysfs not initialized\n",
		       mod->name);
		err = -EINVAL;
		goto out;
	}

AFAICT, module_sysfs_initialized is not ever set if !CONFIG_SYSFS.

I can't see the point of module_sysfs_initialized.  It was introduced by Greg 
in commit 823bccfc ("remove "struct subsystem" as it is no longer needed").

Greg, what were you trying to do here?  Modules can't be loaded before 
param_sysfs_init(): are you trying to handle the case where the 
kset_create_and_add() fails?

Thanks,
Rusty.

Re: [PATCH 3/4] modules: proper cleanup of kobject without CONFIG_SYSFS

[Denis V. Lunev]

On Thu, 2008-05-22 at 19:20 +1000, Rusty Russell wrote:
> On Tuesday 20 May 2008 19:59:48 Denis V. Lunev wrote:
> > kobject: '<NULL>' (ffffffffa0104050): is not initialized, yet kobject_put()
> 
> Thanks Denis.
> 
> This patch masks a deeper problem; looks like you can't load any modules with 
> CONFIG_SYSFS=n:
> 
> kernel/module.c:
> int mod_sysfs_init(struct module *mod)
> {
> 	int err;
> 	struct kobject *kobj;
> 
> 	if (!module_sysfs_initialized) {
> 		printk(KERN_ERR "%s: module sysfs not initialized\n",
> 		       mod->name);
> 		err = -EINVAL;
> 		goto out;
> 	}
> 
> AFAICT, module_sysfs_initialized is not ever set if !CONFIG_SYSFS.
> 
> I can't see the point of module_sysfs_initialized.  It was introduced by Greg 
> in commit 823bccfc ("remove "struct subsystem" as it is no longer needed").
> 
> Greg, what were you trying to do here?  Modules can't be loaded before 
> param_sysfs_init(): are you trying to handle the case where the 
> kset_create_and_add() fails?

Basically you miss
static inline int mod_sysfs_init(struct module *mod)
{
        return 0;
}
in include/linux/module.h

So, without CONFIG_SYSFS a dummy stab for mod_sysfs_init is called.

Regards,
	Den

Re: [PATCH 3/4] modules: proper cleanup of kobject without CONFIG_SYSFS

[Rusty Russell]

On Thursday 22 May 2008 21:44:21 Denis V. Lunev wrote:
> On Thu, 2008-05-22 at 19:20 +1000, Rusty Russell wrote:
> > On Tuesday 20 May 2008 19:59:48 Denis V. Lunev wrote:
> > > kobject: '<NULL>' (ffffffffa0104050): is not initialized, yet
> > > kobject_put()
> >
> > AFAICT, module_sysfs_initialized is not ever set if !CONFIG_SYSFS.
> >
>
> Basically you miss
> static inline int mod_sysfs_init(struct module *mod)
> {
>         return 0;
> }
> in include/linux/module.h
>
> So, without CONFIG_SYSFS a dummy stab for mod_sysfs_init is called.

Ah, thanks for the explanation.

Basically, this code is a dog's breakfast.  There's no reason for this to be 
in the header, and no reason for the other mod_sysfs_init() not to be static.  
Ditto for most of the rest.

Patch applied, thanks!
Rusty.

Re: [PATCH 3/4] modules: proper cleanup of kobject without CONFIG_SYSFS

[Greg KH]

On Thu, May 22, 2008 at 07:20:22PM +1000, Rusty Russell wrote:
> On Tuesday 20 May 2008 19:59:48 Denis V. Lunev wrote:
> > kobject: '<NULL>' (ffffffffa0104050): is not initialized, yet kobject_put()
> 
> Thanks Denis.
> 
> This patch masks a deeper problem; looks like you can't load any modules with 
> CONFIG_SYSFS=n:
> 
> kernel/module.c:
> int mod_sysfs_init(struct module *mod)
> {
> 	int err;
> 	struct kobject *kobj;
> 
> 	if (!module_sysfs_initialized) {
> 		printk(KERN_ERR "%s: module sysfs not initialized\n",
> 		       mod->name);
> 		err = -EINVAL;
> 		goto out;
> 	}
> 
> AFAICT, module_sysfs_initialized is not ever set if !CONFIG_SYSFS.
> 
> I can't see the point of module_sysfs_initialized.  It was introduced by Greg 
> in commit 823bccfc ("remove "struct subsystem" as it is no longer needed").
> 
> Greg, what were you trying to do here?  Modules can't be loaded before 
> param_sysfs_init(): are you trying to handle the case where the 
> kset_create_and_add() fails?

Yes.  Previously you were never detecting that if the subsystem was not
properly created (for whatever reason), we could fail horribly when
trying to load a module.

Now we at least detect that problem, is is causing an issue somehow?  I
think you have now seen that we can load modules with CONFIG_SYSFS=n,
otherwise people would have complained by now (not that anyone actually
runs that kind of configuration that I know of...)

thanks,

greg k-h

Re: [PATCH 3/4] modules: proper cleanup of kobject without CONFIG_SYSFS

[Rusty Russell]

On Friday 23 May 2008 03:54:15 Greg KH wrote:
> On Thu, May 22, 2008 at 07:20:22PM +1000, Rusty Russell wrote:
> > On Tuesday 20 May 2008 19:59:48 Denis V. Lunev wrote:
> > > kobject: '<NULL>' (ffffffffa0104050): is not initialized, yet
> > > kobject_put()
> >
> > Thanks Denis.
> >
> > This patch masks a deeper problem; looks like you can't load any modules
> > with CONFIG_SYSFS=n:
> >
> > kernel/module.c:
> > int mod_sysfs_init(struct module *mod)
> > {
> > 	int err;
> > 	struct kobject *kobj;
> >
> > 	if (!module_sysfs_initialized) {
> > 		printk(KERN_ERR "%s: module sysfs not initialized\n",
> > 		       mod->name);
> > 		err = -EINVAL;
> > 		goto out;
> > 	}
> >
> > AFAICT, module_sysfs_initialized is not ever set if !CONFIG_SYSFS.
> >
> > I can't see the point of module_sysfs_initialized.  It was introduced by
> > Greg in commit 823bccfc ("remove "struct subsystem" as it is no longer
> > needed").
> >
> > Greg, what were you trying to do here?  Modules can't be loaded before
> > param_sysfs_init(): are you trying to handle the case where the
> > kset_create_and_add() fails?
>
> Yes.  Previously you were never detecting that if the subsystem was not
> properly created (for whatever reason), we could fail horribly when
> trying to load a module.

Well, my policy is to crash when allocations fail during boot, rather than 
traversing untested code paths.  But since that code already exists, I'm not 
religious enough to argue about it; just wanted to see if there was some 
subtlety I was missing.

> Now we at least detect that problem, is is causing an issue somehow?  I
> think you have now seen that we can load modules with CONFIG_SYSFS=n,
> otherwise people would have complained by now (not that anyone actually
> runs that kind of configuration that I know of...)

Yes, thanks.  But it seems noone has removed a module in such a config since 
April 2007.

The module/sysfs code is messy though: we do most sysfs stuff only under 
CONFIG_SYSFS, which seems overkill since at a glance it should just neatly do 
nothing.  Do you have the cycles and inclination to take a look at it?

Thanks,
Rusty.

[PATCH 4/4] flock: remove unused fields from file_lock_operations

[Denis V. Lunev]

fl_insert and fl_remove are not used right now in the kernel. Remove them.

Signed-off-by: Denis V. Lunev <den@openvz.org>
Cc: Matthew Wilcox <matthew@wil.cx>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>
---
 fs/locks.c         |    6 ------
 include/linux/fs.h |    2 --
 2 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/fs/locks.c b/fs/locks.c
index 11dbf08..dce8c74 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -561,9 +561,6 @@ static void locks_insert_lock(struct file_lock **pos, struct file_lock *fl)
 	/* insert into file's list */
 	fl->fl_next = *pos;
 	*pos = fl;
-
-	if (fl->fl_ops && fl->fl_ops->fl_insert)
-		fl->fl_ops->fl_insert(fl);
 }
 
 /*
@@ -586,9 +583,6 @@ static void locks_delete_lock(struct file_lock **thisfl_p)
 		fl->fl_fasync = NULL;
 	}
 
-	if (fl->fl_ops && fl->fl_ops->fl_remove)
-		fl->fl_ops->fl_remove(fl);
-
 	if (fl->fl_nspid) {
 		put_pid(fl->fl_nspid);
 		fl->fl_nspid = NULL;
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 9bb4ffd..13fb854 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -901,8 +901,6 @@ static inline int file_check_writeable(struct file *filp)
 typedef struct files_struct *fl_owner_t;
 
 struct file_lock_operations {
-	void (*fl_insert)(struct file_lock *);	/* lock insertion callback */
-	void (*fl_remove)(struct file_lock *);	/* lock removal callback */
 	void (*fl_copy_lock)(struct file_lock *, struct file_lock *);
 	void (*fl_release_private)(struct file_lock *);
 };
-- 
1.5.3.rc5