* Re: RFC: mac802154 Packet Queueing and Slave Devices
From: Alan Ott @ 2013-03-22 5:33 UTC (permalink / raw)
To: Alexander Smirnov, Dmitry Eremin-Solenikov, Tony Cheneau
Cc: linux-zigbee-devel, netdev, Eric Dumazet
In-Reply-To: <514B30BC.4040802@signal11.us>
On 03/21/2013 12:09 PM, Alan Ott wrote:
> On 09/09/2012 08:43 PM, Alan Ott wrote:
>> Tony and I were recently talking about packet queueing on 802.15.4. What
>> currently happens (in net/mac802154/tx.c) is that each tx packet (skb)
>> is stuck on a work queue, and the worker function then sends each packet
>> to the hardware driver in order.
>>
>> The problem with this is that it defeats the netif flow control. The
>> networking layer thinks the packet is sent as soon as it's put on the
>> workqueue (because the function that queues it returns NETDEV_TX_OK to
>> the networking layer), and the workqueue can then get arbitrarily large
>> if an application tries to send a lot of data. (Tony has shown this with
>> iperf)
>>
> So I tried fixing this using netif_stop_queue() and netif_wake_queue(),
> the standard way. The flow control works, but I'm now losing packets.
>
> It happens like this:
>
> ipv6 -> 6lowpan -> net core -> mac802154 -> hardware
> single packet fragment netif_stop_queue()
> fragment
> fragment
> fragment
>
> Above: a single ipv6 packet is split into fragments by 6lowpan. Each
> fragment is sent through the networking core where it ends up in
> mac802154, which will call netif_stop_queue() and netif_wake_queue()
> for flow control as packets are sent.
>
>
> The problem is that since many ieee802154 hardware devices can only hold
> one packet at a time in their tx buffer, netif_stop_queue() gets called
> after the first fragment. Since the 6lowpan code is trying to, in the
> above case, send 4 packets, the remaining 3 will get dropped when
> they're handed to the networking core (dev_queue_xmit()) when the queue
> is stopped.
>
> So as a solution, one could envision 6lowpan putting the fragments into
> a queue, and submitting one at a time, as the queue gets woken. The
> problem with this is that there's no way to get notification for when a
> queue is woken. I checked both ppp and ax25 (which would seem to have
> this same issue), and they both have a fragment queue, but they rely on
> external events (mostly unrelated to the queue being woken) to trigger
> sending packets from the queue (see calls to ax25_kick()). That seems
> hacky at best.
>
> A thread from pppoe[1] talks about what's a similar issue. The patch
> from that email was never merged. Even so, their solution seems a bit
> hacky too (because it would basically cause a kick to (in this case)
> 6lowpan, whenever an skb gets destroyed (ie: after it's sent). With the
> desire for 6lowpan to be a generic protocol[2], one would want it to be
> efficient on MAC layers which do support longer queues[3].
>
> What am I missing here? What's the right way to do this?
>
> Alan.
>
> [1] http://thread.gmane.org/gmane.linux.network/233089
> [2] There has been some discussion about using 6lowpan on Bluetooth
> low-energy.
> [3] There's also the case where 2 6lowpan instances are on attached to
> the same hardware, or where 6lowpan and raw are being used concurrently.
I guess the more condensed question is, as a protocol which generates
fragments, what's the right way to handle queue management from the device?
Alan.
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: increase inner ip id during encapsulated tso
From: Eric Dumazet @ 2013-03-22 4:34 UTC (permalink / raw)
To: Dmitry Kravkov
Cc: davem, netdev, Eilon Greenstein, Ariel Elior, Maciej Zenczykowski,
Jesse Gross
In-Reply-To: <1363916305-15690-1-git-send-email-dmitry@broadcom.com>
On Fri, 2013-03-22 at 03:38 +0200, Dmitry Kravkov wrote:
> 57712/578xx devices during handling of encapsulated TSO can
> properly increase ip id for only one ip header.
> The patch selects inner header to be increased.
>
> Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
> CC: Eilon Greenstein <eilong@broadcom.com>
> CC: Ariel Elior <ariele@broadcom.com>
> CC: Maciej Zenczykowski <maze@google.com>
> CC: Jesse Gross <jesse@nicira.com>
> ---
> tested over 1bc277f79
> ---
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 22 ++++++++++------------
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 1 +
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c | 2 ++
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.h | 3 ++-
> 4 files changed, 15 insertions(+), 13 deletions(-)
Fine, GRO is back
Reported-by: Eric Dumazet <edumazet@google.com>
Tested-by: Eric Dumazet <edumazet@google.com>
Thanks !
^ permalink raw reply
* Re: [PATCH 2/2] thermal: shorten too long mcast group name
From: Masatake YAMATO @ 2013-03-22 3:43 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-acpi
In-Reply-To: <20130321.105324.1538473102849136394.davem@davemloft.net>
Sorry for cross posting to netdev and linux-acpi.
I submitted almost same patch about thermal subsystem both netdev list
and then linux-acpi list.
http://marc.info/?l=linux-netdev&m=136371412725264&w=2
http://marc.info/?l=linux-acpi&m=136386050309109&w=2
After submitting to linux-acpi list, I noticed the patch
is merged to a tree davem maintained.
What I should do?
The submitted pathes are bit different.
In netdev, I proposed changing "thermal_mc_group" to
"thermal_mc_grp". In linux-acpi I proposed changing
"thermal_mc_group" to "thermal_mc_grou".
"thermal_mc_grp" is easier to read. However, when thinking
about compatibility, "thermal_mc_grou" is better.
I've already submitted another patch for genl command which
truncates the C string returned from kernel.
http://marc.info/?l=linux-netdev&m=136371412625262&w=2
Consider a situation(A); using old kernel(without my patch submitted for linux-acpi)
and new genl command (with my patch for genl). You will get
thermal_mc_grou
as output.
Consider anther situation(B); using new kernel(with my patch submitted for
linux-acpi) and old genl command (without my patch for genl). You will get
thermal_mc_grou
as output. In both situations(A and B) users can get the same output.
If you choose "thermal_mc_grp", users may see "thermal_mc_grp" or
"thermal_mc_grou".
>>> From: Masatake YAMATO <yamato@redhat.com>
>>> Date: Tue, 19 Mar 2013 20:47:28 +0900
>>>
>>>> The original name is too long.
>>>>
>>>> Signed-off-by: Masatake YAMATO <yamato@redhat.com>
>>>
>>> This change needs to go in via the Thermal driver maintainers.
>>
>> Thanks. I've submitted the patch to linux-acpi ML.
>
> I already applied the patch to my tree, didn't you read
> the rest of this thread?
I read but I didn't understand the meaning of applying because
I cannot find my 2nd patch for thermal in net-next tree when I
pulled.
What I should do? Should I withdraw the patch submitted to
linux-acpi?
However, I slight modified the patch when I submitted it to
linux-acpi.
> And in the future, order your patches such that you fix the bug before
> adding the assertion.
Sorry. I'll do so next time.
Masatake YAMATO
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: increase inner ip id during encapsulated tso
From: Eric Dumazet @ 2013-03-22 3:38 UTC (permalink / raw)
To: Dmitry Kravkov
Cc: davem, netdev, Eilon Greenstein, Ariel Elior, Maciej Zenczykowski,
Jesse Gross
In-Reply-To: <1363916305-15690-1-git-send-email-dmitry@broadcom.com>
On Fri, 2013-03-22 at 03:38 +0200, Dmitry Kravkov wrote:
> 57712/578xx devices during handling of encapsulated TSO can
> properly increase ip id for only one ip header.
> The patch selects inner header to be increased.
>
> Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
> CC: Eilon Greenstein <eilong@broadcom.com>
> CC: Ariel Elior <ariele@broadcom.com>
> CC: Maciej Zenczykowski <maze@google.com>
> CC: Jesse Gross <jesse@nicira.com>
> ---
Thanks for CC me :(
I'll test this in the following hour, thanks!
^ permalink raw reply
* Re: [PATCH] net: Fix tentative IPv6 address due to DAD looping back
From: YOSHIFUJI Hideaki @ 2013-03-22 3:39 UTC (permalink / raw)
To: Meng, Jilin
Cc: davem@davemloft.net, kuznet@ms2.inr.ac.ru, jmorris@namei.org,
kaber@trash.net, Sun, Yinglin, Prithviraj, Lakshmanan,
netdev@vger.kernel.org
In-Reply-To: <D6EA916C7149064CB4D5C686612478A3183E2D27D1@MX34A.corp.emc.com>
Meng, Jilin wrote:
> we should ignore the looped-back IPv6 DAD packet to avoid configuration failure.
> This occurs when a bonding interface with roundrobin mode is being configured an IPv6 address
> while the switch side isn't configured bonding/channel yet.
>
> Signed-off-by: Jilin Meng <jilin.meng@emc.com>
> Signed-off-by: Yinglin Sun <yinglin.sun@emc.com>
> Signed-off-by: Lakshmanan Prithviraj <lakshmanan.prithviraj@emc.com>
> ---
> --- linux/net/ipv6/ndisc.c.orig 2013-03-12 17:16:18.000000000 +0800
> +++ linux/net/ipv6/ndisc.c 2013-03-21 10:37:06.000000000 +0800
> @@ -757,6 +757,24 @@ static void ndisc_recv_ns(struct sk_buff
>
> if (ifp->flags & (IFA_F_TENTATIVE|IFA_F_OPTIMISTIC)) {
> if (dad) {
> + if (dev->type == ARPHRD_ETHER) {
> + const unsigned char *sadr;
> + sadr = skb_mac_header(skb);
> + if (sadr[6] == dev->dev_addr[0] &&
> + sadr[7] == dev->dev_addr[1] &&
> + sadr[8] == dev->dev_addr[2] &&
> + sadr[9] == dev->dev_addr[3] &&
> + sadr[10] == dev->dev_addr[4] &&
> + sadr[11] == dev->dev_addr[5]) {
> + /*
> + * looped-back to us. This occurs when
> + * a bonding interface with roundrobin
> + * mode is being configured while the
> + * switch side isn't configured yet.
> + */
> + goto out;
> + }
> +
> /*
> * We are colliding with another node
> * who is doing DAD
I would say that it is a configuration error.
--yoshfuji
^ permalink raw reply
* [PATCH] tcp: preserve ACK clocking in TSO
From: Eric Dumazet @ 2013-03-22 3:36 UTC (permalink / raw)
To: David Miller
Cc: netdev, Yuchung Cheng, Neal Cardwell, Nandita Dukkipati,
Van Jacobson
From: Eric Dumazet <edumazet@google.com>
A long standing problem with TSO is the fact that tcp_tso_should_defer()
rearms the deferred timer, while it should not.
Current code leads to following bad bursty behavior :
20:11:24.484333 IP A > B: . 297161:316921(19760) ack 1 win 119
20:11:24.484337 IP B > A: . ack 263721 win 1117
20:11:24.485086 IP B > A: . ack 265241 win 1117
20:11:24.485925 IP B > A: . ack 266761 win 1117
20:11:24.486759 IP B > A: . ack 268281 win 1117
20:11:24.487594 IP B > A: . ack 269801 win 1117
20:11:24.488430 IP B > A: . ack 271321 win 1117
20:11:24.489267 IP B > A: . ack 272841 win 1117
20:11:24.490104 IP B > A: . ack 274361 win 1117
20:11:24.490939 IP B > A: . ack 275881 win 1117
20:11:24.491775 IP B > A: . ack 277401 win 1117
20:11:24.491784 IP A > B: . 316921:332881(15960) ack 1 win 119
20:11:24.492620 IP B > A: . ack 278921 win 1117
20:11:24.493448 IP B > A: . ack 280441 win 1117
20:11:24.494286 IP B > A: . ack 281961 win 1117
20:11:24.495122 IP B > A: . ack 283481 win 1117
20:11:24.495958 IP B > A: . ack 285001 win 1117
20:11:24.496791 IP B > A: . ack 286521 win 1117
20:11:24.497628 IP B > A: . ack 288041 win 1117
20:11:24.498459 IP B > A: . ack 289561 win 1117
20:11:24.499296 IP B > A: . ack 291081 win 1117
20:11:24.500133 IP B > A: . ack 292601 win 1117
20:11:24.500970 IP B > A: . ack 294121 win 1117
20:11:24.501388 IP B > A: . ack 295641 win 1117
20:11:24.501398 IP A > B: . 332881:351881(19000) ack 1 win 119
While the expected behavior is more like :
20:19:49.259620 IP A > B: . 197601:202161(4560) ack 1 win 119
20:19:49.260446 IP B > A: . ack 154281 win 1212
20:19:49.261282 IP B > A: . ack 155801 win 1212
20:19:49.262125 IP B > A: . ack 157321 win 1212
20:19:49.262136 IP A > B: . 202161:206721(4560) ack 1 win 119
20:19:49.262958 IP B > A: . ack 158841 win 1212
20:19:49.263795 IP B > A: . ack 160361 win 1212
20:19:49.264628 IP B > A: . ack 161881 win 1212
20:19:49.264637 IP A > B: . 206721:211281(4560) ack 1 win 119
20:19:49.265465 IP B > A: . ack 163401 win 1212
20:19:49.265886 IP B > A: . ack 164921 win 1212
20:19:49.266722 IP B > A: . ack 166441 win 1212
20:19:49.266732 IP A > B: . 211281:215841(4560) ack 1 win 119
20:19:49.267559 IP B > A: . ack 167961 win 1212
20:19:49.268394 IP B > A: . ack 169481 win 1212
20:19:49.269232 IP B > A: . ack 171001 win 1212
20:19:49.269241 IP A > B: . 215841:221161(5320) ack 1 win 119
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Cc: Van Jacobson <vanj@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Nandita Dukkipati <nanditad@google.com>
---
net/ipv4/tcp_output.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 817fbb3..5d0b438 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1809,8 +1809,11 @@ static bool tcp_tso_should_defer(struct sock *sk, struct sk_buff *skb)
goto send_now;
}
- /* Ok, it looks like it is advisable to defer. */
- tp->tso_deferred = 1 | (jiffies << 1);
+ /* Ok, it looks like it is advisable to defer.
+ * Do not rearm the timer if already set to not break TCP ACK clocking.
+ */
+ if (!tp->tso_deferred)
+ tp->tso_deferred = 1 | (jiffies << 1);
return true;
^ permalink raw reply related
* Re: [git pull] firewire net: resource management improvements
From: YOSHIFUJI Hideaki @ 2013-03-22 3:34 UTC (permalink / raw)
To: David Miller; +Cc: Stefan Richter, linux1394-devel, netdev, yoshfuji
In-Reply-To: <20130313163742.73a3a842@stein>
Dave,
would you consider pulling this one to net-next, please?
I can prepare rebased tree, if you want.
Thanks.
--yoshfuji
Stefan Richter wrote:
> David,
>
> please pull from the tag "firewire-net-resource-mgt" at
>
> git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394.git firewire-net-resource-mgt
>
> to receive the following firewire-net driver changes:
> - fix memory leak and kmap leak at shutdown
> - release IR DMA context already at ifdown rather than shutdown
> (many controllers have got only 4 of them, so let's not hold it
> longer than strictly necessary)
> - misc startup/shutdown changes which prepare for later addition
> of IPv6-over-1394 support
>
> YOSHIFUJI Hideaki (11):
> firewire net: No need to reset dev->local_fifo after failure of fw_core_add_address_handler().
> firewire net: Introduce fwnet_fifo_{start, stop}() helpers.
> firewire net: Setup broadcast and local fifo independently.
> firewire net: Check dev->broadcast_state inside fwnet_broadcast_start().
> firewire net: Fix memory leakage in fwnet_remove().
> firewire net: Clear dev->broadcast_rcv_context and dev->broadcast_state after destruction of context.
> firewire net: Omit checking dev->broadcast_rcv_context in fwnet_broadcast_start().
> firewire net: Fix leakage of kmap for broadcast receive buffer.
> firewire net: Allocate dev->broadcast_rcv_buffer_ptrs early.
> firewire net: Introduce fwnet_broadcast_stop() to destroy broadcast resources.
> firewire net: Release broadcast/fifo resources on ifdown.
>
> drivers/firewire/net.c | 177 +++++++++++++++++++--------------
> 1 file changed, 105 insertions(+), 72 deletions(-)
>
> Thanks,
^ permalink raw reply
* [PATCH] net: Fix tentative IPv6 address due to DAD looping back
From: Meng, Jilin @ 2013-03-22 3:20 UTC (permalink / raw)
To: davem@davemloft.net, kuznet@ms2.inr.ac.ru, jmorris@namei.org,
yoshfuji@linux-ipv6.org, kaber@trash.net
Cc: Sun, Yinglin, Prithviraj, Lakshmanan, netdev@vger.kernel.org
we should ignore the looped-back IPv6 DAD packet to avoid configuration failure.
This occurs when a bonding interface with roundrobin mode is being configured an IPv6 address
while the switch side isn't configured bonding/channel yet.
Signed-off-by: Jilin Meng <jilin.meng@emc.com>
Signed-off-by: Yinglin Sun <yinglin.sun@emc.com>
Signed-off-by: Lakshmanan Prithviraj <lakshmanan.prithviraj@emc.com>
---
--- linux/net/ipv6/ndisc.c.orig 2013-03-12 17:16:18.000000000 +0800
+++ linux/net/ipv6/ndisc.c 2013-03-21 10:37:06.000000000 +0800
@@ -757,6 +757,24 @@ static void ndisc_recv_ns(struct sk_buff
if (ifp->flags & (IFA_F_TENTATIVE|IFA_F_OPTIMISTIC)) {
if (dad) {
+ if (dev->type == ARPHRD_ETHER) {
+ const unsigned char *sadr;
+ sadr = skb_mac_header(skb);
+ if (sadr[6] == dev->dev_addr[0] &&
+ sadr[7] == dev->dev_addr[1] &&
+ sadr[8] == dev->dev_addr[2] &&
+ sadr[9] == dev->dev_addr[3] &&
+ sadr[10] == dev->dev_addr[4] &&
+ sadr[11] == dev->dev_addr[5]) {
+ /*
+ * looped-back to us. This occurs when
+ * a bonding interface with roundrobin
+ * mode is being configured while the
+ * switch side isn't configured yet.
+ */
+ goto out;
+ }
+
/*
* We are colliding with another node
* who is doing DAD
^ permalink raw reply
* Re: virtio: remove obsolete virtqueue_get_queue_index()
From: Rusty Russell @ 2013-03-22 0:17 UTC (permalink / raw)
To: Cornelia Huck; +Cc: mst, netdev
In-Reply-To: <20130321100146.7a741c75@gondolin>
Cornelia Huck <cornelia.huck@de.ibm.com> writes:
> On Thu, 21 Mar 2013 17:47:03 +1030
> Rusty Russell <rusty@rustcorp.com.au> wrote:
>
>> You can access it directly now, since 3.8: v3.7-rc1-13-g06ca287
>> 'virtio: move queue_index and num_free fields into core struct
>> virtqueue.'
>>
>> Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
>> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
...
>> @@ -610,7 +610,7 @@ static struct virtqueue *virtio_ccw_vq_by_ind(struct virtio_ccw_device *vcdev,
>> vq = NULL;
>> spin_lock_irqsave(&vcdev->lock, flags);
>> list_for_each_entry(info, &vcdev->virtqueues, node) {
>> - if (virtqueue_get_queue_index(info->vq) == index) {
>> + if (vq->index == index) {
>
> Should be
> if (info->vq->index == index) {
>
>> vq = info->vq;
>> break;
>> }
Thanks, fixed.
virtio: remove obsolete virtqueue_get_queue_index()
You can access it directly now, since 3.8: v3.7-rc1-13-g06ca287
'virtio: move queue_index and num_free fields into core struct
virtqueue.'
Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index d88d436..24fc9f5 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -153,7 +153,7 @@ struct padded_vnet_hdr {
*/
static int vq2txq(struct virtqueue *vq)
{
- return (virtqueue_get_queue_index(vq) - 1) / 2;
+ return (vq->index - 1) / 2;
}
static int txq2vq(int txq)
@@ -163,7 +163,7 @@ static int txq2vq(int txq)
static int vq2rxq(struct virtqueue *vq)
{
- return virtqueue_get_queue_index(vq) / 2;
+ return vq->index / 2;
}
static int rxq2vq(int rxq)
diff --git a/drivers/s390/kvm/virtio_ccw.c b/drivers/s390/kvm/virtio_ccw.c
index 2029b6c..a7eddc7 100644
--- a/drivers/s390/kvm/virtio_ccw.c
+++ b/drivers/s390/kvm/virtio_ccw.c
@@ -166,7 +166,7 @@ static void virtio_ccw_kvm_notify(struct virtqueue *vq)
vcdev = to_vc_device(info->vq->vdev);
ccw_device_get_schid(vcdev->cdev, &schid);
- do_kvm_notify(schid, virtqueue_get_queue_index(vq));
+ do_kvm_notify(schid, vq->index);
}
static int virtio_ccw_read_vq_conf(struct virtio_ccw_device *vcdev,
@@ -188,7 +188,7 @@ static void virtio_ccw_del_vq(struct virtqueue *vq, struct ccw1 *ccw)
unsigned long flags;
unsigned long size;
int ret;
- unsigned int index = virtqueue_get_queue_index(vq);
+ unsigned int index = vq->index;
/* Remove from our list. */
spin_lock_irqsave(&vcdev->lock, flags);
@@ -610,7 +610,7 @@ static struct virtqueue *virtio_ccw_vq_by_ind(struct virtio_ccw_device *vcdev,
vq = NULL;
spin_lock_irqsave(&vcdev->lock, flags);
list_for_each_entry(info, &vcdev->virtqueues, node) {
- if (virtqueue_get_queue_index(info->vq) == index) {
+ if (info->vq->index == index) {
vq = info->vq;
break;
}
diff --git a/include/linux/virtio.h b/include/linux/virtio.h
index 833f17b..9ff8645 100644
--- a/include/linux/virtio.h
+++ b/include/linux/virtio.h
@@ -76,12 +76,6 @@ void *virtqueue_detach_unused_buf(struct virtqueue *vq);
unsigned int virtqueue_get_vring_size(struct virtqueue *vq);
-/* FIXME: Obsolete accessor, but required for virtio_net merge. */
-static inline unsigned int virtqueue_get_queue_index(struct virtqueue *vq)
-{
- return vq->index;
-}
-
/**
* virtio_device - representation of a device using virtio
* @index: unique position on the virtio bus
^ permalink raw reply related
* Re: [BUG] bisected: PandaBoard smsc95xx ethernet driver error from USB timeout
From: Frank Rowand @ 2013-03-22 2:45 UTC (permalink / raw)
To: Alan Stern
Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
balbi@ti.com, netdev@vger.kernel.org
In-Reply-To: <Pine.LNX.4.44L0.1303211037070.1899-100000@iolanthe.rowland.org>
On 03/21/13 07:41, Alan Stern wrote:
> On Wed, 20 Mar 2013, Frank Rowand wrote:
>
>> Hi All,
>>
>> Not quite sure quite where the problem is (USB, OMAP, smsc95xx driver, other???),
>> so casting the nets wide...
>>
>> The PandaBoard frequently fails to boot with an eth0 error when mounting
>> the root file system via NFS (ethernet driver fails due to a USB timeout;
>> no ethernet means NFS won't work). A typical set of error messages is:
>>
>> [ 3.264373] smsc95xx 1-1.1:1.0: usb_probe_interface
>> [ 3.269500] smsc95xx 1-1.1:1.0: usb_probe_interface - got id
>> [ 3.275543] smsc95xx v1.0.4
>> [ 8.078674] smsc95xx 1-1.1:1.0: eth0: register 'smsc95xx' at usb-ehci-omap.0-1.1, smsc95xx USB 2.0 Ethernet, 82:b9:1d:fa:67:0d
>> [ 8.091003] hub 1-1:1.0: state 7 ports 5 chg 0000 evt 0002
>> [ 13.509918] usb 1-1.1: swapper/0 timed out on ep0out len=0/4
>> [ 13.515869] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x00000108
>> [ 13.523559] smsc95xx 1-1.1:1.0: eth0: Failed to write ADDRL: -110
>> [ 13.529998] IP-Config: Failed to open eth0
>>
>> I have bisected this to:
>>
>> commit 18aafe64d75d0e27dae206cacf4171e4e485d285
>> Author: Alan Stern <stern@rowland.harvard.edu>
>> Date: Wed Jul 11 11:23:04 2012 -0400
>>
>> USB: EHCI: use hrtimer for the I/O watchdog
>
> I don't understand how that commit could cause a timeout unless there
> are at least two other bugs present in your system.
>
>> Note that to compile this version of the kernel, an additional fix must
>> also be applied:
>>
>> commit ba5952e0711b14d8d4fe172671f8aa6091ace3ee
>> Author: Ming Lei <ming.lei@canonical.com>
>> Date: Fri Jul 13 17:25:24 2012 +0800
>>
>> USB: ehci-omap: fix compile failure(v1)
>>
>> The symptom can be worked around by retrying the USB access if a timeout
>> occurs. This is clearly _not_ the fix, just a hack that I used to
>> investigate the problem:
>>
>> http://article.gmane.org/gmane.linux.rt.user/9773
>>
>> My kernel configuration is:
>>
>> arch/arm/configs/omap2plus_defconfig
>>
>> plus to get the ethernet driver I add:
>>
>> CONFIG_USB_EHCI_HCD
>> CONFIG_USB_NET_SMSC95XX
>>
>> I found the problem on 3.6.11, but have not replicated it on 3.9-rcX
>> yet because my config fails to build on 3.9-rc1 and 3.9-rc2. I'll try
>> to work on that issue tomorrow.
>
> Let me know how it works out.
My PandaBoard builds fail on 3.9-rcX due to ARM multiplatform issues.
Either there is something I need to change about the way I build it,
or it is broken (that is a side issue). My simple expedient was to
hack around multiplatform, and just make it build (patch below if
anyone else wants a _temporary_ hack).
The problem appears to not be present in 3.9-rc3. In older kernel versions,
the worst case to see the problem was 18 boots. For 3.9-rc3 I booted 42
times without seeing the problem.
The problem occurs at least up through 3.8. I'll try to reverse bisect
between 3.8 and 3.9-rc3 to see when the problem disappeared (I'm running
short of time, so no promises for a near term result).
-Frank
This patch is a _temporary_ hack, not fit for man or beast. Avert
your eyes, do not apply to any respectable repository!
---
arch/arm/Kconfig | 2 1 + 1 - 0 !
arch/arm/Makefile | 2 2 + 0 - 0 !
2 files changed, 3 insertions(+), 1 deletion(-)
Index: b/arch/arm/Kconfig
===================================================================
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1013,7 +1013,7 @@ config ARCH_MULTI_V7
bool "ARMv7 based platforms (Cortex-A, PJ4, Krait)"
default y
select ARCH_MULTI_V6_V7
- select ARCH_VEXPRESS
+ select ARCH_VEXPRESS if !ARCH_OMAP2PLUS
select CPU_V7
config ARCH_MULTI_V6_V7
Index: b/arch/arm/Makefile
===================================================================
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -227,8 +227,10 @@ else
MACHINE :=
endif
ifeq ($(CONFIG_ARCH_MULTIPLATFORM),y)
+ifneq ($(CONFIG_ARCH_OMAP2PLUS),y)
MACHINE :=
endif
+endif
machdirs := $(patsubst %,arch/arm/mach-%/,$(machine-y))
platdirs := $(patsubst %,arch/arm/plat-%/,$(plat-y))
^ permalink raw reply
* Re: [PATCH 1/1 v2 net-next] net: fec: fix the build as module
From: Frank Li @ 2013-03-22 2:39 UTC (permalink / raw)
To: Fabio Estevam; +Cc: Frank Li, u.kleine-koenig, netdev, davem, linux-arm-kernel
In-Reply-To: <CAOMZO5D1p-QJ=7N-QrLbjcwK0b=280QEFuxNkbmYsmTeRitv+w@mail.gmail.com>
>
> This error does not not happen in 'net-next' anymore.
what's your suggestion? change commit message or request apply to 3.9
best regards
Frank Li
^ permalink raw reply
* Re: [PATCH 1/1 v2 net-next] net: fec: fix the build as module
From: Fabio Estevam @ 2013-03-22 2:36 UTC (permalink / raw)
To: Frank Li; +Cc: lznuaa, u.kleine-koenig, netdev, davem, linux-arm-kernel
In-Reply-To: <1363915193-22179-1-git-send-email-Frank.Li@freescale.com>
On Thu, Mar 21, 2013 at 10:19 PM, Frank Li <Frank.Li@freescale.com> wrote:
> Since commit ff43da86c69 (NET: FEC: dynamtic check DMA desc buff type) the
> following build error happens when CONFIG_FEC=m
>
> ERROR: "fec_ptp_init" [drivers/net/ethernet/freescale/fec.ko] undefined!
> ERROR: "fec_ptp_ioctl" [drivers/net/ethernet/freescale/fec.ko] undefined!
> ERROR: "fec_ptp_start_cyclecounter" [drivers/net/ethernet/freescale/fec.ko] undefined!
This error does not not happen in 'net-next' anymore.
^ permalink raw reply
* [PATCH 1/1 v2 net-next] net: fec: fix the build as module
From: Frank Li @ 2013-03-22 1:19 UTC (permalink / raw)
To: festevam, lznuaa, u.kleine-koenig, netdev, davem,
linux-arm-kernel; +Cc: Frank Li
Since commit ff43da86c69 (NET: FEC: dynamtic check DMA desc buff type) the
following build error happens when CONFIG_FEC=m
ERROR: "fec_ptp_init" [drivers/net/ethernet/freescale/fec.ko] undefined!
ERROR: "fec_ptp_ioctl" [drivers/net/ethernet/freescale/fec.ko] undefined!
ERROR: "fec_ptp_start_cyclecounter" [drivers/net/ethernet/freescale/fec.ko] undefined!
rename fec.c to fec_main.c
Build fec.o and fec_ptp.o into one fec.ko
Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Frank Li <Frank.Li@freescale.com>
---
Change from V1 to V2
1. Use -M option to create patch
drivers/net/ethernet/freescale/Makefile | 3 ++-
.../net/ethernet/freescale/{fec.c => fec_main.c} | 0
2 files changed, 2 insertions(+), 1 deletions(-)
rename drivers/net/ethernet/freescale/{fec.c => fec_main.c} (100%)
diff --git a/drivers/net/ethernet/freescale/Makefile b/drivers/net/ethernet/freescale/Makefile
index b7d58fe..549ce13 100644
--- a/drivers/net/ethernet/freescale/Makefile
+++ b/drivers/net/ethernet/freescale/Makefile
@@ -2,7 +2,8 @@
# Makefile for the Freescale network device drivers.
#
-obj-$(CONFIG_FEC) += fec.o fec_ptp.o
+obj-$(CONFIG_FEC) += fec.o
+fec-objs :=fec_main.o fec_ptp.o
obj-$(CONFIG_FEC_MPC52xx) += fec_mpc52xx.o
ifeq ($(CONFIG_FEC_MPC52xx_MDIO),y)
obj-$(CONFIG_FEC_MPC52xx) += fec_mpc52xx_phy.o
diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec_main.c
similarity index 100%
rename from drivers/net/ethernet/freescale/fec.c
rename to drivers/net/ethernet/freescale/fec_main.c
--
1.7.1
^ permalink raw reply related
* [PATCH net-next] bnx2x: increase inner ip id during encapsulated tso
From: Dmitry Kravkov @ 2013-03-22 1:38 UTC (permalink / raw)
To: davem, netdev
Cc: Dmitry Kravkov, Eilon Greenstein, Ariel Elior,
Maciej Zenczykowski, Jesse Gross
57712/578xx devices during handling of encapsulated TSO can
properly increase ip id for only one ip header.
The patch selects inner header to be increased.
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
CC: Eilon Greenstein <eilong@broadcom.com>
CC: Ariel Elior <ariele@broadcom.com>
CC: Maciej Zenczykowski <maze@google.com>
CC: Jesse Gross <jesse@nicira.com>
---
tested over 1bc277f79
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 22 ++++++++++------------
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 1 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c | 2 ++
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.h | 3 ++-
4 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
index 3f5cd7c..352e58e 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
@@ -3464,30 +3464,28 @@ static void bnx2x_update_pbds_gso_enc(struct sk_buff *skb,
u16 *global_data,
u32 xmit_type)
{
- u16 inner_hlen_w = 0;
+ u16 hlen_w = 0;
u8 outerip_off, outerip_len = 0;
-
- /* IP len */
- inner_hlen_w = (skb_inner_transport_header(skb) -
- skb_inner_network_header(skb)) >> 1;
+ /* from outer IP to transport */
+ hlen_w = (skb_inner_transport_header(skb) -
+ skb_network_header(skb)) >> 1;
/* transport len */
if (xmit_type & XMIT_CSUM_TCP)
- inner_hlen_w += inner_tcp_hdrlen(skb) >> 1;
+ hlen_w += inner_tcp_hdrlen(skb) >> 1;
else
- inner_hlen_w += sizeof(struct udphdr) >> 1;
+ hlen_w += sizeof(struct udphdr) >> 1;
- pbd2->fw_ip_hdr_to_payload_w = inner_hlen_w;
+ pbd2->fw_ip_hdr_to_payload_w = hlen_w;
if (xmit_type & XMIT_CSUM_ENC_V4) {
- struct iphdr *iph = inner_ip_hdr(skb);
-
+ struct iphdr *iph = ip_hdr(skb);
pbd2->fw_ip_csum_wo_len_flags_frag =
bswab16(csum_fold((~iph->check) -
iph->tot_len - iph->frag_off));
} else {
pbd2->fw_ip_hdr_to_payload_w =
- inner_hlen_w - ((sizeof(struct ipv6hdr)) >> 1);
+ hlen_w - ((sizeof(struct ipv6hdr)) >> 1);
}
pbd2->tcp_send_seq = bswab32(inner_tcp_hdr(skb)->seq);
@@ -3495,7 +3493,7 @@ static void bnx2x_update_pbds_gso_enc(struct sk_buff *skb,
pbd2->tcp_flags = pbd_tcp_flags(inner_tcp_hdr(skb));
if (xmit_type & XMIT_GSO_V4) {
- pbd2->hw_ip_id = bswab16(ip_hdr(skb)->id);
+ pbd2->hw_ip_id = bswab16(inner_ip_hdr(skb)->id);
pbd_e2->data.tunnel_data.pseudo_csum =
bswab16(~csum_tcpudp_magic(
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 10b0748..2c6a2a6 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -2962,6 +2962,7 @@ static unsigned long bnx2x_get_common_flags(struct bnx2x *bp,
__set_bit(BNX2X_Q_FLG_ZERO_STATS, &flags);
__set_bit(BNX2X_Q_FLG_PCSUM_ON_PKT, &flags);
+ __set_bit(BNX2X_Q_FLG_TUN_INC_INNER_IP_ID, &flags);
#ifdef BNX2X_STOP_ON_ERROR
__set_bit(BNX2X_Q_FLG_TX_SEC, &flags);
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c
index 5bdc1d6..32a9609 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c
@@ -4432,6 +4432,8 @@ static void bnx2x_q_fill_init_tx_data(struct bnx2x_queue_sp_obj *o,
tx_data->force_default_pri_flg =
test_bit(BNX2X_Q_FLG_FORCE_DEFAULT_PRI, flags);
+ tx_data->tunnel_lso_inc_ip_id =
+ test_bit(BNX2X_Q_FLG_TUN_INC_INNER_IP_ID, flags);
tx_data->tunnel_non_lso_pcsum_location =
test_bit(BNX2X_Q_FLG_PCSUM_ON_PKT, flags) ? PCSUM_ON_PKT :
PCSUM_ON_BD;
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.h
index 35479da..43c00bc 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.h
@@ -828,7 +828,8 @@ enum {
BNX2X_Q_FLG_ANTI_SPOOF,
BNX2X_Q_FLG_SILENT_VLAN_REM,
BNX2X_Q_FLG_FORCE_DEFAULT_PRI,
- BNX2X_Q_FLG_PCSUM_ON_PKT
+ BNX2X_Q_FLG_PCSUM_ON_PKT,
+ BNX2X_Q_FLG_TUN_INC_INNER_IP_ID
};
/* Queue type options: queue type may be a compination of below. */
--
1.7.7.2
^ permalink raw reply related
* [PATCH v2] net: Fix p3_gelic_net sparse warnings
From: Geoff Levand @ 2013-03-22 0:06 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20130321.171723.2170130040090928680.davem@davemloft.net>
Rearrange routines to avoid local declarations and remove
unnecessary inline tags. No functional changes.
Fixes sparse warnings like these:
ps3_gelic_net.c: error: marked inline, but without a definition
Signed-off-by: Geoff Levand <geoff@infradead.org>
---
V2:
* Rearrange routines to avoid local declarations.
* Remove unnecessary inline tags.
Hi Dave,
Cleaned up as suggested. Please apply.
-Geoff
---
drivers/net/ethernet/toshiba/ps3_gelic_net.c | 240 +++++++++++++-------------
1 file changed, 117 insertions(+), 123 deletions(-)
diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_net.c b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
index 445c059..ad32af6 100644
--- a/drivers/net/ethernet/toshiba/ps3_gelic_net.c
+++ b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
@@ -58,13 +58,6 @@ MODULE_DESCRIPTION("Gelic Network driver");
MODULE_LICENSE("GPL");
-static inline void gelic_card_enable_rxdmac(struct gelic_card *card);
-static inline void gelic_card_disable_rxdmac(struct gelic_card *card);
-static inline void gelic_card_disable_txdmac(struct gelic_card *card);
-static inline void gelic_card_reset_chain(struct gelic_card *card,
- struct gelic_descr_chain *chain,
- struct gelic_descr *start_descr);
-
/* set irq_mask */
int gelic_card_set_irq_mask(struct gelic_card *card, u64 mask)
{
@@ -78,12 +71,12 @@ int gelic_card_set_irq_mask(struct gelic_card *card, u64 mask)
return status;
}
-static inline void gelic_card_rx_irq_on(struct gelic_card *card)
+static void gelic_card_rx_irq_on(struct gelic_card *card)
{
card->irq_mask |= GELIC_CARD_RXINT;
gelic_card_set_irq_mask(card, card->irq_mask);
}
-static inline void gelic_card_rx_irq_off(struct gelic_card *card)
+static void gelic_card_rx_irq_off(struct gelic_card *card)
{
card->irq_mask &= ~GELIC_CARD_RXINT;
gelic_card_set_irq_mask(card, card->irq_mask);
@@ -127,6 +120,120 @@ static int gelic_card_set_link_mode(struct gelic_card *card, int mode)
return 0;
}
+/**
+ * gelic_card_disable_txdmac - disables the transmit DMA controller
+ * @card: card structure
+ *
+ * gelic_card_disable_txdmac terminates processing on the DMA controller by
+ * turing off DMA and issuing a force end
+ */
+static void gelic_card_disable_txdmac(struct gelic_card *card)
+{
+ int status;
+
+ /* this hvc blocks until the DMA in progress really stopped */
+ status = lv1_net_stop_tx_dma(bus_id(card), dev_id(card));
+ if (status)
+ dev_err(ctodev(card),
+ "lv1_net_stop_tx_dma failed, status=%d\n", status);
+}
+
+/**
+ * gelic_card_enable_rxdmac - enables the receive DMA controller
+ * @card: card structure
+ *
+ * gelic_card_enable_rxdmac enables the DMA controller by setting RX_DMA_EN
+ * in the GDADMACCNTR register
+ */
+static void gelic_card_enable_rxdmac(struct gelic_card *card)
+{
+ int status;
+
+#ifdef DEBUG
+ if (gelic_descr_get_status(card->rx_chain.head) !=
+ GELIC_DESCR_DMA_CARDOWNED) {
+ printk(KERN_ERR "%s: status=%x\n", __func__,
+ be32_to_cpu(card->rx_chain.head->dmac_cmd_status));
+ printk(KERN_ERR "%s: nextphy=%x\n", __func__,
+ be32_to_cpu(card->rx_chain.head->next_descr_addr));
+ printk(KERN_ERR "%s: head=%p\n", __func__,
+ card->rx_chain.head);
+ }
+#endif
+ status = lv1_net_start_rx_dma(bus_id(card), dev_id(card),
+ card->rx_chain.head->bus_addr, 0);
+ if (status)
+ dev_info(ctodev(card),
+ "lv1_net_start_rx_dma failed, status=%d\n", status);
+}
+
+/**
+ * gelic_card_disable_rxdmac - disables the receive DMA controller
+ * @card: card structure
+ *
+ * gelic_card_disable_rxdmac terminates processing on the DMA controller by
+ * turing off DMA and issuing a force end
+ */
+static void gelic_card_disable_rxdmac(struct gelic_card *card)
+{
+ int status;
+
+ /* this hvc blocks until the DMA in progress really stopped */
+ status = lv1_net_stop_rx_dma(bus_id(card), dev_id(card));
+ if (status)
+ dev_err(ctodev(card),
+ "lv1_net_stop_rx_dma failed, %d\n", status);
+}
+
+/**
+ * gelic_descr_set_status -- sets the status of a descriptor
+ * @descr: descriptor to change
+ * @status: status to set in the descriptor
+ *
+ * changes the status to the specified value. Doesn't change other bits
+ * in the status
+ */
+static void gelic_descr_set_status(struct gelic_descr *descr,
+ enum gelic_descr_dma_status status)
+{
+ descr->dmac_cmd_status = cpu_to_be32(status |
+ (be32_to_cpu(descr->dmac_cmd_status) &
+ ~GELIC_DESCR_DMA_STAT_MASK));
+ /*
+ * dma_cmd_status field is used to indicate whether the descriptor
+ * is valid or not.
+ * Usually caller of this function wants to inform that to the
+ * hardware, so we assure here the hardware sees the change.
+ */
+ wmb();
+}
+
+/**
+ * gelic_card_reset_chain - reset status of a descriptor chain
+ * @card: card structure
+ * @chain: address of chain
+ * @start_descr: address of descriptor array
+ *
+ * Reset the status of dma descriptors to ready state
+ * and re-initialize the hardware chain for later use
+ */
+static void gelic_card_reset_chain(struct gelic_card *card,
+ struct gelic_descr_chain *chain,
+ struct gelic_descr *start_descr)
+{
+ struct gelic_descr *descr;
+
+ for (descr = start_descr; start_descr != descr->next; descr++) {
+ gelic_descr_set_status(descr, GELIC_DESCR_DMA_CARDOWNED);
+ descr->next_descr_addr = cpu_to_be32(descr->next->bus_addr);
+ }
+
+ chain->head = start_descr;
+ chain->tail = (descr - 1);
+
+ (descr - 1)->next_descr_addr = 0;
+}
+
void gelic_card_up(struct gelic_card *card)
{
pr_debug("%s: called\n", __func__);
@@ -183,29 +290,6 @@ gelic_descr_get_status(struct gelic_descr *descr)
}
/**
- * gelic_descr_set_status -- sets the status of a descriptor
- * @descr: descriptor to change
- * @status: status to set in the descriptor
- *
- * changes the status to the specified value. Doesn't change other bits
- * in the status
- */
-static void gelic_descr_set_status(struct gelic_descr *descr,
- enum gelic_descr_dma_status status)
-{
- descr->dmac_cmd_status = cpu_to_be32(status |
- (be32_to_cpu(descr->dmac_cmd_status) &
- ~GELIC_DESCR_DMA_STAT_MASK));
- /*
- * dma_cmd_status field is used to indicate whether the descriptor
- * is valid or not.
- * Usually caller of this function wants to inform that to the
- * hardware, so we assure here the hardware sees the change.
- */
- wmb();
-}
-
-/**
* gelic_card_free_chain - free descriptor chain
* @card: card structure
* @descr_in: address of desc
@@ -286,31 +370,6 @@ iommu_error:
}
/**
- * gelic_card_reset_chain - reset status of a descriptor chain
- * @card: card structure
- * @chain: address of chain
- * @start_descr: address of descriptor array
- *
- * Reset the status of dma descriptors to ready state
- * and re-initialize the hardware chain for later use
- */
-static void gelic_card_reset_chain(struct gelic_card *card,
- struct gelic_descr_chain *chain,
- struct gelic_descr *start_descr)
-{
- struct gelic_descr *descr;
-
- for (descr = start_descr; start_descr != descr->next; descr++) {
- gelic_descr_set_status(descr, GELIC_DESCR_DMA_CARDOWNED);
- descr->next_descr_addr = cpu_to_be32(descr->next->bus_addr);
- }
-
- chain->head = start_descr;
- chain->tail = (descr - 1);
-
- (descr - 1)->next_descr_addr = 0;
-}
-/**
* gelic_descr_prepare_rx - reinitializes a rx descriptor
* @card: card structure
* @descr: descriptor to re-init
@@ -599,71 +658,6 @@ void gelic_net_set_multi(struct net_device *netdev)
}
/**
- * gelic_card_enable_rxdmac - enables the receive DMA controller
- * @card: card structure
- *
- * gelic_card_enable_rxdmac enables the DMA controller by setting RX_DMA_EN
- * in the GDADMACCNTR register
- */
-static inline void gelic_card_enable_rxdmac(struct gelic_card *card)
-{
- int status;
-
-#ifdef DEBUG
- if (gelic_descr_get_status(card->rx_chain.head) !=
- GELIC_DESCR_DMA_CARDOWNED) {
- printk(KERN_ERR "%s: status=%x\n", __func__,
- be32_to_cpu(card->rx_chain.head->dmac_cmd_status));
- printk(KERN_ERR "%s: nextphy=%x\n", __func__,
- be32_to_cpu(card->rx_chain.head->next_descr_addr));
- printk(KERN_ERR "%s: head=%p\n", __func__,
- card->rx_chain.head);
- }
-#endif
- status = lv1_net_start_rx_dma(bus_id(card), dev_id(card),
- card->rx_chain.head->bus_addr, 0);
- if (status)
- dev_info(ctodev(card),
- "lv1_net_start_rx_dma failed, status=%d\n", status);
-}
-
-/**
- * gelic_card_disable_rxdmac - disables the receive DMA controller
- * @card: card structure
- *
- * gelic_card_disable_rxdmac terminates processing on the DMA controller by
- * turing off DMA and issuing a force end
- */
-static inline void gelic_card_disable_rxdmac(struct gelic_card *card)
-{
- int status;
-
- /* this hvc blocks until the DMA in progress really stopped */
- status = lv1_net_stop_rx_dma(bus_id(card), dev_id(card));
- if (status)
- dev_err(ctodev(card),
- "lv1_net_stop_rx_dma failed, %d\n", status);
-}
-
-/**
- * gelic_card_disable_txdmac - disables the transmit DMA controller
- * @card: card structure
- *
- * gelic_card_disable_txdmac terminates processing on the DMA controller by
- * turing off DMA and issuing a force end
- */
-static inline void gelic_card_disable_txdmac(struct gelic_card *card)
-{
- int status;
-
- /* this hvc blocks until the DMA in progress really stopped */
- status = lv1_net_stop_tx_dma(bus_id(card), dev_id(card));
- if (status)
- dev_err(ctodev(card),
- "lv1_net_stop_tx_dma failed, status=%d\n", status);
-}
-
-/**
* gelic_net_stop - called upon ifconfig down
* @netdev: interface device structure
*
@@ -746,7 +740,7 @@ static void gelic_descr_set_tx_cmdstat(struct gelic_descr *descr,
}
}
-static inline struct sk_buff *gelic_put_vlan_tag(struct sk_buff *skb,
+static struct sk_buff *gelic_put_vlan_tag(struct sk_buff *skb,
unsigned short tag)
{
struct vlan_ethhdr *veth;
--
1.7.9.5
^ permalink raw reply related
* [PATCH] appletalk: remove "config IPDDP_DECAP"
From: Paul Bolle @ 2013-03-21 23:35 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo; +Cc: netdev, linux-kernel
The Kconfig symbol IPDDP_DECAP got added in v2.1.75. It has never been
used. Its entry can safely be removed.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
---
0) No, v2.1.75 is not a typo.
1) A follow up patch might involve some corrections to the IPDDP and
IPDDP_ENCAP entries and to Documentation/networking/ipddp.txt. I hope to
do that within the next 16 years.
2) Untested, by the way.
drivers/net/appletalk/Kconfig | 18 +-----------------
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/drivers/net/appletalk/Kconfig b/drivers/net/appletalk/Kconfig
index f5a8916..4ce6ca5 100644
--- a/drivers/net/appletalk/Kconfig
+++ b/drivers/net/appletalk/Kconfig
@@ -106,20 +106,4 @@ config IPDDP_ENCAP
IP packets inside AppleTalk frames; this is useful if your Linux box
is stuck on an AppleTalk network (which hopefully contains a
decapsulator somewhere). Please see
- <file:Documentation/networking/ipddp.txt> for more information. If
- you said Y to "AppleTalk-IP driver support" above and you say Y
- here, then you cannot say Y to "AppleTalk-IP to IP Decapsulation
- support", below.
-
-config IPDDP_DECAP
- bool "Appletalk-IP to IP Decapsulation support"
- depends on IPDDP
- help
- If you say Y here, the AppleTalk-IP code will be able to decapsulate
- AppleTalk-IP frames to IP packets; this is useful if you want your
- Linux box to act as an Internet gateway for an AppleTalk network.
- Please see <file:Documentation/networking/ipddp.txt> for more
- information. If you said Y to "AppleTalk-IP driver support" above
- and you say Y here, then you cannot say Y to "IP to AppleTalk-IP
- Encapsulation support", above.
-
+ <file:Documentation/networking/ipddp.txt> for more information.
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH] sh_eth: fix unused variable warning
From: David Miller @ 2013-03-21 22:27 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: netdev, nobuhiro.iwamatsu.yj
In-Reply-To: <201303220159.00633.sergei.shtylyov@cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Fri, 22 Mar 2013 01:59:00 +0300
> Commit d5e07e69218fd9aa21d6c8c5ccc629d92bdb9b0f (sh_eth: use managed device API)
> has caused this warning (due to my overlook):
>
> drivers/net/ethernet/renesas/sh_eth.c: In function `sh_eth_drv_remove':
> drivers/net/ethernet/renesas/sh_eth.c:2482:25: warning: unused variable `mdp'
> [-Wunused-variable]
>
> Kill the darn variable now...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Applied, thanks.
^ permalink raw reply
* NULL pointer deref, selinux_socket_unix_may_send+0x34/0x90
From: Ján Stanček @ 2013-03-21 22:19 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 3388 bytes --]
Hi,
I'm occasionally seeing a panic early after system booted and while
systemd is starting other services.
I made a reproducer which is quite reliable on my system (32 CPU Intel)
and can usually trigger this issue within a minute or two. I can reproduce
this issue with 3.9.0-rc3 as root or unprivileged user (see call trace below).
I'm attaching my reproducer and (experimental) patch, which fixes the
issue for me.
Regards,
Jan
[ 307.419660] BUG: unable to handle kernel NULL pointer dereference
at 0000000000000250
[ 307.428453] IP: [<ffffffff812a2d04>] selinux_socket_unix_may_send+0x34/0x90
[ 307.436258] PGD 422cd8067 PUD 4081b1067 PMD 0
[ 307.441266] Oops: 0000 [#1] SMP
[ 307.558800] CPU 25
[ 307.560953] Pid: 7412, comm: a.out Tainted: GF
3.9.0-rc3 #1 Intel Corporation W2600CR/W2600CR
[ 307.571736] RIP: 0010:[<ffffffff812a2d04>] [<ffffffff812a2d04>]
selinux_socket_unix_may_send+0x34/0x90
[ 307.582240] RSP: 0018:ffff880423c67ab8 EFLAGS: 00010246
[ 307.588171] RAX: ffff8808243a0680 RBX: ffff880423c67be8 RCX:
0000000000000007
[ 307.596139] RDX: 0000000000000000 RSI: ffff88042ef1c380 RDI:
ffff880423c67ad8
[ 307.604100] RBP: ffff880423c67b18 R08: ffff88042511e180 R09:
0000000000000000
[ 307.612067] R10: 0000000000000000 R11: 0000000000000000 R12:
ffff8808243a0680
[ 307.620034] R13: 7fffffffffffffff R14: ffff88042511e180 R15:
ffff88042511e470
[ 307.628001] FS: 00007f19d1bb2740(0000) GS:ffff88082ef20000(0000)
knlGS:0000000000000000
[ 307.637028] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 307.643437] CR2: 0000000000000250 CR3: 0000000404ff4000 CR4:
00000000000407e0
[ 307.651397] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[ 307.659358] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[ 307.667331] Process a.out (pid: 7412, threadinfo
ffff880423c66000, task ffff880423600000)
[ 307.676453] Stack:
[ 307.678694] ffff88042511e102 ffff88042749f600 ffff8808243a0680
ffff88042511e180
[ 307.686990] ffff88042511e180 000000000000000a ffff880423c67af8
ffffffff8129ef36
[ 307.695284] ffff880423c67b28 ffffffff81529747 ffff880423c67be8
00000000fdbc1448
[ 307.703584] Call Trace:
[ 307.706332] [<ffffffff8129ef36>] ? security_sock_rcv_skb+0x16/0x20
[ 307.713339] [<ffffffff81529747>] ? sk_filter+0x37/0xd0
[ 307.719168] [<ffffffff8129ef16>] security_unix_may_send+0x16/0x20
[ 307.726075] [<ffffffff815b694d>] unix_dgram_sendmsg+0x48d/0x640
[ 307.732802] [<ffffffff814fd9c0>] sock_sendmsg+0xb0/0xe0
[ 307.738732] [<ffffffff8103edde>] ? physflat_send_IPI_mask+0xe/0x10
[ 307.745726] [<ffffffff814ff55c>] __sys_sendmsg+0x3ac/0x3c0
[ 307.751961] [<ffffffff811a3357>] ? do_sync_write+0xa7/0xe0
[ 307.758186] [<ffffffff811e31fb>] ? fsnotify+0x24b/0x340
[ 307.764120] [<ffffffff815013c9>] sys_sendmsg+0x49/0x90
[ 307.769966] [<ffffffff81630b99>] system_call_fastpath+0x16/0x1b
[ 307.776665] Code: 00 00 45 31 c9 48 89 e5 48 83 ec 60 48 8b 56 20
65 48 8b 04 25 28 00 00 00 48 89 45 f8 31 c0 48 8b 47 20 48 8d 7d c0
c6 45 a0 02 <48> 8b b2 50 02 00 00 4c 8b 80 50 02 00 00 31 c0 f3 48 ab
48 89
[ 307.798450] RIP [<ffffffff812a2d04>]
selinux_socket_unix_may_send+0x34/0x90
[ 307.806334] RSP <ffff880423c67ab8>
[ 307.810223] CR2: 0000000000000250
[ 307.813957] ---[ end trace 0829e3985976c28a ]---
[-- Attachment #2: 0001-af_unix-fix-race-in-unix_release-unix_dgram_sendmsg.patch --]
[-- Type: application/octet-stream, Size: 4419 bytes --]
From 7bed585f37d10f62fe7389fdd704d3684d61cdf9 Mon Sep 17 00:00:00 2001
Message-Id: <7bed585f37d10f62fe7389fdd704d3684d61cdf9.1363863447.git.jan@stancek.eu>
From: Jan Stancek <jan@stancek.eu>
Date: Thu, 21 Mar 2013 11:20:18 +0100
Subject: [PATCH] af_unix: fix race in unix_release/unix_dgram_sendmsg
unix_release() will set sock->sk to NULL for server side,
while client may still be at unix_dgram_sendmsg(). When client
now calls security_unix_may_send(), other->sk->sk_security will
cause NULL pointer dereference.
Check that 'other' is not in process of being released.
[ 307.419660] BUG: unable to handle kernel NULL pointer dereference at 0000000000000250
[ 307.428453] IP: [<ffffffff812a2d04>] selinux_socket_unix_may_send+0x34/0x90
[ 307.436258] PGD 422cd8067 PUD 4081b1067 PMD 0
[ 307.441266] Oops: 0000 [#1] SMP
[ 307.558800] CPU 25
[ 307.560953] Pid: 7412, comm: a.out Tainted: GF 3.9.0-rc3 #1 Intel Corporation W2600CR/W2600CR
[ 307.571736] RIP: 0010:[<ffffffff812a2d04>] [<ffffffff812a2d04>] selinux_socket_unix_may_send+0x34/0x90
[ 307.582240] RSP: 0018:ffff880423c67ab8 EFLAGS: 00010246
[ 307.588171] RAX: ffff8808243a0680 RBX: ffff880423c67be8 RCX: 0000000000000007
[ 307.596139] RDX: 0000000000000000 RSI: ffff88042ef1c380 RDI: ffff880423c67ad8
[ 307.604100] RBP: ffff880423c67b18 R08: ffff88042511e180 R09: 0000000000000000
[ 307.612067] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8808243a0680
[ 307.620034] R13: 7fffffffffffffff R14: ffff88042511e180 R15: ffff88042511e470
[ 307.628001] FS: 00007f19d1bb2740(0000) GS:ffff88082ef20000(0000) knlGS:0000000000000000
[ 307.637028] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 307.643437] CR2: 0000000000000250 CR3: 0000000404ff4000 CR4: 00000000000407e0
[ 307.651397] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 307.659358] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 307.667331] Process a.out (pid: 7412, threadinfo ffff880423c66000, task ffff880423600000)
[ 307.676453] Stack:
[ 307.678694] ffff88042511e102 ffff88042749f600 ffff8808243a0680 ffff88042511e180
[ 307.686990] ffff88042511e180 000000000000000a ffff880423c67af8 ffffffff8129ef36
[ 307.695284] ffff880423c67b28 ffffffff81529747 ffff880423c67be8 00000000fdbc1448
[ 307.703584] Call Trace:
[ 307.706332] [<ffffffff8129ef36>] ? security_sock_rcv_skb+0x16/0x20
[ 307.713339] [<ffffffff81529747>] ? sk_filter+0x37/0xd0
[ 307.719168] [<ffffffff8129ef16>] security_unix_may_send+0x16/0x20
[ 307.726075] [<ffffffff815b694d>] unix_dgram_sendmsg+0x48d/0x640
[ 307.732802] [<ffffffff814fd9c0>] sock_sendmsg+0xb0/0xe0
[ 307.738732] [<ffffffff8103edde>] ? physflat_send_IPI_mask+0xe/0x10
[ 307.745726] [<ffffffff814ff55c>] __sys_sendmsg+0x3ac/0x3c0
[ 307.751961] [<ffffffff811a3357>] ? do_sync_write+0xa7/0xe0
[ 307.758186] [<ffffffff811e31fb>] ? fsnotify+0x24b/0x340
[ 307.764120] [<ffffffff815013c9>] sys_sendmsg+0x49/0x90
[ 307.769966] [<ffffffff81630b99>] system_call_fastpath+0x16/0x1b
[ 307.776665] Code: 00 00 45 31 c9 48 89 e5 48 83 ec 60 48 8b 56 20 65 48 8b 04 25 28 00 00 00 48 89 45 f8 31 c0 48 8b 47 20 48 8d 7d c0 c6 45 a0 02 <48> 8b b2 50 02 00 00 4c 8b 80 50 02 00 00 31 c0 f3 48 ab 48 89
[ 307.798450] RIP [<ffffffff812a2d04>] selinux_socket_unix_may_send+0x34/0x90
[ 307.806334] RSP <ffff880423c67ab8>
[ 307.810223] CR2: 0000000000000250
[ 307.813957] ---[ end trace 0829e3985976c28a ]---
Signed-off-by: Jan Stancek <jan@stancek.eu>
---
net/unix/af_unix.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 51be64f..433952c 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -993,6 +993,11 @@ restart:
if (!unix_may_send(sk, other))
goto out_unlock;
+ err = -ECONNREFUSED;
+ /* other is being released */
+ if (!other->sk_socket->sk)
+ goto out_unlock;
+
err = security_unix_may_send(sk->sk_socket, other->sk_socket);
if (err)
goto out_unlock;
@@ -1554,6 +1559,11 @@ restart:
goto out_unlock;
if (sk->sk_type != SOCK_SEQPACKET) {
+ err = -ECONNREFUSED;
+ /* other is being released */
+ if (!other->sk_socket->sk)
+ goto out_unlock;
+
err = security_unix_may_send(sk->sk_socket, other->sk_socket);
if (err)
goto out_unlock;
--
1.7.1
[-- Attachment #3: selinux_socket_unix_may_send.c --]
[-- Type: text/x-csrc, Size: 3730 bytes --]
/*
* reproducer for Bug 887683
* unable to handle kernel NULL in selinux_socket_unix_may_send
*
* This reproducer is based on systemd/journald sources,
* it's possible there is way to make it even more simple, but
* since I was able to trigger the Bug, I rather kept it as it is.
*
* jstancek@redhat.com
*
* gcc selinux_socket_unix_may_send.c; ./a.out
*/
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/un.h>
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <signal.h>
#include <net/if.h>
#include <netinet/in.h>
#include <linux/netlink.h>
#include <unistd.h>
#define offsetof(type, member) __builtin_offsetof (type, member)
#define SNDBUF_SIZE (8*1024*1024)
int pipefd[2];
union sockaddr_union {
struct sockaddr sa;
struct sockaddr_in in4;
struct sockaddr_in6 in6;
struct sockaddr_un un;
struct sockaddr_nl nl;
struct sockaddr_storage storage;
};
int fd_inc_sndbuf(int fd, size_t n) {
int r, value;
socklen_t l = sizeof(value);
r = getsockopt(fd, SOL_SOCKET, SO_SNDBUF, &value, &l);
if (r >= 0 &&
l == sizeof(value) &&
(size_t) value >= n*2)
return 0;
value = (int) n;
r = setsockopt(fd, SOL_SOCKET, SO_SNDBUF, &value, sizeof(value));
if (r < 0)
return -errno;
return 1;
}
int child()
{
int fd = socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0);
char data[1024] = "123456789";
struct iovec *w;
int j = 0;
int n = 1;
int ret;
int dummy;
struct sockaddr_un sa;
struct msghdr mh;
union {
struct cmsghdr cmsghdr;
uint8_t buf[CMSG_SPACE(sizeof(int))];
} control;
if (fd < 0)
return -errno;
ret = fd_inc_sndbuf(fd, SNDBUF_SIZE);
if (ret < 0)
perror("fd_inc_sndbuf");
memset(&sa, 0, sizeof(sa));
sa.sun_family = AF_UNIX;
strncpy(sa.sun_path, "/run/systemd/journal/socket_test", sizeof(sa.sun_path));
w = malloc(sizeof(struct iovec) * n * 5 + 3);
w[j].iov_base = data;
w[j].iov_len = 10;
j++;
memset(&control, 0, sizeof(control));
mh.msg_control = &control;
mh.msg_controllen = sizeof(control);
memset(&mh, 0, sizeof(mh));
mh.msg_name = &sa;
mh.msg_namelen = offsetof(struct sockaddr_un, sun_path) + strlen(sa.sun_path);
mh.msg_iov = w;
mh.msg_iovlen = 1;
write(pipefd[1], &dummy, 1);
ret = sendmsg(fd, &mh, MSG_NOSIGNAL);
/*if (ret < 0)
perror("ret:");
else
printf("ret: %d\n", ret);*/
close(fd);
}
int parent()
{
int fd, ret, status;
union sockaddr_union sa;
int dummy;
fd = socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0);
if (fd < 0)
perror("socket");
sa.un.sun_family = AF_UNIX;
strncpy(sa.un.sun_path, "/run/systemd/journal/socket_test", sizeof(sa.un.sun_path));
unlink(sa.un.sun_path);
int one = 1;
ret = setsockopt(fd, SOL_SOCKET, SO_PASSCRED, &one, sizeof(one));
if (ret < 0)
perror("setsockopt 1");
ret = setsockopt(fd, SOL_SOCKET, SO_PASSSEC, &one, sizeof(one));
if (ret < 0)
perror("setsockopt 2");
ret = setsockopt(fd, SOL_SOCKET, SO_TIMESTAMP, &one, sizeof(one));
if (ret < 0)
perror("setsockopt 3");
ret = bind(fd, &sa.sa, offsetof(union sockaddr_union, un.sun_path) + strlen(sa.un.sun_path));
if (ret < 0)
perror("bind");
read(pipefd[0], &dummy, 1);
close(fd);
wait(&status);
}
int main()
{
int busypids[8192];
int childpid;
int i = 0;
int cpus = sysconf(_SC_NPROCESSORS_ONLN)*2;
if (pipe(pipefd) < 0) {
perror("pipe");
return 1;
}
for (i = 0; i < cpus; i++) {
childpid = fork();
if (childpid == 0) {
while(1);
}
busypids[i] = childpid;
}
i = 0;
while (i < 100000) {
childpid = fork();
if (childpid == 0) {
child();
exit(0);
}
parent();
i++;
if (i % 10 == 0) {
printf("loop: %d\n", i);
}
}
for (i = 0; i < cpus; i++) {
kill(busypids[i], SIGKILL);
}
printf("Done.\n");
return 0;
}
^ permalink raw reply related
* RE: [Xen-devel] [PATCH 4/4] xen-netback: coalesce slots before copying
From: James Harper @ 2013-03-21 22:14 UTC (permalink / raw)
To: Wei Liu
Cc: Wei Liu, netdev@vger.kernel.org, xen-devel@lists.xen.org,
annie.li@oracle.com, ian.campbell@citrix.com,
konrad.wilk@oracle.com
In-Reply-To: <CAOsiSVWSRmo1+Ubo7GyAKcvUr8XUenkMvnAqt607gPoJm-sXFQ@mail.gmail.com>
>
>> Actually it turns out GPLPV just stops counting at 20. If I keep
>> counting I can sometimes see over 1000 buffers per GSO packet under
>> Windows using "iperf -
>
> Do you think it is necessary to increase MAX_SKB_SLOTS_DEFAULT to 21?
>
Doesn't really matter. Under windows you have to coalesce anyway and the number of cases where the skb count is 20 or 21 is very small so there will be negligible gain and it will break guests that can't handle more than 19.
Has anyone done the benchmarks on if memcpy to coalesce is better or worse than consuming additional ring slots? Probably OT here but I'm talking about packets that might have 19 buffers but could fit on a page or two of coalesced.
James
^ permalink raw reply
* [PATCH] sh_eth: fix unused variable warning
From: Sergei Shtylyov @ 2013-03-21 22:59 UTC (permalink / raw)
To: netdev; +Cc: nobuhiro.iwamatsu.yj
Commit d5e07e69218fd9aa21d6c8c5ccc629d92bdb9b0f (sh_eth: use managed device API)
has caused this warning (due to my overlook):
drivers/net/ethernet/renesas/sh_eth.c: In function `sh_eth_drv_remove':
drivers/net/ethernet/renesas/sh_eth.c:2482:25: warning: unused variable `mdp'
[-Wunused-variable]
Kill the darn variable now...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
The patch is against the David Miller's net-next.git repo.
drivers/net/ethernet/renesas/sh_eth.c | 1 -
1 file changed, 1 deletion(-)
Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -2479,7 +2479,6 @@ out:
static int sh_eth_drv_remove(struct platform_device *pdev)
{
struct net_device *ndev = platform_get_drvdata(pdev);
- struct sh_eth_private *mdp = netdev_priv(ndev);
sh_mdio_release(ndev);
unregister_netdev(ndev);
^ permalink raw reply
* Re: [PATCH v2 3/3] sh_eth: use managed device API
From: Sergei Shtylyov @ 2013-03-21 22:43 UTC (permalink / raw)
To: David Miller; +Cc: netdev, nobuhiro.iwamatsu.yj
In-Reply-To: <20130321.173523.2134000966916487176.davem@davemloft.net>
Hello.
On 03/22/2013 12:35 AM, David Miller wrote:
>
>> Switch the driver to the managed device API by replacing ioremap() calls with
>> devm_ioremap_resource() (which will also result in calling request_mem_region()
>> which the driver forgot to do until now) and k[mz]alloc() with devm_kzalloc() --
>> this permits to simplify driver's probe()/remove() method cleanup. We can now
>> remove the ioremap() error messages since the error messages are printed by
>> devm_ioremap_resource() itself. We can also remove the 'bitbang' field from
>> 'struct sh_eth_private' as we don't need it anymore in order to free the memory
>> behind it...
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>
>> ---
>> Changes since initial posting:
>> - removed unused 'mdp' variable in sh_eth_drv_remove().
>>
>> Sorry, I seem to have missed the unused variable warning... :-/
> I already applied your original patch.
Thanks, you're really quick. Maybe too quick. :-)
> Please read your email before posting new versions of patches.
I'm monitoring my mail constantly but was just somewhat carried away
by testing a new patch when I suddenly saw the warning and went on to
fix it immediately. Unfortunately, it was already too late. :-(
> You have to send me a relative fix since your patches are applied
> already.
Will send in a jiffy...
WBR, Sergei
^ permalink raw reply
* Re: [PATCH net-next] gro: relax ID check in inet_gro_receive()
From: David Miller @ 2013-03-21 21:39 UTC (permalink / raw)
To: jesse; +Cc: maze, dkravkov, eric.dumazet, netdev, dmitry, eilong, pshelar,
hkchu
In-Reply-To: <CAEP_g=8pqnVddN1jjZNVQ-POc3ths5DmAnr-9=UYKSpgFGrysQ@mail.gmail.com>
From: Jesse Gross <jesse@nicira.com>
Date: Thu, 21 Mar 2013 14:37:38 -0700
> On Thu, Mar 21, 2013 at 2:05 PM, David Miller <davem@davemloft.net> wrote:
>> From: Maciej Żenczykowski <maze@google.com>
>> Date: Thu, 21 Mar 2013 13:47:07 -0700
>>
>>> They might create non incrementing IP ID packet sequences on the wire,
>>> and this may prevent GRO from kicking in, but it does not make TSO
>>> non-reversible
>>> (if anything it makes it easy to detect that it happened).
>>
>> This is not an acceptable outcome for any form GSO, it should be
>> completely transparent. The packets we would have output individually
>> and those which result from the segmented frame must be
>> indistinguishable.
>
> We actually don't set the outer IP ID for GRE packets with the DF bit
> set in the non-GSO/TSO case either (and this is not new behavior).
> Obviously TCP/IP header compression doesn't apply to the GRE packet
> itself.
>
> Therefore, I think if the driver is switched to increment the inner
> ID, which it sounds like it can be, then everything should be
> transparent.
That's my impression as well.
^ permalink raw reply
* Re: [PATCH net-next] gro: relax ID check in inet_gro_receive()
From: Jesse Gross @ 2013-03-21 21:37 UTC (permalink / raw)
To: David Miller
Cc: maze, dkravkov, eric.dumazet, netdev, dmitry, eilong, pshelar,
hkchu
In-Reply-To: <20130321.170511.612698812448620739.davem@davemloft.net>
On Thu, Mar 21, 2013 at 2:05 PM, David Miller <davem@davemloft.net> wrote:
> From: Maciej Żenczykowski <maze@google.com>
> Date: Thu, 21 Mar 2013 13:47:07 -0700
>
>> They might create non incrementing IP ID packet sequences on the wire,
>> and this may prevent GRO from kicking in, but it does not make TSO
>> non-reversible
>> (if anything it makes it easy to detect that it happened).
>
> This is not an acceptable outcome for any form GSO, it should be
> completely transparent. The packets we would have output individually
> and those which result from the segmented frame must be
> indistinguishable.
We actually don't set the outer IP ID for GRE packets with the DF bit
set in the non-GSO/TSO case either (and this is not new behavior).
Obviously TCP/IP header compression doesn't apply to the GRE packet
itself.
Therefore, I think if the driver is switched to increment the inner
ID, which it sounds like it can be, then everything should be
transparent.
^ permalink raw reply
* Re: [PATCH v2 3/3] sh_eth: use managed device API
From: David Miller @ 2013-03-21 21:35 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: netdev, nobuhiro.iwamatsu.yj
In-Reply-To: <201303220135.51520.sergei.shtylyov@cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Fri, 22 Mar 2013 01:35:51 +0300
> Switch the driver to the managed device API by replacing ioremap() calls with
> devm_ioremap_resource() (which will also result in calling request_mem_region()
> which the driver forgot to do until now) and k[mz]alloc() with devm_kzalloc() --
> this permits to simplify driver's probe()/remove() method cleanup. We can now
> remove the ioremap() error messages since the error messages are printed by
> devm_ioremap_resource() itself. We can also remove the 'bitbang' field from
> 'struct sh_eth_private' as we don't need it anymore in order to free the memory
> behind it...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> ---
> Changes since initial posting:
> - removed unused 'mdp' variable in sh_eth_drv_remove().
>
> Sorry, I seem to have missed the unused variable warning... :-/
I already applied your original patch.
Please read your email before posting new versions of patches.
You have to send me a relative fix since your patches are applied
already.
^ permalink raw reply
* [PATCH v2 3/3] sh_eth: use managed device API
From: Sergei Shtylyov @ 2013-03-21 22:35 UTC (permalink / raw)
To: netdev; +Cc: nobuhiro.iwamatsu.yj
Switch the driver to the managed device API by replacing ioremap() calls with
devm_ioremap_resource() (which will also result in calling request_mem_region()
which the driver forgot to do until now) and k[mz]alloc() with devm_kzalloc() --
this permits to simplify driver's probe()/remove() method cleanup. We can now
remove the ioremap() error messages since the error messages are printed by
devm_ioremap_resource() itself. We can also remove the 'bitbang' field from
'struct sh_eth_private' as we don't need it anymore in order to free the memory
behind it...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Changes since initial posting:
- removed unused 'mdp' variable in sh_eth_drv_remove().
Sorry, I seem to have missed the unused variable warning... :-/
drivers/net/ethernet/renesas/sh_eth.c | 48 +++++++++-------------------------
drivers/net/ethernet/renesas/sh_eth.h | 1
2 files changed, 13 insertions(+), 36 deletions(-)
Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -2215,7 +2215,6 @@ static void sh_eth_tsu_init(struct sh_et
/* MDIO bus release function */
static int sh_mdio_release(struct net_device *ndev)
{
- struct sh_eth_private *mdp = netdev_priv(ndev);
struct mii_bus *bus = dev_get_drvdata(&ndev->dev);
/* unregister mdio bus */
@@ -2224,15 +2223,9 @@ static int sh_mdio_release(struct net_de
/* remove mdio bus info from net_device */
dev_set_drvdata(&ndev->dev, NULL);
- /* free interrupts memory */
- kfree(bus->irq);
-
/* free bitbang info */
free_mdio_bitbang(bus);
- /* free bitbang memory */
- kfree(mdp->bitbang);
-
return 0;
}
@@ -2245,7 +2238,8 @@ static int sh_mdio_init(struct net_devic
struct sh_eth_private *mdp = netdev_priv(ndev);
/* create bit control struct for PHY */
- bitbang = kzalloc(sizeof(struct bb_info), GFP_KERNEL);
+ bitbang = devm_kzalloc(&ndev->dev, sizeof(struct bb_info),
+ GFP_KERNEL);
if (!bitbang) {
ret = -ENOMEM;
goto out;
@@ -2261,11 +2255,10 @@ static int sh_mdio_init(struct net_devic
bitbang->ctrl.ops = &bb_ops;
/* MII controller setting */
- mdp->bitbang = bitbang;
mdp->mii_bus = alloc_mdio_bitbang(&bitbang->ctrl);
if (!mdp->mii_bus) {
ret = -ENOMEM;
- goto out_free_bitbang;
+ goto out;
}
/* Hook up MII support for ethtool */
@@ -2275,7 +2268,9 @@ static int sh_mdio_init(struct net_devic
mdp->pdev->name, id);
/* PHY IRQ */
- mdp->mii_bus->irq = kmalloc(sizeof(int)*PHY_MAX_ADDR, GFP_KERNEL);
+ mdp->mii_bus->irq = devm_kzalloc(&ndev->dev,
+ sizeof(int) * PHY_MAX_ADDR,
+ GFP_KERNEL);
if (!mdp->mii_bus->irq) {
ret = -ENOMEM;
goto out_free_bus;
@@ -2287,21 +2282,15 @@ static int sh_mdio_init(struct net_devic
/* register mdio bus */
ret = mdiobus_register(mdp->mii_bus);
if (ret)
- goto out_free_irq;
+ goto out_free_bus;
dev_set_drvdata(&ndev->dev, mdp->mii_bus);
return 0;
-out_free_irq:
- kfree(mdp->mii_bus->irq);
-
out_free_bus:
free_mdio_bitbang(mdp->mii_bus);
-out_free_bitbang:
- kfree(bitbang);
-
out:
return ret;
}
@@ -2389,10 +2378,9 @@ static int sh_eth_drv_probe(struct platf
mdp = netdev_priv(ndev);
mdp->num_tx_ring = TX_RING_SIZE;
mdp->num_rx_ring = RX_RING_SIZE;
- mdp->addr = ioremap(res->start, resource_size(res));
- if (mdp->addr == NULL) {
- ret = -ENOMEM;
- dev_err(&pdev->dev, "ioremap failed.\n");
+ mdp->addr = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(mdp->addr)) {
+ ret = PTR_ERR(mdp->addr);
goto out_release;
}
@@ -2438,11 +2426,9 @@ static int sh_eth_drv_probe(struct platf
ret = -ENODEV;
goto out_release;
}
- mdp->tsu_addr = ioremap(rtsu->start,
- resource_size(rtsu));
- if (mdp->tsu_addr == NULL) {
- ret = -ENOMEM;
- dev_err(&pdev->dev, "TSU ioremap failed.\n");
+ mdp->tsu_addr = devm_ioremap_resource(&pdev->dev, rtsu);
+ if (IS_ERR(mdp->tsu_addr)) {
+ ret = PTR_ERR(mdp->tsu_addr);
goto out_release;
}
mdp->port = devno % 2;
@@ -2483,10 +2469,6 @@ out_unregister:
out_release:
/* net_dev free */
- if (mdp && mdp->addr)
- iounmap(mdp->addr);
- if (mdp && mdp->tsu_addr)
- iounmap(mdp->tsu_addr);
if (ndev)
free_netdev(ndev);
@@ -2497,14 +2479,10 @@ out:
static int sh_eth_drv_remove(struct platform_device *pdev)
{
struct net_device *ndev = platform_get_drvdata(pdev);
- struct sh_eth_private *mdp = netdev_priv(ndev);
- if (mdp->cd->tsu)
- iounmap(mdp->tsu_addr);
sh_mdio_release(ndev);
unregister_netdev(ndev);
pm_runtime_disable(&pdev->dev);
- iounmap(mdp->addr);
free_netdev(ndev);
platform_set_drvdata(pdev, NULL);
Index: net-next/drivers/net/ethernet/renesas/sh_eth.h
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.h
+++ net-next/drivers/net/ethernet/renesas/sh_eth.h
@@ -705,7 +705,6 @@ struct sh_eth_private {
const u16 *reg_offset;
void __iomem *addr;
void __iomem *tsu_addr;
- struct bb_info *bitbang;
u32 num_rx_ring;
u32 num_tx_ring;
dma_addr_t rx_desc_dma;
^ 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