* [PATCH 5/5] vt: move vt notifiers into vt.h
From: Amerigo Wang @ 2011-06-22 6:35 UTC (permalink / raw)
To: linux-kernel
Cc: akpm, netdev, Amerigo Wang, David S. Miller, Lucas De Marchi,
Paul E. McKenney, Josh Triplett
In-Reply-To: <1308724522-32461-1-git-send-email-amwang@redhat.com>
It is not necessary to share the same notifier.h.
Signed-off-by: WANG Cong <amwang@redhat.com>
---
include/linux/notifier.h | 9 ++-------
include/linux/vt.h | 7 +++++++
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/include/linux/notifier.h b/include/linux/notifier.h
index ae8f7d9..d65746e 100644
--- a/include/linux/notifier.h
+++ b/include/linux/notifier.h
@@ -193,6 +193,8 @@ static inline int notifier_to_errno(int ret)
/* Hibernation and suspend events are defined in include/linux/suspend.h. */
+/* Virtual Terminal events are defined in include/linux/vt.h. */
+
#define NETLINK_URELEASE 0x0001 /* Unicast netlink socket released */
/* Console keyboard events.
@@ -206,12 +208,5 @@ static inline int notifier_to_errno(int ret)
extern struct blocking_notifier_head reboot_notifier_list;
-/* Virtual Terminal events. */
-#define VT_ALLOCATE 0x0001 /* Console got allocated */
-#define VT_DEALLOCATE 0x0002 /* Console will be deallocated */
-#define VT_WRITE 0x0003 /* A char got output */
-#define VT_UPDATE 0x0004 /* A bigger update occurred */
-#define VT_PREWRITE 0x0005 /* A char is about to be written to the console */
-
#endif /* __KERNEL__ */
#endif /* _LINUX_NOTIFIER_H */
diff --git a/include/linux/vt.h b/include/linux/vt.h
index d5dd0bc..30a8dd9 100644
--- a/include/linux/vt.h
+++ b/include/linux/vt.h
@@ -86,6 +86,13 @@ struct vt_setactivate {
#ifdef __KERNEL__
+/* Virtual Terminal events. */
+#define VT_ALLOCATE 0x0001 /* Console got allocated */
+#define VT_DEALLOCATE 0x0002 /* Console will be deallocated */
+#define VT_WRITE 0x0003 /* A char got output */
+#define VT_UPDATE 0x0004 /* A bigger update occurred */
+#define VT_PREWRITE 0x0005 /* A char is about to be written to the console */
+
#ifdef CONFIG_VT_CONSOLE
extern int vt_kmsg_redirect(int new);
--
1.7.4.4
^ permalink raw reply related
* [PATCH v2] linux-firmware: update firmware for RTL8111E-VL
From: Hayes Wang @ 2011-06-22 6:40 UTC (permalink / raw)
To: dwmw2; +Cc: romieu, netdev, Hayes Wang
Updated firmware with stability fixes.
change version to rtl8168e-3_0.0.1.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
rtl_nic/rtl8168e-3.fw | Bin 2804 -> 3264 bytes
1 files changed, 0 insertions(+), 0 deletions(-)
diff --git a/rtl_nic/rtl8168e-3.fw b/rtl_nic/rtl8168e-3.fw
index cb494071d0273c7b3102b97552f4bc7b756c0e17..43d1b8641fb09d2f8dd91998ed78c1deb7c71a7a 100644
GIT binary patch
literal 3264
zcmaKvYiyKd7RR4XJEv1F2Cx-|%P_rAM4+9iSgT*G$Qn#^V@Nhxb+hmRKA3FcMoAX$
zr$R?<l^E|avDV%FqB0d(q94pMd@!2qCYvonBD=bIr?%kknwf+^%cW)foq68TS3{iS
z&3T^loXh{*p7$N+oO^Kh@A|U6eY-YZzdh5H>B^=vz1=-M-PtT>_Pd*BdA)N<x9!f}
zo@{3G_HDP`wf(jScJA7q&1QPDnRIs3%{_fLXEW{v=T@s*=G3_sS1G$R^r+kFv=M%{
zOTl-)uX8SNZlwvO)x}14I@611YPu%d{v+9?4xO|^wmFoIBQsrzt2(LLHhHPPMjLtF
zcP+Z3KdA?yZckD_F#1GN4?zz;nAE@6{>h{sw*5m%t*dL%xJzn1v>qCV&SjD+(3v-r
z+6euWJ+V}MIDEt`&hXjMy0nU+9}Ep{nI3OirVjs;MiWUrYqXNohIyXfY;-|VJB-5L
zZFCyB<^H^31r)tzqjSg^#oi{P=xqu4FB?U#iX(!-fx&pu962RdG0~Z=q5(OZsfg;R
z=oq}%v}jA6Xq~OwL`OAT-y(VseAA2lRrFu*hXc{#GosH9Ba>oZ6ip4mLvA?Ad(QKo
zkMj0o8@bP%=*MHC1II-tkBPpB%<z=x_)DUNdeQbl(HrqO-p(G{8SYE$6FJcmGV_e?
z5M5*xdy7MQ1T3XS^o%|v`U=!+JcAGSt>`;R(HB^kE(rbObuAa;myyHH@~CgHt_t@J
z_zupC4xyXQqu1=$F?8NoO&kI7c8ac@WL+W#){|4Bvuj1qH~75epBHUTv*z5f9zti&
zy`m$;6KfLvcU<%-%k`t8*&fk`S?_ay=yQ4%Hqp2JfXV$v^zZ9MH`;og=wa+M*!mUG
zzjcZ3v-M}957hkc7oFcK+Dg5L!5L$}iL({R1>bnPZNxSWj>$H^w|eK1OAvp1L~ms_
zjES>&hiFH57O*#bYif4Z{KO7<>5SMpw=rUeT&<0qJ!0{YgA3%nd=ZTIi#{FZ;@B=<
zum5(7_JTi!UV+%oh5H5UQ;R+Ce3ZAu^DaesS9{)T)X{8Jb*Zn}OAkhP*MI@ubM#aU
z*|rgCc#8bc>&@gNL(FA-{u&!23*gg-iC*~BxZy44WgNXRY7gx$us%ahZxnsCEILR3
z)nfezv0A(riMNg!Is7ZIaK0hLa)8+8Un@FjHmLhFKCV5$EZ>3LPSJG{x%-fF|MY!z
zU<b7Vf1AmIvG7aLPpEJ1i0Com{eoUN$$T{OB){bOia95S^0T79#cqZ5u7&h7eV1~g
zU*0bI6|#qTj!%FUUJaAQwTf5+Y!^NuKRM!K){|fGoJ1E}rfa^=9s(nA+WZ-IoBhl5
zo8{$G;<ntx>4S+2qW=SL@U`f@|EEsaNYNvw(joseXYglDrik90pS=LR0s5wsxP#?>
z-D+!M9<+Y4^;Le|ZtH~avkumlr&5pT%1J2sSp}VdJ{IB#9vAHk{pD|Bmbyf5q7TN&
zQ=v}u1o^gjV#IUoDe6W}`a-)g5nZxZbT8*~)+5ANq}R{VU)8xAAns1;#re#i!9^`C
zj#li);@oA}TsITSlD9Z{Xg1mRki9O9CzL(CM09;k_Gx50yx*A*MW;4+pSAm@nk&;I
zw^QJ+VQFG*ch-TkqV@P{$5-%rm_y`)CU3`bYr2=1tEw*8n!x(KZX0o%E<JAZ+!4{W
z{G0B_d#{|21o_wthCIC#TSMP73pIT6z_*XH>3O_o)^bjc*456zkN~q`$bZ8bve!k=
zz-M+wkum@4YiHytL9TLk24*|kz}e80=-cEW;ru+e+AN;%^K5y{mEa@){oRk9RK!jk
zJ*)fJ1a{9+kGgPwhW&i@oZ0<7MqiHN)A5+yi}c6+%!Qqmh(E?$mC?QYsy{Dr-UQFy
zOZV;byhZe!Gn_y3*t^Z%t+}G;YU((G&Bel=ILFvq@0+h#_!iSeX3B6BF5v_I!>k=O
zu{ln)!3W>B-M;q=?V@Ms1-n}plDm6;0p``r|7-aCT=XSoatU|MAD4>$2ixU}k7qWV
z-<q!yz6`?&a-qbMBj;t4e;9w*ypq2>{$lh(Wsi?-1-<buF_gQw>+tW;T|WYr0s7c#
z*yC$hy{n07!6MOv-02I+eF54%82L5<Lv3&0CWg)Ki>tvj{3p@R4-=RAxbjzs%kCw+
zf9zcuY~{XV?uUxpErtu*H-Kx%`iR<ADSYeS;t{YQo0|~*8hrNcW4X;+9@Ad7KGgXL
zooX*4SEa<Tn0`3b;=i48r@;)b#GM!YmYTzV^*)0Bp<lEgTmd!eX%oGhb#XU2-NH9v
z0H1noJBkfkp9JrnqMM6xi^0Cz7eSBq|72hLK6T;$fl9?W6w>y8p!SV#{{uGL|A2P?
OJ^RD|0{iy%zwZF4*F!x3
literal 2804
zcmaKuS!|S56vyvuXDEwdX=z8WolZ+xrAP=!Vq#-Nc`(M9m<Srf13vJiQ4@-BIfa&`
zMS>d`6R?UeXp0DaGtxc~Ow<@#AOWSxH%JAQw21-A(sulv@B5~F;_~q2-gE9*{^x(s
zJu}W#sjG16T$w8jxh!jsTkSNBzTQ=$cQ3}A^PHP)Mp<?7_Vv!~b}qHVg}!E6^Ecaa
zhfmgFTN>J?u(?)9sXFmvo4q7vYMSp0SElP4GJ2TRHD>fnTi?j&5!S;mW%Q`YZ)UX1
z<d-uVi<N20Wi-K>U`?@(F3G5{4)4oon)L)SwfH$4IpT&j{MJ>M`xqL)kaQJVo32nd
zmeFOlj%KvBf^`JhR%G8V;^Xi!U9={r)D{;VUM=cT<8VP#+eHtdi(eBhi;2c;pA)Sw
z?jICg!`}SjJ4FwwXqzXR-!8hN4f{&uyl7=BI_%n_I_ypNR#dl3v>n|y<p1iBXwxat
z3;RXi!KQ6MwD(=n?u6*u&7v#F*;|9m`d%mxB1?<tAT|?NyVr?s$Jbp3TSjy@`@tK+
zJ+hL+YU~}uj{Wv%Ov4(=Nn(1}1Dx4T{7QqpakQ4Y5{;rIU`!bYKZ`!FS#&A;k^4li
zCyC>Uc2d{fS<x&!wq3vud0vy~Li71fbpE}>v3-~5`}i!j{kNhoMEoaJi&jVcmvJ@=
zJMWU{F6zpG?OF=Ha)DgTI|2MP5x?2sDxRfkMQg(|4@?$kPBG4$JL1%d)<xo61@m~E
zxuSC;XRpG4azyk7ybaw1;|9@f#5Vr=o)7r`tzL9F_$%@2rnal0JQ=xiTA;fg)lCm{
zx1zckfo^YA5X<-Fek|Uu=7?@47|`wHzT(*CxUbe<xfgn{6h4-KYlxgrgJ=I_^lAEM
zIr_EK@ezI8iy!^ySnIpl{|TonME4Adj?zEHT7RHctM?}L#^~Lyr@+Gbhar|uYI}5^
zXtTxG%YBh!UWe$9&mhxJ)tmW{JGe)CXOEN9!}i#5aBd|}pJ?U`-&xUfVC<)-(|kL2
zh^_}q`Z>`l1<_~W*uniHmDrx+>lZzL1Ra>VW1@S(WAEn>y>aXw(c|>!R`T@0-I=85
z*)VR=_XxR8UBMrWMeJ7p5Vei%;X6UUk8<DO_Rfp`^1J9C#7x6q0zR|g@ZkGmsP{O_
z(;uU(N%I4%^-@O@@1*YbzLY!j^(~@zWpD4Tr+xi4c&g>S!PA97V$BX$YVvWsCi*&Y
z{e1U}u4KQMyY8F?Pb-6at+u;39o*+;<AfR0F$o>^LR{0uPx98b1U1^5Zp{-DKAPz1
zI^xBt`_mkEIUL~Xq>dEWYw#UDi0ypQmazZL_H%e%P_(7C6!lCu+l$yP4Bkp@7<VIi
z7h&5vKz?$L&lGYb;Hnxwk2AwkjgMC%dWAmE(ns-x=m*3$t~$w60*9^aJBX72-wgA;
z6=180_~t_2o4h&S7oJPtdEA$nTksu$-+$x7n?Nst+n*(tgPtG9H&JwAb1*Mb?Ysdy
zkMLu@m%wke_-6|u_&Cc_XQJpA;mZ6RH5ShX76m-GkD2kD*^EC;&DQrL;2-23%|40V
z=DW=&<J_ZHP4CEIcXfa|uF?mwP(F%02{|6hUn3`wE$@g6_^=re-@u#UtYr{i^foI-
zcrV76=^SsW*|5;FzRu%K2ycemu_}6Rzvuun$>b#Qi*bsx#&X;uM+^NsM4Y}&<Redx
zFHQ~qoVpzJ^$hEAW|qyHRZ~Q()-VIWbF!cJ1~>im{8Vz-`~JVLoPJ1tB3k(VpR;cq
z549yM4sWVk$qW8X<XXk|Uzp~?dm}aE3&HPpjQ6?tvjF3!v&>}THF4M7;BBXOiog9s
zF>vEIZ8AI_W~DZNKJ5$Yws{?ujYFHW#^(WkJG!`Y<!z7G1&-)U&tto>L9`)HUyyrg
zPV@=(`B&iJVbPyF^k9Cnhkmj>Slwfy59L$Fqy2}R%G%R#hg|&c<--4_g@POZZ(97n
VdHX+Uxf?6kf6?+D|9>1#e*sYqwB!H)
--
1.7.3.2
^ permalink raw reply
* Re: [PATCH 0/5] notifiers: split notifier.h into subsystem headers
From: David Miller @ 2011-06-22 6:42 UTC (permalink / raw)
To: amwang; +Cc: linux-kernel, akpm, netdev
In-Reply-To: <1308724522-32461-1-git-send-email-amwang@redhat.com>
From: Amerigo Wang <amwang@redhat.com>
Date: Wed, 22 Jun 2011 14:35:17 +0800
> Now we define all kinds of notifiers in notifier.h, this is not
> necessary at all, since different subsystems use different
> notifiers, they are almost non-related with each other.
>
> This can also save much build time. Suppose I add a new netdevice
> event, really I don't have to recompile all the source, just network
> related. Without this patch, all the source will be recompiled.
>
> I move the notify events near to their subsystem notifier registers,
> so that they can be found more easily.
>
> In case of conflicts, I hope Andrew Morton would take the whole
> patchset, rather than different subsystem maintainers take their own.
>
> Signed-off-by: WANG Cong <amwang@redhat.com>
For networking bits:
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [RFC PATCH] packet: Add fanout support.
From: Victor Julien @ 2011-06-22 6:49 UTC (permalink / raw)
To: Changli Gao; +Cc: David Miller, netdev
In-Reply-To: <BANLkTinxvHbkCLehJkqoCfryeTqL0zhWiw@mail.gmail.com>
On 06/22/2011 03:44 AM, Changli Gao wrote:
> On Wed, Jun 22, 2011 at 5:39 AM, David Miller <davem@davemloft.net> wrote:
>> From: Victor Julien <victor@inliniac.net>
>> Date: Tue, 21 Jun 2011 15:27:54 +0200
>>
>>> From a Suricata IDS point of view, I would need to have the
>>> fragments of a flow/tuple on the same socket.
>>
>> Currently you would, they would all go to the first socket in
>> the fanout.
>>
>
> I think he also needs all the packets belong to the related
> connections are received via the same socket. I am afraid that he has
> to dispatch these kind of packets among the uesrland processes again.
> :)
>
Indeed. Although in Suricata we *could* work around it as we distribute
the flows over threads, not processes. It would still be messy. For this
to be useful to a tool like Snort (I'm sure they're interested) I think
this would be a deal breaker.
--
---------------------------------------------
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
---------------------------------------------
^ permalink raw reply
* RE: [PATCH net-next 5/7] qlcnic: fix default operating state of interface
From: Amit Salecha @ 2011-06-22 7:01 UTC (permalink / raw)
To: Stephen Hemminger, David Miller; +Cc: Anirban Chakraborty, netdev
In-Reply-To: <20110617120012.6feb524d@nehalam.ftrdhcpuser.net>
> -----Original Message-----
> From: Stephen Hemminger [mailto:shemminger@vyatta.com]
>
> David Miller <davem@davemloft.net> wrote:
>
> > From: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
> > Date: Thu, 16 Jun 2011 13:37:36 -0700
> >
> > > From: Amit Kumar Salecha <amit.salecha@qlogic.com>
> > >
> > > Currently interface shows status as RUNNING, even if there is no
> link.
> > > To fix this, netif_carrier_off should be called after
> register_netdev().
> > >
> > > netif_carrier_off calls linkwatch_fire_event(dev); only if netdev
> is registered,
> > > otherwise it skips. linkwatch_fire_event set default state of nic
> interface.
> > >
> > > Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
> > > Signed-off-by: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
> >
> > You cannot do this.
> >
> > The exact second that register_netdev() is called, the device can
> > be brought up asynchronously and the link brought into the up state.
> >
> > Your netif_carrier_off() call will race with this.
> >
> > This is why no other (properly functioning) driver does what you're
> > trying to do here.
>
> The proper place to do this is in the open() routine.
> When device is not open, the carrier state is undefined; and devices
> that are trying to save power turn off PHY when device is not in use.
>
> Therefore the open() routine should ensure that the carrier is in
> the proper state when returning. Just doing something like:
>
> static int qlcnic_open() {
> ...
> netif_carrier_off()
>
> err = __qlcnic_up();
> ...
> }
>
> static int __qlcnic_up() {
> ...
> (lots of tests)
> ...
>
> netif_carrier_on();
> adapter->reset_context = 0;
> set_bit(__QLCNIC_DEV_UP, &adapter->state);
> return 0;
> }
netif_carrier_off() is ok, should be call from qlcnic_open().
netif_carrier_on() will be call during asynchronous notification from fw.
-Thanks.
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Remove Sven Eckelmann from BATMAN ADVANCED
From: Sven Eckelmann @ 2011-06-22 7:41 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <20110621.143515.1651926143381429168.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2763 bytes --]
On Tuesday 21 June 2011 14:35:15 David Miller wrote:
> From: Sven Eckelmann <sven-KaDOiPu9UxWEi8DpZVb4nw@public.gmane.org>
> Date: Tue, 21 Jun 2011 15:13:03 +0200
>
> > I cannot speak on behalf of the batman-adv developers due to conflicts
> > in the opinion about the ongoing development. The batman-adv module is
> > still maintained by Marek Lindner and Simon Wunderlich. Those are the
> > main persons behind the visions of batman-adv. Therefore, the state of
> > module hasn't changed.
> >
> > Signed-off-by: Sven Eckelmann <sven-KaDOiPu9UxWEi8DpZVb4nw@public.gmane.org>
> > Cc: b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r@public.gmane.org
>
> You have to be kidding me.
Thanks for the warm welcome :)
> All of this effort was placed to get this thing merged into the
> main tree, and then moved out of staging.
"Shooting the messenger" - I think that is the matching phrase. Just try to
grep my name in the net/batman-adv/ and you will see it nowhere. The problem
is that I am probably the most unimportant person in the whole project. But at
least I was good enough to send some patches around which were accepted or
made by other people. I was also not the person behind the whole Linux-merge
thing, but only some kind of marionette.
> And now you're just going to give up and jump ship and take exactly
> zero responsibility for that burdon you've placed upon us?
This is your interpretation. I would say that I don't take zero responsibility
for the stuff which is not yet part of the tree (of course still take
responsibilities for the stuff with my name in it). I never said that
completely run away, but that I am no longer the person which is send to the
enemy general to bring bad news. Desertion to the enemy or bringing bad news -
the end result for me is the same.
At least I tried to only do only one step backwards instead of running
silently away in the night never to be seen again.
> You make me feel like a real idiot for sticking around and maintaining
> the Linux networking for more than 15 years. Maybe 13 years ago I
> should have stepped down just because I disagreed with a few other
> people.
Sry, never wanted to say that it is bad to disagree with other people or that
you are a bad person/maintainer.
Disagreeing with everyone else and pushing your opinion until the end against
anybody makes the person a dictator (could be a good or bad one). Disagreeing
with everyone and not being man enough to stand for it makes me a moron.
Maybe I am an incompetent idiot, but at least this time I stand behind my
opinion. Please think everything bad about me, but not that I didn't try to
explain my position instead of going into stealth mode (which would have been
a lot easier solution).
thanks,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH]: Add Network Sysrq Support
From: WANG Cong @ 2011-06-22 7:55 UTC (permalink / raw)
To: netdev
In-Reply-To: <20110621130040.12035.62533.sendpatchset@prarit.bos.redhat.com>
On Tue, 21 Jun 2011 09:00:40 -0400, Prarit Bhargava wrote:
> Add Network Sysrq Support
>
> In some circumstances, a system can hang/lockup in such a way that the
> system is completely unresponsive to keyboard or console input but is
> still responsive to ping. The config option, CONFIG_SYSRQ_PING, builds
> net/ipv4/sysrq-ping.ko which allows a root user to configure the system
> for a remote sysrq.
>
Cool work, Prarit! Now we have remote sysrq!
I am just wondering why the module is in net/ipv4/sysrq-ping.c?
Not drivers/net/sysrq-ping.c? or perhaps net/core/sysrq-ping.c?
I understand it only supports IPv4 now, but we can add IPv6 support,
can't we? ;)
Thanks!
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Remove Sven Eckelmann from BATMAN ADVANCED
From: David Miller @ 2011-06-22 8:16 UTC (permalink / raw)
To: sven-KaDOiPu9UxWEi8DpZVb4nw
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <28453742.RFlbu1Gcpv-1RWNDQYo44h8XcdJbWeDu3TFMtCCXL7YSoIsB4E12gc@public.gmane.org>
From: Sven Eckelmann <sven-KaDOiPu9UxWEi8DpZVb4nw@public.gmane.org>
Date: Wed, 22 Jun 2011 09:41:45 +0200
> On Tuesday 21 June 2011 14:35:15 David Miller wrote:
>> All of this effort was placed to get this thing merged into the
>> main tree, and then moved out of staging.
>
> "Shooting the messenger" - I think that is the matching phrase. Just try to
> grep my name in the net/batman-adv/ and you will see it nowhere.
It is everywhere as far as I am concerned, because you're the only person
actually keeping upstream maintained and in sync.
> The problem is that I am probably the most unimportant person in the
> whole project.
>From my perspective, this is not true. You are the most important
person. And this is because the people writing the code obviously
don't care enough about upstream to do any merges themselves. Yet
you do.
> But at least I was good enough to send some patches around which
> were accepted or made by other people. I was also not the person
> behind the whole Linux-merge thing, but only some kind of
> marionette.
When we agree to allow someone to merge something into the tree,
especially a significant piece of code like batman-adv, there are some
impressions we want to have beforehand.
And one such impression we want is that there is going to be someone
continuing to be active maintaing the code upstream, even after the
code is merged.
Otherwise we get "merge and run" scenerios. As networking maintainer,
I've been burnt by this several times.
If you're the only person who had the energy and motivation to do the
merges of this code, then you're only person we know that can keep up
with the expectations we had when we agreed to merge the code.
If you step down, that trust has been broken, and we're left with a
rotting pile of poo in the tree because it's unlikely anyone else is
going to step up and keep things maintained upstream as you did.
^ permalink raw reply
* Re: [PATCH v2 net-next af-packet 0/2] Enhance af-packet to provide (near zero)lossless packet capture functionality.
From: David Miller @ 2011-06-22 8:35 UTC (permalink / raw)
To: loke.chetan
Cc: netdev, eric.dumazet, joe, bhutchings, shemminger, linux-kernel
In-Reply-To: <1308708650-25509-1-git-send-email-loke.chetan@gmail.com>
From: Chetan Loke <loke.chetan@gmail.com>
Date: Tue, 21 Jun 2011 22:10:48 -0400
> Please review the patchset.
This is interesting work but it's going to take some time for something
this involved to get sufficient review, please be patient.
^ permalink raw reply
* Re: [PATCH] gianfar v5: implement nfc
From: Sebastian Pöhn @ 2011-06-22 9:29 UTC (permalink / raw)
To: Joe Perches; +Cc: Sebastian Pöhn, Linux Netdev
First of all thanks for the feedback. I know the fgar_swap_*bits
function is a bit ugly. The problem with your suggestion is that it is
necessary to swap a1<>a2 and b1<>b2 AT THE SAME TIME. Otherwise
information the second swap is needing is swapped away by the first one.
If you would do this as a macro I guess it will be blown up and be as
bad as it is at the moment:
#define swap_bits(a, b, c, d, bits) \
do { \
typeof(a) _bits = bits; \
typeof(a) _a_bits = (a) & _bits; \
typeof(a) _b_bits = (b) & _bits; \
typeof(a) _c_bits = (c) & _bits; \
typeof(a) _d_bits = (d) & _bits; \
\
(a) &= ~_bits; \
(b) &= ~_bits; \
(c) &= ~_bits; \
(d) &= ~_bits; \
\
(a) |= _b_bits; \
(b) |= _a_bits; \
(c) |= _d_bits; \
(d) |= _c_bits; \
} while (0)
> > +/* Swaps the 0xFF80 masked bits of a1<>a2 and b1<>b2 */
> > +static void gfar_swap_ff80_bits(struct gfar_filer_entry *a1,
> > + struct gfar_filer_entry *a2, struct gfar_filer_entry *b1,
> > + struct gfar_filer_entry *b2)
> > +{
> > + u32 temp[4];
> > + temp[0] = a1->ctrl & 0xFF80;
> > + temp[1] = a2->ctrl & 0xFF80;
> > + temp[2] = b1->ctrl & 0xFF80;
> > + temp[3] = b2->ctrl & 0xFF80;
> > +
> > + a1->ctrl &= ~0xFF80;
> > + a2->ctrl &= ~0xFF80;
> > + b1->ctrl &= ~0xFF80;
> > + b2->ctrl &= ~0xFF80;
> > +
> > + a1->ctrl |= temp[1];
> > + a2->ctrl |= temp[0];
> > + b1->ctrl |= temp[3];
> > + b2->ctrl |= temp[2];
> > +}
>
> maybe add a macro similar to swap:
>
> #define swap_bits(a, b, bits) \
> do { \
> typeof(a) _bits = bits; \
> typeof(a) _a_bits = (a) & _bits; \
> typeof(a) _b_bits = (b) & _bits; \
> \
> (a) &= ~_bits; \
> (b) &= ~_bits; \
> \
> (a) |= _b_bits; \
> (b) |= _a_bits; \
> } while (0)
>
> and use this macro directly in gfar_sort_mask_table?
>
> swap_bits(temp_table->fe[new_first],
> temp_table->fe[old_first], 0xff80);
> swap_bits(temp_table->fe[new_last],
> temp_table->fe[old_last], 0xff80);
>
> And maybe 0xff80 should be a #define?
Signed-off-by: Sebastian Poehn <sebastian.poehn@belden.com>
---
drivers/net/gianfar.h | 1 +
drivers/net/gianfar_ethtool.c | 29 ++++++++++++++++-------------
2 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
index 76f14d0..27499c6 100644
--- a/drivers/net/gianfar.h
+++ b/drivers/net/gianfar.h
@@ -409,6 +409,7 @@ extern const char gfar_driver_version[];
#define RQFCR_HASHTBL_2 0x00060000
#define RQFCR_HASHTBL_3 0x00080000
#define RQFCR_HASH 0x00010000
+#define RQFCR_QUEUE 0x0000FC00
#define RQFCR_CLE 0x00000200
#define RQFCR_RJE 0x00000100
#define RQFCR_AND 0x00000080
diff --git a/drivers/net/gianfar_ethtool.c b/drivers/net/gianfar_ethtool.c
index 2ecdc9a..ee93bb8 100644
--- a/drivers/net/gianfar_ethtool.c
+++ b/drivers/net/gianfar_ethtool.c
@@ -1262,21 +1262,21 @@ static void gfar_cluster_filer(struct filer_table *tab)
}
}
-/* Swaps the 0xFF80 masked bits of a1<>a2 and b1<>b2 */
-static void gfar_swap_ff80_bits(struct gfar_filer_entry *a1,
+/* Swaps the masked bits of a1<>a2 and b1<>b2 */
+static void gfar_swap_bits(struct gfar_filer_entry *a1,
struct gfar_filer_entry *a2, struct gfar_filer_entry *b1,
- struct gfar_filer_entry *b2)
+ struct gfar_filer_entry *b2, u32 mask)
{
u32 temp[4];
- temp[0] = a1->ctrl & 0xFF80;
- temp[1] = a2->ctrl & 0xFF80;
- temp[2] = b1->ctrl & 0xFF80;
- temp[3] = b2->ctrl & 0xFF80;
+ temp[0] = a1->ctrl & mask;
+ temp[1] = a2->ctrl & mask;
+ temp[2] = b1->ctrl & mask;
+ temp[3] = b2->ctrl & mask;
- a1->ctrl &= ~0xFF80;
- a2->ctrl &= ~0xFF80;
- b1->ctrl &= ~0xFF80;
- b2->ctrl &= ~0xFF80;
+ a1->ctrl &= ~mask;
+ a2->ctrl &= ~mask;
+ b1->ctrl &= ~mask;
+ b2->ctrl &= ~mask;
a1->ctrl |= temp[1];
a2->ctrl |= temp[0];
@@ -1356,10 +1356,13 @@ static void gfar_sort_mask_table(struct gfar_mask_entry *mask_table,
new_first = mask_table[start].start + 1;
new_last = mask_table[i - 1].end;
- gfar_swap_ff80_bits(&temp_table->fe[new_first],
+ gfar_swap_bits(&temp_table->fe[new_first],
&temp_table->fe[old_first],
&temp_table->fe[new_last],
- &temp_table->fe[old_last]);
+ &temp_table->fe[old_last],
+ RQFCR_QUEUE | RQFCR_CLE |
+ RQFCR_RJE | RQFCR_AND
+ );
start = i;
size = 0;
^ permalink raw reply related
* Re: [PATCH]: Add Network Sysrq Support
From: Prarit Bhargava @ 2011-06-22 10:26 UTC (permalink / raw)
To: David Miller; +Cc: fw, fbl, netdev, agospoda, nhorman, lwoodman
In-Reply-To: <20110621.155816.1840729860084652508.davem@davemloft.net>
On 06/21/2011 06:58 PM, David Miller wrote:
> From: Florian Westphal <fw@strlen.de>
> Date: Wed, 22 Jun 2011 00:56:45 +0200
>
>
>> Flavio Leitner <fbl@redhat.com> wrote:
>>
>>> What about a whitelist of source MAC or IP addresses to accept the sysrq?
>>>
>> This is one of the reasons why I still think that
>> xt_SYSREQ would be the better solution, you get all
>> kinds of filtering features for free.
>>
>> You could even use crazy things like '-m time' to restrict
>> sysreq availability to working hours and whatnot.
>>
> Agreed.
>
It is not the same thing. At least AFAICT ... I have a system in which
we're experiencing random pauses. That is, unlike a hang or a
softlockup the system just (for lack of a better word) slows down.
Typing through the keyboard is lagged as is output on the console.
Running the date command in the background shows that the date is not
updated for 30-40 seconds. I got lucky this morning, logged in an
noticed that the system I've been watching was in this state :)
Using the ping, I can get a sysrq-c/t/m/whatever into the system
immediately.
Using the netfilter xt-SYSRQ code seems to store the entered code and
execute it later after the system has returned to a normal state....
which is much too late to be useful.
I want/need an *immediate* way to sysrq the machine.
P.
^ permalink raw reply
* Re: [PATCH]: Add Network Sysrq Support
From: David Miller @ 2011-06-22 10:35 UTC (permalink / raw)
To: prarit; +Cc: fw, fbl, netdev, agospoda, nhorman, lwoodman
In-Reply-To: <4E01C34F.6050009@redhat.com>
From: Prarit Bhargava <prarit@redhat.com>
Date: Wed, 22 Jun 2011 06:26:23 -0400
> Using the netfilter xt-SYSRQ code seems to store the entered code and
> execute it later after the system has returned to a normal state....
> which is much too late to be useful.
So add a feature that allows xt-SYSRQ to not queue the request
and instead execute it immediately in softirq context.
I don't see what the big deal is.
^ permalink raw reply
* Re: [PATCH]: Add Network Sysrq Support
From: Prarit Bhargava @ 2011-06-22 10:42 UTC (permalink / raw)
To: David Miller; +Cc: fw, fbl, netdev, agospoda, nhorman, lwoodman
In-Reply-To: <20110622.033502.2198841895093553350.davem@davemloft.net>
On 06/22/2011 06:35 AM, David Miller wrote:
> From: Prarit Bhargava <prarit@redhat.com>
> Date: Wed, 22 Jun 2011 06:26:23 -0400
>
>
>> Using the netfilter xt-SYSRQ code seems to store the entered code and
>> execute it later after the system has returned to a normal state....
>> which is much too late to be useful.
>>
> So add a feature that allows xt-SYSRQ to not queue the request
> and instead execute it immediately in softirq context.
>
> I don't see what the big deal is.
>
I'm not familiar with the netfilter code and was about to ask some other
colleagues about it ... but I think you answered my main question which
was "does netfilter do things in interrupt context?"
P.
^ permalink raw reply
* Re: [PATCH]: Add Network Sysrq Support
From: Florian Westphal @ 2011-06-22 10:54 UTC (permalink / raw)
To: Prarit Bhargava
Cc: David Miller, fbl, netdev, agospoda, nhorman, lwoodman,
john.haxby
In-Reply-To: <4E01C34F.6050009@redhat.com>
Prarit Bhargava <prarit@redhat.com> wrote:
[ cc'd John Haxby, who worked on xt_SYSREQ ]
> On 06/21/2011 06:58 PM, David Miller wrote:
> > From: Florian Westphal <fw@strlen.de>
> > Date: Wed, 22 Jun 2011 00:56:45 +0200
> >> This is one of the reasons why I still think that
> >> xt_SYSREQ would be the better solution, you get all
> >> kinds of filtering features for free.
> >>
> >> You could even use crazy things like '-m time' to restrict
> >> sysreq availability to working hours and whatnot.
> >>
> > Agreed.
> Using the netfilter xt-SYSRQ code seems to store the entered code and
> execute it later after the system has returned to a normal state....
> which is much too late to be useful.
The target handler of the kernel part invokes handle_sysrq(),
I don't see any delaying/queueing?
FWIW, the old discussion is in the archives:
search for subject "nf-next: sysrq and condition 20100421" from Jan
Engelhardt, or try
http://thread.gmane.org/gmane.comp.security.firewalls.netfilter.devel/33615/focus=34808
As far as i understand the use case described by John Haxby matches yours.
Patrick McHardy suggested an alternative standalone method involving
encapsulation sockets; perhaps the reasons why this path was not chosen
have changed.
I think that a standalone module (i.e. not requiring netfilter) that
runs the sysreq handling after all netfilter hooks would be optimal,
but I don't see a simple method to implement that.
^ permalink raw reply
* Re: [PATCH 2/3] ipv4: Fix packet size calculation for IPsec packets in __ip_append_data
From: Steffen Klassert @ 2011-06-22 11:02 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, herbert, netdev
In-Reply-To: <20110609.144704.1705676110990397845.davem@davemloft.net>
On Thu, Jun 09, 2011 at 02:47:04PM -0700, David Miller wrote:
> From: Steffen Klassert <steffen.klassert@secunet.com>
> Date: Wed, 8 Jun 2011 07:30:20 +0200
>
> > In between I can confirm that we get the slowpath problem back with my
> > patch, so we still have a bug somewhere. Reverting your commit would
> > be just a band aid. I think it is better to find the bug and do a real
> > fix instead. Unfortunatly I fear I'm not able to track it down before
> > my vacation that starts tomorrow. I'll continue to work at it once I'm
> > back...
>
> Thanks Steffen, looking forward to this.
In between I found the problem. In ip_setup_cork() we take the mtu on the
base of dst_mtu(rt->dst.path) and assign it to cork->fragsize which is
used as the mtu in __ip_append_data(). The path dst_entry is a routing
dst_entry that does not take the IPsec header and trailer overhead into
account. So if we build an IPsec packet based on this mtu it might be to
big after the IPsec transformations are applied. If we take the actual
IPsec mtu from dst_mtu(&rt->dst) and adapt the exthdr handling to this,
it works as expected. So I'll send two patches, one that reverts Eric's
patch and one that fixes the slowpath issue.
While reading through the code of __ip_append_data() I noticed that we
might use ip_ufo_append_data() for packets that will be IPsec transformed
later, is this ok? I don't know how ufo handling works, but I would guess
that it expects an udp header and not an IPsec header as the packets
transport header.
I found another funny thing when I tested my patches:
I use an IPsec tunnel with tunnel endpoints 192.168.1.1 and 192.168.1.2
Then I do at 192.168.1.2
ping -c20 -M do -s 1500 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 1500(1528) bytes of data.
>From 192.168.1.1 icmp_seq=1 Frag needed and DF set (mtu = 1438)
>From 192.168.1.1 icmp_seq=1 Frag needed and DF set (mtu = 1438)
>From 192.168.1.1 icmp_seq=1 Frag needed and DF set (mtu = 1374)
>From 192.168.1.1 icmp_seq=1 Frag needed and DF set (mtu = 1310)
>From 192.168.1.1 icmp_seq=1 Frag needed and DF set (mtu = 1246)
>From 192.168.1.1 icmp_seq=1 Frag needed and DF set (mtu = 1182)
>From 192.168.1.1 icmp_seq=1 Frag needed and DF set (mtu = 1118)
>From 192.168.1.1 icmp_seq=1 Frag needed and DF set (mtu = 1054)
>From 192.168.1.1 icmp_seq=1 Frag needed and DF set (mtu = 990)
>From 192.168.1.1 icmp_seq=1 Frag needed and DF set (mtu = 926)
>From 192.168.1.1 icmp_seq=1 Frag needed and DF set (mtu = 862)
>From 192.168.1.1 icmp_seq=1 Frag needed and DF set (mtu = 798)
>From 192.168.1.1 icmp_seq=1 Frag needed and DF set (mtu = 734)
>From 192.168.1.1 icmp_seq=1 Frag needed and DF set (mtu = 670)
>From 192.168.1.1 icmp_seq=1 Frag needed and DF set (mtu = 606)
>From 192.168.1.1 icmp_seq=1 Frag needed and DF set (mtu = 552)
>From 192.168.1.1 icmp_seq=1 Frag needed and DF set (mtu = 494)
>From 192.168.1.1 icmp_seq=1 Frag needed and DF set (mtu = 494)
>From 192.168.1.1 icmp_seq=1 Frag needed and DF set (mtu = 494)
>From 192.168.1.1 icmp_seq=1 Frag needed and DF set (mtu = 494)
--- 192.168.1.1 ping statistics ---
0 packets transmitted, 0 received, +20 errors
These packets are locally generated and not from 192.168.1.1 as they
claim to be. I think the problem is the following:
The IPsec mtu is 1438 here, so the first packet is too big.
xfrm4_tunnel_check_size() notices this and sends a ICMP_FRAG_NEEDED
packet that announces a mtu of 1438 to the original sender of the ping
packet. Unfortunately the sender is a local address, it's the IPsec
tunnel entry point. So we update the mtu for this connection to 1438.
Now, with the next packet xfrm_bundle_ok() notices that the path mtu has
changed, so it subtracts the IPsec overhead from the mtu a second time
and we end up with a mtu of 1374. This game goes until we reach a minimal
mtu of 494.
Unfortunately I don't know how to fix this. Any ideas?
^ permalink raw reply
* [PATCH v2 1/2] ipv4: Fix packet size calculation in __ip_append_data
From: Steffen Klassert @ 2011-06-22 11:04 UTC (permalink / raw)
To: David Miller, Eric Dumazet, Herbert Xu; +Cc: netdev
Git commit 59104f06 (ip: take care of last fragment in ip_append_data)
added a check to see if we exceed the mtu when we add trailer_len.
However, the mtu is already subtracted by the trailer length when the
xfrm transfomation bundles are set up. So IPsec packets with mtu
size get fragmented, or if the DF bit is set the packets will not
be send even though they match the mtu perfectly fine. This patch
actually reverts commit 59104f06.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/ipv4/ip_output.c | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index a8024ea..6b894d4 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -888,12 +888,9 @@ alloc_new_skb:
* because we have no idea what fragment will be
* the last.
*/
- if (datalen == length + fraggap) {
+ if (datalen == length + fraggap)
alloclen += rt->dst.trailer_len;
- /* make sure mtu is not reached */
- if (datalen > mtu - fragheaderlen - rt->dst.trailer_len)
- datalen -= ALIGN(rt->dst.trailer_len, 8);
- }
+
if (transhdrlen) {
skb = sock_alloc_send_skb(sk,
alloclen + hh_len + 15,
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/2] ipv4: Fix IPsec slowpath fragmentation problem
From: Steffen Klassert @ 2011-06-22 11:05 UTC (permalink / raw)
To: David Miller, Eric Dumazet, Herbert Xu; +Cc: netdev
In-Reply-To: <20110622110437.GG6489@secunet.com>
ip_append_data() builds packets based on the mtu from dst_mtu(rt->dst.path).
On IPsec the effective mtu is lower because we need to add the protocol
headers and trailers later when we do the IPsec transformations. So after
the IPsec transformations the packet might be too big, which leads to a
slowpath fragmentation then. This patch fixes this by building the packets
based on the lower IPsec mtu from dst_mtu(&rt->dst) and adapts the exthdr
handling to this.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/ipv4/ip_output.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 6b894d4..4a7e16b 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -802,8 +802,6 @@ static int __ip_append_data(struct sock *sk,
skb = skb_peek_tail(queue);
exthdrlen = !skb ? rt->dst.header_len : 0;
- length += exthdrlen;
- transhdrlen += exthdrlen;
mtu = cork->fragsize;
hh_len = LL_RESERVED_SPACE(rt->dst.dev);
@@ -883,6 +881,8 @@ alloc_new_skb:
else
alloclen = fraglen;
+ alloclen += exthdrlen;
+
/* The last fragment gets additional space at tail.
* Note, with MSG_MORE we overallocate on fragments,
* because we have no idea what fragment will be
@@ -923,11 +923,11 @@ alloc_new_skb:
/*
* Find where to start putting bytes.
*/
- data = skb_put(skb, fraglen);
+ data = skb_put(skb, fraglen + exthdrlen);
skb_set_network_header(skb, exthdrlen);
skb->transport_header = (skb->network_header +
fragheaderlen);
- data += fragheaderlen;
+ data += fragheaderlen + exthdrlen;
if (fraggap) {
skb->csum = skb_copy_and_csum_bits(
@@ -1061,7 +1061,7 @@ static int ip_setup_cork(struct sock *sk, struct inet_cork *cork,
*/
*rtp = NULL;
cork->fragsize = inet->pmtudisc == IP_PMTUDISC_PROBE ?
- rt->dst.dev->mtu : dst_mtu(rt->dst.path);
+ rt->dst.dev->mtu : dst_mtu(&rt->dst);
cork->dst = &rt->dst;
cork->length = 0;
cork->tx_flags = ipc->tx_flags;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH]: Add Network Sysrq Support
From: Prarit Bhargava @ 2011-06-22 12:19 UTC (permalink / raw)
To: Florian Westphal
Cc: David Miller, fbl, netdev, agospoda, nhorman, lwoodman,
john.haxby
In-Reply-To: <20110622105434.GE16021@Chamillionaire.breakpoint.cc>
On 06/22/2011 06:54 AM, Florian Westphal wrote:
> Prarit Bhargava <prarit@redhat.com> wrote:
>
> [ cc'd John Haxby, who worked on xt_SYSREQ ]
>
>
>> On 06/21/2011 06:58 PM, David Miller wrote:
>>
>>> From: Florian Westphal <fw@strlen.de>
>>> Date: Wed, 22 Jun 2011 00:56:45 +0200
>>>
>>>> This is one of the reasons why I still think that
>>>> xt_SYSREQ would be the better solution, you get all
>>>> kinds of filtering features for free.
>>>>
>>>> You could even use crazy things like '-m time' to restrict
>>>> sysreq availability to working hours and whatnot.
>>>>
>>>>
>>> Agreed.
>>>
>> Using the netfilter xt-SYSRQ code seems to store the entered code and
>> execute it later after the system has returned to a normal state....
>> which is much too late to be useful.
>>
> The target handler of the kernel part invokes handle_sysrq(),
> I don't see any delaying/queueing?
>
Yeah ... It just occurred to me on the way into the office that I made a
mistake.
... What if the "slow down" I'm seeing is due to the network layer? ...
but why would ping work and the xt_SYSRQ not work?
Either way ... I have a feeling that I'm on to something,
P.
^ permalink raw reply
* Re: [PATCH]: Add Network Sysrq Support
From: John Haxby @ 2011-06-22 12:37 UTC (permalink / raw)
To: Florian Westphal
Cc: Prarit Bhargava, David Miller, fbl, netdev, agospoda, nhorman,
lwoodman
In-Reply-To: <20110622105434.GE16021@Chamillionaire.breakpoint.cc>
On 22/06/11 11:54, Florian Westphal wrote:
> Prarit Bhargava <prarit@redhat.com> wrote:
>
> [ cc'd John Haxby, who worked on xt_SYSREQ ]
>
>> On 06/21/2011 06:58 PM, David Miller wrote:
>>> From: Florian Westphal <fw@strlen.de>
>>> Date: Wed, 22 Jun 2011 00:56:45 +0200
>>>> This is one of the reasons why I still think that
>>>> xt_SYSREQ would be the better solution, you get all
>>>> kinds of filtering features for free.
>>>>
>>>> You could even use crazy things like '-m time' to restrict
>>>> sysreq availability to working hours and whatnot.
>>>>
>>> Agreed.
>> Using the netfilter xt-SYSRQ code seems to store the entered code and
>> execute it later after the system has returned to a normal state....
>> which is much too late to be useful.
> The target handler of the kernel part invokes handle_sysrq(),
> I don't see any delaying/queueing?
>
> FWIW, the old discussion is in the archives:
> search for subject "nf-next: sysrq and condition 20100421" from Jan
> Engelhardt, or try
> http://thread.gmane.org/gmane.comp.security.firewalls.netfilter.devel/33615/focus=34808
>
> As far as i understand the use case described by John Haxby matches yours.
>
> Patrick McHardy suggested an alternative standalone method involving
> encapsulation sockets; perhaps the reasons why this path was not chosen
> have changed.
>
> I think that a standalone module (i.e. not requiring netfilter) that
> runs the sysreq handling after all netfilter hooks would be optimal,
> but I don't see a simple method to implement that.
The xt_SYSRQ calls handle_sysrq() in BH context, much the same context
as ping is handled in. (Actually, it's likely xt_SYSRQ will work even
if ping doesn't since nothing has to come back.)
It's possible for xt_SYSRQ to fail. My usual case for failure was
simply not enabling it :-) However, as you typically have to fight your
way through iptables to get to xt_SYSRQ then you can get into trouble
that way.
Although I wasn't sure that it could happen, it's also possible that the
cryptographic functions can get in your way. xt_SYSRQ does its best to
avoid problems by pre-allocating everything it can so there is as little
as possible to do when it is needed, but it is possible for it to fail.
The module that Patrick McHardy suggested works up to a point:
handle_sysrq() can still be called in BH context but unfortunately I
couldn't get it working for IPv6: the necessary hook isn't implemented
for IPv6 (or rather, it wasn't, I don't know if something has changed
since then).
jch
^ permalink raw reply
* Re: net/ipv4: commit d0733d2e29b breaks rtorrent
From: Marcus Meissner @ 2011-06-22 12:47 UTC (permalink / raw)
To: Fabienne Ducroquet
Cc: sundell.software, Reinhard Max, David S. Miller, netdev
In-Reply-To: <20110622124045.GA3247@localhost>
On Wed, Jun 22, 2011 at 02:40:45PM +0200, Fabienne Ducroquet wrote:
> Hi,
>
> With the latest versions of the Linux kernel (I've just tried
> 3.0.0-rc4-00034-g2992c4b) rtorrent (version 0.8.7 with libtorrent
> 0.12.7, from Debian unstable) fails to start with the error message:
>
> rtorrent: Could not open/bind port for listening: Invalid argument
>
> I bisected it down to:
>
> commit d0733d2e29b652b2e7b1438ececa732e4eed98eb
> Author: Marcus Meissner <meissner@suse.de>
> Date: Wed Jun 1 21:05:22 2011 -0700
>
> net/ipv4: Check for mistakenly passed in non-IPv4 address
>
> Check against mistakenly passing in IPv6 addresses (which would result
> in an INADDR_ANY bind) or similar incompatible sockaddrs.
>
> Signed-off-by: Marcus Meissner <meissner@suse.de>
> Cc: Reinhard Max <max@suse.de>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
> net/ipv4/af_inet.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> index cc14631..9c19260 100644
> --- a/net/ipv4/af_inet.c
> +++ b/net/ipv4/af_inet.c
> @@ -465,6 +465,9 @@ int inet_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
> if (addr_len < sizeof(struct sockaddr_in))
> goto out;
>
> + if (addr->sin_family != AF_INET)
> + goto out;
> +
> chk_addr_ret = inet_addr_type(sock_net(sk), addr->sin_addr.s_addr);
>
> /* Not specified by any standard per-se, however it breaks too
>
> With this commit reverted rtorrent works again.
Can you show us the code surrounding the bind in rtorrent?
You either do not set the sin_family member, or pass in a ipv6 address.
Ciao, Marcus
^ permalink raw reply
* net/ipv4: commit d0733d2e29b breaks rtorrent
From: Fabienne Ducroquet @ 2011-06-22 12:40 UTC (permalink / raw)
To: Marcus Meissner; +Cc: sundell.software, Reinhard Max, David S. Miller, netdev
Hi,
With the latest versions of the Linux kernel (I've just tried
3.0.0-rc4-00034-g2992c4b) rtorrent (version 0.8.7 with libtorrent
0.12.7, from Debian unstable) fails to start with the error message:
rtorrent: Could not open/bind port for listening: Invalid argument
I bisected it down to:
commit d0733d2e29b652b2e7b1438ececa732e4eed98eb
Author: Marcus Meissner <meissner@suse.de>
Date: Wed Jun 1 21:05:22 2011 -0700
net/ipv4: Check for mistakenly passed in non-IPv4 address
Check against mistakenly passing in IPv6 addresses (which would result
in an INADDR_ANY bind) or similar incompatible sockaddrs.
Signed-off-by: Marcus Meissner <meissner@suse.de>
Cc: Reinhard Max <max@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/ipv4/af_inet.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index cc14631..9c19260 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -465,6 +465,9 @@ int inet_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
if (addr_len < sizeof(struct sockaddr_in))
goto out;
+ if (addr->sin_family != AF_INET)
+ goto out;
+
chk_addr_ret = inet_addr_type(sock_net(sk), addr->sin_addr.s_addr);
/* Not specified by any standard per-se, however it breaks too
With this commit reverted rtorrent works again.
Fabienne
^ permalink raw reply
* [PATCH 3/7] qlcnic: Add code to tune FW dump
From: Anirban Chakraborty @ 2011-06-22 12:52 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Anirban Chakraborty
In-Reply-To: <1308747144-23785-1-git-send-email-anirban.chakraborty@qlogic.com>
To accommodate change in FW dump template, it is required to modify the
FW dump routine that captures cache data. Also, the default mask is changed
to capture a dump that would cover all the protocols that this FW supports.
Signed-off-by: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
---
drivers/net/qlcnic/qlcnic.h | 5 ++---
drivers/net/qlcnic/qlcnic_hw.c | 14 +++++++++++---
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/net/qlcnic/qlcnic.h b/drivers/net/qlcnic/qlcnic.h
index 194376e..e5bb332 100644
--- a/drivers/net/qlcnic/qlcnic.h
+++ b/drivers/net/qlcnic/qlcnic.h
@@ -1220,8 +1220,7 @@ struct __ctrl {
struct __cache {
__le32 addr;
- u8 stride;
- u8 rsvd;
+ __le16 stride;
__le16 init_tag_val;
__le32 size;
__le32 no_ops;
@@ -1319,7 +1318,7 @@ enum op_codes {
#define QLCNIC_DUMP_SKIP BIT_7
#define QLCNIC_DUMP_MASK_MIN 3
-#define QLCNIC_DUMP_MASK_DEF 0x0f
+#define QLCNIC_DUMP_MASK_DEF 0x7f
#define QLCNIC_DUMP_MASK_MAX 0xff
#define QLCNIC_FORCE_FW_DUMP_KEY 0xdeadfeed
diff --git a/drivers/net/qlcnic/qlcnic_hw.c b/drivers/net/qlcnic/qlcnic_hw.c
index 1947f81..81de563 100644
--- a/drivers/net/qlcnic/qlcnic_hw.c
+++ b/drivers/net/qlcnic/qlcnic_hw.c
@@ -1509,18 +1509,26 @@ qlcnic_dump_l2_cache(struct qlcnic_adapter *adapter,
for (i = 0; i < l2->no_ops; i++) {
QLCNIC_WR_DUMP_REG(l2->addr, base, val);
- do {
+ if (LSW(l2->ctrl_val))
QLCNIC_WR_DUMP_REG(l2->ctrl_addr, base,
LSW(l2->ctrl_val));
+ if (!poll_mask)
+ goto skip_poll;
+ do {
QLCNIC_RD_DUMP_REG(l2->ctrl_addr, base, &data);
if (!(data & poll_mask))
break;
msleep(1);
time_out++;
} while (time_out <= poll_to);
- if (time_out > poll_to)
- return -EINVAL;
+ if (time_out > poll_to) {
+ dev_err(&adapter->pdev->dev,
+ "Timeout exceeded in %s, aborting dump\n",
+ __func__);
+ return -EINVAL;
+ }
+skip_poll:
addr = l2->read_addr;
cnt = l2->read_addr_num;
while (cnt) {
--
1.7.4.1
^ permalink raw reply related
* [PATCH 2/7] qlcnic: Remove holding api lock while taking the dump
From: Anirban Chakraborty @ 2011-06-22 12:52 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Anirban Chakraborty
In-Reply-To: <1308747144-23785-1-git-send-email-anirban.chakraborty@qlogic.com>
With the change in logic for taking FW dump across multiple drivers,
there is no need to hold onto the api lock anymore in the fw dump path.
Instead use rtnl_lock() to synchronize the access to FW dump data structs.
Signed-off-by: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
---
drivers/net/qlcnic/qlcnic_ethtool.c | 6 ------
drivers/net/qlcnic/qlcnic_main.c | 8 +++++---
2 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/net/qlcnic/qlcnic_ethtool.c b/drivers/net/qlcnic/qlcnic_ethtool.c
index 8ea8001..e183ed2 100644
--- a/drivers/net/qlcnic/qlcnic_ethtool.c
+++ b/drivers/net/qlcnic/qlcnic_ethtool.c
@@ -986,8 +986,6 @@ qlcnic_get_dump_data(struct net_device *netdev, struct ethtool_dump *dump,
struct qlcnic_adapter *adapter = netdev_priv(netdev);
struct qlcnic_fw_dump *fw_dump = &adapter->ahw->fw_dump;
- if (qlcnic_api_lock(adapter))
- return -EIO;
if (!fw_dump->clr) {
netdev_info(netdev, "Dump not available\n");
qlcnic_api_unlock(adapter);
@@ -1009,7 +1007,6 @@ qlcnic_get_dump_data(struct net_device *netdev, struct ethtool_dump *dump,
vfree(fw_dump->data);
fw_dump->data = NULL;
fw_dump->clr = 0;
- qlcnic_api_unlock(adapter);
return 0;
}
@@ -1032,10 +1029,7 @@ qlcnic_set_dump(struct net_device *netdev, struct ethtool_dump *val)
ret = -EINVAL;
goto out;
}
- if (qlcnic_api_lock(adapter))
- return -EIO;
fw_dump->tmpl_hdr->drv_cap_mask = val->flag & 0xff;
- qlcnic_api_unlock(adapter);
netdev_info(netdev, "Driver mask changed to: 0x%x\n",
fw_dump->tmpl_hdr->drv_cap_mask);
}
diff --git a/drivers/net/qlcnic/qlcnic_main.c b/drivers/net/qlcnic/qlcnic_main.c
index 0ddbb80..a656a12 100644
--- a/drivers/net/qlcnic/qlcnic_main.c
+++ b/drivers/net/qlcnic/qlcnic_main.c
@@ -2846,13 +2846,15 @@ skip_ack_check:
set_bit(__QLCNIC_START_FW, &adapter->state);
QLCDB(adapter, DRV, "Restarting fw\n");
qlcnic_idc_debug_info(adapter, 0);
- QLCDB(adapter, DRV, "Take FW dump\n");
- qlcnic_dump_fw(adapter);
- adapter->flags &= ~QLCNIC_FW_RESET_OWNER;
}
qlcnic_api_unlock(adapter);
+ rtnl_lock();
+ QLCDB(adapter, DRV, "Take FW dump\n");
+ qlcnic_dump_fw(adapter);
+ adapter->flags &= ~QLCNIC_FW_RESET_OWNER;
+ rtnl_unlock();
if (!adapter->nic_ops->start_firmware(adapter)) {
qlcnic_schedule_work(adapter, qlcnic_attach_work, 0);
adapter->fw_wait_cnt = 0;
--
1.7.4.1
^ permalink raw reply related
* [PATCH 5/7] qlcnic: fix default operating state of interface
From: Anirban Chakraborty @ 2011-06-22 12:52 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Amit Kumar Salecha
In-Reply-To: <1308747144-23785-1-git-send-email-anirban.chakraborty@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Currently interface shows status as RUNNING, even if there is no link.
To fix this, netif_carrier_off should be called qlcnic_open().
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Signed-off-by: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
---
drivers/net/qlcnic/qlcnic_main.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/qlcnic/qlcnic_main.c b/drivers/net/qlcnic/qlcnic_main.c
index a050746..5dcb853 100644
--- a/drivers/net/qlcnic/qlcnic_main.c
+++ b/drivers/net/qlcnic/qlcnic_main.c
@@ -1485,8 +1485,6 @@ qlcnic_setup_netdev(struct qlcnic_adapter *adapter,
netdev->irq = adapter->msix_entries[0].vector;
- netif_carrier_off(netdev);
-
err = register_netdev(netdev);
if (err) {
dev_err(&pdev->dev, "failed to register net device\n");
@@ -1816,6 +1814,8 @@ static int qlcnic_open(struct net_device *netdev)
struct qlcnic_adapter *adapter = netdev_priv(netdev);
int err;
+ netif_carrier_off(netdev);
+
err = qlcnic_attach(adapter);
if (err)
return err;
--
1.7.4.1
^ permalink raw reply related
* [PATCH 1/7] qlcnic: Add capability to take FW dump deterministically
From: Anirban Chakraborty @ 2011-06-22 12:52 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Sritej Velaga
From: Sritej Velaga <sritej.velaga@qlogic.com>
In presence of multiple functions, current driver implementation does not
guarantee that the FW dump is taken by the same function that forces it.
Change it by adding a fw reset owner flag that could be changed in the device
reset path and only when a function determines that it needs to reset it.
Signed-off-by: Sritej Velaga <sritej.velaga@qlogic.com>
Signed-off-by: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
---
drivers/net/qlcnic/qlcnic.h | 1 +
drivers/net/qlcnic/qlcnic_ctx.c | 4 ++--
drivers/net/qlcnic/qlcnic_main.c | 32 ++++++++++++++++++++++++--------
3 files changed, 27 insertions(+), 10 deletions(-)
diff --git a/drivers/net/qlcnic/qlcnic.h b/drivers/net/qlcnic/qlcnic.h
index 480ef5c..194376e 100644
--- a/drivers/net/qlcnic/qlcnic.h
+++ b/drivers/net/qlcnic/qlcnic.h
@@ -895,6 +895,7 @@ struct qlcnic_ipaddr {
#define QLCNIC_MAC_OVERRIDE_DISABLED 0x400
#define QLCNIC_PROMISC_DISABLED 0x800
#define QLCNIC_NEED_FLR 0x1000
+#define QLCNIC_FW_RESET_OWNER 0x2000
#define QLCNIC_IS_MSI_FAMILY(adapter) \
((adapter)->flags & (QLCNIC_MSI_ENABLED | QLCNIC_MSIX_ENABLED))
diff --git a/drivers/net/qlcnic/qlcnic_ctx.c b/drivers/net/qlcnic/qlcnic_ctx.c
index c77024f..be2dee1 100644
--- a/drivers/net/qlcnic/qlcnic_ctx.c
+++ b/drivers/net/qlcnic/qlcnic_ctx.c
@@ -95,8 +95,8 @@ int qlcnic_fw_cmd_get_minidump_temp(struct qlcnic_adapter *adapter)
QLCNIC_CDRP_CMD_TEMP_SIZE);
if (err != QLCNIC_RCODE_SUCCESS) {
err = QLCRD32(adapter, QLCNIC_ARG1_CRB_OFFSET);
- dev_err(&adapter->pdev->dev,
- "Failed to get template size %d\n", err);
+ dev_info(&adapter->pdev->dev,
+ "Can't get template size %d\n", err);
err = -EIO;
return err;
}
diff --git a/drivers/net/qlcnic/qlcnic_main.c b/drivers/net/qlcnic/qlcnic_main.c
index 347a4a8..0ddbb80 100644
--- a/drivers/net/qlcnic/qlcnic_main.c
+++ b/drivers/net/qlcnic/qlcnic_main.c
@@ -1590,10 +1590,6 @@ qlcnic_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
/* This will be reset for mezz cards */
adapter->portnum = adapter->ahw->pci_func;
- /* Get FW dump template and store it */
- if (adapter->op_mode != QLCNIC_NON_PRIV_FUNC)
- qlcnic_fw_cmd_get_minidump_temp(adapter);
-
err = qlcnic_get_board_info(adapter);
if (err) {
dev_err(&pdev->dev, "Error getting board config info.\n");
@@ -1612,6 +1608,12 @@ qlcnic_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
goto err_out_decr_ref;
}
+ /* Get FW dump template and store it */
+ if (adapter->op_mode != QLCNIC_NON_PRIV_FUNC)
+ if (!qlcnic_fw_cmd_get_minidump_temp(adapter))
+ dev_info(&pdev->dev,
+ "Supports FW dump capability\n");
+
if (qlcnic_read_mac_addr(adapter))
dev_warn(&pdev->dev, "failed to read mac addr\n");
@@ -2683,11 +2685,16 @@ err:
static int
qlcnic_check_drv_state(struct qlcnic_adapter *adapter)
{
- int act, state;
+ int act, state, active_mask;
state = QLCRD32(adapter, QLCNIC_CRB_DRV_STATE);
act = QLCRD32(adapter, QLCNIC_CRB_DRV_ACTIVE);
+ if (adapter->flags & QLCNIC_FW_RESET_OWNER) {
+ active_mask = (~(1 << (adapter->ahw->pci_func * 4)));
+ act = act & active_mask;
+ }
+
if (((state & 0x11111111) == (act & 0x11111111)) ||
((act & 0x11111111) == ((state >> 1) & 0x11111111)))
return 0;
@@ -2826,6 +2833,11 @@ qlcnic_fwinit_work(struct work_struct *work)
if (!qlcnic_check_drv_state(adapter)) {
skip_ack_check:
+ if (!(adapter->flags & QLCNIC_FW_RESET_OWNER)) {
+ qlcnic_api_unlock(adapter);
+ goto wait_npar;
+ }
+
dev_state = QLCRD32(adapter, QLCNIC_CRB_DEV_STATE);
if (dev_state == QLCNIC_DEV_NEED_RESET) {
@@ -2836,6 +2848,7 @@ skip_ack_check:
qlcnic_idc_debug_info(adapter, 0);
QLCDB(adapter, DRV, "Take FW dump\n");
qlcnic_dump_fw(adapter);
+ adapter->flags &= ~QLCNIC_FW_RESET_OWNER;
}
qlcnic_api_unlock(adapter);
@@ -2900,9 +2913,11 @@ qlcnic_detach_work(struct work_struct *work)
if (adapter->temp == QLCNIC_TEMP_PANIC)
goto err_ret;
-
- if (qlcnic_set_drv_state(adapter, adapter->dev_state))
- goto err_ret;
+ /* Dont ack if this instance is the reset owner */
+ if (!(adapter->flags & QLCNIC_FW_RESET_OWNER)) {
+ if (qlcnic_set_drv_state(adapter, adapter->dev_state))
+ goto err_ret;
+ }
adapter->fw_wait_cnt = 0;
@@ -2947,6 +2962,7 @@ qlcnic_dev_request_reset(struct qlcnic_adapter *adapter)
if (state == QLCNIC_DEV_READY) {
QLCWR32(adapter, QLCNIC_CRB_DEV_STATE, QLCNIC_DEV_NEED_RESET);
+ adapter->flags |= QLCNIC_FW_RESET_OWNER;
QLCDB(adapter, DRV, "NEED_RESET state set\n");
qlcnic_idc_debug_info(adapter, 0);
}
--
1.7.4.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox