From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
stable@vger.kernel.org, hujianyang <hujianyang@huawei.com>,
Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Subject: [PATCH 3.4 06/19] UBIFS: Remove incorrect assertion in shrink_tnc()
Date: Fri, 4 Jul 2014 15:15:16 -0700 [thread overview]
Message-ID: <20140704221436.733842392@linuxfoundation.org> (raw)
In-Reply-To: <20140704221436.423715636@linuxfoundation.org>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: hujianyang <hujianyang@huawei.com>
commit 72abc8f4b4e8574318189886de627a2bfe6cd0da upstream.
I hit the same assert failed as Dolev Raviv reported in Kernel v3.10
shows like this:
[ 9641.164028] UBIFS assert failed in shrink_tnc at 131 (pid 13297)
[ 9641.234078] CPU: 1 PID: 13297 Comm: mmap.test Tainted: G O 3.10.40 #1
[ 9641.234116] [<c0011a6c>] (unwind_backtrace+0x0/0x12c) from [<c000d0b0>] (show_stack+0x20/0x24)
[ 9641.234137] [<c000d0b0>] (show_stack+0x20/0x24) from [<c0311134>] (dump_stack+0x20/0x28)
[ 9641.234188] [<c0311134>] (dump_stack+0x20/0x28) from [<bf22425c>] (shrink_tnc_trees+0x25c/0x350 [ubifs])
[ 9641.234265] [<bf22425c>] (shrink_tnc_trees+0x25c/0x350 [ubifs]) from [<bf2245ac>] (ubifs_shrinker+0x25c/0x310 [ubifs])
[ 9641.234307] [<bf2245ac>] (ubifs_shrinker+0x25c/0x310 [ubifs]) from [<c00cdad8>] (shrink_slab+0x1d4/0x2f8)
[ 9641.234327] [<c00cdad8>] (shrink_slab+0x1d4/0x2f8) from [<c00d03d0>] (do_try_to_free_pages+0x300/0x544)
[ 9641.234344] [<c00d03d0>] (do_try_to_free_pages+0x300/0x544) from [<c00d0a44>] (try_to_free_pages+0x2d0/0x398)
[ 9641.234363] [<c00d0a44>] (try_to_free_pages+0x2d0/0x398) from [<c00c6a60>] (__alloc_pages_nodemask+0x494/0x7e8)
[ 9641.234382] [<c00c6a60>] (__alloc_pages_nodemask+0x494/0x7e8) from [<c00f62d8>] (new_slab+0x78/0x238)
[ 9641.234400] [<c00f62d8>] (new_slab+0x78/0x238) from [<c031081c>] (__slab_alloc.constprop.42+0x1a4/0x50c)
[ 9641.234419] [<c031081c>] (__slab_alloc.constprop.42+0x1a4/0x50c) from [<c00f80e8>] (kmem_cache_alloc_trace+0x54/0x188)
[ 9641.234459] [<c00f80e8>] (kmem_cache_alloc_trace+0x54/0x188) from [<bf227908>] (do_readpage+0x168/0x468 [ubifs])
[ 9641.234553] [<bf227908>] (do_readpage+0x168/0x468 [ubifs]) from [<bf2296a0>] (ubifs_readpage+0x424/0x464 [ubifs])
[ 9641.234606] [<bf2296a0>] (ubifs_readpage+0x424/0x464 [ubifs]) from [<c00c17c0>] (filemap_fault+0x304/0x418)
[ 9641.234638] [<c00c17c0>] (filemap_fault+0x304/0x418) from [<c00de694>] (__do_fault+0xd4/0x530)
[ 9641.234665] [<c00de694>] (__do_fault+0xd4/0x530) from [<c00e10c0>] (handle_pte_fault+0x480/0xf54)
[ 9641.234690] [<c00e10c0>] (handle_pte_fault+0x480/0xf54) from [<c00e2bf8>] (handle_mm_fault+0x140/0x184)
[ 9641.234716] [<c00e2bf8>] (handle_mm_fault+0x140/0x184) from [<c0316688>] (do_page_fault+0x150/0x3ac)
[ 9641.234737] [<c0316688>] (do_page_fault+0x150/0x3ac) from [<c000842c>] (do_DataAbort+0x3c/0xa0)
[ 9641.234759] [<c000842c>] (do_DataAbort+0x3c/0xa0) from [<c0314e38>] (__dabt_usr+0x38/0x40)
After analyzing the code, I found a condition that may cause this failed
in correct operations. Thus, I think this assertion is wrong and should be
removed.
Suppose there are two clean znodes and one dirty znode in TNC. So the
per-filesystem atomic_t @clean_zn_cnt is (2). If commit start, dirty_znode
is set to COW_ZNODE in get_znodes_to_commit() in case of potentially ops
on this znode. We clear COW bit and DIRTY bit in write_index() without
@tnc_mutex locked. We don't increase @clean_zn_cnt in this place. As the
comments in write_index() shows, if another process hold @tnc_mutex and
dirty this znode after we clean it, @clean_zn_cnt would be decreased to (1).
We will increase @clean_zn_cnt to (2) with @tnc_mutex locked in
free_obsolete_znodes() to keep it right.
If shrink_tnc() performs between decrease and increase, it will release
other 2 clean znodes it holds and found @clean_zn_cnt is less than zero
(1 - 2 = -1), then hit the assertion. Because free_obsolete_znodes() will
soon correct @clean_zn_cnt and no harm to fs in this case, I think this
assertion could be removed.
2 clean zondes and 1 dirty znode, @clean_zn_cnt == 2
Thread A (commit) Thread B (write or others) Thread C (shrinker)
->write_index
->clear_bit(DIRTY_NODE)
->clear_bit(COW_ZNODE)
@clean_zn_cnt == 2
->mutex_locked(&tnc_mutex)
->dirty_cow_znode
->!ubifs_zn_cow(znode)
->!test_and_set_bit(DIRTY_NODE)
->atomic_dec(&clean_zn_cnt)
->mutex_unlocked(&tnc_mutex)
@clean_zn_cnt == 1
->mutex_locked(&tnc_mutex)
->shrink_tnc
->destroy_tnc_subtree
->atomic_sub(&clean_zn_cnt, 2)
->ubifs_assert <- hit
->mutex_unlocked(&tnc_mutex)
@clean_zn_cnt == -1
->mutex_lock(&tnc_mutex)
->free_obsolete_znodes
->atomic_inc(&clean_zn_cnt)
->mutux_unlock(&tnc_mutex)
@clean_zn_cnt == 0 (correct after shrink)
Signed-off-by: hujianyang <hujianyang@huawei.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ubifs/shrinker.c | 1 -
1 file changed, 1 deletion(-)
--- a/fs/ubifs/shrinker.c
+++ b/fs/ubifs/shrinker.c
@@ -128,7 +128,6 @@ static int shrink_tnc(struct ubifs_info
freed = ubifs_destroy_tnc_subtree(znode);
atomic_long_sub(freed, &ubifs_clean_zn_cnt);
atomic_long_sub(freed, &c->clean_zn_cnt);
- ubifs_assert(atomic_long_read(&c->clean_zn_cnt) >= 0);
total_freed += freed;
znode = zprev;
}
next prev parent reply other threads:[~2014-07-04 22:17 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-04 22:15 [PATCH 3.4 00/19] 3.4.97-stable review Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 01/19] Input: elantech - deal with clickpads reporting right button events Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 02/19] PCI: Add new ID for Intel GPU "spurious interrupt" quirk Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 03/19] PCI: Fix incorrect vgaarb conditional in WARN_ON() Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 04/19] recordmcount/MIPS: Fix possible incorrect mcount_loc table entries in modules Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 05/19] MIPS: MSC: Prevent out-of-bounds writes to MIPS SC ioremapd region Greg Kroah-Hartman
2014-07-04 22:15 ` Greg Kroah-Hartman [this message]
2014-07-04 22:15 ` [PATCH 3.4 07/19] watchdog: sp805: Set watchdog_device->timeout from ->set_timeout() Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 08/19] IB/qib: Fix port in pkey change event Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 09/19] IB/ipath: Translate legacy diagpkt into newer extended diagpkt Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 10/19] IB/srp: Fix a sporadic crash triggered by cable pulling Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 11/19] IB/umad: Fix error handling Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 12/19] IB/umad: Fix use-after-free on close Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 13/19] nfsd4: fix FREE_STATEID lockowner leak Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 14/19] nfsd: getattr for FATTR4_WORD0_FILES_AVAIL needs the statfs buffer Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 15/19] powerpc/pseries: Fix overwritten PE state Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 16/19] powerpc: fix typo CONFIG_PMAC Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 17/19] powerpc: fix typo CONFIG_PPC_CPU Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 18/19] ptrace,x86: force IRET path after a ptrace_stop() Greg Kroah-Hartman
2014-07-04 22:15 ` [PATCH 3.4 19/19] tracing: Fix syscall_*regfunc() vs copy_process() race Greg Kroah-Hartman
2014-07-05 5:39 ` [PATCH 3.4 00/19] 3.4.97-stable review Guenter Roeck
2014-07-05 6:53 ` Satoru Takeuchi
2014-07-05 17:47 ` Greg Kroah-Hartman
2014-07-05 17:46 ` Greg Kroah-Hartman
2014-07-05 17:48 ` Greg Kroah-Hartman
2014-07-05 18:26 ` Guenter Roeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140704221436.733842392@linuxfoundation.org \
--to=gregkh@linuxfoundation.org \
--cc=artem.bityutskiy@linux.intel.com \
--cc=hujianyang@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.