Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751556AbdIJTJZ (ORCPT ); Sun, 10 Sep 2017 15:09:25 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:41662 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750902AbdIJTJY (ORCPT ); Sun, 10 Sep 2017 15:09:24 -0400 Date: Sun, 10 Sep 2017 21:09:08 +0200 From: Greg Kroah-Hartman To: Dmitry Torokhov Cc: Jakub Kicinski , LKML Subject: Re: [bisected] Re: Module removal-related regression? Message-ID: <20170910190908.GA5164@kroah.com> References: <20170909194121.39cd9f56@cakuba.netronome.com> <20170909212732.5bc98775@cakuba.netronome.com> <20170909221726.241c29f6@cakuba.netronome.com> <20170910000338.093aa04e@cakuba.netronome.com> <20170910162111.GA17387@dtor-ws> <20170910200010.4ad7a032@cakuba.netronome.com> <8D38F5B5-C5EA-4436-91CB-B302A42A78F0@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8D38F5B5-C5EA-4436-91CB-B302A42A78F0@gmail.com> User-Agent: Mutt/1.9.0 (2017-09-02) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3928 Lines: 104 On Sun, Sep 10, 2017 at 11:12:17AM -0700, Dmitry Torokhov wrote: > On September 10, 2017 11:00:10 AM PDT, Jakub Kicinski wrote: > >On Sun, 10 Sep 2017 09:21:11 -0700, Dmitry Torokhov wrote: > >> On Sun, Sep 10, 2017 at 12:03:38AM +0200, Jakub Kicinski wrote: > >> > On Sat, 09 Sep 2017 13:59:25 -0700, Dmitry Torokhov wrote: > >> > > On September 9, 2017 1:17:26 PM PDT, Jakub Kicinski > > wrote: > >> > > >On Sat, 9 Sep 2017 12:55:51 -0700, Dmitry Torokhov wrote: > >> > > >> On Sat, Sep 9, 2017 at 12:27 PM, Jakub Kicinski > > > >> > > >wrote: > >> > > >> > 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 > >> > > >> > >> > > >> Does it happen with all modules or only nfp one? > >> > > >> > >> > > >> It seems to work here: > >> > > >> > >> > > >> dtor@dtor-glaptop3:~ $ lsmod | grep psmouse > >> > > >> psmouse 135168 0 > >> > > >> dtor@dtor-glaptop3:~ $ sudo rmmod psmouse > >> > > >> dtor@dtor-glaptop3:~ $ lsmod | grep psmouse > >> > > >> dtor@dtor-glaptop3:~ $ sudo modprobe psmouse > >> > > > > >> > > >It looks like the driver is actually reloaded. The driver used > >to > >> > > >return EPROBE_DEFER, but I think it doesn't any more (rebuilding > >the > >> > > >kernel to test that right now). > >> > > > > >> > > >Could the uevent on unbind tickle Ubuntu 14.04's udev or somehow > >> > > >else cause the driver to be loaded again? > >> > > > >> > > It depends on how silly the udev rules are, but yes, this can > >definitely happen. > >> > > >> > I confirmed the driver doesn't use EPROBE_DEFER any more: > >> > > >> > $ grep -nrI EPROBE_DEFER drivers/net/ethernet/netronome/ > >> > $ > >> > >> Not sure why you bring the deferrals here, they have nothing to do > >with > >> module removal. Also, deferrals are rarely issued by the leaf driver, > >and > >> more often by providers of resources (GPIO, regulator, interrupt, > >etc). > > > >Yes, it's unusual, but this driver used to do it. Which is exactly why > >I brought it up. Turns out it was irrelevant :) > > > >> > I tested without any udev rules in /etc/udev/, just the standard > >distro > >> > ones. Same thing. > >> > >> Right, so this is the default udev rule: > >> > >> /lib/udev/rules.d/80-drivers.rules: > >> > >> # do not edit this file, it will be overwritten on update > >> > >> ACTION=="remove", GOTO="drivers_end" > >> > >> ENV{MODALIAS}=="?*", RUN{builtin}="kmod load $env{MODALIAS}" So if the new uevents do not have the MODALIAS line in them, then they will not trigger this? Dmitry, can you see if that would fix this problem without having to fix everyone's old versions of udev/systemd? thanks, greg k-h