2005-08-09 21:21:49 -06:00
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/skbuff.h>
|
|
|
|
#include <linux/netfilter.h>
|
2006-03-20 23:33:17 -07:00
|
|
|
#include <linux/mutex.h>
|
2005-08-09 21:21:49 -06:00
|
|
|
#include <net/sock.h>
|
|
|
|
|
|
|
|
#include "nf_internals.h"
|
|
|
|
|
|
|
|
/* Sockopts only registered and called from user context, so
|
|
|
|
net locking would be overkill. Also, [gs]etsockopt calls may
|
|
|
|
sleep. */
|
2006-03-20 23:33:17 -07:00
|
|
|
static DEFINE_MUTEX(nf_sockopt_mutex);
|
2005-08-09 21:21:49 -06:00
|
|
|
static LIST_HEAD(nf_sockopts);
|
|
|
|
|
|
|
|
/* Do exclusive ranges overlap? */
|
|
|
|
static inline int overlap(int min1, int max1, int min2, int max2)
|
|
|
|
{
|
|
|
|
return max1 > min2 && min1 < max2;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Functions to register sockopt ranges (exclusive). */
|
|
|
|
int nf_register_sockopt(struct nf_sockopt_ops *reg)
|
|
|
|
{
|
2007-11-05 21:44:06 -07:00
|
|
|
struct nf_sockopt_ops *ops;
|
2005-08-09 21:21:49 -06:00
|
|
|
int ret = 0;
|
|
|
|
|
2006-03-20 23:33:17 -07:00
|
|
|
if (mutex_lock_interruptible(&nf_sockopt_mutex) != 0)
|
2005-08-09 21:21:49 -06:00
|
|
|
return -EINTR;
|
|
|
|
|
2007-11-05 21:44:06 -07:00
|
|
|
list_for_each_entry(ops, &nf_sockopts, list) {
|
2005-08-09 21:21:49 -06:00
|
|
|
if (ops->pf == reg->pf
|
2007-02-12 12:15:49 -07:00
|
|
|
&& (overlap(ops->set_optmin, ops->set_optmax,
|
2005-08-09 21:21:49 -06:00
|
|
|
reg->set_optmin, reg->set_optmax)
|
2007-02-12 12:15:49 -07:00
|
|
|
|| overlap(ops->get_optmin, ops->get_optmax,
|
2005-08-09 21:21:49 -06:00
|
|
|
reg->get_optmin, reg->get_optmax))) {
|
|
|
|
NFDEBUG("nf_sock overlap: %u-%u/%u-%u v %u-%u/%u-%u\n",
|
2007-02-12 12:15:49 -07:00
|
|
|
ops->set_optmin, ops->set_optmax,
|
|
|
|
ops->get_optmin, ops->get_optmax,
|
2005-08-09 21:21:49 -06:00
|
|
|
reg->set_optmin, reg->set_optmax,
|
|
|
|
reg->get_optmin, reg->get_optmax);
|
|
|
|
ret = -EBUSY;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
list_add(®->list, &nf_sockopts);
|
|
|
|
out:
|
2006-03-20 23:33:17 -07:00
|
|
|
mutex_unlock(&nf_sockopt_mutex);
|
2005-08-09 21:21:49 -06:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(nf_register_sockopt);
|
|
|
|
|
|
|
|
void nf_unregister_sockopt(struct nf_sockopt_ops *reg)
|
|
|
|
{
|
2006-03-20 23:33:17 -07:00
|
|
|
mutex_lock(&nf_sockopt_mutex);
|
2005-08-09 21:21:49 -06:00
|
|
|
list_del(®->list);
|
2006-03-20 23:33:17 -07:00
|
|
|
mutex_unlock(&nf_sockopt_mutex);
|
2005-08-09 21:21:49 -06:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(nf_unregister_sockopt);
|
|
|
|
|
|
|
|
/* Call get/setsockopt() */
|
2007-02-12 12:15:49 -07:00
|
|
|
static int nf_sockopt(struct sock *sk, int pf, int val,
|
2005-08-09 21:21:49 -06:00
|
|
|
char __user *opt, int *len, int get)
|
|
|
|
{
|
|
|
|
struct nf_sockopt_ops *ops;
|
|
|
|
int ret;
|
|
|
|
|
2007-09-12 05:58:02 -06:00
|
|
|
if (sk->sk_net != &init_net)
|
|
|
|
return -ENOPROTOOPT;
|
|
|
|
|
2006-03-20 23:33:17 -07:00
|
|
|
if (mutex_lock_interruptible(&nf_sockopt_mutex) != 0)
|
2005-08-09 21:21:49 -06:00
|
|
|
return -EINTR;
|
|
|
|
|
2007-11-05 21:44:06 -07:00
|
|
|
list_for_each_entry(ops, &nf_sockopts, list) {
|
2005-08-09 21:21:49 -06:00
|
|
|
if (ops->pf == pf) {
|
[NETFILTER]: Fix/improve deadlock condition on module removal netfilter
So I've had a deadlock reported to me. I've found that the sequence of
events goes like this:
1) process A (modprobe) runs to remove ip_tables.ko
2) process B (iptables-restore) runs and calls setsockopt on a netfilter socket,
increasing the ip_tables socket_ops use count
3) process A acquires a file lock on the file ip_tables.ko, calls remove_module
in the kernel, which in turn executes the ip_tables module cleanup routine,
which calls nf_unregister_sockopt
4) nf_unregister_sockopt, seeing that the use count is non-zero, puts the
calling process into uninterruptible sleep, expecting the process using the
socket option code to wake it up when it exits the kernel
4) the user of the socket option code (process B) in do_ipt_get_ctl, calls
ipt_find_table_lock, which in this case calls request_module to load
ip_tables_nat.ko
5) request_module forks a copy of modprobe (process C) to load the module and
blocks until modprobe exits.
6) Process C. forked by request_module process the dependencies of
ip_tables_nat.ko, of which ip_tables.ko is one.
7) Process C attempts to lock the request module and all its dependencies, it
blocks when it attempts to lock ip_tables.ko (which was previously locked in
step 3)
Theres not really any great permanent solution to this that I can see, but I've
developed a two part solution that corrects the problem
Part 1) Modifies the nf_sockopt registration code so that, instead of using a
use counter internal to the nf_sockopt_ops structure, we instead use a pointer
to the registering modules owner to do module reference counting when nf_sockopt
calls a modules set/get routine. This prevents the deadlock by preventing set 4
from happening.
Part 2) Enhances the modprobe utilty so that by default it preforms non-blocking
remove operations (the same way rmmod does), and add an option to explicity
request blocking operation. So if you select blocking operation in modprobe you
can still cause the above deadlock, but only if you explicity try (and since
root can do any old stupid thing it would like.... :) ).
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-09-11 03:28:26 -06:00
|
|
|
if (!try_module_get(ops->owner))
|
|
|
|
goto out_nosup;
|
2005-08-09 21:21:49 -06:00
|
|
|
if (get) {
|
|
|
|
if (val >= ops->get_optmin
|
|
|
|
&& val < ops->get_optmax) {
|
2006-03-20 23:33:17 -07:00
|
|
|
mutex_unlock(&nf_sockopt_mutex);
|
2005-08-09 21:21:49 -06:00
|
|
|
ret = ops->get(sk, val, opt, len);
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
if (val >= ops->set_optmin
|
|
|
|
&& val < ops->set_optmax) {
|
2006-03-20 23:33:17 -07:00
|
|
|
mutex_unlock(&nf_sockopt_mutex);
|
2005-08-09 21:21:49 -06:00
|
|
|
ret = ops->set(sk, val, opt, *len);
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
}
|
[NETFILTER]: Fix/improve deadlock condition on module removal netfilter
So I've had a deadlock reported to me. I've found that the sequence of
events goes like this:
1) process A (modprobe) runs to remove ip_tables.ko
2) process B (iptables-restore) runs and calls setsockopt on a netfilter socket,
increasing the ip_tables socket_ops use count
3) process A acquires a file lock on the file ip_tables.ko, calls remove_module
in the kernel, which in turn executes the ip_tables module cleanup routine,
which calls nf_unregister_sockopt
4) nf_unregister_sockopt, seeing that the use count is non-zero, puts the
calling process into uninterruptible sleep, expecting the process using the
socket option code to wake it up when it exits the kernel
4) the user of the socket option code (process B) in do_ipt_get_ctl, calls
ipt_find_table_lock, which in this case calls request_module to load
ip_tables_nat.ko
5) request_module forks a copy of modprobe (process C) to load the module and
blocks until modprobe exits.
6) Process C. forked by request_module process the dependencies of
ip_tables_nat.ko, of which ip_tables.ko is one.
7) Process C attempts to lock the request module and all its dependencies, it
blocks when it attempts to lock ip_tables.ko (which was previously locked in
step 3)
Theres not really any great permanent solution to this that I can see, but I've
developed a two part solution that corrects the problem
Part 1) Modifies the nf_sockopt registration code so that, instead of using a
use counter internal to the nf_sockopt_ops structure, we instead use a pointer
to the registering modules owner to do module reference counting when nf_sockopt
calls a modules set/get routine. This prevents the deadlock by preventing set 4
from happening.
Part 2) Enhances the modprobe utilty so that by default it preforms non-blocking
remove operations (the same way rmmod does), and add an option to explicity
request blocking operation. So if you select blocking operation in modprobe you
can still cause the above deadlock, but only if you explicity try (and since
root can do any old stupid thing it would like.... :) ).
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-09-11 03:28:26 -06:00
|
|
|
module_put(ops->owner);
|
2005-08-09 21:21:49 -06:00
|
|
|
}
|
|
|
|
}
|
[NETFILTER]: Fix/improve deadlock condition on module removal netfilter
So I've had a deadlock reported to me. I've found that the sequence of
events goes like this:
1) process A (modprobe) runs to remove ip_tables.ko
2) process B (iptables-restore) runs and calls setsockopt on a netfilter socket,
increasing the ip_tables socket_ops use count
3) process A acquires a file lock on the file ip_tables.ko, calls remove_module
in the kernel, which in turn executes the ip_tables module cleanup routine,
which calls nf_unregister_sockopt
4) nf_unregister_sockopt, seeing that the use count is non-zero, puts the
calling process into uninterruptible sleep, expecting the process using the
socket option code to wake it up when it exits the kernel
4) the user of the socket option code (process B) in do_ipt_get_ctl, calls
ipt_find_table_lock, which in this case calls request_module to load
ip_tables_nat.ko
5) request_module forks a copy of modprobe (process C) to load the module and
blocks until modprobe exits.
6) Process C. forked by request_module process the dependencies of
ip_tables_nat.ko, of which ip_tables.ko is one.
7) Process C attempts to lock the request module and all its dependencies, it
blocks when it attempts to lock ip_tables.ko (which was previously locked in
step 3)
Theres not really any great permanent solution to this that I can see, but I've
developed a two part solution that corrects the problem
Part 1) Modifies the nf_sockopt registration code so that, instead of using a
use counter internal to the nf_sockopt_ops structure, we instead use a pointer
to the registering modules owner to do module reference counting when nf_sockopt
calls a modules set/get routine. This prevents the deadlock by preventing set 4
from happening.
Part 2) Enhances the modprobe utilty so that by default it preforms non-blocking
remove operations (the same way rmmod does), and add an option to explicity
request blocking operation. So if you select blocking operation in modprobe you
can still cause the above deadlock, but only if you explicity try (and since
root can do any old stupid thing it would like.... :) ).
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-09-11 03:28:26 -06:00
|
|
|
out_nosup:
|
2006-03-20 23:33:17 -07:00
|
|
|
mutex_unlock(&nf_sockopt_mutex);
|
2005-08-09 21:21:49 -06:00
|
|
|
return -ENOPROTOOPT;
|
2007-02-12 12:15:49 -07:00
|
|
|
|
2005-08-09 21:21:49 -06:00
|
|
|
out:
|
[NETFILTER]: Fix/improve deadlock condition on module removal netfilter
So I've had a deadlock reported to me. I've found that the sequence of
events goes like this:
1) process A (modprobe) runs to remove ip_tables.ko
2) process B (iptables-restore) runs and calls setsockopt on a netfilter socket,
increasing the ip_tables socket_ops use count
3) process A acquires a file lock on the file ip_tables.ko, calls remove_module
in the kernel, which in turn executes the ip_tables module cleanup routine,
which calls nf_unregister_sockopt
4) nf_unregister_sockopt, seeing that the use count is non-zero, puts the
calling process into uninterruptible sleep, expecting the process using the
socket option code to wake it up when it exits the kernel
4) the user of the socket option code (process B) in do_ipt_get_ctl, calls
ipt_find_table_lock, which in this case calls request_module to load
ip_tables_nat.ko
5) request_module forks a copy of modprobe (process C) to load the module and
blocks until modprobe exits.
6) Process C. forked by request_module process the dependencies of
ip_tables_nat.ko, of which ip_tables.ko is one.
7) Process C attempts to lock the request module and all its dependencies, it
blocks when it attempts to lock ip_tables.ko (which was previously locked in
step 3)
Theres not really any great permanent solution to this that I can see, but I've
developed a two part solution that corrects the problem
Part 1) Modifies the nf_sockopt registration code so that, instead of using a
use counter internal to the nf_sockopt_ops structure, we instead use a pointer
to the registering modules owner to do module reference counting when nf_sockopt
calls a modules set/get routine. This prevents the deadlock by preventing set 4
from happening.
Part 2) Enhances the modprobe utilty so that by default it preforms non-blocking
remove operations (the same way rmmod does), and add an option to explicity
request blocking operation. So if you select blocking operation in modprobe you
can still cause the above deadlock, but only if you explicity try (and since
root can do any old stupid thing it would like.... :) ).
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-09-11 03:28:26 -06:00
|
|
|
module_put(ops->owner);
|
2005-08-09 21:21:49 -06:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
int nf_setsockopt(struct sock *sk, int pf, int val, char __user *opt,
|
|
|
|
int len)
|
|
|
|
{
|
|
|
|
return nf_sockopt(sk, pf, val, opt, &len, 0);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(nf_setsockopt);
|
|
|
|
|
|
|
|
int nf_getsockopt(struct sock *sk, int pf, int val, char __user *opt, int *len)
|
|
|
|
{
|
|
|
|
return nf_sockopt(sk, pf, val, opt, len, 1);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(nf_getsockopt);
|
|
|
|
|
2006-03-20 23:45:21 -07:00
|
|
|
#ifdef CONFIG_COMPAT
|
|
|
|
static int compat_nf_sockopt(struct sock *sk, int pf, int val,
|
2006-03-20 23:48:35 -07:00
|
|
|
char __user *opt, int *len, int get)
|
2006-03-20 23:45:21 -07:00
|
|
|
{
|
|
|
|
struct nf_sockopt_ops *ops;
|
|
|
|
int ret;
|
|
|
|
|
2007-09-12 05:58:02 -06:00
|
|
|
if (sk->sk_net != &init_net)
|
|
|
|
return -ENOPROTOOPT;
|
|
|
|
|
|
|
|
|
2006-03-20 23:45:21 -07:00
|
|
|
if (mutex_lock_interruptible(&nf_sockopt_mutex) != 0)
|
|
|
|
return -EINTR;
|
|
|
|
|
2007-11-05 21:44:06 -07:00
|
|
|
list_for_each_entry(ops, &nf_sockopts, list) {
|
2006-03-20 23:45:21 -07:00
|
|
|
if (ops->pf == pf) {
|
[NETFILTER]: Fix/improve deadlock condition on module removal netfilter
So I've had a deadlock reported to me. I've found that the sequence of
events goes like this:
1) process A (modprobe) runs to remove ip_tables.ko
2) process B (iptables-restore) runs and calls setsockopt on a netfilter socket,
increasing the ip_tables socket_ops use count
3) process A acquires a file lock on the file ip_tables.ko, calls remove_module
in the kernel, which in turn executes the ip_tables module cleanup routine,
which calls nf_unregister_sockopt
4) nf_unregister_sockopt, seeing that the use count is non-zero, puts the
calling process into uninterruptible sleep, expecting the process using the
socket option code to wake it up when it exits the kernel
4) the user of the socket option code (process B) in do_ipt_get_ctl, calls
ipt_find_table_lock, which in this case calls request_module to load
ip_tables_nat.ko
5) request_module forks a copy of modprobe (process C) to load the module and
blocks until modprobe exits.
6) Process C. forked by request_module process the dependencies of
ip_tables_nat.ko, of which ip_tables.ko is one.
7) Process C attempts to lock the request module and all its dependencies, it
blocks when it attempts to lock ip_tables.ko (which was previously locked in
step 3)
Theres not really any great permanent solution to this that I can see, but I've
developed a two part solution that corrects the problem
Part 1) Modifies the nf_sockopt registration code so that, instead of using a
use counter internal to the nf_sockopt_ops structure, we instead use a pointer
to the registering modules owner to do module reference counting when nf_sockopt
calls a modules set/get routine. This prevents the deadlock by preventing set 4
from happening.
Part 2) Enhances the modprobe utilty so that by default it preforms non-blocking
remove operations (the same way rmmod does), and add an option to explicity
request blocking operation. So if you select blocking operation in modprobe you
can still cause the above deadlock, but only if you explicity try (and since
root can do any old stupid thing it would like.... :) ).
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-09-11 03:28:26 -06:00
|
|
|
if (!try_module_get(ops->owner))
|
|
|
|
goto out_nosup;
|
|
|
|
|
2006-03-20 23:45:21 -07:00
|
|
|
if (get) {
|
|
|
|
if (val >= ops->get_optmin
|
|
|
|
&& val < ops->get_optmax) {
|
|
|
|
mutex_unlock(&nf_sockopt_mutex);
|
|
|
|
if (ops->compat_get)
|
|
|
|
ret = ops->compat_get(sk,
|
|
|
|
val, opt, len);
|
|
|
|
else
|
|
|
|
ret = ops->get(sk,
|
|
|
|
val, opt, len);
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
if (val >= ops->set_optmin
|
|
|
|
&& val < ops->set_optmax) {
|
|
|
|
mutex_unlock(&nf_sockopt_mutex);
|
|
|
|
if (ops->compat_set)
|
|
|
|
ret = ops->compat_set(sk,
|
|
|
|
val, opt, *len);
|
|
|
|
else
|
|
|
|
ret = ops->set(sk,
|
|
|
|
val, opt, *len);
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
}
|
[NETFILTER]: Fix/improve deadlock condition on module removal netfilter
So I've had a deadlock reported to me. I've found that the sequence of
events goes like this:
1) process A (modprobe) runs to remove ip_tables.ko
2) process B (iptables-restore) runs and calls setsockopt on a netfilter socket,
increasing the ip_tables socket_ops use count
3) process A acquires a file lock on the file ip_tables.ko, calls remove_module
in the kernel, which in turn executes the ip_tables module cleanup routine,
which calls nf_unregister_sockopt
4) nf_unregister_sockopt, seeing that the use count is non-zero, puts the
calling process into uninterruptible sleep, expecting the process using the
socket option code to wake it up when it exits the kernel
4) the user of the socket option code (process B) in do_ipt_get_ctl, calls
ipt_find_table_lock, which in this case calls request_module to load
ip_tables_nat.ko
5) request_module forks a copy of modprobe (process C) to load the module and
blocks until modprobe exits.
6) Process C. forked by request_module process the dependencies of
ip_tables_nat.ko, of which ip_tables.ko is one.
7) Process C attempts to lock the request module and all its dependencies, it
blocks when it attempts to lock ip_tables.ko (which was previously locked in
step 3)
Theres not really any great permanent solution to this that I can see, but I've
developed a two part solution that corrects the problem
Part 1) Modifies the nf_sockopt registration code so that, instead of using a
use counter internal to the nf_sockopt_ops structure, we instead use a pointer
to the registering modules owner to do module reference counting when nf_sockopt
calls a modules set/get routine. This prevents the deadlock by preventing set 4
from happening.
Part 2) Enhances the modprobe utilty so that by default it preforms non-blocking
remove operations (the same way rmmod does), and add an option to explicity
request blocking operation. So if you select blocking operation in modprobe you
can still cause the above deadlock, but only if you explicity try (and since
root can do any old stupid thing it would like.... :) ).
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-09-11 03:28:26 -06:00
|
|
|
module_put(ops->owner);
|
2006-03-20 23:45:21 -07:00
|
|
|
}
|
|
|
|
}
|
[NETFILTER]: Fix/improve deadlock condition on module removal netfilter
So I've had a deadlock reported to me. I've found that the sequence of
events goes like this:
1) process A (modprobe) runs to remove ip_tables.ko
2) process B (iptables-restore) runs and calls setsockopt on a netfilter socket,
increasing the ip_tables socket_ops use count
3) process A acquires a file lock on the file ip_tables.ko, calls remove_module
in the kernel, which in turn executes the ip_tables module cleanup routine,
which calls nf_unregister_sockopt
4) nf_unregister_sockopt, seeing that the use count is non-zero, puts the
calling process into uninterruptible sleep, expecting the process using the
socket option code to wake it up when it exits the kernel
4) the user of the socket option code (process B) in do_ipt_get_ctl, calls
ipt_find_table_lock, which in this case calls request_module to load
ip_tables_nat.ko
5) request_module forks a copy of modprobe (process C) to load the module and
blocks until modprobe exits.
6) Process C. forked by request_module process the dependencies of
ip_tables_nat.ko, of which ip_tables.ko is one.
7) Process C attempts to lock the request module and all its dependencies, it
blocks when it attempts to lock ip_tables.ko (which was previously locked in
step 3)
Theres not really any great permanent solution to this that I can see, but I've
developed a two part solution that corrects the problem
Part 1) Modifies the nf_sockopt registration code so that, instead of using a
use counter internal to the nf_sockopt_ops structure, we instead use a pointer
to the registering modules owner to do module reference counting when nf_sockopt
calls a modules set/get routine. This prevents the deadlock by preventing set 4
from happening.
Part 2) Enhances the modprobe utilty so that by default it preforms non-blocking
remove operations (the same way rmmod does), and add an option to explicity
request blocking operation. So if you select blocking operation in modprobe you
can still cause the above deadlock, but only if you explicity try (and since
root can do any old stupid thing it would like.... :) ).
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-09-11 03:28:26 -06:00
|
|
|
out_nosup:
|
2006-03-20 23:45:21 -07:00
|
|
|
mutex_unlock(&nf_sockopt_mutex);
|
|
|
|
return -ENOPROTOOPT;
|
|
|
|
|
|
|
|
out:
|
[NETFILTER]: Fix/improve deadlock condition on module removal netfilter
So I've had a deadlock reported to me. I've found that the sequence of
events goes like this:
1) process A (modprobe) runs to remove ip_tables.ko
2) process B (iptables-restore) runs and calls setsockopt on a netfilter socket,
increasing the ip_tables socket_ops use count
3) process A acquires a file lock on the file ip_tables.ko, calls remove_module
in the kernel, which in turn executes the ip_tables module cleanup routine,
which calls nf_unregister_sockopt
4) nf_unregister_sockopt, seeing that the use count is non-zero, puts the
calling process into uninterruptible sleep, expecting the process using the
socket option code to wake it up when it exits the kernel
4) the user of the socket option code (process B) in do_ipt_get_ctl, calls
ipt_find_table_lock, which in this case calls request_module to load
ip_tables_nat.ko
5) request_module forks a copy of modprobe (process C) to load the module and
blocks until modprobe exits.
6) Process C. forked by request_module process the dependencies of
ip_tables_nat.ko, of which ip_tables.ko is one.
7) Process C attempts to lock the request module and all its dependencies, it
blocks when it attempts to lock ip_tables.ko (which was previously locked in
step 3)
Theres not really any great permanent solution to this that I can see, but I've
developed a two part solution that corrects the problem
Part 1) Modifies the nf_sockopt registration code so that, instead of using a
use counter internal to the nf_sockopt_ops structure, we instead use a pointer
to the registering modules owner to do module reference counting when nf_sockopt
calls a modules set/get routine. This prevents the deadlock by preventing set 4
from happening.
Part 2) Enhances the modprobe utilty so that by default it preforms non-blocking
remove operations (the same way rmmod does), and add an option to explicity
request blocking operation. So if you select blocking operation in modprobe you
can still cause the above deadlock, but only if you explicity try (and since
root can do any old stupid thing it would like.... :) ).
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-09-11 03:28:26 -06:00
|
|
|
module_put(ops->owner);
|
2006-03-20 23:45:21 -07:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
int compat_nf_setsockopt(struct sock *sk, int pf,
|
|
|
|
int val, char __user *opt, int len)
|
|
|
|
{
|
|
|
|
return compat_nf_sockopt(sk, pf, val, opt, &len, 0);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(compat_nf_setsockopt);
|
|
|
|
|
|
|
|
int compat_nf_getsockopt(struct sock *sk, int pf,
|
|
|
|
int val, char __user *opt, int *len)
|
|
|
|
{
|
|
|
|
return compat_nf_sockopt(sk, pf, val, opt, len, 1);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(compat_nf_getsockopt);
|
|
|
|
#endif
|