Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp4220488imm; Wed, 30 May 2018 01:10:35 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJaygSq87p+qdFgqaIyikV+gqSknMc4NGiBminiLOlYWp0osNoSs8QTpyE/ocDM5ngrRLUI X-Received: by 2002:a17:902:b416:: with SMTP id x22-v6mr1867587plr.267.1527667834965; Wed, 30 May 2018 01:10:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527667834; cv=none; d=google.com; s=arc-20160816; b=Kuc7QK96CDySEYtPGzPZoWlGASgNCrA7GKe9XPT8+UFsJQzJOjOjbHfupJoZLkkEM/ 6DTAYX3IVL4yxGyxUNBHMSEOYHXwDx8JEKDSd+e7zt2VSwxtcC2NFBVON8iNF8AjJAoo ZRourVHRwz2mi/Iw+iTVGcMaEqoldK7yv+V8BSPjJO8210b4BBTr7uGaQ0e+4oFPcp+j 7Iw0WufqgaVgK5tsioWDAoX8L1ft43SHqbF8T6bbIJKVJz83hkm71mc0im+45fUz6Zov kKmHM+yl3gYYEKp/F7+LXWYms5C8xMOyBxXDC9DJFfFQ0+JbTn0x9iF3UWg03KAtts5T wtDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=Je30XxFotzOuSDN7VtER7KXbnK+md4D1RgqoPXeFnj4=; b=H7eUdYnEcMazBTSslWm69pTpzLOvEXgCdicYvZZTG5SUxJhB9nnmWtTsUgj8T889Tq hfnelic6AIyHOu5LjMIK+5LDziqyZYcZ0PAjtve6anP80lgwSo+vPUGgATtwU39dp+Y4 i3U0G/L2xL9T0pBlvW4JLR7byjp00CGzrLfQjphz4+A7YGBuXcZ2Sol+HfmQAUAt/nik cMP0NPFWNzniRV79it6NQYazBrD20muBnw8cQ3UhFvng+Pvk18WPkzCCMp6GbClKBVl9 A+Y8rccslzgiNaV4RXjwENdBDct4X1Cmg4/I9CgF1k55RlA73ZwvWZ8HvpRpralKZz1Z V4TA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u32-v6si14243854pgn.488.2018.05.30.01.10.21; Wed, 30 May 2018 01:10:34 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S937313AbeE3IIs (ORCPT + 99 others); Wed, 30 May 2018 04:08:48 -0400 Received: from foss.arm.com ([217.140.101.70]:51762 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935852AbeE3II1 (ORCPT ); Wed, 30 May 2018 04:08:27 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6D0251435; Wed, 30 May 2018 01:08:27 -0700 (PDT) Received: from salmiak (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 933B43F25D; Wed, 30 May 2018 01:08:22 -0700 (PDT) Date: Wed, 30 May 2018 09:08:16 +0100 From: Mark Rutland To: Nixiaoming Cc: Will Deacon , "catalin.marinas@arm.com" , "ard.biesheuvel@linaro.org" , "marc.zyngier@arm.com" , "james.morse@arm.com" , "kristina.martsenko@arm.com" , "steve.capper@arm.com" , "tglx@linutronix.de" , "mingo@redhat.com" , "hpa@zytor.com" , "akpm@linux-foundation.org" , "vbabka@suse.cz" , "mhocko@suse.com" , "dave.hansen@linux.intel.com" , "dan.j.williams@intel.com" , "kirill.shutemov@linux.intel.com" , "zhang.jia@linux.alibaba.com" , "schwidefsky@de.ibm.com" , "heiko.carstens@de.ibm.com" , "gregkh@linuxfoundation.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "x86@kernel.org" , "linux-s390@vger.kernel.org" Subject: Re: [PATCH 1/3] arm64:add missing CONFIG_STRICT_KERNEL_RWX for mark_rodata_ro Message-ID: <20180530080816.f74elebj4demiohl@salmiak> References: <20180529133615.26889-1-nixiaoming@huawei.com> <20180529154523.GK17159@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 30, 2018 at 03:31:38AM +0000, Nixiaoming wrote: > Unable to set CONFIG_STRICT_KERNEL_RWX=n by make menuconfig ARCH=arm64 Indeed. Making this mandatory was a deliberate decision, in part because this allows simplification of code (e.g. removal of #ifdef guards). > When reading the code, I feel it is more appropriate to add macro control > here. I must disagree. I do not think it makes sense to add an #ifdef for a configuration option that is mandatory. There are other places in the kernel that should behave differently if CONFIG_STRICT_KERNEL_RWX were disabled, so this wouldn't be sufficient even if we were to make CONFIG_STRICT_KERNEL_RWX optional. i.e. the #ifdef would give the misleading impression that STRICT_KERNEL_RWX *could* be made optional, even though this might not function correctly. Having an #ifdef here makes the code more complicated and confusing, for the benefit of a case which cannot occur. Thanks, Mark. > -----Original Message----- > From: Will Deacon [mailto:will.deacon@arm.com] > Sent: Tuesday, May 29, 2018 11:45 PM > To: Nixiaoming > Cc: catalin.marinas@arm.com; ard.biesheuvel@linaro.org; marc.zyngier@arm.com; james.morse@arm.com; kristina.martsenko@arm.com; steve.capper@arm.com; tglx@linutronix.de; mingo@redhat.com; hpa@zytor.com; akpm@linux-foundation.org; vbabka@suse.cz; mhocko@suse.com; dave.hansen@linux.intel.com; dan.j.williams@intel.com; kirill.shutemov@linux.intel.com; zhang.jia@linux.alibaba.com; schwidefsky@de.ibm.com; heiko.carstens@de.ibm.com; gregkh@linuxfoundation.org; linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org; x86@kernel.org; linux-s390@vger.kernel.org > Subject: Re: [PATCH 1/3] arm64:add missing CONFIG_STRICT_KERNEL_RWX for mark_rodata_ro > > On Tue, May 29, 2018 at 09:36:15PM +0800, nixiaoming wrote: > > mark_rodata_ro is only called by the function mark_readonly when > > CONFIG_STRICT_KERNEL_RWX=y, > > if CONFIG_STRICT_KERNEL_RWX is not set > > a compile warning may be triggered: unused function > > How are you achieving this configuration? In our Kconfig we select this > unconditionally. > > Will