Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp691697imw; Wed, 13 Jul 2022 06:24:45 -0700 (PDT) X-Google-Smtp-Source: AGRyM1uTYfZK7+OgyS2xme+8Ad8kJrbqscCGgLzrwb/DHPYiptgiVJpyNgDW0s5y/pY8rGnodyuQ X-Received: by 2002:aa7:9631:0:b0:52a:cbf8:fa3e with SMTP id r17-20020aa79631000000b0052acbf8fa3emr3241009pfg.33.1657718685000; Wed, 13 Jul 2022 06:24:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657718684; cv=none; d=google.com; s=arc-20160816; b=HOKwnlXWEMjI08V2lMnR1BCnDXecxuo9CVKebBVmJaX1jhwfKwU5zTksvV7V6LNYDb 7IIMh8Gw6OorpJMYgrPFyPSdewCMev+wKYmPCWvbS/PR/Tn+Y63HOA+gMImXXXi8Trxk BgFDmEKzHc/3+zCgeASygmcwFiObmqdzCX9tWvK341z/zpRad/UQoqdVZP0K0O/Zgdsm ortmd57xWVFVVTG334dsMCpFkDGdozURbsmYrCfhdzMkC5EPE/X+nYQNm6ceEBlA+Szq NYBUrCPGhK9yYzeHsZqBz/RDSDt+CWQVIrbrB+rnkB7aiQ/a0ZGG/iV//fEynJZOthx2 wa4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=4e4Gm/oIvSIMzo1neoL6FQvpFUH5pVZEso8qBS5NgGs=; b=XdfTB2LXPlaSXnR6MF6+kJ6Emy3vaDB3WXjhdOZnaq+fm/NxLDJlziuLbLL+UlWwd/ sbh3xzs4VO7whCocUVUgWy+13y8X380/gUPnTYJj2icWYpYaYhvRbvqICxup5LOzVuVI B83ICAH2lhnP81klUXqj5CCplVX0u6MBU6oky8+CoBlQ9ttCtstOVQri+iRnfQFaEo94 qjf1moGBpasLQaafkdLXh6lPT03FrYX731CjzDbTv/HIxqzDkP/6ZeodWEXJenNSnBh0 2v5QUhF5G3Ui7Ger53vmHmIjtgwYUoFNjhgN+PrTUwNtCP+oh3Yw5OIRbku/1PnZ60vn fEWQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=RCnnZ5qf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id rj7-20020a17090b3e8700b001f01c6f537asi2841708pjb.137.2022.07.13.06.24.32; Wed, 13 Jul 2022 06:24:44 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=RCnnZ5qf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235287AbiGMNGd (ORCPT + 99 others); Wed, 13 Jul 2022 09:06:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54648 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229640AbiGMNGc (ORCPT ); Wed, 13 Jul 2022 09:06:32 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C5CFB8F for ; Wed, 13 Jul 2022 06:06:31 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 708E5B81F01 for ; Wed, 13 Jul 2022 13:06:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9A73EC34114; Wed, 13 Jul 2022 13:06:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1657717589; bh=I/8fgDiVhnQn+g4npPm+EFV2apCMQYq4lmg3gRkrX5A=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=RCnnZ5qfDQxP81MKBUlOpjlcR8nVBAkxZYruHpAfkjACJXmeHrCjG7/7ak8I7mERB bClPoF99tHTeV+XmL8u9WAZzgVRdlp5dACgY1ZDgjX1rZZm2BC4HFILR7vhRFnS1mI AFC+ubeNtWL7LXuMWpsVCX6tKTSm7h0x7/9eIqAg= Date: Wed, 13 Jul 2022 15:06:25 +0200 From: Greg Kroah-Hartman To: Phil Auld Cc: Barry Song <21cnbao@gmail.com>, LKML , "Rafael J . Wysocki : --cc=" , Tian Tao , Barry Song Subject: Re: [PATCH] drivers/base/node.c: fix userspace break from using bin_attributes for cpumap and cpulist Message-ID: References: <20220712214301.809967-1-pauld@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 13, 2022 at 07:37:27AM -0400, Phil Auld wrote: > On Wed, Jul 13, 2022 at 11:18:59AM +1200 Barry Song wrote: > > On Wed, Jul 13, 2022 at 9:58 AM Phil Auld wrote: > > > > > > Using bin_attributes with a 0 size causes fstat and friends to return that 0 size. > > > This breaks userspace code that retrieves the size before reading the file. Rather > > > than reverting 75bd50fa841 ("drivers/base/node.c: use bin_attribute to break the size > > > limitation of cpumap ABI") let's put in a size value at compile time. Use direct > > > comparison and a worst-case maximum to ensure compile time constants. For cpulist the > > > max is on the order of NR_CPUS * (ceil(log10(NR_CPUS)) + 1) which for 8192 is 40960. > > > In order to get near that you'd need a system with every other CPU on one node or > > > something similar. e.g. (0,2,4,... 1024,1026...). We set it to a min of PAGE_SIZE > > > to retain the older behavior. For cpumap, PAGE_SIZE is plenty big. > > > > > > On an 80 cpu 4-node system (NR_CPUS == 8192) > > > > > > before: > > > > > > -r--r--r--. 1 root root 0 Jul 12 14:08 /sys/devices/system/node/node0/cpulist > > > -r--r--r--. 1 root root 0 Jul 11 17:25 /sys/devices/system/node/node0/cpumap > > > > it is a fundamental problem of bin_attr, isn't it? when we don't know the > > exact size of an attribute, and this size might become more than one > > PAGE_SIZE, we use bin_attr to break the limitation. but the fact is that > > we really don't know or it is really hard to know the actual size of the > > attribute. > > > > But it broke userspace applications. I figured rather than revert it maybe > we can find a max size to put in there and make it continue to work. Yes, we need to do this, we can't break userspace. thanks, greg k-h