From mboxrd@z Thu Jan 1 00:00:00 1970 From: keescook@chromium.org (Kees Cook) Date: Wed, 14 Feb 2018 11:35:54 -0800 Subject: arm64 physmap (was Re: [kernel-hardening] [PATCH 4/6] Protectable Memory) In-Reply-To: References: <20180124175631.22925-1-igor.stoppa@huawei.com> <20180124175631.22925-5-igor.stoppa@huawei.com> <20180126053542.GA30189@bombadil.infradead.org> <8818bfd4-dd9f-f279-0432-69b59531bd41@huawei.com> <17e5b515-84c8-dca2-1695-cdf819834ea2@huawei.com> <414027d3-dd73-cf11-dc2a-e8c124591646@redhat.com> <2f23544a-bd24-1e71-967b-e8d1cf5a20a3@redhat.com> Message-ID: To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Wed, Feb 14, 2018 at 11:29 AM, Kees Cook wrote: > Why does using finer granularity on the physmap degrade performance? I > assume TLB pressure, but what is heavily using that area? (I must not > be understanding what physmap actually gets used for -- I thought it > was just a convenience to have a 1:1 virt/phys map for some lookups?) Jann has sorted me out: it's that physmap isn't an _alias_ for the buddy allocator memory areas; it's used directly. -Kees -- Kees Cook Pixel Security -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html