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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7B5DFC433F5 for ; Fri, 18 Feb 2022 17:57:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BB9736B0074; Fri, 18 Feb 2022 12:57:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B41C36B0075; Fri, 18 Feb 2022 12:57:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9E19E6B0078; Fri, 18 Feb 2022 12:57:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0186.hostedemail.com [216.40.44.186]) by kanga.kvack.org (Postfix) with ESMTP id 8B2B76B0074 for ; Fri, 18 Feb 2022 12:57:52 -0500 (EST) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 492508249980 for ; Fri, 18 Feb 2022 17:57:52 +0000 (UTC) X-FDA: 79156658784.20.A1E5B13 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf28.hostedemail.com (Postfix) with ESMTP id AE2E9C000A for ; Fri, 18 Feb 2022 17:57:51 +0000 (UTC) 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 dfw.source.kernel.org (Postfix) with ESMTPS id BC9B86200C; Fri, 18 Feb 2022 17:57:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 75124C340E9; Fri, 18 Feb 2022 17:57:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1645207070; bh=dP5b+VA+uAx3bJhnVmVq20KQ+X+9Cy6qAmDwVZSVETA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=QvDPAbFjC/4BDN5N4QWsBAXqH2By2fN9OfvYaiEa2EMGl4mymWW8xR+qlQyNEIuA8 TPqKYelwYUzcA6s0HPFMHH/nhichKTgj+hHrBc37kVQaDoNGGuLZTVgIDxzZ9up4Nv 3l394mt2DHKY8m9e4DnwbzD5MGioZ5eock/RE5GY= Date: Fri, 18 Feb 2022 18:57:47 +0100 From: Greg Kroah-Hartman To: Vlastimil Babka Cc: linux-kernel@vger.kernel.org, stable , Kees Cook , Daniel Micay , Nick Desaulniers , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Nathan Chancellor , linux-mm@kvack.org, llvm@lists.linux.dev Subject: Re: [PATCH] slab: remove __alloc_size attribute from __kmalloc_track_caller Message-ID: References: <20220218131358.3032912-1-gregkh@linuxfoundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: AE2E9C000A X-Rspam-User: Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b=QvDPAbFj; spf=pass (imf28.hostedemail.com: domain of gregkh@linuxfoundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org; dmarc=pass (policy=none) header.from=linuxfoundation.org X-Stat-Signature: 9bqzym3m5ytqz8jcsicawscmofp1xcya X-HE-Tag: 1645207071-253151 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 Fri, Feb 18, 2022 at 06:14:55PM +0100, Vlastimil Babka wrote: > On 2/18/22 14:13, Greg Kroah-Hartman wrote: > > Commit c37495d6254c ("slab: add __alloc_size attributes for better > > bounds checking") added __alloc_size attributes to a bunch of kmalloc > > function prototypes. Unfortunately the change to __kmalloc_track_caller > > seems to cause clang to generate broken code and the first time this is > > called when booting, the box will crash. > > > > While the compiler problems are being reworked and attempted to be > > solved, let's just drop the attribute to solve the issue now. Once it > > is resolved it can be added back. > > Could we instead wrap it in some #ifdef that' only true for clang build? > That would make the workaround more precise and self-documented. Even > better if it can trigger using clang version range and once a fixed > clang version is here, it can be updated to stay true for older clangs. It's not doing all that much good like this, let's just remove it for now until it does actually provide a benifit and not just crash the box :) This is only 1 function, that is used in only a very small number of callers. I do not think it will be missed. thanks, greg k-h