From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A51E3C433EF for ; Thu, 3 Feb 2022 19:04:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1353651AbiBCTEX (ORCPT ); Thu, 3 Feb 2022 14:04:23 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:21842 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237541AbiBCTEV (ORCPT ); Thu, 3 Feb 2022 14:04:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1643915061; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8WFk5VazJGj78aF3vcRFOwWn7//j5v/p/zsICay1c+U=; b=OmCKu02w5dUeLpKhZoqXqtl4B04ntFeX4HXfTwitkdTUYU6O3llgreP79mxem9eSQWvJgc 7fNIPj8OHRkwPK62ZTDvkQ0Ho+gnvQszVWo9JUa5t4TQmo3GqrX51crqoRhD3pqLwaFE1k lYhg2GOxIqHna57DIIBjnrfGnvXXS4s= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-544-1_xSlXEUNfiENHGx0Rm0IQ-1; Thu, 03 Feb 2022 14:04:18 -0500 X-MC-Unique: 1_xSlXEUNfiENHGx0Rm0IQ-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A074518B613D; Thu, 3 Feb 2022 19:04:15 +0000 (UTC) Received: from [10.22.8.80] (unknown [10.22.8.80]) by smtp.corp.redhat.com (Postfix) with ESMTP id 747A75D6BA; Thu, 3 Feb 2022 19:03:59 +0000 (UTC) Message-ID: <3f042edb-3769-afea-17a7-899578cd5c69@redhat.com> Date: Thu, 3 Feb 2022 14:03:58 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: [PATCH v4 3/4] mm/page_owner: Print memcg information Content-Language: en-US To: Michal Hocko Cc: Johannes Weiner , Vladimir Davydov , Andrew Morton , Petr Mladek , Steven Rostedt , Sergey Senozhatsky , Andy Shevchenko , Rasmus Villemoes , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, Ira Weiny , Mike Rapoport , David Rientjes , Roman Gushchin , Rafael Aquini References: <20220131192308.608837-5-longman@redhat.com> <20220202203036.744010-4-longman@redhat.com> From: Waiman Long In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/3/22 07:46, Michal Hocko wrote: > On Wed 02-02-22 15:30:35, Waiman Long wrote: > [...] >> +#ifdef CONFIG_MEMCG >> + unsigned long memcg_data; >> + struct mem_cgroup *memcg; >> + bool online; >> + char name[80]; >> + >> + rcu_read_lock(); >> + memcg_data = READ_ONCE(page->memcg_data); >> + if (!memcg_data) >> + goto out_unlock; >> + >> + if (memcg_data & MEMCG_DATA_OBJCGS) >> + ret += scnprintf(kbuf + ret, count - ret, >> + "Slab cache page\n"); >> + >> + memcg = page_memcg_check(page); >> + if (!memcg) >> + goto out_unlock; >> + >> + online = (memcg->css.flags & CSS_ONLINE); >> + cgroup_name(memcg->css.cgroup, name, sizeof(name)); > Is there any specific reason to use another buffer allocated on the > stack? Also 80B seems too short to cover NAME_MAX. > > Nothing else jumped at me. I suppose we can print directly into kbuf with cgroup_name(), but using a separate buffer is easier to read and understand. 79 characters should be enough for most cgroup names. Some auto-generated names with some kind of embedded uuids may be longer than that, but the random sequence of hex digits that may be missing do not convey much information for identification purpose. We can always increase the buffer length later if it turns out to be an issue. Cheers, Longman