* Re: [PATCH net v2 1/2] macvlan: introduce macvlan_dev_real_dev() helper function
From: David Miller @ 2013-11-14 22:03 UTC (permalink / raw)
To: mkubecek; +Cc: vyasevich, netdev, kaber, john.r.fastabend
In-Reply-To: <20131114155756.GA4161@lion.mk-sys.cz>
From: Michal Kubecek <mkubecek@suse.cz>
Date: Thu, 14 Nov 2013 16:57:57 +0100
> On Thu, Nov 14, 2013 at 10:03:19AM -0500, Vlad Yasevich wrote:
>> On 11/14/2013 09:00 AM, Michal Kubecek wrote:
>> >+#if IS_ENABLED(CONFIG_MACVLAN)
>> >+static inline struct net_device *
>> >+macvlan_dev_real_dev(const struct net_device *dev)
>> >+{
>> >+ struct macvlan_dev *macvlan = netdev_priv(dev);
>> >+
>> >+ return macvlan->lowerdev;
>> >+}
>> >+#else
>> >+static inline struct net_device *
>> >+macvlan_dev_real_dev(const struct net_device *dev)
>> >+{
>> >+ return NULL;
>> >+}
>> >+#endif
>> >+
>>
>> You may want to do the same here as was done for
>> vlan_dev_real_dev(). This function is not intended to be called
>> blindly and should always
>> be called after netif_is_macvlan().
>
> I'm not sure. It makes sense from the developer point of view: if we
> find an inconsistency which must be caused by a bug in kernel code, do
> panic so that the bug is found and fixed as soon as possible. However,
> I remember a discussion where the point was that BUG() and BUG_ON()
> should only be used if there is no way to recover. From this point of
> view, WARN or WARN_ONCE might be better choice - but I'm not strictly
> opposed to BUG().
At least for the time being use BUG(), to be consistent with the same
way how VLAN handles this situation.
Thanks.
^ permalink raw reply
* Re: [PATCH net] ip6tnl: fix use after free of fb_tnl_dev
From: David Miller @ 2013-11-14 22:05 UTC (permalink / raw)
To: nicolas.dichtel
Cc: rostedt, linux-kernel, stable, gregkh, williams, linux-rt-users,
lclaudio, netdev, willemb
In-Reply-To: <1384440423-4275-1-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Thu, 14 Nov 2013 15:47:03 +0100
> Bug has been introduced by commit bb8140947a24 ("ip6tnl: allow to use rtnl ops
> on fb tunnel").
>
> When ip6_tunnel.ko is unloaded, FB device is delete by rtnl_link_unregister()
> and then we try to use the pointer in ip6_tnl_destroy_tunnels().
>
> Let's add an handler for dellink, which will never remove the FB tunnel. With
> this patch it will no more be possible to remove it via 'ip link del ip6tnl0',
> but it's safer.
>
> The same fix was already proposed by Willem de Bruijn <willemb@google.com> for
> sit interfaces.
>
> CC: Willem de Bruijn <willemb@google.com>
> Reported-by: Steven Rostedt <rostedt@goodmis.org>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Applied and queued up for -stable, thanks for being so proactive about this
Nicolas.
^ permalink raw reply
* Re: [PATCH net-next 0/6] 6lowpan: udp compression/uncompression fix
From: David Miller @ 2013-11-14 22:06 UTC (permalink / raw)
To: eric.dumazet
Cc: alex.aring, alex.bluesman.smirnov, linux-zigbee-devel, werner,
jukka.rissanen, dbaryshkov, netdev
In-Reply-To: <1384445983.28716.1.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 14 Nov 2013 08:19:43 -0800
> On Thu, 2013-11-14 at 16:48 +0100, Alexander Aring wrote:
>> The current 6LoWPAN udp compression/uncompression is completely broken.
>> This patch series fix a lot of udp compression/uncompression issues and
>> add support parsing with lowpan_fetch_skb function.
>
> If its broken, why targeting net-next tree (which is closed BTW ATM) ?
In any event, if you do want it to go into net-next, please resubmit
this series when the net-next tree opens back up after the merge
window.
Thanks!
^ permalink raw reply
* Re: [PATCH 0/9] genetlink: reduce ops size and complexity (v2)
From: David Miller @ 2013-11-14 22:12 UTC (permalink / raw)
To: johannes
Cc: netdev, linux-wimax, bsingharora, netfilter-devel,
alex.bluesman.smirnov, dbaryshkov
In-Reply-To: <1384445687-30948-1-git-send-email-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Thu, 14 Nov 2013 17:14:38 +0100
> As before - reduce the complexity and data/code size of genetlink ops
> by making them an array rather than a linked list. Most users already
> use an array thanks to genl_register_family_with_ops(), so convert the
> remaining ones allowing us to get rid of the list head in each op.
>
> Also make them const, this just makes sense at that point and the security
> people like making function pointers const as well :-)
I have to say, this is an absolutely fantastic space usage and
complexity improvement.
Applied, thanks a lot.
^ permalink raw reply
* Re: [PATCH] alx: Reset phy speed after resume
From: David Miller @ 2013-11-14 22:15 UTC (permalink / raw)
To: linux
Cc: jcliburn, chris.snook, johannes, wangyijing, maarten.lankhorst,
netdev, linux-kernel
In-Reply-To: <1384445773.29057.5.camel@localhost.tld>
From: hahnjo <linux@hahnjo.de>
Date: Thu, 14 Nov 2013 17:16:13 +0100
> From 27744b24f9291782c1342dbd6cac511e68da907c Mon Sep 17 00:00:00 2001
> From: hahnjo <hahnjo@hahnjo.de>
> Date: Tue, 12 Nov 2013 18:19:24 +0100
> Subject: [PATCH] alx: Reset phy speed after resume
>
> This fixes bug 62491 (https://bugzilla.kernel.org/show_bug.cgi?id=62491).
> After resuming some users got the following error flooding the kernel log:
> alx 0000:02:00.0: invalid PHY speed/duplex: 0xffff
>
> Signed-off-by: Jonas Hahnfeld <linux@hahnjo.de>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] pkt_sched: fq: change classification of control packets
From: David Miller @ 2013-11-14 22:16 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, maze, willemb, ycheng, stephen
In-Reply-To: <1384447843.28716.15.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 14 Nov 2013 08:50:43 -0800
> From: Maciej Żenczykowski <maze@google.com>
>
> Initial sch_fq implementation copied code from pfifo_fast to classify
> a packet as a high prio packet.
>
> This clashes with setups using PRIO with say 7 bands, as one of the
> band could be incorrectly (mis)classified by FQ.
>
> Packets would be queued in the 'internal' queue, and no pacing ever
> happen for this special queue.
>
> Fixes: afe4fd062416 ("pkt_sched: fq: Fair Queue packet scheduler")
> Signed-off-by: Maciej Żenczykowski <maze@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied and queued up for -stable, thanks Eric.
^ permalink raw reply
* Re: [PATCH net] ip6tnl: fix use after free of fb_tnl_dev
From: Steven Rostedt @ 2013-11-14 22:18 UTC (permalink / raw)
To: David Miller
Cc: nicolas.dichtel, linux-kernel, stable, gregkh, williams,
linux-rt-users, lclaudio, netdev, willemb
In-Reply-To: <20131114.170529.1627250972818871118.davem@davemloft.net>
On Thu, 14 Nov 2013 17:05:29 -0500 (EST)
David Miller <davem@davemloft.net> wrote:
> Applied and queued up for -stable, thanks for being so proactive about this
> Nicolas.
I should also note that I added this back to 3.10.18 and the bug goes
away.
If it's not too late:
Tested-by: Steven Rostedt <rostedt@goodmis.org>
-- Steve
^ permalink raw reply
* Re: [PATCH] connector: improved unaligned access error fix
From: David Miller @ 2013-11-14 22:20 UTC (permalink / raw)
To: cmetcalf; +Cc: zbr, erikj, akpm, matthltc, zaitcev, netdev, linux-kernel
In-Reply-To: <201311141743.rAEHhuEV004998@farm-0012.internal.tilera.com>
From: Chris Metcalf <cmetcalf@tilera.com>
Date: Thu, 14 Nov 2013 12:09:21 -0500
> In af3e095a1fb4, Erik Jacobsen fixed one type of unaligned access
> bug for ia64 by converting a 64-bit write to use put_unaligned().
> Unfortunately, since gcc will convert a short memset() to a series
> of appropriately-aligned stores, the problem is now visible again
> on tilegx, where the memset that zeros out proc_event is converted
> to three 64-bit stores, causing an unaligned access panic.
>
> A better fix for the original problem is to ensure that proc_event
> is aligned to 8 bytes here. We can do that relatively easily by
> arranging to start the struct cn_msg aligned to 8 bytes and then
> offset by 4 bytes. Doing so means that the immediately following
> proc_event structure is then correctly aligned to 8 bytes.
>
> The result is that the memset() stores are now aligned, and as an
> added benefit, we can remove the put_unaligned() calls in the code.
>
> Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
This looks fine to me, applied and queued up for -stable, thanks
Chris.
^ permalink raw reply
* Re: [PATCH] pkt_sched: fq: fix pacing for small frames
From: David Miller @ 2013-11-14 22:22 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, maze, willemb, ycheng, ncardwell
In-Reply-To: <1384455496.28716.27.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 14 Nov 2013 10:58:16 -0800
> @@ -655,9 +664,6 @@ static int fq_change(struct Qdisc *sch, struct nlattr *opt)
> if (tb[TCA_FQ_INITIAL_QUANTUM])
> q->initial_quantum = nla_get_u32(tb[TCA_FQ_INITIAL_QUANTUM]);
>
> - if (tb[TCA_FQ_FLOW_DEFAULT_RATE])
> - q->flow_default_rate = nla_get_u32(tb[TCA_FQ_FLOW_DEFAULT_RATE]);
> -
> if (tb[TCA_FQ_FLOW_MAX_RATE])
> q->flow_max_rate = nla_get_u32(tb[TCA_FQ_FLOW_MAX_RATE]);
>
I think it's at best confusing to suddenly stop ignoring a configuration
parameter the user is giving us.
Can you at least ratelimit warn if the parameter is specified so the user
has some chance to figure out what is happening?
Thanks.
^ permalink raw reply
* Re: [PATCH] virtio-net: mergeable buffer size should include virtio-net header
From: David Miller @ 2013-11-14 22:23 UTC (permalink / raw)
To: eric.dumazet; +Cc: mwdalton, mst, netdev, dborkman, virtualization, edumazet
In-Reply-To: <1384455552.28716.28.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 14 Nov 2013 10:59:12 -0800
> On Thu, 2013-11-14 at 10:41 -0800, Michael Dalton wrote:
>> Commit 2613af0ed18a ("virtio_net: migrate mergeable rx buffers to page
>> frag allocators") changed the mergeable receive buffer size from PAGE_SIZE
>> to MTU-size. However, the merge buffer size does not take into account the
>> size of the virtio-net header. Consequently, packets that are MTU-size
>> will take two buffers intead of one (to store the virtio-net header),
>> substantially decreasing the throughput of MTU-size traffic due to TCP
>> window / SKB truesize effects.
>>
>> This commit changes the mergeable buffer size to include the virtio-net
>> header. The buffer size is cacheline-aligned because skb_page_frag_refill
>> will not automatically align the requested size.
>>
>> Benchmarks taken from an average of 5 netperf 30-second TCP_STREAM runs
>> between two QEMU VMs on a single physical machine. Each VM has two VCPUs and
>> vhost enabled. All VMs and vhost threads run in a single 4 CPU cgroup
>> cpuset, using cgroups to ensure that other processes in the system will not
>> be scheduled on the benchmark CPUs. Transmit offloads and mergeable receive
>> buffers are enabled, but guest_tso4 / guest_csum are explicitly disabled to
>> force MTU-sized packets on the receiver.
>>
>> next-net trunk before 2613af0ed18a (PAGE_SIZE buf): 3861.08Gb/s
>> net-next trunk (MTU 1500- packet uses two buf due to size bug): 4076.62Gb/s
>> net-next trunk (MTU 1480- packet fits in one buf): 6301.34Gb/s
>> net-next trunk w/ size fix (MTU 1500 - packet fits in one buf): 6445.44Gb/s
>>
>> Suggested-by: Eric Northup <digitaleric@google.com>
>> Signed-off-by: Michael Dalton <mwdalton@google.com>
>> ---
>
> Acked-by: Eric Dumazet <edumazet@google.com>
Applied, thanks.
^ permalink raw reply
* Re: pull request: wireless 2013-11-14
From: David Miller @ 2013-11-14 22:24 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20131114191119.GB17693-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Thu, 14 Nov 2013 14:11:20 -0500
> Please pull this batch of fixes intended for the 3.13 stream!
Pulled, thanks John.
--
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
* Re: [PATCH] net/hsr: Fix possible leak in 'hsr_get_node_status()'
From: David Miller @ 2013-11-14 22:26 UTC (permalink / raw)
To: geyslan; +Cc: arvid.brodin, netdev, linux-kernel
In-Reply-To: <1384456378-29970-1-git-send-email-geyslan@gmail.com>
From: "Geyslan G. Bem" <geyslan@gmail.com>
Date: Thu, 14 Nov 2013 16:12:54 -0300
> If 'hsr_get_node_data()' returns error, going directly to 'fail' label
> doesn't free the memory pointed by 'skb_out'.
>
> Signed-off-by: Geyslan G. Bem <geyslan@gmail.com>
Looks good, applied, thanks!
^ permalink raw reply
* Re: [PATCH] ipv4: fix possible seqlock deadlock
From: David Miller @ 2013-11-14 22:32 UTC (permalink / raw)
To: eric.dumazet; +Cc: davej, netdev
In-Reply-To: <1384465074.28716.41.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 14 Nov 2013 13:37:54 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> ip4_datagram_connect() being called from process context,
> it should use IP_INC_STATS() instead of IP_INC_STATS_BH()
> otherwise we can deadlock on 32bit arches, or get corruptions of
> SNMP counters.
>
> Fixes: 584bdf8cbdf6 ("[IPV4]: Fix "ipOutNoRoutes" counter error for TCP and UDP")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Dave Jones <davej@redhat.com>
Applied and queued up for -stable, thanks!
^ permalink raw reply
* Re: [PATCH] pkt_sched: fq: fix pacing for small frames
From: Eric Dumazet @ 2013-11-14 22:51 UTC (permalink / raw)
To: David Miller; +Cc: netdev, maze, willemb, ycheng, ncardwell
In-Reply-To: <20131114.172220.940454781221829007.davem@davemloft.net>
On Thu, 2013-11-14 at 17:22 -0500, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu, 14 Nov 2013 10:58:16 -0800
>
> > @@ -655,9 +664,6 @@ static int fq_change(struct Qdisc *sch, struct nlattr *opt)
> > if (tb[TCA_FQ_INITIAL_QUANTUM])
> > q->initial_quantum = nla_get_u32(tb[TCA_FQ_INITIAL_QUANTUM]);
> >
> > - if (tb[TCA_FQ_FLOW_DEFAULT_RATE])
> > - q->flow_default_rate = nla_get_u32(tb[TCA_FQ_FLOW_DEFAULT_RATE]);
> > -
> > if (tb[TCA_FQ_FLOW_MAX_RATE])
> > q->flow_max_rate = nla_get_u32(tb[TCA_FQ_FLOW_MAX_RATE]);
> >
>
> I think it's at best confusing to suddenly stop ignoring a configuration
> parameter the user is giving us.
>
> Can you at least ratelimit warn if the parameter is specified so the user
> has some chance to figure out what is happening?
Oh this parameter was removed in 7eec4174ff29cd
("pkt_sched: fq: fix non TCP flows pacing"), I probably should
have added this warning at that time...
OK, we can warn the user, will send a v2.
^ permalink raw reply
* Re: [PATCH 2/2] net: phy: at803x: soft-reset PHY when link goes down
From: Sergei Shtylyov @ 2013-11-15 0:03 UTC (permalink / raw)
To: Daniel Mack, netdev; +Cc: davem, marek.belisko, ujhelyi.m
In-Reply-To: <1384376870-7810-2-git-send-email-zonque@gmail.com>
Hello.
On 11/14/2013 12:07 AM, Daniel Mack wrote:
> When the link goes down and up again quickly and multiple times in a
> row, the AT803x PHY gets stuck and won't recover unless it is soft-reset
> via the BMCR register.
> Unfortunately, there is no way to detect this state, as all registers
> contain perfectly sane values in such cases. Hence, the only option is
> to always soft-reset the PHY when the link goes down.
> Reset logic is based on a patch from Marek Belisko.
> Signed-off-by: Daniel Mack <zonque@gmail.com>
> Reported-and-tested-by: Marek Belisko <marek.belisko@gmail.com>
> ---
> drivers/net/phy/at803x.c | 52 ++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 52 insertions(+)
> diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
> index bc71947..303c5ae 100644
> --- a/drivers/net/phy/at803x.c
> +++ b/drivers/net/phy/at803x.c
> @@ -32,10 +32,56 @@
> #define AT803X_DEBUG_SYSTEM_MODE_CTRL 0x05
> #define AT803X_DEBUG_RGMII_TX_CLK_DLY BIT(8)
>
> +#define AT803X_BMCR_SOFTRESET BIT(15)
> +
This is the standard bit (BMCR_RESET) #define'd in the same file as MII_BMCR.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 1/4] wl1251: split wl251 platform data to a separate structure
From: Sebastian Reichel @ 2013-11-14 23:03 UTC (permalink / raw)
To: Tony Lindgren
Cc: Luciano Coelho, Rob Herring, Pawel Moll, Mark Rutland,
Stephen Warren, Ian Campbell, Rob Landley, Russell King,
John W. Linville, Felipe Balbi, Sachin Kamat, Greg Kroah-Hartman,
Bill Pemberton, devicetree, linux-doc, linux-kernel, linux-omap,
linux-arm-kernel, linux-wireless, netdev, Luciano Coelho
In-Reply-To: <20131114185132.GQ10317@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 615 bytes --]
On Thu, Nov 14, 2013 at 10:51:33AM -0800, Tony Lindgren wrote:
> [...]
>
> If this is not going into v3.13, these will cause conflicts
> with the mach-omap2/board-*.c files for v3.14.
>
> So it might be best to do a minimal header patch first that
> can be merged in by both linux-omap and wireless trees.
I guess this patch is pretty minimal. It also seems to be acked by
the involved Maintainers, so maybe just merge Patch 1 without the
other patches?
This does not solve the problem with the struct modification from
the second patch, but I guess it's the more intrusive patch.
-- Sebastian
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4] wl1251: split wl251 platform data to a separate structure
From: Tony Lindgren @ 2013-11-14 23:22 UTC (permalink / raw)
To: Luciano Coelho, Rob Herring, Pawel Moll, Mark Rutland,
Stephen Warren, Ian Campbell, Rob Landley, Russell King,
John W. Linville, Felipe Balbi, Sachin Kamat, Greg Kroah-Hartman,
Bill Pemberton, devicetree, linux-doc, linux-kernel, linux-omap,
linux-arm-kernel, linux-wireless, netdev, Luciano Coelho
In-Reply-To: <20131114230330.GB6383@earth.universe>
* Sebastian Reichel <sre@debian.org> [131114 15:04]:
> On Thu, Nov 14, 2013 at 10:51:33AM -0800, Tony Lindgren wrote:
> > [...]
> >
> > If this is not going into v3.13, these will cause conflicts
> > with the mach-omap2/board-*.c files for v3.14.
> >
> > So it might be best to do a minimal header patch first that
> > can be merged in by both linux-omap and wireless trees.
>
> I guess this patch is pretty minimal. It also seems to be acked by
> the involved Maintainers, so maybe just merge Patch 1 without the
> other patches?
>
> This does not solve the problem with the struct modification from
> the second patch, but I guess it's the more intrusive patch.
Once at least the first two patches are ready, how about I queue
them after -rc1 and set up an immutable branch that can be merged
in by linux-omap tree and the wireless tree?
Regards,
Tony
^ permalink raw reply
* Re: Bug - regression - Via velocity interface coming up freezes kernel
From: Francois Romieu @ 2013-11-15 0:01 UTC (permalink / raw)
To: Michele Baldessari; +Cc: Dirk Kraft, netdev, Julia Lawall
In-Reply-To: <20131114072451.GA2313@electric-eye.fr.zoreil.com>
Francois Romieu <romieu@fr.zoreil.com> :
> Michele Baldessari <michele@acksyn.org> :
> [...]
> > any chance you can submit this officially ?
>
> Yes.
>
> > Or does this patch need some more work ?
>
> I'll write some narrative for the commit message.
I would actually rather send the patch below.
The previous patch isn't safe against mtu changes. Please give the patch
below some testing. Test case: receive lots of packets while changing MTU.
Loop. The former patch may crash. The later shouldn't.
diff --git a/drivers/net/ethernet/via/via-velocity.c b/drivers/net/ethernet/via/via-velocity.c
index d022bf9..ad61d26 100644
--- a/drivers/net/ethernet/via/via-velocity.c
+++ b/drivers/net/ethernet/via/via-velocity.c
@@ -2172,16 +2172,13 @@ static int velocity_poll(struct napi_struct *napi, int budget)
unsigned int rx_done;
unsigned long flags;
- spin_lock_irqsave(&vptr->lock, flags);
/*
* Do rx and tx twice for performance (taken from the VIA
* out-of-tree driver).
*/
- rx_done = velocity_rx_srv(vptr, budget / 2);
- velocity_tx_srv(vptr);
- rx_done += velocity_rx_srv(vptr, budget - rx_done);
+ rx_done = velocity_rx_srv(vptr, budget);
+ spin_lock_irqsave(&vptr->lock, flags);
velocity_tx_srv(vptr);
-
/* If budget not fully consumed, exit the polling mode */
if (rx_done < budget) {
napi_complete(napi);
@@ -2342,6 +2339,8 @@ static int velocity_change_mtu(struct net_device *dev, int new_mtu)
if (ret < 0)
goto out_free_tmp_vptr_1;
+ napi_disable(&vptr->napi);
+
spin_lock_irqsave(&vptr->lock, flags);
netif_stop_queue(dev);
@@ -2362,6 +2361,8 @@ static int velocity_change_mtu(struct net_device *dev, int new_mtu)
velocity_give_many_rx_descs(vptr);
+ napi_enable(&vptr->napi);
+
mac_enable_int(vptr->mac_regs);
netif_start_queue(dev);
^ permalink raw reply related
* [PATCH] net: Do not include padding in TCP GRO checksum
From: Alexander Duyck @ 2013-11-15 1:18 UTC (permalink / raw)
To: davem; +Cc: netdev, edumazet, herbert
In some recent tests where I was generating invalid frames I found that
the checksum was being treated as valid for certain frames that computed
the checksum with padding included. On closer inspection I found the
issue was that GRO was using the skb->len instead of the length recorded in
the IP/IPv6 header to determine the number of bytes to checksum. As such
padded frames that actually had invalid checksums generated by adding the
padding to the checksum were being incorrectly tagged as valid.
This change corrects that by using the tot_len from IPv4 headers and the
payload_len from IPv6 headers to compute the total number of bytes to be
included in the checksum.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
I haven't had a chance to test this much yet and I am not that familiar
some of this GRO code so any review of this would be greatly appreciated.
I will try to get this tested by end-of-day tomorrow to verify it resolves
the issues I saw with invalid padded frames being marked as valid and
doesn't introduce any new issues.
net/ipv4/tcp_offload.c | 13 ++++++++-----
net/ipv6/tcpv6_offload.c | 11 +++++++----
2 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/net/ipv4/tcp_offload.c b/net/ipv4/tcp_offload.c
index a2b68a1..3dabb76 100644
--- a/net/ipv4/tcp_offload.c
+++ b/net/ipv4/tcp_offload.c
@@ -273,13 +273,16 @@ static int tcp_v4_gso_send_check(struct sk_buff *skb)
static struct sk_buff **tcp4_gro_receive(struct sk_buff **head, struct sk_buff *skb)
{
const struct iphdr *iph = skb_gro_network_header(skb);
+ int length = iph->tot_len;
__wsum wsum;
__sum16 sum;
+ /* adjust for any offsets */
+ length += skb_network_offset(skb) - skb_gro_offset(skb);
+
switch (skb->ip_summed) {
case CHECKSUM_COMPLETE:
- if (!tcp_v4_check(skb_gro_len(skb), iph->saddr, iph->daddr,
- skb->csum)) {
+ if (!tcp_v4_check(length, iph->saddr, iph->daddr, skb->csum)) {
skb->ip_summed = CHECKSUM_UNNECESSARY;
break;
}
@@ -288,11 +291,11 @@ flush:
return NULL;
case CHECKSUM_NONE:
- wsum = csum_tcpudp_nofold(iph->saddr, iph->daddr,
- skb_gro_len(skb), IPPROTO_TCP, 0);
+ wsum = csum_tcpudp_nofold(iph->saddr, iph->daddr, length,
+ IPPROTO_TCP, 0);
sum = csum_fold(skb_checksum(skb,
skb_gro_offset(skb),
- skb_gro_len(skb),
+ length,
wsum));
if (sum)
goto flush;
diff --git a/net/ipv6/tcpv6_offload.c b/net/ipv6/tcpv6_offload.c
index c1097c7..53fc71d 100644
--- a/net/ipv6/tcpv6_offload.c
+++ b/net/ipv6/tcpv6_offload.c
@@ -36,12 +36,16 @@ static struct sk_buff **tcp6_gro_receive(struct sk_buff **head,
struct sk_buff *skb)
{
const struct ipv6hdr *iph = skb_gro_network_header(skb);
+ int length = iph->payload_len;
__wsum wsum;
__sum16 sum;
+ /* adjust for any offset due to extension headers */
+ length += skb_transport_offset(skb) - skb_gro_offset(skb);
+
switch (skb->ip_summed) {
case CHECKSUM_COMPLETE:
- if (!tcp_v6_check(skb_gro_len(skb), &iph->saddr, &iph->daddr,
+ if (!tcp_v6_check(length, &iph->saddr, &iph->daddr,
skb->csum)) {
skb->ip_summed = CHECKSUM_UNNECESSARY;
break;
@@ -52,11 +56,10 @@ flush:
case CHECKSUM_NONE:
wsum = ~csum_unfold(csum_ipv6_magic(&iph->saddr, &iph->daddr,
- skb_gro_len(skb),
- IPPROTO_TCP, 0));
+ length, IPPROTO_TCP, 0));
sum = csum_fold(skb_checksum(skb,
skb_gro_offset(skb),
- skb_gro_len(skb),
+ length,
wsum));
if (sum)
goto flush;
^ permalink raw reply related
* Re: [PATCH] net: Do not include padding in TCP GRO checksum
From: Eric Dumazet @ 2013-11-15 1:26 UTC (permalink / raw)
To: Alexander Duyck; +Cc: davem, netdev, edumazet, herbert
In-Reply-To: <20131115011413.7090.9349.stgit@ahduyck-fpga.jf.intel.com>
On Thu, 2013-11-14 at 17:18 -0800, Alexander Duyck wrote:
> In some recent tests where I was generating invalid frames I found that
> the checksum was being treated as valid for certain frames that computed
> the checksum with padding included. On closer inspection I found the
> issue was that GRO was using the skb->len instead of the length recorded in
> the IP/IPv6 header to determine the number of bytes to checksum. As such
> padded frames that actually had invalid checksums generated by adding the
> padding to the checksum were being incorrectly tagged as valid.
>
> This change corrects that by using the tot_len from IPv4 headers and the
> payload_len from IPv6 headers to compute the total number of bytes to be
> included in the checksum.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> ---
>
> I haven't had a chance to test this much yet and I am not that familiar
> some of this GRO code so any review of this would be greatly appreciated.
> I will try to get this tested by end-of-day tomorrow to verify it resolves
> the issues I saw with invalid padded frames being marked as valid and
> doesn't introduce any new issues.
>
> net/ipv4/tcp_offload.c | 13 ++++++++-----
> net/ipv6/tcpv6_offload.c | 11 +++++++----
> 2 files changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/net/ipv4/tcp_offload.c b/net/ipv4/tcp_offload.c
> index a2b68a1..3dabb76 100644
> --- a/net/ipv4/tcp_offload.c
> +++ b/net/ipv4/tcp_offload.c
> @@ -273,13 +273,16 @@ static int tcp_v4_gso_send_check(struct sk_buff *skb)
> static struct sk_buff **tcp4_gro_receive(struct sk_buff **head, struct sk_buff *skb)
> {
> const struct iphdr *iph = skb_gro_network_header(skb);
> + int length = iph->tot_len;
Well, you probably should test this on x86 for example ;)
^ permalink raw reply
* [PATCH net v4] bonding: add ip checks when store ip target
From: Ding Tianhong @ 2013-11-15 1:58 UTC (permalink / raw)
To: Jay Vosburgh, Andy Gospodarek, David S. Miller,
Nikolay Aleksandrov, Veaceslav Falico, Netdev
>From 513509eecdee98d72668219aead9784d56dbad0f Mon Sep 17 00:00:00 2001
From: Wang Weidong <wangweidong1@huawei.com>
Date: Fri, 15 Nov 2013 10:34:30 -0500
Subject: [PATCH] bonding: add ip checks when store ip target
I met a Bug when I add ip target with the wrong ip address:
echo +500.500.500.500 > /sys/class/net/bond0/bonding/arp_ip_target
the wrong ip address will transfor to 245.245.245.244 and add
to the ip target success, it is uncorrect, so I add checks to avoid
adding wrong address.
The in4_pton() will set wrong ip address to 0.0.0.0, it will return by
the next check and will not add to ip target.
v2
According Veaceslav's opinion, simplify the code.
v3
According Veaceslav's opinion, add broadcast check and make a micro
definition to package it.
v4
Solve the problem of the format which David point out.
Suggested-by: Veaceslav Falico <vfalico@redhat.com>
Suggested-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
---
drivers/net/bonding/bond_sysfs.c | 19 ++++++-------------
drivers/net/bonding/bonding.h | 3 +++
2 files changed, 9 insertions(+), 13 deletions(-)
diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index 47749c9..21dd2a5 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -611,15 +611,14 @@ static ssize_t bonding_store_arp_targets(struct device *d,
return restart_syscall();
targets = bond->params.arp_targets;
- newtarget = in_aton(buf + 1);
+ if (!in4_pton(buf + 1, -1, (u8 *)&newtarget, -1, NULL) ||
+ IS_IP_TARGET_UNUSABLE_ADDRESS(newtarget)) {
+ pr_err("%s: invalid ARP target %pI4 specified for addition\n",
+ bond->dev->name, &newtarget);
+ goto out;
+ }
/* look for adds */
if (buf[0] == '+') {
- if ((newtarget == 0) || (newtarget == htonl(INADDR_BROADCAST))) {
- pr_err("%s: invalid ARP target %pI4 specified for addition\n",
- bond->dev->name, &newtarget);
- goto out;
- }
-
if (bond_get_targets_ip(targets, newtarget) != -1) { /* dup */
pr_err("%s: ARP target %pI4 is already present\n",
bond->dev->name, &newtarget);
@@ -642,12 +641,6 @@ static ssize_t bonding_store_arp_targets(struct device *d,
targets[ind] = newtarget;
write_unlock_bh(&bond->lock);
} else if (buf[0] == '-') {
- if ((newtarget == 0) || (newtarget == htonl(INADDR_BROADCAST))) {
- pr_err("%s: invalid ARP target %pI4 specified for removal\n",
- bond->dev->name, &newtarget);
- goto out;
- }
-
ind = bond_get_targets_ip(targets, newtarget);
if (ind == -1) {
pr_err("%s: unable to remove nonexistent ARP target %pI4.\n",
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index 046a605..253d5da 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -63,6 +63,9 @@
(((mode) == BOND_MODE_TLB) || \
((mode) == BOND_MODE_ALB))
+#define IS_IP_TARGET_UNUSABLE_ADDRESS(a) \
+ ((htonl(INADDR_BROADCAST) == a) || \
+ ipv4_is_zeronet(a))
/*
* Less bad way to call ioctl from within the kernel; this needs to be
* done some other way to get the call out of interrupt context.
--
1.7.12
^ permalink raw reply related
* Re: [PATCH] rds: Error on offset mismatch if not loopback
From: Honggang LI @ 2013-11-15 2:32 UTC (permalink / raw)
To: Venkat Venkatsubra, Josh Hunt; +Cc: David Miller, jjolly, LKML, netdev
In-Reply-To: <41aa904c-6707-4c74-ae72-96e401c68e13@default>
[-- Attachment #1: Type: text/plain, Size: 8977 bytes --]
On 11/14/2013 09:43 PM, Venkat Venkatsubra wrote:
>
> -----Original Message-----
> From: Honggang LI [mailto:honli@redhat.com]
> Sent: Wednesday, November 13, 2013 6:56 PM
> To: Josh Hunt; Venkat Venkatsubra
> Cc: David Miller; jjolly@suse.com; LKML; netdev@vger.kernel.org
> Subject: Re: [PATCH] rds: Error on offset mismatch if not loopback
>
> On 11/14/2013 01:40 AM, Josh Hunt wrote:
>> On Wed, Nov 13, 2013 at 9:16 AM, Venkat Venkatsubra
>> <venkat.x.venkatsubra@oracle.com> wrote:
>>> -----Original Message-----
>>> From: Josh Hunt [mailto:joshhunt00@gmail.com]
>>> Sent: Tuesday, November 12, 2013 10:25 PM
>>> To: David Miller
>>> Cc: jjolly@suse.com; LKML; Venkat Venkatsubra; netdev@vger.kernel.org
>>> Subject: Re: [PATCH] rds: Error on offset mismatch if not loopback
>>>
>>> On Tue, Nov 12, 2013 at 10:22 PM, Josh Hunt <joshhunt00@gmail.com> wrote:
>>>> On Sat, Sep 22, 2012 at 2:25 PM, David Miller <davem@davemloft.net> wrote:
>>>>> From: John Jolly <jjolly@suse.com>
>>>>> Date: Fri, 21 Sep 2012 15:32:40 -0600
>>>>>
>>>>>> Attempting an rds connection from the IP address of an IPoIB
>>>>>> interface to itself causes a kernel panic due to a BUG_ON() being triggered.
>>>>>> Making the test less strict allows rds-ping to work without
>>>>>> crashing the machine.
>>>>>>
>>>>>> A local unprivileged user could use this flaw to crash the system.
>>>>>>
>>>>>> Signed-off-by: John Jolly <jjolly@suse.com>
>>>>> Besides the questions being asked of you by Venkat Venkatsubra,
>>>>> this patch has another issue.
>>>>>
>>>>> It has been completely corrupted by your email client, it has
>>>>> turned all TAB characters into spaces, making the patch useless.
>>>>>
>>>>> Please learn how to send a patch unmolested in the body of your
>>>>> email. Test it by emailing the patch to yourself, and verifying
>>>>> that you can in fact apply the patch you receive in that email.
>>>>> Then, and only then, should you consider making a new submission of
>>>>> this patch.
>>>>>
>>>>> Use Documentation/email-clients.txt for guidance.
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>> linux-kernel" in the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>> Please read the FAQ at http://www.tux.org/lkml/
>>>> I think this issue was lost in the shuffle. It appears that redhat,
>>>> ubuntu, and oracle are maintaining local patches to resolve this:
>>>>
>>>> https://oss.oracle.com/git/?p=redpatch.git;a=commit;h=c7b6a0a1d8d636
>>>> 85
>>>> 2be130fa15fa8be10d4704e8
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=822754
>>>> http://ubuntu.5.x6.nabble.com/CVE-2012-2372-RDS-local-ping-DOS-td498
>>>> 53
>>>> 88.html
>>>>
>>>> Given that Oracle has applied it I'll make the assumption that
>>>> Venkat's question was answered at some point.
>>>>
>>>> David - I can resubmit the patch with the proper signed-off-by and
>>>> formatting if you are willing to apply it unless John wants to try
>>>> again. I think it's time this got upstream.
>>>>
>>>> --
>>>> Josh
>>> Ugh.. hopefully resending with all the html crap removed...
>>>
>>> --
>>> Josh
>>>
>>> Hi Josh,
>>>
>>> No, I still didn't get an answer for how "off" could be non-zero in case of rds-ping to hit BUG_ON(off % RDS_FRAG_SIZE).
>>> Because, rds-ping uses zero byte messages to ping.
>>> If you have a test case that reproduces the kernel panic I can try it out and see how that can happen.
>>> The Oracle's internal code I checked doesn't have that patch applied.
>>>
>>> Venkat
>> No I don't have a test case. I came across this CVE while doing an
>> audit and noticed it was patched in Ubuntu's kernel and other distros,
>> but was not in the upstream kernel yet. Quick googling of lkml showed
>> that there were at least two attempts to get this patch upstream, but
>> both had issues due to not following the proper submission process:
>>
>> https://lkml.org/lkml/2012/10/22/433
>> https://lkml.org/lkml/2012/9/21/505
>>
>> From my searching it appears the initial bug was found by someone at redhat:
>> https://bugzilla.redhat.com/show_bug.cgi?id=822754
>>
>> I've added Li Honggang the reporter of this issue from Redhat to the
>> mail. Hopefully he can share his testcase.
> The test case is very simple:
> Steps to Reproduce:
> 1. yum install -y rds-tools
>
> 2. [root@rdma3 ~]# ifconfig ib0 | grep 'inet addr'
> inet addr:172.31.0.3 Bcast:172.31.0.255 Mask:255.255.255.0
>
> 3. [root@rdma3 ~]# /usr/bin/rds-ping 172.31.0.3 <<<< kernel panic (You may need to wait for a few seconds before the kernel panic.)
>> and possibly requires certain hardware as Jay writes in the first link above:
>> "...some Infiniband HCAs(QLogic, possibly others) the machine will panic..."
> This bug can be reproduced with Mellanox HCAs (mlx4_ib.ko and mthca.ko), QLogic HCA (ib_qib.ko). I did not test the QLogic HCA running "ib_ipath.ko".
>
> As I know the upstream code of RDS is broken. There are *many* RDS bugs.
>
> Best regards.
> Honggang
>> I was referring to this oracle commit:
>> https://oss.oracle.com/git/?p=redpatch.git;a=commit;h=c7b6a0a1d8d63685
>> 2be130fa15fa8be10d4704e8
>>
>> I have no experience with this code. There were a few comments around
>> the reset and xmit fns about making sure the caller did certain things
>> if not they were racy, but I have no idea if that's coming into play
>> here.
>>
> Hi Honggang,
>
> I ran rds-ping over local interface for 30 minutes. I stopped it after that.
> It didn't hit any panic.
>
> # ip addr show dev ib0
> 6: ib0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2044 qdisc pfifo_fast qlen 1024
> link/infiniband 80:00:00:48:fe:80:00:00:00:00:00:00:00:21:28:00:01:cf:63:db brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
> inet 10.196.4.125/30 brd 10.196.4.127 scope global ib0
> inet6 fe80::221:2800:1cf:63db/64 scope link
> valid_lft forever preferred_lft forever
> #
>
> # rds-ping 10.196.4.125
> 1: 170 usec
> 2: 171 usec
> ....
> ....
> ....
> 1860: 173 usec
> 1861: 171 usec
> 1862: 177 usec
> 1863: 168 usec
> 1864: 171 usec
> 1865: 175 usec
> ^C#
>
> I tested with Oracle UEK2 which is based on 2.6.39 kernel. Mellanox IB adaptor.
> 19:00.0 InfiniBand: Mellanox Technologies MT26428 [ConnectX VPI PCIe 2.0 5GT/s - IB QDR / 10GigE] (rev b0)
>
> There is something about your setup that must be causing it for you.
> Can I work with you offline if you are available ?
>
> The panic you are hitting is not making sense to me.
>
> Venkat
Hi, Venkat
It seems we are in different time zone. Please contact me via email if
you need I do something for this bug. Could you please try upstream
kernel 2.6.39. I confirmed that the bug can be reproduced with Mellanox
and QLogic HCA when running upstream kernel-2.6.39.
[root@rdma01 ~]# ifconfig mlx4_ib1
Ifconfig uses the ioctl access method to get the full address
information, which limits hardware addresses to 8 bytes.
Because Infiniband address has 20 bytes, only the first 8 bytes are
displayed correctly.
Ifconfig is obsolete! For replacement check ip.
mlx4_ib1 Link encap:InfiniBand HWaddr
80:00:00:48:FE:80:00:00:00:00:00:00:00:00:00:00:00:00:00:00
inet addr:172.31.2.1 Bcast:172.31.2.255 Mask:255.255.255.0
inet6 addr: fe80::7ae7:d1ff:ff6b:b01/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:65520 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:5 overruns:0 carrier:0
collisions:0 txqueuelen:256
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
[root@rdma01 ~]# rpm -qf /usr/bin/rds-ping
rds-tools-2.0.6-3.el6.x86_64
[root@rdma01 ~]# uname -a
Linux rdma01.rhts.eng.nay.redhat.com 2.6.39 #1 SMP Thu Nov 14 20:25:45
EST 2013 x86_64 x86_64 x86_64 GNU/Linux
[root@rdma01 ~]# ibstat
CA 'mlx4_0'
CA type: MT26428
Number of ports: 2
Firmware version: 2.8.600
Hardware version: b0
Node GUID: 0x78e7d1ffff6b0b00
System image GUID: 0x78e7d1ffff6b0b03
Port 1:
State: Active
Physical state: LinkUp
Rate: 40
Base lid: 1
LMC: 0
SM lid: 4
Capability mask: 0x02510868
Port GUID: 0x78e7d1ffff6b0b01
Link layer: InfiniBand
Port 2:
State: Down
Physical state: Polling
Rate: 70
Base lid: 0
LMC: 0
SM lid: 0
Capability mask: 0x02510868
Port GUID: 0x78e7d1ffff6b0b02
Link layer: InfiniBand
[root@rdma01 ~]# lspci | grep Mellanox
1f:00.0 InfiniBand: Mellanox Technologies MT26428 [ConnectX VPI PCIe 2.0
5GT/s - IB QDR / 10GigE] (rev b0)
[root@rdma01 ~]# ssh 172.31.2.2 hostname (make sure the IPoIB
interface works)
rdma02.rhts.eng.nay.redhat.com
[root@rdma01 ~]# ssh 172.31.2.1 hostname
rdma01.rhts.eng.nay.redhat.com
[root@rdma01 ~]# /usr/bin/rds-ping 172.31.2.1 (kernel panic, please see
the attachment for console log)
[-- Attachment #2: upstream-kernel-2.6.39-rds-ping-panic.log --]
[-- Type: text/x-log, Size: 6544 bytes --]
RDS/IB: connected to 172.31.2.1 version 3.1
RDS/IB: connected to 172.31.2.1 version 3.1
------------[ cut here ]------------
kernel BUG at net/rds/ib_send.c:547!
invalid opcode: 0000 [#1] SMP
last sysfs file: /sys/devices/system/cpu/online
CPU 6
Modules linked in: ib_iser libiscsi scsi_transport_iscsi ib_srp scsi_transport_srp scsi_tgt rds_rdma rds_tcp rds ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm ib_addr ipv6 ib_sa microcode cdc_ether usbnet mii serio_raw pcspkr i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support sg shpchp ioatdma dca i7core_edac edac_core cxgb3 mdio mlx4_ib ib_mad mlx4_en mlx4_core ib_core cxgb4 bnx2 ext4 mbcache jbd2 sd_mod crc_t10dif pata_acpi ata_generic ata_piix megaraid_sas dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan]
Pid: 136, comm: kworker/u:1 Not tainted 2.6.39 #1 IBM System x3650 M3 -[7945O63]-/00D4062
RIP: 0010:[<ffffffffa036d7f9>] [<ffffffffa036d7f9>] rds_ib_xmit+0xa69/0xaf0 [rds_rdma]
RSP: 0018:ffff880271b51c50 EFLAGS: 00010202
RAX: ffff880266dc2000 RBX: ffff880271639a00 RCX: 0000000000000000
RDX: 0000000000000030 RSI: ffff880471e81000 RDI: ffff880270997cf0
RBP: ffff880271b51d30 R08: 0000000000000fd0 R09: ffff880471e81190
R10: 00000000ffffffff R11: 0000000000000001 R12: ffff880471e81000
R13: ffff880471e81000 R14: 0000000000000000 R15: ffff880271b51d90
FS: 0000000000000000(0000) GS:ffff88047fc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00002b302d2aa080 CR3: 0000000001a03000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process kworker/u:1 (pid: 136, threadinfo ffff880271b50000, task ffff880271ae60c0)
Stack:
0000000000000400 0000000000000001 0000000000000001 0000000a0000000a
0000000000000128 ffffffff8114747c 0000000000000002 0000000000000001
ffff880271ae60c0 ffffffff812402f0 ffff880471e81000 0000003000000002
Call Trace:
[<ffffffff8114747c>] ? __kmalloc+0x21c/0x230
[<ffffffff812402f0>] ? sg_init_table+0x30/0x50
[<ffffffffa0340df2>] ? rds_message_alloc_sgs+0x62/0xa0 [rds]
[<ffffffffa0341224>] ? rds_message_map_pages+0xa4/0x110 [rds]
[<ffffffffa0342f5b>] rds_send_xmit+0x38b/0x6e0 [rds]
[<ffffffffa0344010>] ? rds_recv_worker+0xc0/0xc0 [rds]
[<ffffffffa0344045>] rds_send_worker+0x35/0xc0 [rds]
[<ffffffff8107d0f9>] process_one_work+0x129/0x430
[<ffffffff8107f4ab>] worker_thread+0x17b/0x3c0
[<ffffffff8107f330>] ? manage_workers+0x120/0x120
[<ffffffff81084566>] kthread+0x96/0xa0
[<ffffffff814e4104>] kernel_thread_helper+0x4/0x10
[<ffffffff810844d0>] ? kthread_worker_fn+0x1a0/0x1a0
[<ffffffff814e4100>] ? gs_change+0x13/0x13
Code: ff ff e9 b1 fe ff ff 48 8b 0d c4 fe 69 e1 48 89 8d 70 ff ff ff e9 71 ff ff ff 83 bd 7c ff ff ff 00 0f 84 f4 f5 ff ff 0f 0b eb fe <0f> 0b eb fe 44 8b 8d 48 ff ff ff 41 b7 01 e9 51 f6 ff ff 0f 0b
RIP [<ffffffffa036d7f9>] rds_ib_xmit+0xa69/0xaf0 [rds_rdma]
RSP <ffff880271b51c50>
---[ end trace de7f8972e25cd611 ]---
BUG: unable to handle kernel paging request at fffffffffffffff8
IP: [<ffffffff810840c0>] kthread_data+0x10/0x20
PGD 1a05067 PUD 1a06067 PMD 0
Oops: 0000 [#2] SMP
last sysfs file: /sys/devices/system/cpu/online
CPU 6
Modules linked in: ib_iser libiscsi scsi_transport_iscsi ib_srp scsi_transport_srp scsi_tgt rds_rdma rds_tcp rds ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm ib_addr ipv6 ib_sa microcode cdc_ether usbnet mii serio_raw pcspkr i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support sg shpchp ioatdma dca i7core_edac edac_core cxgb3 mdio mlx4_ib ib_mad mlx4_en mlx4_core ib_core cxgb4 bnx2 ext4 mbcache jbd2 sd_mod crc_t10dif pata_acpi ata_generic ata_piix megaraid_sas dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan]
Pid: 136, comm: kworker/u:1 Tainted: G D 2.6.39 #1 IBM System x3650 M3 -[7945O63]-/00D4062
RIP: 0010:[<ffffffff810840c0>] [<ffffffff810840c0>] kthread_data+0x10/0x20
RSP: 0018:ffff880271b51918 EFLAGS: 00010096
RAX: 0000000000000000 RBX: 0000000000000006 RCX: ffff880271ae60c0
RDX: 0000000000009bf5 RSI: 0000000000000006 RDI: ffff880271ae60c0
RBP: ffff880271b51918 R08: ffff880271ae6570 R09: dead000000200200
R10: 00000000ffffffff R11: 0000000000000007 R12: ffff880271ae6658
R13: 0000000000000006 R14: 0000000000000006 R15: 0000000000000006
FS: 0000000000000000(0000) GS:ffff88047fc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: fffffffffffffff8 CR3: 0000000001a03000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process kworker/u:1 (pid: 136, threadinfo ffff880271b50000, task ffff880271ae60c0)
Stack:
ffff880271b51938 ffffffff8107e385 ffff880272d67b40 ffff88047fc150c0
ffff880271b519d8 ffffffff814d882e ffff880271b51978 ffff880271ae60c0
ffff880271ae60c0 00000000000150c0 ffff880271b51fd8 ffff880271b50010
Call Trace:
[<ffffffff8107e385>] wq_worker_sleeping+0x15/0xa0
[<ffffffff814d882e>] schedule+0x49e/0x9c0
[<ffffffff810675d1>] do_exit+0x271/0x430
[<ffffffff814dc08b>] oops_end+0xab/0xf0
[<ffffffff8100e7cb>] die+0x5b/0x90
[<ffffffff814db994>] do_trap+0xc4/0x170
[<ffffffff8100c695>] do_invalid_op+0x95/0xb0
[<ffffffffa036d7f9>] ? rds_ib_xmit+0xa69/0xaf0 [rds_rdma]
[<ffffffff814e3f7b>] invalid_op+0x1b/0x20
[<ffffffffa036d7f9>] ? rds_ib_xmit+0xa69/0xaf0 [rds_rdma]
[<ffffffff8114747c>] ? __kmalloc+0x21c/0x230
[<ffffffff812402f0>] ? sg_init_table+0x30/0x50
[<ffffffffa0340df2>] ? rds_message_alloc_sgs+0x62/0xa0 [rds]
[<ffffffffa0341224>] ? rds_message_map_pages+0xa4/0x110 [rds]
[<ffffffffa0342f5b>] rds_send_xmit+0x38b/0x6e0 [rds]
[<ffffffffa0344010>] ? rds_recv_worker+0xc0/0xc0 [rds]
[<ffffffffa0344045>] rds_send_worker+0x35/0xc0 [rds]
[<ffffffff8107d0f9>] process_one_work+0x129/0x430
[<ffffffff8107f4ab>] worker_thread+0x17b/0x3c0
[<ffffffff8107f330>] ? manage_workers+0x120/0x120
[<ffffffff81084566>] kthread+0x96/0xa0
[<ffffffff814e4104>] kernel_thread_helper+0x4/0x10
[<ffffffff810844d0>] ? kthread_worker_fn+0x1a0/0x1a0
[<ffffffff814e4100>] ? gs_change+0x13/0x13
Code: 1f 44 00 00 65 48 8b 04 25 80 cc 00 00 48 8b 80 40 05 00 00 8b 40 f0 c9 c3 66 90 55 48 89 e5 0f 1f 44 00 00 48 8b 87 40 05 00 00
8b 40 f8 c9 c3 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 0f
RIP [<ffffffff810840c0>] kthread_data+0x10/0x20
RSP <ffff880271b51918>
CR2: fffffffffffffff8
---[ end trace de7f8972e25cd612 ]---
Fixing recursive fault but reboot is needed!
^ permalink raw reply
* Re: [PATCH] net: sctp: recover a tranport when an ack comes
From: Vlad Yasevich @ 2013-11-15 2:34 UTC (permalink / raw)
To: Chang Xiangzhong, nhorman
Cc: davem, linux-sctp, netdev, linux-kernel, dreibh, ernstgr
In-Reply-To: <1384461624-17636-1-git-send-email-changxiangzhong@gmail.com>
On 11/14/2013 03:40 PM, Chang Xiangzhong wrote:
> Expected Behavior:
> When hearing an ack from a tranport/path, set its state to normal/on if it's
> in abnormal(__partial_failure__ or inactive) state.
>
> state machine of tranport->state
> Whenever a T3_RTX timer expires, then transport->error_count++.
> When (association->pf_retrans < transport->error_count < tranport->pathmaxrtx)
> transport->state = SCTP_PF //partial failure
>
> When a heartbeat-ack comes or conventional ack acknowledged its availability,
> transport->state = SCTP_ON
>
> Signed-off-by: Chang Xiangzhong <changxiangzhong@gmail.com>
> Fixes: 5aa93bcf66f ("sctp: Implement quick failover draft from tsvwg")
I don't think this is right. The spec states:
8. ACKs for retransmissions do not transition a PF destination back
to Active state, since a sender cannot disambiguate whether the
ack was for the original transmission or the retransmission(s).
Now, the proper way to this would would be modify
sctp_assoc_control_transport() to transition the transport state to
ACTIVE if it was PF transport that was chosen to send data.
-vlad
> ---
> net/sctp/outqueue.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
> index 94df758..2557fa5 100644
> --- a/net/sctp/outqueue.c
> +++ b/net/sctp/outqueue.c
> @@ -1517,6 +1517,7 @@ static void sctp_check_transmitted(struct sctp_outq *q,
> * active if it is not so marked.
> */
> if ((transport->state == SCTP_INACTIVE ||
> + transport->state == SCTP_PF ||
> transport->state == SCTP_UNCONFIRMED) &&
> sctp_cmp_addr_exact(&transport->ipaddr, saddr)) {
> sctp_assoc_control_transport(
>
^ permalink raw reply
* Re: [PATCH net v2 1/2] macvlan: introduce macvlan_dev_real_dev() helper function
From: Vlad Yasevich @ 2013-11-15 2:43 UTC (permalink / raw)
To: Michal Kubecek; +Cc: netdev, David S. Miller, Patrick McHardy, John Fastabend
In-Reply-To: <20131114155756.GA4161@lion.mk-sys.cz>
On 11/14/2013 10:57 AM, Michal Kubecek wrote:
> On Thu, Nov 14, 2013 at 10:03:19AM -0500, Vlad Yasevich wrote:
>> On 11/14/2013 09:00 AM, Michal Kubecek wrote:
>>> +#if IS_ENABLED(CONFIG_MACVLAN)
>>> +static inline struct net_device *
>>> +macvlan_dev_real_dev(const struct net_device *dev)
>>> +{
>>> + struct macvlan_dev *macvlan = netdev_priv(dev);
>>> +
>>> + return macvlan->lowerdev;
>>> +}
>>> +#else
>>> +static inline struct net_device *
>>> +macvlan_dev_real_dev(const struct net_device *dev)
>>> +{
>>> + return NULL;
>>> +}
>>> +#endif
>>> +
>>
>> You may want to do the same here as was done for
>> vlan_dev_real_dev(). This function is not intended to be called
>> blindly and should always
>> be called after netif_is_macvlan().
>
> I'm not sure. It makes sense from the developer point of view: if we
> find an inconsistency which must be caused by a bug in kernel code, do
> panic so that the bug is found and fixed as soon as possible. However,
> I remember a discussion where the point was that BUG() and BUG_ON()
> should only be used if there is no way to recover. From this point of
> view, WARN or WARN_ONCE might be better choice - but I'm not strictly
> opposed to BUG().
>
> Michal Kubecek
>
If someone blindly calls macvlan_dev_real_dev() and macvlan module is
enabled, but there is no macvlan device, you are going to get garbage
and crash. So crashing if module is disabled for the same case seems
perfectly reasonable.
-vlad
^ permalink raw reply
* Re: Fwd: Cross thread shutdown of connected UDP socket, unexpected recvfrom behavior
From: Hannes Frederic Sowa @ 2013-11-15 4:05 UTC (permalink / raw)
To: mpb; +Cc: netdev
In-Reply-To: <CAApbN=K8j+XQG+pQF2fxBSrDEPcjD242e9uP72azD9XWBzHcGQ@mail.gmail.com>
On Wed, Nov 13, 2013 at 12:07:20PM -0800, mpb wrote:
> I have a C/pthreads program with two threads ("main" and "thread").
> "thread" calls recvfrom on a connected UDP socket and blocks, waiting
> for input. "main" then calls shutdown SHUT_RD on the socket. In
> "thread", recvfrom returns, apparently successfully, returning a zero
> length string, and setting src_addr to a bogus(?) address family,
> port, and source address.
>
> Is the above the correct behavior for recvfrom?
>
> Here is output from my program. "main" sends "hello\0", then "" (the
> empty string), then calls shutdown. "thread" receives "hello\0", "",
> and then finally receives an empty string that was never sent!
>
> thread recvfrom: Success
> rv 6 addrlen 16 fam 2 port 8000 addr 100007f
>
> thread recvfrom: Success
> rv 0 addrlen 16 fam 2 port 8000 addr 100007f
>
> main shutdown: Success
> rv 0
>
> thread recvfrom: Success
> rv 0 addrlen 16 fam 59060 port 44237 addr deaadef0
>
> The source code (2k) for the porgram is attached. I'm running Ubuntu
> 13.04, kernel 3.8.0-19-generic #30-Ubuntu, on 32-bit i686.
>
> For reference, this June 2000 LKML thread discusses calling close in a
> similar situation.
> http://www.gossamer-threads.com/lists/linux/kernel/144379
>
> Please CC me if you have questions, otherwise I'll try to watch for
> answers in the list archives.
Changing such errno values is often brittle e.g. returning -EPIPE instead of
an EOF marker. It is coded very demonstrative to not return an error in
wait_for_more_packets, so I guess there will be a reason.
But at least we should not return uninitialized data from the stack:
diff --git a/net/socket.c b/net/socket.c
index c226ace..44499db 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -1834,6 +1834,7 @@ SYSCALL_DEFINE6(recvfrom, int, fd, void __user *, ubuf, size_t, size,
if (!sock)
goto out;
+ memset(&address, 0, sizeof(address));
msg.msg_control = NULL;
msg.msg_controllen = 0;
msg.msg_iovlen = 1;
@@ -2228,6 +2229,8 @@ static int ___sys_recvmsg(struct socket *sock, struct msghdr __user *msg,
uaddr = (__force void __user *)msg_sys->msg_name;
uaddr_len = COMPAT_NAMELEN(msg);
+ if (uaddr != NULL)
+ memset(&addr, 0, sizeof(addr));
if (MSG_CMSG_COMPAT & flags) {
err = verify_compat_iovec(msg_sys, iov, &addr, VERIFY_WRITE);
} else
I'll test and submit the above patch if no one else speaks up.
Greetings,
Hannes
^ permalink raw reply related
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