* Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
From: Mark Lord @ 2013-10-09 1:55 UTC (permalink / raw)
To: Alexander Gordeev, linux-kernel
Cc: Bjorn Helgaas, Ralf Baechle, Michael Ellerman,
Benjamin Herrenschmidt, Martin Schwidefsky, Ingo Molnar,
Tejun Heo, Dan Williams, Andy King, Jon Mason, Matt Porter,
linux-pci, linux-mips, linuxppc-dev, linux390, linux-s390, x86,
linux-ide, iss_storagedev, linux-nvme, linux-rdma, netdev,
e1000-devel, linux-driver, Solarflare linux maintainers, VMware,
"Inc." <pv-drive
In-Reply-To: <cover.1380703262.git.agordeev@redhat.com>
On 13-10-02 06:29 AM, Alexander Gordeev wrote:
..
> This update converts pci_enable_msix() and pci_enable_msi_block()
> interfaces to canonical kernel functions and makes them return a
> error code in case of failure or 0 in case of success.
Rather than silently break dozens of drivers in mysterious ways,
please invent new function names for the replacements to the
existing pci_enable_msix() and pci_enable_msi_block() functions.
That way, both in-tree and out-of-tree drivers will notice the API change,
rather than having it go unseen and just failing for unknown reasons.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 net] pkt_sched: fq: fix non TCP flows pacing
From: David Miller @ 2013-10-09 1:54 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, sesse
In-Reply-To: <1381270560.12191.64.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 08 Oct 2013 15:16:00 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> Steinar reported FQ pacing was not working for UDP flows.
>
> It looks like the initial sk->sk_pacing_rate value of 0 was
> a wrong choice. We should init it to ~0U (unlimited)
>
> Then, TCA_FQ_FLOW_DEFAULT_RATE should be removed because it makes
> no real sense. The default rate is really unlimited, and we
> need to avoid a zero divide.
>
> Reported-by: Steinar H. Gunderson <sesse@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
> I removed the ACCESS_ONCE() stuff, as it adds conflicts for
> next (net / net-next) merge. I'll send a separate patch later.
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] veth: Showing peer of veth type dev in ip link (kernel side)
From: David Miller @ 2013-10-09 1:52 UTC (permalink / raw)
To: stephen; +Cc: yamato, netdev
In-Reply-To: <20131008141337.1a8a556c@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Tue, 8 Oct 2013 14:13:37 -0700
> Please revert this. It is incorrect.
Ok, done.
^ permalink raw reply
* Re: [PATCH v2 6/6] ipv6: Do route updating for redirect in ndisc layer
From: Hannes Frederic Sowa @ 2013-10-09 1:43 UTC (permalink / raw)
To: Duan Jiong, David Miller, netdev
In-Reply-To: <20130918041337.GD8947@order.stressinduktion.org>
Hi Duan!
On Wed, Sep 18, 2013 at 06:13:37AM +0200, Hannes Frederic Sowa wrote:
> Especially because redirects also help in the on-link determination (same
> RFC, section 8), I changed my mind and am still in favour of updating it
> in the ndisc layer. In my opinion we just have to consider all routing
> tables and apply the update to every one which carries a valid next hop
> to the source of the redirect (under consideration of the destination).
>
> This will be important if we actually try to get linux to correctly
> implement the ipv6 subnet model (RFC 5942, Section 4 Rule 1). In that
> case we are not allowed to assume nodes on-link even if they would match
> the same prefix as a locally configured address.
I am playing around with a simple patch which does suppress adding routing
information for the on-link assumption we currently do in linux.
Are you intereseted in following up on this? I still do think we should update
not only the routing table the socket uses but all routing tables which have a
valid route towards the router which emitted the redirect.
I try to check if we actually handle redirect messages when ECMP routes are in
use correctly.
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCHv1 net] xen-netback: transition to CLOSED when removing a VIF
From: David Miller @ 2013-10-09 1:34 UTC (permalink / raw)
To: david.vrabel
Cc: xen-devel, konrad.wilk, boris.ostrovsky, netdev, ian.campbell,
wei.liu2, Paul.Durrant
In-Reply-To: <1381150519-14557-1-git-send-email-david.vrabel@citrix.com>
From: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 7 Oct 2013 13:55:19 +0100
> From: David Vrabel <david.vrabel@citrix.com>
>
> If a guest is destroyed without transitioning its frontend to CLOSED,
> the domain becomes a zombie as netback was not grant unmapping the
> shared rings.
>
> When removing a VIF, transition the backend to CLOSED so the VIF is
> disconnected if necessary (which will unmap the shared rings etc).
>
> This fixes a regression introduced by
> 279f438e36c0a70b23b86d2090aeec50155034a9 (xen-netback: Don't destroy
> the netdev until the vif is shut down).
>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
From: Michael Ellerman @ 2013-10-09 1:34 UTC (permalink / raw)
To: Alexander Gordeev
Cc: linux-kernel, Bjorn Helgaas, Ralf Baechle, Benjamin Herrenschmidt,
Martin Schwidefsky, Ingo Molnar, Tejun Heo, Dan Williams,
Andy King, Jon Mason, Matt Porter, linux-pci, linux-mips,
linuxppc-dev, linux390, linux-s390, x86, linux-ide,
iss_storagedev, linux-nvme, linux-rdma, netdev, e1000-devel,
linux-driver, Solarflare linux maintainers, VMware, Inc.,
linux-scsi
In-Reply-To: <20131008073301.GC10669@dhcp-26-207.brq.redhat.com>
On Tue, Oct 08, 2013 at 09:33:02AM +0200, Alexander Gordeev wrote:
> On Tue, Oct 08, 2013 at 03:33:30PM +1100, Michael Ellerman wrote:
> > On Wed, Oct 02, 2013 at 12:29:04PM +0200, Alexander Gordeev wrote:
> > > This technique proved to be confusing and error-prone. Vast share
> > > of device drivers simply fail to follow the described guidelines.
> >
> > To clarify "Vast share of device drivers":
> >
> > - 58 drivers call pci_enable_msix()
> > - 24 try a single allocation and then fallback to MSI/LSI
> > - 19 use the loop style allocation as above
> > - 14 try an allocation, and if it fails retry once
> > - 1 incorrectly continues when pci_enable_msix() returns > 0
> >
> > So 33 drivers (> 50%) successfully make use of the "confusing and
> > error-prone" return value.
>
> Ok, you caught me - 'vast share' is incorrect and is a subject to
> rewording. But out of 19/58 how many drivers tested fallbacks on the
> real hardware? IOW, which drivers are affected by the pSeries quota?
It's not 19/58, it's 33/58.
As to how many we care about on powerpc I can't say, so you have a point
there. But I still think the interface is not actually that terrible.
cheers
^ permalink raw reply
* [PATCH] rtlwifi: Add new firmware files for rtl8188eu
From: Larry Finger @ 2013-10-08 23:28 UTC (permalink / raw)
To: dwmw2, Ben Hutchings; +Cc: Larry Finger, netdev
The vendor driver RTL8188EUS_linux_v4.1.4_6773.20130222 contains
firmware in the form of data statements. This info has been extracted
into a binary file.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
WHENCE | 9 +++++++++
rtlwifi/rtl8188eufw.bin | Bin 0 -> 13904 bytes
2 files changed, 9 insertions(+)
create mode 100644 rtlwifi/rtl8188eufw.bin
diff --git a/WHENCE b/WHENCE
index 27865b6..ee963a0 100644
--- a/WHENCE
+++ b/WHENCE
@@ -1893,6 +1893,15 @@ Licence: Redistributable. See
LICENCE.rtlwifi_firmware.txt for details.
--------------------------------------------------------------------------
+Driver: rtl8188eu - Realtek 802.11n WLAN driver for RTL8188EU
+
+Info: Taken from Realtek version RTL8188EUS_linux_v4.1.4_6773.20130222
+File: rtlwifi/rtl8188eufw.bin
+
+Licence: Redistributable. See LICENCE.rtlwifi_firmware.txt for details.
+
+--------------------------------------------------------------------------
+
Driver: r8169 - RealTek 8169/8168/8101 ethernet driver.
File: rtl_nic/rtl8168d-1.fw
diff --git a/rtlwifi/rtl8188eufw.bin b/rtlwifi/rtl8188eufw.bin
new file mode 100644
index
0000000000000000000000000000000000000000..4ae7e1c5deb7846e59c461546a49679504ffed28
GIT binary patch
literal 13904
zcmeHud2|%Vx$ksO&mtkTv{-#@BZgs*(1^ug2ZI0s#%7UB3p?HzJ9vQ@GniI9#DVD+
zFAiR=X$6v#dy{KB8OQO4^|(*IFE?J0Eu3IG!NNE>j^7Cs!;J8PG|iX+fi%<a_f^kG
z2s_C==l=8lcsi%2wy&zb`s%B1tJ3kErH&yE!6A$-n;5vt;i&XD2K|YPR}Lzp@YbeF
zYyN)u7oB#yxaQp72mJr7|L;-Y?G`ONU0x{tpkqj5hxbMH_7jQ6{P(6GOFS`iYx;=~
zpE%`zw5RiRr>I)(Kh|4o95siwN?~n8r#Cd@?Uv5KacAwQvmds2|I+pO;~l<4ku}b*
z_mp_O`z0yj2<x4Jc*>C|YJa+}!d0a19ADJanR!n4cD_>dCJp(=o=-OhnYXizX=f8f
zN1m>km?)z8a?P1hoqy~}=o^FX4t92wmPX^wgJ*{qX-5)8G*3h#6qvI#Rupjrj(Y+p
zq=;8JqkR8&AGRpkLXR)J^Eq902HlqTyVkMZh!hWNXT4{=$1a5R?*@#;M^#~W8;j#x
z^r+DISg`Sltsg$|VT;e1JhI1G<BV87Rj;b*>8wbc!9=wIEcBJ4ZY*YOvAT0wPv?1W
z=P168OxOBgLBYw<qt6u-XkU&Pp?%Vg#YisQrBlX7(B97T-LDpjFX*G(?oQre^yrfX
z1?NU<UtX#GCF$SU(<${Nt0bVc`>Z!vwfk(u;p;~vN$c$la72_RfJma~RZpS16WFD7
zap8)(Y3ifM?<cB)Z0D(^x3llF`-9%+T_?|8F<LwGyz@EN80vNc19Rxis7Hhnf_zT!
zJ|a<*__E%GE<+2RcXgiA&QR6SNA<5DLS#?40!;ic{$UKn2K8e?iMVk2E;DXrX>+um
zw_gaH8yfL;28UFh4F>9_X`aAoch}kA`0b)MV3uNt(v#zg1F<4>mo%A|%av0ru{NwH
z;`JtLcYy3`_+GBEeD9b&Q8vj$l4u&<6cUH;U~^1g@>Z++mTcFzGN*3t^CfSvy06c6
zEz6v`uFuE%qAU|-*(kGou|97s<Bes#G30x_vGd;81#j&A9^a{yw=3oCPI;3l-?QVJ
z(oG3-){gWJAM1^>3sH97_k|h#+>Cx^`Z{)WH1))Hhh*?fXlOLLy9b$c)6O07EvmTt
zzF;yMjcUil#ZQO}{~F&N1!%O!c~%or-eYI9$yB3w{6z=bXB<#UYAX)zsFBXB(S#*u
zkHxhif+%@QD{3@j@!|M(VR!KLsHMygBnp%<S#%5v#UChb<5}?en%|&!fyTmj@SUcE
z@4d6*J+nV|?6adMwKp9LnhNk0;v4DsR_r$a9k;LjMH_1~+jg`ywRJRhINBU-LYvs;
zY?IntZSFRYAskRUO?7e9JUmP7lu+b_4o`=>!_^^mI6K4+p~KP9(a{7dm>q1o;ZRt^
ztn}4U)^Jt&8vM>qe-poR(sTD-9Z}@zSMI$g(m=^KBWoy`8@UO|>gJ^HA0o2JRF_0e
z`TlTXK_D(g#O8^}bUNkx|CCsSqb}FKjr6!vUQvWJ=9HJeh4cj4V@Tspd833hfpiAa
zPVsa}qL#qxBkCr5Wf=YMtxP-0T7_~$pU8qk4Sgz8vZmq*iKnOd41EkU^vMC{VwR}x
zV%9d{NNJ1E-qv9>m3NtjK7|=g!;tz}_CR^L;sm<lb<cDoU#<vt0RSw!DMa;2`W@-d
zQc~y72J8KOlzrUa7o_Iy)?%l;><;P>azzAr*>1|Vx=}fk=cE!$%dDVF-qNT!<$ESj
z?K&^-EN?l2A^vvX;sW`)U+ow26Rax=io!Exze=tXc;<q@`?eN)$^a!+b1YijVzoVU
zkzHMOfzK#~Zj&EOqiaa1ep9RCxcyf;hNOs4Z7)i?Oy2UEHk@}YDmL`-%mT^gL%vk+
z>*)AVi|_DDgqqh7exnMeb}f+@5ar640OOUSsZC1aVC9OEsg1@?u_Jq=8s6?THA>@V
zMDQ8Hf2yJhk!E14fps;_r({gS<x@8S;PlY_f=n~iYP6?nF@DFHyqjQR5D9toFx*lF
zD`K@Z90)TOGbO_FMZ5!si`$Ux<rTmZBNdt2mFPx&@`Fp5cA{Mvr&57;Y8sw2W#w+8
zX*dhIcpY^|Ga*uaf(l-{KuBBW>1zyOHWrnMIO}h!J`o4NCCxv0O|JOl52m9n^2Bzp
zJnfeTuYff&EE3vYOcnZhK#+M7&scK9<&p0LuJX21wOXIi<dQ26(QoZvc)vru5q$)Q
zI^T@i#9Pg3D~L)n)fzJsx72H)jaFpOs)4F>Q+%e7-qCIPa>oVuy>H56p0yMqONUCy
zuFRTAMYOt=%qojovWk>RD!nT#G@IRuH=9(>t<1HQq9vJcsX)uImDGi(EZ%tsjb{be
zMogiOHIp_Q4XIy=GOGm}6k+lTGiq+Dv6?3ka3;q`9u6U!U7U^V5*_9->_EBV2{5~c
zSmJ$#JwxhaK~WzW5x}^Z47`!6T_;h!C9f{lM{;xsv6BQ-{WS==x7EbI78P+2Dzy3e
ziN~>ZV(5xYM3R?YE7xz?FBA~7LmX*N+PtOLY74*tkX7Ss?y51hz{MzzW38fln*gml
z1Td`C>p`Ii{SME>K=RV7<y(HukKHyA@^=CnMZTTct}}OBvZKk+>}_EVBu1P7Js1(?
z&ASZYrZ|quT(D$rWI9jEIa5iRhP#j{J;W(jsbMopAYrTiCQJq1rN&whmO4EOBHwJ%
z5p5MfU!2fhR8L_Qv0}npTnZsDp4IZh$afqkjOY@)hD3KrN(NXV!J}r<z8wUc+vj11
zUdgN|+Y~B1{m16Z4SgEJHVd6BH&lSR4Sg(aC&mdbrk;6GBOAguSs*@ydR4MvhHHyy
zG!2P2nu1*WLc7sa#P(>YVC%F!TFnqc_$et5Rx6ltW6$9~8~S_}U`6rt717hZppfdq
zv~TihxgZLPZ;j))^K=3OA3{3$4EIae$!Vb5i%2VR+^i7RTFJ7O=0F1|Y7+vC9k_^c
z16#ngSccPHpTI1P>(A7QS_$zcl$pFS1@-a3yBE<2BAC<YRgVN3am7c+3rD~vImB^D
zJUkZ-6G?*JV_;mRBv?-b4>>JJb)tMxkZUF3R+|?j)0X0MKmkL)hP9U~k@S`E-c01?
z?SfqAGK5=+B<>$^+C%($Nqk~J;!a|9pCMhw&IFw#x}|?&if5fC0)2&|To>%$5#m`e
zlD-gYtF-wCnsFrP%vuY<@3qLqQ2|obGRT)j>{X8|9yL!7@x`rOs}1Q2790(+%F=7N
zWF;-B_M#%O#sr;^mBy$Qq)0GI2_%W(>S3XhC<_h2=fUSh+YzIwl<oNx5DcC~p&_)9
zcm%4E>DwLh^cT^P;~Q<iI;N6DWM6s*Q|6n=;1%lF{)*aC^P*;GB;Q4iI87Hf*1#IJ
znNpaqmXb117w3fVoQs4os})VY1y?hh{K|IW$<ezmOI)dV4$M&44@U3!!DUTm;tIQH
zC9dQrXI0evB42ZbT>~%xN2BH&LJ{&$A{$kmrY~O~#ZH1s`U?9j-JDanb*P~|Ag1Ol
zi1SS%$;Cmdw<JT7-Dd?0`iXf#1dec(yefZiz!w#<e#St@<$R8iIQBt%mLTPF>>l*N
zymCsRvG!qy&4eQ!V8ODaeUhRkouuWQ@90QegwJv_hYyXvoCO!<@ZtTPtwI4uEWos(
zxlE(!eAb@@UsW-n+m}1%gV8lyix@nnlOkCoB&~3;Xx=hA@l->kyB6Fkubi9Ln1+5O
z<e)?nn;Ky`X<+ls#av1o`VA~tf<xwl4i=I0fyM2iN~5_&S?%RyO+8h1z!pQE=DWFF
zf%&=ggftz;wmVuyal1g8ZJVQ261NFmD?{UwyzAJf>LCkBS-9hwNRbAWGmeGawi3c9
zgdZdd7s0eIA`UDU4`L7!my3rYc_riqx{#{LPdxu`PCPz8v8=w#XD*_dy&A+i(2!6d
zRX0GP_vOW7$fy7=Cb!^FF~V>N@|ZVZJC4;LbOzOM`B%Z*acgt22GVd^<_&s~z-Ss_
zZVHLIlpGeEH!OJ9u#kA?Z|LWkpA@`=c4oCoQu6|Uw2D%5UB1pKH7lqiV_KJ*7v-w~
z`ehFE=6oGMKSf<=Tk}+HD~;GHxnwn{ZRB}DY96cI#j{RSZ`RgOK2+B{Mq5rfOpog2
z+WaJ#qj{z_o8xgztKwjjo2P5zZ7}Nnur`W=4be&oY@Zt@F^wiR7x1MwPbFh=6E_)@
z{a_#;EKXnZRC(E7DKC;V_R)#90WA)J)870gnXu@AQ|LqSW-ZzLsrE&V!BB@$@?;eR
z&Y`dy(cS&O)dKvss*jj?Yg389+7!6837vY0wQ1Y1a9#)7ux*#xu+Diw@W#H&?N!}P
zSOZPY?lv}dmh5ga-t9HfarnyOb7;4D+FWEG10g*D<lq#0<X}2?_zr^alJeq74VxVe
z-xC^khz*ZB8}>*IKd)$bc5K7maSgBf8{Qn>@cRi3AGA3f4IdjidW;Y^{LftGZr#o-
zXv<YJ=0LPsyW*`Iat#}L?9B1wxr*!W&t<+d&(3JMRQ%3Lu5z$j@+~*?o7#)X)HeCK
z8fKpiLtkPV4iRU>(3b)@Z<NpHkTy)#a4D?)DMPO@lQ07MHx@90A-oO})-XeOBiB2E
zQ*S11pBKuJpFc}6VRdA=957d+(uoNbVLU?>?7|FiQc4aeCeAKNidBG+I7*Yv!@nbc
zjXPeLXd)*1Ez-$IUqedJFrtVx`SE}7e-Vr&FP}##^!P<bUMaEcm1g7z5B%de#5q%4
zLve^-C6-bAVAEElG4V7N5pCG?&xz|P8nNkJq=-6%e2E(Z$Hn?E63AH#$qDf^ODqo@
zcSW3X?L_1Nw(<Z{1SdjskRqrNI;5VnqY{|w??okOH8WuwK}(F|n&uMwscew>1afe5
zTV6WFM|*1M)gX~@Fb;DiYCbG{Pv2S}v9j{iiQIRnXX~6nr%!kZCwL90x`tWpd&C-1
z=xkTBPh0Uljx6tUBRY_u|B#{I$SkET8+0X=qR<Gt7zo~*RGh)P41G2BOCxQ*8iTE7
zXbwSEb(1e<=nD3_h_cYSLs?b{P*u0$1h41{TNel^QF3oq8jdtmY7G4*lZ6(Lo1m2%
z`pq;ltlu@za6%cytv)l=o2cu};E01rZ$$boQcNqnXF_3&LEuUIlh1IRV-+V0SVXAk
zEQ*M{jPOvz=_@;FXmgWhb-5v|!|-C|udDUyebqJ9Yvbuz>8sMS({uLDiqugU>#9gS
zC9@+pQZgs9TAY4m<F%#n^t{ITp2ix{5CVy7&1hmCJ~+k+SY(ZhiyM~+i<Xo&E_F6u
zcb6f|Ni0Uo5`0VXT}S&8u=fSa5a#e5io$rK34uOMh=e9YLKBjUZRNn=WA%5Su-i6^
zhux4+*bT`|)WM-4!jOq*s4_AR64mlepVdDkPk*TX-TFHaTUrE*X8}lT**OpwJj*MQ
ztrqI%^C4>NAsQ>J`upn7*GJ-(xag_+yXrU9|9bPP`p4>jZ0ICl;L|yQ6in(UtiSXM
zSb*A55aLs3<MaQ63LjI0A?zW~2x(j$f-aPWgM{wri0nejBA^mg3v)FTComDGfg@;p
zlFBiA5=?~93Pyr*f#D<kT-}bEAK`ljpC2_pQ<vfQUsZ<Re~IJgr_f2@&w5}&ZW@fS
zIE*pU*z?+nhxY75BimD6gQ(G4WPbvq`kcWY8OAO6BOGozhjY~Yry=}~1y1}sjXIG=
z<)X<{Oyo$y<xqx~f|XJ;Dtjq((o1TS{I)8U`@LWVYy|42+CW((ld(MB;}{YOBk{t1
zPM$nb&Y^N<E`kGohBby`Qmy`rsmWACzSZec4O4R>K4a)}2o1Pfz(A;-#Iv+v9Mg;F
zOIn?F(a^tzPTzvFXZrm-K71Q3VhTA>li4OXdP}Dq_U;$N=C%7$^7N;W+jp<LaE10>
zUh`wY0p`zHo0pME>Dku{GtD;Vte_KyW%ExovH7`+?XZ2m=HKSjEF8h1hpYAr-sYbe
zLIQm0+xMm6@G>O{qmWLAwW|(z-om#O=iIihlXutgExna*=`Fb}g)_#t^p>w|Dd4cB
zfXi<w`*&=8HOoYH)9KMCu^^%VRV;AQ1s6+mBM+hy9<`-59ucAWJ;Pyuxib+1eTZGe
z=`ZH!AXol6p2lH*DjD4J?Hh%}jsAN%Id2C!9XnaNE?o~t`dFeaz=l*nVN8B!b$z!s
zALZjCDiXzV*&7HOFRHIF1b5tAU7ykXXo?M~fG)Y$y}G_v8;0_U5=c7v&IdTCwz~e@
z-ulQ+prZYd(-N}JU=_IAfb9cOoAaR~B4hx|CflE?8<iZ-_-#`hL5$xZ)EFhtwM08g
z{)+fR7UVHiNaB%(_z0^w&WnhE4hpe)sZYH3LI(1s7U8!yl4j66yjeSy=Lq2sq`dVv
z!AEbhOh`QbbEBz%S*ozz@w~^Yx!PwOnsMmk^H%b9wEdXc8cpcR4ta4Q*m=L%SS~aU
z(;J8HZyX_T_0%R$?dk_RY=gap2u-fzhjz`|12sqNn)ZPj)2=x%P;=U@d1s&|W!L;}
zpyo@v=J$Lh7EPE{h3DN~O>Cd>ao?G>e3ACrXl1<C5dHx0HfC|u-;x{VQ$GYL6sP%C
z6F1&OlW*5WH0&T6%J+}fzA*HUl4i8ajOK&3h8{B`ejc+m^iRlw)<0ss<llY*yHy+U
zMWg9`)_+$TfrcL<&_K6h2=5yDQ4abiX2tt5+3-lY;<e|c7hEs8UxH716g|6?NamEH
z^~tq=;IZIb2O9JgS?gq!AL0{J4EZDM(WTS0(G3$H%LXPhhX<Vb7!+T=bPU`KRFH%D
z5v16N$Rxg~uve~lKB)*6&UlPsUNJDiN5Nuy!h86-v?9B-?vhn@DJ7YBpP~Pmul3I&
z+3_cm=1VZ@Kg-dt#mUz{Y|#1>eErmyR<D#`2*87~C+vBG7tdoa^D}fASf)7bm-%zQ
z_CNS$hD%i;WrzhV>_~aliqxnWg4Hf>%&(<jmK&K;Gc3gX4jP!^L1AZVofI4zvv9BD
zNzygVok!zgF%@>ktWhysL|4W#qhggL_Lw!$EvrhEJ>98ftL4U!;Ht0~lTzBdVJQ}t
zQ&!j&3zwzB?pU}y752o!!%|^yEIcC>E{KI^rox4>@T^pLNGyC+DqIu`&rXGh#=>(_
z;o?~M>QuNS7QQAG4-Zcz{XM}(e_!x^zZYn=h09{Cf(ruc&UYv)x*)6UtW!GewsWN;
z!^2|PQL#*y6&}%@%Hr15LNLs3Ec@C<yXP6q@Xn|d0EdHq7=N7yH7|x|#%#U?bG+7;
z<J<5IyRyT9U2Dr-afWB*AWH$6ztBW`c$8e54G)jOt>2Bk0BY51!<SRtoUa>t_SX%4
z_1_q}f`-8lT*jZ#n5X61{r&i0-UKyL<yY{bMt&i4C|pkW)^s7G{S)#QuCcNDUSMqK
zubZ2XYc6mU_@OjLCVO3JGFXVc#yYA}V-1LF$l#YfU3;alKh@<;ebFj;!V^J3t@w-Z
z#8#IJU11PNsUzX>u|4Ru$5Hp~cz8l8Jdwu8wm)4X{vx8znAQ^uPfB4%7OYffQ)zmt
z+d`izK+SaQY9dyhoC;5mS!c50$+0_VkCV5rOojbG-V3nsq*w+TC_I7q@E85ldFs~x
zgXz!%?-^p1_+~o(IX96yyNcuRmFXtMEOZzIpET`Bf5y=-3H$jg0LZ@ZH0;ly+3Ri}
zwA85tkwEWW5^CprAb`S?lPPufRD1I5nYDaf-M6nwVSRk&cGdZB88}RR4`<aWmFHD$
z?uDd0=5t#0Ps3AaTe+~yV=?WQK4@WbU2~3d7T#K>9oCVYcU^7Y`~x^thW-HwzC+#k
z`G8#KL(DqzRNWjK5*-yGs~+W%UX8BX2J*NMIXqs26h@DI8YR%yzokHF2qqaUE6Jk!
zW#mZ29G<}KOMY7e0}w_yki@kmU2oF;q-}!&?=G%__Bvk{A(YeH@H(JgZL0S~%~Q&J
z#6D}f%vYptvJ|^uPy}cCKM7v$pBq|W=-uqVj2SZ&;F5yzxgMWpYTuxG#1weluTTdQ
zV-$x~O6^MW2Vi#bD**jVxOi@ionpaaLs*F1Y1Ax&TZvynGle2mpMjYwEM#k8tfpYB
zcB@z0J~!~>kT@q;zy{O!;aVt_^<;g27v1imk6huJy5Z_pPFFp>gCbX`1_6%)j$qc4
z6?_k))8Z8GlhtF>&c|my0`nw2?9t(kBMP~Ozm<#={WfUbs)<R-p5Ruxhswy+pC|nX
z4LxiUn_;}$xLx!Rp>a2g_tHmbNOic@c!*_f8>0N<z6ypg$Gr>}ROrpB{97@ve&J!E
z&DjPb-VG%sKI^~zysFPKA1}9&5%G}2$x*o*OQ7CZ$kRZ_UPF~B-dlrtK?{8Y!^&&K
z1uf7lTS*~d@gUFrCY*K(=VT21J8;}fvQbn0UY<Gt*l6~3XHWHh0i+)6Hls<i3&FAb
z9(UaLwy=JSxZxS+`X{CJEw1$~?)5F6^)22FGYU4WFLXFIw9uRx|M&BAWz~oIJqXPU
zjbZ3&x7mmBFa?qECx(6>T%`riP`80z0}5flkU{&y`B8cMMVf*4-ZrQ;e2J3C3vCX%
zeK6>#!TQ9|AK(_k1KbYy3C}-hTU*mW*ZUAsC4@IJQ14=_dgGQH_&vQ^`1+;|)K}nr
zY0>}PCEuU3_bypz9{cYwf3MXBdBK-KF9Tro05OC;p@?v|PPo_$AeQTAb>ZRc_q44u
zIDcV}z$`3-RljaNENQq}rqzE<FX?aga?9U7j&95^Vyq3U$`nSz0V%+l!4rWNSJyN{
zyB2;Eh4`(mDnpxx0?A8Wn2!R*8F>LdFAphNueb<s0UUZ8GQcMA0NI?}IEH>T0#sQX
zOhuqLB#mI`-=qM*94z`0pV<zsVOo72WX(w)0yXsO`^UOrAoQ(g_+j8-5kt=qPo!~W
z291iFV+Y+8>K5G<!sUW{s=<4rcLi47LoMV%2ko7R!0pJq6Q#q?8DlgRG7F@22+%cs
zk(TYk=3tU8!qGV5@$$zYh73nB7UCDvBOr~0t<Uf+qGr3n5MII3AlZcXaeHn19l0su
zmZALx+D7}BWnOhl+i~->-O-Im$#g?#VWIM_MziEu|3av`Stex9=Knw(B{+h>;mkxF
zt%Vd=2_hPZxDQ8t*HGWCVrUd$CTqAhy#UX~=A{?ncYb;ierwXTXh|$UY-}OEMfhqd
zwlkMCEKV;2z>@U!_+6U50l(L!m!l=I3_#c8y8+*Fb9M7EY!<)T=EU~d7lI+2t%)p%
zC|~|<g1qXCeLa_lfZhW{#Q+5MmB(rFH|U-a1v)r*tAJ}QKo{GQ9y~J;HRs_7Zl<pQ
zQNW5gVVQmFpIo_Xm3?8{e+SZ3jJIM<Lz4(j_MM*neaBu8O3aYPqqZ0WswG^QlKBrd
zXmP3Dd^v8a1^GNfXzAjs;B(NlEiRkDD^K6BUl?U*HS{KA-}=3tm)$KZ<yB2NL=5)}
z5Yx*|mQmV5aI^RuH|@c$KqoF5aG@`TrqH@^Wmv&@GvajGq})1%5WEds$s$B3?E6rw
z-~|!}6p9BGq<yQjA%`Oxga;p&ZcUL5oGg=9owmtMgQLHXf=$@jwQ;cBTtpeZ64$;h
z_by;<?p*-MJ#;Na!Y!2|L`3N>5wdgDP*UNzq|L7lOB<R)0n>;}v83fJ&^eZ`Pze3E
z@s1->Ql7yp6LGr+AFIo3arf^qJt4RZrV>+(ARbrZIODYz#RreaajJ11_%?C&amrgD
z;pQVYhPQZs1>b_DX7M=xasPjT9_RoD#bYsWrM&q%T$_`6^y3W+1y?oLY!p9SfrTSj
zPEji<o(o!OoR$H08Q$7Z%#jBlbB}JMQ%w0Qwgzb}ZuB6~2JV-!)vgSVHlNwbJ#(Cx
zgq>(e3_CqOKX)mgJAZcr$qyVMOAsOsFd({&Wr7R766>KcdXu*X-Pp`!G{;hQ<lpK_
z4dM4N`^w(T1(<#Esv$H2VS(5txXxp^DdIMORk?x(m)}T|$(lp!I7os^gc9Pq{wpQY
zN1!;J>WCmb(B8dAs3{!U#U1f@mF43Vej`)HHij-Ugpur37mUle`jCk_B4w9^j7gxt
zcqL3=n3N7OljxQUVHRYV^{QL&A*@`-_N+7XRTNvqAm9oL#G)C?T$O(e@-~06k$Y%$
z@vDuzz;BXCdXy#2BYQk`AqtoEhm_9XerqXPn~5xirv;cnjc8lKR%Iefc$>_EqrL`W
zF<XV0-X%S0*u^yLVr@IM`Fl*}moA-n5kV~a`iU3O#C97dzJd=jXaLNxkYE;Smw&a9
z=7;f)R*arIIb14(;uJWaif1o)-%%umAfxQ?y00r#2&Ii}sN{ZACB4qAWaNn80TbR8
z(MtrVuzVczUXm0RF0Xh6xMU55wX<==Li4fB+GHTc^LRrDk83L4f$<`|k;ybF-DuG>
zPsB?rObu6J^KxNQ_%&49|MV1s6VLjC3v*ftS{iTLa7uCgTmtchBa4_j2{itO0pgCh
zWQt0T&N%RQ|AC^{QG>6nr*Oj%K=gDpcTYfFAR=<lY0L1Y65~KH<3hp{T1YQx12{&!
ziX=w>PYMK4qxTGMyuag3bI6bjF#H=s3E|u-;OqhAUd%(+i-v1zKG@C?f)O!rv+g7$
z`91r<D*}1h3A%Kr_XLCS=kE<(@$eUoaDVwzlEM}|RD_7PLmAK?EO?!*FKlIyTUgOW
z3&Vm3t!V)NVjF*`CL4c4n@<{2-njlrWmm)AhL@F=)licy4X-GMq(Pr$UiPSE-ynmZ
zYh%H@s00F_b;LmH1ydb9P#Qz6?twD)R$2|rr5o|plc^=usTorp)(@hzt;ndu^7_5Y
z^u6SH(cLw*H-629c0>C=>}Q7d3H#T&@+k8Qu*p7QGacFXFP`rG{HY6{lMrfgst(?}
z7nXxXmZ_!C`&zn5%U${x+O{$ty%AfGB!)7-4!cZSyaW&7@I3iPOu0NXq+i0~iUTk5
OE+=Occa@IUp8UUyqelq<
literal 0
HcmV?d00001
--
1.8.1.4
^ permalink raw reply related
* Re: [PATCH 1/3] net: bpf jit: ppc: optimize choose_load_func error path
From: Jan Seiffert @ 2013-10-08 22:50 UTC (permalink / raw)
To: Vladimir Murzin, netdev
Cc: av1474, Benjamin Herrenschmidt, Paul Mackerras, Daniel Borkmann,
Matt Evans
In-Reply-To: <1381249910-17338-1-git-send-email-murzin.v@gmail.com>
Vladimir Murzin schrieb:
> Macro CHOOSE_LOAD_FUNC returns handler for "any offset" if checks for K
> were not passed. At the same time handlers for "any offset" cases make
> the same checks against r_addr at run-time, that will always lead to
> bpf_error.
>
Hmmm, if i only would remember why i wrote it that way....
I memory serves me right the idea was to always have a solid fall back, no
matter what, to the generic load function which works more like the load_pointer
from filter.c.
This way the COOSE-macro may could have been used at more places, but that
never played out.
And since all i wanted was to get the negative indirect load fixed,
optimizing the constant error case was not on my plate.
That you can get your negative K filter JITed in the first place, even
if the constant error case was slower than necessary, was good enough ;)
The ARM JIT is broken till this date...
You can have my
I'm-OK-with-this: Jan Seiffert <kaffeemonster@googlemail.com>
for all three patches, -ENOTIME for a full review ATM.
> Run-time checks are still necessary for indirect load operations, but
> error path for absolute and mesh loads are worth to optimize during bpf
> compile time.
>
> Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
>
> Cc: Jan Seiffert <kaffeemonster@googlemail.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Daniel Borkmann <dborkman@redhat.com>
> Cc: Matt Evans <matt@ozlabs.org>
>
> ---
> arch/powerpc/net/bpf_jit_comp.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
> index bf56e33..754320a 100644
> --- a/arch/powerpc/net/bpf_jit_comp.c
> +++ b/arch/powerpc/net/bpf_jit_comp.c
> @@ -132,7 +132,7 @@ static void bpf_jit_build_epilogue(u32 *image, struct codegen_context *ctx)
> }
>
> #define CHOOSE_LOAD_FUNC(K, func) \
> - ((int)K < 0 ? ((int)K >= SKF_LL_OFF ? func##_negative_offset : func) : func##_positive_offset)
> + ((int)K < 0 ? ((int)K >= SKF_LL_OFF ? func##_negative_offset : NULL) : func##_positive_offset)
>
> /* Assemble the body code between the prologue & epilogue. */
> static int bpf_jit_build_body(struct sk_filter *fp, u32 *image,
> @@ -427,6 +427,11 @@ static int bpf_jit_build_body(struct sk_filter *fp, u32 *image,
> case BPF_S_LD_B_ABS:
> func = CHOOSE_LOAD_FUNC(K, sk_load_byte);
> common_load:
> + if (!func) {
> + PPC_LI(r_ret, 0);
> + PPC_JMP(exit_addr);
> + break;
> + }
> /* Load from [K]. */
> ctx->seen |= SEEN_DATAREF;
> PPC_LI64(r_scratch1, func);
>
--
An UDP packet walks into a
^ permalink raw reply
* RE: [PATCH RFC 63/77] qlcnic: Update MSI/MSI-X interrupts enablement code
From: Himanshu Madhani @ 2013-10-08 22:46 UTC (permalink / raw)
To: Alexander Gordeev, linux-kernel
Cc: Bjorn Helgaas, Ralf Baechle, Michael Ellerman,
Benjamin Herrenschmidt, Martin Schwidefsky, Ingo Molnar,
Tejun Heo, Dan Williams, Andy King, Jon Mason, Matt Porter,
linux-pci, linux-mips@linux-mips.org,
linuxppc-dev@lists.ozlabs.org, linux390@de.ibm.com,
linux-s390@vger.kernel.org, x86@kernel.org,
linux-ide@vger.kernel.org
In-Reply-To: <c92efbde96541d08f37510422c096d543bb01279.1380703263.git.agordeev@redhat.com>
> -----Original Message-----
> From: Alexander Gordeev [mailto:agordeev@redhat.com]
> Sent: Wednesday, October 02, 2013 3:49 AM
> To: linux-kernel
> Cc: Alexander Gordeev; Bjorn Helgaas; Ralf Baechle; Michael Ellerman;
> Benjamin Herrenschmidt; Martin Schwidefsky; Ingo Molnar; Tejun Heo; Dan
> Williams; Andy King; Jon Mason; Matt Porter; linux-pci; linux-mips@linux-
> mips.org; linuxppc-dev@lists.ozlabs.org; linux390@de.ibm.com; linux-
> s390@vger.kernel.org; x86@kernel.org; linux-ide@vger.kernel.org;
> iss_storagedev@hp.com; linux-nvme@lists.infradead.org; linux-
> rdma@vger.kernel.org; netdev; e1000-devel@lists.sourceforge.net; Dept-
> Eng Linux Driver; Solarflare linux maintainers; VMware, Inc.; linux-scsi
> Subject: [PATCH RFC 63/77] qlcnic: Update MSI/MSI-X interrupts enablement
> code
>
> As result of recent re-design of the MSI/MSI-X interrupts enabling pattern
> this driver has to be updated to use the new technique to obtain a optimal
> number of MSI/MSI-X interrupts required.
>
"We will test this change for the driver and provide feedback."
> Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
Thanks,
Himanshu
^ permalink raw reply
* [PATCH v2 net] pkt_sched: fq: fix non TCP flows pacing
From: Eric Dumazet @ 2013-10-08 22:16 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Steinar H. Gunderson
In-Reply-To: <1381182269.12191.27.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <edumazet@google.com>
Steinar reported FQ pacing was not working for UDP flows.
It looks like the initial sk->sk_pacing_rate value of 0 was
a wrong choice. We should init it to ~0U (unlimited)
Then, TCA_FQ_FLOW_DEFAULT_RATE should be removed because it makes
no real sense. The default rate is really unlimited, and we
need to avoid a zero divide.
Reported-by: Steinar H. Gunderson <sesse@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
I removed the ACCESS_ONCE() stuff, as it adds conflicts for
next (net / net-next) merge. I'll send a separate patch later.
net/core/sock.c | 1 +
net/sched/sch_fq.c | 20 +++++++++-----------
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/net/core/sock.c b/net/core/sock.c
index 5b6beba..0b39e7a 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -2319,6 +2319,7 @@ void sock_init_data(struct socket *sock, struct sock *sk)
sk->sk_ll_usec = sysctl_net_busy_read;
#endif
+ sk->sk_pacing_rate = ~0U;
/*
* Before updating sk_refcnt, we must commit prior changes to memory
* (Documentation/RCU/rculist_nulls.txt for details)
diff --git a/net/sched/sch_fq.c b/net/sched/sch_fq.c
index 48501a2..a9dfdda 100644
--- a/net/sched/sch_fq.c
+++ b/net/sched/sch_fq.c
@@ -472,20 +472,16 @@ begin:
if (f->credit > 0 || !q->rate_enable)
goto out;
- if (skb->sk && skb->sk->sk_state != TCP_TIME_WAIT) {
- rate = skb->sk->sk_pacing_rate ?: q->flow_default_rate;
+ rate = q->flow_max_rate;
+ if (skb->sk && skb->sk->sk_state != TCP_TIME_WAIT)
+ rate = min(skb->sk->sk_pacing_rate, rate);
- rate = min(rate, q->flow_max_rate);
- } else {
- rate = q->flow_max_rate;
- if (rate == ~0U)
- goto out;
- }
- if (rate) {
+ if (rate != ~0U) {
u32 plen = max(qdisc_pkt_len(skb), q->quantum);
u64 len = (u64)plen * NSEC_PER_SEC;
- do_div(len, rate);
+ if (likely(rate))
+ do_div(len, rate);
/* Since socket rate can change later,
* clamp the delay to 125 ms.
* TODO: maybe segment the too big skb, as in commit
@@ -735,12 +731,14 @@ static int fq_dump(struct Qdisc *sch, struct sk_buff *skb)
if (opts == NULL)
goto nla_put_failure;
+ /* TCA_FQ_FLOW_DEFAULT_RATE is not used anymore,
+ * do not bother giving its value
+ */
if (nla_put_u32(skb, TCA_FQ_PLIMIT, sch->limit) ||
nla_put_u32(skb, TCA_FQ_FLOW_PLIMIT, q->flow_plimit) ||
nla_put_u32(skb, TCA_FQ_QUANTUM, q->quantum) ||
nla_put_u32(skb, TCA_FQ_INITIAL_QUANTUM, q->initial_quantum) ||
nla_put_u32(skb, TCA_FQ_RATE_ENABLE, q->rate_enable) ||
- nla_put_u32(skb, TCA_FQ_FLOW_DEFAULT_RATE, q->flow_default_rate) ||
nla_put_u32(skb, TCA_FQ_FLOW_MAX_RATE, q->flow_max_rate) ||
nla_put_u32(skb, TCA_FQ_BUCKETS_LOG, q->fq_trees_log))
goto nla_put_failure;
^ permalink raw reply related
* Re: [PATCH] pkt_sched: fq: fix non TCP flows pacing
From: Eric Dumazet @ 2013-10-08 21:24 UTC (permalink / raw)
To: David Miller; +Cc: netdev, sesse
In-Reply-To: <20131008.165318.1392122841162708841.davem@davemloft.net>
On Tue, 2013-10-08 at 16:53 -0400, David Miller wrote:
> Is this meant for net or net-next? It doesn't apply cleanly to the
> former.
Oh right, I need to respin for net tree, sorry for the confusion.
^ permalink raw reply
* Re: [PATCH] veth: Showing peer of veth type dev in ip link (kernel side)
From: Stephen Hemminger @ 2013-10-08 21:13 UTC (permalink / raw)
To: David Miller; +Cc: yamato, netdev
In-Reply-To: <20131008.152349.729447337097758010.davem@davemloft.net>
On Tue, 08 Oct 2013 15:23:49 -0400 (EDT)
David Miller <davem@davemloft.net> wrote:
> From: Masatake YAMATO <yamato@redhat.com>
> Date: Fri, 4 Oct 2013 11:34:21 +0900
>
> > ip link has ability to show extra information of net work device if
> > kernel provides sunh information. With this patch veth driver can
> > provide its peer ifindex information to ip command via netlink
> > interface.
> >
> > Signed-off-by: Masatake YAMATO <yamato@redhat.com>
>
> Applied to net-next, thank you.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Please revert this. It is incorrect.
The info returned by any netlink message should be equal to the message
for setting.
I think the correct patch would be something like this (compile tested only).
--- a/drivers/net/veth.c 2013-10-06 14:48:23.806461177 -0700
+++ b/drivers/net/veth.c 2013-10-08 14:11:42.434074690 -0700
@@ -434,6 +434,35 @@ static const struct nla_policy veth_poli
[VETH_INFO_PEER] = { .len = sizeof(struct ifinfomsg) },
};
+static size_t veth_get_size(const struct net_device *dev)
+{
+ return nla_total_size(sizeof(struct ifinfomsg)) + /* VETH_INFO_PEER */
+ 0;
+}
+
+static int veth_fill_info(struct sk_buff *skb, const struct net_device *dev)
+{
+ struct veth_priv *priv = netdev_priv(dev);
+ struct net_device *peer = rtnl_dereference(priv->peer);
+
+ if (peer) {
+ struct ifinfomsg ifi = {
+ .ifi_family = AF_UNSPEC,
+ .ifi_type = peer->type,
+ .ifi_index = peer->ifindex,
+ .ifi_flags = dev_get_flags(peer),
+ };
+
+ if (nla_put(skb, VETH_INFO_PEER, sizeof(ifi), &ifi))
+ goto nla_put_failure;
+ }
+
+ return 0;
+
+nla_put_failure:
+ return -EMSGSIZE;
+}
+
static struct rtnl_link_ops veth_link_ops = {
.kind = DRV_NAME,
.priv_size = sizeof(struct veth_priv),
@@ -443,6 +472,8 @@ static struct rtnl_link_ops veth_link_op
.dellink = veth_dellink,
.policy = veth_policy,
.maxtype = VETH_INFO_MAX,
+ .get_size = veth_get_size,
+ .fill_info = veth_fill_info,
};
/*
^ permalink raw reply
* Re: IPv6 kernel warning
From: Yuchung Cheng @ 2013-10-08 20:53 UTC (permalink / raw)
To: dormando
Cc: Michele Baldessari, Russell King - ARM Linux, netdev,
Neal Cardwell, Nandita Dukkipati
In-Reply-To: <alpine.DEB.2.02.1310081123230.21359@dtop>
On Tue, Oct 8, 2013 at 11:24 AM, dormando <dormando@rydia.net> wrote:
> On Mon, 7 Oct 2013, Yuchung Cheng wrote:
>
>> On Mon, Oct 7, 2013 at 12:56 PM, dormando <dormando@rydia.net> wrote:
>> > On Mon, 7 Oct 2013, Yuchung Cheng wrote:
>> >
>> >> On Mon, Oct 7, 2013 at 11:13 AM, dormando <dormando@rydia.net> wrote:
>> >> >
>> >> > > >
>> >> > > > there's been multiple reports about this one:
>> >> > > > https://bugzilla.redhat.com/show_bug.cgi?id=989251
>> >> > > > http://bugzilla.kernel.org/show_bug.cgi?id=60779
>> >> > > >
>> >> > > > Could you try Yuchung's debug patch?
>> >> > > > http://www.spinics.net/lists/netdev/msg250193.html
>> >> > > Yes it looks like the same bug. Please try that patch to help identify
>> >> > > this elusive bug.
>> >> > >
>> >> >
>> >> > Hi!
>> >> >
>> >> > We get this one a few times a day in production. Here's a warning with
>> >> > your debug trace in the line immediately following:
>> >> > (I censored a few things)
>> >> >
>> >> > [125311.721950] ------------[ cut here ]------------
>> >> > [125311.721961] WARNING: at net/ipv4/tcp_input.c:2776 tcp_fastretrans_alert+0xb58/0xc80()
>> >> > [125311.721962] Modules linked in: bridge ip_vs macvlan coretemp crc32_pclmul ghash_clmulni_intel gpio_ich ipmi_watchdog microcode ipmi_devintf sb_edac lpc_ich edac_core mfd_core ipmi_si ipmi_msghandler iptable_nat nf_nat_ipv4 nf_nat ixgbe igb mdio i2c_algo_bit ptp pps_core
>> >> > [125311.721981] CPU: 11 PID: 0 Comm: swapper/11 Not tainted 3.10.13 #1
>> >> > [125311.721982] Hardware name: Supermicro XXXXXXXXXXX, BIOS 1.1 10/03/2012
>> >> > [125311.721984] ffffffff81a82007 ffff88407fc63958 ffffffff816bb9cc ffff88407fc63998
>> >> > [125311.721986] ffffffff8104b940 00ff8840ad904f82 ffff883b8a165b00 0000000000004120
>> >> > [125311.721989] 0000000000000001 0000000000000019 0000000000000000 ffff88407fc639a8
>> >> > [125311.721991] Call Trace:
>> >> > [125311.721992] <IRQ> [<ffffffff816bb9cc>] dump_stack+0x19/0x1d
>> >> > [125311.722002] [<ffffffff8104b940>] warn_slowpath_common+0x70/0xa0
>> >> > [125311.722005] [<ffffffff8104b98a>] warn_slowpath_null+0x1a/0x20
>> >> > [125311.722007] [<ffffffff81616db8>] tcp_fastretrans_alert+0xb58/0xc80
>> >> > [125311.722011] [<ffffffff8161891f>] tcp_ack+0x6df/0xe90
>> >> > [125311.722016] [<ffffffff8164e0ca>] ? ipt_do_table+0x22a/0x680
>> >> > [125311.722018] [<ffffffff816194b3>] ? tcp_validate_incoming+0x63/0x320
>> >> > [125311.722021] [<ffffffff8161a55c>] tcp_rcv_established+0x2cc/0x810
>> >> > [125311.722023] [<ffffffff81622c84>] tcp_v4_do_rcv+0x254/0x4f0
>> >> > [125311.722025] [<ffffffff816245ac>] tcp_v4_rcv+0x5fc/0x750
>> >> > [125311.722027] [<ffffffff815ffa00>] ? ip_rcv+0x350/0x350
>> >> > [125311.722032] [<ffffffff815df3ad>] ? nf_hook_slow+0x7d/0x160
>> >> > [125311.722034] [<ffffffff815ffa00>] ? ip_rcv+0x350/0x350
>> >> > [125311.722036] [<ffffffff815fface>] ip_local_deliver_finish+0xce/0x250
>> >> > [125311.722037] [<ffffffff815ffc9c>] ip_local_deliver+0x4c/0x80
>> >> > [125311.722039] [<ffffffff815ff329>] ip_rcv_finish+0x119/0x360
>> >> > [125311.722040] [<ffffffff815ff8e0>] ip_rcv+0x230/0x350
>> >> > [125311.722046] [<ffffffff815b4067>] __netif_receive_skb_core+0x477/0x600
>> >> > [125311.722049] [<ffffffff815b4217>] __netif_receive_skb+0x27/0x70
>> >> > [125311.722051] [<ffffffff815b4354>] process_backlog+0xf4/0x1e0
>> >> > [125311.722053] [<ffffffff815b4b45>] net_rx_action+0xf5/0x250
>> >> > [125311.722056] [<ffffffff81053a5f>] __do_softirq+0xef/0x270
>> >> > [125311.722058] [<ffffffff81053cb5>] irq_exit+0x95/0xa0
>> >> > [125311.722062] [<ffffffff816c8f26>] do_IRQ+0x66/0xe0
>> >> > [125311.722065] [<ffffffff816bf62a>] common_interrupt+0x6a/0x6a
>> >> > [125311.722065] <EOI> [<ffffffff8100abf1>] ? default_idle+0x21/0xc0
>> >> > [125311.722082] [<ffffffff8100a54f>] arch_cpu_idle+0xf/0x20
>> >> > [125311.722086] [<ffffffff8108f353>] cpu_startup_entry+0xb3/0x230
>> >> > [125311.722091] [<ffffffff816b439e>] start_secondary+0x1dc/0x1e3
>> >> > [125311.722093] ---[ end trace e77cd5ba583fcbe9 ]---
>> >> > [125311.722096] 355.355.1.355:22496 F0x4120 S1 s7 IF25+17-1-24f0 ur57 rr3 rt0 um0 hs23120 nxt23120
>> >> >
>> >> > It's been happening with all 3.10 kernels, and the one above is .13 as
>> >> > stated in the trace.
>> >>
>> >> Thanks! could you post the output of `sysctl -a |grep tcp`?
>> >>
>> >> I suspect tcp_process_tlp_ack() should not revert state to Open
>> >> directly, but calling tcp_try_keep_open() instead, similar to all the
>> >> undo processing in the tcp_fastretrans_alert(): after
>> >> tcp_end_cwnd_reduction(), the process (E) falls back to check other
>> >> stats before moving to CA_Open.
>> >>
>> >>
>> >> index 9c62257..9012b42 100644
>> >> --- a/net/ipv4/tcp_input.c
>> >> +++ b/net/ipv4/tcp_input.c
>> >> @@ -3314,7 +3314,7 @@ static void tcp_process_tlp_ack(struct sock *sk, u32 ack,
>> >> 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);
>> >> }
>> >>
>> >
>> > Should I apply this and see if the warning stops?
>> I'd like to hear what the authors of TLP think. In the mean time could
>> you help us collect more evidence by disabling TLP with
>> sysctl net.ipv4.tcp_early_retrans=2
>> and see if the problem still occurs? (it should not).
>>
>> thanks
>
> Box hasn't had a warning in the last 24ish hours. A neighboring machine
> with the default tcp_early_retrans setting has had 5-6 in the same
> timeframe.
>
> Is this a harmful situation to the socket in any way, or is it just
> informational weirdness?
It should be fairly harmless. The ack that triggers the warning should
set the TCP back to the good (non-Open) state, but it's still good to
get rid of.
^ permalink raw reply
* Re: [PATCH] qlcnic: add missing destroy_workqueue() on error path in qlcnic_probe()
From: David Miller @ 2013-10-08 20:53 UTC (permalink / raw)
To: weiyj.lk
Cc: himanshu.madhani, rajesh.borundia, shahed.shaikh,
jitendra.kalsaria, sony.chacko, sucheta.chakraborty, yongjun_wei,
linux-driver, netdev
In-Reply-To: <CAPgLHd9oA08=1o_DWE0SGeg_7nokr3-WPEAOrG71bYg2C1676A@mail.gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Tue, 8 Oct 2013 11:32:17 +0800
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> Add the missing destroy_workqueue() before return from
> qlcnic_probe() in the error handling case.
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Applied.
^ permalink raw reply
* Re: [PATCH] sh_eth: NAPI requires netif_receive_skb()
From: Sergei Shtylyov @ 2013-10-08 21:52 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: David Miller, netdev, nobuhiro.iwamatsu.yj, linux-sh
In-Reply-To: <Pine.LNX.4.64.1309261751200.11968@axis700.grange>
Hello.
On 26-09-2013 18:12, Guennadi Liakhovetski wrote:
>> From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>> Date: Tue, 3 Sep 2013 03:03:10 +0400
>>> Driver supporting NAPI should use NAPI-specific function for receiving packets,
>>> so netif_rx() should be changed to netif_receive_skb().
>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> This patch breaks NFS boot on Armadillo800eva for me. Network
> communication slows down to a crawl with
> net eth0: Receive FIFO Overflow
> nfs: server 192.168.x.y not responding, still trying
> With this patch reverted (e.g. in today's Linus tree snapshot) boot is
> restored.
Guennadi, are you expecting some actions (like looking into what Eric have
suggested) from me? If so, I'm still on vacation, should be back next Tuesday.
I don't think reverting the patch is a Right Thing to do.
> Thanks
> Guennadi
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] moxa: fix the error handling in moxart_mac_probe()
From: David Miller @ 2013-10-08 20:53 UTC (permalink / raw)
To: weiyj.lk
Cc: grant.likely, rob.herring, jg1.han, b.zolnierkie, kyungmin.park,
yongjun_wei, netdev
In-Reply-To: <CAPgLHd95agB+cseQmD4wg50wX_ddyZ0=0VxJ8vAR80ZbcFsMTw@mail.gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Tue, 8 Oct 2013 11:19:19 +0800
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> This patch fix the error handling in moxart_mac_probe():
> - return -ENOMEM in some memory alloc fail cases
> - add missing free_netdev() in the error handling case
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Applied.
^ permalink raw reply
* Re: [PATCH] pkt_sched: fq: fix non TCP flows pacing
From: David Miller @ 2013-10-08 20:53 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, sesse
In-Reply-To: <1381182269.12191.27.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 07 Oct 2013 14:44:29 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> Steinar reported FQ pacing was not working for UDP flows.
>
> It looks like the initial sk->sk_pacing_rate value of 0 was
> a wrong choice. We should init it to ~0U like sk_max_pacing_rate
>
> Then, TCA_FQ_FLOW_DEFAULT_RATE should be removed because it makes
> no real sense. (The default rate is really : ~0U)
>
> While debugging this issue, I realized sk_pacing_rate is shared between
> transport and packet scheduler without locking / barriers :
>
> We should use ACCESS_ONCE() to make sure compiler wont perform
> multiple loads or stores.
>
> Reported-by: Steinar H. Gunderson <sesse@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Is this meant for net or net-next? It doesn't apply cleanly to the
former.
^ permalink raw reply
* Re: [PATCH] net: vlan: fix nlmsg size calculation in vlan_get_size()
From: David Miller @ 2013-10-08 20:53 UTC (permalink / raw)
To: mkl; +Cc: netdev, kernel, kaber
In-Reply-To: <1381180798-26654-1-git-send-email-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Mon, 7 Oct 2013 23:19:58 +0200
> This patch fixes the calculation of the nlmsg size, by adding the missing
> nla_total_size().
>
> Cc: Patrick McHardy <kaber@trash.net>
> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Applied.
^ permalink raw reply
* Re: [PATCH] pkt_sched: fq: fix typo for initial_quantum
From: David Miller @ 2013-10-08 20:52 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1381175418.12191.19.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 07 Oct 2013 12:50:18 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> TCA_FQ_INITIAL_QUANTUM should set q->initial_quantum
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ipv6: Fix the upper MTU limit in GRE tunnel
From: David Miller @ 2013-10-08 20:52 UTC (permalink / raw)
To: ou.ghorbel; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <1381168205-7465-1-git-send-email-ou.ghorbel@gmail.com>
From: Oussama Ghorbel <ou.ghorbel@gmail.com>
Date: Mon, 7 Oct 2013 18:50:05 +0100
> Unlike ipv4, the struct member hlen holds the length of the GRE and ipv6
> headers. This length is also counted in dev->hard_header_len.
> Perhaps, it's more clean to modify the hlen to count only the GRE header
> without ipv6 header as the variable name suggest, but the simple way to fix
> this without regression risk is simply modify the calculation of the limit
> in ip6gre_tunnel_change_mtu function.
> Verified in kernel version v3.11.
>
> Signed-off-by: Oussama Ghorbel <ou.ghorbel@gmail.com>
> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] cgroup: cls: remove unnecessary task_cls_classid
From: David Miller @ 2013-10-08 20:52 UTC (permalink / raw)
To: gaofeng-BthXqXjhjHXQFUHtdCDX3A
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, cgroups-u79uwXL29TY76Z2rM5mHXA,
jhs-jkUAjuhPggJWk0Htik3J/w, tj-DgEjT+Ai2ygdnm+yROfE0A,
nhorman-2XuSBdqkA4R54TAoqtyWWQ, lizefan-hv44wF8Li93QT0dZR+AlfA,
daniel.wagner-98C5kh4wR6ohFhg+JK9F0w
In-Reply-To: <1381201520-25938-2-git-send-email-gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
From: Gao feng <gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
Date: Tue, 8 Oct 2013 11:05:20 +0800
> We can get classid through cgroup_subsys_state,
> this is directviewing and effective.
>
> Signed-off-by: Gao feng <gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] cgroup: netprio: remove unnecessary task_netprioidx
From: David Miller @ 2013-10-08 20:52 UTC (permalink / raw)
To: gaofeng-BthXqXjhjHXQFUHtdCDX3A
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, cgroups-u79uwXL29TY76Z2rM5mHXA,
jhs-jkUAjuhPggJWk0Htik3J/w, tj-DgEjT+Ai2ygdnm+yROfE0A,
nhorman-2XuSBdqkA4R54TAoqtyWWQ, lizefan-hv44wF8Li93QT0dZR+AlfA,
daniel.wagner-98C5kh4wR6ohFhg+JK9F0w
In-Reply-To: <1381201520-25938-1-git-send-email-gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
From: Gao feng <gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
Date: Tue, 8 Oct 2013 11:05:19 +0800
> Since the tasks have been migrated to the cgroup,
> there is no need to call task_netprioidx to get
> task's cgroup id.
>
> Signed-off-by: Gao feng <gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v3 0/3] Improve UDP multicast receive latency
From: David Miller @ 2013-10-08 20:51 UTC (permalink / raw)
To: shawn.bohrer; +Cc: netdev, tomk, eric.dumazet, sbohrer
In-Reply-To: <1381161700-14453-1-git-send-email-shawn.bohrer@gmail.com>
From: Shawn Bohrer <shawn.bohrer@gmail.com>
Date: Mon, 7 Oct 2013 11:01:37 -0500
> From: Shawn Bohrer <sbohrer@rgmadvisors.com>
>
> The removal of the routing cache in 3.6 had impacted the latency of our
> UDP multicast workload. This patch series brings down the latency to
> what we were seeing with 3.4.
>
> Patch 1 "udp: Only allow busy read/poll on connected sockets" is mostly
> done for correctness and because it allows unifying the unicast and
> multicast paths when a socket is found in early demux. It can also
> improve latency for a connected multicast socket if busy read/poll is
> used.
>
> Patches 2&3 remove the fib lookups and restore latency for our workload
> to the pre 3.6 levels.
>
> Benchmark results from a netperf UDP_RR test:
> v3.12-rc3-447-g40dc9ab kernel 87961.22 transactions/s
> v3.12-rc3-447-g40dc9ab + series 90587.62 transactions/s
>
> Benchmark results from a fio 1 byte UDP multicast pingpong test
> (Multicast one way unicast response):
> v3.12-rc3-447-g40dc9ab kernel 12.97us RTT
> v3.12-rc3-447-g40dc9ab + series 12.48us RTT
Great work, all applied to net-next, thanks!
^ permalink raw reply
* Re: [PATCH net-next] net_sched: increment drop counters in qdisc_tree_decrease_qlen()
From: David Miller @ 2013-10-08 20:51 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1381159952.12191.14.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 07 Oct 2013 08:32:32 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> qdisc_tree_decrease_qlen() is called when some packets are dropped
> on a qdisc, and we want to notify parents of qlen changes.
>
> We also can increment parents qdisc qstats drop counters.
>
> This permits more accurate drop counters up to root qdisc.
>
> For example a graft operation typically resets a qdisc
> (drops all packets) and call qdisc_tree_decrease_qlen()
>
> Note that callers are responsible for their drop counters.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net V1 0/2] net/mlx4_en: Fix pages never dma unmapped on rx
From: David Miller @ 2013-10-08 20:10 UTC (permalink / raw)
To: amirv; +Cc: netdev, ogerlitz, eugenia, edumazet
In-Reply-To: <1381145893-20930-1-git-send-email-amirv@mellanox.com>
From: Amir Vadai <amirv@mellanox.com>
Date: Mon, 7 Oct 2013 13:38:11 +0200
> This patchset fixes a bug introduced by commit 51151a16 (mlx4: allow order-0
> memory allocations in RX path). Where dma_unmap_page wasn't called.
>
> Changes from V0:
> - Added "Rename name of mlx4_en_rx_alloc members". Old names were confusing.
> - Last frag in page calculation was wrong. Since all frags in page are of the
> same size, need to add this frag_stride to end of frag offset, and not the
> size of next frag in skb.
Series applied, thanks.
^ 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