[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20120117.124449.1065919030248165158.davem@davemloft.net>
Date: Tue, 17 Jan 2012 12:44:49 -0500 (EST)
From: David Miller <davem@...emloft.net>
To: fruggeri@...stanetworks.com
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] net: race condition in ipv6 forwarding and
disable_ipv6 parameters
From: Francesco Ruggeri <fruggeri@...stanetworks.com>
Date: Mon, 16 Jan 2012 12:40:10 -0800
> -static int addrconf_fixup_forwarding(struct ctl_table *table, int *p, int old)
> +static int addrconf_fixup_forwarding(struct ctl_table *table, int *p, int newf)
...
> @@ -4257,9 +4259,17 @@ int addrconf_sysctl_forward(ctl_table *c
> int *valp = ctl->data;
> int val = *valp;
> loff_t pos = *ppos;
> + ctl_table lctl;
> int ret;
>
> - ret = proc_dointvec(ctl, write, buffer, lenp, ppos);
> + /*
> + * ctl->data points to idev->cnf.forwarding, we should
> + * not modify it until we get the rtnl lock.
> + */
> + lctl = *ctl;
> + lctl.data = &val;
> +
> + ret = proc_dointvec(&lctl, write, buffer, lenp, ppos);
>
> if (write)
> ret = addrconf_fixup_forwarding(ctl, valp, val);
I don't understand this at all.
"val" is still the old value, before proc_dointvec() runs, after your
changes. So renaming the argument to addrconf_fixup_forwarding() as
"newf" and treating it as the new value doesn't make any sense at all.
Did you really test this patch?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists