linux-kernel - Re: [PATCH 4.19 089/219] ipmi: Dont allow device module unload when in use

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0494ad8e-0f6b-2db8-7faf-9da89179aa9a@redhat.com>
Date:   Wed, 8 Jan 2020 09:55:30 -0500
From:   Tony Camuso <tcamuso@...hat.com>
To:     cminyard@...sta.com, Pavel Machek <pavel@...x.de>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Sasha Levin <sashal@...nel.org>
Subject: Re: [PATCH 4.19 089/219] ipmi: Dont allow device module unload when
 in use



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@...sta.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
> 
>