From: Hideki EIRAKU <hdk1983-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8 in nilfs_segctor_do_co
Date: Thu, 30 Apr 2020 21:38:42 +0900 (JST) [thread overview]
Message-ID: <20200430.213842.00392641.hdk1983@gmail.com> (raw)
In-Reply-To: <20200328.182640.1933740379722138264.hermes-akuOmOme3sQYOdUovKs6ag@public.gmane.org>
> In Msg <874kuapb2s.fsf-3l5KtCzVe0PQT0dZR+AlfA@public.gmane.org>;
> Subject "Re: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8 in nilfs_segctor_do_construct":
>
>> Tomas Hlavaty <tom-3l5KtCzVe0PQT0dZR+AlfA@public.gmane.org> writes:
>>>>> 2) Can you mount the corrupted(?) partition from a recent version of
>>>>> kernel ?
>>
>> I tried the following Linux kernel versions:
>>
>> - v4.19
>> - v5.4
>> - v5.5.11
>>
>> and still get the crash
I found conditions to reproduce this issue with Linux 5.7-rc3:
- CONFIG_MEMCG=y *and* CONFIG_BLK_CGROUP=y
- When the NILFS2 file system writes to a device, the device file has
never written by other programs since boot
The following is an example with CONFIG_MEMCG=y and
CONFIG_BLK_CGROUP=y kernel. If you do mkfs and mount it, it works
because the mkfs command has written data to the device file before
mounting:
# mkfs -t nilfs2 /dev/sda1
mkfs.nilfs2 (nilfs-utils 2.2.7)
Start writing file system initial data to the device
Blocksize:4096 Device:/dev/sda1 Device Size:267386880
File system initialization succeeded !!
# mount /dev/sda1 /mnt
# touch /mnt
# sync
#
Loopback mount seems to be the same - if you do losetup, mkfs and
mount on a loopback device, it works:
# losetup /dev/loop0 foo
# mkfs -t nilfs2 /dev/loop0
mkfs.nilfs2 (nilfs-utils 2.2.7)
Start writing file system initial data to the device
Blocksize:4096 Device:/dev/loop0 Device Size:267386880
File system initialization succeeded !!
# mount /dev/sda1 /mnt
# touch /mnt
# sync
#
But if you do mkfs on a file and use mount -o loop, it may fail,
depending on whether the loopback device assigned by the mount command
was used or not before mounting:
# /sbin/mkfs.nilfs2 ./foo
mkfs.nilfs2 (nilfs-utils 2.2.7)
Start writing file system initial data to the device
Blocksize:4096 Device:./foo Device Size:268435456
File system initialization succeeded !!
# mount -o loop ./foo /mnt
[ 36.371331] NILFS (loop0): segctord starting. Construction interval = 5 seconds, CP frequency < 30 seconds
# touch /mnt
# sync
[ 40.252869] BUG: kernel NULL pointer dereference, address: 00000000000000a8
(snip)
After reboot, it fails:
# mount /dev/sda1 /mnt
[ 14.021188] NILFS (sda1): segctord starting. Construction interval = 5 seconds, CP frequency < 30 seconds
# touch /mnt
# sync
[ 20.576309] BUG: kernel NULL pointer dereference, address: 00000000000000a8
(snip)
But if you do dummy write to the device file before mounting, it
works:
# dd if=/dev/sda1 of=/dev/sda1 count=1
1+0 records in
1+0 records out
512 bytes copied, 0.0135982 s, 37.7 kB/s
# mount /dev/sda1 /mnt
[ 52.604560] NILFS (sda1): mounting unchecked fs
[ 52.613335] NILFS (sda1): recovery complete
[ 52.613877] NILFS (sda1): segctord starting. Construction interval = 5 seconds, CP frequency < 30 seconds
# touch /mnt
# sync
#
# losetup /dev/loop0 foo
# dd if=/dev/loop0 of=/dev/loop0 count=1
1+0 records in
1+0 records out
512 bytes copied, 0.0243797 s, 21.0 kB/s
# mount /dev/loop0 /mnt
[ 271.915595] NILFS (loop0): mounting unchecked fs
[ 272.049603] NILFS (loop0): recovery complete
[ 272.049724] NILFS (loop0): segctord starting. Construction interval = 5 seconds, CP frequency < 30 seconds
# touch /mnt
# sync
#
I think the dummy write is a simple workaround for now, unless
mounting NILFS2 at boot time. But I have been using NILFS2 /home for
years, I would like to know better workarounds.
WARNING: multiple messages have this Message-ID (diff)
From: Hideki EIRAKU <hdk1983@gmail.com>
To: linux-nilfs@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8 in nilfs_segctor_do_co
Date: Thu, 30 Apr 2020 21:38:42 +0900 (JST) [thread overview]
Message-ID: <20200430.213842.00392641.hdk1983@gmail.com> (raw)
In-Reply-To: <20200328.182640.1933740379722138264.hermes@ceres.dti.ne.jp>
> In Msg <874kuapb2s.fsf@logand.com>;
> Subject "Re: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8 in nilfs_segctor_do_construct":
>
>> Tomas Hlavaty <tom@logand.com> writes:
>>>>> 2) Can you mount the corrupted(?) partition from a recent version of
>>>>> kernel ?
>>
>> I tried the following Linux kernel versions:
>>
>> - v4.19
>> - v5.4
>> - v5.5.11
>>
>> and still get the crash
I found conditions to reproduce this issue with Linux 5.7-rc3:
- CONFIG_MEMCG=y *and* CONFIG_BLK_CGROUP=y
- When the NILFS2 file system writes to a device, the device file has
never written by other programs since boot
The following is an example with CONFIG_MEMCG=y and
CONFIG_BLK_CGROUP=y kernel. If you do mkfs and mount it, it works
because the mkfs command has written data to the device file before
mounting:
# mkfs -t nilfs2 /dev/sda1
mkfs.nilfs2 (nilfs-utils 2.2.7)
Start writing file system initial data to the device
Blocksize:4096 Device:/dev/sda1 Device Size:267386880
File system initialization succeeded !!
# mount /dev/sda1 /mnt
# touch /mnt
# sync
#
Loopback mount seems to be the same - if you do losetup, mkfs and
mount on a loopback device, it works:
# losetup /dev/loop0 foo
# mkfs -t nilfs2 /dev/loop0
mkfs.nilfs2 (nilfs-utils 2.2.7)
Start writing file system initial data to the device
Blocksize:4096 Device:/dev/loop0 Device Size:267386880
File system initialization succeeded !!
# mount /dev/sda1 /mnt
# touch /mnt
# sync
#
But if you do mkfs on a file and use mount -o loop, it may fail,
depending on whether the loopback device assigned by the mount command
was used or not before mounting:
# /sbin/mkfs.nilfs2 ./foo
mkfs.nilfs2 (nilfs-utils 2.2.7)
Start writing file system initial data to the device
Blocksize:4096 Device:./foo Device Size:268435456
File system initialization succeeded !!
# mount -o loop ./foo /mnt
[ 36.371331] NILFS (loop0): segctord starting. Construction interval = 5 seconds, CP frequency < 30 seconds
# touch /mnt
# sync
[ 40.252869] BUG: kernel NULL pointer dereference, address: 00000000000000a8
(snip)
After reboot, it fails:
# mount /dev/sda1 /mnt
[ 14.021188] NILFS (sda1): segctord starting. Construction interval = 5 seconds, CP frequency < 30 seconds
# touch /mnt
# sync
[ 20.576309] BUG: kernel NULL pointer dereference, address: 00000000000000a8
(snip)
But if you do dummy write to the device file before mounting, it
works:
# dd if=/dev/sda1 of=/dev/sda1 count=1
1+0 records in
1+0 records out
512 bytes copied, 0.0135982 s, 37.7 kB/s
# mount /dev/sda1 /mnt
[ 52.604560] NILFS (sda1): mounting unchecked fs
[ 52.613335] NILFS (sda1): recovery complete
[ 52.613877] NILFS (sda1): segctord starting. Construction interval = 5 seconds, CP frequency < 30 seconds
# touch /mnt
# sync
#
# losetup /dev/loop0 foo
# dd if=/dev/loop0 of=/dev/loop0 count=1
1+0 records in
1+0 records out
512 bytes copied, 0.0243797 s, 21.0 kB/s
# mount /dev/loop0 /mnt
[ 271.915595] NILFS (loop0): mounting unchecked fs
[ 272.049603] NILFS (loop0): recovery complete
[ 272.049724] NILFS (loop0): segctord starting. Construction interval = 5 seconds, CP frequency < 30 seconds
# touch /mnt
# sync
#
I think the dummy write is a simple workaround for now, unless
mounting NILFS2 at boot time. But I have been using NILFS2 /home for
years, I would like to know better workarounds.
next prev parent reply other threads:[~2020-04-30 12:38 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-17 17:34 BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8 in nilfs_segctor_do_construct Tomas Hlavaty
2019-11-17 17:34 ` Tomas Hlavaty
2019-11-18 16:51 ` Ryusuke Konishi
2019-11-19 6:04 ` Viacheslav Dubeyko
[not found] ` <76887BD9-D6C4-4A89-8F55-4BEAF2828FD3-yeENwD64cLxBDgjK7y7TUQ@public.gmane.org>
2020-01-23 13:00 ` Tomas Hlavaty
2020-01-23 13:00 ` Tomas Hlavaty
2019-12-19 21:02 ` Tomas Hlavaty
[not found] ` <87immckp07.fsf-3l5KtCzVe0PQT0dZR+AlfA@public.gmane.org>
2020-01-23 12:31 ` Tomas Hlavaty
2020-01-23 12:31 ` Tomas Hlavaty
[not found] ` <87v9p2tkut.fsf-3l5KtCzVe0PQT0dZR+AlfA@public.gmane.org>
2020-03-27 6:26 ` Tomas Hlavaty
2020-03-27 6:26 ` Tomas Hlavaty
2020-03-28 9:26 ` ARAI Shun-ichi
[not found] ` <20200328.182640.1933740379722138264.hermes-akuOmOme3sQYOdUovKs6ag@public.gmane.org>
2020-04-30 12:38 ` Hideki EIRAKU [this message]
2020-04-30 12:38 ` BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8 in nilfs_segctor_do_co Hideki EIRAKU
[not found] ` <20200430.213842.00392641.hdk1983-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-04-30 15:27 ` Tom
2020-04-30 15:27 ` Tom
[not found] ` <ee5677b7-802b-f524-36cc-9d5ae071859b-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-05-31 17:49 ` Ryusuke Konishi
2020-05-31 17:49 ` Ryusuke Konishi
[not found] ` <20200601024013.1296-1-hdanton@sina.com>
[not found] ` <20200601024013.1296-1-hdanton-k+cT0dCbe1g@public.gmane.org>
2020-06-01 11:46 ` Ryusuke Konishi
2020-06-01 11:46 ` Ryusuke Konishi
2020-01-23 13:58 ` BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8 in nilfs_segctor_do_construct ARAI Shun-ichi
[not found] ` <20200123.225827.1155989593018204741.hermes-akuOmOme3sQYOdUovKs6ag@public.gmane.org>
2020-01-23 14:07 ` ARAI Shun-ichi
2020-01-23 14:30 ` ARAI Shun-ichi
2020-01-23 14:30 ` ARAI Shun-ichi
2020-02-10 13:46 ` ARAI Shun-ichi
2020-02-10 13:46 ` ARAI Shun-ichi
[not found] ` <20200210.224609.499887311281343618.hermes-akuOmOme3sQYOdUovKs6ag@public.gmane.org>
2020-02-16 2:10 ` ARAI Shun-ichi
2020-02-16 2:10 ` ARAI Shun-ichi
[not found] ` <20200216.111029.687350152614907818.hermes-akuOmOme3sQYOdUovKs6ag@public.gmane.org>
2020-02-16 2:24 ` Brian G.
2020-02-16 2:24 ` Brian G.
2020-02-16 3:59 ` Ryusuke Konishi
2020-02-16 3:59 ` Ryusuke Konishi
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=20200430.213842.00392641.hdk1983@gmail.com \
--to=hdk1983-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.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.