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 8198DC433EF for ; Thu, 24 Feb 2022 09:31:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E96108D0002; Thu, 24 Feb 2022 04:31:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E47718D0001; Thu, 24 Feb 2022 04:31:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D34B08D0002; Thu, 24 Feb 2022 04:31:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id C074C8D0001 for ; Thu, 24 Feb 2022 04:31:43 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 8B88B12129F for ; Thu, 24 Feb 2022 09:31:43 +0000 (UTC) X-FDA: 79177156086.10.8B2D9D1 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf11.hostedemail.com (Postfix) with ESMTP id ED2C840002 for ; Thu, 24 Feb 2022 09:31:42 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id B72E6212B8; Thu, 24 Feb 2022 09:31:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1645695101; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=/nPvKs1oIrJwWVDpcneKVOW7b7d/cdXeZfU3+c7ooSo=; b=O4QVF+uy/FlVk3fzEES2po7V50s0tZqU1eMi1aeX7+BsS8jsGrmmWQcmv48eHy5k3hxJXu gtaVQsYpEojmMvVya4rCCHCOvSYdYKN1r/5zjAhNjTkCfxGrLnCY5/1VyB5XQfMQomI7Yo nggnnnAYM9+UXUv9PPQLYtLszaeRRi4= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 2682EA3B85; Thu, 24 Feb 2022 09:31:41 +0000 (UTC) Date: Thu, 24 Feb 2022 10:31:40 +0100 From: Michal Hocko To: Mike Kravetz Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Baolin Wang , Zhenguo Yao , Liu Yuntao , Dan Carpenter , Andrew Morton Subject: Re: [PATCH v2] hugetlb: clean up potential spectre issue warnings Message-ID: References: <20220218212946.35441-1-mike.kravetz@oracle.com> <26565cd7-01b0-197c-6ce9-af92f5bc8563@oracle.com> <4bad1923-354d-3858-0339-82df8c090c3f@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: ED2C840002 X-Stat-Signature: 81mgi1ym77f31s9tjxwk7opffqrjro6y Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=O4QVF+uy; spf=pass (imf11.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-Rspam-User: X-HE-Tag: 1645695102-603726 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed 23-02-22 10:36:55, Mike Kravetz wrote: > On 2/23/22 00:33, Michal Hocko wrote: > > On Tue 22-02-22 13:53:56, Mike Kravetz wrote: > >> On 2/21/22 23:47, Michal Hocko wrote: > >> How about adding this note to the commit message? > >> > >> Note: these routines take a user specified value used as an index ONCE > >> during the boot process. As a result, they can not be used as a general > >> method of exploitation. Code changes are being made to eliminate warnings. > > > > This would help but the question whether the change is worth remains. > > Does this change have any other advantage than silencing the warning? > > > > Silencing the warnings was the primary motivation for the change. If Dan > has a plan to change smatch so that they are silenced for __init functions, > then it would be better to not make the changes to use array_index_nospec. > > While making the changes, I shuffled the code a little and did not immediately > notice that it also 'fixes' an overflow/truncation issue when assigning an > unsigned long to int as addressed in [1]. We should probably make this change > whether or not we use array_index_nospec to silence warnings. > > [1] https://lore.kernel.org/linux-mm/20220209134018.8242-1-liuyuntao10@huawei.com/ Yeah, this makes sense to me. -- Michal Hocko SUSE Labs