* Re: [PATCH 1/1] ipv6: fix the noflags test in addrconf_get_prefix_route
From: David Miller @ 2013-01-10 22:39 UTC (permalink / raw)
To: yoshfuji; +Cc: r.kuntz, netdev, linux-kernel, andi
In-Reply-To: <50EE9141.6020805@linux-ipv6.org>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Thu, 10 Jan 2013 19:00:33 +0900
> Romain KUNTZ wrote:
>> From e7ece201c35615c44a3cfdc10ee28ad5a5878f41 Mon Sep 17 00:00:00 2001
>> From: Romain Kuntz <r.kuntz@ipflavors.com>
>> Date: Wed, 9 Jan 2013 15:02:26 +0100
>> Subject: [PATCH 1/1] ipv6: fix the noflags test in addrconf_get_prefix_route
>>
>> The tests on the flags in addrconf_get_prefix_route() does no make
>> much sense: the 'noflags' parameter contains the set of flags that
>> must not match with the route flags, so the test must be done
>> against 'noflags', and not against 'flags'.
>>
>> Signed-off-by: Romain Kuntz <r.kuntz@ipflavors.com>
...
> Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Applied.
^ permalink raw reply
* Re: tainted warnings with tcp splicing in 3.7.1
From: David Miller @ 2013-01-10 22:39 UTC (permalink / raw)
To: eric.dumazet; +Cc: c.becker, netdev, w
In-Reply-To: <1357801149.27446.1142.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 09 Jan 2013 22:59:09 -0800
> [PATCH] tcp: fix splice() and tcp collapsing interaction
>
> Under unusual circumstances, TCP collapse can split a big GRO TCP packet
> while its being used in a splice(socket->pipe) operation.
>
> skb_splice_bits() releases the socket lock before calling
> splice_to_pipe().
>
> [ 1081.353685] WARNING: at net/ipv4/tcp.c:1330 tcp_cleanup_rbuf+0x4d/0xfc()
> [ 1081.371956] Hardware name: System x3690 X5 -[7148Z68]-
> [ 1081.391820] cleanup rbuf bug: copied AD3BCF1 seq AD370AF rcvnxt AD3CF13
>
> To fix this problem, we must eat skbs in tcp_recv_skb().
>
> Remove the inline keyword from tcp_recv_skb() definition since
> it has three call sites.
>
> Reported-by: Christian Becker <c.becker@traviangames.com>
> Cc: Willy Tarreau <w@1wt.eu>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] doc: Clarify behavior when sysctl tcp_ecn = 1
From: David Miller @ 2013-01-10 22:40 UTC (permalink / raw)
To: subramanian.vijay; +Cc: netdev, edumazet, rick.jones2
In-Reply-To: <1357770090-29253-1-git-send-email-subramanian.vijay@gmail.com>
From: Vijay Subramanian <subramanian.vijay@gmail.com>
Date: Wed, 9 Jan 2013 14:21:30 -0800
> Recent commit (commit 7e3a2dc52953 doc: make the description of how tcp_ecn
> works more explicit and clear ) clarified the behavior of tcp_ecn sysctl
> variable but description is inconsistent. When requested by incoming conections,
> ECN is enabled with not just tcp_ecn = 2 but also with tcp_ecn = 1.
>
> This patch makes it clear that with tcp_ecn = 1, ECN is enabled when requested
> by incoming connections.
>
> Also fix spelling of 'incoming'.
>
> Signed-off-by: Vijay Subramanian <subramanian.vijay@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: align define usage to satisfy static checkers
From: David Miller @ 2013-01-10 22:40 UTC (permalink / raw)
To: ariele; +Cc: netdev
In-Reply-To: <1357751075-23112-1-git-send-email-ariele@broadcom.com>
From: "Ariel Elior" <ariele@broadcom.com>
Date: Wed, 9 Jan 2013 19:04:35 +0200
> Static checkers complained that the E1H_FUNC_MAX define is used
> incorrectly in bnx2x_pretend_func(). The complaint was justified,
> although its not a real bug, as the first part of the conditional
> protects us in this case (a real bug would happen if a VF tried to
> use the pretend func, but there are no VFs in E1H chips).
>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Ariel Elior <ariele@broadcom.com>
Applied.
^ permalink raw reply
* Re: [RFCv2 00/12] Introduce host-side virtio queue and CAIF Virtio.
From: Rusty Russell @ 2013-01-10 22:48 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev, Linus Walleij, virtualization
In-Reply-To: <20130110111117.GE13451@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> writes:
> On Thu, Jan 10, 2013 at 09:00:55PM +1030, Rusty Russell wrote:
>> Not sure why vhost/net doesn't built a packet and feed it in
>> netif_rx_ni(). This is what tun seems to do, and with this code it
>> should be fairly optimal.
>
> Because we want to use NAPI.
Not quite what I was asking; it was more a question of why we're using a
raw socket, when we trivially have a complete skb already which we
should be able to feed to Linux like any network packet.
And that path is pretty well optimized...
Cheers,
Rusty.
^ permalink raw reply
* Re: [PATCH v2 net-next] net_sched: more precise pkt_len computation
From: David Miller @ 2013-01-10 22:58 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, shemminger, kaber, paolo.valente, jhs, herbert
In-Reply-To: <1357857402.27446.2734.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 10 Jan 2013 14:36:42 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> One long standing problem with TSO/GSO/GRO packets is that skb->len
> doesn't represent a precise amount of bytes on wire.
>
> Headers are only accounted for the first segment.
> For TCP, thats typically 66 bytes per 1448 bytes segment missing,
> an error of 4.5 % for normal MSS value.
>
> As consequences :
>
> 1) TBF/CBQ/HTB/NETEM/... can send more bytes than the assigned limits.
> 2) Device stats are slightly under estimated as well.
>
> Fix this by taking account of headers in qdisc_skb_cb(skb)->pkt_len
> computation.
>
> Packet schedulers should use qdisc pkt_len instead of skb->len for their
> bandwidth limitations, and TSO enabled devices drivers could use pkt_len
> if their statistics are not hardware assisted, and if they don't scratch
> skb->cb[] first word.
>
> Both egress and ingress paths work, thanks to commit fda55eca5a
> (net: introduce skb_transport_header_was_set()) : If GRO built
> a GSO packet, it also set the transport header for us.
>
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Looks good, applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] tcp: splice: fix an infinite loop in tcp_read_sock()
From: Willy Tarreau @ 2013-01-10 23:01 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1357837570.27446.2285.camel@edumazet-glaptop>
Hi Eric,
On Thu, Jan 10, 2013 at 09:06:10AM -0800, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> commit 02275a2ee7c0 (tcp: don't abort splice() after small transfers)
> added a regression.
>
>
> [ 83.843570] INFO: rcu_sched self-detected stall on CPU
> [ 83.844575] INFO: rcu_sched detected stalls on CPUs/tasks: { 6} (detected by 0, t=21002 jiffies, g=4457, c=4456, q=13132)
> [ 83.844582] Task dump for CPU 6:
> [ 83.844584] netperf R running task 0 8966 8952 0x0000000c
> [ 83.844587] 0000000000000000 0000000000000006 0000000000006c6c 0000000000000000
> [ 83.844589] 000000000000006c 0000000000000096 ffffffff819ce2bc ffffffffffffff10
> [ 83.844592] ffffffff81088679 0000000000000010 0000000000000246 ffff880c4b9ddcd8
> [ 83.844594] Call Trace:
> [ 83.844596] [<ffffffff81088679>] ? vprintk_emit+0x1c9/0x4c0
> [ 83.844601] [<ffffffff815ad449>] ? schedule+0x29/0x70
> [ 83.844606] [<ffffffff81537bd2>] ? tcp_splice_data_recv+0x42/0x50
> [ 83.844610] [<ffffffff8153beaa>] ? tcp_read_sock+0xda/0x260
> [ 83.844613] [<ffffffff81537b90>] ? tcp_prequeue_process+0xb0/0xb0
> [ 83.844615] [<ffffffff8153c0f0>] ? tcp_splice_read+0xc0/0x250
> [ 83.844618] [<ffffffff814dc0c2>] ? sock_splice_read+0x22/0x30
> [ 83.844622] [<ffffffff811b820b>] ? do_splice_to+0x7b/0xa0
> [ 83.844627] [<ffffffff811ba4bc>] ? sys_splice+0x59c/0x5d0
> [ 83.844630] [<ffffffff8119745b>] ? putname+0x2b/0x40
> [ 83.844633] [<ffffffff8118bcb4>] ? do_sys_open+0x174/0x1e0
> [ 83.844636] [<ffffffff815b6202>] ? system_call_fastpath+0x16/0x1b
>
>
> if recv_actor() returns 0, we should stop immediately,
> because looping wont give a chance to drain the pipe.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Willy Tarreau <w@1wt.eu>
> ---
> net/ipv4/tcp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> index 1ca2536..5f173dc 100644
> --- a/net/ipv4/tcp.c
> +++ b/net/ipv4/tcp.c
> @@ -1482,7 +1482,7 @@ int tcp_read_sock(struct sock *sk, read_descriptor_t *desc,
> break;
> }
> used = recv_actor(desc, skb, offset, len);
> - if (used < 0) {
> + if (used <= 0) {
> if (!copied)
> copied = used;
> break;
Thanks for catching this one. I'm amazed we didn't notice it earlier,
I've been running my stress-test kernels with this patch applied since
we did it.
Willy
^ permalink raw reply
* Re: [PATCH] tcp: splice: fix an infinite loop in tcp_read_sock()
From: Eric Dumazet @ 2013-01-10 23:05 UTC (permalink / raw)
To: Willy Tarreau; +Cc: David Miller, netdev
In-Reply-To: <20130110230145.GC17390@1wt.eu>
On Fri, 2013-01-11 at 00:01 +0100, Willy Tarreau wrote:
> Hi Eric,
> Thanks for catching this one. I'm amazed we didn't notice it earlier,
> I've been running my stress-test kernels with this patch applied since
> we did it.
>
Thats because you splice( very_large_amount_of_bytes), so you dont
hit this bug.
netperf does the splice ( exact_amount_of_bytes ) so hits this pretty
fast on loopback at least.
Thanks !
^ permalink raw reply
* Re: [PATCH] tcp: splice: fix an infinite loop in tcp_read_sock()
From: Willy Tarreau @ 2013-01-10 23:21 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1357859155.27446.2768.camel@edumazet-glaptop>
On Thu, Jan 10, 2013 at 03:05:55PM -0800, Eric Dumazet wrote:
> On Fri, 2013-01-11 at 00:01 +0100, Willy Tarreau wrote:
> > Hi Eric,
>
> > Thanks for catching this one. I'm amazed we didn't notice it earlier,
> > I've been running my stress-test kernels with this patch applied since
> > we did it.
> >
>
> Thats because you splice( very_large_amount_of_bytes), so you dont
> hit this bug.
Not always, I use many sizes (from 1k to very large).
> netperf does the splice ( exact_amount_of_bytes ) so hits this pretty
> fast on loopback at least.
OK I see, if we need an exact size to trigger it, that explains it !
Thanks for the explanation,
Willy
^ permalink raw reply
* Re: [PATCH] tcp: splice: fix an infinite loop in tcp_read_sock()
From: Rick Jones @ 2013-01-10 23:48 UTC (permalink / raw)
To: Willy Tarreau; +Cc: Eric Dumazet, David Miller, netdev
In-Reply-To: <20130110232153.GE17390@1wt.eu>
On 01/10/2013 03:21 PM, Willy Tarreau wrote:
> On Thu, Jan 10, 2013 at 03:05:55PM -0800, Eric Dumazet wrote:
>> Thats because you splice( very_large_amount_of_bytes), so you dont
>> hit this bug.
>
> Not always, I use many sizes (from 1k to very large).
>
>> netperf does the splice ( exact_amount_of_bytes ) so hits this pretty
>> fast on loopback at least.
>
> OK I see, if we need an exact size to trigger it, that explains it !
Netperf does not use a specific size all the time - the size it uses on
the receive will be the "receive_size" calculated the same way it has
been since the beginning - either a size specified by a test-specific -M
option, or based on the value of SO_RCVBUF at the time the socket was
created.
The kernel of the code making the splice calls - recv_data_no_copy() in
src/nettest_omni.c looks like:
recv_data_no_copy(SOCKET data_socket, struct ring_elt *recv_ring,
uint32_t bytes_to_recv, struct sockaddr *source, netperf_socklen_t
*sourcelen, uint32_t flags, uint32_t *num_receives) {
...
do {
bytes_recvd = splice(data_socket,
NULL,
pfd[1],
NULL,
bytes_left,
my_flags);
if (bytes_recvd > 0) {
/* per Eric Dumazet, we should just let this second splice call
move as many bytes as it can and not worry about how much.
this should make the call more robust when made on a system
under memory pressure */
splice(pfd[0], NULL, fdnull, NULL, 1 << 30, my_flags);
bytes_left -= bytes_recvd;
}
else {
break;
}
my_recvs++; /* should the pair of splices count as one? */
} while ((bytes_left > 0) && (flags & NETPERF_WAITALL));
where NETPERF_WAITALL is only set for an _RR test. Bytes_left is
initialized to bytes_to_recv which is the "receive_size." my_flags is
set to 0x03.
Now, if there are no test-specific -M option (or -s or -S depending on
the test) netperf will, from run to run use the same receive_size -
under Linux chances are quite good that will be 87380.
happy benchmarking,
rick jones
^ permalink raw reply
* RE: [PATCH 1/3] net: stmmac: add gmac autonet set for SGMII, TBI, and RTBI
From: Byungho An @ 2013-01-10 23:54 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: 'Giuseppe CAVALLARO', davem, jeffrey.t.kirsher, kgene.kim
This patch adds gmac autoneg set function for SGMII, TBI,
or RTBI interface. In case of PHY's autoneg is set, gmac's
autoneg enable bit should set. After checking phy's autoneg
if phydev's autoneg is '1' gmac's ANE bit set for those
interface.
Signed-off-by: Byungho An <bh74.an@samsung.com>
---
drivers/net/ethernet/stmicro/stmmac/common.h | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c | 11 +++++++++++
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 9 +++++++++
3 files changed, 21 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h
b/drivers/net/ethernet/stmicro/stmmac/common.h
index 186d148..72ba769 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -344,6 +344,7 @@ struct stmmac_ops {
void (*reset_eee_mode) (void __iomem *ioaddr);
void (*set_eee_timer) (void __iomem *ioaddr, int ls, int tw);
void (*set_eee_pls) (void __iomem *ioaddr, int link);
+ void (*set_autoneg) (void __iomem *ioaddr);
};
struct mac_link {
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index bfe0226..a0737b39 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -297,6 +297,16 @@ static void dwmac1000_set_eee_timer(void __iomem
*ioaddr, int ls, int tw)
writel(value, ioaddr + LPI_TIMER_CTRL);
}
+static void dwmac1000_set_autoneg(void __iomem *ioaddr)
+{
+ u32 value;
+
+ value = readl(ioaddr + GMAC_AN_CTRL);
+ value |= 0x1000;
+ writel(value, ioaddr + GMAC_AN_CTRL);
+}
+
+
static const struct stmmac_ops dwmac1000_ops = {
.core_init = dwmac1000_core_init,
.rx_ipc = dwmac1000_rx_ipc_enable,
@@ -311,6 +321,7 @@ static const struct stmmac_ops dwmac1000_ops = {
.reset_eee_mode = dwmac1000_reset_eee_mode,
.set_eee_timer = dwmac1000_set_eee_timer,
.set_eee_pls = dwmac1000_set_eee_pls,
+ .set_autoneg = dwmac1000_set_autoneg,
};
struct mac_device_info *dwmac1000_setup(void __iomem *ioaddr)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index f07c061..3e28934 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1007,6 +1007,7 @@ static int stmmac_open(struct net_device *dev)
{
struct stmmac_priv *priv = netdev_priv(dev);
int ret;
+ int interface = priv->plat->interface;
clk_prepare_enable(priv->stmmac_clk);
@@ -1041,6 +1042,14 @@ static int stmmac_open(struct net_device *dev)
/* Initialize the MAC Core */
priv->hw->mac->core_init(priv->ioaddr);
+ /* If phy autoneg is on, set gmac autoneg for SGMII, TBI and RTBI*/
+ if((interface == PHY_INTERFACE_MODE_SGMII) ||
+ (interface == PHY_INTERFACE_MODE_TBI) ||
+ (interface == PHY_INTERFACE_MODE_RTBI)) {
+ if (priv->phydev->autoneg)
+ priv->hw->mac->set_autoneg(priv->ioaddr);
+ }
+
/* Request the IRQ lines */
ret = request_irq(dev->irq, stmmac_interrupt,
IRQF_SHARED, dev->name, dev);
--
1.7.10.4
^ permalink raw reply related
* RE: [PATCH v2 3/3] net: stmmac: add gmac autonego set for ethtool support
From: Byungho An @ 2013-01-10 23:54 UTC (permalink / raw)
To: 'David Miller'
Cc: netdev, linux-kernel, peppe.cavallaro, jeffrey.t.kirsher,
kgene.kim
In-Reply-To: <20130110.000208.2040524620441942742.davem@davemloft.net>
This patch adds gmac auto-negotiation setting for ethtool.
If interface is SGMII, TBI or RTBI, gmac's auto-negotiation
enable bit is need to set.
Signed-off-by: Byungho An <bh74.an@samsung.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
index 1372ce2..457c1a4 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
@@ -335,6 +335,7 @@ stmmac_set_pauseparam(struct net_device *netdev,
struct phy_device *phy = priv->phydev;
int new_pause = FLOW_OFF;
int ret = 0;
+ int interface = priv->plat->interface;
spin_lock(&priv->lock);
@@ -348,6 +349,10 @@ stmmac_set_pauseparam(struct net_device *netdev,
if (phy->autoneg) {
if (netif_running(netdev))
+ if((interface == PHY_INTERFACE_MODE_SGMII) ||
+ (interface == PHY_INTERFACE_MODE_TBI) ||
+ (interface == PHY_INTERFACE_MODE_RTBI))
+ priv->hw->mac->set_autoneg(priv->ioaddr);
ret = phy_start_aneg(phy);
} else
priv->hw->mac->flow_ctrl(priv->ioaddr, phy->duplex,
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH v2 3/3] net: stmmac: add gmac autonego set for ethtool support
From: David Miller @ 2013-01-10 23:57 UTC (permalink / raw)
To: bh74.an; +Cc: netdev, linux-kernel, peppe.cavallaro, jeffrey.t.kirsher,
kgene.kim
In-Reply-To: <003d01cdef8d$d25b2bf0$771183d0$@samsung.com>
From: Byungho An <bh74.an@samsung.com>
Date: Thu, 10 Jan 2013 15:54:24 -0800
> @@ -348,6 +349,10 @@ stmmac_set_pauseparam(struct net_device *netdev,
>
> if (phy->autoneg) {
> if (netif_running(netdev))
> + if((interface == PHY_INTERFACE_MODE_SGMII) ||
> + (interface == PHY_INTERFACE_MODE_TBI) ||
> + (interface == PHY_INTERFACE_MODE_RTBI))
> + priv->hw->mac->set_autoneg(priv->ioaddr);
This is still not properly formatted.
You also didn't submit this properly. Never use email thread replies
to submit new versions of patches.
Always use fresh, new, mailing list postings to submit new versions
of patches.
Also, when one patch has to change in a series, you must reubmit
the entire set of patches even if some of them have no changes
at all. I do not see patch #2 here at all.
^ permalink raw reply
* Re: [PATCH V3] wanrouter: Remove it and the drivers that depend on it
From: Jan Engelhardt @ 2013-01-11 0:28 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: David Miller, joe, netdev
In-Reply-To: <20121114152339.GA22933@windriver.com>
On Wednesday 2012-11-14 16:23, Paul Gortmaker wrote:
>> >
>> > Please repost with the HTML stuff removed.
>>
>> Ah crap. I'd replied via gmail ; today and occasionally in the past as
>> a convenient short cut when not reading netdev with a "normal" MUA. And
>> this is not the 1st time gmail has randomly decided to be "helpful" by
>> mangling plain text like this. Well, I'll be having no more of that BS.
>
>I was curious to better figure out what triggered this, now that it
>isn't 1AM. It seems the original wasn't plain text, and that gmail
>didn't know what else to do with the content from your message when it
>arrived as base64 encoded.
>http://marc.info/?l=linux-netdev&m=135284894104364&w=2
I only wonder which component is at fault here, the producer side (it
gives the following headers),
Content-Type: Text/Plain; charset=iso-8859-7
Content-Transfer-Encoding: base64
(and the _absence_ of any MIME chunkwrapping)
or the receiver side. (Al)Pine and derivates displays the message
fine, marc.info does not, and gmail presents the body after literally
taking a stab at it.
^ permalink raw reply
* 3.8-rc2/rc3 write() blocked on CLOSE_WAIT TCP socket
From: Eric Wong @ 2013-01-11 0:49 UTC (permalink / raw)
To: netdev
Cc: Eric Dumazet, Mel Gorman, linux-mm, linux-kernel, Rik van Riel,
Minchan Kim, Andrew Morton, Linus Torvalds
The below Ruby script reproduces the issue for me with write()
getting stuck, usually with a few iterations (sometimes up to 100).
I've reproduced this with 3.8-rc2 and rc3, even with Mel's partial
revert patch in <20130110194212.GJ13304@suse.de> applied.
I can not reproduce this with 3.7.1+
stable-queue 2afd72f59c518da18853192ceeebead670ced5ea
So this seems to be a new bug from the 3.8 cycle...
Fortunately, this bug far easier for me to reproduce than the ppoll+send
(toosleepy) failures.
Both socat and ruby (Ruby 1.8, 1.9, 2.0 should all work), along with
common shell tools (dd, sh, cat) are required for testing this:
# 100 iterations, raise/lower the number if needed
ruby the_script_below.rb 100
lsof -p 15236 reveals this:
ruby 15236 ew 5u IPv4 23066 0t0 TCP localhost:33728->localhost:38658 (CLOSE_WAIT)
$ strace -f -p 15236
Process 15236 attached - interrupt to quit
write(5, "byebye!\n", 8
So write() to fd=5 is blocked, but the lsof shows the socket is already
in CLOSE_WAIT state. I expect write() to give me -EPIPE here since
the socat process on the reading end is long dead.
This could be an issue with sk_stream_wait_memory() that Eric Dumazet
alluded to with when I was chasing the toosleepy problem:
$ cat /proc/15236/stack
[<ffffffff8129fb19>] release_sock+0xe5/0x11b
[<ffffffff812a6328>] sk_stream_wait_memory+0x1f7/0x1fc
[<ffffffff81040d3a>] autoremove_wake_function+0x0/0x2a
[<ffffffff812d8ebf>] tcp_sendmsg+0x710/0x86d
[<ffffffff81000e34>] __switch_to+0x235/0x3c5
[<ffffffff81299c0d>] sock_aio_write+0x102/0x10d
[<ffffffff810d0b66>] do_sync_write+0x88/0xc1
[<ffffffff810d1476>] vfs_write+0xb3/0xda
[<ffffffff81036613>] ptrace_notify+0x5d/0x76
[<ffffffff810d158e>] sys_write+0x58/0x92
[<ffffffff81322669>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
I know many of you may not be familiar with Ruby, so I've tried to
comment the code as much as possible. Feel free to ask for
clarification.
-------------------------------- 8< -------------------------------
require 'socket'
require 'tempfile'
$stdout.sync = $stderr.sync = true # don't buffer any output
# Read the number of iterations (first command-line argument)
# (ARGV[0] in Ruby is argv[1] in C)
iterations = ARGV[0].to_i
iterations > 0 or abort "Usage: #$0 ITERATIONS (iterations should be > 0)"
# Capture a temporary file name for using in the shell script (below)
tmp = Tempfile.new('out')
out = tmp.path
# This is an array of FIFO path names, we create two of them:
fifos = []
%w(a b).each do |name|
fifotmp = Tempfile.new([name, '.fifo'])
# get the pathname from the Tempfile object
fifoname = fifotmp.path
fifos << fifoname
# This unlinks the temporary pathname so mkfifo can succeed
# (yes, there's a tiny race here but unlikely to ever happen).
fifotmp.close!
# create the FIFO
system("mkfifo", fifoname) or abort "mkfifo #{fifoname} failed: #$?"
end
# bind to a random TCP port over loopback
addr = "127.0.0.1"
srv = TCPServer.new(addr, 0)
port = srv.addr[1]
# Start the TCP server in a child process
pid = fork do
begin
response = "byebye!\n"
n = -1 # count the client number, first client is n==0
while client = srv.accept # this is an accept(2) wrapper
n += 1
warn "Accepted client=#{n}"
begin
# this is select(2)
warn "Waiting on client=#{n} to become readable"
IO.select([client], nil, nil, 5) or abort "BUG: #{client} not readable"
# read the request, it should be "hihi"
warn "Reading from client=#{n}"
req = client.gets
if req =~ /hihi/
warn "sending infinite response to client=#{n}"
client.sync = true # do not buffer output
# just write the response in an infinite loop on the socket
# The client will only read 4K (see dd below), disconnect,
# and trigger Errno::EPIPE.
# This just calls write(2) in a loop
loop { client.write(response) }
else
warn "Client sent bad request: #{req}"
end
rescue => e
warn "Got #{e.class} #{e.message} error for client=#{n}"
# this is expected, the client will only read 4K of our infinite
# response and drop the socket. We write to the fifo the
# client is running: "cat #{fifos[0]} &" on
fifo = fifos[0]
File.open(fifo, "w") do |fp|
warn "writing message to #{fifo} for client=#{n}"
fp.write("CLOSING #{n}")
warn "done writing message to #{fifo} for client=#{n}"
end
ensure
warn "Done dealing with client=#{n}"
client.close
end
end
ensure
warn "Server exiting"
end
end
# close the server port in the main process, server is running in child
srv.close
# ensure we shut the server down at exit
at_exit do
Process.kill(:TERM, pid)
fifos.each { |fifopath| File.unlink(fifopath) }
_, status = Process.waitpid2(pid)
puts "Server exited: #{status.inspect}"
end
# inline shell script here
x = <<SH
set -e
# wait for the server to write "CLOSING" above
# After enough iterations, this can get hung up on open():
cat #{fifos[0]} > #{out} &
(
# send a request to the server
echo hihi
# read 4K of the "byebye!" response
dd bs=4096 count=1 < #{fifos[1]} > /dev/null
# socat reads the stdout of the above ('hihi') and writes
# it to the TCP:#{addr}:#{port}, the server response goes to fifos[1],
# which the above dd(1) invocation reads the first 4K of.
# This socat is expected to error out with EPIPE here
) | socat - TCP:#{addr}:#{port} > #{fifos[1]} || :
echo "Waiting on #{fifos[0]} for client=$client"
wait # for the cat fifo[0] above
grep CLOSING #{out}
> #{out}
SH
# run the above shell script, assign the client= variable to the
# iteration number
iterations.times do |i|
system("client=#{i}\n#{x}") or abort "client #{i} failed: #$?"
end
puts "All done!"
--
Eric Wong
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: ppoll() stuck on POLLIN while TCP peer is sending
From: Eric Wong @ 2013-01-11 0:51 UTC (permalink / raw)
To: Mel Gorman
Cc: linux-mm, netdev, linux-kernel, Rik van Riel, Minchan Kim,
Eric Dumazet, Andrew Morton, Linus Torvalds
In-Reply-To: <20130110194212.GJ13304@suse.de>
Mel Gorman <mgorman@suse.de> wrote:
> mm: compaction: Partially revert capture of suitable high-order page
<snip>
> Reported-by: Eric Wong <normalperson@yhbt.net>
> Cc: stable@vger.kernel.org
> Signed-off-by: Mel Gorman <mgorman@suse.de>
Thanks, my original use case and test works great after several hours!
Tested-by: Eric Wong <normalperson@yhbt.net>
Unfortunately, I also hit a new bug in 3.8 (not in 3.7.x). based on Eric
Dumazet's observations, sk_stream_wait_memory may be to blame.
Fortunately this is easier to reproduce (I've cc-ed participants
on this thread already): <20130111004915.GA15415@dcvr.yhbt.net>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 01/19] netfilter: move nf_conntrack initialize out of pernet operations
From: Gao feng @ 2013-01-11 1:01 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: netfilter-devel, netdev, canqunzhang, kaber, ebiederm
In-Reply-To: <20130110164154.GA5457@1984>
On 2013/01/11 00:41, Pablo Neira Ayuso wrote:
> First off, thanks for looking into this.
>
> I want to get this fix into 3.8 and -stable but this patch includes a
> rework whose scope is net-next (upcoming 3.9).
>
> The attached patch aims to fix the issue according to your patch
> description. Once this is in, we can revisit your code refactoring
> proposal.
>
> Let me know.
>
Yes,I'm happy this bug being fixed in 3.8.
So what I should do is waiting for below patch being accepted and
then rebase my patchset? It's OK.
Thanks!
>
> 0001-netfilter-nf_conntrack-fix-BUG_ON-while-removing-nf_.patch
>
>
>>From a211bd666fbfe17ae7171a50ad92fedc7b9e19fa Mon Sep 17 00:00:00 2001
> From: Pablo Neira Ayuso <pablo@netfilter.org>
> Date: Thu, 10 Jan 2013 16:12:01 +0100
> Subject: [PATCH] netfilter: nf_conntrack: fix BUG_ON while removing
> nf_conntrack with netns
>
> canqun zhang reported that we're hitting BUG_ON in the
> nf_conntrack_destroy path when calling kfree_skb while
> rmmod'ing the nf_conntrack module.
>
> Currently, the nf_ct_destroy hook is being set to NULL in the
> destroy path of conntrack.init_net. However, this is a problem
> since init_net may be destroyed before any other existing netns
> (we cannot assume any specific ordering while releasing existing
> netns according to what I read in recent emails).
>
> Thanks to Gao feng for initial patch to address this issue.
>
> Reported-by: canqun zhang <canqunzhang@gmail.com>
> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
> ---
Acked-by: Gao feng <gaofeng@cn.fujitsu.com>
^ permalink raw reply
* Re: [PATCH net-next v5 01/14] vlan: wrap hw-acceleration calls in separate functions.
From: Vlad Yasevich @ 2013-01-11 1:08 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, davem, stephen, bridge, shmulik.ladkani, mst
In-Reply-To: <20130110140749.153023fa@nehalam.linuxnetplumber.net>
On 01/10/2013 05:07 PM, Stephen Hemminger wrote:
> On Thu, 10 Jan 2013 13:41:58 -0500
> Vlad Yasevich <vyasevic@redhat.com> wrote:
>
>> On 01/10/2013 01:25 PM, Stephen Hemminger wrote:
>>> On Wed, 9 Jan 2013 12:17:48 -0500
>>> Vlad Yasevich <vyasevic@redhat.com> wrote:
>>>
>>>>
>>>> /**
>>>> + * vlan_hw_buggy - Check to see if VLAN hw acceleration is supported.
>>>> + * @dev: netdevice of the lowerdev/hw nic
>>>> + *
>>>> + * Checks to see if HW and driver report VLAN acceleration correctly.
>>>> + */
>>>> +static inline bool vlan_hw_buggy(const struct net_device *dev)
>>>> +{
>>>> + const struct net_device_ops *ops = dev->netdev_ops;
>>>> +
>>>> + if ((dev->features & NETIF_F_HW_VLAN_FILTER) &&
>>>> + (!ops->ndo_vlan_rx_add_vid || !ops->ndo_vlan_rx_kill_vid))
>>>> + return true;
>>>> +
>>>> + return false;
>>>> +}
>>>> +
>>>> +/**
>>>> + * vlan_vid_add_hw - Add the VLAN vid to the HW filter
>>>> + * @dev: netdevice of the lowerdev/hw nic
>>>> + * @vid: vlan id.
>>>> + *
>>>> + * Inserts the vid into the HW vlan filter table if hw supports it.
>>>> + */
>>>> +static inline int vlan_vid_add_hw(struct net_device *dev,
>>>> + unsigned short vid)
>>>> +{
>>>> + const struct net_device_ops *ops = dev->netdev_ops;
>>>> + int err = 0;
>>>> +
>>>> + if ((dev->features & NETIF_F_HW_VLAN_FILTER) &&
>>>> + ops->ndo_vlan_rx_add_vid)
>>>> + err = ops->ndo_vlan_rx_add_vid(dev, vid);
>>>> +
>>>> + return err;
>>>> +}
>>>> +
>>>> +/**
>>>> + * vlan_vid_del_hw - Delete the VLAN vid from the HW filter
>>>> + * @dev: netdevice of the lowerdev/hw nic
>>>> + * @vid: vlan id.
>>>> + *
>>>> + * Delete the vid from the HW vlan filter table if hw supports it.
>>>> + */
>>>> +static inline int vlan_vid_del_hw(struct net_device *dev,
>>>> + unsigned short vid)
>>>> +{
>>>> + const struct net_device_ops *ops = dev->netdev_ops;
>>>> + int err = 0;
>>>> +
>>>> + if ((dev->features & NETIF_F_HW_VLAN_FILTER) &&
>>>> + ops->ndo_vlan_rx_kill_vid)
>>>> + err = ops->ndo_vlan_rx_add_vid(dev, vid);
>>>> +
>>>> + return err;
>>>> +}
>>>> +
>>>
>>> I would rather not have all these inline's. This isn't performance critical.
>>
>> I kind of need to keep them as inlines because of the VLAN support is
>> built. Right now, none of the VLAN files are build if VLAN support is
>> turned off. So all we get access to are inlines from if_vlan.h.
>>
>> I suppose I can change how VLANs get built, but not if that's the right
>> thing. It looks like it is set up the way it is on purpose.
>>
>>> Also, the check for buggy devices should be done inside the vlan code,
>>> not repeated in the functions using the add/remove API. When device is
>>> registered the flag and add/kill should be checked, and if the device driver
>>> is buggy it should fail the register_netdevice.
>>>
>>
>> Not sure what you mean here. I don't check if it's buggy again. I
>> check that the device supports filter and the pointer is set. I does
>> exactly what the code used to do. I suppose that the checks for valid
>> function pointers may be a little redundant since otherwise
>> vlan_hw_buggy() would have triggered, but it's safer to have them since
>> we can't guarantee that other users have checked for buggy implementations.
>>
>> -vlad
>
> The best way to handle this is to add stubs for the unconfigure case, and
> include real code if configured.
>
> I.e something like
>
> #if IS_ENABLED(CONFIG_VLAN_8012Q)
> extern int vlan_vid_add_hw(struct net_device *, unsigned short);
> extern int vlan_vid_del_hw(struct net_device *, unsigned short);
> #else
> #define vlan_vid_add_hw(dev,vid) (-ENOTSUPP)
> #define vlan_vid_del_hw(dev,vid) (-ENOTSUPP)
> #endif
>
>
But that wouldn't be right as this would prevent HW filtering from
working when VLAN support isn't built in which defeats the whole point
of extracting this code out it its own functions so it can be re-used.
Either we always build in some parts of VLAN support or we make keep
these inlines.
-vlad
>
^ permalink raw reply
* Re: [PATCH net-next v5 02/14] bridge: Add vlan filtering infrastructure
From: Vlad Yasevich @ 2013-01-11 1:14 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, davem, stephen, bridge, shmulik.ladkani, mst
In-Reply-To: <20130110141005.427ccaf9@nehalam.linuxnetplumber.net>
On 01/10/2013 05:10 PM, Stephen Hemminger wrote:
> The problem with your approach is that it
> adds a hash lookup in the packet process critical path.
>
Right now it is a list lookup and only happens if there is
VLAN filtering configured. Shmulik argued that hash lookup would
be faster, and that would be true for large number of vlans. List
works better for smaller number of vlans.
Something to keep in mind is that this only happens if a port has a
vlan configuration. Out of the box, the cost is that of a
if (list_empty())
statement.
> Also the concept of different filters for egress vs ingress is feature
> madness. It doesn't make sense to have half-duplex connectivity.
>
I am of the same opinion, but it actually simplified the code quite a
bit, but at the cost of additional memory footprint. If you find this
very objectionable, I can easily remove it.
Thanks
-vlad
^ permalink raw reply
* Re: [PATCH 3.8-rc] tuntap: refuse to re-attach to different tun_struct
From: Jason Wang @ 2013-01-11 1:29 UTC (permalink / raw)
To: David Miller; +Cc: stefanha, mst, netdev, linux-kernel
In-Reply-To: <20130110.143902.2166041015759450388.davem@davemloft.net>
On 01/11/2013 06:39 AM, David Miller wrote:
> From: Stefan Hajnoczi <stefanha@redhat.com>
> Date: Thu, 10 Jan 2013 08:59:48 +0100
>
>> Multiqueue tun devices support detaching a tun_file from its tun_struct
>> and re-attaching at a later point in time. This allows users to disable
>> a specific queue temporarily.
>>
>> ioctl(TUNSETIFF) allows the user to specify the network interface to
>> attach by name. This means the user can attempt to attach to interface
>> "B" after detaching from interface "A".
>>
>> The driver is not designed to support this so check we are re-attaching
>> to the right tun_struct. Failure to do so may lead to oops.
>>
>> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> Applied.
Hi David:
Any chance that I can have a respin on this patch, there's still a bug
after this patch. Or I just can send a patch on top?
Thanks
^ permalink raw reply
* LETTER FROM MR JEFF
From: jeff allen @ 2013-01-11 1:27 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 146 bytes --]
--
Hello, I'm contacting you on a business transaction that will be of great
benefit for we both kindly go through my attached file for info.
[-- Attachment #2: p.docx --]
[-- Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document, Size: 10454 bytes --]
^ permalink raw reply
* Re: [tcpdump-workers] [PATCH net 1/2] net: dev_queue_xmit_nit: fix skb->vlan_tci field value
From: Michael Richardson @ 2013-01-11 1:47 UTC (permalink / raw)
To: Eric Dumazet
Cc: Ani Sinha, Jiri Pirko, netdev, edumazet, tcpdump-workers,
dborkman
In-Reply-To: <1357761063.27446.60.camel@edumazet-glaptop>
[-- Attachment #1: Type: text/plain, Size: 1549 bytes --]
>>>>> "Eric" == Eric Dumazet <eric.dumazet@gmail.com> writes:
Eric> On Wed, 2013-01-09 at 11:27 -0800, Ani Sinha wrote:
>> This is wrong. Accelerated or not, the kernel code was organized to
>> have the tags in the packet aux data. So I think this is how user land
>> should be coded as well.
Eric> You have your opinion, thats good.
Eric> My opinion as a kernel developer is that the network tap is here to have
Eric> a copy of the exact frame given to the _device_.
Good: as someone who spends lots of time with tcpdump doing both network
and protocol diagnostics, it's really important to see exactly there.
If that means turning off some hardware offload in order to get the
intact 1p header, then that may be fine for many situations.
(At 10G, on a live router... well...)
The problem is that now we need to know, on a per device basis (based
upon the current configuration) if the VLAN tag was removed by the
hardware or not. It's not enough to try with vlan tag and not.
Eric> If you want other taps, and catch frames before/after various netfilter
Eric> hooks, segmentations, vlan accel, tunnels, or before GRO layer, thats a
Eric> totally different request.
Yes!!!! We need all of these tap points too...
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
[-- Attachment #2: Type: application/pgp-signature, Size: 307 bytes --]
^ permalink raw reply
* Re: 3.8-rc2/rc3 write() blocked on CLOSE_WAIT TCP socket
From: Eric Dumazet @ 2013-01-11 2:01 UTC (permalink / raw)
To: Eric Wong
Cc: netdev, Mel Gorman, linux-mm, linux-kernel, Rik van Riel,
Minchan Kim, Andrew Morton, Linus Torvalds
In-Reply-To: <20130111004915.GA15415@dcvr.yhbt.net>
On Fri, 2013-01-11 at 00:49 +0000, Eric Wong wrote:
> The below Ruby script reproduces the issue for me with write()
> getting stuck, usually with a few iterations (sometimes up to 100).
>
> I've reproduced this with 3.8-rc2 and rc3, even with Mel's partial
> revert patch in <20130110194212.GJ13304@suse.de> applied.
>
> I can not reproduce this with 3.7.1+
> stable-queue 2afd72f59c518da18853192ceeebead670ced5ea
> So this seems to be a new bug from the 3.8 cycle...
>
> Fortunately, this bug far easier for me to reproduce than the ppoll+send
> (toosleepy) failures.
>
> Both socat and ruby (Ruby 1.8, 1.9, 2.0 should all work), along with
> common shell tools (dd, sh, cat) are required for testing this:
>
> # 100 iterations, raise/lower the number if needed
> ruby the_script_below.rb 100
>
> lsof -p 15236 reveals this:
> ruby 15236 ew 5u IPv4 23066 0t0 TCP localhost:33728->localhost:38658 (CLOSE_WAIT)
Hmm, it might be commit c3ae62af8e755ea68380fb5ce682e60079a4c388
tcp: should drop incoming frames without ACK flag set
It seems RST should be allowed to not have ACK set.
I'll send a fix, thanks !
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH 0/3] ixgbe: request_firmware for configuration parameters
From: Shannon Nelson @ 2013-01-11 2:02 UTC (permalink / raw)
To: netdev; +Cc: davem, dwmw2, jeffrey.t.kirsher, linux-kernel
Most networking dials and knobs can be set using ethtool, ifconfig, ip link
commands, or sysfs entries, all of which can be driven by startup scripts
and other configuration tools. However, they all depend on having a netdev
already set up, and we have some low-level device functionality that needs
to be sorted out before we start setting up MSI-x and memory allocations.
In order to do early device configuration, most kernel drivers use module
parameters whose settings can be persisted in modprobe.d config files.
However, these can be clumsy to use and manage, difficult to specify port
specific values in a multiport device, and are actively discouraged in
some circles.
In this patchset, the driver uses the existing request_firmware() and
match_token() facilities to grab an ASCII config file from userspace to
find special startup-time configuration information that needs persistence
across reboots. The configuration strings are formed similar to the
mount options that get passed from /etc/fstab into filesystem modules.
We can assume that the driver and device will come up with sane defaults
that will make the part reasonably useful - we're not solving something
for basic usability. This capability is for folks that need special
configurations for their virtualization server or cloud configuration or
whatever network server where they've taken the time to tune things more
specifically to their application.
We are using existing facilities so that we don't have to build any
userland utilities, and a config file format that is both humanly and
potentially mechanically editable.
After doing some digging around, it seems that the combination of ASCII
config files stored where request_firmware() can find them, plus the
kind of option configurations used in fstab for mount commands can solve
the need. Using the lib/parser.c tools seems obvious - we don't want to
add any other parser code to the kernel, and heaven forbid someone tries to
extend any new parser into an XML solution. Using the request_firmware()
framework also allows the configuration file to get included when building
an initrd image.
In these RFC patches for ixgbe, the configuration data would be found in
the file /lib/firmware/ixgbe.conf, and might look something like this:
#
# example ixgbe driver configuration
#
# this is a generic setting for the driver
ixgbe allow_unsupported_sfp,debug=0xf,AtrSampleRate=0
# msix restricted on one port for testing purposes
00:1b:21:12:4e:60 nomsix
Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: David Woodhouse <dwmw2@infradead.org>
---
Shannon Nelson (3):
ixgbe: add interrupt control parameters
ixgbe: add additional parameter options
ixgbe: replace module options with configuration through request_firmware
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 4
drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c | 6
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 305 +++++++++++++++++++++++--
3 files changed, 289 insertions(+), 26 deletions(-)
--
======================================================================
Mr. Shannon Nelson LAN Access Division, Intel Corp.
shannon.nelson@intel.com I don't speak for Intel
(503) 712-7659 Parents can't afford to be squeamish
^ permalink raw reply
* [PATCH 1/3] ixgbe: replace module options with configuration through request_firmware
From: Shannon Nelson @ 2013-01-11 2:02 UTC (permalink / raw)
To: netdev; +Cc: davem, dwmw2, jeffrey.t.kirsher, linux-kernel
In-Reply-To: <20130111020046.15463.72333.stgit@starfish.jf.intel.com>
Replace the use of module parameters with data read from an ASCII parameter
file found through the request_firmware() framework.
The parameter file is an ASCII data file with lines in the form of
<label> <option>=<val>[,<option>=<val>...]
where the <label> specifies the driver name and/or a specific configuration
line to use and the following options define that configuration. Blank
lines are ignored, as are line comments that start with '#'.
The parameter file is tagged as MODULE_FIRMWARE to be sure it gets
included when pulling the driver into an initrd image. The possible
config options are tagged using MODULE_INFO to be sure there is still
some discoverability in configuration options.
Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: David Woodhouse <dwmw2@infradead.org>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 229 ++++++++++++++++++++++---
1 files changed, 203 insertions(+), 26 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 20d6764..1670fc7 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -47,13 +47,16 @@
#include <linux/if_bridge.h>
#include <linux/prefetch.h>
#include <scsi/fc/fc_fcoe.h>
+#include <linux/firmware.h>
+#include <linux/parser.h>
#include "ixgbe.h"
#include "ixgbe_common.h"
#include "ixgbe_dcb_82599.h"
#include "ixgbe_sriov.h"
-char ixgbe_driver_name[] = "ixgbe";
+#define IXGBE_DRIVER_NAME "ixgbe"
+char ixgbe_driver_name[] = IXGBE_DRIVER_NAME;
static const char ixgbe_driver_string[] =
"Intel(R) 10 Gigabit PCI Express Network Driver";
#ifdef IXGBE_FCOE
@@ -127,28 +130,202 @@ static struct notifier_block dca_notifier = {
};
#endif
-#ifdef CONFIG_PCI_IOV
-static unsigned int max_vfs;
-module_param(max_vfs, uint, 0);
-MODULE_PARM_DESC(max_vfs,
- "Maximum number of virtual functions to allocate per physical function - default is zero and maximum value is 63");
-#endif /* CONFIG_PCI_IOV */
-
-static unsigned int allow_unsupported_sfp;
-module_param(allow_unsupported_sfp, uint, 0);
-MODULE_PARM_DESC(allow_unsupported_sfp,
- "Allow unsupported and untested SFP+ modules on 82599-based adapters");
-
#define DEFAULT_MSG_ENABLE (NETIF_MSG_DRV|NETIF_MSG_PROBE|NETIF_MSG_LINK)
-static int debug = -1;
-module_param(debug, int, 0);
-MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
MODULE_AUTHOR("Intel Corporation, <linux.nics@intel.com>");
MODULE_DESCRIPTION("Intel(R) 10 Gigabit PCI Express Network Driver");
MODULE_LICENSE("GPL");
MODULE_VERSION(DRV_VERSION);
+/*
+ * Firmware parameter processing
+ *
+ * This requests a parameter configuration file through the kernel
+ * firmware management service. The parameter file is an ASCII data
+ * file with lines in the form of
+ * <label> <option>=<val>[,<option>=<val>...]
+ * where the <label> specifies a specific configuration to use
+ * and the following options define that configuration. Blank lines
+ * are ignored, as are line comments that start with '#'.
+ *
+ * For this driver, we use the driver name as the label for the basic
+ * configuration, then use the port MAC address for port specific
+ * override configuration.
+ */
+#define IXGBE_FIRMWARE_FILE IXGBE_DRIVER_NAME ".conf"
+MODULE_FIRMWARE(IXGBE_FIRMWARE_FILE);
+
+#define xstr(s) str(s)
+#define str(s) #s
+
+enum {
+ Opt_debug,
+ Opt_allow_unsupported_sfp,
+#ifdef CONFIG_PCI_IOV
+ Opt_max_vfs,
+#endif
+};
+
+static const match_table_t tokens = {
+ { Opt_debug, "debug=%u" },
+ { Opt_allow_unsupported_sfp, "allow_unsupported_sfp" },
+#ifdef CONFIG_PCI_IOV
+ { Opt_max_vfs, "max_vfs=%u" },
+#endif
+
+ /* terminator token */
+ { 0, NULL },
+};
+MODULE_INFO(fw_option, "debug=N : Debug level (0=none,...,16=all)");
+MODULE_INFO(fw_option, "allow_unsupported_sfp : Allow unsupported and untested SFP+ modules on 82599-based adapters");
+MODULE_INFO(fw_option,
+ "max_vfs=N : Maximum number of virtual functions per physical function (default=0) - 0 <= N < "
+ xstr(IXGBE_MAX_VF_FUNCTIONS));
+
+/**
+ * ixgbe_parse_option_line - find ixgbe options
+ * @adapter: pointer to ixgbe_adapter
+ * @config_line: line of option information
+ * @line_len: length of the config line
+ *
+ **/
+static void ixgbe_parse_option_line(struct ixgbe_adapter *adapter,
+ char *config_line, int line_len)
+{
+ char *p;
+ char *next_option = config_line;
+ substring_t args[MAX_OPT_ARGS];
+ int value;
+
+ if (!config_line)
+ return;
+
+ while ((p = strsep(&next_option, ", \t\n")) != NULL) {
+ int token;
+
+ if (((p - config_line) >= line_len) || *p == '\0' || *p == '#')
+ break;
+
+ /*
+ * Initialize args struct so we know whether arg was
+ * found; some options take optional arguments.
+ */
+ args[0].to = args[0].from = NULL;
+ token = match_token(p, tokens, args);
+ switch (token) {
+
+ case Opt_debug:
+ if (match_int(args, &value))
+ goto parse_error;
+ adapter->msg_enable = netif_msg_init(value,
+ DEFAULT_MSG_ENABLE);
+ break;
+
+ case Opt_allow_unsupported_sfp:
+ adapter->hw.allow_unsupported_sfp = true;
+ break;
+
+#ifdef CONFIG_PCI_IOV
+ case Opt_max_vfs:
+ if (match_int(args, &value))
+ goto parse_error;
+
+ if (adapter->hw.mac.type != ixgbe_mac_82598EB) {
+ if (value < IXGBE_MAX_VF_FUNCTIONS)
+ adapter->num_vfs = value;
+ else
+ goto parse_error;
+ }
+ break;
+
+#endif
+ default:
+ goto parse_error;
+ break;
+ }
+ }
+
+ return;
+
+parse_error:
+ e_dev_err("options error '%s'\n", p);
+ return;
+}
+
+/**
+ * ixgbe_find_config_line - scan config file for labeled option line
+ * @fw: pointer to firmware data
+ * @label: label to search for
+ *
+ * Returns pointer to the configuration options found, or NULL
+ **/
+static char *ixgbe_find_config_line(const struct firmware *fw,
+ const char *label)
+{
+ const char *p = fw->data;
+ const char *p_end = fw->data + fw->size;
+ int label_len = strlen(label);
+
+ while (p < p_end) {
+ /* ignore spaces and line comments */
+ p = skip_spaces(p);
+ if (p >= p_end)
+ break;
+ if (*p == '#')
+ goto scan_to_eol;
+
+ /* find tag match? */
+ if (!strncmp(p, label, min_t(int, label_len, (p_end - p)))) {
+
+ /* skip over the tag to find the options */
+ p += label_len;
+ p = skip_spaces(p);
+ if (p >= p_end)
+ break;
+ if (*p != '#')
+ return (char *)p;
+ }
+
+scan_to_eol:
+ while (p < p_end && *p != '\n')
+ p++;
+ if (p < p_end && *p == '\n')
+ p++;
+ }
+
+ return NULL;
+}
+
+/**
+ * ixgbe_check_options - find and check configuration parameters
+ * @adapter: pointer to ixgbe_adapter
+ * @label: the configuration tag to search for
+ **/
+void ixgbe_check_options(struct ixgbe_adapter *adapter, const char *label)
+{
+ char *config_line;
+ char *line_end;
+ int line_len, remaining;
+ int ret;
+ const struct firmware *fw;
+
+ ret = request_firmware(&fw, IXGBE_FIRMWARE_FILE, &adapter->pdev->dev);
+ if (ret)
+ return;
+
+ config_line = ixgbe_find_config_line(fw, label);
+ if (config_line) {
+ remaining = fw->size - (config_line - (char *)fw->data);
+ line_end = strnchr(config_line, remaining, '\n');
+ if (line_end)
+ line_len = line_end - config_line;
+ else
+ line_len = remaining;
+ ixgbe_parse_option_line(adapter, config_line, line_len);
+ }
+ release_firmware(fw);
+}
+
static void ixgbe_service_event_schedule(struct ixgbe_adapter *adapter)
{
if (!test_bit(__IXGBE_DOWN, &adapter->state) &&
@@ -4572,12 +4749,6 @@ static int ixgbe_sw_init(struct ixgbe_adapter *adapter)
hw->fc.disable_fc_autoneg =
(ixgbe_device_supports_autoneg_fc(hw) == 0) ? false : true;
-#ifdef CONFIG_PCI_IOV
- /* assign number of SR-IOV VFs */
- if (hw->mac.type != ixgbe_mac_82598EB)
- adapter->num_vfs = (max_vfs > 63) ? 0 : max_vfs;
-
-#endif
/* enable itr by default in dynamic mode */
adapter->rx_itr_setting = 1;
adapter->tx_itr_setting = 1;
@@ -7197,6 +7368,7 @@ static int ixgbe_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
u8 part_str[IXGBE_PBANUM_LENGTH];
unsigned int indices = num_possible_cpus();
unsigned int dcb_max = 0;
+ char mac_str[20];
#ifdef IXGBE_FCOE
u16 device_caps;
#endif
@@ -7279,7 +7451,7 @@ static int ixgbe_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
adapter->pdev = pdev;
hw = &adapter->hw;
hw->back = adapter;
- adapter->msg_enable = netif_msg_init(debug, DEFAULT_MSG_ENABLE);
+ adapter->msg_enable = netif_msg_init(-1, DEFAULT_MSG_ENABLE);
hw->hw_addr = ioremap(pci_resource_start(pdev, 0),
pci_resource_len(pdev, 0));
@@ -7324,6 +7496,9 @@ static int ixgbe_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
if (err)
goto err_sw_init;
+ /* look for generic options in userland config file */
+ ixgbe_check_options(adapter, ixgbe_driver_name);
+
/* Make it possible the adapter to be woken up via WOL */
switch (adapter->hw.mac.type) {
case ixgbe_mac_82599EB:
@@ -7344,12 +7519,14 @@ static int ixgbe_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
e_crit(probe, "Fan has stopped, replace the adapter\n");
}
- if (allow_unsupported_sfp)
- hw->allow_unsupported_sfp = allow_unsupported_sfp;
-
/* reset_hw fills in the perm_addr as well */
hw->phy.reset_if_overtemp = true;
err = hw->mac.ops.reset_hw(hw);
+
+ /* look for mac specific options in userland config file */
+ snprintf(mac_str, sizeof(mac_str)-1, "%pM", adapter->hw.mac.addr);
+ ixgbe_check_options(adapter, mac_str);
+
hw->phy.reset_if_overtemp = false;
if (err == IXGBE_ERR_SFP_NOT_PRESENT &&
hw->mac.type == ixgbe_mac_82598EB) {
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox