* (unknown),
From: Zheng, C. @ 2014-02-20 19:19 UTC (permalink / raw)
Cc: inf@fi.fa
تهنئة الخاص بك البريد الإلكتروني قد فقط فاز لك مبلغ (1,000,000.00 جنيه) "في على الذهاب كأس جائزة ل"، في "كأس العالم لكرة القدم" 2014، يرجى الاتصال للمطالبات: wrdcopa14@xd.ae
^ permalink raw reply
* Re: [PATCH net-next 1/8] cxgb4: Add support to recognize 40G links
From: Casey Leedom @ 2014-02-20 19:16 UTC (permalink / raw)
To: Florian Fainelli
Cc: Steve Wise, Hariprasad Shenai, netdev, David Miller, dm,
nirranjan, kumaras, santosh
In-Reply-To: <CAGVrzcbb-7sQqHyf8SS8-mUyD+LM==Z6r3Zy1rFQ72WHFveMcQ@mail.gmail.com>
On 02/20/14 11:00, Florian Fainelli wrote:
> 2014-02-20 10:07 GMT-08:00 Casey Leedom <leedom@chelsio.com>:
>> On 02/19/14 13:12, Steve Wise wrote:
>>>
>>> You probably should add SPEED_40000 to include/uapi/linux/ethtool.h as
>>> part of this series.
>>
>> I'm ~pretty sure~ that the "word on the street" was that the community
>> wanted to get away from the SPEED_XXX symbols since they simply represented
>> the values XXX. Thus they didn't offer any real symbolic isolation from
>> weird constants, etc. I believe that the old SPEED_XXX values were left in
>> place in order to avoid making tons of changes everywhere ...
> Not quite sure where and when you heard that, it seems a little
> disturbing to add a comment in this patch saying "this I how I should
> fix things" and not do them, especially when this is a one-liner.
> Having a well defined constant is easier to grep than having the
> open-coded 40000 constant which will lead to false positives
> throughout the tree.
Like I said, it was a vague memory at best from over a year ago. I
seem to remember someone on our team trying to push SPEED_40000 into the
kernel and getting rebuffed. Perhaps I didn't have enough coffee that day.
In any case, I personally like the idea of SPEED_40000 for exactly
the reason you offer: I can search for it meaningfully. So If my vague
memory is wrong, yeay!
Casey
> --
> Florian
^ permalink raw reply
* Re: [PATCH net-next 1/8] cxgb4: Add support to recognize 40G links
From: Florian Fainelli @ 2014-02-20 19:00 UTC (permalink / raw)
To: Casey Leedom
Cc: Steve Wise, Hariprasad Shenai, netdev, David Miller, dm,
nirranjan, kumaras, santosh
In-Reply-To: <53064459.3030106@chelsio.com>
2014-02-20 10:07 GMT-08:00 Casey Leedom <leedom@chelsio.com>:
>
> On 02/19/14 13:12, Steve Wise wrote:
>>
>>
>> You probably should add SPEED_40000 to include/uapi/linux/ethtool.h as
>> part of this series.
>
>
> I'm ~pretty sure~ that the "word on the street" was that the community
> wanted to get away from the SPEED_XXX symbols since they simply represented
> the values XXX. Thus they didn't offer any real symbolic isolation from
> weird constants, etc. I believe that the old SPEED_XXX values were left in
> place in order to avoid making tons of changes everywhere ...
Not quite sure where and when you heard that, it seems a little
disturbing to add a comment in this patch saying "this I how I should
fix things" and not do them, especially when this is a one-liner.
Having a well defined constant is easier to grep than having the
open-coded 40000 constant which will lead to false positives
throughout the tree.
--
Florian
^ permalink raw reply
* Re: Getting a NIC's MTU size
From: David Miller @ 2014-02-20 18:45 UTC (permalink / raw)
To: dhowells; +Cc: hannes, netdev
In-Reply-To: <16869.1392917423@warthog.procyon.org.uk>
From: David Howells <dhowells@redhat.com>
Date: Thu, 20 Feb 2014 17:30:23 +0000
> David Miller <davem@davemloft.net> wrote:
>
>> > One further question: If I want to get the MTU size of the NIC through
>> > which packets will go to get to a particular peer, can I do:
>>
>> As has been suggested or at least hinted to by others, you have to use
>> the route dst's device pointer.
>
> So I gather. My query was intended to be about the safety of accessing the
> dst->dev pointer. Can I just dereference it? Or do I need to take a lock or
> use RCU?
If the dst is valid and you have a reference to it, dst->dev is good.
^ permalink raw reply
* Re: [PATCH net-next 1/8] cxgb4: Add support to recognize 40G links
From: Casey Leedom @ 2014-02-20 18:07 UTC (permalink / raw)
To: Steve Wise, Hariprasad Shenai
Cc: netdev, davem, dm, nirranjan, kumaras, santosh
In-Reply-To: <53051E48.9050901@opengridcomputing.com>
On 02/19/14 13:12, Steve Wise wrote:
>
> You probably should add SPEED_40000 to include/uapi/linux/ethtool.h as
> part of this series.
I'm ~pretty sure~ that the "word on the street" was that the
community wanted to get away from the SPEED_XXX symbols since they
simply represented the values XXX. Thus they didn't offer any real
symbolic isolation from weird constants, etc. I believe that the old
SPEED_XXX values were left in place in order to avoid making tons of
changes everywhere ...
Casey
^ permalink raw reply
* Re: linux-next: Tree for Feb 19 (netdev)
From: Randy Dunlap @ 2014-02-20 18:37 UTC (permalink / raw)
To: David Miller; +Cc: sfr, linux-next, linux-kernel, netdev
In-Reply-To: <20140220.021320.1623323851847472760.davem@davemloft.net>
On 02/19/14 23:13, David Miller wrote:
> From: Randy Dunlap <rdunlap@infradead.org>
> Date: Wed, 19 Feb 2014 07:08:09 -0800
>
>> on i386:
>>
>> net/built-in.o:(.rodata+0x1707c): undefined reference to `ip_tunnel_get_stats64'
>>
>> Full randconfig file is attached.
>
> Thanks for the report Randy, this should do it:
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.
> diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
> index 6d430ff..7b19528 100644
> --- a/net/ipv4/ip_tunnel.c
> +++ b/net/ipv4/ip_tunnel.c
> @@ -119,52 +119,6 @@ static struct rtable *tunnel_rtable_get(struct ip_tunnel *t, u32 cookie)
> return (struct rtable *)dst;
> }
>
> -/* Often modified stats are per cpu, other are shared (netdev->stats) */
> -struct rtnl_link_stats64 *ip_tunnel_get_stats64(struct net_device *dev,
> - struct rtnl_link_stats64 *tot)
> -{
> - int i;
> -
> - for_each_possible_cpu(i) {
> - const struct pcpu_sw_netstats *tstats =
> - per_cpu_ptr(dev->tstats, i);
> - u64 rx_packets, rx_bytes, tx_packets, tx_bytes;
> - unsigned int start;
> -
> - do {
> - start = u64_stats_fetch_begin_bh(&tstats->syncp);
> - rx_packets = tstats->rx_packets;
> - tx_packets = tstats->tx_packets;
> - rx_bytes = tstats->rx_bytes;
> - tx_bytes = tstats->tx_bytes;
> - } while (u64_stats_fetch_retry_bh(&tstats->syncp, start));
> -
> - tot->rx_packets += rx_packets;
> - tot->tx_packets += tx_packets;
> - tot->rx_bytes += rx_bytes;
> - tot->tx_bytes += tx_bytes;
> - }
> -
> - tot->multicast = dev->stats.multicast;
> -
> - tot->rx_crc_errors = dev->stats.rx_crc_errors;
> - tot->rx_fifo_errors = dev->stats.rx_fifo_errors;
> - tot->rx_length_errors = dev->stats.rx_length_errors;
> - tot->rx_frame_errors = dev->stats.rx_frame_errors;
> - tot->rx_errors = dev->stats.rx_errors;
> -
> - tot->tx_fifo_errors = dev->stats.tx_fifo_errors;
> - tot->tx_carrier_errors = dev->stats.tx_carrier_errors;
> - tot->tx_dropped = dev->stats.tx_dropped;
> - tot->tx_aborted_errors = dev->stats.tx_aborted_errors;
> - tot->tx_errors = dev->stats.tx_errors;
> -
> - tot->collisions = dev->stats.collisions;
> -
> - return tot;
> -}
> -EXPORT_SYMBOL_GPL(ip_tunnel_get_stats64);
> -
> static bool ip_tunnel_key_match(const struct ip_tunnel_parm *p,
> __be16 flags, __be32 key)
> {
> diff --git a/net/ipv4/ip_tunnel_core.c b/net/ipv4/ip_tunnel_core.c
> index 6156f4e..8d69626 100644
> --- a/net/ipv4/ip_tunnel_core.c
> +++ b/net/ipv4/ip_tunnel_core.c
> @@ -148,3 +148,49 @@ error:
> return ERR_PTR(err);
> }
> EXPORT_SYMBOL_GPL(iptunnel_handle_offloads);
> +
> +/* Often modified stats are per cpu, other are shared (netdev->stats) */
> +struct rtnl_link_stats64 *ip_tunnel_get_stats64(struct net_device *dev,
> + struct rtnl_link_stats64 *tot)
> +{
> + int i;
> +
> + for_each_possible_cpu(i) {
> + const struct pcpu_sw_netstats *tstats =
> + per_cpu_ptr(dev->tstats, i);
> + u64 rx_packets, rx_bytes, tx_packets, tx_bytes;
> + unsigned int start;
> +
> + do {
> + start = u64_stats_fetch_begin_bh(&tstats->syncp);
> + rx_packets = tstats->rx_packets;
> + tx_packets = tstats->tx_packets;
> + rx_bytes = tstats->rx_bytes;
> + tx_bytes = tstats->tx_bytes;
> + } while (u64_stats_fetch_retry_bh(&tstats->syncp, start));
> +
> + tot->rx_packets += rx_packets;
> + tot->tx_packets += tx_packets;
> + tot->rx_bytes += rx_bytes;
> + tot->tx_bytes += tx_bytes;
> + }
> +
> + tot->multicast = dev->stats.multicast;
> +
> + tot->rx_crc_errors = dev->stats.rx_crc_errors;
> + tot->rx_fifo_errors = dev->stats.rx_fifo_errors;
> + tot->rx_length_errors = dev->stats.rx_length_errors;
> + tot->rx_frame_errors = dev->stats.rx_frame_errors;
> + tot->rx_errors = dev->stats.rx_errors;
> +
> + tot->tx_fifo_errors = dev->stats.tx_fifo_errors;
> + tot->tx_carrier_errors = dev->stats.tx_carrier_errors;
> + tot->tx_dropped = dev->stats.tx_dropped;
> + tot->tx_aborted_errors = dev->stats.tx_aborted_errors;
> + tot->tx_errors = dev->stats.tx_errors;
> +
> + tot->collisions = dev->stats.collisions;
> +
> + return tot;
> +}
> +EXPORT_SYMBOL_GPL(ip_tunnel_get_stats64);
> --
--
~Randy
^ permalink raw reply
* Re: [net-next 3/3] ixgbe: Check config reads for removal
From: David Miller @ 2014-02-20 18:32 UTC (permalink / raw)
To: aaron.f.brown; +Cc: mark.d.rustad, netdev, gospo, sassmann
In-Reply-To: <1392871521-7731-4-git-send-email-aaron.f.brown@intel.com>
From: Aaron Brown <aaron.f.brown@intel.com>
Date: Wed, 19 Feb 2014 20:45:21 -0800
> - if (!(IXGBE_READ_REG(hw, IXGBE_STATUS) & IXGBE_STATUS_GIO))
> + if (!(IXGBE_READ_REG(hw, IXGBE_STATUS) & IXGBE_STATUS_GIO) ||
> + ixgbe_removed(hw->hw_addr))
> goto out;
This is not indented correctly, the second line of the if() statement
should start at the first column after the openning parenthesis of the
top-level if() statement.
> + if (*value == IXGBE_FAILED_READ_CFG_WORD &&
> + ixgbe_check_cfg_remove(&adapter->hw, parent_dev))
> + return -1;
Just as you correctly did here.
^ permalink raw reply
* Re: [PATCH] net: sctp: Potentially-Failed state should not be reached from unconfirmed state
From: David Miller @ 2014-02-20 18:25 UTC (permalink / raw)
To: matija.glavinic-pecotic.ext; +Cc: linux-sctp, netdev
In-Reply-To: <5305FF60.80404@nsn.com>
From: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@nsn.com>
Date: Thu, 20 Feb 2014 14:13:04 +0100
> In current implementation it is possible to reach PF state from unconfirmed.
> We can interpret sctp-failover-02 in a way that PF state is meant to be reached
> only from active state, in the end, this is when entering PF state makes sense.
> Here are few quotes from sctp-failover-02, but regardless of these, same
> understanding can be reached from whole section 5:
>
> Section 5.1, quickfailover guide:
> "The PF state is an intermediate state between Active and Failed states."
>
> "Each time the T3-rtx timer expires on an active or idle
> destination, the error counter of that destination address will
> be incremented. When the value in the error counter exceeds
> PFMR, the endpoint should mark the destination transport address as PF."
>
> There are several concrete reasons for such interpretation. For start, rfc4960
> does not take into concern quickfailover algorithm. Therefore, quickfailover
> must comply to 4960. Point where this compliance can be argued is following
> behavior:
> When PF is entered, association overall error counter is incremented for each
> missed HB. This is contradictory to rfc4960, as address, while in unconfirmed
> state, is subjected to probing, and while it is probed, it should not increment
> association overall error counter. This has as a consequence that we might end
> up in situation in which we drop association due path failure on unconfirmed
> address, in case we have wrong configuration in a way:
> Association.Max.Retrans == Path.Max.Retrans.
>
> Another reason is that entering PF from unconfirmed will cause a loss of address
> confirmed event when address is once (if) confirmed. This is fine from failover
> guide point of view, but it is not consistent with behavior preceding failover
> implementation and recommendation from 4960:
>
> 5.4. Path Verification
> Whenever a path is confirmed, an indication MAY be given to the upper
> layer.
>
> Signed-off-by: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@nsn.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net] bonding: fix bond_arp_rcv() race of curr_active_slave
From: David Miller @ 2014-02-20 18:21 UTC (permalink / raw)
To: vfalico; +Cc: netdev, dingtianhong, fubar, andy
In-Reply-To: <20140220111519.GD1181@redhat.com>
From: Veaceslav Falico <vfalico@redhat.com>
Date: Thu, 20 Feb 2014 12:15:19 +0100
> On Thu, Feb 20, 2014 at 12:07:57PM +0100, Veaceslav Falico wrote:
>>bond->curr_active_slave can be changed between its deferences, even to
>>NULL, and thus we might panic.
>>
>>We're always holding the rcu
>>(rx_handler->bond_handle_frame()->bond_arp_rcv())
>>so fix this by rcu_dereferencing() it and using the saved.
>>
>>Reported-by: Ding Tianhong <dingtianhong@huawei.com>
>>Fixes: aeea64a ("bonding: don't trust arp requests unless active slave
>>really works")
>>CC: Jay Vosburgh <fubar@us.ibm.com>
>>CC: Andy Gospodarek <andy@greyhouse.net>
>>Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
>
> Sorry David, it should have been net-next (I've based it on the
> net-next
> tree).
>
> Can you apply it to net-next or should I resend it?
>
> Sorry for the noise.
It's fine, applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] net: fec: fix potential issue to avoid fec interrupt lost and crc error
From: David Miller @ 2014-02-20 18:16 UTC (permalink / raw)
To: B38611; +Cc: b20596, netdev
In-Reply-To: <1392891279-11194-1-git-send-email-B38611@freescale.com>
From: Fugang Duan <B38611@freescale.com>
Date: Thu, 20 Feb 2014 18:14:39 +0800
> The current flow: Set TX BD ready, and then set "INT" and "PINS" bit to
> enable tx interrupt generation and crc checksum.
>
> There has potential issue like as:
> CPU fec uDMA
> Set tx ready bit
> uDMA start the BD transmission
> Set "INT" bit
> Set "PINS" bit
> ...
>
> Above situation cause fec tx interrupt lost and fec MAC don't do
> CRC checksum. The patch fix the potential issue.
>
> Signed-off-by: Fugang Duan <B38611@freescale.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net v2] sit: fix panic with route cache in ip tunnels
From: David Miller @ 2014-02-20 18:14 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev, eric.dumazet, therbert
In-Reply-To: <1392887971-10590-1-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Thu, 20 Feb 2014 10:19:31 +0100
> Bug introduced by commit 7d442fab0a67 ("ipv4: Cache dst in tunnels").
>
> Because sit code does not call ip_tunnel_init(), the dst_cache was not
> initialized.
>
> CC: Tom Herbert <therbert@google.com>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Applied, thanks Nicolas.
^ permalink raw reply
* BUG: ip6tables IPv6-REDIRECT over bridges
From: Artie Hamilton @ 2014-02-20 18:14 UTC (permalink / raw)
To: Pablo Neira Ayuso, Patrick McHardy, Jozsef Kadlecsik,
"David S. Miller", Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, netfilter-devel@vger.kernel.org,
netfilter@vger.kernel.org, coreteam@netfilter.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Hi,
I have currently following setup with three devices (actual 3 hardware boxes)
box1 box2 box3
client --> (eth0)[bridging device](eth1) --> service x
The bridging device checks the properties of "client" and maybe redirects
him to a server on the bridging device (just assume HTTP for now). The
user is then welcomed and some instructions are shown. Before anyone
asks: NO, this is not a security mechanism.
The bridging device is a linux device and currently works perfectly fine with
IPv4 redirections. It is done (heavily simplified version) by running.
$ brctl addbr br0
$ brctl addif br0 eth0
$ brctl addif br0 eth1
$ ip addr add 192.168.1.42/24 dev br0
$ sysctl -w net.bridge.bridge-nf-call-iptables=1
$ iptables -t nat -A PREROUTING -p tcp -m tcp --dport 8080 -j REDIRECT --to-ports 81
This works perfectly fine with IPv4 services. Everyone is happy about the
bridged setup and the extra functionality with special redirects for this IPv4
service.
Now the same thing should be done for IPv6. It should works quite similar
(I just assume the above mentioned steps are already done):
$ sysctl -w net.ipv6.conf.br0.accept_ra=2
$ sysctl -w net.bridge.bridge-nf-call-ip6tables=1
$ ip6tables -t nat -A PREROUTING -p tcp -m tcp --dport 8080 -j REDIRECT --to-ports 81
But here is the problem: Connections will not be started. I see for example
connections getting started to the service like this on the client:
$ curl -6 -D - 'http://\[2001:1234::1\]:8080/'
..... nothing .....
A dump shows as first packet at tcp SYN to the service 2001:1234::1 with port
8080. And sometimes I see following too:
* ICMPv6 redirect reply
* SYN+ACK from fde9:....:d320 (one of the addresses of br0 but not
from the actual range 2001:..../64) with port 81 !!!!!!!!!
* RST from client to fde9:....:d320 with port 81
This seems to be a bug in nat or conntrack, right?
The conntrack event output show this:
[NEW] tcp 6 120 SYN_SENT src=2001:...::3 sport=49495 dport=8080 [UNREPLIED] src=fde9:....:d320 sport=81 dport=49495
I've also tried following setups:
* bridge setup but DNAT to service y (some server next to service x)
$ ip6tables -t nat -A PREROUTING -p tcp -m tcp --dport 8080 -j DNAT --to-dest [2001:1234::2]:81
=> works
* routing setup (br0 only contains eth0 and eth1 is a separate device)
$ iptables -t nat -A PREROUTING -p tcp -m tcp --dport 8080 -j REDIRECT --to-ports 81
=> works
When I use curl on the IPv6 address of the bridge device (2001:1234::1337) then
it works on the actual server port 81 and the port which should get redirected
to 81 - port 8080:
$ curl -6 -D - 'http://\[2001:1234::1337)\]:81/'
HTTP/1.1 200 OK
....
$ curl -6 -D - 'http://\[2001:1234::1337)\]:8080/'
HTTP/1.1 200 OK
....
It really seems to be a bug when doing DNAT/REDIRECT with bridges and IPv6. And
it is not possible for me to change the previously mentioned setup to a routed
setup.
I've also read a little bit about TPROXY but found no good way to use it
together with this bridged setup without routing rules (but worked quite well in
routing).
^ permalink raw reply
* Re: Getting a NIC's MTU size
From: Hannes Frederic Sowa @ 2014-02-20 18:12 UTC (permalink / raw)
To: David Howells; +Cc: David Miller, netdev
In-Reply-To: <16869.1392917423@warthog.procyon.org.uk>
On Thu, Feb 20, 2014 at 05:30:23PM +0000, David Howells wrote:
> David Miller <davem@davemloft.net> wrote:
>
> > > One further question: If I want to get the MTU size of the NIC through
> > > which packets will go to get to a particular peer, can I do:
> >
> > As has been suggested or at least hinted to by others, you have to use
> > the route dst's device pointer.
>
> So I gather. My query was intended to be about the safety of accessing the
> dst->dev pointer. Can I just dereference it? Or do I need to take a lock or
> use RCU?
No, you can just dereference it. dst holds a reference on ->dev, so it
is safe without lock or rcu as long as dst is alive and referenced.
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH RFC net-next 0/6] 6lowpan: reimplementation of fragmentation handling
From: David Miller @ 2014-02-20 18:10 UTC (permalink / raw)
To: alex.aring
Cc: dbaryshkov, alex.bluesman.smirnov, linux-zigbee-devel, netdev,
martin.townsend
In-Reply-To: <20140220084642.GA29611@omega>
RFC means "request for comments", if you want me to apply it, resend
the series without the RFC tag in the subject line.
Also, target your patches at net-next.
Thanks.
^ permalink raw reply
* [PATCH] net-tcp: fastopen: fix high order allocations
From: Eric Dumazet @ 2014-02-20 18:09 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Yuchung Cheng
From: Eric Dumazet <edumazet@google.com>
This patch fixes two bugs in fastopen :
1) The tcp_sendmsg(..., @size) argument was ignored.
Code was relying on user not fooling the kernel with iovec mismatches
2) When MTU is about 64KB, tcp_send_syn_data() attempts order-5
allocations, which are likely to fail when memory gets fragmented.
Fixes: 783237e8daf13 ("net-tcp: Fast Open client - sending SYN-data")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
---
include/net/tcp.h | 3 ++-
net/ipv4/tcp.c | 8 +++++---
net/ipv4/tcp_output.c | 7 ++++++-
3 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 56fc366da6d5..8c4dd63134d4 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1303,7 +1303,8 @@ struct tcp_fastopen_request {
/* Fast Open cookie. Size 0 means a cookie request */
struct tcp_fastopen_cookie cookie;
struct msghdr *data; /* data in MSG_FASTOPEN */
- u16 copied; /* queued in tcp_connect() */
+ size_t size;
+ int copied; /* queued in tcp_connect() */
};
void tcp_free_fastopen_req(struct tcp_sock *tp);
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 9f3a2db9109e..97c8f5620c43 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1044,7 +1044,8 @@ void tcp_free_fastopen_req(struct tcp_sock *tp)
}
}
-static int tcp_sendmsg_fastopen(struct sock *sk, struct msghdr *msg, int *size)
+static int tcp_sendmsg_fastopen(struct sock *sk, struct msghdr *msg,
+ int *copied, size_t size)
{
struct tcp_sock *tp = tcp_sk(sk);
int err, flags;
@@ -1059,11 +1060,12 @@ static int tcp_sendmsg_fastopen(struct sock *sk, struct msghdr *msg, int *size)
if (unlikely(tp->fastopen_req == NULL))
return -ENOBUFS;
tp->fastopen_req->data = msg;
+ tp->fastopen_req->size = size;
flags = (msg->msg_flags & MSG_DONTWAIT) ? O_NONBLOCK : 0;
err = __inet_stream_connect(sk->sk_socket, msg->msg_name,
msg->msg_namelen, flags);
- *size = tp->fastopen_req->copied;
+ *copied = tp->fastopen_req->copied;
tcp_free_fastopen_req(tp);
return err;
}
@@ -1083,7 +1085,7 @@ int tcp_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
flags = msg->msg_flags;
if (flags & MSG_FASTOPEN) {
- err = tcp_sendmsg_fastopen(sk, msg, &copied_syn);
+ err = tcp_sendmsg_fastopen(sk, msg, &copied_syn, size);
if (err == -EINPROGRESS && copied_syn > 0)
goto out;
else if (err)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 3be16727f058..09805817627b 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2908,7 +2908,12 @@ static int tcp_send_syn_data(struct sock *sk, struct sk_buff *syn)
space = __tcp_mtu_to_mss(sk, inet_csk(sk)->icsk_pmtu_cookie) -
MAX_TCP_OPTION_SPACE;
- syn_data = skb_copy_expand(syn, skb_headroom(syn), space,
+ space = min_t(size_t, space, fo->size);
+
+ /* limit to order-0 allocations */
+ space = min_t(size_t, space, SKB_MAX_HEAD(MAX_TCP_HEADER));
+
+ syn_data = skb_copy_expand(syn, MAX_TCP_HEADER, space,
sk->sk_allocation);
if (syn_data == NULL)
goto fallback;
^ permalink raw reply related
* Re: Getting a NIC's MTU size
From: David Howells @ 2014-02-20 17:30 UTC (permalink / raw)
To: David Miller; +Cc: dhowells, hannes, netdev
In-Reply-To: <20140217.002153.1121569813590047048.davem@davemloft.net>
David Miller <davem@davemloft.net> wrote:
> > One further question: If I want to get the MTU size of the NIC through
> > which packets will go to get to a particular peer, can I do:
>
> As has been suggested or at least hinted to by others, you have to use
> the route dst's device pointer.
So I gather. My query was intended to be about the safety of accessing the
dst->dev pointer. Can I just dereference it? Or do I need to take a lock or
use RCU?
David
^ permalink raw reply
* Re: [PATCH] net: sctp: Potentially-Failed state should not be reached from unconfirmed state
From: Vlad Yasevich @ 2014-02-20 17:58 UTC (permalink / raw)
To: Matija Glavinic Pecotic, linux-sctp@vger.kernel.org
Cc: netdev@vger.kernel.org
In-Reply-To: <5305FF60.80404@nsn.com>
On 02/20/2014 08:13 AM, Matija Glavinic Pecotic wrote:
> In current implementation it is possible to reach PF state from unconfirmed.
> We can interpret sctp-failover-02 in a way that PF state is meant to be reached
> only from active state, in the end, this is when entering PF state makes sense.
> Here are few quotes from sctp-failover-02, but regardless of these, same
> understanding can be reached from whole section 5:
>
> Section 5.1, quickfailover guide:
> "The PF state is an intermediate state between Active and Failed states."
>
> "Each time the T3-rtx timer expires on an active or idle
> destination, the error counter of that destination address will
> be incremented. When the value in the error counter exceeds
> PFMR, the endpoint should mark the destination transport address as PF."
>
> There are several concrete reasons for such interpretation. For start, rfc4960
> does not take into concern quickfailover algorithm. Therefore, quickfailover
> must comply to 4960. Point where this compliance can be argued is following
> behavior:
> When PF is entered, association overall error counter is incremented for each
> missed HB. This is contradictory to rfc4960, as address, while in unconfirmed
> state, is subjected to probing, and while it is probed, it should not increment
> association overall error counter. This has as a consequence that we might end
> up in situation in which we drop association due path failure on unconfirmed
> address, in case we have wrong configuration in a way:
> Association.Max.Retrans == Path.Max.Retrans.
>
> Another reason is that entering PF from unconfirmed will cause a loss of address
> confirmed event when address is once (if) confirmed. This is fine from failover
> guide point of view, but it is not consistent with behavior preceding failover
> implementation and recommendation from 4960:
>
> 5.4. Path Verification
> Whenever a path is confirmed, an indication MAY be given to the upper
> layer.
>
> Signed-off-by: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@nsn.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Thanks
-vlad
>
> --- net-next.orig/net/sctp/sm_sideeffect.c
> +++ net-next/net/sctp/sm_sideeffect.c
> @@ -495,11 +495,12 @@ static void sctp_do_8_2_transport_strike
> }
>
> /* If the transport error count is greater than the pf_retrans
> - * threshold, and less than pathmaxrtx, then mark this transport
> - * as Partially Failed, ee SCTP Quick Failover Draft, secon 5.1,
> - * point 1
> + * threshold, and less than pathmaxrtx, and if the current state
> + * is not SCTP_UNCONFIRMED, then mark this transport as Partially
> + * Failed, see SCTP Quick Failover Draft, section 5.1
> */
> if ((transport->state != SCTP_PF) &&
> + (transport->state != SCTP_UNCONFIRMED) &&
> (asoc->pf_retrans < transport->pathmaxrxt) &&
> (transport->error_count > asoc->pf_retrans)) {
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH ethtool] ethtool: Report Backplane as supported port
From: Ivan Vecera @ 2014-02-20 17:48 UTC (permalink / raw)
To: netdev; +Cc: bhutchings, agospoda
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
ethtool.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/ethtool.c b/ethtool.c
index 315d00f..acb4397 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -496,6 +496,8 @@ static void dump_supported(struct ethtool_cmd *ep)
fprintf(stdout, "MII ");
if (mask & SUPPORTED_FIBRE)
fprintf(stdout, "FIBRE ");
+ if (mask & SUPPORTED_Backplane)
+ fprintf(stdout, "Backplane ");
fprintf(stdout, "]\n");
dump_link_caps("Supported", "Supports", mask, 0);
--
1.8.3.2
^ permalink raw reply related
* Re: RTL8153 fails to get link after applying c7de7dec2 to 3.8 kernel
From: Grant Grundler @ 2014-02-20 17:20 UTC (permalink / raw)
To: hayeswang; +Cc: Inki Yoo, netdev
In-Reply-To: <FB59F84B1E5E42AA98F0906286C444DF@realtek.com.tw>
On Wed, Feb 19, 2014 at 8:00 PM, hayeswang <hayeswang@realtek.com> wrote:
> Grant Grundler [mailto:grundler@google.com]
>> Sent: Thursday, February 20, 2014 8:08 AM
>> To: hayeswang
>> Cc: Inki Yoo; netdev
>> Subject: Re: RTL8153 fails to get link after applying
>> c7de7dec2 to 3.8 kernel
>>
>> On Fri, Feb 14, 2014 at 1:53 PM, Grant Grundler
>> <grundler@google.com> wrote:
> [...]
>> I will temporarily add the udev rule you previously
>> posted in order to automate testing this until I can get HW that comes
>> up in "vendor mode".
>
> Excuse me if I misunderstand your meaning. Our device has two
> configurations and I don't think you would get one with vendor
> mode only without ECM mode.
Hayes,
I expect the device to come up in a mode that "just works". I don't
have an expectation of which mode that should be. Perhaps there is
another bug that is causing the ECM mode (bConfigurationValue=2) to
not work?
> Besides, according to the information
> from one of the maintainers of the kernel, when a USB device with
> more than one configuration is plugged, the USB core would select
> the configuration which is not vendor mode first if it exists.
Ah ok. I didn't know that. that sounds reasonable....but it should work.
The drivers clearly don't work with c7de7dec2 patch applied (and
default device settings).
> Therefore, it is reasonably considered that the configuration 2
> would be set by default for our device if you do nothing.
Ok.
I can't apply c7de7dec2 as-is to ChromeOS with the current behaviors.
How would you like to see this fixed?
Have the r815x driver flip the device to "Vendor Mode" and not claim
it so r8152 driver can?
Or you have any idea why ECM mode doesn't work with c7de7dec2 patch?
cheers.
grant
^ permalink raw reply
* Re: [Xen-devel] [RFC v2 1/4] bridge: enable interfaces to opt out from becoming the root bridge
From: Stephen Hemminger @ 2014-02-20 17:19 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Ian Campbell, kvm, netdev@vger.kernel.org, bridge,
linux-kernel@vger.kernel.org, Zoltan Kiss, xen-devel
In-Reply-To: <CAB=NE6UAqoiFAJdckE1d7cgMZnU6_=8X+N=tSc6qH2bgH08M7Q@mail.gmail.com>
On Wed, 19 Feb 2014 09:59:33 -0800
"Luis R. Rodriguez" <mcgrof@do-not-panic.com> wrote:
> On Wed, Feb 19, 2014 at 9:08 AM, Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> > On Wed, 19 Feb 2014 09:02:06 -0800
> > "Luis R. Rodriguez" <mcgrof@do-not-panic.com> wrote:
> >
> >> Folks, what if I repurpose my patch to use the IFF_BRIDGE_NON_ROOT (or
> >> relabel to IFF_ROOT_BLOCK_DEF) flag for a default driver preference
> >> upon initialization so that root block will be used once the device
> >> gets added to a bridge. The purpose would be to avoid drivers from
> >> using the high MAC address hack, streamline to use a random MAC
> >> address thereby avoiding the possible duplicate address situation for
> >> IPv6. In the STP use case for these interfaces we'd just require
> >> userspace to unset the root block. I'd consider the STP use case the
> >> most odd of all. The caveat to this approach is 3.8 would be needed
> >> (or its the root block patches cherry picked) for base kernels older
> >> than 3.8.
> >>
> >> Stephen?
> >>
> >> Luis
> >
> > Don't add IFF_ flags that adds yet another API hook into bridge.
>
> The goal was not to add a userspace API, but rather consider a driver
> initialization preference.
>
> > Please only use the netlink/sysfs flags fields that already exist
> > for new features.
>
> Sure, but what if we know a driver in most cases wants the root block
> and we'd want to make it the default, thereby only requiring userspace
> for toggling it off.
>
> Luis
Something in userspace has to put the device into the bridge.
Fix the port setup in that tool via the netlink or sysfs flags in
the bridge. It should not have to be handled in the bridge looking
at magic flags in the device.
^ permalink raw reply
* Re: [PATCH 2/4] net: rfkill: gpio: remove gpio names
From: Stephen Warren @ 2014-02-20 16:38 UTC (permalink / raw)
To: Heikki Krogerus, Johannes Berg, David S. Miller
Cc: Chen-Yu Tsai, Rhyland Klein, linux-wireless, netdev, linux-kernel,
Arnd Bergmann, Linus Walleij, Alexandre Courbot
In-Reply-To: <1392900697-27577-3-git-send-email-heikki.krogerus@linux.intel.com>
On 02/20/2014 05:51 AM, Heikki Krogerus wrote:
> There is no use for them in this driver. This will fix a
> static checker warning..
Didn't you remove the use:
- gpio = devm_gpiod_get_index(&pdev->dev, rfkill->reset_name, 0);
+ gpio = devm_gpiod_get_index(&pdev->dev, NULL, 0);
doesn't that parameter get put into the sysfs GPIO debug file, so people
can see which GPIOs are used for what?
^ permalink raw reply
* RE: [net-next 05/14 v2] i40evf: fix up strings in init task
From: Williams, Mitch A @ 2014-02-20 16:20 UTC (permalink / raw)
To: Brown, Aaron F, Joe Perches
Cc: davem@davemloft.net, netdev@vger.kernel.org, gospo@redhat.com,
sassmann@redhat.com, Brandeburg, Jesse
In-Reply-To: <1392873372.2629.13.camel@localhost>
> -----Original Message-----
> From: Brown, Aaron F
> Sent: Wednesday, February 19, 2014 9:16 PM
> To: Joe Perches
> Cc: davem@davemloft.net; Williams, Mitch A; netdev@vger.kernel.org;
> gospo@redhat.com; sassmann@redhat.com; Brandeburg, Jesse
> Subject: Re: [net-next 05/14 v2] i40evf: fix up strings in init task
>
> On Wed, 2014-02-19 at 20:58 -0800, Joe Perches wrote:
> > On Wed, 2014-02-19 at 20:51 -0800, Aaron Brown wrote:
> > > On Wed, 2014-02-19 at 20:09 -0800, Joe Perches wrote:
> > > > On Wed, 2014-02-19 at 19:49 -0800, Aaron Brown wrote:
> > > > > Make sure errors are reported at the correct log level, quit
> printing
> > > > > the function name every time, and make the messages more consistent
> in
> > > > > format.
> > > > []
> > > > > diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_main.c
> b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
> > []
> > > > + dev_info(&pdev->dev, "Invalid MAC address %pMAC, using
> random\n",
> > > > > + adapter->hw.mac.addr);
> > > > The "AC" after %pM is superfluous.
> > > Thanks Joe, guess I'll be making another spin...
> >
> > Or send another patch after this one because there
> > are 2 %pMAC uses in i40evf_main.c
>
> That works. I'll bug Mitch to look for them when he does a hunt for other
> OOM messages that he said he'd do and send them up later. So I guess this
> patch can stand for now.
>
Added it to my to-do list. Thanks again, Joe.
-Mitch
^ permalink raw reply
* Re: [Xen-devel] [RFC v2 1/4] bridge: enable interfaces to opt out from becoming the root bridge
From: Zoltan Kiss @ 2014-02-20 14:47 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: netdev@vger.kernel.org, kvm, bridge, linux-kernel@vger.kernel.org,
Stephen Hemminger, xen-devel
In-Reply-To: <CAB=NE6XYjOd2vRpQCZOG-S5ZW4xjam+FOPAYzribNQpb50Q5pg@mail.gmail.com>
On 19/02/14 16:45, Luis R. Rodriguez wrote:
> On Mon, Feb 17, 2014 at 9:52 AM, Zoltan Kiss <zoltan.kiss@citrix.com> wrote:
>> On 15/02/14 02:59, Luis R. Rodriguez wrote:
>>>
>>> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>>>
>>> It doesn't make sense for some interfaces to become a root bridge
>>> at any point in time. One example is virtual backend interfaces
>>> which rely on other entities on the bridge for actual physical
>>> connectivity. They only provide virtual access.
>>
>> It is possible that a guest bridge together to VIF, either from the same
>> Dom0 bridge or from different ones. In that case using STP on VIFs sound
>> sensible to me.
>
> You seem to describe a case whereby it can make sense for xen-netback
> interfaces to end up becoming the root port of a bridge. Can you
> elaborate a little more on that as it was unclear the use case.
Well, I might be wrong on that, but the scenario I was thinking: a guest
(let's say domain 1) can have multiple interfaces on different Dom0 (or
driver domain) bridges, let's say vif1.0 is plugged into xenbr0 and
vif1.1 is in xenbr1. If the guest wants to make a bridge of this two,
then using STP makes sense. I wanted to bring up CloudStack's virtual
router as an example, but then I realized it's probably doesn't do such
thing. However I don't think we should hardcode that a netback interface
can't be RP ever.
>
> Additionally if such cases exist then under the current upstream
> implementation one would simply need to change the MAC address in
> order to enable a vif to become the root port. Stephen noted there is
> a way to avoid nominating an interface for a root port through the
> root block flag. We should use that instead of the MAC address hacks.
> Let's keep in mind that part of the motivation for this series is to
> avoid a duplicate IPv6 address left in place by use cases whereby the
> MAC address of the backend vif was left static. The use case your are
> explaining likely describes the more prevalent use case where address
> conflicts can occur, perhaps when administrators for got to change the
> backend MAC address. If we embrace a random MAC address we'd avoid
> that issue, and but we'd need to update userspace to use the root
> block on topologies where desired.
If I understand you correctly, this is the same I suggested in my
another email sent 1.5 hour ago.
Zoli
^ permalink raw reply
* RE: [PATCH] net: fec: fix potential issue to avoid fec interrupt lost and crc error
From: Frank.Li @ 2014-02-20 14:12 UTC (permalink / raw)
To: fugang.duan@freescale.com, davem@davemloft.net; +Cc: netdev@vger.kernel.org
In-Reply-To: <1392891279-11194-1-git-send-email-B38611@freescale.com>
> -----Original Message-----
> From: Fugang Duan [mailto:B38611@freescale.com]
> Sent: Thursday, February 20, 2014 4:15 AM
> To: Li Frank-B20596; davem@davemloft.net
> Cc: netdev@vger.kernel.org
> Subject: [PATCH] net: fec: fix potential issue to avoid fec interrupt lost
> and crc error
>
> The current flow: Set TX BD ready, and then set "INT" and "PINS" bit to
> enable tx interrupt generation and crc checksum.
>
> There has potential issue like as:
> CPU fec uDMA
> Set tx ready bit
> uDMA start the BD transmission
> Set "INT" bit
> Set "PINS" bit
> ...
>
> Above situation cause fec tx interrupt lost and fec MAC don't do CRC checksum.
> The patch fix the potential issue.
>
> Signed-off-by: Fugang Duan <B38611@freescale.com>
Acked-by: Frank Li <Frank.li@freescale.com>
> ---
> drivers/net/ethernet/freescale/fec_main.c | 13 +++++++------
> 1 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/fec_main.c
> b/drivers/net/ethernet/freescale/fec_main.c
> index 45b8b22..739608b 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -390,12 +390,6 @@ fec_enet_start_xmit(struct sk_buff *skb, struct
> net_device *ndev)
> netdev_err(ndev, "Tx DMA memory map failed\n");
> return NETDEV_TX_OK;
> }
> - /* Send it on its way. Tell FEC it's ready, interrupt when done,
> - * it's the last BD of the frame, and to put the CRC on the end.
> - */
> - status |= (BD_ENET_TX_READY | BD_ENET_TX_INTR
> - | BD_ENET_TX_LAST | BD_ENET_TX_TC);
> - bdp->cbd_sc = status;
>
> if (fep->bufdesc_ex) {
>
> @@ -417,6 +411,13 @@ fec_enet_start_xmit(struct sk_buff *skb, struct
> net_device *ndev)
> }
> }
>
> + /* Send it on its way. Tell FEC it's ready, interrupt when done,
> + * it's the last BD of the frame, and to put the CRC on the end.
> + */
> + status |= (BD_ENET_TX_READY | BD_ENET_TX_INTR
> + | BD_ENET_TX_LAST | BD_ENET_TX_TC);
> + bdp->cbd_sc = status;
> +
> bdp_pre = fec_enet_get_prevdesc(bdp, fep);
> if ((id_entry->driver_data & FEC_QUIRK_ERR006358) &&
> !(bdp_pre->cbd_sc & BD_ENET_TX_READY)) {
> --
> 1.7.2.rc3
>
^ permalink raw reply
* [PATCH ipsec-next] pfkey: fix SADB_X_EXT_FILTER length check
From: Nicolas Dichtel @ 2014-02-20 13:52 UTC (permalink / raw)
To: steffen.klassert, herbert, davem
Cc: netdev, dan.carpenter, kbuild-all, Nicolas Dichtel
In-Reply-To: <20140220100735.GA25752@elgon.mountain>
This patch fixes commit d3623099d350 ("ipsec: add support of limited SA dump").
sadb_ext_min_len array should be updated with the new type (SADB_X_EXT_FILTER).
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
net/key/af_key.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/key/af_key.c b/net/key/af_key.c
index f0879c19f452..a50d979b5926 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -365,6 +365,7 @@ static const u8 sadb_ext_min_len[] = {
[SADB_X_EXT_NAT_T_OA] = (u8) sizeof(struct sadb_address),
[SADB_X_EXT_SEC_CTX] = (u8) sizeof(struct sadb_x_sec_ctx),
[SADB_X_EXT_KMADDRESS] = (u8) sizeof(struct sadb_x_kmaddress),
+ [SADB_X_EXT_FILTER] = (u8) sizeof(struct sadb_x_filter),
};
/* Verify sadb_address_{len,prefixlen} against sa_family. */
--
1.8.5.4
^ 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