From mboxrd@z Thu Jan 1 00:00:00 1970 From: Borislav Petkov Subject: Re: [Part1 PATCH v4 15/17] percpu: introduce DEFINE_PER_CPU_UNENCRYPTED Date: Wed, 20 Sep 2017 09:34:26 +0200 Message-ID: <20170920073426.GA26073@nazgul.tnic> References: <20170916123418.37807-1-brijesh.singh@amd.com> <20170916123418.37807-16-brijesh.singh@amd.com> <20170919103906.GM4733@nazgul.tnic> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Brijesh Singh Cc: linux-kernel@vger.kernel.org, x86@kernel.org, kvm@vger.kernel.org, Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , Andy Lutomirski , Tom Lendacky , Arnd Bergmann , Tejun Heo , Christoph Lameter , linux-arch@vger.kernel.org List-Id: linux-arch.vger.kernel.org On Tue, Sep 19, 2017 at 08:50:20AM -0500, Brijesh Singh wrote: > "..shared_aligned" section does not start and end with page-size alignment. Nowhere in the code there's a comment saying: "This percpu section really must be page-size aligned because ." You need to be more verbose with requirements like that. Also, you're ending up needing a whole page per-CPU for those variables. And now with the alignment before and after, you have worst-case two pages fragmentation of percpu memory and percpu memory is a rather limited resource AFAIR. If only there were a alloc_percpu_page()... > Since the C-bit works on PAGE_SIZE alignment hence the "..unencrypted" section Btw, call that section "..decrypted" and everywhere do s/unencrypted/decrypted/g. > starts and ends with page-size alignment. The closest I can find is > "..page_aligned" but again it does not end with page-size alignment. > > Additionally, since we clear the C-bit from unencrypted section hence we > should avoid overloading the existing section -- we don't want to expose more > than we wish. Add that to the comment too. Thx. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de ([195.135.220.15]:58452 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751547AbdITHeb (ORCPT ); Wed, 20 Sep 2017 03:34:31 -0400 Date: Wed, 20 Sep 2017 09:34:26 +0200 From: Borislav Petkov Subject: Re: [Part1 PATCH v4 15/17] percpu: introduce DEFINE_PER_CPU_UNENCRYPTED Message-ID: <20170920073426.GA26073@nazgul.tnic> References: <20170916123418.37807-1-brijesh.singh@amd.com> <20170916123418.37807-16-brijesh.singh@amd.com> <20170919103906.GM4733@nazgul.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-ID: To: Brijesh Singh Cc: linux-kernel@vger.kernel.org, x86@kernel.org, kvm@vger.kernel.org, Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , Andy Lutomirski , Tom Lendacky , Arnd Bergmann , Tejun Heo , Christoph Lameter , linux-arch@vger.kernel.org Message-ID: <20170920073426.2LVw_qGKBp0lBmRtq_Ae8yl4wKX4DgAydIi1O5q-7es@z> On Tue, Sep 19, 2017 at 08:50:20AM -0500, Brijesh Singh wrote: > "..shared_aligned" section does not start and end with page-size alignment. Nowhere in the code there's a comment saying: "This percpu section really must be page-size aligned because ." You need to be more verbose with requirements like that. Also, you're ending up needing a whole page per-CPU for those variables. And now with the alignment before and after, you have worst-case two pages fragmentation of percpu memory and percpu memory is a rather limited resource AFAIR. If only there were a alloc_percpu_page()... > Since the C-bit works on PAGE_SIZE alignment hence the "..unencrypted" section Btw, call that section "..decrypted" and everywhere do s/unencrypted/decrypted/g. > starts and ends with page-size alignment. The closest I can find is > "..page_aligned" but again it does not end with page-size alignment. > > Additionally, since we clear the C-bit from unencrypted section hence we > should avoid overloading the existing section -- we don't want to expose more > than we wish. Add that to the comment too. Thx. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --