public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* decrement of inodes_stat.nr_inodes in inode.c not SMP safe?
@ 2002-11-20  5:07 Rebecca.Callan
  2002-11-20  5:42 ` Andrew Morton
  0 siblings, 1 reply; 2+ messages in thread
From: Rebecca.Callan @ 2002-11-20  5:07 UTC (permalink / raw)
  To: linux-kernel

The value for nr_inodes in /proc/sys/fs/inode-state appears to be wrong.

I think this is probably a bug in all 2.4 smp kernels. I've seen it in
2.4.8-26mdksmp and 2.4.18-3smp.

I first noticed the bug when sar -v reported inode-sz to be 4294966776. 
I check the sar source code and the documentation and found the value 
of nr_free_inodes (second value in the /proc/sys/fs/inode-state file) is
larger than nr_inodes (the number of allocated inodes - first value in
file). 

I think I have tracked the bug down to an unsafe decrement of 
inodes_stat.nr_inodes in fs/inode.c. This variable is changed in a 
number of places in inode.c and it is locked everywhere except in 
dispose_list(). The comment above dispose_list says:
	 
 * Dispose-list gets a local list with local inodes in it, so it doesn't
 * need to worry about list corruption and SMP locks. 

But inodes_stat.nr_inodes is not local and I think it requires locking.

I am not a kernel developer and don't know exactly how to fix this problem.
I suppose there is a reason why the dispose_list function was designed to 
not use locking so I guess it's not a good idea to put a lock in there. The
only other option I can think of is to use atomic decrement, but I don't
know whether it is safe to atomicaly decrement something that is decremented

elsewhere using locking not an atomic decrement. Is it a good idea to change

all accesses  of this variable to atomic? Would this add unnecessary
overhead? 

Thanks,
Rebecca


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: decrement of inodes_stat.nr_inodes in inode.c not SMP safe?
  2002-11-20  5:07 decrement of inodes_stat.nr_inodes in inode.c not SMP safe? Rebecca.Callan
@ 2002-11-20  5:42 ` Andrew Morton
  0 siblings, 0 replies; 2+ messages in thread
From: Andrew Morton @ 2002-11-20  5:42 UTC (permalink / raw)
  To: Rebecca.Callan; +Cc: linux-kernel

Rebecca.Callan@ir.com wrote:
> 
> The value for nr_inodes in /proc/sys/fs/inode-state appears to be wrong.
> 
> I think this is probably a bug in all 2.4 smp kernels. I've seen it in
> 2.4.8-26mdksmp and 2.4.18-3smp.
> 

Is true.  The 2.5 change needs to be backported.


--- linux-akpm/fs/inode.c~inodes_stat-race	Tue Nov 19 21:42:08 2002
+++ linux-akpm-akpm/fs/inode.c	Tue Nov 19 21:42:23 2002
@@ -532,22 +532,25 @@ void clear_inode(struct inode *inode)
  * Dispose-list gets a local list with local inodes in it, so it doesn't
  * need to worry about list corruption and SMP locks.
  */
-static void dispose_list(struct list_head * head)
+static void dispose_list(struct list_head *head)
 {
-	struct list_head * inode_entry;
-	struct inode * inode;
+	int nr_disposed = 0;
 
-	while ((inode_entry = head->next) != head)
-	{
-		list_del(inode_entry);
+	while (!list_empty(head)) {
+		struct inode *inode;
+
+		inode = list_entry(head->next, struct inode, i_list);
+		list_del(&inode->i_list);
 
-		inode = list_entry(inode_entry, struct inode, i_list);
 		if (inode->i_data.nrpages)
 			truncate_inode_pages(&inode->i_data, 0);
 		clear_inode(inode);
 		destroy_inode(inode);
-		inodes_stat.nr_inodes--;
+		nr_disposed++;
 	}
+	spin_lock(&inode_lock);
+	inodes_stat.nr_inodes -= nr_disposed;
+	spin_unlock(&inode_lock);
 }
 
 /*

_

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2002-11-20  5:35 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-11-20  5:07 decrement of inodes_stat.nr_inodes in inode.c not SMP safe? Rebecca.Callan
2002-11-20  5:42 ` Andrew Morton

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox