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 Kari
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 doesn't
On Fri, Apr 24, 2015 at 01:30:00PM +0800, Herbert Xu wrote:
> Now we just need to figre out whether we're still OK with RFC4543.
Looks like we're OK here too as the diagram in section 3.5 says
that the IV should be included in the AAD.
So we're all good!
Thanks,
--
Email: Herbert Xu
Home Page:
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 authenticat
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 9:28 PM, David Miller wrote:
> From: Mahesh Bandewar
> Date: Thu, 23 Apr 2015 19:54:29 -0700
>
>> On Thu, Apr 23, 2015 at 5:32 PM, Eric Dumazet wrote:
>>> On Thu, 2015-04-23 at 14:29 -0700, Mahesh Bandewar wrote:
>>>
+static void ipvlan_multicast_enqueue(struct ipvl_
From: Mahesh Bandewar
Date: Thu, 23 Apr 2015 19:54:29 -0700
> On Thu, Apr 23, 2015 at 5:32 PM, Eric Dumazet wrote:
>> On Thu, 2015-04-23 at 14:29 -0700, Mahesh Bandewar wrote:
>>
>>> +static void ipvlan_multicast_enqueue(struct ipvl_port *port,
>>> + struct sk_bu
On Thu, Apr 23, 2015 at 5:59 PM, Alexei Starovoitov 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 being
On Thu, 2015-04-23 at 19:54 -0700, Mahesh Bandewar wrote:
> The only possibility of schedule_work() while doing kfree_skb() is
> when the queue limit is reached. How can the queue be reduced if not
> scheduled? May be I'm missing something..
What is the point calling schedule_work() if you queue
On Thu, Apr 23, 2015 at 5:32 PM, Eric Dumazet wrote:
> 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))
>>
From: Hyong-Youb Kim
Date: Fri, 24 Apr 2015 10:57:58 +0900
> X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Apr 2015 01:58:46.2847 (UTC)
> X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
> X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR05MB1302
> X-Greylist: Default is to whitelist
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 no
From: Eric Dumazet
[ 3897.923145] BUG: unable to handle kernel NULL pointer dereference at
0080
[ 3897.931025] IP: [] reqsk_timer_handler+0x1a6/0x243
There is a race when reqsk_timer_handler() and tcp_check_req() call
inet_csk_reqsk_queue_unlink() on the same req at the same time.
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
On Thu, Apr 23, 2015 at 11:59:19AM -0400, David Miller wrote:
> From: Johannes Berg
> Date: Thu, 23 Apr 2015 16:38:43 +0200
>
> > From: Johannes Berg
> >
> > 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
From: Florian Fainelli
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 all.
--
To unsubsc
On 23/04/15 16:19, Francois Romieu wrote:
> Sergei Shtylyov :
>> 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. :-)
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 se
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
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:
> >> (...)
> (...)
Sergei Shtylyov :
> 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 disagree.
If someone believes bas
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 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
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
real
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 c
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
---
drivers/net/ip
On Thu, Apr 23, 2015 at 10:07 AM, Josh Boyer 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
> [ 29.382380] -
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 existing
On Thu, Apr 23, 2015 at 3:13 PM, Alexei Starovoitov 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_ since ingre
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 Thu, Apr 23, 2015 at 12:45 PM, Alexander Duyck
wrote:
> On 04/23/2015 12:30 PM, Cong Wang wrote:
>>
>> (Off-topic...)
>>
>> On Wed, Apr 22, 2015 at 4:23 PM, Cong Wang wrote:
>>>
>>> The code looks correct to me now, except it is suspicious skb->len
>>> is not updated after skb_copy_to_linear_d
Jamal Hadi Salim 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 QUEUED. I belie
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
> >
> > 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
On 04/22/15 18:22, Alexei Starovoitov wrote:
On 4/21/15 10:02 PM, Cong Wang wrote:
On Tue, Apr 21, 2015 at 12:27 PM, Alexei Starovoitov
wrote:
TC_ACT_QUEUED was always an alias of TC_ACT_STOLEN.
Get rid of redundant checks in all qdiscs.
Instead do it once.
The current code can be easily ext
On 04/23/15 at 04:38pm, Johannes Berg wrote:
> From: Johannes Berg
>
> 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 ou
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 i
On 04/23/2015 12:30 PM, Cong Wang wrote:
(Off-topic...)
On Wed, Apr 22, 2015 at 4:23 PM, Cong Wang 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 submittin
(Off-topic...)
On Wed, Apr 22, 2015 at 4:23 PM, Cong Wang 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 like we need the
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
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
---
drivers/net/ethernet/ti/netcp_ethss.c |8 ++--
1
On Thu, Apr 23, 2015 at 11:40 AM, Alexander Duyck
wrote:
> On 04/23/2015 11:06 AM, Cong Wang wrote:
>> On Wed, Apr 22, 2015 at 8:40 PM, Alexander Duyck
>> wrote:
>>> On 04/22/2015 04:23 PM, Cong Wang wrote:
On Wed, Apr 22, 2015 at 3:34 PM, Alexander Duyck
wrote:
> On 04/22/2015 02:
On 23 April 2015 at 20:28, 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 :
>
> 3b
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
> Cc: Felix Fietkau
> Fixes: eb64e2923a886 ("bgmac: leave inter
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
> Cc: Felix Fietkau
> Fixes: eb64e2923a886 ("bgmac: leave interrupts disabled
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
Cc: Felix Fietkau
Fixes: eb64e2923a886 ("bgmac: leave interrupts disabled as long as there is
work to do")
---
drivers/net/et
From: Andreas Oetken
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 11:06 AM, Cong Wang wrote:
> On Wed, Apr 22, 2015 at 8:40 PM, Alexander Duyck
> wrote:
>> On 04/22/2015 04:23 PM, Cong Wang wrote:
>>> On Wed, Apr 22, 2015 at 3:34 PM, Alexander Duyck
>>> wrote:
On 04/22/2015 02:56 PM, Cong Wang wrote:
> On Wed, Apr 22, 2015 at 2:42 PM, Ale
On 23 April 2015 at 20:33, Eric Dumazet 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 3.19 or 4.0?
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
On Thu, Apr 23, 2015 at 11:21 AM, Daniel Borkmann wrote:
> On 04/23/2015 08:12 PM, Cong Wang wrote:
>>
>> On Wed, Apr 22, 2015 at 7:46 PM, Alexei Starovoitov
>> wrote:
>
> ...
>>>
>>> TC_ACT_QUEUED cannot be removed.
>>> Only deprecated with backwards compatibility the way this patch did it.
>>>
From: "Luis R. Rodriguez"
Date: Tue, 21 Apr 2015 13:09:45 -0700
> From: "Luis R. Rodriguez"
>
> 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
I can't wait forever for the d
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
d75b1
On 04/23/2015 08:12 PM, Cong Wang wrote:
On Wed, Apr 22, 2015 at 7:46 PM, Alexei Starovoitov 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:
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
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=eb64
From: Geert Uytterhoeven
Date: Thu, 23 Apr 2015 19:59:33 +0200
> If NO_DMA=y:
...
> Signed-off-by: Geert Uytterhoeven
Applied.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.o
On Wed, Apr 22, 2015 at 7:46 PM, Alexei Starovoitov 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 out-of-tree
From: Geert Uytterhoeven
Date: Thu, 23 Apr 2015 20:04:51 +0200
> If NO_DMA=y:
...
> Signed-off-by: Geert Uytterhoeven
Applied.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.o
From: Geert Uytterhoeven
Date: Thu, 23 Apr 2015 19:59:34 +0200
> If NO_DMA=y:
...
> Signed-off-by: Geert Uytterhoeven
Applied.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.o
On Wed, Apr 22, 2015 at 8:40 PM, Alexander Duyck
wrote:
> On 04/22/2015 04:23 PM, Cong Wang wrote:
>> On Wed, Apr 22, 2015 at 3:34 PM, Alexander Duyck
>> wrote:
>>> On 04/22/2015 02:56 PM, Cong Wang wrote:
On Wed, Apr 22, 2015 at 2:42 PM, Alexander Duyck
wrote:
> On 04/22/2015 01:3
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'
Signed-of
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'
emac_main.c:(.text+0x
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): undef
From: Eric Dumazet
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 last packet
in write qu
On Thu, Apr 23, 2015 at 6:07 PM, Josh Boyer 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 observed similar backtrac
From: Eric Dumazet
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
>> > Date: Thu, 23 Apr 2015 07:02:47 -0700
>> >
>> > > +if (!tcp_send_head(sk)) {
>
From: Jason Eastman
Date: Wed, 22 Apr 2015 00:56:42 -0600
> fixed several comment and whitespace style issues
>
> Signed-off-by: Jason Eastman
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majord
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] ==
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
> > Date: Thu, 23 Apr 2015 07:02:47 -0700
> >
> > > + if (!tcp_send_head(sk)) {
> > > + tp->snd_nxt++;
> > > + return;
> >
On Thu, 2015-04-23 at 11:54 -0400, David Miller wrote:
> From: Eric Dumazet
> 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 ne
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, s
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 involv
From: Johannes Berg
Date: Thu, 23 Apr 2015 16:38:43 +0200
> From: Johannes Berg
>
> 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
From: Eric Dumazet
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 unsubscribe from
From: Jon Maloy
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.
Series applied, thank
From: David Gibson
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 maximum
> allocated buffer
From: Niklas Cassel
Date: Thu, 23 Apr 2015 15:37:11 +0200
> Signed-off-by: Niklas Cassel
> ---
> 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
From: Johannes Berg
Date: Thu, 23 Apr 2015 12:06:30 +0200
> From: Johannes Berg
>
> 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
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()
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: Ko
From: Johannes Berg
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 bug and verify the fix I
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() ca
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 we
From: Erik Hugne
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 will cause the message to
From: Ying Xue
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 later,
the socket is
From: Erik Hugne
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 incremented previously which
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 issue
Signed-off-by: Niklas Cassel
---
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 +548,7 @@ static
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
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 gc
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 all
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 may
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 ava
From: Johannes Berg
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 Berg
---
include/linux/
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 loo
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 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
o
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 implemen
On 04/22/15 at 04:38pm, Cong Wang wrote:
> On Wed, Apr 22, 2015 at 3:27 PM, Alexei Starovoitov wrote:
> > On 4/21/15 10:05 PM, Cong Wang wrote:
> >>
> >> On Tue, Apr 21, 2015 at 12:27 PM, Alexei Starovoitov
> >> wrote:
> >>>
> >>> introduce tc_classify_act() and qdisc_drop_bypass() helper functio
On 04/22/15 at 04:29pm, Cong Wang wrote:
> On Wed, Apr 22, 2015 at 3:04 PM, Alexei Starovoitov wrote:
> > On 4/21/15 9:59 PM, Cong Wang wrote:
> >>
> >> On Tue, Apr 21, 2015 at 12:27 PM, Alexei Starovoitov
> >> wrote:
> >>>
> >>> ingress qdisc should return NET_XMIT_* values just like all other q
> -Original Message-
> From: Ivan Vecera [mailto:ivec...@redhat.com]
>
> The driver unlike other drivers does not log link state changes.
>
> Cc: Sathya Perla
> Cc: Subbu Seetharaman
> Cc: Ajit Khaparde
> Signed-off-by: Ivan Vecera
> ---
> drivers/net/ethernet/emulex/benet/be_main.c
1 - 100 of 102 matches
Mail list logo
