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=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 D2687C432C2 for ; Tue, 24 Sep 2019 23:54:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 959E520874 for ; Tue, 24 Sep 2019 23:54:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="CFO304w0" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 959E520874 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2DFCC6B000D; Tue, 24 Sep 2019 19:54:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 28FA86B000E; Tue, 24 Sep 2019 19:54:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1A6936B0010; Tue, 24 Sep 2019 19:54:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0203.hostedemail.com [216.40.44.203]) by kanga.kvack.org (Postfix) with ESMTP id ECF606B000D for ; Tue, 24 Sep 2019 19:54:28 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 69E61613D for ; Tue, 24 Sep 2019 23:54:28 +0000 (UTC) X-FDA: 75971471016.07.party77_27007f3034c12 X-HE-Tag: party77_27007f3034c12 X-Filterd-Recvd-Size: 3650 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf46.hostedemail.com (Postfix) with ESMTP for ; Tue, 24 Sep 2019 23:54:27 +0000 (UTC) Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 347D8206DD; Tue, 24 Sep 2019 23:54:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1569369266; bh=77LgG7sH8ZOfn/RzxREA78GWTNS60M2eU3Gg2LZZdpg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=CFO304w0y4Fr7/j+umJCvtwPWv7SS5ZLtX3xcGFmOMnWdGOFDsQHVh3Dg/H0OkPSm VuUbswWYLalvFIXCA8dOGD6gAsdrEfG47lwYmUHNWLai2zcWU6tC/nScCvlXG9rvyO NliXcizh1hyn+s2NY5x+Vc48EG5aI2akmcTSgqLM= Date: Tue, 24 Sep 2019 16:54:25 -0700 From: Andrew Morton To: cl@linux.com Cc: David Sterba , Vlastimil Babka , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Pekka Enberg , David Rientjes , Ming Lei , Dave Chinner , Matthew Wilcox , "Darrick J . Wong" , Christoph Hellwig , linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org, James Bottomley , linux-btrfs@vger.kernel.org, Roman Gushchin , Johannes Weiner Subject: Re: [PATCH v2 2/2] mm, sl[aou]b: guarantee natural alignment for kmalloc(power-of-two) Message-Id: <20190924165425.a79a2dafbaf37828a931df2b@linux-foundation.org> In-Reply-To: References: <20190826111627.7505-1-vbabka@suse.cz> <20190826111627.7505-3-vbabka@suse.cz> <20190923171710.GN2751@twin.jikos.cz> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Tue, 24 Sep 2019 20:52:52 +0000 (UTC) cl@linux.com wrote: > On Mon, 23 Sep 2019, David Sterba wrote: > > > As a user of the allocator interface in filesystem, I'd like to see a > > more generic way to address the alignment guarantees so we don't have to > > apply workarounds like 3acd48507dc43eeeb each time we find that we > > missed something. (Where 'missed' might be another sort of weird memory > > corruption hard to trigger.) > > The alignment guarantees are clearly documented and objects are misaligned > in debugging kernels. > > Looking at 3acd48507dc43eeeb:Looks like no one tested that patch with a > debug kernel or full debugging on until it hit mainline. Not good. > > The consequence for the lack of proper testing is to make the production > kernel contain the debug measures? This isn't a debug measure - it's making the interface do that which people evidently expect it to do. Minor point. I agree it's a bit regrettable to do this but it does appear that the change will make the kernel overall a better place given the reality of kernel development. Given this, have you reviewed the patch for overall implementation correctness? I'm wondering if we can avoid at least some of the patch's overhead if slab debugging is disabled - the allocators are already returning suitably aligned memory, so why add the new code in that case?