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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E9192C433FE for ; Thu, 3 Feb 2022 19:04:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 79D1B6B0071; Thu, 3 Feb 2022 14:04:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 74D926B0072; Thu, 3 Feb 2022 14:04:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5EE426B0074; Thu, 3 Feb 2022 14:04:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0049.hostedemail.com [216.40.44.49]) by kanga.kvack.org (Postfix) with ESMTP id 4F8CA6B0071 for ; Thu, 3 Feb 2022 14:04:24 -0500 (EST) Received: from smtpin31.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 0F98795CA5 for ; Thu, 3 Feb 2022 19:04:24 +0000 (UTC) X-FDA: 79102394448.31.D5DFD15 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf30.hostedemail.com (Postfix) with ESMTP id 9E6558000B for ; Thu, 3 Feb 2022 19:04:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1643915063; 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=PLQFnHEtj3xkYCEqnP21o1hjIKAbba/Hk7Ulww4yy6ztI+K0kRZfvsZtpF+64gsJWYf+Fl 1sExeTcHrjqslCXeoaQDhTLauoaI255hRK4fDCTV0j2wWtNsZ7rThMj7q6L+fCwzQT/+04 GE1aOSbsrxEp7PCGpetDfoi/Kn9vc5g= 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 X-Rspam-User: nil X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 9E6558000B X-Stat-Signature: bpnjumnz9jfxspozdbmrsug659sfatqt Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=PLQFnHEt; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf30.hostedemail.com: domain of longman@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=longman@redhat.com X-HE-Tag: 1643915063-905993 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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