Linux-f2fs-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: linux-f2fs-devel@lists.sourceforge.net
Subject: [f2fs-dev] [Bug 210745] kernel crash during umounting a partition with f2fs filesystem
Date: Mon, 21 Dec 2020 08:09:23 +0000	[thread overview]
Message-ID: <bug-210745-202145-n5dTGYBCLN@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-210745-202145@https.bugzilla.kernel.org/>

https://bugzilla.kernel.org/show_bug.cgi?id=210745

--- Comment #2 from Zhiguo.Niu (Zhiguo.Niu@unisoc.com) ---
(In reply to Chao Yu from comment #1)
> Hi,
> 
> I checked the code of 4.14.193, I don't have any clue about why this can
> happen,
> and I don't remember that there is such corruption condition occured on nid
> list, because all its update is under nat_tree_lock, let me know if I missed
> something.
> 
> Do you apply private patch on 4.14.193?


hi Chao, 

Thanks for your reply, I have checked my codebase, there is no any other
private patches in current version.

I find that local variables natvec & setvec in f2fs_destroy_node_manager may be
inited as 0xaa and 0xaaaaaaaaaaaaaaaa, just like :

void f2fs_destroy_node_manager(struct f2fs_sb_info *sbi)
{
        struct f2fs_nm_info *nm_i = NM_I(sbi);
        struct free_nid *i, *next_i;
        struct nat_entry *natvec[NATVEC_SIZE];
        struct nat_entry_set *setvec[SETVEC_SIZE];

dis:
crash_arm64> dis f2fs_destroy_node_manager
0xffffff800842e2a8 <f2fs_destroy_node_manager>: stp     x29, x30, [sp,#-96]!
0xffffff800842e2ac <f2fs_destroy_node_manager+4>:       stp     x28, x27,
[sp,#16]
0xffffff800842e2b0 <f2fs_destroy_node_manager+8>:       stp     x26, x25,
[sp,#32]
0xffffff800842e2b4 <f2fs_destroy_node_manager+12>:      stp     x24, x23,
[sp,#48]
0xffffff800842e2b8 <f2fs_destroy_node_manager+16>:      stp     x22, x21,
[sp,#64]
0xffffff800842e2bc <f2fs_destroy_node_manager+20>:      stp     x20, x19,
[sp,#80]
0xffffff800842e2c0 <f2fs_destroy_node_manager+24>:      mov     x29, sp
0xffffff800842e2c4 <f2fs_destroy_node_manager+28>:      sub     sp, sp, #0x320
0xffffff800842e2c8 <f2fs_destroy_node_manager+32>:      adrp    x8,
0xffffff800947e000 <xt_connlimit_locks+768>
0xffffff800842e2cc <f2fs_destroy_node_manager+36>:      ldr     x8, [x8,#264]
0xffffff800842e2d0 <f2fs_destroy_node_manager+40>:      mov     x27, x0
0xffffff800842e2d4 <f2fs_destroy_node_manager+44>:      str     x8, [x29,#-16]
0xffffff800842e2d8 <f2fs_destroy_node_manager+48>:      nop
0xffffff800842e2dc <f2fs_destroy_node_manager+52>:      ldr     x20, [x27,#112]
0xffffff800842e2e0 <f2fs_destroy_node_manager+56>:      add     x0, sp, #0x110
0xffffff800842e2e4 <f2fs_destroy_node_manager+60>:      mov     w1, #0xaa      
                // #170
0xffffff800842e2e8 <f2fs_destroy_node_manager+64>:      mov     w2, #0x200     
                // #512
0xffffff800842e2ec <f2fs_destroy_node_manager+68>:      bl     
0xffffff8008be6b80 <__memset>
0xffffff800842e2f0 <f2fs_destroy_node_manager+72>:      mov     x8,
#0xaaaaaaaaaaaaaaaa         // #-6148914691236517206
0xffffff800842e2f4 <f2fs_destroy_node_manager+76>:      stp     x8, x8,
[sp,#256]
0xffffff800842e2f8 <f2fs_destroy_node_manager+80>:      stp     x8, x8,
[sp,#240]
0xffffff800842e2fc <f2fs_destroy_node_manager+84>:      stp     x8, x8,
[sp,#224]
0xffffff800842e300 <f2fs_destroy_node_manager+88>:      stp     x8, x8,
[sp,#208]
0xffffff800842e304 <f2fs_destroy_node_manager+92>:      stp     x8, x8,
[sp,#192]
0xffffff800842e308 <f2fs_destroy_node_manager+96>:      stp     x8, x8,
[sp,#176]
0xffffff800842e30c <f2fs_destroy_node_manager+100>:     stp     x8, x8,
[sp,#160]
0xffffff800842e310 <f2fs_destroy_node_manager+104>:     stp     x8, x8,
[sp,#144]
0xffffff800842e314 <f2fs_destroy_node_manager+108>:     stp     x8, x8,
[sp,#128]
0xffffff800842e318 <f2fs_destroy_node_manager+112>:     stp     x8, x8,
[sp,#112]
0xffffff800842e31c <f2fs_destroy_node_manager+116>:     stp     x8, x8,
[sp,#96]
0xffffff800842e320 <f2fs_destroy_node_manager+120>:     stp     x8, x8,
[sp,#80]
0xffffff800842e324 <f2fs_destroy_node_manager+124>:     stp     x8, x8,
[sp,#64]
0xffffff800842e328 <f2fs_destroy_node_manager+128>:     stp     x8, x8,
[sp,#48]
0xffffff800842e32c <f2fs_destroy_node_manager+132>:     stp     x8, x8,
[sp,#32]
0xffffff800842e330 <f2fs_destroy_node_manager+136>:     stp     x8, x8,
[sp,#16]

I am not sure this is the root cause about this issue, because these invalid
entry can be found in nat_root radix tree of f2fs_nm_info

thanks!

thanks!

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

  parent reply	other threads:[~2020-12-21  8:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-17  6:43 [f2fs-dev] [Bug 210745] New: kernel crash during umounting a partition with f2fs filesystem bugzilla-daemon
2020-12-18 10:27 ` [f2fs-dev] [Bug 210745] " bugzilla-daemon
2020-12-21  8:09 ` bugzilla-daemon [this message]
2020-12-21  8:29 ` bugzilla-daemon
2020-12-21  8:44 ` bugzilla-daemon

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=bug-210745-202145-n5dTGYBCLN@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@bugzilla.kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox