diff options
author | Frank Filz <ffilzlnx@us.ibm.com> | 2005-09-27 15:23:38 -0700 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2005-09-27 15:23:38 -0700 |
commit | a79af59efd20990473d579b1d8d70bb120f0920c (patch) | |
tree | 763cc7f083cf922e30537c89d92765415ada78e4 /drivers/net/Makefile | |
parent | 9356b8fc07dc126cd91d2b12f314d760ab48996e (diff) |
[NET]: Fix module reference counts for loadable protocol modules
I have been experimenting with loadable protocol modules, and ran into
several issues with module reference counting.
The first issue was that __module_get failed at the BUG_ON check at
the top of the routine (checking that my module reference count was
not zero) when I created the first socket. When sk_alloc() is called,
my module reference count was still 0. When I looked at why sctp
didn't have this problem, I discovered that sctp creates a control
socket during module init (when the module ref count is not 0), which
keeps the reference count non-zero. This section has been updated to
address the point Stephen raised about checking the return value of
try_module_get().
The next problem arose when my socket init routine returned an error.
This resulted in my module reference count being decremented below 0.
My socket ops->release routine was also being called. The issue here
is that sock_release() calls the ops->release routine and decrements
the ref count if sock->ops is not NULL. Since the socket probably
didn't get correctly initialized, this should not be done, so we will
set sock->ops to NULL because we will not call try_module_get().
While searching for another bug, I also noticed that sys_accept() has
a possibility of doing a module_put() when it did not do an
__module_get so I re-ordered the call to security_socket_accept().
Signed-off-by: Frank Filz <ffilzlnx@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers/net/Makefile')
0 files changed, 0 insertions, 0 deletions