Re: [RFC 06/10] kmod: provide sanity check on kmod_concurrent access

2017-01-10 Thread Luis R. Rodriguez
On Thu, Dec 15, 2016 at 01:57:48PM +0100, Petr Mladek wrote: > On Thu 2016-12-08 11:48:50, Luis R. Rodriguez wrote: > > Only decrement *iff* we're possitive. Warn if we've hit > > a situation where the counter is already 0 after we're done > > with a modprobe call, this would tell us we have an una

Re: [RFC 06/10] kmod: provide sanity check on kmod_concurrent access

2016-12-15 Thread Petr Mladek
On Thu 2016-12-08 11:48:50, Luis R. Rodriguez wrote: > Only decrement *iff* we're possitive. Warn if we've hit > a situation where the counter is already 0 after we're done > with a modprobe call, this would tell us we have an unaccounted > counter access -- this in theory should not be possible as

Re: [RFC 06/10] kmod: provide sanity check on kmod_concurrent access

2016-12-14 Thread Luis R. Rodriguez
On Wed, Dec 14, 2016 at 05:08:58PM +0100, Petr Mladek wrote: > On Thu 2016-12-08 11:48:50, Luis R. Rodriguez wrote: > > Only decrement *iff* we're possitive. Warn if we've hit > > a situation where the counter is already 0 after we're done > > with a modprobe call, this would tell us we have an una

Re: [RFC 06/10] kmod: provide sanity check on kmod_concurrent access

2016-12-14 Thread Petr Mladek
On Thu 2016-12-08 11:48:50, Luis R. Rodriguez wrote: > Only decrement *iff* we're possitive. Warn if we've hit > a situation where the counter is already 0 after we're done > with a modprobe call, this would tell us we have an unaccounted > counter access -- this in theory should not be possible as

[RFC 06/10] kmod: provide sanity check on kmod_concurrent access

2016-12-08 Thread Luis R. Rodriguez
Only decrement *iff* we're possitive. Warn if we've hit a situation where the counter is already 0 after we're done with a modprobe call, this would tell us we have an unaccounted counter access -- this in theory should not be possible as only one routine controls the counter, however preemption is