From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
To: Miles Lane <miles.lane@gmail.com>
Cc: Andi Kleen <andi@firstfloor.org>,
LKML <linux-kernel@vger.kernel.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Greg Kroah-Hartman <gregkh@suse.de>,
"Li, Shaohua" <shaohua.li@intel.com>,
Dave Jones <davej@redhat.com>
Subject: Re: 2.6.33-rc4-git7 -- head/6104 is trying to acquire lock: (cpuidle_lock){+.+.+.}, at: [<c129e2ec>] show_current_governor+0x12/0x4e
Date: Fri, 22 Jan 2010 17:34:10 -0800 [thread overview]
Message-ID: <1264210450.16916.321.camel@localhost.localdomain> (raw)
In-Reply-To: <1264124005.16916.301.camel@localhost.localdomain>
On Thu, 2010-01-21 at 17:33 -0800, Pallipadi, Venkatesh wrote:
> On Thu, 2010-01-21 at 11:18 -0800, Dave Jones wrote:
> > On Thu, Jan 21, 2010 at 12:50:09PM -0500, Miles Lane wrote:
> > > I was scanning the first few characters of all the files in /proc and
> > > /sys. I will attempt to determine which file(s) triggered this.
> >
> >
> > Dropped cpufreq-list from Cc, added cpuidle maintainers.
> > While they sound similar, they are unrelated.
>
> Thanks for reporting the problem. I am able to reproduce this locally.
> Will followup once I have some time to poke at it a bit more.
>
This lockdep message started with Eric's
sysfs: Add lockdep annotations for the sysfs active reference
patch.
But, this looks like a false positive to me. Eric, can you please take a
look at this? I am not a sysfs expert, so I may be overlooking something
obvious here...
The sysfs usage is cpuidle is like below
/sys/devices/system/cpu/cpuidle
/sys/devices/system/cpu/cpuidle/current_driver
/sys/devices/system/cpu/cpuidle/current_governor_ro
/sys/devices/system/cpu/cpu0/cpuidle
/sys/devices/system/cpu/cpu0/cpuidle/state0
/sys/devices/system/cpu/cpu0/cpuidle/state0/desc
/sys/devices/system/cpu/cpu0/cpuidle/state0/latency
/sys/devices/system/cpu/cpu0/cpuidle/state0/name
/sys/devices/system/cpu/cpu0/cpuidle/state0/power
/sys/devices/system/cpu/cpu0/cpuidle/state0/time
/sys/devices/system/cpu/cpu0/cpuidle/state0/usage
: :
/sys/devices/system/cpu/cpu0/cpuidle/stateN
: :
/sys/devices/system/cpu/cpuM/cpuidle
: :
The lockdep complaint here happens when
#cat /sys/devices/system/cpu/cpuidle/current_governor_ro
as, the code there takes mutex_lock in .show
[ 606.464855] -> #0 (cpuidle_lock){+.+.+.}:
[ 606.464857] [<ffffffff8106a16b>] __lock_acquire+0x11b3/0x17e5
[ 606.464860] [<ffffffff8106a861>] lock_acquire+0xc4/0xe1
[ 606.464862] [<ffffffff815f4825>] mutex_lock_nested+0x69/0x2dc
[ 606.464866] [<ffffffff814ff32c>] show_current_governor+0x1f/0x68
[ 606.464868] [<ffffffff81372408>] sysdev_class_show+0x25/0x27
[ 606.464872] [<ffffffff8112d6c6>] sysfs_read_file+0xbf/0x141
[ 606.464875] [<ffffffff810dec63>] vfs_read+0xb0/0x14c
[ 606.464879] [<ffffffff810dedcd>] sys_read+0x4c/0x74
and
lockdep has already seen lock is held during add/remove
of /sys/devices/system/cpu/cpu0/cpuidle/state0/*
in other part of the code
[ 606.464805] -> #1 (s_active){++++.+}:
[ 606.464807] [<ffffffff8106a446>] __lock_acquire+0x148e/0x17e5
[ 606.464812] [<ffffffff8106a861>] lock_acquire+0xc4/0xe1
[ 606.464814] [<ffffffff8112e933>] sysfs_addrm_finish+0xd2/0x15c
[ 606.464816] [<ffffffff8112ea85>] sysfs_remove_dir+0x7a/0x8d
[ 606.464819] [<ffffffff812194e7>] kobject_del+0x16/0x37
[ 606.464823] [<ffffffff81219546>] kobject_release+0x3e/0x67
[ 606.464825] [<ffffffff8121a389>] kref_put+0x43/0x4f
[ 606.464827] [<ffffffff81219462>] kobject_put+0x47/0x4b
[ 606.464830] [<ffffffff814ff030>] cpuidle_remove_state_sysfs+0x30/0x69
[ 606.464832] [<ffffffff814fe87a>] cpuidle_disable_device+0x4a/0x54
[ 606.464835] [<ffffffff814fec84>] cpuidle_switch_governor+0x40/0x15b
[ 606.464837] [<ffffffff814fef09>] cpuidle_register_governor+0xc0/0xdf
[ 606.464839] [<ffffffff81c6a884>] init_menu+0x10/0x12
[ 606.464844] [<ffffffff810001fa>] do_one_initcall+0x5f/0x154
[ 606.464848] [<ffffffff81c3c6a3>] kernel_init+0x198/0x1ed
[ 606.464852] [<ffffffff81003014>] kernel_thread_helper+0x4/0x10
lock is not held in the .show functions
of /sys/devices/system/cpu/cpu*/cpuidle/state*/*
And the add of /sys/devices/system/cpu/cpuidle/* happens in core_init
call without the lock held. And this dir never gets removed.
I don't seem to see any deadlock possibility across the two sysfs dirs
here. Am I missing something related to how sysfs works?
Thanks,
Venki
prev parent reply other threads:[~2010-01-23 1:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-21 17:50 2.6.33-rc4-git7 -- head/6104 is trying to acquire lock: (cpuidle_lock){+.+.+.}, at: [<c129e2ec>] show_current_governor+0x12/0x4e Miles Lane
2010-01-21 19:18 ` Dave Jones
2010-01-22 1:33 ` Pallipadi, Venkatesh
2010-01-23 1:34 ` Pallipadi, Venkatesh [this message]
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=1264210450.16916.321.camel@localhost.localdomain \
--to=venkatesh.pallipadi@intel.com \
--cc=andi@firstfloor.org \
--cc=davej@redhat.com \
--cc=ebiederm@xmission.com \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=miles.lane@gmail.com \
--cc=shaohua.li@intel.com \
--cc=viro@zeniv.linux.org.uk \
/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.