* Re: [PATCH v2] ipv6/tcp: Stop processing ICMPv6 redirect messages
From: David Miller @ 2013-04-07 16:36 UTC (permalink / raw)
To: eric.dumazet
Cc: christoph.paasch, netdev, djduanjiong, steffen.klassert,
ncardwell, hannes
In-Reply-To: <1365346942.3887.6.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 07 Apr 2013 08:02:22 -0700
> On Sun, 2013-04-07 at 16:53 +0200, Christoph Paasch wrote:
>> Tetja Rediske found that if the host receives an ICMPv6 redirect message
>> after sending a SYN+ACK, the connection will be reset.
>>
>> He bisected it down to 093d04d (ipv6: Change skb->data before using
>> icmpv6_notify() to propagate redirect), but the origin of the bug comes
>> from ec18d9a26 (ipv6: Add redirect support to all protocol icmp error
>> handlers.). The bug simply did not trigger prior to 093d04d, because
>> skb->data did not point to the inner IP header and thus icmpv6_notify
>> did not call the correct err_handler.
>>
>> This patch adds the missing "goto out;" in tcp_v6_err. After receiving
>> an ICMPv6 Redirect, we should not continue processing the ICMP in
>> tcp_v6_err, as this may trigger the removal of request-socks or setting
>> sk_err(_soft).
>>
>> Reported-by: Tetja Rediske <tetja@tetja.de>
>> Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
>> ---
>> v2: Removed code-cleanup from the patch and improved the commit-message upon
>> suggestion from Eric Dumazet.
>>
>> net/ipv6/tcp_ipv6.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
>> index 1033d2b..e51bd1a 100644
>> --- a/net/ipv6/tcp_ipv6.c
>> +++ b/net/ipv6/tcp_ipv6.c
>> @@ -386,6 +386,7 @@ static void tcp_v6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
>>
>> if (dst)
>> dst->ops->redirect(dst, sk, skb);
>> + goto out;
>> }
>>
>> if (type == ICMPV6_PKT_TOOBIG) {
>
>
> Thanks for sorting this out.
>
> Acked-by: Eric Dumazet <edumazet@google.com>
Applied and queued up for -stable, thanks everyone!
^ permalink raw reply
* Re: [PATCH 00/16] info leak fixes in recvmsg
From: David Miller @ 2013-04-07 20:31 UTC (permalink / raw)
To: minipli
Cc: netdev, allan.stephens, aloisio.almeida, acking, acme, dtor,
georgezhang, gustavo, johan.hedberg, jon.maloy, lauro.venancio,
marcel, ralf, sameo, samuel, sjur.brandeland, ursula.braun,
spender
In-Reply-To: <1365335522-29931-1-git-send-email-minipli@googlemail.com>
From: Mathias Krause <minipli@googlemail.com>
Date: Sun, 7 Apr 2013 13:51:46 +0200
> a few more info leak fixes in the recvmsg path. The error pattern here
> is the protocol specific recvmsg function is missing the msg_namelen
> assignment -- either completely or in early exit paths that do not
> result in errors in __sys_recvmsg()/sys_recvfrom() and, in turn, make
> them call move_addr_to_user(), leaking the then still uninitialized
> sockaddr_storage stack variable to userland.
>
> My audit was initiated by a rather coarse fix of the leak that can be
> found in the grsecurity patch, putting a penalty on protocols complying
> to the rules of recvmsg. So credits for finding the leak in the recvmsg
> path in __sys_recvmsg() should go to Brad!
>
> The buggy protocols/subsystems are rather obscure anyway. As a missing
> assignment of msg_namelen coupled with a missing filling of msg_name
> would only result in garbage -- the leak -- in case userland would care
> about that information, i.e. would provide a msg_name pointer. But
> obviously current userland does not.
>
> While auditing the code for the above pattern I found a few more
> 'uninitialized members' kind of leaks related to the msg_name filling.
> Those are fixed in this series, too.
>
> I have to admit, I failed to test all of the patches due to missing
> hardware, e.g. iucv depends on S390 -- hardware I've no access to :/
All applied and queued up for -stable, thanks!
^ permalink raw reply
* Re: [PATCH v2 net-next 1/8] r8169: Remove firmware code
From: David Miller @ 2013-04-07 20:45 UTC (permalink / raw)
To: romieu; +Cc: hayeswang, netdev, linux-kernel
In-Reply-To: <20130404234229.GA13629@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Fri, 5 Apr 2013 01:42:29 +0200
> David Miller <davem@davemloft.net> :
> [...]
>> If so, should I just apply this series as-is ?
>
> Yes.
>
> - the series is imho -stable unfriendly: whoever wants to figure what
> should be fed into a -stable branch will have a hard time. :o/
> - the driver could had been more careful about firmware version/magic
> checks and firmware opcodes recycling. It's a bit late. It won't
> necessarily hurt.
> - there is a whole release cycle ahead to find problems - if any - due
> to the hw_start flow change. It seems sane.
> - the relative amount of binary like cruft is going down.
>
> I am not overflowed with enthusiasm but the gain should exceed the pain.
All applied to net-next, thanks!
^ permalink raw reply
* Re: [PATCH 1/7] net: ieee802154: mrf24j40: use spi_get_drvdata() and spi_set_drvdata()
From: David Miller @ 2013-04-07 20:48 UTC (permalink / raw)
To: jg1.han; +Cc: netdev
In-Reply-To: <000c01ce3290$c44c0980$4ce41c80$%han@samsung.com>
All applied to net-next, thanks.
^ permalink raw reply
* Sähköposti Alert
From: WebMail Järjestelmänvalvoja @ 2013-04-07 20:40 UTC (permalink / raw)
Postilaatikko on ylittänyt varastointi rajan 2.GB
Määrittelee ylläpito on tällä hetkellä 2.30GB, ei voi lähettää tai vastaanottaa uusia viestejä ennen kuin olet uudelleen Vahvista sähköpostiosoite lähettää tiedon edellytetyt uudelleen vahvistat sähköpostiosoitteen
E-mail:
Käyttäjätunnus:
salasana:
Vahvista salasana:
jona viimeinen merkintä:
E-mail: upgrade@execs.com
System Manager
^ permalink raw reply
* Re: [PATCH 2/2] at86rf230: change irq handling to prevent lockups with edge type irq
From: Sascha Herrmann @ 2013-04-07 20:52 UTC (permalink / raw)
To: Werner Almesberger; +Cc: netdev, linux-zigbee-devel
In-Reply-To: <20130406142035.GG28141@ws>
On 06.04.2013 16:20, Werner Almesberger wrote:
> Sascha Herrmann wrote:
>> The trigger level isn't configurable in the rf230,
>
> Right, I should have mentioned that the polarity can only be set on
> the AT86RF231. The 230 has to make do with rising edge or high level.
Oh, I didn't realized, that this is possible at all with the rf231...
>> I fear the sollution to read the interrupt status register in a loop
>> (as suggested in your earlier message) would leave chances for race
>> conditions or spurious interrupts, depending on wheter interrupts are
>> enabled before or after reading the status register.
>
> I don't think the analysis is worse than for any other solution.
> There are also tools and methods that can help if it becomes too
> much of a headache.
>
> If you don't like the loop, a double read without loop would work in
> this case as well:
>
> irq = read_and_clear_interrupt();
> enable_irq();
> irq |= read_and_clear_interrupt();
> ...
Maybe one way to eliminate the extra latency of the second register read
would be to split the interrupt handling function into a generic part
and two different functions to handle the different types of interrupts:
static void at86rf230_irqwork_level(void) {
__at86rf230_irqwork();
spin_lock_irqsave(&lp->lock, flags);
lp->irq_busy = 0;
enable_irq()
spin_unlock_irqrestore(&lp->lock, flags);
}
For edge type configuration the call to enable_irq() must be removed.
The same would be required for the isr function. The probe function
could than decide, which isr function should be registered for the
interrupt.
> By the way, once we switch to early RX_ON, I think we'll have the
> problem that two TRX_END interrupts may be generated without any
> host action between them, in which case the first will be
> interpreted as the end of sending and the second will be ignored,
> leaving a received frame in the buffer, which in turn leaves
> dynamic buffer protection on and thus prevents any further
> reception.
I think this is right, we should have an eye on this when working on the
early RX_ON...
> Not sure yet how to solve this. I also don't know how bad our
> latencies are, but I fear that they can at times be substantial.
> Already a single register access with spi-gpio takes some 80 us
> (measured on an otherwise idle Ben, 336 MHz MIPS).
>
>> Surely for this option, the assumption that (at least nearly) every
>> platform supports edge type interrupts should hold.
>
> I think you're on relatively safe ground with the assumption that
> most relevant platforms per se can do it. But if the interrupt line
> happens to be shared with some other device, then level trigger is
> quite popular.
If you think the solution above would be ok, I could try to send a
version which allows the configuration of trigger type and level.
Thanks,
Sascha
--
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me
spread!
^ permalink raw reply
* Re: [PATCH net-next 0/4] netxen_nic: Bug fixes and enhancement
From: David Miller @ 2013-04-07 20:53 UTC (permalink / raw)
To: manish.chopra; +Cc: netdev, rajesh.borundia, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1365165403-18348-1-git-send-email-manish.chopra@qlogic.com>
From: Manish Chopra <manish.chopra@qlogic.com>
Date: Fri, 5 Apr 2013 08:36:39 -0400
> netxen_nic: Add module parameters support to switch interrupts
I'm not letting you add more module parameters to this driver,
sorry.
You guys really have to define reasonable infrastructure for
these sorts of interrupt configurations that all drivers use.
It must be a facility which uses a reasonable configuration mechanism,
which can be standardized across all drivers.
Module parameters do not meet those requirements.
I've rejected this entire patch series, you'll need to resubmit
it without the module parameter change.
^ permalink raw reply
* Re: [PATCH V1 net-next 0/3] Mellanox Core and Ethernet driver updates 2013-04-07
From: David Miller @ 2013-04-07 20:56 UTC (permalink / raw)
To: ogerlitz; +Cc: netdev, amirv, sagig, john.r.fastabend
In-Reply-To: <1365342248-31901-1-git-send-email-ogerlitz@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
Date: Sun, 7 Apr 2013 16:44:05 +0300
> Hi Dave,
>
> Here's V1 of this batch of mlx4 driver updates for 3.10, mostly DCB related.
>
> Series done against the net-next tree as of commit a210576c "Merge
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net"
>
> changes from V0:
>
> - in patch #2 advertize getdcbx/setdcbx callbacks also for devices that support only PFC
>
> - per feedback from John, dropeed patch #3 which turned to be work-around for user space
> bug in open-lldp. John posted a user space patch to fix the bug
>
> - per feedback from John, added small a patch under which we advertize DCB_CAP_DCBX_HOST in getdcbx
All applied, thanks.
^ permalink raw reply
* Re: [PATCH V1 net-next 3/3] net/mlx4_en: Advertize DCB_CAP_DCBX_HOST in getdcbx
From: David Miller @ 2013-04-07 20:56 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: ogerlitz, netdev, amirv, sagig, john.r.fastabend
In-Reply-To: <5161914F.8020801@cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Sun, 07 Apr 2013 19:31:27 +0400
>> @@ -186,7 +186,7 @@ static int mlx4_en_dcbnl_ieee_setpfc(struct
>> net_device *dev,
>>
>> static u8 mlx4_en_dcbnl_getdcbx(struct net_device *dev)
>> {
>> - return DCB_CAP_DCBX_VER_IEEE;
>> + return (DCB_CAP_DCBX_HOST | DCB_CAP_DCBX_VER_IEEE);
>
> Nit: parens not needed here.
I made this simplification when I applied this patch, thanks.
^ permalink raw reply
* Re: [PATCH v2 net-next] vxlan: Bypass encapsulation if the destination is local
From: David Miller @ 2013-04-07 21:00 UTC (permalink / raw)
To: sri; +Cc: shemminger, dlstevens, netdev
In-Reply-To: <1364941912.29336.36.camel@oc1677441337.ibm.com>
From: Sridhar Samudrala <sri@us.ibm.com>
Date: Tue, 02 Apr 2013 15:31:52 -0700
> This patch bypasses vxlan encapsulation if the destination vxlan
> endpoint is a local device.
>
> Changes since v1: added missing check for vxlan_find_vni() failure
>
> Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
Applied, but...
> + if (!dst_vxlan)
> + goto tx_error;
^^
Trailing whitespace. We have many tools which will warn you about
things like this.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] sctp: remove 'sridhar' from maintainers list
From: David Miller @ 2013-04-07 21:01 UTC (permalink / raw)
To: sri; +Cc: vyasevich, nhorman, netdev
In-Reply-To: <1364942131.29336.41.camel@oc1677441337.ibm.com>
From: Sridhar Samudrala <sri@us.ibm.com>
Date: Tue, 02 Apr 2013 15:35:31 -0700
> Update SCTP maintainers list.
>
> Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
Applied to 'net', thanks.
^ permalink raw reply
* Re: [PATCH net-next] selftests: net: add PF_PACKET TPACKET v1/v2/v3 selftests
From: David Miller @ 2013-04-07 21:02 UTC (permalink / raw)
To: dborkman; +Cc: netdev
In-Reply-To: <1364943651-3346-1-git-send-email-dborkman@redhat.com>
From: Daniel Borkmann <dborkman@redhat.com>
Date: Wed, 3 Apr 2013 01:00:51 +0200
> This patch adds a simple test case that probes the packet socket's
> TPACKET_V1, TPACKET_V2 and TPACKET_V3 behavior regarding mmap(2)'ed
> I/O for a small burst of 100 packets. The test currently runs for ...
>
> TPACKET_V1: RX_RING, TX_RING
> TPACKET_V2: RX_RING, TX_RING
> TPACKET_V3: RX_RING
>
> ... and will output on success:
>
> test: TPACKET_V1 with PACKET_RX_RING .................... 100 pkts (9600 bytes)
> test: TPACKET_V1 with PACKET_TX_RING .................... 100 pkts (9600 bytes)
> test: TPACKET_V2 with PACKET_RX_RING .................... 100 pkts (9600 bytes)
> test: TPACKET_V2 with PACKET_TX_RING .................... 100 pkts (9600 bytes)
> test: TPACKET_V3 with PACKET_RX_RING .................... 100 pkts (9600 bytes)
> OK. All tests passed
>
> Reusable parts of psock_fanout.c have been put into a psock_lib.h
> file for common usage. Test case successfully tested on x86_64.
>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH net-next] 802: fix a possible race condition
From: David Miller @ 2013-04-07 21:04 UTC (permalink / raw)
To: amwang; +Cc: netdev, eric.dumazet, david.ward, jorge
In-Reply-To: <1364975560-6812-1-git-send-email-amwang@redhat.com>
From: Cong Wang <amwang@redhat.com>
Date: Wed, 3 Apr 2013 15:52:40 +0800
> From: Cong Wang <amwang@redhat.com>
>
> (Resend with a better changelog)
>
> garp_pdu_queue() should ways be called with this spin lock.
> garp_uninit_applicant() only holds rtnl lock which is not
> enough here. A possible race can happen as garp_pdu_rcv()
> is called in BH context:
>
> garp_pdu_rcv()
> |->garp_pdu_parse_msg()
> |->garp_pdu_parse_attr()
> |-> garp_gid_event()
>
> Found by code inspection.
>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: David Ward <david.ward@ll.mit.edu>
> Cc: "Jorge Boncompte [DTI2]" <jorge@dti2.net>
> Signed-off-by: Cong Wang <amwang@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH -next] sctp: fix error return code in __sctp_connect()
From: David Miller @ 2013-04-07 21:04 UTC (permalink / raw)
To: weiyj.lk; +Cc: vyasevich, sri, nhorman, yongjun_wei, linux-sctp, netdev
In-Reply-To: <CAPgLHd-X5Qw64BnaSMr2ny6==jXGpRAYC7_1MGhP2v_GcVeApQ@mail.gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Wed, 3 Apr 2013 21:02:28 +0800
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> Fix to return a negative error code from the error handling
> case instead of 0, as returned elsewhere in this function.
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Applied.
^ permalink raw reply
* Re: [PATCH v2 0/4] 802.15.4 and 6LoWPAN Buffering Fixes
From: David Miller @ 2013-04-07 21:06 UTC (permalink / raw)
To: alan
Cc: alex.bluesman.smirnov, dbaryshkov, linux-zigbee-devel, netdev,
linux-kernel
In-Reply-To: <1364997658-16498-1-git-send-email-alan@signal11.us>
From: Alan Ott <alan@signal11.us>
Date: Wed, 3 Apr 2013 10:00:54 -0400
> Version 2 of this patch series:
>
> Differences from v1:
>
> 1. Patches previously numbered 5 and 6 were squashed (to become current
> patch #4) at the request of Alexander Smirnov.
>
> 2. Current patch #2 had extraneous braces removed.
>
> 3. Current patch #1 was changed. It is now a patch to make mac802154 _not_
> retry sending packets on failure. I believe this to be consistent with the
> 802.15.4 specification (Section 7.5.6.4.3 of IEEE 802.15.4-2006)
Series applied, thanks.
^ permalink raw reply
* Re: [net-next] stmmac: modified pcs mode support for SGMII
From: David Miller @ 2013-04-07 21:08 UTC (permalink / raw)
To: bh74.an; +Cc: netdev, peppe.cavallaro, kgene.kim, cpgs
In-Reply-To: <00b401ce30f9$3a628c50$af27a4f0$%an@samsung.com>
From: Byungho An <bh74.an@samsung.com>
Date: Thu, 04 Apr 2013 14:57:01 +0900
> This patch modifies the pcs mode support for SGMII. Even though
> SGMII does auto-negotiation with phy, it needs stmmac_init_phy and
> stmmac_mdio_register function for initializing phy.
>
> Signed-off-by: Byungho An <bh74.an@samsung.com>
Your email client corrupted this patch, it turned all TAB characters
into spaces. This makes your submission unusable.
Please fix this, email the patch to yourself, and only resubmit the
patch here if you are able to successfully apply the patch you receive
in a test email.
^ permalink raw reply
* Re: [Patch net-next] tcp: add a global sysctl to control TCP delayed ack
From: David Miller @ 2013-04-07 21:09 UTC (permalink / raw)
To: amwang; +Cc: netdev, eric.dumazet, rick.jones2, shemminger, tgraf,
David.Laight
In-Reply-To: <1365070560-11544-1-git-send-email-amwang@redhat.com>
From: Cong Wang <amwang@redhat.com>
Date: Thu, 4 Apr 2013 18:16:00 +0800
> From: Cong Wang <amwang@redhat.com>
>
> Change from RFC:
> * make the sysctl per netns
>
> According to previous discussion, it seems there is no
> reasonable heuristics.
>
> Similar to TCP_QUICK_ACK option, but for people who can't
> modify the source code and still wants to control
> TCP delayed ACK behavior.
>
> David, do you still have any objection?
>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Rick Jones <rick.jones2@hp.com>
> Cc: Stephen Hemminger <shemminger@vyatta.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Thomas Graf <tgraf@suug.ch>
> CC: David Laight <David.Laight@ACULAB.COM>
> Signed-off-by: Cong Wang <amwang@redhat.com>
I'm not applying a patch that adds a global parameter for
an attribute which has per-path scope.
^ permalink raw reply
* Re: [PATCH v3] netdev/phy: Implement ieee802.3 clause 45 in mdio-octeon.c
From: David Miller @ 2013-04-07 21:12 UTC (permalink / raw)
To: ddaney.cavm; +Cc: netdev, linux-kernel, david.daney
In-Reply-To: <1365017132-6035-1-git-send-email-ddaney.cavm@gmail.com>
From: David Daney <ddaney.cavm@gmail.com>
Date: Wed, 3 Apr 2013 12:25:32 -0700
> From: David Daney <david.daney@cavium.com>
>
> The Octeon SMI/MDIO interfaces can do clause 45 communications, so
> implement this in the driver.
>
> Also fix some comment formatting to make it consistent and to comply
> with the netdev style.
>
> Signed-off-by: David Daney <david.daney@cavium.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH -next] net_cls: remove duplicated include from cls_api.c
From: David Miller @ 2013-04-07 21:12 UTC (permalink / raw)
To: weiyj.lk; +Cc: jhs, yongjun_wei, netdev
In-Reply-To: <CAPgLHd8m+ZY0DO2BZq7jj3pNLDL0feaKMPgs9xPmen=mXyKe-Q@mail.gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Thu, 4 Apr 2013 09:21:22 +0800
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> Remove duplicated include.
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Applied.
^ permalink raw reply
* Re: [PATCH -next] decnet: remove duplicated include from dn_table.c
From: David Miller @ 2013-04-07 21:12 UTC (permalink / raw)
To: weiyj.lk
Cc: tgraf, shemminger, sasha.levin, akpm, yongjun_wei,
linux-decnet-user, netdev
In-Reply-To: <CAPgLHd-7CZLD7qCbR04iWWFRgdvW=aru06MF1JnW58dKvg5NTw@mail.gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Thu, 4 Apr 2013 09:33:07 +0800
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> Remove duplicated include.
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Applied.
^ permalink raw reply
* Re: [PATCH net 1/1] bnx2x: Fix KR2 rapid link flap
From: David Miller @ 2013-04-07 21:17 UTC (permalink / raw)
To: yanivr; +Cc: netdev, eilong
In-Reply-To: <1365348983-29314-1-git-send-email-yanivr@broadcom.com>
From: "Yaniv Rosner" <yanivr@broadcom.com>
Date: Sun, 7 Apr 2013 18:36:23 +0300
> Check KR2 recovery time at the beginning of the work-around function.
>
> Signed-off-by: Yaniv Rosner <yanivr@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied, thanks.
^ permalink raw reply
* Re: AMD Vi error and lost networking with r8169
From: Francois Romieu @ 2013-04-07 21:53 UTC (permalink / raw)
To: David R; +Cc: Linux Kernel Mailing List, netdev
In-Reply-To: <51616695.7080305@unsolicited.net>
David R <david@unsolicited.net> :
> I'm been seeing some problems with my new ish AMD motherboard/processor
> combo and networking (r8169). I see the following page fault :-
>
> Apr 7 12:25:14 david kernel: [156421.436545] AMD-Vi: Event logged
> [IO_PAGE_FAULT device=02:00.0 domain=0x0015 address=0x0000000000003000
> flags=0x0050]
Can you give the hack below a try ?
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 28fb50a..ed8625d 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -4125,6 +4125,8 @@ static void rtl_init_rxcfg(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_23:
case RTL_GIGA_MAC_VER_24:
case RTL_GIGA_MAC_VER_34:
+ case RTL_GIGA_MAC_VER_35:
+ case RTL_GIGA_MAC_VER_36:
RTL_W32(RxConfig, RX128_INT_EN | RX_MULTI_EN | RX_DMA_BURST);
break;
default:
^ permalink raw reply related
* Re: [PATCH RFC] unix: account skb memory to receiving socket's sk_rmem_alloc on sending
From: Hannes Frederic Sowa @ 2013-04-07 22:47 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, yannick, xiyou.wangcong, davem
In-Reply-To: <1364313218.1716.37.camel@edumazet-glaptop>
I am still unsure if I should just drop this patch from my todo
list. Eric, may I ask you for additional input again? I try to
specifically answer your question now with code samples. If you do think
it is not worth the effort I will finally drop the patch from my queue.
Thanks a lot!
On Tue, Mar 26, 2013 at 08:53:38AM -0700, Eric Dumazet wrote:
> This opens the possibility of a sender to flood a receiver, instead of
> being blocked by its own sndbuf.
In unix_dgram_sendmsg there are two points where the sending process
could be prevented from delivery of the unix dgram msg:
a) The first one is at sock_alloc_send_pskb and checks if the sk_sndbuf
is smaller than the maximum buffer size. I didn't change anything here,
so it only blocks if sndbuf filled up.
b) The second one is where we check if the receiving sockets has less
than sk_max_ack_backlog of outstanding datagrams. This was checked by
unix_recvq_full. I changed the code that it does now check the status of
the other socket's receive buffer instead of the number of outstanding
datagrams in the receiver's queue. If the rcvbuf is full, it stops the
delivery of the message to the receiver (unchanged blocking/o_nonblock
behaviour):
| @@ -1559,7 +1601,7 @@ restart:
| goto out_unlock;
| }
|
| - if (unix_peer(other) != sk && unix_recvq_full(other)) {
| + if (unix_rmem_full(other, skb)) {
| if (!timeo) {
| err = -EAGAIN;
| goto out_unlock;
|
This is unix_recvq_full:
| +static inline bool unix_rmem_full(struct sock const *sk,
| + struct sk_buff const *skb)
| +{
| + return sk_rmem_alloc_get(sk) + skb->truesize > sk->sk_rcvbuf;
| +}
| +
These checks ensure that a sending socket can not flood a receiver with
messages but instead has to back down.
The maximum rcvbuf size is taken from
/proc/sys/net/core/rmem_{default,max}, so we already have a safe default
setting (we could actually add seperate net/unix/rmem_{default,max} knobs).
This patch would help to prevent that a server socket in a
request/response kind of protocol could be stopped to answer to furhter
requests because its send buffer has filled up because other clients
did not read their messages yet. Instead it could handle this situation
for each client properly.
I also implemented the necessary changes for ->poll().
I tried to come up with a list what could change for user-space
applications but actually found this one only:
a) the SIOCOUTQ ioctl will report a different value: it won't report the
number of not yet received bytes by the other socket but the number of
not yet delivered bytes. I think this is rather harmless As the memory
overhead is accounted too and an application which does rely on this
feature would also have problems as soon as the kernel internal data
structures grow.
I hope I did not forget an important aspect of this change.
Thanks again,
Hannes
^ permalink raw reply
* Re: [PATCH] netfilter: don't reset nf_trace in nf_reset()
From: Gao feng @ 2013-04-08 1:11 UTC (permalink / raw)
To: Patrick McHardy; +Cc: pablo, netfilter-devel, netdev
In-Reply-To: <1365187325-25147-1-git-send-email-kaber@trash.net>
On 2013/04/06 02:42, Patrick McHardy wrote:
> Commit 130549fe added code to reset nf_trace in nf_reset(). This is wrong
> and unnecessary.
>
> nf_reset() is used in the following cases:
>
> - when passing packets up the the socket layer, at which point we want to
> release all netfilter references that might keep modules pinned while
> the packet is queued. nf_trace doesn't matter anymore at this point.
>
> - when encapsulating or decapsulating IPsec packets. We want to continue
> tracing these packets after IPsec processing.
>
> - when passing packets through virtual network devices. Only devices on
> that encapsulate in IPv4/v6 matter since otherwise nf_trace is not
> used anymore. Its not entirely clear whether those packets should
> be traced after that, however we've always done that.
>
> - when passing packets through virtual network devices that make the
> packet cross network namespace boundaries. This is the only cases
> where we clearly want to reset nf_trace and is also what the
> original patch intended to fix.
>
> Add a new function nf_reset_trace() and use it in dev_forward_skb() to
> fix this properly.
>
> Signed-off-by: Patrick McHardy <kaber@trash.net>
Ok, I was confused by the nf_*reset*...
This patch is more proper,Since my commit will change the behavior of TRACE in some case.
Thanks for your fix and explanation.
^ permalink raw reply
* [PATCH net-next] ixgbe: Remove unnecessary #ifdef CONFIG_DEBUG_FS tests
From: Joe Perches @ 2013-04-08 1:27 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: e1000-devel, netdev
Add some empty static inlines instead to make
the code more readable.
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 5 +++++
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 10 ----------
2 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
index a8e10cf..ca93238 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
@@ -740,6 +740,11 @@ extern void ixgbe_dbg_adapter_init(struct ixgbe_adapter *adapter);
extern void ixgbe_dbg_adapter_exit(struct ixgbe_adapter *adapter);
extern void ixgbe_dbg_init(void);
extern void ixgbe_dbg_exit(void);
+#else
+static inline void ixgbe_dbg_adapter_init(struct ixgbe_adapter *adapter) {}
+static inline void ixgbe_dbg_adapter_exit(struct ixgbe_adapter *adapter) {}
+static inline void ixgbe_dbg_init(void) {}
+static inline void ixgbe_dbg_exit(void) {}
#endif /* CONFIG_DEBUG_FS */
static inline struct netdev_queue *txring_txq(const struct ixgbe_ring *ring)
{
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 1339932..06cd8cd 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -7575,9 +7575,7 @@ skip_sriov:
e_err(probe, "failed to allocate sysfs resources\n");
#endif /* CONFIG_IXGBE_HWMON */
-#ifdef CONFIG_DEBUG_FS
ixgbe_dbg_adapter_init(adapter);
-#endif /* CONFIG_DEBUG_FS */
return 0;
@@ -7613,9 +7611,7 @@ static void ixgbe_remove(struct pci_dev *pdev)
struct ixgbe_adapter *adapter = pci_get_drvdata(pdev);
struct net_device *netdev = adapter->netdev;
-#ifdef CONFIG_DEBUG_FS
ixgbe_dbg_adapter_exit(adapter);
-#endif /*CONFIG_DEBUG_FS */
set_bit(__IXGBE_DOWN, &adapter->state);
cancel_work_sync(&adapter->service_task);
@@ -7878,15 +7874,11 @@ static int __init ixgbe_init_module(void)
pr_info("%s - version %s\n", ixgbe_driver_string, ixgbe_driver_version);
pr_info("%s\n", ixgbe_copyright);
-#ifdef CONFIG_DEBUG_FS
ixgbe_dbg_init();
-#endif /* CONFIG_DEBUG_FS */
ret = pci_register_driver(&ixgbe_driver);
if (ret) {
-#ifdef CONFIG_DEBUG_FS
ixgbe_dbg_exit();
-#endif /* CONFIG_DEBUG_FS */
return ret;
}
@@ -7912,9 +7904,7 @@ static void __exit ixgbe_exit_module(void)
#endif
pci_unregister_driver(&ixgbe_driver);
-#ifdef CONFIG_DEBUG_FS
ixgbe_dbg_exit();
-#endif /* CONFIG_DEBUG_FS */
rcu_barrier(); /* Wait for completion of call_rcu()'s */
}
^ 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