* Re: [PATCH -net v2 2/2] bonding: fix bond_arp_rcv setting and arp validate desync state
From: Marcelo Ricardo Leitner @ 2013-09-10 14:48 UTC (permalink / raw)
To: Nikolay Aleksandrov; +Cc: netdev, fubar, andy, davem
In-Reply-To: <1378504826-18855-3-git-send-email-nikolay@redhat.com>
Em 06-09-2013 19:00, Nikolay Aleksandrov escreveu:
> We make bond_arp_rcv global so it can be used in bond_sysfs if the bond
> interface is up and arp_interval is being changed to a positive value
> and cleared otherwise as per Jay's suggestion.
> This also fixes a problem where bond_arp_rcv was set even though
> arp_validate was disabled while the bond was up by unsetting recv_probe
> in bond_store_arp_validate and respectively setting it if enabled.
>
> Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
> ---
> v2: fix the mode check in store_arp_validate
> I've intentionally left the prototype line >80 chars, let me know if I
> should break it.
>
> drivers/net/bonding/bond_main.c | 4 ++--
> drivers/net/bonding/bond_sysfs.c | 19 ++++++++++++++++---
> drivers/net/bonding/bonding.h | 1 +
> 3 files changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 39e5b1c..72df399 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -2404,8 +2404,8 @@ static void bond_validate_arp(struct bonding *bond, struct slave *slave, __be32
> slave->target_last_arp_rx[i] = jiffies;
> }
>
> -static int bond_arp_rcv(const struct sk_buff *skb, struct bonding *bond,
> - struct slave *slave)
> +int bond_arp_rcv(const struct sk_buff *skb, struct bonding *bond,
> + struct slave *slave)
> {
> struct arphdr *arp = (struct arphdr *)skb->data;
> unsigned char *arp_ptr;
> diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
> index 4e38683..eeab40b 100644
> --- a/drivers/net/bonding/bond_sysfs.c
> +++ b/drivers/net/bonding/bond_sysfs.c
> @@ -349,6 +349,8 @@ static ssize_t bonding_store_mode(struct device *d,
> goto out;
> }
>
> + /* don't cache arp_validate between modes */
> + bond->params.arp_validate = BOND_ARP_VALIDATE_NONE;
> bond->params.mode = new_value;
> bond_set_mode_ops(bond, bond->params.mode);
> pr_info("%s: setting mode to %s (%d).\n",
> @@ -419,8 +421,8 @@ static ssize_t bonding_store_arp_validate(struct device *d,
> struct device_attribute *attr,
> const char *buf, size_t count)
> {
> - int new_value, ret = count;
> struct bonding *bond = to_bond(d);
> + int new_value, ret = count;
>
> if (!rtnl_trylock())
> return restart_syscall();
> @@ -431,7 +433,7 @@ static ssize_t bonding_store_arp_validate(struct device *d,
> ret = -EINVAL;
> goto out;
> }
> - if (new_value && (bond->params.mode != BOND_MODE_ACTIVEBACKUP)) {
> + if (bond->params.mode != BOND_MODE_ACTIVEBACKUP) {
> pr_err("%s: arp_validate only supported in active-backup mode.\n",
> bond->dev->name);
> ret = -EINVAL;
> @@ -441,6 +443,12 @@ static ssize_t bonding_store_arp_validate(struct device *d,
> bond->dev->name, arp_validate_tbl[new_value].modename,
> new_value);
>
> + if (bond->dev->flags & IFF_UP) {
> + if (!new_value)
> + bond->recv_probe = NULL;
> + else if (bond->params.arp_interval)
> + bond->recv_probe = bond_arp_rcv;
> + }
> bond->params.arp_validate = new_value;
> out:
> rtnl_unlock();
> @@ -561,8 +569,8 @@ static ssize_t bonding_store_arp_interval(struct device *d,
> struct device_attribute *attr,
> const char *buf, size_t count)
> {
> - int new_value, ret = count;
> struct bonding *bond = to_bond(d);
> + int new_value, ret = count;
>
> if (!rtnl_trylock())
> return restart_syscall();
> @@ -605,8 +613,13 @@ static ssize_t bonding_store_arp_interval(struct device *d,
> * is called.
> */
> if (!new_value) {
> + if (bond->params.arp_validate)
> + bond->recv_probe = NULL;
> cancel_delayed_work_sync(&bond->arp_work);
> } else {
> + /* arp_validate can be set only in active-backup mode */
> + if (bond->params.arp_validate)
> + bond->recv_probe = bond_arp_rcv;
> cancel_delayed_work_sync(&bond->mii_work);
> queue_delayed_work(bond->wq, &bond->arp_work, 0);
> }
> diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
> index f7ab161..7ad8bd5 100644
> --- a/drivers/net/bonding/bonding.h
> +++ b/drivers/net/bonding/bonding.h
> @@ -430,6 +430,7 @@ static inline bool slave_can_tx(struct slave *slave)
>
> struct bond_net;
>
> +int bond_arp_rcv(const struct sk_buff *skb, struct bonding *bond, struct slave *slave);
> struct vlan_entry *bond_next_vlan(struct bonding *bond, struct vlan_entry *curr);
> int bond_dev_queue_xmit(struct bonding *bond, struct sk_buff *skb, struct net_device *slave_dev);
> void bond_xmit_slave_id(struct bonding *bond, struct sk_buff *skb, int slave_id);
>
^ permalink raw reply
* Re: [PATCH net 4/4] bridge: Fix updating FDB entries when the PVID is applied
From: Vlad Yasevich @ 2013-09-10 14:24 UTC (permalink / raw)
To: Toshiaki Makita; +Cc: David S. Miller, netdev
In-Reply-To: <1378809571.3988.13.camel@ubuntu-vm-makita>
On 09/10/2013 06:39 AM, Toshiaki Makita wrote:
> We currently set the value that variable vid pointing, which will be used
> in FDB later, to 0 at br_allowed_ingress() when we receive untagged or
> priority-tagged frames, even though the PVID is valid.
> This leads to FDB updates in such a wrong way that they are learned with
> VID 0.
> Update the value to that of PVID if the PVID is applied.
>
> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Reviewed-by: Vlad Yasevich <vyasevich@redhat.com>
-vlad
> ---
> net/bridge/br_vlan.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
> index 5a9c44a..53f0990 100644
> --- a/net/bridge/br_vlan.c
> +++ b/net/bridge/br_vlan.c
> @@ -217,6 +217,7 @@ bool br_allowed_ingress(struct net_bridge *br, struct net_port_vlans *v,
> /* PVID is set on this port. Any untagged or priority-tagged
> * ingress frame is considered to belong to this vlan.
> */
> + *vid = pvid;
> if (likely(err))
> /* Untagged Frame. */
> __vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), pvid);
>
^ permalink raw reply
* Re: [PATCH net 3/4] bridge: Fix the way the PVID is referenced
From: Vlad Yasevich @ 2013-09-10 14:24 UTC (permalink / raw)
To: Toshiaki Makita; +Cc: David S. Miller, netdev
In-Reply-To: <1378809451.3988.11.camel@ubuntu-vm-makita>
On 09/10/2013 06:37 AM, Toshiaki Makita wrote:
> We are using the VLAN_TAG_PRESENT bit to detect whether the PVID is
> set or not at br_get_pvid(), while we don't care about the bit in
> adding/deleting the PVID, which makes it impossible to forward any
> incomming untagged frame with vlan_filtering enabled.
>
> Since vid 0 cannot be used for the PVID, we can use vid 0 to indicate
> that the PVID is not set, which is slightly more efficient than using
> the VLAN_TAG_PRESENT.
Yes, that is simpler.
>
> Fix the problem by getting rid of using the VLAN_TAG_PRESENT.
>
> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Reviewed-by: Vlad Yasevich <vyasevich@redhat.com>
-vlad
> ---
> net/bridge/br_private.h | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
> index 598cb0b..435ca4d 100644
> --- a/net/bridge/br_private.h
> +++ b/net/bridge/br_private.h
> @@ -646,9 +646,7 @@ static inline u16 br_get_pvid(const struct net_port_vlans *v)
> * vid wasn't set
> */
> smp_rmb();
> - return (v->pvid & VLAN_TAG_PRESENT) ?
> - (v->pvid & ~VLAN_TAG_PRESENT) :
> - VLAN_N_VID;
> + return v->pvid ?: VLAN_N_VID;
> }
>
> #else
>
^ permalink raw reply
* Re: [PATCH net 1/4] bridge: Don't use VID 0 and 4095 in vlan filtering
From: Vlad Yasevich @ 2013-09-10 14:22 UTC (permalink / raw)
To: Toshiaki Makita; +Cc: David S. Miller, netdev
In-Reply-To: <1378809144.3988.6.camel@ubuntu-vm-makita>
On 09/10/2013 06:32 AM, Toshiaki Makita wrote:
> IEEE 802.1Q says that:
> - VID 0 shall not be configured as a PVID, or configured in any Filtering
> Database entry.
> - VID 4095 shall not be configured as a PVID, or transmitted in a tag
> header. This VID value may be used to indicate a wildcard match for the VID
> in management operations or Filtering Database entries.
> (See IEEE 802.1Q-2005 6.7.1 and Table 9-2)
>
> Don't accept adding these VIDs in the vlan_filtering implementation.
>
> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Reviewed-by: Vlad Yasevich <vyasevich@redhat.com>
-vlad
> ---
> net/bridge/br_fdb.c | 4 +-
> net/bridge/br_netlink.c | 2 +-
> net/bridge/br_vlan.c | 97 +++++++++++++++++++++++--------------------------
> 3 files changed, 49 insertions(+), 54 deletions(-)
>
> diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
> index ffd5874..33e8f23 100644
> --- a/net/bridge/br_fdb.c
> +++ b/net/bridge/br_fdb.c
> @@ -700,7 +700,7 @@ int br_fdb_add(struct ndmsg *ndm, struct nlattr *tb[],
>
> vid = nla_get_u16(tb[NDA_VLAN]);
>
> - if (vid >= VLAN_N_VID) {
> + if (!vid || vid >= VLAN_VID_MASK) {
> pr_info("bridge: RTM_NEWNEIGH with invalid vlan id %d\n",
> vid);
> return -EINVAL;
> @@ -794,7 +794,7 @@ int br_fdb_delete(struct ndmsg *ndm, struct nlattr *tb[],
>
> vid = nla_get_u16(tb[NDA_VLAN]);
>
> - if (vid >= VLAN_N_VID) {
> + if (!vid || vid >= VLAN_VID_MASK) {
> pr_info("bridge: RTM_NEWNEIGH with invalid vlan id %d\n",
> vid);
> return -EINVAL;
> diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
> index b9259ef..9bac61e 100644
> --- a/net/bridge/br_netlink.c
> +++ b/net/bridge/br_netlink.c
> @@ -243,7 +243,7 @@ static int br_afspec(struct net_bridge *br,
>
> vinfo = nla_data(tb[IFLA_BRIDGE_VLAN_INFO]);
>
> - if (vinfo->vid >= VLAN_N_VID)
> + if (!vinfo->vid || vinfo->vid >= VLAN_VID_MASK)
> return -EINVAL;
>
> switch (cmd) {
> diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
> index 9a9ffe7..21b6d21 100644
> --- a/net/bridge/br_vlan.c
> +++ b/net/bridge/br_vlan.c
> @@ -45,37 +45,34 @@ static int __vlan_add(struct net_port_vlans *v, u16 vid, u16 flags)
> return 0;
> }
>
> - if (vid) {
> - if (v->port_idx) {
> - p = v->parent.port;
> - br = p->br;
> - dev = p->dev;
> - } else {
> - br = v->parent.br;
> - dev = br->dev;
> - }
> - ops = dev->netdev_ops;
> -
> - if (p && (dev->features & NETIF_F_HW_VLAN_CTAG_FILTER)) {
> - /* Add VLAN to the device filter if it is supported.
> - * Stricly speaking, this is not necessary now, since
> - * devices are made promiscuous by the bridge, but if
> - * that ever changes this code will allow tagged
> - * traffic to enter the bridge.
> - */
> - err = ops->ndo_vlan_rx_add_vid(dev, htons(ETH_P_8021Q),
> - vid);
> - if (err)
> - return err;
> - }
> -
> - err = br_fdb_insert(br, p, dev->dev_addr, vid);
> - if (err) {
> - br_err(br, "failed insert local address into bridge "
> - "forwarding table\n");
> - goto out_filt;
> - }
> + if (v->port_idx) {
> + p = v->parent.port;
> + br = p->br;
> + dev = p->dev;
> + } else {
> + br = v->parent.br;
> + dev = br->dev;
> + }
> + ops = dev->netdev_ops;
> +
> + if (p && (dev->features & NETIF_F_HW_VLAN_CTAG_FILTER)) {
> + /* Add VLAN to the device filter if it is supported.
> + * Stricly speaking, this is not necessary now, since
> + * devices are made promiscuous by the bridge, but if
> + * that ever changes this code will allow tagged
> + * traffic to enter the bridge.
> + */
> + err = ops->ndo_vlan_rx_add_vid(dev, htons(ETH_P_8021Q),
> + vid);
> + if (err)
> + return err;
> + }
>
> + err = br_fdb_insert(br, p, dev->dev_addr, vid);
> + if (err) {
> + br_err(br, "failed insert local address into bridge "
> + "forwarding table\n");
> + goto out_filt;
> }
>
> set_bit(vid, v->vlan_bitmap);
> @@ -98,7 +95,7 @@ static int __vlan_del(struct net_port_vlans *v, u16 vid)
> __vlan_delete_pvid(v, vid);
> clear_bit(vid, v->untagged_bitmap);
>
> - if (v->port_idx && vid) {
> + if (v->port_idx) {
> struct net_device *dev = v->parent.port->dev;
> const struct net_device_ops *ops = dev->netdev_ops;
>
> @@ -248,7 +245,9 @@ bool br_allowed_egress(struct net_bridge *br,
> return false;
> }
>
> -/* Must be protected by RTNL */
> +/* Must be protected by RTNL.
> + * Must be called with vid in range from 1 to 4094 inclusive.
> + */
> int br_vlan_add(struct net_bridge *br, u16 vid, u16 flags)
> {
> struct net_port_vlans *pv = NULL;
> @@ -278,7 +277,9 @@ out:
> return err;
> }
>
> -/* Must be protected by RTNL */
> +/* Must be protected by RTNL.
> + * Must be called with vid in range from 1 to 4094 inclusive.
> + */
> int br_vlan_delete(struct net_bridge *br, u16 vid)
> {
> struct net_port_vlans *pv;
> @@ -289,14 +290,9 @@ int br_vlan_delete(struct net_bridge *br, u16 vid)
> if (!pv)
> return -EINVAL;
>
> - if (vid) {
> - /* If the VID !=0 remove fdb for this vid. VID 0 is special
> - * in that it's the default and is always there in the fdb.
> - */
> - spin_lock_bh(&br->hash_lock);
> - fdb_delete_by_addr(br, br->dev->dev_addr, vid);
> - spin_unlock_bh(&br->hash_lock);
> - }
> + spin_lock_bh(&br->hash_lock);
> + fdb_delete_by_addr(br, br->dev->dev_addr, vid);
> + spin_unlock_bh(&br->hash_lock);
>
> __vlan_del(pv, vid);
> return 0;
> @@ -329,7 +325,9 @@ unlock:
> return 0;
> }
>
> -/* Must be protected by RTNL */
> +/* Must be protected by RTNL.
> + * Must be called with vid in range from 1 to 4094 inclusive.
> + */
> int nbp_vlan_add(struct net_bridge_port *port, u16 vid, u16 flags)
> {
> struct net_port_vlans *pv = NULL;
> @@ -363,7 +361,9 @@ clean_up:
> return err;
> }
>
> -/* Must be protected by RTNL */
> +/* Must be protected by RTNL.
> + * Must be called with vid in range from 1 to 4094 inclusive.
> + */
> int nbp_vlan_delete(struct net_bridge_port *port, u16 vid)
> {
> struct net_port_vlans *pv;
> @@ -374,14 +374,9 @@ int nbp_vlan_delete(struct net_bridge_port *port, u16 vid)
> if (!pv)
> return -EINVAL;
>
> - if (vid) {
> - /* If the VID !=0 remove fdb for this vid. VID 0 is special
> - * in that it's the default and is always there in the fdb.
> - */
> - spin_lock_bh(&port->br->hash_lock);
> - fdb_delete_by_addr(port->br, port->dev->dev_addr, vid);
> - spin_unlock_bh(&port->br->hash_lock);
> - }
> + spin_lock_bh(&port->br->hash_lock);
> + fdb_delete_by_addr(port->br, port->dev->dev_addr, vid);
> + spin_unlock_bh(&port->br->hash_lock);
>
> return __vlan_del(pv, vid);
> }
>
^ permalink raw reply
* Question about reading the routing table with netlink
From: Fernando Gont @ 2013-09-10 14:21 UTC (permalink / raw)
To: netdev
Folks,
Short version of the question:
I'm trying to loop up a routing table entry with a
socket(AF_NETLINK,SOCK_RAW,NETLINK_ROUTE).
Everything seems fine, except that I do not quite understand what's the
effect of setting the RTA_SRC attribute type when doing that.
Empirically, it seems that if the RTA_SRC attribute is set and it
contains an address that is assigned to the interface involved in the
route, then such address is later returned in the reply as an RTA_SRC
attribute.
Aside question, I was curious about the NETLINK_FIB_LOOKUP family (I
guess it can be used for the same purpose?) -- but I wasn't able to get
much information about it.
Any help will be welcome.
Thanks!
P.S.: Not sure if this is the right forum to ask this.. please direct me
elsewhere if appropriate.
Best regards,
--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
^ permalink raw reply
* Re: [PATCH 4/7] ptp: switch to use gpiolib
From: Richard Cochran @ 2013-09-10 14:19 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-gpio, Imre Kaloz, Krzysztof Halasa, Alexandre Courbot,
linux-arm-kernel, netdev
In-Reply-To: <1378816260-8091-1-git-send-email-linus.walleij@linaro.org>
On Tue, Sep 10, 2013 at 02:31:00PM +0200, Linus Walleij wrote:
> This platform supports gpiolib, so remove the custom API use
> and replace with calls to gpiolib. Also request the GPIO before
> starting to use it.
>
> Cc: Imre Kaloz <kaloz@openwrt.org>
> Cc: Krzysztof Halasa <khc@pm.waw.pl>
> Cc: Alexandre Courbot <acourbot@nvidia.com>
> Cc: Richard Cochran <richardcochran@gmail.com>
> Cc: netdev@vger.kernel.org
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> Hi Richard, I'm seeking an ACK on this patch to take it throug
> the GPIO tree as part of a clean-out of custom GPIO implementations.
I don't have this hardware for testing (it is really obsolete now),
but the change looks okay to me.
Acked-by: Richard Cochran <richardcochran@gmail.com>
^ permalink raw reply
* Re: [PATCH] net: fec: add the initial to set the physical mac address
From: Denis Kirjanov @ 2013-09-10 14:19 UTC (permalink / raw)
To: Fugang Duan
Cc: b20596, b45643, davem, netdev, shawn.guo, bhutchings, R49496,
stephen
In-Reply-To: <1377170269-8988-1-git-send-email-B38611@freescale.com>
On 8/22/13, Fugang Duan <B38611@freescale.com> wrote:
> For imx6slx evk platform, the fec driver cannot work since there
> have no valid mac address set in physical mac registers.
>
> For imx serial platform, fec/enet IPs both need the physical MAC
> address initial, otherwise it cannot work.
>
> After acquiring the valid MAC address from devices tree/pfuse/
> kernel command line/random mac address, and then set it to the
> physical MAC address registers.
>
> Signed-off-by: Fugang Duan <B38611@freescale.com>
> ---
> drivers/net/ethernet/freescale/fec_main.c | 9 ++++++---
> 1 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/fec_main.c
> b/drivers/net/ethernet/freescale/fec_main.c
> index 4349a9e..9b5e08c 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -1867,10 +1867,12 @@ fec_set_mac_address(struct net_device *ndev, void
> *p)
> struct fec_enet_private *fep = netdev_priv(ndev);
> struct sockaddr *addr = p;
>
> - if (!is_valid_ether_addr(addr->sa_data))
> - return -EADDRNOTAVAIL;
> + if (p) {
I don't see how the p pointer can be NULL...
> + if (!is_valid_ether_addr(addr->sa_data))
> + return -EADDRNOTAVAIL;
>
> - memcpy(ndev->dev_addr, addr->sa_data, ndev->addr_len);
> + memcpy(ndev->dev_addr, addr->sa_data, ndev->addr_len);
> + }
>
> writel(ndev->dev_addr[3] | (ndev->dev_addr[2] << 8) |
> (ndev->dev_addr[1] << 16) | (ndev->dev_addr[0] << 24),
> @@ -1969,6 +1971,7 @@ static int fec_enet_init(struct net_device *ndev)
>
> /* Get the Ethernet address */
> fec_get_mac(ndev);
> + fec_set_mac_address(ndev, NULL);
>
> /* Set receive and transmit descriptor base. */
> fep->rx_bd_base = cbd_base;
> --
> 1.7.1
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH net] net: sctp: fix smatch warning in sctp_send_asconf_del_ip
From: Vlad Yasevich @ 2013-09-10 14:18 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, netdev, linux-sctp, Neil Horman, Michio Honda
In-Reply-To: <1378579881-27881-1-git-send-email-dborkman@redhat.com>
On 09/07/2013 02:51 PM, Daniel Borkmann wrote:
> This was originally reported in [1] and posted by Neil Horman [2], he said:
>
> Fix up a missed null pointer check in the asconf code. If we don't find
> a local address, but we pass in an address length of more than 1, we may
> dereference a NULL laddr pointer. Currently this can't happen, as the only
> users of the function pass in the value 1 as the addrcnt parameter, but
> its not hot path, and it doesn't hurt to check for NULL should that ever
> be the case.
>
> The callpath from sctp_asconf_mgmt() looks okay. But this could be triggered
> from sctp_setsockopt_bindx() call with SCTP_BINDX_REM_ADDR and addrcnt > 1
> while passing all possible addresses from the bind list to SCTP_BINDX_REM_ADDR
> so that we do *not* find a single address in the association's bind address
> list that is not in the packed array of addresses. If this happens when we
> have an established association with ASCONF-capable peers, then we could get
> a NULL pointer dereference as we only check for laddr == NULL && addrcnt == 1
> and call later sctp_make_asconf_update_ip() with NULL laddr.
>
> BUT: this actually won't happen as sctp_bindx_rem() will catch such a case
> and return with an error earlier. As this is incredably unintuitive and error
> prone, add a check to catch at least future bugs here. As Neil says, its not
> hot path. Introduced by 8a07eb0a5 ("sctp: Add ASCONF operation on the
> single-homed host").
>
> [1] http://www.spinics.net/lists/linux-sctp/msg02132.html
> [2] http://www.spinics.net/lists/linux-sctp/msg02133.html
>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> Cc: Michio Honda <micchie@sfc.wide.ad.jp>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
-vlad
> ---
> net/sctp/socket.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index 5462bbb..911b71b 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -806,6 +806,9 @@ static int sctp_send_asconf_del_ip(struct sock *sk,
> goto skip_mkasconf;
> }
>
> + if (laddr == NULL)
> + return -EINVAL;
> +
> /* We do not need RCU protection throughout this loop
> * because this is done under a socket lock from the
> * setsockopt call.
>
^ permalink raw reply
* [PATCH] bonding: Make alb learning packet interval configurable
From: Neil Horman @ 2013-09-10 14:14 UTC (permalink / raw)
To: netdev
Cc: Neil Horman, Neil Horman, Jay Vosburgh, Andy Gospodarek,
David S. Miller
From: Neil Horman <nhorman@redhat.com>
running bonding in ALB mode requires that learning packets be sent periodically,
so that the switch knows where to send responding traffic. However, depending
on switch configuration, there may not be any need to send traffic at the
default rate of 3 packets per second, which represents little more than wasted
data. Allow the ALB learning packet interval to be made configurable via sysfs
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Jay Vosburgh <fubar@us.ibm.com>
CC: Andy Gospodarek <andy@greyhouse.net>
CC: "David S. Miller" <davem@davemloft.net>
---
drivers/net/bonding/bond_alb.c | 2 +-
drivers/net/bonding/bond_alb.h | 8 ++++----
drivers/net/bonding/bond_main.c | 1 +
drivers/net/bonding/bond_sysfs.c | 39 +++++++++++++++++++++++++++++++++++++++
drivers/net/bonding/bonding.h | 1 +
5 files changed, 46 insertions(+), 5 deletions(-)
diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
index 91f179d..f428ef57 100644
--- a/drivers/net/bonding/bond_alb.c
+++ b/drivers/net/bonding/bond_alb.c
@@ -1472,7 +1472,7 @@ void bond_alb_monitor(struct work_struct *work)
bond_info->lp_counter++;
/* send learning packets */
- if (bond_info->lp_counter >= BOND_ALB_LP_TICKS) {
+ if (bond_info->lp_counter >= BOND_ALB_LP_TICKS(bond)) {
/* change of curr_active_slave involves swapping of mac addresses.
* in order to avoid this swapping from happening while
* sending the learning packets, the curr_slave_lock must be held for
diff --git a/drivers/net/bonding/bond_alb.h b/drivers/net/bonding/bond_alb.h
index 28d8e4c..e78fd9b 100644
--- a/drivers/net/bonding/bond_alb.h
+++ b/drivers/net/bonding/bond_alb.h
@@ -36,14 +36,14 @@ struct slave;
* Used for division - never set
* to zero !!!
*/
-#define BOND_ALB_LP_INTERVAL 1 /* In seconds, periodic send of
- * learning packets to the switch
- */
+#define BOND_ALB_LP_INTERVAL(bond) (bond->params.lp_interval) /* In seconds, periodic send of
+ * learning packets to the switch
+ */
#define BOND_TLB_REBALANCE_TICKS (BOND_TLB_REBALANCE_INTERVAL \
* ALB_TIMER_TICKS_PER_SEC)
-#define BOND_ALB_LP_TICKS (BOND_ALB_LP_INTERVAL \
+#define BOND_ALB_LP_TICKS(bond) (BOND_ALB_LP_INTERVAL(bond) \
* ALB_TIMER_TICKS_PER_SEC)
#define TLB_HASH_TABLE_SIZE 256 /* The size of the clients hash table.
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 39e5b1c..b8c9ec3 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -4416,6 +4416,7 @@ static int bond_check_params(struct bond_params *params)
params->all_slaves_active = all_slaves_active;
params->resend_igmp = resend_igmp;
params->min_links = min_links;
+ params->lp_interval = 1;
if (primary) {
strncpy(params->primary, primary, IFNAMSIZ);
diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index ce46776..4532259 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -1680,6 +1680,44 @@ out:
static DEVICE_ATTR(resend_igmp, S_IRUGO | S_IWUSR,
bonding_show_resend_igmp, bonding_store_resend_igmp);
+
+static ssize_t bonding_show_lp_interval(struct device *d,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct bonding *bond = to_bond(d);
+ return sprintf(buf, "%d\n", bond->params.lp_interval);
+}
+
+static ssize_t bonding_store_lp_interval(struct device *d,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct bonding *bond = to_bond(d);
+ int new_value, ret = count;
+
+ if (sscanf(buf, "%d", &new_value) != 1) {
+ pr_err("%s: no lp interval value specified.\n",
+ bond->dev->name);
+ ret = -EINVAL;
+ goto out;
+ }
+
+ if (new_value <= 0) {
+ pr_err ("%s: lp_interval must be between 1 and %d\n",
+ bond->dev->name, INT_MAX);
+ ret = -EINVAL;
+ goto out;
+ }
+
+ bond->params.lp_interval = new_value;
+out:
+ return ret;
+}
+
+static DEVICE_ATTR(lp_interval, S_IRUGO | S_IWUSR,
+ bonding_show_lp_interval, bonding_store_lp_interval);
+
static struct attribute *per_bond_attrs[] = {
&dev_attr_slaves.attr,
&dev_attr_mode.attr,
@@ -1710,6 +1748,7 @@ static struct attribute *per_bond_attrs[] = {
&dev_attr_all_slaves_active.attr,
&dev_attr_resend_igmp.attr,
&dev_attr_min_links.attr,
+ &dev_attr_lp_interval.attr,
NULL,
};
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index f7ab161..4bd9d5b 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -176,6 +176,7 @@ struct bond_params {
int tx_queues;
int all_slaves_active;
int resend_igmp;
+ int lp_interval;
};
struct bond_parm_tbl {
--
1.8.3.1
^ permalink raw reply related
* Re: VLAN filtering/VLAN aware bridge problems
From: Vlad Yasevich @ 2013-09-10 14:11 UTC (permalink / raw)
To: Stefan Priebe - Profihost AG; +Cc: David Miller, Linux Netdev List
In-Reply-To: <2036307B-46CC-40F6-ACE0-93A08BDEE0B9@profihost.ag>
On 08/30/2013 11:01 AM, Stefan Priebe - Profihost AG wrote:
> Yes
>
Can you apply this patch and see if this fixes your problem.
http://patchwork.ozlabs.org/patch/273841/
In my attempts to reproduce your problem I didn't configuring filtering
on the upper bridge, but that is what could have been causing
your problem. I'll attempt it and let you know.
-vlad
> Stefan
>
> This mail was sent with my iPhone.
>
> Am 30.08.2013 um 16:13 schrieb Vlad Yasevich <vyasevic@redhat.com>:
>
>> On 08/30/2013 03:24 AM, Stefan Priebe - Profihost AG wrote:
>>> Am 29.08.2013 22:45, schrieb Vlad Yasevich:
>>>> On 08/29/2013 08:50 AM, Stefan Priebe - Profihost AG wrote:
>>>
>>>>> The packets never reach the TAP device.
>>>>>
>>>>> Here is an output of ip a l (vlan 3021):
>>>>
>>>> Can you provide output of brctl show?
>>>
>>> Sure:
>>> # brctl show
>>> bridge name bridge id STP enabled interfaces
>>> vmbr0 8000.00259084dea8 no bond0
>>> tap320i0
>>> vmbr1 8000.00259084deaa no bond1
>>> vmbr1v3021 8000.00259084deaa no tap320i1
>>> vmbr1.3021
>>
>> so let me see if I can understand this configuration.
>>
>> vmbr1v3021 (bridge)
>> / \
>> tap320i1 vmbr1.3021 (vlan)
>> \
>> vmbr1 (bridge)
>> \
>> bond1
>> \
>> eth X
>>
>>
>> Is that right? Is this the setup that has the problem you are
>> describing?
>>
>> Thanks
>> -vlad
>>
>>>> On the off chance that you are actually trying to configure vlan
>>>> filtering, can you give this patch a try (net-2.6 tree):
>>>>
>>>> Author: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>>>> Date: Tue Aug 20 17:10:18 2013 +0900
>>>>
>>>> bridge: Use the correct bit length for bitmap functions in the VLAN
>>>> code
>>>>
>>>> I don't think it made it to stable yet.
>>>
>>> I addd that patch and now the vlan stuff works at least on the host
>>> node. But my tap devices still don't work.
>>>
>>> I also tried to attach the tap device on top of a vlan attached to bond1
>>> but then gvrp does not work anymore. The kernel announces gvrp once and
>>> then does not answer the query packets from the switch.
>>>
>>> Stefan
>>
^ permalink raw reply
* Re: [PATCH net 3/4] bridge: Fix the way the PVID is referenced
From: Vlad Yasevich @ 2013-09-10 14:08 UTC (permalink / raw)
To: Toshiaki Makita; +Cc: David S. Miller, netdev
In-Reply-To: <1378809451.3988.11.camel@ubuntu-vm-makita>
On 09/10/2013 06:37 AM, Toshiaki Makita wrote:
> We are using the VLAN_TAG_PRESENT bit to detect whether the PVID is
> set or not at br_get_pvid(), while we don't care about the bit in
> adding/deleting the PVID, which makes it impossible to forward any
> incomming untagged frame with vlan_filtering enabled.
>
> Since vid 0 cannot be used for the PVID, we can use vid 0 to indicate
> that the PVID is not set, which is slightly more efficient than using
> the VLAN_TAG_PRESENT.
>
> Fix the problem by getting rid of using the VLAN_TAG_PRESENT.
>
> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Reviewed-by: Vlad Yasevich <vyasevic@redhat.com>
-vlad
> ---
> net/bridge/br_private.h | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
> index 598cb0b..435ca4d 100644
> --- a/net/bridge/br_private.h
> +++ b/net/bridge/br_private.h
> @@ -646,9 +646,7 @@ static inline u16 br_get_pvid(const struct net_port_vlans *v)
> * vid wasn't set
> */
> smp_rmb();
> - return (v->pvid & VLAN_TAG_PRESENT) ?
> - (v->pvid & ~VLAN_TAG_PRESENT) :
> - VLAN_N_VID;
> + return v->pvid ?: VLAN_N_VID;
> }
>
> #else
>
^ permalink raw reply
* Re: [PATCH net 2/4] bridge: Handle priority-tagged frames properly
From: Vlad Yasevich @ 2013-09-10 14:03 UTC (permalink / raw)
To: Toshiaki Makita; +Cc: David S. Miller, netdev
In-Reply-To: <1378809280.3988.8.camel@ubuntu-vm-makita>
On 09/10/2013 06:34 AM, Toshiaki Makita wrote:
> IEEE 802.1Q says that when we receive priority-tagged (VID 0) frames
> use the PVID for the port as its VID.
> (See IEEE 802.1Q-2005 6.7.1 and Table 9-2)
>
> Apply the PVID to not only untagged frames but also priority-tagged frames.
>
> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> ---
> net/bridge/br_vlan.c | 27 ++++++++++++++++++++-------
> 1 file changed, 20 insertions(+), 7 deletions(-)
>
> diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
> index 21b6d21..5a9c44a 100644
> --- a/net/bridge/br_vlan.c
> +++ b/net/bridge/br_vlan.c
> @@ -189,6 +189,8 @@ out:
> bool br_allowed_ingress(struct net_bridge *br, struct net_port_vlans *v,
> struct sk_buff *skb, u16 *vid)
> {
> + int err;
> +
> /* If VLAN filtering is disabled on the bridge, all packets are
> * permitted.
> */
> @@ -201,20 +203,31 @@ bool br_allowed_ingress(struct net_bridge *br, struct net_port_vlans *v,
> if (!v)
> return false;
>
> - if (br_vlan_get_tag(skb, vid)) {
> + err = br_vlan_get_tag(skb, vid);
> + if (!*vid) {
> u16 pvid = br_get_pvid(v);
>
> - /* Frame did not have a tag. See if pvid is set
> - * on this port. That tells us which vlan untagged
> - * traffic belongs to.
> + /* Frame had a tag with VID 0 or did not have a tag.
> + * See if pvid is set on this port. That tells us which
> + * vlan untagged or priority-tagged traffic belongs to.
> */
> if (pvid == VLAN_N_VID)
> return false;
>
> - /* PVID is set on this port. Any untagged ingress
> - * frame is considered to belong to this vlan.
> + /* PVID is set on this port. Any untagged or priority-tagged
> + * ingress frame is considered to belong to this vlan.
> */
> - __vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), pvid);
> + if (likely(err))
> + /* Untagged Frame. */
> + __vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), pvid);
> + else
> + /* Priority-tagged Frame.
> + * At this point, We know that skb->vlan_tci had
> + * VLAN_TAG_PRESENT bit and its VID field was 0x000.
> + * We update only VID field and preserve PCP field.
> + */
> + skb->vlan_tci |= pvid;
> +
In the case of a priority tagged frame, we should unroll the
modification above and restore the VID field to 0. Otherwise, you
may end up either stripping the vlan header completely or forwarding
with pvid of the ingress port.
-vlad
> return true;
> }
>
>
^ permalink raw reply
* [PATCH] net: qmi_wwan: add new Qualcomm devices
From: Bjørn Mork @ 2013-09-10 13:06 UTC (permalink / raw)
To: netdev; +Cc: linux-usb, 王康, Bjørn Mork
Adding the device list from the Windows driver description files
included with a new Qualcomm MDM9615 based device, "Alcatel-sbell
ASB TL131 TDD LTE", from China Mobile. This device is tested
and verified to work. The others are assumed to work based on
using the same Windows driver.
Many of these devices support multiple QMI/wwan ports, requiring
multiple interface matching entries. All devices are composite,
providing a mix of one or more serial, storage or Android Debug
Brigde functions in addition to the wwan function.
This device list included an update of one previously known device,
which was incorrectly assumed to have a Gobi 2K layout. This is
corrected.
Reported-by: 王康 <scateu@gmail.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
---
drivers/net/usb/qmi_wwan.c | 130 +++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 129 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 3a81315..6312332 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -518,6 +518,135 @@ static const struct usb_device_id products[] = {
/* 3. Combined interface devices matching on interface number */
{QMI_FIXED_INTF(0x0408, 0xea42, 4)}, /* Yota / Megafon M100-1 */
+ {QMI_FIXED_INTF(0x05c6, 0x7000, 0)},
+ {QMI_FIXED_INTF(0x05c6, 0x7001, 1)},
+ {QMI_FIXED_INTF(0x05c6, 0x7002, 1)},
+ {QMI_FIXED_INTF(0x05c6, 0x7101, 1)},
+ {QMI_FIXED_INTF(0x05c6, 0x7101, 2)},
+ {QMI_FIXED_INTF(0x05c6, 0x7101, 3)},
+ {QMI_FIXED_INTF(0x05c6, 0x7102, 1)},
+ {QMI_FIXED_INTF(0x05c6, 0x7102, 2)},
+ {QMI_FIXED_INTF(0x05c6, 0x7102, 3)},
+ {QMI_FIXED_INTF(0x05c6, 0x8000, 7)},
+ {QMI_FIXED_INTF(0x05c6, 0x8001, 6)},
+ {QMI_FIXED_INTF(0x05c6, 0x9000, 4)},
+ {QMI_FIXED_INTF(0x05c6, 0x9003, 4)},
+ {QMI_FIXED_INTF(0x05c6, 0x9005, 2)},
+ {QMI_FIXED_INTF(0x05c6, 0x900a, 4)},
+ {QMI_FIXED_INTF(0x05c6, 0x900b, 2)},
+ {QMI_FIXED_INTF(0x05c6, 0x900c, 4)},
+ {QMI_FIXED_INTF(0x05c6, 0x900c, 5)},
+ {QMI_FIXED_INTF(0x05c6, 0x900c, 6)},
+ {QMI_FIXED_INTF(0x05c6, 0x900d, 5)},
+ {QMI_FIXED_INTF(0x05c6, 0x900f, 3)},
+ {QMI_FIXED_INTF(0x05c6, 0x900f, 4)},
+ {QMI_FIXED_INTF(0x05c6, 0x900f, 5)},
+ {QMI_FIXED_INTF(0x05c6, 0x9010, 4)},
+ {QMI_FIXED_INTF(0x05c6, 0x9010, 5)},
+ {QMI_FIXED_INTF(0x05c6, 0x9011, 3)},
+ {QMI_FIXED_INTF(0x05c6, 0x9011, 4)},
+ {QMI_FIXED_INTF(0x05c6, 0x9021, 1)},
+ {QMI_FIXED_INTF(0x05c6, 0x9022, 2)},
+ {QMI_FIXED_INTF(0x05c6, 0x9025, 4)}, /* Alcatel-sbell ASB TL131 TDD LTE (China Mobile) */
+ {QMI_FIXED_INTF(0x05c6, 0x9026, 3)},
+ {QMI_FIXED_INTF(0x05c6, 0x902e, 5)},
+ {QMI_FIXED_INTF(0x05c6, 0x9031, 5)},
+ {QMI_FIXED_INTF(0x05c6, 0x9032, 4)},
+ {QMI_FIXED_INTF(0x05c6, 0x9033, 3)},
+ {QMI_FIXED_INTF(0x05c6, 0x9033, 4)},
+ {QMI_FIXED_INTF(0x05c6, 0x9033, 5)},
+ {QMI_FIXED_INTF(0x05c6, 0x9033, 6)},
+ {QMI_FIXED_INTF(0x05c6, 0x9034, 3)},
+ {QMI_FIXED_INTF(0x05c6, 0x9034, 4)},
+ {QMI_FIXED_INTF(0x05c6, 0x9034, 5)},
+ {QMI_FIXED_INTF(0x05c6, 0x9034, 6)},
+ {QMI_FIXED_INTF(0x05c6, 0x9034, 7)},
+ {QMI_FIXED_INTF(0x05c6, 0x9035, 4)},
+ {QMI_FIXED_INTF(0x05c6, 0x9036, 3)},
+ {QMI_FIXED_INTF(0x05c6, 0x9037, 5)},
+ {QMI_FIXED_INTF(0x05c6, 0x9038, 4)},
+ {QMI_FIXED_INTF(0x05c6, 0x903b, 7)},
+ {QMI_FIXED_INTF(0x05c6, 0x903c, 6)},
+ {QMI_FIXED_INTF(0x05c6, 0x903d, 6)},
+ {QMI_FIXED_INTF(0x05c6, 0x903e, 5)},
+ {QMI_FIXED_INTF(0x05c6, 0x9043, 3)},
+ {QMI_FIXED_INTF(0x05c6, 0x9046, 3)},
+ {QMI_FIXED_INTF(0x05c6, 0x9046, 4)},
+ {QMI_FIXED_INTF(0x05c6, 0x9046, 5)},
+ {QMI_FIXED_INTF(0x05c6, 0x9047, 2)},
+ {QMI_FIXED_INTF(0x05c6, 0x9047, 3)},
+ {QMI_FIXED_INTF(0x05c6, 0x9047, 4)},
+ {QMI_FIXED_INTF(0x05c6, 0x9048, 4)},
+ {QMI_FIXED_INTF(0x05c6, 0x9048, 5)},
+ {QMI_FIXED_INTF(0x05c6, 0x9048, 6)},
+ {QMI_FIXED_INTF(0x05c6, 0x9048, 7)},
+ {QMI_FIXED_INTF(0x05c6, 0x9048, 8)},
+ {QMI_FIXED_INTF(0x05c6, 0x904c, 5)},
+ {QMI_FIXED_INTF(0x05c6, 0x904c, 6)},
+ {QMI_FIXED_INTF(0x05c6, 0x904c, 7)},
+ {QMI_FIXED_INTF(0x05c6, 0x904c, 8)},
+ {QMI_FIXED_INTF(0x05c6, 0x9050, 3)},
+ {QMI_FIXED_INTF(0x05c6, 0x9052, 4)},
+ {QMI_FIXED_INTF(0x05c6, 0x9053, 6)},
+ {QMI_FIXED_INTF(0x05c6, 0x9053, 7)},
+ {QMI_FIXED_INTF(0x05c6, 0x9054, 5)},
+ {QMI_FIXED_INTF(0x05c6, 0x9054, 6)},
+ {QMI_FIXED_INTF(0x05c6, 0x9055, 3)},
+ {QMI_FIXED_INTF(0x05c6, 0x9055, 4)},
+ {QMI_FIXED_INTF(0x05c6, 0x9055, 5)},
+ {QMI_FIXED_INTF(0x05c6, 0x9055, 6)},
+ {QMI_FIXED_INTF(0x05c6, 0x9055, 7)},
+ {QMI_FIXED_INTF(0x05c6, 0x9056, 3)},
+ {QMI_FIXED_INTF(0x05c6, 0x9062, 2)},
+ {QMI_FIXED_INTF(0x05c6, 0x9062, 3)},
+ {QMI_FIXED_INTF(0x05c6, 0x9062, 4)},
+ {QMI_FIXED_INTF(0x05c6, 0x9062, 5)},
+ {QMI_FIXED_INTF(0x05c6, 0x9062, 6)},
+ {QMI_FIXED_INTF(0x05c6, 0x9062, 7)},
+ {QMI_FIXED_INTF(0x05c6, 0x9062, 8)},
+ {QMI_FIXED_INTF(0x05c6, 0x9062, 9)},
+ {QMI_FIXED_INTF(0x05c6, 0x9064, 3)},
+ {QMI_FIXED_INTF(0x05c6, 0x9065, 6)},
+ {QMI_FIXED_INTF(0x05c6, 0x9065, 7)},
+ {QMI_FIXED_INTF(0x05c6, 0x9066, 5)},
+ {QMI_FIXED_INTF(0x05c6, 0x9066, 6)},
+ {QMI_FIXED_INTF(0x05c6, 0x9067, 1)},
+ {QMI_FIXED_INTF(0x05c6, 0x9068, 2)},
+ {QMI_FIXED_INTF(0x05c6, 0x9068, 3)},
+ {QMI_FIXED_INTF(0x05c6, 0x9068, 4)},
+ {QMI_FIXED_INTF(0x05c6, 0x9068, 5)},
+ {QMI_FIXED_INTF(0x05c6, 0x9068, 6)},
+ {QMI_FIXED_INTF(0x05c6, 0x9068, 7)},
+ {QMI_FIXED_INTF(0x05c6, 0x9069, 5)},
+ {QMI_FIXED_INTF(0x05c6, 0x9069, 6)},
+ {QMI_FIXED_INTF(0x05c6, 0x9069, 7)},
+ {QMI_FIXED_INTF(0x05c6, 0x9069, 8)},
+ {QMI_FIXED_INTF(0x05c6, 0x9070, 4)},
+ {QMI_FIXED_INTF(0x05c6, 0x9070, 5)},
+ {QMI_FIXED_INTF(0x05c6, 0x9075, 5)},
+ {QMI_FIXED_INTF(0x05c6, 0x9076, 4)},
+ {QMI_FIXED_INTF(0x05c6, 0x9076, 5)},
+ {QMI_FIXED_INTF(0x05c6, 0x9076, 6)},
+ {QMI_FIXED_INTF(0x05c6, 0x9076, 7)},
+ {QMI_FIXED_INTF(0x05c6, 0x9076, 8)},
+ {QMI_FIXED_INTF(0x05c6, 0x9077, 3)},
+ {QMI_FIXED_INTF(0x05c6, 0x9077, 4)},
+ {QMI_FIXED_INTF(0x05c6, 0x9077, 5)},
+ {QMI_FIXED_INTF(0x05c6, 0x9077, 6)},
+ {QMI_FIXED_INTF(0x05c6, 0x9078, 3)},
+ {QMI_FIXED_INTF(0x05c6, 0x9079, 4)},
+ {QMI_FIXED_INTF(0x05c6, 0x9079, 5)},
+ {QMI_FIXED_INTF(0x05c6, 0x9079, 6)},
+ {QMI_FIXED_INTF(0x05c6, 0x9079, 7)},
+ {QMI_FIXED_INTF(0x05c6, 0x9079, 8)},
+ {QMI_FIXED_INTF(0x05c6, 0x9080, 5)},
+ {QMI_FIXED_INTF(0x05c6, 0x9080, 6)},
+ {QMI_FIXED_INTF(0x05c6, 0x9080, 7)},
+ {QMI_FIXED_INTF(0x05c6, 0x9080, 8)},
+ {QMI_FIXED_INTF(0x05c6, 0x9083, 3)},
+ {QMI_FIXED_INTF(0x05c6, 0x9084, 4)},
+ {QMI_FIXED_INTF(0x05c6, 0x920d, 0)},
+ {QMI_FIXED_INTF(0x05c6, 0x920d, 5)},
{QMI_FIXED_INTF(0x12d1, 0x140c, 1)}, /* Huawei E173 */
{QMI_FIXED_INTF(0x12d1, 0x14ac, 1)}, /* Huawei E1820 */
{QMI_FIXED_INTF(0x19d2, 0x0002, 1)},
@@ -612,7 +741,6 @@ static const struct usb_device_id products[] = {
{QMI_GOBI_DEVICE(0x413c, 0x8186)}, /* Dell Gobi 2000 Modem device (N0218, VU936) */
{QMI_GOBI_DEVICE(0x413c, 0x8194)}, /* Dell Gobi 3000 Composite */
{QMI_GOBI_DEVICE(0x05c6, 0x920b)}, /* Generic Gobi 2000 Modem device */
- {QMI_GOBI_DEVICE(0x05c6, 0x920d)}, /* Gobi 3000 Composite */
{QMI_GOBI_DEVICE(0x05c6, 0x9225)}, /* Sony Gobi 2000 Modem device (N0279, VU730) */
{QMI_GOBI_DEVICE(0x05c6, 0x9245)}, /* Samsung Gobi 2000 Modem device (VL176) */
{QMI_GOBI_DEVICE(0x03f0, 0x251d)}, /* HP Gobi 2000 Modem device (VP412) */
--
1.7.10.4
^ permalink raw reply related
* Re: [RFC PATCH 4/4] ARM: dts: am33xx: adopt to cpsw-phy-sel driver to configure phy mode
From: Sergei Shtylyov @ 2013-09-10 12:55 UTC (permalink / raw)
To: Mugunthan V N
Cc: netdev, zonque, davem, bcousson, tony, devicetree, linux-omap
In-Reply-To: <522D6DE7.5080305@ti.com>
Hello.
On 09-09-2013 10:42, Mugunthan V N wrote:
>>> Add DT entries for the phy mode selection in AM33xx SoC using
>>> cpsw-phy-sel
>>> driver.
>>> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
>>> ---
>>> arch/arm/boot/dts/am33xx.dtsi | 6 ++++++
>>> 1 file changed, 6 insertions(+)
>>> diff --git a/arch/arm/boot/dts/am33xx.dtsi
>>> b/arch/arm/boot/dts/am33xx.dtsi
>>> index f9c5da9..4359672 100644
>>> --- a/arch/arm/boot/dts/am33xx.dtsi
>>> +++ b/arch/arm/boot/dts/am33xx.dtsi
>>> @@ -594,6 +594,12 @@
>>> /* Filled in by U-Boot */
>>> mac-address = [ 00 00 00 00 00 00 ];
>>> };
>>> +
>>> + phy_sel: cpsw_phy_sel@44e10650 {
>> Dashes are preferred to uderscores in the device tree names.
> I tried with dashes but i get the below error.
> $ make CROSS_COMPILE=arm-linux-gnueabihf- ARCH=arm dtbs
> DTC arch/arm/boot/dts/am335x-evm.dtb
> Error: arch/arm/boot/dts/am33xx.dtsi:598.11-12 syntax error
> FATAL ERROR: Unable to parse input tree
> make[1]: *** [arch/arm/boot/dts/am335x-evm.dtb] Error 1
> make: *** [dtbs] Error 2
Hm, perhaps the dashes can't be used in the labels but I was talking of
the names. Dashes in the node names should be definitely valid.
> Regards
> Mugunthan V N
WBR, Sergei
^ permalink raw reply
* Userspace header linux/netlink.h uses GCC-specific 'typeof'
From: Thorben Hasenpusch @ 2013-09-10 12:51 UTC (permalink / raw)
To: netdev@vger.kernel.org
Compilation of a user space program which includes linux/netlink.h and
uses NL_MMAP_MSG_ALIGN fails if GCC is ordered not to use GNU
extensions.
__KERNEL_ALIGN is defined to use typeof which is a GCC-extension and not
supported by standard C/C++.
Can that be changed so standard conforming C/C++ compiles successfully?
Regards.
^ permalink raw reply
* Re: [PATCH net-next] net: sk_buff: memset(skb,0) after alloc in skb_clone
From: Eric Dumazet @ 2013-09-10 12:40 UTC (permalink / raw)
To: Govindarajulu Varadarajan; +Cc: davem, netdev
In-Reply-To: <1378788533-5609-1-git-send-email-govindarajulu90@gmail.com>
On Tue, 2013-09-10 at 10:18 +0530, Govindarajulu Varadarajan wrote:
> The following patch memset the skb to 0 after alloc. We do this in
> __alloc_skb_head, __alloc_skb, build_skb. We are missing this in
> skb_clone.
>
> The following call to __skb_clone in skb_clone does not copy all the
> members of sk_buff. If we donot clear the skb to 0, we will have some
> uninitialized members in new skb.
Which ones exactly ?
I would rather make sure all fields are properly copied.
Your patch is incomplete, because it doesn't handle the fast clone case.
^ permalink raw reply
* Re: TSQ accounting skb->truesize degrades throughput for large packets
From: Eric Dumazet @ 2013-09-10 12:35 UTC (permalink / raw)
To: Jason Wang
Cc: Zoltan Kiss, Wei Liu, Jonathan Davies, Ian Campbell, netdev,
xen-devel, Michael S. Tsirkin
In-Reply-To: <522ECE2B.7020409@redhat.com>
On Tue, 2013-09-10 at 15:45 +0800, Jason Wang wrote:
> For example, virtio-net will stop the tx queue when it finds the tx
> queue may full and enable the queue when some packets were sent. In this
> case, tsq works and throttles the total bytes queued in qdisc. This
> usually happen during heavy network load such as two sessions of netperf.
You told me skb were _orphaned_.
This automatically _disables_ TSQ, after packets leave Qdisc.
So you have a problem because your skb orphaning is only working when
packets leave Qdisc.
If you cant afford sockets being throttled, make sure you have no
Qdisc !
> We notice a regression, and bisect shows it was introduced by TSQ.
You do realize TSQ is a balance between throughput and latencies ?
In case of TSQ, it was very clear that limiting amount of outstanding
bytes in queues could have an impact on bandwidth.
Pushing Megabytes of TCP packets with identical TCP timestamps is
bad, because it prevents us doing delay based congestion control and
a single flow could fill the Qdisc with a thousand of packets.
(Self induced delays, see BufferBloat discussions)
One known problem in TCP stack is that sendmsg() locks the socket for
the duration of the call. sendpage() do not have this problem.
tcp_tsq_handler() is deferred if tcp_tasklet_func() finds a locked
socket. The owner of socket will call tcp_tsq_handler() when socket is
released.
So if you use sendmsg() with large buffers or if copyin data from user
land involves page faults, it may explain why you need larger number of
in-flight bytes to sustain a given throughput.
You could take a look at commit c9bee3b7fdecb0c1d070c
("tcp: TCP_NOTSENT_LOWAT socket option"), and play
with /proc/sys/net/ipv4/tcp_notsent_lowat, to force sendmsg() to release
the socket lock every hundreds of kbytes.
^ permalink raw reply
* [PATCH 4/7] ptp: switch to use gpiolib
From: Linus Walleij @ 2013-09-10 12:31 UTC (permalink / raw)
To: linux-gpio, Imre Kaloz, Krzysztof Halasa, Richard Cochran
Cc: Alexandre Courbot, linux-arm-kernel, Linus Walleij, netdev
This platform supports gpiolib, so remove the custom API use
and replace with calls to gpiolib. Also request the GPIO before
starting to use it.
Cc: Imre Kaloz <kaloz@openwrt.org>
Cc: Krzysztof Halasa <khc@pm.waw.pl>
Cc: Alexandre Courbot <acourbot@nvidia.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: netdev@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
Hi Richard, I'm seeking an ACK on this patch to take it throug
the GPIO tree as part of a clean-out of custom GPIO implementations.
---
drivers/ptp/ptp_ixp46x.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/ptp/ptp_ixp46x.c b/drivers/ptp/ptp_ixp46x.c
index d49b851..4a08727 100644
--- a/drivers/ptp/ptp_ixp46x.c
+++ b/drivers/ptp/ptp_ixp46x.c
@@ -259,8 +259,15 @@ static struct ixp_clock ixp_clock;
static int setup_interrupt(int gpio)
{
int irq;
+ int err;
- gpio_line_config(gpio, IXP4XX_GPIO_IN);
+ err = gpio_request(gpio, "ixp4-ptp");
+ if (err)
+ return err;
+
+ err = gpio_direction_input(gpio);
+ if (err)
+ return err;
irq = gpio_to_irq(gpio);
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH 1/1] sfc: Staticize efx_ef10_filter_update_rx_scatter
From: Ben Hutchings @ 2013-09-10 12:08 UTC (permalink / raw)
To: Sachin Kamat; +Cc: netdev, linux-net-drivers
In-Reply-To: <1378806567-30625-1-git-send-email-sachin.kamat@linaro.org>
On Tue, 2013-09-10 at 15:19 +0530, Sachin Kamat wrote:
> 'efx_ef10_filter_update_rx_scatter' is used only in this file.
> Make it static.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> ---
> drivers/net/ethernet/sfc/ef10.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/sfc/ef10.c b/drivers/net/ethernet/sfc/ef10.c
> index 5f42313..6956bd2 100644
> --- a/drivers/net/ethernet/sfc/ef10.c
> +++ b/drivers/net/ethernet/sfc/ef10.c
> @@ -2121,7 +2121,7 @@ out_unlock:
> return rc;
> }
>
> -void efx_ef10_filter_update_rx_scatter(struct efx_nic *efx)
> +static void efx_ef10_filter_update_rx_scatter(struct efx_nic *efx)
> {
> /* no need to do anything here on EF10 */
> }
Same for this.
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 1/1] sfc: Staticize efx_ethtool_get_ts_info
From: Ben Hutchings @ 2013-09-10 12:08 UTC (permalink / raw)
To: Sachin Kamat; +Cc: netdev, linux-net-drivers
In-Reply-To: <1378806210-12155-1-git-send-email-sachin.kamat@linaro.org>
On Tue, 2013-09-10 at 15:13 +0530, Sachin Kamat wrote:
> 'efx_ethtool_get_ts_info' is used only in this file.
> Make it static.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> ---
> drivers/net/ethernet/sfc/ethtool.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/sfc/ethtool.c b/drivers/net/ethernet/sfc/ethtool.c
> index 5b471cf..c8dc407 100644
> --- a/drivers/net/ethernet/sfc/ethtool.c
> +++ b/drivers/net/ethernet/sfc/ethtool.c
> @@ -1035,8 +1035,8 @@ static int efx_ethtool_set_rxfh_indir(struct net_device *net_dev,
> return 0;
> }
>
> -int efx_ethtool_get_ts_info(struct net_device *net_dev,
> - struct ethtool_ts_info *ts_info)
> +static int efx_ethtool_get_ts_info(struct net_device *net_dev,
> + struct ethtool_ts_info *ts_info)
> {
> struct efx_nic *efx = netdev_priv(net_dev);
>
I already have this fix, but net-next is not open for changes.
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
* Update to RFC793's TCP sequence number validation checks
From: Fernando Gont @ 2013-09-10 11:00 UTC (permalink / raw)
To: netdev
Folks,
Dave Borman and me have posted an IETF Internet-Draft
(<http://tools.ietf.org/id/draft-gont-tcpm-tcp-seq-validation-01.txt>)
that fixes an existing bug in the RFC 793 TCP sequence number validation
checks.
The proposed fix has been implemented in open source stacks for many
years, so we're essentially updating the specs accordingly.
The IETF's TCPM working group chairs wanted to to some reviews of this
(very short) Internet-Draft before it is adopted as a working group item.
If you have a few minutes, please take a look, and post your
comments/review to <tcpm@ietf.org> (and make sure to CC me). This will
be of much help, and having feedback from the implementers' community
would be really valuable.
Thanks!
Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
^ permalink raw reply
* copyright in net/usb/ax188179_178a.c
From: David Laight @ 2013-09-10 11:16 UTC (permalink / raw)
To: netdev
The copyright at the top of net/usb/ax188179_178a.c just says
Copyright (C) 2011-2113 ASIX
However a lot of the code comes from the earlier driver
so the earlier copyrights should have been copied over.
(Unless it can be determined that all the changes related
to one of the copyrights have not been carried forwards.)
David
^ permalink raw reply
* Re: [PATCH net-next 0/26] bonding: use neighbours instead of own lists
From: Ding Tianhong @ 2013-09-10 11:08 UTC (permalink / raw)
To: Veaceslav Falico
Cc: netdev, jiri, Jay Vosburgh, Andy Gospodarek, Dimitris Michailidis,
David S. Miller, Patrick McHardy, Eric Dumazet, Alexander Duyck
In-Reply-To: <1378757804-3159-1-git-send-email-vfalico@redhat.com>
On 2013/9/10 4:16, Veaceslav Falico wrote:
> (David, feel free to drop the whole patchset - I know that the window is
> closed and I'm quite sure that it's not the last version, and even if it is
> - I'll easily re-submit it. Sorry for the mess :-/)
>
> Hi,
>
> RFC -> v1:
> I've added proper, consistent naming for all variables/functions, uninlined
> some helpers to get better backtraces, just in case (overhead is minimal,
> no hot paths), rearranged patches for better review, dropped bondings
> ->prev and bond_for_each_slave_continue() functionality - to be able to
> RCUify it easier, and renamed slave_* sysfs links to lower_* sysfs links to
> maintain upper/lower naming. I've also dropped, thanks to bonding cleanup,
> some heavy and ugly/intrusive patches.
>
> I'm sending it as early as possible, because it's quite a big patchset and
> some of the approaches I've chosen are not really easy/straightforward.
> It's, however, quite heavily tested already and works fine.
>
> I'm sending it to gather any feedback possible.
>
> This patchset introduces all the needed infrastructure, on top of current
> adjacent lists, to be able to remove bond's slave_list/slave->list. The
> overhead in memory/CPU is minimal, and after the patchset bonding can rely
> on its slave-related functions, given the proper locking. I've done some
> netperf benchmarks on a vm, and the delta was about 0.1gbps for 35gbps as a
> whole, so no speed fluctuations.
>
> It also automatically creates lower/upper and master symlinks in dev's
> sysfs directory.
reviewed, and can't found any problem till now, but it is a big changes,
and I could not sure whether it is the trend of the future for net device,
I'll wait and see everyone's opinion.
Best Regards
Ding
> .
>
^ permalink raw reply
* [PATCH net 4/4] bridge: Fix updating FDB entries when the PVID is applied
From: Toshiaki Makita @ 2013-09-10 10:39 UTC (permalink / raw)
To: David S. Miller, Vlad Yasevich, netdev; +Cc: Toshiaki Makita
In-Reply-To: <1378808874.3988.2.camel@ubuntu-vm-makita>
We currently set the value that variable vid pointing, which will be used
in FDB later, to 0 at br_allowed_ingress() when we receive untagged or
priority-tagged frames, even though the PVID is valid.
This leads to FDB updates in such a wrong way that they are learned with
VID 0.
Update the value to that of PVID if the PVID is applied.
Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
---
net/bridge/br_vlan.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
index 5a9c44a..53f0990 100644
--- a/net/bridge/br_vlan.c
+++ b/net/bridge/br_vlan.c
@@ -217,6 +217,7 @@ bool br_allowed_ingress(struct net_bridge *br, struct net_port_vlans *v,
/* PVID is set on this port. Any untagged or priority-tagged
* ingress frame is considered to belong to this vlan.
*/
+ *vid = pvid;
if (likely(err))
/* Untagged Frame. */
__vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), pvid);
--
1.8.1.2
^ permalink raw reply related
* [PATCH net 3/4] bridge: Fix the way the PVID is referenced
From: Toshiaki Makita @ 2013-09-10 10:37 UTC (permalink / raw)
To: David S. Miller, Vlad Yasevich, netdev; +Cc: Toshiaki Makita
In-Reply-To: <1378808874.3988.2.camel@ubuntu-vm-makita>
We are using the VLAN_TAG_PRESENT bit to detect whether the PVID is
set or not at br_get_pvid(), while we don't care about the bit in
adding/deleting the PVID, which makes it impossible to forward any
incomming untagged frame with vlan_filtering enabled.
Since vid 0 cannot be used for the PVID, we can use vid 0 to indicate
that the PVID is not set, which is slightly more efficient than using
the VLAN_TAG_PRESENT.
Fix the problem by getting rid of using the VLAN_TAG_PRESENT.
Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
---
net/bridge/br_private.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index 598cb0b..435ca4d 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -646,9 +646,7 @@ static inline u16 br_get_pvid(const struct net_port_vlans *v)
* vid wasn't set
*/
smp_rmb();
- return (v->pvid & VLAN_TAG_PRESENT) ?
- (v->pvid & ~VLAN_TAG_PRESENT) :
- VLAN_N_VID;
+ return v->pvid ?: VLAN_N_VID;
}
#else
--
1.8.1.2
^ permalink raw reply related
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