* Re: kernel 2.6.37 : oops in cleanup_once
From: Yann Dupont @ 2011-02-02 13:08 UTC (permalink / raw)
To: Eric Dumazet; +Cc: linux-kernel, netdev
In-Reply-To: <1296645887.20445.11.camel@edumazet-laptop>
Le 02/02/2011 12:24, Eric Dumazet a écrit :
> Le mercredi 02 février 2011 à 11:52 +0100, Eric Dumazet a écrit :
>> Le mercredi 02 février 2011 à 09:53 +0100, Yann Dupont a écrit :
>>> Hello.
>>> We recently upgraded one machine with vanilla 2.6.37, and experienced 2
>>> kernel oops since. Each oops is after ~1 week of uptime.
>>> The last oops was last night but we didn't had any trace.
> oops, 2.6.37 "only"
>
>> Yes this is a known problem.
>>
>> Please try commit 3408404a4c2a4eead9d73b0bbbfe3f225b65f492
>> (inetpeer: Use correct AVL tree base pointer in inet_getpeer())
>>
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3408404a4c2a4eead9d73b0bbbfe3f225b65f492
>>
>> I believe David will send it to stable team shortly, if not already
>> done :)
> Please ignore, this patch was for linux-2.6 tree, 2.6.37 was not
> affected by the problem.
>
> So its another problem... Is there anything particular you do on this
> machine ?
>
>
>
>
Nothing really special there, we run a lot (20) of KVM guest (mainly
linux firewalls for lots of differents vlan), so we have a lot of
bridges vlan & tun/tap.
Oh, and CONFIG_BRIDGE_IGMP_SNOOPING is set to n (because of the other
bug already sent to netdev - more to come on next mail)
Hard to say if this BUG is new in 2.6.37. This host was running fine
with 2.6.34.2 since August 2010.
Bisecting will be hard due to the time to trigger the bug (and the fact
that this machine is a production machine)
Anyway, I can test with a specific kernel version if you suspect something.
Regards,
--
Yann Dupont - Service IRTS, DSI Université de Nantes
Tel : 02.53.48.49.20 - Mail/Jabber : Yann.Dupont@univ-nantes.fr
^ permalink raw reply
* Re: possible issue between bridge igmp/multicast handling & bnx2x on kernel 2.6.34 and >
From: Yann Dupont @ 2011-02-02 13:29 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1294399705.3306.8.camel@edumazet-laptop>
> Le vendredi 07 janvier 2011 à 11:40 +0100, Yann Dupont a écrit :
>> Le 04/01/2011 14:40, Yann Dupont a écrit :
>> ...
>>> We just added BCM57711 10G cards (bnx2x driver) on our blade servers
>>> (connected to 10G Power Connect M8024).
>>> Since then, we are experiencing random lost of packets.
>>>
>>> Symptom : packets are lost on some vlans for a few seconds, then
>>> things go back to normal (and stops again a few minutes later)
>>>
>> As I didn't had answer so far , I digged a little more and captured more
>> packets.
>> I just noticed that an event trigger that problem : IPv6 neighbor
>> discovery packet .
>>
>> This is , of course, a multicast packet.
>>
>> Just saw that 2.6.36.3 should include this fix :
>>
Just a little update, the problem doesn't seem to be what we thought at
first.
It may not be related to the bnx2x driver after all.
We noticed that we had the same symptoms on target machine using bnx2
drivers (we missed that at first since the outages are way briefer).
We're now rather suspecting our own firewall (also a linux in a kvm
machine) since without it we don't get any more problem and the packet
drops occurs on _THIS_ network, when packets are routed by _THIS_ firewall.
Anyway, all of that is very puzzling, we have made a lot of network
dumps and we have really no clue of what's happening there.
We don't understand why, if the problem is really on our firewall
machine, setting CONFIG_BRIDGE_IGMP_SNOOPING to 'n' on the target
machine efficiently fix the problem, Especially since it doesn't seem
related at all with our setup and we don't see anything in our network
dumps that could explain this.
It's probably not a single problem, but a sum of different problems.
We continue to search.
Sorry for the noise.
Regards,
--
Yann Dupont - Service IRTS, DSI Université de Nantes
Tel : 02.53.48.49.20 - Mail/Jabber : Yann.Dupont@univ-nantes.fr
^ permalink raw reply
* [PATCH] bna: use device model DMA API
From: Ivan Vecera @ 2011-02-02 14:37 UTC (permalink / raw)
To: netdev; +Cc: rmody, ddutt
Use DMA API as PCI equivalents will be deprecated.
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
drivers/net/bna/bnad.c | 108 +++++++++++++++++++++++++-----------------------
drivers/net/bna/bnad.h | 2 +-
2 files changed, 57 insertions(+), 53 deletions(-)
diff --git a/drivers/net/bna/bnad.c b/drivers/net/bna/bnad.c
index fad9126..9f356d5 100644
--- a/drivers/net/bna/bnad.c
+++ b/drivers/net/bna/bnad.c
@@ -126,22 +126,22 @@ bnad_free_all_txbufs(struct bnad *bnad,
}
unmap_array[unmap_cons].skb = NULL;
- pci_unmap_single(bnad->pcidev,
- pci_unmap_addr(&unmap_array[unmap_cons],
+ dma_unmap_single(&bnad->pcidev->dev,
+ dma_unmap_addr(&unmap_array[unmap_cons],
dma_addr), skb_headlen(skb),
- PCI_DMA_TODEVICE);
+ DMA_TO_DEVICE);
- pci_unmap_addr_set(&unmap_array[unmap_cons], dma_addr, 0);
+ dma_unmap_addr_set(&unmap_array[unmap_cons], dma_addr, 0);
if (++unmap_cons >= unmap_q->q_depth)
break;
for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
- pci_unmap_page(bnad->pcidev,
- pci_unmap_addr(&unmap_array[unmap_cons],
+ dma_unmap_page(&bnad->pcidev->dev,
+ dma_unmap_addr(&unmap_array[unmap_cons],
dma_addr),
skb_shinfo(skb)->frags[i].size,
- PCI_DMA_TODEVICE);
- pci_unmap_addr_set(&unmap_array[unmap_cons], dma_addr,
+ DMA_TO_DEVICE);
+ dma_unmap_addr_set(&unmap_array[unmap_cons], dma_addr,
0);
if (++unmap_cons >= unmap_q->q_depth)
break;
@@ -199,23 +199,23 @@ bnad_free_txbufs(struct bnad *bnad,
sent_bytes += skb->len;
wis -= BNA_TXQ_WI_NEEDED(1 + skb_shinfo(skb)->nr_frags);
- pci_unmap_single(bnad->pcidev,
- pci_unmap_addr(&unmap_array[unmap_cons],
+ dma_unmap_single(&bnad->pcidev->dev,
+ dma_unmap_addr(&unmap_array[unmap_cons],
dma_addr), skb_headlen(skb),
- PCI_DMA_TODEVICE);
- pci_unmap_addr_set(&unmap_array[unmap_cons], dma_addr, 0);
+ DMA_TO_DEVICE);
+ dma_unmap_addr_set(&unmap_array[unmap_cons], dma_addr, 0);
BNA_QE_INDX_ADD(unmap_cons, 1, unmap_q->q_depth);
prefetch(&unmap_array[unmap_cons + 1]);
for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
prefetch(&unmap_array[unmap_cons + 1]);
- pci_unmap_page(bnad->pcidev,
- pci_unmap_addr(&unmap_array[unmap_cons],
+ dma_unmap_page(&bnad->pcidev->dev,
+ dma_unmap_addr(&unmap_array[unmap_cons],
dma_addr),
skb_shinfo(skb)->frags[i].size,
- PCI_DMA_TODEVICE);
- pci_unmap_addr_set(&unmap_array[unmap_cons], dma_addr,
+ DMA_TO_DEVICE);
+ dma_unmap_addr_set(&unmap_array[unmap_cons], dma_addr,
0);
BNA_QE_INDX_ADD(unmap_cons, 1, unmap_q->q_depth);
}
@@ -340,19 +340,22 @@ static void
bnad_free_all_rxbufs(struct bnad *bnad, struct bna_rcb *rcb)
{
struct bnad_unmap_q *unmap_q;
+ struct bnad_skb_unmap *unmap_array;
struct sk_buff *skb;
int unmap_cons;
unmap_q = rcb->unmap_q;
+ unmap_array = unmap_q->unmap_array;
for (unmap_cons = 0; unmap_cons < unmap_q->q_depth; unmap_cons++) {
- skb = unmap_q->unmap_array[unmap_cons].skb;
+ skb = unmap_array[unmap_cons].skb;
if (!skb)
continue;
- unmap_q->unmap_array[unmap_cons].skb = NULL;
- pci_unmap_single(bnad->pcidev, pci_unmap_addr(&unmap_q->
- unmap_array[unmap_cons],
- dma_addr), rcb->rxq->buffer_size,
- PCI_DMA_FROMDEVICE);
+ unmap_array[unmap_cons].skb = NULL;
+ dma_unmap_single(&bnad->pcidev->dev,
+ dma_unmap_addr(&unmap_array[unmap_cons],
+ dma_addr),
+ rcb->rxq->buffer_size,
+ DMA_FROM_DEVICE);
dev_kfree_skb(skb);
}
bnad_reset_rcb(bnad, rcb);
@@ -391,9 +394,10 @@ bnad_alloc_n_post_rxbufs(struct bnad *bnad, struct bna_rcb *rcb)
skb->dev = bnad->netdev;
skb_reserve(skb, NET_IP_ALIGN);
unmap_array[unmap_prod].skb = skb;
- dma_addr = pci_map_single(bnad->pcidev, skb->data,
- rcb->rxq->buffer_size, PCI_DMA_FROMDEVICE);
- pci_unmap_addr_set(&unmap_array[unmap_prod], dma_addr,
+ dma_addr = dma_map_single(&bnad->pcidev->dev, skb->data,
+ rcb->rxq->buffer_size,
+ DMA_FROM_DEVICE);
+ dma_unmap_addr_set(&unmap_array[unmap_prod], dma_addr,
dma_addr);
BNA_SET_DMA_ADDR(dma_addr, &rxent->host_addr);
BNA_QE_INDX_ADD(unmap_prod, 1, unmap_q->q_depth);
@@ -434,8 +438,9 @@ bnad_poll_cq(struct bnad *bnad, struct bna_ccb *ccb, int budget)
struct bna_rcb *rcb = NULL;
unsigned int wi_range, packets = 0, wis = 0;
struct bnad_unmap_q *unmap_q;
+ struct bnad_skb_unmap *unmap_array;
struct sk_buff *skb;
- u32 flags;
+ u32 flags, unmap_cons;
u32 qid0 = ccb->rcb[0]->rxq->rxq_id;
struct bna_pkt_rate *pkt_rt = &ccb->pkt_rate;
@@ -456,17 +461,17 @@ bnad_poll_cq(struct bnad *bnad, struct bna_ccb *ccb, int budget)
rcb = ccb->rcb[1];
unmap_q = rcb->unmap_q;
+ unmap_array = unmap_q->unmap_array;
+ unmap_cons = unmap_q->consumer_index;
- skb = unmap_q->unmap_array[unmap_q->consumer_index].skb;
+ skb = unmap_array[unmap_cons].skb;
BUG_ON(!(skb));
- unmap_q->unmap_array[unmap_q->consumer_index].skb = NULL;
- pci_unmap_single(bnad->pcidev,
- pci_unmap_addr(&unmap_q->
- unmap_array[unmap_q->
- consumer_index],
+ unmap_array[unmap_cons].skb = NULL;
+ dma_unmap_single(&bnad->pcidev->dev,
+ dma_unmap_addr(&unmap_array[unmap_cons],
dma_addr),
- rcb->rxq->buffer_size,
- PCI_DMA_FROMDEVICE);
+ rcb->rxq->buffer_size,
+ DMA_FROM_DEVICE);
BNA_QE_INDX_ADD(unmap_q->consumer_index, 1, unmap_q->q_depth);
/* Should be more efficient ? Performance ? */
@@ -1015,9 +1020,9 @@ bnad_mem_free(struct bnad *bnad,
if (mem_info->mem_type == BNA_MEM_T_DMA) {
BNA_GET_DMA_ADDR(&(mem_info->mdl[i].dma),
dma_pa);
- pci_free_consistent(bnad->pcidev,
- mem_info->mdl[i].len,
- mem_info->mdl[i].kva, dma_pa);
+ dma_free_coherent(&bnad->pcidev->dev,
+ mem_info->mdl[i].len,
+ mem_info->mdl[i].kva, dma_pa);
} else
kfree(mem_info->mdl[i].kva);
}
@@ -1047,8 +1052,9 @@ bnad_mem_alloc(struct bnad *bnad,
for (i = 0; i < mem_info->num; i++) {
mem_info->mdl[i].len = mem_info->len;
mem_info->mdl[i].kva =
- pci_alloc_consistent(bnad->pcidev,
- mem_info->len, &dma_pa);
+ dma_alloc_coherent(&bnad->pcidev->dev,
+ mem_info->len, &dma_pa,
+ GFP_KERNEL);
if (mem_info->mdl[i].kva == NULL)
goto err_return;
@@ -2600,9 +2606,9 @@ bnad_start_xmit(struct sk_buff *skb, struct net_device *netdev)
unmap_q->unmap_array[unmap_prod].skb = skb;
BUG_ON(!(skb_headlen(skb) <= BFI_TX_MAX_DATA_PER_VECTOR));
txqent->vector[vect_id].length = htons(skb_headlen(skb));
- dma_addr = pci_map_single(bnad->pcidev, skb->data, skb_headlen(skb),
- PCI_DMA_TODEVICE);
- pci_unmap_addr_set(&unmap_q->unmap_array[unmap_prod], dma_addr,
+ dma_addr = dma_map_single(&bnad->pcidev->dev, skb->data,
+ skb_headlen(skb), DMA_TO_DEVICE);
+ dma_unmap_addr_set(&unmap_q->unmap_array[unmap_prod], dma_addr,
dma_addr);
BNA_SET_DMA_ADDR(dma_addr, &txqent->vector[vect_id].host_addr);
@@ -2630,11 +2636,9 @@ bnad_start_xmit(struct sk_buff *skb, struct net_device *netdev)
BUG_ON(!(size <= BFI_TX_MAX_DATA_PER_VECTOR));
txqent->vector[vect_id].length = htons(size);
- dma_addr =
- pci_map_page(bnad->pcidev, frag->page,
- frag->page_offset, size,
- PCI_DMA_TODEVICE);
- pci_unmap_addr_set(&unmap_q->unmap_array[unmap_prod], dma_addr,
+ dma_addr = dma_map_page(&bnad->pcidev->dev, frag->page,
+ frag->page_offset, size, DMA_TO_DEVICE);
+ dma_unmap_addr_set(&unmap_q->unmap_array[unmap_prod], dma_addr,
dma_addr);
BNA_SET_DMA_ADDR(dma_addr, &txqent->vector[vect_id].host_addr);
BNA_QE_INDX_ADD(unmap_prod, 1, unmap_q->q_depth);
@@ -3022,14 +3026,14 @@ bnad_pci_init(struct bnad *bnad,
err = pci_request_regions(pdev, BNAD_NAME);
if (err)
goto disable_device;
- if (!pci_set_dma_mask(pdev, DMA_BIT_MASK(64)) &&
- !pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64))) {
+ if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)) &&
+ !dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64))) {
*using_dac = 1;
} else {
- err = pci_set_dma_mask(pdev, DMA_BIT_MASK(32));
+ err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
if (err) {
- err = pci_set_consistent_dma_mask(pdev,
- DMA_BIT_MASK(32));
+ err = dma_set_coherent_mask(&pdev->dev,
+ DMA_BIT_MASK(32));
if (err)
goto release_regions;
}
diff --git a/drivers/net/bna/bnad.h b/drivers/net/bna/bnad.h
index 8b1d515..a89117f 100644
--- a/drivers/net/bna/bnad.h
+++ b/drivers/net/bna/bnad.h
@@ -181,7 +181,7 @@ struct bnad_rx_info {
/* Unmap queues for Tx / Rx cleanup */
struct bnad_skb_unmap {
struct sk_buff *skb;
- DECLARE_PCI_UNMAP_ADDR(dma_addr)
+ DEFINE_DMA_UNMAP_ADDR(dma_addr);
};
struct bnad_unmap_q {
--
1.7.3.4
^ permalink raw reply related
* Re: kernel 2.6.37 : oops in cleanup_once
From: Eric Dumazet @ 2011-02-02 14:53 UTC (permalink / raw)
To: Yann Dupont; +Cc: linux-kernel, netdev
In-Reply-To: <4D495765.4090806@univ-nantes.fr>
Le mercredi 02 février 2011 à 14:08 +0100, Yann Dupont a écrit :
> Le 02/02/2011 12:24, Eric Dumazet a écrit :
> > Le mercredi 02 février 2011 à 11:52 +0100, Eric Dumazet a écrit :
> >> Le mercredi 02 février 2011 à 09:53 +0100, Yann Dupont a écrit :
> >>> Hello.
> >>> We recently upgraded one machine with vanilla 2.6.37, and experienced 2
> >>> kernel oops since. Each oops is after ~1 week of uptime.
> >>> The last oops was last night but we didn't had any trace.
> > oops, 2.6.37 "only"
> >
> >> Yes this is a known problem.
> >>
> >> Please try commit 3408404a4c2a4eead9d73b0bbbfe3f225b65f492
> >> (inetpeer: Use correct AVL tree base pointer in inet_getpeer())
> >>
> >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3408404a4c2a4eead9d73b0bbbfe3f225b65f492
> >>
> >> I believe David will send it to stable team shortly, if not already
> >> done :)
> > Please ignore, this patch was for linux-2.6 tree, 2.6.37 was not
> > affected by the problem.
> >
> > So its another problem... Is there anything particular you do on this
> > machine ?
> >
> >
> >
> >
> Nothing really special there, we run a lot (20) of KVM guest (mainly
> linux firewalls for lots of differents vlan), so we have a lot of
> bridges vlan & tun/tap.
> Oh, and CONFIG_BRIDGE_IGMP_SNOOPING is set to n (because of the other
> bug already sent to netdev - more to come on next mail)
>
> Hard to say if this BUG is new in 2.6.37. This host was running fine
> with 2.6.34.2 since August 2010.
> Bisecting will be hard due to the time to trigger the bug (and the fact
> that this machine is a production machine)
>
> Anyway, I can test with a specific kernel version if you suspect something.
>
I suspect a mem corruption from another layer (not inetpeer)
Unfortunately many kmem caches share the "64 bytes" cache.
Could you please add "slub_nomerge" on your boot command ?
This way, we can separate corruptions on each cache.
On your crash, one inetpeer contain garbage on unused_lists next/prev
pointers :
RCX: 0000000000000005
RDX: 0b000209f1beadde
Definitly something overwrote these values with non pointers values.
^ permalink raw reply
* Re: kernel 2.6.37 : oops in cleanup_once
From: Yann Dupont @ 2011-02-02 15:04 UTC (permalink / raw)
To: Eric Dumazet; +Cc: linux-kernel, netdev
In-Reply-To: <1296658407.20445.19.camel@edumazet-laptop>
Le 02/02/2011 15:53, Eric Dumazet a écrit :
> Le mercredi 02 février 2011 à 14:08 +0100, Yann Dupont a écrit :
>> Le 02/02/2011 12:24, Eric Dumazet a écrit :
>>> Le mercredi 02 février 2011 à 11:52 +0100, Eric Dumazet a écrit :
>>>> Le mercredi 02 février 2011 à 09:53 +0100, Yann Dupont a écrit :
>>>>> Hello.
>>>>> We recently upgraded one machine with vanilla 2.6.37, and experienced 2
>>>>> kernel oops since. Each oops is after ~1 week of uptime.
>>>>> The last oops was last night but we didn't had any trace.
>>> oops, 2.6.37 "only"
>>>
>>>> Yes this is a known problem.
>>>>
>>>> Please try commit 3408404a4c2a4eead9d73b0bbbfe3f225b65f492
>>>> (inetpeer: Use correct AVL tree base pointer in inet_getpeer())
>>>>
>>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3408404a4c2a4eead9d73b0bbbfe3f225b65f492
>>>>
>>>> I believe David will send it to stable team shortly, if not already
>>>> done :)
>>> Please ignore, this patch was for linux-2.6 tree, 2.6.37 was not
>>> affected by the problem.
>>>
>>> So its another problem... Is there anything particular you do on this
>>> machine ?
>>>
>>>
>>>
>>>
>> Nothing really special there, we run a lot (20) of KVM guest (mainly
>> linux firewalls for lots of differents vlan), so we have a lot of
>> bridges vlan& tun/tap.
>> Oh, and CONFIG_BRIDGE_IGMP_SNOOPING is set to n (because of the other
>> bug already sent to netdev - more to come on next mail)
>>
>> Hard to say if this BUG is new in 2.6.37. This host was running fine
>> with 2.6.34.2 since August 2010.
>> Bisecting will be hard due to the time to trigger the bug (and the fact
>> that this machine is a production machine)
>>
>> Anyway, I can test with a specific kernel version if you suspect something.
>>
> I suspect a mem corruption from another layer (not inetpeer)
>
> Unfortunately many kmem caches share the "64 bytes" cache.
>
> Could you please add "slub_nomerge" on your boot command ?
>
Ok, will do it at 18:30 CET (to minimize impact)
It the suspected bug SLUB related ?
The 2.6.34.2 kernel previously used on that server used SLAB.
2 questions :
-How can I be sure slub_nomerge is active ? Boot message ?
-Is there a very severe impact on performance ?
Regards,
--
Yann Dupont - Service IRTS, DSI Université de Nantes
Tel : 02.53.48.49.20 - Mail/Jabber : Yann.Dupont@univ-nantes.fr
^ permalink raw reply
* Re: kernel 2.6.37 : oops in cleanup_once
From: Eric Dumazet @ 2011-02-02 15:08 UTC (permalink / raw)
To: Yann Dupont; +Cc: linux-kernel, netdev
In-Reply-To: <4D49726C.6020103@univ-nantes.fr>
Le mercredi 02 février 2011 à 16:04 +0100, Yann Dupont a écrit :
> >
> Ok, will do it at 18:30 CET (to minimize impact)
> It the suspected bug SLUB related ?
>
no : It can be a corruption from another part of kernel.
> The 2.6.34.2 kernel previously used on that server used SLAB.
>
>
> 2 questions :
> -How can I be sure slub_nomerge is active ? Boot message ?
# ls -l /sys/kernel/slab/
If you have symlinks : merge is on (default)
If you dont have symlinks : nomerge is in action
> -Is there a very severe impact on performance ?
>
not at all
> Regards,
>
^ permalink raw reply
* Re: Network performance with small packets
From: Shirley Ma @ 2011-02-02 15:39 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Krishna Kumar2, David Miller, kvm, mashirle, netdev, netdev-owner,
Sridhar Samudrala, Steve Dobbelstein
In-Reply-To: <20110202104832.GA8505@redhat.com>
On Wed, 2011-02-02 at 12:48 +0200, Michael S. Tsirkin wrote:
> Yes, I think doing this in the host is much simpler,
> just send an interrupt after there's a decent amount
> of space in the queue.
>
> Having said that the simple heuristic that I coded
> might be a bit too simple.
>From the debugging out what I have seen so far (a single small message
TCP_STEAM test), I think the right approach is to patch both guest and
vhost. The problem I have found is a regression for single small
message TCP_STEAM test. Old kernel works well for TCP_STREAM, only new
kernel has problem.
For Steven's problem, it's multiple stream TCP_RR issues, the old guest
doesn't perform well, so does new guest kernel. We tested reducing vhost
signaling patch before, it didn't help the performance at all.
Thanks
Shirley
^ permalink raw reply
* kernel panic when exiting a network namespace
From: Daniel Lezcano @ 2011-02-02 15:40 UTC (permalink / raw)
To: Linux Netdev List
Hi All,
if we create a network namespace and a pair network device veth with one
side within the new netns and the other side in the old netns, then when
the new netns exits that leads to a beautiful kernel panic.
That does not appear when both side are in the same network namespace.
linux-swk0 login: BUG: unable to handle kernel paging request at
ffff88003aacfce0
IP: [<ffffffff812d2ebc>] unregister_netdevice_queue+0x4d/0x85
PGD 160b063 PUD 160f063 PMD 1ffd3067 PTE 3aacf160
Oops: 0002 [#1] DEBUG_PAGEALLOC
last sysfs file: /sys/devices/virtual/block/ram9/uevent
CPU 0
Modules linked in:
Pid: 5, comm: kworker/u:0 Not tainted 2.6.38-rc2+ #4 /Bochs
RIP: 0010:[<ffffffff812d2ebc>] [<ffffffff812d2ebc>]
unregister_netdevice_queue+0x4d/0x85
RSP: 0018:ffff88003ecf1ca0 EFLAGS: 00010282
RAX: ffff88003aacfcd8 RBX: ffff88003908b800 RCX: 0000000000000000
RDX: ffff88003aacfcd8 RSI: ffff88003ecf1ce0 RDI: ffff88003908b8b0
RBP: ffff88003ecf1cb0 R08: ffffffff816655e0 R09: 00014b8a6008606d
R10: 0000000000000002 R11: 0000000000000004 R12: ffff88003ecf1ce0
R13: ffff88003ecf1ce0 R14: ffff88003ecf1d60 R15: ffff8800394a17f0
FS: 0000000000000000(0000) GS:ffffffff8161b000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffff88003aacfce0 CR3: 0000000039587000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process kworker/u:0 (pid: 5, threadinfo ffff88003ecf0000, task
ffff88003ece1100)
Stack:
ffff88003ecf1ce0 ffff8800397fd800 ffff88003ecf1cd0 ffffffff8129c570
ffff88003908b800 ffff8800394a1740 ffff88003ecf1d20 ffffffff812d2f4c
ffff88003ecf1ce0 ffff88003ecf1ce0 2222222222222222 ffffffff81665220
Call Trace:
[<ffffffff8129c570>] veth_dellink+0x16/0x26
[<ffffffff812d2f4c>] default_device_exit_batch+0x58/0xc1
[<ffffffff812cd73d>] ? cleanup_net+0x0/0x192
[<ffffffff812cd116>] ops_exit_list+0x4e/0x56
[<ffffffff812cd82d>] cleanup_net+0xf0/0x192
[<ffffffff81042a11>] process_one_work+0x24d/0x407
[<ffffffff81042984>] ? process_one_work+0x1c0/0x407
[<ffffffff81042ede>] worker_thread+0x1b8/0x30a
[<ffffffff81042d26>] ? worker_thread+0x0/0x30a
[<ffffffff81046072>] kthread+0x7c/0x84
[<ffffffff810034b4>] kernel_thread_helper+0x4/0x10
[<ffffffff8139bebe>] ? restore_args+0x0/0x30
[<ffffffff81045ff6>] ? kthread+0x0/0x84
[<ffffffff810034b0>] ? kernel_thread_helper+0x0/0x10
Code: 48 c7 c7 3d a2 53 81 e8 ca 60 0c 00 e8 ce 5e 0c 00 4d 85 e4 74 26
48 8b 93 b0 00 00 00 48 8b 83 b8 00 00 00 48 8d bb b0 00 00 00 <48> 89
42 08 48 89 10 4c
89 e2 49 8b 74 24 08 eb 1d 48 89 df e8
RIP [<ffffffff812d2ebc>] unregister_netdevice_queue+0x4d/0x85
RSP <ffff88003ecf1ca0>
CR2: ffff88003aacfce0
---[ end trace 66938c79ba1c0677 ]---
addr2line -e ./vmlinux ffffffff8129c570
==> net-2.6/drivers/net/veth.c:455
static void veth_dellink(struct net_device *dev, struct list_head *head)
{
struct veth_priv *priv;
struct net_device *peer;
priv = netdev_priv(dev);
peer = priv->peer;
unregister_netdevice_queue(dev, head);
==> unregister_netdevice_queue(peer, head); <==
}
^ permalink raw reply
* Re: Network performance with small packets
From: Shirley Ma @ 2011-02-02 15:42 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Sridhar Samudrala, Steve Dobbelstein, David Miller, kvm, mashirle,
netdev
In-Reply-To: <20110202104946.GC8505@redhat.com>
On Wed, 2011-02-02 at 12:49 +0200, Michael S. Tsirkin wrote:
> On Tue, Feb 01, 2011 at 11:33:49PM -0800, Shirley Ma wrote:
> > On Tue, 2011-02-01 at 23:14 -0800, Shirley Ma wrote:
> > > w/i guest change, I played around the parameters,for example: I
> could
> > > get 3.7Gb/s with 42% CPU BW increasing from 2.5Gb/s for 1K message
> > > size,
> > > w/i dropping packet, I was able to get up to 6.2Gb/s with similar
> CPU
> > > usage.
> >
> > I meant w/o guest change, only vhost changes. Sorry about that.
> >
> > Shirley
>
> Ah, excellent. What were the parameters?
I used half of the ring size 129 for packet counters, but the
performance is still not as good as dropping packets on guest, 3.7 Gb/s
vs. 6.2Gb/s.
Shirley
^ permalink raw reply
* Re: Network performance with small packets
From: Michael S. Tsirkin @ 2011-02-02 15:47 UTC (permalink / raw)
To: Shirley Ma
Cc: Krishna Kumar2, David Miller, kvm, mashirle, netdev, netdev-owner,
Sridhar Samudrala, Steve Dobbelstein
In-Reply-To: <1296661185.25430.10.camel@localhost.localdomain>
On Wed, Feb 02, 2011 at 07:39:45AM -0800, Shirley Ma wrote:
> On Wed, 2011-02-02 at 12:48 +0200, Michael S. Tsirkin wrote:
> > Yes, I think doing this in the host is much simpler,
> > just send an interrupt after there's a decent amount
> > of space in the queue.
> >
> > Having said that the simple heuristic that I coded
> > might be a bit too simple.
>
> >From the debugging out what I have seen so far (a single small message
> TCP_STEAM test), I think the right approach is to patch both guest and
> vhost.
One problem is slowing down the guest helps here.
So there's a chance that just by adding complexity
in guest driver we get a small improvement :(
We can't rely on a patched guest anyway, so
I think it is best to test guest and host changes separately.
And I do agree something needs to be done in guest too,
for example when vqs share an interrupt, we
might invoke a callback when we see vq is not empty
even though it's not requested. Probably should
check interrupts enabled here?
> The problem I have found is a regression for single small
> message TCP_STEAM test. Old kernel works well for TCP_STREAM, only new
> kernel has problem.
Likely new kernel is faster :)
> For Steven's problem, it's multiple stream TCP_RR issues, the old guest
> doesn't perform well, so does new guest kernel. We tested reducing vhost
> signaling patch before, it didn't help the performance at all.
>
> Thanks
> Shirley
Yes, it seems unrelated to tx interrupts.
--
MST
^ permalink raw reply
* Re: Network performance with small packets
From: Michael S. Tsirkin @ 2011-02-02 15:48 UTC (permalink / raw)
To: Shirley Ma
Cc: Sridhar Samudrala, Steve Dobbelstein, David Miller, kvm, mashirle,
netdev
In-Reply-To: <1296661371.25430.13.camel@localhost.localdomain>
On Wed, Feb 02, 2011 at 07:42:51AM -0800, Shirley Ma wrote:
> On Wed, 2011-02-02 at 12:49 +0200, Michael S. Tsirkin wrote:
> > On Tue, Feb 01, 2011 at 11:33:49PM -0800, Shirley Ma wrote:
> > > On Tue, 2011-02-01 at 23:14 -0800, Shirley Ma wrote:
> > > > w/i guest change, I played around the parameters,for example: I
> > could
> > > > get 3.7Gb/s with 42% CPU BW increasing from 2.5Gb/s for 1K message
> > > > size,
> > > > w/i dropping packet, I was able to get up to 6.2Gb/s with similar
> > CPU
> > > > usage.
> > >
> > > I meant w/o guest change, only vhost changes. Sorry about that.
> > >
> > > Shirley
> >
> > Ah, excellent. What were the parameters?
>
> I used half of the ring size 129 for packet counters, but the
> performance is still not as good as dropping packets on guest, 3.7 Gb/s
> vs. 6.2Gb/s.
>
> Shirley
And this is with sndbuf=0 in host, yes?
And do you see a lot of tx interrupts?
How packets per interrupt?
--
MST
^ permalink raw reply
* bonding + igb TX queue warnings
From: Phil Oester @ 2011-02-02 15:55 UTC (permalink / raw)
To: netdev
Running 2.6.36.3 here, and brought up a bond on 2 igb interfaces.
Syslog now getting flooded with this:
kernel: bond0 selects TX queue 16, but real number of TX queues is 16
Any way to change which queue bond0 is selecting or otherwise fix
this?
Phil
^ permalink raw reply
* [Patch] atl1c: Add missing PCI device ID
From: Chuck Ebbert @ 2011-02-02 15:59 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Jie Yang
Commit 8f574b35f22fbb9b5e5f1d11ad6b55b6f35f4533 added support for a new
adapter but failed to add it to the PCI device table.
Signed-Off-By: Chuck Ebbert <cebbert@redhat.com>
--- vanilla-2.6.38-rc3.orig/drivers/net/atl1c/atl1c_main.c
+++ vanilla-2.6.38-rc3/drivers/net/atl1c/atl1c_main.c
@@ -48,6 +48,7 @@ static DEFINE_PCI_DEVICE_TABLE(atl1c_pci
{PCI_DEVICE(PCI_VENDOR_ID_ATTANSIC, PCI_DEVICE_ID_ATHEROS_L2C_B)},
{PCI_DEVICE(PCI_VENDOR_ID_ATTANSIC, PCI_DEVICE_ID_ATHEROS_L2C_B2)},
{PCI_DEVICE(PCI_VENDOR_ID_ATTANSIC, PCI_DEVICE_ID_ATHEROS_L1D)},
+ {PCI_DEVICE(PCI_VENDOR_ID_ATTANSIC, PCI_DEVICE_ID_ATHEROS_L1D_2_0)},
/* required last entry */
{ 0 }
};
^ permalink raw reply
* [patch 0/6] [resend] s390: network patches for net-next
From: frank.blaschka @ 2011-02-02 16:04 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390
Hi Dave,
I have removed the NET_SKB_PAD patch from the patch set.
We will define it in an arch specific header. The new
version of the patch will come via the s390 tree. Thx!
shortlog:
Ursula Braun (3)
qeth: show new mac-address if its setting fails
qeth: allow HiperSockets framesize change in suspend
qeth: allow OSA CHPARM change in suspend state
Frank Blaschka (1)
qeth: add more strict MTU checking
Stefan Weil (2)
s390: Fix wrong size in memcmp (netiucv)
s390: Fix possibly wrong size in strncmp (smsgiucv)
Thanks,
Frank
^ permalink raw reply
* [patch 2/6] [PATCH] qeth: add more strict MTU checking
From: frank.blaschka @ 2011-02-02 16:04 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390
In-Reply-To: <20110202160430.554090958@de.ibm.com>
[-- Attachment #1: 605-qeth-mtu-checking.diff --]
[-- Type: text/plain, Size: 2285 bytes --]
From: Frank Blaschka <frank.blaschka@de.ibm.com>
HiperSockets and OSA hardware report a maximum MTU size. Add checking
to reject larger MTUs than allowed by hardware.
Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>
---
drivers/s390/net/qeth_core_main.c | 35 ++++-------------------------------
1 file changed, 4 insertions(+), 31 deletions(-)
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -1832,33 +1832,6 @@ static inline int qeth_get_initial_mtu_f
}
}
-static inline int qeth_get_max_mtu_for_card(int cardtype)
-{
- switch (cardtype) {
-
- case QETH_CARD_TYPE_UNKNOWN:
- case QETH_CARD_TYPE_OSD:
- case QETH_CARD_TYPE_OSN:
- case QETH_CARD_TYPE_OSM:
- case QETH_CARD_TYPE_OSX:
- return 61440;
- case QETH_CARD_TYPE_IQD:
- return 57344;
- default:
- return 1500;
- }
-}
-
-static inline int qeth_get_mtu_out_of_mpc(int cardtype)
-{
- switch (cardtype) {
- case QETH_CARD_TYPE_IQD:
- return 1;
- default:
- return 0;
- }
-}
-
static inline int qeth_get_mtu_outof_framesize(int framesize)
{
switch (framesize) {
@@ -1881,10 +1854,9 @@ static inline int qeth_mtu_is_valid(stru
case QETH_CARD_TYPE_OSD:
case QETH_CARD_TYPE_OSM:
case QETH_CARD_TYPE_OSX:
- return ((mtu >= 576) && (mtu <= 61440));
case QETH_CARD_TYPE_IQD:
return ((mtu >= 576) &&
- (mtu <= card->info.max_mtu + 4096 - 32));
+ (mtu <= card->info.max_mtu));
case QETH_CARD_TYPE_OSN:
case QETH_CARD_TYPE_UNKNOWN:
default:
@@ -1907,7 +1879,7 @@ static int qeth_ulp_enable_cb(struct qet
memcpy(&card->token.ulp_filter_r,
QETH_ULP_ENABLE_RESP_FILTER_TOKEN(iob->data),
QETH_MPC_TOKEN_LENGTH);
- if (qeth_get_mtu_out_of_mpc(card->info.type)) {
+ if (card->info.type == QETH_CARD_TYPE_IQD) {
memcpy(&framesize, QETH_ULP_ENABLE_RESP_MAX_MTU(iob->data), 2);
mtu = qeth_get_mtu_outof_framesize(framesize);
if (!mtu) {
@@ -1920,7 +1892,8 @@ static int qeth_ulp_enable_cb(struct qet
card->qdio.in_buf_size = mtu + 2 * PAGE_SIZE;
} else {
card->info.initial_mtu = qeth_get_initial_mtu_for_card(card);
- card->info.max_mtu = qeth_get_max_mtu_for_card(card->info.type);
+ card->info.max_mtu = *(__u16 *)QETH_ULP_ENABLE_RESP_MAX_MTU(
+ iob->data);
card->qdio.in_buf_size = QETH_IN_BUF_SIZE_DEFAULT;
}
^ permalink raw reply
* [patch 1/6] [PATCH] qeth: show new mac-address if its setting fails
From: frank.blaschka @ 2011-02-02 16:04 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390, Ursula Braun
In-Reply-To: <20110202160430.554090958@de.ibm.com>
[-- Attachment #1: 604-qeth-mac-address.diff --]
[-- Type: text/plain, Size: 1152 bytes --]
From: Ursula Braun <ursula.braun@de.ibm.com>
Setting of a MAC-address may fail because an already used MAC-address
is to bet set or because of authorization problems. In those cases
qeth issues a message, but the mentioned MAC-address is not the
new MAC-address to be set, but the actual MAC-address. This patch
chooses now the new MAC-address to be set for the error messages.
Signed-off-by: Ursula Braun <ursula.braun@de.ibm.com>
Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>
---
drivers/s390/net/qeth_l2_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/s390/net/qeth_l2_main.c
+++ b/drivers/s390/net/qeth_l2_main.c
@@ -573,13 +573,13 @@ static int qeth_l2_send_setmac_cb(struct
case IPA_RC_L2_DUP_LAYER3_MAC:
dev_warn(&card->gdev->dev,
"MAC address %pM already exists\n",
- card->dev->dev_addr);
+ cmd->data.setdelmac.mac);
break;
case IPA_RC_L2_MAC_NOT_AUTH_BY_HYP:
case IPA_RC_L2_MAC_NOT_AUTH_BY_ADP:
dev_warn(&card->gdev->dev,
"MAC address %pM is not authorized\n",
- card->dev->dev_addr);
+ cmd->data.setdelmac.mac);
break;
default:
break;
^ permalink raw reply
* [patch 3/6] [PATCH] qeth: allow HiperSockets framesize change in suspend
From: frank.blaschka @ 2011-02-02 16:04 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390, Ursula Braun
In-Reply-To: <20110202160430.554090958@de.ibm.com>
[-- Attachment #1: 607-qeth-chparm-change.diff --]
[-- Type: text/plain, Size: 1268 bytes --]
From: Ursula Braun <ursula.braun@de.ibm.com>
For HiperSockets the framesize-definition determines the selected
mtu-size and the size of the allocated qdio buffers.
A framesize-change may occur while a Linux system with probed
HiperSockets device is in suspend state. This patch enables proper
resuming of a HiperSockets device in this case.
Signed-off-by: Ursula Braun <ursula.braun@de.ibm.com>
Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>
---
drivers/s390/net/qeth_core_main.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -1887,8 +1887,16 @@ static int qeth_ulp_enable_cb(struct qet
QETH_DBF_TEXT_(SETUP, 2, " rc%d", iob->rc);
return 0;
}
- card->info.max_mtu = mtu;
+ if (card->info.initial_mtu && (card->info.initial_mtu != mtu)) {
+ /* frame size has changed */
+ if (card->dev &&
+ ((card->dev->mtu == card->info.initial_mtu) ||
+ (card->dev->mtu > mtu)))
+ card->dev->mtu = mtu;
+ qeth_free_qdio_buffers(card);
+ }
card->info.initial_mtu = mtu;
+ card->info.max_mtu = mtu;
card->qdio.in_buf_size = mtu + 2 * PAGE_SIZE;
} else {
card->info.initial_mtu = qeth_get_initial_mtu_for_card(card);
^ permalink raw reply
* [patch 5/6] [PATCH] s390: Fix wrong size in memcmp (netiucv)
From: frank.blaschka @ 2011-02-02 16:04 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390, Stefan Weil
In-Reply-To: <20110202160430.554090958@de.ibm.com>
[-- Attachment #1: 609-netiucv-memcmp-size.diff --]
[-- Type: text/plain, Size: 850 bytes --]
From: Stefan Weil <weil@mail.berlios.de>
This error was reported by cppcheck:
drivers/s390/net/netiucv.c:568: error: Using sizeof for array given
as function argument returns the size of pointer.
sizeof(ipuser) did not result in 16 (as many programmers would have
expected) but sizeof(u8 *), so it is 4 or 8, too small here.
Signed-off-by: Stefan Weil <weil@mail.berlios.de>
Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>
---
drivers/s390/net/netiucv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/s390/net/netiucv.c
+++ b/drivers/s390/net/netiucv.c
@@ -565,7 +565,7 @@ static int netiucv_callback_connreq(stru
struct iucv_event ev;
int rc;
- if (memcmp(iucvMagic, ipuser, sizeof(ipuser)))
+ if (memcmp(iucvMagic, ipuser, 16))
/* ipuser must match iucvMagic. */
return -EINVAL;
rc = -EINVAL;
^ permalink raw reply
* [patch 4/6] [PATCH] qeth: allow OSA CHPARM change in suspend state
From: frank.blaschka @ 2011-02-02 16:04 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390, Ursula braun
In-Reply-To: <20110202160430.554090958@de.ibm.com>
[-- Attachment #1: 608-qeth-osa-chparm-change.diff --]
[-- Type: text/plain, Size: 4525 bytes --]
From: Ursula Braun <ursula.braun@de.ibm.com>
For OSA the CHPARM-definition determines the number of available
outbound queues.
A CHPARM-change may occur while a Linux system with probed
OSA device is in suspend state. This patch enables proper
resuming of an OSA device in this case.
Signed-off-by: Ursula braun <ursula.braun@de.ibm.com>
Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>
---
drivers/s390/net/qeth_core_main.c | 104 +++++++++++++++++++++++---------------
1 file changed, 63 insertions(+), 41 deletions(-)
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -988,16 +988,30 @@ static void qeth_get_channel_path_desc(s
chp_dsc = (struct channelPath_dsc *)ccw_device_get_chp_desc(ccwdev, 0);
if (chp_dsc != NULL) {
/* CHPP field bit 6 == 1 -> single queue */
- if ((chp_dsc->chpp & 0x02) == 0x02)
+ if ((chp_dsc->chpp & 0x02) == 0x02) {
+ if ((atomic_read(&card->qdio.state) !=
+ QETH_QDIO_UNINITIALIZED) &&
+ (card->qdio.no_out_queues == 4))
+ /* change from 4 to 1 outbound queues */
+ qeth_free_qdio_buffers(card);
card->qdio.no_out_queues = 1;
+ if (card->qdio.default_out_queue != 0)
+ dev_info(&card->gdev->dev,
+ "Priority Queueing not supported\n");
+ card->qdio.default_out_queue = 0;
+ } else {
+ if ((atomic_read(&card->qdio.state) !=
+ QETH_QDIO_UNINITIALIZED) &&
+ (card->qdio.no_out_queues == 1)) {
+ /* change from 1 to 4 outbound queues */
+ qeth_free_qdio_buffers(card);
+ card->qdio.default_out_queue = 2;
+ }
+ card->qdio.no_out_queues = 4;
+ }
card->info.func_level = 0x4100 + chp_dsc->desc;
kfree(chp_dsc);
}
- if (card->qdio.no_out_queues == 1) {
- card->qdio.default_out_queue = 0;
- dev_info(&card->gdev->dev,
- "Priority Queueing not supported\n");
- }
QETH_DBF_TEXT_(SETUP, 2, "nr:%x", card->qdio.no_out_queues);
QETH_DBF_TEXT_(SETUP, 2, "lvl:%02x", card->info.func_level);
return;
@@ -3756,6 +3770,47 @@ static inline int qeth_get_qdio_q_format
}
}
+static void qeth_determine_capabilities(struct qeth_card *card)
+{
+ int rc;
+ int length;
+ char *prcd;
+ struct ccw_device *ddev;
+ int ddev_offline = 0;
+
+ QETH_DBF_TEXT(SETUP, 2, "detcapab");
+ ddev = CARD_DDEV(card);
+ if (!ddev->online) {
+ ddev_offline = 1;
+ rc = ccw_device_set_online(ddev);
+ if (rc) {
+ QETH_DBF_TEXT_(SETUP, 2, "3err%d", rc);
+ goto out;
+ }
+ }
+
+ rc = qeth_read_conf_data(card, (void **) &prcd, &length);
+ if (rc) {
+ QETH_DBF_MESSAGE(2, "%s qeth_read_conf_data returned %i\n",
+ dev_name(&card->gdev->dev), rc);
+ QETH_DBF_TEXT_(SETUP, 2, "5err%d", rc);
+ goto out_offline;
+ }
+ qeth_configure_unitaddr(card, prcd);
+ qeth_configure_blkt_default(card, prcd);
+ kfree(prcd);
+
+ rc = qdio_get_ssqd_desc(ddev, &card->ssqd);
+ if (rc)
+ QETH_DBF_TEXT_(SETUP, 2, "6err%d", rc);
+
+out_offline:
+ if (ddev_offline == 1)
+ ccw_device_set_offline(ddev);
+out:
+ return;
+}
+
static int qeth_qdio_establish(struct qeth_card *card)
{
struct qdio_initialize init_data;
@@ -3886,6 +3941,7 @@ int qeth_core_hardsetup_card(struct qeth
QETH_DBF_TEXT(SETUP, 2, "hrdsetup");
atomic_set(&card->force_alloc_skb, 0);
+ qeth_get_channel_path_desc(card);
retry:
if (retries)
QETH_DBF_MESSAGE(2, "%s Retrying to do IDX activates.\n",
@@ -3914,6 +3970,7 @@ retriable:
else
goto retry;
}
+ qeth_determine_capabilities(card);
qeth_init_tokens(card);
qeth_init_func_level(card);
rc = qeth_idx_activate_channel(&card->read, qeth_idx_read_cb);
@@ -4183,41 +4240,6 @@ void qeth_core_free_discipline(struct qe
card->discipline.ccwgdriver = NULL;
}
-static void qeth_determine_capabilities(struct qeth_card *card)
-{
- int rc;
- int length;
- char *prcd;
-
- QETH_DBF_TEXT(SETUP, 2, "detcapab");
- rc = ccw_device_set_online(CARD_DDEV(card));
- if (rc) {
- QETH_DBF_TEXT_(SETUP, 2, "3err%d", rc);
- goto out;
- }
-
-
- rc = qeth_read_conf_data(card, (void **) &prcd, &length);
- if (rc) {
- QETH_DBF_MESSAGE(2, "%s qeth_read_conf_data returned %i\n",
- dev_name(&card->gdev->dev), rc);
- QETH_DBF_TEXT_(SETUP, 2, "5err%d", rc);
- goto out_offline;
- }
- qeth_configure_unitaddr(card, prcd);
- qeth_configure_blkt_default(card, prcd);
- kfree(prcd);
-
- rc = qdio_get_ssqd_desc(CARD_DDEV(card), &card->ssqd);
- if (rc)
- QETH_DBF_TEXT_(SETUP, 2, "6err%d", rc);
-
-out_offline:
- ccw_device_set_offline(CARD_DDEV(card));
-out:
- return;
-}
-
static int qeth_core_probe_device(struct ccwgroup_device *gdev)
{
struct qeth_card *card;
^ permalink raw reply
* [patch 6/6] [PATCH] s390: Fix possibly wrong size in strncmp (smsgiucv)
From: frank.blaschka @ 2011-02-02 16:04 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390, Stefan Weil
In-Reply-To: <20110202160430.554090958@de.ibm.com>
[-- Attachment #1: 610-smsgiucv-strncmp-size.diff --]
[-- Type: text/plain, Size: 951 bytes --]
From: Stefan Weil <weil@mail.berlios.de>
This error was reported by cppcheck:
drivers/s390/net/smsgiucv.c:63: error: Using sizeof for array given as
function argument returns the size of pointer.
Although there is no runtime problem as long as sizeof(u8 *) == 8,
this misleading code should get fixed.
Signed-off-by: Stefan Weil <weil@mail.berlios.de>
Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>
---
drivers/s390/net/smsgiucv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/s390/net/smsgiucv.c
+++ b/drivers/s390/net/smsgiucv.c
@@ -60,7 +60,7 @@ static struct iucv_handler smsg_handler
static int smsg_path_pending(struct iucv_path *path, u8 ipvmid[8],
u8 ipuser[16])
{
- if (strncmp(ipvmid, "*MSG ", sizeof(ipvmid)) != 0)
+ if (strncmp(ipvmid, "*MSG ", 8) != 0)
return -EINVAL;
/* Path pending from *MSG. */
return iucv_path_accept(path, &smsg_handler, "SMSGIUCV ", NULL);
^ permalink raw reply
* LOAN
From: steve lindsey @ 2011-02-03 8:19 UTC (permalink / raw)
Are you in need of financial help?, you need a loan for your business or to solve
other monetary issues.We offer loans with a fixed interest rate of 2% within
minimum range of $5,000.00 to maximum of $200,000,000.00. Interested applicants
should submit their request via email (stevelindsey112@kkwl.ac.th) for immediate
processing with the information listed below:
Names in full:
Address:
Gender:
Phone Number:
Amount Required:
Loan Duration:
Country:
Best Regard:Steve lindsey
Email:stevelindsey112@kkwl.ac.th
^ permalink raw reply
* [PATCH] ipsec: allow to align IPv4 AH on 32 bits
From: Nicolas Dichtel @ 2011-02-02 16:29 UTC (permalink / raw)
To: David Miller; +Cc: herbert, netdev, christophe.gouault
In-Reply-To: <20110128.114610.193716130.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 388 bytes --]
On 28/01/2011 20:46, David Miller wrote:
> From: Nicolas Dichtel<nicolas.dichtel@6wind.com>
> Date: Fri, 28 Jan 2011 09:51:40 +0100
>
>> On 28/01/2011 05:51, Herbert Xu wrote:
>>> So perhaps an SA configuration flag is needed?
>> I agree. If David is ok, I will update the patch.
>
> Sounds good to me.
Here is the new patch.
The patch for iproute2 in the next email.
Regards,
Nicolas
[-- Attachment #2: 0001-ipsec-allow-to-align-IPv4-AH-on-32-bits.patch --]
[-- Type: text/x-patch, Size: 3736 bytes --]
>From 1772aa5401b24f4cb4cc10b038becdeb2c687531 Mon Sep 17 00:00:00 2001
From: Dang Hongwu <hongwu.dang@6wind.com>
Date: Wed, 22 Dec 2010 11:38:47 -0500
Subject: [PATCH] ipsec: allow to align IPv4 AH on 32 bits
The Linux IPv4 AH stack aligns the AH header on a 64 bit boundary
(like in IPv6). This is not RFC compliant (see RFC4302, Section
3.3.3.2.1), it should be aligned on 32 bits.
For most of the authentication algorithms, the ICV size is 96 bits.
The AH header alignment on 32 or 64 bits gives the same results.
However for SHA-256-128 for instance, the wrong 64 bit alignment results
in adding useless padding in IPv4 AH, which is forbidden by the RFC.
To avoid breaking backward compatibility, we use a new flag
(XFRM_STATE_ALIGN4) do change original behavior.
Initial patch from Dang Hongwu <hongwu.dang@6wind.com> and
Christophe Gouault <christophe.gouault@6wind.com>.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
include/linux/xfrm.h | 1 +
include/net/xfrm.h | 1 +
net/ipv4/ah4.c | 25 +++++++++++++++++++------
3 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/include/linux/xfrm.h b/include/linux/xfrm.h
index 930fdd2..b93d6f5 100644
--- a/include/linux/xfrm.h
+++ b/include/linux/xfrm.h
@@ -350,6 +350,7 @@ struct xfrm_usersa_info {
#define XFRM_STATE_WILDRECV 8
#define XFRM_STATE_ICMP 16
#define XFRM_STATE_AF_UNSPEC 32
+#define XFRM_STATE_ALIGN4 64
};
struct xfrm_usersa_id {
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index b9f385d..1f6e8a0 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -36,6 +36,7 @@
#define XFRM_PROTO_ROUTING IPPROTO_ROUTING
#define XFRM_PROTO_DSTOPTS IPPROTO_DSTOPTS
+#define XFRM_ALIGN4(len) (((len) + 3) & ~3)
#define XFRM_ALIGN8(len) (((len) + 7) & ~7)
#define MODULE_ALIAS_XFRM_MODE(family, encap) \
MODULE_ALIAS("xfrm-mode-" __stringify(family) "-" __stringify(encap))
diff --git a/net/ipv4/ah4.c b/net/ipv4/ah4.c
index 86961be..325053d 100644
--- a/net/ipv4/ah4.c
+++ b/net/ipv4/ah4.c
@@ -201,7 +201,10 @@ static int ah_output(struct xfrm_state *x, struct sk_buff *skb)
top_iph->ttl = 0;
top_iph->check = 0;
- ah->hdrlen = (XFRM_ALIGN8(sizeof(*ah) + ahp->icv_trunc_len) >> 2) - 2;
+ if (x->props.flags & XFRM_STATE_ALIGN4)
+ ah->hdrlen = (XFRM_ALIGN4(sizeof(*ah) + ahp->icv_trunc_len) >> 2) - 2;
+ else
+ ah->hdrlen = (XFRM_ALIGN8(sizeof(*ah) + ahp->icv_trunc_len) >> 2) - 2;
ah->reserved = 0;
ah->spi = x->id.spi;
@@ -299,9 +302,15 @@ static int ah_input(struct xfrm_state *x, struct sk_buff *skb)
nexthdr = ah->nexthdr;
ah_hlen = (ah->hdrlen + 2) << 2;
- if (ah_hlen != XFRM_ALIGN8(sizeof(*ah) + ahp->icv_full_len) &&
- ah_hlen != XFRM_ALIGN8(sizeof(*ah) + ahp->icv_trunc_len))
- goto out;
+ if (x->props.flags & XFRM_STATE_ALIGN4) {
+ if (ah_hlen != XFRM_ALIGN4(sizeof(*ah) + ahp->icv_full_len) &&
+ ah_hlen != XFRM_ALIGN4(sizeof(*ah) + ahp->icv_trunc_len))
+ goto out;
+ } else {
+ if (ah_hlen != XFRM_ALIGN8(sizeof(*ah) + ahp->icv_full_len) &&
+ ah_hlen != XFRM_ALIGN8(sizeof(*ah) + ahp->icv_trunc_len))
+ goto out;
+ }
if (!pskb_may_pull(skb, ah_hlen))
goto out;
@@ -450,8 +459,12 @@ static int ah_init_state(struct xfrm_state *x)
BUG_ON(ahp->icv_trunc_len > MAX_AH_AUTH_LEN);
- x->props.header_len = XFRM_ALIGN8(sizeof(struct ip_auth_hdr) +
- ahp->icv_trunc_len);
+ if (x->props.flags & XFRM_STATE_ALIGN4)
+ x->props.header_len = XFRM_ALIGN4(sizeof(struct ip_auth_hdr) +
+ ahp->icv_trunc_len);
+ else
+ x->props.header_len = XFRM_ALIGN8(sizeof(struct ip_auth_hdr) +
+ ahp->icv_trunc_len);
if (x->props.mode == XFRM_MODE_TUNNEL)
x->props.header_len += sizeof(struct iphdr);
x->data = ahp;
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH] ipv4: Remove fib_hash.
From: Stephen Hemminger @ 2011-02-02 16:29 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev
In-Reply-To: <20110201.181542.193701016.davem@davemloft.net>
On Tue, 01 Feb 2011 18:15:42 -0800 (PST)
David Miller <davem@davemloft.net> wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed, 02 Feb 2011 01:48:13 +0100
>
> > Hmm... I know having to maintain two implementations is time consuming,
> > but I know fib_trie is bigger :
> >
> > # size net/ipv4/fib_*.o
> > text data bss dec hex filename
> > 7252 120 0 7372 1ccc net/ipv4/fib_frontend.o
> > 7279 16 4 7299 1c83 net/ipv4/fib_hash.o
> > 1479 0 0 1479 5c7 net/ipv4/fib_rules.o
> > 7885 0 2080 9965 26ed net/ipv4/fib_semantics.o
> > 16222 16 16 16254 3f7e net/ipv4/fib_trie.o
> >
> > In my tests, I know that fib_trie is more expensive for typical routing
> > tables for hosts (no more than a dozen or entries), in latencies
> > results, mostly because of icache misses, but also dcache ones.
>
> It's mostly the rebalancing code that takes up the space.
>
> The lookup path is on the same order of magnitude as the fib hash
> stuff was.
>
> In any event, we have several months to hash out any regressions and I
> think if I didn't do this removal nobody would work on it so... :-)
For the case of small devices, what about keeping fib_hash as option
under CONFIG_EMBEDDED. And remove all the magic resizing of hash table.
Get back to something with really small size.
--
^ permalink raw reply
* [PATCH] iproute2: allow to specify truncation bits on auth algo
From: Nicolas Dichtel @ 2011-02-02 16:30 UTC (permalink / raw)
To: David Miller; +Cc: herbert, netdev, christophe.gouault
In-Reply-To: <20110128.114610.193716130.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 350 bytes --]
On 28/01/2011 20:46, David Miller wrote:
> From: Nicolas Dichtel<nicolas.dichtel@6wind.com>
> Date: Fri, 28 Jan 2011 09:51:40 +0100
>
>> On 28/01/2011 05:51, Herbert Xu wrote:
>>> So perhaps an SA configuration flag is needed?
>> I agree. If David is ok, I will update the patch.
>
> Sounds good to me.
And the patch for iproute2.
Regards,
Nicolas
[-- Attachment #2: 0001-iproute2-allow-to-specify-truncation-bits-on-auth-a.patch --]
[-- Type: text/x-patch, Size: 5896 bytes --]
>From e0d84548d363cfa46a03719bc318ef52fa5ca98f Mon Sep 17 00:00:00 2001
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Thu, 23 Dec 2010 06:48:12 -0500
Subject: [PATCH] iproute2: allow to specify truncation bits on auth algo
Attribute XFRMA_ALG_AUTH_TRUNC can be used to specify
truncation bits, so we add a new algo type: auth-trunc.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
ip/ipxfrm.c | 28 +++++++++++++++++++++++++++-
ip/xfrm_state.c | 50 +++++++++++++++++++++++++++++++++-----------------
2 files changed, 60 insertions(+), 18 deletions(-)
diff --git a/ip/ipxfrm.c b/ip/ipxfrm.c
index ba7360f..591f7bf 100644
--- a/ip/ipxfrm.c
+++ b/ip/ipxfrm.c
@@ -155,6 +155,7 @@ const char *strxf_xfrmproto(__u8 proto)
static const struct typeent algo_types[]= {
{ "enc", XFRMA_ALG_CRYPT }, { "auth", XFRMA_ALG_AUTH },
{ "comp", XFRMA_ALG_COMP }, { "aead", XFRMA_ALG_AEAD },
+ { "auth-trunc", XFRMA_ALG_AUTH_TRUNC },
{ NULL, -1 }
};
@@ -570,6 +571,25 @@ static void xfrm_aead_print(struct xfrm_algo_aead *algo, int len,
fprintf(fp, "%s", _SL_);
}
+static void xfrm_auth_trunc_print(struct xfrm_algo_auth *algo, int len,
+ FILE *fp, const char *prefix)
+{
+ struct {
+ struct xfrm_algo algo;
+ char key[algo->alg_key_len / 8];
+ } base;
+
+ memcpy(base.algo.alg_name, algo->alg_name, sizeof(base.algo.alg_name));
+ base.algo.alg_key_len = algo->alg_key_len;
+ memcpy(base.algo.alg_key, algo->alg_key, algo->alg_key_len / 8);
+
+ __xfrm_algo_print(&base.algo, XFRMA_ALG_AUTH_TRUNC, len, fp, prefix, 0);
+
+ fprintf(fp, " %d", algo->alg_trunc_len);
+
+ fprintf(fp, "%s", _SL_);
+}
+
static void xfrm_tmpl_print(struct xfrm_user_tmpl *tmpls, int len,
__u16 family, FILE *fp, const char *prefix)
{
@@ -677,12 +697,18 @@ void xfrm_xfrma_print(struct rtattr *tb[], __u16 family,
fprintf(fp, "\tmark %d/0x%x\n", m->v, m->m);
}
- if (tb[XFRMA_ALG_AUTH]) {
+ if (tb[XFRMA_ALG_AUTH] && !tb[XFRMA_ALG_AUTH_TRUNC]) {
struct rtattr *rta = tb[XFRMA_ALG_AUTH];
xfrm_algo_print((struct xfrm_algo *) RTA_DATA(rta),
XFRMA_ALG_AUTH, RTA_PAYLOAD(rta), fp, prefix);
}
+ if (tb[XFRMA_ALG_AUTH_TRUNC]) {
+ struct rtattr *rta = tb[XFRMA_ALG_AUTH_TRUNC];
+ xfrm_auth_trunc_print((struct xfrm_algo_auth *) RTA_DATA(rta),
+ RTA_PAYLOAD(rta), fp, prefix);
+ }
+
if (tb[XFRMA_ALG_AEAD]) {
struct rtattr *rta = tb[XFRMA_ALG_AEAD];
xfrm_aead_print((struct xfrm_algo_aead *)RTA_DATA(rta),
diff --git a/ip/xfrm_state.c b/ip/xfrm_state.c
index 70f0a0b..5260d85 100644
--- a/ip/xfrm_state.c
+++ b/ip/xfrm_state.c
@@ -83,18 +83,19 @@ static void usage(void)
//fprintf(stderr, "REQID - number(default=0)\n");
fprintf(stderr, "FLAG-LIST := [ FLAG-LIST ] FLAG\n");
- fprintf(stderr, "FLAG := [ noecn | decap-dscp | nopmtudisc | wildrecv | icmp | af-unspec ]\n");
+ fprintf(stderr, "FLAG := [ noecn | decap-dscp | nopmtudisc | wildrecv | icmp | af-unspec | align4 ]\n");
fprintf(stderr, "ENCAP := ENCAP-TYPE SPORT DPORT OADDR\n");
fprintf(stderr, "ENCAP-TYPE := espinudp | espinudp-nonike\n");
fprintf(stderr, "ALGO-LIST := [ ALGO-LIST ] | [ ALGO ]\n");
fprintf(stderr, "ALGO := ALGO_TYPE ALGO_NAME ALGO_KEY "
- "[ ALGO_ICV_LEN ]\n");
+ "[ ALGO_ICV_LEN | ALGO_TRUNC_LEN ]\n");
fprintf(stderr, "ALGO_TYPE := [ ");
fprintf(stderr, "%s | ", strxf_algotype(XFRMA_ALG_AEAD));
fprintf(stderr, "%s | ", strxf_algotype(XFRMA_ALG_CRYPT));
fprintf(stderr, "%s | ", strxf_algotype(XFRMA_ALG_AUTH));
+ fprintf(stderr, "%s | ", strxf_algotype(XFRMA_ALG_AUTH_TRUNC));
fprintf(stderr, "%s ", strxf_algotype(XFRMA_ALG_COMP));
fprintf(stderr, "]\n");
@@ -342,6 +343,7 @@ static int xfrm_state_modify(int cmd, unsigned flags, int argc, char **argv)
case XFRMA_ALG_AEAD:
case XFRMA_ALG_CRYPT:
case XFRMA_ALG_AUTH:
+ case XFRMA_ALG_AUTH_TRUNC:
case XFRMA_ALG_COMP:
{
/* ALGO */
@@ -349,11 +351,12 @@ static int xfrm_state_modify(int cmd, unsigned flags, int argc, char **argv)
union {
struct xfrm_algo alg;
struct xfrm_algo_aead aead;
+ struct xfrm_algo_auth auth;
} u;
char buf[XFRM_ALGO_KEY_BUF_SIZE];
} alg = {};
int len;
- __u32 icvlen;
+ __u32 icvlen, trunclen;
char *name;
char *key;
char *buf;
@@ -370,6 +373,7 @@ static int xfrm_state_modify(int cmd, unsigned flags, int argc, char **argv)
ealgop = *argv;
break;
case XFRMA_ALG_AUTH:
+ case XFRMA_ALG_AUTH_TRUNC:
if (aalgop)
duparg("ALGOTYPE", *argv);
aalgop = *argv;
@@ -397,21 +401,33 @@ static int xfrm_state_modify(int cmd, unsigned flags, int argc, char **argv)
buf = alg.u.alg.alg_key;
len = sizeof(alg.u.alg);
- if (type != XFRMA_ALG_AEAD)
- goto parse_algo;
-
- if (!NEXT_ARG_OK())
- missarg("ALGOICVLEN");
- NEXT_ARG();
- if (get_u32(&icvlen, *argv, 0))
- invarg("\"aead\" ICV length is invalid",
- *argv);
- alg.u.aead.alg_icv_len = icvlen;
-
- buf = alg.u.aead.alg_key;
- len = sizeof(alg.u.aead);
+ switch (type) {
+ case XFRMA_ALG_AEAD:
+ if (!NEXT_ARG_OK())
+ missarg("ALGOICVLEN");
+ NEXT_ARG();
+ if (get_u32(&icvlen, *argv, 0))
+ invarg("\"aead\" ICV length is invalid",
+ *argv);
+ alg.u.aead.alg_icv_len = icvlen;
+
+ buf = alg.u.aead.alg_key;
+ len = sizeof(alg.u.aead);
+ break;
+ case XFRMA_ALG_AUTH_TRUNC:
+ if (!NEXT_ARG_OK())
+ missarg("ALGOTRUNCLEN");
+ NEXT_ARG();
+ if (get_u32(&trunclen, *argv, 0))
+ invarg("\"auth\" trunc length is invalid",
+ *argv);
+ alg.u.auth.alg_trunc_len = trunclen;
+
+ buf = alg.u.auth.alg_key;
+ len = sizeof(alg.u.auth);
+ break;
+ }
-parse_algo:
xfrm_algo_parse((void *)&alg, type, name, key,
buf, sizeof(alg.buf));
len += alg.u.alg.alg_key_len;
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH] iproute2: allow to specify truncation bits on auth algo
From: Nicolas Dichtel @ 2011-02-02 16:34 UTC (permalink / raw)
Cc: David Miller, herbert, netdev, christophe.gouault
In-Reply-To: <4D498693.6020909@6wind.com>
[-- Attachment #1: Type: text/plain, Size: 463 bytes --]
On 02/02/2011 17:30, Nicolas Dichtel wrote:
> On 28/01/2011 20:46, David Miller wrote:
>> From: Nicolas Dichtel<nicolas.dichtel@6wind.com>
>> Date: Fri, 28 Jan 2011 09:51:40 +0100
>>
>>> On 28/01/2011 05:51, Herbert Xu wrote:
>>>> So perhaps an SA configuration flag is needed?
>>> I agree. If David is ok, I will update the patch.
>>
>> Sounds good to me.
> And the patch for iproute2.
Sorry, two patches were mixed :(
Here is the right one.
Regards,
Nicolas
[-- Attachment #2: 0001-iproute2-add-support-of-flag-XFRM_STATE_ALIGN4.patch --]
[-- Type: text/x-patch, Size: 2232 bytes --]
>From fe61b9c3564b2f9504bca652cdea80ff3b5a2743 Mon Sep 17 00:00:00 2001
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Tue, 1 Feb 2011 07:29:54 -0500
Subject: [PATCH] iproute2: add support of flag XFRM_STATE_ALIGN4
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
include/linux/xfrm.h | 1 +
ip/ipxfrm.c | 1 +
ip/xfrm_state.c | 4 +++-
3 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/include/linux/xfrm.h b/include/linux/xfrm.h
index 07f2b63..8b2d220 100644
--- a/include/linux/xfrm.h
+++ b/include/linux/xfrm.h
@@ -349,6 +349,7 @@ struct xfrm_usersa_info {
#define XFRM_STATE_WILDRECV 8
#define XFRM_STATE_ICMP 16
#define XFRM_STATE_AF_UNSPEC 32
+#define XFRM_STATE_ALIGN4 64
};
struct xfrm_usersa_id {
diff --git a/ip/ipxfrm.c b/ip/ipxfrm.c
index 9753822..ba7360f 100644
--- a/ip/ipxfrm.c
+++ b/ip/ipxfrm.c
@@ -828,6 +828,7 @@ void xfrm_state_info_print(struct xfrm_usersa_info *xsinfo,
XFRM_FLAG_PRINT(fp, flags, XFRM_STATE_WILDRECV, "wildrecv");
XFRM_FLAG_PRINT(fp, flags, XFRM_STATE_ICMP, "icmp");
XFRM_FLAG_PRINT(fp, flags, XFRM_STATE_AF_UNSPEC, "af-unspec");
+ XFRM_FLAG_PRINT(fp, flags, XFRM_STATE_ALIGN4, "align4");
if (flags)
fprintf(fp, "%x", flags);
}
diff --git a/ip/xfrm_state.c b/ip/xfrm_state.c
index 38d4039..e8c7c96 100644
--- a/ip/xfrm_state.c
+++ b/ip/xfrm_state.c
@@ -83,7 +83,7 @@ static void usage(void)
//fprintf(stderr, "REQID - number(default=0)\n");
fprintf(stderr, "FLAG-LIST := [ FLAG-LIST ] FLAG\n");
- fprintf(stderr, "FLAG := [ noecn | decap-dscp | nopmtudisc | wildrecv | icmp | af-unspec ]\n");
+ fprintf(stderr, "FLAG := [ noecn | decap-dscp | nopmtudisc | wildrecv | icmp | af-unspec | align4 ]\n");
fprintf(stderr, "ENCAP := ENCAP-TYPE SPORT DPORT OADDR\n");
fprintf(stderr, "ENCAP-TYPE := espinudp | espinudp-nonike\n");
@@ -214,6 +214,8 @@ static int xfrm_state_flag_parse(__u8 *flags, int *argcp, char ***argvp)
*flags |= XFRM_STATE_ICMP;
else if (strcmp(*argv, "af-unspec") == 0)
*flags |= XFRM_STATE_AF_UNSPEC;
+ else if (strcmp(*argv, "align4") == 0)
+ *flags |= XFRM_STATE_ALIGN4;
else {
PREV_ARG(); /* back track */
break;
--
1.5.6.5
^ 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