Modify

Opened 8 years ago

Closed 6 years ago

Last modified 4 years ago

#6125 closed defect (wontfix)

Lockdep warning in mini_fo on ar71xx

Reported by: Will Dyson <will.dyson@…> Owned by: developers
Priority: normal Milestone: Chaos Calmer 15.05
Component: kernel Version:
Keywords: mini_fo ar71xx Cc:

Description

After building an openwrt image with linux's lockdep features enabled, I see a lockdep warning in the log after flashing the firmware (and keeping settings).

jffs2_scan_eraseblock(): End of filesystem marker found at 0x10000
jffs2_build_filesystem(): unlocking the mtd device... done.
jffs2_build_filesystem(): erasing all blocks after the end marker... done.
mini_fo: using base directory: /
mini_fo: using storage directory: /jffs

=============================================
[ INFO: possible recursive locking detected ]
2.6.30.9 #2


tar/314 is trying to acquire lock:

(&sb->s_type->i_mutex_key#9){+.+.+.}, at: [<80135ca4>] meta_build_lists+0xa8/0x37c

but task is already holding lock:

(&sb->s_type->i_mutex_key#9){+.+.+.}, at: [<8013c228>] build_sto_structure+0x10c/0x400

other info that might help us debug this:
3 locks held by tar/314:

#0: (&sb->s_type->i_mutex_key#8/1){+.+.+.}, at: [<800f1688>] do_unlinkat+0x5c/0x174
#1: (&sb->s_type->i_mutex_key#8){+.+.+.}, at: [<800ef4e0>] vfs_unlink+0x50/0xbc
#2: (&sb->s_type->i_mutex_key#9){+.+.+.}, at: [<8013c228>] build_sto_structure+0x10c/0x400

stack backtrace:
Call Trace:
[<80067d90>] dump_stack+0x8/0x34
[<800ab244>] lock_acquire+0x167c/0x1744
[<800ab368>] lock_acquire+0x5c/0x84
[<800694f4>] mutex_lock_nested+0x70/0x344
[<80135ca4>] meta_build_lists+0xa8/0x37c
[<8013c310>] build_sto_structure+0x1f4/0x400
[<8013c59c>] get_neg_sto_dentry+0x80/0x134
[<8013aea4>] nondir_unmod_to_del+0x5c/0xb4
[<801394dc>] mini_fo_unlink+0x78/0x1fc
[<800ef500>] vfs_unlink+0x70/0xbc
[<800f1700>] do_unlinkat+0xd4/0x174
[<80062778>] stack_done+0x20/0x3c

Attachments (1)

boot.log (10.1 KB) - added by Will Dyson <will.dyson@…> 8 years ago.
Full boot log

Download all attachments as: .zip

Change History (11)

Changed 8 years ago by Will Dyson <will.dyson@…>

Full boot log

comment:1 Changed 8 years ago by psvopenwrt@…

Bug 5864 indicates that there may be more recursive locking in mini_fo.

comment:2 Changed 8 years ago by Will Dyson <will.dyson@…>

r19203 is the fix for this! Thanks!

comment:3 Changed 8 years ago by nbd

  • Resolution set to fixed
  • Status changed from new to closed

comment:4 Changed 6 years ago by lwang998@…

  • Resolution fixed deleted
  • Status changed from closed to reopened

Hi,developer
I encounter this problem again on octeon CN52xx,even though my platform is after r19203.
my SDK base on OpenWrt rc4(svn version r24064)

log information as follow:
===============================

eth1: 0 Mbps Half duplex, port 1, queue 1
eth2: 0 Mbps Half duplex, port 2, queue 2
eth3: 0 Mbps Half duplex, port 3, queue 3

  • preinit -

Press the [f] key and hit [enter] to enter failsafe mode

  • regular preinit -

jffs2_scan_eraseblock(): End of filesystem marker found at 0x20000
jffs2_build_filesystem(): unlocking the mtd device... done.
jffs2_build_filesystem(): erasing all blocks after the end marker... eth0: 100 Mbps Full duplex, port 0, queue 0
done.
switching to jffs2
mini_fo: using base directory: /
mini_fo: using storage directory: /overlay

  • config restore -

=============================================
[ INFO: possible recursive locking detected ]
2.6.30.10 #24


tar/1428 is trying to acquire lock:

(&sb->s_type->i_mutex_key#8){+.+.+.}, at: [<ffffffff812265a8>] meta_build_lists+0xa8/0x37c

but task is already holding lock:

(&sb->s_type->i_mutex_key#8){+.+.+.}, at: [<ffffffff8122ca30>] build_sto_structure+0x14c/0x414

other info that might help us debug this:
3 locks held by tar/1428:

#0: (&sb->s_type->i_mutex_key#7/1){+.+.+.}, at: [<ffffffff811d60dc>] do_unlinkat+0x5c/0x174
#1: (&sb->s_type->i_mutex_key#7){+.+.+.}, at: [<ffffffff811d3e50>] vfs_unlink+0x50/0xd0
#2: (&sb->s_type->i_mutex_key#8){+.+.+.}, at: [<ffffffff8122ca30>] build_sto_structure+0x14c/0x414

stack backtrace:
Call Trace:
[<ffffffff8110b6f8>] dump_stack+0x8/0x34
[<ffffffff811747e0>] lock_acquire+0x18d4/0x1a6c
[<ffffffff81174a64>] lock_acquire+0xec/0x12c
[<ffffffff8110d460>] mutex_lock_nested+0x6c/0x3b8
[<ffffffff812265a8>] meta_build_lists+0xa8/0x37c
[<ffffffff8122cb10>] build_sto_structure+0x22c/0x414
[<ffffffff8122cd78>] get_neg_sto_dentry+0x80/0x12c
[<ffffffff8122b710>] nondir_unmod_to_del+0x60/0xb8
[<ffffffff81229c90>] mini_fo_unlink+0x78/0x1f8
[<ffffffff811d3e70>] vfs_unlink+0x70/0xd0
[<ffffffff811d6154>] do_unlinkat+0xd4/0x174
[<ffffffff81102e44>] handle_sys64+0x44/0x60

  • init -

Please press Enter to activate this console. device eth0 entered promiscuous mode
br-lan: port 1(eth0) entering forwarding state

APROCLOG@awrt_procfs_modu[0154]: Module Init

comment:5 follow-up: Changed 6 years ago by kaloz

are you using backfire as a base for your SDK?

comment:6 Changed 6 years ago by anonymous

yes,from the .config as follow:

#
# Automatically generated make config: don't edit
# OpenWrt version: Backfire (r32)
# Mon May 2 08:57:12 2011
#

comment:7 Changed 6 years ago by kaloz

  • Milestone changed from Attitude Adjustment (trunk) to Backfire 10.03.2

I would suggest thinking about migrating your SDK to trunk, which uses overlayfs instead of mini_fo.

comment:8 in reply to: ↑ 5 Changed 6 years ago by anonymous

ok,let me try and thank u very much

comment:9 Changed 6 years ago by nbd

  • Resolution set to wontfix
  • Status changed from reopened to closed

comment:10 Changed 4 years ago by jow

  • Milestone changed from Backfire 10.03.2 to Chaos Calmer (trunk)

Milestone Backfire 10.03.2 deleted

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.