* Re: [PATCH] driver:net:stmmac: Disable DMA store and forward mode if platform data force_sf_dma_mode is negative.
From: Giuseppe CAVALLARO @ 2013-08-19 14:29 UTC (permalink / raw)
To: Sonic Zhang; +Cc: netdev, adi-buildroot-devel, Sonic Zhang
In-Reply-To: <CAJxxZ0NFhMMKp2eB+b168=c6+JsmJE6-yva7ZOGKciK3e4b8Yg@mail.gmail.com>
On 8/19/2013 12:51 PM, Sonic Zhang wrote:
> Hi Giuseppe,
>
> On Mon, Aug 19, 2013 at 3:45 PM, Giuseppe CAVALLARO
> <peppe.cavallaro@st.com> wrote:
>> On 8/19/2013 9:31 AM, Sonic Zhang wrote:
>>>
>>> Hi Giuseppe,
>>>
>>> On Mon, Aug 19, 2013 at 2:03 PM, Giuseppe CAVALLARO
>>> <peppe.cavallaro@st.com> wrote:
>>>>
>>>> Hello Sonic
>>>>
>>>>
>>>> On 8/15/2013 9:37 AM, Sonic Zhang wrote:
>>>>>
>>>>>
>>>>> From: Sonic Zhang <sonic.zhang@analog.com>
>>>>>
>>>>> Some synopsys ip implementation doesn't support DMA store and forward
>>>>> mode,
>>>>> such as BF60x. So, define force_sf_dma_mode negative to use DMA
>>>>> thresholds
>>>>> only.
>>>>
>>>>
>>>>
>>>> I think that you should not pass the force_sf_dma_mode platform field
>>>> at all (and it doesn't make sense to force it as negative).
>>>> To use the threshold you should reset tx_coe. In fact, your HW cannot
>>>> perform the Hw csum if SF is not available.
>>>> Note that, the HW cap register (if available) can override (set/reset)
>>>> tx_coe.
>>>
>>>
>>> Even if I reset tx_coe, the SF mode is still set to RX DMA in current
>>> stmmac_dma_operation_mode(). SF mode is not supported in both RX DMA
>>> and TX DMA in Blackfin MAC.
>>
>>
>> yes this is true. the SF is always set for the RX path because I have
>> never had and known HW w/o RX csum (since the 209).
>>
>> So I think the code could be improved to disable/enable the SF also for
>> the RX path.
>>
>>
>>>>
>>>> I tested, long time ago, this scenario on old mac w/o HW cap register
>>>> and w/o SF.
>>>
>>>
>>> Blackfin synopsys MAC IP has the HW cap register with tx_coe set to 1,
>>> but the HW tx_coe doesn't really work. I have the other patch to
>>> disable HW tx_coe in board file and override the HW cap register.
>>
>>
>> AFAIK the HW shouldn't be able to perform the csum in HW w/o SF.
>>
>> Maybe, an easy way could be to use a new field to force the threshold
>> mode. This should also remove the csum in HW (IMO) and program the
>> DMA operation register.
>>
>
> The problem is that HW RX csum works perfectly on Blackfin MAC
> although the SF mode is not supported in RX DMA.
hmm maybe we should ask SYNP. I'll try.
> I may need 2 platform
> fields to force RX DMA threshold and disable HW tx_coe. One field
> doesn't cover both cases well.
concerning tx_coe, I had added it to inform the stmmac that the HW
was (or not) able to do the csum in hw. This was true on chip w/o
the HW cap register. If you have the HW cap reg so let me assume
there is another problem. For example, I worked (time ago) on an HW
where the cap reg declared that the mac was able to perform the csum
in hw but, after debugging it, I discovered that the problem was on
SG. I mean, the HW was able to do the csum in HW but had problems on
fragmented frame (I mean, frames that were split in one more
descriptor).
I will send you the patch I used to fix that... maybe you are in the
same scenario.
Concerning the threshold, just to avoid to complicate the code, we could
keep force_sf_dma_mode and add force_thresh_dma_mode that force both
rx and tx. I do not want to remove the force_sf_dma_mode that is also
used on some platforms (AFAIK).
Do not forget to update the stmmac.txt and devicetree support
What do you think?
I also think that the patch should be prepared on top of net-next.
Peppe
>
> Which 2 fields do you prefer?
>
> Thanks
>
> Sonic
>
>
^ permalink raw reply
* Re: NAT stops forwarding ACKs after PMTU discovery
From: Phil Oester @ 2013-08-19 14:35 UTC (permalink / raw)
To: Eric Dumazet
Cc: Christoph Paasch, Corey Hickey, Jozsef Kadlecsik,
Linux Netdev List, netfilter-devel
In-Reply-To: <1376920685.4226.61.camel@edumazet-glaptop>
On Mon, Aug 19, 2013 at 06:58:05AM -0700, Eric Dumazet wrote:
> Yeah, but here, this is conntrack who is blocking the thing.
>
> TCP receiver has no chance to 'fix' it.
>
> See conntrack is one of those buggy middle box as well.
>
> So if you want to properly handle this mess, you'll also have to fix
> conntrack.
Better to fix the box which is randomizing the acks and ignoring
the SACKs. Usually these are older Cisco PIX/ASA devices which just
need a code upgrade.
Phil
^ permalink raw reply
* IFB network driver problems and questions
From: Brad Johnson @ 2013-08-19 14:35 UTC (permalink / raw)
To: netdev
We are trying to use the IFB driver for ingress QoS and are having some
problems getting it to work for us. Even though I have seen it described
as a replacement for IMQ, it appears that it hooks the packets before
netfilter and so marks set with iptables are not seen by tc filters on
the ifb device. This makes it difficult, and in some cases impossible,
to do any kind of complex filtering, such as port ranges and many other
matches that are easy to do with iptables. So my questions are:
1. Is there any way to set marks with iptables and have them seen in the
IFB device?
2. Is there any way to use IFB as an iptables target the same way you
can do a "-j IMQ" target?
3. If the previous answers are 'no', then are there any plans to
implement those features?
Thanks
^ permalink raw reply
* Re: [Patch net-next v3 7/9] fs: use generic union inet_addr and helper functions
From: Christoph Hellwig @ 2013-08-19 14:37 UTC (permalink / raw)
To: Cong Wang
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, David S. Miller, Steve French,
Christine Caulfield, David Teigland, Trond Myklebust,
linux-cifs-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
cluster-devel-H+wXaHxf7aLQT0dZR+AlfA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1376907278-26377-8-git-send-email-amwang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> @@ -1900,17 +1901,9 @@ srcip_matches(struct sockaddr *srcaddr, struct sockaddr *rhs)
> {
I think your new sockaddr_equal should be equivalent to to this
srcip_matches, that is it should warn about and return false for unknown
address families.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: NAT stops forwarding ACKs after PMTU discovery
From: Christoph Paasch @ 2013-08-19 14:43 UTC (permalink / raw)
To: Eric Dumazet
Cc: Corey Hickey, Jozsef Kadlecsik, Linux Netdev List,
netfilter-devel
In-Reply-To: <1376920685.4226.61.camel@edumazet-glaptop>
On 19/08/13 - 06:58:05, Eric Dumazet wrote:
> On Mon, 2013-08-19 at 15:49 +0200, Christoph Paasch wrote:
> > It's a TCP-patch, that interprets duplicate-acks with invalid SACK-blocks as
> > duplicate acks in tcp_sock->sacked_out.
>
> Yeah, but here, this is conntrack who is blocking the thing.
Yes, of course. I know that here conntrack is blocking the dup-ACKs.
Sorry for having added TCP-stack specific things in a conntrack-thread.
I just wanted to highlight that the TCP-stack has also problems with
sequence-number rewriting middleboxes.
> TCP receiver has no chance to 'fix' it.
>
> See conntrack is one of those buggy middle box as well.
>
> So if you want to properly handle this mess, you'll also have to fix
> conntrack.
^ permalink raw reply
* Re: [PATCH net-next 2/2] bnx2x: add RSS capability for GRE traffic
From: Jerry Chu @ 2013-08-19 14:57 UTC (permalink / raw)
To: Eric Dumazet
Cc: Dmitry Kravkov, Dmitry Kravkov, davem@davemloft.net,
netdev@vger.kernel.org, Eilon Greenstein, Tom Herbert,
Maciej Żenczykowski, Uday Naik, Michael Dalton
In-Reply-To: <1376869493.4226.13.camel@edumazet-glaptop>
On Sun, Aug 18, 2013 at 4:44 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Sun, 2013-08-18 at 14:11 -0700, Jerry Chu wrote:
>
>> It can if the csum validation is deferred. But this requires the stack code to
>> aggregate csum from individual pkt header, which can get ugly as one needs
>> to remove the header part from the individual csum first.
>
> You can _not_ aggregate packets _before_ validating their checksum, or
> else you could end up with a correct final checksum while two or more
> segments had buggy checksums. Checksum are already quite weak, please
> do not make them even weaker ;)
Yes I know how weak the 16bit 1's complement inet csum (see my previous email).
I've had the pleasure to debug a number of bugs in the past where 16bit words
were flipped by the buggy h/w hence went undetected by the weak TCP csum.
But I also think it's a tradeoff call. For WAN it's probably a bad
idea but for data
center traffic, pkt corruption is usually rare. If the performance
gain is large enough,
perhaps it justifies this hack (?)
>
> GRO should not throw out any segments, it is not its role.
I did not suggest GRO to throw away any pkt. GRO would just fix the csum
field in the header of the aggregated pkt and passes it on.
>
> If a router receives a bunch of packets, it should forward them
> regardless of the (TCP) checksum being good or not.
It won't affect the forwarding path (i think).
>
> The final receiver has full responsibility for ultimately validate the
> checksums and update various SNMP counters.
When the GRO pkt with the csum field fixed (aggregated) get to
the receiving TCP endpoint, it will be csum validated by the TCP stack
because skb->ip_summed == CHECKSUM_NONE, and the pkt will be
tossed if the csum check fails like non-GRO pkts.
To be clear, this hack is not something I'd be proud of and I doubt the
performance gain will be enough to justify it. This idea grew more out of
desperation for not having csum offload for encap'ed pkts, which I think
is a P0 bug!
Jerry
>
>
>
^ permalink raw reply
* Re: [Patch net-next v3 8/9] sctp: use generic union inet_addr
From: Vlad Yasevich @ 2013-08-19 15:05 UTC (permalink / raw)
To: Cong Wang
Cc: netdev, David S. Miller, Daniel Borkmann, Neil Horman, linux-sctp
In-Reply-To: <1376907278-26377-9-git-send-email-amwang@redhat.com>
On 08/19/2013 06:14 AM, Cong Wang wrote:
> From: Cong Wang <amwang@redhat.com>
>
> sctp has its own union sctp_addr which is nearly same
> with the generic union inet_addr, so just convert it
> to the generic one.
>
> Sorry for the big patch, it is not easy to split it. Most
> of the patch simply does s/union sctp_addr/union inet_addr/
> and some adjustments for the fields.
>
> The address family specific ops, ->cmp_addr(), ->is_any() etc.,
> are removed, since we have generic helpers, they are unnecessary.
You are not actually removing cmp_addr(), so that's invalid.
For the usage of ->is_any, see below.
> diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
> index 422db6c..8dfaa39 100644
> --- a/include/net/sctp/structs.h
> +++ b/include/net/sctp/structs.h
> @@ -1117,10 +1105,10 @@ union sctp_params sctp_bind_addrs_to_raw(const struct sctp_bind_addr *bp,
> int sctp_raw_to_bind_addrs(struct sctp_bind_addr *bp, __u8 *raw, int len,
> __u16 port, gfp_t gfp);
>
> -sctp_scope_t sctp_scope(const union sctp_addr *);
> -int sctp_in_scope(struct net *net, const union sctp_addr *addr, const sctp_scope_t scope);
> -int sctp_is_any(struct sock *sk, const union sctp_addr *addr);
> -int sctp_addr_is_valid(const union sctp_addr *addr);
> +sctp_scope_t sctp_scope(const union inet_addr *);
> +int sctp_in_scope(struct net *net, const union inet_addr *addr, const sctp_scope_t scope);
> +int sctp_is_any(struct sock *sk, const union inet_addr *addr);
You are keeping the prototype and remove the implementation of
sctp_is_any later, but that's ok since I don't think the implementation
should be removed. However, this points out that this should probably
be a separate patch (first do straight conversion to new data structure,
then fix up usage and delete unneeded functions).
> +int sctp_addr_is_valid(const union inet_addr *addr);
> int sctp_is_ep_boundall(struct sock *sk);
>
>
> diff --git a/net/sctp/bind_addr.c b/net/sctp/bind_addr.c
> index 077bb07..03d8f85 100644
> --- a/net/sctp/bind_addr.c
> +++ b/net/sctp/bind_addr.c
> @@ -47,7 +47,7 @@
> @@ -436,13 +436,13 @@ union sctp_addr *sctp_find_unmatch_addr(struct sctp_bind_addr *bp,
>
> /* Copy out addresses from the global local address list. */
> static int sctp_copy_one_addr(struct net *net, struct sctp_bind_addr *dest,
> - union sctp_addr *addr,
> + union inet_addr *addr,
> sctp_scope_t scope, gfp_t gfp,
> int flags)
> {
> int error = 0;
>
> - if (sctp_is_any(NULL, addr)) {
> + if (inet_addr_any(addr)) {
> error = sctp_copy_local_addr_list(net, dest, scope, gfp, flags);
> } else if (sctp_in_scope(net, addr, scope)) {
> /* Now that the address is in scope, check to see if
> @@ -461,27 +461,8 @@ static int sctp_copy_one_addr(struct net *net, struct sctp_bind_addr *dest,
> return error;
> }
>
> -/* Is this a wildcard address? */
> -int sctp_is_any(struct sock *sk, const union sctp_addr *addr)
> -{
> - unsigned short fam = 0;
> - struct sctp_af *af;
> -
> - /* Try to get the right address family */
> - if (addr->sa.sa_family != AF_UNSPEC)
> - fam = addr->sa.sa_family;
> - else if (sk)
> - fam = sk->sk_family;
> -
> - af = sctp_get_af_specific(fam);
> - if (!af)
> - return 0;
> -
> - return af->is_any(addr);
> -}
> -
I don't think you can remove this implentation. It is would introduce
a lot of regressions for code that does:
struct sockaddr_in sin;
memset(&sin, 0, sizeof(sin));
/* Do some setsockopt... with sin */
While I do agree that this is a bit sloppy (and I've made that argument
to all the bug submitters), this type of bug has been reported for a
long time and sctp_is_any() was finally changed to fix it once and for
all. You are un-fixing it...
> /* Is 'addr' valid for 'scope'? */
> -int sctp_in_scope(struct net *net, const union sctp_addr *addr, sctp_scope_t scope)
> +int sctp_in_scope(struct net *net, const union inet_addr *addr, sctp_scope_t scope)
> {
> sctp_scope_t addr_scope = sctp_scope(addr);
>
> @@ -530,7 +511,7 @@ int sctp_is_ep_boundall(struct sock *sk)
> if (sctp_list_single_entry(&bp->address_list)) {
> addr = list_entry(bp->address_list.next,
> struct sctp_sockaddr_entry, list);
> - if (sctp_is_any(sk, &addr->a))
> + if (inet_addr_any(&addr->a))
> return 1;
> }
> return 0;
> diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c
> index da613ce..2e1262b 100644
> --- a/net/sctp/ipv6.c
> +++ b/net/sctp/ipv6.c
>
> /* Compare addresses exactly.
> * v4-mapped-v6 is also in consideration.
> */
> -static int sctp_v6_cmp_addr(const union sctp_addr *addr1,
> - const union sctp_addr *addr2)
> +static bool sctp_v6_cmp_addr(const union inet_addr *addr1,
> + const union inet_addr *addr2)
> {
> if (addr1->sa.sa_family != addr2->sa.sa_family) {
> if (addr1->sa.sa_family == AF_INET &&
> addr2->sa.sa_family == AF_INET6 &&
> - ipv6_addr_v4mapped(&addr2->v6.sin6_addr)) {
> - if (addr2->v6.sin6_port == addr1->v4.sin_port &&
> - addr2->v6.sin6_addr.s6_addr32[3] ==
> - addr1->v4.sin_addr.s_addr)
> + ipv6_addr_v4mapped(&addr2->sin6.sin6_addr)) {
> + if (addr2->sin6.sin6_port == addr1->sin.sin_port &&
> + addr2->sin6.sin6_addr.s6_addr32[3] ==
> + addr1->sin.sin_addr.s_addr)
> return 1;
> }
> if (addr2->sa.sa_family == AF_INET &&
> addr1->sa.sa_family == AF_INET6 &&
> - ipv6_addr_v4mapped(&addr1->v6.sin6_addr)) {
> - if (addr1->v6.sin6_port == addr2->v4.sin_port &&
> - addr1->v6.sin6_addr.s6_addr32[3] ==
> - addr2->v4.sin_addr.s_addr)
> + ipv6_addr_v4mapped(&addr1->sin6.sin6_addr)) {
> + if (addr1->sin6.sin6_port == addr2->sin.sin_port &&
> + addr1->sin6.sin6_addr.s6_addr32[3] ==
> + addr2->sin.sin_addr.s_addr)
> return 1;
> }
> return 0;
> }
> - if (!ipv6_addr_equal(&addr1->v6.sin6_addr, &addr2->v6.sin6_addr))
> - return 0;
> - /* If this is a linklocal address, compare the scope_id. */
> - if (ipv6_addr_type(&addr1->v6.sin6_addr) & IPV6_ADDR_LINKLOCAL) {
> - if (addr1->v6.sin6_scope_id && addr2->v6.sin6_scope_id &&
> - (addr1->v6.sin6_scope_id != addr2->v6.sin6_scope_id)) {
> - return 0;
> - }
> - }
> -
> - return 1;
> -}
>
> -/* Initialize addr struct to INADDR_ANY. */
> -static void sctp_v6_inaddr_any(union sctp_addr *addr, __be16 port)
> -{
> - memset(addr, 0x00, sizeof(union sctp_addr));
> - addr->v6.sin6_family = AF_INET6;
> - addr->v6.sin6_port = port;
> -}
> -
> -/* Is this a wildcard address? */
> -static int sctp_v6_is_any(const union sctp_addr *addr)
> -{
> - return ipv6_addr_any(&addr->v6.sin6_addr);
> + return inet_addr_equal(addr1, addr2);
You've dropped the scope_id comparision which inet_addr_equal does not
seem to do. As far as I can see from this series, inet_addr_equal()
just calls ipv6_addr_equal.
-vlad
^ permalink raw reply
* Re: [PATCH 6/7] net: add the AF_FLEXRAY protocol
From: Schmitt, Sven (EVM/E) @ 2013-08-19 15:00 UTC (permalink / raw)
To: 'b.spranger@linutronix.de'; +Cc: 'netdev@vger.kernel.org'
On 13.08.2013 11:08, Benedikt Spranger wrote:
> FlexRay is a networking technology used in automotive fields as
> successor of the Controller Area Network (CAN). It provides the
> core functionality and a RAW protocol driver.
>
> Signed-off-by: Benedikt Spranger <b.spranger@linutronix.de>
> ---
> Documentation/networking/00-INDEX | 2 +
> Documentation/networking/flexray.txt | 24 ++
> include/linux/flexray.h | 168 ++++++++
Hello Benedikt,
thanks for bringing flexray to linux.
Some general remarks/questions:
- how can errors (crc, boundary, tx on not empty slot) be transported by the frame like in a CAN frame (/include/uapi/linux/can/error.h):
-> canid_t can_id; /* 32 bit CAN_ID + EFF/RTR/ERR flags */ ?
...there is no more space in the id field in your frame definition.
- what about special bus content like wakeup pattern (WUP), collision avoidance symbol (CAS) and media test symbols (MTS). These are interesting for logging use cases.
- do we need the crc fields? What happens if the cr check fails (-> error flag)? Do we need this information then?
- do we need the reserved bit? (there is none in CAN frame definition)
Best regards,
Sven
^ permalink raw reply
* [PATCH net-next 0/4] tun: Some bits required for tun's checkpoint-restore
From: Pavel Emelyanov @ 2013-08-19 15:09 UTC (permalink / raw)
To: Linux Netdev List, David Miller
Hi,
After taking a closer look on tun checkpoint-restore I've found several
issues with the tun's API that make it impossible to dump and restore
the state of tun device and attached tun-files.
The proposed API changes are all about extending the existing ioctl-based
stuff. Patches fit today's net-next.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
^ permalink raw reply
* [PATCH 1/4] tun: Add ability to create tun device with given index
From: Pavel Emelyanov @ 2013-08-19 15:09 UTC (permalink / raw)
To: Linux Netdev List, David Miller
In-Reply-To: <52123515.3060507@parallels.com>
Tun devices cannot be created with ifidex user wants, but it's
required by checkpoint-restore project.
Long time ago such ability was implemented for rtnl_ops-based
interface for creating links (9c7dafbf net: Allow to create links
with given ifindex), but the only API for creating and managing
tuntap devices is ioctl-based and is evolving with adding new ones
(cde8b15f tuntap: add ioctl to attach or detach a file form tuntap
device).
Following that trend, here's how a new ioctl that sets the ifindex
for device, that _will_ be created by TUNSETIFF ioctl looks like.
So those who want a tuntap device with the ifindex N, should open
the tun device, call ioctl(fd, TUNSETIFINDEX, &N), then call TUNSETIFF.
If the index N is busy, then the register_netdev will find this out
and the ioctl would be failed with -EBUSY.
If setifindex is not called, then it will be generated as before.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
---
drivers/net/tun.c | 21 ++++++++++++++++++++-
include/uapi/linux/if_tun.h | 1 +
2 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 7ed13cc..a12450b 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -138,7 +138,10 @@ struct tun_file {
struct fasync_struct *fasync;
/* only used for fasnyc */
unsigned int flags;
- u16 queue_index;
+ union {
+ u16 queue_index;
+ unsigned ifindex;
+ };
struct list_head next;
struct tun_struct *detached;
};
@@ -1601,6 +1604,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
dev_net_set(dev, net);
dev->rtnl_link_ops = &tun_link_ops;
+ dev->ifindex = tfile->ifindex;
tun = netdev_priv(dev);
tun->dev = dev;
@@ -1817,6 +1821,7 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
kgid_t group;
int sndbuf;
int vnet_hdr_sz;
+ unsigned ifindex;
int ret;
if (cmd == TUNSETIFF || cmd == TUNSETQUEUE || _IOC_TYPE(cmd) == 0x89) {
@@ -1851,6 +1856,19 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
ret = -EFAULT;
goto unlock;
}
+ if (cmd == TUNSETIFINDEX) {
+ ret = -EPERM;
+ if (tun)
+ goto unlock;
+
+ ret = -EFAULT;
+ if (copy_from_user(&ifindex, argp, sizeof(ifindex)))
+ goto unlock;
+
+ ret = 0;
+ tfile->ifindex = ifindex;
+ goto unlock;
+ }
ret = -EBADFD;
if (!tun)
@@ -2099,6 +2117,7 @@ static int tun_chr_open(struct inode *inode, struct file * file)
rcu_assign_pointer(tfile->tun, NULL);
tfile->net = get_net(current->nsproxy->net_ns);
tfile->flags = 0;
+ tfile->ifindex = 0;
rcu_assign_pointer(tfile->socket.wq, &tfile->wq);
init_waitqueue_head(&tfile->wq.wait);
diff --git a/include/uapi/linux/if_tun.h b/include/uapi/linux/if_tun.h
index 1870ee2..c58d023 100644
--- a/include/uapi/linux/if_tun.h
+++ b/include/uapi/linux/if_tun.h
@@ -56,6 +56,7 @@
#define TUNGETVNETHDRSZ _IOR('T', 215, int)
#define TUNSETVNETHDRSZ _IOW('T', 216, int)
#define TUNSETQUEUE _IOW('T', 217, int)
+#define TUNSETIFINDEX _IOW('T', 218, unsigned int)
/* TUNSETIFF ifr flags */
#define IFF_TUN 0x0001
--
1.7.6.5
^ permalink raw reply related
* [PATCH 2/4] tun: Report whether the queue is attached or not
From: Pavel Emelyanov @ 2013-08-19 15:09 UTC (permalink / raw)
To: Linux Netdev List, David Miller
In-Reply-To: <52123515.3060507@parallels.com>
Multiqueue tun devices allow to attach and detach from its queues
while keeping the interface itself set on file.
Knowing this is critical for the checkpoint part of criu project.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
---
drivers/net/tun.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index a12450b..167222f 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1881,6 +1881,9 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
case TUNGETIFF:
tun_get_iff(current->nsproxy->net_ns, tun, &ifr);
+ if (tfile->detached)
+ ifr.ifr_flags |= IFF_DETACH_QUEUE;
+
if (copy_to_user(argp, &ifr, ifreq_len))
ret = -EFAULT;
break;
--
1.7.6.5
^ permalink raw reply related
* [PATCH 3/4] tun: Allow to skip filter on attach
From: Pavel Emelyanov @ 2013-08-19 15:10 UTC (permalink / raw)
To: Linux Netdev List, David Miller
In-Reply-To: <52123515.3060507@parallels.com>
There's a small problem with sk-filters on tun devices. Consider
an application doing this sequence of steps:
fd = open("/dev/net/tun");
ioctl(fd, TUNSETIFF, { .ifr_name = "tun0" });
ioctl(fd, TUNATTACHFILTER, &my_filter);
ioctl(fd, TUNSETPERSIST, 1);
close(fd);
At that point the tun0 will remain in the system and will keep in
mind that there should be a socket filter at address '&my_filter'.
If after that we do
fd = open("/dev/net/tun");
ioctl(fd, TUNSETIFF, { .ifr_name = "tun0" });
we most likely receive the -EFAULT error, since tun_attach() would
try to connect the filter back. But (!) if we provide a filter at
address &my_filter, then tun0 will be created and the "new" filter
would be attached, but application may not know about that.
This may create certain problems to anyone using tun-s, but it's
critical problem for c/r -- if we meet a persistent tun device
with a filter in mind, we will not be able to attach to it to dump
its state (flags, owner, address, vnethdr size, etc.).
The proposal is to allow to attach to tun device (with TUNSETIFF)
w/o attaching the filter to the tun-file's socket. After this
attach app may e.g clean the device by dropping the filter, it
doesn't want to have one, or (in case of c/r) get information
about the device with tun ioctls.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
---
drivers/net/tun.c | 12 +++++++-----
include/uapi/linux/if_tun.h | 1 +
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 167222f..8bfc1ce 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -501,7 +501,7 @@ static void tun_detach_all(struct net_device *dev)
module_put(THIS_MODULE);
}
-static int tun_attach(struct tun_struct *tun, struct file *file)
+static int tun_attach(struct tun_struct *tun, struct file *file, bool skip_filter)
{
struct tun_file *tfile = file->private_data;
int err;
@@ -526,7 +526,7 @@ static int tun_attach(struct tun_struct *tun, struct file *file)
err = 0;
/* Re-attach the filter to presist device */
- if (tun->filter_attached == true) {
+ if (!skip_filter && (tun->filter_attached == true)) {
err = sk_attach_filter(&tun->fprog, tfile->socket.sk);
if (!err)
goto out;
@@ -1557,7 +1557,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
if (err < 0)
return err;
- err = tun_attach(tun, file);
+ err = tun_attach(tun, file, ifr->ifr_flags & IFF_NOFILTER);
if (err < 0)
return err;
@@ -1631,7 +1631,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
dev->vlan_features = dev->features;
INIT_LIST_HEAD(&tun->disabled);
- err = tun_attach(tun, file);
+ err = tun_attach(tun, file, false);
if (err < 0)
goto err_free_dev;
@@ -1795,7 +1795,7 @@ static int tun_set_queue(struct file *file, struct ifreq *ifr)
ret = security_tun_dev_attach_queue(tun->security);
if (ret < 0)
goto unlock;
- ret = tun_attach(tun, file);
+ ret = tun_attach(tun, file, false);
} else if (ifr->ifr_flags & IFF_DETACH_QUEUE) {
tun = rtnl_dereference(tfile->tun);
if (!tun || !(tun->flags & TUN_TAP_MQ) || tfile->detached)
@@ -1883,6 +1883,8 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
if (tfile->detached)
ifr.ifr_flags |= IFF_DETACH_QUEUE;
+ if (!tfile->socket.sk->sk_filter)
+ ifr.ifr_flags |= IFF_NOFILTER;
if (copy_to_user(argp, &ifr, ifreq_len))
ret = -EFAULT;
diff --git a/include/uapi/linux/if_tun.h b/include/uapi/linux/if_tun.h
index c58d023..cc127b2 100644
--- a/include/uapi/linux/if_tun.h
+++ b/include/uapi/linux/if_tun.h
@@ -71,6 +71,7 @@
#define IFF_DETACH_QUEUE 0x0400
/* read-only flag */
#define IFF_PERSIST 0x0800
+#define IFF_NOFILTER 0x1000
/* Socket options */
#define TUN_TX_TIMESTAMP 1
--
1.7.6.5
^ permalink raw reply related
* [PATCH 4/4] tun: Get skfilter layout
From: Pavel Emelyanov @ 2013-08-19 15:10 UTC (permalink / raw)
To: Linux Netdev List, David Miller
In-Reply-To: <52123515.3060507@parallels.com>
The only thing we may have from tun device is the fprog, whic contains
the number of filter elements and a pointer to (user-space) memory
where the elements are. The program itself may not be available if the
device is persistent and detached.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
---
drivers/net/tun.c | 10 ++++++++++
include/uapi/linux/if_tun.h | 1 +
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 8bfc1ce..eb48157 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -2042,6 +2042,16 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
tun_detach_filter(tun, tun->numqueues);
break;
+ case TUNGETFILTER:
+ ret = -EINVAL;
+ if ((tun->flags & TUN_TYPE_MASK) != TUN_TAP_DEV)
+ break;
+ ret = -EFAULT;
+ if (copy_to_user(argp, &tun->fprog, sizeof(tun->fprog)))
+ break;
+ ret = 0;
+ break;
+
default:
ret = -EINVAL;
break;
diff --git a/include/uapi/linux/if_tun.h b/include/uapi/linux/if_tun.h
index cc127b2..e9502dd 100644
--- a/include/uapi/linux/if_tun.h
+++ b/include/uapi/linux/if_tun.h
@@ -57,6 +57,7 @@
#define TUNSETVNETHDRSZ _IOW('T', 216, int)
#define TUNSETQUEUE _IOW('T', 217, int)
#define TUNSETIFINDEX _IOW('T', 218, unsigned int)
+#define TUNGETFILTER _IOR('T', 219, struct sock_fprog)
/* TUNSETIFF ifr flags */
#define IFF_TUN 0x0001
--
1.7.6.5
^ permalink raw reply related
* Re: NAT stops forwarding ACKs after PMTU discovery
From: Eric Dumazet @ 2013-08-19 15:32 UTC (permalink / raw)
To: Phil Oester
Cc: Christoph Paasch, Corey Hickey, Jozsef Kadlecsik,
Linux Netdev List, netfilter-devel
In-Reply-To: <20130819143509.GA31320@linuxace.com>
On Mon, 2013-08-19 at 07:35 -0700, Phil Oester wrote:
> On Mon, Aug 19, 2013 at 06:58:05AM -0700, Eric Dumazet wrote:
> > Yeah, but here, this is conntrack who is blocking the thing.
> >
> > TCP receiver has no chance to 'fix' it.
> >
> > See conntrack is one of those buggy middle box as well.
> >
> > So if you want to properly handle this mess, you'll also have to fix
> > conntrack.
>
> Better to fix the box which is randomizing the acks and ignoring
> the SACKs. Usually these are older Cisco PIX/ASA devices which just
> need a code upgrade.
Having a patch to relax things could be evaluated, if not adding new
problems ( http://en.wikipedia.org/wiki/Robustness_principle )
^ permalink raw reply
* Re: NAT stops forwarding ACKs after PMTU discovery
From: Christoph Paasch @ 2013-08-19 15:33 UTC (permalink / raw)
To: Phil Oester
Cc: Eric Dumazet, Corey Hickey, Jozsef Kadlecsik, Linux Netdev List,
netfilter-devel
In-Reply-To: <20130819143509.GA31320@linuxace.com>
On 19/08/13 - 07:35:09, Phil Oester wrote:
> On Mon, Aug 19, 2013 at 06:58:05AM -0700, Eric Dumazet wrote:
> > Yeah, but here, this is conntrack who is blocking the thing.
> >
> > TCP receiver has no chance to 'fix' it.
> >
> > See conntrack is one of those buggy middle box as well.
> >
> > So if you want to properly handle this mess, you'll also have to fix
> > conntrack.
>
> Better to fix the box which is randomizing the acks and ignoring
> the SACKs. Usually these are older Cisco PIX/ASA devices which just
> need a code upgrade.
I agree, the problem are these horrid middleboxes...
Unfortunately, they will hardly go away in the near futur. Rather the
opposite is the case.
If you have a public server running, I would be interested in the count of
invalid SACK-blocks received (netstat -s | grep TCPSACKDiscard). This is an
indication for such kind of middlebox between your server and the client,
implying that these connections cannot benefit from TCP-FastRetransmission
and each packet-loss will require an RTO to recover.
Cheers,
Christoph
^ permalink raw reply
* Re: [PATCH] ip: Add label option to ip monitor
From: Stephen Hemminger @ 2013-08-19 15:58 UTC (permalink / raw)
To: Martin Schwenke; +Cc: netdev
In-Reply-To: <20130819154330.77c29d55@martins.ozlabs.org>
On Mon, 19 Aug 2013 15:43:30 +1000
Martin Schwenke <martin@meltin.net> wrote:
> Prefix labelling is currently only activated when monitoring "all"
> objects. However, the output can still be confusing when monitoring
> more than 1 object, so add an option to always print prefix labels.
>
> Signed-off-by: Martin Schwenke <martin@meltin.net>
> ---
> Really a reply to http://www.spinics.net/lists/netdev/msg246739.html
Thanks, applied.
^ permalink raw reply
* Re: NAT stops forwarding ACKs after PMTU discovery
From: Eric Dumazet @ 2013-08-19 16:00 UTC (permalink / raw)
To: Christoph Paasch
Cc: Phil Oester, Corey Hickey, Jozsef Kadlecsik, Linux Netdev List,
netfilter-devel
In-Reply-To: <20130819153328.GH3583@cpaasch-mac>
On Mon, 2013-08-19 at 17:33 +0200, Christoph Paasch wrote:
>
> Unfortunately, they will hardly go away in the near futur. Rather the
> opposite is the case.
>
>
> If you have a public server running, I would be interested in the count of
> invalid SACK-blocks received (netstat -s | grep TCPSACKDiscard). This is an
> indication for such kind of middlebox between your server and the client,
> implying that these connections cannot benefit from TCP-FastRetransmission
> and each packet-loss will require an RTO to recover.
>
If the (random) sequence offset is small rather than completely out of
window, it's going to be hard to detect all problems.
Show us your patch ;)
^ permalink raw reply
* pull request net: 2013-08-19
From: Antonio Quartulli @ 2013-08-19 16:59 UTC (permalink / raw)
To: davem; +Cc: netdev, b.a.t.m.a.n
Hi David,
after a not so quiet weekend, here is my small pull request intended for
net/linux-3.11.
This is a fix that aims to block TX operations in case of skb preparation
failure.
Please pull or let me know of any problem.
Thanks,
Antonio
p.s. is net going to be merged into net-next one of these days? I need it in
order to send a couple of changes to net-next.
The following changes since commit 0f7dd1aa8f959216f1faa71513b9d3c1a9065e5a:
Merge tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mturquette/linux (2013-08-16 10:00:18 -0700)
are available in the git repository at:
git://git.open-mesh.org/linux-merge.git tags/batman-adv-fix-for-davem
for you to fetch changes up to 50fa3b31f4700deb1a860fa1a04016b889765323:
batman-adv: check return type of unicast packet preparations (2013-08-17 20:02:32 +0200)
----------------------------------------------------------------
Included change:
- Check if the skb has been correctly prepared before going on
----------------------------------------------------------------
Linus Lüssing (1):
batman-adv: check return type of unicast packet preparations
net/batman-adv/unicast.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
^ permalink raw reply
* [PATCH] batman-adv: check return type of unicast packet preparations
From: Antonio Quartulli @ 2013-08-19 16:59 UTC (permalink / raw)
To: davem
Cc: netdev, b.a.t.m.a.n, Linus Lüssing, Marek Lindner,
Antonio Quartulli
In-Reply-To: <1376931595-2070-1-git-send-email-ordex@autistici.org>
From: Linus Lüssing <linus.luessing@web.de>
batadv_unicast(_4addr)_prepare_skb might reallocate the skb's data.
And if it tries to do so then this can potentially fail.
We shouldn't continue working on this skb in such a case.
Signed-off-by: Linus Lüssing <linus.luessing@web.de>
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
Acked-by: Antonio Quartulli <ordex@autistici.org>
Signed-off-by: Antonio Quartulli <ordex@autistici.org>
---
net/batman-adv/unicast.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/net/batman-adv/unicast.c b/net/batman-adv/unicast.c
index 688a041..857e1b8 100644
--- a/net/batman-adv/unicast.c
+++ b/net/batman-adv/unicast.c
@@ -432,12 +432,16 @@ find_router:
switch (packet_type) {
case BATADV_UNICAST:
- batadv_unicast_prepare_skb(skb, orig_node);
+ if (!batadv_unicast_prepare_skb(skb, orig_node))
+ goto out;
+
header_len = sizeof(struct batadv_unicast_packet);
break;
case BATADV_UNICAST_4ADDR:
- batadv_unicast_4addr_prepare_skb(bat_priv, skb, orig_node,
- packet_subtype);
+ if (!batadv_unicast_4addr_prepare_skb(bat_priv, skb, orig_node,
+ packet_subtype))
+ goto out;
+
header_len = sizeof(struct batadv_unicast_4addr_packet);
break;
default:
--
1.8.1.5
^ permalink raw reply related
* Re: NAT stops forwarding ACKs after PMTU discovery
From: Christoph Paasch @ 2013-08-19 17:15 UTC (permalink / raw)
To: Eric Dumazet
Cc: Phil Oester, Corey Hickey, Jozsef Kadlecsik, Linux Netdev List,
netfilter-devel
In-Reply-To: <1376928031.4226.66.camel@edumazet-glaptop>
On 19/08/13 - 09:00:31, Eric Dumazet wrote:
> On Mon, 2013-08-19 at 17:33 +0200, Christoph Paasch wrote:
> > Unfortunately, they will hardly go away in the near futur. Rather the
> > opposite is the case.
> >
> >
> > If you have a public server running, I would be interested in the count of
> > invalid SACK-blocks received (netstat -s | grep TCPSACKDiscard). This is an
> > indication for such kind of middlebox between your server and the client,
> > implying that these connections cannot benefit from TCP-FastRetransmission
> > and each packet-loss will require an RTO to recover.
> >
>
> If the (random) sequence offset is small rather than completely out of
> window, it's going to be hard to detect all problems.
Yes, it is not possible to make it 100% perfect. But considering the size of
the seq-space, the probability is rather low that the SACK-block falls
in-window.
> Show us your patch ;)
Will send it soon. Have to rebase on net-next,... :)
(it's several months ago that I did this)
Christoph
^ permalink raw reply
* Re: [RFC][PATCH 2/2] bgmac: pass received packet to the netif instead of copying it
From: Rafał Miłecki @ 2013-08-19 17:20 UTC (permalink / raw)
To: Felix Fietkau
Cc: Network Development, Jonas Gorski, Hauke Mehrtens,
OpenWrt Development List
In-Reply-To: <5211A0CB.70003@openwrt.org>
2013/8/19 Felix Fietkau <nbd@openwrt.org>:
> On 2013-08-15 10:21 PM, Rafał Miłecki wrote:
>> I'm afraid this "perf top" output doesn't really tell us where to look
>> for optimizations :| I'll still try Felix ideas tomorrow, but I'm not
>> sure if they help, since there isn't __copy_user_common anymore in the
>> "perf top" output...
> What's the CPU load while passing traffic without running perf?
During "ping 192.168.5.1"
# top
Mem: 19564K used, 107076K free, 0K shrd, 0K buff, 12916K cached
CPU: 0% usr 0% sys 0% nic 99% idle 0% io 0% irq 0% sirq
Load average: 0.17 0.10 0.04 1/24 810
# perf top
PerfTop: 261 irqs/sec kernel:100.0% exact: 0.0% [4000Hz cycles], (all, 1 CPU)
-------------------------------------------------------------------------------
64.21% [kernel] [k] arch_cpu_idle
16.38% [kernel] [k] arch_local_irq_restore
12.01% [kernel] [k] cpu_startup_entry
2.16% [kernel] [k] rcu_idle_exit
During "iperf -c 192.168.5.1"
# top
Mem: 19572K used, 107068K free, 0K shrd, 0K buff, 12916K cached
CPU: 0% usr 0% sys 0% nic 3% idle 0% io 0% irq 96% sirq
Load average: 0.29 0.11 0.04 1/24 809
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
3 2 root RW 0 0% 9% [ksoftirqd/0]
809 376 root R 1496 1% 2% top
716 1 nobody S 964 1% 1% /usr/sbin/dnsmasq -C /var/etc/dnsmasq
# perf top
PerfTop: 265 irqs/sec kernel:100.0% exact: 0.0% [4000Hz cycles], (all, 1 CPU)
-------------------------------------------------------------------------------
6.41% [ip_tables] [k] ipt_do_table
4.01% [bgmac] [k] 0x000006ec
3.43% [kernel] [k] arch_cpu_idle
3.30% [kernel] [k] arch_local_irq_restore
3.25% [kernel] [k] ip_rcv
3.11% [nf_conntrack] [k] nf_conntrack_proto_fini
3.11% [nf_conntrack] [k] nf_conntrack_in
> Have you tested bridging performance?
Do you mean connecting both machines to the same VLAN? Like 2 LAN
ports in the standard configuration? It gives me ~600Mb/s using
OpenWrt. It's pretty much the same performance I got with the original
firmware for transfer between 2 VLANs.
[ 5] local 192.168.1.218 port 5001 connected with 192.168.1.131 port 59463
[ 5] 0.0-60.0 sec 4.16 GBytes 596 Mbits/sec
--
Rafał
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
^ permalink raw reply
* Re: NAT stops forwarding ACKs after PMTU discovery
From: Phil Oester @ 2013-08-19 18:00 UTC (permalink / raw)
To: Christoph Paasch
Cc: Eric Dumazet, Corey Hickey, Jozsef Kadlecsik, Linux Netdev List,
netfilter-devel
In-Reply-To: <20130819171519.GA4008@cpaasch-mac>
On Mon, Aug 19, 2013 at 07:15:19PM +0200, Christoph Paasch wrote:
> On 19/08/13 - 09:00:31, Eric Dumazet wrote:
> > On Mon, 2013-08-19 at 17:33 +0200, Christoph Paasch wrote:
> > > Unfortunately, they will hardly go away in the near futur. Rather the
> > > opposite is the case.
> > >
> > >
> > > If you have a public server running, I would be interested in the count of
> > > invalid SACK-blocks received (netstat -s | grep TCPSACKDiscard). This is an
> > > indication for such kind of middlebox between your server and the client,
> > > implying that these connections cannot benefit from TCP-FastRetransmission
> > > and each packet-loss will require an RTO to recover.
> > >
> >
> > If the (random) sequence offset is small rather than completely out of
> > window, it's going to be hard to detect all problems.
It is not small unfortunately. The bug is that with ISN randomization enabled
the PIX leaves the SACK sequence numbers untouched. For reference, the cisco
bug is CSCse14419.
> Yes, it is not possible to make it 100% perfect. But considering the size of
> the seq-space, the probability is rather low that the SACK-block falls
> in-window.
s/rather low/nil/
> > Show us your patch ;)
Or just disable SACK on the box behind the problematic PIX.
Phil
^ permalink raw reply
* Re: NAT stops forwarding ACKs after PMTU discovery
From: Eric Dumazet @ 2013-08-19 18:10 UTC (permalink / raw)
To: Christoph Paasch
Cc: Phil Oester, Corey Hickey, Jozsef Kadlecsik, Linux Netdev List,
netfilter-devel
In-Reply-To: <20130819171519.GA4008@cpaasch-mac>
On Mon, 2013-08-19 at 19:15 +0200, Christoph Paasch wrote:
>
> Will send it soon. Have to rebase on net-next,... :)
> (it's several months ago that I did this)
No hurry.
This is a very unlikely problem anyway.
Trace taken on a random Google server :
TcpExtTCPSACKDiscard 44666
TcpExtTCPSACKReneging 173593
TcpExtTCPSACKReorder 1331306
TcpExtTCPSackFailures 791292
TcpExtTCPSackMerged 261702691
TcpExtTCPSackRecovery 57267494
TcpExtTCPSackRecoveryFail 2008511
TcpExtTCPSackShiftFallback 841017416
TcpExtTCPSackShifted 619337144
...
TcpOutSegs 42215528084
TcpRetransSegs 441868477
^ permalink raw reply
* Re: [GLIBC Patch v2] inet: avoid redefinition of some structs in kernel
From: Carlos O'Donell @ 2013-08-19 18:11 UTC (permalink / raw)
To: Cong Wang
Cc: netdev, David S. Miller, Thomas Backlund, libc-alpha,
YOSHIFUJI Hideaki
In-Reply-To: <1376875250.2742.2.camel@cr0>
On 08/18/2013 09:20 PM, Cong Wang wrote:
> On Fri, 2013-08-16 at 11:47 -0400, Carlos O'Donell wrote:
>> On 08/15/2013 05:28 AM, Cong Wang wrote:
>>> 2013-08-13 Carlos O'Donell <carlos@redhat.com>
>>> Cong Wang <amwang@redhat.com>
>>>
>>> * sysdeps/unix/sysv/linux/bits/in.h
>>> [_UAPI_LINUX_IN6_H]: Define __USE_KERNEL_IPV6_DEFS.
>>> * inet/netinet/in.h: Move in_addr definition and bits/in.h inclusion
>>> before __USE_KERNEL_IPV6_DEFS uses.
>>> * inet/netinet/in.h [!__USE_KERNEL_IPV6_DEFS]: Define IPPROTO_MH, and
>>> IPPROTO_BEETPH.
>>> [__USE_KERNEL_IPV6_DEFS]: Don't define any of IPPROTO_*, in6_addr,
>>> sockaddr_in6, or ipv6_mreq.
>>
>> Cong,
>>
>> Given that this is a user visible change could you please file
>> a glibc bugzilla bug in sourceware[1] so we can track the commit and so
>> that future users can reopen the bug to discuss any defects?
>
> Done, http://sourceware.org/bugzilla/show_bug.cgi?id=15850
Perfect.
>>
>> Then you need to add the BZ# to the ChangeLog, and whomever
>> commits this for you will mark it fixed in the NEWS. We should
>> also write up a NEWS blurb for this since it's the first explicit
>> header coordination of it's kind and we should highlight that
>> so developers take note and help us coordinate more headers.
>>
>
> Should I resend this patch with BZ# included?
No need. But the final ChangeLog should have the BZ# in it, and the
committer will add it to the NEWS list of bugs fixed in 2.19.
Cheers,
Carlos.
^ permalink raw reply
* Re: [PATCH net] net-packet: restore packet statistics tp_packets to include drops
From: Sergei Shtylyov @ 2013-08-19 18:22 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: davem, dborkman, netdev
In-Reply-To: <1376855916-21824-1-git-send-email-willemb@google.com>
Hello.
On 08/18/2013 11:58 PM, Willem de Bruijn wrote:
> getsockopt PACKET_STATISTICS returns tp_packets + tp_drops.
> Commit ee80fbf301 cleaned up the getsockopt PACKET_STATISTICS code.
Please also specify that commit's summary in parens.
> This also changed semantics. Historically, tp_packets included
> tp_drops on return. The commit removed the line that adds tp_drops
> into tp_packets.
> This patch reinstates the old semantics.
> Signed-off-by: Willem de Bruijn <willemb@google.com>
WBR, Sergei
^ 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