All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	stable@vger.kernel.org, Andreas Rohner <andreas.rohner@gmx.net>,
	Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: [PATCH 3.12 17/27] nilfs2: fix segctor bug that causes file system corruption
Date: Thu, 23 Jan 2014 11:06:54 -0800	[thread overview]
Message-ID: <20140123190650.465416100@linuxfoundation.org> (raw)
In-Reply-To: <20140123190648.720195687@linuxfoundation.org>

3.12-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Andreas Rohner <andreas.rohner@gmx.net>

commit 70f2fe3a26248724d8a5019681a869abdaf3e89a upstream.

There is a bug in the function nilfs_segctor_collect, which results in
active data being written to a segment, that is marked as clean.  It is
possible, that this segment is selected for a later segment
construction, whereby the old data is overwritten.

The problem shows itself with the following kernel log message:

  nilfs_sufile_do_cancel_free: segment 6533 must be clean

Usually a few hours later the file system gets corrupted:

  NILFS: bad btree node (blocknr=8748107): level = 0, flags = 0x0, nchildren = 0
  NILFS error (device sdc1): nilfs_bmap_last_key: broken bmap (inode number=114660)

The issue can be reproduced with a file system that is nearly full and
with the cleaner running, while some IO intensive task is running.
Although it is quite hard to reproduce.

This is what happens:

 1. The cleaner starts the segment construction
 2. nilfs_segctor_collect is called
 3. sc_stage is on NILFS_ST_SUFILE and segments are freed
 4. sc_stage is on NILFS_ST_DAT current segment is full
 5. nilfs_segctor_extend_segments is called, which
    allocates a new segment
 6. The new segment is one of the segments freed in step 3
 7. nilfs_sufile_cancel_freev is called and produces an error message
 8. Loop around and the collection starts again
 9. sc_stage is on NILFS_ST_SUFILE and segments are freed
    including the newly allocated segment, which will contain active
    data and can be allocated at a later time
10. A few hours later another segment construction allocates the
    segment and causes file system corruption

This can be prevented by simply reordering the statements.  If
nilfs_sufile_cancel_freev is called before nilfs_segctor_extend_segments
the freed segments are marked as dirty and cannot be allocated any more.

Signed-off-by: Andreas Rohner <andreas.rohner@gmx.net>
Reviewed-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
Tested-by: Andreas Rohner <andreas.rohner@gmx.net>
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/nilfs2/segment.c |   10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

--- a/fs/nilfs2/segment.c
+++ b/fs/nilfs2/segment.c
@@ -1440,17 +1440,19 @@ static int nilfs_segctor_collect(struct
 
 		nilfs_clear_logs(&sci->sc_segbufs);
 
-		err = nilfs_segctor_extend_segments(sci, nilfs, nadd);
-		if (unlikely(err))
-			return err;
-
 		if (sci->sc_stage.flags & NILFS_CF_SUFREED) {
 			err = nilfs_sufile_cancel_freev(nilfs->ns_sufile,
 							sci->sc_freesegs,
 							sci->sc_nfreesegs,
 							NULL);
 			WARN_ON(err); /* do not happen */
+			sci->sc_stage.flags &= ~NILFS_CF_SUFREED;
 		}
+
+		err = nilfs_segctor_extend_segments(sci, nilfs, nadd);
+		if (unlikely(err))
+			return err;
+
 		nadd = min_t(int, nadd << 1, SC_MAX_SEGDELTA);
 		sci->sc_stage = prev_stage;
 	}



  parent reply	other threads:[~2014-01-23 19:07 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-23 19:06 [PATCH 3.12 00/27] 3.12.9-stable review Greg Kroah-Hartman
2014-01-23 19:06 ` [PATCH 3.12 01/27] Revert "ACPI: Add BayTrail SoC GPIO and LPSS ACPI IDs" Greg Kroah-Hartman
2014-01-23 19:06 ` [PATCH 3.12 02/27] perf/x86/amd/ibs: Fix waking up from S3 for AMD family 10h Greg Kroah-Hartman
2014-01-23 19:06 ` [PATCH 3.12 03/27] GFS2: Increase i_writecount during gfs2_setattr_chown Greg Kroah-Hartman
2014-01-23 19:06 ` [PATCH 3.12 04/27] staging: comedi: addi_apci_1032: fix subdevice type/flags bug Greg Kroah-Hartman
2014-01-23 19:06 ` [PATCH 3.12 05/27] staging: comedi: adl_pci9111: fix incorrect irq passed to request_irq() Greg Kroah-Hartman
2014-01-23 19:06 ` [PATCH 3.12 06/27] vfs: In d_path dont call d_dname on a mount point Greg Kroah-Hartman
2014-01-23 19:06 ` [PATCH 3.12 07/27] vfs: Fix a regression in mounting proc Greg Kroah-Hartman
2014-01-23 19:06 ` [PATCH 3.12 08/27] fork: Allow CLONE_PARENT after setns(CLONE_NEWPID) Greg Kroah-Hartman
2014-01-23 19:06 ` [PATCH 3.12 09/27] i2c: Re-instate body of i2c_parent_is_i2c_adapter() Greg Kroah-Hartman
2014-01-23 19:06 ` [PATCH 3.12 10/27] hwmon: (coretemp) Fix truncated name of alarm attributes Greg Kroah-Hartman
2014-01-23 19:06 ` [PATCH 3.12 11/27] writeback: Fix data corruption on NFS Greg Kroah-Hartman
2014-01-23 19:06 ` [PATCH 3.12 12/27] SELinux: Fix possible NULL pointer dereference in selinux_inode_permission() Greg Kroah-Hartman
2014-01-23 19:06 ` [PATCH 3.12 13/27] thp: fix copy_page_rep GPF by testing is_huge_zero_pmd once only Greg Kroah-Hartman
2014-01-23 19:06 ` [PATCH 3.12 14/27] ftrace/x86: Load ftrace_ops in parameter not the variable holding it Greg Kroah-Hartman
2014-01-23 19:06 ` [PATCH 3.12 15/27] crash_dump: fix compilation error (on MIPS at least) Greg Kroah-Hartman
2014-01-23 19:06 ` [PATCH 3.12 16/27] mm: fix crash when using XFS on loopback Greg Kroah-Hartman
2014-01-23 19:06 ` Greg Kroah-Hartman [this message]
2014-01-23 19:06 ` [PATCH 3.12 18/27] drm/i915: fix DDI PLLs HW state readout code Greg Kroah-Hartman
2014-01-23 19:06 ` [PATCH 3.12 19/27] md: fix problem when adding device to read-only array with bitmap Greg Kroah-Hartman
2014-01-23 19:06 ` [PATCH 3.12 20/27] md/raid10: fix bug when raid10 recovery fails to recover a block Greg Kroah-Hartman
2014-01-23 19:06 ` [PATCH 3.12 21/27] md/raid10: fix two bugs in handling of known-bad-blocks Greg Kroah-Hartman
2014-01-23 19:06 ` [PATCH 3.12 22/27] md/raid5: Fix possible confusion when multiple write errors occur Greg Kroah-Hartman
2014-01-23 19:07 ` [PATCH 3.12 23/27] mm: Make {,set}page_address() static inline if WANT_PAGE_VIRTUAL Greg Kroah-Hartman
2014-01-23 19:07 ` [PATCH 3.12 24/27] serial: amba-pl011: use port lock to guard control register access Greg Kroah-Hartman
2014-01-23 19:07 ` [PATCH 3.12 25/27] ARM: 7934/1: DT/kernel: fix arch_match_cpu_phys_id to avoid erroneous match Greg Kroah-Hartman
2014-01-23 19:07 ` [PATCH 3.12 27/27] ARM: 7938/1: OMAP4/highbank: Flush L2 cache before disabling Greg Kroah-Hartman
2014-01-23 23:20 ` [PATCH 3.12 00/27] 3.12.9-stable review Guenter Roeck
2014-01-24  4:11   ` Greg Kroah-Hartman
2014-01-24  5:17     ` Guenter Roeck
2014-01-24 15:19 ` Shuah Khan
2014-01-24 19:39 ` Radim Krčmář
2014-01-25  0:05   ` Greg Kroah-Hartman
2014-02-03 13:36   ` Luis Henriques
2014-01-25 14:08 ` Satoru Takeuchi

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=20140123190650.465416100@linuxfoundation.org \
    --to=gregkh@linuxfoundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=andreas.rohner@gmx.net \
    --cc=konishi.ryusuke@lab.ntt.co.jp \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=torvalds@linux-foundation.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.