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 2E1BEC2BD09 for ; Thu, 27 Jun 2024 12:01:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A0AA86B0096; Thu, 27 Jun 2024 08:01:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9B9576B0098; Thu, 27 Jun 2024 08:01:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 85AE36B0099; Thu, 27 Jun 2024 08:01:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 66AEF6B0096 for ; Thu, 27 Jun 2024 08:01:22 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id CCE67140156 for ; Thu, 27 Jun 2024 12:01:21 +0000 (UTC) X-FDA: 82276528362.12.12EC033 Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com [209.85.208.45]) by imf29.hostedemail.com (Postfix) with ESMTP id 3CFA2120034 for ; Thu, 27 Jun 2024 12:01:18 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=2RqvLblF; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf29.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.45 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719489666; a=rsa-sha256; cv=none; b=vR6RM6mo1R584x3zi7TeqkH0WytDT90jk+K4K2lQiD3fhqH0unAXgHWcCSn3JU9f9+h48u 90P+6aKHyYGcDdbF15aoOtxlR5nyMwZL3+121UKwlE+d+ln/CBxng9XjDVs5NwbSVr6afL 9e7Ap57Jv+EBbiRvkWiGJXqJ01UeWL8= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=2RqvLblF; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf29.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.45 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719489666; h=from:from:sender: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:dkim-signature; bh=k9j+/cSs2PAYgdkbCUNnS381bOcAZnMsEBwA3t2khoI=; b=sJPfcwsNwBjubC0igfjlYL9RTdQwz9KuipjfBiXBcS5oFn9ZTirXsS+/+w4MedUybNX1Eg L2gwKeXZZQBPx4mr0ss8RJdwmWG8gjpVLV4Z0eSm73DpHWs9eI9FYxWoTGLycVXX908Cp3 FwN+TBbycp81Z7w/dffCdrAlX6iW2Yg= Received: by mail-ed1-f45.google.com with SMTP id 4fb4d7f45d1cf-57d203d4682so1836710a12.0 for ; Thu, 27 Jun 2024 05:01:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1719489677; x=1720094477; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=k9j+/cSs2PAYgdkbCUNnS381bOcAZnMsEBwA3t2khoI=; b=2RqvLblF8CX/l+IxOdyZJrakf2Rgc1iRoDNb+ywStmYYssLXi063NK0FG5CfqT+orc IwDIXHGhOff435OTuo+HyD5yfJow7vxcyvlraUYA7zF0reEr2PyNjgY8vn4+bNIZNTs3 EFxOvH5XD1ElRJn8wEj2qJjQuC/pDds1cN9JL3Zp0RwfEC0lQkMjwrsguoRgG1pDI4A7 bc2DMlqyT862EbL+L44agPeIYjuKTAf/g2meXu5rcV1vJ4lONHlbU2+i/71aVIkdTytM ZviNB7X8/iMFZxBoK/q1n+s82Z7LIXJ/DM7YFM8EV6w2BVU6oFSwWq51woEX/Cr1PMO8 dASw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719489677; x=1720094477; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=k9j+/cSs2PAYgdkbCUNnS381bOcAZnMsEBwA3t2khoI=; b=CEfUDgzO3rfnAHhDsMO0lN4SJnGIq0QHWxsOGGuMLYx54vKLWM0FV3/rfU5FOu44UN oOJFJ1CohckJ2PejHKFxFdkSonDFcGWG27Ss2ZvLLVmTM3nLq6sUFqR7JoM/g2jmHIyP 3DlB6Qb6lo3FMU8U4ryUXbvD0BKjexWYs+49xkMK60NqjSWXgmyoLOf0pDQO/mHIdz3/ drQlYNumH20X8SJlYCaEKbjFp6sSocqAw5C5yjQEfrDu0URCqp9ivFsdJD6l7sQ9lx4a G6seo4++iUXSNdvCJl+9OXo2qc3M7jFIzM2KxZZRFO/bnkqdCX9ZSpCcbo3/mW542Xr8 RhHA== X-Forwarded-Encrypted: i=1; AJvYcCWICcXSkNWHCGUHTEWgxX8R/dzQR1rar2+ocLNeHGC0c6voD/RrxEgHR2eVDhZJ0ju12ZvH+b8vF69MOdXCtAOE60A= X-Gm-Message-State: AOJu0YzOHhOeamVnehgIwNQbNz9QZqy2TwChRExvaG5nl/CcUI4zbslf Uk496w9mj8utbEiF0sSUGxEMNz/p62WdTZdFePHm5p9ybULVt0Vvx3uOHsSK57bEHu8uzwGHVgI oDP5VN5Rvv0FYuamJJOnssOeHmPpesB30kVbk X-Google-Smtp-Source: AGHT+IFF8Hiiq5pYK9NbSKbcRGMGJtjP5zoG6SUD3CzR5idX+/EYVlkwu3pidiz4GSLWh9u4DpKft3r0SyrDpQHzrFs= X-Received: by 2002:a17:907:c78d:b0:a72:5f9a:159a with SMTP id a640c23a62f3a-a727f680828mr594305966b.2.1719489676985; Thu, 27 Jun 2024 05:01:16 -0700 (PDT) MIME-Version: 1.0 References: <20240626094232.2432891-1-xiujianfeng@huawei.com> In-Reply-To: From: Yosry Ahmed Date: Thu, 27 Jun 2024 05:00:18 -0700 Message-ID: Subject: Re: [PATCH -next] mm: memcg: remove redundant seq_buf_has_overflowed() To: Michal Hocko Cc: Xiu Jianfeng , hannes@cmpxchg.org, roman.gushchin@linux.dev, shakeel.butt@linux.dev, muchun.song@linux.dev, akpm@linux-foundation.org, cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 3CFA2120034 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: iru9epzz5z78e3k4cfg9mguf1urm6t9q X-HE-Tag: 1719489678-17384 X-HE-Meta: U2FsdGVkX1+Xz7n0X7Wz6oaT85EQJ5FXPjpUJYlbzy+vhnVlctx88dujVLye4w7A0RdDqL+30vwMJe7m2mHPkEHG5aul5+TpRiGsH/+vm57+zXZQ8YeHr5TZWVymDcL9J2shIrrZuo2Paifz7/FjtP7NyQzikZsowztOgZ4Xd1p8EUgOhbPkqqsggY1T1ssFrAYHH3lzj/8FUtq5T4J1xVj36KMfHvHaBRZtDccog0qkUrRhfZhQTUW3dAmlb08yjEzUl87jmBeBZA47gH8O5EzIYx+EtjjJ3pxmx9gZHlwptRfJWkTci1fYANAOn2lbhuOfNDIIxOqQhjfYPyU7/j0tlx02fsTu65FjpjgA9xhkXCjHCjUWMPsLgsCxTG0G2Qs88wqimth0n5aF6kc8jiCDQgSnbVbKFThrLjFGV6rLCMWIv3DPOTLv3Rx4EdcrrEIfZuqzC5Oba0nxeO5HxDSKFWQIiNkw7HPnbsontAcDtSVpxI9euX7rraUBm0rWQixPNgQt74F7C/+vWZx5oUiKXXhh9bo8eYGghRT1wS+ReXVShnj+GdKJNrwIkaglRGVLKhxGB6WnHswT1Dxo4Wp2dzzPX1IaUGF3SlF+kFs38fPmuu9XYndO4tR+493qv1pyPesFON9THBIRGRfCpVesygztilDQ1nEk2BAPype+y1O8pFckGK2UfbnQTTHAH9Tdb3UfPiJTwSy5Vd9hxRaqPO3EdxiDbN3M+vQBLlS7RRitvZ4aD651u1g3g6oBW677qwEr7q9jPPcFegjWDwd666Nl5WX6td4hMQ6j2FTA3fmvO05l/4+sKOwtRzzlDafMm26vtWiLeC21mquSLegivvq3dy0S5avfOhETeiNIC8hmOZEUOT5eZ9pFyK7QvFLX1cA2SPuPQMf/9k8Rf2ECzlcP4I8VbBpyDqq+Qp0Sj/UmcpYapsiRpyUg/bJ53MjubZRhx/tayeH+Pdy cx//ea0E kG3SX8NQFGTzyKogSgvrSXVJfDrpwn+f1VjxQ8ohlkPRK3bjTuffmxe9CSuR5RYs/P8KFJPP+x8XZ9AXrT9uqDEj5LaoEq6k6kXhAm6avgOP0dXtWi4z1AUCO1Doiz+1PNOqyvhwcKiUf77uH1sNf2QuBDtFnd8Ihhl1aytroZ2toPGNdFLCJZiiOPR7JATlVDcPpoQ3fQiOl1PnyqGSiHedsagFQFTq8/fk5BOGGtXarmL8+t6zwDwLrzDeDNAeBvlRj2+UXw9zeEHSiSgyha+uu9w== X-Bogosity: Ham, tests=bogofilter, spamicity=0.086620, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Jun 27, 2024 at 4:56=E2=80=AFAM Michal Hocko wrot= e: > > On Thu 27-06-24 04:33:50, Yosry Ahmed wrote: > > On Thu, Jun 27, 2024 at 12:13=E2=80=AFAM Michal Hocko = wrote: > > > > > > On Wed 26-06-24 09:42:32, Xiu Jianfeng wrote: > > > > Both the end of memory_stat_format() and memcg_stat_format() will c= all > > > > WARN_ON_ONCE(seq_buf_has_overflowed()). However, memory_stat_format= () > > > > is the only caller of memcg_stat_format(), when memcg is on the def= ault > > > > hierarchy, seq_buf_has_overflowed() will be executed twice, so remo= ve > > > > the reduntant one. > > > > > > Shouldn't we rather remove both? Are they giving us anything useful > > > actually? Would a simpl pr_warn be sufficient? Afterall all we care > > > about is to learn that we need to grow the buffer size because our st= ats > > > do not fit anymore. It is not really important whether that is an OOM= or > > > cgroupfs interface path. > > > > Is it possible for userspace readers to break if the stats are > > incomplete? > > They will certainly get an imprecise picture. Sufficient to break I > dunno. If some stats go completely missing and a parser expects them to always be there, I think they may break. > > > If yes, I think WARN_ON_ONCE() may be prompted to make it > > easier to catch and fix before deployment. > > The only advantage of WARN_ON_ONCE is that the splat is so verbose that > it gets noticed. Right, that's exactly what I meant. > And also it panics the system if panic_on_warn is > enabled. I do not particularly care about the latter but to me it seems > like the warning is just an over reaction and a simple pr_warn should > just achieve the similar effect - see my other reply If pr_warn()'s usually get noticed in a timely manner (by testers or bots), then I think pr_warn() would be sufficient. If they can go unnoticed for a while, I think WARN_ON_ONCE() may be warranted to avoid the possibility of breaking a userspace parser.