On Wed 26-06-13 02:29:40, Glauber Costa wrote: > When removing an element from the lru, this will be done today after the lock > is released. This is a clear mistake, although we are not sure if the bugs we > are seeing are related to this. All list manipulations are done inside the > lock, and so should this one. > > Signed-off-by: Glauber Costa <glommer@xxxxxxxxxx> Yes this fixed BUG_ONs triggered during my testing (e.g. BUG at mm/list_lru.c:92) Tested-by: Michal Hocko <mhocko@xxxxxxx> > --- > fs/inode.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/inode.c b/fs/inode.c > index a2b49c8..e315c0a 100644 > --- a/fs/inode.c > +++ b/fs/inode.c > @@ -735,9 +735,9 @@ inode_lru_isolate(struct list_head *item, spinlock_t *lru_lock, void *arg) > > WARN_ON(inode->i_state & I_NEW); > inode->i_state |= I_FREEING; > + list_move(&inode->i_lru, freeable); > spin_unlock(&inode->i_lock); > > - list_move(&inode->i_lru, freeable); > this_cpu_dec(nr_unused); > return LRU_REMOVED; > } > -- > 1.8.2.1 > -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>