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 8211CEB64DA for ; Tue, 18 Jul 2023 15:41:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229485AbjGRPll (ORCPT ); Tue, 18 Jul 2023 11:41:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41242 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230296AbjGRPlg (ORCPT ); Tue, 18 Jul 2023 11:41:36 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CA114B0; Tue, 18 Jul 2023 08:41:35 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3E04A61636; Tue, 18 Jul 2023 15:41:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6087CC433C7; Tue, 18 Jul 2023 15:41:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1689694894; bh=2z4VemvJVhwmItrQCFbXp9Jgb8x1GmS7nNXmRAUmxe4=; h=Date:Cc:Subject:From:To:References:In-Reply-To:From; b=b7YN7txj1on5brdZbnALpUA94GYmyReQ+rClZl8Mz2bWYBYwgmIEkm8pdca4djZv/ M0/ca7LkPW9RLp4P5PxIhT4+N4GIFM0+SDwh848mHn+4gCX/qzKQDzYdF/H9OdGwA2 LqF+D+CokWv5RrrXVPnDyJ80a2/otiTTB4iz9ik+d0/+wa7T3aHw7GUMCpflWkoxJ5 8ocmj/cGk3YWBFL0Cbe1589RT4WHM40Sbl5wCDRS9LLcaY1bliMbadfrb/dDmlHV8e 2s0h4K2G6ILAYhmyVG/Wf6mi64APUa8G9zu3M2+1psXxsFLMceexRWUl36HHyJU2ym IVDuIGvKOZKBw== Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Tue, 18 Jul 2023 18:41:27 +0300 Message-Id: Cc: , , , , "Zefan Li" , "Johannes Weiner" , , , , , Subject: Re: [PATCH] cgroup/misc: Fix an overflow From: "Jarkko Sakkinen" To: "Tejun Heo" , "Haitao Huang" X-Mailer: aerc 0.14.0 References: <20230717184719.85523-1-haitao.huang@linux.intel.com> In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon Jul 17, 2023 at 11:37 PM EEST, Tejun Heo wrote: > Hello, > > On Mon, Jul 17, 2023 at 03:19:38PM -0500, Haitao Huang wrote: > > Actually, we are using atomic_long_t for 'current' which is the same wi= dth > > as long defined by arch/compiler. So new_usage should be long to be > > consistent? > > We can use atomic64_t, right? It's slower on 32bit machines but I think i= t'd > be better to guarantee resource counter range than micro-optimizing charg= e > operations. None of the current users are hot enough for this to matter a= nd > if somebody becomes that hot, the difference between atomic_t and atomic6= 4_t > isn't gonna matter that much. We'd need to batch allocations per-cpu and = so > on. In our context, the microcode of SGX could support 32-bit but by design we only support 64-bit. So at least with the current implementation this would not be an issue for SGX. BR, Jarkko From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jarkko Sakkinen" Subject: Re: [PATCH] cgroup/misc: Fix an overflow Date: Tue, 18 Jul 2023 18:41:27 +0300 Message-ID: References: <20230717184719.85523-1-haitao.huang@linux.intel.com> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1689694894; bh=2z4VemvJVhwmItrQCFbXp9Jgb8x1GmS7nNXmRAUmxe4=; h=Date:Cc:Subject:From:To:References:In-Reply-To:From; b=b7YN7txj1on5brdZbnALpUA94GYmyReQ+rClZl8Mz2bWYBYwgmIEkm8pdca4djZv/ M0/ca7LkPW9RLp4P5PxIhT4+N4GIFM0+SDwh848mHn+4gCX/qzKQDzYdF/H9OdGwA2 LqF+D+CokWv5RrrXVPnDyJ80a2/otiTTB4iz9ik+d0/+wa7T3aHw7GUMCpflWkoxJ5 8ocmj/cGk3YWBFL0Cbe1589RT4WHM40Sbl5wCDRS9LLcaY1bliMbadfrb/dDmlHV8e 2s0h4K2G6ILAYhmyVG/Wf6mi64APUa8G9zu3M2+1psXxsFLMceexRWUl36HHyJU2ym IVDuIGvKOZKBw== In-Reply-To: List-ID: Content-Type: text/plain; charset="us-ascii" To: Tejun Heo , Haitao Huang Cc: dave.hansen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-sgx-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Zefan Li , Johannes Weiner , vipinsh-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, kai.huang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, reinette.chatre-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, zhiquan1.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, kristen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org On Mon Jul 17, 2023 at 11:37 PM EEST, Tejun Heo wrote: > Hello, > > On Mon, Jul 17, 2023 at 03:19:38PM -0500, Haitao Huang wrote: > > Actually, we are using atomic_long_t for 'current' which is the same wi= dth > > as long defined by arch/compiler. So new_usage should be long to be > > consistent? > > We can use atomic64_t, right? It's slower on 32bit machines but I think i= t'd > be better to guarantee resource counter range than micro-optimizing charg= e > operations. None of the current users are hot enough for this to matter a= nd > if somebody becomes that hot, the difference between atomic_t and atomic6= 4_t > isn't gonna matter that much. We'd need to batch allocations per-cpu and = so > on. In our context, the microcode of SGX could support 32-bit but by design we only support 64-bit. So at least with the current implementation this would not be an issue for SGX. BR, Jarkko