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: Fri, 20 Jan 2012 12:40:32 -0800 [thread overview]
Message-ID: <m1k44mt8e7.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <alpine.DEB.2.00.1201200848040.25882@router.home> (Christoph Lameter's message of "Fri, 20 Jan 2012 08:49:57 -0600 (CST)")
Christoph Lameter <cl@linux.com> writes:
> On Thu, 19 Jan 2012, Eric W. Biederman wrote:
>
>> 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.
>
> Ok then I guess my last patch is needed to make sysfs operations safe.
>
> It may be good to audit the kernel for locks being held while calling
> sysfs functions. Isnt there a lockdep check that ensures that no locks are
> held?
I don't see a no locks are held check but call_usermodehelper in the
blocking case could certainly use one.
For the sysfs remove case lockdep should work.
Eric
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
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: Fri, 20 Jan 2012 12:40:32 -0800 [thread overview]
Message-ID: <m1k44mt8e7.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <alpine.DEB.2.00.1201200848040.25882@router.home> (Christoph Lameter's message of "Fri, 20 Jan 2012 08:49:57 -0600 (CST)")
Christoph Lameter <cl@linux.com> writes:
> On Thu, 19 Jan 2012, Eric W. Biederman wrote:
>
>> 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.
>
> Ok then I guess my last patch is needed to make sysfs operations safe.
>
> It may be good to audit the kernel for locks being held while calling
> sysfs functions. Isnt there a lockdep check that ensures that no locks are
> held?
I don't see a no locks are held check but call_usermodehelper in the
blocking case could certainly use one.
For the sysfs remove case lockdep should work.
Eric
next prev parent reply other threads:[~2012-01-20 20:40 UTC|newest]
Thread overview: 45+ 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 16:30 ` Sasha Levin
2012-01-14 17:10 ` Eric Dumazet
2012-01-14 17:10 ` Eric Dumazet
2012-01-14 17:10 ` Eric Dumazet
2012-01-14 17:18 ` Eric Dumazet
2012-01-14 17:18 ` Eric Dumazet
2012-01-14 17:18 ` Eric Dumazet
2012-01-15 12:59 ` Sasha Levin
2012-01-15 12:59 ` Sasha Levin
2012-01-15 17:25 ` Eric Dumazet
2012-01-15 17:25 ` Eric Dumazet
2012-01-15 17:25 ` Eric Dumazet
2012-01-17 15:12 ` Christoph Lameter
2012-01-17 15:12 ` Christoph Lameter
2012-01-17 15:20 ` Eric Dumazet
2012-01-17 15:20 ` Eric Dumazet
2012-01-17 15:20 ` Eric Dumazet
2012-01-17 15:27 ` Christoph Lameter
2012-01-17 15:27 ` Christoph Lameter
2012-01-17 15:30 ` Eric Dumazet
2012-01-17 15:30 ` Eric Dumazet
2012-01-17 15:30 ` Eric Dumazet
2012-01-17 16:04 ` Christoph Lameter
2012-01-17 16:04 ` Christoph Lameter
2012-01-17 22:22 ` Christoph Lameter
2012-01-17 22:22 ` Christoph Lameter
2012-01-19 21:43 ` Eric W. Biederman
2012-01-19 21:43 ` Eric W. Biederman
2012-01-19 22:15 ` Eric W. Biederman
2012-01-19 22:15 ` Eric W. Biederman
2012-01-20 2:03 ` Christoph Lameter
2012-01-20 2:03 ` Christoph Lameter
2012-01-20 2:31 ` Eric W. Biederman
2012-01-20 2:31 ` Eric W. Biederman
2012-01-20 14:49 ` Christoph Lameter
2012-01-20 14:49 ` Christoph Lameter
2012-01-20 20:40 ` Eric W. Biederman [this message]
2012-01-20 20:40 ` Eric W. Biederman
2012-02-01 8:05 ` Pekka Enberg
2012-02-01 8:05 ` Pekka Enberg
2012-02-01 17:32 ` Eric W. Biederman
2012-02-01 17:32 ` Eric W. Biederman
2012-02-01 8:07 ` Pekka Enberg
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=m1k44mt8e7.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 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.