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:     Michal Hocko <mhocko@kernel.org>
CC:     =?iso-8859-1?Q?Michal_Koutn=FD?= <mkoutny@suse.com>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        "Johannes Weiner" <hannes@cmpxchg.org>,
        "linux-kernel@vger.kernel.org" <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/KeJVScAgAAK2ICAAbZBgIABgJEA
Date:   Fri, 15 Nov 2019 18:13:31 +0000
Message-ID: <20191115181322.GB27385@localhost.localdomain>
References: <20191106225131.3543616-1-guro@fb.com>
 <20191113162934.GF19372@blackbody.suse.cz>
 <20191113170823.GA12464@castle.DHCP.thefacebook.com>
 <20191114191657.GN20866@dhcp22.suse.cz>
In-Reply-To: <20191114191657.GN20866@dhcp22.suse.cz>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2620:10d:c090:180::9012]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: fd24e0f2-756f-4783-2ff3-08d769f78517
x-ms-traffictypediagnostic: BN8PR15MB2835:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BN8PR15MB2835D0E5C0C2878E8949801BBE700@BN8PR15MB2835.namprd15.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02229A4115
x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(979002)(346002)(376002)(39860400002)(396003)(366004)(136003)(189003)(199004)(66556008)(102836004)(46003)(4326008)(6116002)(33656002)(9686003)(478600001)(8936002)(25786009)(86362001)(229853002)(6246003)(2906002)(66946007)(81166006)(316002)(446003)(5660300002)(6916009)(14454004)(476003)(71190400001)(486006)(305945005)(6436002)(8676002)(6486002)(99286004)(11346002)(6512007)(66446008)(7736002)(54906003)(76176011)(1076003)(71200400001)(6506007)(386003)(64756008)(52116002)(14444005)(186003)(256004)(66476007)(81156014)(969003)(989001)(999001)(1009001)(1019001);DIR:OUT;SFP:1102;SCL:1;SRVR:BN8PR15MB2835;H:BN8PR15MB2626.namprd15.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;MX:1;A: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: MMzRDd2MniFjPuRsPcc06dGjrqtouk7UAd52XBjwwfy+Hjp2bCIwkKJiczqGsyU/fZ3TcW2ofsULRY8KvMtAihB8t/pooO/cyMcHlWkz4eDP52lyVSar8+oh2PLU5X3jCglgJZq/u1sN0OgRHW7v7YvTYV9KJ8F/9Av0mGp4f8osNbTWgK8kiHyg0cpBB410NvDJHk8deHKo2LOJ9nbIGpcHuCjZU17W5P+Cx0YzhsplW+fWcAf112sYnpagGdSuinNHpuffCAt+uRKJayI/FDppX7UX66IAFiFAzN2eSQ1bBxlEfQSJP0G5MZSi+Btux/FJVfYa3w9ZdetrJVIWn6PaHgSZX5tqOQxWxt6zBREVqj/CLaWSt0zfDJ1RLK3C2P4rNykoyEHtOFo6Ok0tpGDxjN3hAASOmBqdOYKCVeeaazn1z44RhNVXJzG9le+4
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <6F24FB96FF5A3F4A9DB8C549060B5F60@namprd15.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: fd24e0f2-756f-4783-2ff3-08d769f78517
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2019 18:13:31.9395
 (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: 95RVB9UMi25S3QnxNG90rkpqM0afh/qRRhlNwbU6QTHSNC8lIv7uQcEG8+PzivdD
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR15MB2835
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572
 definitions=2019-11-15_05:2019-11-15,2019-11-15 signatures=0
X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 lowpriorityscore=0
 mlxlogscore=999 mlxscore=0 suspectscore=0 clxscore=1015 priorityscore=1501
 phishscore=0 spamscore=0 bulkscore=0 adultscore=0 malwarescore=0
 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-1910280000 definitions=main-1911150162
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 Thu, Nov 14, 2019 at 08:16:57PM +0100, Michal Hocko wrote:
> On Wed 13-11-19 17:08:29, Roman Gushchin wrote:
> > On Wed, Nov 13, 2019 at 05:29:34PM +0100, Michal Koutn=FD wrote:
> > > Hi.
> > >=20
> > > On Wed, Nov 06, 2019 at 02:51:30PM -0800, Roman Gushchin <guro@fb.com=
> wrote:
> > > > Let's fix it by switching from css_tryget_online() to css_tryget().
> > > Is this a safe thing to do? The stack captures a kmem charge path, wi=
th
> > > css_tryget() it may happen it gets an offlined memcg and carry out
> > > charge into it. What happens when e.g. memcg_deactivate_kmem_caches i=
s
> > > skipped as a consequence?
> >=20
> > The thing here is that css_tryget_online() cannot pin the online state,
> > so even if returned true, the cgroup can be offline at the return from
> > the function. So if we rely somewhere on it, it's already broken.
>=20
> Then what is the point of this function and what about all other users?
>=20
> > Generally speaking, it's better to reduce it's usage to the bare minimu=
m.
>=20
> If it doesn't have any sensible semantic then I would argue it should go
> altogether otherwise we are going to chase new users again and aagain?

That's the plan: to audit all use cases and get rid of it where it's possib=
le.

> =20
> > > > 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 wo=
n't
> > > > become online and the exiting task won't be migrated to a live memc=
g.
> > > As discussed in other replies, the task is not yet exiting. However, =
the
> > > access to memcg isn't through `current` but `mm->owner`, i.e. another
> > > task of a threadgroup may have got stuck in an offlined memcg (I don'=
t
> > > have a good explanation for that though).
>=20
> The trace however points to current->mm or current->active_memcg. Is it
> possible that we have a stale active_memcg?

It wouldn't cause a rcu stall.

Thanks!