f2fs_bug_on in init_dirty_segmap

f2fs_bug_on in init_dirty_segmap

[Philippe De Muyter]

Hi f2fs developpers,

Please excuse my maybe dumb question.

I recently encountered a kernel panic at root mount time (thus making my
system unusable, as my root partition is formatted as f2fs) due to the
following segment in fs/f2fs/segment.c:init_dirty_segmap

		if (valid_blocks > sbi->blocks_per_seg) {
                        f2fs_bug_on(sbi, 1); <<<<<<<<<<<<<<<<<<<<
			continue;
		}

Is that really a condition requiring a kernel panic, or could a read-only
mount be allowed ?

Philippe

-- 
Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford

Re: f2fs_bug_on in init_dirty_segmap

[Jaegeuk Kim]

Hi,

On 03/08, Philippe De Muyter wrote:
> Hi f2fs developpers,
> 
> Please excuse my maybe dumb question.
> 
> I recently encountered a kernel panic at root mount time (thus making my
> system unusable, as my root partition is formatted as f2fs) due to the
> following segment in fs/f2fs/segment.c:init_dirty_segmap
> 
> 		if (valid_blocks > sbi->blocks_per_seg) {
>                         f2fs_bug_on(sbi, 1); <<<<<<<<<<<<<<<<<<<<
> 			continue;
> 		}
> 
> Is that really a condition requiring a kernel panic, or could a read-only
> mount be allowed ?

It would be helpful that you can remain your kernel and f2fs-tools version
information, as well as fsck.f2fs result.

You can get the latest f2fs-tools from
http://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs-tools.git/log/?h=dev-test

Anyway, if you don't have time, you may have some options like:

1. disable F2FS_CHECK_FS in Kconfig
 : bypass BUG_ON here, so mount-ro would be preferable.

2. run fsck.f2fs
 : fix some inconsistency and let you mount your system again.

So, I think you'd better try #1 to retrieve your important data, and then
#2 to fix something wrong.

Thanks,

> 
> Philippe
> 
> -- 
> Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles
> 
> ------------------------------------------------------------------------------
> Announcing the Oxford Dictionaries API! The API offers world-renowned
> dictionary content that is easy and intuitive to access. Sign up for an
> account today to start using our lexical data to power your apps and
> projects. Get started today and enter our developer competition.
> http://sdm.link/oxford
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford

Re: f2fs_bug_on in init_dirty_segmap

[Philippe De Muyter]

Hi,

thanks for your quick answer

On Wed, Mar 08, 2017 at 01:52:03PM -0800, Jaegeuk Kim wrote:
> Hi,
> 
> On 03/08, Philippe De Muyter wrote:
> > Hi f2fs developpers,
> > 
> > Please excuse my maybe dumb question.
> > 
> > I recently encountered a kernel panic at root mount time (thus making my
> > system unusable, as my root partition is formatted as f2fs) due to the
> > following segment in fs/f2fs/segment.c:init_dirty_segmap
> > 
> > 		if (valid_blocks > sbi->blocks_per_seg) {
> >                         f2fs_bug_on(sbi, 1); <<<<<<<<<<<<<<<<<<<<
> > 			continue;
> > 		}
> > 
> > Is that really a condition requiring a kernel panic, or could a read-only
> > mount be allowed ?
> 
> It would be helpful that you can remain your kernel and f2fs-tools version
> information, as well as fsck.f2fs result.

It is actually a Freescale (now NXP) provided kernel tagged rel_imx_4.1.15_1.2.0_ga
available at git://git.freescale.com/imx/linux-2.6-imx.git 

I surmise that the f2fs driver is the one from the linux-4.1 version.

> 
> You can get the latest f2fs-tools from
> http://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs-tools.git/log/?h=dev-test
> 
> Anyway, if you don't have time, you may have some options like:
> 
> 1. disable F2FS_CHECK_FS in Kconfig
>  : bypass BUG_ON here, so mount-ro would be preferable.

Actually F2FS_CHECK_FS was disabled, but kernel panic'ed.

> 
> 2. run fsck.f2fs
>  : fix some inconsistency and let you mount your system again.
> 
> So, I think you'd better try #1 to retrieve your important data, and then
> #2 to fix something wrong.

There wasn't a need to retrieve important data, as it is an unattended device
in the wild.  The problem was that boot did not succeed anymore and the device
needed a return to our aftersales department for reflashing.  Without the 'panic',
and with a read-only mount we could probably fix it without reflashing
and without return.

If that happens again, I'll try to provide more information.
> 
> > 
> > Philippe

-- 
Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford

Re: f2fs_bug_on in init_dirty_segmap

[Jaegeuk Kim]

On 03/09, Philippe De Muyter wrote:
> Hi,
> 
> thanks for your quick answer
> 
> On Wed, Mar 08, 2017 at 01:52:03PM -0800, Jaegeuk Kim wrote:
> > Hi,
> > 
> > On 03/08, Philippe De Muyter wrote:
> > > Hi f2fs developpers,
> > > 
> > > Please excuse my maybe dumb question.
> > > 
> > > I recently encountered a kernel panic at root mount time (thus making my
> > > system unusable, as my root partition is formatted as f2fs) due to the
> > > following segment in fs/f2fs/segment.c:init_dirty_segmap
> > > 
> > > 		if (valid_blocks > sbi->blocks_per_seg) {
> > >                         f2fs_bug_on(sbi, 1); <<<<<<<<<<<<<<<<<<<<
> > > 			continue;
> > > 		}
> > > 
> > > Is that really a condition requiring a kernel panic, or could a read-only
> > > mount be allowed ?
> > 
> > It would be helpful that you can remain your kernel and f2fs-tools version
> > information, as well as fsck.f2fs result.
> 
> It is actually a Freescale (now NXP) provided kernel tagged rel_imx_4.1.15_1.2.0_ga
> available at git://git.freescale.com/imx/linux-2.6-imx.git 
> 
> I surmise that the f2fs driver is the one from the linux-4.1 version.
> 
> > 
> > You can get the latest f2fs-tools from
> > http://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs-tools.git/log/?h=dev-test
> > 
> > Anyway, if you don't have time, you may have some options like:
> > 
> > 1. disable F2FS_CHECK_FS in Kconfig
> >  : bypass BUG_ON here, so mount-ro would be preferable.
> 
> Actually F2FS_CHECK_FS was disabled, but kernel panic'ed.

So, you got a warning message from there?

#ifdef CONFIG_F2FS_CHECK_FS
#define f2fs_bug_on(sbi, condition)	BUG_ON(condition)
#define f2fs_down_write(x, y)	down_write_nest_lock(x, y)
#else
#define f2fs_bug_on(sbi, condition)					\
	do {								\
		if (unlikely(condition)) {				\
			WARN_ON(1);					\
			set_sbi_flag(sbi, SBI_NEED_FSCK);		\
		}							\
	} while (0)
#define f2fs_down_write(x, y)	down_write(x)
#endif

> > 
> > 2. run fsck.f2fs
> >  : fix some inconsistency and let you mount your system again.
> > 
> > So, I think you'd better try #1 to retrieve your important data, and then
> > #2 to fix something wrong.
> 
> There wasn't a need to retrieve important data, as it is an unattended device
> in the wild.  The problem was that boot did not succeed anymore and the device
> needed a return to our aftersales department for reflashing.  Without the 'panic',
> and with a read-only mount we could probably fix it without reflashing
> and without return.

So, there is no fscking before mounting any filesystem during boot-up, right?
Most of distros and android do that and provide a recovery mode tho.

I think there is a way to mount with ro without loading in-memory structures
which results in potential panics. Will cosider about that. ;)

Note, there is a backported f2fs for v4.1 which I've been maintaining.

http://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs-stable.git/log/?h=linux-4.1.y

Thanks,

> 
> If that happens again, I'll try to provide more information.
> > 
> > > 
> > > Philippe
> 
> -- 
> Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles
> 
> ------------------------------------------------------------------------------
> Announcing the Oxford Dictionaries API! The API offers world-renowned
> dictionary content that is easy and intuitive to access. Sign up for an
> account today to start using our lexical data to power your apps and
> projects. Get started today and enter our developer competition.
> http://sdm.link/oxford
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford

Re: f2fs_bug_on in init_dirty_segmap

[Philippe De Muyter]

On Thu, Mar 09, 2017 at 03:11:46PM -0800, Jaegeuk Kim wrote:
> On 03/09, Philippe De Muyter wrote:
> > Hi,
> > 
> > thanks for your quick answer
> > 
> > On Wed, Mar 08, 2017 at 01:52:03PM -0800, Jaegeuk Kim wrote:
> > > Hi,
> > > 
> > > On 03/08, Philippe De Muyter wrote:
> > > > Hi f2fs developpers,
> > > > 
> > > > Please excuse my maybe dumb question.
> > > > 
> > > > I recently encountered a kernel panic at root mount time (thus making my
> > > > system unusable, as my root partition is formatted as f2fs) due to the
> > > > following segment in fs/f2fs/segment.c:init_dirty_segmap
> > > > 
> > > > 		if (valid_blocks > sbi->blocks_per_seg) {
> > > >                         f2fs_bug_on(sbi, 1); <<<<<<<<<<<<<<<<<<<<
> > > > 			continue;
> > > > 		}
> > > > 
> > > > Is that really a condition requiring a kernel panic, or could a read-only
> > > > mount be allowed ?
> > > 
> > > It would be helpful that you can remain your kernel and f2fs-tools version
> > > information, as well as fsck.f2fs result.
> > 
> > It is actually a Freescale (now NXP) provided kernel tagged rel_imx_4.1.15_1.2.0_ga
> > available at git://git.freescale.com/imx/linux-2.6-imx.git 
> > 
> > I surmise that the f2fs driver is the one from the linux-4.1 version.
> > 
> > > 
> > > You can get the latest f2fs-tools from
> > > http://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs-tools.git/log/?h=dev-test
> > > 
> > > Anyway, if you don't have time, you may have some options like:
> > > 
> > > 1. disable F2FS_CHECK_FS in Kconfig
> > >  : bypass BUG_ON here, so mount-ro would be preferable.
> > 
> > Actually F2FS_CHECK_FS was disabled, but kernel panic'ed.
> 
> So, you got a warning message from there?
> 
> #ifdef CONFIG_F2FS_CHECK_FS
> #define f2fs_bug_on(sbi, condition)	BUG_ON(condition)
> #define f2fs_down_write(x, y)	down_write_nest_lock(x, y)
> #else
> #define f2fs_bug_on(sbi, condition)					\
> 	do {								\
> 		if (unlikely(condition)) {				\
> 			WARN_ON(1);					\
> 			set_sbi_flag(sbi, SBI_NEED_FSCK);		\
> 		}							\
> 	} while (0)
> #define f2fs_down_write(x, y)	down_write(x)
> #endif

Yes, I got a 'panic'.  I'll look deeper into that and let you know.

> 
> > > 
> > > 2. run fsck.f2fs
> > >  : fix some inconsistency and let you mount your system again.
> > > 
> > > So, I think you'd better try #1 to retrieve your important data, and then
> > > #2 to fix something wrong.
> > 
> > There wasn't a need to retrieve important data, as it is an unattended device
> > in the wild.  The problem was that boot did not succeed anymore and the device
> > needed a return to our aftersales department for reflashing.  Without the 'panic',
> > and with a read-only mount we could probably fix it without reflashing
> > and without return.
> 
> So, there is no fscking before mounting any filesystem during boot-up, right?
> Most of distros and android do that and provide a recovery mode tho.

No, there is no fsck before mounting the root filesystem during boot-up.
But I do my best to avoid writing in the root partition.  It's not read-only,
but all log, lock, run, cache and tmp files are in tmpfs partitions.  I have
just noticed though that the partition is mounted with 'relatime', not 'noatime'
as I would like, but I do not know where this 'relatime' option comes from.
Is 'relatime' a default mount option for f2fs ?

> 
> I think there is a way to mount with ro without loading in-memory structures
> which results in potential panics. Will cosider about that. ;)
> 
> Note, there is a backported f2fs for v4.1 which I've been maintaining.
> 
> http://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs-stable.git/log/?h=linux-4.1.y

Thank you. I will apply it

Philippe

-- 
Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford

Re: f2fs_bug_on in init_dirty_segmap

[Jaegeuk Kim]

On 03/10, Philippe De Muyter wrote:
...
> > > It is actually a Freescale (now NXP) provided kernel tagged rel_imx_4.1.15_1.2.0_ga
> > > available at git://git.freescale.com/imx/linux-2.6-imx.git 
> > > 
> > > I surmise that the f2fs driver is the one from the linux-4.1 version.
> > > 
> > > > 
> > > > You can get the latest f2fs-tools from
> > > > http://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs-tools.git/log/?h=dev-test
> > > > 
> > > > Anyway, if you don't have time, you may have some options like:
> > > > 
> > > > 1. disable F2FS_CHECK_FS in Kconfig
> > > >  : bypass BUG_ON here, so mount-ro would be preferable.
> > > 
> > > Actually F2FS_CHECK_FS was disabled, but kernel panic'ed.
> > 
> > So, you got a warning message from there?
> > 
> > #ifdef CONFIG_F2FS_CHECK_FS
> > #define f2fs_bug_on(sbi, condition)	BUG_ON(condition)
> > #define f2fs_down_write(x, y)	down_write_nest_lock(x, y)
> > #else
> > #define f2fs_bug_on(sbi, condition)					\
> > 	do {								\
> > 		if (unlikely(condition)) {				\
> > 			WARN_ON(1);					\
> > 			set_sbi_flag(sbi, SBI_NEED_FSCK);		\
> > 		}							\
> > 	} while (0)
> > #define f2fs_down_write(x, y)	down_write(x)
> > #endif
> 
> Yes, I got a 'panic'.  I'll look deeper into that and let you know.

Okay, thank you. ;)

> > > > 2. run fsck.f2fs
> > > >  : fix some inconsistency and let you mount your system again.
> > > > 
> > > > So, I think you'd better try #1 to retrieve your important data, and then
> > > > #2 to fix something wrong.
> > > 
> > > There wasn't a need to retrieve important data, as it is an unattended device
> > > in the wild.  The problem was that boot did not succeed anymore and the device
> > > needed a return to our aftersales department for reflashing.  Without the 'panic',
> > > and with a read-only mount we could probably fix it without reflashing
> > > and without return.
> > 
> > So, there is no fscking before mounting any filesystem during boot-up, right?
> > Most of distros and android do that and provide a recovery mode tho.
> 
> No, there is no fsck before mounting the root filesystem during boot-up.
> But I do my best to avoid writing in the root partition.  It's not read-only,
> but all log, lock, run, cache and tmp files are in tmpfs partitions.  I have
> just noticed though that the partition is mounted with 'relatime', not 'noatime'
> as I would like, but I do not know where this 'relatime' option comes from.
> Is 'relatime' a default mount option for f2fs ?

Not specific from f2fs. It's default given by vfs, and you need to mount with
noatime explicitly, if you want. BTW, once you got a panic during boot-up, how
can you change mount option?

Thanks,

> 
> > 
> > I think there is a way to mount with ro without loading in-memory structures
> > which results in potential panics. Will cosider about that. ;)
> > 
> > Note, there is a backported f2fs for v4.1 which I've been maintaining.
> > 
> > http://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs-stable.git/log/?h=linux-4.1.y
> 
> Thank you. I will apply it
> 
> Philippe
> 
> -- 
> Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford

Re: f2fs_bug_on in init_dirty_segmap

[Philippe De Muyter]

On Fri, Mar 10, 2017 at 10:20:34AM -0800, Jaegeuk Kim wrote:
> On 03/10, Philippe De Muyter wrote:
> ...
> > > > It is actually a Freescale (now NXP) provided kernel tagged rel_imx_4.1.15_1.2.0_ga
> > > > available at git://git.freescale.com/imx/linux-2.6-imx.git 
> > > > 
> > > > I surmise that the f2fs driver is the one from the linux-4.1 version.
> > > > 
> > > > > 
> > > > > You can get the latest f2fs-tools from
> > > > > http://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs-tools.git/log/?h=dev-test
> > > > > 
> > > > > Anyway, if you don't have time, you may have some options like:
> > > > > 
> > > > > 1. disable F2FS_CHECK_FS in Kconfig
> > > > >  : bypass BUG_ON here, so mount-ro would be preferable.
> > > > 
> > > > Actually F2FS_CHECK_FS was disabled, but kernel panic'ed.
> > > 
> > > So, you got a warning message from there?
> > > 
> > > #ifdef CONFIG_F2FS_CHECK_FS
> > > #define f2fs_bug_on(sbi, condition)	BUG_ON(condition)
> > > #define f2fs_down_write(x, y)	down_write_nest_lock(x, y)
> > > #else
> > > #define f2fs_bug_on(sbi, condition)					\
> > > 	do {								\
> > > 		if (unlikely(condition)) {				\
> > > 			WARN_ON(1);					\
> > > 			set_sbi_flag(sbi, SBI_NEED_FSCK);		\
> > > 		}							\
> > > 	} while (0)
> > > #define f2fs_down_write(x, y)	down_write(x)
> > > #endif
> > 
> > Yes, I got a 'panic'.  I'll look deeper into that and let you know.
> 
> Okay, thank you. ;)

For a test, I forced a call to f2fs_bug_on(sbi, 1) at the entry of init_dirty_segmap(),
and tested on another board but only got a message, not a panic, so I don't know
what happened on the first board.  If it happens again on another board, I'll
try to collect more info.

> 
> > > > > 2. run fsck.f2fs
> > > > >  : fix some inconsistency and let you mount your system again.
> > > > > 
> > > > > So, I think you'd better try #1 to retrieve your important data, and then
> > > > > #2 to fix something wrong.
> > > > 
> > > > There wasn't a need to retrieve important data, as it is an unattended device
> > > > in the wild.  The problem was that boot did not succeed anymore and the device
> > > > needed a return to our aftersales department for reflashing.  Without the 'panic',
> > > > and with a read-only mount we could probably fix it without reflashing
> > > > and without return.
> > > 
> > > So, there is no fscking before mounting any filesystem during boot-up, right?
> > > Most of distros and android do that and provide a recovery mode tho.
> > 
> > No, there is no fsck before mounting the root filesystem during boot-up.
> > But I do my best to avoid writing in the root partition.  It's not read-only,
> > but all log, lock, run, cache and tmp files are in tmpfs partitions.  I have
> > just noticed though that the partition is mounted with 'relatime', not 'noatime'
> > as I would like, but I do not know where this 'relatime' option comes from.
> > Is 'relatime' a default mount option for f2fs ?
> 
> Not specific from f2fs. It's default given by vfs, and you need to mount with
> noatime explicitly, if you want. BTW, once you got a panic during boot-up, how
> can you change mount option?

It is a ARM board, started by U-boot.  I can change the kernel command-line,
and hope the kernel will understand the noatime option.

I wasn't speaking about changing the mount option after a panic, but about changing
the default mount option on all the new boards, to avoid unvoluntary writes to the
eMMC.

> 
> Thanks,
> 
> > 
> > > 
> > > I think there is a way to mount with ro without loading in-memory structures
> > > which results in potential panics. Will cosider about that. ;)
> > > 
> > > Note, there is a backported f2fs for v4.1 which I've been maintaining.
> > > 
> > > http://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs-stable.git/log/?h=linux-4.1.y
> > 
> > Thank you. I will apply it
> > 
> > Philippe

-- 
Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford

Re: f2fs_bug_on in init_dirty_segmap

[Jaegeuk Kim]

On 03/10, Philippe De Muyter wrote:
> On Fri, Mar 10, 2017 at 10:20:34AM -0800, Jaegeuk Kim wrote:
> > On 03/10, Philippe De Muyter wrote:
> > ...
> > > > > It is actually a Freescale (now NXP) provided kernel tagged rel_imx_4.1.15_1.2.0_ga
> > > > > available at git://git.freescale.com/imx/linux-2.6-imx.git 
> > > > > 
> > > > > I surmise that the f2fs driver is the one from the linux-4.1 version.
> > > > > 
> > > > > > 
> > > > > > You can get the latest f2fs-tools from
> > > > > > http://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs-tools.git/log/?h=dev-test
> > > > > > 
> > > > > > Anyway, if you don't have time, you may have some options like:
> > > > > > 
> > > > > > 1. disable F2FS_CHECK_FS in Kconfig
> > > > > >  : bypass BUG_ON here, so mount-ro would be preferable.
> > > > > 
> > > > > Actually F2FS_CHECK_FS was disabled, but kernel panic'ed.
> > > > 
> > > > So, you got a warning message from there?
> > > > 
> > > > #ifdef CONFIG_F2FS_CHECK_FS
> > > > #define f2fs_bug_on(sbi, condition)	BUG_ON(condition)
> > > > #define f2fs_down_write(x, y)	down_write_nest_lock(x, y)
> > > > #else
> > > > #define f2fs_bug_on(sbi, condition)					\
> > > > 	do {								\
> > > > 		if (unlikely(condition)) {				\
> > > > 			WARN_ON(1);					\
> > > > 			set_sbi_flag(sbi, SBI_NEED_FSCK);		\
> > > > 		}							\
> > > > 	} while (0)
> > > > #define f2fs_down_write(x, y)	down_write(x)
> > > > #endif
> > > 
> > > Yes, I got a 'panic'.  I'll look deeper into that and let you know.
> > 
> > Okay, thank you. ;)
> 
> For a test, I forced a call to f2fs_bug_on(sbi, 1) at the entry of init_dirty_segmap(),
> and tested on another board but only got a message, not a panic, so I don't know
> what happened on the first board.  If it happens again on another board, I'll
> try to collect more info.

BTW, do you have the corrupted image? Then, you can back up it and run fsck to
retrieve some information on it. Or, can you share?

> > > > > > 2. run fsck.f2fs
> > > > > >  : fix some inconsistency and let you mount your system again.
> > > > > > 
> > > > > > So, I think you'd better try #1 to retrieve your important data, and then
> > > > > > #2 to fix something wrong.
> > > > > 
> > > > > There wasn't a need to retrieve important data, as it is an unattended device
> > > > > in the wild.  The problem was that boot did not succeed anymore and the device
> > > > > needed a return to our aftersales department for reflashing.  Without the 'panic',
> > > > > and with a read-only mount we could probably fix it without reflashing
> > > > > and without return.
> > > > 
> > > > So, there is no fscking before mounting any filesystem during boot-up, right?
> > > > Most of distros and android do that and provide a recovery mode tho.
> > > 
> > > No, there is no fsck before mounting the root filesystem during boot-up.
> > > But I do my best to avoid writing in the root partition.  It's not read-only,
> > > but all log, lock, run, cache and tmp files are in tmpfs partitions.  I have
> > > just noticed though that the partition is mounted with 'relatime', not 'noatime'
> > > as I would like, but I do not know where this 'relatime' option comes from.
> > > Is 'relatime' a default mount option for f2fs ?
> > 
> > Not specific from f2fs. It's default given by vfs, and you need to mount with
> > noatime explicitly, if you want. BTW, once you got a panic during boot-up, how
> > can you change mount option?
> 
> It is a ARM board, started by U-boot.  I can change the kernel command-line,
> and hope the kernel will understand the noatime option.
> 
> I wasn't speaking about changing the mount option after a panic, but about changing
> the default mount option on all the new boards, to avoid unvoluntary writes to the
> eMMC.

If there was almost no change in the root partition, that may happen due to
other reason like overwritting block device by user accidently.
(fsck can show some clues tho.)

Thanks,

> 
> > 
> > Thanks,
> > 
> > > 
> > > > 
> > > > I think there is a way to mount with ro without loading in-memory structures
> > > > which results in potential panics. Will cosider about that. ;)
> > > > 
> > > > Note, there is a backported f2fs for v4.1 which I've been maintaining.
> > > > 
> > > > http://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs-stable.git/log/?h=linux-4.1.y
> > > 
> > > Thank you. I will apply it
> > > 
> > > Philippe
> 
> -- 
> Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford

Re: f2fs_bug_on in init_dirty_segmap

[Philippe De Muyter]

On Sat, Mar 11, 2017 at 01:01:11PM -0800, Jaegeuk Kim wrote:
> On 03/10, Philippe De Muyter wrote:
> > On Fri, Mar 10, 2017 at 10:20:34AM -0800, Jaegeuk Kim wrote:
> > > On 03/10, Philippe De Muyter wrote:
> > > ...
> > > > > > It is actually a Freescale (now NXP) provided kernel tagged rel_imx_4.1.15_1.2.0_ga
> > > > > > available at git://git.freescale.com/imx/linux-2.6-imx.git 
> > > > > > 
> > > > > > I surmise that the f2fs driver is the one from the linux-4.1 version.
> > > > > > 
> > > > > > > 
> > > > > > > You can get the latest f2fs-tools from
> > > > > > > http://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs-tools.git/log/?h=dev-test
> > > > > > > 
> > > > > > > Anyway, if you don't have time, you may have some options like:
> > > > > > > 
> > > > > > > 1. disable F2FS_CHECK_FS in Kconfig
> > > > > > >  : bypass BUG_ON here, so mount-ro would be preferable.
> > > > > > 
> > > > > > Actually F2FS_CHECK_FS was disabled, but kernel panic'ed.
> > > > > 
> > > > > So, you got a warning message from there?
> > > > > 
> > > > > #ifdef CONFIG_F2FS_CHECK_FS
> > > > > #define f2fs_bug_on(sbi, condition)	BUG_ON(condition)
> > > > > #define f2fs_down_write(x, y)	down_write_nest_lock(x, y)
> > > > > #else
> > > > > #define f2fs_bug_on(sbi, condition)					\
> > > > > 	do {								\
> > > > > 		if (unlikely(condition)) {				\
> > > > > 			WARN_ON(1);					\
> > > > > 			set_sbi_flag(sbi, SBI_NEED_FSCK);		\
> > > > > 		}							\
> > > > > 	} while (0)
> > > > > #define f2fs_down_write(x, y)	down_write(x)
> > > > > #endif
> > > > 
> > > > Yes, I got a 'panic'.  I'll look deeper into that and let you know.
> > > 
> > > Okay, thank you. ;)
> > 
> > For a test, I forced a call to f2fs_bug_on(sbi, 1) at the entry of init_dirty_segmap(),
> > and tested on another board but only got a message, not a panic, so I don't know
> > what happened on the first board.  If it happens again on another board, I'll
> > try to collect more info.
> 
> BTW, do you have the corrupted image? Then, you can back up it and run fsck to
> retrieve some information on it. Or, can you share?

No unfortunately, the device got reflashed before I had any chance so save
a copy of the partition.  If it happens again, I'll save it.

> 
> > > > > > > 2. run fsck.f2fs
> > > > > > >  : fix some inconsistency and let you mount your system again.
> > > > > > > 
> > > > > > > So, I think you'd better try #1 to retrieve your important data, and then
> > > > > > > #2 to fix something wrong.
> > > > > > 
> > > > > > There wasn't a need to retrieve important data, as it is an unattended device
> > > > > > in the wild.  The problem was that boot did not succeed anymore and the device
> > > > > > needed a return to our aftersales department for reflashing.  Without the 'panic',
> > > > > > and with a read-only mount we could probably fix it without reflashing
> > > > > > and without return.
> > > > > 
> > > > > So, there is no fscking before mounting any filesystem during boot-up, right?
> > > > > Most of distros and android do that and provide a recovery mode tho.
> > > > 
> > > > No, there is no fsck before mounting the root filesystem during boot-up.
> > > > But I do my best to avoid writing in the root partition.  It's not read-only,
> > > > but all log, lock, run, cache and tmp files are in tmpfs partitions.  I have
> > > > just noticed though that the partition is mounted with 'relatime', not 'noatime'
> > > > as I would like, but I do not know where this 'relatime' option comes from.
> > > > Is 'relatime' a default mount option for f2fs ?
> > > 
> > > Not specific from f2fs. It's default given by vfs, and you need to mount with
> > > noatime explicitly, if you want. BTW, once you got a panic during boot-up, how
> > > can you change mount option?
> > 
> > It is a ARM board, started by U-boot.  I can change the kernel command-line,
> > and hope the kernel will understand the noatime option.
> > 
> > I wasn't speaking about changing the mount option after a panic, but about changing
> > the default mount option on all the new boards, to avoid unvoluntary writes to the
> > eMMC.
> 
> If there was almost no change in the root partition, that may happen due to
> other reason like overwritting block device by user accidently.
> (fsck can show some clues tho.)

I am aware of two possible external causes

- some dma engine on my device does not always terminate when the user process
using it terminates and the memory is freed :( (a GPU or VPU with hidden firmware)
- there is no UPS to power the device and hence the eMMC

Therefor I really prefer to have 'noatime' rather than 'relatime' set.

I now found that specifying "rootflags=noatime" on the linux command-line does not
work for the root partition, as it answers :

	Unrecognized mount option "noatime" or missing value

I also saw in linux sources that 'jffs2' sets arbitrarily 'noatime'.  I'll try to 
do the same for f2fs.

> 
> Thanks,
> 
> > 
> > > 
> > > Thanks,
> > > 
> > > > 
> > > > > 
> > > > > I think there is a way to mount with ro without loading in-memory structures
> > > > > which results in potential panics. Will cosider about that. ;)
> > > > > 
> > > > > Note, there is a backported f2fs for v4.1 which I've been maintaining.
> > > > > 
> > > > > http://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs-stable.git/log/?h=linux-4.1.y
> > > > 
> > > > Thank you. I will apply it
> > > > 
> > > > Philippe

-- 
Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford