From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0CFF843B3EF; Wed, 23 Sep 2026 09:19:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790155191; cv=none; b=Tsz6Tz7mi6XP8KC2396rYbV5IVrbV7t3P97Ot0siaxauzt6z13twdxuecEVWuIMGgOv0dyUcYnLoNUwnTwNp15/Xnmbvc7XDCTW2vGNsx/MnprHlw0YoJNezIdQp7ul9MGx0Qnsl9bEziOnwOLb5xRSiWjLYTMe4V3tbaXXeI4I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790155191; c=relaxed/simple; bh=QoOgO/A2U5dtm7QoQT4ErByB/CY9vpIhJBSi3Us/+JE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=f88xMqq3cjWElRLMXj/7zkUanEwLNUL/uZBFqrcQSmWL+G99azVuDPFcBZLJOG5nMlHgAUDo3bTkV+N6zZyDy4f9nWGuV/BEW6QNu4RARBIooi0bK/DdMEjH8zspJwrRZlFyc0idKA6/1jcsoe9J4EUmWVIzMPBanNuBVmqdvqg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=i935KHZ0; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="i935KHZ0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 465CD1F000FF; Wed, 23 Sep 2026 09:19:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1790155189; bh=szozd7BSlCRG6SBcZcvnaC59iOuE2gZVQMEdYxaAPfg=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=i935KHZ03UQCOH4iIXqvpXzISRCnQkyg/7sekoDfNzFScbwNm9ckk0hABoKJ4MivO 4PVX5vSdjD8HGmskfgBtcNDkI8qvRU8v5/w3PkwoUvgmZ17uCo75xWaxQaK9Mleuhh 78BPW4fvbSD9Fzat6DcWvAb4K7OFR3z+TnYuIFxAI7BLwiiLTnLA+fvF/Xxogg9kWu ojjUK6uDDp1zJyv/DcHgGv0bvoIqwp9lKyFkmCn8PCT4za8eUYdsIcaxYcgADguYMm F6cIZ8f+dI4Uyue/PLV1oc1e2KAMFSYI+UoZCHFacoLvBgH9vLGXzpBDyqachCkMFz wvxTQ0rPS6eag== Date: Wed, 23 Sep 2026 12:19:34 +0300 From: Mike Rapoport To: Guenter Roeck Cc: Marco Elver , Vlastimil Babka , Andrew Morton , "Gustavo A. R. Silva" , "Liam R. Howlett" , Andrey Konovalov , Bill Wendling , David Hildenbrand , David Rientjes , Dmitry Vyukov , Jann Horn , Justin Stitt , KP Singh , Kees Cook , Lorenzo Stoakes , Matteo Rizzo , Michal Hocko , Nathan Chancellor , Nick Desaulniers , Roman Gushchin , Suren Baghdasaryan , linux-hardening@vger.kernel.org, Nicolas Schier , Dennis Zhou , Tejun Heo , Christoph Lameter , Harry Yoo , Hao Li , "Liam R. Howlett" , Alexander Potapenko , Miguel Ojeda , linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, kasan-dev@googlegroups.com, llvm@lists.linux.dev, Guo Ren , linux-csky@vger.kernel.org, Arnd Bergmann Subject: Re: csky ICe (was: Re: [PATCH v4 2/3] slab: improve KMALLOC_PARTITION_RANDOM randomness) Message-ID: References: <20260511200136.3201646-1-elver@google.com> <20260511200136.3201646-2-elver@google.com> <6106aefa-47c7-4bda-a51f-8a2fba3bf715@roeck-us.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6106aefa-47c7-4bda-a51f-8a2fba3bf715@roeck-us.net> On Tue, Sep 22, 2026 at 07:58:56AM -0700, Guenter Roeck wrote: > Hi, > > On Mon, May 11, 2026 at 10:00:49PM +0200, Marco Elver wrote: > > When using CONFIG_KMALLOC_PARTITION_RANDOM, _RET_IP_ was previously used > > to identify the allocation site. _RET_IP_, however, evaluates to the > > caller's parent's instruction pointer rather than the actual allocation > > site; this would lead to collisions where a function performs multiple > > allocations. > > > > With the generalization to kmalloc_token_t, we now generate the token at > > the outermost macro, and using _THIS_IP_ would fix this for all cases. > > > > Unfortunately, the generic implementation of _THIS_IP_ relies on taking > > the address of a local label, which is considered broken by both GCC [1] > > and Clang [2] because label addresses are only expected to be used with > > computed gotos. While the generic version more or less works today, it > > is known to be brittle. For example, Clang -O2 always returns 1 when > > this function is inlined: > > > > static inline unsigned long get_ip(void) > > { return ({ __label__ __here; __here: (unsigned long)&&__here; }); } > > > > To provide a reliable unique identifier without breaking architectures > > relying on the generic _THIS_IP_, introduce _CODE_LOCATION_: it resolves > > to _THIS_IP_ where architectures provide a safe implementation, and > > falls back to a zero-cost static marker where _THIS_IP_ is broken. > > > > Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120071 [1] > > Link: https://github.com/llvm/llvm-project/issues/138272 [2] > > Signed-off-by: Marco Elver > > With this patch in the tree, I get ICE erors when trying to build > csky:allmodconfig. > > Example: > > Error log: > sound/core/oss/mixer_oss.c: In function 'snd_mixer_oss_proc_write': > sound/core/oss/mixer_oss.c:1202:1: error: could not split insn > 1202 | } > | ^ > (insn 183 400 184 (set (reg:SI 0 a0 [orig:307 _55 ] [307]) > (xor:SI (reg:SI 3 a3 [orig:308 random_kmalloc_seed ] [308]) > (const:SI (plus:SI (symbol_ref:SI ("*.LANCHOR0") [flags 0x182]) > (const_int 132 [0x84]))))) "include/linux/slab.h":759:52 288 {cskyv2_xorsi3} > (expr_list:REG_DEAD (reg:SI 3 a3 [orig:308 random_kmalloc_seed ] [308]) > (nil))) > during RTL pass: final > sound/core/oss/mixer_oss.c:1202:1: internal compiler error: in final_scan_insn_1, at final.cc:2813 > 0x779b51e2a1c9 __libc_start_call_main > ../sysdeps/nptl/libc_start_call_main.h:58 > 0x779b51e2a28a __libc_start_main_impl > ../csu/libc-start.c:360 > > This happens with lots of files, not just this one. It is seen with all > versions of gcc starting with at least v13.x. Reverting this patch fixes > the problem. Bisect log is attached for reference. > > Any idea what I could do to avoid the problem other than stopping to build > csky:allmodconfig ? Maybe it's time to say goodbye to csky? ;-) > Thanks, > Guenter -- Sincerely yours, Mike.