Messages in this thread |  | | Date | Thu, 20 Feb 2003 17:17:52 -0800 | From | Max Krasnyansky <> | Subject | Re: [PATCH/RFC] New module refcounting for net_proto_family |
| |
At 04:30 PM 2/20/2003, Rusty Russell wrote: >In message <5.1.0.14.2.20030220092216.0d3fefd0@mail1.qualcomm.com> you write: >> >There has been talk of this, but OTOH, the admin has explicitly gone >> >out of their way to remove this module. They really don't want anyone >> >new using it. Presumably at this very moment they are killing off all >> >the processes they can find with such a socket. >> The thing is that once those processes are killed sockets will be >> destroyed and release the module anyway. i.e. There is no reason to >> sort of artificially force accept() to fail. Everything will be cleaned >> up once the process is gone. > >Yes, but in practical terms it's probably going to fork a child with >that socket. But it will also be killed.
>> >I think it can be argued both ways, honestly. >> Yep. And I'd argue in for of module_get() :) > >My only real insistence in this is that such an interface be called >__try_module_get(), because the "__" warn people that it's a "you'd >better know *exactly* what you are doing", even though the "try" is a >bit of a misnomer. Yeah, I think 'try' is definitely be a misnomer in this case. How about something like this ?
static inline void __module_get(struct module *mod) { #ifdef CONFIG_MODULE_DETECT_API_VIOLATION if (!module_refcount(mod)) __unsafe(mod); #endif local_inc(&mod->ref[get_cpu()].count); put_cpu(); }
We will be able to compile the kernel with CONFIG_MODULE_DETECT_API_VIOLATION and easily find all modules that call __module_get() without holding a reference.
Comments ?
Max
- 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/
|  |