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;
Subject: Re: [PATCH 4.19 089/219] ipmi: Dont allow device module unload when
 in use
To:     cminyard@mvista.com, Pavel Machek <pavel@denx.de>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        linux-kernel@vger.kernel.org, stable@vger.kernel.org,
        Sasha Levin <sashal@kernel.org>
References: <20191229162508.458551679@linuxfoundation.org>
 <20191229162520.260768030@linuxfoundation.org> <20191230103218.GA10304@amd>
 <20191231213255.GC6497@minyard.net>
From:   Tony Camuso <tcamuso@redhat.com>
Message-ID: <0494ad8e-0f6b-2db8-7faf-9da89179aa9a@redhat.com>
Date:   Wed, 8 Jan 2020 09:55:30 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: <20191231213255.GC6497@minyard.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


On 12/31/19 4:32 PM, Corey Minyard wrote:
> On Mon, Dec 30, 2019 at 11:32:18AM +0100, Pavel Machek wrote:
>> On Sun 2019-12-29 18:18:11, Greg Kroah-Hartman wrote:
>>> From: Corey Minyard <cminyard@mvista.com>
>>>
>>> [ Upstream commit cbb79863fc3175ed5ac506465948b02a893a8235 ]
>>>
>>> If something has the IPMI driver open, don't allow the device
>>> module to be unloaded.  Before it would unload and the user would
>>> get errors on use.
>>>
>>> This change is made on user request, and it makes it consistent
>>> with the I2C driver, which has the same behavior.
>>>
>>> It does change things a little bit with respect to kernel users.
>>> If the ACPI or IPMI watchdog (or any other kernel user) has
>>> created a user, then the device module cannot be unloaded.  Before
>>> it could be unloaded,
>>>
>>> This does not affect hot-plug.  If the device goes away (it's on
>>> something removable that is removed or is hot-removed via sysfs)
>>> then it still behaves as it did before.
>>
>> I don't think this is good idea for stable. First, it includes
>> unrelated function rename,
> 
> Umm, no, that's not unrelated, it was renamed so a defined could be
> done with the original name so the module could be passed in
> automatically.
> 
>> and second, it does not really fix any bug;
>> it just changes behaviour.
> 
> This is true.  I assume Tony asked for the backport.  I'm ambivolent
> on whether this gets backported.  I'll defer to Tony for justification.

I was PTO, and now I'm back, so I'll address this.

The fix returns behavior back to what it was before.
To at least some of our customers, the change in behavior this patch fixes
is a bug.

If backporting it causes an issue, then I'm okay with not doing that, since
we've already backported it into our kernel.

> -corey
> 
>>
>> Best regards,
>> 									Pavel
>> -- 
>> (english) http://www.livejournal.com/~pavelmachek
>> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> 
>