From: ebiederm@xmission.com (Eric W. Biederman)
To: Christoph Lameter <cl@linux.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
Sasha Levin <levinsasha928@gmail.com>,
Dave Jones <davej@redhat.com>, davem <davem@davemloft.net>,
Pekka Enberg <penberg@kernel.org>, Matt Mackall <mpm@selenic.com>,
kaber@trash.net, pablo@netfilter.org,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
netfilter-devel@vger.kernel.org, netdev <netdev@vger.kernel.org>
Subject: Re: Hung task when calling clone() due to netfilter/slab
Date: Thu, 19 Jan 2012 18:31:30 -0800 [thread overview]
Message-ID: <m1y5t3yuil.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <alpine.DEB.2.00.1201191959540.14480@router.home> (Christoph Lameter's message of "Thu, 19 Jan 2012 20:03:51 -0600 (CST)")
Christoph Lameter <cl@linux.com> writes:
> On Thu, 19 Jan 2012, Eric W. Biederman wrote:
>
>> Oh. I see. The problem is calling kobject_uevent (which happens to
>> live in slabs sysfs_slab_add) with a lock held. And kobject_uevent
>> makes a blocking call to userspace.
>>
>> No locks held seems to be a good policy on that one.
>
> Well we can just remove that call to kobject_uevent instead then. Does it
> do anything useful? Cannot remember why we put that in there.
Empirically it sounds like something is listening for it and doing cat
/proc/slabinfo. Something like that would have to occur for their to be
a deadlock that was observed.
On the flip side removing from sysfs with locks held must be done
carefully, and as a default I would recommend not to hold locks over
removing things from sysfs. As removal blocks waiting for all of the
callers into sysfs those sysfs attributes to complete.
It looks like you are ok on the removal because none of the sysfs
attributes appear to take the slub_lock, just /proc/slabinfo. But
it does look like playing with fire.
Eric
next prev parent reply other threads:[~2012-01-20 2:29 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-14 16:30 Hung task when calling clone() due to netfilter/slab Sasha Levin
2012-01-14 17:10 ` Eric Dumazet
2012-01-14 17:18 ` Eric Dumazet
2012-01-15 12:59 ` Sasha Levin
2012-01-15 17:25 ` Eric Dumazet
2012-01-17 15:12 ` Christoph Lameter
2012-01-17 15:20 ` Eric Dumazet
2012-01-17 15:27 ` Christoph Lameter
2012-01-17 15:30 ` Eric Dumazet
2012-01-17 16:04 ` Christoph Lameter
2012-01-17 22:22 ` Christoph Lameter
2012-01-19 21:43 ` Eric W. Biederman
2012-01-19 22:15 ` Eric W. Biederman
2012-01-20 2:03 ` Christoph Lameter
2012-01-20 2:31 ` Eric W. Biederman [this message]
2012-01-20 14:49 ` Christoph Lameter
2012-01-20 20:40 ` Eric W. Biederman
2012-02-01 8:05 ` Pekka Enberg
2012-02-01 17:32 ` Eric W. Biederman
2012-02-01 8:07 ` Pekka Enberg
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=m1y5t3yuil.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=cl@linux.com \
--cc=davej@redhat.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=kaber@trash.net \
--cc=levinsasha928@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mpm@selenic.com \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
--cc=penberg@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).