* Re: [PATCH 1/2] genl: Fix genl dumpit() locking.
From: Pravin Shelar @ 2013-08-22 20:31 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, Jesse Gross
In-Reply-To: <1377195534.14110.29.camel@jlt4.sipsolutions.net>
On Thu, Aug 22, 2013 at 11:18 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Thu, 2013-08-22 at 11:10 -0700, Pravin Shelar wrote:
>
>> > By the way - why? This just means that netlink will allocate another
>> > lock to lock it all, so it's not a very useful change?
>> >
>> This replaces global genl-lock with per-socket lock which allows
>> parallel operation in parallel-genl-families and they are not blocked
>> due to other unrelated genl-family operations.
>
> I don't think so? It replaces the genl lock as cb_mutex with a per
> *kernel* socket lock, so really just one per network namespace. That's
> not much of an improvement really.
>
You are thinking abt genl-sock -> nlk -> cb_lock which is not used in
genl-dump locking if cb_lock is NULL while creating nl socket.
^ permalink raw reply
* [PATCH net-next 0/2] qlge: feature update
From: Jitendra Kalsaria @ 2013-08-22 19:54 UTC (permalink / raw)
To: davem; +Cc: netdev, ron.mercer, Dept_NX_Linux_NIC_Driver, Jitendra Kalsaria
From: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
This patch series enhance the handling of nested vlan tags in Rx path.
Please apply it to net-next.
Jitendra Kalsaria (2):
qlge: Enhance nested VLAN (Q-in-Q) handling.
qlge: Update version to 1.0.0.33
drivers/net/ethernet/qlogic/qlge/qlge.h | 2 +-
drivers/net/ethernet/qlogic/qlge/qlge_main.c | 87 ++++++++++++++++++++------
2 files changed, 68 insertions(+), 21 deletions(-)
^ permalink raw reply
* Re: [PATCH 1/2] Revert "genetlink: fix family dump race"
From: Johannes Berg @ 2013-08-22 20:36 UTC (permalink / raw)
To: David Miller; +Cc: netdev, tgraf, Pravin Shelar
In-Reply-To: <20130822.132631.2273195424430844661.davem@davemloft.net>
On Thu, 2013-08-22 at 13:26 -0700, David Miller wrote:
> How to deal with the problem we were attempting to solve is still
> under discussion. It seems that even if we go to RCU we must also
> address to module reference count issue.
Yes, that's a separate issue. However, I think we should also check in
more detail the dumpit locking issue Pravin pointed out - before his
changes there was indeed the genl lock used as the cb_mutex. As I've
said over in the other thread, I'm not sure that change was actually
useful - it sounded like he confused kernel sockets and userland sockets
here? (Or maybe I am?!)
OTOH, we've already fixed the race conditions that resulted from his
patch, at least in nl80211. You might remember the issue Linus ran into
with the attrbuf, it's looking like that issue was because he changed
generic netlink to no longer use the genl_lock as the cb_mutex.
> I think the existing locking is very messy, and RCU looks a lot
> cleaner and has potential for future improvements to the scalability
> of dumps.
I agree, though we're not all that interested in generic netlink family
scalability I think, we have less than a dozen families, so this
shouldn't really be an issue.
> So I'd like to propose that we combine Johannes's RCU conversion
> with some variant of the module reference count fix.
>
> Can you guys work together and come up with something I can apply?
Sure, that in itself isn't really a problem, but if we don't take
Pravin's patch to "revert" the cb_mutex change in his parallel_ops
changes, then we definitely need to audit all generic netlink dumpit
implementations in all users to see if they have similar races to
nl80211. I originally thought that it was an nl80211 problem, but I'm
now convinced that it wasn't. Still the new code in nl80211 is probably
nicer, and we can probably make it parallel_ops now due to these changes
but I'm not convinced we can audit all genl families.
If it wasn't that so much time has already passed since the parallel_ops
changes I'd almost suggest reverting those altogether and addressing the
locking properly ...
johannes
^ permalink raw reply
* [PATCH net-next 1/2] qlge: Enhance nested VLAN (Q-in-Q) handling.
From: Jitendra Kalsaria @ 2013-08-22 19:54 UTC (permalink / raw)
To: davem; +Cc: netdev, ron.mercer, Dept_NX_Linux_NIC_Driver, Jitendra Kalsaria
In-Reply-To: <1377201252-9283-1-git-send-email-jitendra.kalsaria@qlogic.com>
From: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Adapter doesn’t handle packets with nested VLAN tags in
Rx path. Turn off VLAN tag stripping in the hardware and
let the stack handle stripping of VLAN tags in the Rx path.
Signed-off-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
---
drivers/net/ethernet/qlogic/qlge/qlge_main.c | 79 +++++++++++++++++++-------
1 files changed, 59 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlge/qlge_main.c b/drivers/net/ethernet/qlogic/qlge/qlge_main.c
index 2553cf4..f6f2c5f 100644
--- a/drivers/net/ethernet/qlogic/qlge/qlge_main.c
+++ b/drivers/net/ethernet/qlogic/qlge/qlge_main.c
@@ -87,6 +87,12 @@ MODULE_PARM_DESC(qlge_force_coredump,
"Option to allow force of firmware core dump. "
"Default is OFF - Do not allow.");
+static int qlge_hw_strip_vlan;
+module_param(qlge_hw_strip_vlan, int, 0);
+MODULE_PARM_DESC(qlge_hw_strip_vlan,
+ "Option to enable hardware to strip vlan tag. "
+ "Default is OFF - Hardware will not strip.");
+
static DEFINE_PCI_DEVICE_TABLE(qlge_pci_tbl) = {
{PCI_DEVICE(PCI_VENDOR_ID_QLOGIC, QLGE_DEVICE_ID_8012)},
{PCI_DEVICE(PCI_VENDOR_ID_QLOGIC, QLGE_DEVICE_ID_8000)},
@@ -1464,6 +1470,25 @@ static void ql_categorize_rx_err(struct ql_adapter *qdev, u8 rx_err,
}
}
+/*
+ * This routine will update the mac header length based on
+ * single or nested vlan tags if present
+ */
+static void ql_update_mac_hdr_len(struct ib_mac_iocb_rsp *ib_mac_rsp,
+ void *page, size_t *len)
+{
+ u16 *tags;
+
+ if ((ib_mac_rsp->flags2 & IB_MAC_IOCB_RSP_V) && !qlge_hw_strip_vlan) {
+ tags = (u16 *)page;
+ if (tags[6] == htons(ETH_P_8021Q) &&
+ tags[8] == htons(ETH_P_8021Q))
+ *len += 2 * VLAN_HLEN;
+ else
+ *len += VLAN_HLEN;
+ }
+}
+
/* Process an inbound completion from an rx ring. */
static void ql_process_mac_rx_gro_page(struct ql_adapter *qdev,
struct rx_ring *rx_ring,
@@ -1523,6 +1548,7 @@ static void ql_process_mac_rx_page(struct ql_adapter *qdev,
void *addr;
struct bq_desc *lbq_desc = ql_get_curr_lchunk(qdev, rx_ring);
struct napi_struct *napi = &rx_ring->napi;
+ size_t hlen = ETH_HLEN;
skb = netdev_alloc_skb(ndev, length);
if (!skb) {
@@ -1540,25 +1566,28 @@ static void ql_process_mac_rx_page(struct ql_adapter *qdev,
goto err_out;
}
+ /* Update the MAC header length*/
+ ql_update_mac_hdr_len(ib_mac_rsp, addr, &hlen);
+
/* The max framesize filter on this chip is set higher than
* MTU since FCoE uses 2k frames.
*/
- if (skb->len > ndev->mtu + ETH_HLEN) {
+ if (skb->len > ndev->mtu + hlen) {
netif_err(qdev, drv, qdev->ndev,
"Segment too small, dropping.\n");
rx_ring->rx_dropped++;
goto err_out;
}
- memcpy(skb_put(skb, ETH_HLEN), addr, ETH_HLEN);
+ memcpy(skb_put(skb, hlen), addr, hlen);
netif_printk(qdev, rx_status, KERN_DEBUG, qdev->ndev,
"%d bytes of headers and data in large. Chain page to new skb and pull tail.\n",
length);
skb_fill_page_desc(skb, 0, lbq_desc->p.pg_chunk.page,
- lbq_desc->p.pg_chunk.offset+ETH_HLEN,
- length-ETH_HLEN);
- skb->len += length-ETH_HLEN;
- skb->data_len += length-ETH_HLEN;
- skb->truesize += length-ETH_HLEN;
+ lbq_desc->p.pg_chunk.offset + hlen,
+ length - hlen);
+ skb->len += length - hlen;
+ skb->data_len += length - hlen;
+ skb->truesize += length - hlen;
rx_ring->rx_packets++;
rx_ring->rx_bytes += skb->len;
@@ -1576,7 +1605,7 @@ static void ql_process_mac_rx_page(struct ql_adapter *qdev,
(ib_mac_rsp->flags3 & IB_MAC_IOCB_RSP_V4)) {
/* Unfragmented ipv4 UDP frame. */
struct iphdr *iph =
- (struct iphdr *) ((u8 *)addr + ETH_HLEN);
+ (struct iphdr *) ((u8 *)addr + hlen);
if (!(iph->frag_off &
htons(IP_MF|IP_OFFSET))) {
skb->ip_summed = CHECKSUM_UNNECESSARY;
@@ -1726,7 +1755,8 @@ static struct sk_buff *ql_build_rx_skb(struct ql_adapter *qdev,
struct bq_desc *sbq_desc;
struct sk_buff *skb = NULL;
u32 length = le32_to_cpu(ib_mac_rsp->data_len);
- u32 hdr_len = le32_to_cpu(ib_mac_rsp->hdr_len);
+ u32 hdr_len = le32_to_cpu(ib_mac_rsp->hdr_len);
+ size_t hlen = ETH_HLEN;
/*
* Handle the header buffer if present.
@@ -1853,9 +1883,10 @@ static struct sk_buff *ql_build_rx_skb(struct ql_adapter *qdev,
skb->data_len += length;
skb->truesize += length;
length -= length;
- __pskb_pull_tail(skb,
- (ib_mac_rsp->flags2 & IB_MAC_IOCB_RSP_V) ?
- VLAN_ETH_HLEN : ETH_HLEN);
+ ql_update_mac_hdr_len(ib_mac_rsp,
+ lbq_desc->p.pg_chunk.va,
+ &hlen);
+ __pskb_pull_tail(skb, hlen);
}
} else {
/*
@@ -1910,8 +1941,9 @@ static struct sk_buff *ql_build_rx_skb(struct ql_adapter *qdev,
length -= size;
i++;
}
- __pskb_pull_tail(skb, (ib_mac_rsp->flags2 & IB_MAC_IOCB_RSP_V) ?
- VLAN_ETH_HLEN : ETH_HLEN);
+ ql_update_mac_hdr_len(ib_mac_rsp, lbq_desc->p.pg_chunk.va,
+ &hlen);
+ __pskb_pull_tail(skb, hlen);
}
return skb;
}
@@ -2003,7 +2035,7 @@ static void ql_process_mac_split_rx_intr(struct ql_adapter *qdev,
rx_ring->rx_packets++;
rx_ring->rx_bytes += skb->len;
skb_record_rx_queue(skb, rx_ring->cq_id);
- if ((ib_mac_rsp->flags2 & IB_MAC_IOCB_RSP_V) && (vlan_id != 0))
+ if (vlan_id != 0xffff)
__vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), vlan_id);
if (skb->ip_summed == CHECKSUM_UNNECESSARY)
napi_gro_receive(&rx_ring->napi, skb);
@@ -2017,7 +2049,8 @@ static unsigned long ql_process_mac_rx_intr(struct ql_adapter *qdev,
struct ib_mac_iocb_rsp *ib_mac_rsp)
{
u32 length = le32_to_cpu(ib_mac_rsp->data_len);
- u16 vlan_id = (ib_mac_rsp->flags2 & IB_MAC_IOCB_RSP_V) ?
+ u16 vlan_id = ((ib_mac_rsp->flags2 & IB_MAC_IOCB_RSP_V) &&
+ qlge_hw_strip_vlan) ?
((le16_to_cpu(ib_mac_rsp->vlan_id) &
IB_MAC_IOCB_RSP_VLAN_MASK)) : 0xffff;
@@ -3704,8 +3737,12 @@ static int ql_adapter_initialize(struct ql_adapter *qdev)
ql_write32(qdev, SYS, mask | value);
/* Set the default queue, and VLAN behavior. */
- value = NIC_RCV_CFG_DFQ | NIC_RCV_CFG_RV;
- mask = NIC_RCV_CFG_DFQ_MASK | (NIC_RCV_CFG_RV << 16);
+ value = NIC_RCV_CFG_DFQ;
+ mask = NIC_RCV_CFG_DFQ_MASK;
+ if (qdev->ndev->features & NETIF_F_HW_VLAN_CTAG_RX) {
+ value |= NIC_RCV_CFG_RV;
+ mask |= (NIC_RCV_CFG_RV << 16);
+ }
ql_write32(qdev, NIC_RCV_CFG, (mask | value));
/* Set the MPI interrupt to enabled. */
@@ -4695,10 +4732,12 @@ static int qlge_probe(struct pci_dev *pdev,
ndev->hw_features = NETIF_F_SG | NETIF_F_IP_CSUM |
NETIF_F_TSO | NETIF_F_TSO_ECN |
NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_RXCSUM;
- ndev->features = ndev->hw_features |
- NETIF_F_HW_VLAN_CTAG_RX | NETIF_F_HW_VLAN_CTAG_FILTER;
+ ndev->features = ndev->hw_features | NETIF_F_HW_VLAN_CTAG_FILTER;
ndev->vlan_features = ndev->hw_features;
+ if (qlge_hw_strip_vlan)
+ ndev->features |= NETIF_F_HW_VLAN_CTAG_RX;
+
if (test_bit(QL_DMA64, &qdev->flags))
ndev->features |= NETIF_F_HIGHDMA;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH net-next 3/3] net: tcp_probe: add IPv6 support
From: David Miller @ 2013-08-22 20:43 UTC (permalink / raw)
To: dborkman; +Cc: netdev
In-Reply-To: <1377107280-31091-4-git-send-email-dborkman@redhat.com>
From: Daniel Borkmann <dborkman@redhat.com>
Date: Wed, 21 Aug 2013 19:48:00 +0200
> + union {
> + struct sockaddr raw;
> + struct sockaddr_in v4;
> + struct sockaddr_in6 v6;
> + } src, dst;
This bloats up the tcp_log structure unnecessarily. You have
absolutely no use for the port member, for example.
I know you want to use this so that you can be lazy and only
use the single printf format specifier. Here, keeping the
tcp_log compact is more important.
^ permalink raw reply
* Can linux kernel bridge forward 802.1q tagged vlan packets?
From: Stephan von Krawczynski @ 2013-08-22 20:44 UTC (permalink / raw)
To: bridge; +Cc: netdev
Hello all,
first it seemed a trivial question to me, but since I could not find anybody
being neither able to answer this question nor giving a short config example
I'd like to ask here, maybe this is the right place.
My general idea is to bridge tagged vlan packets from a physical interface
(intel) to a virtual interface (virtio in qemu) and not losing the tags, so
the qemu guest can use vconfig and friends to get some vlan interfaces.
Is this possible and are there any additional steps necessary besides the
usual bridge configuration?
What bothers me especially is the vlan filtering done by nics which can
prevent to even receive the packets from the LAN.
And on the other side of course can the bridge code forward packets including
tags so that virtio is able to handle them?
--
Regards,
Stephan
^ permalink raw reply
* [PATCH] net/phy: Remove duplicate micrel phy defines
From: dinguyen @ 2013-08-22 21:01 UTC (permalink / raw)
To: dinh.linux; +Cc: Dinh Nguyen, Sean Cross, David S. Miller, netdev
From: Dinh Nguyen <dinguyen@altera.com>
Commit <f275487fa phy: micrel: Add definitions for common Micrel PHY
registers>, that is currently in Shawn Guo for-next tree at:
http://git.linaro.org/git-ro/people/shawnguo/linux-2.6.git, has moved
a few of the Micrel PHY defines to include/linux/micrel_phy.h.
This commit removes the duplicate defines from commit:
<954c3967 net/phy: micrel: Add OF configuration support for ksz9021>.
It also moves a few defines to the include file.
Signed-off-by: Dinh Nguyen <dinguyen@altera.com>
Cc: Sean Cross <xobs@kosagi.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
---
drivers/net/phy/micrel.c | 26 +++++++-------------------
include/linux/micrel_phy.h | 4 ++++
2 files changed, 11 insertions(+), 19 deletions(-)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index c31aad0..6ddaa87 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -54,18 +54,6 @@
#define KS8737_CTRL_INT_ACTIVE_HIGH (1 << 14)
#define KSZ8051_RMII_50MHZ_CLK (1 << 7)
-/* Write/read to/from extended registers */
-#define MII_KSZPHY_EXTREG 0x0b
-#define KSZPHY_EXTREG_WRITE 0x8000
-
-#define MII_KSZPHY_EXTREG_WRITE 0x0c
-#define MII_KSZPHY_EXTREG_READ 0x0d
-
-/* Extended registers */
-#define MII_KSZPHY_CLK_CONTROL_PAD_SKEW 0x104
-#define MII_KSZPHY_RX_DATA_PAD_SKEW 0x105
-#define MII_KSZPHY_TX_DATA_PAD_SKEW 0x106
-
#define PS_TO_REG 200
static int ksz_config_flags(struct phy_device *phydev)
@@ -83,15 +71,15 @@ static int ksz_config_flags(struct phy_device *phydev)
static int kszphy_extended_write(struct phy_device *phydev,
u32 regnum, u16 val)
{
- phy_write(phydev, MII_KSZPHY_EXTREG, KSZPHY_EXTREG_WRITE | regnum);
- return phy_write(phydev, MII_KSZPHY_EXTREG_WRITE, val);
+ phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL, KSZPHY_EXTREG_WRITE | regnum);
+ return phy_write(phydev, MICREL_KSZ9021_EXTREG_DATA_WRITE, val);
}
static int kszphy_extended_read(struct phy_device *phydev,
u32 regnum)
{
- phy_write(phydev, MII_KSZPHY_EXTREG, regnum);
- return phy_read(phydev, MII_KSZPHY_EXTREG_READ);
+ phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL, regnum);
+ return phy_read(phydev, MICREL_KSZ9021_EXTREG_DATA_READ);
}
static int kszphy_ack_interrupt(struct phy_device *phydev)
@@ -227,15 +215,15 @@ static int ksz9021_config_init(struct phy_device *phydev)
if (of_node) {
ksz9021_load_values_from_of(phydev, of_node,
- MII_KSZPHY_CLK_CONTROL_PAD_SKEW,
+ MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SCEW,
"txen-skew-ps", "txc-skew-ps",
"rxdv-skew-ps", "rxc-skew-ps");
ksz9021_load_values_from_of(phydev, of_node,
- MII_KSZPHY_RX_DATA_PAD_SKEW,
+ MICREL_KSZ9021_RGMII_RX_DATA_PAD_SCEW,
"rxd0-skew-ps", "rxd1-skew-ps",
"rxd2-skew-ps", "rxd3-skew-ps");
ksz9021_load_values_from_of(phydev, of_node,
- MII_KSZPHY_TX_DATA_PAD_SKEW,
+ MICREL_KSZ9021_RGMII_TX_DATA_PAD_SKEW,
"txd0-skew-ps", "txd1-skew-ps",
"txd2-skew-ps", "txd3-skew-ps");
}
diff --git a/include/linux/micrel_phy.h b/include/linux/micrel_phy.h
index ad05ce6..f9cf9bb 100644
--- a/include/linux/micrel_phy.h
+++ b/include/linux/micrel_phy.h
@@ -38,7 +38,11 @@
#define MICREL_KSZ9021_EXTREG_CTRL 0xB
#define MICREL_KSZ9021_EXTREG_DATA_WRITE 0xC
+#define MICREL_KSZ9021_EXTREG_DATA_READ 0xD
#define MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SCEW 0x104
#define MICREL_KSZ9021_RGMII_RX_DATA_PAD_SCEW 0x105
+#define MICREL_KSZ9021_RGMII_TX_DATA_PAD_SCEW 0x106
+
+#define KSZPHY_EXTREG_WRITE 0x8000
#endif /* _MICREL_PHY_H */
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH net-next 3/3] net: tcp_probe: add IPv6 support
From: Daniel Borkmann @ 2013-08-22 21:20 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20130822.134309.2073296501906078763.davem@davemloft.net>
On 08/22/2013 10:43 PM, David Miller wrote:
> From: Daniel Borkmann <dborkman@redhat.com>
> Date: Wed, 21 Aug 2013 19:48:00 +0200
>
>> + union {
>> + struct sockaddr raw;
>> + struct sockaddr_in v4;
>> + struct sockaddr_in6 v6;
>> + } src, dst;
>
> This bloats up the tcp_log structure unnecessarily. You have
> absolutely no use for the port member, for example.
>
> I know you want to use this so that you can be lazy and only
> use the single printf format specifier. Here, keeping the
> tcp_log compact is more important.
Well, the port is being filled out *and* used in both IPv4 and IPv6
cases. That is why %pISpc is being used, hence IP + port that is being
printed. The port was of course also printed to the log before in
IPv4 only case, so nothing would change there.
^ permalink raw reply
* [PATCH 1/2] genl: Fix genl dumpit() locking.
From: Pravin B Shelar @ 2013-08-22 21:25 UTC (permalink / raw)
To: netdev; +Cc: Pravin B Shelar, Jesse Gross, Johannes Berg
In case of genl-family with parallel ops off, dumpif() callback
is expected to run under genl_lock, But commit def3117493eafd9df
(genl: Allow concurrent genl callbacks.) changed this behaviour
where only first dumpit() op was called under genl-lock.
For subsequent dump, only nlk->cb_lock was taken.
Following patch fixes it by defining locked dumpit() and done()
callback which takes care of genl-locking.
CC: Jesse Gross <jesse@nicira.com>
CC: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
---
v1-v2:
No change.
---
net/netlink/genetlink.c | 46 +++++++++++++++++++++++++++++++++++++++++-----
1 files changed, 41 insertions(+), 5 deletions(-)
diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index f85f8a2..3669039 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -544,6 +544,28 @@ void *genlmsg_put(struct sk_buff *skb, u32 portid, u32 seq,
}
EXPORT_SYMBOL(genlmsg_put);
+static int genl_lock_dumpit(struct sk_buff *skb, struct netlink_callback *cb)
+{
+ struct genl_ops *ops = cb->data;
+ int rc;
+
+ genl_lock();
+ rc = ops->dumpit(skb, cb);
+ genl_unlock();
+ return rc;
+}
+
+static int genl_lock_done(struct netlink_callback *cb)
+{
+ struct genl_ops *ops = cb->data;
+ int rc;
+
+ genl_lock();
+ rc = ops->done(cb);
+ genl_unlock();
+ return rc;
+}
+
static int genl_family_rcv_msg(struct genl_family *family,
struct sk_buff *skb,
struct nlmsghdr *nlh)
@@ -572,15 +594,29 @@ static int genl_family_rcv_msg(struct genl_family *family,
return -EPERM;
if ((nlh->nlmsg_flags & NLM_F_DUMP) == NLM_F_DUMP) {
- struct netlink_dump_control c = {
- .dump = ops->dumpit,
- .done = ops->done,
- };
+ struct netlink_dump_control c;
+ int rc;
if (ops->dumpit == NULL)
return -EOPNOTSUPP;
- return netlink_dump_start(net->genl_sock, skb, nlh, &c);
+ memset(&c, 0, sizeof(c));
+ if (!family->parallel_ops) {
+ genl_unlock();
+ c.data = ops;
+ c.dump = genl_lock_dumpit;
+ if (ops->done)
+ c.done = genl_lock_done;
+ } else {
+ c.dump = ops->dumpit;
+ c.done = ops->done;
+ }
+
+ rc = netlink_dump_start(net->genl_sock, skb, nlh, &c);
+ if (!family->parallel_ops)
+ genl_lock();
+ return rc;
+
}
if (ops->doit == NULL)
--
1.7.1
^ permalink raw reply related
* [PATCH 2/2] genl: Hold reference on correct module while netlink-dump.
From: Pravin B Shelar @ 2013-08-22 21:25 UTC (permalink / raw)
To: netdev; +Cc: Pravin B Shelar, Jesse Gross, Johannes Berg
netlink dump operations take module as parameter to hold
reference for entire netlink dump duration.
Currently it holds ref only on genl module which is not correct
when we use ops registered to genl from another module.
Following patch adds module pointer to genl_ops so that netlink
can hold ref count on it.
CC: Jesse Gross <jesse@nicira.com>
CC: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
---
v1-v2:
No need to ref count genl module.
---
include/net/genetlink.h | 20 +++++++++++++++++---
net/netlink/genetlink.c | 20 +++++++++++---------
2 files changed, 28 insertions(+), 12 deletions(-)
diff --git a/include/net/genetlink.h b/include/net/genetlink.h
index 93024a4..ab8a7c5 100644
--- a/include/net/genetlink.h
+++ b/include/net/genetlink.h
@@ -61,6 +61,7 @@ struct genl_family {
struct list_head ops_list; /* private */
struct list_head family_list; /* private */
struct list_head mcast_groups; /* private */
+ struct module *module;
};
/**
@@ -121,9 +122,22 @@ struct genl_ops {
struct list_head ops_list;
};
-extern int genl_register_family(struct genl_family *family);
-extern int genl_register_family_with_ops(struct genl_family *family,
- struct genl_ops *ops, size_t n_ops);
+extern int __genl_register_family(struct genl_family *family, struct module *module);
+
+static inline int genl_register_family(struct genl_family *family)
+{
+ return __genl_register_family(family, THIS_MODULE);
+}
+
+extern int __genl_register_family_with_ops(struct genl_family *family,
+ struct genl_ops *ops, size_t n_ops, struct module *module);
+
+static inline int genl_register_family_with_ops(struct genl_family *family,
+ struct genl_ops *ops, size_t n_ops)
+{
+ return __genl_register_family_with_ops(family, ops, n_ops, THIS_MODULE);
+}
+
extern int genl_unregister_family(struct genl_family *family);
extern int genl_register_ops(struct genl_family *, struct genl_ops *ops);
extern int genl_unregister_ops(struct genl_family *, struct genl_ops *ops);
diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index 3669039..d491604 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -364,7 +364,7 @@ int genl_unregister_ops(struct genl_family *family, struct genl_ops *ops)
EXPORT_SYMBOL(genl_unregister_ops);
/**
- * genl_register_family - register a generic netlink family
+ * __genl_register_family - register a generic netlink family
* @family: generic netlink family
*
* Registers the specified family after validating it first. Only one
@@ -374,7 +374,7 @@ EXPORT_SYMBOL(genl_unregister_ops);
*
* Return 0 on success or a negative error code.
*/
-int genl_register_family(struct genl_family *family)
+int __genl_register_family(struct genl_family *family, struct module *module)
{
int err = -EINVAL;
@@ -418,6 +418,7 @@ int genl_register_family(struct genl_family *family)
} else
family->attrbuf = NULL;
+ family->module = module;
list_add_tail(&family->family_list, genl_family_chain(family->id));
genl_unlock_all();
@@ -430,10 +431,10 @@ errout_locked:
errout:
return err;
}
-EXPORT_SYMBOL(genl_register_family);
+EXPORT_SYMBOL(__genl_register_family);
/**
- * genl_register_family_with_ops - register a generic netlink family
+ * __genl_register_family_with_ops - register a generic netlink family
* @family: generic netlink family
* @ops: operations to be registered
* @n_ops: number of elements to register
@@ -457,12 +458,12 @@ EXPORT_SYMBOL(genl_register_family);
*
* Return 0 on success or a negative error code.
*/
-int genl_register_family_with_ops(struct genl_family *family,
- struct genl_ops *ops, size_t n_ops)
+int __genl_register_family_with_ops(struct genl_family *family,
+ struct genl_ops *ops, size_t n_ops, struct module *module)
{
int err, i;
- err = genl_register_family(family);
+ err = __genl_register_family(family, module);
if (err)
return err;
@@ -476,7 +477,7 @@ err_out:
genl_unregister_family(family);
return err;
}
-EXPORT_SYMBOL(genl_register_family_with_ops);
+EXPORT_SYMBOL(__genl_register_family_with_ops);
/**
* genl_unregister_family - unregister generic netlink family
@@ -612,7 +613,8 @@ static int genl_family_rcv_msg(struct genl_family *family,
c.done = ops->done;
}
- rc = netlink_dump_start(net->genl_sock, skb, nlh, &c);
+ c.module = family->module;
+ rc = __netlink_dump_start(net->genl_sock, skb, nlh, &c);
if (!family->parallel_ops)
genl_lock();
return rc;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH net-next v4] r8169: fix invalid register dump
From: David Miller @ 2013-08-22 21:26 UTC (permalink / raw)
To: lekensteyn; +Cc: netdev, nic_swsd, bhutchings, romieu
In-Reply-To: <1377119831-29691-1-git-send-email-lekensteyn@gmail.com>
From: Peter Wu <lekensteyn@gmail.com>
Date: Wed, 21 Aug 2013 23:17:11 +0200
> For some reason, my PCIe RTL8111E onboard NIC on a GA-Z68X-UD3H-B3
> motherboard reads as FFs when reading from MMIO with a block size
> larger than 7. Therefore change to reading blocks of four bytes.
>
> Ben Hutchings noted that the buffer is large enough to hold all
> registers, so now all registers are read.
>
> Signed-off-by: Peter Wu <lekensteyn@gmail.com>
> Acked-by: Francois Romieu <romieu@fr.zoreil.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/2] Revert "genetlink: fix family dump race"
From: Pravin Shelar @ 2013-08-22 21:27 UTC (permalink / raw)
To: Johannes Berg; +Cc: David Miller, netdev, Thomas Graf
In-Reply-To: <1377203769.32535.5.camel@jlt4.sipsolutions.net>
On Thu, Aug 22, 2013 at 1:36 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Thu, 2013-08-22 at 13:26 -0700, David Miller wrote:
>
>> How to deal with the problem we were attempting to solve is still
>> under discussion. It seems that even if we go to RCU we must also
>> address to module reference count issue.
>
> Yes, that's a separate issue. However, I think we should also check in
> more detail the dumpit locking issue Pravin pointed out - before his
> changes there was indeed the genl lock used as the cb_mutex. As I've
> said over in the other thread, I'm not sure that change was actually
> useful - it sounded like he confused kernel sockets and userland sockets
> here? (Or maybe I am?!)
>
> OTOH, we've already fixed the race conditions that resulted from his
> patch, at least in nl80211. You might remember the issue Linus ran into
> with the attrbuf, it's looking like that issue was because he changed
> generic netlink to no longer use the genl_lock as the cb_mutex.
>
>> I think the existing locking is very messy, and RCU looks a lot
>> cleaner and has potential for future improvements to the scalability
>> of dumps.
>
> I agree, though we're not all that interested in generic netlink family
> scalability I think, we have less than a dozen families, so this
> shouldn't really be an issue.
>
>> So I'd like to propose that we combine Johannes's RCU conversion
>> with some variant of the module reference count fix.
>>
>> Can you guys work together and come up with something I can apply?
>
> Sure, that in itself isn't really a problem, but if we don't take
> Pravin's patch to "revert" the cb_mutex change in his parallel_ops
> changes, then we definitely need to audit all generic netlink dumpit
> implementations in all users to see if they have similar races to
> nl80211. I originally thought that it was an nl80211 problem, but I'm
> now convinced that it wasn't. Still the new code in nl80211 is probably
> nicer, and we can probably make it parallel_ops now due to these changes
> but I'm not convinced we can audit all genl families.
>
I have sent fixes for genl-locking.
> If it wasn't that so much time has already passed since the parallel_ops
> changes I'd almost suggest reverting those altogether and addressing the
> locking properly ...
>
I think genl-parallel ops patch decouple genl-locking from netlink
lock which simplifies it. This also allows existing genl-family
gradually converted to parallel-ops. Once all are moved to parallel
ops, we can get rid of genl_mutex completely.
Passing mutex after one module to another is messy and confusing.
After genl-parallel op changes this is done only by rtnl module.
I will try to get rid of this cb_mutex parameter so that each layer
can have independent locks. I need to check rtnl module for that.
^ permalink raw reply
* Re: [PATCH 0/2] SH: fix typos in Ether platform data
From: David Miller @ 2013-08-22 21:32 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: netdev, lethal, linux-sh
In-Reply-To: <201308220215.16463.sergei.shtylyov@cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Thu, 22 Aug 2013 02:15:16 +0400
> Shamefully, I have fat fingered in both patches fixing Ether support on SH
> platforms and I didn't bother to compile test them at least with the ARM
> compiler I have at hand (although one of the files turned out to not really be
> compilable by it). Here's 2 patches fixing the typos, they are against David
> Miller's 'net-next.git'.
Applied, thanks Sergei.
^ permalink raw reply
* Re: [PATCH net-next] tcp: increase throughput when reordering is high
From: David Miller @ 2013-08-22 21:40 UTC (permalink / raw)
To: ycheng; +Cc: ncardwell, edumazet, netdev
In-Reply-To: <1377131363-31341-1-git-send-email-ycheng@google.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Wed, 21 Aug 2013 17:29:23 -0700
> The stack currently detects reordering and avoid spurious
> retransmission very well. However the throughput is sub-optimal under
> high reordering because cwnd is increased only if the data is deliverd
> in order. I.e., FLAG_DATA_ACKED check in tcp_ack(). The more packet
> are reordered the worse the throughput is.
>
> Therefore when reordering is proven high, cwnd should advance whenever
> the data is delivered regardless of its ordering. If reordering is low,
> conservatively advance cwnd only on ordered deliveries in Open state,
> and retain cwnd in Disordered state (RFC5681).
>
> Using netperf on a qdisc setup of 20Mbps BW and random RTT from 45ms
> to 55ms (for reordering effect). This change increases TCP throughput
> by 20 - 25% to near bottleneck BW.
>
> A special case is the stretched ACK with new SACK and/or ECE mark.
> For example, a receiver may receive an out of order or ECN packet with
> unacked data buffered because of LRO or delayed ACK. The principle on
> such an ACK is to advance cwnd on the cummulative acked part first,
> then reduce cwnd in tcp_fastretrans_alert().
>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
Applied, your team is doing great work on the TCP stack!
^ permalink raw reply
* Re: Can linux kernel bridge forward 802.1q tagged vlan packets?
From: Marek Kierdelewicz @ 2013-08-22 21:49 UTC (permalink / raw)
To: Stephan von Krawczynski; +Cc: netdev, bridge
In-Reply-To: <20130822224453.ca93782f.skraw@ithnet.com>
Hi,
>My general idea is to bridge tagged vlan packets from a physical
>interface (intel) to a virtual interface (virtio in qemu) and not
>losing the tags, so the qemu guest can use vconfig and friends to get
>some vlan interfaces. Is this possible and are there any additional
>steps necessary besides the usual bridge configuration?
I'm using this setup with KVM virtualization (Qemu's successor). It
didn't work with default nic type for guest (realtek I think) as 802.1q
tags were not preserved properly in one of the directions. I don't
remember specifics. Anyway using e1000 driver instead of default fixed
it. Works like a charm.
Best regards,
Marek Kierdelewicz
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: tcp_probe: add IPv6 support
From: David Miller @ 2013-08-22 21:50 UTC (permalink / raw)
To: dborkman; +Cc: netdev
In-Reply-To: <52168097.7050200@redhat.com>
From: Daniel Borkmann <dborkman@redhat.com>
Date: Thu, 22 Aug 2013 23:20:23 +0200
> On 08/22/2013 10:43 PM, David Miller wrote:
>> From: Daniel Borkmann <dborkman@redhat.com>
>> Date: Wed, 21 Aug 2013 19:48:00 +0200
>>
>>> + union {
>>> + struct sockaddr raw;
>>> + struct sockaddr_in v4;
>>> + struct sockaddr_in6 v6;
>>> + } src, dst;
>>
>> This bloats up the tcp_log structure unnecessarily. You have
>> absolutely no use for the port member, for example.
>>
>> I know you want to use this so that you can be lazy and only
>> use the single printf format specifier. Here, keeping the
>> tcp_log compact is more important.
>
> Well, the port is being filled out *and* used in both IPv4 and IPv6
> cases. That is why %pISpc is being used, hence IP + port that is being
> printed. The port was of course also printed to the log before in
> IPv4 only case, so nothing would change there.
Good point, ok I'll reconsider this series.
^ permalink raw reply
* [PATCH next 1/2] net: can: mscan: add a comment on reg to idx mapping
From: Anatolij Gustschin @ 2013-08-22 22:01 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde; +Cc: Gerhard Sittig, linux-can, netdev
From: Gerhard Sittig <gsi@denx.de>
add a comment about the magic of deriving an MSCAN component index
from the peripheral's physical address / register offset
Cc: linux-can@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Gerhard Sittig <gsi@denx.de>
---
drivers/net/can/mscan/mpc5xxx_can.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/can/mscan/mpc5xxx_can.c b/drivers/net/can/mscan/mpc5xxx_can.c
index 5b0ee8e..bc422ba 100644
--- a/drivers/net/can/mscan/mpc5xxx_can.c
+++ b/drivers/net/can/mscan/mpc5xxx_can.c
@@ -148,7 +148,10 @@ static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
goto exit_put;
}
- /* Determine the MSCAN device index from the physical address */
+ /* Determine the MSCAN device index from the peripheral's
+ * physical address. Register address offsets against the
+ * IMMR base are: 0x1300, 0x1380, 0x2300, 0x2380
+ */
pval = of_get_property(ofdev->dev.of_node, "reg", &plen);
BUG_ON(!pval || plen < sizeof(*pval));
clockidx = (*pval & 0x80) ? 1 : 0;
--
1.7.9.5
^ permalink raw reply related
* [PATCH next 2/2] net: can: mscan: improve clock API use
From: Anatolij Gustschin @ 2013-08-22 22:01 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde; +Cc: Gerhard Sittig, linux-can, netdev
In-Reply-To: <1377208917-16698-1-git-send-email-agust@denx.de>
From: Gerhard Sittig <gsi@denx.de>
the .get_clock() callback is run from probe() and might allocate
resources, introduce a .put_clock() callback that is run from remove()
to undo any allocation activities
prepare and enable the clocks in open(), disable and unprepare the
clocks in close() if clocks were acquired during probe(), to not assume
knowledge about which activities are done in probe() and remove()
use devm_get_clk() to lookup the SYS and REF clocks, to have the clocks
put upon device shutdown
store pointers to data structures upon successful allocation already
instead of deferral until complete setup, such that subroutines in the
setup sequence may access those data structures as well to track their
resource acquisition
since clock allocation remains optional, the release callback as well as
the enable/disable calls in open/close are optional as well
Cc: linux-can@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Gerhard Sittig <gsi@denx.de>
---
drivers/net/can/mscan/mpc5xxx_can.c | 18 ++++++++++++------
drivers/net/can/mscan/mscan.c | 25 ++++++++++++++++++++++++-
drivers/net/can/mscan/mscan.h | 3 +++
3 files changed, 39 insertions(+), 7 deletions(-)
diff --git a/drivers/net/can/mscan/mpc5xxx_can.c b/drivers/net/can/mscan/mpc5xxx_can.c
index bc422ba..e59b3a3 100644
--- a/drivers/net/can/mscan/mpc5xxx_can.c
+++ b/drivers/net/can/mscan/mpc5xxx_can.c
@@ -40,6 +40,7 @@ struct mpc5xxx_can_data {
unsigned int type;
u32 (*get_clock)(struct platform_device *ofdev, const char *clock_name,
int *mscan_clksrc);
+ void (*put_clock)(struct platform_device *ofdev);
};
#ifdef CONFIG_PPC_MPC52xx
@@ -180,7 +181,7 @@ static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
clockdiv = 1;
if (!clock_name || !strcmp(clock_name, "sys")) {
- sys_clk = clk_get(&ofdev->dev, "sys_clk");
+ sys_clk = devm_clk_get(&ofdev->dev, "sys_clk");
if (IS_ERR(sys_clk)) {
dev_err(&ofdev->dev, "couldn't get sys_clk\n");
goto exit_unmap;
@@ -203,7 +204,7 @@ static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
}
if (clocksrc < 0) {
- ref_clk = clk_get(&ofdev->dev, "ref_clk");
+ ref_clk = devm_clk_get(&ofdev->dev, "ref_clk");
if (IS_ERR(ref_clk)) {
dev_err(&ofdev->dev, "couldn't get ref_clk\n");
goto exit_unmap;
@@ -280,6 +281,8 @@ static int mpc5xxx_can_probe(struct platform_device *ofdev)
dev = alloc_mscandev();
if (!dev)
goto exit_dispose_irq;
+ platform_set_drvdata(ofdev, dev);
+ SET_NETDEV_DEV(dev, &ofdev->dev);
priv = netdev_priv(dev);
priv->reg_base = base;
@@ -296,8 +299,6 @@ static int mpc5xxx_can_probe(struct platform_device *ofdev)
goto exit_free_mscan;
}
- SET_NETDEV_DEV(dev, &ofdev->dev);
-
err = register_mscandev(dev, mscan_clksrc);
if (err) {
dev_err(&ofdev->dev, "registering %s failed (err=%d)\n",
@@ -305,8 +306,6 @@ static int mpc5xxx_can_probe(struct platform_device *ofdev)
goto exit_free_mscan;
}
- platform_set_drvdata(ofdev, dev);
-
dev_info(&ofdev->dev, "MSCAN at 0x%p, irq %d, clock %d Hz\n",
priv->reg_base, dev->irq, priv->can.clock.freq);
@@ -324,10 +323,17 @@ exit_unmap_mem:
static int mpc5xxx_can_remove(struct platform_device *ofdev)
{
+ const struct of_device_id *match;
+ const struct mpc5xxx_can_data *data;
struct net_device *dev = platform_get_drvdata(ofdev);
struct mscan_priv *priv = netdev_priv(dev);
+ match = of_match_device(mpc5xxx_can_table, &ofdev->dev);
+ data = match ? match->data : NULL;
+
unregister_mscandev(dev);
+ if (data && data->put_clock)
+ data->put_clock(ofdev);
iounmap(priv->reg_base);
irq_dispose_mapping(dev->irq);
free_candev(dev);
diff --git a/drivers/net/can/mscan/mscan.c b/drivers/net/can/mscan/mscan.c
index e6b4095..a955ec8 100644
--- a/drivers/net/can/mscan/mscan.c
+++ b/drivers/net/can/mscan/mscan.c
@@ -573,10 +573,21 @@ static int mscan_open(struct net_device *dev)
struct mscan_priv *priv = netdev_priv(dev);
struct mscan_regs __iomem *regs = priv->reg_base;
+ if (priv->clk_ipg) {
+ ret = clk_prepare_enable(priv->clk_ipg);
+ if (ret)
+ goto exit_retcode;
+ }
+ if (priv->clk_can) {
+ ret = clk_prepare_enable(priv->clk_can);
+ if (ret)
+ goto exit_dis_ipg_clock;
+ }
+
/* common open */
ret = open_candev(dev);
if (ret)
- return ret;
+ goto exit_dis_can_clock;
napi_enable(&priv->napi);
@@ -604,6 +615,13 @@ exit_free_irq:
exit_napi_disable:
napi_disable(&priv->napi);
close_candev(dev);
+exit_dis_can_clock:
+ if (priv->clk_can)
+ clk_disable_unprepare(priv->clk_can);
+exit_dis_ipg_clock:
+ if (priv->clk_ipg)
+ clk_disable_unprepare(priv->clk_ipg);
+exit_retcode:
return ret;
}
@@ -621,6 +639,11 @@ static int mscan_close(struct net_device *dev)
close_candev(dev);
free_irq(dev->irq, dev);
+ if (priv->clk_can)
+ clk_disable_unprepare(priv->clk_can);
+ if (priv->clk_ipg)
+ clk_disable_unprepare(priv->clk_ipg);
+
return 0;
}
diff --git a/drivers/net/can/mscan/mscan.h b/drivers/net/can/mscan/mscan.h
index af2ed8b..9c24d60 100644
--- a/drivers/net/can/mscan/mscan.h
+++ b/drivers/net/can/mscan/mscan.h
@@ -21,6 +21,7 @@
#ifndef __MSCAN_H__
#define __MSCAN_H__
+#include <linux/clk.h>
#include <linux/types.h>
/* MSCAN control register 0 (CANCTL0) bits */
@@ -283,6 +284,8 @@ struct mscan_priv {
unsigned int type; /* MSCAN type variants */
unsigned long flags;
void __iomem *reg_base; /* ioremap'ed address to registers */
+ struct clk *clk_ipg; /* clock for registers */
+ struct clk *clk_can; /* clock for bitrates */
u8 shadow_statflg;
u8 shadow_canrier;
u8 cur_pri;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 1/2] ethernet: moxa: remove unnecessary platform_set_drvdata()
From: David Miller @ 2013-08-22 22:12 UTC (permalink / raw)
To: jg1.han; +Cc: netdev, jonas.jensen
In-Reply-To: <001901ce9eda$a9351310$fb9f3930$%han@samsung.com>
From: Jingoo Han <jg1.han@samsung.com>
Date: Thu, 22 Aug 2013 10:55:21 +0900
> The driver core clears the driver data to NULL after device_release
> or on probe failure. Thus, it is not needed to manually clear the
> device driver data to NULL.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] ethernet: broadcom: remove unnecessary platform_set_drvdata()
From: David Miller @ 2013-08-22 22:12 UTC (permalink / raw)
To: jg1.han; +Cc: netdev, mbizon, florian
In-Reply-To: <001a01ce9eda$efcfdf80$cf6f9e80$%han@samsung.com>
From: Jingoo Han <jg1.han@samsung.com>
Date: Thu, 22 Aug 2013 10:57:20 +0900
> The driver core clears the driver data to NULL after device_release
> or on probe failure. Thus, it is not needed to manually clear the
> device driver data to NULL.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Applied.
^ permalink raw reply
* Re: Can linux kernel bridge forward 802.1q tagged vlan packets?
From: Stephen Hemminger @ 2013-08-22 22:19 UTC (permalink / raw)
To: Marek Kierdelewicz; +Cc: bridge, Stephan von Krawczynski, netdev
In-Reply-To: <20130822234941.4affc863@catus>
On Thu, 22 Aug 2013 23:49:41 +0200
Marek Kierdelewicz <marek@piasta.pl> wrote:
> Hi,
>
> >My general idea is to bridge tagged vlan packets from a physical
> >interface (intel) to a virtual interface (virtio in qemu) and not
> >losing the tags, so the qemu guest can use vconfig and friends to get
> >some vlan interfaces. Is this possible and are there any additional
> >steps necessary besides the usual bridge configuration?
>
> I'm using this setup with KVM virtualization (Qemu's successor). It
> didn't work with default nic type for guest (realtek I think) as 802.1q
> tags were not preserved properly in one of the directions. I don't
> remember specifics. Anyway using e1000 driver instead of default fixed
> it. Works like a charm.
KVM e1000 Vnic doesn't do VLAN offloading at least in my experience.
Virtio works fine.
^ permalink raw reply
* [PATCH] net/cxgb3: fix revert error
From: Doug Ledford @ 2013-08-22 22:27 UTC (permalink / raw)
To: netdev
Cc: Doug Ledford, Santosh Rastapur, Jay Fenlason, David S. Miller,
Divy Le ray, Alexey Kardashevskiy
[-- Attachment #1: Type: text/plain, Size: 1474 bytes --]
728e2cc Revert "cxgb3: Check and handle the dma mapping errors"
reverted f83331b cxgb3: Check and handle the dma mapping errors,
however, in between those two there was also
be8b678 cxgb3: Correct comparisons and calculations using skb->tail and
skb-transport_header and
15dd16c cxgb3: Correct comparisons and calculations using skb->tail and
skb-transport_header
The author of the revert did not fix up the conflicts in such as way as
to preserve the other two commits, so they were reverted too. As they
correct math issues under certain conditions, they should be retained.
This puts them back in place.
Signed-off-by: Doug Ledford <dledford@redhat.com>
---
drivers/net/ethernet/chelsio/cxgb3/sge.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb3/sge.c
b/drivers/net/ethernet/chelsio/cxgb3/sge.c
index 9c89dc8..632b318 100644
--- a/drivers/net/ethernet/chelsio/cxgb3/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb3/sge.c
@@ -1599,7 +1599,8 @@ static void write_ofld_wr(struct adapter *adap,
struct sk_buff *skb,
flits = skb_transport_offset(skb) / 8;
sgp = ndesc == 1 ? (struct sg_ent *)&d->flit[flits] : sgl;
sgl_flits = make_sgl(skb, sgp, skb_transport_header(skb),
- skb->tail - skb->transport_header,
+ skb_tail_pointer(skb) -
+ skb_transport_header(skb),
adap->pdev);
if (need_skb_unmap()) {
setup_deferred_unmapping(skb, adap->pdev, sgp, sgl_flits);
--
1.8.1.4
[-- Attachment #2: Attached Message Part --]
[-- Type: text/plain, Size: 0 bytes --]
^ permalink raw reply related
* Re: pull request (net-next): ipsec-next 2013-08-22
From: David Miller @ 2013-08-22 23:05 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, netdev
In-Reply-To: <1377169931-7302-1-git-send-email-steffen.klassert@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Thu, 22 Aug 2013 13:12:04 +0200
> 1) Some constifications, from Mathias Krause.
>
> 2) Catch bugs if a hold timer is still active when xfrm_policy_destroy()
> is called, from Fan Du.
>
> 3) Remove a redundant address family checking, from Fan Du.
>
> 4) Make xfrm_state timer monotonic to be independent of system clock changes,
> from Fan Du.
>
> 5) Remove an outdated comment on returning -EREMOTE in the xfrm_lookup(),
> from Rami Rosen.
>
> Please pull or let me know if there are problems.
Pulled, thanks Steffen.
^ permalink raw reply
* Re: ipvsadm: One-packet scheduling with UDP service is unstable
From: Drunkard Zhang @ 2013-08-22 23:24 UTC (permalink / raw)
To: Julian Anastasov
Cc: Wensong Zhang, Simon Horman, Pablo Neira Ayuso, Patrick McHardy,
Jozsef Kadlecsik, David S. Miller, netdev, lvs-devel,
netfilter-devel, netfilter, coreteam, linux-kernel
In-Reply-To: <alpine.LFD.2.00.1308221558160.2993@ja.ssi.bg>
2013/8/22 Julian Anastasov <ja@ssi.bg>:
>
> Hello,
>
> On Thu, 22 Aug 2013, Drunkard Zhang wrote:
>
>> 2013/8/22 Julian Anastasov <ja@ssi.bg>:
>> >
>> > No kernel options should be related to OPS. I assume
>> > you are not using the SH scheduler. Make sure the OPS mode
>> > is properly applied to the virtual service, check for "ops"
>> > in the configuration:
>> >
>> > cat /proc/net/ip_vs
>>
>> Still no lucky here, ops is set in running config, but it's not like
>> that in real world.
>>
>> vs3 ~ # cat /proc/net/ip_vs
>> IP Virtual Server version 1.2.1 (size=1024)
>> Prot LocalAddress:Port Scheduler Flags
>> -> RemoteAddress:Port Forward Weight ActiveConn InActConn
>> UDP 96A46478:0202 wrr ops
>
>> -> 96A46450:0202 Route 25 0 1
>
> The OPS connections are accounted in InActConn
> for a very short period, they live up to 1 jiffie, eg. 10ms.
> Also, WRR should be reliable for OPS while other
> schedulers (eg. *LC) are not suitable.
I noticed this too. While ops working, the InActConn is always
changing too, if it's fixed, the ops is not working.
>> And the traffic routed to each realserver didn't following weight I
>> set, it's routed pretty much one to one. I got 17 udp sources sending
>> to 16 different realservers, the others are bonding to another VIP.
>>
>> Prot LocalAddress:Port CPS InPPS OutPPS InBPS OutBPS
>> -> RemoteAddress:Port
>> UDP x.x.x.120:514 0 67622 0 12339373 0
>> -> x.x.x.65:514 0 29 0 2895 0
>> -> x.x.x.66:514 0 225 0 21850 0
>
> Do you see the same problem with ipvsadm -Ln --stats ?
> ipvsadm -Z may be needed to zero the stats after restoring all
> rules. "Conns" counter in stats should be according to WRR
> weights, it shows the scheduler decisions.
After every restore, the stats also zeroed, right? While, ops still not working.
vs3 ~/pkgs # ./ipvsadm -Z
vs3 ~/pkgs # ./ipvsadm -ln --stats -u [snipped]
Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes
-> RemoteAddress:Port
UDP x.x.x.120:514 0 12497040 0 2572M 0
-> x.x.x.65:514 0 3975 0 394171 0
-> x.x.x.66:514 0 48466 0 4835716 0
-> x.x.x.67:514 0 407051 0 58479621 0
-> x.x.x.68:514 0 561120 0 85289892 0
-> x.x.x.69:514 0 30958 0 3120506 0
-> x.x.x.70:514 0 645475 0 100552K 0
-> x.x.x.71:514 0 147228 0 14560649 0
-> x.x.x.72:514 0 535693 0 84069390 0
-> x.x.x.73:514 0 564787 0 88165140 0
-> x.x.x.74:514 0 346734 0 53256088 0
-> x.x.x.75:514 0 47232 0 4801578 0
-> x.x.x.76:514 0 1175288 0 192699K 0
-> x.x.x.77:514 0 254915 0 25939720 0
-> x.x.x.78:514 0 2701531 0 652417K 0
-> x.x.x.79:514 0 2426686 0 573897K 0
-> x.x.x.80:514 0 2599901 0 629793K 0
-> x.x.x.81:514 0 0 0 0 0
-> x.x.x.82:514 0 0 0 0 0
-> x.x.x.83:514 0 0 0 0 0
-> x.x.x.84:514 0 0 0 0 0
-> x.x.x.85:514 0 0 0 0 0
-> x.x.x.86:514 0 0 0 0 0
-> x.x.x.87:514 0 0 0 0 0
-> x.x.x.88:514 0 0 0 0 0
-> x.x.x.89:514 0 0 0 0 0
> In your rates listing CPS 0 is confusing, even for OPS.
> Is it from the new ipvsadm?
Yes, latest git version. When CPS is changing, the ops works, or it's not.
^ permalink raw reply
* Re: [PATCH ipsec 2/2] ipv6: set skb->protocol on tcp, raw and ip6_append_data genereated skbs
From: Eric Dumazet @ 2013-08-22 23:59 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: Steffen Klassert, David Miller, netdev
In-Reply-To: <20130822195406.GA4745@order.stressinduktion.org>
On Thu, 2013-08-22 at 21:54 +0200, Hannes Frederic Sowa wrote:
> Currently we don't initialize skb->protocol when transmitting data via
> tcp, raw(with and without inclhdr) or udp+ufo or appending data directly
> to the socket transmit queue (via ip6_append_data). This needs to be
> done so that we can get the correct mtu in the xfrm layer.
>
> Setting of skb->protocol happens only in functions where we also have
> a transmitting socket and a new skb, so we don't overwrite old values.
>
> Cc: Steffen Klassert <steffen.klassert@secunet.com>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> ---
Seems good to me.
Acked-by: Eric Dumazet <edumazet@google.com>
^ 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