* Re: [PATCH] can: dev: fix nlmsg size calculation in can_get_size()
From: Marc Kleine-Budde @ 2013-10-07 14:14 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: netdev, linux-can, kernel
In-Reply-To: <52507B7D.6030008@grandegger.com>
[-- Attachment #1: Type: text/plain, Size: 1045 bytes --]
On 10/05/2013 10:50 PM, Wolfgang Grandegger wrote:
> On 10/05/2013 09:25 PM, Marc Kleine-Budde wrote:
>> This patch fixes the calculation of the nlmsg size, by adding the missing
>> nla_total_size().
>>
>> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
>> ---
>> Hello,
>>
>> this patch touches the rtnl_link_ops get_size() callback:
>>
>> static struct rtnl_link_ops can_link_ops __read_mostly = {
>> ...
>> .get_size = can_get_size,
>> ...
>> };
>>
>> By looking at other nlmsg size calculation I think a nla_total_size() for all
>> contributers is needed. Am I correct?
>
> Yes, seems so, nla_put() calls this code:
>
> http://lxr.free-electrons.com/source/lib/nlattr.c#L328
Is this an Acked-by? :)
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply
* Re: [PATCHv1 net] xen-netback: transition to CLOSED when removing a VIF
From: David Vrabel @ 2013-10-07 13:57 UTC (permalink / raw)
To: Wei Liu
Cc: xen-devel, Konrad Rzeszutek Wilk, Boris Ostrovsky, netdev,
Ian Campbell, Paul Durrant
In-Reply-To: <20131007134314.GD28411@zion.uk.xensource.com>
On 07/10/13 14:43, Wei Liu wrote:
> On Mon, Oct 07, 2013 at 01:55:19PM +0100, David Vrabel wrote:
>> From: David Vrabel <david.vrabel@citrix.com>
>>
>> If a guest is destroyed without transitioning its frontend to CLOSED,
>> the domain becomes a zombie as netback was not grant unmapping the
>> shared rings.
>>
>> When removing a VIF, transition the backend to CLOSED so the VIF is
>> disconnected if necessary (which will unmap the shared rings etc).
>>
>> This fixes a regression introduced by
>> 279f438e36c0a70b23b86d2090aeec50155034a9 (xen-netback: Don't destroy
>> the netdev until the vif is shut down).
>>
>
> Is this regression solely caused by 279f438e36c or caused by both
> ea732dff5c and 279f438e36c? I ask because you make use of the new state
> machine introduced in ea732dff5c. Or are you simply using the new state
> machine to fix the regression instead of going back to old code?
I bisected it to 279f438. I'm just using the handy new state machine to
fix it.
David
^ permalink raw reply
* Re: [PATCHv1 net] xen-netback: transition to CLOSED when removing a VIF
From: Wei Liu @ 2013-10-07 13:43 UTC (permalink / raw)
To: David Vrabel
Cc: xen-devel, Konrad Rzeszutek Wilk, Boris Ostrovsky, netdev,
Ian Campbell, Wei Liu, Paul Durrant
In-Reply-To: <1381150519-14557-1-git-send-email-david.vrabel@citrix.com>
On Mon, Oct 07, 2013 at 01:55:19PM +0100, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
>
> If a guest is destroyed without transitioning its frontend to CLOSED,
> the domain becomes a zombie as netback was not grant unmapping the
> shared rings.
>
> When removing a VIF, transition the backend to CLOSED so the VIF is
> disconnected if necessary (which will unmap the shared rings etc).
>
> This fixes a regression introduced by
> 279f438e36c0a70b23b86d2090aeec50155034a9 (xen-netback: Don't destroy
> the netdev until the vif is shut down).
>
Is this regression solely caused by 279f438e36c or caused by both
ea732dff5c and 279f438e36c? I ask because you make use of the new state
machine introduced in ea732dff5c. Or are you simply using the new state
machine to fix the regression instead of going back to old code?
Wei.
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Cc: Paul Durrant <Paul.Durrant@citrix.com>
> ---
> drivers/net/xen-netback/xenbus.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
> index b45bce2..1b08d87 100644
> --- a/drivers/net/xen-netback/xenbus.c
> +++ b/drivers/net/xen-netback/xenbus.c
> @@ -39,11 +39,15 @@ static int connect_rings(struct backend_info *);
> static void connect(struct backend_info *);
> static void backend_create_xenvif(struct backend_info *be);
> static void unregister_hotplug_status_watch(struct backend_info *be);
> +static void set_backend_state(struct backend_info *be,
> + enum xenbus_state state);
>
> static int netback_remove(struct xenbus_device *dev)
> {
> struct backend_info *be = dev_get_drvdata(&dev->dev);
>
> + set_backend_state(be, XenbusStateClosed);
> +
> unregister_hotplug_status_watch(be);
> if (be->vif) {
> kobject_uevent(&dev->dev.kobj, KOBJ_OFFLINE);
> --
> 1.7.2.5
^ permalink raw reply
* Re: [PATCH net V1 2/2] net/mlx4_en: Fix pages never dma unmapped on rx
From: Eric Dumazet @ 2013-10-07 13:47 UTC (permalink / raw)
To: Amir Vadai
Cc: David S. Miller, netdev, Or Gerlitz, Eugenia Emantayev,
Eric Dumazet
In-Reply-To: <1381145893-20930-3-git-send-email-amirv@mellanox.com>
On Mon, 2013-10-07 at 13:38 +0200, Amir Vadai wrote:
> This patch fixes a bug introduced by commit 51151a16 (mlx4: allow
> order-0 memory allocations in RX path).
>
> dma_unmap_page never reached because condition to detect last fragment
> in page is wrong. offset+frag_stride can't be greater than size, need to
> make sure no additional frag will fit in page => compare offset +
> frag_stride + next_frag_size instead.
> next_frag_size is the same as the current one, since page is shared only
> with frags of the same size.
>
> CC: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Amir Vadai <amirv@mellanox.com>
> ---
> After looking at the code again, need to use 2*frag_stride and not to look at
> size of next frag in skb. Changed it accordingly
Yes indeed this looks much better, thanks !
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH net V1 1/2] net/mlx4_en: Rename name of mlx4_en_rx_alloc members
From: Eric Dumazet @ 2013-10-07 13:44 UTC (permalink / raw)
To: Amir Vadai
Cc: David S. Miller, netdev, Or Gerlitz, Eugenia Emantayev,
Eric Dumazet
In-Reply-To: <1381145893-20930-2-git-send-email-amirv@mellanox.com>
On Mon, 2013-10-07 at 13:38 +0200, Amir Vadai wrote:
> Add page prefix to page related members: @size and @offset into
> @page_size and @page_offset
>
> CC: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Amir Vadai <amirv@mellanox.com>
> ---
> drivers/net/ethernet/mellanox/mlx4/en_rx.c | 40 ++++++++++++++++------------
> drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 4 +--
> 2 files changed, 25 insertions(+), 19 deletions(-)
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH] usbnet: smsc95xx: Add device tree input for MAC address
From: Dan Murphy @ 2013-10-07 13:30 UTC (permalink / raw)
To: Ming Lei
Cc: Steve Glendinning, Network Development, Linux Kernel Mailing List,
linux-usb, mugunthanvnm-l0cyMroinI0
In-Reply-To: <CACVXFVNAB3VnmdoP_LGJsBjQ17j1aoqKMsBE7LRt65OqROeRUQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 10/07/2013 06:42 AM, Ming Lei wrote:
> On Mon, Oct 7, 2013 at 1:31 AM, Dan Murphy <dmurphy-l0cyMroinI0@public.gmane.org> wrote:
>> On 10/06/2013 10:05 AM, Ming Lei wrote:
>>> On Sat, Oct 5, 2013 at 2:25 AM, Dan Murphy <dmurphy-l0cyMroinI0@public.gmane.org> wrote:
>>>> If the smsc95xx does not have a valid MAC address stored within
>>>> the eeprom then a random number is generated. The MAC can also
>>>> be set by uBoot but the smsc95xx does not have a way to read this.
>>>>
>>>> Create the binding for the smsc95xx so that uBoot can set the MAC
>>>> and the code can retrieve the MAC from the modified DTB file.
>>> Suppose there are two smsc95xx usbnet devices connected to usb bus, and
>>> one is built-in, another is hotplug device, can your patch handle the situation
>>> correctly?
>> Look at this line in the patch below
>>
>> sprintf(of_name, "%s%i", SMSC95XX_OF_NAME, dev->udev->dev.id);
>>
>> I am appending the dev ID of the device to the of_name here. As long as init_mac_address is called, the dev.id and the uBoot
>> entry match then yes.
> Currently, non-root-hub usb device is created and added into usb bus without
> any platform(device tree) knowledge, so you can't expect the match here.
That is correct. Platform/dev tree will have no concept of the PnP USB dongle therefore there should be no entry in either.
I will need to test this issue with a PnP usb->ethernet dongle.
Dan
> Also not mention the two smsc95xx devices may attach to two different
> usb host controllers(buses).
>
> Thanks,
--
------------------
Dan Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCHv1 net] xen-netback: transition to CLOSED when removing a VIF
From: David Vrabel @ 2013-10-07 12:55 UTC (permalink / raw)
To: xen-devel
Cc: David Vrabel, Konrad Rzeszutek Wilk, Boris Ostrovsky, netdev,
Ian Campbell, Wei Liu, Paul Durrant
From: David Vrabel <david.vrabel@citrix.com>
If a guest is destroyed without transitioning its frontend to CLOSED,
the domain becomes a zombie as netback was not grant unmapping the
shared rings.
When removing a VIF, transition the backend to CLOSED so the VIF is
disconnected if necessary (which will unmap the shared rings etc).
This fixes a regression introduced by
279f438e36c0a70b23b86d2090aeec50155034a9 (xen-netback: Don't destroy
the netdev until the vif is shut down).
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Paul Durrant <Paul.Durrant@citrix.com>
---
drivers/net/xen-netback/xenbus.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index b45bce2..1b08d87 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -39,11 +39,15 @@ static int connect_rings(struct backend_info *);
static void connect(struct backend_info *);
static void backend_create_xenvif(struct backend_info *be);
static void unregister_hotplug_status_watch(struct backend_info *be);
+static void set_backend_state(struct backend_info *be,
+ enum xenbus_state state);
static int netback_remove(struct xenbus_device *dev)
{
struct backend_info *be = dev_get_drvdata(&dev->dev);
+ set_backend_state(be, XenbusStateClosed);
+
unregister_hotplug_status_watch(be);
if (be->vif) {
kobject_uevent(&dev->dev.kobj, KOBJ_OFFLINE);
--
1.7.2.5
^ permalink raw reply related
* Re: [PATCH] usbnet: smsc95xx: Add device tree input for MAC address
From: Ming Lei @ 2013-10-07 11:42 UTC (permalink / raw)
To: Dan Murphy
Cc: Steve Glendinning, Network Development, Linux Kernel Mailing List,
linux-usb, mugunthanvnm
In-Reply-To: <52519E7A.40804@ti.com>
On Mon, Oct 7, 2013 at 1:31 AM, Dan Murphy <dmurphy@ti.com> wrote:
> On 10/06/2013 10:05 AM, Ming Lei wrote:
>> On Sat, Oct 5, 2013 at 2:25 AM, Dan Murphy <dmurphy@ti.com> wrote:
>>> If the smsc95xx does not have a valid MAC address stored within
>>> the eeprom then a random number is generated. The MAC can also
>>> be set by uBoot but the smsc95xx does not have a way to read this.
>>>
>>> Create the binding for the smsc95xx so that uBoot can set the MAC
>>> and the code can retrieve the MAC from the modified DTB file.
>> Suppose there are two smsc95xx usbnet devices connected to usb bus, and
>> one is built-in, another is hotplug device, can your patch handle the situation
>> correctly?
>
> Look at this line in the patch below
>
> sprintf(of_name, "%s%i", SMSC95XX_OF_NAME, dev->udev->dev.id);
>
> I am appending the dev ID of the device to the of_name here. As long as init_mac_address is called, the dev.id and the uBoot
> entry match then yes.
Currently, non-root-hub usb device is created and added into usb bus without
any platform(device tree) knowledge, so you can't expect the match here.
Also not mention the two smsc95xx devices may attach to two different
usb host controllers(buses).
Thanks,
--
Ming Lei
^ permalink raw reply
* [PATCH net V1 2/2] net/mlx4_en: Fix pages never dma unmapped on rx
From: Amir Vadai @ 2013-10-07 11:38 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Amir Vadai, Or Gerlitz, Eugenia Emantayev, Eric Dumazet
In-Reply-To: <1381145893-20930-1-git-send-email-amirv@mellanox.com>
This patch fixes a bug introduced by commit 51151a16 (mlx4: allow
order-0 memory allocations in RX path).
dma_unmap_page never reached because condition to detect last fragment
in page is wrong. offset+frag_stride can't be greater than size, need to
make sure no additional frag will fit in page => compare offset +
frag_stride + next_frag_size instead.
next_frag_size is the same as the current one, since page is shared only
with frags of the same size.
CC: Eric Dumazet <edumazet@google.com>
Signed-off-by: Amir Vadai <amirv@mellanox.com>
---
After looking at the code again, need to use 2*frag_stride and not to look at
size of next frag in skb. Changed it accordingly
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index 066fc27..afe2efa 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -135,9 +135,10 @@ static void mlx4_en_free_frag(struct mlx4_en_priv *priv,
int i)
{
const struct mlx4_en_frag_info *frag_info = &priv->frag_info[i];
+ u32 next_frag_end = frags[i].page_offset + 2 * frag_info->frag_stride;
- if (frags[i].page_offset + frag_info->frag_stride >
- frags[i].page_size)
+
+ if (next_frag_end > frags[i].page_size)
dma_unmap_page(priv->ddev, frags[i].dma, frags[i].page_size,
PCI_DMA_FROMDEVICE);
--
1.8.3.4
^ permalink raw reply related
* [PATCH net V1 0/2] net/mlx4_en: Fix pages never dma unmapped on rx
From: Amir Vadai @ 2013-10-07 11:38 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Amir Vadai, Or Gerlitz, Eugenia Emantayev, Eric Dumazet
This patchset fixes a bug introduced by commit 51151a16 (mlx4: allow order-0
memory allocations in RX path). Where dma_unmap_page wasn't called.
Changes from V0:
- Added "Rename name of mlx4_en_rx_alloc members". Old names were confusing.
- Last frag in page calculation was wrong. Since all frags in page are of the
same size, need to add this frag_stride to end of frag offset, and not the
size of next frag in skb.
Amir Vadai (2):
net/mlx4_en: Rename name of mlx4_en_rx_alloc members
net/mlx4_en: Fix pages never dma unmapped on rx
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 41 ++++++++++++++++------------
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 4 +--
2 files changed, 26 insertions(+), 19 deletions(-)
--
1.8.3.4
^ permalink raw reply
* [PATCH net V1 1/2] net/mlx4_en: Rename name of mlx4_en_rx_alloc members
From: Amir Vadai @ 2013-10-07 11:38 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Amir Vadai, Or Gerlitz, Eugenia Emantayev, Eric Dumazet
In-Reply-To: <1381145893-20930-1-git-send-email-amirv@mellanox.com>
Add page prefix to page related members: @size and @offset into
@page_size and @page_offset
CC: Eric Dumazet <edumazet@google.com>
Signed-off-by: Amir Vadai <amirv@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 40 ++++++++++++++++------------
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 4 +--
2 files changed, 25 insertions(+), 19 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index dec455c..066fc27 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -70,14 +70,15 @@ static int mlx4_alloc_pages(struct mlx4_en_priv *priv,
put_page(page);
return -ENOMEM;
}
- page_alloc->size = PAGE_SIZE << order;
+ page_alloc->page_size = PAGE_SIZE << order;
page_alloc->page = page;
page_alloc->dma = dma;
- page_alloc->offset = frag_info->frag_align;
+ page_alloc->page_offset = frag_info->frag_align;
/* Not doing get_page() for each frag is a big win
* on asymetric workloads.
*/
- atomic_set(&page->_count, page_alloc->size / frag_info->frag_stride);
+ atomic_set(&page->_count,
+ page_alloc->page_size / frag_info->frag_stride);
return 0;
}
@@ -96,16 +97,19 @@ static int mlx4_en_alloc_frags(struct mlx4_en_priv *priv,
for (i = 0; i < priv->num_frags; i++) {
frag_info = &priv->frag_info[i];
page_alloc[i] = ring_alloc[i];
- page_alloc[i].offset += frag_info->frag_stride;
- if (page_alloc[i].offset + frag_info->frag_stride <= ring_alloc[i].size)
+ page_alloc[i].page_offset += frag_info->frag_stride;
+
+ if (page_alloc[i].page_offset + frag_info->frag_stride <=
+ ring_alloc[i].page_size)
continue;
+
if (mlx4_alloc_pages(priv, &page_alloc[i], frag_info, gfp))
goto out;
}
for (i = 0; i < priv->num_frags; i++) {
frags[i] = ring_alloc[i];
- dma = ring_alloc[i].dma + ring_alloc[i].offset;
+ dma = ring_alloc[i].dma + ring_alloc[i].page_offset;
ring_alloc[i] = page_alloc[i];
rx_desc->data[i].addr = cpu_to_be64(dma);
}
@@ -117,7 +121,7 @@ out:
frag_info = &priv->frag_info[i];
if (page_alloc[i].page != ring_alloc[i].page) {
dma_unmap_page(priv->ddev, page_alloc[i].dma,
- page_alloc[i].size, PCI_DMA_FROMDEVICE);
+ page_alloc[i].page_size, PCI_DMA_FROMDEVICE);
page = page_alloc[i].page;
atomic_set(&page->_count, 1);
put_page(page);
@@ -132,9 +136,10 @@ static void mlx4_en_free_frag(struct mlx4_en_priv *priv,
{
const struct mlx4_en_frag_info *frag_info = &priv->frag_info[i];
- if (frags[i].offset + frag_info->frag_stride > frags[i].size)
- dma_unmap_page(priv->ddev, frags[i].dma, frags[i].size,
- PCI_DMA_FROMDEVICE);
+ if (frags[i].page_offset + frag_info->frag_stride >
+ frags[i].page_size)
+ dma_unmap_page(priv->ddev, frags[i].dma, frags[i].page_size,
+ PCI_DMA_FROMDEVICE);
if (frags[i].page)
put_page(frags[i].page);
@@ -161,7 +166,7 @@ out:
page_alloc = &ring->page_alloc[i];
dma_unmap_page(priv->ddev, page_alloc->dma,
- page_alloc->size, PCI_DMA_FROMDEVICE);
+ page_alloc->page_size, PCI_DMA_FROMDEVICE);
page = page_alloc->page;
atomic_set(&page->_count, 1);
put_page(page);
@@ -184,10 +189,11 @@ static void mlx4_en_destroy_allocator(struct mlx4_en_priv *priv,
i, page_count(page_alloc->page));
dma_unmap_page(priv->ddev, page_alloc->dma,
- page_alloc->size, PCI_DMA_FROMDEVICE);
- while (page_alloc->offset + frag_info->frag_stride < page_alloc->size) {
+ page_alloc->page_size, PCI_DMA_FROMDEVICE);
+ while (page_alloc->page_offset + frag_info->frag_stride <
+ page_alloc->page_size) {
put_page(page_alloc->page);
- page_alloc->offset += frag_info->frag_stride;
+ page_alloc->page_offset += frag_info->frag_stride;
}
page_alloc->page = NULL;
}
@@ -478,7 +484,7 @@ static int mlx4_en_complete_rx_desc(struct mlx4_en_priv *priv,
/* Save page reference in skb */
__skb_frag_set_page(&skb_frags_rx[nr], frags[nr].page);
skb_frag_size_set(&skb_frags_rx[nr], frag_info->frag_size);
- skb_frags_rx[nr].page_offset = frags[nr].offset;
+ skb_frags_rx[nr].page_offset = frags[nr].page_offset;
skb->truesize += frag_info->frag_stride;
frags[nr].page = NULL;
}
@@ -517,7 +523,7 @@ static struct sk_buff *mlx4_en_rx_skb(struct mlx4_en_priv *priv,
/* Get pointer to first fragment so we could copy the headers into the
* (linear part of the) skb */
- va = page_address(frags[0].page) + frags[0].offset;
+ va = page_address(frags[0].page) + frags[0].page_offset;
if (length <= SMALL_PACKET_SIZE) {
/* We are copying all relevant data to the skb - temporarily
@@ -645,7 +651,7 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
dma_sync_single_for_cpu(priv->ddev, dma, sizeof(*ethh),
DMA_FROM_DEVICE);
ethh = (struct ethhdr *)(page_address(frags[0].page) +
- frags[0].offset);
+ frags[0].page_offset);
if (is_multicast_ether_addr(ethh->h_dest)) {
struct mlx4_mac_entry *entry;
diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
index 5e0aa56..bf06e36 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
+++ b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
@@ -237,8 +237,8 @@ struct mlx4_en_tx_desc {
struct mlx4_en_rx_alloc {
struct page *page;
dma_addr_t dma;
- u32 offset;
- u32 size;
+ u32 page_offset;
+ u32 page_size;
};
struct mlx4_en_tx_ring {
--
1.8.3.4
^ permalink raw reply related
* [PATCH mmots] net: static declaration of net_secret_init() follows non-static
From: Sergey Senozhatsky @ 2013-10-07 11:16 UTC (permalink / raw)
To: Andrew Morton, David S. Miller; +Cc: netdev, linux-kernel
Fix secure_seq build error
net/core/secure_seq.c:17:13: error: static declaration of ‘net_secret_init’ follows
non-static declaration
static void net_secret_init(void)
In file included from net/core/secure_seq.c:11:0:
include/net/secure_seq.h:6:6: note: previous declaration of ‘net_secret_init’ was
here
void net_secret_init(void);
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
---
include/net/secure_seq.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/net/secure_seq.h b/include/net/secure_seq.h
index 52c1a90..f257486 100644
--- a/include/net/secure_seq.h
+++ b/include/net/secure_seq.h
@@ -3,7 +3,6 @@
#include <linux/types.h>
-void net_secret_init(void);
__u32 secure_ip_id(__be32 daddr);
__u32 secure_ipv6_id(const __be32 daddr[4]);
u32 secure_ipv4_port_ephemeral(__be32 saddr, __be32 daddr, __be16 dport);
^ permalink raw reply related
* Re: [Xen-devel] [PATCH net-next] xen-netback: fix xenvif_count_skb_slots()
From: Wei Liu @ 2013-10-07 10:53 UTC (permalink / raw)
To: Paul Durrant
Cc: David Vrabel, Wei Liu, Ian Campbell, netdev@vger.kernel.org,
xen-devel@lists.xen.org, Annie Li, Matt Wilson, Xi Xiong
In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD0129EE1@AMSPEX01CL01.citrite.net>
On Mon, Oct 07, 2013 at 11:37:31AM +0100, Paul Durrant wrote:
> > -----Original Message-----
> > From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> > bounces@lists.xen.org] On Behalf Of Paul Durrant
> > Sent: 07 October 2013 11:24
> > To: David Vrabel
> > Cc: Wei Liu; Ian Campbell; netdev@vger.kernel.org; xen-devel@lists.xen.org;
> > Annie Li; Matt Wilson; Xi Xiong
> > Subject: Re: [Xen-devel] [PATCH net-next] xen-netback: fix
> > xenvif_count_skb_slots()
> >
> > > -----Original Message-----
> > > From: David Vrabel
> > > Sent: 07 October 2013 10:50
> > > To: Paul Durrant
> > > Cc: xen-devel@lists.xen.org; netdev@vger.kernel.org; Wei Liu; Ian
> > Campbell;
> > > Annie Li; Matt Wilson; Xi Xiong
> > > Subject: Re: [Xen-devel] [PATCH net-next] xen-netback: fix
> > > xenvif_count_skb_slots()
> > >
> > > On 04/10/13 17:26, Paul Durrant wrote:
> > > > Commit 4f0581d25827d5e864bcf07b05d73d0d12a20a5c introduced an
> > error
> > > into
> > > > xenvif_count_skb_slots() for skbs with a linear area spanning a page
> > > > boundary. The alignment of skb->data needs to be taken into account,
> > not
> > > > just the head length. This patch fixes the issue by dry-running the code
> > > > from xenvif_gop_skb() (and adjusting the comment above the function
> > to
> > > note
> > > > that).
> > >
> > > If 4f0581d2582 is causing the skb->data to be fully packed into a
> > > minimal number of slots then the simple
> > > DIV_ROUND_UP(skb_headlen(skb))
> > > is correct.
> > >
> > > I think this change will miscount in the number of slots,
> > > over-estimating the count which I think will eventually cause netback to
> > > think the ring has no space when it has some.
> > >
> > > Is the problem here not the miscounting of slots but running out of
> > > space in the grant table op array because we know use more copy ops?
> > >
> >
> > Essentially yes. Netback is built on the assumption of no more than two grant
> > copies per ring slot.
> >
>
> To be clear; I believe that, with the packing change, a third grant copy may be used for the initial slot and that is why we blow the array.
>
OK, thanks for the explanation. I'm fine with reverting the problematic
changeset as that part of code is quite fragile now. Looking at the git
history we've tripped over this many times, sigh.
Wei.
^ permalink raw reply
* RE: [Xen-devel] [PATCH net-next] xen-netback: fix xenvif_count_skb_slots()
From: Paul Durrant @ 2013-10-07 10:37 UTC (permalink / raw)
To: Paul Durrant, David Vrabel
Cc: Wei Liu, Ian Campbell, netdev@vger.kernel.org,
xen-devel@lists.xen.org, Annie Li, Matt Wilson, Xi Xiong
In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD0129E7A@AMSPEX01CL01.citrite.net>
> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> bounces@lists.xen.org] On Behalf Of Paul Durrant
> Sent: 07 October 2013 11:24
> To: David Vrabel
> Cc: Wei Liu; Ian Campbell; netdev@vger.kernel.org; xen-devel@lists.xen.org;
> Annie Li; Matt Wilson; Xi Xiong
> Subject: Re: [Xen-devel] [PATCH net-next] xen-netback: fix
> xenvif_count_skb_slots()
>
> > -----Original Message-----
> > From: David Vrabel
> > Sent: 07 October 2013 10:50
> > To: Paul Durrant
> > Cc: xen-devel@lists.xen.org; netdev@vger.kernel.org; Wei Liu; Ian
> Campbell;
> > Annie Li; Matt Wilson; Xi Xiong
> > Subject: Re: [Xen-devel] [PATCH net-next] xen-netback: fix
> > xenvif_count_skb_slots()
> >
> > On 04/10/13 17:26, Paul Durrant wrote:
> > > Commit 4f0581d25827d5e864bcf07b05d73d0d12a20a5c introduced an
> error
> > into
> > > xenvif_count_skb_slots() for skbs with a linear area spanning a page
> > > boundary. The alignment of skb->data needs to be taken into account,
> not
> > > just the head length. This patch fixes the issue by dry-running the code
> > > from xenvif_gop_skb() (and adjusting the comment above the function
> to
> > note
> > > that).
> >
> > If 4f0581d2582 is causing the skb->data to be fully packed into a
> > minimal number of slots then the simple
> > DIV_ROUND_UP(skb_headlen(skb))
> > is correct.
> >
> > I think this change will miscount in the number of slots,
> > over-estimating the count which I think will eventually cause netback to
> > think the ring has no space when it has some.
> >
> > Is the problem here not the miscounting of slots but running out of
> > space in the grant table op array because we know use more copy ops?
> >
>
> Essentially yes. Netback is built on the assumption of no more than two grant
> copies per ring slot.
>
To be clear; I believe that, with the packing change, a third grant copy may be used for the initial slot and that is why we blow the array.
Paul
> > I didn't think there was any real merit in the problematic commit (or at
> > least there was no evidence that it was better) so I would suggest just
> > reverting it instead of trying to fix it up.
> >
>
> I'd be happy with a reversion.
>
> > If we do want to change how netback fills the ring then netback needs
> > some redesign (i.e., change it so it doesn't have to this counting in
> > advance) to make it much less fragile to changes in this area.
> >
>
> Yes, that would be much better.
>
> Paul
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
^ permalink raw reply
* APPLY FOR A LOAN NOW
From: Mr. Lewis Harry @ 2013-10-07 10:27 UTC (permalink / raw)
To: Recipients
Do you need a loan ? If Yes, Apply with Name:Country:State:Amount:Duration:Cell No: Contact Us at lewisharrylending@aol.com
^ permalink raw reply
* RE: [Xen-devel] [PATCH net-next] xen-netback: fix xenvif_count_skb_slots()
From: Paul Durrant @ 2013-10-07 10:23 UTC (permalink / raw)
To: David Vrabel
Cc: xen-devel@lists.xen.org, netdev@vger.kernel.org, Wei Liu,
Ian Campbell, Annie Li, Matt Wilson, Xi Xiong
In-Reply-To: <525283D4.7010504@citrix.com>
> -----Original Message-----
> From: David Vrabel
> Sent: 07 October 2013 10:50
> To: Paul Durrant
> Cc: xen-devel@lists.xen.org; netdev@vger.kernel.org; Wei Liu; Ian Campbell;
> Annie Li; Matt Wilson; Xi Xiong
> Subject: Re: [Xen-devel] [PATCH net-next] xen-netback: fix
> xenvif_count_skb_slots()
>
> On 04/10/13 17:26, Paul Durrant wrote:
> > Commit 4f0581d25827d5e864bcf07b05d73d0d12a20a5c introduced an error
> into
> > xenvif_count_skb_slots() for skbs with a linear area spanning a page
> > boundary. The alignment of skb->data needs to be taken into account, not
> > just the head length. This patch fixes the issue by dry-running the code
> > from xenvif_gop_skb() (and adjusting the comment above the function to
> note
> > that).
>
> If 4f0581d2582 is causing the skb->data to be fully packed into a
> minimal number of slots then the simple
> DIV_ROUND_UP(skb_headlen(skb))
> is correct.
>
> I think this change will miscount in the number of slots,
> over-estimating the count which I think will eventually cause netback to
> think the ring has no space when it has some.
>
> Is the problem here not the miscounting of slots but running out of
> space in the grant table op array because we know use more copy ops?
>
Essentially yes. Netback is built on the assumption of no more than two grant copies per ring slot.
> I didn't think there was any real merit in the problematic commit (or at
> least there was no evidence that it was better) so I would suggest just
> reverting it instead of trying to fix it up.
>
I'd be happy with a reversion.
> If we do want to change how netback fills the ring then netback needs
> some redesign (i.e., change it so it doesn't have to this counting in
> advance) to make it much less fragile to changes in this area.
>
Yes, that would be much better.
Paul
^ permalink raw reply
* RE: [PATCH net-next] xen-netback: fix xenvif_count_skb_slots()
From: Paul Durrant @ 2013-10-07 10:17 UTC (permalink / raw)
To: Matt Wilson
Cc: xen-devel@lists.xen.org, netdev@vger.kernel.org, Xi Xiong,
Matt Wilson, Annie Li, Wei Liu, Ian Campbell, Simon Graham
In-Reply-To: <20131007000741.GB5970@u109add4315675089e695.ant.amazon.com>
> -----Original Message-----
> From: Matt Wilson [mailto:mswilson@gmail.com] On Behalf Of Matt Wilson
> Sent: 07 October 2013 01:08
> To: Paul Durrant
> Cc: xen-devel@lists.xen.org; netdev@vger.kernel.org; Xi Xiong; Matt Wilson;
> Annie Li; Wei Liu; Ian Campbell; Simon Graham
> Subject: Re: [PATCH net-next] xen-netback: fix xenvif_count_skb_slots()
>
> On Sun, Oct 06, 2013 at 05:06:52PM -0700, Matt Wilson wrote:
> > On Fri, Oct 04, 2013 at 05:26:23PM +0100, Paul Durrant wrote:
> > > Commit 4f0581d25827d5e864bcf07b05d73d0d12a20a5c introduced an
> error into
> > > xenvif_count_skb_slots() for skbs with a linear area spanning a page
> > > boundary. The alignment of skb->data needs to be taken into account,
> not
> > > just the head length. This patch fixes the issue by dry-running the code
> > > from xenvif_gop_skb() (and adjusting the comment above the function
> to note
> > > that).
> > >
> > > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> > > Cc: Xi Xiong <xixiong@amazon.com>
> > > Cc: Matt Wilson <msw@amazon.com>
> > > Cc: Annie Li <annie.li@oracle.com>
> > > Cc: Wei Liu <wei.liu2@citrix.com>
> > > Cc: Ian Campbell <Ian.Campbell@citrix.com>
> >
> > Paul, can you reconcile this change with the one made by Simon in cs
> > 8f985b4f7a5394c8f8725a5109451a541ddb9eea?
>
> Correction: e26b203ede31fffd52571a5ba607a26c79dc5c0d
>
The comment is possibly correct with modified ring packing but the problem is that by reducing that count netback now tries to handle more skbs than it has grant copy slots for. Maybe it would be more appropriate to simply revert 4f0581d25827d5e864bcf07b05d73d0d12a20a5c. I see no problem before that patch was applied.
Paul
^ permalink raw reply
* RE: [PATCH net-next] xen-netback: fix xenvif_count_skb_slots()
From: Paul Durrant @ 2013-10-07 10:12 UTC (permalink / raw)
To: Wei Liu
Cc: xen-devel@lists.xen.org, netdev@vger.kernel.org, Xi Xiong,
Matt Wilson, Annie Li, Wei Liu, Ian Campbell
In-Reply-To: <20131007100132.GA28411@zion.uk.xensource.com>
> -----Original Message-----
> From: Wei Liu [mailto:wei.liu2@citrix.com]
> Sent: 07 October 2013 11:02
> To: Paul Durrant
> Cc: xen-devel@lists.xen.org; netdev@vger.kernel.org; Xi Xiong; Matt Wilson;
> Annie Li; Wei Liu; Ian Campbell
> Subject: Re: [PATCH net-next] xen-netback: fix xenvif_count_skb_slots()
>
> On Fri, Oct 04, 2013 at 05:26:23PM +0100, Paul Durrant wrote:
> > Commit 4f0581d25827d5e864bcf07b05d73d0d12a20a5c introduced an error
> into
> > xenvif_count_skb_slots() for skbs with a linear area spanning a page
> > boundary. The alignment of skb->data needs to be taken into account, not
> > just the head length. This patch fixes the issue by dry-running the code
> > from xenvif_gop_skb() (and adjusting the comment above the function to
> note
> > that).
> >
>
> If I'm not mistaken the change in commit 4f0581d2 is correct because we
> changed the way that the ring is packed. Now you seem to fall back to
> the original scheme (or something in between without reverting later
> other changes in that commit).
>
It's not possible to use a single grant copy to copy to even a 2-byte linear area that spans a page boundary so you have to take into account the alignment of skb->data. How the ring is packed is not relevant.
> Do you have instruction to reproduce the bug? Can you paste some
> detailed oops message?
>
I don't have the message to hand, but it's this BUG_ON that I hit:
BUG_ON(npo.copy_prod > ARRAY_SIZE(vif->grant_copy_op));
I.e. we blow the grant copy op array.
Paul
^ permalink raw reply
* From Mr. Charles Kabore.
From: Mr. Charles Kabore @ 2013-10-07 10:01 UTC (permalink / raw)
>From Mr. Charles Kabore.
Ouagadougou,
Burkina Faso.
Dear Friend,
Good day to you. I am Mr. Charles Kabore. a lawyer and personal confidant to Abdullah Senussi who was the intelligence chief of Colonel Muammar Gaddafi. I need your urgent assistance in transferring the sum of ($39.5) million to your account within 14 banking days from a bank in Burkina Faso. This money belongs to my master Abdullah Senussi and was deposited in the bank on the name of his son. The urgent need for the transfer of this fund is to avoid confiscation by the Libyan government as they quest the seizure of every related assets belonging to Late Colonel Muammar Gaddafi and his aides. I am contacting you in a good faith so that the bank will release the money to you for safe keeping/investments till the release of my master who is now in custody.
So if you are capable of receiving this huge amount of money,let me have a positive response from you via return mail for more personal discussions on how we are going to go about it.Contact me in this my private email address for security purpose {ckabore94@yahoo.com.hk}.
Best.Regards,
Mr. Charles Kabore.
^ permalink raw reply
* Re: [PATCH net-next] xen-netback: fix xenvif_count_skb_slots()
From: Wei Liu @ 2013-10-07 10:01 UTC (permalink / raw)
To: Paul Durrant
Cc: xen-devel, netdev, Xi Xiong, Matt Wilson, Annie Li, Wei Liu,
Ian Campbell
In-Reply-To: <1380903983-27429-1-git-send-email-paul.durrant@citrix.com>
On Fri, Oct 04, 2013 at 05:26:23PM +0100, Paul Durrant wrote:
> Commit 4f0581d25827d5e864bcf07b05d73d0d12a20a5c introduced an error into
> xenvif_count_skb_slots() for skbs with a linear area spanning a page
> boundary. The alignment of skb->data needs to be taken into account, not
> just the head length. This patch fixes the issue by dry-running the code
> from xenvif_gop_skb() (and adjusting the comment above the function to note
> that).
>
If I'm not mistaken the change in commit 4f0581d2 is correct because we
changed the way that the ring is packed. Now you seem to fall back to
the original scheme (or something in between without reverting later
other changes in that commit).
Do you have instruction to reproduce the bug? Can you paste some
detailed oops message?
Wei.
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> Cc: Xi Xiong <xixiong@amazon.com>
> Cc: Matt Wilson <msw@amazon.com>
> Cc: Annie Li <annie.li@oracle.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Cc: Ian Campbell <Ian.Campbell@citrix.com>
>
> ---
> drivers/net/xen-netback/netback.c | 17 +++++++++++++++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index d0b0feb..6f680f4 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -223,15 +223,28 @@ static bool start_new_rx_buffer(int offset, unsigned long size, int head)
> /*
> * Figure out how many ring slots we're going to need to send @skb to
> * the guest. This function is essentially a dry run of
> - * xenvif_gop_frag_copy.
> + * xenvif_gop_skb.
> */
> unsigned int xenvif_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
> {
> + unsigned char *data;
> unsigned int count;
> int i, copy_off;
> struct skb_cb_overlay *sco;
>
> - count = DIV_ROUND_UP(skb_headlen(skb), PAGE_SIZE);
> + count = 0;
> +
> + data = skb->data;
> + while (data < skb_tail_pointer(skb)) {
> + unsigned int offset = offset_in_page(data);
> + unsigned int len = PAGE_SIZE - offset;
> +
> + if (data + len > skb_tail_pointer(skb))
> + len = skb_tail_pointer(skb) - data;
> +
> + count++;
> + data += len;
> + }
>
> copy_off = skb_headlen(skb) % PAGE_SIZE;
>
> --
> 1.7.10.4
^ permalink raw reply
* Re: [Xen-devel] [PATCH net-next] xen-netback: fix xenvif_count_skb_slots()
From: David Vrabel @ 2013-10-07 9:50 UTC (permalink / raw)
To: Paul Durrant
Cc: xen-devel, netdev, Wei Liu, Ian Campbell, Annie Li, Matt Wilson,
Xi Xiong
In-Reply-To: <1380903983-27429-1-git-send-email-paul.durrant@citrix.com>
On 04/10/13 17:26, Paul Durrant wrote:
> Commit 4f0581d25827d5e864bcf07b05d73d0d12a20a5c introduced an error into
> xenvif_count_skb_slots() for skbs with a linear area spanning a page
> boundary. The alignment of skb->data needs to be taken into account, not
> just the head length. This patch fixes the issue by dry-running the code
> from xenvif_gop_skb() (and adjusting the comment above the function to note
> that).
If 4f0581d2582 is causing the skb->data to be fully packed into a
minimal number of slots then the simple DIV_ROUND_UP(skb_headlen(skb))
is correct.
I think this change will miscount in the number of slots,
over-estimating the count which I think will eventually cause netback to
think the ring has no space when it has some.
Is the problem here not the miscounting of slots but running out of
space in the grant table op array because we know use more copy ops?
I didn't think there was any real merit in the problematic commit (or at
least there was no evidence that it was better) so I would suggest just
reverting it instead of trying to fix it up.
If we do want to change how netback fills the ring then netback needs
some redesign (i.e., change it so it doesn't have to this counting in
advance) to make it much less fragile to changes in this area.
David
^ permalink raw reply
* Re: [PATCH nf-next] netfilter: xtables: lightweight process control group matching
From: Gao feng @ 2013-10-07 9:42 UTC (permalink / raw)
To: Daniel Borkmann
Cc: pablo-Cap9r6Oaw4JrovVCs/uTlw,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Tejun Heo,
cgroups-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <52527C3E.1060004-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On 10/07/2013 05:17 PM, Daniel Borkmann wrote:
> On 10/07/2013 05:07 AM, Gao feng wrote:
>> On 10/05/2013 02:20 AM, Daniel Borkmann wrote:
>>> +static void cgroup_attach(struct cgroup_subsys_state *css,
>>> + struct cgroup_taskset *tset)
>>> +{
>>> + struct task_struct *p;
>>> + void *v;
>>> +
>>> + cgroup_taskset_for_each(p, css, tset) {
>>> + task_lock(p);
>>> + v = (void *)(unsigned long) task_fwid(p);
>>
>> Shouldn't v be css_nf_state(css)->fwid?
>
> Nope, this is in line with net_cls and net_prio; the task has been
> moved there via cgroup backend already through cgroup_attach_task(),
Yes, these tasks have already been migrated to this cgroup.
> so we only need to update each of it's socket sk_cgrp_fwid parts.
Sorry, I still don't know in which situation that css_nf_state(css)->fwid
isn't equal to task_fwid(p).
two threads write the same pid to different cgroup at the same time?
it seems can not happen since we have cgroup_mutex protected.
> css is not strictly for net_filter. See also: 6a328d8c6f (cgroup:
> net_cls: Rework update socket logic)
>
>>> + iterate_fd(p->files, 0, cgroup_fwid_update, v);
>>> + task_unlock(p);
>>> + }
>>> +}
>
^ permalink raw reply
* Congratulations !!!
From: office3 @ 2013-10-07 9:28 UTC (permalink / raw)
To: Recipients
Ticket Number: 7PWYZ2008
Ballot Number: BT:12052008/20
Draw:#1471
Special Notification to you,You are receiving this email because you have just been picked for a total grand prize of One Million Dollars in the top 10 winners of the Coca-Cola Consumer`s Award for the year 2013: kindly send your:
Name:
Address:
Country:
Phone Number:
To Mr. Bruce Morgan
via Email: colaclaims13@msn.com
Telephone Number:+44701006909
^ permalink raw reply
* Re: [PATCH nf-next] netfilter: xtables: lightweight process control group matching
From: Daniel Borkmann @ 2013-10-07 9:17 UTC (permalink / raw)
To: Gao feng; +Cc: pablo, netfilter-devel, netdev, Tejun Heo, cgroups
In-Reply-To: <52522555.70407@cn.fujitsu.com>
On 10/07/2013 05:07 AM, Gao feng wrote:
> On 10/05/2013 02:20 AM, Daniel Borkmann wrote:
>> +static void cgroup_attach(struct cgroup_subsys_state *css,
>> + struct cgroup_taskset *tset)
>> +{
>> + struct task_struct *p;
>> + void *v;
>> +
>> + cgroup_taskset_for_each(p, css, tset) {
>> + task_lock(p);
>> + v = (void *)(unsigned long) task_fwid(p);
>
> Shouldn't v be css_nf_state(css)->fwid?
Nope, this is in line with net_cls and net_prio; the task has been
moved there via cgroup backend already through cgroup_attach_task(),
so we only need to update each of it's socket sk_cgrp_fwid parts.
css is not strictly for net_filter. See also: 6a328d8c6f (cgroup:
net_cls: Rework update socket logic)
>> + iterate_fd(p->files, 0, cgroup_fwid_update, v);
>> + task_unlock(p);
>> + }
>> +}
^ permalink raw reply
* Re: IPv6 path MTU discovery broken
From: Steinar H. Gunderson @ 2013-10-07 8:37 UTC (permalink / raw)
To: netdev, edumazet, fan.du
In-Reply-To: <20131007015252.GE9295@order.stressinduktion.org>
On Mon, Oct 07, 2013 at 03:52:52AM +0200, Hannes Frederic Sowa wrote:
>> pannekake:~> cat /proc/net/ipv6_route
>> 2001067c00a400037c4d9ae8ab73230f 80 00000000000000000000000000000000 00 fe80000000000000023048fffe555743 00000000 00000001 00000137 01000023 eth0
> This one does look like the most probable route which could have the problem.
> It has a RTF_MODIFIED flag indicating it received a pmtu update.
I got the idea to correlate auth.log with the email I sent:
Oct 6 14:01:12 pannekake sshd[13211]: Accepted keyboard-interactive/pam for
sesse from 2001:67c:a4:3:7c4d:9ae8:ab73:230f port 60116 ssh2
So that's definitely the right address.
/* Steinar */
--
Homepage: http://www.sesse.net/
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox