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]
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
> 
> 

Powered by blists - more mailing lists