All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
To: Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
Cc: cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
	devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org,
	kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org,
	netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
	Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,
	Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>
Subject: Re: [PATCH v5 2/2] decrement static keys on real destroy time
Date: Wed, 16 May 2012 22:37:15 -0700	[thread overview]
Message-ID: <20120516223715.5d1b4385.akpm@linux-foundation.org> (raw)
In-Reply-To: <4FB46B4C.3000307-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>

On Thu, 17 May 2012 07:06:52 +0400 Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> wrote:

> ...
> >> +	else if (val != RESOURCE_MAX) {
> >> +		/*
> >> +		 * ->activated needs to be written after the static_key update.
> >> +		 *  This is what guarantees that the socket activation function
> >> +		 *  is the last one to run. See sock_update_memcg() for details,
> >> +		 *  and note that we don't mark any socket as belonging to this
> >> +		 *  memcg until that flag is up.
> >> +		 *
> >> +		 *  We need to do this, because static_keys will span multiple
> >> +		 *  sites, but we can't control their order. If we mark a socket
> >> +		 *  as accounted, but the accounting functions are not patched in
> >> +		 *  yet, we'll lose accounting.
> >> +		 *
> >> +		 *  We never race with the readers in sock_update_memcg(), because
> >> +		 *  when this value change, the code to process it is not patched in
> >> +		 *  yet.
> >> +		 */
> >> +		if (!cg_proto->activated) {
> >> +			static_key_slow_inc(&memcg_socket_limit_enabled);
> >> +			cg_proto->activated = true;
> >> +		}
> >
> > If two threads run this code concurrently, they can both see
> > cg_proto->activated==false and they will both run
> > static_key_slow_inc().
> >
> > Hopefully there's some locking somewhere which prevents this, but it is
> > unobvious.  We should comment this, probably at the cg_proto.activated
> > definition site.  Or we should fix the bug ;)
> >
> If that happens, locking in static_key_slow_inc will prevent any damage.
> My previous version had explicit code to prevent that, but we were 
> pointed out that this is already part of the static_key expectations, so 
> that was dropped.

This makes no sense.  If two threads run that code concurrently,
key->enabled gets incremented twice.  Nobody anywhere has a record that
this happened so it cannot be undone.  key->enabled is now in an
unknown state.


WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Glauber Costa <glommer@parallels.com>
Cc: cgroups@vger.kernel.org, linux-mm@kvack.org, devel@openvz.org,
	kamezawa.hiroyu@jp.fujitsu.com, netdev@vger.kernel.org,
	Tejun Heo <tj@kernel.org>, Li Zefan <lizefan@huawei.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Michal Hocko <mhocko@suse.cz>
Subject: Re: [PATCH v5 2/2] decrement static keys on real destroy time
Date: Wed, 16 May 2012 22:37:15 -0700	[thread overview]
Message-ID: <20120516223715.5d1b4385.akpm@linux-foundation.org> (raw)
In-Reply-To: <4FB46B4C.3000307@parallels.com>

On Thu, 17 May 2012 07:06:52 +0400 Glauber Costa <glommer@parallels.com> wrote:

> ...
> >> +	else if (val != RESOURCE_MAX) {
> >> +		/*
> >> +		 * ->activated needs to be written after the static_key update.
> >> +		 *  This is what guarantees that the socket activation function
> >> +		 *  is the last one to run. See sock_update_memcg() for details,
> >> +		 *  and note that we don't mark any socket as belonging to this
> >> +		 *  memcg until that flag is up.
> >> +		 *
> >> +		 *  We need to do this, because static_keys will span multiple
> >> +		 *  sites, but we can't control their order. If we mark a socket
> >> +		 *  as accounted, but the accounting functions are not patched in
> >> +		 *  yet, we'll lose accounting.
> >> +		 *
> >> +		 *  We never race with the readers in sock_update_memcg(), because
> >> +		 *  when this value change, the code to process it is not patched in
> >> +		 *  yet.
> >> +		 */
> >> +		if (!cg_proto->activated) {
> >> +			static_key_slow_inc(&memcg_socket_limit_enabled);
> >> +			cg_proto->activated = true;
> >> +		}
> >
> > If two threads run this code concurrently, they can both see
> > cg_proto->activated==false and they will both run
> > static_key_slow_inc().
> >
> > Hopefully there's some locking somewhere which prevents this, but it is
> > unobvious.  We should comment this, probably at the cg_proto.activated
> > definition site.  Or we should fix the bug ;)
> >
> If that happens, locking in static_key_slow_inc will prevent any damage.
> My previous version had explicit code to prevent that, but we were 
> pointed out that this is already part of the static_key expectations, so 
> that was dropped.

This makes no sense.  If two threads run that code concurrently,
key->enabled gets incremented twice.  Nobody anywhere has a record that
this happened so it cannot be undone.  key->enabled is now in an
unknown state.


--
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: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
To: Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
Cc: <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	<linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org>,
	<devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>,
	<kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>,
	<netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
	Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,
	Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>
Subject: Re: [PATCH v5 2/2] decrement static keys on real destroy time
Date: Wed, 16 May 2012 22:37:15 -0700	[thread overview]
Message-ID: <20120516223715.5d1b4385.akpm@linux-foundation.org> (raw)
In-Reply-To: <4FB46B4C.3000307-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>

On Thu, 17 May 2012 07:06:52 +0400 Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> wrote:

> ...
> >> +	else if (val != RESOURCE_MAX) {
> >> +		/*
> >> +		 * ->activated needs to be written after the static_key update.
> >> +		 *  This is what guarantees that the socket activation function
> >> +		 *  is the last one to run. See sock_update_memcg() for details,
> >> +		 *  and note that we don't mark any socket as belonging to this
> >> +		 *  memcg until that flag is up.
> >> +		 *
> >> +		 *  We need to do this, because static_keys will span multiple
> >> +		 *  sites, but we can't control their order. If we mark a socket
> >> +		 *  as accounted, but the accounting functions are not patched in
> >> +		 *  yet, we'll lose accounting.
> >> +		 *
> >> +		 *  We never race with the readers in sock_update_memcg(), because
> >> +		 *  when this value change, the code to process it is not patched in
> >> +		 *  yet.
> >> +		 */
> >> +		if (!cg_proto->activated) {
> >> +			static_key_slow_inc(&memcg_socket_limit_enabled);
> >> +			cg_proto->activated = true;
> >> +		}
> >
> > If two threads run this code concurrently, they can both see
> > cg_proto->activated==false and they will both run
> > static_key_slow_inc().
> >
> > Hopefully there's some locking somewhere which prevents this, but it is
> > unobvious.  We should comment this, probably at the cg_proto.activated
> > definition site.  Or we should fix the bug ;)
> >
> If that happens, locking in static_key_slow_inc will prevent any damage.
> My previous version had explicit code to prevent that, but we were 
> pointed out that this is already part of the static_key expectations, so 
> that was dropped.

This makes no sense.  If two threads run that code concurrently,
key->enabled gets incremented twice.  Nobody anywhere has a record that
this happened so it cannot be undone.  key->enabled is now in an
unknown state.

  parent reply	other threads:[~2012-05-17  5:37 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-11 20:11 [PATCH v5 0/2] fix static_key disabling problem in memcg Glauber Costa
2012-05-11 20:11 ` Glauber Costa
2012-05-11 20:11 ` [PATCH v5 1/2] Always free struct memcg through schedule_work() Glauber Costa
2012-05-11 20:11   ` Glauber Costa
2012-05-11 20:11   ` Glauber Costa
     [not found]   ` <1336767077-25351-2-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-05-14  0:56     ` KAMEZAWA Hiroyuki
2012-05-14  0:56       ` KAMEZAWA Hiroyuki
2012-05-11 20:11 ` [PATCH v5 2/2] decrement static keys on real destroy time Glauber Costa
2012-05-11 20:11   ` Glauber Costa
2012-05-11 20:11   ` Glauber Costa
     [not found]   ` <1336767077-25351-3-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-05-14  0:59     ` KAMEZAWA Hiroyuki
2012-05-14  0:59       ` KAMEZAWA Hiroyuki
     [not found]       ` <4FB058D8.6060707-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2012-05-16  6:03         ` Glauber Costa
2012-05-16  6:03           ` Glauber Costa
2012-05-16  6:03           ` Glauber Costa
     [not found]           ` <4FB3431C.3050402-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-05-16  7:04             ` Glauber Costa
2012-05-16  7:04               ` Glauber Costa
2012-05-16  7:04               ` Glauber Costa
     [not found]               ` <4FB3518B.3090205-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-05-16  8:28                 ` KAMEZAWA Hiroyuki
2012-05-16  8:28                   ` KAMEZAWA Hiroyuki
     [not found]                   ` <4FB3652D.2040909-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2012-05-16  8:30                     ` Glauber Costa
2012-05-16  8:30                       ` Glauber Costa
2012-05-16  8:30                       ` Glauber Costa
2012-05-16  8:37                     ` Glauber Costa
2012-05-16  8:37                       ` Glauber Costa
2012-05-16  8:37                       ` Glauber Costa
2012-05-14  1:38     ` Li Zefan
2012-05-14  1:38       ` Li Zefan
     [not found]       ` <4FB0621C.3010604-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2012-05-16  7:03         ` Glauber Costa
2012-05-16  7:03           ` Glauber Costa
2012-05-16  7:03           ` Glauber Costa
2012-05-16 20:57           ` Andrew Morton
2012-05-16 20:57             ` Andrew Morton
2012-05-14 18:12     ` Tejun Heo
2012-05-14 18:12       ` Tejun Heo
2012-05-16 21:06     ` Andrew Morton
2012-05-16 21:06       ` Andrew Morton
2012-05-16 21:06       ` Andrew Morton
2012-05-17  3:06       ` Glauber Costa
2012-05-17  3:06         ` Glauber Costa
2012-05-17  3:06         ` Glauber Costa
     [not found]         ` <4FB46B4C.3000307-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-05-17  5:37           ` Andrew Morton [this message]
2012-05-17  5:37             ` Andrew Morton
2012-05-17  5:37             ` Andrew Morton
     [not found]             ` <20120516223715.5d1b4385.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2012-05-17  9:52               ` Glauber Costa
2012-05-17  9:52                 ` Glauber Costa
2012-05-17  9:52                 ` Glauber Costa
2012-05-17 10:18                 ` KAMEZAWA Hiroyuki
     [not found]                   ` <4FB4D061.10406-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2012-05-17 10:22                     ` Glauber Costa
2012-05-17 10:22                       ` Glauber Costa
2012-05-17 10:22                       ` Glauber Costa
     [not found]                       ` <4FB4D14D.4020303-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-05-17 10:27                         ` KAMEZAWA Hiroyuki
2012-05-17 10:27                           ` KAMEZAWA Hiroyuki
2012-05-17 15:19                 ` Tejun Heo
2012-05-17 17:02                 ` Andrew Morton
2012-05-17 17:02                   ` Andrew Morton
2012-05-16 21:13   ` Andrew Morton
2012-05-16 21:13     ` Andrew Morton
     [not found]     ` <20120516141342.911931e7.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2012-05-17  0:07       ` KAMEZAWA Hiroyuki
2012-05-17  0:07         ` KAMEZAWA Hiroyuki
2012-05-17  3:09       ` Glauber Costa
2012-05-17  3:09         ` Glauber Costa
2012-05-17  3:09         ` Glauber Costa

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=20120516223715.5d1b4385.akpm@linux-foundation.org \
    --to=akpm-de/tnxtf+jlsfhdxvbkv3wd2fqjk+8+b@public.gmane.org \
    --cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org \
    --cc=glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org \
    --cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
    --cc=kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org \
    --cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
    --cc=lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
    --cc=mhocko-AlSwsSmVLrQ@public.gmane.org \
    --cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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.