Re: [Potential Spoof] Re: kernel BUG at fs/jffs2/gc.c:395!

From: Tao Ren <taoren@fb.com>
To: Richard Weinberger <richard@nod.at>
Cc: Andrew Jeffery <andrew@aj.id.au>,
	OpenBMC Maillist <openbmc@lists.ozlabs.org>,
	linux-mtd <linux-mtd@lists.infradead.org>
Subject: Re: [Potential Spoof] Re: kernel BUG at fs/jffs2/gc.c:395!
Date: Wed, 28 Aug 2019 00:08:35 +0000	[thread overview]
Message-ID: <30720005-49a6-c2ba-2719-c00772bf1caf@fb.com> (raw)
In-Reply-To: <bc19f328-ef5d-9840-7985-82461c99205e@fb.com>

On 8/26/19 9:42 PM, Tao Ren wrote:
> On 8/25/19 3:29 PM, Richard Weinberger wrote:
>> ----- Ursprüngliche Mail -----
>>> Von: "Tao Ren" <taoren@fb.com>
>>> An: "Richard Weinberger" <richard.weinberger@gmail.com>, "Andrew Jeffery" <andrew@aj.id.au>
>>> CC: "linux-mtd" <linux-mtd@lists.infradead.org>, "OpenBMC Maillist" <openbmc@lists.ozlabs.org>
>>> Gesendet: Montag, 26. August 2019 00:08:08
>>> Betreff: Re: kernel BUG at fs/jffs2/gc.c:395!
>>
>>> On 8/25/19 12:22 PM, Richard Weinberger wrote:
>>>> On Wed, Aug 21, 2019 at 2:06 AM Andrew Jeffery <andrew@aj.id.au> wrote:
>>>>> Looks like a lack of robustness to filesystem corruption to me. LWN
>>>>
>>>> What exactly makes you think so?
>>>> The inode cache entry is in state INO_STATE_UNCHECKED while GC run,
>>>> which is not allowed.
>>>>
>>>> Tao, is the error persistent or did it happen only once?
>>>
>>> Hi Richard,
>>>
>>> It rarely happens (~1 out of 1000 machines in my environment), but once it
>>> happens, it's persistent: the machine will fall into reboot loop due to the
>>> crash.
>>
>> Can you provide me an image of the filesystem such that I can have a look?
>> An image where the issue is persistent...
> 
> Hi Richard,
> 
> I tried kernel image with jffs2 summary enabled and disabled, and it looks to
> me the result is similar: I can reach login screen now, but the same kernel
> panic happens after "reboot" command.
> 
> The behavior is a little different from what I saw yesterday: previously kernel
> panic happened at boot time, and now it's after "reboot" command. I guess it's
> because more node being written to the flash?
> 
> I understand it's helpful to share the file system image, but unfortunately I
> cannot do it because it contains confidential data. Sorry about that..
> 
> Thank you again for the help, and kindly let me know if you have further
> suggestions.

Some interesting findings: I checked 3 impacted machines and all of them are
caused by the same set of files, and these files have been on the flash for
years without modification.

- Tao
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/