Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750927AbdIIT1i (ORCPT ); Sat, 9 Sep 2017 15:27:38 -0400 Received: from mx4.wp.pl ([212.77.101.12]:24426 "EHLO mx4.wp.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750759AbdIIT1h (ORCPT ); Sat, 9 Sep 2017 15:27:37 -0400 Date: Sat, 9 Sep 2017 21:27:32 +0200 From: Jakub Kicinski To: LKML , Dmitry Torokhov Cc: Greg Kroah-Hartman Subject: [bisected] Re: Module removal-related regression? Message-ID: <20170909212732.5bc98775@cakuba.netronome.com> In-Reply-To: <20170909194121.39cd9f56@cakuba.netronome.com> References: <20170909194121.39cd9f56@cakuba.netronome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-WP-MailID: 496209a4d77d993bf59a15a8d37cc2be X-WP-AV: skaner antywirusowy Poczty Wirtualnej Polski X-WP-SPAM: NO 000000A [wZPE] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2208 Lines: 53 On Sat, 9 Sep 2017 19:41:21 +0200, Jakub Kicinski wrote: > Hi! > > I'm having trouble with modules on linux/master. rmmod succeeds but the > module is still loaded and the refcount goes to 1: > > #rmmod nfp; insmod ./src/nfp.ko nfp_pf_netdev=0 ; \ > /opt/netronome/bin/nfp-hwinfo -n 2 assembly.partno \ > lsmod | grep nfp; \ > rmmod nfp; \ > lsmod | grep nfp > nfp 249856 0 > nfp 200704 1 > > If I rmmod again the module will be actually unloaded. The user space > is mostly Ubuntu 14.04. Has anyone seen this? I'm trying to bisect > now... Got 'em! commit 1455cf8dbfd06aa7651dcfccbadb7a093944ca65 (HEAD, refs/bisect/bad) Author: Dmitry Torokhov Date: Wed Jul 19 17:24:30 2017 -0700 driver core: emit uevents when device is bound to a driver There are certain touch controllers that may come up in either normal (application) or boot mode, depending on whether firmware/configuration is corrupted when they are powered on. In boot mode the kernel does not create input device instance (because it does not necessarily know the characteristics of the input device in question). Another number of controllers does not store firmware in a non-volatile memory, and they similarly need to have firmware loaded before input device instance is created. There are also other types of devices with similar behavior. There is a desire to be able to trigger firmware loading via udev, but it has to happen only when driver is bound to a physical device (i2c or spi). These udev actions can not use ADD events, as those happen too early, so we are introducing BIND and UNBIND events that are emitted at the right moment. Also, many drivers create additional driver-specific device attributes when binding to the device, to provide userspace with additional controls. The new events allow userspace to adjust these driver-specific attributes without worrying that they are not there yet. Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman Heeello... :)