* Re: [PATCH 1/1] isdn: hfcpci_softirq: get func return to suppress compiler warning
From: David Miller @ 2013-09-16 4:53 UTC (permalink / raw)
To: antonio.alecrim; +Cc: isdn, standby24x7, netdev, linux-kernel
In-Reply-To: <1379179240-21927-1-git-send-email-antonio.alecrim@gmail.com>
From: Antonio Alecrim Jr <antonio.alecrim@gmail.com>
Date: Sat, 14 Sep 2013 14:20:40 -0300
> Signed-off-by: Antonio Alecrim Jr <antonio.alecrim@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] cxgb4: remove workqueue when driver registration fails
From: David Miller @ 2013-09-16 4:53 UTC (permalink / raw)
To: weiyang; +Cc: dm, netdev
In-Reply-To: <1379253180-10292-1-git-send-email-weiyang@linux.vnet.ibm.com>
From: Wei Yang <weiyang@linux.vnet.ibm.com>
Date: Sun, 15 Sep 2013 21:53:00 +0800
> When driver registration fails, we need to clean up the resources allocated
> before. cxgb4 missed to destroy the workqueue allocated at the very beginning.
>
> This patch destroies the workqueue when registration fails.
>
> Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/1] net: race condition when removing virtual net_device
From: Francesco Ruggeri @ 2013-09-16 2:54 UTC (permalink / raw)
To: Eric W. Biederman
Cc: David S. Miller, Eric Dumazet, Jiri Pirko, Alexander Duyck,
Cong Wang, netdev
In-Reply-To: <87d2ocrx9b.fsf@xmission.com>
On Fri, Sep 13, 2013 at 6:46 PM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> Francesco Ruggeri <fruggeri@aristanetworks.com> writes:
>
>> On Thu, Sep 12, 2013 at 10:50 PM, Eric W. Biederman
>> <ebiederm@xmission.com> wrote:
>>
>> I do have some concerns about both correctness and feasibility of this approach.
>>
>> About 2), namespace dependent operations triggered by unregistering
>> the virtual devices (eg rt_flush_dev, dst_dev_event/dst_ifdown and
>> probably more) would not be done in the namespaces where they should.
>
> Yes they will. That is what dev_change_net_namespace does.
You are right, I don't know what I was thinking.
>
> It was worth a second look. I can not find anything wrong with your
> patch but I can not convince myself that it is correct either. The
> moving around the loopback device in the net dev todo list to prevent
> deadlock I can't imagine why you are doing that.
>
That is in order not to introduce a potential deadlock when multiple
namespaces are destroyed in default_device_exit_batch.
Take the same veth scenario as before:
v0 in namespace ns0 (loopback_dev lo0) and similarly for v1, ns1 and lo1.
Assume two processes destroy ns0 and ns1. cleanup_net is executed in a
workqueue and the two namespaces can end up being processed in the
same instance of cleanup_net/ops_exit_list/default_device_exit_batch.
default_device_exit_batch traverses each namespace's dev_base list and
unregister_netdevice_queue is executed in this order:
v0 v1 lo0 v1 v0 lo1.
unregister_netdevice_queue is executed twice on v0 and v1 but that is
ok because it uses list_move_tail and only the last one sticks.
The resulting list for unregister_netdevice_many is:
lo0 v1 v0 lo1.
If v0 holds a reference to lo0 there will be a deadlock in
netdev_run_todo if v0 does not come before lo0 in net_todo_list. By
pushing all loopback_devs to the end of net_todo_list this situation
is avoided.
This is the sequence with today's (actually 3.4) code:
unregister_netdevice_queue: v0 (ns ffff880037aecd00)
unregister_netdevice_queue: v1 (ns ffff880037aed800)
unregister_netdevice_queue: lo (ns ffff880037aecd00)
unregister_netdevice_queue: v1 (ns ffff880037aed800)
unregister_netdevice_queue: v0 (ns ffff880037aecd00)
unregister_netdevice_queue: lo (ns ffff880037aed800)
unregister_netdevice_many: lo (ns ffff880037aecd00) v1 (ns
ffff880037aed800) v0 (ns ffff880037aecd00) lo (ns ffff880037aed800)
netdev_run_todo: lo (ns ffff880037aecd00) v1 (ns ffff880037aed800) v0
(ns ffff880037aecd00) lo (ns ffff880037aed800)
and this is the sequence after pushing the loopback_devs to the tail
of net_todo_list:
unregister_netdevice_queue: v0 (ns ffff8800379f8000)
unregister_netdevice_queue: v1 (ns ffff8800378c0b00)
unregister_netdevice_queue: lo (ns ffff8800379f8000)
unregister_netdevice_queue: v1 (ns ffff8800378c0b00)
unregister_netdevice_queue: v0 (ns ffff8800379f8000)
unregister_netdevice_queue: lo (ns ffff8800378c0b00)
unregister_netdevice_many: lo (ns ffff8800379f8000) v1 (ns
ffff8800378c0b00) v0 (ns ffff8800379f8000) lo (ns ffff8800378c0b00)
netdev_run_todo: v1 (ns ffff8800378c0b00) v0 (ns ffff8800379f8000) lo
(ns ffff8800379f8000) lo (ns ffff8800378c0b00)
Should we take this discussion offline?
I do appreciate your spending time on this.
Thanks,
Francesco
>
> Eric
>
^ permalink raw reply
* Re: [PATCHv3 linux-next] hrtimer: Add notifier when clock_was_set was called
From: Fan Du @ 2013-09-16 0:26 UTC (permalink / raw)
To: Thomas Gleixner
Cc: David Miller, herbert, steffen.klassert, dborkman, linux-kernel,
netdev, John Stultz
In-Reply-To: <alpine.DEB.2.02.1309131628250.4089@ionos.tec.linutronix.de>
Hi, Thomas
On 2013年09月13日 22:32, Thomas Gleixner wrote:
> On Fri, 13 Sep 2013, Fan Du wrote:
>> (2) What I have been bugging you around here for this long time is really the
>> second
>> problem, I'm sorry I didn't make it clearly to you and others, which is
>> below:
>>
>> Why using wall clock time to calculate soft/hard IPsec events when
>> xfrm_state timer
>> out happens in its timeout handler? Because even if xfrm_state using
>> CLOCK_BOOTTIME,
>> system wall clock time changing will surely disturb soft/hard IPsec
>> events, which
>> you raised your concern about in (*a*).
>
> No CLOCK_BOOTTIME is not affected by wall clock time changes. It's
> basically CLOCK_MONOTONIC, it just keeps counting the suspend time as
> well. So without a suspend/resume cycle CLOCK_MONOTONIC and
> CLOCK_BOOTTIME are the same. After a suspend/resume cycle
> CLOCK_BOOTTIME will be N seconds ahead of CLOCK_MONOTONIC, where N is
> the number of seconds spent in suspend.
Sorry for the ambiguity. Yes, CLOCK_BOOTTIME is monotonic *and* counting
suspend/resume time as well as not affected by wall clock time change.
Using CLOCK_BOOTTIME guarantees b- will timeout in a right manner, i.e., not
affected by wall clock time change, as well as keep the timer valid when
suspend/resume.
A classic way of using timer is:
a- Arm a timer with specified interval
b- Wait for the timer to timeout
c- After the timeout, notify the event to other place in the timer handler.
IPsec key lifetime timer does its this way:
a- Arm a timer with specified interval
b- Wait for the timer to timeout
c- After timeout, in the timer handler, using wall clock time to calculate
which kind of event to notify user(soft or hard for both key use time,
and key created time). So the problem arises at this stage if wall clock
time changed.
Thanks
> Thanks,
>
> tglx
>
--
浮沉随浪只记今朝笑
--fan
^ permalink raw reply
* [PATCH] bgmac: implement unaligned addressing for DMA rings that support it
From: Rafał Miłecki @ 2013-09-15 21:13 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: Hauke Mehrtens, Rafał Miłecki
This is important patch for new devices that support unaligned
addressing. That devices suffer from the backward-compatibility bug in
DMA engine. In theory we should be able to use old mechanism, but in
practice DMA address seems to be randomly copied into status register
when hardware reaches end of a ring. This breaks reading slot number
from status register and we can't use DMA anymore.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
---
drivers/net/ethernet/broadcom/bgmac.c | 38 ++++++++++++++++++++++++---------
drivers/net/ethernet/broadcom/bgmac.h | 2 ++
2 files changed, 30 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
index 59f3e0c..249468f 100644
--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -157,6 +157,7 @@ static netdev_tx_t bgmac_dma_tx_add(struct bgmac *bgmac,
if (++ring->end >= BGMAC_TX_RING_SLOTS)
ring->end = 0;
bgmac_write(bgmac, ring->mmio_base + BGMAC_DMA_TX_INDEX,
+ ring->index_base +
ring->end * sizeof(struct bgmac_dma_desc));
/* Always keep one slot free to allow detecting bugged calls. */
@@ -181,6 +182,8 @@ static void bgmac_dma_tx_free(struct bgmac *bgmac, struct bgmac_dma_ring *ring)
/* The last slot that hardware didn't consume yet */
empty_slot = bgmac_read(bgmac, ring->mmio_base + BGMAC_DMA_TX_STATUS);
empty_slot &= BGMAC_DMA_TX_STATDPTR;
+ empty_slot -= ring->index_base;
+ empty_slot &= BGMAC_DMA_TX_STATDPTR;
empty_slot /= sizeof(struct bgmac_dma_desc);
while (ring->start != empty_slot) {
@@ -274,6 +277,8 @@ static int bgmac_dma_rx_read(struct bgmac *bgmac, struct bgmac_dma_ring *ring,
end_slot = bgmac_read(bgmac, ring->mmio_base + BGMAC_DMA_RX_STATUS);
end_slot &= BGMAC_DMA_RX_STATDPTR;
+ end_slot -= ring->index_base;
+ end_slot &= BGMAC_DMA_RX_STATDPTR;
end_slot /= sizeof(struct bgmac_dma_desc);
ring->end = end_slot;
@@ -418,9 +423,6 @@ static int bgmac_dma_alloc(struct bgmac *bgmac)
ring = &bgmac->tx_ring[i];
ring->num_slots = BGMAC_TX_RING_SLOTS;
ring->mmio_base = ring_base[i];
- if (bgmac_dma_unaligned(bgmac, ring, BGMAC_DMA_RING_TX))
- bgmac_warn(bgmac, "TX on ring 0x%X supports unaligned addressing but this feature is not implemented\n",
- ring->mmio_base);
/* Alloc ring of descriptors */
size = ring->num_slots * sizeof(struct bgmac_dma_desc);
@@ -435,6 +437,13 @@ static int bgmac_dma_alloc(struct bgmac *bgmac)
if (ring->dma_base & 0xC0000000)
bgmac_warn(bgmac, "DMA address using 0xC0000000 bit(s), it may need translation trick\n");
+ ring->unaligned = bgmac_dma_unaligned(bgmac, ring,
+ BGMAC_DMA_RING_TX);
+ if (ring->unaligned)
+ ring->index_base = lower_32_bits(ring->dma_base);
+ else
+ ring->index_base = 0;
+
/* No need to alloc TX slots yet */
}
@@ -444,9 +453,6 @@ static int bgmac_dma_alloc(struct bgmac *bgmac)
ring = &bgmac->rx_ring[i];
ring->num_slots = BGMAC_RX_RING_SLOTS;
ring->mmio_base = ring_base[i];
- if (bgmac_dma_unaligned(bgmac, ring, BGMAC_DMA_RING_RX))
- bgmac_warn(bgmac, "RX on ring 0x%X supports unaligned addressing but this feature is not implemented\n",
- ring->mmio_base);
/* Alloc ring of descriptors */
size = ring->num_slots * sizeof(struct bgmac_dma_desc);
@@ -462,6 +468,13 @@ static int bgmac_dma_alloc(struct bgmac *bgmac)
if (ring->dma_base & 0xC0000000)
bgmac_warn(bgmac, "DMA address using 0xC0000000 bit(s), it may need translation trick\n");
+ ring->unaligned = bgmac_dma_unaligned(bgmac, ring,
+ BGMAC_DMA_RING_RX);
+ if (ring->unaligned)
+ ring->index_base = lower_32_bits(ring->dma_base);
+ else
+ ring->index_base = 0;
+
/* Alloc RX slots */
for (j = 0; j < ring->num_slots; j++) {
err = bgmac_dma_rx_skb_for_slot(bgmac, &ring->slots[j]);
@@ -489,12 +502,14 @@ static void bgmac_dma_init(struct bgmac *bgmac)
for (i = 0; i < BGMAC_MAX_TX_RINGS; i++) {
ring = &bgmac->tx_ring[i];
- /* We don't implement unaligned addressing, so enable first */
- bgmac_dma_tx_enable(bgmac, ring);
+ if (!ring->unaligned)
+ bgmac_dma_tx_enable(bgmac, ring);
bgmac_write(bgmac, ring->mmio_base + BGMAC_DMA_TX_RINGLO,
lower_32_bits(ring->dma_base));
bgmac_write(bgmac, ring->mmio_base + BGMAC_DMA_TX_RINGHI,
upper_32_bits(ring->dma_base));
+ if (ring->unaligned)
+ bgmac_dma_tx_enable(bgmac, ring);
ring->start = 0;
ring->end = 0; /* Points the slot that should *not* be read */
@@ -505,12 +520,14 @@ static void bgmac_dma_init(struct bgmac *bgmac)
ring = &bgmac->rx_ring[i];
- /* We don't implement unaligned addressing, so enable first */
- bgmac_dma_rx_enable(bgmac, ring);
+ if (!ring->unaligned)
+ bgmac_dma_rx_enable(bgmac, ring);
bgmac_write(bgmac, ring->mmio_base + BGMAC_DMA_RX_RINGLO,
lower_32_bits(ring->dma_base));
bgmac_write(bgmac, ring->mmio_base + BGMAC_DMA_RX_RINGHI,
upper_32_bits(ring->dma_base));
+ if (ring->unaligned)
+ bgmac_dma_rx_enable(bgmac, ring);
for (j = 0, dma_desc = ring->cpu_base; j < ring->num_slots;
j++, dma_desc++) {
@@ -531,6 +548,7 @@ static void bgmac_dma_init(struct bgmac *bgmac)
}
bgmac_write(bgmac, ring->mmio_base + BGMAC_DMA_RX_INDEX,
+ ring->index_base +
ring->num_slots * sizeof(struct bgmac_dma_desc));
ring->start = 0;
diff --git a/drivers/net/ethernet/broadcom/bgmac.h b/drivers/net/ethernet/broadcom/bgmac.h
index 12a35cf..66c8afb 100644
--- a/drivers/net/ethernet/broadcom/bgmac.h
+++ b/drivers/net/ethernet/broadcom/bgmac.h
@@ -384,6 +384,8 @@ struct bgmac_dma_ring {
u16 mmio_base;
struct bgmac_dma_desc *cpu_base;
dma_addr_t dma_base;
+ u32 index_base; /* Used for unaligned rings only, otherwise 0 */
+ bool unaligned;
struct bgmac_slot_info slots[BGMAC_RX_RING_SLOTS];
};
--
1.7.10.4
^ permalink raw reply related
* [PATCH V2] bgmac: allow bigger et_swtype nvram variable
From: Rafał Miłecki @ 2013-09-15 20:49 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: Hauke Mehrtens, Rafał Miłecki
In-Reply-To: <1379276748-13687-1-git-send-email-zajec5@gmail.com>
From: Hauke Mehrtens <hauke@hauke-m.de>
Without this patch it is impossible to read et_swtype, because the 1
byte space is needed for the terminating null byte. The max expected
value is 0xF, so now it should be possible to read decimal form ("15")
and hex form ("0xF").
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
---
V2: Add "From: " - sorry Hauke for the earlier mistake
---
drivers/net/ethernet/broadcom/bgmac.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
index 1c6bc96..59f3e0c 100644
--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -909,9 +909,9 @@ static void bgmac_chip_reset(struct bgmac *bgmac)
u8 et_swtype = 0;
u8 sw_type = BGMAC_CHIPCTL_1_SW_TYPE_EPHY |
BGMAC_CHIPCTL_1_IF_TYPE_MII;
- char buf[2];
+ char buf[4];
- if (bcm47xx_nvram_getenv("et_swtype", buf, 1) > 0) {
+ if (bcm47xx_nvram_getenv("et_swtype", buf, sizeof(buf)) > 0) {
if (kstrtou8(buf, 0, &et_swtype))
bgmac_err(bgmac, "Failed to parse et_swtype (%s)\n",
buf);
--
1.7.10.4
^ permalink raw reply related
* [PATCH] bgmac: allow bigger et_swtype nvram variable
From: Rafał Miłecki @ 2013-09-15 20:25 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: Rafał Miłecki, Hauke Mehrtens
Without this patch it is impossible to read et_swtype, because the 1
byte space is needed for the terminating null byte. The max expected
value is 0xF, so now it should be possible to read decimal form ("15")
and hex form ("0xF").
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
---
drivers/net/ethernet/broadcom/bgmac.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
index 1c6bc96..59f3e0c 100644
--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -909,9 +909,9 @@ static void bgmac_chip_reset(struct bgmac *bgmac)
u8 et_swtype = 0;
u8 sw_type = BGMAC_CHIPCTL_1_SW_TYPE_EPHY |
BGMAC_CHIPCTL_1_IF_TYPE_MII;
- char buf[2];
+ char buf[4];
- if (bcm47xx_nvram_getenv("et_swtype", buf, 1) > 0) {
+ if (bcm47xx_nvram_getenv("et_swtype", buf, sizeof(buf)) > 0) {
if (kstrtou8(buf, 0, &et_swtype))
bgmac_err(bgmac, "Failed to parse et_swtype (%s)\n",
buf);
--
1.7.10.4
^ permalink raw reply related
* Re: mvneta: oops in __rcu_read_lock on mirabox
From: Thomas Petazzoni @ 2013-09-15 18:57 UTC (permalink / raw)
To: Ethan Tuttle
Cc: Willy Tarreau, netdev, linux-arm-kernel, Gregory Clément,
Ezequiel Garcia, Andrew Lunn, Jason Cooper
In-Reply-To: <CACzLR4tTvt+ROEhkXUCQhV6=bPPTX4LFSkWfrEhF+OdM1Jm1Rw@mail.gmail.com>
Hello Ethan,
On Sat, 14 Sep 2013 18:05:32 -0700, Ethan Tuttle wrote:
> When I upgraded my mirabox from 3.11-rc4 to 3.11, I started seeing
> oopses while receiving network traffic (see below). Sending a flood
> ping will trigger the oops within a few minutes.
>
> The stack looks similar, but not identical to, the one reported
> earlier by Jochen De Smet[1]. In my case the PC is always
> __rcu_read_lock.
>
> A git bisect found a878764 "Merge
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net" to be the
> first bad commit... interesting, because neither of the merge parents
> produce the oops. I rebased the net changes onto the other merge
> parent and bisected that series, which identified 702821f "net: revert
> 8728c544a9c ("net: dev_pick_tx() fix")" as the first bad commit.
> Indeed, reverting 702821f from 3.11 produces a kernel which stands up
> to a ping flood for hours.
>
> Each of the times I reproduced this, it was identified as "Unhandled
> prefetch abort: unknown 25 (0x409) at 0xc0036ea0", except once when I
> got "unknown 16 (0x400)".
>
> I'm assuming this is an mvneta bug that was exposed by 702821f.
> That's just a guess, and I don't have the skills to debug this any
> further. In any case, I figured the maintainers would want to know
> about it.
Thanks a lot for the report and the detailed investigation.
Unfortunately, I don't have Armada 370 hardware with me this week, so
I'm unable to test and reproduce the issue.
However, I've added a bunch of Armada 370 people/maintainers in Cc,
hopefully they can at least try to reproduce and confirm that reverting
this patch makes the problem go away, which would confirm that we
should look for a bug in the mvneta driver around this problem.
Thanks!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: [ovs-dev] [PATCH v2.39 0/7] MPLS actions and matches
From: Simon Horman @ 2013-09-15 16:39 UTC (permalink / raw)
To: Jesse Gross
Cc: Ben Pfaff, dev@openvswitch.org, netdev, Isaku Yamahata, Ravi K
In-Reply-To: <CAEP_g=9ji2ihWrVuoUrcZswrOCz_f2SFeYBTwPzbB7p=ONCPUA@mail.gmail.com>
On Fri, Sep 13, 2013 at 03:15:17PM -0700, Jesse Gross wrote:
> On Thu, Sep 12, 2013 at 3:54 PM, Ben Pfaff <blp@nicira.com> wrote:
> > On Fri, Sep 13, 2013 at 07:56:14AM +0900, Simon Horman wrote:
> >> On Thu, Sep 12, 2013 at 12:06:36PM -0700, Ben Pfaff wrote:
> >> > I've totally lost track of the status of this patch series. I assume it
> >> > needs Jesse's review. Jesse, if I'm wrong about that, let me know and
> >> > I'll take a pass at it.
> >>
> >> My understanding is that you have looked over the approach
> >> taken for the non-datapath code and were happy with it in
> >> the context that it needed review from Jesse along with the
> >> datapath code.
> >>
> >> I believe it was a few revisions ago that you looked over
> >> the series but I don't believe the non-datapath code has changed
> >> in a meaningful way since then.
> >
> > That sounds plausible, thanks for refreshing my memory.
>
> I haven't really reviewed the userspace code but there is one thing in
> particular that concerns me: mpls_depth in the flow structure. We
> obviously can't be making flow-level decisions on information that the
> kernel doesn't include in the flow and I think that it is mostly
> vestigial at this point. However, at best the name seems misleading
> and at worst could result in someone trying to use information that we
> don't really have. Can we fix this somehow? Maybe using the BoS bit?
I believe we discussed this a long time ago.
The recirculation series includes a patch to allow multiple levels of pull
and push and that patch removes the mpls_depth field from the flow
structure. The approach taken is to track changes in the mpls depth during
translation, without knowing what the original depth was, and to
recirculate when the depth changes by more than one. So in a nutshell my
strategy was to use recirculation to resolve this problem.
However, I do entirely agree with your concerns and I don't believe that we
need mpls_depth at all even at this stage. I will take a look at removing
it by tracking the depth during translation without a dependency on
recirculation.
^ permalink raw reply
* Re: [PATCH v2.39 6/7] datapath: Break out deacceleration portion of vlan_push
From: Simon Horman @ 2013-09-15 16:32 UTC (permalink / raw)
To: Jesse Gross
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org, Ravi K, netdev,
Isaku Yamahata
In-Reply-To: <CAEP_g=_ZQ6hNpxoHm6t3N=PxA+3WTrvNegL514j0R3GDM5C92A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
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-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> 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 think that should be possible.
^ permalink raw reply
* Re: [PATCH] cxgb4: remove workqueue when driver registration fails
From: Wei Yang @ 2013-09-15 13:58 UTC (permalink / raw)
To: Wei Yang; +Cc: dm, netdev, davem
In-Reply-To: <1379253180-10292-1-git-send-email-weiyang@linux.vnet.ibm.com>
This time, I cc-ed to myself. And this applies to the latest net tree.
It looks not corrupted to me. Not sure other people can see it clearly?
On Sun, Sep 15, 2013 at 09:53:00PM +0800, Wei Yang wrote:
>When driver registration fails, we need to clean up the resources allocated
>before. cxgb4 missed to destroy the workqueue allocated at the very beginning.
>
>This patch destroies the workqueue when registration fails.
>
>Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com>
>---
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
>diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
>index 0d0665c..c73cabd 100644
>--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
>+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
>@@ -6149,8 +6149,10 @@ static int __init cxgb4_init_module(void)
> pr_warn("could not create debugfs entry, continuing\n");
>
> ret = pci_register_driver(&cxgb4_driver);
>- if (ret < 0)
>+ if (ret < 0) {
> debugfs_remove(cxgb4_debugfs_root);
>+ destroy_workqueue(workq);
>+ }
>
> register_inet6addr_notifier(&cxgb4_inet6addr_notifier);
>
>--
>1.7.1
>
>--
>To unsubscribe from this list: send the line "unsubscribe netdev" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Richard Yang
Help you, Help me
^ permalink raw reply
* [PATCH] cxgb4: remove workqueue when driver registration fails
From: Wei Yang @ 2013-09-15 13:53 UTC (permalink / raw)
To: dm, netdev; +Cc: davem, weiyang
When driver registration fails, we need to clean up the resources allocated
before. cxgb4 missed to destroy the workqueue allocated at the very beginning.
This patch destroies the workqueue when registration fails.
Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 0d0665c..c73cabd 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -6149,8 +6149,10 @@ static int __init cxgb4_init_module(void)
pr_warn("could not create debugfs entry, continuing\n");
ret = pci_register_driver(&cxgb4_driver);
- if (ret < 0)
+ if (ret < 0) {
debugfs_remove(cxgb4_debugfs_root);
+ destroy_workqueue(workq);
+ }
register_inet6addr_notifier(&cxgb4_inet6addr_notifier);
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] Do not drop DNATed 6to4/6rd packets
From: Hannes Frederic Sowa @ 2013-09-15 13:14 UTC (permalink / raw)
To: Catalin(ux) M. BOIE; +Cc: netdev, yoshfuji, davem
In-Reply-To: <1379154647-5781-1-git-send-email-catab@embedromix.ro>
On Sat, Sep 14, 2013 at 01:30:47PM +0300, Catalin(ux) M. BOIE wrote:
> From: "Catalin(ux) M. BOIE" <catab@embedromix.ro>
>
> When a router is doing DNAT for 6to4/6rd packets the latest anti-spoofing
> patch (218774dc) will drop them because the IPv6 address embedded
> does not match the IPv4 destination. This patch will allow them to
> pass by testing if we have an address that matches on 6to4/6rd interface.
> I have been hit by this problem using Fedora and IPV6TO4_IPV4ADDR.
> Also, log the dropped packets (with rate limit).
>
> Signed-off-by: Catalin(ux) M. BOIE <catab@embedromix.ro>
Pretty neat idea, I think. Could you rebase the patch ontop of net or net-next
and have a look at the warnings when you feed your patch to
./scripts/checkpatch --strict?
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH] cxgb4: remove workqueue when driver registration fails
From: Wei Yang @ 2013-09-15 12:24 UTC (permalink / raw)
To: David Miller; +Cc: weiyang, dm, netdev
In-Reply-To: <20130911.155200.1385893449933655541.davem@davemloft.net>
On Wed, Sep 11, 2013 at 03:52:00PM -0400, David Miller wrote:
>From: Wei Yang <weiyang@linux.vnet.ibm.com>
>Date: Fri, 6 Sep 2013 09:32:25 +0800
>
>> When driver registration fails, we need to clean up the resources allocated
>> before. cxgb4 missed to destroy the workqueue allocated at the very beginning.
>>
>> This patch destroies the workqueue when registration fails.
>>
>> Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com>
>
>This patch was corrupted by your email client, please email the patch
>to yourself, make sure the patch you receive in the email applies
>cleanly to the current 'net' tree, and then resubmit.
Sorry for this bothering.
I will re-do it.
Thanks.
>
>Thanks.
--
Richard Yang
Help you, Help me
^ permalink raw reply
* Re: [PATCH net-next v3] ptp: add the PTP_SYS_OFFSET ioctl to the testptp program
From: Dong Zhu @ 2013-09-15 9:25 UTC (permalink / raw)
To: Richard Cochran; +Cc: Rob Landley, netdev, linux-doc, linux-kernel
In-Reply-To: <20130915084811.GA10163@netboy>
Hi Richard,
Thanks for your comments, I modified the patch and resubmit it again:
>From 7636f69b74c34eca14c85fd2d518da6044b94f53 Mon Sep 17 00:00:00 2001
From: Dong Zhu <bluezhudong@gmail.com>
Date: Sun, 15 Sep 2013 17:12:52 +0800
This patch add a method into testptp.c to measure the time offset
between phc and system clock through the ioctl PTP_SYS_OFFSET.
Signed-off-by: Dong Zhu <bluezhudong@gmail.com>
---
Documentation/ptp/testptp.c | 40 ++++++++++++++++++++++++++++++++++++++--
1 file changed, 38 insertions(+), 2 deletions(-)
diff --git a/Documentation/ptp/testptp.c b/Documentation/ptp/testptp.c
index f59ded0..b6f6f47 100644
--- a/Documentation/ptp/testptp.c
+++ b/Documentation/ptp/testptp.c
@@ -112,6 +112,8 @@ static void usage(char *progname)
" -f val adjust the ptp clock frequency by 'val' ppb\n"
" -g get the ptp clock time\n"
" -h prints this message\n"
+ " -k val measure the time offset between phc and system clock\n"
+ " for 'val' times (Maximum 25)\n"
" -p val enable output with a period of 'val' nanoseconds\n"
" -P val enable or disable (val=1|0) the system clock PPS\n"
" -s set the ptp clock time from the system time\n"
@@ -133,8 +135,12 @@ int main(int argc, char *argv[])
struct itimerspec timeout;
struct sigevent sigevent;
+ struct ptp_clock_time *pct;
+ struct ptp_sys_offset *sysoff;
+
+
char *progname;
- int c, cnt, fd;
+ int i, c, cnt, fd;
char *device = DEVICE;
clockid_t clkid;
@@ -144,6 +150,8 @@ int main(int argc, char *argv[])
int extts = 0;
int gettime = 0;
int oneshot = 0;
+ int offset = 0;
+ int n_samples = 0;
int periodic = 0;
int perout = -1;
int pps = -1;
@@ -151,7 +159,7 @@ int main(int argc, char *argv[])
progname = strrchr(argv[0], '/');
progname = progname ? 1+progname : argv[0];
- while (EOF != (c = getopt(argc, argv, "a:A:cd:e:f:ghp:P:sSt:v"))) {
+ while (EOF != (c = getopt(argc, argv, "a:A:cd:e:f:ghk:p:P:sSt:v"))) {
switch (c) {
case 'a':
oneshot = atoi(optarg);
@@ -174,6 +182,10 @@ int main(int argc, char *argv[])
case 'g':
gettime = 1;
break;
+ case 'k':
+ offset = 1;
+ n_samples = atoi(optarg);
+ break;
case 'p':
perout = atoi(optarg);
break;
@@ -376,6 +388,30 @@ int main(int argc, char *argv[])
}
}
+ if (offset) {
+ sysoff = calloc(1, sizeof(*sysoff));
+ if (!sysoff) {
+ perror("calloc");
+ return -1;
+ }
+ sysoff->n_samples = n_samples;
+
+ if (ioctl(fd, PTP_SYS_OFFSET, sysoff))
+ perror("PTP_SYS_OFFSET");
+ else
+ puts("phc and system clock time offset request okay");
+
+ pct = &sysoff->ts[0];
+ for (i = 0; i < sysoff->n_samples; i++, pct++) {
+ printf("system time: %ld.%ld\n", pct->sec, pct->nsec);
+ pct++;
+ printf("phc time: %ld.%ld\n", pct->sec, pct->nsec);
+ }
+ printf("system time: %ld.%ld\n", pct->sec, pct->nsec);
+
+ free(sysoff);
+ }
+
close(fd);
return 0;
}
--
1.7.11.7
--
Best Regards,
Dong Zhu
^ permalink raw reply related
* Re: [PATCH] ptp: add the PTP_SYS_OFFSET ioctl to the testptp program clock
From: Richard Cochran @ 2013-09-15 8:48 UTC (permalink / raw)
To: Dong Zhu; +Cc: Rob Landley, netdev, linux-doc, linux-kernel
In-Reply-To: <20130914153952.GD23682@zhudong.nay.redhat.com>
On Sat, Sep 14, 2013 at 11:39:52PM +0800, Dong Zhu wrote:
> On Sat, Sep 14, 2013 at 04:31:46PM +0200, Richard Cochran wrote:
> > On Sat, Sep 14, 2013 at 04:03:06PM +0800, Dong Zhu wrote:
> > > This patch add a method into testptp.c to measure the time offset
> > > between phc and system clock through the ioctl PTP_SYS_OFFSET.
> > >
> >
> > This is a nice addition to the testptp program. I do have a few
> > comments, below.
> >
>
> Thanks very much for your comments, I have modified the patch as below,
> Cuold you have a look at it again ? Any comments would be appreciated.
It looks better, but could you please tweak a few more things?
> Subject: Re: [PATCH] ptp: add the PTP_SYS_OFFSET ioctl to the testptp program clock
The subject line has the word "clock" at the end by mistake.
...
> diff --git a/Documentation/ptp/testptp.c b/Documentation/ptp/testptp.c
> index f59ded0..8acdc70 100644
> --- a/Documentation/ptp/testptp.c
> +++ b/Documentation/ptp/testptp.c
> @@ -112,6 +112,8 @@ static void usage(char *progname)
> " -f val adjust the ptp clock frequency by 'val' ppb\n"
> " -g get the ptp clock time\n"
> " -h prints this message\n"
> + " -k val measure the time offset between phc and system clock "
> + "for 'val' times (Maximum 25)\n"
This line is getting a bit too long for the terminal. Please line up
the text, like this:
" -k val measure the time offset between phc and system clock\n"
" for 'val' times (Maximum 25)\n"
Also, when you resubmit the patch, add "net-next" and a patch version,
like this: [PATCH net-next v3].
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH] net, mellanox mlx4 Fix compile warnings
From: ZHAO Gang @ 2013-09-15 6:27 UTC (permalink / raw)
To: ZHAO Gang
Cc: Or Gerlitz, Prarit Bhargava, netdev@vger.kernel.org, Doug Ledford,
Amir Vadai, Or Gerlitz
In-Reply-To: <20130915062125.GA20185@will>
sorry for the inconvenince, i'm just practise the use of mutt, sorry again.
On Sun, Sep 15, 2013 at 2:22 PM, ZHAO Gang <gamerh2o@gmail.com> wrote:
> hell what!
>
> On Sun, Sep 15, 2013 at 09:14:00AM +0300, Jack Morgenstein wrote:
>> On Sat, 14 Sep 2013 22:10:19 +0300
>> Or Gerlitz <or.gerlitz@gmail.com> wrote:
>>
>> > > + struct res_cq *uninitialized_var(cq);
>> > >
>> > > err = cq_res_start_move_to(dev, slave, cqn,
>> > > RES_CQ_ALLOCATED, &cq);
>>
>> I have no objection. However, I don't know if the compiler is being too
>> clever here or too stupid. The cq variable is initialized in
>> cq_res_start_move_to(), but the compiler is ignoring this -- or maybe
>> it is simply not assuming that cq will in fact be
>> initialized by the called procedure?
>>
>> In any event, this change cannot hurt.
>>
>> -Jack
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net, mellanox mlx4 Fix compile warnings
From: ZHAO Gang @ 2013-09-15 6:22 UTC (permalink / raw)
To: gamerh2o
Cc: Or Gerlitz, Prarit Bhargava, netdev@vger.kernel.org, Doug Ledford,
Amir Vadai, Or Gerlitz
In-Reply-To: <20130915091400.49f90bc4@jpm-OptiPlex-GX620>
hell what!
On Sun, Sep 15, 2013 at 09:14:00AM +0300, Jack Morgenstein wrote:
> On Sat, 14 Sep 2013 22:10:19 +0300
> Or Gerlitz <or.gerlitz@gmail.com> wrote:
>
> > > + struct res_cq *uninitialized_var(cq);
> > >
> > > err = cq_res_start_move_to(dev, slave, cqn,
> > > RES_CQ_ALLOCATED, &cq);
>
> I have no objection. However, I don't know if the compiler is being too
> clever here or too stupid. The cq variable is initialized in
> cq_res_start_move_to(), but the compiler is ignoring this -- or maybe
> it is simply not assuming that cq will in fact be
> initialized by the called procedure?
>
> In any event, this change cannot hurt.
>
> -Jack
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net, mellanox mlx4 Fix compile warnings
From: Jack Morgenstein @ 2013-09-15 6:14 UTC (permalink / raw)
To: Or Gerlitz
Cc: Prarit Bhargava, netdev@vger.kernel.org, Doug Ledford, Amir Vadai,
Or Gerlitz
In-Reply-To: <CAJZOPZLt8G8MsPxiRNySex=izThR74bXcnWTmWB2wjPys09_ig@mail.gmail.com>
On Sat, 14 Sep 2013 22:10:19 +0300
Or Gerlitz <or.gerlitz@gmail.com> wrote:
> > + struct res_cq *uninitialized_var(cq);
> >
> > err = cq_res_start_move_to(dev, slave, cqn,
> > RES_CQ_ALLOCATED, &cq);
I have no objection. However, I don't know if the compiler is being too
clever here or too stupid. The cq variable is initialized in
cq_res_start_move_to(), but the compiler is ignoring this -- or maybe
it is simply not assuming that cq will in fact be
initialized by the called procedure?
In any event, this change cannot hurt.
-Jack
^ permalink raw reply
* Re: [PATCH net 2/3] lib: introduce upper case hex ascii helpers
From: Andrew Morton @ 2013-09-15 4:35 UTC (permalink / raw)
To: Thiago Farina
Cc: 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: <CACnwZYdBocYEjASpKCNZ6cfLNpzxeLxaVjLCHwxwsYO+P14tAQ@mail.gmail.com>
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.
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.
^ permalink raw reply
* Re: [PATCH net 2/3] lib: introduce upper case hex ascii helpers
From: Thiago Farina @ 2013-09-15 4:27 UTC (permalink / raw)
To: Andre Naujoks
Cc: David S. Miller, Andrew Morton, Steven Rostedt, Rusty Russell,
Arnd Bergmann, Michael S. Tsirkin, Vladimir Kondratiev,
Jason Baron, Greg Kroah-Hartman, linux list, linux-can, netdev
In-Reply-To: <1379093833-4949-3-git-send-email-nautsch2@gmail.com>
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?
--
Thiago Farina
^ permalink raw reply
* mvneta: oops in __rcu_read_lock on mirabox
From: Ethan Tuttle @ 2013-09-15 1:05 UTC (permalink / raw)
To: Thomas Petazzoni, Willy Tarreau, netdev, linux-arm-kernel
When I upgraded my mirabox from 3.11-rc4 to 3.11, I started seeing
oopses while receiving network traffic (see below). Sending a flood
ping will trigger the oops within a few minutes.
The stack looks similar, but not identical to, the one reported
earlier by Jochen De Smet[1]. In my case the PC is always
__rcu_read_lock.
A git bisect found a878764 "Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net" to be the
first bad commit... interesting, because neither of the merge parents
produce the oops. I rebased the net changes onto the other merge
parent and bisected that series, which identified 702821f "net: revert
8728c544a9c ("net: dev_pick_tx() fix")" as the first bad commit.
Indeed, reverting 702821f from 3.11 produces a kernel which stands up
to a ping flood for hours.
Each of the times I reproduced this, it was identified as "Unhandled
prefetch abort: unknown 25 (0x409) at 0xc0036ea0", except once when I
got "unknown 16 (0x400)".
I'm assuming this is an mvneta bug that was exposed by 702821f.
That's just a guess, and I don't have the skills to debug this any
further. In any case, I figured the maintainers would want to know
about it.
Thanks much,
Ethan
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-September/196332.html
Unhandled prefetch abort: unknown 25 (0x409) at 0xc0036ea0
Internal error: : 409 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.11.0-ARCH-00005-gecca798 #31
task: c074b140 ti: c0740000 task.ti: c0740000
PC is at __rcu_read_lock+0x1c/0x20
LR is at __netif_receive_skb_core+0x80/0x6fc
pc : [<c0036ea0>] lr : [<c04528d4>] psr: 60000113
sp : c0741de8 ip : 5232ad87 fp : ef181800
r10: c073ede4 r9 : c07494b8 r8 : ef181800
r7 : 00000000 r6 : 00000001 r5 : ee972b40 r4 : ee972b40
r3 : c074b140 r2 : 00000001 r1 : 00000042 r0 : 0000ffff
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c5387d Table: 2e8cc019 DAC: 00000015
Process swapper/0 (pid: 0, stack limit = 0xc0740240)
Stack: (0xc0741de8 to 0xc0742000)
1de0: 00000000 c0741e28 ee972b40 ee972b40 ef300c00 00000067
1e00: f014f000 ee972b40 ee972b40 ee972b40 ef300c00 00000067 f014f000 00000000
1e20: ef181800 c0455a70 b685321e 13236156 ee972b40 ee972b40 ef300c00 00000067
1e40: f014f000 00000003 ee972b40 c04562a8 00000000 ef181c80 f014fce0 c03bd688
1e60: 00000000 00000000 ef181ccc 00000001 00000001 00000001 c077e190 00000040
1e80: 00000100 00000000 ef181800 ef181c80 ef300c00 00000000 ef181ccc c03bd860
1ea0: 00000001 c076ebf8 c03bd7b0 ef181ccc c1363dc0 00000001 0000012c c1363dc8
1ec0: 00000040 c077d773 c07420c0 c0456018 c074208c 000044fe 0000000c 00000001
1ee0: c0742090 c0740000 0000000a 3f8bdf7c 00000000 00200000 00000101 c0024368
1f00: c077e190 c001bc60 00000000 0000000c 00000003 000044fd c02f91ac 00000017
1f20: 00000000 c0741f78 000003ff c07484c0 561f5811 00000000 00000000 c0024768
1f40: 00000017 c000e6c0 f0002870 c00579e4 c07a4440 c000851c c00579e4 60000013
1f60: ffffffff c0741fac c135f4c0 561f5811 00000000 c00118c0 c13629b0 00000000
1f80: 00000000 00000000 c0740000 c077dd00 c055cc88 c0735450 c135f4c0 561f5811
1fa0: 00000000 00000000 00000002 c0741fc0 c000e980 c00579e4 60000013 ffffffff
1fc0: c0740000 c0711a38 ffffffff ffffffff c0711544 00000000 00000000 c0735450
1fe0: 10c5387d c07484fc c073544c c074c290 00004059 00008074 00000000 00000000
[<c0036ea0>] (__rcu_read_lock+0x1c/0x20) from [<c04528d4>]
(__netif_receive_skb_core+0x80/0x6fc)
[<c04528d4>] (__netif_receive_skb_core+0x80/0x6fc) from [<c0455a70>]
(netif_receive_skb+0x60/0xb8)
[<c0455a70>] (netif_receive_skb+0x60/0xb8) from [<c04562a8>]
(napi_gro_receive+0x48/0x98)
[<c04562a8>] (napi_gro_receive+0x48/0x98) from [<c03bd688>]
(mvneta_rx+0x244/0x36c)
[<c03bd688>] (mvneta_rx+0x244/0x36c) from [<c03bd860>] (mvneta_poll+0xb0/0x15c)
[<c03bd860>] (mvneta_poll+0xb0/0x15c) from [<c0456018>]
(net_rx_action+0x70/0x170)
[<c0456018>] (net_rx_action+0x70/0x170) from [<c0024368>]
(__do_softirq+0xd4/0x1c8)
[<c0024368>] (__do_softirq+0xd4/0x1c8) from [<c0024768>] (irq_exit+0x74/0x88)
[<c0024768>] (irq_exit+0x74/0x88) from [<c000e6c0>] (handle_IRQ+0x68/0x8c)
[<c000e6c0>] (handle_IRQ+0x68/0x8c) from [<c000851c>]
(armada_370_xp_handle_irq+0x44/0xa4)
[<c000851c>] (armada_370_xp_handle_irq+0x44/0xa4) from [<c00118c0>]
(__irq_svc+0x40/0x70)
Exception stack(0xc0741f78 to 0xc0741fc0)
1f60: c13629b0 00000000
1f80: 00000000 00000000 c0740000 c077dd00 c055cc88 c0735450 c135f4c0 561f5811
1fa0: 00000000 00000000 00000002 c0741fc0 c000e980 c00579e4 60000013 ffffffff
[<c00118c0>] (__irq_svc+0x40/0x70) from [<c00579e4>]
(cpu_startup_entry+0xb0/0x114)
[<c00579e4>] (cpu_startup_entry+0xb0/0x114) from [<c0711a38>]
(start_kernel+0x2c8/0x324)
Code: e593300c e59321b4 e2822001 e58321b4 (e12fff1e)
---[ end trace 8f21018165664a9e ]---
Kernel panic - not syncing: Fatal exception in interrupt
^ permalink raw reply
* Re: [patch 2/4] mISDN: add support for group membership check
From: Ben Hutchings @ 2013-09-14 23:28 UTC (permalink / raw)
To: akpm, jeffm; +Cc: davem, netdev, isdn4linux, isdn, jslaby, sergei.shtylyov
In-Reply-To: <20130913215202.7D16C31C1BF@corp2gmr1-1.hot.corp.google.com>
[-- Attachment #1: Type: text/plain, Size: 2113 bytes --]
On Fri, 2013-09-13 at 14:52 -0700, akpm@linux-foundation.org wrote:
> From: Jeff Mahoney <jeffm@suse.com>
> Subject: mISDN: add support for group membership check
>
> This patch adds a module parameter to allow a group access to the mISDN
> devices.
This doesn't just 'add support' or 'allow a group access'. It also
changes the default behaviour.
[...]
> --- a/drivers/isdn/mISDN/core.c~misdn-add-support-for-group-membership-check
> +++ a/drivers/isdn/mISDN/core.c
> @@ -21,10 +21,14 @@
> #include "core.h"
>
> static u_int debug;
> +static u_int gid;
> +kgid_t misdn_permitted_gid;
>
> MODULE_AUTHOR("Karsten Keil");
> MODULE_LICENSE("GPL");
> module_param(debug, uint, S_IRUGO | S_IWUSR);
> +module_param(gid, uint, 0);
So you can't change the privileged gid after loading, or even see what
it is.
[...]
> --- a/drivers/isdn/mISDN/socket.c~misdn-add-support-for-group-membership-check
> +++ a/drivers/isdn/mISDN/socket.c
> @@ -612,6 +612,11 @@ data_sock_create(struct net *net, struct
> {
> struct sock *sk;
>
> + if (!capable(CAP_SYS_ADMIN) &&
> + !gid_eq(misdn_permitted_gid, current_gid()) &&
> + !in_group_p(misdn_permitted_gid))
> + return -EPERM;
> +
> if (sock->type != SOCK_DGRAM)
> return -ESOCKTNOSUPPORT;
>
I'm pretty sure you could restrict this with LSMs, in a much more
flexible way.
> @@ -694,6 +699,10 @@ base_sock_ioctl(struct socket *sock, uns
> case IMSETDEVNAME:
> {
> struct mISDN_devrename dn;
> + if (!capable(CAP_SYS_ADMIN) &&
> + !gid_eq(misdn_permitted_gid, current_gid()) &&
> + !in_group_p(misdn_permitted_gid))
> + return -EPERM;
> if (copy_from_user(&dn, (void __user *)arg,
> sizeof(dn))) {
> err = -EFAULT;
This seems to be the important bit: renaming of devices (if allowed at
all) ought to be limited to CAP_SYS_ADMIN or possibly CAP_NET_ADMIN.
But why should the group that is allowed to use mISDN data sockets also
be allowed to do this?
Ben.
--
Ben Hutchings
In a hierarchy, every employee tends to rise to his level of incompetence.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* [PATCH] bgmac: fix internal switch initialization
From: Rafał Miłecki @ 2013-09-14 22:22 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: Hauke Mehrtens, Rafał Miłecki, stable
Some devices (BCM4749, BCM5357, BCM53572) have internal switch that
requires initialization. We already have code for this, but because
of the typo in code it was never working. This resulted in network not
working for some routers and possibility of soft-bricking them.
Use correct bit for switch initialization and fix typo in the define.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Cc: stable@vger.kernel.org
---
drivers/net/ethernet/broadcom/bgmac.c | 2 +-
drivers/net/ethernet/broadcom/bgmac.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
index eec0af4..1c6bc96 100644
--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -908,7 +908,7 @@ static void bgmac_chip_reset(struct bgmac *bgmac)
struct bcma_drv_cc *cc = &bgmac->core->bus->drv_cc;
u8 et_swtype = 0;
u8 sw_type = BGMAC_CHIPCTL_1_SW_TYPE_EPHY |
- BGMAC_CHIPCTL_1_IF_TYPE_RMII;
+ BGMAC_CHIPCTL_1_IF_TYPE_MII;
char buf[2];
if (bcm47xx_nvram_getenv("et_swtype", buf, 1) > 0) {
diff --git a/drivers/net/ethernet/broadcom/bgmac.h b/drivers/net/ethernet/broadcom/bgmac.h
index 98d4b5f..12a35cf 100644
--- a/drivers/net/ethernet/broadcom/bgmac.h
+++ b/drivers/net/ethernet/broadcom/bgmac.h
@@ -333,7 +333,7 @@
#define BGMAC_CHIPCTL_1_IF_TYPE_MASK 0x00000030
#define BGMAC_CHIPCTL_1_IF_TYPE_RMII 0x00000000
-#define BGMAC_CHIPCTL_1_IF_TYPE_MI 0x00000010
+#define BGMAC_CHIPCTL_1_IF_TYPE_MII 0x00000010
#define BGMAC_CHIPCTL_1_IF_TYPE_RGMII 0x00000020
#define BGMAC_CHIPCTL_1_SW_TYPE_MASK 0x000000C0
#define BGMAC_CHIPCTL_1_SW_TYPE_EPHY 0x00000000
--
1.7.10.4
^ permalink raw reply related
* Re: [RFC PATCH 2/4] net: Add lower dev list helpers
From: Veaceslav Falico @ 2013-09-14 21:14 UTC (permalink / raw)
To: John Fastabend
Cc: stephen, bhutchings, ogerlitz, john.ronciak, netdev,
shannon.nelson
In-Reply-To: <5234CA5D.5020603@gmail.com>
On Sat, Sep 14, 2013 at 01:43:09PM -0700, John Fastabend wrote:
>On 09/14/2013 05:27 AM, Veaceslav Falico wrote:
>>On Wed, Sep 11, 2013 at 11:46:49AM -0700, John Fastabend wrote:
>>>This patch adds helpers to traverse the lower dev lists, these
>>>helpers match the upper dev list implementation.
>>>
>>>VSI implementers may use these to track a list of connected netdevs.
>>>This is easier then having drivers do their own accounting.
>>
>>Just as a note (as I have quite no idea how ixgbe works) - you are aware
>>that the upper/lower lists currently include *all* upper/lower devices, and
>>not only the first-connected ones?
>
>Yep, the netif_is_vsi_port() should hopefully catch all the cases.
>
>>
>>I've seen that you usually verify it, however not always, just a heads-up -
>>sorry if misread.
>
>I'll audit it again, maybe I missed a case.
It was about lower devices, and I think I've just really misread it -
indeed they can be only 'your' devices.
>
>>
>>I'm also currently trying to get the new patchset included - which would
>>split the first-tier connected devices from all the 'other' (as in - lower
>>of a lower and upper of an upper) devices, so that way, I think, it would
>>be easier/faster for you to use it. It also has a ->private field, easily
>>accessible, which you could have used instead of/in conjunction with/for
>>struct ixgbe_vsi_adapter.
>
>Yeah I saw the patch set I'll use the improved lists once I see the
>series gets applied. Although in my case the list walking only occurs in
>the configuration path so its not critical.
>
>Also the net device structure already has private space to hang the
>device dependent structure off of, so I'm not sure having another
>private field helps here.
Yep, it should/can be used when linking devices which might already be
using their private space for their own structures, which is not your case,
I suppose.
>
>Thanks,
>John
>
>--
>John Fastabend Intel Corporation
^ 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