Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp1966240ybz; Thu, 30 Apr 2020 08:31:54 -0700 (PDT) X-Google-Smtp-Source: APiQypJFWoXpIQx3z9p8XT2q4jPD/wgQ2OGAIl18/R4Y/ykTlHCrUiHyZdp8XAJ9xD30ke9DOH6C X-Received: by 2002:a05:6402:b82:: with SMTP id cf2mr3109590edb.49.1588260714544; Thu, 30 Apr 2020 08:31:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588260714; cv=none; d=google.com; s=arc-20160816; b=WiLcsFNqgMfJ7RXmmG5m/tiZ9e9jtGpPP4qT/uJ+U+lgkM+NfGnBC5QTA7tuxjwMSd uF0r6KZCrFrZke66CBS+uGbV9xIgfNgIM86vZmTpAw2Q6uDxH+SMz7mFNoWbUPxGtfhq 2khJsX3FPMk13YIUWfAnPqffjAMOiQcultnJioIq4giHKBQWd32BWu5z5e++YESMKXO+ 3RVQtn6LFfEDBU8X8yWCuw2lowlgoq3qiMxpfZLIoXlRgeDEr3JJK4UeKT5pJKaJJIP/ UNoJWkkQSxt86Z5A1dT3VlHP/X/TRcJldvOP3Mandc5x1mTI+zOUJknDrEDYSYmJZoCx B4nQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=h7aecSn7WemaPr5MKAU25qlIzkvX9/7QdX+8sxse6As=; b=YG1NykJQHuT5xh3FBO67RdpWpWSeNE2FJbE2L17xSEomv63a465JL3oaKHL1h5CZnb SlMxuDpLud/dP56GTpIwdauIUtFNOv7KcU3upj7zzKd+QJPGexl0RwghbvXYGBTZ7djJ hcm1wu+N+ZCtjNedv+04FYJctq+cU3PFJgvT+PGbXZdgPObrrTZsjnMkzF4908s650pC 7oAUjtH7H+jYQpCWT1Ne9Fge7ljEaTYi0j1QnARe8l4iR7Tr0qV3Rwzd53gxmRk9fjow De1EA7hXmn9x5bEiUHA0RnzYyLKZasgxT89ONgkB8mcLLkH256XUVtaIG6l7BUtZp97a bfKw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=RI0twVI0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s26si5308599edq.433.2020.04.30.08.31.30; Thu, 30 Apr 2020 08:31:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=RI0twVI0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727119AbgD3P1x (ORCPT + 99 others); Thu, 30 Apr 2020 11:27:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41730 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726318AbgD3P1x (ORCPT ); Thu, 30 Apr 2020 11:27:53 -0400 Received: from mail-pj1-x1041.google.com (mail-pj1-x1041.google.com [IPv6:2607:f8b0:4864:20::1041]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3AA30C035494; Thu, 30 Apr 2020 08:27:53 -0700 (PDT) Received: by mail-pj1-x1041.google.com with SMTP id fu13so834721pjb.5; Thu, 30 Apr 2020 08:27:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=h7aecSn7WemaPr5MKAU25qlIzkvX9/7QdX+8sxse6As=; b=RI0twVI0BCbvsJGtmfAURnVd29jYqM/+tPwkK6KWFVPzAsJUtQO+isXMTV5bxrTixq IEi4hZENsklYeP6tC5frsru0LnToqen1Mmu5G25ZTukvm1eQ5E9sTcECsNVSRSTHjfs6 OSelV67AYFF2IG4iYEyGFbMbRLlp18AgzPfij6hW3M92CTGsTFmkc5N1QMlvHTI65qKD 1IIDHIHH2XT0eDme/InswnMbTsndIVcx/qXa9HZk4kTuMKIrNCbYf4L/5IWqv+5TU+4j xzEhFuekRqi2jKQCgBcIJ6hJeeXDuS+VJtgQGlTu2QURv9p3fS2qKv2tNa8g1zjvQAeG g8sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=h7aecSn7WemaPr5MKAU25qlIzkvX9/7QdX+8sxse6As=; b=rkVN9gy526efa75nYVZy91YuRnV3g+/PiJGH6CDxM1ZEtDCg/gOoiSA1UAG5wtGcX+ 928IrwtYiVLSDXTRCnvAn758Fz9gzvW08o9orZh1d5sXm8MAszGUOzZ4tsBThEPDIRUr YH0M6CKxbFvfOH9nmo42qs1veTK0JTTY79ccJ6//b/KNSYjgm3ivSAck8T4chFy8fjj0 50Jlcw1Nt+cTNpEqRamjNKlFWaOovy1FjAxzJ6NrcH/os6o33O3xpocIOUHQ22yCmqcV CMc7FMCD3CYchR/CXfIVE8avqkupM6cWOXIqSqKwFLv/sbz0CTfH2yS84Huz55gO6jDM IL5A== X-Gm-Message-State: AGi0PuY2NzzGgJM5XQlvc3TMst813yWfR2urIp93qP5mg+uEZM2rz5bG +gxs2zzSacLfVSO8H9f8Rsly4Vy48Fg= X-Received: by 2002:a17:902:d70f:: with SMTP id w15mr4420618ply.55.1588260469297; Thu, 30 Apr 2020 08:27:49 -0700 (PDT) Received: from [192.168.1.159] (ip70-185-146-31.sb.sd.cox.net. [70.185.146.31]) by smtp.gmail.com with ESMTPSA id q64sm150019pfc.112.2020.04.30.08.27.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Apr 2020 08:27:48 -0700 (PDT) Subject: Re: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8 in nilfs_segctor_do_co To: Hideki EIRAKU , linux-nilfs@vger.kernel.org Cc: linux-kernel@vger.kernel.org References: <20200328.182640.1933740379722138264.hermes@ceres.dti.ne.jp> <20200430.213842.00392641.hdk1983@gmail.com> From: Tom Message-ID: Date: Thu, 30 Apr 2020 08:27:47 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200430.213842.00392641.hdk1983@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thank you! This is very helpful information, and does seem to be a workaround. Like you, I have my home directory on a separate NILFS2 filesystem. As a temporary solution, I removed the line from /etc/fstab for that filesystem and added your dd suggestion along with a manual mount of the home filesystem to /etc/rc.local. /home is now mounted properly at boot with any of the newer kernels I tried. Thanks, Tom On 4/30/20 5:38 AM, Hideki EIRAKU wrote: >> 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 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. >