* Re: [PATCH net 0/2] bnx2x: bug fix patch series
From: David Miller @ 2013-01-10 22:38 UTC (permalink / raw)
To: yuvalmin; +Cc: netdev, eilong, ariele
In-Reply-To: <1357829620-17890-1-git-send-email-yuvalmin@broadcom.com>
From: "Yuval Mintz" <yuvalmin@broadcom.com>
Date: Thu, 10 Jan 2013 16:53:38 +0200
> Hi Dave,
>
> This patch series contains 2 bug fixes:
>
> 1. Failed memory allocation during Tx queue allocation can
> later cause the driver to dereference incorrect pointers,
> causing a panic.
>
> 2. During probe, management traffic is stopped and resumes
> only after some of its functions gets loaded.
>
> Please consider applying this patch-series to 'net'.
Applied.
^ permalink raw reply
* Re: [PATCH] tun: avoid owner checks on IFF_ATTACH_QUEUE
From: David Miller @ 2013-01-10 22:38 UTC (permalink / raw)
To: stefanha; +Cc: mst, jasowang, netdev, linux-kernel
In-Reply-To: <20130110115503.GD30885@stefanha-thinkpad.redhat.com>
From: Stefan Hajnoczi <stefanha@redhat.com>
Date: Thu, 10 Jan 2013 12:55:03 +0100
> On Thu, Jan 10, 2013 at 01:31:08PM +0200, Michael S. Tsirkin wrote:
>> At the moment, we check owner when we enable queue in tun.
>> This seems redundant and will break some valid uses
>> where fd is passed around: I think TUNSETOWNER is there
>> to prevent others from attaching to a persistent device not
>> owned by them. Here the fd is already attached,
>> enabling/disabling queue is more like read/write.
>>
>> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>>
>> ---
>>
>> Note: this is unrelated to Stefan's bugfix.
>
> This should go into 3.8-rc.
>
> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH 3.8-rc] tuntap: refuse to re-attach to different tun_struct
From: David Miller @ 2013-01-10 22:39 UTC (permalink / raw)
To: stefanha; +Cc: jasowang, mst, netdev, linux-kernel
In-Reply-To: <1357804788-19976-1-git-send-email-stefanha@redhat.com>
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.
^ permalink raw reply
* Re: [patch] bnx2x: move debugging code before the return
From: David Miller @ 2013-01-10 22:39 UTC (permalink / raw)
To: dan.carpenter; +Cc: eilong, netdev, kernel-janitors
In-Reply-To: <20130110085807.GB23063@elgon.mountain>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Thu, 10 Jan 2013 11:58:07 +0300
> I move the return down a line after the debugging printk.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/1] ipv6: use addrconf_get_prefix_route for prefix route lookup [v2]
From: David Miller @ 2013-01-10 22:39 UTC (permalink / raw)
To: yoshfuji; +Cc: r.kuntz, nicolas.dichtel, netdev, eric.dumazet
In-Reply-To: <50EE8D79.1080807@linux-ipv6.org>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Thu, 10 Jan 2013 18:44:25 +0900
> Romain KUNTZ wrote:
>
>> From 203474c87f45da40b5c9d9e629164561307b4199 Mon Sep 17 00:00:00 2001
>> From: Romain Kuntz <r.kuntz@ipflavors.com>
>> Date: Thu, 10 Jan 2013 07:41:36 +0100
>> Subject: [PATCH 1/1] ipv6: use addrconf_get_prefix_route for prefix route lookup [v2]
>>
>> Replace ip6_route_lookup() with addrconf_get_prefix_route() when
>> looking up for a prefix route. This ensures that the connected prefix
>> is looked up in the main table, and avoids the selection of other
>> matching routes located in different tables as well as blackhole
>> or prohibited entries.
>>
>> In addition, this fixes an Opps introduced by commit 64c6d08e (ipv6:
>> del unreachable route when an addr is deleted on lo), that would occur
>> when a blackhole or prohibited entry is selected by ip6_route_lookup().
>> Such entries have a NULL rt6i_table argument, which is accessed by
>> __ip6_del_rt() when trying to lock rt6i_table->tb6_lock.
>>
>> The function addrconf_is_prefix_route() is not used anymore and is
>> removed.
>>
>> [v2] Minor indentation cleanup and log updates.
>>
>> Signed-off-by: Romain Kuntz <r.kuntz@ipflavors.com>
>> Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
...
> Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
>
Applied.
^ permalink raw reply
* 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
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