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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, UNPARSEABLE_RELAY 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 E3137C433ED for ; Wed, 7 Apr 2021 13:21:17 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1C2E661394 for ; Wed, 7 Apr 2021 13:21:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1C2E661394 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=perches.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6729C6B007D; Wed, 7 Apr 2021 09:21:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5FBFF6B007E; Wed, 7 Apr 2021 09:21:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 475AD6B0080; Wed, 7 Apr 2021 09:21:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0141.hostedemail.com [216.40.44.141]) by kanga.kvack.org (Postfix) with ESMTP id 28F956B007D for ; Wed, 7 Apr 2021 09:21:16 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id C4F37180ACF8B for ; Wed, 7 Apr 2021 13:21:15 +0000 (UTC) X-FDA: 78005632110.17.447EC69 Received: from smtprelay.hostedemail.com (smtprelay0053.hostedemail.com [216.40.44.53]) by imf04.hostedemail.com (Postfix) with ESMTP id 38BDF13A for ; Wed, 7 Apr 2021 13:21:14 +0000 (UTC) Received: from omf07.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay08.hostedemail.com (Postfix) with ESMTP id 115EE182CCCAD; Wed, 7 Apr 2021 13:21:15 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: joe@perches.com) by omf07.hostedemail.com (Postfix) with ESMTPA id 78264315D7A; Wed, 7 Apr 2021 13:21:12 +0000 (UTC) Message-ID: Subject: Re: [QUESTION] WARNNING after 3d8e2128f26a ("sysfs: Add sysfs_emit and sysfs_emit_at to format sysfs output") From: Joe Perches To: yangerkun , Matthew Wilcox , Greg KH Cc: stable@vger.kernel.org, vbabka@suse.cz, linux-mm@kvack.org, open-iscsi@googlegroups.com, cleech@redhat.com, "zhangyi (F)" , Kefeng Wang , liuyongqiang13@huawei.com, "Zhengyejian (Zetta)" , Yang Yingliang , chenzhou10@huawei.com Date: Wed, 07 Apr 2021 06:21:11 -0700 In-Reply-To: <08b739b5-4401-e550-2028-1ce43db38141@huawei.com> References: <5837f5d9-2235-3ac2-f3f2-712e6cf4da5c@huawei.com> <20210402144120.GO351017@casper.infradead.org> <08b739b5-4401-e550-2028-1ce43db38141@huawei.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.1-1 MIME-Version: 1.0 X-Session-Marker: 6A6F6540706572636865732E636F6D X-Session-ID: U2FsdGVkX19tPg5BY8oiEk400kiihuFsLCQX8VKOJ1I= X-HE-Tag: 1617801672-488380 X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 38BDF13A X-Stat-Signature: zwnwb9njkrfbiy1fjujpyez18bg1b8p1 Received-SPF: none (perches.com>: No applicable sender policy available) receiver=imf04; identity=mailfrom; envelope-from=""; helo=smtprelay.hostedemail.com; client-ip=216.40.44.53 X-HE-DKIM-Result: none/none X-HE-Tag: 1617801674-530504 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: On Wed, 2021-04-07 at 20:14 +0800, yangerkun wrote: >=20 > =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 cha= nge > > > 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? > > >=20 > > > I think backporting 59bb47985c1d ("mm, sl[aou]b: guarantee natural > > > alignment for kmalloc(power-of-two)") seems like the correct thing = to do > > > here to bring things into alignment (pun intended) with newer kerne= ls. > >=20 > > 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. > >=20 > > . > >=20 >=20 > Thanks for your explain! The imfluence seems minimal since the "waste"=20 > will happen only when we enable slub_debug. >=20 > 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 th= is? 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.