* Re: 3.12-git Intel e1000e hardware unit hang / tx queue timeouts
From: Andre Tomt @ 2013-10-12 15:30 UTC (permalink / raw)
To: netdev
In-Reply-To: <52594DBD.3070108@tomt.net>
On 12. okt. 2013 15:25, Andre Tomt wrote:
> I'm going to boot 3.10.16 on it now, and see how it fares.
3.10.16 is just as flaky.
Turning the offloads back off for now, will try to dig a little deeper
later.
3.10 log:
> [ 2990.799280] e1000e 0000:00:19.0 em2: Detected Hardware Unit Hang:
> [ 2990.799280] TDH <f8>
> [ 2990.799280] TDT <1a>
> [ 2990.799280] next_to_use <1a>
> [ 2990.799280] next_to_clean <f6>
> [ 2990.799280] buffer_info[next_to_clean]:
> [ 2990.799280] time_stamp <1000a3f4a>
> [ 2990.799280] next_to_watch <f8>
> [ 2990.799280] jiffies <1000a41cd>
> [ 2990.799280] next_to_watch.status <0>
> [ 2990.799280] MAC Status <80083>
> [ 2990.799280] PHY Status <796d>
> [ 2990.799280] PHY 1000BASE-T Status <7800>
> [ 2990.799280] PHY Extended Status <3000>
> [ 2990.799280] PCI Status <10>
> [ 2992.800488] e1000e 0000:00:19.0 em2: Detected Hardware Unit Hang:
> [ 2992.800488] TDH <f8>
> [ 2992.800488] TDT <1a>
> [ 2992.800488] next_to_use <1a>
> [ 2992.800488] next_to_clean <f6>
> [ 2992.800488] buffer_info[next_to_clean]:
> [ 2992.800488] time_stamp <1000a3f4a>
> [ 2992.800488] next_to_watch <f8>
> [ 2992.800488] jiffies <1000a43c1>
> [ 2992.800488] next_to_watch.status <0>
> [ 2992.800488] MAC Status <80083>
> [ 2992.800488] PHY Status <796d>
> [ 2992.800488] PHY 1000BASE-T Status <7800>
> [ 2992.800488] PHY Extended Status <3000>
> [ 2992.800488] PCI Status <10>
> [ 2994.801816] e1000e 0000:00:19.0 em2: Detected Hardware Unit Hang:
> [ 2994.801816] TDH <f8>
> [ 2994.801816] TDT <1a>
> [ 2994.801816] next_to_use <1a>
> [ 2994.801816] next_to_clean <f6>
> [ 2994.801816] buffer_info[next_to_clean]:
> [ 2994.801816] time_stamp <1000a3f4a>
> [ 2994.801816] next_to_watch <f8>
> [ 2994.801816] jiffies <1000a45b5>
> [ 2994.801816] next_to_watch.status <0>
> [ 2994.801816] MAC Status <80083>
> [ 2994.801816] PHY Status <796d>
> [ 2994.801816] PHY 1000BASE-T Status <7800>
> [ 2994.801816] PHY Extended Status <3000>
> [ 2994.801816] PCI Status <10>
> [ 2995.805673] ------------[ cut here ]------------
> [ 2995.805684] WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x185/0x1eb()
> [ 2995.805695] NETDEV WATCHDOG: em2 (e1000e): transmit queue 0 timed out
> [ 2995.805697] Modules linked in: vhost_net macvtap macvlan tun xt_pkttype xt_CT iptable_raw ipt_MASQUERADE xt_nat iptable_nat nf_nat_ipv4 nf_nat ip6t_frag ip6t_ah ip6t_REJECT ebtable_nat ip6table_filter ebtables ip6_tables xt_LOG xt_limit ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 xt_tcpudp xt_conntrack nf_conntrack xt_multiport iptable_filter ip_tables x_tables iTCO_wdt iTCO_vendor_support act_mirred cls_u32 sch_ingress sch_fq_codel sch_hfsc fbcon bitblit softcursor font tileblit bridge arc4 8021q garp stp mrp llc dm_multipath scsi_dh ath9k ath9k_common ath9k_hw ath coretemp mac80211 crc32_pclmul crc32c_intel ghash_clmulni_intel cryptd lpc_ich cfg80211 mfd_core rfkill firmware_class i915 intel_agp intel_gtt drm_kms_helper drm i2c_algo_bit mei_me i2c_core mei tpm_tis evdev tpm tpm_bios
ehci_pci ehci_hcd video kvm_intel kvm ifb dummy w83627ehf hwmon_vid hwmon ext4 crc16 jbd2 mbcache dm_mod sd_mod ahci e1000e libahci xhci_hcd ptp pps_core usbcore usb_common
> [ 2995.805772] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-1-server #1
> [ 2995.805774] Hardware name: /DQ77KB, BIOS KBQ7710H.86A.0052.2013.0708.1336 07/08/2013
> [ 2995.805777] 00000000000114a8 ffff88021e203da0 ffffffff813394c7 ffff88021e203dd8
> [ 2995.805780] ffffffff8102d71c ffff88021e203de8 ffff88020fd0c000 ffff880212b8cc00
> [ 2995.805783] 0000000000000001 0000000000000000 ffff88021e203e38 ffffffff8102d77b
> [ 2995.805787] Call Trace:
> [ 2995.805788] <IRQ> [<ffffffff813394c7>] dump_stack+0x19/0x1b
> [ 2995.805799] [<ffffffff8102d71c>] warn_slowpath_common+0x60/0x78
> [ 2995.805802] [<ffffffff8102d77b>] warn_slowpath_fmt+0x47/0x49
> [ 2995.805808] [<ffffffff812956c6>] dev_watchdog+0x185/0x1eb
> [ 2995.805812] [<ffffffff81295541>] ? dev_graft_qdisc+0x66/0x66
> [ 2995.805815] [<ffffffff81295541>] ? dev_graft_qdisc+0x66/0x66
> [ 2995.805820] [<ffffffff810384c3>] call_timer_fn.isra.26+0x23/0x7b
> [ 2995.805823] [<ffffffff810386c6>] run_timer_softirq+0x1ab/0x1d3
> [ 2995.805826] [<ffffffff8103362e>] __do_softirq+0xbf/0x173
> [ 2995.805831] [<ffffffff8133f07c>] call_softirq+0x1c/0x30
> [ 2995.805836] [<ffffffff810035b7>] do_softirq+0x2e/0x69
> [ 2995.805838] [<ffffffff810337ac>] irq_exit+0x3e/0x4c
> [ 2995.805842] [<ffffffff8101d092>] smp_apic_timer_interrupt+0x86/0x94
> [ 2995.805846] [<ffffffff8133ea0a>] apic_timer_interrupt+0x6a/0x70
> [ 2995.805847] <EOI> [<ffffffff81253412>] ? cpuidle_enter_state+0x4d/0x9e
> [ 2995.805853] [<ffffffff8125340b>] ? cpuidle_enter_state+0x46/0x9e
> [ 2995.805856] [<ffffffff81253535>] cpuidle_idle_call+0xd2/0x121
> [ 2995.805860] [<ffffffff81008dfd>] arch_cpu_idle+0x9/0x18
> [ 2995.805864] [<ffffffff8105e497>] cpu_startup_entry+0xfc/0x148
> [ 2995.805868] [<ffffffff813252de>] rest_init+0x72/0x74
> [ 2995.805873] [<ffffffff81686cd0>] start_kernel+0x3d7/0x3e2
> [ 2995.805877] [<ffffffff81686748>] ? do_early_param+0x93/0x93
> [ 2995.805881] [<ffffffff8168647f>] x86_64_start_reservations+0x2a/0x2c
> [ 2995.805885] [<ffffffff81686548>] x86_64_start_kernel+0xc7/0xca
> [ 2995.805887] ---[ end trace fd899d2b4fca47a0 ]---
> [ 2995.805901] e1000e 0000:00:19.0 em2: Reset adapter unexpectedly
> [ 2999.697213] e1000e: em2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
> [ 3949.321404] UDP: bad checksum. From 87.114.227.207:53185 to 84.209.201.2:51413 ulen 40
> [ 6117.966435] UDP: bad checksum. From 109.61.95.12:62354 to 84.209.201.2:51413 ulen 114
> [ 6520.077066] e1000e 0000:00:19.0 em2: Detected Hardware Unit Hang:
> [ 6520.077066] TDH <26>
> [ 6520.077066] TDT <33>
> [ 6520.077066] next_to_use <33>
> [ 6520.077066] next_to_clean <24>
> [ 6520.077066] buffer_info[next_to_clean]:
> [ 6520.077066] time_stamp <10017b369>
> [ 6520.077066] next_to_watch <26>
> [ 6520.077066] jiffies <10017b623>
> [ 6520.077066] next_to_watch.status <0>
> [ 6520.077066] MAC Status <80083>
> [ 6520.077066] PHY Status <796d>
> [ 6520.077066] PHY 1000BASE-T Status <7800>
> [ 6520.077066] PHY Extended Status <3000>
> [ 6520.077066] PCI Status <10>
> [ 6522.078332] e1000e 0000:00:19.0 em2: Detected Hardware Unit Hang:
> [ 6522.078332] TDH <26>
> [ 6522.078332] TDT <33>
> [ 6522.078332] next_to_use <33>
> [ 6522.078332] next_to_clean <24>
> [ 6522.078332] buffer_info[next_to_clean]:
> [ 6522.078332] time_stamp <10017b369>
> [ 6522.078332] next_to_watch <26>
> [ 6522.078332] jiffies <10017b817>
> [ 6522.078332] next_to_watch.status <0>
> [ 6522.078332] MAC Status <80083>
> [ 6522.078332] PHY Status <796d>
> [ 6522.078332] PHY 1000BASE-T Status <7800>
> [ 6522.078332] PHY Extended Status <3000>
> [ 6522.078332] PCI Status <10>
> [ 6524.079633] e1000e 0000:00:19.0 em2: Detected Hardware Unit Hang:
> [ 6524.079633] TDH <26>
> [ 6524.079633] TDT <33>
> [ 6524.079633] next_to_use <33>
> [ 6524.079633] next_to_clean <24>
> [ 6524.079633] buffer_info[next_to_clean]:
> [ 6524.079633] time_stamp <10017b369>
> [ 6524.079633] next_to_watch <26>
> [ 6524.079633] jiffies <10017ba0b>
> [ 6524.079633] next_to_watch.status <0>
> [ 6524.079633] MAC Status <80083>
> [ 6524.079633] PHY Status <796d>
> [ 6524.079633] PHY 1000BASE-T Status <7800>
> [ 6524.079633] PHY Extended Status <3000>
> [ 6524.079633] PCI Status <10>
> [ 6526.080929] e1000e 0000:00:19.0 em2: Detected Hardware Unit Hang:
> [ 6526.080929] TDH <26>
> [ 6526.080929] TDT <33>
> [ 6526.080929] next_to_use <33>
> [ 6526.080929] next_to_clean <24>
> [ 6526.080929] buffer_info[next_to_clean]:
> [ 6526.080929] time_stamp <10017b369>
> [ 6526.080929] next_to_watch <26>
> [ 6526.080929] jiffies <10017bbff>
> [ 6526.080929] next_to_watch.status <0>
> [ 6526.080929] MAC Status <80083>
> [ 6526.080929] PHY Status <796d>
> [ 6526.080929] PHY 1000BASE-T Status <7800>
> [ 6526.080929] PHY Extended Status <3000>
> [ 6526.080929] PCI Status <10>
> [ 6527.092694] e1000e 0000:00:19.0 em2: Reset adapter unexpectedly
> [ 6530.984252] e1000e: em2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
^ permalink raw reply
* Re: [PATCH] net: sh_eth: Fix RX packets errors on R8A7740
From: Sergei Shtylyov @ 2013-10-12 16:58 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: Nguyen Hong Ky, David S. Miller, netdev, Ryusuke Sakato,
Simon Horman
In-Reply-To: <1381127365-6521-2-git-send-email-nh-ky@jinso.co.jp>
Hello.
On 07-10-2013 8:29, Nguyen Hong Ky wrote:
> This patch will fix RX packets errors when receiving big size
> of data by set bit RNC = 1.
> RNC - Receive Enable Control
> 0: Upon completion of reception of one frame, the E-DMAC writes
> the receive status to the descriptor and clears the RR bit in
> EDRRR to 0.
> 1: Upon completion of reception of one frame, the E-DMAC writes
> (writes back) the receive status to the descriptor. In addition,
> the E-DMAC reads the next descriptor and prepares for reception
> of the next frame.
> In addition, for get more stable when receiving packets, I set
> maximum size for the transmit/receive FIFO and inserts padding
> in receive data.
> Signed-off-by: Nguyen Hong Ky <nh-ky@jinso.co.jp>
> ---
> drivers/net/ethernet/renesas/sh_eth.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
> diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
> index a753928..11d34f0 100644
> --- a/drivers/net/ethernet/renesas/sh_eth.c
> +++ b/drivers/net/ethernet/renesas/sh_eth.c
> @@ -649,12 +649,16 @@ static struct sh_eth_cpu_data r8a7740_data = {
> .eesr_err_check = EESR_TWB1 | EESR_TWB | EESR_TABT | EESR_RABT |
> EESR_RFE | EESR_RDE | EESR_RFRMER | EESR_TFE |
> EESR_TDE | EESR_ECI,
> + .fdr_value = 0x0000070f,
> + .rmcr_value = 0x00000001,
>
> .apr = 1,
> .mpr = 1,
> .tpauser = 1,
> .bculr = 1,
> .hw_swap = 1,
> + .rpadir = 1,
> + .rpadir_value = 2 << 16,
> .no_trimd = 1,
> .no_ade = 1,
> .tsu = 1,
Guennadi, could you check if this patch fixes your issue with NFS. Make
sure it applies to 'r8a7740_data' (it was misapplied to DaveM's tree).
WBR, Sergei
^ permalink raw reply
* [Patch 1/1]: libertas/sdio: fix releasing memory twice.
From: Dr. H. Nikolaus Schaller @ 2013-10-12 16:02 UTC (permalink / raw)
To: John W. Linville, Bing Zhao, H. Nikolaus Schaller, Dan Williams,
Harro Haan, libertas-dev, linux-wireless, netdev, LKML,
Belisko Marek, NeilBrown Brown
[-- Attachment #1: Type: text/plain, Size: 398 bytes --]
While upgrading the GTA04 kernel to 3.12-rc4 we came across
an issue with libertas/sdio referencing stale memory on ifconfig up
when trying to load the firmware (for a second time).
I am not at all sure if the patch is how it should be done and the right
location, but it appears to work for us with resetting priv->helper_fw to NULL
before asynchronously loading the firmware again.
[-- Attachment #2: 0001-libertas-sdio-fix-releasing-memory-twice.patch --]
[-- Type: application/octet-stream, Size: 1850 bytes --]
From f6864491ea45d2bd877a37fbb4a618e42fe03fbe Mon Sep 17 00:00:00 2001
From: "H. Nikolaus Schaller" <hns@goldelico.com>
Date: Sat, 12 Oct 2013 17:49:31 +0200
Subject: [PATCH] libertas/sdio: fix releasing memory twice. We have connected
a Wi2Wi W2CBW003 to an OMAP3 using SDIO. We have seen an
issue (not related with this patch) that sometimes power is
not turned off. This did lead to a kernel Oops if an
ifconfig up / down / up when the chip was not powered down.
This leads to a second call to lbs_get_firmware_async()
with the same priv data - and that tries to
release_firmware(priv->helper_fw); This appears to be
wrong, since it was alredy released in the
if_sdio_do_prog_firmware.
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
---
drivers/net/wireless/libertas/if_sdio.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/libertas/if_sdio.c b/drivers/net/wireless/libertas/if_sdio.c
index 4557833..a04eb41 100644
--- a/drivers/net/wireless/libertas/if_sdio.c
+++ b/drivers/net/wireless/libertas/if_sdio.c
@@ -769,6 +769,19 @@ static int if_sdio_prog_firmware(struct if_sdio_card *card)
return 0;
}
+ /* This is missing in lbs_get_firmware_async()
+ * and therefore a second call using the same priv structure
+ * may find a stale helper_fw entry that has already been
+ * released by release_firmware(helper) in
+ * if_sdio_do_prog_firmware().
+ * Or doing that release in if_sdio_do_prog_firmware()
+ * is a duplicate and should not be there.
+ * Anyways, this can happen if a ifconfig up / down / up
+ * sequence is issued.
+ */
+
+ card->priv->helper_fw = NULL;
+
ret = lbs_get_firmware_async(card->priv, &card->func->dev, card->model,
fw_table, if_sdio_do_prog_firmware);
--
1.7.7.4
^ permalink raw reply related
* Re: [PATCH v2 tip/core/rcu 07/13] ipv6/ip6_tunnel: Apply rcu_access_pointer() to avoid sparse false positive
From: Hannes Frederic Sowa @ 2013-10-12 16:43 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Eric Dumazet, Josh Triplett, linux-kernel, mingo, laijs, dipankar,
akpm, mathieu.desnoyers, niv, tglx, peterz, rostedt, dhowells,
edumazet, darren, fweisbec, sbw, David S. Miller,
Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI,
Patrick McHardy, netdev
In-Reply-To: <20131012075336.GA5790@linux.vnet.ibm.com>
On Sat, Oct 12, 2013 at 12:53:36AM -0700, Paul E. McKenney wrote:
> On Sat, Oct 12, 2013 at 04:25:08AM +0200, Hannes Frederic Sowa wrote:
> > I saw your patch regarding making rcu_assign_pointer volatile and wonder if we
> > can still make it a bit more safe to use if we force the evaluation of the
> > to-be-assigned pointer before the write barrier. This is what I have in mind:
> >
> > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> > index f1f1bc3..79eccc3 100644
> > --- a/include/linux/rcupdate.h
> > +++ b/include/linux/rcupdate.h
> > @@ -550,8 +550,9 @@ static inline void rcu_preempt_sleep_check(void)
> > })
> > #define __rcu_assign_pointer(p, v, space) \
> > do { \
> > + typeof(v) ___v = (v); \
> > smp_wmb(); \
> > - (p) = (typeof(*v) __force space *)(v); \
> > + (p) = (typeof(*___v) __force space *)(___v); \
> > } while (0)
> >
> >
> > I don't think ___v must be volatile for this case because the memory barrier
> > will force the evaluation of v first.
> >
> > This would guard against cases where rcu_assign_pointer is used like:
> >
> > rcu_assign_pointer(ptr, compute_ptr_with_side_effects());
>
> I am sorry, but I am not seeing how this would be particularly useful.
Oh, I do not think it is useful. It should help enforcing the right memory
orderings if someone uses rcu_assign_pointer in such a nasty way.
It was meant by me as a "defensive rearragement" to guard rcu_assign_pointer
to accidentaly slip memory mutations across the barrier without hurting
compiler optimizations too bad (or at all).
> The point of rcu_assign_pointer() is to order the initialization of
> a data structure against publishing a pointer to that data structure.
> An example may be found in cgroup_create():
>
> name = cgroup_alloc_name(dentry);
> if (!name)
> goto err_free_cgrp;
> rcu_assign_pointer(cgrp->name, name);
>
> Here, cgroup_alloc_name() allocates memory for the name and fills in
> the name:
>
> static struct cgroup_name *cgroup_alloc_name(struct dentry *dentry)
> {
> struct cgroup_name *name;
>
> name = kmalloc(sizeof(*name) + dentry->d_name.len + 1, GFP_KERNEL);
> if (!name)
> return NULL;
> strcpy(name->name, dentry->d_name.name);
> return name;
> }
>
> So the point of the smp_wmb() in __rcu_assign_pointer() is to order the
> strcpy() in cgroup_alloc_name() to happen before the assignment of the
> name pointer to cgrp->name.
>
> To make this example fit your pattern, we could change the code in
> cgroup_create() to look as follows (and to be buggy):
>
> /* BAD CODE! Do not do this! */
> rcu_assign_pointer(cgrp->name, cgroup_alloc_name(dentry));
> if (!cgrp->name)
> goto err_free_cgrp;
>
> The reason that this is bad practice is that it is hiding the fact that
> the allocation and initialization in cgroup_alloc_name() needs to be
> ordered before the assignment to cgrp->name.
>
> Make sense?
Absolutely! But e.g. the pointer could be preallocated and no length
checks are needed so there is no need for an error path, I guess someone
could think it is safe to put the get_ptr_with_side_effects (and if the
side effect is only a bit flip in the strucutre pointed to by the value)
in the v argument of rcu_assign_pointer.
I also tought about adding a (*(&(v))) statement to enfore that only
lvalues where allowed as the value in rcu_assign_pointer, but that would
already cause compilation errors (e.g. rcu_assign_pointer(ptr, ptr|MARK)).
The nice thing with ACCESS_ONCE(p) is, that there is now no way to put
a non-lvalue expression into the first argument of rcu_assign_pointer. :)
Regarding the volatile access, I hope that the C11 memory model
and enhancements to the compiler will some day provide a better
way to express the semantics of what is tried to express here
(__atomic_store_n/__atomic_load_n with the accompanied memory model,
which could be even weaker to what a volatile access would enfore
now and could guarantee atomic stores/loads).
Greeting,
Hannes
^ permalink raw reply
* Re: [PATCH v3 tip/core/rcu 0/14] Sparse-related updates for 3.13
From: Paul E. McKenney @ 2013-10-12 17:13 UTC (permalink / raw)
To: Josh Triplett
Cc: peterz, fweisbec, dhowells, edumazet, gaofeng, mingo, bridge,
jmorris, dipankar, darren, rostedt, niv, mathieu.desnoyers,
kuznet, tglx, johannes, laijs, yoshfuji, netdev,
linux-decnet-user, linux-kernel, kaber, stephen, sbw, tgraf, akpm,
fengguang.wu, davem
In-Reply-To: <20131012065326.GG15339@leaf>
On Fri, Oct 11, 2013 at 11:53:27PM -0700, Josh Triplett wrote:
> On Fri, Oct 11, 2013 at 04:16:59PM -0700, Paul E. McKenney wrote:
> > Changes from v2:
> >
> > o Switch from rcu_assign_pointer() to ACCESS_ONCE() given that
> > the pointers are all --rcu and already visible to readers,
> > as suggested by Eric Dumazet and Josh Triplett.
>
> Hang on a moment. Do *none* of these cases need write memory barriers?
Sigh. Some afternoons it doesn't pay to touch the keyboard.
Thank you for catching this. I will fix, but at this point, I am thinking
in terms of 3.14 rather than 3.13 for this series.
Thanx, Paul
^ permalink raw reply
* [PATCH net] tcp: fix incorrect ca_state in tail loss probe
From: Yuchung Cheng @ 2013-10-12 17:16 UTC (permalink / raw)
To: davem, ncardwell, nanditad
Cc: netdev, michael, jwboyer, sesse, dormando, Yuchung Cheng
On receiving an ACK that covers the loss probe sequence, TLP
immediately sets the congestion state to Open, even though some packets
are not recovered and retransmisssion are on the way. The later ACks
may trigger a WARN_ON check in step D of tcp_fastretrans_alert(), e.g.,
https://bugzilla.redhat.com/show_bug.cgi?id=989251
The fix is to follow the similar procedure in recovery by calling
tcp_try_keep_open(). The sender switches to Open state if no packets
are retransmissted. Otherwise it goes to Disorder and let subsequent
ACKs move the state to Recovery or Open.
Reported-By: Michael Sterrett <michael@sterretts.net>
Tested-By: Dormando <dormando@rydia.net>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
---
net/ipv4/tcp_input.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 113dc5f..53974c7 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -3291,7 +3291,7 @@ static void tcp_process_tlp_ack(struct sock *sk, u32 ack, int flag)
tcp_init_cwnd_reduction(sk, true);
tcp_set_ca_state(sk, TCP_CA_CWR);
tcp_end_cwnd_reduction(sk);
- tcp_set_ca_state(sk, TCP_CA_Open);
+ tcp_try_keep_open(sk);
NET_INC_STATS_BH(sock_net(sk),
LINUX_MIB_TCPLOSSPROBERECOVERY);
}
--
1.8.4
^ permalink raw reply related
* Re: [PATCH v2 tip/core/rcu 07/13] ipv6/ip6_tunnel: Apply rcu_access_pointer() to avoid sparse false positive
From: Hannes Frederic Sowa @ 2013-10-12 17:37 UTC (permalink / raw)
To: Paul E. McKenney, Eric Dumazet, Josh Triplett, linux-kernel,
mingo, laijs, dipankar, akpm, mathieu.desnoyers, niv, tglx,
peterz, rostedt, dhowells, edumazet, darren, fweisbec, sbw,
David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev
In-Reply-To: <20131012164345.GB20321@order.stressinduktion.org>
On Sat, Oct 12, 2013 at 06:43:45PM +0200, Hannes Frederic Sowa wrote:
> Regarding the volatile access, I hope that the C11 memory model
> and enhancements to the compiler will some day provide a better
> way to express the semantics of what is tried to express here
> (__atomic_store_n/__atomic_load_n with the accompanied memory model,
> which could be even weaker to what a volatile access would enfore
> now and could guarantee atomic stores/loads).
I just played around a bit more. Perhaps we could try to warn of silly
usages of ACCESS_ONCE():
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -349,7 +349,11 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
* use is to mediate communication between process-level code and irq/NMI
* handlers, all running on the same CPU.
*/
-#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
+#define ACCESS_ONCE(x) (*({ \
+ compiletime_assert(sizeof(typeof(x)) <= sizeof(typeof(&x)), \
+ "ACCESS_ONCE likely not atomic"); \
+ (volatile typeof(x) *)&(x); \
+}))
/* Ignore/forbid kprobes attach on very low level functions marked by this attribute: */
#ifdef CONFIG_KPROBES
^ permalink raw reply
* Re: [Bridge] [PATCH v3 tip/core/rcu 0/14] Sparse-related updates for 3.13
From: Hannes Frederic Sowa @ 2013-10-12 17:39 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Josh Triplett, peterz, fweisbec, dhowells, edumazet, gaofeng,
mingo, bridge, jmorris, dipankar, darren, rostedt, niv,
mathieu.desnoyers, kuznet, tglx, johannes, laijs, yoshfuji,
netdev, linux-decnet-user, linux-kernel, kaber, stephen, sbw,
tgraf, akpm, fengguang.wu, davem
In-Reply-To: <20131012171345.GB5790@linux.vnet.ibm.com>
On Sat, Oct 12, 2013 at 10:13:45AM -0700, Paul E. McKenney wrote:
> On Fri, Oct 11, 2013 at 11:53:27PM -0700, Josh Triplett wrote:
> > On Fri, Oct 11, 2013 at 04:16:59PM -0700, Paul E. McKenney wrote:
> > > Changes from v2:
> > >
> > > o Switch from rcu_assign_pointer() to ACCESS_ONCE() given that
> > > the pointers are all --rcu and already visible to readers,
> > > as suggested by Eric Dumazet and Josh Triplett.
> >
> > Hang on a moment. Do *none* of these cases need write memory barriers?
>
> Sigh. Some afternoons it doesn't pay to touch the keyboard.
>
> Thank you for catching this. I will fix, but at this point, I am thinking
> in terms of 3.14 rather than 3.13 for this series.
Some of them looked safe. You could also replace --rcu with __rcu in the
comments while at it.
Thanks,
Hannes
^ permalink raw reply
* Re: [Bridge] [PATCH v3 tip/core/rcu 0/14] Sparse-related updates for 3.13
From: Hannes Frederic Sowa @ 2013-10-12 17:43 UTC (permalink / raw)
To: Paul E. McKenney, Josh Triplett, peterz, fweisbec, dhowells,
edumazet, gaofeng, mingo, bridge, jmorris, dipankar, darren,
rostedt, niv, mathieu.desnoyers, kuznet, tglx, johannes, laijs,
yoshfuji, netdev, linux-decnet-user, linux-kernel, kaber, stephen,
sbw, tgraf, akpm, fengguang.wu, davem
In-Reply-To: <20131012173930.GD20321@order.stressinduktion.org>
On Sat, Oct 12, 2013 at 07:39:30PM +0200, Hannes Frederic Sowa wrote:
> On Sat, Oct 12, 2013 at 10:13:45AM -0700, Paul E. McKenney wrote:
> > On Fri, Oct 11, 2013 at 11:53:27PM -0700, Josh Triplett wrote:
> > > On Fri, Oct 11, 2013 at 04:16:59PM -0700, Paul E. McKenney wrote:
> > > > Changes from v2:
> > > >
> > > > o Switch from rcu_assign_pointer() to ACCESS_ONCE() given that
> > > > the pointers are all --rcu and already visible to readers,
> > > > as suggested by Eric Dumazet and Josh Triplett.
> > >
> > > Hang on a moment. Do *none* of these cases need write memory barriers?
> >
> > Sigh. Some afternoons it doesn't pay to touch the keyboard.
> >
> > Thank you for catching this. I will fix, but at this point, I am thinking
> > in terms of 3.14 rather than 3.13 for this series.
>
> Some of them looked safe. You could also replace --rcu with __rcu in the
> comments while at it.
Most of them deal with management, maybe a rtnl_assign_pointer with lockdep
check for rtnl lock could help to not clean up the wrong bits.
I don't know if rtnl_assign_pointer is that a could name as it does not really
explain why the barrier is not needed there. :/
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH v2 tip/core/rcu 07/13] ipv6/ip6_tunnel: Apply rcu_access_pointer() to avoid sparse false positive
From: Mathieu Desnoyers @ 2013-10-12 19:42 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: Paul E. McKenney, Eric Dumazet, Josh Triplett, linux-kernel,
mingo, laijs, dipankar, akpm, niv, tglx, peterz, rostedt,
dhowells, edumazet, darren, fweisbec, sbw, David S. Miller,
Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI,
Patrick McHardy, netdev
In-Reply-To: <20131012173734.GC20321@order.stressinduktion.org>
----- Original Message -----
> From: "Hannes Frederic Sowa" <hannes@stressinduktion.org>
> To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>, "Eric Dumazet" <eric.dumazet@gmail.com>, "Josh Triplett"
> <josh@joshtriplett.org>, linux-kernel@vger.kernel.org, mingo@kernel.org, laijs@cn.fujitsu.com, dipankar@in.ibm.com,
> akpm@linux-foundation.org, "mathieu desnoyers" <mathieu.desnoyers@efficios.com>, niv@us.ibm.com, tglx@linutronix.de,
> peterz@infradead.org, rostedt@goodmis.org, dhowells@redhat.com, edumazet@google.com, darren@dvhart.com,
> fweisbec@gmail.com, sbw@mit.edu, "David S. Miller" <davem@davemloft.net>, "Alexey Kuznetsov" <kuznet@ms2.inr.ac.ru>,
> "James Morris" <jmorris@namei.org>, "Hideaki YOSHIFUJI" <yoshfuji@linux-ipv6.org>, "Patrick McHardy"
> <kaber@trash.net>, netdev@vger.kernel.org
> Sent: Saturday, October 12, 2013 1:37:34 PM
> Subject: Re: [PATCH v2 tip/core/rcu 07/13] ipv6/ip6_tunnel: Apply rcu_access_pointer() to avoid sparse false positive
>
> On Sat, Oct 12, 2013 at 06:43:45PM +0200, Hannes Frederic Sowa wrote:
> > Regarding the volatile access, I hope that the C11 memory model
> > and enhancements to the compiler will some day provide a better
> > way to express the semantics of what is tried to express here
> > (__atomic_store_n/__atomic_load_n with the accompanied memory model,
> > which could be even weaker to what a volatile access would enfore
> > now and could guarantee atomic stores/loads).
>
> I just played around a bit more. Perhaps we could try to warn of silly
> usages of ACCESS_ONCE():
>
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -349,7 +349,11 @@ void ftrace_likely_update(struct ftrace_branch_data *f,
> int val, int expect);
> * use is to mediate communication between process-level code and irq/NMI
> * handlers, all running on the same CPU.
> */
> -#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
> +#define ACCESS_ONCE(x) (*({ \
> + compiletime_assert(sizeof(typeof(x)) <= sizeof(typeof(&x)), \
> + "ACCESS_ONCE likely not atomic"); \
AFAIU, ACCESS_ONCE() is not meant to ensure atomicity of load/store, but rather merely ensures that the compiler will not merge nor refetch accesses. I don't think the assert check you propose is appropriate with respect to the ACCESS_ONCE() semantic.
Thanks,
Mathieu
> + (volatile typeof(x) *)&(x); \
> +}))
>
> /* Ignore/forbid kprobes attach on very low level functions marked by this
> attribute: */
> #ifdef CONFIG_KPROBES
>
>
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
^ permalink raw reply
* Re: [Patch 1/1]: libertas/sdio: fix releasing memory twice.
From: Dan Williams @ 2013-10-12 19:58 UTC (permalink / raw)
To: Dr. H. Nikolaus Schaller
Cc: John W. Linville, Bing Zhao, Harro Haan, libertas-dev,
linux-wireless, netdev, LKML, Belisko Marek, NeilBrown Brown
In-Reply-To: <D5BD8103-A6A6-4070-878B-99FC5883725F@goldelico.com>
On Sat, 2013-10-12 at 18:02 +0200, Dr. H. Nikolaus Schaller wrote:
> While upgrading the GTA04 kernel to 3.12-rc4 we came across
> an issue with libertas/sdio referencing stale memory on ifconfig up
> when trying to load the firmware (for a second time).
>
> I am not at all sure if the patch is how it should be done and the right
> location, but it appears to work for us with resetting priv->helper_fw to NULL
> before asynchronously loading the firmware again.
How about we go even simpler? helper_fw is *only* used inside
firmware.c anyway, and that's probably where its lifetime should be
handled. Same for the main firmware. I have no idea why the bus code
is responsible for releasing the firmware anyway, when it originates
from firmware.c and control returns back there after the firmware loaded
callback is done. Does the following patch fix your problem too?
Dan
---
diff --git a/drivers/net/wireless/libertas/firmware.c b/drivers/net/wireless/libertas/firmware.c
index c0f9e7e..51b92b5 100644
--- a/drivers/net/wireless/libertas/firmware.c
+++ b/drivers/net/wireless/libertas/firmware.c
@@ -49,14 +49,19 @@ static void main_firmware_cb(const struct firmware *firmware, void *context)
/* Failed to find firmware: try next table entry */
load_next_firmware_from_table(priv);
return;
}
/* Firmware found! */
lbs_fw_loaded(priv, 0, priv->helper_fw, firmware);
+ if (priv->helper_fw) {
+ release_firmware (priv->helper_fw);
+ priv->helper_fw = NULL;
+ }
+ release_firmware (firmware);
}
static void helper_firmware_cb(const struct firmware *firmware, void *context)
{
struct lbs_private *priv = context;
if (!firmware) {
diff --git a/drivers/net/wireless/libertas/if_cs.c b/drivers/net/wireless/libertas/if_cs.c
index c94dd68..ef8c98e 100644
--- a/drivers/net/wireless/libertas/if_cs.c
+++ b/drivers/net/wireless/libertas/if_cs.c
@@ -750,22 +750,22 @@ static void if_cs_prog_firmware(struct lbs_private *priv, int ret,
}
/* Load the firmware */
ret = if_cs_prog_helper(card, helper);
if (ret == 0 && (card->model != MODEL_8305))
ret = if_cs_prog_real(card, mainfw);
if (ret)
- goto out;
+ return;
/* Now actually get the IRQ */
ret = request_irq(card->p_dev->irq, if_cs_interrupt,
IRQF_SHARED, DRV_NAME, card);
if (ret) {
pr_err("error in request_irq\n");
- goto out;
+ return;
}
/*
* Clear any interrupt cause that happened while sending
* firmware/initializing card
*/
if_cs_write16(card, IF_CS_CARD_INT_CAUSE, IF_CS_BIT_MASK);
@@ -773,18 +773,14 @@ static void if_cs_prog_firmware(struct lbs_private *priv, int ret,
/* And finally bring the card up */
priv->fw_ready = 1;
if (lbs_start_card(priv) != 0) {
pr_err("could not activate card\n");
free_irq(card->p_dev->irq, card);
}
-
-out:
- release_firmware(helper);
- release_firmware(mainfw);
}
/********************************************************************/
/* Callback functions for libertas.ko */
/********************************************************************/
diff --git a/drivers/net/wireless/libertas/if_sdio.c b/drivers/net/wireless/libertas/if_sdio.c
index 4557833..991238a 100644
--- a/drivers/net/wireless/libertas/if_sdio.c
+++ b/drivers/net/wireless/libertas/if_sdio.c
@@ -704,28 +704,24 @@ static void if_sdio_do_prog_firmware(struct lbs_private *priv, int ret,
if (ret) {
pr_err("failed to find firmware (%d)\n", ret);
return;
}
ret = if_sdio_prog_helper(card, helper);
if (ret)
- goto out;
+ return;
lbs_deb_sdio("Helper firmware loaded\n");
ret = if_sdio_prog_real(card, mainfw);
if (ret)
- goto out;
+ return;
lbs_deb_sdio("Firmware loaded\n");
if_sdio_finish_power_on(card);
-
-out:
- release_firmware(helper);
- release_firmware(mainfw);
}
static int if_sdio_prog_firmware(struct if_sdio_card *card)
{
int ret;
u16 scratch;
diff --git a/drivers/net/wireless/libertas/if_spi.c b/drivers/net/wireless/libertas/if_spi.c
index 4bb6574..87ff0ca 100644
--- a/drivers/net/wireless/libertas/if_spi.c
+++ b/drivers/net/wireless/libertas/if_spi.c
@@ -1090,19 +1090,15 @@ static int if_spi_init_card(struct if_spi_card *card)
}
err = spu_set_interrupt_mode(card, 0, 1);
if (err)
goto out;
out:
- release_firmware(helper);
- release_firmware(mainfw);
-
lbs_deb_leave_args(LBS_DEB_SPI, "err %d\n", err);
-
return err;
}
static void if_spi_resume_worker(struct work_struct *work)
{
struct if_spi_card *card;
diff --git a/drivers/net/wireless/libertas/if_usb.c b/drivers/net/wireless/libertas/if_usb.c
index 2798077..dff08a2 100644
--- a/drivers/net/wireless/libertas/if_usb.c
+++ b/drivers/net/wireless/libertas/if_usb.c
@@ -840,15 +840,15 @@ static void if_usb_prog_firmware(struct lbs_private *priv, int ret,
pr_err("failed to find firmware (%d)\n", ret);
goto done;
}
cardp->fw = fw;
if (check_fwfile_format(cardp->fw->data, cardp->fw->size)) {
ret = -EINVAL;
- goto release_fw;
+ goto done;
}
/* Cancel any pending usb business */
usb_kill_urb(cardp->rx_urb);
usb_kill_urb(cardp->tx_urb);
cardp->fwlastblksent = 0;
@@ -857,15 +857,15 @@ static void if_usb_prog_firmware(struct lbs_private *priv, int ret,
cardp->fwfinalblk = 0;
cardp->bootcmdresp = 0;
restart:
if (if_usb_submit_rx_urb_fwload(cardp) < 0) {
lbs_deb_usbd(&cardp->udev->dev, "URB submission is failed\n");
ret = -EIO;
- goto release_fw;
+ goto done;
}
cardp->bootcmdresp = 0;
do {
int j = 0;
i++;
if_usb_issue_boot_command(cardp, BOOT_CMD_FW_BY_USB);
@@ -879,22 +879,22 @@ restart:
if (cardp->bootcmdresp == BOOT_CMD_RESP_NOT_SUPPORTED) {
/* Return to normal operation */
ret = -EOPNOTSUPP;
usb_kill_urb(cardp->rx_urb);
usb_kill_urb(cardp->tx_urb);
if (if_usb_submit_rx_urb(cardp) < 0)
ret = -EIO;
- goto release_fw;
+ goto done;
} else if (cardp->bootcmdresp <= 0) {
if (--reset_count >= 0) {
if_usb_reset_device(cardp);
goto restart;
}
ret = -EIO;
- goto release_fw;
+ goto done;
}
i = 0;
cardp->totalbytes = 0;
cardp->fwlastblksent = 0;
cardp->CRC_OK = 1;
@@ -917,37 +917,34 @@ restart:
if (--reset_count >= 0) {
if_usb_reset_device(cardp);
goto restart;
}
pr_info("FW download failure, time = %d ms\n", i * 100);
ret = -EIO;
- goto release_fw;
+ goto done;
}
cardp->priv->fw_ready = 1;
if_usb_submit_rx_urb(cardp);
if (lbs_start_card(priv))
- goto release_fw;
+ goto done;
if_usb_setup_firmware(priv);
/*
* EHS_REMOVE_WAKEUP is not supported on all versions of the firmware.
*/
priv->wol_criteria = EHS_REMOVE_WAKEUP;
if (lbs_host_sleep_cfg(priv, priv->wol_criteria, NULL))
priv->ehs_remove_supported = false;
- release_fw:
- release_firmware(cardp->fw);
- cardp->fw = NULL;
-
done:
+ cardp->fw = NULL;
lbs_deb_leave(LBS_DEB_USB);
}
#ifdef CONFIG_PM
static int if_usb_suspend(struct usb_interface *intf, pm_message_t message)
{
^ permalink raw reply related
* (unknown),
From: Innocent Eleazu @ 2013-10-12 20:46 UTC (permalink / raw)
Loan offer at 3% interest rate,contact: beverlyloanservices@outlook.com
Note: Reply to this Email Only: beverlyloanservices@outlook.com
==========================================================================
Darlehen Angebot bei 3% Zins, Kontakt: beverlyloanservices@outlook.com
Hinweis: Antworten Sie auf diese E-Mail nur: beverlyloanservices@outlook.com
^ permalink raw reply
* [PATCH] bnx2x: record rx queue for LRO packets
From: Eric Dumazet @ 2013-10-12 21:08 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Eilon Greenstein, Willem de Bruijn
From: Eric Dumazet <edumazet@google.com>
RPS support is kind of broken on bnx2x, because only non LRO packets
get proper rx queue information. This triggers reorders, as it seems
bnx2x like to generate a non LRO packet for segment including TCP PUSH
flag : (this might be pure coincidence, but all the reorders I've
seen involve segments with a PUSH)
11:13:34.335847 IP A > B: . 415808:447136(31328) ack 1 win 457 <nop,nop,timestamp 3789336 3985797>
11:13:34.335992 IP A > B: . 447136:448560(1424) ack 1 win 457 <nop,nop,timestamp 3789336 3985797>
11:13:34.336391 IP A > B: . 448560:479888(31328) ack 1 win 457 <nop,nop,timestamp 3789337 3985797>
11:13:34.336425 IP A > B: P 511216:512640(1424) ack 1 win 457 <nop,nop,timestamp 3789337 3985798>
11:13:34.336423 IP A > B: . 479888:511216(31328) ack 1 win 457 <nop,nop,timestamp 3789337 3985798>
11:13:34.336924 IP A > B: . 512640:543968(31328) ack 1 win 457 <nop,nop,timestamp 3789337 3985798>
11:13:34.336963 IP A > B: . 543968:575296(31328) ack 1 win 457 <nop,nop,timestamp 3789337 3985798>
We must call skb_record_rx_queue() to properly give to RPS (and more
generally for TX queue selection on forward path) the receive queue
information.
Similar fix is needed for skb_mark_napi_id(), but will be handled
in a separate patch to ease stable backports.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Willem de Bruijn <willemb@google.com>
Cc: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
index 0c64122..6e46cff 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
@@ -681,6 +681,7 @@ static void bnx2x_gro_receive(struct bnx2x *bp, struct bnx2x_fastpath *fp,
}
}
#endif
+ skb_record_rx_queue(skb, fp->rx_queue);
napi_gro_receive(&fp->napi, skb);
}
^ permalink raw reply related
* [PATCH net-next] fib_trie: remove duplicated rcu lock
From: baker.kernel @ 2013-10-13 0:13 UTC (permalink / raw)
To: davem; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel,
baker.zhang
From: "baker.zhang" <baker.kernel@gmail.com>
fib_table_lookup has included the rcu lock protection.
Signed-off-by: baker.zhang <baker.kernel@gmail.com>
---
net/ipv4/fib_frontend.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index b3f627a..0e9127d 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -170,12 +170,10 @@ static inline unsigned int __inet_dev_addr_type(struct net *net,
local_table = fib_get_table(net, RT_TABLE_LOCAL);
if (local_table) {
ret = RTN_UNICAST;
- rcu_read_lock();
if (!fib_table_lookup(local_table, &fl4, &res, FIB_LOOKUP_NOREF)) {
if (!dev || dev == res.fi->fib_dev)
ret = res.type;
}
- rcu_read_unlock();
}
return ret;
}
@@ -933,7 +931,6 @@ static void nl_fib_lookup(struct fib_result_nl *frn, struct fib_table *tb)
local_bh_disable();
frn->tb_id = tb->tb_id;
- rcu_read_lock();
frn->err = fib_table_lookup(tb, &fl4, &res, FIB_LOOKUP_NOREF);
if (!frn->err) {
@@ -942,7 +939,6 @@ static void nl_fib_lookup(struct fib_result_nl *frn, struct fib_table *tb)
frn->type = res.type;
frn->scope = res.scope;
}
- rcu_read_unlock();
local_bh_enable();
}
}
--
1.8.1.2
^ permalink raw reply related
* [PATCH net-next] net: refactor sk_page_frag_refill()
From: Eric Dumazet @ 2013-10-13 0:25 UTC (permalink / raw)
To: Michael Dalton
Cc: Daniel Borkmann, davem, netdev, Francesco Fusco, ycheng,
Neal Cardwell, Eric Northup
In-Reply-To: <CANJ5vPJpVfDjaC8JauGYu=Qe4ZshqmBMkCbB1cru-xAfa7K1+g@mail.gmail.com>
From: Eric Dumazet <edumazet@google.com>
While working on virtio_net new allocation strategy to increase
payload/truesize ratio, we found that refactoring sk_page_frag_refill()
was needed.
This patch splits sk_page_frag_refill() into two parts, adding
page_frag_refill() which can be used without a socket.
While we are at it, add a minimum frag size of 32 for
sk_page_frag_refill()
Michael will either use netdev_alloc_frag() from softirq context,
or page_frag_refill() from process context in refill_work() (GFP_KERNEL
allocations)
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Michael Dalton <mwdalton@google.com>
---
include/linux/skbuff.h | 2 ++
net/core/sock.c | 27 +++++++++++++++++++++++----
2 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 1cd32f9..0c5d40f 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -2062,6 +2062,8 @@ static inline void skb_frag_set_page(struct sk_buff *skb, int f,
__skb_frag_set_page(&skb_shinfo(skb)->frags[f], page);
}
+bool page_frag_refill(unsigned int sz, struct page_frag *pfrag, gfp_t prio);
+
/**
* skb_frag_dma_map - maps a paged fragment via the DMA API
* @dev: the device to map the fragment to
diff --git a/net/core/sock.c b/net/core/sock.c
index fd6afa2..e87d624 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1847,7 +1847,17 @@ EXPORT_SYMBOL(sock_alloc_send_skb);
/* On 32bit arches, an skb frag is limited to 2^15 */
#define SKB_FRAG_PAGE_ORDER get_order(32768)
-bool sk_page_frag_refill(struct sock *sk, struct page_frag *pfrag)
+/**
+ * page_frag_refill - check that a page_frag contains enough room
+ * @sz: minimum size of the fragment we want to get
+ * @pfrag: pointer to page_frag
+ * @prio: priority for memory allocation
+ *
+ * Note: While this allocator tries to use high order pages, there is
+ * no guarantee that allocations succeed. Therefore, @sz MUST be
+ * less or equal than PAGE_SIZE.
+ */
+bool page_frag_refill(unsigned int sz, struct page_frag *pfrag, gfp_t prio)
{
int order;
@@ -1856,16 +1866,16 @@ bool sk_page_frag_refill(struct sock *sk, struct page_frag *pfrag)
pfrag->offset = 0;
return true;
}
- if (pfrag->offset < pfrag->size)
+ if (pfrag->offset + sz < pfrag->size)
return true;
put_page(pfrag->page);
}
/* We restrict high order allocations to users that can afford to wait */
- order = (sk->sk_allocation & __GFP_WAIT) ? SKB_FRAG_PAGE_ORDER : 0;
+ order = (prio & __GFP_WAIT) ? SKB_FRAG_PAGE_ORDER : 0;
do {
- gfp_t gfp = sk->sk_allocation;
+ gfp_t gfp = prio;
if (order)
gfp |= __GFP_COMP | __GFP_NOWARN;
@@ -1877,6 +1887,15 @@ bool sk_page_frag_refill(struct sock *sk, struct page_frag *pfrag)
}
} while (--order >= 0);
+ return false;
+}
+EXPORT_SYMBOL(page_frag_refill);
+
+bool sk_page_frag_refill(struct sock *sk, struct page_frag *pfrag)
+{
+ if (page_frag_refill(32U, pfrag, sk->sk_allocation))
+ return true;
+
sk_enter_memory_pressure(sk);
sk_stream_moderate_sndbuf(sk);
return false;
^ permalink raw reply related
* Re: [PATCH net-next] net: refactor sk_page_frag_refill()
From: Eric Dumazet @ 2013-10-13 0:55 UTC (permalink / raw)
To: Michael Dalton
Cc: Daniel Borkmann, davem, netdev, Francesco Fusco, ycheng,
Neal Cardwell, Eric Northup
In-Reply-To: <1381623952.3392.25.camel@edumazet-glaptop.roam.corp.google.com>
On Sat, 2013-10-12 at 17:25 -0700, Eric Dumazet wrote:
> - if (pfrag->offset < pfrag->size)
> + if (pfrag->offset + sz < pfrag->size)
> return true;
> put_page(pfrag->page);
This needs to be :
if (pfrag->offset + sz <= pfrag->size)
I'll send a v2
^ permalink raw reply
* Re: [PATCH net-next] fib_trie: remove duplicated rcu lock
From: Eric Dumazet @ 2013-10-13 3:58 UTC (permalink / raw)
To: baker.kernel
Cc: davem, kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <1381623217-5883-1-git-send-email-baker.kernel@gmail.com>
On Sun, 2013-10-13 at 08:13 +0800, baker.kernel@gmail.com wrote:
> From: "baker.zhang" <baker.kernel@gmail.com>
>
> fib_table_lookup has included the rcu lock protection.
>
> Signed-off-by: baker.zhang <baker.kernel@gmail.com>
> ---
> net/ipv4/fib_frontend.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
> index b3f627a..0e9127d 100644
> --- a/net/ipv4/fib_frontend.c
> +++ b/net/ipv4/fib_frontend.c
> @@ -170,12 +170,10 @@ static inline unsigned int __inet_dev_addr_type(struct net *net,
> local_table = fib_get_table(net, RT_TABLE_LOCAL);
> if (local_table) {
> ret = RTN_UNICAST;
> - rcu_read_lock();
> if (!fib_table_lookup(local_table, &fl4, &res, FIB_LOOKUP_NOREF)) {
> if (!dev || dev == res.fi->fib_dev)
> ret = res.type;
> }
> - rcu_read_unlock();
> }
This looks very wrong.
res.fi could disappear, and we crash.
^ permalink raw reply
* [PATCH v2 net-next] net: refactor sk_page_frag_refill()
From: Eric Dumazet @ 2013-10-13 4:46 UTC (permalink / raw)
To: Michael Dalton
Cc: Daniel Borkmann, davem, netdev, Francesco Fusco, ycheng,
Neal Cardwell, Eric Northup
In-Reply-To: <1381623952.3392.25.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <edumazet@google.com>
While working on virtio_net new allocation strategy to increase
payload/truesize ratio, we found that refactoring sk_page_frag_refill()
was needed.
This patch splits sk_page_frag_refill() into two parts, adding
page_frag_refill() which can be used without a socket.
While we are at it, add a minimum frag size of 32 for
sk_page_frag_refill()
Michael will either use netdev_alloc_frag() from softirq context,
or page_frag_refill() from process context in refill_work() (GFP_KERNEL
allocations)
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Michael Dalton <mwdalton@google.com>
---
v2: fix a off-by one error
include/linux/skbuff.h | 2 ++
net/core/sock.c | 27 +++++++++++++++++++++++----
2 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 1cd32f9..0c5d40f 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -2062,6 +2062,8 @@ static inline void skb_frag_set_page(struct sk_buff *skb, int f,
__skb_frag_set_page(&skb_shinfo(skb)->frags[f], page);
}
+bool page_frag_refill(unsigned int sz, struct page_frag *pfrag, gfp_t prio);
+
/**
* skb_frag_dma_map - maps a paged fragment via the DMA API
* @dev: the device to map the fragment to
diff --git a/net/core/sock.c b/net/core/sock.c
index fd6afa2..7824d60 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1847,7 +1847,17 @@ EXPORT_SYMBOL(sock_alloc_send_skb);
/* On 32bit arches, an skb frag is limited to 2^15 */
#define SKB_FRAG_PAGE_ORDER get_order(32768)
-bool sk_page_frag_refill(struct sock *sk, struct page_frag *pfrag)
+/**
+ * page_frag_refill - check that a page_frag contains enough room
+ * @sz: minimum size of the fragment we want to get
+ * @pfrag: pointer to page_frag
+ * @prio: priority for memory allocation
+ *
+ * Note: While this allocator tries to use high order pages, there is
+ * no guarantee that allocations succeed. Therefore, @sz MUST be
+ * less or equal than PAGE_SIZE.
+ */
+bool page_frag_refill(unsigned int sz, struct page_frag *pfrag, gfp_t prio)
{
int order;
@@ -1856,16 +1866,16 @@ bool sk_page_frag_refill(struct sock *sk, struct page_frag *pfrag)
pfrag->offset = 0;
return true;
}
- if (pfrag->offset < pfrag->size)
+ if (pfrag->offset + sz <= pfrag->size)
return true;
put_page(pfrag->page);
}
/* We restrict high order allocations to users that can afford to wait */
- order = (sk->sk_allocation & __GFP_WAIT) ? SKB_FRAG_PAGE_ORDER : 0;
+ order = (prio & __GFP_WAIT) ? SKB_FRAG_PAGE_ORDER : 0;
do {
- gfp_t gfp = sk->sk_allocation;
+ gfp_t gfp = prio;
if (order)
gfp |= __GFP_COMP | __GFP_NOWARN;
@@ -1877,6 +1887,15 @@ bool sk_page_frag_refill(struct sock *sk, struct page_frag *pfrag)
}
} while (--order >= 0);
+ return false;
+}
+EXPORT_SYMBOL(page_frag_refill);
+
+bool sk_page_frag_refill(struct sock *sk, struct page_frag *pfrag)
+{
+ if (likely(page_frag_refill(32U, pfrag, sk->sk_allocation)))
+ return true;
+
sk_enter_memory_pressure(sk);
sk_stream_moderate_sndbuf(sk);
return false;
^ permalink raw reply related
* RE: [PATCH 1/1] net: fix cipso packet validation when !NETLABEL
From: Seif Mazareeb @ 2013-10-13 5:21 UTC (permalink / raw)
To: Paul Moore
Cc: davem@davemloft.net, netdev@vger.kernel.org,
thomas.petazzoni@free-electrons.com, Dmitri Epshtein
In-Reply-To: <2291823.ee0I8c00DA@olly>
When CONFIG_NETLABEL is disabled, the cipso_v4_validate() function could loop
forever in the main loop if opt[opt_iter +1] == 0, this will causing a kernel
crash in an SMP system, since the CPU executing this function will
stall /not respond to IPIs.
This problem can be reproduced by running the IP Stack Integrity Checker
(http://isic.sourceforge.net) using the following command on a Linux machine
connected to DUT:
"icmpsic -s rand -d <DUT IP address> -r 123456"
wait (1-2 min)
Signed-off-by: Seif Mazareeb <seif@marvell.com>
---
include/net/cipso_ipv4.h | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/net/cipso_ipv4.h b/include/net/cipso_ipv4.h
index a7a683e..a8c2ef6 100644
--- a/include/net/cipso_ipv4.h
+++ b/include/net/cipso_ipv4.h
@@ -290,6 +290,7 @@ static inline int cipso_v4_validate(const struct sk_buff *skb,
unsigned char err_offset = 0;
u8 opt_len = opt[1];
u8 opt_iter;
+ u8 tag_len;
if (opt_len < 8) {
err_offset = 1;
@@ -302,11 +303,12 @@ static inline int cipso_v4_validate(const struct sk_buff *skb,
}
for (opt_iter = 6; opt_iter < opt_len;) {
- if (opt[opt_iter + 1] > (opt_len - opt_iter)) {
+ tag_len = opt[opt_iter + 1];
+ if ((tag_len == 0) || (opt[opt_iter + 1] > (opt_len - opt_iter))) {
err_offset = opt_iter + 1;
goto out;
}
- opt_iter += opt[opt_iter + 1];
+ opt_iter += tag_len;
}
out:
--
1.8.1.2
-----Original Message-----
From: Paul Moore [mailto:paul@paul-moore.com]
Sent: Saturday, October 12, 2013 4:57 AM
To: Seif Mazareeb
Cc: davem@davemloft.net; netdev@vger.kernel.org; thomas.petazzoni@free-electrons.com; Dmitri Epshtein
Subject: Re: [PATCH 1/1] net: fix cipso packet validation when !NETLABEL
On Friday, October 11, 2013 2:04:10 PM Seif Mazareeb wrote:
> When CONFIG_NETLABEL is disabled, the cipso_v4_validate() function
> could loop forever in the main loop if opt[opt_iter +1] == 0, this
> will causing a kernel crash in an SMP system, since the CPU executing
> this function will stall /not respond to IPIs.
>
> This problem can be reproduced by running the IP Stack Integrity
> Checker
> (http://isic.sourceforge.net) using the following command on a Linux
> machine connected to DUT:
>
> "icmpsic -s rand -d <DUT IP address> -r 123456"
> wait (1-2 min)
>
> Signed-off-by: Seif Mazareeb <seif@marvell.com>
> ---
> include/net/cipso_ipv4.h | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/include/net/cipso_ipv4.h b/include/net/cipso_ipv4.h index
> a7a683e..286b7da 100644
> --- a/include/net/cipso_ipv4.h
> +++ b/include/net/cipso_ipv4.h
> @@ -290,6 +290,7 @@ static inline int cipso_v4_validate(const struct
> sk_buff *skb, unsigned char err_offset = 0;
> u8 opt_len = opt[1];
> u8 opt_iter;
> + u8 tag_len;
>
> if (opt_len < 8) {
> err_offset = 1;
> @@ -302,7 +303,8 @@ static inline int cipso_v4_validate(const struct
> sk_buff *skb, }
>
> for (opt_iter = 6; opt_iter < opt_len;) {
> - if (opt[opt_iter + 1] > (opt_len - opt_iter)) {
> + tag_len = opt[opt_iter + 1];
> + if ((tag_len == 0) || (opt[opt_iter + 1] > (opt_len -
> opt_iter))) { err_offset = opt_iter + 1;
> goto out;
> }
You should also use 'tag_len' inside the for-loop, and after the if-block, where we increment 'opt_iter'. See my original reply for an example.
--
paul moore
www.paul-moore.com
^ permalink raw reply related
* [PATCH] isdn: remove deprecated IRQF_DISABLED
From: Michael Opdenacker @ 2013-10-13 5:24 UTC (permalink / raw)
To: mac, isdn; +Cc: netdev, linux-kernel, davem, Michael Opdenacker
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
---
drivers/isdn/hardware/eicon/divasmain.c | 2 +-
drivers/isdn/sc/init.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/isdn/hardware/eicon/divasmain.c b/drivers/isdn/hardware/eicon/divasmain.c
index 52377b4..a2e0ed6 100644
--- a/drivers/isdn/hardware/eicon/divasmain.c
+++ b/drivers/isdn/hardware/eicon/divasmain.c
@@ -481,7 +481,7 @@ void __inline__ outpp(void __iomem *addr, word p)
int diva_os_register_irq(void *context, byte irq, const char *name)
{
int result = request_irq(irq, diva_os_irq_wrapper,
- IRQF_DISABLED | IRQF_SHARED, name, context);
+ IRQF_SHARED, name, context);
return (result);
}
diff --git a/drivers/isdn/sc/init.c b/drivers/isdn/sc/init.c
index ca997bd..92acc81 100644
--- a/drivers/isdn/sc/init.c
+++ b/drivers/isdn/sc/init.c
@@ -336,7 +336,7 @@ static int __init sc_init(void)
*/
sc_adapter[cinst]->interrupt = irq[b];
if (request_irq(sc_adapter[cinst]->interrupt, interrupt_handler,
- IRQF_DISABLED, interface->id,
+ 0, interface->id,
(void *)(unsigned long) cinst))
{
kfree(sc_adapter[cinst]->channel);
--
1.8.1.2
^ permalink raw reply related
* RE: [PATCH] bnx2x: record rx queue for LRO packets
From: Dmitry Kravkov @ 2013-10-13 6:23 UTC (permalink / raw)
To: Eric Dumazet, David Miller; +Cc: netdev, Eilon Greenstein, Willem de Bruijn
In-Reply-To: <1381612114.3392.14.camel@edumazet-glaptop.roam.corp.google.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Eric Dumazet
> Sent: Sunday, October 13, 2013 12:09 AM
> To: David Miller
> Cc: netdev; Eilon Greenstein; Willem de Bruijn
> Subject: [PATCH] bnx2x: record rx queue for LRO packets
>
> From: Eric Dumazet <edumazet@google.com>
>
> RPS support is kind of broken on bnx2x, because only non LRO packets get
> proper rx queue information. This triggers reorders, as it seems bnx2x like to
> generate a non LRO packet for segment including TCP PUSH flag : (this might
> be pure coincidence, but all the reorders I've seen involve segments with a
> PUSH)
>
> 11:13:34.335847 IP A > B: . 415808:447136(31328) ack 1 win 457
> <nop,nop,timestamp 3789336 3985797>
> 11:13:34.335992 IP A > B: . 447136:448560(1424) ack 1 win 457
> <nop,nop,timestamp 3789336 3985797>
> 11:13:34.336391 IP A > B: . 448560:479888(31328) ack 1 win 457
> <nop,nop,timestamp 3789337 3985797>
> 11:13:34.336425 IP A > B: P 511216:512640(1424) ack 1 win 457
> <nop,nop,timestamp 3789337 3985798>
> 11:13:34.336423 IP A > B: . 479888:511216(31328) ack 1 win 457
> <nop,nop,timestamp 3789337 3985798>
> 11:13:34.336924 IP A > B: . 512640:543968(31328) ack 1 win 457
> <nop,nop,timestamp 3789337 3985798>
> 11:13:34.336963 IP A > B: . 543968:575296(31328) ack 1 win 457
> <nop,nop,timestamp 3789337 3985798>
>
> We must call skb_record_rx_queue() to properly give to RPS (and more
> generally for TX queue selection on forward path) the receive queue
> information.
>
> Similar fix is needed for skb_mark_napi_id(), but will be handled in a
> separate patch to ease stable backports.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Willem de Bruijn <willemb@google.com>
> Cc: Eilon Greenstein <eilong@broadcom.com>
> ---
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 1 +
> 1 file changed, 1 insertion(+)
Thanks!
Acked-by: Dmitry Kravkov <dmitry@broadcom.com>
^ permalink raw reply
* [PATCH] irda: update comment mentioning IRQF_DISABLED
From: Michael Opdenacker @ 2013-10-13 6:26 UTC (permalink / raw)
To: samuel, davem; +Cc: netdev, linux-kernel, Michael Opdenacker
This patch removes a comment mentioning IRQF_DISABLED,
which is deprecated.
Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
---
include/net/irda/irda_device.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/net/irda/irda_device.h b/include/net/irda/irda_device.h
index 94c852d..1141747 100644
--- a/include/net/irda/irda_device.h
+++ b/include/net/irda/irda_device.h
@@ -162,7 +162,7 @@ typedef struct {
int irq, irq2; /* Interrupts used */
int dma, dma2; /* DMA channel(s) used */
int fifo_size; /* FIFO size */
- int irqflags; /* interrupt flags (ie, IRQF_SHARED|IRQF_DISABLED) */
+ int irqflags; /* interrupt flags (ie, IRQF_SHARED) */
int direction; /* Link direction, used by some FIR drivers */
int enabled; /* Powered on? */
int suspended; /* Suspended by APM */
--
1.8.1.2
^ permalink raw reply related
* Re: [Patch 1/1]: libertas/sdio: fix releasing memory twice.
From: Dr. H. Nikolaus Schaller @ 2013-10-13 7:09 UTC (permalink / raw)
To: Dan Williams
Cc: John W. Linville, Bing Zhao, Harro Haan, libertas-dev,
linux-wireless, netdev, LKML, Belisko Marek, NeilBrown Brown
In-Reply-To: <1381607911.21655.7.camel@dcbw.foobar.com>
Hi Dan,
Am 12.10.2013 um 21:58 schrieb Dan Williams:
> On Sat, 2013-10-12 at 18:02 +0200, Dr. H. Nikolaus Schaller wrote:
>> While upgrading the GTA04 kernel to 3.12-rc4 we came across
>> an issue with libertas/sdio referencing stale memory on ifconfig up
>> when trying to load the firmware (for a second time).
>>
>> I am not at all sure if the patch is how it should be done and the right
>> location, but it appears to work for us with resetting priv->helper_fw to NULL
>> before asynchronously loading the firmware again.
>
> How about we go even simpler? helper_fw is *only* used inside
> firmware.c anyway, and that's probably where its lifetime should be
> handled. Same for the main firmware. I have no idea why the bus code
> is responsible for releasing the firmware anyway, when it originates
> from firmware.c and control returns back there after the firmware loaded
> callback is done. Does the following patch fix your problem too?
Yes, it works!
I think your approach is much better from software architecture point
of view than our hack.
Thank you,
Nikolaus
>
> Dan
>
> ---
> diff --git a/drivers/net/wireless/libertas/firmware.c b/drivers/net/wireless/libertas/firmware.c
> index c0f9e7e..51b92b5 100644
> --- a/drivers/net/wireless/libertas/firmware.c
> +++ b/drivers/net/wireless/libertas/firmware.c
> @@ -49,14 +49,19 @@ static void main_firmware_cb(const struct firmware *firmware, void *context)
> /* Failed to find firmware: try next table entry */
> load_next_firmware_from_table(priv);
> return;
> }
>
> /* Firmware found! */
> lbs_fw_loaded(priv, 0, priv->helper_fw, firmware);
> + if (priv->helper_fw) {
> + release_firmware (priv->helper_fw);
> + priv->helper_fw = NULL;
> + }
> + release_firmware (firmware);
> }
>
> static void helper_firmware_cb(const struct firmware *firmware, void *context)
> {
> struct lbs_private *priv = context;
>
> if (!firmware) {
> diff --git a/drivers/net/wireless/libertas/if_cs.c b/drivers/net/wireless/libertas/if_cs.c
> index c94dd68..ef8c98e 100644
> --- a/drivers/net/wireless/libertas/if_cs.c
> +++ b/drivers/net/wireless/libertas/if_cs.c
> @@ -750,22 +750,22 @@ static void if_cs_prog_firmware(struct lbs_private *priv, int ret,
> }
>
> /* Load the firmware */
> ret = if_cs_prog_helper(card, helper);
> if (ret == 0 && (card->model != MODEL_8305))
> ret = if_cs_prog_real(card, mainfw);
> if (ret)
> - goto out;
> + return;
>
> /* Now actually get the IRQ */
> ret = request_irq(card->p_dev->irq, if_cs_interrupt,
> IRQF_SHARED, DRV_NAME, card);
> if (ret) {
> pr_err("error in request_irq\n");
> - goto out;
> + return;
> }
>
> /*
> * Clear any interrupt cause that happened while sending
> * firmware/initializing card
> */
> if_cs_write16(card, IF_CS_CARD_INT_CAUSE, IF_CS_BIT_MASK);
> @@ -773,18 +773,14 @@ static void if_cs_prog_firmware(struct lbs_private *priv, int ret,
>
> /* And finally bring the card up */
> priv->fw_ready = 1;
> if (lbs_start_card(priv) != 0) {
> pr_err("could not activate card\n");
> free_irq(card->p_dev->irq, card);
> }
> -
> -out:
> - release_firmware(helper);
> - release_firmware(mainfw);
> }
>
>
> /********************************************************************/
> /* Callback functions for libertas.ko */
> /********************************************************************/
>
> diff --git a/drivers/net/wireless/libertas/if_sdio.c b/drivers/net/wireless/libertas/if_sdio.c
> index 4557833..991238a 100644
> --- a/drivers/net/wireless/libertas/if_sdio.c
> +++ b/drivers/net/wireless/libertas/if_sdio.c
> @@ -704,28 +704,24 @@ static void if_sdio_do_prog_firmware(struct lbs_private *priv, int ret,
> if (ret) {
> pr_err("failed to find firmware (%d)\n", ret);
> return;
> }
>
> ret = if_sdio_prog_helper(card, helper);
> if (ret)
> - goto out;
> + return;
>
> lbs_deb_sdio("Helper firmware loaded\n");
>
> ret = if_sdio_prog_real(card, mainfw);
> if (ret)
> - goto out;
> + return;
>
> lbs_deb_sdio("Firmware loaded\n");
> if_sdio_finish_power_on(card);
> -
> -out:
> - release_firmware(helper);
> - release_firmware(mainfw);
> }
>
> static int if_sdio_prog_firmware(struct if_sdio_card *card)
> {
> int ret;
> u16 scratch;
>
> diff --git a/drivers/net/wireless/libertas/if_spi.c b/drivers/net/wireless/libertas/if_spi.c
> index 4bb6574..87ff0ca 100644
> --- a/drivers/net/wireless/libertas/if_spi.c
> +++ b/drivers/net/wireless/libertas/if_spi.c
> @@ -1090,19 +1090,15 @@ static int if_spi_init_card(struct if_spi_card *card)
> }
>
> err = spu_set_interrupt_mode(card, 0, 1);
> if (err)
> goto out;
>
> out:
> - release_firmware(helper);
> - release_firmware(mainfw);
> -
> lbs_deb_leave_args(LBS_DEB_SPI, "err %d\n", err);
> -
> return err;
> }
>
> static void if_spi_resume_worker(struct work_struct *work)
> {
> struct if_spi_card *card;
>
> diff --git a/drivers/net/wireless/libertas/if_usb.c b/drivers/net/wireless/libertas/if_usb.c
> index 2798077..dff08a2 100644
> --- a/drivers/net/wireless/libertas/if_usb.c
> +++ b/drivers/net/wireless/libertas/if_usb.c
> @@ -840,15 +840,15 @@ static void if_usb_prog_firmware(struct lbs_private *priv, int ret,
> pr_err("failed to find firmware (%d)\n", ret);
> goto done;
> }
>
> cardp->fw = fw;
> if (check_fwfile_format(cardp->fw->data, cardp->fw->size)) {
> ret = -EINVAL;
> - goto release_fw;
> + goto done;
> }
>
> /* Cancel any pending usb business */
> usb_kill_urb(cardp->rx_urb);
> usb_kill_urb(cardp->tx_urb);
>
> cardp->fwlastblksent = 0;
> @@ -857,15 +857,15 @@ static void if_usb_prog_firmware(struct lbs_private *priv, int ret,
> cardp->fwfinalblk = 0;
> cardp->bootcmdresp = 0;
>
> restart:
> if (if_usb_submit_rx_urb_fwload(cardp) < 0) {
> lbs_deb_usbd(&cardp->udev->dev, "URB submission is failed\n");
> ret = -EIO;
> - goto release_fw;
> + goto done;
> }
>
> cardp->bootcmdresp = 0;
> do {
> int j = 0;
> i++;
> if_usb_issue_boot_command(cardp, BOOT_CMD_FW_BY_USB);
> @@ -879,22 +879,22 @@ restart:
> if (cardp->bootcmdresp == BOOT_CMD_RESP_NOT_SUPPORTED) {
> /* Return to normal operation */
> ret = -EOPNOTSUPP;
> usb_kill_urb(cardp->rx_urb);
> usb_kill_urb(cardp->tx_urb);
> if (if_usb_submit_rx_urb(cardp) < 0)
> ret = -EIO;
> - goto release_fw;
> + goto done;
> } else if (cardp->bootcmdresp <= 0) {
> if (--reset_count >= 0) {
> if_usb_reset_device(cardp);
> goto restart;
> }
> ret = -EIO;
> - goto release_fw;
> + goto done;
> }
>
> i = 0;
>
> cardp->totalbytes = 0;
> cardp->fwlastblksent = 0;
> cardp->CRC_OK = 1;
> @@ -917,37 +917,34 @@ restart:
> if (--reset_count >= 0) {
> if_usb_reset_device(cardp);
> goto restart;
> }
>
> pr_info("FW download failure, time = %d ms\n", i * 100);
> ret = -EIO;
> - goto release_fw;
> + goto done;
> }
>
> cardp->priv->fw_ready = 1;
> if_usb_submit_rx_urb(cardp);
>
> if (lbs_start_card(priv))
> - goto release_fw;
> + goto done;
>
> if_usb_setup_firmware(priv);
>
> /*
> * EHS_REMOVE_WAKEUP is not supported on all versions of the firmware.
> */
> priv->wol_criteria = EHS_REMOVE_WAKEUP;
> if (lbs_host_sleep_cfg(priv, priv->wol_criteria, NULL))
> priv->ehs_remove_supported = false;
>
> - release_fw:
> - release_firmware(cardp->fw);
> - cardp->fw = NULL;
> -
> done:
> + cardp->fw = NULL;
> lbs_deb_leave(LBS_DEB_USB);
> }
>
>
> #ifdef CONFIG_PM
> static int if_usb_suspend(struct usb_interface *intf, pm_message_t message)
> {
>
>
^ permalink raw reply
* DaVinci Emac Driver Fails to wake up on suspending to RAM
From: Prabhakar Lad @ 2013-10-13 7:28 UTC (permalink / raw)
To: dlos, Mugunthan V N, netdev
Hi,
While testing the suspend to RAM on OMAP-L138, I see a issue while waking up
the request irq fails with following log.
Linux version is Linux version 3.12.0-rc2
root@da850-omapl138-evm:~# rtcwake -d /dev/rtc0 -s 20 -m mem
wakeup from "mem" at Sat Jan 1 00:01:47 2000
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.001 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
Suspending console(s) (use no_console_suspend to debug)
PM: suspend of devices complete after 8.693 msecs
PM: suspend devices took 0.010 seconds
PM: late suspend of devices complete after 3.096 msecs
PM: noirq suspend of devices complete after 2.989 msecs
PM: noirq resume of devices complete after 2.396 msecs
PM: early resume of devices complete after 2.851 msecs
genirq: Flags mismatch irq 33. 00000000 (eth0) vs. 00000000 (eth0)
net eth0: DaVinci EMAC: devm_request_irq() failed
PM: resume of devices complete after 15.857 msecs
PM: resume devices took 0.020 seconds
Restarting tasks ... done.
nfs: server 169.254.80.251 not responding, still trying
nfs: server 169.254.80.251 not responding, still trying
--
Regards,
--Prabhakar Lad
^ permalink raw reply
* Re: IPv6 path MTU discovery broken
From: Steinar H. Gunderson @ 2013-10-13 10:40 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: netdev, edumazet, fan.du
In-Reply-To: <20131007030910.GG9295@order.stressinduktion.org>
[resending with proper quoting and cc]
On Mon, Oct 07, 2013 at 05:09:10AM +0200, Hannes Frederic Sowa wrote:
> Could you try to check (with e.g. nstat) if any of the following counters
> change if the icmp messages hit the host?
>
> TcpExtOutOfWindowIcmps
> Icmp6InErrors
> TcpExtTCPMinTTLDrop
> TcpExtListenDrops
Hi,
I am now seeing the same problem against a 3.9.0 machine (that I've never had
problems with before). I looked through the four nstat counters, and none of
them are increasing. Here's /proc/net/ipv6_route from the server while it's
going on; the client is 2001:67c:a4:1:71f9:c84b:8b2a:c65b (second line) and
the server is 2001:67c:29f4::2007.
20010500002e00000000000000000001 80 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000000 00000000 00000001 01000003 eth0.10
2001067c00a4000171f9c84b8b2ac65b 80 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000000 00000003 000005fb 01000023 eth0.10
2001067c2804100100000000c21f2797 80 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000000 00000000 00000001 01000003 eth0.10
2001067c29f400000000000000000021 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000002 00000723 01000001 eth0.10
2001067c29f400000000000000000022 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 0000003c 01000001 eth0.10
2001067c29f400000000000000000029 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 0000000c 025f8b9d 01000001 eth0.10
2001067c29f400000000000000000031 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 000000c5 01000001 eth0.10
2001067c29f400000000000000000052 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000040 01000001 eth0.10
2001067c29f400000000000000000056 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 00001a37 01000001 eth0.10
2001067c29f400000000000000000065 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000041 01000001 eth0.10
2001067c29f400000000000000000070 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 000073fb 01000001 eth0.10
2001067c29f400000000000000000072 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000002 01000001 eth0.10
2001067c29f400000000000000000086 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 0000244b 01000001 eth0.10
2001067c29f400000000000000002010 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000020 01000001 eth0.10
2001067c29f400000000000000002012 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 000001d6 01000001 eth0.10
2001067c29f400000000000000003001 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 0000005f 01000001 eth0.10
2001067c29f400000000000000005001 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000001 01000001 eth0.10
2001067c29f400000000000000005015 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000016 01000001 eth0.10
2001067c29f400000000000000005201 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 0000509f 01000001 eth0.10
2001067c29f400000000000000005205 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 00039f0b 01000001 eth0.10
2001067c29f400000000000000000000 40 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000001 00000001 eth0.10
200107000300146281ec7e498c3e8d5e 80 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000000 00000000 00000002 01000003 eth0.10
200141d0006000000000000000000012 80 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000000 00000000 00000001 01000003 eth0.10
20014600000400110000000000000005 80 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000000 00000000 00000003 01000003 eth0.10
20014600000410120000000000000005 80 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000000 00000000 00000002 01000003 eth0.10
20014600000410120000000000000006 80 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000000 00000000 00000001 01000003 eth0.10
20014600000410120000000000000007 80 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000000 00000000 00000002 01000003 eth0.10
20014801000d00000000000000530001 80 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000000 00000000 00000002 01000003 eth0.10
2406da00ff0000000000000036d3b443 80 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000000 00000000 00000002 01000003 eth0.10
2406da00ff0000000000000036e313b8 80 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000000 00000000 00000002 01000003 eth0.10
26003c03000000000000000000000003 80 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000000 00000000 00000001 01000003 eth0.10
2607f8b040020c010000000000000154 80 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000000 00000000 00000001 01000003 eth0.10
2a001450400b0c010000000000000154 80 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000000 00000000 00000001 01000003 eth0.10
2a00145040130c00000000000000005f 80 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000000 00000000 00000002 01000003 eth0.10
2a0103b0000100fa000000000000000f 80 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000000 00000000 00000001 01000003 eth0.10
2a020fe0000100020001000000010110 80 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000000 00000000 00000003 01000003 eth0.10
2a028070000002010082021200620039 80 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000000 00000000 00000001 01000003 eth0.10
fe800000000000000000000000000000 40 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 eth0
fe800000000000000000000000000000 40 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 eth0.10
fe800000000000000000000000000000 40 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 eth0.4
00000000000000000000000000000000 00 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000400 00000000 00000000 00000003 eth0.10
00000000000000000000000000000000 00 00000000000000000000000000000000 00 00000000000000000000000000000000 ffffffff 00000001 0a896d3b 00200200 lo
00000000000000000000000000000001 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000002 3348a5ad 80200001 lo
2001067c29f400000000000000000028 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 01afbbc1 80200001 lo
2001067c29f400000000000000000030 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000020 29f1bc63 80200001 lo
2001067c29f400000000000000000049 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 03174149 80200001 lo
2001067c29f400000000000000002001 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 000b20f8 80200001 lo
2001067c29f400000000000000002002 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 0003c38f 80200001 lo
2001067c29f400000000000000002003 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 000bf060 80200001 lo
2001067c29f400000000000000002004 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 0000e383 80200001 lo
2001067c29f400000000000000002005 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 00058cae 80200001 lo
2001067c29f400000000000000002006 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 000082f7 80200001 lo
2001067c29f400000000000000002007 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000003 001a353e 80200001 lo
fe80000000000000022590fffec352c8 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 00000000 80200001 lo
fe80000000000000022590fffec352c8 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 0020538d 80200001 lo
fe80000000000000022590fffec352c8 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 00000000 80200001 lo
ff020000000000000000000000000001 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000003 01000001 eth0.10
ff020000000000000000000000000002 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000001 01000001 eth0.10
ff02000000000000000000000000000d 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000003 01000001 eth0.10
ff020000000000000000000000010003 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 0000000e 01000001 eth0.10
ff0200000000000000000001ff000030 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000002 01000001 eth0.10
ff0200000000000000000001ff000031 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000002 01000001 eth0.10
ff0200000000000000000001ff003005 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000003 01000001 eth0.10
ff0200000000000000000001ff006001 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000001 01000001 eth0.10
ff0200000000000000000001ff2c2de5 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000001 01000001 eth0.10
ff0200000000000000000001ff4793da 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000001 01000001 eth0.10
ff0200000000000000000001ff555743 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000001 01000001 eth0.10
ff0200000000000000000001ff5945c2 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000007 01000001 eth0.10
ff0200000000000000000001ffdae370 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000002 01000001 eth0.10
ff000000000000000000000000000000 08 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 eth0
ff000000000000000000000000000000 08 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 eth0.10
ff000000000000000000000000000000 08 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 eth0.4
00000000000000000000000000000000 00 00000000000000000000000000000000 00 00000000000000000000000000000000 ffffffff 00000001 0a896d3b 00200200 lo
/* Steinar */
--
Homepage: http://www.sesse.net/
^ 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