Fix the coredump problem caused by lock acquisition failure
As net-ipmid depends on ipmid, stress testing found that frequent
start/stop of net-ipmid will cause coredump due to lock acquisition
failure in ipmid's inithannelPersistData.
Since net-ipmid depends on ipmid, stress testing found that if
net-ipmid is started/stopped frequently, it will exit abnormally due
to failure to obtain the lock in the inithannelPersistData method of
ipmid.
```
netipmid-eth1[893]: terminate called after throwing an instance of ‘boost::interprocess::lock_exception’
netipmid-eth1[893]: what(): boost::interprocess::lock_exception
```
Because in the main method of net-ipmid, the ipmi::ipmiChannelInit
method is called first, and then the startEventLoop method is called
to process the signal. This will cause a bug:
1. After net-ipmid@eth0 starts, ipmi::ipmiChannelInit will be
executed to initialize and construct ChannelConfig.
2. The initChannelPersistData method will be executed in the
construction method to obtain the lock and load the configuration.
3. If the stop method of net-ipmid is executed before the
construction method is completed, the held lock will not be
released correctly
4. If start is executed immediately at this time, the ipmid process
will coredump because the current lock is undefined.
This submission moves the signal processing to before the
ipmi::ipmiChannelInit method, which will ensure that if net-ipmid
starts and captures abnormal operations, it will stop io first, so
that the held lock will be released correctly.
Tested:
Using this patch, no ipmid coredump occurs in the stress test.
Signed-off-by: George Liu <liuxiwei@ieisystem.com>
Change-Id: I29694405679330c083fa35d04443fb2e31bfca3b
3 files changed