* Re: [PATCH net-next 5/8] net/mlx4_en: Remove redundant code from RX/GRO path
From: Eric Dumazet @ 2014-10-30 19:00 UTC (permalink / raw)
To: Or Gerlitz
Cc: David S. Miller, netdev, Matan Barak, Amir Vadai, Saeed Mahameed,
Shani Michaeli
In-Reply-To: <1414685216-28907-6-git-send-email-ogerlitz@mellanox.com>
On Thu, 2014-10-30 at 18:06 +0200, Or Gerlitz wrote:
> Remove the code which goes through napi_gro_frags() on the RX path,
> use only napi_gro_receive().
>
> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
> ---
Hmpff... napi_gro_frags() should be faster.
Have you benchmarked this ?
^ permalink raw reply
* Re: nfs stalls over loopback interface (no sk_data_ready events?)
From: Christoph Hellwig @ 2014-10-30 19:00 UTC (permalink / raw)
To: Jeff Layton
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Christoph Hellwig,
Linux NFS Mailing List, Bruce Fields, Trond Myklebust
In-Reply-To: <20141029102123.58f6c960-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
On Wed, Oct 29, 2014 at 10:21:23AM -0400, Jeff Layton wrote:
> Looks some change that went into -rc2 has fixed the problem for me.
> Christoph, can you confirm that this no longer occurs with -rc2?
I can't reproduce it anymore on -rc2.
However:
generic/133 fails fairly reliably with:
Buffered writer, buffered reader
+pread64: Device or resource busy
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Mistake in commit 0d961b3b52f566f823070ce2366511a7f64b928c breaks cpsw non dual_emac mode.
From: David Miller @ 2014-10-30 19:43 UTC (permalink / raw)
To: lsorense; +Cc: linux-kernel, hs, mugunthanvnm, netdev
In-Reply-To: <20141028170242.GA24112@csclub.uwaterloo.ca>
From: "Lennart Sorensen" <lsorense@csclub.uwaterloo.ca>
Date: Tue, 28 Oct 2014 13:02:42 -0400
> I believe commit 0d961b3b52f566f823070ce2366511a7f64b928c made a mistake
> while correcting a bug.
This patch submission is not properly formed.
You subject line should be of the form:
subsystem: Description.
"subsystem" here would be "cpsw: " or something like that.
Secondly, you should not refer to a commit ID in the patch
Subject line, instead just describe exactly what is being
fixed in the most succinct yet complete manner that is
possible.
Thirdly, when you do refer to commit ID's in your commit
message body you must do so in the following format:
${SHA1_ID} ("Commit message header line text.")
The commit message body is also not a place to have a general
discussion. Please avoid saying things like "I think", for example.
State facts, and be exact about what the problem is and exactly
how you are fixing it.
Because this commit message will be read by others looking at your
change days, weeks, years from now.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/3] reduce verifier memory consumption and add tests
From: David Miller @ 2014-10-30 19:45 UTC (permalink / raw)
To: ast; +Cc: hannes, edumazet, dborkman, luto, netdev, linux-kernel
In-Reply-To: <1414534303-9906-1-git-send-email-ast@plumgrid.com>
From: Alexei Starovoitov <ast@plumgrid.com>
Date: Tue, 28 Oct 2014 15:11:40 -0700
> Small set of cleanups:
> - reduce verifier memory consumption
> - add verifier test to check register state propagation and state equivalence
> - add JIT test reduced from recent nmap triggered crash
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net 0/3] r8152: patches for autosuspend
From: David Miller @ 2014-10-30 19:49 UTC (permalink / raw)
To: hayeswang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <1394712342-15778-69-Taiwan-albertk@realtek.com>
From: Hayes Wang <hayeswang@realtek.com>
Date: Wed, 29 Oct 2014 11:12:14 +0800
> There are unexpected processes when enabling autosuspend.
> These patches are used to fix them.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH 0/6 3.18] Fixes for iwlwifi drivers
From: Arend van Spriel @ 2014-10-30 19:51 UTC (permalink / raw)
To: Larry Finger
Cc: Luca Coelho, linville-2XuSBdqkA4R54TAoqtyWWQ,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Murilo Opsfelder Araujo
In-Reply-To: <545258D6.20000-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
On 10/30/14 16:27, Larry Finger wrote:
> On 10/30/2014 06:08 AM, Luca Coelho wrote:
>> The cover-letter subject is wrong. :) I guess you meant
>> s/iwlwifi/rtlwifi/ ;)
>
> Yes, the changes were for rtlwifi, not iwlwifi. Sorry. (:
>
> My laptop has an Intel 7260 card built in, and it is working correctly
> on both 2.4 and 5G bands under mainline 3.18-rc2.
>
> Those types of errors are what I get for trying to "work" while on a
> family vacation. Unfortunately, I needed to submit those patches quickly
> to prevent a set of conflicting updates from being accepted, and I made
> a silly mistake.
Don't let it spoil your vacation ;-)
Regards,
Arend
> Larry
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-wireless" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/1 net-next] ipx: remove all unnecessary castings on ntohl
From: David Miller @ 2014-10-30 19:52 UTC (permalink / raw)
To: fabf; +Cc: linux-kernel, acme, netdev
In-Reply-To: <1414571502-9231-1-git-send-email-fabf@skynet.be>
From: Fabian Frederick <fabf@skynet.be>
Date: Wed, 29 Oct 2014 09:31:42 +0100
> Apply commit e0f36310f793
> ("ipx: remove unnecessary casting on ntohl")
> to all seq_printf/08lX
>
> Inspired-by: "David S. Miller" <davem@davemloft.net>
> Inspired-by: Joe Perches <joe@perches.com>
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
Applied.
^ permalink raw reply
* Re: [PATCH/TRIVIAL 1/1 net-next] ipv6: spelling s/incomming/incoming
From: David Miller @ 2014-10-30 19:52 UTC (permalink / raw)
To: fabf; +Cc: linux-kernel, kuznet, jmorris, yoshfuji, kaber, trivial, netdev
In-Reply-To: <1414573227-10743-1-git-send-email-fabf@skynet.be>
From: Fabian Frederick <fabf@skynet.be>
Date: Wed, 29 Oct 2014 10:00:26 +0100
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
Applied.
^ permalink raw reply
* Re: [PATCH 1/1 net-next] ipv6: remove inline on static in c file
From: David Miller @ 2014-10-30 19:52 UTC (permalink / raw)
To: fabf; +Cc: linux-kernel, kuznet, jmorris, yoshfuji, kaber, netdev
In-Reply-To: <1414579097-11659-1-git-send-email-fabf@skynet.be>
From: Fabian Frederick <fabf@skynet.be>
Date: Wed, 29 Oct 2014 11:38:17 +0100
> remove __inline__ / inline and let compiler decide what to do
> with static functions
>
> Inspired-by: "David S. Miller" <davem@davemloft.net>
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
Applied.
^ permalink raw reply
* Re: [PATCH 1/1 net-next] ipv6: remove assignment in if condition
From: David Miller @ 2014-10-30 19:52 UTC (permalink / raw)
To: fabf; +Cc: linux-kernel, kuznet, jmorris, yoshfuji, kaber, netdev
In-Reply-To: <1414583871-14196-1-git-send-email-fabf@skynet.be>
From: Fabian Frederick <fabf@skynet.be>
Date: Wed, 29 Oct 2014 12:57:51 +0100
> Do assignment before if condition and test !skb like in rawv6_recvmsg()
>
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
Applied.
^ permalink raw reply
* Re: [PATCH -next 0/2] net: allow setting ecn via routing table
From: David Miller @ 2014-10-30 19:59 UTC (permalink / raw)
To: fw; +Cc: netdev
In-Reply-To: <20141029122307.GA29253@breakpoint.cc>
From: Florian Westphal <fw@strlen.de>
Date: Wed, 29 Oct 2014 13:23:07 +0100
> We could do that, if you prefer.
>
> I tried to come up with a scenario though, where sysctl_tcp_ecn=0, and
> then we want to enable 'passive' ecn for incoming connections only on
> a particular route without announcing ecn to the peer. I haven't been
> able to find any -- I think if you deem 'route to x' safe for ecn it
> might as well be enabled for both initiator and responder. The original
> patch would be sufficient for that.
>
> IOW, is 'ecn from a to b but not b to a' a sensible requirement?
I think you have to apply the same logic for the sysctl (there's a
reason to only support ECN passively) as you do for the route feature
because you can logically look at the sysctl as applying to the
default route.
> Unrelated to this patch, but I'd like to see sysctl_tcp_ecn=1 as a
> default at one point (almost no routers set CE bit at this time, perhaps
> that would change if ecn usage is more widespread).
Now you're talking.
So, either passive ECN support makes sense or it does not. To me, no
matter what the argument, it doesn't matter what realm (whole system,
specific routes) you apply that argument to.
^ permalink raw reply
* Re: [PATCH v2] ip6_tunnel: allow to change mode for the ip6tnl0
From: David Miller @ 2014-10-30 20:09 UTC (permalink / raw)
To: alan; +Cc: netdev, edumazet
In-Reply-To: <1414569292-15384-1-git-send-email-alan@al-an.info>
From: "Alexey Andriyanov" <alan@al-an.info>
Date: Wed, 29 Oct 2014 10:54:52 +0300
> The fallback device is in ipv6 mode by default.
> The mode can not be changed in runtime, so there
> is no way to decapsulate ip4in6 packets coming from
> various sources without creating the specific tunnel
> ifaces for each peer.
>
> This allows to update the fallback tunnel device, but only
> the mode could be changed. Usual command should work for the
> fallback device: `ip -6 tun change ip6tnl0 mode any`
>
> The fallback device can not be hidden from the packet receiver
> as a regular tunnel, but there is no need for synchronization
> as long as we do single assignment.
>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Alexey Andriyanov <alan@al-an.info>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] Add missing descriptions for fwmark_reflect for ipv4 and ipv6.
From: David Miller @ 2014-10-30 20:11 UTC (permalink / raw)
To: logan; +Cc: netdev
In-Reply-To: <20141029172915.GA15714@mx.elandsys.com>
From: Loganaden Velvindron <logan@elandsys.com>
Date: Wed, 29 Oct 2014 10:29:15 -0700
> (It's my first time sending a diff to netdev, please let me know if
> I made a mistake)
Please don't put text like this into the commit log message body.
^ permalink raw reply
* Re: PATCH: Add IFF_ALLMULTI support to cpsw (and fix IFF_PROMISC support too)
From: David Miller @ 2014-10-30 20:12 UTC (permalink / raw)
To: lsorense; +Cc: linux-kernel, mugunthanvnm, netdev
In-Reply-To: <20141029190612.GH24110@csclub.uwaterloo.ca>
From: "Lennart Sorensen" <lsorense@csclub.uwaterloo.ca>
Date: Wed, 29 Oct 2014 15:06:12 -0400
> The cpsw driver did not support the IFF_ALLMULTI flag which makes dynamic
> multicast routing rather hard to handle. Related to this, when enabling
> IFF_PROMISC in non dual_emac mode, all registered vlans are flushed,
> and only broadcast and unicast are allowed which isn't what you would
> want from IFF_PROMISC.
>
> A new cpsw_ale_set_allmulti function now scans through the ALE entry
> table and adds or removes the host port from the unregistered multicast
> port mask depending on the state of IFF_ALLMULTI. In promisc mode,
> it is also called to enable reception of all multicast traffic.
>
> With this change I am now able to run dynamic multicast routing and also
> use tcpdump and actually see multicast traffic.
>
> Signed-off-by: Len Sorensen <lsorense@csclub.uwaterloo.ca>
Please fix your Subject line and resubmit this patch.
Subject lines end up as the commit message header text, and
therefore must be of the form:
subsystem: Description.
In this case "cpsw: " is probably an appropriate subsystem
prefix.
^ permalink raw reply
* Re: [PATCH net-next] tcp: allow for bigger reordering level
From: David Miller @ 2014-10-30 20:14 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, wygivan
In-Reply-To: <1414610869.631.94.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 29 Oct 2014 12:27:49 -0700
> Yuchung and othres are working on a new way to handle reorders (RACK),
> and should present the concept in next IETF meeting.
>
> A linux patch should follow shortly.
>
> High level idea is :
>
> Decide when and what to retransmit based on the timing, instead of
> sequence, relationships. This covers both original or retransmitted
> packets.
>
> On dupacks, wait a fraction of RTT before the repair process to both
> allow reordering and relieve the network
My instint says that this delay will increase recovery time, but I
guess they've taken that into consideration :-)
^ permalink raw reply
* Re: [PATCH net-next] ipv4: minor spelling fixes
From: David Miller @ 2014-10-30 20:14 UTC (permalink / raw)
To: stephen; +Cc: netdev
In-Reply-To: <20141029160506.46011813@urahara>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Wed, 29 Oct 2014 16:05:06 -0700
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Applied, thanks Stephen.
^ permalink raw reply
* Re: [PATCH v2] PPC: bpf_jit_comp: add SKF_AD_PKTTYPE instruction
From: Alexei Starovoitov @ 2014-10-30 20:32 UTC (permalink / raw)
To: Denis Kirjanov
Cc: netdev@vger.kernel.org, linuxppc-dev, Michael Ellerman,
Matt Evans
In-Reply-To: <1414649535-3956-1-git-send-email-kda@linux-powerpc.org>
On Wed, Oct 29, 2014 at 11:12 PM, Denis Kirjanov <kda@linux-powerpc.org> wrote:
> Add BPF extension SKF_AD_PKTTYPE to ppc JIT to load
> skb->pkt_type field.
>
> Before:
> [ 88.262622] test_bpf: #11 LD_IND_NET 86 97 99 PASS
> [ 88.265740] test_bpf: #12 LD_PKTTYPE 109 107 PASS
>
> After:
> [ 80.605964] test_bpf: #11 LD_IND_NET 44 40 39 PASS
> [ 80.607370] test_bpf: #12 LD_PKTTYPE 9 9 PASS
if you'd only quoted #12, it would all make sense ;)
but #11 test is not using PKTTYPE. So your patch shouldn't
make a difference. Are these numbers with JIT on and off?
^ permalink raw reply
* Re: [PATCH 6/7] can: m_can: update to support CAN FD features
From: Oliver Hartkopp @ 2014-10-30 20:32 UTC (permalink / raw)
To: Dong Aisheng; +Cc: linux-can, mkl, wg, varkabhadram, netdev, linux-arm-kernel
In-Reply-To: <20141030024226.GA29572@shlinux1.ap.freescale.net>
On 10/30/2014 03:42 AM, Dong Aisheng wrote:
> On Wed, Oct 29, 2014 at 08:21:28PM +0100, Oliver Hartkopp wrote:
>> So first I would suggest to check the core release register (CREL) to be
>> version 3.0.x and quit the driver initialization if it doesn't fit this
>> version. I would suggest to provide a separate patch for that check. What
>> about printing the core release version into the kernel log at driver
>> initialization time?
>>
>
> One question is that if v3.1.0 and v3.2.0 will be backward compatible with
> v3.0.1, if yes, how about let the driver still work for them instead of
> simply quit?
There are several important differences between 3.0.x and 3.1.x.
E.g. the CCCR, BTP, PSR and others are changed and a register for the
transmitter delay compensation is added.
I assume from 3.1.x to 3.2.x the controller registers will only change in
small details as the main update will be on the wire and not in the functionality.
> And then we can add new features according new released IP version.
Yes. We probably can wait for 3.[12].x to become available before adding the
special code that behaves according the core release register content.
>>> @@ -375,7 +414,7 @@ static int m_can_do_rx_poll(struct net_device *dev, int quota)
>>> if (rxfs & RXFS_RFL)
>>> netdev_warn(dev, "Rx FIFO 0 Message Lost\n");
>>>
>>> - skb = alloc_can_skb(dev, &frame);
>>> + skb = alloc_canfd_skb(dev, &frame);
>>
>> You are *always* allocating CAN FD frames now?
>>
>
> Yes, currently it is.
> The test seemed ok using CAN FD frames even receive normal frame.
When you put CAN frame content into a CAN FD skb it becomes a CAN FD frame -
which is wrong.
CAN 2.0 frame (EDL is clear) -> alloc_can_skb()
CAN FD frame (EDL is set) -> alloc_canfd_skb()
You can have a CAN FD frame with a DLC of 8, which does *not* mean that you
have a CAN 2.0 frame.
> The issue i know is that candump seemed can not recognize remote frame reported
> by the driver.
Do you use the latest candump from
https://gitorious.org/linux-can/can-utils/
??
The latest candump switches the CAN_RAW socket into the mode to accept both
CAN *and* CAN FD frames and displays the frames correctly.
> Not sure if it's caused by canfd_frame used.
Yes. CAN FD frames do not have a RTR bit.
> Will test and check.
>
>> Depending on RX_BUF_EDL in the RX FIFO message you should create a CAN or CAN
>> FD frame.
>>
>> Of course you can use the struct canfd_frame in m_can_read_fifo() as the
>> layout of the struct can_frame is identical when filled with 'normal' CAN
>> frame content.
>>
>> But you need to distinguish whether it is a CAN or CAN FD frame when
>> allocating the skb based on the RX_BUF_EDL value.
>>
>
> Yes, i think it's good to do that.
> One obvious benefit is it saves memory at least.
The main point is that CAN frames and CAN FD frames are separated by this
(MTU) length information. It's not about saving memory.
A CAN FD frame with DLC 8 still has 64 data bytes inside it's data structure.
Regards,
Oliver
^ permalink raw reply
* Re: [PATCH net-next] mlx4: use napi_schedule_irqoff()
From: David Miller @ 2014-10-30 20:50 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, amirv
In-Reply-To: <1414626885.631.102.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 29 Oct 2014 16:54:45 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> mlx4_en_rx_irq() and mlx4_en_tx_irq() run from hard interrupt context.
>
> They can use napi_schedule_irqoff() instead of napi_schedule()
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: use napi_schedule_irqoff()
From: David Miller @ 2014-10-30 20:51 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, ariel.elior
In-Reply-To: <1414627670.631.105.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 29 Oct 2014 17:07:50 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> bnx2x_msix_fp_int() and bnx2x_interrupt() run from hard interrupt
> context.
>
> They can use napi_schedule_irqoff() instead of napi_schedule()
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH -next 0/2] net: allow setting ecn via routing table
From: Florian Westphal @ 2014-10-30 20:52 UTC (permalink / raw)
To: David Miller; +Cc: fw, netdev
In-Reply-To: <20141030.155958.156984068627586090.davem@davemloft.net>
David Miller <davem@davemloft.net> wrote:
> From: Florian Westphal <fw@strlen.de>
> Date: Wed, 29 Oct 2014 13:23:07 +0100
>
> > We could do that, if you prefer.
> >
> > I tried to come up with a scenario though, where sysctl_tcp_ecn=0, and
> > then we want to enable 'passive' ecn for incoming connections only on
> > a particular route without announcing ecn to the peer. I haven't been
> > able to find any -- I think if you deem 'route to x' safe for ecn it
> > might as well be enabled for both initiator and responder. The original
> > patch would be sufficient for that.
> >
> > IOW, is 'ecn from a to b but not b to a' a sensible requirement?
>
> I think you have to apply the same logic for the sysctl (there's a
> reason to only support ECN passively) as you do for the route feature
> because you can logically look at the sysctl as applying to the
> default route.
Agreed, sysctl is comparable to default route.
And I think 'passive ecn' makes perfect sense for a default route.
But for a specific host/network?
Either I know that path to $x is ecn-safe (i.e. turn it on for both ends)
or I don't, in which case the global 'passive' default ("if peer requests
it they probably know what they're doing") is fine.
> > default at one point (almost no routers set CE bit at this time, perhaps
> > that would change if ecn usage is more widespread).
>
> Now you're talking.
>
> So, either passive ECN support makes sense or it does not. To me, no
> matter what the argument, it doesn't matter what realm (whole system,
> specific routes) you apply that argument to.
The passive mode was added 5 years ago via
commit 255cac91c3c9ce7dca7713b93ab03c75b7902e0e
(tcp: extend ECN sysctl to allow server-side only ECN), and I think the
commit log rationale makes sense.
So, what about changing the default to 1 in net-next?
We could add automatic 'no-ecn' to retransmitted syns to avoid
ecn blackholes (Daniel Borkmann has a patch for this), and, in case
ecn=1 causes too much breakage we can always revert (and re-consider ecn
per route settings as an intermediate step).
What do you think?
Thanks,
Florian
^ permalink raw reply
* Re: [PATCH net] cxgb4 : Fix missing initialization of win0_lock
From: David Miller @ 2014-10-30 20:52 UTC (permalink / raw)
To: anish; +Cc: netdev, hariprasad, leedom
In-Reply-To: <1414630443-6412-1-git-send-email-anish@chelsio.com>
From: Anish Bhatt <anish@chelsio.com>
Date: Wed, 29 Oct 2014 17:54:03 -0700
> win0_lock was being used un-initialized, resulting in warning traces
> being seen when lock debugging is enabled (and just wrong)
>
> Fixes : fc5ab0209650 ('cxgb4: Replaced the backdoor mechanism to access the HW
> memory with PCIe Window method')
>
> Signed-off-by: Anish Bhatt <anish@chelsio.com>
> Signed-off-by: Casey Leedom <leedom@chelsio.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH -next] syncookies: only increment SYNCOOKIESFAILED on validation error
From: David Miller @ 2014-10-30 20:54 UTC (permalink / raw)
To: fw; +Cc: netdev
In-Reply-To: <1414634138-23238-1-git-send-email-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Thu, 30 Oct 2014 02:55:38 +0100
> Only count packets that failed cookie-authentication.
> We can get SYNCOOKIESFAILED > 0 while we never even sent a single cookie.
>
> Signed-off-by: Florian Westphal <fw@strlen.de>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] r8152: set RTL8152_UNPLUG when finding -ENODEV
From: David Miller @ 2014-10-30 20:55 UTC (permalink / raw)
To: hayeswang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <1394712342-15778-73-Taiwan-albertk@realtek.com>
From: Hayes Wang <hayeswang@realtek.com>
Date: Thu, 30 Oct 2014 11:46:40 +0800
> Set RTL8152_UNPLUG when finding -ENODEV. This could accelerate
> unloading the driver when the device is unplugged.
>
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] tipc: spelling errors
From: David Miller @ 2014-10-30 20:56 UTC (permalink / raw)
To: stephen; +Cc: jon.maloy, allan.stephens, netdev
In-Reply-To: <20141029225851.03651f3f@urahara>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Wed, 29 Oct 2014 22:58:51 -0700
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Applied, thanks Stephen.
^ 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