* [PATCH] skge: fix broken driver
From: Mikulas Patocka @ 2013-09-19 16:33 UTC (permalink / raw)
To: David S. Miller, Stephen Hemminger, netdev
The patch 136d8f377e1575463b47840bc5f1b22d94bf8f63 broke the skge driver.
Note this part of the patch:
+ if (skge_rx_setup(skge, e, nskb, skge->rx_buf_size) < 0) {
+ dev_kfree_skb(nskb);
+ goto resubmit;
+ }
+
pci_unmap_single(skge->hw->pdev,
dma_unmap_addr(e, mapaddr),
dma_unmap_len(e, maplen),
PCI_DMA_FROMDEVICE);
skb = e->skb;
prefetch(skb->data);
- skge_rx_setup(skge, e, nskb, skge->rx_buf_size);
The function skge_rx_setup modifies e->skb to point to the new skb. Thus,
after this change, the new buffer, not the old, is returned to the
networking stack.
This bug is present in kernels 3.11, 3.11.1 and 3.12-rc1.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@kernel.org # 3.11
---
drivers/net/ethernet/marvell/skge.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Index: linux-3.11.1-fast/drivers/net/ethernet/marvell/skge.c
===================================================================
--- linux-3.11.1-fast.orig/drivers/net/ethernet/marvell/skge.c 2013-09-10 19:46:58.000000000 +0200
+++ linux-3.11.1-fast/drivers/net/ethernet/marvell/skge.c 2013-09-19 18:20:43.000000000 +0200
@@ -3092,6 +3092,9 @@ static struct sk_buff *skge_rx_get(struc
if (!nskb)
goto resubmit;
+ skb = e->skb;
+ prefetch(skb->data);
+
if (skge_rx_setup(skge, e, nskb, skge->rx_buf_size) < 0) {
dev_kfree_skb(nskb);
goto resubmit;
@@ -3101,8 +3104,6 @@ static struct sk_buff *skge_rx_get(struc
dma_unmap_addr(e, mapaddr),
dma_unmap_len(e, maplen),
PCI_DMA_FROMDEVICE);
- skb = e->skb;
- prefetch(skb->data);
}
skb_put(skb, len);
^ permalink raw reply
* Re: [PATCH] powerpc/83xx: gianfar_ptp: select 1588 clock source through dts file
From: Claudiu Manoil @ 2013-09-19 16:30 UTC (permalink / raw)
To: Aida Mynzhasova; +Cc: richardcochran, netdev
In-Reply-To: <5239D74F.5030801@skitlab.ru>
On 9/18/2013 7:39 PM, Aida Mynzhasova wrote:
> On 18.09.2013 19:44, Claudiu Manoil wrote:
>>
>> On 9/18/2013 4:21 PM, Aida Mynzhasova wrote:
>>> IEEE 1588 timer reference clock source is determined through hard-coded
>>> value in gianfar_ptp driver by default. This patch allows to select ptp
>>> clock source by means of device tree file node.
>>>
>>> For instance:
>>>
>>> fsl,cksel = <0>;
>>>
>>
>> Has this device tree binding been defined? (Where?)
>> I don't see this property in the net-next.git tree at least.
>>
>> Claudiu
>>
>>
>
> Hi Claudiu,
>
> actually, I don't know where I should define this binding, my only idea
> is to add "cksel" property description in
> /Documentation/devicetree/bindings/net/fsl-tsec-phy.txt. Am I right or I
> need to do some additional changes?
>
> Thanks.
>
>
If you ask me, updates for the device trees of several powerpc boards,
like the 83xx series (as this patch implies), should be discussed and
agreed upon on the powerpc list (linuxppc-dev@lists.ozlabs.org),
where these kind of changes are usually being discussed with people more
knowledgeable in device tree bindings and the powerpc/83xx hardware.
Regards,
Claudiu
^ permalink raw reply
* [stable] [PATCH] sfc: Fix efx_rx_buf_offset() for recycled pages
From: Ben Hutchings @ 2013-09-19 16:13 UTC (permalink / raw)
To: David Miller; +Cc: stable, netdev
[-- Attachment #1: Type: text/plain, Size: 1323 bytes --]
[Re-sending with cc to the current stable address. I still had the old
address in contacts, though I've definitely sent to the current address
previously...]
This bug fix is only for stable branches older than 3.10. The bug was
fixed upstream by commit 2768935a4660 ('sfc: reuse pages to avoid DMA
mapping/unmapping costs'), but that change is totally unsuitable for
stable.
Commit b590ace09d51 ('sfc: Fix efx_rx_buf_offset() in the presence of
swiotlb') added an explicit page_offset member to struct
efx_rx_buffer, which must be set consistently with the u.page and
dma_addr fields. However, it failed to add the necessary assignment
in efx_resurrect_rx_buffer(). It also did not correct the calculation
of efx_rx_buffer::dma_addr in efx_resurrect_rx_buffer(), which assumes
that DMA-mapping a page will result in a page-aligned DMA address
(exactly what swiotlb violates).
Add the assignment of efx_rx_buffer::page_offset and change the
calculation of dma_addr to make use of it.
I'm attaching the patches for 3.0.y, 3.2.y and 3.4.y (the last of which
should also be applicable to the later unofficial stable branches).
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
[-- Attachment #2: sfc-Fix-efx_rx_buf_offset-for-recycled-pages-3.0.patch --]
[-- Type: text/x-patch, Size: 1833 bytes --]
>From d4e70d42eff6938c12d7d0b12f657b10d06a156d Mon Sep 17 00:00:00 2001
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Fri, 6 Sep 2013 22:39:20 +0100
Subject: sfc: Fix efx_rx_buf_offset() for recycled pages
This bug fix is only for stable branches older than 3.10. The bug was
fixed upstream by commit 2768935a4660 ('sfc: reuse pages to avoid DMA
mapping/unmapping costs'), but that change is totally unsuitable for
stable.
Commit b590ace09d51 ('sfc: Fix efx_rx_buf_offset() in the presence of
swiotlb') added an explicit page_offset member to struct
efx_rx_buffer, which must be set consistently with the u.page and
dma_addr fields. However, it failed to add the necessary assignment
in efx_resurrect_rx_buffer(). It also did not correct the calculation
of efx_rx_buffer::dma_addr in efx_resurrect_rx_buffer(), which assumes
that DMA-mapping a page will result in a page-aligned DMA address
(exactly what swiotlb violates).
Add the assignment of efx_rx_buffer::page_offset and change the
calculation of dma_addr to make use of it.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/sfc/rx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/sfc/rx.c b/drivers/net/sfc/rx.c
index d429f0a..26e4cca 100644
--- a/drivers/net/sfc/rx.c
+++ b/drivers/net/sfc/rx.c
@@ -311,8 +311,9 @@ static void efx_resurrect_rx_buffer(struct efx_rx_queue *rx_queue,
index = rx_queue->added_count & rx_queue->ptr_mask;
new_buf = efx_rx_buffer(rx_queue, index);
- new_buf->dma_addr = rx_buf->dma_addr ^ (PAGE_SIZE >> 1);
new_buf->u.page = rx_buf->u.page;
+ new_buf->page_offset = rx_buf->page_offset ^ (PAGE_SIZE >> 1);
+ new_buf->dma_addr = state->dma_addr + new_buf->page_offset;
new_buf->len = rx_buf->len;
new_buf->is_page = true;
++rx_queue->added_count;
--
1.8.1.4
[-- Attachment #3: sfc-Fix-efx_rx_buf_offset-for-recycled-pages-3.2.patch --]
[-- Type: text/x-patch, Size: 1878 bytes --]
>From 43587737635de32882d9f69df36562e0d5b0e0bd Mon Sep 17 00:00:00 2001
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Fri, 6 Sep 2013 22:39:20 +0100
Subject: sfc: Fix efx_rx_buf_offset() for recycled pages
This bug fix is only for stable branches older than 3.10. The bug was
fixed upstream by commit 2768935a4660 ('sfc: reuse pages to avoid DMA
mapping/unmapping costs'), but that change is totally unsuitable for
stable.
Commit b590ace09d51 ('sfc: Fix efx_rx_buf_offset() in the presence of
swiotlb') added an explicit page_offset member to struct
efx_rx_buffer, which must be set consistently with the u.page and
dma_addr fields. However, it failed to add the necessary assignment
in efx_resurrect_rx_buffer(). It also did not correct the calculation
of efx_rx_buffer::dma_addr in efx_resurrect_rx_buffer(), which assumes
that DMA-mapping a page will result in a page-aligned DMA address
(exactly what swiotlb violates).
Add the assignment of efx_rx_buffer::page_offset and change the
calculation of dma_addr to make use of it.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/ethernet/sfc/rx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/sfc/rx.c b/drivers/net/ethernet/sfc/rx.c
index 9ce8665..c231b3f 100644
--- a/drivers/net/ethernet/sfc/rx.c
+++ b/drivers/net/ethernet/sfc/rx.c
@@ -312,8 +312,9 @@ static void efx_resurrect_rx_buffer(struct efx_rx_queue *rx_queue,
index = rx_queue->added_count & rx_queue->ptr_mask;
new_buf = efx_rx_buffer(rx_queue, index);
- new_buf->dma_addr = rx_buf->dma_addr ^ (PAGE_SIZE >> 1);
new_buf->u.page = rx_buf->u.page;
+ new_buf->page_offset = rx_buf->page_offset ^ (PAGE_SIZE >> 1);
+ new_buf->dma_addr = state->dma_addr + new_buf->page_offset;
new_buf->len = rx_buf->len;
new_buf->is_page = true;
++rx_queue->added_count;
--
1.8.1.4
[-- Attachment #4: sfc-Fix-efx_rx_buf_offset-for-recycled-pages-3.4.patch --]
[-- Type: text/x-patch, Size: 1888 bytes --]
>From 55961f9a914e637f143da275da42154a49c9743a Mon Sep 17 00:00:00 2001
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Fri, 6 Sep 2013 22:39:20 +0100
Subject: sfc: Fix efx_rx_buf_offset() for recycled pages
This bug fix is only for stable branches older than 3.10. The bug was
fixed upstream by commit 2768935a4660 ('sfc: reuse pages to avoid DMA
mapping/unmapping costs'), but that change is totally unsuitable for
stable.
Commit b590ace09d51 ('sfc: Fix efx_rx_buf_offset() in the presence of
swiotlb') added an explicit page_offset member to struct
efx_rx_buffer, which must be set consistently with the u.page and
dma_addr fields. However, it failed to add the necessary assignment
in efx_resurrect_rx_buffer(). It also did not correct the calculation
of efx_rx_buffer::dma_addr in efx_resurrect_rx_buffer(), which assumes
that DMA-mapping a page will result in a page-aligned DMA address
(exactly what swiotlb violates).
Add the assignment of efx_rx_buffer::page_offset and change the
calculation of dma_addr to make use of it.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/ethernet/sfc/rx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/sfc/rx.c b/drivers/net/ethernet/sfc/rx.c
index 7b3c068..62311ad3 100644
--- a/drivers/net/ethernet/sfc/rx.c
+++ b/drivers/net/ethernet/sfc/rx.c
@@ -311,8 +311,9 @@ static void efx_resurrect_rx_buffer(struct efx_rx_queue *rx_queue,
index = rx_queue->added_count & rx_queue->ptr_mask;
new_buf = efx_rx_buffer(rx_queue, index);
- new_buf->dma_addr = rx_buf->dma_addr ^ (PAGE_SIZE >> 1);
new_buf->u.page = rx_buf->u.page;
+ new_buf->page_offset = rx_buf->page_offset ^ (PAGE_SIZE >> 1);
+ new_buf->dma_addr = state->dma_addr + new_buf->page_offset;
new_buf->len = rx_buf->len;
new_buf->flags = EFX_RX_BUF_PAGE;
++rx_queue->added_count;
--
1.8.1.4
^ permalink raw reply related
* [PATCH net-next 2/2] net_sched: htb: support of 64bit rates
From: Eric Dumazet @ 2013-09-19 16:10 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
HTB already can deal with 64bit rates, we only have to add two new
attributes so that tc can use them to break the current 32bit ABI
barrier.
TCA_HTB_RATE64 : class rate (in bytes per second)
TCA_HTB_CEIL64 : class ceil (in bytes per second)
This allows us to setup HTB on 40Gbps links, as 32bit limit is
actually ~34Gbps
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
include/uapi/linux/pkt_sched.h | 2 ++
net/sched/sch_htb.c | 17 +++++++++++++++--
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/pkt_sched.h b/include/uapi/linux/pkt_sched.h
index 9b82913..f2624b5 100644
--- a/include/uapi/linux/pkt_sched.h
+++ b/include/uapi/linux/pkt_sched.h
@@ -357,6 +357,8 @@ enum {
TCA_HTB_CTAB,
TCA_HTB_RTAB,
TCA_HTB_DIRECT_QLEN,
+ TCA_HTB_RATE64,
+ TCA_HTB_CEIL64,
__TCA_HTB_MAX,
};
diff --git a/net/sched/sch_htb.c b/net/sched/sch_htb.c
index 6b126f6..0e1e38b 100644
--- a/net/sched/sch_htb.c
+++ b/net/sched/sch_htb.c
@@ -997,6 +997,8 @@ static const struct nla_policy htb_policy[TCA_HTB_MAX + 1] = {
[TCA_HTB_CTAB] = { .type = NLA_BINARY, .len = TC_RTAB_SIZE },
[TCA_HTB_RTAB] = { .type = NLA_BINARY, .len = TC_RTAB_SIZE },
[TCA_HTB_DIRECT_QLEN] = { .type = NLA_U32 },
+ [TCA_HTB_RATE64] = { .type = NLA_U64 },
+ [TCA_HTB_CEIL64] = { .type = NLA_U64 },
};
static void htb_work_func(struct work_struct *work)
@@ -1114,6 +1116,12 @@ static int htb_dump_class(struct Qdisc *sch, unsigned long arg,
opt.level = cl->level;
if (nla_put(skb, TCA_HTB_PARMS, sizeof(opt), &opt))
goto nla_put_failure;
+ if ((cl->rate.rate_bytes_ps >= (1ULL << 32)) &&
+ nla_put_u64(skb, TCA_HTB_RATE64, cl->rate.rate_bytes_ps))
+ goto nla_put_failure;
+ if ((cl->ceil.rate_bytes_ps >= (1ULL << 32)) &&
+ nla_put_u64(skb, TCA_HTB_CEIL64, cl->ceil.rate_bytes_ps))
+ goto nla_put_failure;
nla_nest_end(skb, nest);
spin_unlock_bh(root_lock);
@@ -1332,6 +1340,7 @@ static int htb_change_class(struct Qdisc *sch, u32 classid,
struct qdisc_rate_table *rtab = NULL, *ctab = NULL;
struct nlattr *tb[TCA_HTB_MAX + 1];
struct tc_htb_opt *hopt;
+ u64 rate64, ceil64;
/* extract all subattrs from opt attr */
if (!opt)
@@ -1491,8 +1500,12 @@ static int htb_change_class(struct Qdisc *sch, u32 classid,
cl->prio = TC_HTB_NUMPRIO - 1;
}
- psched_ratecfg_precompute(&cl->rate, &hopt->rate, 0);
- psched_ratecfg_precompute(&cl->ceil, &hopt->ceil, 0);
+ rate64 = tb[TCA_HTB_RATE64] ? nla_get_u64(tb[TCA_HTB_RATE64]) : 0;
+
+ ceil64 = tb[TCA_HTB_CEIL64] ? nla_get_u64(tb[TCA_HTB_CEIL64]) : 0;
+
+ psched_ratecfg_precompute(&cl->rate, &hopt->rate, rate64);
+ psched_ratecfg_precompute(&cl->ceil, &hopt->ceil, ceil64);
cl->buffer = PSCHED_TICKS2NS(hopt->buffer);
cl->cbuffer = PSCHED_TICKS2NS(hopt->cbuffer);
^ permalink raw reply related
* [PATCH net-next 1/2] net_sched: add u64 rate to psched_ratecfg_precompute()
From: Eric Dumazet @ 2013-09-19 16:10 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
Add an extra u64 rate parameter to psched_ratecfg_precompute()
so that some qdisc can opt-in for 64bit rates in the future,
to overcome the ~34 Gbits limit.
psched_ratecfg_getrate() reports a legacy structure to
tc utility, so if actual rate is above the 32bit rate field,
cap it to the 34Gbit limit.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
include/net/sch_generic.h | 11 +++++++++--
net/sched/act_police.c | 4 ++--
net/sched/sch_generic.c | 5 +++--
net/sched/sch_htb.c | 4 ++--
net/sched/sch_tbf.c | 4 ++--
5 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index f4eb365..d0a6321 100644
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -702,13 +702,20 @@ static inline u64 psched_l2t_ns(const struct psched_ratecfg *r,
}
void psched_ratecfg_precompute(struct psched_ratecfg *r,
- const struct tc_ratespec *conf);
+ const struct tc_ratespec *conf,
+ u64 rate64);
static inline void psched_ratecfg_getrate(struct tc_ratespec *res,
const struct psched_ratecfg *r)
{
memset(res, 0, sizeof(*res));
- res->rate = r->rate_bytes_ps;
+
+ /* legacy struct tc_ratespec has a 32bit @rate field
+ * Qdisc using 64bit rate should add new attributes
+ * in order to maintain compatibility.
+ */
+ res->rate = min_t(u64, r->rate_bytes_ps, ~0U);
+
res->overhead = r->overhead;
res->linklayer = (r->linklayer & TC_LINKLAYER_MASK);
}
diff --git a/net/sched/act_police.c b/net/sched/act_police.c
index 189e3c5..272d8e9 100644
--- a/net/sched/act_police.c
+++ b/net/sched/act_police.c
@@ -231,14 +231,14 @@ override:
}
if (R_tab) {
police->rate_present = true;
- psched_ratecfg_precompute(&police->rate, &R_tab->rate);
+ psched_ratecfg_precompute(&police->rate, &R_tab->rate, 0);
qdisc_put_rtab(R_tab);
} else {
police->rate_present = false;
}
if (P_tab) {
police->peak_present = true;
- psched_ratecfg_precompute(&police->peak, &P_tab->rate);
+ psched_ratecfg_precompute(&police->peak, &P_tab->rate, 0);
qdisc_put_rtab(P_tab);
} else {
police->peak_present = false;
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index a74e278..e7121d2 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -910,11 +910,12 @@ void dev_shutdown(struct net_device *dev)
}
void psched_ratecfg_precompute(struct psched_ratecfg *r,
- const struct tc_ratespec *conf)
+ const struct tc_ratespec *conf,
+ u64 rate64)
{
memset(r, 0, sizeof(*r));
r->overhead = conf->overhead;
- r->rate_bytes_ps = conf->rate;
+ r->rate_bytes_ps = max_t(u64, conf->rate, rate64);
r->linklayer = (conf->linklayer & TC_LINKLAYER_MASK);
r->mult = 1;
/*
diff --git a/net/sched/sch_htb.c b/net/sched/sch_htb.c
index 863846c..6b126f6 100644
--- a/net/sched/sch_htb.c
+++ b/net/sched/sch_htb.c
@@ -1491,8 +1491,8 @@ static int htb_change_class(struct Qdisc *sch, u32 classid,
cl->prio = TC_HTB_NUMPRIO - 1;
}
- psched_ratecfg_precompute(&cl->rate, &hopt->rate);
- psched_ratecfg_precompute(&cl->ceil, &hopt->ceil);
+ psched_ratecfg_precompute(&cl->rate, &hopt->rate, 0);
+ psched_ratecfg_precompute(&cl->ceil, &hopt->ceil, 0);
cl->buffer = PSCHED_TICKS2NS(hopt->buffer);
cl->cbuffer = PSCHED_TICKS2NS(hopt->cbuffer);
diff --git a/net/sched/sch_tbf.c b/net/sched/sch_tbf.c
index 1aaf1b6..b057122 100644
--- a/net/sched/sch_tbf.c
+++ b/net/sched/sch_tbf.c
@@ -341,9 +341,9 @@ static int tbf_change(struct Qdisc *sch, struct nlattr *opt)
q->tokens = q->buffer;
q->ptokens = q->mtu;
- psched_ratecfg_precompute(&q->rate, &rtab->rate);
+ psched_ratecfg_precompute(&q->rate, &rtab->rate, 0);
if (ptab) {
- psched_ratecfg_precompute(&q->peak, &ptab->rate);
+ psched_ratecfg_precompute(&q->peak, &ptab->rate, 0);
q->peak_present = true;
} else {
q->peak_present = false;
^ permalink raw reply related
* [PATCH 5/5] net: ethernet: eth.c: removed checkpatch warnings and errors
From: avi.kp.137 @ 2013-09-19 16:06 UTC (permalink / raw)
To: davem; +Cc: akong, stefanha, jiri, netdev, linux-kernel, Avinash Kumar
From: Avinash Kumar <avi.kp.137@gmail.com>
removed these checkpatch.pl warnings:
net/ethernet/eth.c:61: WARNING: Use #include <linux/uaccess.h> instead of <asm/uaccess.h>
net/ethernet/eth.c:136: WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then pr_debug(... to printk(KERN_DEBUG ...
net/ethernet/eth.c:181: ERROR: space prohibited before that close parenthesis ')'
Signed-off-by: Avinash Kumar <avi.kp.137@gmail.com>
---
net/ethernet/eth.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/ethernet/eth.c b/net/ethernet/eth.c
index be1f64d..9bd3c31 100644
--- a/net/ethernet/eth.c
+++ b/net/ethernet/eth.c
@@ -58,7 +58,7 @@
#include <net/ipv6.h>
#include <net/ip.h>
#include <net/dsa.h>
-#include <asm/uaccess.h>
+#include <linux/uaccess.h>
__setup("ether=", netdev_boot_setup);
@@ -133,7 +133,7 @@ int eth_rebuild_header(struct sk_buff *skb)
return arp_find(eth->h_dest, skb);
#endif
default:
- printk(KERN_DEBUG
+ netdev_dbg(dev,
"%s: unable to resolve type %X addresses.\n",
dev->name, ntohs(eth->h_proto));
@@ -178,7 +178,7 @@ __be16 eth_type_trans(struct sk_buff *skb, struct net_device *dev)
* seems to set IFF_PROMISC.
*/
- else if (1 /*dev->flags&IFF_PROMISC */ ) {
+ else if (1 /*dev->flags&IFF_PROMISC */) {
if (unlikely(!ether_addr_equal_64bits(eth->h_dest,
dev->dev_addr)))
skb->pkt_type = PACKET_OTHERHOST;
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH v2.39 7/7] datapath: Add basic MPLS support to kernel
From: Simon Horman @ 2013-09-19 15:57 UTC (permalink / raw)
To: Jesse Gross
Cc: Ben Pfaff, Pravin Shelar, dev@openvswitch.org, netdev, Ravi K,
Isaku Yamahata, Joe Stringer
In-Reply-To: <CAEP_g=8FBQPZ=C6G39YdHRzG57m5MqfXSZFAX2S_KLHRwfzc2w@mail.gmail.com>
On Mon, Sep 16, 2013 at 03:38:21PM -0500, Jesse Gross wrote:
> On Mon, Sep 9, 2013 at 12:20 AM, Simon Horman <horms@verge.net.au> wrote:
> > diff --git a/datapath/actions.c b/datapath/actions.c
> > index 6741d81..2335014 100644
> > --- a/datapath/actions.c
> > +++ b/datapath/actions.c
> > +/* Push MPLS after the ethernet header. */
> > +static int push_mpls(struct sk_buff *skb,
> > + const struct ovs_action_push_mpls *mpls)
> [...]
> > + /* update mac_len for subsequent pop_mpls actions. */
> > + skb->mac_len += VLAN_HLEN;
>
> Is this supposed to be part of put_vlan()?
Thanks, this does seem bogus.
I will remove it as mac_len is already incremented in put_vlan().
>
> [...]
>
> > + if (skb->ip_summed == CHECKSUM_COMPLETE)
> > + skb->csum = csum_add(skb->csum, csum_partial(new_mpls_lse,
> > + MPLS_HLEN, 0));
> > +
> > + hdr = (struct ethhdr *)(skb_mac_header(skb));
>
> I think you could simplify this by using eth_hdr().
Thanks, I have updated the code as follows:
hdr = eth_hdr(skb);
> > @@ -616,6 +736,13 @@ int ovs_execute_actions(struct datapath *dp, struct sk_buff *skb)
> > goto out_loop;
> > }
> >
> > + /* Needed to initialise inner protocol on kernels older
> > + * than v3.11 where skb->inner_protocol is not present
> > + * and compatibility code uses the OVS_CB(skb) to store
> > + * the inner protocol.
> > + */
> > + ovs_skb_set_inner_protocol(skb, skb->protocol);
>
> The comment makes it sound like this code should just be deleted when
> upstreaming. However, I believe that we still need to initialize this
> field, right? Is this the best place do it or should it be conditional
> on adding a first MPLS header? (i.e. what happens if inner_protocol is
> already set and the packet simply passes through OVS?)
I believe there are several problems here.
The first one, which my comment was written around is that I think that if
inner_protocol is a field of struct sk_buff then we can rely on it already
being initialised. However, if we are using compatibility code, where
inner_protcol is called in the callback field of struct sk_buff then I
think that OVS needs to initialise it.
Perhaps a good solution to that problem is to add
an ovs_skb_reset_inner_protocol() call which sets
the inner_protocol unconditionally if it is not a field of struct sk_buff.
I believe this could be called from ovs_execute_actions().
A second problem is one that you raise which I had not considered
which is how to handle things if inner_protocol is already set.
I believe this should only occur in the case where inner_protocol
is a field of struct sk_buff and I think it would be most convenient
to set it conditionally in ovs_skb_reset_inner_protocol().
I think that if it is not set it should be zero but it should be
safe to check for values less than ETH_P_802_3_MIN.
In short, I am thinking of something like this:
#ifdef HAVE_INNER_PROTOCOL
static inline void ovs_skb_reset_inner_protocol(struct sk_buff *skb)
{
OVS_CB(skb)->inner_protocol = skb->protocol;
}
#else
static inline void ovs_skb_reset_inner_protocol(struct sk_buff *skb)
{
if (skb->inner_protocol < ETH_P_802_3_MIN)
skb->inner_protocol = skb->protocol;
}
#endif
Pravin has also raised a separate discussion on wheather
OVS_GSO_CB should be used in place of OVS_CB. I would like
to continue that discussion in the sub-thread where is started.
Though obviously the outcome of that discussion may affect the
exact implementation of a solution to the problem discussed above.
> > diff --git a/datapath/vport-netdev.c b/datapath/vport-netdev.c
> > index 215a47e..69f24d1 100644
> > --- a/datapath/vport-netdev.c
> > +++ b/datapath/vport-netdev.c
> > @@ -287,8 +291,17 @@ static int netdev_send(struct vport *vport, struct sk_buff *skb)
> > + inner_protocol = ovs_skb_get_inner_protocol(skb);
> > + if (eth_p_mpls(skb->protocol) && !eth_p_mpls(inner_protocol))
> > + mpls = true;
> > +
> > + if (vlan_tx_tag_present(skb) && !dev_supports_vlan_tx(skb->dev))
> > + vlan = true;
>
> A couple of thoughts on this:
> - I'm not sure that the check on inner_protocol is right since I
> don't think it will be set to an MPLS EtherType in any real situation.
> I think you can just drop it.
Sure, that sounds reasonable.
> - Can we simplify the loop by just inserting the vlan tag (if
> necessary), calling skb_gso_segment(), and sending the packet? I think
> it should be possible now that our skb_gso_segment() backport is more
> robust and it would make things easier to read.
Pravin also raised that idea and yes I think it should be possible.
I have posted a prototype in the sub-thread where Pravin reviewed the code
(as I read that first).
> - Can we have some kind of version check for MPLS, similar to what we
> do for VLAN, so that we don't call into this on kernels >= 3.11?
Sure, I'll see about making that so.
> These are all pretty targeted comments though, as was the one in the
> previous kernel patch so I am basically happy with this overall.
>
> To move forward with this:
> - Pravin, would you mind double checking the GSO compat code?
> - Ben, do you want to take over for the userspace portions of the
> series on the assumption that the above comments can be fixed fairly
> easily?
>
^ permalink raw reply
* Re: [PATCH v2.39 6/7] datapath: Break out deacceleration portion of vlan_push
From: Simon Horman @ 2013-09-19 14:56 UTC (permalink / raw)
To: Jesse Gross
Cc: dev@openvswitch.org, netdev, Ravi K, Isaku Yamahata,
Pravin B Shelar, Joe Stringer
In-Reply-To: <CAEP_g=_ZQ6hNpxoHm6t3N=PxA+3WTrvNegL514j0R3GDM5C92A@mail.gmail.com>
On Fri, Sep 13, 2013 at 03:07:12PM -0700, Jesse Gross wrote:
> On Mon, Sep 9, 2013 at 12:20 AM, Simon Horman <horms@verge.net.au> wrote:
> > diff --git a/datapath/actions.c b/datapath/actions.c
> > index 30ea1d2..6741d81 100644
> > --- a/datapath/actions.c
> > +++ b/datapath/actions.c
> > @@ -105,22 +105,29 @@ static int pop_vlan(struct sk_buff *skb)
> > return 0;
> > }
> >
> > -static int push_vlan(struct sk_buff *skb, const struct ovs_action_push_vlan *vlan)
> > +/* push down current VLAN tag */
> > +static struct sk_buff *put_vlan(struct sk_buff *skb)
>
> This never changes the skb, right? Can we simplify things and just
> return an error code?
Yes. I'm not sure what I was thinking when I chose not to do that
but I will change things around as you suggest.
^ permalink raw reply
* [stable] [PATCH] sfc: Fix efx_rx_buf_offset() for recycled pages
From: Ben Hutchings @ 2013-09-19 14:54 UTC (permalink / raw)
To: David Miller; +Cc: stable, netdev
[-- Attachment #1: Type: text/plain, Size: 1162 bytes --]
This bug fix is only for stable branches older than 3.10. The bug was
fixed upstream by commit 2768935a4660 ('sfc: reuse pages to avoid DMA
mapping/unmapping costs'), but that change is totally unsuitable for
stable.
Commit b590ace09d51 ('sfc: Fix efx_rx_buf_offset() in the presence of
swiotlb') added an explicit page_offset member to struct
efx_rx_buffer, which must be set consistently with the u.page and
dma_addr fields. However, it failed to add the necessary assignment
in efx_resurrect_rx_buffer(). It also did not correct the calculation
of efx_rx_buffer::dma_addr in efx_resurrect_rx_buffer(), which assumes
that DMA-mapping a page will result in a page-aligned DMA address
(exactly what swiotlb violates).
Add the assignment of efx_rx_buffer::page_offset and change the
calculation of dma_addr to make use of it.
I'm attaching the patches for 3.0.y, 3.2.y and 3.4.y (the last of which
should also be applicable to the later unofficial stable branches).
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
[-- Attachment #2: sfc-Fix-efx_rx_buf_offset-for-recycled-pages-3.0.patch --]
[-- Type: text/x-patch, Size: 1833 bytes --]
>From d4e70d42eff6938c12d7d0b12f657b10d06a156d Mon Sep 17 00:00:00 2001
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Fri, 6 Sep 2013 22:39:20 +0100
Subject: sfc: Fix efx_rx_buf_offset() for recycled pages
This bug fix is only for stable branches older than 3.10. The bug was
fixed upstream by commit 2768935a4660 ('sfc: reuse pages to avoid DMA
mapping/unmapping costs'), but that change is totally unsuitable for
stable.
Commit b590ace09d51 ('sfc: Fix efx_rx_buf_offset() in the presence of
swiotlb') added an explicit page_offset member to struct
efx_rx_buffer, which must be set consistently with the u.page and
dma_addr fields. However, it failed to add the necessary assignment
in efx_resurrect_rx_buffer(). It also did not correct the calculation
of efx_rx_buffer::dma_addr in efx_resurrect_rx_buffer(), which assumes
that DMA-mapping a page will result in a page-aligned DMA address
(exactly what swiotlb violates).
Add the assignment of efx_rx_buffer::page_offset and change the
calculation of dma_addr to make use of it.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/sfc/rx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/sfc/rx.c b/drivers/net/sfc/rx.c
index d429f0a..26e4cca 100644
--- a/drivers/net/sfc/rx.c
+++ b/drivers/net/sfc/rx.c
@@ -311,8 +311,9 @@ static void efx_resurrect_rx_buffer(struct efx_rx_queue *rx_queue,
index = rx_queue->added_count & rx_queue->ptr_mask;
new_buf = efx_rx_buffer(rx_queue, index);
- new_buf->dma_addr = rx_buf->dma_addr ^ (PAGE_SIZE >> 1);
new_buf->u.page = rx_buf->u.page;
+ new_buf->page_offset = rx_buf->page_offset ^ (PAGE_SIZE >> 1);
+ new_buf->dma_addr = state->dma_addr + new_buf->page_offset;
new_buf->len = rx_buf->len;
new_buf->is_page = true;
++rx_queue->added_count;
--
1.8.1.4
[-- Attachment #3: sfc-Fix-efx_rx_buf_offset-for-recycled-pages-3.2.patch --]
[-- Type: text/x-patch, Size: 1878 bytes --]
>From 43587737635de32882d9f69df36562e0d5b0e0bd Mon Sep 17 00:00:00 2001
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Fri, 6 Sep 2013 22:39:20 +0100
Subject: sfc: Fix efx_rx_buf_offset() for recycled pages
This bug fix is only for stable branches older than 3.10. The bug was
fixed upstream by commit 2768935a4660 ('sfc: reuse pages to avoid DMA
mapping/unmapping costs'), but that change is totally unsuitable for
stable.
Commit b590ace09d51 ('sfc: Fix efx_rx_buf_offset() in the presence of
swiotlb') added an explicit page_offset member to struct
efx_rx_buffer, which must be set consistently with the u.page and
dma_addr fields. However, it failed to add the necessary assignment
in efx_resurrect_rx_buffer(). It also did not correct the calculation
of efx_rx_buffer::dma_addr in efx_resurrect_rx_buffer(), which assumes
that DMA-mapping a page will result in a page-aligned DMA address
(exactly what swiotlb violates).
Add the assignment of efx_rx_buffer::page_offset and change the
calculation of dma_addr to make use of it.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/ethernet/sfc/rx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/sfc/rx.c b/drivers/net/ethernet/sfc/rx.c
index 9ce8665..c231b3f 100644
--- a/drivers/net/ethernet/sfc/rx.c
+++ b/drivers/net/ethernet/sfc/rx.c
@@ -312,8 +312,9 @@ static void efx_resurrect_rx_buffer(struct efx_rx_queue *rx_queue,
index = rx_queue->added_count & rx_queue->ptr_mask;
new_buf = efx_rx_buffer(rx_queue, index);
- new_buf->dma_addr = rx_buf->dma_addr ^ (PAGE_SIZE >> 1);
new_buf->u.page = rx_buf->u.page;
+ new_buf->page_offset = rx_buf->page_offset ^ (PAGE_SIZE >> 1);
+ new_buf->dma_addr = state->dma_addr + new_buf->page_offset;
new_buf->len = rx_buf->len;
new_buf->is_page = true;
++rx_queue->added_count;
--
1.8.1.4
[-- Attachment #4: sfc-Fix-efx_rx_buf_offset-for-recycled-pages-3.4.patch --]
[-- Type: text/x-patch, Size: 1888 bytes --]
>From 55961f9a914e637f143da275da42154a49c9743a Mon Sep 17 00:00:00 2001
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Fri, 6 Sep 2013 22:39:20 +0100
Subject: sfc: Fix efx_rx_buf_offset() for recycled pages
This bug fix is only for stable branches older than 3.10. The bug was
fixed upstream by commit 2768935a4660 ('sfc: reuse pages to avoid DMA
mapping/unmapping costs'), but that change is totally unsuitable for
stable.
Commit b590ace09d51 ('sfc: Fix efx_rx_buf_offset() in the presence of
swiotlb') added an explicit page_offset member to struct
efx_rx_buffer, which must be set consistently with the u.page and
dma_addr fields. However, it failed to add the necessary assignment
in efx_resurrect_rx_buffer(). It also did not correct the calculation
of efx_rx_buffer::dma_addr in efx_resurrect_rx_buffer(), which assumes
that DMA-mapping a page will result in a page-aligned DMA address
(exactly what swiotlb violates).
Add the assignment of efx_rx_buffer::page_offset and change the
calculation of dma_addr to make use of it.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/ethernet/sfc/rx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/sfc/rx.c b/drivers/net/ethernet/sfc/rx.c
index 7b3c068..62311ad3 100644
--- a/drivers/net/ethernet/sfc/rx.c
+++ b/drivers/net/ethernet/sfc/rx.c
@@ -311,8 +311,9 @@ static void efx_resurrect_rx_buffer(struct efx_rx_queue *rx_queue,
index = rx_queue->added_count & rx_queue->ptr_mask;
new_buf = efx_rx_buffer(rx_queue, index);
- new_buf->dma_addr = rx_buf->dma_addr ^ (PAGE_SIZE >> 1);
new_buf->u.page = rx_buf->u.page;
+ new_buf->page_offset = rx_buf->page_offset ^ (PAGE_SIZE >> 1);
+ new_buf->dma_addr = state->dma_addr + new_buf->page_offset;
new_buf->len = rx_buf->len;
new_buf->flags = EFX_RX_BUF_PAGE;
++rx_queue->added_count;
--
1.8.1.4
^ permalink raw reply related
* Re: [PATCH 1/2] net, vxlan Fix compile warning [v3]
From: Prarit Bhargava @ 2013-09-19 13:13 UTC (permalink / raw)
To: David Miller; +Cc: netdev, jpirko, stephen, bhutchings
In-Reply-To: <20130919.090924.197034249810458131.davem@davemloft.net>
On 09/19/2013 09:09 AM, David Miller wrote:
>
> You must resend all of the patches in the series when you make
> updates, not just the patches you have changed.
Ah, okay :) I've been dealing with other mailing lists and they prefer single
patch updates like this. My apologies ... I'll send out a new update in a week
or so when Jack Morgenstein, jackm@dev.mellanox.co.il, returns.
Again, my apologies for not adhering to this list's rules and procedures.
P.
^ permalink raw reply
* Re: [PATCH 1/2] net, vxlan Fix compile warning [v3]
From: David Miller @ 2013-09-19 13:09 UTC (permalink / raw)
To: prarit; +Cc: netdev, jpirko, stephen, bhutchings
In-Reply-To: <1379595894-23200-1-git-send-email-prarit@redhat.com>
You must resend all of the patches in the series when you make
updates, not just the patches you have changed.
^ permalink raw reply
* Re: [PATCH] USBNET: fix handling padding packet
From: Ming Lei @ 2013-09-19 13:08 UTC (permalink / raw)
To: Bjørn Mork
Cc: Oliver Neukum, David S. Miller, Greg Kroah-Hartman,
Network Development, linux-usb
In-Reply-To: <87wqmd46vj.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
On Thu, Sep 19, 2013 at 3:18 PM, Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> wrote:
> Oliver Neukum <oneukum-l3A5Bk7waGM@public.gmane.org> writes:
>> On Wed, 2013-09-18 at 20:56 +0200, Bjørn Mork wrote:
>>> Oliver Neukum <oneukum-l3A5Bk7waGM@public.gmane.org> wrote:
>>
>>> >No, USB 3.0 uses no companion controllers, so you can have devices
>>> >of any speed connected to it.
>>> >
>>>
>>> Ah, right. I don't own such modern hardware, but I should have known
>>> this anyway.
>>>
>>> This still doesn't change the fact that the driver is brand new for
>>> brand new devices. I believe we should assume such devices will
>>> support ZLPs unless we have documentation stating anything else.
>>
>> For such devices we might assume it. But how does that matter for
>> generic code?
>
> The code isn't generic yet. Most of it is placed inside the
> ax88179_178a minidriver.
No, the patch doesn't touch code of ax99179_178a.
And it is really generic to fix the padding in case of dma sg.
>
> But I do agree that adding this padding support can be seen as one step
> towards making the code generic. So if you really anticipate this being
> enabled for e.g. the ECM class driver, then yes, padding must be
> supported.
1byte padding frame is already supported by usbnet before, isn't it?
>
> I would have had less trouble understanding the value if this patch was
> part of a generalisation series, though...
As my below test on ax99179_178a, I believe the patch should fix padding
for dma sg, but need a little update, and I will send out v1 later:
$ping -s 974 another_machine #from host with ax99179_178a attached
If FLAG_SEND_ZLP is set for ax99179_178a, the above ping won't work any
more either on USB3.0 or USB 2.0 host controller.
So don't assume that these brand new devices can support ZLP well.
>
>> As any kind of device may be connected to XHCI, the sg
>> code is relevant for every driver. And I certainly don't want trouble
>> for older devices' drivers converted to sg.
>
> I wonder what the gain of that really is? Yes, I can see the advantage
> of making the class drivers more effective. But padding is only
> relevant for the ECM class, isn't it? And are there any ECM class
> devices where SG support matters?
Why is padding only relevant for the ECM? Of course, other devices
need it too, such as asix devices.
Thanks,
--
Ming Lei
--
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
* [PATCH -net v2 2/2] netconsole: fix a deadlock with rtnl and netconsole's mutex
From: Nikolay Aleksandrov @ 2013-09-19 13:02 UTC (permalink / raw)
To: netdev; +Cc: davem
In-Reply-To: <1379595756-3527-1-git-send-email-nikolay@redhat.com>
This bug was introduced by commit
7a163bfb7ce50895bbe67300ea610d31b9c09230 ("netconsole: avoid a crash with
multiple sysfs writers"). In store_enabled() we have the following
sequence: acquire nt->mutex then rtnl, but in the netconsole netdev
notifier we have rtnl then nt->mutex effectively leading to a deadlock.
The NULL pointer dereference that the above commit tries to fix is
actually due to another bug in netpoll_cleanup(). This is fixed by dropping
the mutex from the netdev notifier as it's already protected by rtnl.
Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
---
v2: new patch dependent on the fix from patch 01
drivers/net/netconsole.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
index dcb2134..adeee61 100644
--- a/drivers/net/netconsole.c
+++ b/drivers/net/netconsole.c
@@ -684,15 +684,12 @@ restart:
case NETDEV_RELEASE:
case NETDEV_JOIN:
case NETDEV_UNREGISTER:
- /*
- * rtnl_lock already held
+ /* rtnl_lock already held
* we might sleep in __netpoll_cleanup()
*/
spin_unlock_irqrestore(&target_list_lock, flags);
- mutex_lock(&nt->mutex);
__netpoll_cleanup(&nt->np);
- mutex_unlock(&nt->mutex);
spin_lock_irqsave(&target_list_lock, flags);
dev_put(nt->np.dev);
--
1.8.1.4
^ permalink raw reply related
* [PATCH -net v2 1/2] netpoll: fix NULL pointer dereference in netpoll_cleanup
From: Nikolay Aleksandrov @ 2013-09-19 13:02 UTC (permalink / raw)
To: netdev; +Cc: davem
In-Reply-To: <1379595756-3527-1-git-send-email-nikolay@redhat.com>
I've been hitting a NULL ptr deref while using netconsole because the
np->dev check and the pointer manipulation in netpoll_cleanup are done
without rtnl and the following sequence happens when having a netconsole
over a vlan and we remove the vlan while disabling the netconsole:
CPU 1 CPU2
removes vlan and calls the notifier
enters store_enabled(), calls
netdev_cleanup which checks np->dev
and then waits for rtnl
executes the netconsole netdev
release notifier making np->dev
== NULL and releases rtnl
continues to dereference a member of
np->dev which at this point is == NULL
Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
---
v2: fix the style as requested
net/core/netpoll.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index 2c637e9..2ba363d 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -1284,15 +1284,14 @@ EXPORT_SYMBOL_GPL(__netpoll_free_async);
void netpoll_cleanup(struct netpoll *np)
{
- if (!np->dev)
- return;
-
rtnl_lock();
+ if (!np->dev)
+ goto out;
__netpoll_cleanup(np);
- rtnl_unlock();
-
dev_put(np->dev);
np->dev = NULL;
+out:
+ rtnl_unlock();
}
EXPORT_SYMBOL(netpoll_cleanup);
--
1.8.1.4
^ permalink raw reply related
* [PATCH -net v2 0/2] net: netpoll and netconsole fixes
From: Nikolay Aleksandrov @ 2013-09-19 13:02 UTC (permalink / raw)
To: netdev; +Cc: davem
Hi,
This small patchset fixes a possible race condition in netpoll_cleanup
which can lead to a NULL pointer dereference because the check and
manipulation of np->dev are done outside of the rtnl lock (patch 01).
The second patch fixes a deadlock in netconsole and does a trivial comment
style fix.
v2: fix the function style in patch 01
Best regards,
Nikolay Aleksandrov
Nikolay Aleksandrov (2):
netpoll: fix NULL pointer dereference in netpoll_cleanup
netconsole: fix a deadlock with rtnl and netconsole's mutex
drivers/net/netconsole.c | 5 +----
net/core/netpoll.c | 9 ++++-----
2 files changed, 5 insertions(+), 9 deletions(-)
--
1.8.1.4
^ permalink raw reply
* Re: [PATCH 1/2] net, vxlan Fix compile warning [v3]
From: Prarit Bhargava @ 2013-09-19 13:04 UTC (permalink / raw)
To: netdev; +Cc: Prarit Bhargava, jpirko, davem, stephen, bhutchings
In-Reply-To: <1379449581.1644.17.camel@bwh-desktop.uk.level5networks.com>
Fix a unintialized variable warning.
drivers/net/vxlan.c: In function ‘vxlan_sock_add’:
drivers/net/vxlan.c:2240:11: error: ‘sock’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
vs->sock = sock;
^
drivers/net/vxlan.c:2217:17: note: ‘sock’ was declared here
struct socket *sock;
^
[v2]: davem suggested resolving this by making create_v{4,6}_sock() return an err
pointer.
[v3]: Ben Hutchings pointed out a missed conversion
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Cc: jpirko@redhat.com
Cc: davem@davemloft.net
Cc: stephen@networkplumber.org
Cc: bhutchings@solarflare.com
---
drivers/net/vxlan.c | 31 ++++++++++++++-----------------
1 file changed, 14 insertions(+), 17 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index bf64b41..0583d45 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -2184,7 +2184,7 @@ static void vxlan_del_work(struct work_struct *work)
* could be used for both IPv4 and IPv6 communications, but
* users may set bindv6only=1.
*/
-static int create_v6_sock(struct net *net, __be16 port, struct socket **psock)
+static struct socket *create_v6_sock(struct net *net, __be16 port)
{
struct sock *sk;
struct socket *sock;
@@ -2197,7 +2197,7 @@ static int create_v6_sock(struct net *net, __be16 port, struct socket **psock)
rc = sock_create_kern(AF_INET6, SOCK_DGRAM, IPPROTO_UDP, &sock);
if (rc < 0) {
pr_debug("UDPv6 socket create failed\n");
- return rc;
+ return ERR_PTR(rc);
}
/* Put in proper namespace */
@@ -2212,28 +2212,27 @@ static int create_v6_sock(struct net *net, __be16 port, struct socket **psock)
pr_debug("bind for UDPv6 socket %pI6:%u (%d)\n",
&vxlan_addr.sin6_addr, ntohs(vxlan_addr.sin6_port), rc);
sk_release_kernel(sk);
- return rc;
+ return ERR_PTR(rc);
}
/* At this point, IPv6 module should have been loaded in
* sock_create_kern().
*/
BUG_ON(!ipv6_stub);
- *psock = sock;
/* Disable multicast loopback */
inet_sk(sk)->mc_loop = 0;
- return 0;
+ return sock;
}
#else
-static int create_v6_sock(struct net *net, __be16 port, struct socket **psock)
+static struct socket *create_v6_sock(struct net *net, __be16 port)
{
- return -EPFNOSUPPORT;
+ return ERR_PTR(-EPFNOSUPPORT);
}
#endif
-static int create_v4_sock(struct net *net, __be16 port, struct socket **psock)
+static struct socket *create_v4_sock(struct net *net, __be16 port)
{
struct sock *sk;
struct socket *sock;
@@ -2248,7 +2247,7 @@ static int create_v4_sock(struct net *net, __be16 port, struct socket **psock)
rc = sock_create_kern(AF_INET, SOCK_DGRAM, IPPROTO_UDP, &sock);
if (rc < 0) {
pr_debug("UDP socket create failed\n");
- return rc;
+ return ERR_PTR(rc);
}
/* Put in proper namespace */
@@ -2261,13 +2260,12 @@ static int create_v4_sock(struct net *net, __be16 port, struct socket **psock)
pr_debug("bind for UDP socket %pI4:%u (%d)\n",
&vxlan_addr.sin_addr, ntohs(vxlan_addr.sin_port), rc);
sk_release_kernel(sk);
- return rc;
+ return ERR_PTR(rc);
}
- *psock = sock;
/* Disable multicast loopback */
inet_sk(sk)->mc_loop = 0;
- return 0;
+ return sock;
}
/* Create new listen socket if needed */
@@ -2278,7 +2276,6 @@ static struct vxlan_sock *vxlan_socket_create(struct net *net, __be16 port,
struct vxlan_sock *vs;
struct socket *sock;
struct sock *sk;
- int rc = 0;
unsigned int h;
vs = kmalloc(sizeof(*vs), GFP_KERNEL);
@@ -2291,12 +2288,12 @@ static struct vxlan_sock *vxlan_socket_create(struct net *net, __be16 port,
INIT_WORK(&vs->del_work, vxlan_del_work);
if (ipv6)
- rc = create_v6_sock(net, port, &sock);
+ sock = create_v6_sock(net, port);
else
- rc = create_v4_sock(net, port, &sock);
- if (rc < 0) {
+ sock = create_v4_sock(net, port);
+ if (IS_ERR(sock)) {
kfree(vs);
- return ERR_PTR(rc);
+ return ERR_CAST(sock);
}
vs->sock = sock;
--
1.7.9.3
^ permalink raw reply related
* RE: [PATCH net-next v4] Don't destroy the netdev until the vif is shut down
From: Paul Durrant @ 2013-09-19 11:55 UTC (permalink / raw)
To: Ian Campbell
Cc: Wei Liu, xen-devel@lists.xen.org, netdev@vger.kernel.org,
David Vrabel
In-Reply-To: <1379521517.11304.274.camel@hastur.hellion.org.uk>
> -----Original Message-----
> From: Ian Campbell [mailto:ian.campbell@citrix.com]
> Sent: 18 September 2013 17:25
> To: Paul Durrant
> Cc: Wei Liu; xen-devel@lists.xen.org; netdev@vger.kernel.org; David Vrabel
> Subject: Re: [PATCH net-next v4] Don't destroy the netdev until the vif is
> shut down
>
> On Wed, 2013-09-18 at 17:04 +0100, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Ian Campbell [mailto:ian.campbell@citrix.com]
> > > Sent: 18 September 2013 16:58
> > > To: Wei Liu
> > > Cc: Paul Durrant; xen-devel@lists.xen.org; netdev@vger.kernel.org;
> David
> > > Vrabel
> > > Subject: Re: [PATCH net-next v4] Don't destroy the netdev until the vif is
> > > shut down
> > >
> > > On Wed, 2013-09-18 at 11:37 +0100, Wei Liu wrote:
> > > > On Tue, Sep 17, 2013 at 05:46:08PM +0100, Paul Durrant wrote:
> > > > > Without this patch, if a frontend cycles through states Closing
> > > > > and Closed (which Windows frontends need to do) then the netdev
> > > > > will be destroyed and requires re-invocation of hotplug scripts
> > > > > to restore state before the frontend can move to Connected. Thus
> > > > > when udev is not in use the backend gets stuck in InitWait.
> > > > >
> > > > > With this patch, the netdev is left alone whilst the backend is
> > > > > still online and is only de-registered and freed just prior to
> > > > > destroying the vif (which is also nicely symmetrical with the
> > > > > netdev allocation and registration being done during probe) so
> > > > > no re-invocation of hotplug scripts is required.
> > > > >
> > > > > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> > > > > Cc: David Vrabel <david.vrabel@citrix.com>
> > > > > Cc: Wei Liu <wei.liu2@citrix.com>
> > > > > Cc: Ian Campbell <ian.campbell@citrix.com>
> > > >
> > > > Acked-by: Wei Liu <wei.liu2@citrix.com>
> > >
> > > yeah, looks good, thanks.
> > >
> > > Paul, did you test this with non-Windows frontends too? and do things
> > > like vif hot(un)plug still work?
> > >
> >
> > Ian,
> >
> > I tested with a debian (wheezy) PV guest but I didn't test unplug. I
> > cycled a windows frontend several times (which is how I spotted the
> > tx_irq thing), and shutdown and brought up both the debian and windows
> > guests several times. I can test unplug too if you'd like.
>
> I don't think it needs to be a blocker for accepting this patch but it
> would be good to try it, it's the sort of area which historically gets
> broken by this sort of change.
>
FWIW I just checked network-detach with a windows frontend and it worked ok.
Paul
^ permalink raw reply
* Re: [PATCH] net: tsi108: Prevent compiler warning
From: Thierry Reding @ 2013-09-19 11:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel
In-Reply-To: <20130918.123853.1464055976885078627.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 927 bytes --]
On Wed, Sep 18, 2013 at 12:38:53PM -0400, David Miller wrote:
> From: Thierry Reding <thierry.reding@gmail.com>
> Date: Wed, 18 Sep 2013 14:49:55 +0200
>
> > The dump_eth_one() function is only used if DEBUG is enabled, so protect
> > it by a corresponding #ifdef DEBUG block.
> >
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
>
> I would prefer that this function and the one call site is simply
> removed instead.
>
> This kind of thing can be provided via ethtool register dumps
> and therefore without all of the ugliness this ad-hoc stuff
> presents.
I just noticed the warning during some test builds I was doing due to
some unrelated patches and thought I'd clean it up along the way.
I'll send a patch to remove the functionality completely if that's what
you prefer, but I won't be able to reimplement it using ethtool. Perhaps
someone with actual hardware can do that.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH net 1/3] slip/slcan: added locking in wakeup function
From: Peter Hurley @ 2013-09-19 10:43 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Andre Naujoks, davem, Wolfgang Grandegger, linux-can, netdev,
linux-kernel, Greg KH
In-Reply-To: <523AD356.70607@pengutronix.de>
[ +cc Greg Kroah-Hartman]
On 09/19/2013 06:35 AM, Marc Kleine-Budde wrote:
> On 09/19/2013 12:29 PM, Andre Naujoks wrote:
>> On 19.09.2013 11:36, schrieb Marc Kleine-Budde:
>>> On 09/13/2013 07:37 PM, Andre Naujoks wrote:
>>>> The locking is needed, since the the internal buffer for the CAN
>>>> frames is changed during the wakeup call. This could cause buffer
>>>> inconsistencies under high loads, especially for the outgoing
>>>> short CAN packet skbuffs.
>>>>
>>>> The needed locks led to deadlocks before commit
>>>> "5ede52538ee2b2202d9dff5b06c33bfde421e6e4 tty: Remove extra
>>>> wakeup from pty write() path", which removed the direct callback
>>>> to the wakeup function from the tty layer.
>>>
>>> What does that mean for older kernels? (<
>>> 5ede52538ee2b2202d9dff5b06c33bfde421e6e4)
>>
>> It seems the slcan (and slip) driver is broken for older kernels. See
>> this thread for a discussion about the patch in pty.c.
>>
>> http://marc.info/?l=linux-kernel&m=137269017002789&w=2
>
> Thanks for the info.
>
>> The patch from Peter Hurley was actually already in the queue, when I
>> ran into the problem, and is now in kernel 3.12.
>>
>> Without the pty patch and slow CAN traffic, the driver works, because
>> the wakeup is called directly from the pty driver. That is also the
>> reason why there was no locking. It would just deadlock.
>>
>> When the pty driver defers the wakeup, we ran into synchronisation
>> problems (which should be fixed by the locking) and eventually into a
>> kernel panic because of a recursive loop (which should be fixed by the
>> pty.c patch).
>>
>> Maybe it is possible to get both patches back into the stable branches?
>
> Sounds reasonable. You might get in touch with Peter Hurley, if his
> patch is scheduled for stable. Documentation/stable_kernel_rules.txt
> suggests a procedure if your patch depends on others to be cherry picked.
Already following along.
I'd like to wait for 3.12 release before the pty patch goes to -stable
(so that it gets more in-the-wild testing).
Regards,
Peter Hurley
^ permalink raw reply
* Re: [PATCH net 1/3] slip/slcan: added locking in wakeup function
From: Marc Kleine-Budde @ 2013-09-19 10:35 UTC (permalink / raw)
To: Andre Naujoks; +Cc: davem, Wolfgang Grandegger, linux-can, netdev, linux-kernel
In-Reply-To: <523AD21C.8030102@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2097 bytes --]
On 09/19/2013 12:29 PM, Andre Naujoks wrote:
> On 19.09.2013 11:36, schrieb Marc Kleine-Budde:
>> On 09/13/2013 07:37 PM, Andre Naujoks wrote:
>>> The locking is needed, since the the internal buffer for the CAN
>>> frames is changed during the wakeup call. This could cause buffer
>>> inconsistencies under high loads, especially for the outgoing
>>> short CAN packet skbuffs.
>>>
>>> The needed locks led to deadlocks before commit
>>> "5ede52538ee2b2202d9dff5b06c33bfde421e6e4 tty: Remove extra
>>> wakeup from pty write() path", which removed the direct callback
>>> to the wakeup function from the tty layer.
>>
>> What does that mean for older kernels? (<
>> 5ede52538ee2b2202d9dff5b06c33bfde421e6e4)
>
> It seems the slcan (and slip) driver is broken for older kernels. See
> this thread for a discussion about the patch in pty.c.
>
> http://marc.info/?l=linux-kernel&m=137269017002789&w=2
Thanks for the info.
> The patch from Peter Hurley was actually already in the queue, when I
> ran into the problem, and is now in kernel 3.12.
>
> Without the pty patch and slow CAN traffic, the driver works, because
> the wakeup is called directly from the pty driver. That is also the
> reason why there was no locking. It would just deadlock.
>
> When the pty driver defers the wakeup, we ran into synchronisation
> problems (which should be fixed by the locking) and eventually into a
> kernel panic because of a recursive loop (which should be fixed by the
> pty.c patch).
>
> Maybe it is possible to get both patches back into the stable branches?
Sounds reasonable. You might get in touch with Peter Hurley, if his
patch is scheduled for stable. Documentation/stable_kernel_rules.txt
suggests a procedure if your patch depends on others to be cherry picked.
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
* xmm registers in amd64 drivers
From: David Laight @ 2013-09-19 10:31 UTC (permalink / raw)
To: Network Development
I realise this isn't quite the right list for this question.
But I suspect someone will know the answer!
I've just compiled one of our drivers (an ss7 protocol stack)
on a much newer system than the one we usually use
(ubunto 13.04 with gcc 4.7.3 rather than debian lenny).
I've bodged around some strict-aliasing and const-cast warnings
- the usage all look safe.
Looking at the object code I noticed that all the stdarg
functions now contain code to conditionally save the xmm
registers.
Is this now considered 'normal' or am I missing a compiler flag?
I know I've looked at the code before since I tried adding
enough fixed parameters to one of the functions to get all
the variable ones on-stack hoping that would optimise the
accesses - it didn't.
David
^ permalink raw reply
* Re: [PATCH net 1/3] slip/slcan: added locking in wakeup function
From: Andre Naujoks @ 2013-09-19 10:29 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: davem, Wolfgang Grandegger, linux-can, netdev, linux-kernel
In-Reply-To: <523AC589.5040006@pengutronix.de>
On 19.09.2013 11:36, schrieb Marc Kleine-Budde:
> On 09/13/2013 07:37 PM, Andre Naujoks wrote:
>> The locking is needed, since the the internal buffer for the CAN
>> frames is changed during the wakeup call. This could cause buffer
>> inconsistencies under high loads, especially for the outgoing
>> short CAN packet skbuffs.
>>
>> The needed locks led to deadlocks before commit
>> "5ede52538ee2b2202d9dff5b06c33bfde421e6e4 tty: Remove extra
>> wakeup from pty write() path", which removed the direct callback
>> to the wakeup function from the tty layer.
>
> What does that mean for older kernels? (<
> 5ede52538ee2b2202d9dff5b06c33bfde421e6e4)
It seems the slcan (and slip) driver is broken for older kernels. See
this thread for a discussion about the patch in pty.c.
http://marc.info/?l=linux-kernel&m=137269017002789&w=2
The patch from Peter Hurley was actually already in the queue, when I
ran into the problem, and is now in kernel 3.12.
Without the pty patch and slow CAN traffic, the driver works, because
the wakeup is called directly from the pty driver. That is also the
reason why there was no locking. It would just deadlock.
When the pty driver defers the wakeup, we ran into synchronisation
problems (which should be fixed by the locking) and eventually into a
kernel panic because of a recursive loop (which should be fixed by the
pty.c patch).
Maybe it is possible to get both patches back into the stable branches?
Regards
Andre
>
>> As slcan.c is based on slip.c the issue in the original code is
>> fixed, too.
>>
>> Signed-off-by: Andre Naujoks <nautsch2@gmail.com>
> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
>
> Marc
>
^ permalink raw reply
* [PATCH] Confirm success for each tc -batch command
From: Petr Písař @ 2013-09-19 10:13 UTC (permalink / raw)
To: netdev; +Cc: shemminger, Petr Písař
If `tc -force -batch' is fed by a controlling program from a pipe,
it's not possible to recognize when a command has been processes
successfully.
This patch adds an optional `-OK' option to the tc(8) tool, so `tc
-force -OK -batch' will print "OK\n" to standard output on each
successfully completed tc command.
Signed-off-by: Petr Písař <ppisar@redhat.com>
---
man/man8/tc.8 | 8 +++++++-
tc/tc.c | 8 +++++++-
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/man/man8/tc.8 b/man/man8/tc.8
index e0acfeb..583eae2 100644
--- a/man/man8/tc.8
+++ b/man/man8/tc.8
@@ -49,7 +49,7 @@ DEV
DEV
.P
-.B tc [ -force ] -b\fR[\fIatch\fR] \fB[ filename ]
+.B tc [ -force ] [ -OK ] -b\fR[\fIatch\fR] \fB[ filename ]
.ti 8
.IR FORMAT " := {"
@@ -440,6 +440,12 @@ First failure will cause termination of tc.
don't terminate tc on errors in batch mode.
If there were any errors during execution of the commands, the application return code will be non zero.
+.TP
+.BR "\-OK"
+in batch mode, print
+.B OK
+and a new line on standard output after each successfully interpreted command.
+
.SH HISTORY
.B tc
was written by Alexey N. Kuznetsov and added in Linux 2.2.
diff --git a/tc/tc.c b/tc/tc.c
index 9b50e74..b43bb47 100644
--- a/tc/tc.c
+++ b/tc/tc.c
@@ -39,6 +39,7 @@ int batch_mode = 0;
int resolve_hosts = 0;
int use_iec = 0;
int force = 0;
+int ok = 0;
struct rtnl_handle rth;
static void *BODY = NULL; /* cached handle dlopen(NULL) */
@@ -183,7 +184,7 @@ noexist:
static void usage(void)
{
fprintf(stderr, "Usage: tc [ OPTIONS ] OBJECT { COMMAND | help }\n"
- " tc [-force] -batch filename\n"
+ " tc [-force] [-OK] -batch filename\n"
"where OBJECT := { qdisc | class | filter | action | monitor }\n"
" OPTIONS := { -s[tatistics] | -d[etails] | -r[aw] | -p[retty] | -b[atch] [filename] }\n");
}
@@ -251,6 +252,9 @@ static int batch(const char *name)
ret = 1;
if (!force)
break;
+ } else if (ok) {
+ printf("OK\n");
+ fflush(stdout);
}
}
if (line)
@@ -288,6 +292,8 @@ int main(int argc, char **argv)
return 0;
} else if (matches(argv[1], "-force") == 0) {
++force;
+ } else if (matches(argv[1], "-OK") == 0) {
+ ++ok;
} else if (matches(argv[1], "-batch") == 0) {
argc--; argv++;
if (argc <= 1)
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net 2/3] lib: introduce upper case hex ascii helpers
From: Oliver Hartkopp @ 2013-09-19 9:57 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Andrew Morton, Thiago Farina, Andre Naujoks, David S. Miller,
Steven Rostedt, Rusty Russell, Arnd Bergmann, Michael S. Tsirkin,
Vladimir Kondratiev, Jason Baron, Greg Kroah-Hartman, linux list,
linux-can, netdev
In-Reply-To: <523AC615.9020204@pengutronix.de>
On 19.09.2013 11:38, Marc Kleine-Budde wrote:
> On 09/15/2013 06:35 AM, Andrew Morton wrote:
>> On Sun, 15 Sep 2013 01:27:03 -0300 Thiago Farina <tfransosi@gmail.com> wrote:
>>
>>> On Fri, Sep 13, 2013 at 2:37 PM, Andre Naujoks <nautsch2@gmail.com> wrote:
>>>> To be able to use the hex ascii functions in case sensitive environments
>>>> the array hex_asc_upper[] and the needed functions for hex_byte_pack_upper()
>>>> are introduced.
>>>>
>>>> Signed-off-by: Andre Naujoks <nautsch2@gmail.com>
>>>> ---
>>>> include/linux/kernel.h | 11 +++++++++++
>>>> lib/hexdump.c | 2 ++
>>>> 2 files changed, 13 insertions(+)
>>>>
>>>> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
>>>> index 482ad2d..672ddc4 100644
>>>> --- a/include/linux/kernel.h
>>>> +++ b/include/linux/kernel.h
>>>> @@ -439,6 +439,17 @@ static inline char *hex_byte_pack(char *buf, u8 byte)
>>>> return buf;
>>>> }
>>>>
>>>> +extern const char hex_asc_upper[];
>>>> +#define hex_asc_upper_lo(x) hex_asc_upper[((x) & 0x0f)]
>>>> +#define hex_asc_upper_hi(x) hex_asc_upper[((x) & 0xf0) >> 4]
>>> Does using a macro instead of a real function (static inline)
>>> generates a better code?
>>
>> Yes, a static inline would be nicer, but these are derived from
>> hex_asc_lo/hex_asc_hi. If we change one we should change the other
>> and that becomes a separate cleanup. So I think this patch is
>> OK as-is.
>
> Is this an Acked-by?
>
>> Also, it would make sense to get all the *hex* stuff out of kernel.h
>> and into a new header file (hexchar.h?). They're a clean
>> self-contained thing and kernel.h is rather a dumping ground.
>
> Who is taking this series?
Andre suggested that Dave Miller could take these three patches for 3.12 as
they are mainly network fixes:
http://marc.info/?l=linux-can&m=137909384116115&w=2
Regards,
Oliver
^ permalink raw reply
* Re: [PATCH net 3/3] slcan: rewrite of slc_bump and slc_encaps
From: Marc Kleine-Budde @ 2013-09-19 9:47 UTC (permalink / raw)
To: Andre Naujoks; +Cc: davem, Wolfgang Grandegger, linux-can, netdev, linux-kernel
In-Reply-To: <1379093833-4949-4-git-send-email-nautsch2@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 995 bytes --]
On 09/13/2013 07:37 PM, Andre Naujoks wrote:
> The old implementation was heavy on str* functions and sprintf calls.
> This version is more manual, but faster.
>
> Profiling just the printing of a 3 char CAN-id resulted in 60 instructions
> for the manual method and over 2000 for the sprintf method. Bear in
> mind the profiling was done against libc and not the kernel sprintf.
>
> Together with this rewrite an issue with sending and receiving of RTR frames
> has been fixed by Oliver for the cases that the DLC is not zero.
>
> Signed-off-by: Andre Naujoks <nautsch2@gmail.com>
> Tested-by: Oliver Hartkopp <socketcan@hartkopp.net>
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
regards,
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
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