From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933410AbcLNQJK (ORCPT ); Wed, 14 Dec 2016 11:09:10 -0500 Received: from mx2.suse.de ([195.135.220.15]:33683 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933320AbcLNQJJ (ORCPT ); Wed, 14 Dec 2016 11:09:09 -0500 Date: Wed, 14 Dec 2016 17:08:58 +0100 From: Petr Mladek To: "Luis R. Rodriguez" Cc: shuah@kernel.org, jeyu@redhat.com, rusty@rustcorp.com.au, ebiederm@xmission.com, dmitry.torokhov@gmail.com, acme@redhat.com, corbet@lwn.net, martin.wilck@suse.com, mmarek@suse.com, hare@suse.com, rwright@hpe.com, jeffm@suse.com, DSterba@suse.com, fdmanana@suse.com, neilb@suse.com, linux@roeck-us.net, rgoldwyn@suse.com, subashab@codeaurora.org, xypron.glpk@gmx.de, keescook@chromium.org, atomlin@redhat.com, mbenes@suse.cz, paulmck@linux.vnet.ibm.com, dan.j.williams@intel.com, jpoimboe@redhat.com, davem@davemloft.net, mingo@redhat.com, akpm@linux-foundation.org, torvalds@linux-foundation.org, linux-kselftest@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC 06/10] kmod: provide sanity check on kmod_concurrent access Message-ID: <20161214160858.GI16064@pathway.suse.cz> References: <20161208184801.1689-1-mcgrof@kernel.org> <20161208194850.2627-1-mcgrof@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161208194850.2627-1-mcgrof@kernel.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > only one routine controls the counter, however preemption is > one case that could trigger this situation. Avoid that situation > by disabling preemptiong while we access the counter. I am curious about it. How could enabled preemption cause that the counter will get negative? Unaccounted access would be possible if put() is called without get() or if put() is called before get(). I do not see a way how the value might get negative when the calls are paired and ordered. Best Regards, Petr