* 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
* Re: [PATCH 080/493] fddi: remove use of __devexit_p
From: Jan Engelhardt @ 2012-11-19 21:22 UTC (permalink / raw)
To: Greg KH; +Cc: Maciej W. Rozycki, Bill Pemberton, netdev
In-Reply-To: <20121119192949.GA16976@kroah.com>
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.)
^ permalink raw reply
* Re: unable to handle paging request, arm, at aio/tcp code, only 3.6
From: Lluís Batlle i Rossell @ 2012-11-19 21:10 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1353354095.10798.76.camel@edumazet-glaptop>
On Mon, Nov 19, 2012 at 11:41:35AM -0800, Eric Dumazet wrote:
> On Mon, 2012-11-19 at 19:32 +0100, Lluís Batlle i Rossell wrote:
> > (crosspost from lkml)
> > Hello,
> >
> > in a Sheevaplug (armv5tel), if I run the kernels 3.6.3 or 3.6.6, they crash in
> > less than 48h. Kernel 3.5.3 runs perfect, as most previous kernels I've been
> > running until 2.6.36.
> >
> > Can anyone suggest what change can be the cause of that?
> > Or how could I debug this to fix it?
> >
> > Here is the panic:
> > unable to handle kernel paging request at virtual address ffffffab
> > pgd = d864c000
> > [ffffffab] *pgd=1fffe831, *pte=00000000, *ppte=00000000
> > Internal error: Oops: 1 [#1] PREEMPT ARM
> > Modules linked in: netconsole cbc sg cryptodev(O) fuse ipv6 ums_cypress dm_mod btrfs ext4 jb
> > d2 reiserfs [last unloaded: netconsole]
> > CPU: 0 Tainted: G O (3.6.6 #1)
> > PC is at tcp_v6_mtu_reduced+0x40/0x80 [ipv6]
> > LR is at ip6_dst_lookup_tail+0xd8/0xfc [ipv6]
> > pc : [<bf2b02f8>] lr : [<bf28a67c>] psr: a0000013
> > ...
> 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.
If it can help, I keep the vmlinux kernel with debug info.
Regards,
Lluís.
^ permalink raw reply
* Re: [PATCH 04/10] batman-adv: export compatibility version via debugfs
From: Antonio Quartulli @ 2012-11-19 21:09 UTC (permalink / raw)
To: David Miller
Cc: bhutchings-s/n/eUQHGBpZroRs9YW3xA, netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r,
lindner_marek-LWAfsSFWpa4
In-Reply-To: <20121119.144745.1093556126398582629.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2378 bytes --]
On Mon, Nov 19, 2012 at 02:47:45PM -0500, David Miller wrote:
> From: Sven Eckelmann <sven-KaDOiPu9UxWEi8DpZVb4nw@public.gmane.org>
> Date: Mon, 19 Nov 2012 20:29:07 +0100
>
> > On Monday 19 November 2012 18:52:30 Ben Hutchings wrote:
> >> On Mon, 2012-11-19 at 09:24 +0100, Antonio Quartulli wrote:
> >> > Different versions of the batman-adv module may use the same compatibility
> >> > version, but this is not understandable at runtime (the only way is to
> >> > parse the kernel log and fetch the batman-adv advertisement message on
> >> > loading). The user may want to know whether two nodes using different
> >> > versions can communicate or not. For this purpose the module has to
> >> > export this value through debugfs.
> >> [...]
> >>
> >> I do hope that you're not planning to use unstable debugfs interfaces
> >> indefinitely.
> >
> > Why are you refering to the adding of an file as "incompatible" debugfs
> > interface? I would call it additional information. And the rest of the commit
> > message is talking about *possible* protocol incompatibilies of the network
> > protocol (which caused this uncontrolled erruption of anger in a network
> > maintainer).
>
> Debugfs files aren't where you store information that userspace actually
> uses in normal situations.
>
> It's for developer debug, to expose internals that otherwise have no
> business being part of the user visible interfaces.
Ok, you are right. As you already stated, I do see two problems here:
1) debugfs not used properly (this information is not really for "devs")
2) this compatibility version export is like the claim: "compatibility is broken
everyday". But actually this is not what we really wanted.
This patch simply came from a feature request raised by a user of ours. As Sven
pointed out, we have seen it just as "more information available for network
debugging" and we (in particular me) didn't think about the fact that having
such a patch was against the "stabilisation" process that we are following (we
discussed about this process during the last pull request, so you already know
that we are already going towards this direction).
David, Ben, if you agree I would remove this patch and repost the pull request.
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: [PATCH 196/493] net/wireless: remove use of __devinit
From: Arend van Spriel @ 2012-11-19 20:57 UTC (permalink / raw)
To: Bill Pemberton
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, John W. Linville,
Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez, Simon Kelley,
Stefano Brivio, Stanislav Yakovlev, Dan Williams,
Christian Lamparter, Herton Ronaldo Krzesinski, Hin-Tak Leung,
Larry Finger, Chaoming Li, Luciano Coelho,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, ath5k-devel-xDcbHBWguxEUs3QNXV6qNA,
b43-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
brcm80211-dev-list-dY08KVG/lbpWk0Htik3J/w,
libertas-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1353349642-3677-196-git-send-email-wfp5p-4Ng6DfrEGID2fBVCVOL8/A@public.gmane.org>
On 11/19/2012 07:22 PM, Bill Pemberton wrote:
> CONFIG_HOTPLUG is going away as an option so __devinit is no longer
> needed.
Acked-by: Arend van Spriel <arend-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Bill Pemberton <wfp5p-4Ng6DfrEGID2fBVCVOL8/A@public.gmane.org>
> Cc: brcm80211-dev-list-dY08KVG/lbpWk0Htik3J/w@public.gmane.org
> ---
> drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c | 2 +-
For brcm80211 driver change.
Gr. AvS
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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