Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp159949pxj; Thu, 3 Jun 2021 03:34:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxJLCcYFPQXFsu57ju3f9bdC2SkQ1DHFG1SxAcqQAsJgkq3YerSEpQc7Jdqt0djeu4ci8qI X-Received: by 2002:a17:906:c247:: with SMTP id bl7mr39452651ejb.288.1622716445784; Thu, 03 Jun 2021 03:34:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622716445; cv=none; d=google.com; s=arc-20160816; b=0C1BBcBgck+qkXmJrnizknd7fAsNU7mDwEKli6JtILZed/TZC097accEtccFxr/j2e emoA/y++goEbtyNbYv8uX3oTIDFNRjRmDYL9wQPhgWZ8EvqPsQXnOMMd0Dwcmyj/8KY6 kYMmFU4r0vX70eUzq44Z5gzDkIhzYIzHDF1sBpsJ+teqghwteiX+BJ2U2vUNxvh4zQw/ so6k4egB1IeNb1vvtgnahEkvRtBbNk2ygNQa7ut8O2zJO06uxaDjQZofssEIXplLT/qb 2mTrRK7bfwfn1DkkSci2aijCAJjZdygGhOsF2+QlIsN/y5QhtUdMV3cq2o6y1D2ed5im aOAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=2DhEW/DOKIoRkqOavIipZEjSSmU8G/YV7paZrpFVx6U=; b=OzY23e2B+kxk9QQYXco/avRga4FXdCeSKAct2D05d12sbBgVlFqRIKnOVi2yLcngqr tPXr/EssPv0zMDsuNuo7HzI+IyJS7VoiC0iYdW364gYk4EugwwCH6z73xF+Jzr+WRKH0 ZmRJBuSk1pRXPDXa5uI+uAciwVmn0qk4r1yRpbRw+xTW5KfCXQ4gdH5vvrzh3EBoyeMO Z8ExX5Dniq/HcmLkGxNePNU0Ipe5NP+/hWAZJ6M5b119RZkj9CkCTE4qm6e8Vjy42oQG 6nSXQ0yMkeb/cQO5tZ7+MGKb1xgzuK+b/vt4qqVQ2FJc/BbgV3JXMnjplNEy0dQ4hFkW bfYw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m19si2000214edq.272.2021.06.03.03.33.43; Thu, 03 Jun 2021 03:34:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229936AbhFCKdo (ORCPT + 99 others); Thu, 3 Jun 2021 06:33:44 -0400 Received: from szxga01-in.huawei.com ([45.249.212.187]:7089 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229928AbhFCKdn (ORCPT ); Thu, 3 Jun 2021 06:33:43 -0400 Received: from dggeme759-chm.china.huawei.com (unknown [172.30.72.57]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4Fwhvr5rb0zYpX2; Thu, 3 Jun 2021 18:29:12 +0800 (CST) Received: from [127.0.0.1] (10.40.188.144) by dggeme759-chm.china.huawei.com (10.3.19.105) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Thu, 3 Jun 2021 18:31:57 +0800 Subject: Re: [PATCH v3 3/3] drivers/base/node.c: use bin_attribute to avoid buff overflow To: Andy Shevchenko , Tian Tao CC: , , , , , References: <1622712162-7028-1-git-send-email-tiantao6@hisilicon.com> <1622712162-7028-4-git-send-email-tiantao6@hisilicon.com> From: "tiantao (H)" Message-ID: Date: Thu, 3 Jun 2021 18:31:57 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.40.188.144] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To dggeme759-chm.china.huawei.com (10.3.19.105) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2021/6/3 17:53, Andy Shevchenko 写道: > On Thu, Jun 03, 2021 at 05:22:42PM +0800, Tian Tao wrote: >> Reading sys/devices/system/cpu/cpuX/nodeX/ returns cpumap and cpulist. >> However, the size of this file is limited to PAGE_SIZE because of the >> limitation for sysfs attribute. so we use bin_attribute instead of >> attribute to avoid NR_CPUS too big to cause buff overflow. > ... > >> } >> >> -static DEVICE_ATTR_RO(cpumap); >> >> -static inline ssize_t cpulist_show(struct device *dev, >> - struct device_attribute *attr, >> - char *buf) >> +static BIN_ATTR_RO(cpumap, 0); > So, you will have 2 blank lines in a row after this. Why one is not enough? > Same question for other similar cases, if any.  I can delete the line 55. this is the only problem, are there any other problems? 47 static inline ssize_t cpumap_read(struct file *file, struct kobject *kobj,   48                                   struct bin_attribute *attr, char *buf,   49                                   loff_t off, size_t count)   50 {   51         struct device *dev = kobj_to_dev(kobj);   52   53         return node_read_cpumap(dev, false, buf, off, count);   54 }   55   56   57 static BIN_ATTR_RO(cpumap, 0);   58   59 static inline ssize_t cpulist_read(struct file *file, struct kobject *kobj,   60                                    struct bin_attribute *attr, char *buf,   61                                    loff_t off, size_t count)   62 {   63         struct device *dev = kobj_to_dev(kobj);   64   65         return node_read_cpumap(dev, true, buf, off, count);   66 }   67   68 static BIN_ATTR_RO(cpulist, 0); >