On 10/10/19 2:01 PM, tony camuso wrote:
On 10/10/19 9:17 AM, Corey Minyard wrote:
On Wed, Oct 09, 2019 at 01:27:28PM -0400, tony camuso wrote:
One of our vendors reports that the following commit ...
commit e86ee2d44b44056243da17c120ad258717cedf9b
Author: Corey Minyard <cminy...@mvista.com>
Date: Thu Apr 5 22:05:04 2018 -0500
ipmi: Rework locking and shutdown for hot remove
To handle hot remove of interfaces, a lot of rework had to be
done to the locking. Several things were switched over to srcu
and shutdown for users and interfaces was added for cleaner
shutdown.
Signed-off-by: Corey Minyard <cminy...@mvista.com>
... appears to have made it possible to unload ipmi kmods when userspace
is accessing /dev/ipmi0
Is this an intended behavior?
Hmm. It kind of was, you should be able to unload ipmi_si or ipmi_ssif,
but not ipmi_msghandler or ipmi_devintf. If a program is using the
device, it will just get errors.
This was all added because of devices that could be dynamically removed
without warning. The behavior you are referencing is sort of a side
effect of that; it would have taken some extra code to keep the module
from unload, and my assumption was that anyone unloading a module
indended this.
If this is causing a problem, it can be modified.
-corey
Thanks, Corey. I'll check with the vendor.
Vendor is asking for an ipmi hot-plug spec. I couldn't find it in the 2.0 spec.
They will adapt if there is a spec.
_______________________________________________
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
