On Tue, 20 Nov 2012, [email protected] wrote: > > This is a note to let you know that I've just added the patch titled > > tmpfs: change final i_blocks BUG to WARNING > > to the 3.0-stable tree which can be found at: > > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary > > The filename of the patch is: > tmpfs-change-final-i_blocks-bug-to-warning.patch > and it can be found in the queue-3.0 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <[email protected]> know about it.
Thank you for your diligence! But I'll say that this one should not go into 3.0-stable. Whilst there is an argument that this BUG_ON is like many moronic, 3.0-stable is not the place for working on that agenda. The particular condition which makes this BUG_ON triggerable in 3.1 onwards cannot happen in 3.0 or before, because they have a lock spanning the window at both ends of the race, which prevents it. Hugh > > > From 0f3c42f522dc1ad7e27affc0a4aa8c790bce0a66 Mon Sep 17 00:00:00 2001 > From: Hugh Dickins <[email protected]> > Date: Fri, 16 Nov 2012 14:15:04 -0800 > Subject: tmpfs: change final i_blocks BUG to WARNING > Status: RO > Content-Length: 1912 > Lines: 45 > > From: Hugh Dickins <[email protected]> > > commit 0f3c42f522dc1ad7e27affc0a4aa8c790bce0a66 upstream. > > Under a particular load on one machine, I have hit shmem_evict_inode()'s > BUG_ON(inode->i_blocks), enough times to narrow it down to a particular > race between swapout and eviction. > > It comes from the "if (freed > 0)" asymmetry in shmem_recalc_inode(), > and the lack of coherent locking between mapping's nrpages and shmem's > swapped count. There's a window in shmem_writepage(), between lowering > nrpages in shmem_delete_from_page_cache() and then raising swapped > count, when the freed count appears to be +1 when it should be 0, and > then the asymmetry stops it from being corrected with -1 before hitting > the BUG. > > One answer is coherent locking: using tree_lock throughout, without > info->lock; reasonable, but the raw_spin_lock in percpu_counter_add() on > used_blocks makes that messier than expected. Another answer may be a > further effort to eliminate the weird shmem_recalc_inode() altogether, > but previous attempts at that failed. > > So far undecided, but for now change the BUG_ON to WARN_ON: in usual > circumstances it remains a useful consistency check. > > Signed-off-by: Hugh Dickins <[email protected]> > Signed-off-by: Andrew Morton <[email protected]> > Signed-off-by: Linus Torvalds <[email protected]> > Signed-off-by: Greg Kroah-Hartman <[email protected]> > > > --- > mm/shmem.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- a/mm/shmem.c > +++ b/mm/shmem.c > @@ -848,7 +848,7 @@ static void shmem_evict_inode(struct ino > kfree(xattr->name); > kfree(xattr); > } > - BUG_ON(inode->i_blocks); > + WARN_ON(inode->i_blocks); > shmem_free_inode(inode->i_sb); > end_writeback(inode); > } > > > Patches currently in stable-queue which might be from [email protected] are > > queue-3.0/tmpfs-change-final-i_blocks-bug-to-warning.patch -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
