Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752686AbaLWAVX (ORCPT ); Mon, 22 Dec 2014 19:21:23 -0500 Received: from ozlabs.org ([103.22.144.67]:48886 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751114AbaLWAVW (ORCPT ); Mon, 22 Dec 2014 19:21:22 -0500 From: Rusty Russell To: Linus Torvalds Cc: Ionut Alexa , Kees Cook , Masami Hiramatsu , lkml Subject: Re: [PULL] modules-next In-Reply-To: References: <8761d8tq4p.fsf@rustcorp.com.au> User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-pc-linux-gnu) Date: Mon, 22 Dec 2014 11:51:10 +1030 Message-ID: <87zjagv5rt.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Linus Torvalds writes: > On Thu, Dec 18, 2014 at 4:55 PM, Rusty Russell wrote: >> >> The exciting thing here is the getting rid of stop_machine on module >> removal. This is possible by using a simple atomic_t for the counter, >> rather than our fancy per-cpu counter: it turns out that no one is doing >> a module increment per net packet, so the slowdown should be in the noise. > > Famous last words. It may not happen per-packet, but I see > module_get() in various block drivers and in netfilter code etc, and > some of them may be pretty bad. > > Let's see how it all works out. Indeed. The general pattern is "get on open/init"; get-on-every-use was most useful combined with blocking rmmod, which we removed a few kernels ago (because no one used it). I did a random audit until I got bored, and I put a printk-on-module-get in my kernels for a while, and none of my usecases flood my logs. But it's definitely a risk... Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/