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 X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 03479C433B4 for ; Wed, 7 Apr 2021 13:49:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 679B961382 for ; Wed, 7 Apr 2021 13:49:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 679B961382 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A98096B007D; Wed, 7 Apr 2021 09:49:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A48586B007E; Wed, 7 Apr 2021 09:49:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8E9CD6B0080; Wed, 7 Apr 2021 09:49:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0102.hostedemail.com [216.40.44.102]) by kanga.kvack.org (Postfix) with ESMTP id 75E926B007D for ; Wed, 7 Apr 2021 09:49:51 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 2D566180AD802 for ; Wed, 7 Apr 2021 13:49:51 +0000 (UTC) X-FDA: 78005704182.03.7EA8FD0 Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190]) by imf28.hostedemail.com (Postfix) with ESMTP id C867B200025E for ; Wed, 7 Apr 2021 13:49:50 +0000 (UTC) Received: from DGGEMS403-HUB.china.huawei.com (unknown [172.30.72.60]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4FFm1224hfz19Kkt; Wed, 7 Apr 2021 21:47:34 +0800 (CST) Received: from [10.174.176.73] (10.174.176.73) by DGGEMS403-HUB.china.huawei.com (10.3.19.203) with Microsoft SMTP Server id 14.3.498.0; Wed, 7 Apr 2021 21:49:35 +0800 Subject: Re: [QUESTION] WARNNING after 3d8e2128f26a ("sysfs: Add sysfs_emit and sysfs_emit_at to format sysfs output") To: Joe Perches , Matthew Wilcox , "Greg KH" CC: , , , , , "zhangyi (F)" , Kefeng Wang , , "Zhengyejian (Zetta)" , Yang Yingliang , References: <5837f5d9-2235-3ac2-f3f2-712e6cf4da5c@huawei.com> <20210402144120.GO351017@casper.infradead.org> <08b739b5-4401-e550-2028-1ce43db38141@huawei.com> From: yangerkun Message-ID: <91f1d0e6-1ed3-7f32-029a-370169b9c00a@huawei.com> Date: Wed, 7 Apr 2021 21:49:35 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed X-Originating-IP: [10.174.176.73] X-CFilter-Loop: Reflected X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: C867B200025E X-Stat-Signature: 66fwr33zdpabzykzqcodperh59983zux Received-SPF: none (huawei.com>: No applicable sender policy available) receiver=imf28; identity=mailfrom; envelope-from=""; helo=szxga04-in.huawei.com; client-ip=45.249.212.190 X-HE-DKIM-Result: none/none X-HE-Tag: 1617803390-633238 Content-Transfer-Encoding: quoted-printable 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: =E5=9C=A8 2021/4/7 21:21, Joe Perches =E5=86=99=E9=81=93: > On Wed, 2021-04-07 at 20:14 +0800, yangerkun wrote: >> >> =E5=9C=A8 2021/4/2 22:41, Matthew Wilcox =E5=86=99=E9=81=93: >>> On Fri, Apr 02, 2021 at 09:45:12AM +0200, Greg KH wrote: >>>> Why is the buffer alignment considered a "waste" here? If that chan= ge >>>> is in Linus's tree and newer kernels (it showed up in 5.4 which was >>>> released quite a while ago), where are the people complaining about = it >>>> there? >>>> >>>> I think backporting 59bb47985c1d ("mm, sl[aou]b: guarantee natural >>>> alignment for kmalloc(power-of-two)") seems like the correct thing t= o do >>>> here to bring things into alignment (pun intended) with newer kernel= s. >>> >>> It's only a waste for slabs which need things like redzones (eg we co= uld >>> get 7 512-byte allocations out of a 4kB page with a 64 byte redzone >>> and no alignment ; with alignment we can only get four). Since slub >>> can enable/disable redzones on a per-slab basis, and redzones aren't >>> terribly interesting now that we have kasan/kfence, nobody really car= es. >>> >>> . >>> >> >> Thanks for your explain! The imfluence seems minimal since the "waste" >> will happen only when we enable slub_debug. >> >> One more question for Joe Perches. Patch v2[1] does not add the >> alignment check for buf and we add it in v3[2]. I don't see the >> necessity for this check... Can you help to explain that why we need t= his? >=20 > It's to make sure it's a PAGE_SIZE aligned buffer. > It's just so it would not be misused/abused in non-sysfs derived cases. >=20 > . >=20 Thanks! It help me to understand the problem better!