* Re: unable to handle paging request, arm, at aio/tcp code, only 3.6
From: Lluís Batlle i Rossell @ 2012-11-20 6:55 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1353360858.10798.86.camel@edumazet-glaptop>
On Mon, Nov 19, 2012 at 01:34:18PM -0800, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> > Thanks for the report.
> >
> > I believe this is a regression of commit
> > 35ad9b9cf7d8a2e6259a0d24022e910adb6f3489
> > (ipv6: Add helper inet6_csk_update_pmtu().)
> >
> > I'll prepare a patch to fix this.
>
> Please try the following fix.
>
> Thanks !
Ok, I'm running it. Let's see if it crashes today.
Thank you!
^ permalink raw reply
* Re: [Suggestion] net/tipc: can delete checking: (if_local_len > TIPC_MAX_IF_NAME) || (if_peer_len > TIPC_MAX_IF_NAME)
From: Chen Gang @ 2012-11-20 5:25 UTC (permalink / raw)
To: Xue Ying; +Cc: David Miller, Shan Wei, Eric Dumazet, netdev
In-Reply-To: <50AB12EE.6050802@gmail.com>
于 2012年11月20日 13:19, Xue Ying 写道:
> Chen Gang wrote:
>> Hello David Miller:
>>
>> at net/tipc/link.c:212,213, we can delete the check (if_local_len > TIPC_MAX_IF_NAME) and (if_peer_len > TIPC_MAX_IF_NAME)
>> for the total buffer length is no more than TIPC_MAX_IF_NAME, already (at line 182..186).
>>
>>
>
> The length of name_copy array is TIPC_MAX_LINK_NAME(i.e, 60) while
> TIPC_MAX_IF_NAME is defined to 16, why does the former is more than the
> latter?
>
> Regards,
> Ying
>
It is my fault. thanks.
Regards,
gchen
>> suggest to modify it, although it is minor.
>>
>> thanks.
>>
>>
>> 167 static int link_name_validate(const char *name,
>> 168 struct tipc_link_name *name_parts)
>> 169 {
>> 170 char name_copy[TIPC_MAX_LINK_NAME];
>> 171 char *addr_local;
>> 172 char *if_local;
>> 173 char *addr_peer;
>> 174 char *if_peer;
>> 175 char dummy;
>> 176 u32 z_local, c_local, n_local;
>> 177 u32 z_peer, c_peer, n_peer;
>> 178 u32 if_local_len;
>> 179 u32 if_peer_len;
>> 180
>> 181 /* copy link name & ensure length is OK */
>> 182 name_copy[TIPC_MAX_LINK_NAME - 1] = 0;
>> 183 /* need above in case non-Posix strncpy() doesn't pad with nulls */
>> 184 strncpy(name_copy, name, TIPC_MAX_LINK_NAME);
>> 185 if (name_copy[TIPC_MAX_LINK_NAME - 1] != 0)
>> 186 return 0;
>> 187
>> 188 /* ensure all component parts of link name are present */
>> 189 addr_local = name_copy;
>> 190 if_local = strchr(addr_local, ':');
>> 191 if (if_local == NULL)
>> 192 return 0;
>> 193 *(if_local++) = 0;
>> 194 addr_peer = strchr(if_local, '-');
>> 195 if (addr_peer == NULL)
>> 196 return 0;
>> 197 *(addr_peer++) = 0;
>> 198 if_local_len = addr_peer - if_local;
>> 199 if_peer = strchr(addr_peer, ':');
>> 200 if (if_peer == NULL)
>> 201 return 0;
>> 202 *(if_peer++) = 0;
>> 203 if_peer_len = strlen(if_peer) + 1;
>> 204
>> 205 /* validate component parts of link name */
>> 206 if ((sscanf(addr_local, "%u.%u.%u%c",
>> 207 &z_local, &c_local, &n_local, &dummy) != 3) ||
>> 208 (sscanf(addr_peer, "%u.%u.%u%c",
>> 209 &z_peer, &c_peer, &n_peer, &dummy) != 3) ||
>> 210 (z_local > 255) || (c_local > 4095) || (n_local > 4095) ||
>> 211 (z_peer > 255) || (c_peer > 4095) || (n_peer > 4095) ||
>> 212 (if_local_len <= 1) || (if_local_len > TIPC_MAX_IF_NAME) ||
>> 213 (if_peer_len <= 1) || (if_peer_len > TIPC_MAX_IF_NAME))
>> 214 return 0;
>> 215
>> 216 /* return link name components, if necessary */
>> 217 if (name_parts) {
>> 218 name_parts->addr_local = tipc_addr(z_local, c_local, n_local);
>> 219 strcpy(name_parts->if_local, if_local);
>> 220 name_parts->addr_peer = tipc_addr(z_peer, c_peer, n_peer);
>> 221 strcpy(name_parts->if_peer, if_peer);
>> 222 }
>> 223 return 1;
>> 224 }
>>
>>
>>
>>
>
>
>
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* Re: [Suggestion] net/tipc: can delete checking: (if_local_len > TIPC_MAX_IF_NAME) || (if_peer_len > TIPC_MAX_IF_NAME)
From: Xue Ying @ 2012-11-20 5:19 UTC (permalink / raw)
To: Chen Gang; +Cc: David Miller, Shan Wei, Eric Dumazet, netdev
In-Reply-To: <50AB0249.20802@asianux.com>
Chen Gang wrote:
> Hello David Miller:
>
> at net/tipc/link.c:212,213, we can delete the check (if_local_len > TIPC_MAX_IF_NAME) and (if_peer_len > TIPC_MAX_IF_NAME)
> for the total buffer length is no more than TIPC_MAX_IF_NAME, already (at line 182..186).
>
>
The length of name_copy array is TIPC_MAX_LINK_NAME(i.e, 60) while
TIPC_MAX_IF_NAME is defined to 16, why does the former is more than the
latter?
Regards,
Ying
> suggest to modify it, although it is minor.
>
> thanks.
>
>
> 167 static int link_name_validate(const char *name,
> 168 struct tipc_link_name *name_parts)
> 169 {
> 170 char name_copy[TIPC_MAX_LINK_NAME];
> 171 char *addr_local;
> 172 char *if_local;
> 173 char *addr_peer;
> 174 char *if_peer;
> 175 char dummy;
> 176 u32 z_local, c_local, n_local;
> 177 u32 z_peer, c_peer, n_peer;
> 178 u32 if_local_len;
> 179 u32 if_peer_len;
> 180
> 181 /* copy link name & ensure length is OK */
> 182 name_copy[TIPC_MAX_LINK_NAME - 1] = 0;
> 183 /* need above in case non-Posix strncpy() doesn't pad with nulls */
> 184 strncpy(name_copy, name, TIPC_MAX_LINK_NAME);
> 185 if (name_copy[TIPC_MAX_LINK_NAME - 1] != 0)
> 186 return 0;
> 187
> 188 /* ensure all component parts of link name are present */
> 189 addr_local = name_copy;
> 190 if_local = strchr(addr_local, ':');
> 191 if (if_local == NULL)
> 192 return 0;
> 193 *(if_local++) = 0;
> 194 addr_peer = strchr(if_local, '-');
> 195 if (addr_peer == NULL)
> 196 return 0;
> 197 *(addr_peer++) = 0;
> 198 if_local_len = addr_peer - if_local;
> 199 if_peer = strchr(addr_peer, ':');
> 200 if (if_peer == NULL)
> 201 return 0;
> 202 *(if_peer++) = 0;
> 203 if_peer_len = strlen(if_peer) + 1;
> 204
> 205 /* validate component parts of link name */
> 206 if ((sscanf(addr_local, "%u.%u.%u%c",
> 207 &z_local, &c_local, &n_local, &dummy) != 3) ||
> 208 (sscanf(addr_peer, "%u.%u.%u%c",
> 209 &z_peer, &c_peer, &n_peer, &dummy) != 3) ||
> 210 (z_local > 255) || (c_local > 4095) || (n_local > 4095) ||
> 211 (z_peer > 255) || (c_peer > 4095) || (n_peer > 4095) ||
> 212 (if_local_len <= 1) || (if_local_len > TIPC_MAX_IF_NAME) ||
> 213 (if_peer_len <= 1) || (if_peer_len > TIPC_MAX_IF_NAME))
> 214 return 0;
> 215
> 216 /* return link name components, if necessary */
> 217 if (name_parts) {
> 218 name_parts->addr_local = tipc_addr(z_local, c_local, n_local);
> 219 strcpy(name_parts->if_local, if_local);
> 220 name_parts->addr_peer = tipc_addr(z_peer, c_peer, n_peer);
> 221 strcpy(name_parts->if_peer, if_peer);
> 222 }
> 223 return 1;
> 224 }
>
>
>
>
^ permalink raw reply
* [Suggestion] net/tipc: can delete checking: (if_local_len > TIPC_MAX_IF_NAME) || (if_peer_len > TIPC_MAX_IF_NAME)
From: Chen Gang @ 2012-11-20 4:08 UTC (permalink / raw)
To: David Miller; +Cc: Shan Wei, Eric Dumazet, netdev
Hello David Miller:
at net/tipc/link.c:212,213, we can delete the check (if_local_len > TIPC_MAX_IF_NAME) and (if_peer_len > TIPC_MAX_IF_NAME)
for the total buffer length is no more than TIPC_MAX_IF_NAME, already (at line 182..186).
suggest to modify it, although it is minor.
thanks.
167 static int link_name_validate(const char *name,
168 struct tipc_link_name *name_parts)
169 {
170 char name_copy[TIPC_MAX_LINK_NAME];
171 char *addr_local;
172 char *if_local;
173 char *addr_peer;
174 char *if_peer;
175 char dummy;
176 u32 z_local, c_local, n_local;
177 u32 z_peer, c_peer, n_peer;
178 u32 if_local_len;
179 u32 if_peer_len;
180
181 /* copy link name & ensure length is OK */
182 name_copy[TIPC_MAX_LINK_NAME - 1] = 0;
183 /* need above in case non-Posix strncpy() doesn't pad with nulls */
184 strncpy(name_copy, name, TIPC_MAX_LINK_NAME);
185 if (name_copy[TIPC_MAX_LINK_NAME - 1] != 0)
186 return 0;
187
188 /* ensure all component parts of link name are present */
189 addr_local = name_copy;
190 if_local = strchr(addr_local, ':');
191 if (if_local == NULL)
192 return 0;
193 *(if_local++) = 0;
194 addr_peer = strchr(if_local, '-');
195 if (addr_peer == NULL)
196 return 0;
197 *(addr_peer++) = 0;
198 if_local_len = addr_peer - if_local;
199 if_peer = strchr(addr_peer, ':');
200 if (if_peer == NULL)
201 return 0;
202 *(if_peer++) = 0;
203 if_peer_len = strlen(if_peer) + 1;
204
205 /* validate component parts of link name */
206 if ((sscanf(addr_local, "%u.%u.%u%c",
207 &z_local, &c_local, &n_local, &dummy) != 3) ||
208 (sscanf(addr_peer, "%u.%u.%u%c",
209 &z_peer, &c_peer, &n_peer, &dummy) != 3) ||
210 (z_local > 255) || (c_local > 4095) || (n_local > 4095) ||
211 (z_peer > 255) || (c_peer > 4095) || (n_peer > 4095) ||
212 (if_local_len <= 1) || (if_local_len > TIPC_MAX_IF_NAME) ||
213 (if_peer_len <= 1) || (if_peer_len > TIPC_MAX_IF_NAME))
214 return 0;
215
216 /* return link name components, if necessary */
217 if (name_parts) {
218 name_parts->addr_local = tipc_addr(z_local, c_local, n_local);
219 strcpy(name_parts->if_local, if_local);
220 name_parts->addr_peer = tipc_addr(z_peer, c_peer, n_peer);
221 strcpy(name_parts->if_peer, if_peer);
222 }
223 return 1;
224 }
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* Re: [PATCH] bonding: rlb mode of bond should not alter ARP originating via bridge
From: Jay Vosburgh @ 2012-11-20 1:02 UTC (permalink / raw)
To: Zheng Li; +Cc: netdev, andy, linux-kernel, davem, joe.jin
In-Reply-To: <1352972861-17577-1-git-send-email-zheng.x.li@oracle.com>
Zheng Li <zheng.x.li@oracle.com> wrote:
>ARP traffic passing through a bridge and out via the bond (when the bond is a
>port of the bridge) should not have its source MAC address adjusted by the
>receive load balance code in rlb_arp_xmit.
This patch differs from prior versions in that it does more than
what's described here; it also disables the receive load balance logic
for any ARPs (request or reply) that are passing through the bond (not
of local origin). For ARP replies, that's mostly harmless, as the ARPs
passing through will simply always be sent from one particular slave
(the active slave) instead of being balanced.
For ARP requests, though, they are already always sent via the
active slave, but there is also some logic in rlb_arp_xmit to limit the
side effects from the broadcast ARP, in particular this part:
/* The ARP reply packets must be delayed so that
* they can cancel out the influence of the ARP request.
*/
bond->alb_info.rlb_update_delay_counter = RLB_UPDATE_DELAY;
/* arp requests are broadcast and are sent on the primary
* the arp request will collapse all clients on the subnet to
* the primary slave. We must register these clients to be
* updated with their assigned mac.
*/
rlb_req_update_subnet_clients(bond, arp->ip_src);
that arranges for clients to be given ARP updates for their
slave assignments (which may change to the active slave, due to the ARP
broadcast being sent via the active slave).
I think the ARP reply side of this is fine (and is what is
described in teh changelog), but the ARP request behavior change is new
with this version.
Since prior versions of the patch didn't cause this code to be
skipped, is this change intentional?
Did you check to see if the above logic is necessary for ARP
requests passing through via a bridge to prevent peers from "stacking"
(in terms of load balance assignment) on the active slave due to bridged
ARP traffic?
-J
>Signed-off-by: Zheng Li <zheng.x.li@oracle.com>
>Cc: Jay Vosburgh <fubar@us.ibm.com>
>Cc: Andy Gospodarek <andy@greyhouse.net>
>Cc: "David S. Miller" <davem@davemloft.net>
>
>---
> drivers/net/bonding/bond_alb.c | 6 ++++++
> drivers/net/bonding/bonding.h | 13 +++++++++++++
> 2 files changed, 19 insertions(+), 0 deletions(-)
>
>diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
>index e15cc11..75f6f0d 100644
>--- a/drivers/net/bonding/bond_alb.c
>+++ b/drivers/net/bonding/bond_alb.c
>@@ -694,6 +694,12 @@ static struct slave *rlb_arp_xmit(struct sk_buff *skb, struct bonding *bond)
> struct arp_pkt *arp = arp_pkt(skb);
> struct slave *tx_slave = NULL;
>
>+ /* Only modify ARP's MAC if it originates locally;
>+ * don't change ARPs arriving via a bridge.
>+ */
>+ if (!bond_slave_has_mac(bond, arp->mac_src))
>+ return NULL;
>+
> if (arp->op_code == htons(ARPOP_REPLY)) {
> /* the arp must be sent on the selected
> * rx channel
>diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
>index f8af2fc..6dded56 100644
>--- a/drivers/net/bonding/bonding.h
>+++ b/drivers/net/bonding/bonding.h
>@@ -22,6 +22,7 @@
> #include <linux/in6.h>
> #include <linux/netpoll.h>
> #include <linux/inetdevice.h>
>+#include <linux/etherdevice.h>
> #include "bond_3ad.h"
> #include "bond_alb.h"
>
>@@ -450,6 +451,18 @@ static inline void bond_destroy_proc_dir(struct bond_net *bn)
> }
> #endif
>
>+static inline struct slave *bond_slave_has_mac(struct bonding *bond,
>+ const u8 *mac)
>+{
>+ int i = 0;
>+ struct slave *tmp;
>+
>+ bond_for_each_slave(bond, tmp, i)
>+ if (ether_addr_equal_64bits(mac, tmp->dev->dev_addr))
>+ return tmp;
>+
>+ return NULL;
>+}
>
> /* exported from bond_main.c */
> extern int bond_net_id;
>--
>1.7.6.5
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [PATCH net-next 0/3] Remove inet_lro remnants
From: David Miller @ 2012-11-20 0:14 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, eric.dumazet
In-Reply-To: <1353105635.2743.49.camel@bwh-desktop.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Fri, 16 Nov 2012 22:40:35 +0000
> Eric's comments on LRO/GRO conversion prompted me to check what was
> still using inet_lro. Not very many drivers, but there are a few
> unnecessary references outside the code.
Series applied, thanks Ben.
^ permalink raw reply
* Re: [PATCH] netfilter: Remove the spurious \ in __ip_vs_lblc_init
From: David Miller @ 2012-11-20 0:12 UTC (permalink / raw)
To: horms; +Cc: ebiederm, netdev, pablo
In-Reply-To: <20121120000649.GC13829@verge.net.au>
From: Simon Horman <horms@verge.net.au>
Date: Tue, 20 Nov 2012 09:06:49 +0900
> On Mon, Nov 19, 2012 at 07:26:30AM -0800, Eric W. Biederman wrote:
>>
>> In (464dc801c76a net: Don't export sysctls to unprivileged users)
>> I typoed and introduced a spurious backslash. Delete it.
>>
>> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
>
> Signed-off-by: Simon Horman <horms@verge.net.au>
>
> Pablo, can you take this directly through your tree?
I already applied this to net-next yesterday.
^ permalink raw reply
* Re: [PATCH] netfilter: Remove the spurious \ in __ip_vs_lblc_init
From: Simon Horman @ 2012-11-20 0:12 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: David Miller, netdev, Pablo Neira Ayuso
In-Reply-To: <20121120000649.GC13829@verge.net.au>
On Tue, Nov 20, 2012 at 09:06:49AM +0900, Simon Horman wrote:
> On Mon, Nov 19, 2012 at 07:26:30AM -0800, Eric W. Biederman wrote:
> >
> > In (464dc801c76a net: Don't export sysctls to unprivileged users)
> > I typoed and introduced a spurious backslash. Delete it.
> >
> > Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
>
> Signed-off-by: Simon Horman <horms@verge.net.au>
>
> Pablo, can you take this directly through your tree?
Scratch that, I see that David has already applied this change.
^ permalink raw reply
* Re: [PATCH] net: remove unnecessary wireless includes
From: David Miller @ 2012-11-20 0:10 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, netdev, johannes.berg
In-Reply-To: <1353099561-14339-1-git-send-email-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Fri, 16 Nov 2012 21:59:21 +0100
> From: Johannes Berg <johannes.berg@intel.com>
>
> The wireless and wext includes in net-sysfs.c aren't
> needed, so remove them.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Applied, thanks Johannes.
^ permalink raw reply
* Re: [PATCH net-next] gro: Handle inline VLAN tags
From: David Miller @ 2012-11-20 0:10 UTC (permalink / raw)
To: eric.dumazet; +Cc: bhutchings, netdev, linux-net-drivers, gallatin, herbert
In-Reply-To: <1353114559.10798.66.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 16 Nov 2012 17:09:19 -0800
> On Sat, 2012-11-17 at 00:32 +0000, Ben Hutchings wrote:
>> On Fri, 2012-11-16 at 16:16 -0800, Eric Dumazet wrote:
>> > On Sat, 2012-11-17 at 00:00 +0000, Ben Hutchings wrote:
>> >
>> > > I'm not sure what you mean by this. Is your point that the
>> > > copy-on-write is never needed? It is still possible for pskb_may_pull()
>> > > to fail.
>> > >
>> >
>> > A packet sniffer should have a copy of bad frames, even if dropped later
>> > in our stacks.
>> >
>> > GRO layer is not allowed to drop a frame, even if not 'correct'.
>>
>> What do you think the accelerated hardware does with frames that have a
>> truncated VLAN tag?
>
> The hardware should send us the frame, exactly like when RX checksum is
> wrong.
I agree with Eric, and therefore will not apply this patch.
^ permalink raw reply
* Re: [PATCH net-next 1/4] ipip: allow to deactivate the creation of fb dev
From: David Miller @ 2012-11-20 0:07 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: shemminger, netdev
In-Reply-To: <50A66DD3.20807@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Fri, 16 Nov 2012 17:46:11 +0100
> By default, the fb device is created, so there is no change if you
> don't set explicitly setup_fb to 0.
Nicolas, this idea is contentous to me too.
Why not put this aside and submit the other parts of your
patch set on their own, since those looked fine to me?
Thanks.
^ permalink raw reply
* Re: [PATCH] netfilter: Remove the spurious \ in __ip_vs_lblc_init
From: Simon Horman @ 2012-11-20 0:06 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: David Miller, netdev, Pablo Neira Ayuso
In-Reply-To: <87zk2d7gwp.fsf@xmission.com>
On Mon, Nov 19, 2012 at 07:26:30AM -0800, Eric W. Biederman wrote:
>
> In (464dc801c76a net: Don't export sysctls to unprivileged users)
> I typoed and introduced a spurious backslash. Delete it.
>
> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
Pablo, can you take this directly through your tree?
> ---
> net/netfilter/ipvs/ip_vs_lblc.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/netfilter/ipvs/ip_vs_lblc.c b/net/netfilter/ipvs/ip_vs_lblc.c
> index d742aa9..fdd89b9 100644
> --- a/net/netfilter/ipvs/ip_vs_lblc.c
> +++ b/net/netfilter/ipvs/ip_vs_lblc.c
> @@ -574,7 +574,7 @@ static int __net_init __ip_vs_lblc_init(struct net *net)
> register_net_sysctl(net, "net/ipv4/vs", ipvs->lblc_ctl_table);
> if (!ipvs->lblc_ctl_header) {
> if (!net_eq(net, &init_net))
> - kfree(ipvs->lblc_ctl_table);\
> + kfree(ipvs->lblc_ctl_table);
> return -ENOMEM;
> }
>
> --
> 1.7.5.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH net-next 1/4] ipip: allow to deactivate the creation of fb dev
From: David Miller @ 2012-11-20 0:06 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev
In-Reply-To: <1353082456-21234-2-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Fri, 16 Nov 2012 17:14:13 +0100
> Now that tunnels can be configured via rtnetlink, this device is not mandatory.
> The default is conservative.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
I'm not too thrilled about this change, mostly because of my dislike of
module parameters in general.
But in this case there appears to be real bugs in the two sets of changes
where you add this setup_fb thing.
> @@ -1057,7 +1066,8 @@ static void __net_exit ipip_exit_net(struct net *net)
>
> rtnl_lock();
> ipip_destroy_tunnels(ipn, &list);
> - unregister_netdevice_queue(ipn->fb_tunnel_dev, &list);
> + if (setup_fb)
> + unregister_netdevice_queue(ipn->fb_tunnel_dev, &list);
> unregister_netdevice_many(&list);
> rtnl_unlock();
> }
Users can modify module parameter values via sysfs after the module
is loaded, so you need a more internal and protected state to use
to decide whether you really need to unregister the thing or not.
But to me it's just symptomatic of what a bad idea this is in the
first place.
^ permalink raw reply
* Re: [net-next PATCH v2] net/ethernet: remove useless is_valid_ether_addr from drivers ndo_open
From: David Miller @ 2012-11-20 0:03 UTC (permalink / raw)
To: manabian
Cc: nicolas.ferre, shemminger, steve.glendinning, stigge, msink,
netdev
In-Reply-To: <1353077235-342-1-git-send-email-manabian@gmail.com>
From: Joachim Eastwood <manabian@gmail.com>
Date: Fri, 16 Nov 2012 15:47:15 +0100
> If ndo_validate_addr is set to the generic eth_validate_addr
> function there is no point in calling is_valid_ether_addr
> from driver ndo_open if ndo_open is not used elsewhere in
> the driver.
>
> With this change is_valid_ether_addr will be called from the
> generic eth_validate_addr function. So there should be no change
> in the actual behavior.
>
> Signed-off-by: Joachim Eastwood <manabian@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v4 2/9] net: rds: use this_cpu_* per-cpu helper
From: David Miller @ 2012-11-20 0:00 UTC (permalink / raw)
To: shanwei88
Cc: venkat.x.venkatsubra, rds-devel, netdev, linux-kernel, cl, htejun
In-Reply-To: <50A5FB89.4000400@gmail.com>
From: Shan Wei <shanwei88@gmail.com>
Date: Fri, 16 Nov 2012 16:38:33 +0800
> Shan Wei said, at 2012/11/13 9:52:
>> From: Shan Wei <davidshan@tencent.com>
>>
>>
>> Signed-off-by: Shan Wei <davidshan@tencent.com>
>> Reviewed-by: Christoph Lameter <cl@linux.com>
>
> David Miller, would you like to pick it up to your net-next tree?
Applied.
^ permalink raw reply
* Re: [PATCH v4 1/9] net: core: use this_cpu_ptr per-cpu helper
From: David Miller @ 2012-11-20 0:00 UTC (permalink / raw)
To: shanwei88; +Cc: timo.teras, steffen.klassert, netdev, linux-kernel, cl, htejun
In-Reply-To: <50A5FB69.8000907@gmail.com>
From: Shan Wei <shanwei88@gmail.com>
Date: Fri, 16 Nov 2012 16:38:01 +0800
> Shan Wei said, at 2012/11/13 9:51:
>> From: Shan Wei <davidshan@tencent.com>
>>
>> flush_tasklet is a struct, not a pointer in percpu var.
>> so use this_cpu_ptr to get the member pointer.
>>
>> Signed-off-by: Shan Wei <davidshan@tencent.com>
>> Reviewed-by: Christoph Lameter <cl@linux.com>
>
> David Miller, would you like to pick it up to your net-next tree?
Applied.
^ permalink raw reply
* Re: [PATCH v2 3.7.0-rc4] of/net/mdio-gpio: Fix pdev->id issue when using devicetrees.
From: David Miller @ 2012-11-19 23:58 UTC (permalink / raw)
To: srinivas.kandagatla; +Cc: netdev, devicetree-discuss
In-Reply-To: <1353062039-31336-1-git-send-email-srinivas.kandagatla@st.com>
From: Srinivas KANDAGATLA <srinivas.kandagatla@st.com>
Date: Fri, 16 Nov 2012 10:33:59 +0000
> From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
>
> When the mdio-gpio driver is probed via device trees, the platform
> device id is set as -1, However the pdev->id is re-used as bus-id for
> while creating mdio gpio bus.
> So
> For device tree case the mdio-gpio bus name appears as "gpio-ffffffff"
> where as
> for non-device tree case the bus name appears as "gpio-<bus-num>"
>
> Which means the bus_id is fixed in device tree case, so we can't have
> two mdio gpio buses via device trees. Assigning a logical bus number
> via device tree solves the problem and the bus name is much consistent
> with non-device tree bus name.
>
> Without this patch
> 1. we can't support two mdio-gpio buses via device trees.
> 2. we should always pass gpio-ffffffff as bus name to phy_connect, very
> different to non-device tree bus name.
>
> So, setting up the bus_id via aliases from device tree is the right
> solution and other drivers do similar thing.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCHv2 net-next] add DOVE extensions for VXLAN
From: David Miller @ 2012-11-19 23:55 UTC (permalink / raw)
To: dlstevens; +Cc: shemminger, netdev
In-Reply-To: <201211151347.qAFDkR8G023134@lab1.dls>
From: David L Stevens <dlstevens@us.ibm.com>
Date: Thu, 15 Nov 2012 08:46:27 -0500
> @@ -111,6 +113,10 @@ struct vxlan_dev {
> __u8 tos; /* TOS override */
> __u8 ttl;
> bool learn;
> + bool proxy; /* ARP reduction */
> + bool rsc; /* route short-circuit */
> + bool l2miss; /* L2 miss notifications */
> + bool l3miss; /* L3 miss notifications */
>
> unsigned long age_interval;
> struct timer_list age_timer;
Perhaps we've accumulated enough boolean states that a "u32 flags" are
in order?
> + for (i=0; i<ETH_ALEN; ++i)
> + send_eth |= !!fdb->eth_addr[i];
Please use is_zero_ether_addr().
Otherwise these changes look fine to me, thanks.
^ permalink raw reply
* Re: [PATCH] bonding: rlb mode of bond should not alter ARP originating via bridge
From: David Miller @ 2012-11-19 23:49 UTC (permalink / raw)
To: zheng.x.li; +Cc: netdev, fubar, andy, linux-kernel, joe.jin
In-Reply-To: <1352972861-17577-1-git-send-email-zheng.x.li@oracle.com>
From: Zheng Li <zheng.x.li@oracle.com>
Date: Thu, 15 Nov 2012 17:47:41 +0800
> ARP traffic passing through a bridge and out via the bond (when the bond is a
> port of the bridge) should not have its source MAC address adjusted by the
> receive load balance code in rlb_arp_xmit.
>
> Signed-off-by: Zheng Li <zheng.x.li@oracle.com>
Can I please get a review from some bonding experts on this one?
Thanks!
^ permalink raw reply
* Re: [PATCH] pkt_sched: QFQ Plus: fair-queueing service at DRR cost
From: David Miller @ 2012-11-19 23:48 UTC (permalink / raw)
To: paolo.valente; +Cc: jhs, shemminger, linux-kernel, netdev, rizzo, fchecconi
In-Reply-To: <20121112164833.GA12970@paolo-ThinkPad-W520>
From: Paolo Valente <paolo.valente@unimore.it>
Date: Mon, 12 Nov 2012 17:48:33 +0100
> [This patch received positive feedback from Stephen Hemminger ("put in
> net-next"), but no further feedback or decision. So I am (re)sending
> an updated version of it. The only differences with respect to the
> previous version are the support for TSO/GSO (taken from QFQ), and a
> hopefully improved description.]
Can you rearrange the logic so that the compiler doesn't emit this
warning?
In file included from net/sched/sch_qfq.c:18:0:
net/sched/sch_qfq.c: In function ‘qfq_dequeue’:
include/net/sch_generic.h:480:15: warning: ‘skb’ may be used uninitialized in this function [-Wmaybe-uninitialized]
net/sched/sch_qfq.c:1007:18: note: ‘skb’ was declared here
You and I both know that SKB will be initialized at this point, but
the compiler can't see it clearly enough.
Thanks.
^ permalink raw reply
* Re: [PATCH] vxlan: Fix error that was resulting in VXLAN MTU size being 10 bytes too large
From: Joseph Glanville @ 2012-11-19 23:37 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, alexander.h.duyck, netdev
In-Reply-To: <20121119080351.477525b3@nehalam.linuxnetplumber.net>
On 20 November 2012 03:03, Stephen Hemminger <shemminger@vyatta.com> wrote:
> On Mon, 19 Nov 2012 22:33:50 +1100
> Joseph Glanville <joseph.glanville@orionvm.com.au> wrote:
>
>> On 14 November 2012 08:33, Stephen Hemminger <shemminger@vyatta.com> wrote:
>> > On Tue, 13 Nov 2012 14:37:19 -0500 (EST)
>> > David Miller <davem@davemloft.net> wrote:
>> >
>> >> From: Alexander Duyck <alexander.h.duyck@intel.com>
>> >> Date: Fri, 09 Nov 2012 15:35:24 -0800
>> >>
>> >> > This change fixes an issue I found where VXLAN frames were fragmented when
>> >> > they were up to the VXLAN MTU size. I root caused the issue to the fact that
>> >> > the headroom was 4 + 20 + 8 + 8. This math doesn't appear to be correct
>> >> > because we are not inserting a VLAN header, but instead a 2nd Ethernet header.
>> >> > As such the math for the overhead should be 20 + 8 + 8 + 14 to account for the
>> >> > extra headers that are inserted for VXLAN.
>> >> >
>> >> > Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
>> >>
>> >> Applied, thanks for the detailed commit message.
>> >
>> > Probably need smarter code there to look at header length requirement
>> > of underlying device as well, maybe someone will be perverse and runn
>> > vxlan over a tunnel or IPoIB.
>>
>> Forgive my ignorance but why would running VXLAN on IPoIB require
>> special header handling? (and would it work or behave strangely?)
>>
>> I was planning on giving this a go when 3.7 is released but I might do
>> that sooner if problems are anticipated.
>>
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe netdev" in
>> > the body of a message to majordomo@vger.kernel.org
>> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>> Joseph.
>>
>
> Some lower layers require bigger (or smaller headers). As it was, vxlan
> was only allocating skb with a fixed amount of headroom. This would lead to
> lower layers having to copy the skb.
>
> My suggestion has already been addressed by a later patch.
Thankyou for the clarification, I found the patch about the lower_dev
hard_header_len!
--
CTO | Orion Virtualisation Solutions | www.orionvm.com.au
Phone: 1300 56 99 52 | Mobile: 0428 754 846
^ permalink raw reply
* Re: [PATCH] net, batman: don't crash on zero length strings in routing_algo
From: Antonio Quartulli @ 2012-11-19 22:07 UTC (permalink / raw)
To: Sasha Levin; +Cc: lindner_marek, siwu, davem, b.a.t.m.a.n, netdev, linux-kernel
In-Reply-To: <1353355695-23252-1-git-send-email-sasha.levin@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 1246 bytes --]
On Mon, Nov 19, 2012 at 03:08:15PM -0500, Sasha Levin wrote:
> The code that works with routing_algo assumes that the string passed is non
> empty, this assumption is wrong:
>
> sh-4.2# echo -ne '\0' > /sys/module/batman_adv/parameters/routing_algo
> [ 34.531340] BUG: unable to handle kernel paging request at ffff880015142fff
[CUT]
> [ 34.550025] ---[ end trace 6c53b662c574774b ]---
>
> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Hello Sasha,
thank you very much for fixing this bug!
However, any patch sent against the B.A.T.M.A.N.-Advanced code should have a
subject starting with "batman-adv:".
Other than that I think this kind of patch
doesn't really need to report the entire kernel message: a more exhaustive
commit message is enough (e.g. use function names). I personally needed to read
the patch before understanding what you were trying to explain in the message.
Then, we usually pick this patches up in our repo and then we send them as batch
to the networking tree via pull request, therefore you can also skip the netdev
ml when sending the fixes.
Thank you very much!
Regards,
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: unable to handle paging request, arm, at aio/tcp code, only 3.6
From: Eric Dumazet @ 2012-11-19 21:36 UTC (permalink / raw)
To: Lluís Batlle i Rossell; +Cc: netdev
In-Reply-To: <20121119211020.GL2068@vicerveza.homeunix.net>
On Mon, 2012-11-19 at 22:10 +0100, Lluís Batlle i Rossell wrote:
> If it can help, I keep the vmlinux kernel with debug info.
Well, it would be better if you could try the patch ;)
Anyway bug seems pretty obvious to me.
Thanks
^ permalink raw reply
* Re: unable to handle paging request, arm, at aio/tcp code, only 3.6
From: Eric Dumazet @ 2012-11-19 21:34 UTC (permalink / raw)
To: Lluís Batlle i Rossell, David Miller; +Cc: netdev
In-Reply-To: <1353354095.10798.76.camel@edumazet-glaptop>
From: Eric Dumazet <edumazet@google.com>
> Thanks for the report.
>
> I believe this is a regression of commit
> 35ad9b9cf7d8a2e6259a0d24022e910adb6f3489
> (ipv6: Add helper inet6_csk_update_pmtu().)
>
> I'll prepare a patch to fix this.
Please try the following fix.
Thanks !
[PATCH] ipv6: fix inet6_csk_update_pmtu() return value
In case of error, inet6_csk_update_pmtu() should consistently
return NULL.
Bug added in commit 35ad9b9cf7d8a
(ipv6: Add helper inet6_csk_update_pmtu().)
Reported-by: Lluís Batlle i Rossell <viric@viric.name>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv6/inet6_connection_sock.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/inet6_connection_sock.c b/net/ipv6/inet6_connection_sock.c
index c4f9341..3064785 100644
--- a/net/ipv6/inet6_connection_sock.c
+++ b/net/ipv6/inet6_connection_sock.c
@@ -252,6 +252,7 @@ struct dst_entry *inet6_csk_update_pmtu(struct sock *sk, u32 mtu)
return NULL;
dst->ops->update_pmtu(dst, sk, NULL, mtu);
- return inet6_csk_route_socket(sk, &fl6);
+ dst = inet6_csk_route_socket(sk, &fl6);
+ return IS_ERR(dst) ? NULL : dst;
}
EXPORT_SYMBOL_GPL(inet6_csk_update_pmtu);
^ permalink raw reply related
* Re: [PATCH 080/493] fddi: remove use of __devexit_p
From: Bill Pemberton @ 2012-11-19 21:30 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Greg KH, Maciej W. Rozycki, netdev
In-Reply-To: <alpine.LNX.2.01.1211192222160.12904@nerf07.vanv.qr>
Jan Engelhardt writes:
>
> On Monday 2012-11-19 20:29, Greg KH wrote:
> >
> >CONFIG_HOTPLUG is always enabled now, so that's not an option anymore.
> >And again, a user can "hot unbind" a driver from a device from
> >userspace, no matter if the bus physically supports it or not.
>
> Which mailing list was this originally posted on? (I only have
> subscribed to netdev, and google has not indexed 000/493--001/493 yet.)
>
The announcement for this patchset was sent to lkml on Friday. I
originally didn't have the patches themselves Cc'd to the various
subsystems, so no one other than Greg got the patches themselves on
Friday. I resent them with Cc's today.
--
Bill
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox