* Re: Possible networking regression in 3.6.0
From: Chris Clayton @ 2012-10-03 15:01 UTC (permalink / raw)
To: David Miller; +Cc: ja, eric.dumazet, netdev, gpiez, davej
In-Reply-To: <20121002.231037.581571797430134988.davem@davemloft.net>
On 10/03/12 04:10, David Miller wrote:
> From: Julian Anastasov <ja@ssi.bg>
> Date: Wed, 3 Oct 2012 02:24:53 +0300 (EEST)
>
>> Can it be a problem related to fib_info reuse
>> from different routes. For example, when local IP address
>> is created for subnet we have:
>>
>> broadcast 192.168.0.255 dev DEV proto kernel scope link src 192.168.0.1
>> 192.168.0.0/24 dev DEV proto kernel scope link src 192.168.0.1
>> local 192.168.0.1 dev DEV proto kernel scope host src 192.168.0.1
>>
>> The "dev DEV proto kernel scope link src 192.168.0.1" is
>> a reused fib_info structure where we put cached routes.
>> The result can be same fib_info for 192.168.0.255 and
>> 192.168.0.0/24. RTN_BROADCAST is cached only for input
>> routes. Incoming broadcast to 192.168.0.255 can be cached
>> and can cause problems for traffic forwarded to 192.168.0.0/24.
>> So, this patch should solve the problem because it
>> separates the broadcast from unicast traffic.
>
> Now I understand the problem.
>
> I think the way to fix this is to add cfg->fc_type as another
> thing that fib_info objects are key'd by.
>
> I think it also would fix your obscure output multicast case too.
>
>
I've seen the discussion about whether Eric's patch is OK or not, but
thought I'd give it a spin anyway. It applies to 3.6.0 with some fuzz,
but I can confirm that with the patch applied I can now ping my router
and browse the internet from a KVM client, so the Eric's diagnosis
matches the problem I reported.
However, after closing the client, I got an oops. I've taken a
photograph of the screen and uploaded it to
http://i714.photobucket.com/albums/ww149/chris2553/IMAG0059.jpg. As it's
not the final patch, this may be a red herring, but I thought I'd better
give a heads up anyway.
Chris
^ permalink raw reply
* [PATCH net 1/1] bnx2x: fix ring size for 10G functions
From: Yuval Mintz @ 2012-10-03 14:22 UTC (permalink / raw)
To: davem, netdev; +Cc: Yuval Mintz, Ariel Elior, Eilon Greenstein
Commit d760fc37b0f74502b3f748951f22c6683b079a8e caused
1G functions to allocate rx rings which were 1/10 of the
size of 10G functions' rx rings.
However, it also caused 10G functions on 5771x boards to
allocate small rings, which limits their possible (default)
rx throughput. This patch causes all 10G functions to use
rings of intended length by default.
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
Hi Dave,
This is a bug fix which corrects the default rx ring size of
10G functions on 5771x boards.
Please consider applying it to 'net'.
Thanks,
Yuval
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 17 ++++++++++-------
1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
index 30f04a3..2422099 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
@@ -3523,15 +3523,18 @@ static int bnx2x_alloc_fp_mem_at(struct bnx2x *bp, int index)
} else
#endif
if (!bp->rx_ring_size) {
- u32 cfg = SHMEM_RD(bp,
- dev_info.port_hw_config[BP_PORT(bp)].default_cfg);
-
rx_ring_size = MAX_RX_AVAIL/BNX2X_NUM_RX_QUEUES(bp);
- /* Dercease ring size for 1G functions */
- if ((cfg & PORT_HW_CFG_NET_SERDES_IF_MASK) ==
- PORT_HW_CFG_NET_SERDES_IF_SGMII)
- rx_ring_size /= 10;
+ if (CHIP_IS_E3(bp)) {
+ u32 cfg = SHMEM_RD(bp,
+ dev_info.port_hw_config[BP_PORT(bp)].
+ default_cfg);
+
+ /* Decrease ring size for 1G functions */
+ if ((cfg & PORT_HW_CFG_NET_SERDES_IF_MASK) ==
+ PORT_HW_CFG_NET_SERDES_IF_SGMII)
+ rx_ring_size /= 10;
+ }
/* allocate at least number of buffers required by FW */
rx_ring_size = max_t(int, bp->disable_tpa ? MIN_RX_SIZE_NONTPA :
--
1.7.9.rc2
^ permalink raw reply related
* [PATCH] iproute2: List interfaces without net address by default
From: Petr Písař @ 2012-10-03 14:42 UTC (permalink / raw)
To: shemminger; +Cc: netdev, Petr Písař
In-Reply-To: <1348565799-20080-1-git-send-email-ppisar@redhat.com>
This fixes regression in iproute2-3.5.1 when `ip addr show' skipped
interfaces without network layer address.
Wrong output:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:50:54:00:0f:03 brd ff:ff:ff:ff:ff:ff
inet 10.34.25.198/23 brd 10.34.25.255 scope global eth0
inet6 2620:52:0:2219:250:54ff:fe00:f03/64 scope global dynamic
valid_lft 2591919sec preferred_lft 604719sec
inet6 fe80::250:54ff:fe00:f03/64 scope link
valid_lft forever preferred_lft forever
Expected output:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:50:54:00:0f:03 brd ff:ff:ff:ff:ff:ff
inet 10.34.25.198/23 brd 10.34.25.255 scope global eth0
inet6 2620:52:0:2219:250:54ff:fe00:f03/64 scope global dynamic
valid_lft 2591896sec preferred_lft 604696sec
inet6 fe80::250:54ff:fe00:f03/64 scope link
valid_lft forever preferred_lft forever
5: veth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 8a:ec:35:34:1f:a8 brd ff:ff:ff:ff:ff:ff
6: veth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 2e:97:ef:77:40:82 brd ff:ff:ff:ff:ff:ff
Signed-off-by: Petr Písař <ppisar@redhat.com>
---
ip/ipaddress.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index 6c11ce4..5498f46 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -884,6 +884,7 @@ static void ipaddr_filter(struct nlmsg_chain *linfo, struct nlmsg_chain *ainfo)
lp = &linfo->head;
while ( (l = *lp) != NULL) {
int ok = 0;
+ int missing_net_address = 1;
struct ifinfomsg *ifi = NLMSG_DATA(&l->h);
struct nlmsg_list *a;
@@ -891,8 +892,10 @@ static void ipaddr_filter(struct nlmsg_chain *linfo, struct nlmsg_chain *ainfo)
struct nlmsghdr *n = &a->h;
struct ifaddrmsg *ifa = NLMSG_DATA(n);
- if (ifa->ifa_index != ifi->ifi_index ||
- (filter.family && filter.family != ifa->ifa_family))
+ if (ifa->ifa_index != ifi->ifi_index)
+ continue;
+ missing_net_address = 0;
+ if (filter.family && filter.family != ifa->ifa_family)
continue;
if ((filter.scope^ifa->ifa_scope)&filter.scopemask)
continue;
@@ -927,6 +930,9 @@ static void ipaddr_filter(struct nlmsg_chain *linfo, struct nlmsg_chain *ainfo)
ok = 1;
break;
}
+ if (missing_net_address &&
+ (filter.family == AF_UNSPEC || filter.family == AF_PACKET))
+ ok = 1;
if (!ok) {
*lp = l->next;
free(l);
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH] udp: increment UDP_MIB_NOPORTS in mcast receive
From: David Stevens @ 2012-10-03 14:09 UTC (permalink / raw)
To: Eric Dumazet
Cc: chris2553, Dave Jones, David Miller, gpiez, Julian Anastasov,
netdev, netdev-owner
In-Reply-To: <1349270151.12401.2372.camel@edumazet-glaptop>
Eric Dumazet <eric.dumazet@gmail.com> wrote on 10/03/2012 09:15:51 AM:
> So when a host receives an UDP datagram but there was no application
> at the destination port we should increment udpNoPorts, and its not
> an error but just a fact.
Of course. I think our difference is on the definition of
"receives".
I don't think a packet delivered locally due to promiscuous mode,
broadcast
or an imperfect multicast address filter match is a host UDP datagram
receive.
These packets really shouldn't be delivered to UDP at all; they are not
addressed to this host (at least the non-broadcast, no-membership ones).
A unicast UDP packet that doesn't match a local IP address does
not
increment this counter. A promiscuous mode multicast delivery is no
different,
except that the destination alone doesn't tell us if it is for us.
I think counting these will primarily lead to administrators
seeing
non-zero drops and wasting their time trying to track them down.
+-DLS
^ permalink raw reply
* [PATCH] cxgb4: Dynamically allocate memory in t4_memory_rw() and get_vpd_params()
From: Vipul Pandya @ 2012-10-03 13:22 UTC (permalink / raw)
To: netdev; +Cc: davem, divy, dm, leedom, felix, Vipul Pandya, Jay Hernandez
This patch changes memory allocation to reduce stack footprint
Signed-off-by: Jay Hernandez <jay@chelsio.com>
Signed-off-by: Vipul Pandya <vipul@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 43 +++++++++++++++++++--------
1 files changed, 30 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index 35b81d8..137a244 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -408,7 +408,8 @@ static int t4_memory_rw(struct adapter *adap, int mtype, u32 addr, u32 len,
__be32 *buf, int dir)
{
u32 pos, start, end, offset, memoffset;
- int ret;
+ int ret = 0;
+ __be32 *data;
/*
* Argument sanity checks ...
@@ -416,6 +417,10 @@ static int t4_memory_rw(struct adapter *adap, int mtype, u32 addr, u32 len,
if ((addr & 0x3) || (len & 0x3))
return -EINVAL;
+ data = vmalloc(MEMWIN0_APERTURE/sizeof(__be32));
+ if (!data)
+ return -ENOMEM;
+
/*
* Offset into the region of memory which is being accessed
* MEM_EDC0 = 0
@@ -438,7 +443,6 @@ static int t4_memory_rw(struct adapter *adap, int mtype, u32 addr, u32 len,
offset = (addr - start)/sizeof(__be32);
for (pos = start; pos < end; pos += MEMWIN0_APERTURE, offset = 0) {
- __be32 data[MEMWIN0_APERTURE/sizeof(__be32)];
/*
* If we're writing, copy the data from the caller's memory
@@ -452,7 +456,7 @@ static int t4_memory_rw(struct adapter *adap, int mtype, u32 addr, u32 len,
if (offset || len < MEMWIN0_APERTURE) {
ret = t4_mem_win_rw(adap, pos, data, 1);
if (ret)
- return ret;
+ break;
}
while (offset < (MEMWIN0_APERTURE/sizeof(__be32)) &&
len > 0) {
@@ -466,7 +470,7 @@ static int t4_memory_rw(struct adapter *adap, int mtype, u32 addr, u32 len,
*/
ret = t4_mem_win_rw(adap, pos, data, dir);
if (ret)
- return ret;
+ break;
/*
* If we're reading, copy the data into the caller's memory
@@ -480,7 +484,8 @@ static int t4_memory_rw(struct adapter *adap, int mtype, u32 addr, u32 len,
}
}
- return 0;
+ vfree(data);
+ return ret;
}
int t4_memory_write(struct adapter *adap, int mtype, u32 addr, u32 len,
@@ -519,16 +524,21 @@ int get_vpd_params(struct adapter *adapter, struct vpd_params *p)
u32 cclk_param, cclk_val;
int i, ret;
int ec, sn;
- u8 vpd[VPD_LEN], csum;
+ u8 *vpd, csum;
unsigned int vpdr_len, kw_offset, id_len;
- ret = pci_read_vpd(adapter->pdev, VPD_BASE, sizeof(vpd), vpd);
+ vpd = vmalloc(VPD_LEN);
+ if (!vpd)
+ return -ENOMEM;
+
+ ret = pci_read_vpd(adapter->pdev, VPD_BASE, VPD_LEN, vpd);
if (ret < 0)
- return ret;
+ goto out;
if (vpd[0] != PCI_VPD_LRDT_ID_STRING) {
dev_err(adapter->pdev_dev, "missing VPD ID string\n");
- return -EINVAL;
+ ret = -EINVAL;
+ goto out;
}
id_len = pci_vpd_lrdt_size(vpd);
@@ -538,21 +548,24 @@ int get_vpd_params(struct adapter *adapter, struct vpd_params *p)
i = pci_vpd_find_tag(vpd, 0, VPD_LEN, PCI_VPD_LRDT_RO_DATA);
if (i < 0) {
dev_err(adapter->pdev_dev, "missing VPD-R section\n");
- return -EINVAL;
+ ret = -EINVAL;
+ goto out;
}
vpdr_len = pci_vpd_lrdt_size(&vpd[i]);
kw_offset = i + PCI_VPD_LRDT_TAG_SIZE;
if (vpdr_len + kw_offset > VPD_LEN) {
dev_err(adapter->pdev_dev, "bad VPD-R length %u\n", vpdr_len);
- return -EINVAL;
+ ret = -EINVAL;
+ goto out;
}
#define FIND_VPD_KW(var, name) do { \
var = pci_vpd_find_info_keyword(vpd, kw_offset, vpdr_len, name); \
if (var < 0) { \
dev_err(adapter->pdev_dev, "missing VPD keyword " name "\n"); \
- return -EINVAL; \
+ ret = -EINVAL; \
+ goto out; \
} \
var += PCI_VPD_INFO_FLD_HDR_SIZE; \
} while (0)
@@ -564,7 +577,8 @@ int get_vpd_params(struct adapter *adapter, struct vpd_params *p)
if (csum) {
dev_err(adapter->pdev_dev,
"corrupted VPD EEPROM, actual csum %u\n", csum);
- return -EINVAL;
+ ret = -EINVAL;
+ goto out;
}
FIND_VPD_KW(ec, "EC");
@@ -587,6 +601,9 @@ int get_vpd_params(struct adapter *adapter, struct vpd_params *p)
FW_PARAMS_PARAM_X(FW_PARAMS_PARAM_DEV_CCLK));
ret = t4_query_params(adapter, adapter->mbox, 0, 0,
1, &cclk_param, &cclk_val);
+
+out:
+ vfree(vpd);
if (ret)
return ret;
p->cclk = cclk_val;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 5/5] ucc_geth: Add IRQ coalescing
From: Joakim Tjernlund @ 2012-10-03 13:18 UTC (permalink / raw)
Cc: netdev
In-Reply-To: <1347987385-19071-5-git-send-email-Joakim.Tjernlund@transmode.se>
Ping? Got no comments and I can see it in net or net-next trees either.
Joakim Tjernlund <Joakim.Tjernlund@transmode.se> wrote on 2012/09/18 18:56:25:
> From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> To: netdev@vger.kernel.org,
> Cc: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> Date: 2012/09/18 18:56
> Subject: [PATCH 5/5] ucc_geth: Add IRQ coalescing
>
> Enable modest IRQ coalescing(4 pks) to reduce IRQ load.
>
> Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> ---
> arch/powerpc/include/asm/qe.h | 1 +
> drivers/net/ethernet/freescale/ucc_geth.c | 18 +++++++++++++++---
> drivers/net/ethernet/freescale/ucc_geth.h | 20 ++++++++++++++++++++
> 3 files changed, 36 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/qe.h b/arch/powerpc/include/asm/qe.h
> index 5e0b6d5..12a8ac8 100644
> --- a/arch/powerpc/include/asm/qe.h
> +++ b/arch/powerpc/include/asm/qe.h
> @@ -373,6 +373,7 @@ enum comm_dir {
> #define QE_MCC_STOP_RX 0x00000009
> #define QE_ATM_TRANSMIT 0x0000000a
> #define QE_HPAC_CLEAR_ALL 0x0000000b
> +#define QE_SET_LAST_RX_THLD 0x00000013
> #define QE_GRACEFUL_STOP_RX 0x0000001a
> #define QE_RESTART_RX 0x0000001b
> #define QE_HPAC_SET_PRIORITY 0x0000010b
> diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b/drivers/net/ethernet/freescale/ucc_geth.c
> index 7d60b95..772f796 100644
> --- a/drivers/net/ethernet/freescale/ucc_geth.c
> +++ b/drivers/net/ethernet/freescale/ucc_geth.c
> @@ -124,7 +124,7 @@ static struct ucc_geth_info ugeth_primary_info = {
> .ecamptr = ((uint32_t) NULL),
> .eventRegMask = UCCE_OTHER,
> .pausePeriod = 0xf000,
> - .interruptcoalescingmaxvalue = {1, 1, 1, 1, 1, 1, 1, 1},
> + .interruptcoalescingmaxvalue = {4, 4, 4, 4, 4, 4, 4, 4},
> .bdRingLenTx = {
> TX_BD_RING_LEN,
> TX_BD_RING_LEN,
> @@ -237,7 +237,7 @@ static struct sk_buff *get_new_skb(struct ucc_geth_private *ugeth,
> DMA_FROM_DEVICE));
> skb_reserve(skb, UCC_GETH_RX_IP_ALIGNMENT);
> out_be32((u32 __iomem *)bd,
> - (R_E | R_I | (in_be32((u32 __iomem*)bd) & R_W)));
> + (R_E | (in_be32((u32 __iomem*)bd) & R_W)));
>
> return skb;
> }
> @@ -1606,6 +1606,7 @@ static void adjust_link(struct net_device *dev)
> struct ucc_fast __iomem *uf_regs;
> struct phy_device *phydev = ugeth->phydev;
> int new_state = 0;
> + u32 cecr_subblock;
>
> ug_regs = ugeth->ug_regs;
> uf_regs = ugeth->uccf->uf_regs;
> @@ -1657,6 +1658,17 @@ static void adjust_link(struct net_device *dev)
> dev->name, phydev->speed);
> break;
> }
> + cecr_subblock = ucc_fast_get_qe_cr_subblock(ugeth->ug_info->uf_info.ucc_num);
> + if (phydev->speed == SPEED_10)
> + qe_issue_cmd(QE_SET_LAST_RX_THLD, cecr_subblock,
> + QE_CR_PROTOCOL_ETHERNET, UCC_10_TIME);
> + else if (phydev->speed == SPEED_100)
> + qe_issue_cmd(QE_SET_LAST_RX_THLD, cecr_subblock,
> + QE_CR_PROTOCOL_ETHERNET, UCC_100_TIME);
> + else if (phydev->speed == SPEED_1000)
> + qe_issue_cmd(QE_SET_LAST_RX_THLD, cecr_subblock,
> + QE_CR_PROTOCOL_ETHERNET, UCC_GBIT_TIME);
> +
> ugeth->oldspeed = phydev->speed;
> }
>
> @@ -2390,7 +2402,7 @@ static int ucc_geth_alloc_rx(struct ucc_geth_private *ugeth)
> bd = ugeth->rxBd[j] = ugeth->p_rx_bd_ring[j];
> for (i = 0; i < ug_info->bdRingLenRx[j]; i++) {
> /* set bd status and length */
> - out_be32((u32 __iomem *)bd, R_I);
> + out_be32((u32 __iomem *)bd, 0);
> /* clear bd buffer */
> out_be32(&((struct qe_bd __iomem *)bd)->buf, 0);
> bd += sizeof(struct qe_bd);
> diff --git a/drivers/net/ethernet/freescale/ucc_geth.h b/drivers/net/ethernet/freescale/ucc_geth.h
> index b68637e..49165ce 100644
> --- a/drivers/net/ethernet/freescale/ucc_geth.h
> +++ b/drivers/net/ethernet/freescale/ucc_geth.h
> @@ -923,6 +923,26 @@ struct ucc_geth_hardware_statistics {
> #define UCC_GETH_MACCFG1_INIT 0
> #define UCC_GETH_MACCFG2_INIT (MACCFG2_RESERVED_1)
>
> +/*
> + * From QUICC Engine Block Reference Manual, Chap 8.9:
> + * This command is used to set a timeout value for the Ethernet receiver
> + * interrupt coalescing mechanism.
> + * The timeout period is measured from the time that the last Ethernet frame
> + * was received. When the timeout expires, an interrupt is issued to the CPU
> + * even if the interrupt coalescing counter did not reach its maximum value. The
> + * timeout value should be written in the two least significant bytes of CECDR,
> + * and it should be specified in terms of serial clocks.
> + * For example, a value of 1000 in CECDR sets the timeout period to 1000 serial
> + * clocks.
> + * -------------------------------------------------------------------
> + * GBIT = 125MHz => 8ns/tick, 8 bits / tick
> + * 100 = 25 MHz => 40ns/tick, 4 bits / tick
> + * 10 = 2.5 MHz => 400ns/tick, 4 bits / tick
> + */
> +#define UCC_GBIT_TIME 64
> +#define UCC_100_TIME 64
> +#define UCC_10_TIME 8
> +
> /* Ethernet Address Type. */
> enum enet_addr_type {
> ENET_ADDR_TYPE_INDIVIDUAL,
> --
> 1.7.8.6
>
^ permalink raw reply
* Re: [PATCH 4/5] ucc_geth: Increase RX ring buffer from 32 to 64
From: Joakim Tjernlund @ 2012-10-03 13:17 UTC (permalink / raw)
Cc: netdev
In-Reply-To: <1347987385-19071-4-git-send-email-Joakim.Tjernlund@transmode.se>
Ping? Got no comments and I can see it in net or net-next trees either.
Joakim Tjernlund <Joakim.Tjernlund@transmode.se> wrote on 2012/09/18 18:56:24:
> From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> To: netdev@vger.kernel.org,
> Cc: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> Date: 2012/09/18 18:56
> Subject: [PATCH 4/5] ucc_geth: Increase RX ring buffer from 32 to 64
>
> We still see dropped pkgs in a busy network, this makes it better.
>
> Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> ---
> drivers/net/ethernet/freescale/ucc_geth.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/ucc_geth.h b/drivers/net/ethernet/freescale/ucc_geth.h
> index aeb743c..b68637e 100644
> --- a/drivers/net/ethernet/freescale/ucc_geth.h
> +++ b/drivers/net/ethernet/freescale/ucc_geth.h
> @@ -878,7 +878,7 @@ struct ucc_geth_hardware_statistics {
>
> /* Driver definitions */
> #define TX_BD_RING_LEN 0x10
> -#define RX_BD_RING_LEN 0x20
> +#define RX_BD_RING_LEN 0x40
>
> #define TX_RING_MOD_MASK(size) (size-1)
> #define RX_RING_MOD_MASK(size) (size-1)
> --
> 1.7.8.6
>
^ permalink raw reply
* Re: [PATCH 3/5] ucc_geth: Fix two gcc warnings
From: Joakim Tjernlund @ 2012-10-03 13:17 UTC (permalink / raw)
Cc: netdev
In-Reply-To: <1347987385-19071-3-git-send-email-Joakim.Tjernlund@transmode.se>
Ping? Got no comments and I can see it in net or net-next trees either.
Joakim Tjernlund <Joakim.Tjernlund@transmode.se> wrote on 2012/09/18 18:56:23:
> From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> To: netdev@vger.kernel.org,
> Cc: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> Date: 2012/09/18 18:56
> Subject: [PATCH 3/5] ucc_geth: Fix two gcc warnings
>
> ucc_geth.c: In function 'ucc_geth_startup':
> ucc_geth.c:3092:45: warning: comparison between 'enum qe_fltr_largest_external_tbl_lookup_key_size' and 'enum qe_fltr_tbl_lookup_key_size'
>
> ucc_geth.c:3096:45: warning: comparison between 'enum qe_fltr_largest_external_tbl_lookup_key_size' and 'enum qe_fltr_tbl_lookup_key_size'
>
> Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> ---
> drivers/net/ethernet/freescale/ucc_geth.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b/drivers/net/ethernet/freescale/ucc_geth.c
> index 5f1460a..7d60b95 100644
> --- a/drivers/net/ethernet/freescale/ucc_geth.c
> +++ b/drivers/net/ethernet/freescale/ucc_geth.c
> @@ -3074,11 +3074,11 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth)
> if (ug_info->rxExtendedFiltering) {
> size += THREAD_RX_PRAM_ADDITIONAL_FOR_EXTENDED_FILTERING;
> if (ug_info->largestexternallookupkeysize ==
> - QE_FLTR_TABLE_LOOKUP_KEY_SIZE_8_BYTES)
> + QE_FLTR_LARGEST_EXTERNAL_TABLE_LOOKUP_KEY_SIZE_8_BYTES)
> size +=
> THREAD_RX_PRAM_ADDITIONAL_FOR_EXTENDED_FILTERING_8;
> if (ug_info->largestexternallookupkeysize ==
> - QE_FLTR_TABLE_LOOKUP_KEY_SIZE_16_BYTES)
> + QE_FLTR_LARGEST_EXTERNAL_TABLE_LOOKUP_KEY_SIZE_16_BYTES)
> size +=
> THREAD_RX_PRAM_ADDITIONAL_FOR_EXTENDED_FILTERING_16;
> }
> --
> 1.7.8.6
>
^ permalink raw reply
* Re: [PATCH 2/5] ucc_geth: Word align Ethernet RX data
From: Joakim Tjernlund @ 2012-10-03 13:17 UTC (permalink / raw)
Cc: netdev
In-Reply-To: <1347987385-19071-2-git-send-email-Joakim.Tjernlund@transmode.se>
Ping? Got no comments and I can see it in net or net-next trees either.
Joakim Tjernlund <Joakim.Tjernlund@transmode.se> wrote on 2012/09/18 18:56:22:
> From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> To: netdev@vger.kernel.org,
> Cc: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> Date: 2012/09/18 18:56
> Subject: [PATCH 2/5] ucc_geth: Word align Ethernet RX data
>
> UCC controller can shift received Ethernet frames 2 bytes into the buffer,
> making IP data word aligned, this patch enables that feature.
>
> Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> ---
> drivers/net/ethernet/freescale/ucc_geth.c | 19 +++++++++++--------
> drivers/net/ethernet/freescale/ucc_geth.h | 1 +
> 2 files changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b/drivers/net/ethernet/freescale/ucc_geth.c
> index e609c93..5f1460a 100644
> --- a/drivers/net/ethernet/freescale/ucc_geth.c
> +++ b/drivers/net/ethernet/freescale/ucc_geth.c
> @@ -160,6 +160,7 @@ static struct ucc_geth_info ugeth_primary_info = {
> .numThreadsRx = UCC_GETH_NUM_OF_THREADS_1,
> .riscTx = QE_RISC_ALLOCATION_RISC1_AND_RISC2,
> .riscRx = QE_RISC_ALLOCATION_RISC1_AND_RISC2,
> + .ipAddressAlignment = 1,
> };
>
> static struct ucc_geth_info ugeth_info[8];
> @@ -211,12 +212,13 @@ static struct sk_buff *get_new_skb(struct ucc_geth_private *ugeth,
> u8 __iomem *bd)
> {
> struct sk_buff *skb = NULL;
> + u16 buf_len = ugeth->ug_info->uf_info.max_rx_buf_length +
> + UCC_GETH_RX_DATA_BUF_ALIGNMENT +
> + UCC_GETH_RX_IP_ALIGNMENT;
>
> skb = __skb_dequeue(&ugeth->rx_recycle);
> if (!skb)
> - skb = netdev_alloc_skb(ugeth->ndev,
> - ugeth->ug_info->uf_info.max_rx_buf_length +
> - UCC_GETH_RX_DATA_BUF_ALIGNMENT);
> + skb = netdev_alloc_skb(ugeth->ndev, buf_len);
> if (skb == NULL)
> return NULL;
>
> @@ -231,10 +233,9 @@ static struct sk_buff *get_new_skb(struct ucc_geth_private *ugeth,
> out_be32(&((struct qe_bd __iomem *)bd)->buf,
> dma_map_single(ugeth->dev,
> skb->data,
> - ugeth->ug_info->uf_info.max_rx_buf_length +
> - UCC_GETH_RX_DATA_BUF_ALIGNMENT,
> + buf_len,
> DMA_FROM_DEVICE));
> -
> + skb_reserve(skb, UCC_GETH_RX_IP_ALIGNMENT);
> out_be32((u32 __iomem *)bd,
> (R_E | R_I | (in_be32((u32 __iomem*)bd) & R_W)));
>
> @@ -1877,7 +1878,8 @@ static void ucc_geth_free_rx(struct ucc_geth_private *ugeth)
> in_be32(&((struct qe_bd __iomem *)bd)->buf),
> ugeth->ug_info->
> uf_info.max_rx_buf_length +
> - UCC_GETH_RX_DATA_BUF_ALIGNMENT,
> + UCC_GETH_RX_DATA_BUF_ALIGNMENT +
> + UCC_GETH_RX_IP_ALIGNMENT,
> DMA_FROM_DEVICE);
> dev_kfree_skb_any(
> ugeth->rx_skbuff[i][j]);
> @@ -3352,7 +3354,8 @@ static int ucc_geth_tx(struct net_device *dev, u8 txQ)
> if (skb_queue_len(&ugeth->rx_recycle) < RX_BD_RING_LEN &&
> skb_recycle_check(skb,
> ugeth->ug_info->uf_info.max_rx_buf_length +
> - UCC_GETH_RX_DATA_BUF_ALIGNMENT))
> + UCC_GETH_RX_DATA_BUF_ALIGNMENT +
> + UCC_GETH_RX_IP_ALIGNMENT))
> __skb_queue_head(&ugeth->rx_recycle, skb);
> else
> dev_kfree_skb(skb);
> diff --git a/drivers/net/ethernet/freescale/ucc_geth.h b/drivers/net/ethernet/freescale/ucc_geth.h
> index f71b3e7..aeb743c 100644
> --- a/drivers/net/ethernet/freescale/ucc_geth.h
> +++ b/drivers/net/ethernet/freescale/ucc_geth.h
> @@ -855,6 +855,7 @@ struct ucc_geth_hardware_statistics {
> #define UCC_GETH_RX_BD_RING_SIZE_ALIGNMENT 4
> #define UCC_GETH_TX_BD_RING_SIZE_MEMORY_ALIGNMENT 32
> #define UCC_GETH_RX_DATA_BUF_ALIGNMENT 64
> +#define UCC_GETH_RX_IP_ALIGNMENT 2 /* IP word alignment */
>
> #define UCC_GETH_TAD_EF 0x80
> #define UCC_GETH_TAD_V 0x40
> --
> 1.7.8.6
>
^ permalink raw reply
* Re: [PATCH] udp: increment UDP_MIB_NOPORTS in mcast receive
From: Eric Dumazet @ 2012-10-03 13:15 UTC (permalink / raw)
To: David Stevens
Cc: chris2553, Dave Jones, David Miller, gpiez, Julian Anastasov,
netdev, netdev-owner
In-Reply-To: <OFA39D9FC0.CDC6EE41-ON85257A8C.00458030-85257A8C.00461EF4@us.ibm.com>
On Wed, 2012-10-03 at 08:45 -0400, David Stevens wrote:
> netdev-owner@vger.kernel.org wrote on 10/03/2012 03:28:48 AM:
>
> > BTW, it seems we dont properly increase UDP MIB counters when a
> > multicast message is not delivered to at least one socket.
>
> If an interface is in promiscuous mode or there are false
> positives in a multicast address filter, wouldn't this count as
> "drops" packets that were never intended for this machine?
>
Yes, probably. So we drop them and its expected.
> I think an otherwise valid multicast or broadcast packet that doesn't
> have a local receiver is not an error and shouldn't be counted.
Hmmm
This counter is not an "error counter", just a "counter".
RFC definitions are exactly :
udpNoPorts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of received UDP datagrams for which
there was no application at the destination port.
udpInErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of received UDP datagrams that could not be
delivered for reasons other than the lack of an
application at the destination port.
So when a host receives an UDP datagram but there was no application
at the destination port we should increment udpNoPorts, and its not
an error but just a fact.
Now _if_ some reader interprets udpNoPorts increases as an indication
of errors, this reader is wrong.
^ permalink raw reply
* Re: [PATCH] udp: increment UDP_MIB_NOPORTS in mcast receive
From: David Stevens @ 2012-10-03 12:45 UTC (permalink / raw)
To: Eric Dumazet
Cc: chris2553, Dave Jones, David Miller, gpiez, Julian Anastasov,
netdev, netdev-owner
In-Reply-To: <1349249328.12401.1364.camel@edumazet-glaptop>
netdev-owner@vger.kernel.org wrote on 10/03/2012 03:28:48 AM:
> BTW, it seems we dont properly increase UDP MIB counters when a
> multicast message is not delivered to at least one socket.
If an interface is in promiscuous mode or there are false
positives in a multicast address filter, wouldn't this count as
"drops" packets that were never intended for this machine?
I think an otherwise valid multicast or broadcast packet that doesn't
have a local receiver is not an error and shouldn't be counted.
+-DLS
^ permalink raw reply
* Re: drivers/net/cris/eth_v10.c:1715:2: error: too many arguments to function 'e100rxtx_interrupt'
From: Jesper Nilsson @ 2012-10-03 10:46 UTC (permalink / raw)
To: Fengguang Wu; +Cc: kernel-janitors@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <20120928130608.GA5158@localhost>
On Fri, Sep 28, 2012 at 03:06:08PM +0200, Fengguang Wu wrote:
> Hi Jesper,
Hi!
> FYI, a rather old build bug that's introduced by
>
> bafef0a cris build fixes: update eth_v10.c ethernet driver
>
> All error/warnings:
>
> drivers/net/cris/eth_v10.c: In function 'e100_netpoll':
> drivers/net/cris/eth_v10.c:1715:2: error: too many arguments to function 'e100rxtx_interrupt'
> drivers/net/cris/eth_v10.c:1131:1: note: declared here
Yep, I can't figure out why the followup patches never reached mainline,
but we have fixes for exactly that in our in-house tree.
I'll push some move patches after this merge window.
> vim +1715 drivers/net/cris/eth_v10.c
>
> ^1da177e (Linus Torvalds 2005-04-16 1710)
> bafef0ae (Jesper Nilsson 2007-11-14 1711) #ifdef CONFIG_NET_POLL_CONTROLLER
> bafef0ae (Jesper Nilsson 2007-11-14 1712) static void
> bafef0ae (Jesper Nilsson 2007-11-14 1713) e100_netpoll(struct net_device* netdev)
> bafef0ae (Jesper Nilsson 2007-11-14 1714) {
> bafef0ae (Jesper Nilsson 2007-11-14 @1715) e100rxtx_interrupt(NETWORK_DMA_TX_IRQ_NBR, netdev, NULL);
> bafef0ae (Jesper Nilsson 2007-11-14 1716) }
> bafef0ae (Jesper Nilsson 2007-11-14 1717) #endif
> bafef0ae (Jesper Nilsson 2007-11-14 1718)
> ^1da177e (Linus Torvalds 2005-04-16 1719) static int
> ^1da177e (Linus Torvalds 2005-04-16 1720) etrax_init_module(void)
> ^1da177e (Linus Torvalds 2005-04-16 1721) {
> ^1da177e (Linus Torvalds 2005-04-16 1722) return etrax_ethernet_init();
> ^1da177e (Linus Torvalds 2005-04-16 1723) }
Thanks!
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson@axis.com
^ permalink raw reply
* Re: [PATCH 0/3] virtio-net: inline header support
From: Paolo Bonzini @ 2012-10-03 10:53 UTC (permalink / raw)
To: Rusty Russell
Cc: kvm, Michael S. Tsirkin, netdev, linux-kernel, Sasha Levin,
virtualization, Thomas Lendacky, avi
In-Reply-To: <87vces2gxq.fsf__45058.6618776017$1349247807$gmane$org@rustcorp.com.au>
Il 03/10/2012 08:44, Rusty Russell ha scritto:
> There's a reason I haven't done this. I really, really dislike "my
> implemention isn't broken" feature bits. We could have an infinite
> number of them, for each bug in each device.
However, this bug affects (almost) all implementations and (almost) all
devices. It even makes sense to reserve a transport feature bit for it
instead of a device feature bit.
Paolo
^ permalink raw reply
* Re: You have to fix this
From: Vipul Pandya @ 2012-10-03 10:12 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <20120928.134313.2263654281720915031.davem@davemloft.net>
On 28-09-2012 23:13, David Miller wrote:
> From: Vipul Pandya <vipul@chelsio.com>
> Date: Fri, 28 Sep 2012 17:29:22 +0530
>
>> Please let me know how else would I get above warning message?
>
> Maybe your compiler is too old. Does -Wframe-larger-than= show up in your
> build logs with "make V=1"?
>
I am using gcc version 4.4.4 20100726. Yes -Wframe-larger-than=2048 does
show up in my build logs as shown below:
===
gcc -Wp,-MD,arch/x86/kernel/.hw_breakpoint.o.d -nostdinc -isystem
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include
-I/root/git_kernel_tree/net-next/arch/x86/include
-Iarch/x86/include/generated -Iinclude -include
/root/git_kernel_tree/net-next/include/linux/kconfig.h -D__KERNEL__
-Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing
-fno-common -Werror-implicit-function-declaration -Wno-format-security
-fno-delete-null-pointer-checks -O2 -m64 -mtune=generic -mno-red-zone
-mcmodel=kernel -funit-at-a-time -maccumulate-outgoing-args
-DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1
-DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_AVX=1 -pipe
-Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx
-mno-sse2 -mno-3dnow -mno-avx -Wframe-larger-than=2048
-fno-stack-protector -Wno-unused-but-set-variable -fomit-frame-pointer
-Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow
-fconserve-stack -DCC_HAVE_ASM_GOTO -D"KBUILD_STR(s)=#s"
-D"KBUILD_BASENAME=KBUILD_STR(hw_breakpoint)"
-D"KBUILD_MODNAME=KBUILD_STR(hw_breakpoint)" -c -o
arch/x86/kernel/hw_breakpoint.o arch/x86/kernel/hw_breakpoint.c
===
^ permalink raw reply
* Re: [Patch net-next] netpoll: call ->ndo_select_queue() in tx path
From: Sylvain Munaut @ 2012-10-03 9:33 UTC (permalink / raw)
To: David Miller; +Cc: amwang, netdev, edumazet
In-Reply-To: <20120919.172108.1539457128236567338.davem@davemloft.net>
Hi,
>> In netpoll tx path, we miss the chance of calling ->ndo_select_queue(),
>> thus could cause problems when bonding is involved.
>>
>> This patch makes dev_pick_tx() extern (and rename it to netdev_pick_tx())
>> to let netpoll call it in netpoll_send_skb_on_dev().
>>
>> Reported-by: Sylvain Munaut <s.munaut@whatever-company.com>
>> Cc: "David S. Miller" <davem@davemloft.net>
>> Cc: Eric Dumazet <edumazet@google.com>
>> Signed-off-by: Cong Wang <amwang@redhat.com>
>> Tested-by: Sylvain Munaut <s.munaut@whatever-company.com>
>
> Applied, thanks.
Huh, I don't see it in the final 3.6 ?
That's rather inconvenient :(
Cheers,
Sylvain
^ permalink raw reply
* Re: [PATCH net-next v2] netxen: write IP address to firmware when using bonding
From: Nikolay Aleksandrov @ 2012-10-03 9:20 UTC (permalink / raw)
To: sony.chacko; +Cc: agospoda, rajesh.borundia, davem, netdev
In-Reply-To: <1349169386-18391-1-git-send-email-nikolay@redhat.com>
On 10/02/2012 11:16 AM, Nikolay Aleksandrov wrote:
> This patch allows LRO aggregation on bonded devices that contain an NX3031
> device. It also adds a for_each_netdev_in_bond_rcu(bond, slave) macro
> which executes for each slave that has bond as master.
>
> V2: Remove local ip caching, retrieve addresses dynamically and
> restore them if necessary.
>
> Note: Tested with NX3031 adapter.
>
> Signed-off-by: Andy Gospodarek <agospoda@redhat.com>
> Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
> ---
> drivers/net/ethernet/qlogic/netxen/netxen_nic.h | 6 -
> .../net/ethernet/qlogic/netxen/netxen_nic_main.c | 192 +++++++++++----------
> include/linux/netdevice.h | 3 +
> 3 files changed, 100 insertions(+), 101 deletions(-)
>
> diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic.h b/drivers/net/ethernet/qlogic/netxen/netxen_nic.h
> index eb3dfdb..cb4f2ce 100644
> --- a/drivers/net/ethernet/qlogic/netxen/netxen_nic.h
> +++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic.h
> @@ -955,11 +955,6 @@ typedef struct nx_mac_list_s {
> uint8_t mac_addr[ETH_ALEN+2];
> } nx_mac_list_t;
>
> -struct nx_vlan_ip_list {
> - struct list_head list;
> - __be32 ip_addr;
> -};
> -
> /*
> * Interrupt coalescing defaults. The defaults are for 1500 MTU. It is
> * adjusted based on configured MTU.
> @@ -1605,7 +1600,6 @@ struct netxen_adapter {
> struct net_device *netdev;
> struct pci_dev *pdev;
> struct list_head mac_list;
> - struct list_head vlan_ip_list;
>
> spinlock_t tx_clean_lock;
>
> diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c b/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
> index e2a4858..8e3eb61 100644
> --- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
> +++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
> @@ -90,7 +90,6 @@ static irqreturn_t netxen_intr(int irq, void *data);
> static irqreturn_t netxen_msi_intr(int irq, void *data);
> static irqreturn_t netxen_msix_intr(int irq, void *data);
>
> -static void netxen_free_vlan_ip_list(struct netxen_adapter *);
> static void netxen_restore_indev_addr(struct net_device *dev, unsigned long);
> static struct rtnl_link_stats64 *netxen_nic_get_stats(struct net_device *dev,
> struct rtnl_link_stats64 *stats);
> @@ -1451,7 +1450,6 @@ netxen_nic_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
>
> spin_lock_init(&adapter->tx_clean_lock);
> INIT_LIST_HEAD(&adapter->mac_list);
> - INIT_LIST_HEAD(&adapter->vlan_ip_list);
>
> err = netxen_setup_pci_map(adapter);
> if (err)
> @@ -1586,7 +1584,7 @@ static void __devexit netxen_nic_remove(struct pci_dev *pdev)
>
> cancel_work_sync(&adapter->tx_timeout_task);
>
> - netxen_free_vlan_ip_list(adapter);
> + netxen_restore_indev_addr(netdev, NETDEV_DOWN);
> netxen_nic_detach(adapter);
>
> nx_decr_dev_ref_cnt(adapter);
> @@ -3135,66 +3133,22 @@ netxen_destip_supported(struct netxen_adapter *adapter)
> return 1;
> }
>
> -static void
> -netxen_free_vlan_ip_list(struct netxen_adapter *adapter)
> +static inline __be32
> +netxen_get_addr(struct net_device *dev)
> {
> - struct nx_vlan_ip_list *cur;
> - struct list_head *head = &adapter->vlan_ip_list;
> -
> - while (!list_empty(head)) {
> - cur = list_entry(head->next, struct nx_vlan_ip_list, list);
> - netxen_config_ipaddr(adapter, cur->ip_addr, NX_IP_DOWN);
> - list_del(&cur->list);
> - kfree(cur);
> - }
> -
> -}
> -static void
> -netxen_list_config_vlan_ip(struct netxen_adapter *adapter,
> - struct in_ifaddr *ifa, unsigned long event)
> -{
> - struct net_device *dev;
> - struct nx_vlan_ip_list *cur, *tmp_cur;
> - struct list_head *head;
> -
> - dev = ifa->ifa_dev ? ifa->ifa_dev->dev : NULL;
> -
> - if (dev == NULL)
> - return;
> -
> - if (!is_vlan_dev(dev))
> - return;
> + struct in_device *in_dev;
> + __be32 addr = 0;
>
> - switch (event) {
> - case NX_IP_UP:
> - list_for_each(head, &adapter->vlan_ip_list) {
> - cur = list_entry(head, struct nx_vlan_ip_list, list);
> + rcu_read_lock();
> + in_dev = __in_dev_get_rcu(dev);
>
> - if (cur->ip_addr == ifa->ifa_address)
> - return;
> - }
> + if (in_dev)
> + addr = inet_confirm_addr(in_dev, 0, 0, RT_SCOPE_HOST);
>
> - cur = kzalloc(sizeof(struct nx_vlan_ip_list), GFP_ATOMIC);
> - if (cur == NULL) {
> - printk(KERN_ERR "%s: failed to add vlan ip to list\n",
> - adapter->netdev->name);
> - return;
> - }
> -
> - cur->ip_addr = ifa->ifa_address;
> - list_add_tail(&cur->list, &adapter->vlan_ip_list);
> - break;
> - case NX_IP_DOWN:
> - list_for_each_entry_safe(cur, tmp_cur,
> - &adapter->vlan_ip_list, list) {
> - if (cur->ip_addr == ifa->ifa_address) {
> - list_del(&cur->list);
> - kfree(cur);
> - break;
> - }
> - }
> - }
> + rcu_read_unlock();
> + return addr;
> }
> +
> static void
> netxen_config_indev_addr(struct netxen_adapter *adapter,
> struct net_device *dev, unsigned long event)
> @@ -3213,12 +3167,10 @@ netxen_config_indev_addr(struct netxen_adapter *adapter,
> case NETDEV_UP:
> netxen_config_ipaddr(adapter,
> ifa->ifa_address, NX_IP_UP);
> - netxen_list_config_vlan_ip(adapter, ifa, NX_IP_UP);
> break;
> case NETDEV_DOWN:
> netxen_config_ipaddr(adapter,
> ifa->ifa_address, NX_IP_DOWN);
> - netxen_list_config_vlan_ip(adapter, ifa, NX_IP_DOWN);
> break;
> default:
> break;
> @@ -3233,15 +3185,54 @@ netxen_restore_indev_addr(struct net_device *netdev, unsigned long event)
>
> {
> struct netxen_adapter *adapter = netdev_priv(netdev);
> - struct nx_vlan_ip_list *pos, *tmp_pos;
> + struct net_device *vlan_dev, *real_dev;
> unsigned long ip_event;
> + __be32 addr = 0;
>
> ip_event = (event == NETDEV_UP) ? NX_IP_UP : NX_IP_DOWN;
> netxen_config_indev_addr(adapter, netdev, event);
>
> - list_for_each_entry_safe(pos, tmp_pos, &adapter->vlan_ip_list, list) {
> - netxen_config_ipaddr(adapter, pos->ip_addr, ip_event);
> + rcu_read_lock();
> + for_each_netdev_rcu(&init_net, vlan_dev) {
> + if (vlan_dev->priv_flags & IFF_802_1Q_VLAN) {
> + real_dev = vlan_dev_real_dev(vlan_dev);
> +
> + if (real_dev == netdev) {
> + addr = netxen_get_addr(vlan_dev);
> +
> + if (addr) {
> + netxen_config_ipaddr(adapter, addr,
> + ip_event);
> + }
> + }
> + }
> }
> +
> + if (netdev->master) {
> + addr = netxen_get_addr(netdev->master);
> + if (addr)
> + netxen_config_ipaddr(adapter, addr, ip_event);
> + }
> + rcu_read_unlock();
> +}
> +
> +static inline int
> +netxen_config_checkdev(struct net_device *dev)
> +{
> + struct netxen_adapter *adapter;
> +
> + if (!is_netxen_netdev(dev))
> + return -ENODEV;
> +
> + adapter = netdev_priv(dev);
> +
> + if (!adapter)
> + return -ENODEV;
> +
> + if (adapter->is_up != NETXEN_ADAPTER_UP_MAGIC)
> + return -ENODEV;
> +
> + return 0;
> }
>
> static int netxen_netdev_event(struct notifier_block *this,
> @@ -3260,18 +3251,26 @@ recheck:
> goto recheck;
> }
>
> - if (!is_netxen_netdev(dev))
> - goto done;
> + /* If this is a bonding device, look for netxen-based slaves*/
> + if (dev->priv_flags & IFF_BONDING) {
> + struct net_device *slave;
>
> - adapter = netdev_priv(dev);
> + rcu_read_lock();
> + for_each_netdev_in_bond_rcu(dev, slave) {
> + if (netxen_config_checkdev(slave) < 0)
> + continue;
>
> - if (!adapter)
> - goto done;
> -
> - if (adapter->is_up != NETXEN_ADAPTER_UP_MAGIC)
> - goto done;
> + adapter = netdev_priv(slave);
> + netxen_config_indev_addr(adapter, orig_dev, event);
> + }
> + rcu_read_unlock();
> + } else {
> + if (netxen_config_checkdev(dev) < 0)
> + goto done;
>
> - netxen_config_indev_addr(adapter, orig_dev, event);
> + adapter = netdev_priv(dev);
> + netxen_config_indev_addr(adapter, orig_dev, event);
> + }
> done:
> return NOTIFY_DONE;
> }
> @@ -3282,10 +3281,11 @@ netxen_inetaddr_event(struct notifier_block *this,
> {
> struct netxen_adapter *adapter;
> struct net_device *dev;
> -
> + unsigned long ip_event;
> struct in_ifaddr *ifa = (struct in_ifaddr *)ptr;
>
> dev = ifa->ifa_dev ? ifa->ifa_dev->dev : NULL;
> + ip_event = (event == NETDEV_UP) ? NX_IP_UP : NX_IP_DOWN;
>
> recheck:
> if (dev == NULL)
> @@ -3296,30 +3296,35 @@ recheck:
> goto recheck;
> }
>
> - if (!is_netxen_netdev(dev))
> - goto done;
> + /* If this is a bonding device, look for netxen-based slaves*/
> + if (dev->priv_flags & IFF_BONDING) {
> + struct net_device *slave;
>
> - adapter = netdev_priv(dev);
> + rcu_read_lock();
> + for_each_netdev_in_bond_rcu(dev, slave) {
> + if (netxen_config_checkdev(slave) < 0)
> + continue;
>
> - if (!adapter || !netxen_destip_supported(adapter))
> - goto done;
> + adapter = netdev_priv(slave);
>
> - if (adapter->is_up != NETXEN_ADAPTER_UP_MAGIC)
> - goto done;
> + if (!netxen_destip_supported(adapter))
> + continue;
>
> - switch (event) {
> - case NETDEV_UP:
> - netxen_config_ipaddr(adapter, ifa->ifa_address, NX_IP_UP);
> - netxen_list_config_vlan_ip(adapter, ifa, NX_IP_UP);
> - break;
> - case NETDEV_DOWN:
> - netxen_config_ipaddr(adapter, ifa->ifa_address, NX_IP_DOWN);
> - netxen_list_config_vlan_ip(adapter, ifa, NX_IP_DOWN);
> - break;
> - default:
> - break;
> - }
> + netxen_config_ipaddr(adapter, ifa->ifa_address,
> + ip_event);
> + }
> + rcu_read_unlock();
> + } else {
> + if (netxen_config_checkdev(dev) < 0)
> + goto done;
> +
> + adapter = netdev_priv(dev);
>
> + if (!netxen_destip_supported(adapter))
> + goto done;
> +
> + netxen_config_ipaddr(adapter, ifa->ifa_address, ip_event);
> + }
> done:
> return NOTIFY_DONE;
> }
> @@ -3335,9 +3340,6 @@ static struct notifier_block netxen_inetaddr_cb = {
> static void
> netxen_restore_indev_addr(struct net_device *dev, unsigned long event)
> { }
> -static void
> -netxen_free_vlan_ip_list(struct netxen_adapter *adapter)
> -{ }
> #endif
>
> static struct pci_error_handlers netxen_err_handler = {
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 59dc05f3..463bb40 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -1578,6 +1578,9 @@ extern rwlock_t dev_base_lock; /* Device list lock */
> list_for_each_entry_continue(d, &(net)->dev_base_head, dev_list)
> #define for_each_netdev_continue_rcu(net, d) \
> list_for_each_entry_continue_rcu(d, &(net)->dev_base_head, dev_list)
> +#define for_each_netdev_in_bond_rcu(bond, slave) \
> + for_each_netdev_rcu(&init_net, slave) \
> + if (slave->master == bond)
> #define net_device_entry(lh) list_entry(lh, struct net_device, dev_list)
>
> static inline struct net_device *next_net_device(struct net_device *dev)
Hello Dave,
I just synced with upstream, I've missed a few patches and it seems
that it doesn't apply cleanly because my previous patch was
changed before it was applied. There is one character missing from
a comment - "/* root bus? */", in upstream it was changed to
/* root bus */.
("netxen: check for root bus in netxen_mask_aer_correctable")
About the rest, after QLogic test the functionality I'll clean-up the
empty lines and re-send it.
Thank you,
Nik
^ permalink raw reply
* RE: [PATCH v2] iproute2: add support for tcp_metrics
From: David Laight @ 2012-10-03 8:20 UTC (permalink / raw)
To: Stephen Hemminger, Julian Anastasov; +Cc: Eric Dumazet, netdev
In-Reply-To: <20121002172633.2be06886@nehalam.linuxnetplumber.net>
> > fprintf(fp, "%lluus",
> > ((__u64) val * 1000) >> 2);
...
> Remember u64 is not always same as unsigned long long.
> One safe way of handling this is:
...
> fprintf(fp, "%"PRIu64"us",
> ((__u64) val * 1000) >> 3);
Or convert the constant.
fprintf(fp, "%lluus", (val * 1000ull) >> 2);
which may well generate better code on 32bit systems.
David
^ permalink raw reply
* [PATCH] iputils: ping: Fix typo in echo reply
From: Jan Synacek @ 2012-10-03 8:26 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev
[-- Attachment #1: Type: text/plain, Size: 136 bytes --]
Hello,
here is a fix for a typo that's currently present in ping.
Cheers,
--
Jan Synacek
Software Engineer, BaseOS team Brno, Red Hat
[-- Attachment #2: 0001-ping-Fix-typo-in-echo-reply.patch --]
[-- Type: text/x-patch, Size: 662 bytes --]
>From 3b5623a03279538ca9a6f3796626c1aad9ef5477 Mon Sep 17 00:00:00 2001
From: Jan Synacek <jsynacek@redhat.com>
Date: Wed, 3 Oct 2012 10:14:45 +0200
Subject: [PATCH] ping: Fix typo in echo reply
Signed-off-by: Jan Synacek <jsynacek@redhat.com>
---
ping.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ping.c b/ping.c
index 1425d1d..3ab2ae0 100644
--- a/ping.c
+++ b/ping.c
@@ -705,7 +705,7 @@ int send_probe()
void pr_echo_reply(__u8 *_icp, int len)
{
struct icmphdr *icp = (struct icmphdr *)_icp;
- printf(" icmp_req=%u", ntohs(icp->un.echo.sequence));
+ printf(" icmp_seq=%u", ntohs(icp->un.echo.sequence));
}
int
--
1.7.11.4
^ permalink raw reply related
* [PATCH] udp: increment UDP_MIB_NOPORTS in mcast receive
From: Eric Dumazet @ 2012-10-03 7:28 UTC (permalink / raw)
To: Julian Anastasov; +Cc: David Miller, chris2553, netdev, gpiez, Dave Jones
In-Reply-To: <alpine.LFD.2.00.1210030032430.25856@ja.ssi.bg>
On Wed, 2012-10-03 at 02:24 +0300, Julian Anastasov wrote:
> Hello,
>
> On Tue, 2 Oct 2012, Eric Dumazet wrote:
>
> > > David, shouldnt we use a nh_rth_forward instead of a nh_rth_input in
> > > __mkroute_input() ?
> > >
> > > (And change rt_cache_route() as well ?)
> > >
> > > I am testing a patch right now.
> >
> > Yeah, this patch seems to fix the bug for me.
> >
> > [PATCH] ipv4: properly cache forward routes
> >
> > commit d2d68ba9fe8 (ipv4: Cache input routes in fib_info nexthops.)
> > introduced a regression for forwarding.
> >
> > This was hard to reproduce but the symptom was that packets were
> > delivered to local host instead of being forwarded.
> >
> > Add a separate cache (nh_rth_forward) to solve the problem.
>
> Can it be a problem related to fib_info reuse
> from different routes. For example, when local IP address
> is created for subnet we have:
>
> broadcast 192.168.0.255 dev DEV proto kernel scope link src 192.168.0.1
> 192.168.0.0/24 dev DEV proto kernel scope link src 192.168.0.1
> local 192.168.0.1 dev DEV proto kernel scope host src 192.168.0.1
>
> The "dev DEV proto kernel scope link src 192.168.0.1" is
> a reused fib_info structure where we put cached routes.
> The result can be same fib_info for 192.168.0.255 and
> 192.168.0.0/24. RTN_BROADCAST is cached only for input
> routes. Incoming broadcast to 192.168.0.255 can be cached
> and can cause problems for traffic forwarded to 192.168.0.0/24.
> So, this patch should solve the problem because it
> separates the broadcast from unicast traffic.
>
> And the ip_route_input_slow caching will work for
> local and broadcast input routes (above routes 1 and 3) just
> because they differ in scope and use different fib_info.
>
> Another possible failure is for output routes:
>
> multicast 224.0.0.0/4 fib_info
> with unicast
> 192.168.0.0/24 fib_info
>
> The multicast sets RTCF_MULTICAST | RTCF_LOCAL
> and can cause problems for generated unicast traffic on
> fib_info reuse. Depends on the scope, for multicast it is
> usually scope global, so may be it is difficult to happen
> in practice.
>
> __mkroute_output works for local/unicast routes
> because they differ in scope.
Thanks Julian for these informations.
BTW, it seems we dont properly increase UDP MIB counters when a
multicast message is not delivered to at least one socket.
Lets fix this to ease future bug hunting.
I hate when "netstat -s" is useless and we have to use dropwatch to
figure out where we drop a frame.
[PATCH] udp: increment UDP_MIB_NOPORTS in multicast receive
We should increment UDP_MIB_NOPORTS in the case we found
no socket to deliver a copy of one incoming UDP message.
(RFC 4113 udpNoPorts)
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv4/udp.c | 1 +
net/ipv6/udp.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 79c8dbe..dfa73c5 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1591,6 +1591,7 @@ static int __udp4_lib_mcast_deliver(struct net *net, struct sk_buff *skb,
sock_put(stack[i]);
} else {
kfree_skb(skb);
+ UDP_INC_STATS_BH(net, UDP_MIB_NOPORTS, udptable != &udp_table);
}
return 0;
}
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index fc99972..0be9ac2 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -748,6 +748,7 @@ static int __udp6_lib_mcast_deliver(struct net *net, struct sk_buff *skb,
sock_put(stack[i]);
} else {
kfree_skb(skb);
+ UDP6_INC_STATS_BH(net, UDP_MIB_NOPORTS, udptable != &udp_table);
}
return 0;
}
^ permalink raw reply related
* Re: [PATCH 0/2] PCI-Express Non-Transparent Bridge Support
From: Nicholas A. Bellinger @ 2012-10-03 7:11 UTC (permalink / raw)
To: Jon Mason; +Cc: linux-kernel, netdev, linux-pci, Dave Jiang, Christoph Hellwig
In-Reply-To: <1349213177-9985-1-git-send-email-jon.mason@intel.com>
On Tue, 2012-10-02 at 14:26 -0700, Jon Mason wrote:
> I am submitting version 4 of the PCI-Express Non-Transparent Bridge
> patches for inclusion in 3.7. All outstanding issues from the RFC
> process have been addressed.
>
> version 1
> http://thread.gmane.org/gmane.linux.kernel.pci/16443
>
> Version 2 incorporates numerous clean-ups
> http://thread.gmane.org/gmane.linux.kernel.pci/16696
>
> Version 3 incorporates changes to conform NTB and client devices to the
> Linux device model (per Greg KH's request).
> http://thread.gmane.org/gmane.linux.kernel.pci/17808
>
> Version 4 removes the transport transmit tasklet (per Dave Miller's
> request).
> http://thread.gmane.org/gmane.linux.network/244491
>
Hi Jon,
I'm really excited to see this series merged for v3.7-rc code.
Please feel free to add my:
Reviewed-by: Nicholas Bellinger <nab@linux-iscsi.org>
to the two individual patches for an initial merge. I'm not sure which
tree that your intending to take this code upstream via, but also feel
free to add my:
Acked-by: Nicholas Bellinger <nab@linux-iscsi.org>
of your maintainer-ship of /drivers/ntb/ subsystem code.
Very nice work on this series Jon !
--nab
^ permalink raw reply
* Re: [PATCH 0/3] virtio-net: inline header support
From: Rusty Russell @ 2012-10-03 7:10 UTC (permalink / raw)
To: Michael S. Tsirkin, Thomas Lendacky
Cc: Sasha Levin, virtualization, linux-kernel, avi, kvm, netdev
In-Reply-To: <87vces2gxq.fsf@rustcorp.com.au>
Rusty Russell <rusty@rustcorp.com.au> writes:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
>
>> Thinking about Sasha's patches, we can reduce ring usage
>> for virtio net small packets dramatically if we put
>> virtio net header inline with the data.
>> This can be done for free in case guest net stack allocated
>> extra head room for the packet, and I don't see
>> why would this have any downsides.
>
> I've been wanting to do this for the longest time... but...
>
>> Even though with my recent patches qemu
>> no longer requires header to be the first s/g element,
Breaks for me; see why I hate bug features? Now we'd need another
one...
qemu-system-i386: virtio: trying to map MMIO memory
Please try my patch.
Cheers,
Rusty.
^ permalink raw reply
* Re: [PATCH 0/3] virtio-net: inline header support
From: Rusty Russell @ 2012-10-03 6:44 UTC (permalink / raw)
To: Michael S. Tsirkin, Thomas Lendacky
Cc: Sasha Levin, virtualization, linux-kernel, avi, kvm, netdev
In-Reply-To: <cover.1348824232.git.mst@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> writes:
> Thinking about Sasha's patches, we can reduce ring usage
> for virtio net small packets dramatically if we put
> virtio net header inline with the data.
> This can be done for free in case guest net stack allocated
> extra head room for the packet, and I don't see
> why would this have any downsides.
I've been wanting to do this for the longest time... but...
> Even though with my recent patches qemu
> no longer requires header to be the first s/g element,
> we need a new feature bit to detect this.
> A trivial qemu patch will be sent separately.
There's a reason I haven't done this. I really, really dislike "my
implemention isn't broken" feature bits. We could have an infinite
number of them, for each bug in each device.
So my plan was to tie this assumption to the new PCI layout. And have a
stress-testing patch like the one below in the kernel (see my virtio-wip
branch for stuff like this). Turn it on at boot with
"virtio_ring.torture" on the kernel commandline.
BTW, I've fixed lguest, but my kvm here (Ubuntu precise, kvm-qemu 1.0)
is too old. Building the latest git now...
Cheers,
Rusty.
Subject: virtio: CONFIG_VIRTIO_DEVICE_TORTURE
Virtio devices are not supposed to depend on the framing of the scatter-gather
lists, but various implementations did. Safeguard this in future by adding
an option to deliberately create perverse descriptors.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 8d5bddb..930a4ea 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -5,6 +5,15 @@ config VIRTIO
bus, such as CONFIG_VIRTIO_PCI, CONFIG_VIRTIO_MMIO, CONFIG_LGUEST,
CONFIG_RPMSG or CONFIG_S390_GUEST.
+config VIRTIO_DEVICE_TORTURE
+ bool "Virtio device torture tests"
+ depends on VIRTIO && DEBUG_KERNEL
+ help
+ This makes the virtio_ring implementation creatively change
+ the format of requests to make sure that devices are
+ properly implemented. This will make your virtual machine
+ slow *and* unreliable! Say N.
+
menu "Virtio drivers"
config VIRTIO_PCI
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index e639584..8893753 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -124,6 +124,149 @@ struct vring_virtqueue
#define to_vvq(_vq) container_of(_vq, struct vring_virtqueue, vq)
+#ifdef CONFIG_VIRTIO_DEVICE_TORTURE
+static bool torture;
+module_param(torture, bool, 0644);
+
+struct torture {
+ unsigned int orig_out, orig_in;
+ void *orig_data;
+ struct scatterlist sg[4];
+ struct scatterlist orig_sg[];
+};
+
+static size_t tot_len(struct scatterlist sg[], unsigned num)
+{
+ size_t len, i;
+
+ for (len = 0, i = 0; i < num; i++)
+ len += sg[i].length;
+
+ return len;
+}
+
+static void copy_sg_data(const struct scatterlist *dst, unsigned dnum,
+ const struct scatterlist *src, unsigned snum)
+{
+ unsigned len;
+ struct scatterlist s, d;
+
+ s = *src;
+ d = *dst;
+
+ while (snum && dnum) {
+ len = min(s.length, d.length);
+ memcpy(sg_virt(&d), sg_virt(&s), len);
+ d.offset += len;
+ d.length -= len;
+ s.offset += len;
+ s.length -= len;
+ if (!s.length) {
+ BUG_ON(snum == 0);
+ src++;
+ snum--;
+ s = *src;
+ }
+ if (!d.length) {
+ BUG_ON(dnum == 0);
+ dst++;
+ dnum--;
+ d = *dst;
+ }
+ }
+}
+
+static bool torture_replace(struct scatterlist **sg,
+ unsigned int *out,
+ unsigned int *in,
+ void **data,
+ gfp_t gfp)
+{
+ static size_t seed;
+ struct torture *t;
+ size_t outlen, inlen, ourseed, len1;
+ void *buf;
+
+ if (!torture)
+ return true;
+
+ outlen = tot_len(*sg, *out);
+ inlen = tot_len(*sg + *out, *in);
+
+ /* This will break horribly on large block requests. */
+ t = kmalloc(sizeof(*t) + (*out + *in) * sizeof(t->orig_sg[1])
+ + outlen + 1 + inlen + 1, gfp);
+ if (!t)
+ return false;
+
+ sg_init_table(t->sg, 4);
+ buf = &t->orig_sg[*out + *in];
+
+ memcpy(t->orig_sg, *sg, sizeof(**sg) * (*out + *in));
+ t->orig_out = *out;
+ t->orig_in = *in;
+ t->orig_data = *data;
+ *data = t;
+
+ ourseed = ACCESS_ONCE(seed);
+ seed++;
+
+ *sg = t->sg;
+ if (outlen) {
+ /* Split outbuf into two parts, one byte apart. */
+ *out = 2;
+ len1 = ourseed % (outlen + 1);
+ sg_set_buf(&t->sg[0], buf, len1);
+ buf += len1 + 1;
+ sg_set_buf(&t->sg[1], buf, outlen - len1);
+ buf += outlen - len1;
+ copy_sg_data(t->sg, *out, t->orig_sg, t->orig_out);
+ }
+
+ if (inlen) {
+ /* Split inbuf into two parts, one byte apart. */
+ *in = 2;
+ len1 = ourseed % (inlen + 1);
+ sg_set_buf(&t->sg[*out], buf, len1);
+ buf += len1 + 1;
+ sg_set_buf(&t->sg[*out + 1], buf, inlen - len1);
+ buf += inlen - len1;
+ }
+ return true;
+}
+
+static void *torture_done(struct torture *t)
+{
+ void *data;
+
+ if (!torture)
+ return t;
+
+ if (t->orig_in)
+ copy_sg_data(t->orig_sg + t->orig_out, t->orig_in,
+ t->sg + (t->orig_out ? 2 : 0), 2);
+
+ data = t->orig_data;
+ kfree(t);
+ return data;
+}
+
+#else
+static bool torture_replace(struct scatterlist **sg,
+ unsigned int *out,
+ unsigned int *in,
+ void **data,
+ gfp_t gfp)
+{
+ return true;
+}
+
+static void *torture_done(void *data)
+{
+ return data;
+}
+#endif /* CONFIG_VIRTIO_DEVICE_TORTURE */
+
/* Set up an indirect table of descriptors and add it to the queue. */
static int vring_add_indirect(struct vring_virtqueue *vq,
struct scatterlist sg[],
@@ -213,6 +356,9 @@ int virtqueue_add_buf(struct virtqueue *_vq,
BUG_ON(data == NULL);
+ if (!torture_replace(&sg, &out, &in, &data, gfp))
+ return -ENOMEM;
+
#ifdef DEBUG
{
ktime_t now = ktime_get();
@@ -246,6 +392,7 @@ int virtqueue_add_buf(struct virtqueue *_vq,
if (out)
vq->notify(&vq->vq);
END_USE(vq);
+ torture_done(data);
return -ENOSPC;
}
@@ -476,7 +623,7 @@ void *virtqueue_get_buf(struct virtqueue *_vq, unsigned int *len)
#endif
END_USE(vq);
- return ret;
+ return torture_done(ret);
}
EXPORT_SYMBOL_GPL(virtqueue_get_buf);
^ permalink raw reply related
* RE: [PATCHv4 1/4] modem_shm: Add Modem Access Framework
From: Arun MURTHY @ 2012-10-03 4:31 UTC (permalink / raw)
To: anish singh
Cc: Greg KH, linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-doc@vger.kernel.org, alan@lxorguk.ukuu.org.uk
In-Reply-To: <CAK7N6vqpHvi0R4eY0NPJ90Yu1_sVXOri-qOU5FPhp_5XcY3z0w@mail.gmail.com>
> On Wed, Oct 3, 2012 at 9:24 AM, Arun MURTHY
> <arun.murthy@stericsson.com> wrote:
> >> On Mon, Oct 01, 2012 at 07:30:38AM +0200, Arun MURTHY wrote:
> >> > > On Fri, Sep 28, 2012 at 01:35:01PM +0530, Arun Murthy wrote:
> >> > > > +#include <linux/module.h>
> >> > > > +#include <linux/slab.h>
> >> > > > +#include <linux/err.h>
> >> > > > +#include <linux/printk.h>
> >> > > > +#include <linux/modem_shm/modem.h>
> >> > > > +
> >> > > > +static struct class *modem_class;
> >> > >
> >> > > What's wrong with a bus_type instead?
> >> >
> >> > Can I know the advantage of using bus_type over class?
> >>
> >> You have devices living on a bus, and it's much more descriptive than
> >> a class (which we are going to eventually get rid of one of these days...).
> >>
> >> Might I ask why you choose a class over a bus_type?
> >
> > Basically my requirement is to create a central entity for accessing
> > and releasing modem from APE. Since this is done by different clients
> > the central entity should be able to handle the request and play
> > safely, since this has more affect in system suspend and deep sleep.
> > Using class helps me in achieving this and also create an entry to
> > user space which can be used in the later parts. Moreover
> You can have that same mechanism work for bus_type as well.
> > this not something like a bus or so, so I didn't use bus instead went
> > with a simple class approach.
> >
> >>
> >> > > > +int modem_release(struct modem_desc *mdesc) {
> >> > > > + if (!mdesc->release)
> >> > > > + return -EFAULT;
> >> > > > +
> >> > > > + if (modem_is_requested(mdesc)) {
> >> > > > + atomic_dec(&mdesc->mclients->cnt);
> >> > > > + if (atomic_read(&mdesc->use_cnt) == 1) {
> >> > > > + mdesc->release(mdesc);
> >> > > > + atomic_dec(&mdesc->use_cnt);
> >> > > > + }
> >> > >
> >> > > Eeek, why aren't you using the built-in reference counting that
> >> > > the struct device provided to you, and instead are rolling your own?
> >> > > This happens in many places, why?
> >> >
> >> > My usage of counters over here is for each modem there are many
> clients.
> >> > Each of the clients will have a ref to modem_desc. Each of them use
> >> > this for requesting and releasing the modem. One counter for
> >> > tracking the request and release for each client which is done by
> >> > variable 'cnt' in
> >> struct clients.
> >> > The counter use_cnt is used for tracking the modem request/release
> >> > irrespective of the clients and counter cli_cnt is used for
> >> > restricting the modem_get to the no of clients defined in no_clients.
> >> >
> >> > So totally 3 counter one for restricting the usage of modem_get by
> >> > clients, second for restricting modem request/release at top level,
> >> > and 3rd for restricting modem release/request for per client per
> >> > modem
> >> basis.
> >> >
> >> > Can you let me know if the same can be achieved by using built-in
> >> > ref counting?
> >>
> >> Yes, because you don't need all of those different levels, just stick
> >> with one and you should be fine. :)
> >>
> >
> > No, checks at all these levels are required, I have briefed out the need also.
> > This will have effect on system power management, i.e suspend and deep
> > sleep.
> > We restrict that the drivers should request modem only once and
> > release only once, but we cannot rely on the clients hence a check for
> > the same has to be done in the MAF. Also the no of clients should be
> > defined and hence a check for the same is done in MAF. Apart from all
> > these the requests coming from all the clients is to be accumulated
> > and based on that modem release or access should be performed, hence
> so.
> I think best way to deal with this is:
> Define a new bus type and have your clients call the bus exposed
> functionality when ever they need a service.So in your case it would be
> request and release only AND when all of your clients have released the bus
> then you can do the cleanup i.e. switch off the modem and on added
> advantage of making it a bus_type would be that you can do the reference
> counting in your bus driver.
>
> Designing is not my forte but I feel this way you can solve the problem at
> hand.
> Please feel free to correct me.I would really appreciate it.
At the very first look itself this MAF is not a bus by its technical meaning, so
why to use bus_type is the point that I have.
Thanks and Regards,
Arun R Murthy
------------------
^ permalink raw reply
* Re: [PATCHv4 1/4] modem_shm: Add Modem Access Framework
From: anish singh @ 2012-10-03 4:17 UTC (permalink / raw)
To: Arun MURTHY
Cc: Greg KH, linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-doc@vger.kernel.org, alan@lxorguk.ukuu.org.uk
In-Reply-To: <F45880696056844FA6A73F415B568C695B6962CC8C@EXDCVYMBSTM006.EQ1STM.local>
On Wed, Oct 3, 2012 at 9:24 AM, Arun MURTHY <arun.murthy@stericsson.com> wrote:
>> On Mon, Oct 01, 2012 at 07:30:38AM +0200, Arun MURTHY wrote:
>> > > On Fri, Sep 28, 2012 at 01:35:01PM +0530, Arun Murthy wrote:
>> > > > +#include <linux/module.h>
>> > > > +#include <linux/slab.h>
>> > > > +#include <linux/err.h>
>> > > > +#include <linux/printk.h>
>> > > > +#include <linux/modem_shm/modem.h>
>> > > > +
>> > > > +static struct class *modem_class;
>> > >
>> > > What's wrong with a bus_type instead?
>> >
>> > Can I know the advantage of using bus_type over class?
>>
>> You have devices living on a bus, and it's much more descriptive than a class
>> (which we are going to eventually get rid of one of these days...).
>>
>> Might I ask why you choose a class over a bus_type?
>
> Basically my requirement is to create a central entity for accessing and releasing
> modem from APE. Since this is done by different clients the central entity should
> be able to handle the request and play safely, since this has more affect in
> system suspend and deep sleep. Using class helps me in achieving this and
> also create an entry to user space which can be used in the later parts. Moreover
You can have that same mechanism work for bus_type as well.
> this not something like a bus or so, so I didn't use bus instead went with a
> simple class approach.
>
>>
>> > > > +int modem_release(struct modem_desc *mdesc) {
>> > > > + if (!mdesc->release)
>> > > > + return -EFAULT;
>> > > > +
>> > > > + if (modem_is_requested(mdesc)) {
>> > > > + atomic_dec(&mdesc->mclients->cnt);
>> > > > + if (atomic_read(&mdesc->use_cnt) == 1) {
>> > > > + mdesc->release(mdesc);
>> > > > + atomic_dec(&mdesc->use_cnt);
>> > > > + }
>> > >
>> > > Eeek, why aren't you using the built-in reference counting that the
>> > > struct device provided to you, and instead are rolling your own?
>> > > This happens in many places, why?
>> >
>> > My usage of counters over here is for each modem there are many clients.
>> > Each of the clients will have a ref to modem_desc. Each of them use
>> > this for requesting and releasing the modem. One counter for tracking
>> > the request and release for each client which is done by variable 'cnt' in
>> struct clients.
>> > The counter use_cnt is used for tracking the modem request/release
>> > irrespective of the clients and counter cli_cnt is used for
>> > restricting the modem_get to the no of clients defined in no_clients.
>> >
>> > So totally 3 counter one for restricting the usage of modem_get by
>> > clients, second for restricting modem request/release at top level,
>> > and 3rd for restricting modem release/request for per client per modem
>> basis.
>> >
>> > Can you let me know if the same can be achieved by using built-in ref
>> > counting?
>>
>> Yes, because you don't need all of those different levels, just stick with one
>> and you should be fine. :)
>>
>
> No, checks at all these levels are required, I have briefed out the need also.
> This will have effect on system power management, i.e suspend and deep
> sleep.
> We restrict that the drivers should request modem only once and release
> only once, but we cannot rely on the clients hence a check for the same has
> to be done in the MAF. Also the no of clients should be defined and hence a
> check for the same is done in MAF. Apart from all these the requests coming
> from all the clients is to be accumulated and based on that modem release
> or access should be performed, hence so.
I think best way to deal with this is:
Define a new bus type and have your clients call the bus exposed functionality
when ever they need a service.So in your case it would be request and release
only AND when all of your clients have released the bus then you can do the
cleanup i.e. switch off the modem and on added advantage of making it a bus_type
would be that you can do the reference counting in your bus driver.
Designing is not my forte but I feel this way you can solve the problem at hand.
Please feel free to correct me.I would really appreciate it.
>
> Thanks and Regards,
> Arun R Murthy
> -------------------
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* RE: [PATCHv4 1/4] modem_shm: Add Modem Access Framework
From: Arun MURTHY @ 2012-10-03 3:54 UTC (permalink / raw)
To: Greg KH
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-doc@vger.kernel.org, alan@lxorguk.ukuu.org.uk
In-Reply-To: <20121001155940.GA1957@kroah.com>
> On Mon, Oct 01, 2012 at 07:30:38AM +0200, Arun MURTHY wrote:
> > > On Fri, Sep 28, 2012 at 01:35:01PM +0530, Arun Murthy wrote:
> > > > +#include <linux/module.h>
> > > > +#include <linux/slab.h>
> > > > +#include <linux/err.h>
> > > > +#include <linux/printk.h>
> > > > +#include <linux/modem_shm/modem.h>
> > > > +
> > > > +static struct class *modem_class;
> > >
> > > What's wrong with a bus_type instead?
> >
> > Can I know the advantage of using bus_type over class?
>
> You have devices living on a bus, and it's much more descriptive than a class
> (which we are going to eventually get rid of one of these days...).
>
> Might I ask why you choose a class over a bus_type?
Basically my requirement is to create a central entity for accessing and releasing
modem from APE. Since this is done by different clients the central entity should
be able to handle the request and play safely, since this has more affect in
system suspend and deep sleep. Using class helps me in achieving this and
also create an entry to user space which can be used in the later parts. Moreover
this not something like a bus or so, so I didn't use bus instead went with a
simple class approach.
>
> > > > +int modem_release(struct modem_desc *mdesc) {
> > > > + if (!mdesc->release)
> > > > + return -EFAULT;
> > > > +
> > > > + if (modem_is_requested(mdesc)) {
> > > > + atomic_dec(&mdesc->mclients->cnt);
> > > > + if (atomic_read(&mdesc->use_cnt) == 1) {
> > > > + mdesc->release(mdesc);
> > > > + atomic_dec(&mdesc->use_cnt);
> > > > + }
> > >
> > > Eeek, why aren't you using the built-in reference counting that the
> > > struct device provided to you, and instead are rolling your own?
> > > This happens in many places, why?
> >
> > My usage of counters over here is for each modem there are many clients.
> > Each of the clients will have a ref to modem_desc. Each of them use
> > this for requesting and releasing the modem. One counter for tracking
> > the request and release for each client which is done by variable 'cnt' in
> struct clients.
> > The counter use_cnt is used for tracking the modem request/release
> > irrespective of the clients and counter cli_cnt is used for
> > restricting the modem_get to the no of clients defined in no_clients.
> >
> > So totally 3 counter one for restricting the usage of modem_get by
> > clients, second for restricting modem request/release at top level,
> > and 3rd for restricting modem release/request for per client per modem
> basis.
> >
> > Can you let me know if the same can be achieved by using built-in ref
> > counting?
>
> Yes, because you don't need all of those different levels, just stick with one
> and you should be fine. :)
>
No, checks at all these levels are required, I have briefed out the need also.
This will have effect on system power management, i.e suspend and deep
sleep.
We restrict that the drivers should request modem only once and release
only once, but we cannot rely on the clients hence a check for the same has
to be done in the MAF. Also the no of clients should be defined and hence a
check for the same is done in MAF. Apart from all these the requests coming
from all the clients is to be accumulated and based on that modem release
or access should be performed, hence so.
Thanks and Regards,
Arun R Murthy
-------------------
^ 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