From: Johannes Berg johannes.b...@intel.com
The conversion of mac80211's station table to rhashtable had a bug
that I found by accident in code review, that hadn't been found as
rhashtable apparently managed to have a maximum hash chain length
of one (!) in all our testing.
In order to test the
From: Johannes Berg johan...@sipsolutions.net
Date: Thu, 23 Apr 2015 16:38:43 +0200
From: Johannes Berg johannes.b...@intel.com
The conversion of mac80211's station table to rhashtable had a bug
that I found by accident in code review, that hadn't been found as
rhashtable apparently managed
On 04/23/2015 07:45 AM, Steffen Klassert wrote:
On Thu, Apr 23, 2015 at 11:26:20AM +0800, Herbert Xu wrote:
Hi:
It looks like our IPsec implementations of CCM and GCM are buggy
in that they don't include the IV in the authentication calculation.
Seems like crypto_rfc4106_crypt() passes the
From: David Gibson da...@gibson.dropbear.id.au
Date: Thu, 23 Apr 2015 14:43:05 +1000
AFAIK the PAPR document which defines the virtual device interface used by
the ibmveth driver doesn't specify a specific maximum MTU. So, in the
ibmveth driver, the maximum allowed MTU is determined by the
On 04/23/2015 06:09 PM, Johannes Berg wrote:
On Thu, 2015-04-23 at 11:59 -0400, David Miller wrote:
This fixes the lost insertion issue and consequently allows my
code to display its error (and verify my fix for it.)
It looks fine to me, but I'll let Herbert and Thomas review this.
Oh,
From: Eric Dumazet eric.duma...@gmail.com
Date: Thu, 23 Apr 2015 07:02:47 -0700
+ if (!tcp_send_head(sk)) {
+ tp-snd_nxt++;
+ return;
+ }
I'm not so sure about this. Why is this needed?
Otherwise patch looks fine to me.
--
To
On Thu, 2015-04-23 at 11:59 -0400, David Miller wrote:
This fixes the lost insertion issue and consequently allows my
code to display its error (and verify my fix for it.)
It looks fine to me, but I'll let Herbert and Thomas review this.
Oh, sorry, didn't know Herbert was also involved
This patch simply forwards unicast netpoll packets via one of physical
interface in datapath depending on source mac address from the skb.
It seems possible to use common net flow classification for netpoll but
there is no way to guarantee presence of right flow in kernel cache.
Signed-off-by:
From: Niklas Cassel niklas.cas...@axis.com
Date: Thu, 23 Apr 2015 15:37:11 +0200
Signed-off-by: Niklas Cassel nikl...@axis.com
---
drivers/net/phy/micrel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index
From: Jon Maloy jon.ma...@ericsson.com
Date: Thu, 23 Apr 2015 09:37:37 -0400
A set of unrelated corrections; one for the tipc netns implementation,
one regarding problems with random link resets, and one removing a
an erroneous refcount decrement when reading link statistsics via
netlink.
On Thu, 2015-04-23 at 11:54 -0400, David Miller wrote:
From: Eric Dumazet eric.duma...@gmail.com
Date: Thu, 23 Apr 2015 07:02:47 -0700
+ if (!tcp_send_head(sk)) {
+ tp-snd_nxt++;
+ return;
+ }
I'm not so sure about this. Why
On Thu, 2015-04-23 at 20:18 +0200, Rafał Miłecki wrote:
Can you help us with this, please? Does bgmac use NAPI incorrectly?
Were there some important changes in 3.19 or 4.0?
Right they were important changes in NAPI indeed :
3b47d30396ba net: gro: add a per device gro flush timer
From: Luis R. Rodriguez mcg...@do-not-panic.com
Date: Tue, 21 Apr 2015 13:09:45 -0700
From: Luis R. Rodriguez mcg...@suse.com
This driver already uses ioremap_wc() on the same range
so when write-combining is available that will be used
instead.
...
Signed-off-by: Luis R. Rodriguez
On Thu, 2015-04-23 at 09:16 -0700, Eric Dumazet wrote:
On Thu, 2015-04-23 at 11:54 -0400, David Miller wrote:
From: Eric Dumazet eric.duma...@gmail.com
Date: Thu, 23 Apr 2015 07:02:47 -0700
+ if (!tcp_send_head(sk)) {
+ tp-snd_nxt++;
+
From: Jason Eastman eastman.jason.li...@gmail.com
Date: Wed, 22 Apr 2015 00:56:42 -0600
fixed several comment and whitespace style issues
Signed-off-by: Jason Eastman eastman.jason.li...@gmail.com
Applied, thanks.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body
On Thu, Apr 23, 2015 at 6:07 PM, Josh Boyer jwbo...@fedoraproject.org wrote:
Hi All,
We've had a user report the following backtrace from the bridge module
with a recent Linus' tree. Has anything like this been reported yet?
If you have any questions on setup, the user is CC'd.
I too
From: Geert Uytterhoeven ge...@linux-m68k.org
Date: Thu, 23 Apr 2015 19:59:33 +0200
If NO_DMA=y:
...
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
Applied.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More
On 23 April 2015 at 20:33, Eric Dumazet eric.duma...@gmail.com wrote:
On Thu, 2015-04-23 at 11:28 -0700, Eric Dumazet wrote:
On Thu, 2015-04-23 at 20:18 +0200, Rafał Miłecki wrote:
Can you help us with this, please? Does bgmac use NAPI incorrectly?
Were there some important changes in
If NO_DMA=y:
drivers/built-in.o: In function `arc_emac_tx_clean':
emac_main.c:(.text+0x2decde): undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `arc_emac_rx':
emac_main.c:(.text+0x2dee1c): undefined reference to `dma_unmap_single'
If NO_DMA=y:
drivers/built-in.o: In function `xgbe_probe':
xgbe-main.c:(.text+0x2def0a): undefined reference to `dma_set_mask'
xgbe-main.c:(.text+0x2def20): undefined reference to `dma_supported'
drivers/built-in.o: In function `xgbe_rx_poll':
xgbe-drv.c:(.text+0x2e0320):
From: Geert Uytterhoeven ge...@linux-m68k.org
Date: Thu, 23 Apr 2015 19:59:34 +0200
If NO_DMA=y:
...
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
Applied.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More
From: Geert Uytterhoeven ge...@linux-m68k.org
Date: Thu, 23 Apr 2015 20:04:51 +0200
If NO_DMA=y:
...
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
Applied.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More
On 04/23/2015 08:12 PM, Cong Wang wrote:
On Wed, Apr 22, 2015 at 7:46 PM, Alexei Starovoitov a...@plumgrid.com wrote:
...
TC_ACT_QUEUED cannot be removed.
Only deprecated with backwards compatibility the way this patch did it.
That should have been obvious.
It is at least the third time I
On Thu, Apr 23, 2015 at 11:21 AM, Daniel Borkmann dan...@iogearbox.net wrote:
On 04/23/2015 08:12 PM, Cong Wang wrote:
On Wed, Apr 22, 2015 at 7:46 PM, Alexei Starovoitov a...@plumgrid.com
wrote:
...
TC_ACT_QUEUED cannot be removed.
Only deprecated with backwards compatibility the way
On Thu, 2015-04-23 at 11:28 -0700, Eric Dumazet wrote:
On Thu, 2015-04-23 at 20:18 +0200, Rafał Miłecki wrote:
Can you help us with this, please? Does bgmac use NAPI incorrectly?
Were there some important changes in 3.19 or 4.0?
Right they were important changes in NAPI indeed :
On 04/23/2015 11:06 AM, Cong Wang wrote:
On Wed, Apr 22, 2015 at 8:40 PM, Alexander Duyck
alexander.du...@gmail.com wrote:
On 04/22/2015 04:23 PM, Cong Wang wrote:
On Wed, Apr 22, 2015 at 3:34 PM, Alexander Duyck
alexander.du...@gmail.com wrote:
On 04/22/2015 02:56 PM, Cong Wang wrote:
On
From: Eric Dumazet eric.duma...@gmail.com
Date: Thu, 23 Apr 2015 09:48:12 -0700
On Thu, 2015-04-23 at 09:16 -0700, Eric Dumazet wrote:
On Thu, 2015-04-23 at 11:54 -0400, David Miller wrote:
From: Eric Dumazet eric.duma...@gmail.com
Date: Thu, 23 Apr 2015 07:02:47 -0700
+
From: Eric Dumazet eduma...@google.com
Presence of an unbound loop in tcp_send_fin() had always been hard
to explain when analyzing crash dumps involving gigantic dying processes
with millions of sockets.
Lets try a different strategy :
In case of memory pressure, try to add the FIN flag to
From: Johannes Berg johan...@sipsolutions.net
Date: Thu, 23 Apr 2015 12:06:30 +0200
From: Johannes Berg johannes.b...@intel.com
With the CPU iteration variable called 'i', it's relatively easy
to have variable shadowing which sparse will warn about. Avoid
that by renaming the variable to
Hi All,
We've had a user report the following backtrace from the bridge module
with a recent Linus' tree. Has anything like this been reported yet?
If you have any questions on setup, the user is CC'd.
josh
[ 29.382235] br0: port 1(tap0) entered forwarding state
[ 29.382286]
If NO_DMA=y:
drivers/built-in.o: In function `grcan_free_dma_buffers':
grcan.c:(.text+0x2d7716): undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `grcan_allocate_dma_buffers':
grcan.c:(.text+0x2d779c): undefined reference to `dma_alloc_coherent'
On Wed, Apr 22, 2015 at 8:40 PM, Alexander Duyck
alexander.du...@gmail.com wrote:
On 04/22/2015 04:23 PM, Cong Wang wrote:
On Wed, Apr 22, 2015 at 3:34 PM, Alexander Duyck
alexander.du...@gmail.com wrote:
On 04/22/2015 02:56 PM, Cong Wang wrote:
On Wed, Apr 22, 2015 at 2:42 PM, Alexander
Hi,
Recently Felix improved bgmac driver to be smarter in situation where
new packets were Tx/Rx-ed during bgmac_poll execution. It was handled
in:
eb64e29 bgmac: leave interrupts disabled as long as there is work to do
On Thu, 2015-04-23 at 20:56 +0200, Rafał Miłecki wrote:
After d75b1ade567f (net: less interrupt masking in NAPI) polling
function has to return whole budget when it wants NAPI to call it again.
Signed-off-by: Rafał Miłecki zaj...@gmail.com
Cc: Felix Fietkau n...@openwrt.org
Fixes:
After d75b1ade567f (net: less interrupt masking in NAPI) polling
function has to return whole budget when it wants NAPI to call it again.
Signed-off-by: Rafał Miłecki zaj...@gmail.com
Cc: Felix Fietkau n...@openwrt.org
Fixes: eb64e2923a886 (bgmac: leave interrupts disabled as long as there is
From: Andreas Oetken ennoerlan...@googlemail.com
Date: Wed, 22 Apr 2015 15:22:22 +0200
+ /* check if a fixed-link is defined in device-tree */
+ if (of_phy_is_fixed_link(priv-device-of_node)) {
+ if (of_phy_register_fixed_link(priv-device-of_node)
+
On 04/23/2015 12:30 PM, Cong Wang wrote:
(Off-topic...)
On Wed, Apr 22, 2015 at 4:23 PM, Cong Wang cw...@twopensource.com wrote:
The code looks correct to me now, except it is suspicious skb-len
is not updated after skb_copy_to_linear_data() while skb-tail is
advanced already. I need to think
On 22.04.2015 00:27, Joe Perches wrote:
On Tue, 2015-04-21 at 23:44 +0200, Mateusz Kulikowski wrote:
On 21.04.2015 23:22, Joe Perches wrote:
On Tue, 2015-04-21 at 22:57 +0200, Mateusz Kulikowski wrote:
(...)
(...)
True, True; If you prefer $line and ability to --fix - I'll use that in v3
I
On Thu, 2015-04-23 at 21:46 +0100, Thomas Graf wrote:
On 04/23/15 at 04:38pm, Johannes Berg wrote:
From: Johannes Berg johannes.b...@intel.com
The conversion of mac80211's station table to rhashtable had a bug
that I found by accident in code review, that hadn't been found as
On Thu, 2015-04-23 at 21:08 +0200, Rafał Miłecki wrote:
As you obviously noticed, I fixed bgmac now and submitted the fix.
Just wanted to say a thanks for helping with that!
Sure, it was a pleasure ;)
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a
On 04/23/15 at 04:38pm, Johannes Berg wrote:
From: Johannes Berg johannes.b...@intel.com
The conversion of mac80211's station table to rhashtable had a bug
that I found by accident in code review, that hadn't been found as
rhashtable apparently managed to have a maximum hash chain length
of
On 23 April 2015 at 20:28, Eric Dumazet eric.duma...@gmail.com wrote:
On Thu, 2015-04-23 at 20:18 +0200, Rafał Miłecki wrote:
Can you help us with this, please? Does bgmac use NAPI incorrectly?
Were there some important changes in 3.19 or 4.0?
Right they were important changes in NAPI
(Off-topic...)
On Wed, Apr 22, 2015 at 4:23 PM, Cong Wang cw...@twopensource.com wrote:
The code looks correct to me now, except it is suspicious skb-len
is not updated after skb_copy_to_linear_data() while skb-tail is
advanced already. I need to think more before submitting a patch.
I feel
Currently when interface type is MAC to Phy, netif_carrier_(on/off)
is called which is not needed as Phy lib already updates the carrier
status to net stack. This is needed only for other interface types
Signed-off-by: Murali Karicheri m-kariche...@ti.com
---
On Thu, Apr 23, 2015 at 10:07 AM, Josh Boyer jwbo...@fedoraproject.org wrote:
[ 29.382235] br0: port 1(tap0) entered forwarding state
[ 29.382286] ===
[ 29.382315] [ INFO: suspicious RCU usage. ]
[ 29.382344] 4.1.0-0.rc0.git11.1.fc23.x86_64 #1 Not tainted
On Thu, Apr 23, 2015 at 3:13 PM, Alexei Starovoitov a...@plumgrid.com wrote:
On 4/23/15 1:45 PM, Jamal Hadi Salim wrote:
1) the _XMIT semantics are useful on the egress side because in fact
we do have queues and they can be attached to qdiscs etc.
The TC_ACT_XXX codes were _intentional_
On 04/23/15 18:13, Alexei Starovoitov wrote:
On 4/23/15 1:45 PM, Jamal Hadi Salim wrote:
then it is worse mess than I thought :(
Why call it _qdisc_ then? and have special and convoluted handling for
it in qdisc_create, qdisc_graft and other places?
Convinience for tooling and using
Jamal Hadi Salim j...@mojatatu.com wrote:
2) the ACT_QUEUED vs STOLEN was supposed to have semantics of something
that was stolen (eg redirection should definetely have been returning
STOLEN not QUEUED); something that queues for later re-injection
(with any/all metadata) was intended to use
On Thu, Apr 23, 2015 at 12:45 PM, Alexander Duyck
alexander.h.du...@redhat.com wrote:
On 04/23/2015 12:30 PM, Cong Wang wrote:
(Off-topic...)
On Wed, Apr 22, 2015 at 4:23 PM, Cong Wang cw...@twopensource.com wrote:
The code looks correct to me now, except it is suspicious skb-len
is not
On 4/23/15 1:45 PM, Jamal Hadi Salim wrote:
1) the _XMIT semantics are useful on the egress side because in fact
we do have queues and they can be attached to qdiscs etc.
The TC_ACT_XXX codes were _intentional_ since ingress works as a
classifier shell.
then it is worse mess than I thought :(
On Wed, Apr 22, 2015 at 7:46 PM, Alexei Starovoitov a...@plumgrid.com wrote:
TC_ACT_QUEUED cannot be removed.
Only deprecated with backwards compatibility the way this patch did it.
That should have been obvious.
It is at least the third time I have to repeat that: we really don't care
about
On Thu, Apr 23, 2015 at 5:59 PM, Alexei Starovoitov a...@plumgrid.com wrote:
On 4/23/15 3:51 PM, Jamal Hadi Salim wrote:
So you are planning to add queues? If you are that is a different
discussion (and the use case needs some clarity).
nope. I wasn't planning to do that.
For packets
From: Mahesh Bandewar mahe...@google.com
Date: Thu, 23 Apr 2015 19:54:29 -0700
On Thu, Apr 23, 2015 at 5:32 PM, Eric Dumazet eric.duma...@gmail.com wrote:
On Thu, 2015-04-23 at 14:29 -0700, Mahesh Bandewar wrote:
+static void ipvlan_multicast_enqueue(struct ipvl_port *port,
+
On 2015-04-23 20:56, Rafał Miłecki wrote:
After d75b1ade567f (net: less interrupt masking in NAPI) polling
function has to return whole budget when it wants NAPI to call it again.
Signed-off-by: Rafał Miłecki zaj...@gmail.com
Cc: Felix Fietkau n...@openwrt.org
Fixes: eb64e2923a886 (bgmac:
On Thu, Apr 23, 2015 at 11:40 AM, Alexander Duyck
alexander.du...@gmail.com wrote:
On 04/23/2015 11:06 AM, Cong Wang wrote:
On Wed, Apr 22, 2015 at 8:40 PM, Alexander Duyck
alexander.du...@gmail.com wrote:
On 04/22/2015 04:23 PM, Cong Wang wrote:
On Wed, Apr 22, 2015 at 3:34 PM, Alexander
On Thu, Apr 23, 2015 at 03:24:59PM +0200, Martin Willi wrote:
Do you have any pointer for me where this is defined? Why is it needed,
given that GCM implicitly authenticates the IV by using it in Y0?
The IV if present must be covered by the ICV. This is required
by RFC4303 (section 2). But
Sergei Shtylyov sergei.shtyl...@cogentembedded.com :
On 4/23/2015 1:08 PM, Jia-Ju Bai wrote:
[...]
I also find many drivers do not use these managed APIs, especially in
ethernet
card drivers (like e100, r8169). Is it possible to change them?
Patches welcome. :-)
I respectfully
On Thu, 2015-04-23 at 16:54 -0700, Joe Perches wrote:
On Thu, 2015-04-23 at 21:53 +0200, Mateusz Kulikowski wrote:
I noticed funny behavior about $stat matches -
it reports the same error several times (including as scope whole file)
Is it feature or feature or I missed something?
You
Processing multicast / broadcast in fast path is performance draining
and having more links means more clonning and bringing performance
down further.
Broadcast; in particular, need to be given to all the virtual links.
Earlier tricks of enabling broadcast bit for IPv4 only interfaces are not
Earlier tricks of setting broadcast bit only when IPv4 address is added
onto interface are not good enough especially when autoconf comes in play.
Setting them on always is performance drag but now that multicast /
broadcast is not processed in fast-path; enabling broadcast will let
autoconf work
Multicast processing in IPvlan was faulty as is. Eric Dumazet
pointed out that fragmented packets wont be processed correctly
unless defrag step is introduced.
This patch adds the defrag step before driver attempts to process
multicast frame(s).
Signed-off-by: Mahesh Bandewar mahe...@google.com
On Thu, 2015-04-23 at 21:53 +0200, Mateusz Kulikowski wrote:
On 22.04.2015 00:27, Joe Perches wrote:
On Tue, 2015-04-21 at 23:44 +0200, Mateusz Kulikowski wrote:
On 21.04.2015 23:22, Joe Perches wrote:
On Tue, 2015-04-21 at 22:57 +0200, Mateusz Kulikowski wrote:
(...)
(...)
True, True;
From: Florian Fainelli f.faine...@gmail.com
Date: Thu, 23 Apr 2015 17:40:12 -0700
Well, for one, we could have a device managed register_netdev()
which cleans up resources in case of failures and calls
free_netdev() automatically, but is that adding much value?
I don't think it's worth it at
On 4/23/15 3:51 PM, Jamal Hadi Salim wrote:
So you are planning to add queues? If you are that is a different
discussion (and the use case needs some clarity).
nope. I wasn't planning to do that.
For packets being forwarded we already had egress qdiscs which had
queues so it didnt seem to
From: Eric Dumazet eduma...@google.com
[ 3897.923145] BUG: unable to handle kernel NULL pointer dereference at
0080
[ 3897.931025] IP: [a9f27686] reqsk_timer_handler+0x1a6/0x243
There is a race when reqsk_timer_handler() and tcp_check_req() call
inet_csk_reqsk_queue_unlink()
On Thu, Apr 23, 2015 at 01:45:34PM +0200, Steffen Klassert wrote:
Adding a second template for the correct implementation is
probaply the only thing that we can do if we don't want to
break backwards compatibility. But maybe we can add a warning
to the old implementation, such that users
On 23/04/15 16:19, Francois Romieu wrote:
Sergei Shtylyov sergei.shtyl...@cogentembedded.com :
On 4/23/2015 1:08 PM, Jia-Ju Bai wrote:
[...]
I also find many drivers do not use these managed APIs, especially in
ethernet
card drivers (like e100, r8169). Is it possible to change them?
On 04/21/2015 07:09 PM, Eric Dumazet wrote:
Note that this patch adds a deadlock possibility in some stress
situations.
If a process owning some tcp socket dies, and tcp_mem[2] is already hit,
all sk_stream_alloc_skb() can return NULL and we loop in tcp_send_fin(),
making no progress because
On Thu, 2015-04-23 at 08:48 -0500, Josh Hunt wrote:
On 04/21/2015 07:09 PM, Eric Dumazet wrote:
Note that this patch adds a deadlock possibility in some stress
situations.
If a process owning some tcp socket dies, and tcp_mem[2] is already hit,
all sk_stream_alloc_skb() can return
On 04/23/2015 08:31 AM, Sathya Perla wrote:
-Original Message-
From: Ivan Vecera [mailto:ivec...@redhat.com]
The driver unlike other drivers does not log link state changes.
v2: added current link speed to log message
Ivan, I disagree with the v2 change. I think your original
-Original Message-
From: Ivan Vecera [mailto:ivec...@redhat.com]
The driver unlike other drivers does not log link state changes.
v2: added current link speed to log message
Ivan, I disagree with the v2 change. I think your original intention
was just to log a message when the
On 04/23/2015 04:46 AM, Alexei Starovoitov wrote:
...
The other two threads degenerated into non-technical comments.
Yep. :-/
Anyway, this set was RFC to answer my main question whether I should
continue with tc cleanup or stop right here. I got my answer.
I think it's worth proceeding
From: Markos Chandras markos.chand...@imgtec.com
This patch has been added to the 3.12 stable tree. If you have any
objections, please let us know.
===
commit 87f966d97b89774162df04d2106c6350c8fe4cb3 upstream.
On a MIPS Malta board, tons of fifo underflow errors have been observed
-Original Message-
From: Joe Perches [mailto:j...@perches.com]
On Wed, 2015-04-22 at 15:43 +0200, Ivan Vecera wrote:
The driver unlike other drivers does not log link state changes.
...
Question for the emulex folk:
Is the dom argument to link_status_query necessary?
It's
-Original Message-
From: Ivan Vecera [mailto:ivec...@redhat.com]
The driver unlike other drivers does not log link state changes.
Cc: Sathya Perla sathya.pe...@emulex.com
Cc: Subbu Seetharaman subbu.seethara...@emulex.com
Cc: Ajit Khaparde ajit.khapa...@emulex.com
Signed-off-by:
On 4/23/2015 6:26 AM, Herbert Xu wrote:
Hi:
It looks like our IPsec implementations of CCM and GCM are buggy
This applies also to GMAC (rfc4543), right?
in that they don't include the IV in the authentication calculation.
This definitely breaks interoperability with anyone who implements
Thank you!
On 04/23/2015 05:19 PM, Sergei Shtylyov wrote:
Hello.
On 4/23/2015 9:45 AM, Jia-Ju Bai wrote:
Dear Sir,
I am very sorry to trouble you.
I find that resource management is error-prone when writing Linux
drivers, and
many problems may occur, such as resource leaks.
Meanwhile,
On 04/22/15 at 04:29pm, Cong Wang wrote:
On Wed, Apr 22, 2015 at 3:04 PM, Alexei Starovoitov a...@plumgrid.com wrote:
On 4/21/15 9:59 PM, Cong Wang wrote:
On Tue, Apr 21, 2015 at 12:27 PM, Alexei Starovoitov a...@plumgrid.com
wrote:
ingress qdisc should return NET_XMIT_* values just
On 04/22/15 at 04:38pm, Cong Wang wrote:
On Wed, Apr 22, 2015 at 3:27 PM, Alexei Starovoitov a...@plumgrid.com wrote:
On 4/21/15 10:05 PM, Cong Wang wrote:
On Tue, Apr 21, 2015 at 12:27 PM, Alexei Starovoitov a...@plumgrid.com
wrote:
introduce tc_classify_act() and qdisc_drop_bypass()
On Thu, Apr 23, 2015 at 12:03:38PM +0300, Horia Geantă wrote:
This applies also to GMAC (rfc4543), right?
No RFC4543 appears to be correctly implemented.
Does this mean that even the test vectors (crypto/testmgr.h) are broken?
Indeed. The test vectors appear to be generated either through
From: Johannes Berg johannes.b...@intel.com
With the CPU iteration variable called 'i', it's relatively easy
to have variable shadowing which sparse will warn about. Avoid
that by renaming the variable to __cpu which is less likely to
be used in the surrounding context.
Signed-off-by: Johannes
On 04/23/2015 05:29 PM, Jia-Ju Bai wrote:
Thank you!
On 04/23/2015 05:19 PM, Sergei Shtylyov wrote:
Hello.
On 4/23/2015 9:45 AM, Jia-Ju Bai wrote:
Dear Sir,
I am very sorry to trouble you.
I find that resource management is error-prone when writing Linux
drivers, and
many problems
Hi Herbert,
Does this mean that even the test vectors (crypto/testmgr.h) are broken?
Indeed. The test vectors appear to be generated either through
our implementation or by one that is identical to us.
I'm not sure about that. RFC4106 refers to [1] for test vectors, which
is still
On Thu, Apr 23, 2015 at 11:58:52AM +0200, Martin Willi wrote:
I'm not sure about that. RFC4106 refers to [1] for test vectors, which
is still available at web.archive.org [2].
When looking for example at Test Case 3, this is the same as in a newer
revision of the document [3]. That looks
On 4/23/2015 1:08 PM, Jia-Ju Bai wrote:
I am very sorry to trouble you.
I find that resource management is error-prone when writing Linux drivers,
and
many problems may occur, such as resource leaks.
Meanwhile, I find that many applied patches in the kernel mailing list focus
on releasing
Hi Steffen,
It looks like our IPsec implementations of CCM and GCM are buggy
in that they don't include the IV in the authentication calculation.
Seems like crypto_rfc4106_crypt() passes the associated data it
got from ESP directly to gcm, without chaining with the IV.
Do you have any
Signed-off-by: Niklas Cassel nikl...@axis.com
---
drivers/net/phy/micrel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 1190fd8..a422036 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -548,7
A set of unrelated corrections; one for the tipc netns implementation,
one regarding problems with random link resets, and one removing a
an erroneous refcount decrement when reading link statistsics via
netlink.
Erik Hugne (2):
tipc: fix random link reset problem
tipc: fix node refcount
From: Erik Hugne erik.hu...@ericsson.com
When link statistics is dumped over netlink, we iterate over
the list of peer nodes and append each links statistics to
the netlink msg. In the case where the dump is resumed after
filling up a nlmsg, the node refcnt is decremented without
having been
From: Ying Xue ying@windriver.com
When a new topology server is launched in a new namespace, its
listening socket is inserted into the init ns namespace's socket
hash table rather than the one owned by the new namespace. Although
the socket's namespace is forcedly changed to the new namespace
From: Erik Hugne erik.hu...@ericsson.com
In the function tipc_sk_rcv(), the stack variable 'err'
is only initialized to TIPC_ERR_NO_PORT for the first
iteration over the link input queue. If a chain of messages
are received from a link, failure to lookup the socket for
any but the first message
On Thu, Apr 23, 2015 at 11:26:20AM +0800, Herbert Xu wrote:
Hi:
It looks like our IPsec implementations of CCM and GCM are buggy
in that they don't include the IV in the authentication calculation.
Seems like crypto_rfc4106_crypt() passes the associated data it
got from ESP directly to gcm,
On Thu, 2015-04-23 at 14:29 -0700, Mahesh Bandewar wrote:
+static void ipvlan_multicast_enqueue(struct ipvl_port *port,
+ struct sk_buff *skb)
+{
+ if (skb-protocol == htons(ETH_P_PAUSE))
+ return;
But what happens to this packet ? It seems
On Thu, Apr 23, 2015 at 11:59:19AM -0400, David Miller wrote:
From: Johannes Berg johan...@sipsolutions.net
Date: Thu, 23 Apr 2015 16:38:43 +0200
From: Johannes Berg johannes.b...@intel.com
The conversion of mac80211's station table to rhashtable had a bug
that I found by accident in
The recent commit to only register the EHEA memory hotplug hooks on
adapter probe has a few problems.
Firstly the reference counting is wrong for multiple adapters, in that
the hooks are registered multiple times. Secondly the check in the tear
down path is backward. Finally the error path
On Friday 24 April 2015 12:47 AM, Murali Karicheri wrote:
Currently when interface type is MAC to Phy, netif_carrier_(on/off)
is called which is not needed as Phy lib already updates the carrier
status to net stack. This is needed only for other interface types
Signed-off-by: Murali
On Thu, Apr 23, 2015 at 9:28 PM, David Miller da...@davemloft.net wrote:
From: Mahesh Bandewar mahe...@google.com
Date: Thu, 23 Apr 2015 19:54:29 -0700
On Thu, Apr 23, 2015 at 5:32 PM, Eric Dumazet eric.duma...@gmail.com wrote:
On Thu, 2015-04-23 at 14:29 -0700, Mahesh Bandewar wrote:
When having permanent EEH error, the PCI device will be removed
from the system. For this case, we shouldn't set pcierr_recovery
to true wrongly, which blocks the driver to release the allocated
interrupts and their handlers. Eventually, we can't disable MSI
or MSIx successfully because of the MSI
On Thu, Apr 23, 2015 at 03:24:59PM +0200, Martin Willi wrote:
Do you have any pointer for me where this is defined? Why is it needed,
given that GCM implicitly authenticates the IV by using it in Y0?
Actually you're quite right. Both GCM and CCM implicitly includes
the IV in the
On Thu, Apr 23, 2015 at 02:28:40PM -0400, David Miller wrote:
I can't wait forever for the driver maintainers to review this, so
I'm applying it.
FWIW, I replied to Luis's patch yesterday. It appears on the netdev
list and patchwork. Checked the recipient list, and it includes
netdev, but not
1 - 100 of 103 matches
Mail list logo
