From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752292AbdJ0IL7 (ORCPT <rfc822;w@1wt.eu>);
        Fri, 27 Oct 2017 04:11:59 -0400
Received: from szxga05-in.huawei.com ([45.249.212.191]:9519 "EHLO
        szxga05-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752219AbdJ0ILj (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 27 Oct 2017 04:11:39 -0400
Message-ID: <59F2EA25.1080903@huawei.com>
Date: Fri, 27 Oct 2017 16:11:17 +0800
From: zhouchengming <zhouchengming1@huawei.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Borislav Petkov <bp@suse.de>
CC: <mingo@redhat.com>, <tglx@linutronix.de>, <peterz@infradead.org>,
        <hpa@zytor.com>, <jkosina@suse.cz>, <rostedt@goodmis.org>,
        <mjurczyk@google.com>, <x86@kernel.org>,
        <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86/alternatives: free smp_alt_modules when enable smp
References: <1509088692-9971-1-git-send-email-zhouchengming1@huawei.com> <20171027074912.GB1305@nazgul.tnic>
In-Reply-To: <20171027074912.GB1305@nazgul.tnic>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.177.236.183]
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
        refid=str=0001.0A020202.59F2EA29.0032,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0,
        ip=0.0.0.0,
        so=2014-11-16 11:51:01,
        dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: d3c0ca17c8c6c2786e77e0b11884b1e4
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2017/10/27 15:49, Borislav Petkov wrote:
> On Fri, Oct 27, 2017 at 03:18:12PM +0800, Zhou Chengming wrote:
>> In the current code, we don't free smp_alt_modules when enable smp,
>> so have to wait module unload to call alternatives_smp_module_del()
>> to free its smp_alt_module. This strategy has shortcomings.
> I love it when the commit message states there is allegedly some problem
> but it doesn't explain what that problem is.

Well, I should explain it although it's small shortcomings. First, maybe
some modules don't unload after smp enabled, so these smp_alt_modules won't
be freed even they are useless anymore. Second, every module has to call
alternatives_smp_module_del() when unload to see if it's in the list even
after smp enabled, it's complete useless work. So why not take the quick
way like we do in alternatives_smp_module_add() ?

Thanks.

> > From the looks of the patch, though, I'd prefer what we do now and not
> touch the code.
>