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. _______________________________________________ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
