* Re: PMTU discovery is broken on kernel 3.7.1 for UDP sockets
From: Ben Hutchings @ 2012-12-19 19:37 UTC (permalink / raw)
To: Yurij M. Plotnikov; +Cc: netdev, Alexandra N. Kossovsky
In-Reply-To: <50D1CECE.7090706@oktetlabs.ru>
On Wed, 2012-12-19 at 18:27 +0400, Yurij M. Plotnikov wrote:
> On 12/19/12 17:35, Ben Hutchings wrote:
> > On Wed, 2012-12-19 at 17:10 +0400, Yurij M. Plotnikov wrote:
> >
> >> On kernel 3.7.1 I get strange behaviour of IP_MTU_DISCOVER socket
> >> option. The behaviour in case of IP_PMTUDISC_DO and IP_PMTUDISC_WANT
> >> values of IP_MTU_DISCOVER socket option on SOCK_DGRAM socket are the
> >> same and packet is always sent with "Don't Fragment" bit in case of
> >> IP_PMTUDISC_WANT. Also, the value of IP_MTU socket option is not updated.
> >>
> > You could try reverting:
> >
> > commit ee9a8f7ab2edf801b8b514c310455c94acc232f6
> > Author: Steffen Klassert<steffen.klassert@secunet.com>
> > Date: Mon Oct 8 00:56:54 2012 +0000
> >
> > ipv4: Don't report stale pmtu values to userspace
> >
> > We report cached pmtu values even if they are already expired.
> > Change this to not report these values after they are expired
> > and fix a race in the expire time calculation, as suggested by
> > Eric Dumazet.
> >
> > Still, PMTU information is not supposed to expire for 10 minutes...
> >
> >
> With reverted commit there is no such problem on 3.7.1: IP_MTU is
> updated and DF is set only for the first packet in case of
> IP_PMTUDISC_WANT.
[...]
So it looks like something is going wrong with the expiry calculation
here.
This change shouldn't affect the PMTU actually used by the kernel, but
could affect Onload since that relies on netlink route updates to keep
in synch. You didn't say you were using Onload, but if you are then we
should not bother netdev with this until we can demonstrate a problem
that involves only the kernel stack.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH V2 00/12] Add basic VLAN support to bridges
From: Shmulik Ladkani @ 2012-12-19 19:37 UTC (permalink / raw)
To: vyasevic; +Cc: netdev, shemminger, davem, or.gerlitz, jhs, mst
In-Reply-To: <50D1CB76.50202@redhat.com>
Hi Vlad,
On Wed, 19 Dec 2012 09:13:10 -0500 Vlad Yasevich <vyasevic@redhat.com> wrote:
> > Why the "untagged vlan" is per-bridge global?
> It's not. There is a per port untagged pointer where you can designate
> which VLAN is untagged/native on a port.
Ok (misinterpreted the text in the cover letter).
> > 802.1q switches usually allow conifguring per-vlan, per-port
> > tagged/untagged egress policy: each vid has its port membership map and
> > an accompanying port egress-policy map.
> > This gives great flexibility defining all sorts of configurations.
>
> Right, and that's what's provided here.
> * Each VLAN has port membership map (net_bridge_vlan.portgroup).
> * Each port has a list of vlans configured as well
> (net_port_vlan.vlan_list).
> * Each port also has a single vlan that can be untagged
> (net_bridge_port.untagged).
> * The bridge also has a single untagged vlan (net_bridge.untagged)
>
> The limitation (in switches as well) is that only a single VLAN
> may be untagged on any 1 port.
Switches usually allow you to configure each port's egress policy per
vlan, and allow you to configure multiple vlans to _egress_ untagged
on a port.
> If you have more then 1, you don't know
> which VLAN the untagged traffic belongs to.
The port's PVID uniquely determines VID to associate with the frame
during _ingress_ on that port - in the case frame arrived untagged.
This is unrelated to whether a frame having a specific VID would _egress_
tagged or untagged on that port.
> > Personally, I'd prefer a fully flexible vlan bridge allowing all sorts
> > of configurations (as available in 802.1q switches).
> >
> > What's the reason limiting such configurations?
>
> So, what do you see that's missing?
I suspect some configurations wouldn't be possible at current design,
please let me know what do you think.
Take for example such a configuration:
+---+---+
| | |
p1 p2 p3
A bridge with 3 ports: p1 p2 p3.
(the bridge interface itself is irrelevant for this discussion)
This setup expects all traffic at those ports to be untagged.
I'd like p1 to be bridged to p2, but not to p3.
I'd like p3 to be bridged to p2, but not to p1.
Set the following:
p1 - PVID is 1
member of VLANs 1(egress untagged), 2(egress untagged)
p3 - PVID is 3
member of VLANs 3(egress untagged), 2(egress untagged)
p2 - PVID is 2
member of VLANs 1,2,3 (all egress untagged)
Or putting it differently:
VLAN 1 ports membership: p1, p2
egress policy: U U
VLAN 2 ports membership: p1, p2, p3
egress policy: U U U
VLAN 3 ports membership: p2, p3
egress policy: U U
Now, untagged traffic arriving at p1 will be assigned its PVID, which
is 1, an thus forced to egress via p2 (the only other member of VLAN 1).
Upon egress on p2, it will egress untagged.
(similarly for ingress in p3, only egress at p2 is possible, again
untagged).
If untagged traffic arrives at p2, it will be assigned its PVID, which
is 2, and thus it may egress on either p1 or p3 (they are both members
of VLAN 2).
Actual port of egress is according to FDB match.
Again egress would be untagged.
This setup might sound exotic, but similar patterns may be used in
reality.
Although the example is synthetic and simplistic, still it demonstrates
the vast flexibility allowed by a 802.1q bridge.
The bridge constructs needed for supporting such setups are:
- per port: PVID
- per VLAN: port membership map
- per VLAN: port egress policy map
I agree, tools other than a vlan bridge may implement such setups, but
using the vlan bridge would be preferred, mainly due to the simplicity.
Regards,
Shmulik
^ permalink raw reply
* [PATCH] 8139cp: Prevent dev_close/cp_interrupt race on MTU change
From: John Greene @ 2012-12-19 19:47 UTC (permalink / raw)
To: netdev; +Cc: John Greene, David S. Miller, David Woodhouse
commit: cb64edb6b89491edfdbae52ba7db9a8b8391d339 upstream
Above commit may introduce a race between cp_interrupt and dev_close
/ change MTU / dev_open up state. Changes cp_interrupt to tolerate
this. Change spin_locking in cp_interrupt to avoid possible
but unobserved race.
Reported-by: "Francois Romieu" <romieu@fr.zoreil.com>
Tested on virtual hardware, Tx MTU size up to 4096, max tx payload
was ping -s 4068 for MTU of 4096. No real hardware, need test
assist.
Signed-off-by: "John Greene" <jogreene@redhat.com>
CC: "David S. Miller" <davem@davemloft.net>
CC: "David Woodhouse" <David.Woodhouse@intel.com>
---
drivers/net/ethernet/realtek/8139cp.c | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/realtek/8139cp.c b/drivers/net/ethernet/realtek/8139cp.c
index 0da3f5e..585c35c 100644
--- a/drivers/net/ethernet/realtek/8139cp.c
+++ b/drivers/net/ethernet/realtek/8139cp.c
@@ -577,28 +577,30 @@ static irqreturn_t cp_interrupt (int irq, void *dev_instance)
{
struct net_device *dev = dev_instance;
struct cp_private *cp;
+ int handled = 0;
u16 status;
if (unlikely(dev == NULL))
return IRQ_NONE;
cp = netdev_priv(dev);
+ spin_lock(&cp->lock);
+
status = cpr16(IntrStatus);
if (!status || (status == 0xFFFF))
- return IRQ_NONE;
+ goto out_unlock;
+
+ handled = 1;
netif_dbg(cp, intr, dev, "intr, status %04x cmd %02x cpcmd %04x\n",
status, cpr8(Cmd), cpr16(CpCmd));
cpw16(IntrStatus, status & ~cp_rx_intr_mask);
- spin_lock(&cp->lock);
-
/* close possible race's with dev_close */
if (unlikely(!netif_running(dev))) {
cpw16(IntrMask, 0);
- spin_unlock(&cp->lock);
- return IRQ_HANDLED;
+ goto out_unlock;
}
if (status & (RxOK | RxErr | RxEmpty | RxFIFOOvr))
@@ -612,7 +614,6 @@ static irqreturn_t cp_interrupt (int irq, void *dev_instance)
if (status & LinkChg)
mii_check_media(&cp->mii_if, netif_msg_link(cp), false);
- spin_unlock(&cp->lock);
if (status & PciErr) {
u16 pci_status;
@@ -625,7 +626,10 @@ static irqreturn_t cp_interrupt (int irq, void *dev_instance)
/* TODO: reset hardware */
}
- return IRQ_HANDLED;
+out_unlock:
+ spin_unlock(&cp->lock);
+
+ return IRQ_RETVAL(handled);
}
#ifdef CONFIG_NET_POLL_CONTROLLER
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH V2 00/12] Add basic VLAN support to bridges
From: Vlad Yasevich @ 2012-12-19 20:03 UTC (permalink / raw)
To: Shmulik Ladkani; +Cc: netdev, shemminger, davem, or.gerlitz, jhs, mst
In-Reply-To: <20121219213716.778d6449.shmulik.ladkani@gmail.com>
On 12/19/2012 02:37 PM, Shmulik Ladkani wrote:
> Hi Vlad,
>
> On Wed, 19 Dec 2012 09:13:10 -0500 Vlad Yasevich <vyasevic@redhat.com> wrote:
>>> Why the "untagged vlan" is per-bridge global?
>> It's not. There is a per port untagged pointer where you can designate
>> which VLAN is untagged/native on a port.
>
> Ok (misinterpreted the text in the cover letter).
>
>>> 802.1q switches usually allow conifguring per-vlan, per-port
>>> tagged/untagged egress policy: each vid has its port membership map and
>>> an accompanying port egress-policy map.
>>> This gives great flexibility defining all sorts of configurations.
>>
>> Right, and that's what's provided here.
>> * Each VLAN has port membership map (net_bridge_vlan.portgroup).
>> * Each port has a list of vlans configured as well
>> (net_port_vlan.vlan_list).
>> * Each port also has a single vlan that can be untagged
>> (net_bridge_port.untagged).
>> * The bridge also has a single untagged vlan (net_bridge.untagged)
>>
>> The limitation (in switches as well) is that only a single VLAN
>> may be untagged on any 1 port.
>
> Switches usually allow you to configure each port's egress policy per
> vlan, and allow you to configure multiple vlans to _egress_ untagged
> on a port.
>
>> If you have more then 1, you don't know
>> which VLAN the untagged traffic belongs to.
>
> The port's PVID uniquely determines VID to associate with the frame
> during _ingress_ on that port - in the case frame arrived untagged.
>
> This is unrelated to whether a frame having a specific VID would _egress_
> tagged or untagged on that port.
>
Ahh... I see what you mean. You would like to separate
ingress policy and egress policy with regard to how tags are applied...
I haven't seen that type of config before.
I did say "Basic VLAN support". :)
In this set of patches ingress and egress policies are hardcoded the same...
So, consider that what I am calling "untagged" in this series is
really vlan associated with PVID. To change the egress policy, we
could add an untagged bitmap into the vlan. Then the bitmap from the
vlan would determine the egress policy. If the port is in the "tagged"
bitmap, frame leaves tagged. If the port is in the "untagged" bitmap,
frame leaves untagged.
The code to make this would would be simple enough. The more
interesting part would be the configuration :)
>>> Personally, I'd prefer a fully flexible vlan bridge allowing all sorts
>>> of configurations (as available in 802.1q switches).
>>>
>>> What's the reason limiting such configurations?
>>
>> So, what do you see that's missing?
>
[ snip good example ]
>
> The bridge constructs needed for supporting such setups are:
> - per port: PVID
> - per VLAN: port membership map
> - per VLAN: port egress policy map
Ok, so from above, membership map is the exiting port_bitmap. Egress
policy map could be new untagged_bitmap. We wouldn't need a tagged
policy map since a port can't be "in egress policy, but not in
membership map".
Membership port_bitmap is consulted on egress for basic forward/drop
decision (just as it is now). Egress policy (untagged bitmap) is
consulted to see how the forwarding is done.
Sounds about right? If so, I could probably work something up.
Will probably leave the configuration for later as that might take a bit
longer to figure out.
-vlad
>
> I agree, tools other than a vlan bridge may implement such setups, but
> using the vlan bridge would be preferred, mainly due to the simplicity.
>
> Regards,
> Shmulik
>
^ permalink raw reply
* Re: pull request: wireless 2012-12-19
From: David Miller @ 2012-12-19 20:39 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20121219183220.GB1912@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Wed, 19 Dec 2012 13:32:20 -0500
> Please pull these fixes for the 3.8 stream.
>
> Gabor Juhos provides and rt2x00 fix to properly clear-out the skb->cb
> for reporting tx_status. Recent changes made this necessary where it
> previously was not.
>
> Vladimir Kondratiev gives us a fix for a build issue that caused some
> ath9k devices to be skipped in the build based on unrelated config
> choices.
Pulled, thanks John.
^ permalink raw reply
* Re: [PATCH] 8139cp: Prevent dev_close/cp_interrupt race on MTU change
From: David Miller @ 2012-12-19 20:40 UTC (permalink / raw)
To: jogreene; +Cc: netdev, David.Woodhouse
In-Reply-To: <1355946468-3290-1-git-send-email-jogreene@redhat.com>
From: John Greene <jogreene@redhat.com>
Date: Wed, 19 Dec 2012 14:47:48 -0500
> commit: cb64edb6b89491edfdbae52ba7db9a8b8391d339 upstream
>
> Above commit may introduce a race between cp_interrupt and dev_close
> / change MTU / dev_open up state. Changes cp_interrupt to tolerate
> this. Change spin_locking in cp_interrupt to avoid possible
> but unobserved race.
>
> Reported-by: "Francois Romieu" <romieu@fr.zoreil.com>
>
> Tested on virtual hardware, Tx MTU size up to 4096, max tx payload
> was ping -s 4068 for MTU of 4096. No real hardware, need test
> assist.
>
> Signed-off-by: "John Greene" <jogreene@redhat.com>
You sent this as a "request for testing" last week, but I saw
no testing on real hardware whatsoever.
^ permalink raw reply
* Re: [PATCH 1/2] qlcnic: fix unused variable warnings
From: David Miller @ 2012-12-19 20:43 UTC (permalink / raw)
To: sony.chacko; +Cc: netdev, Dept_NX_Linux_NIC_Driver, shahed.shaikh
In-Reply-To: <1355853591-29917-2-git-send-email-sony.chacko@qlogic.com>
From: Sony Chacko <sony.chacko@qlogic.com>
Date: Tue, 18 Dec 2012 12:59:50 -0500
> From: Shahed Shaikh <shahed.shaikh@qlogic.com>
>
> qlcnic_hw.c:370: warning: variable cmd_desc set but not used
> qlcnic_hw.c:368: warning: variable consumer set but not used
> qlcnic_main.c:448: warning: variable ref_count set but not used
> qlcnic_main.c:534: warning: variable mem_base set but not used
> qlcnic_ctx.c:137: warning: variable tmp_tmpl set but not used
> qlcnic_ctx.c:133: warning: variable version set but not used
> qlcnic_minidump.c:200: warning: variable opcode set but not used
>
> Signed-off-by: Shahed Shaikh <shahed.shaikh@qlogic.com>
> Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] qlcnic: update driver version
From: David Miller @ 2012-12-19 20:43 UTC (permalink / raw)
To: sony.chacko; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1355853591-29917-3-git-send-email-sony.chacko@qlogic.com>
From: Sony Chacko <sony.chacko@qlogic.com>
Date: Tue, 18 Dec 2012 12:59:51 -0500
> From: Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
>
> Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ksz884x: fix receive polling race condition
From: David Miller @ 2012-12-19 20:45 UTC (permalink / raw)
To: buytenh; +Cc: Tristram.Ha, dannyfeng, netdev, cphealy
In-Reply-To: <20121218135700.GT23447@wantstofly.org>
From: Lennert Buytenhek <buytenh@wantstofly.org>
Date: Tue, 18 Dec 2012 14:57:00 +0100
> The ksz884x driver does receive processing in a custom tasklet, and
> seems to be assuming that since it takes its private interface spinlock
> with spin_lock_irq(), it won't be running concurrently with its own
> interrupt handler, as it cannot be preempted by it, but since its
> interrupt handler doesn't do any locking whatsoever, the receive
> processing tasklet and interrupt handler can end up running concurrently
> on different CPUs.
>
> As a result of this, the ksz884x receive path ends up locking up fairly
> easily, when the receive processing tasklet's reenabling of receive
> interrupts (due to it being done with polling the receive ring) races
> with the interrupt handler's disabling of receive interrupts (due to a
> new receive interrupt coming in) resulting in the receive interrupt
> being masked but the receive processing tasklet not being scheduled.
>
> Fix this by making the ksz884x interrupt handler take its private
> interface spinlock. This requires upgrading the spin_lock() in the
> transmit cleanup tasklet to a spin_lock_irq(), as otherwise the IRQ
> handler can preempt transmit cleanup and deadlock the system, but
> with those two changes, no more receive lockups have been observed.
>
> Reported-by: Chris Healy <cphealy@gmail.com>
> Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/3] usbnet: handle PM failure gracefully
From: David Miller @ 2012-12-19 20:47 UTC (permalink / raw)
To: oliver; +Cc: netdev, oneukum
In-Reply-To: <1355841929-983-1-git-send-email-oliver@neukum.org>
From: Oliver Neukum <oliver@neukum.org>
Date: Tue, 18 Dec 2012 15:45:29 +0100
> If a device fails to do remote wakeup, this is no reason
> to abort an open totally. This patch just continues without
> runtime PM.
>
> Signed-off-by: Oliver Neukum <oneukum@suse.de>
Applied.
^ permalink raw reply
* Re: [PATCH 2/3] usbnet: generic manage_power()
From: David Miller @ 2012-12-19 20:47 UTC (permalink / raw)
To: oliver; +Cc: netdev, oneukum
In-Reply-To: <1355841952-1025-1-git-send-email-oliver@neukum.org>
From: Oliver Neukum <oliver@neukum.org>
Date: Tue, 18 Dec 2012 15:45:52 +0100
> Centralise common code for manage_power() in usbnet
> by making a generic simple implementation
>
> Signed-off-by: Oliver Neukum <oneukum@suse.de>
Applied.
^ permalink raw reply
* Re: [PATCH 3/3] use generic usbnet_manage_power()
From: David Miller @ 2012-12-19 20:47 UTC (permalink / raw)
To: oliver; +Cc: netdev, oneukum
In-Reply-To: <1355841972-1068-1-git-send-email-oliver@neukum.org>
From: Oliver Neukum <oliver@neukum.org>
Date: Tue, 18 Dec 2012 15:46:12 +0100
> This covers the drivers that can use a primitive
> implementation.
>
> Signed-off-by: Oliver Neukum <oneukum@suse.de>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] drivers/net: Use of_match_ptr() macro in smc91x.c
From: David Miller @ 2012-12-19 20:50 UTC (permalink / raw)
To: sachin.kamat; +Cc: netdev, steve.glendinning, patches, nico
In-Reply-To: <1355915830-29481-1-git-send-email-sachin.kamat@linaro.org>
From: Sachin Kamat <sachin.kamat@linaro.org>
Date: Wed, 19 Dec 2012 16:47:09 +0530
> This eliminates having an #ifdef returning NULL for the case
> when OF is disabled.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] drivers/net: Use of_match_ptr() macro in smsc911x.c
From: David Miller @ 2012-12-19 20:50 UTC (permalink / raw)
To: sachin.kamat; +Cc: netdev, steve.glendinning, patches, nico
In-Reply-To: <1355915830-29481-2-git-send-email-sachin.kamat@linaro.org>
From: Sachin Kamat <sachin.kamat@linaro.org>
Date: Wed, 19 Dec 2012 16:47:10 +0530
> Add CONFIG_OF guard and use of_match_ptr macro.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Applied.
^ permalink raw reply
* Re: [PATCH net] net: qmi_wwan: add ZTE MF880
From: David Miller @ 2012-12-19 20:50 UTC (permalink / raw)
To: bjorn-yOkvZcmFvRU
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1355926551-30316-1-git-send-email-bjorn-yOkvZcmFvRU@public.gmane.org>
From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
Date: Wed, 19 Dec 2012 15:15:51 +0100
> The driver description files gives these names to the vendor specific
> functions on this modem:
>
> diag: VID_19D2&PID_0284&MI_00
> nmea: VID_19D2&PID_0284&MI_01
> at: VID_19D2&PID_0284&MI_02
> mdm: VID_19D2&PID_0284&MI_03
> net: VID_19D2&PID_0284&MI_04
>
> Signed-off-by: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] bridge: Do not unregister all PF_BRIDGE rtnl operations
From: David Miller @ 2012-12-19 20:50 UTC (permalink / raw)
To: vyasevic; +Cc: netdev, shemminger
In-Reply-To: <1355944428-32051-1-git-send-email-vyasevic@redhat.com>
From: Vlad Yasevich <vyasevic@redhat.com>
Date: Wed, 19 Dec 2012 14:13:48 -0500
> Bridge fdb and link rtnl operations are registered in
> core/rtnetlink. Bridge mdb operations are registred
> in bridge/mdb. When removing bridge module, do not
> unregister ALL PF_BRIDGE ops since that would remove
> the ops from rtnetlink as well. Do remove mdb ops when
> bridge is destroyed.
>
> Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH] bridge: Correctly encode addresses when dumping mdb entries
From: David Miller @ 2012-12-19 20:50 UTC (permalink / raw)
To: vyasevic; +Cc: netdev, shemminger
In-Reply-To: <1355867648-17316-1-git-send-email-vyasevic@redhat.com>
From: Vlad Yasevich <vyasevic@redhat.com>
Date: Tue, 18 Dec 2012 16:54:08 -0500
> When dumping mdb table, set the addresses the kernel returns
> based on the address protocol type.
>
> Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ipv6: addrconf.c: remove unnecessary "if"
From: David Miller @ 2012-12-19 20:51 UTC (permalink / raw)
To: dinggnu; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <1355868536-1622-1-git-send-email-dinggnu@gmail.com>
From: Cong Ding <dinggnu@gmail.com>
Date: Tue, 18 Dec 2012 23:08:56 +0100
> the value of err is always negative if it goes to errout, so we don't need to
> check the value of err.
>
> Signed-off-by: Cong Ding <dinggnu@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] 8139cp: Prevent dev_close/cp_interrupt race on MTU change
From: David Woodhouse @ 2012-12-19 20:55 UTC (permalink / raw)
To: David Miller; +Cc: jogreene, netdev
In-Reply-To: <20121219.124014.891279563982531558.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 438 bytes --]
On Wed, 2012-12-19 at 12:40 -0800, David Miller wrote:
> You sent this as a "request for testing" last week, but I saw
> no testing on real hardware whatsoever.
Thanks for the reminder :)
Seems to work fine here. I haven't confirmed whether I actually see the
race or not but changing MTU on a live device works fine, even when it's
being ping-flooded.
Tested-by: David Woodhouse <David.Woodhouse@intel.com>
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply
* Re: TCP delayed ACK heuristic
From: David Miller @ 2012-12-19 20:59 UTC (permalink / raw)
To: rick.jones2
Cc: amwang, David.Laight, netdev, greearb, eric.dumazet, shemminger,
tgraf
In-Reply-To: <50D209E9.2000504@hp.com>
From: Rick Jones <rick.jones2@hp.com>
Date: Wed, 19 Dec 2012 10:39:37 -0800
> On 12/18/2012 11:00 PM, Cong Wang wrote:
>> On Tue, 2012-12-18 at 16:39 +0000, David Laight wrote:
>>> There are problems with only implementing the acks
>>> specified by RFC1122.
>>
>> Yeah, the problem is if we can violate this RFC for getting better
>> performance. Or it is just a no-no?
>>
>> Although RFC 2525 mentions this as "Stretch ACK Violation", I am still
>> not sure if that means we can violate RFC1122 legally.
>
> The term used in RFC1122 is "SHOULD" not "MUST." Same for RFC2525
> when it talks about "Stretch ACK Violation." A TCP stack may have
> behaviour which differs from a SHOULD so long as there is a reasonable
> reason for it.
Yes, but RFC2525 makes it very clear why we should not even
consider doing crap like this.
ACKs are the only information we have to detect loss.
And, for the same reasons that TCP VEGAS is fundamentally broken, we
cannot measure the pipe or some other receiver-side-visible piece of
information to determine when it's "safe" to stretch ACK.
And even if it's "safe", we should not do it so that losses are
accurately detected and we don't spuriously retransmit.
The only way to know when the bandwidth increases is to "test" it, by
sending more and more packets until drops happen. That's why all
successful congestion control algorithms must operate on explicited
tested pieces of information.
Similarly, it's not really possible to universally know if it's safe
to stretch ACK or not.
Can we please drop this idea? It has zero value and all downside as
far as I'm concerned.
Thanks.
^ permalink raw reply
* [PATCH 2/4] solos-pci: remove superfluous debug output
From: David Woodhouse @ 2012-12-19 21:01 UTC (permalink / raw)
To: netdev; +Cc: Nathan Williams
In-Reply-To: <1355950881-31550-1-git-send-email-dwmw2@infradead.org>
From: Nathan Williams <nathan@traverse.com.au>
Signed-off-by: Nathan Williams <nathan@traverse.com.au>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
---
drivers/atm/solos-pci.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/atm/solos-pci.c b/drivers/atm/solos-pci.c
index 473d808..50e5c56 100644
--- a/drivers/atm/solos-pci.c
+++ b/drivers/atm/solos-pci.c
@@ -452,7 +452,6 @@ static ssize_t console_show(struct device *dev, struct device_attribute *attr,
len = skb->len;
memcpy(buf, skb->data, len);
- dev_dbg(&card->dev->dev, "len: %d\n", len);
kfree_skb(skb);
return len;
--
1.8.0.1
^ permalink raw reply related
* [PATCH 1/4] solos-pci: add GPIO support for newer versions on Geos board
From: David Woodhouse @ 2012-12-19 21:01 UTC (permalink / raw)
To: netdev; +Cc: Nathan Williams
From: Nathan Williams <nathan@traverse.com.au>
dwmw2: Tidy up a little, simpler matching on which GPIO is being accessed,
only register on newer boards, register under PCI device instead of
duplicating them under each ATM device.
Signed-off-by: Nathan Williams <nathan@traverse.com.au>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
---
drivers/atm/solos-pci.c | 105 ++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 105 insertions(+)
diff --git a/drivers/atm/solos-pci.c b/drivers/atm/solos-pci.c
index c909b7b..473d808 100644
--- a/drivers/atm/solos-pci.c
+++ b/drivers/atm/solos-pci.c
@@ -56,6 +56,7 @@
#define FLASH_BUSY 0x60
#define FPGA_MODE 0x5C
#define FLASH_MODE 0x58
+#define GPIO_STATUS 0x54
#define TX_DMA_ADDR(port) (0x40 + (4 * (port)))
#define RX_DMA_ADDR(port) (0x30 + (4 * (port)))
@@ -498,6 +499,78 @@ static ssize_t console_store(struct device *dev, struct device_attribute *attr,
return err?:count;
}
+struct geos_gpio_attr {
+ struct device_attribute attr;
+ int offset;
+};
+
+#define SOLOS_GPIO_ATTR(_name, _mode, _show, _store, _offset) \
+ struct geos_gpio_attr gpio_attr_##_name = { \
+ .attr = __ATTR(_name, _mode, _show, _store), \
+ .offset = _offset }
+
+static ssize_t geos_gpio_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct pci_dev *pdev = container_of(dev, struct pci_dev, dev);
+ struct geos_gpio_attr *gattr = container_of(attr, struct geos_gpio_attr, attr);
+ struct solos_card *card = pci_get_drvdata(pdev);
+ uint32_t data32;
+
+ if (count != 1 && (count != 2 || buf[1] != '\n'))
+ return -EINVAL;
+
+ spin_lock_irq(&card->param_queue_lock);
+ data32 = ioread32(card->config_regs + GPIO_STATUS);
+ if (buf[0] == '1') {
+ data32 |= 1 << gattr->offset;
+ iowrite32(data32, card->config_regs + GPIO_STATUS);
+ } else if (buf[0] == '0') {
+ data32 &= ~(1 << gattr->offset);
+ iowrite32(data32, card->config_regs + GPIO_STATUS);
+ } else {
+ count = -EINVAL;
+ }
+ spin_lock_irq(&card->param_queue_lock);
+ return count;
+}
+
+static ssize_t geos_gpio_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct pci_dev *pdev = container_of(dev, struct pci_dev, dev);
+ struct geos_gpio_attr *gattr = container_of(attr, struct geos_gpio_attr, attr);
+ struct solos_card *card = pci_get_drvdata(pdev);
+ uint32_t data32;
+
+ data32 = ioread32(card->config_regs + GPIO_STATUS);
+ data32 = (data32 >> gattr->offset) & 1;
+
+ return sprintf(buf, "%d\n", data32);
+}
+
+static ssize_t hardware_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct pci_dev *pdev = container_of(dev, struct pci_dev, dev);
+ struct geos_gpio_attr *gattr = container_of(attr, struct geos_gpio_attr, attr);
+ struct solos_card *card = pci_get_drvdata(pdev);
+ uint32_t data32;
+
+ data32 = ioread32(card->config_regs + GPIO_STATUS);
+ switch (gattr->offset) {
+ case 0:
+ /* HardwareVersion */
+ data32 = data32 & 0x1F;
+ break;
+ case 1:
+ /* HardwareVariant */
+ data32 = (data32 >> 5) & 0x0F;
+ break;
+ }
+ return sprintf(buf, "%d\n", data32);
+}
+
static DEVICE_ATTR(console, 0644, console_show, console_store);
@@ -506,6 +579,14 @@ static DEVICE_ATTR(console, 0644, console_show, console_store);
#include "solos-attrlist.c"
+static SOLOS_GPIO_ATTR(GPIO1, 0644, geos_gpio_show, geos_gpio_store, 9);
+static SOLOS_GPIO_ATTR(GPIO2, 0644, geos_gpio_show, geos_gpio_store, 10);
+static SOLOS_GPIO_ATTR(GPIO3, 0644, geos_gpio_show, geos_gpio_store, 11);
+static SOLOS_GPIO_ATTR(GPIO4, 0644, geos_gpio_show, geos_gpio_store, 12);
+static SOLOS_GPIO_ATTR(GPIO5, 0644, geos_gpio_show, geos_gpio_store, 13);
+static SOLOS_GPIO_ATTR(PushButton, 0444, geos_gpio_show, NULL, 14);
+static SOLOS_GPIO_ATTR(HardwareVersion, 0444, hardware_show, NULL, 0);
+static SOLOS_GPIO_ATTR(HardwareVariant, 0444, hardware_show, NULL, 1);
#undef SOLOS_ATTR_RO
#undef SOLOS_ATTR_RW
@@ -522,6 +603,23 @@ static struct attribute_group solos_attr_group = {
.name = "parameters",
};
+static struct attribute *gpio_attrs[] = {
+ &gpio_attr_GPIO1.attr.attr,
+ &gpio_attr_GPIO2.attr.attr,
+ &gpio_attr_GPIO3.attr.attr,
+ &gpio_attr_GPIO4.attr.attr,
+ &gpio_attr_GPIO5.attr.attr,
+ &gpio_attr_PushButton.attr.attr,
+ &gpio_attr_HardwareVersion.attr.attr,
+ &gpio_attr_HardwareVariant.attr.attr,
+ NULL
+};
+
+static struct attribute_group gpio_attr_group = {
+ .attrs = gpio_attrs,
+ .name = "gpio",
+};
+
static int flash_upgrade(struct solos_card *card, int chip)
{
const struct firmware *fw;
@@ -1179,6 +1277,10 @@ static int fpga_probe(struct pci_dev *dev, const struct pci_device_id *id)
if (err)
goto out_free_irq;
+ if (card->fpga_version >= DMA_SUPPORTED &&
+ sysfs_create_group(&card->dev->dev.kobj, &gpio_attr_group))
+ dev_err(&card->dev->dev, "Could not register parameter group for GPIOs\n");
+
return 0;
out_free_irq:
@@ -1289,6 +1391,9 @@ static void fpga_remove(struct pci_dev *dev)
iowrite32(1, card->config_regs + FPGA_MODE);
(void)ioread32(card->config_regs + FPGA_MODE);
+ if (card->fpga_version >= DMA_SUPPORTED)
+ sysfs_remove_group(&card->dev->dev.kobj, &gpio_attr_group);
+
atm_remove(card);
free_irq(dev->irq, card);
--
1.8.0.1
^ permalink raw reply related
* [PATCH 3/4] solos-pci: add firmware upgrade support for new models
From: David Woodhouse @ 2012-12-19 21:01 UTC (permalink / raw)
To: netdev; +Cc: Nathan Williams
In-Reply-To: <1355950881-31550-1-git-send-email-dwmw2@infradead.org>
From: Nathan Williams <nathan@traverse.com.au>
Signed-off-by: Nathan Williams <nathan@traverse.com.au>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
---
drivers/atm/solos-pci.c | 53 +++++++++++++++++++++++++++++++++++++++----------
1 file changed, 42 insertions(+), 11 deletions(-)
diff --git a/drivers/atm/solos-pci.c b/drivers/atm/solos-pci.c
index 50e5c56..aa4f35d 100644
--- a/drivers/atm/solos-pci.c
+++ b/drivers/atm/solos-pci.c
@@ -42,7 +42,8 @@
#include <linux/swab.h>
#include <linux/slab.h>
-#define VERSION "0.07"
+#define VERSION "1.04"
+#define DRIVER_VERSION 0x01
#define PTAG "solos-pci"
#define CONFIG_RAM_SIZE 128
@@ -57,16 +58,20 @@
#define FPGA_MODE 0x5C
#define FLASH_MODE 0x58
#define GPIO_STATUS 0x54
+#define DRIVER_VER 0x50
#define TX_DMA_ADDR(port) (0x40 + (4 * (port)))
#define RX_DMA_ADDR(port) (0x30 + (4 * (port)))
#define DATA_RAM_SIZE 32768
#define BUF_SIZE 2048
#define OLD_BUF_SIZE 4096 /* For FPGA versions <= 2*/
-#define FPGA_PAGE 528 /* FPGA flash page size*/
-#define SOLOS_PAGE 512 /* Solos flash page size*/
-#define FPGA_BLOCK (FPGA_PAGE * 8) /* FPGA flash block size*/
-#define SOLOS_BLOCK (SOLOS_PAGE * 8) /* Solos flash block size*/
+/* Old boards use ATMEL AD45DB161D flash */
+#define ATMEL_FPGA_PAGE 528 /* FPGA flash page size*/
+#define ATMEL_SOLOS_PAGE 512 /* Solos flash page size*/
+#define ATMEL_FPGA_BLOCK (ATMEL_FPGA_PAGE * 8) /* FPGA block size*/
+#define ATMEL_SOLOS_BLOCK (ATMEL_SOLOS_PAGE * 8) /* Solos block size*/
+/* Current boards use M25P/M25PE SPI flash */
+#define SPI_FLASH_BLOCK (256 * 64)
#define RX_BUF(card, nr) ((card->buffers) + (nr)*(card->buffer_size)*2)
#define TX_BUF(card, nr) ((card->buffers) + (nr)*(card->buffer_size)*2 + (card->buffer_size))
@@ -128,6 +133,7 @@ struct solos_card {
int using_dma;
int fpga_version;
int buffer_size;
+ int atmel_flash;
};
@@ -630,16 +636,25 @@ static int flash_upgrade(struct solos_card *card, int chip)
switch (chip) {
case 0:
fw_name = "solos-FPGA.bin";
- blocksize = FPGA_BLOCK;
+ if (card->atmel_flash)
+ blocksize = ATMEL_FPGA_BLOCK;
+ else
+ blocksize = SPI_FLASH_BLOCK;
break;
case 1:
fw_name = "solos-Firmware.bin";
- blocksize = SOLOS_BLOCK;
+ if (card->atmel_flash)
+ blocksize = ATMEL_SOLOS_BLOCK;
+ else
+ blocksize = SPI_FLASH_BLOCK;
break;
case 2:
if (card->fpga_version > LEGACY_BUFFERS){
fw_name = "solos-db-FPGA.bin";
- blocksize = FPGA_BLOCK;
+ if (card->atmel_flash)
+ blocksize = ATMEL_FPGA_BLOCK;
+ else
+ blocksize = SPI_FLASH_BLOCK;
} else {
dev_info(&card->dev->dev, "FPGA version doesn't support"
" daughter board upgrades\n");
@@ -649,7 +664,10 @@ static int flash_upgrade(struct solos_card *card, int chip)
case 3:
if (card->fpga_version > LEGACY_BUFFERS){
fw_name = "solos-Firmware.bin";
- blocksize = SOLOS_BLOCK;
+ if (card->atmel_flash)
+ blocksize = ATMEL_SOLOS_BLOCK;
+ else
+ blocksize = SPI_FLASH_BLOCK;
} else {
dev_info(&card->dev->dev, "FPGA version doesn't support"
" daughter board upgrades\n");
@@ -665,6 +683,9 @@ static int flash_upgrade(struct solos_card *card, int chip)
dev_info(&card->dev->dev, "Flash upgrade starting\n");
+ /* New FPGAs require driver version before permitting flash upgrades */
+ iowrite32(DRIVER_VERSION, card->config_regs + DRIVER_VER);
+
numblocks = fw->size / blocksize;
dev_info(&card->dev->dev, "Firmware size: %zd\n", fw->size);
dev_info(&card->dev->dev, "Number of blocks: %d\n", numblocks);
@@ -694,9 +715,13 @@ static int flash_upgrade(struct solos_card *card, int chip)
/* dev_info(&card->dev->dev, "Set FPGA Flash mode to Block Write\n"); */
iowrite32(((chip * 2) + 1), card->config_regs + FLASH_MODE);
- /* Copy block to buffer, swapping each 16 bits */
+ /* Copy block to buffer, swapping each 16 bits for Atmel flash */
for(i = 0; i < blocksize; i += 4) {
- uint32_t word = swahb32p((uint32_t *)(fw->data + offset + i));
+ uint32_t word;
+ if (card->atmel_flash)
+ word = swahb32p((uint32_t *)(fw->data + offset + i));
+ else
+ word = *(uint32_t *)(fw->data + offset + i);
if(card->fpga_version > LEGACY_BUFFERS)
iowrite32(word, FLASH_BUF + i);
else
@@ -1230,6 +1255,12 @@ static int fpga_probe(struct pci_dev *dev, const struct pci_device_id *id)
db_fpga_upgrade = db_firmware_upgrade = 0;
}
+ /* Stopped using Atmel flash after 0.03-38 */
+ if (fpga_ver < 39)
+ card->atmel_flash = 1;
+ else
+ card->atmel_flash = 0;
+
if (card->fpga_version >= DMA_SUPPORTED) {
pci_set_master(dev);
card->using_dma = 1;
--
1.8.0.1
^ permalink raw reply related
* [PATCH 4/4] solos-pci: ensure all TX packets are aligned to 4 bytes
From: David Woodhouse @ 2012-12-19 21:01 UTC (permalink / raw)
To: netdev; +Cc: David Woodhouse
In-Reply-To: <1355950881-31550-1-git-send-email-dwmw2@infradead.org>
From: David Woodhouse <David.Woodhouse@intel.com>
The FPGA can't handled unaligned DMA (yet). So copy into an aligned buffer,
if skb->data isn't suitably aligned.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
---
drivers/atm/solos-pci.c | 27 +++++++++++++++++++++++----
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/drivers/atm/solos-pci.c b/drivers/atm/solos-pci.c
index aa4f35d..d70abe7 100644
--- a/drivers/atm/solos-pci.c
+++ b/drivers/atm/solos-pci.c
@@ -128,9 +128,11 @@ struct solos_card {
struct sk_buff_head cli_queue[4];
struct sk_buff *tx_skb[4];
struct sk_buff *rx_skb[4];
+ unsigned char *dma_bounce;
wait_queue_head_t param_wq;
wait_queue_head_t fw_wq;
int using_dma;
+ int dma_alignment;
int fpga_version;
int buffer_size;
int atmel_flash;
@@ -1083,7 +1085,12 @@ static uint32_t fpga_tx(struct solos_card *card)
tx_started |= 1 << port;
oldskb = skb; /* We're done with this skb already */
} else if (skb && card->using_dma) {
- SKB_CB(skb)->dma_addr = pci_map_single(card->dev, skb->data,
+ unsigned char *data = skb->data;
+ if ((unsigned long)data & card->dma_alignment) {
+ data = card->dma_bounce + (BUF_SIZE * port);
+ memcpy(data, skb->data, skb->len);
+ }
+ SKB_CB(skb)->dma_addr = pci_map_single(card->dev, data,
skb->len, PCI_DMA_TODEVICE);
card->tx_skb[port] = skb;
iowrite32(SKB_CB(skb)->dma_addr,
@@ -1261,18 +1268,27 @@ static int fpga_probe(struct pci_dev *dev, const struct pci_device_id *id)
else
card->atmel_flash = 0;
+ data32 = ioread32(card->config_regs + PORTS);
+ card->nr_ports = (data32 & 0x000000FF);
+
if (card->fpga_version >= DMA_SUPPORTED) {
pci_set_master(dev);
card->using_dma = 1;
+ if (1) { /* All known FPGA versions so far */
+ card->dma_alignment = 3;
+ card->dma_bounce = kmalloc(card->nr_ports * BUF_SIZE, GFP_KERNEL);
+ if (!card->dma_bounce) {
+ dev_warn(&card->dev->dev, "Failed to allocate DMA bounce buffers\n");
+ /* Fallback to MMIO doesn't work */
+ goto out_unmap_both;
+ }
+ }
} else {
card->using_dma = 0;
/* Set RX empty flag for all ports */
iowrite32(0xF0, card->config_regs + FLAGS_ADDR);
}
- data32 = ioread32(card->config_regs + PORTS);
- card->nr_ports = (data32 & 0x000000FF);
-
pci_set_drvdata(dev, card);
tasklet_init(&card->tlet, solos_bh, (unsigned long)card);
@@ -1319,6 +1335,7 @@ static int fpga_probe(struct pci_dev *dev, const struct pci_device_id *id)
tasklet_kill(&card->tlet);
out_unmap_both:
+ kfree(card->dma_bounce);
pci_set_drvdata(dev, NULL);
pci_iounmap(dev, card->buffers);
out_unmap_config:
@@ -1429,6 +1446,8 @@ static void fpga_remove(struct pci_dev *dev)
free_irq(dev->irq, card);
tasklet_kill(&card->tlet);
+ kfree(card->dma_bounce);
+
/* Release device from reset */
iowrite32(0, card->config_regs + FPGA_MODE);
(void)ioread32(card->config_regs + FPGA_MODE);
--
1.8.0.1
^ permalink raw reply related
* Re: [PATCH 0/2] iputils: minor ninfod and ping6 fixes
From: YOSHIFUJI Hideaki @ 2012-12-19 21:05 UTC (permalink / raw)
To: Jan Synacek; +Cc: netdev
In-Reply-To: <1354868724-15549-1-git-send-email-jsynacek@redhat.com>
Jan Synacek wrote:
> When calling ping6 with the flowlabel (e.g. `ping6 -F 123 ::1'), it exited with
> an error. For some reason, the errno was set when it should not have been. Maybe
> it shouldn't be checked at all, maybe just checking flowlabel for values below
> zero would be enough. I wanted to be on the safer side so I left the errno check
> in there.
>
> Also, I fixed the rest of the unused variables in ninfod.
>
> Jan Synacek (2):
> ninfod: Fix more unused variables.
> ping6: Fix -F switch.
>
> ninfod/ni_ifaddrs.c | 8 +-------
> ping6.c | 3 ++-
> 2 files changed, 3 insertions(+), 8 deletions(-)
>
Fixes committed. Thank you!
--yoshfuji
^ 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