Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Roman Gushchin <guro@fb.com>
To:     Shakeel Butt <shakeelb@google.com>
CC:     Johannes Weiner <hannes@cmpxchg.org>,
        Linux MM <linux-mm@kvack.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Michal Hocko <mhocko@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Kernel Team <Kernel-team@fb.com>,
        "stable@vger.kernel.org" <stable@vger.kernel.org>,
        Tejun Heo <tj@kernel.org>
Subject: Re: [PATCH 1/2] mm: memcg: switch to css_tryget() in
 get_mem_cgroup_from_mm()
Thread-Topic: [PATCH 1/2] mm: memcg: switch to css_tryget() in
 get_mem_cgroup_from_mm()
Thread-Index: AQHVlPTSqR6tDyqEq0WgIBYYtGCX/Kd+2NkAgAARtACAAATxgA==
Date:   Thu, 7 Nov 2019 01:43:14 +0000
Message-ID: <20191107014307.GA1158@castle.dhcp.thefacebook.com>
References: <20191106225131.3543616-1-guro@fb.com>
 <20191107002204.GA96548@cmpxchg.org>
 <CALvZod5=g230Lwnjh7qXyLkoknZJpOiv-nLJ4XYC9rSSzL=e6w@mail.gmail.com>
In-Reply-To: <CALvZod5=g230Lwnjh7qXyLkoknZJpOiv-nLJ4XYC9rSSzL=e6w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2620:10d:c090:180::1716]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b10c3a4a-6a29-4b0c-c787-08d76323daeb
x-ms-traffictypediagnostic: BN8PR15MB3121:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BN8PR15MB31219716CFED0987E7273848BE780@BN8PR15MB3121.namprd15.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 0214EB3F68
x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(39860400002)(366004)(136003)(396003)(346002)(376002)(199004)(189003)(86362001)(8936002)(4326008)(8676002)(5660300002)(71200400001)(305945005)(6116002)(81166006)(14454004)(66946007)(316002)(64756008)(1076003)(54906003)(66556008)(229853002)(66446008)(66476007)(71190400001)(46003)(33656002)(186003)(446003)(6436002)(6916009)(486006)(6246003)(476003)(256004)(99286004)(11346002)(6486002)(81156014)(6506007)(53546011)(76176011)(2906002)(386003)(7736002)(25786009)(478600001)(52116002)(102836004)(9686003)(6512007);DIR:OUT;SFP:1102;SCL:1;SRVR:BN8PR15MB3121;H:BN8PR15MB2626.namprd15.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:1;MX:1;
received-spf: None (protection.outlook.com: fb.com does not designate
 permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: FpcXEqc3WTEWNaInBWX/cQaCziujdOwcd2N6exj1/SnFbRaMlcnFMNxk3JMmhTCP4Of0VfhCMMW0ZeyyFNMXmJ/naLaVEQS5xrShDQx5DFFdKPYapgZuDjG8orPi3YtVABJ9rdr1z/GcEY9UClIQG9EDjd7Z74cYiEq0dGty65qk26mZl/KZnr4FCDiSjaGV233/SPQ7Pu+0YXiZ2xpDd//Os2TNi8j18xaZdr3HsogglAdRq9Ianqo5yPI9g6iSBsl5xHLQBqzx+d7FoueN55FeOWk/xi2xNgy4DzsvTRq6mm/IbYb8A/kVgMjuD2EGz4QjfEhsh70boXqCrBJ8o3w2yUWWHg/Xp7eLVm0VSBxZeCXlLT/8UZ0elOwLGS7iOE89j49hpVltjBNRlpIFHIQc+bBEUexm9Sg0W45P+SJkPP5TM8G++e+RP3MtgAdR
Content-Type: text/plain; charset="us-ascii"
Content-ID: <86BDE64FADE7B2479B2A0C428D08A077@namprd15.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b10c3a4a-6a29-4b0c-c787-08d76323daeb
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2019 01:43:14.6263
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: w9Cb2xK1vubVfzJHTg8nRq99UJ95zrJUegfSM2NwFG1YC00s8VKso0YkHzaRa3gQ
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR15MB3121
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572
 definitions=2019-11-06_09:2019-11-06,2019-11-06 signatures=0
X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 lowpriorityscore=0
 bulkscore=0 suspectscore=0 priorityscore=1501 malwarescore=0 phishscore=0
 adultscore=0 impostorscore=0 mlxlogscore=999 mlxscore=0 clxscore=1015
 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-1910280000 definitions=main-1911070016
X-FB-Internal: deliver
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Nov 06, 2019 at 05:25:26PM -0800, Shakeel Butt wrote:
> On Wed, Nov 6, 2019 at 4:22 PM Johannes Weiner <hannes@cmpxchg.org> wrote=
:
> >
> > On Wed, Nov 06, 2019 at 02:51:30PM -0800, Roman Gushchin wrote:
> > > We've encountered a rcu stall in get_mem_cgroup_from_mm():
> > >
> > >  rcu: INFO: rcu_sched self-detected stall on CPU
> > >  rcu: 33-....: (21000 ticks this GP) idle=3D6c6/1/0x4000000000000002 =
softirq=3D35441/35441 fqs=3D5017
> > >  (t=3D21031 jiffies g=3D324821 q=3D95837) NMI backtrace for cpu 33
> > >  <...>
> > >  RIP: 0010:get_mem_cgroup_from_mm+0x2f/0x90
> > >  <...>
> > >  __memcg_kmem_charge+0x55/0x140
> > >  __alloc_pages_nodemask+0x267/0x320
> > >  pipe_write+0x1ad/0x400
> > >  new_sync_write+0x127/0x1c0
> > >  __kernel_write+0x4f/0xf0
> > >  dump_emit+0x91/0xc0
> > >  writenote+0xa0/0xc0
> > >  elf_core_dump+0x11af/0x1430
> > >  do_coredump+0xc65/0xee0
> > >  ? unix_stream_sendmsg+0x37d/0x3b0
> > >  get_signal+0x132/0x7c0
> > >  do_signal+0x36/0x640
> > >  ? recalc_sigpending+0x17/0x50
> > >  exit_to_usermode_loop+0x61/0xd0
> > >  do_syscall_64+0xd4/0x100
> > >  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > >
> > > The problem is caused by an exiting task which is associated with
> > > an offline memcg. We're iterating over and over in the
> > > do {} while (!css_tryget_online()) loop, but obviously the memcg won'=
t
> > > become online and the exiting task won't be migrated to a live memcg.
> > >
> > > Let's fix it by switching from css_tryget_online() to css_tryget().
> > >
> > > As css_tryget_online() cannot guarantee that the memcg won't go
> > > offline, the check is usually useless, except some rare cases
> > > when for example it determines if something should be presented
> > > to a user.
> > >
> > > A similar problem is described by commit 18fa84a2db0e ("cgroup: Use
> > > css_tryget() instead of css_tryget_online() in task_get_css()").
> > >
> > > Signed-off-by: Roman Gushchin <guro@fb.com>
> > > Cc: stable@vger.kernel.org
> > > Cc: Tejun Heo <tj@kernel.org>
> >
> > Acked-by: Johannes Weiner <hannes@cmpxchg.org>
> >
> > The bug aside, it doesn't matter whether the cgroup is online for the
> > callers. It used to matter when offlining needed to evacuate all
> > charges from the memcg, and so needed to prevent new ones from showing
> > up, but we don't care now.
>=20
> Should get_mem_cgroup_from_current() and get_mem_cgroup_from_page() be
> switched to css_tryget() as well then?

In those case it can't cause a rcu stall, so it's not a so urgent.
But you are right, we should probably do the same here. I'll look
at all remaining callers and prepare the patchset.

I'll also probably rename it to css_tryget_if_online() to make obvious
that it doesn't hold the cgroup from being onlined.

Thanks!