* Re: net-PA Semi: Deletion of unnecessary checks before the function call "pci_dev_put"
From: SF Markus Elfring @ 2014-11-30 20:40 UTC (permalink / raw)
To: Lino Sanfilippo
Cc: Julia Lawall, Olof Johansson, netdev, LKML, kernel-janitors
In-Reply-To: <547B6F9A.8030806@gmx.de>
> Maybe this topic should be clarified somewhere (e.g. in "CodingStyle")?
> On the other hand i always found it obvious that its the callers
> responsibility to only pass sane parameters to the called functions...
Can you imagine that any more source code places which would benefit from
check adjustments because of defensive programming?
Regards,
Markus
^ permalink raw reply
* Re: [PATCH 3/3] net-PPP: Delete an unnecessary assignment
From: SF Markus Elfring @ 2014-11-30 21:16 UTC (permalink / raw)
To: Eric Dumazet
Cc: Paul Mackerras, linux-ppp, netdev, LKML, kernel-janitors,
Julia Lawall
In-Reply-To: <1417377583.4442.11.camel@edumazet-glaptop2.roam.corp.google.com>
> I have no idea why its a patch on its own, and why state->arc4 gets
> special treatment while state->sha1 does not.
I did not fiddle with the data structure element "sha1" because
I assumed that it might be still relevant for the call of a function
like crypto_free_blkcipher().
> This definitely belongs to the previous patch, refactoring error
> handling in mppe_alloc()
I have got different preferences for change distribution over several
patches here.
I find it safer to tackle an assignment clean-up after adjustments
for jump labels.
> Also, it seems your patches do not fix bugs, so so you need to target
> net-next tree, as explained in Documentation/networking/netdev-FAQ.txt
Do you want that I resend my update suggestion?
Regards,
Markus
^ permalink raw reply
* Re: net-PA Semi: Deletion of unnecessary checks before the function call "pci_dev_put"
From: Lino Sanfilippo @ 2014-11-30 21:36 UTC (permalink / raw)
To: SF Markus Elfring
Cc: Julia Lawall, Olof Johansson, netdev, LKML, kernel-janitors
In-Reply-To: <547B80B7.5030707@users.sourceforge.net>
On 30.11.2014 21:40, SF Markus Elfring wrote:
>> Maybe this topic should be clarified somewhere (e.g. in "CodingStyle")?
>> On the other hand i always found it obvious that its the callers
>> responsibility to only pass sane parameters to the called functions...
>
> Can you imagine that any more source code places which would benefit from
> check adjustments because of defensive programming?
>
I am not sure if i understand your question correctly. But i would not
call sanity checks for function parameters "defensive programming". I
would rather call it not being totally careless. So to me the question
if those checks should be done or not is different from the question
whether there are code parts that would benefit from an adjustment to
defensive programming.
Regards,
Lino
^ permalink raw reply
* [PATCH iproute2] ip monitor: Fixed printing timestamp few times
From: Vadim Kochan @ 2014-11-30 23:14 UTC (permalink / raw)
To: netdev; +Cc: Vadim Kochan
Another fix when timestamp is printed few times
before the event message.
Fixed by skipping the message types which are not supported.
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
---
ip/ipmonitor.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/ip/ipmonitor.c b/ip/ipmonitor.c
index 4cc75f4..5c3ed18 100644
--- a/ip/ipmonitor.c
+++ b/ip/ipmonitor.c
@@ -42,6 +42,15 @@ static int accept_msg(const struct sockaddr_nl *who,
{
FILE *fp = (FILE*)arg;
+ if (n->nlmsg_type == RTM_NEWQDISC ||
+ n->nlmsg_type == RTM_DELQDISC ||
+ n->nlmsg_type == RTM_NEWTCLASS ||
+ n->nlmsg_type == RTM_DELTCLASS ||
+ n->nlmsg_type == RTM_NEWTFILTER ||
+ n->nlmsg_type == RTM_DELTFILTER ||
+ n->nlmsg_type == RTM_NEWNDUSEROPT)
+ return 0;
+
if (n->nlmsg_type == RTM_NEWROUTE || n->nlmsg_type == RTM_DELROUTE) {
struct rtmsg *r = NLMSG_DATA(n);
int len = n->nlmsg_len - NLMSG_LENGTH(sizeof(*r));
@@ -134,14 +143,6 @@ static int accept_msg(const struct sockaddr_nl *who,
fprintf(fp, "Timestamp: %s %lu us\n", tstr, usecs);
return 0;
}
- if (n->nlmsg_type == RTM_NEWQDISC ||
- n->nlmsg_type == RTM_DELQDISC ||
- n->nlmsg_type == RTM_NEWTCLASS ||
- n->nlmsg_type == RTM_DELTCLASS ||
- n->nlmsg_type == RTM_NEWTFILTER ||
- n->nlmsg_type == RTM_DELTFILTER ||
- n->nlmsg_type == RTM_NEWNDUSEROPT)
- return 0;
if (n->nlmsg_type != NLMSG_ERROR && n->nlmsg_type != NLMSG_NOOP &&
n->nlmsg_type != NLMSG_DONE) {
fprintf(fp, "Unknown message: type=0x%08x(%d) flags=0x%08x(%d)"
--
2.1.3
^ permalink raw reply related
* Possible memory leak in function (r8712_setrttbl_cmd) not freeing pointer (ph2c) on error path
From: Ahmed Tamrawi @ 2014-12-01 1:06 UTC (permalink / raw)
To: netdev
Bug Report Filed: https://bugzilla.kernel.org/show_bug.cgi?id=88881
Linux Version [3.17-rc1]
Configuration: Default configuration for x86
In function (r8712_setrttbl_cmd) file (drivers/staging/rtl8712/rtl871x_cmd.c):
Function (r8712_setrttbl_cmd) allocates the variable (ph2c) at line
732 and passes it as a parameter to function (r8712_enqueue_cmd) at
line 743. Function (r8712_setrttbl_cmd) returns (_SUCCESS) result
regardless of the result of the called function (r8712_enqueue_cmd)
which may return (_FAIL) at line 176. This failure causing the
allocated object not to be queued and hence not freed later. Thus,
causing a possible memory leak not freeing the (ph2c) pointer upon
(_FAIL) return of function (r8712_enqueue_cmd).
Source code reference for function (r8712_setrttbl_cmd):
http://lxr.free-electrons.com/source/drivers/staging/rtl8712/rtl871x_cmd.c#L725
Source code reference for function (r8712_enqueue_cmd):
http://lxr.free-electrons.com/source/drivers/staging/rtl8712/rtl871x_cmd.c#L171
~Ahmed
^ permalink raw reply
* [PATCH] uapi: fix to export linux/vm_sockets.h
From: Masahiro Yamada @ 2014-12-01 1:16 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: Masahiro Yamada, Stephen Hemminger, David S. Miller,
Greg Kroah-Hartman, Alexei Starovoitov, Piotr Król,
Andrew Morton, Sakari Ailus, linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
A typo "header=y" was introduced by commit 7071cf7fc435
(uapi: add missing network related headers to kbuild).
Signed-off-by: Masahiro Yamada <yamada.m-NAum8xwdG0+S7A1Ibl2khg@public.gmane.org>
Cc: Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
---
include/uapi/linux/Kbuild | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
index 4c94f31..8523f9b 100644
--- a/include/uapi/linux/Kbuild
+++ b/include/uapi/linux/Kbuild
@@ -427,7 +427,7 @@ header-y += virtio_net.h
header-y += virtio_pci.h
header-y += virtio_ring.h
header-y += virtio_rng.h
-header=y += vm_sockets.h
+header-y += vm_sockets.h
header-y += vt.h
header-y += wait.h
header-y += wanrouter.h
--
1.9.1
^ permalink raw reply related
* Re: [PATCH net] net/mlx4_en: correct the endianness of doorbell_qpn on big endian platform
From: Wei Yang @ 2014-12-01 1:29 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Wei Yang, netdev, davem, gideonn, Eric Dumazet, Amir Vadai
In-Reply-To: <1417375668.4442.5.camel@edumazet-glaptop2.roam.corp.google.com>
On Sun, Nov 30, 2014 at 11:27:48AM -0800, Eric Dumazet wrote:
>On Sun, 2014-11-30 at 10:43 +0800, Wei Yang wrote:
>> In commit 6a4e812 (net/mlx4_en: Avoid calling bswap in tx fast path), we store
>> doorbell_qpn in big endian to avoid bswap(). Then we try to write it directly
>> by iowrite32() instead of iowrite32be().
>>
>> This works fine on little endian platform, while has some problem on big
>> endian platform. Here is the definition in general:
>>
>> #define iowrite32(v, addr) writel((v), (addr))
>> #define writel(b,addr) __raw_writel(__cpu_to_le32(b),addr)
>
>Oh well...
>
>>
>> On little endian platform, the value is not swapped before write. While on big
>> endian platform, the value is swapped. This is not expected to happen.
>>
>> This patch does the swap on big endian platform before it is written.
>>
>> Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com>
>> CC: Eric Dumazet <edumazet@google.com>
>> CC: Amir Vadai <amirv@mellanox.com>
>> ---
>> drivers/net/ethernet/mellanox/mlx4/en_tx.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_tx.c b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
>> index 454d9fe..76f028b 100644
>> --- a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
>> +++ b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
>> @@ -954,7 +954,7 @@ netdev_tx_t mlx4_en_xmit(struct sk_buff *skb, struct net_device *dev)
>> tx_desc->ctrl.owner_opcode = op_own;
>> if (send_doorbell) {
>> wmb();
>> - iowrite32(ring->doorbell_qpn,
>> + iowrite32(__cpu_to_le32(ring->doorbell_qpn),
>> ring->bf.uar->map + MLX4_SEND_DOORBELL);
>> } else {
>> ring->xmit_more++;
>
>Well, whole idea of the patch was to perform the swap (if any) out of
>the fast path.
Yes, I know the it.
>
>ring->doorbell_qpn is a cache of whatever value.
>
>Have you tried to convert it to a __le32 instead of __be32 ?
>
You mean change the type of doorbell_qpn or the function __cpu_to_be32()?
I don't get your point.
>Thanks
>
--
Richard Yang
Help you, Help me
^ permalink raw reply
* Re: net-PA Semi: Deletion of unnecessary checks before the function call "pci_dev_put"
From: SF Markus Elfring @ 2014-12-01 1:34 UTC (permalink / raw)
To: Lino Sanfilippo, Olof Johansson, netdev-u79uwXL29TY76Z2rM5mHXA,
backports-u79uwXL29TY76Z2rM5mHXA
Cc: LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Julia Lawall,
Luis R. Rodriguez
In-Reply-To: <547B579F.10709-Mmb7MZpHnFY@public.gmane.org>
> I know there has been some criticism about those kind of "code
> improvements" already but i would like to point out just one more thing:
>
> Some of those NULL pointer checks on input parameters may have been
> added subsequently to functions. So there may be older kernel versions
> out there in which those checks dont exists in some cases. If some of
> the now "cleaned up" code is backported to such a kernel chances are
> good that those missing checks are overseen. And then neither caller nor
> callee is doing the NULL pointer check.
I guess that the Coccinelle software can also help you in this use case.
How do you think about to shield against "unwanted" or unexpected collateral
evolutions with additional inline functions?
I assume that a few backporters can tell you more about their corresponding
software development experiences.
http://www.do-not-panic.com/2014/04/automatic-linux-kernel-backporting-with-coccinelle.html
Regards,
Markus
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Kevin Zhu @ 2014-12-01 2:31 UTC (permalink / raw)
To: Enrico Mioso, Bjørn Mork
Cc: Eli Britstein, youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Midge Shaojun Tan
In-Reply-To: <alpine.LNX.2.03.1411301931280.2605-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Sorry for the late reply.
I tried to calculate the offset as what windows did, but it did not help.
Regards,
Kevin
On 12/01/2014 02:36 AM, Enrico Mioso wrote:
> Thank you Bjorn for the help and suggestions.
> These are parameters that the driver ends up choosing:
> /sys/class/net/wwan0/cdc_ncm/bmNtbFormatsSupported:0x0003
> /sys/class/net/wwan0/cdc_ncm/dwNtbInMaxSize:131072
> /sys/class/net/wwan0/cdc_ncm/dwNtbOutMaxSize:16384
> /sys/class/net/wwan0/cdc_ncm/min_tx_pkt:14848
> /sys/class/net/wwan0/cdc_ncm/rx_max:16384
> /sys/class/net/wwan0/cdc_ncm/tx_max:16384
> /sys/class/net/wwan0/cdc_ncm/tx_timer_usecs:400
> /sys/class/net/wwan0/cdc_ncm/wNdpInAlignment:4
> /sys/class/net/wwan0/cdc_ncm/wNdpInDivisor:4
> /sys/class/net/wwan0/cdc_ncm/wNdpInPayloadRemainder:2
> /sys/class/net/wwan0/cdc_ncm/wNdpOutAlignment:4
> /sys/class/net/wwan0/cdc_ncm/wNdpOutDivisor:4
> /sys/class/net/wwan0/cdc_ncm/wNdpOutPayloadRemainder:2
> /sys/class/net/wwan0/cdc_ncm/wNtbOutMaxDatagrams:0
>
> Sorry if I did not report them before. If I missed someone in CC please add it
> guys.
> Kevin - after you discovered that the device might handle the offset in a
> different way, have you tried this approach?
>
>
> On Thu, 27 Nov 2014, Bjørn Mork wrote:
>
> ==Date: Thu, 27 Nov 2014 11:03:24
> ==From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
> ==To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ==Cc: youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, linux-usb-u79uwXL29TasMV2rI37PzA@public.gmane.orgorg,
> == netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> ==Subject: Re: Is this 32-bit NCM?
> ==
> ==Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> ==
> ==> Ok - we can arrive to some ocnclusions regarding the E3272.
> ==> First of all - the modem seems buggy enough to not be able to handle requests
> ==> for different formats. You need to unplug and re-plug it, but this is onlyan
> ==> impression and is reasonable.
> ==>
> ==> Then - the modem will accept to ndisdup the connection with
> ==> at^ndisdup=1,1,"internet"
> ==> but - if we use huawei_cdc_ncm + cdc_ncm we have no flow handling messages and
> ==> the modem stops here.
> ==> If we use the cdc_ncm 32-bit driver (modified) we get lotfs of
> ==> ^dsflorpt
> ==> that's how it should be.
> ==> So I think we can say that something is changing.
> ==> Then there's the alignment problem you mentioned in your previous reply. And
> ==> this is hard to solve.
> ==> could you try to help me understand where the problem is?
> ==> I feel like we are very close to the solution but something isn't working.
> ==> Or might be just try to change the 16 bit driver?
> ==
> ==If you use a recent version of the driver as a basis, then you get the
> ==CDC NCM NTB parameters in sysfs (if not, then you need to enable
> ==debugging and look in the log for these values). For example:
> ==
> ==bjorn@nemi:~$ grep . /sys/class/net/wwan0/cdc_ncm/*
> ==/sys/class/net/wwan0/cdc_ncm/bmNtbFormatsSupported:0x0001
> ==/sys/class/net/wwan0/cdc_ncm/dwNtbInMaxSize:15360
> ==/sys/class/net/wwan0/cdc_ncm/dwNtbOutMaxSize:15360
> ==/sys/class/net/wwan0/cdc_ncm/min_tx_pkt:13824
> ==/sys/class/net/wwan0/cdc_ncm/rx_max:15360
> ==/sys/class/net/wwan0/cdc_ncm/tx_max:15360
> ==/sys/class/net/wwan0/cdc_ncm/tx_timer_usecs:400
> ==/sys/class/net/wwan0/cdc_ncm/wNdpInAlignment:4
> ==/sys/class/net/wwan0/cdc_ncm/wNdpInDivisor:1
> ==/sys/class/net/wwan0/cdc_ncm/wNdpInPayloadRemainder:0
> ==/sys/class/net/wwan0/cdc_ncm/wNdpOutAlignment:4
> ==/sys/class/net/wwan0/cdc_ncm/wNdpOutDivisor:32
> ==/sys/class/net/wwan0/cdc_ncm/wNdpOutPayloadRemainder:0
> ==/sys/class/net/wwan0/cdc_ncm/wNtbOutMaxDatagrams:32
> ==
> ==
> ==The possible problem I am thinking of is proper handling of the
> ==wNdp*PayloadRemainder values. See section 3.3.4 "NCM Ethernet Frame
> ==Alignment" in the spec. Which is confusing as hell, but if I understand
> ==it correctly then we are supposed to align the start of the IP packets
> ==(the "payload", _not_ the ethernet frame) to a whole wNdp*Divisor number
> ==as long as the wNdp*PayloadRemainder is 0.
> ==
> ==
> ==Bjørn
> ==
This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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: Is this 32-bit NCM?
From: Kevin Zhu @ 2014-12-01 2:51 UTC (permalink / raw)
To: Enrico Mioso, Alex Strizhevsky
Cc: Eli Britstein, linux-usb@vger.kernel.org, youtux@gmail.com,
Midge Shaojun Tan, netdev@vger.kernel.org, Bjørn Mork
In-Reply-To: <alpine.LNX.2.03.1411301112330.1477@gmail.com>
Hi,
My dongle firmware version is 21.286.03.01.209, not working either.
Regards,
Kevin
On 11/30/2014 06:18 PM, Enrico Mioso wrote:
> Sorry - by error I did not send the message to all.
> Hi everyone, and good Sunday!
> The problem is that - between those two firmwares things might change, and so
> we don't know what Windows does when it meets this specific branch /version of
> the firmware.
> I am desperately suspecting that we would not get anything hinting a lot even
> looking at the usb capture of this specific firmware, but... in any case it
> might be interesting to have it.
> (at+gmr returns the firmware revision)
> Is the dongles with 23 firmwares working under Linux?
> Or, you might upgrade all dongles firmware until all of then are running the 23
> version and so workaround the problem differently in case.
> Bjorn: I noticed that anyway, as Alex suggested, tcpdump can reveal some
> traffic: in particular you can see the gateway asking for us ... but no
> traffic can flow out, only flow in.
> The system can see traffic coming in, not generate it. Any idea or comment
> from anyone is welcome.
This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message
^ permalink raw reply
* [PATCH net-next 0/3] timestamping updates
From: Willem de Bruijn @ 2014-12-01 3:22 UTC (permalink / raw)
To: netdev; +Cc: davem, luto, richardcochran, Willem de Bruijn
From: Willem de Bruijn <willemb@google.com>
The main goal for this patchset is to allow correlating timestamps
with the egress interface. Also introduce a warning, as discussed
previously, and update the tests to verify the new feature.
Willem de Bruijn (3):
ipv4: warn once on passing AF_INET6 socket to ip_recv_error
net-timestamp: allow reading recv cmsg on errqueue with origin tstamp
net-timestamp: expand documentation and test
Documentation/networking/timestamping.txt | 33 ++++++--
.../networking/timestamping/txtimestamp.c | 90 +++++++++++++++++++---
include/uapi/linux/net_tstamp.h | 3 +-
net/ipv4/ip_sockglue.c | 24 +++++-
net/ipv6/datagram.c | 21 ++++-
5 files changed, 146 insertions(+), 25 deletions(-)
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply
* [PATCH net-next 1/3] ipv4: warn once on passing AF_INET6 socket to ip_recv_error
From: Willem de Bruijn @ 2014-12-01 3:22 UTC (permalink / raw)
To: netdev; +Cc: davem, luto, richardcochran, Willem de Bruijn
In-Reply-To: <1417404155-28607-1-git-send-email-willemb@google.com>
From: Willem de Bruijn <willemb@google.com>
One line change, in response to catching an occurrence of this bug.
See also fix f4713a3dfad0 ("net-timestamp: make tcp_recvmsg call ...")
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
net/ipv4/ip_sockglue.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index b782657..59eba6c 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -414,6 +414,8 @@ int ip_recv_error(struct sock *sk, struct msghdr *msg, int len, int *addr_len)
int err;
int copied;
+ WARN_ON_ONCE(sk->sk_family == AF_INET6);
+
err = -EAGAIN;
skb = sock_dequeue_err_skb(sk);
if (skb == NULL)
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* [PATCH net-next 3/3] net-timestamp: expand documentation and test
From: Willem de Bruijn @ 2014-12-01 3:22 UTC (permalink / raw)
To: netdev; +Cc: davem, luto, richardcochran, Willem de Bruijn
In-Reply-To: <1417404155-28607-1-git-send-email-willemb@google.com>
From: Willem de Bruijn <willemb@google.com>
Documentation:
expand explanation of timestamp counter
Test:
new: flag -I requests and prints PKTINFO
new: flag -x prints payload (possibly truncated)
fix: remove pretty print that breaks common flag '-l 1'
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
Documentation/networking/timestamping.txt | 23 ++++--
.../networking/timestamping/txtimestamp.c | 90 +++++++++++++++++++---
2 files changed, 93 insertions(+), 20 deletions(-)
diff --git a/Documentation/networking/timestamping.txt b/Documentation/networking/timestamping.txt
index b08e272..a5c784c 100644
--- a/Documentation/networking/timestamping.txt
+++ b/Documentation/networking/timestamping.txt
@@ -130,19 +130,26 @@ SOF_TIMESTAMPING_OPT_ID:
have multiple concurrent timestamping requests outstanding. Packets
can be reordered in the transmit path, for instance in the packet
scheduler. In that case timestamps will be queued onto the error
- queue out of order from the original send() calls. This option
- embeds a counter that is incremented at send() time, to order
- timestamps within a flow.
+ queue out of order from the original send() calls. It is not always
+ possible to uniquely match timestamps to the original send() calls
+ based on timestamp order or payload inspection alone, then.
+
+ This option associates each packet at send() with a unique
+ identifier and returns that along with the timestamp. The identifier
+ is derived from a per-socket u32 counter (that wraps). For datagram
+ sockets, the counter increments with each sent packet. For stream
+ sockets, it increments with every byte.
+
+ The counter starts at zero. It is initialized the first time that
+ the socket option is enabled. It is reset each time the option is
+ enabled after having been disabled. Resetting the counter does not
+ change the identifiers of existing packets in the system.
This option is implemented only for transmit timestamps. There, the
timestamp is always looped along with a struct sock_extended_err.
The option modifies field ee_data to pass an id that is unique
among all possibly concurrently outstanding timestamp requests for
- that socket. In practice, it is a monotonically increasing u32
- (that wraps).
-
- In datagram sockets, the counter increments on each send call. In
- stream sockets, it increments with every byte.
+ that socket.
SOF_TIMESTAMPING_OPT_CMSG:
diff --git a/Documentation/networking/timestamping/txtimestamp.c b/Documentation/networking/timestamping/txtimestamp.c
index b32fc2a..876f71c 100644
--- a/Documentation/networking/timestamping/txtimestamp.c
+++ b/Documentation/networking/timestamping/txtimestamp.c
@@ -46,6 +46,7 @@
#include <netpacket/packet.h>
#include <poll.h>
#include <stdarg.h>
+#include <stdbool.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
@@ -58,6 +59,14 @@
#include <time.h>
#include <unistd.h>
+/* ugly hack to work around netinet/in.h and linux/ipv6.h conflicts */
+#ifndef in6_pktinfo
+struct in6_pktinfo {
+ struct in6_addr ipi6_addr;
+ int ipi6_ifindex;
+};
+#endif
+
/* command line parameters */
static int cfg_proto = SOCK_STREAM;
static int cfg_ipproto = IPPROTO_TCP;
@@ -65,6 +74,8 @@ static int cfg_num_pkts = 4;
static int do_ipv4 = 1;
static int do_ipv6 = 1;
static int cfg_payload_len = 10;
+static bool cfg_show_payload;
+static bool cfg_do_pktinfo;
static uint16_t dest_port = 9000;
static struct sockaddr_in daddr;
@@ -131,6 +142,30 @@ static void print_timestamp(struct scm_timestamping *tss, int tstype,
__print_timestamp(tsname, &tss->ts[0], tskey, payload_len);
}
+/* TODO: convert to check_and_print payload once API is stable */
+static void print_payload(char *data, int len)
+{
+ int i;
+
+ if (len > 70)
+ len = 70;
+
+ fprintf(stderr, "payload: ");
+ for (i = 0; i < len; i++)
+ fprintf(stderr, "%02hhx ", data[i]);
+ fprintf(stderr, "\n");
+}
+
+static void print_pktinfo(int family, int ifindex, void *saddr, void *daddr)
+{
+ char sa[INET6_ADDRSTRLEN], da[INET6_ADDRSTRLEN];
+
+ fprintf(stderr, " pktinfo: ifindex=%u src=%s dst=%s\n",
+ ifindex,
+ saddr ? inet_ntop(family, saddr, sa, sizeof(sa)) : "unknown",
+ daddr ? inet_ntop(family, daddr, da, sizeof(da)) : "unknown");
+}
+
static void __poll(int fd)
{
struct pollfd pollfd;
@@ -156,10 +191,9 @@ static void __recv_errmsg_cmsg(struct msghdr *msg, int payload_len)
cm->cmsg_type == SCM_TIMESTAMPING) {
tss = (void *) CMSG_DATA(cm);
} else if ((cm->cmsg_level == SOL_IP &&
- cm->cmsg_type == IP_RECVERR) ||
- (cm->cmsg_level == SOL_IPV6 &&
- cm->cmsg_type == IPV6_RECVERR)) {
-
+ cm->cmsg_type == IP_RECVERR) ||
+ (cm->cmsg_level == SOL_IPV6 &&
+ cm->cmsg_type == IPV6_RECVERR)) {
serr = (void *) CMSG_DATA(cm);
if (serr->ee_errno != ENOMSG ||
serr->ee_origin != SO_EE_ORIGIN_TIMESTAMPING) {
@@ -168,6 +202,16 @@ static void __recv_errmsg_cmsg(struct msghdr *msg, int payload_len)
serr->ee_origin);
serr = NULL;
}
+ } else if (cm->cmsg_level == SOL_IP &&
+ cm->cmsg_type == IP_PKTINFO) {
+ struct in_pktinfo *info = (void *) CMSG_DATA(cm);
+ print_pktinfo(AF_INET, info->ipi_ifindex,
+ &info->ipi_spec_dst, &info->ipi_addr);
+ } else if (cm->cmsg_level == SOL_IPV6 &&
+ cm->cmsg_type == IPV6_PKTINFO) {
+ struct in6_pktinfo *info6 = (void *) CMSG_DATA(cm);
+ print_pktinfo(AF_INET6, info6->ipi6_ifindex,
+ NULL, &info6->ipi6_addr);
} else
fprintf(stderr, "unknown cmsg %d,%d\n",
cm->cmsg_level, cm->cmsg_type);
@@ -206,7 +250,11 @@ static int recv_errmsg(int fd)
if (ret == -1 && errno != EAGAIN)
error(1, errno, "recvmsg");
- __recv_errmsg_cmsg(&msg, ret);
+ if (ret > 0) {
+ __recv_errmsg_cmsg(&msg, ret);
+ if (cfg_show_payload)
+ print_payload(data, cfg_payload_len);
+ }
free(data);
return ret == -1;
@@ -215,9 +263,9 @@ static int recv_errmsg(int fd)
static void do_test(int family, unsigned int opt)
{
char *buf;
- int fd, i, val, total_len;
+ int fd, i, val = 1, total_len;
- if (family == IPPROTO_IPV6 && cfg_proto != SOCK_STREAM) {
+ if (family == AF_INET6 && cfg_proto != SOCK_STREAM) {
/* due to lack of checksum generation code */
fprintf(stderr, "test: skipping datagram over IPv6\n");
return;
@@ -239,7 +287,6 @@ static void do_test(int family, unsigned int opt)
error(1, errno, "socket");
if (cfg_proto == SOCK_STREAM) {
- val = 1;
if (setsockopt(fd, IPPROTO_TCP, TCP_NODELAY,
(char*) &val, sizeof(val)))
error(1, 0, "setsockopt no nagle");
@@ -253,7 +300,20 @@ static void do_test(int family, unsigned int opt)
}
}
+ if (cfg_do_pktinfo) {
+ if (family == AF_INET6) {
+ if (setsockopt(fd, SOL_IPV6, IPV6_RECVPKTINFO,
+ &val, sizeof(val)))
+ error(1, errno, "setsockopt pktinfo ipv6");
+ } else {
+ if (setsockopt(fd, SOL_IP, IP_PKTINFO,
+ &val, sizeof(val)))
+ error(1, errno, "setsockopt pktinfo ipv4");
+ }
+ }
+
opt |= SOF_TIMESTAMPING_SOFTWARE |
+ SOF_TIMESTAMPING_OPT_CMSG |
SOF_TIMESTAMPING_OPT_ID;
if (setsockopt(fd, SOL_SOCKET, SO_TIMESTAMPING,
(char *) &opt, sizeof(opt)))
@@ -262,8 +322,6 @@ static void do_test(int family, unsigned int opt)
for (i = 0; i < cfg_num_pkts; i++) {
memset(&ts_prev, 0, sizeof(ts_prev));
memset(buf, 'a' + i, total_len);
- buf[total_len - 2] = '\n';
- buf[total_len - 1] = '\0';
if (cfg_proto == SOCK_RAW) {
struct udphdr *udph;
@@ -324,11 +382,13 @@ static void __attribute__((noreturn)) usage(const char *filepath)
" -4: only IPv4\n"
" -6: only IPv6\n"
" -h: show this message\n"
+ " -I: request PKTINFO\n"
" -l N: send N bytes at a time\n"
" -r: use raw\n"
" -R: use raw (IP_HDRINCL)\n"
" -p N: connect to port N\n"
- " -u: use udp\n",
+ " -u: use udp\n"
+ " -x: show payload (up to 70 bytes)\n",
filepath);
exit(1);
}
@@ -338,7 +398,7 @@ static void parse_opt(int argc, char **argv)
int proto_count = 0;
char c;
- while ((c = getopt(argc, argv, "46hl:p:rRu")) != -1) {
+ while ((c = getopt(argc, argv, "46hIl:p:rRux")) != -1) {
switch (c) {
case '4':
do_ipv6 = 0;
@@ -346,6 +406,9 @@ static void parse_opt(int argc, char **argv)
case '6':
do_ipv4 = 0;
break;
+ case 'I':
+ cfg_do_pktinfo = true;
+ break;
case 'r':
proto_count++;
cfg_proto = SOCK_RAW;
@@ -367,6 +430,9 @@ static void parse_opt(int argc, char **argv)
case 'p':
dest_port = strtoul(optarg, NULL, 10);
break;
+ case 'x':
+ cfg_show_payload = true;
+ break;
case 'h':
default:
usage(argv[0]);
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* Re: [PATCH] ioc3: fix incorrect use of htons/ntohs
From: Ben Hutchings @ 2014-12-01 4:09 UTC (permalink / raw)
To: Lino Sanfilippo; +Cc: ralf, linux-mips, netdev, linux-kernel
In-Reply-To: <1417344054-4374-1-git-send-email-LinoSanfilippo@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 2826 bytes --]
On Sun, 2014-11-30 at 11:40 +0100, Lino Sanfilippo wrote:
> The protocol type in the ip header struct is a single byte variable. So there
> is no need to swap bytes depending on host endianness.
>
> Signed-off-by: Lino Sanfilippo <LinoSanfilippo@gmx.de>
> ---
>
> Please note that I could not test this, since I dont have access to the
> concerning hardware.
>
> drivers/net/ethernet/sgi/ioc3-eth.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/sgi/ioc3-eth.c b/drivers/net/ethernet/sgi/ioc3-eth.c
> index 7a254da..0bb303d 100644
> --- a/drivers/net/ethernet/sgi/ioc3-eth.c
> +++ b/drivers/net/ethernet/sgi/ioc3-eth.c
> @@ -540,8 +540,7 @@ static void ioc3_tcpudp_checksum(struct sk_buff *skb, uint32_t hwsum, int len)
>
> /* Same as tx - compute csum of pseudo header */
> csum = hwsum +
> - (ih->tot_len - (ih->ihl << 2)) +
> - htons((uint16_t)ih->protocol) +
> + (ih->tot_len - (ih->ihl << 2)) + ih->protocol +
> (ih->saddr >> 16) + (ih->saddr & 0xffff) +
> (ih->daddr >> 16) + (ih->daddr & 0xffff);
>
The pseudo-header is specified as:
+--------+--------+--------+--------+
| Source Address |
+--------+--------+--------+--------+
| Destination Address |
+--------+--------+--------+--------+
| zero | PTCL | TCP Length |
+--------+--------+--------+--------+
The current code zero-extends the protocol number to produce the 5th
16-bit word of the pseudo-header, then uses htons() to put it in
big-endian order, consistent with the other fields. (Yes, it's doing
addition on big-endian words; this works even on little-endian machines
due to the way the checksum is specified.)
The driver should not be doing this at all, though. It should set
skb->csum = hwsum; skb->ip_summed = CHECKSUM_COMPLETE; and let the
network stack adjust the hardware checksum.
> @@ -1417,7 +1416,7 @@ static int ioc3_start_xmit(struct sk_buff *skb, struct net_device *dev)
> */
> if (skb->ip_summed == CHECKSUM_PARTIAL) {
> const struct iphdr *ih = ip_hdr(skb);
> - const int proto = ntohs(ih->protocol);
> + const int proto = ih->protocol;
> unsigned int csoff;
> uint32_t csum, ehsum;
> uint16_t *eh;
This should logically be __be16 proto = htons(ih->protocol), but the
current version should work in practice.
However, the driver should really use skb->csum_start and
skb->csum_offset to work out where the checksum belongs and which bytes
to cancel out.
Ben.
--
Ben Hutchings
The first rule of tautology club is the first rule of tautology club.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: [PATCH v7 28/46] vhost: make features 64 bit
From: Ben Hutchings @ 2014-12-01 4:12 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: thuth, kvm, Michael S. Tsirkin, rusty, netdev, linux-kernel,
virtualization, dahi, pbonzini, David Miller
In-Reply-To: <547B3B61.3090801@cogentembedded.com>
[-- Attachment #1.1: Type: text/plain, Size: 1369 bytes --]
On Sun, 2014-11-30 at 18:44 +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 11/30/2014 6:11 PM, Michael S. Tsirkin wrote:
>
> > We need to use bit 32 for virtio 1.0
>
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > Reviewed-by: Jason Wang <jasowang@redhat.com>
> > ---
> > drivers/vhost/vhost.h | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
>
> > diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
> > index 3eda654..c624b09 100644
> > --- a/drivers/vhost/vhost.h
> > +++ b/drivers/vhost/vhost.h
> > @@ -106,7 +106,7 @@ struct vhost_virtqueue {
> > /* Protected by virtqueue mutex. */
> > struct vhost_memory *memory;
> > void *private_data;
> > - unsigned acked_features;
> > + u64 acked_features;
> > /* Log write descriptors */
> > void __user *log_base;
> > struct vhost_log *log;
> > @@ -174,6 +174,6 @@ enum {
> >
> > static inline int vhost_has_feature(struct vhost_virtqueue *vq, int bit)
> > {
> > - return vq->acked_features & (1 << bit);
> > + return vq->acked_features & (1ULL << bit);
>
> Erm, wouldn't the high word be just dropped when returning *int*? I think
> you need !!(vq->acked_features & (1ULL << bit)).
Or change the return type to bool.
Ben.
--
Ben Hutchings
The first rule of tautology club is the first rule of tautology club.
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Charity Work
From: luv2charitys @ 2014-12-01 4:38 UTC (permalink / raw)
To: netdev
Hello,this is Mr Paul N,i sent you an email on charity work but i am yet to hear fom you,do reply with this code CHA-2015 to my email address paulcharity@qq.com i Look forward to hearing from you this time,God bless Brother Paul
^ permalink raw reply
* Re: [PATCH] e1000: remove unused variables
From: Sudip Mukherjee @ 2014-12-01 4:54 UTC (permalink / raw)
To: Ben Hutchings
Cc: Linux NICS, e1000-devel, Bruce Allan, Jesse Brandeburg,
linux-kernel, John Ronciak, netdev
In-Reply-To: <1417311913.7215.111.camel@decadent.org.uk>
On Sun, Nov 30, 2014 at 01:45:13AM +0000, Ben Hutchings wrote:
> On Wed, 2014-11-26 at 21:59 -0800, Hisashi T Fujinaka wrote:
> > I'm pretty sure those double reads are there for a reason, so most of
> > this I'm going to have to check on Monday. We have a long holiday
> > weekend here in the US.
> [...]
>
> If there were double register reads being replaced with single register
> reads, I'd agree this was likely to introduce a regression. But all I
> see is var = er32(REG) being changed to er32(REG).
no, double register reads are not modified. only the unused variables are removed.
thanks
sudip
>
> Ben.
>
> --
> Ben Hutchings
> The world is coming to an end. Please log off.
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Enrico Mioso @ 2014-12-01 5:28 UTC (permalink / raw)
To: Kevin Zhu
Cc: Alex Strizhevsky, Eli Britstein, linux-usb@vger.kernel.org,
youtux@gmail.com, Midge Shaojun Tan, netdev@vger.kernel.org,
Bjørn Mork
In-Reply-To: <547BDCF5.8070705@audiocodes.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 5009 bytes --]
Sorry.
I am a visually impaired person - and use a braille display to read your
messages; can't have access to files that don't contain ascii-based content.
Sorry Kevin.
And thank you for everything. Don't worry about the lateness.
It was sunday.
On Mon, 1 Dec 2014, Kevin Zhu wrote:
==Date: Mon, 1 Dec 2014 04:14:10
==From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
==To: Enrico Mioso <mrkiko.rs@gmail.com>, Alex Strizhevsky <alexxst@gmail.com>
==Cc: Eli Britstein <Eli.Britstein@audiocodes.com>,
== "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
== "youtux@gmail.com" <youtux@gmail.com>,
== Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
== "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
== Bjørn Mork <bjorn@mork.no>
==Subject: Re: Is this 32-bit NCM?
==
==Hi Enrico,
==
==I think those packets are some interrupt status. Please check my capture by
==wireshark.
==
==[IMAGE]
==
==And this is a ping packet from window, which indicates it's an NCM packet.
==
==[IMAGE]
==
==Regards,
==Kevin
==On 11/30/2014 06:39 PM, Enrico Mioso wrote:
==
==My impression guys is that this is not cdc_ncm protocol.
==Look how many short packets you can see in there.
==Without any ncm signature.
==right?
==
==
==On Sun, 30 Nov 2014, Alex Strizhevsky wrote:
==
====Date: Sun, 30 Nov 2014 05:22:20
====From: Alex Strizhevsky <alexxst@gmail.com>
====To: Mrkiko Rs <mrkiko.rs@gmail.com>
====Cc: Eli Britstein <Eli.Britstein@audiocodes.com>, linux-usb@vger.kernel.or
==g,
==== "youtux@gmail.com" <youtux@gmail.com>,
==== Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
==== "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
==== Kevin Zhu <Mingying.Zhu@audiocodes.com>, Bjørn Mork <bjorn@mork.no>
====Subject: Re: Is this 32-bit NCM?
====
====
====Hi Enrico,
====
====Actually I have two dongles with different firmwares (23.128.00.00.00 &
====21.286.03.01.209).
====Probably have sent to you the USB capture with the first one.
====
====In fact we have to make work the second one, this dongle has relevant SW.
====
====On Nov 30, 2014 3:13 AM, "Enrico Mioso" <mrkiko.rs@gmail.com> wrote:
==== Hi guys.
==== Sorry for the late our but ... I was trying to figure out
==== something new about
==== this dongle.
==== I also searched for it in my city shops without finding it
==== actually.
==== But then I came back and ... tried to look at some things.
====
==== Alex, Kevin: in the Windows USB captures you sent me (and that I
==== sent on the
==== List), I can notiche something very strange.
==== with a shell on a computer connected to a test device I can see
==== the following:
==== at+gmr
==== 21.286.03.01.209
==== OK
==== and so why in the Windows sniff the dongle answers to the same
==== question
==== something like
==== 23.128.00.00.00
==== ?
==== Alex - was it the same dongle?
==== Kevin or anyone: can you use putty to interact with the dongle
==== under Windows
==== and type some commands, like:
==== at+gmr
==== and other similar commands?
==== If the dongle reports different firmware versions under Linux
==== and Windows, then
==== guys... we need to figure out the Windows switch message.
==== Overmore - in the device installation sh*t, you can see there is
==== a firmware
==== updater... Why?
====
==== Alex: I used the
==== at^reset
==== command to get the modem back to normal state once; and so it
==== restored the
==== nvram to default or something.
==== If you reconnect it to windows ... i hope it gets re-setup as
==== before.
==== But - nothing harmful to the device, only to it's settings,
==== sorry.
==== I restored the relevant settings and it connects again, but no
==== dhcp. But - be
==== peaceful: other modems out there seems to not get dhcp anyway.
==== this is the state the modem arrives when you buy it, so windows
==== should know
==== Wwhat To Say To The Modem (TM).
==== Another thing - note that:
==== [14170.048693] cdc_ncm 1-2:1.2: GET_MAX_DATAGRAM_SIZE failed
====
==== Any ideas, comments, suggestions are highly appreciated guys.
==== Of any type.
====
==== Bjorn - unfortunately it seems this problem is related to E3727
==== and E3276
==== sticks; they can get IP from DHCP but not go ahead.
====
====
====
==
==
==This email and any files transmitted with it are confidential material. They
==are intended solely for the use of the designated individual or entity to
==whom they are addressed. If the reader of this message is not the intended
==recipient, you are hereby notified that any dissemination, use, distribution
==or copying of this communication is strictly prohibited and may be unlawful.
==
==If you have received this email in error please immediately notify the
==sender and delete or destroy any copy of this message
==
^ permalink raw reply
* Re: tun issue after e0b46d0ee9c: tun: Use iovec iterators
From: Jason Wang @ 2014-12-01 5:33 UTC (permalink / raw)
To: Herbert Xu; +Cc: Marcelo Ricardo Leitner, netdev
In-Reply-To: <20141130100331.GA10050@gondor.apana.org.au>
On Sun, Nov 30, 2014 at 6:03 PM, Herbert Xu
<herbert@gondor.apana.org.au> wrote:
> On Sat, Nov 29, 2014 at 07:59:35AM +0800, Herbert Xu wrote:
>> On Fri, Nov 28, 2014 at 05:25:27PM -0200, Marcelo Ricardo Leitner
>> wrote:
>> >
>> > I saw there are tun updates on Dave's queue but none seemed to
>> handle this.
>> >
>> > I can't use current net-next
>> > (799d2fff1858004526ad75d66a5dd8a5cce6ad40) on a kvm hypervisor
>> > because tun got clogged somehow. Bisected down to:
>> >
>> > commit e0b46d0ee9c240c7430a47e9b0365674d4a04522
>> > Author: Herbert Xu <herbert@gondor.apana.org.au>
>> > Date: Fri Nov 7 21:22:23 2014 +0800
>>
>> Does this patch help?
>
> Oops, there was an embarrassing typo in the patch which causes
> it to not even build. Here is the corrected version.
>
> -- >8 --
> Subject: tun: Fix GSO meta-data handling in tun_get_user
>
> When we write the GSO meta-data in tun_get_user we end up advancing
> the IO vector twice, thus exhausting the user buffer before we can
> finish writing the packet.
>
> Fixes: f5ff53b4d97c ("{macvtap,tun}_get_user(): switch to iov_iter")
> Reported-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index 4b743c6..6d44da1 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -1052,7 +1052,7 @@ static ssize_t tun_get_user(struct tun_struct
> *tun, struct tun_file *tfile,
>
> if (gso.hdr_len > len)
> return -EINVAL;
> - iov_iter_advance(from, tun->vnet_hdr_sz);
> + iov_iter_advance(from, tun->vnet_hdr_sz - sizeof(gso));
> }
>
> if ((tun->flags & TUN_TYPE_MASK) == TUN_TAP_DEV) {
>
Acked-by: Jason Wang <jasowang@redhat.com>
^ permalink raw reply
* Re: [PATCH net-next] vhost: remove unnecessary forward declarations in vhost.h
From: Jason Wang @ 2014-12-01 5:34 UTC (permalink / raw)
To: David Miller, Michael S. Tsirkin
Cc: netdev, linux-kernel, kvm, virtualization
In-Reply-To: <20141129.210422.2298555198780052887.davem@davemloft.net>
On Sun, Nov 30, 2014 at 1:04 PM, David Miller <davem@davemloft.net>
wrote:
> From: Jason Wang <jasowang@redhat.com>
> Date: Thu, 27 Nov 2014 14:41:21 +0800
>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>
> I don't think generic vhost patches should go via my tree.
>
> If you disagree, let me know why, thanks :)
Agree. Michael, could you pls pick this into vhost tree?
^ permalink raw reply
* Re: [PATCH net-next V3] tun/macvtap: use consume_skb() instead of kfree_skb() when needed
From: Jason Wang @ 2014-12-01 5:35 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel, mst, eric.dumazet
In-Reply-To: <20141129.210350.1994537005887744173.davem@davemloft.net>
On Sun, Nov 30, 2014 at 1:03 PM, David Miller <davem@davemloft.net>
wrote:
> From: Jason Wang <jasowang@redhat.com>
> Date: Thu, 27 Nov 2014 14:36:06 +0800
>
>> To be more friendly with drop monitor, we should only call
>> kfree_skb() when
>> the packets were dropped and use consume_skb() in other cases.
>>
>> Cc: Eric Dumazet <eric.dumazet@gmail.com>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>> ---
>> Changes from V2:
>> - use unlikely() when necessary
>> Changes from V1:
>> - check the return value of tun/macvtap_put_user()
>
> This does not apply cleanly to net-next and will thus need to
> be respun, thanks.
Will post V3.
Thanks
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Kevin Zhu @ 2014-12-01 5:51 UTC (permalink / raw)
To: Enrico Mioso
Cc: Alex Strizhevsky, Eli Britstein, linux-usb@vger.kernel.org,
youtux@gmail.com, Midge Shaojun Tan, netdev@vger.kernel.org,
Bjørn Mork
In-Reply-To: <alpine.LNX.2.03.1412010626590.1576@gmail.com>
I'm sorry.
According to the wireshark capture, those packets without NCM signature
are probably some periodical status checking interrupts. And some other
packets in the same capture do show the NCM signature. Those packets are
ping packets.
Regarding the offset and alignment definition, the specification says as
below:
Alignment requirements are met by controlling the location of the
payload (the data following the Ether-
net header in each datagram). This alignment is specified by indicating
a constraint as a divisor and a
remainder. The agent formatting a given NTB aligns the payload of each
datagram by inserting padding,
such that the offset of each datagram satisfies the constraint:
Offset % wNdpInDivisor == wNdpInPayloadRemainder (for IN datagrams)
Or
Offset % wNdpOutDivisor == wNdpOutPayloadRemainder (for OUT datagrams)
Regards,
Kevin
On 12/01/2014 01:28 PM, Enrico Mioso wrote:
> Sorry.
> I am a visually impaired person - and use a braille display to read your
> messages; can't have access to files that don't contain ascii-based content.
> Sorry Kevin.
>
> And thank you for everything. Don't worry about the lateness.
> It was sunday.
>
>
> On Mon, 1 Dec 2014, Kevin Zhu wrote:
>
> ==Date: Mon, 1 Dec 2014 04:14:10
> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
> ==To: Enrico Mioso <mrkiko.rs@gmail.com>, Alex Strizhevsky <alexxst@gmail.com>
> ==Cc: Eli Britstein <Eli.Britstein@audiocodes.com>,
> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
> == "youtux@gmail.com" <youtux@gmail.com>,
> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
> == "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
> == Bjørn Mork <bjorn@mork.no>
> ==Subject: Re: Is this 32-bit NCM?
> ==
> ==Hi Enrico,
> ==
> ==I think those packets are some interrupt status. Please check my capture by
> ==wireshark.
> ==
> ==[IMAGE]
> ==
> ==And this is a ping packet from window, which indicates it's an NCM packet.
> ==
> ==[IMAGE]
> ==
> ==Regards,
> ==Kevin
> ==On 11/30/2014 06:39 PM, Enrico Mioso wrote:
> ==
> ==My impression guys is that this is not cdc_ncm protocol.
> ==Look how many short packets you can see in there.
> ==Without any ncm signature.
> ==right?
> ==
> ==
> ==On Sun, 30 Nov 2014, Alex Strizhevsky wrote:
> ==
> ====Date: Sun, 30 Nov 2014 05:22:20
> ====From: Alex Strizhevsky <alexxst@gmail.com>
> ====To: Mrkiko Rs <mrkiko.rs@gmail.com>
> ====Cc: Eli Britstein <Eli.Britstein@audiocodes.com>, linux-usb@vger.kernel.or
> ==g,
> ==== "youtux@gmail.com" <youtux@gmail.com>,
> ==== Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
> ==== "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
> ==== Kevin Zhu <Mingying.Zhu@audiocodes.com>, Bjørn Mork <bjorn@mork.no>
> ====Subject: Re: Is this 32-bit NCM?
> ====
> ====
> ====Hi Enrico,
> ====
> ====Actually I have two dongles with different firmwares (23.128.00.00.00 &
> ====21.286.03.01.209).
> ====Probably have sent to you the USB capture with the first one.
> ====
> ====In fact we have to make work the second one, this dongle has relevant SW.
> ====
> ====On Nov 30, 2014 3:13 AM, "Enrico Mioso" <mrkiko.rs@gmail.com> wrote:
> ==== Hi guys.
> ==== Sorry for the late our but ... I was trying to figure out
> ==== something new about
> ==== this dongle.
> ==== I also searched for it in my city shops without finding it
> ==== actually.
> ==== But then I came back and ... tried to look at some things.
> ====
> ==== Alex, Kevin: in the Windows USB captures you sent me (and that I
> ==== sent on the
> ==== List), I can notiche something very strange.
> ==== with a shell on a computer connected to a test device I can see
> ==== the following:
> ==== at+gmr
> ==== 21.286.03.01.209
> ==== OK
> ==== and so why in the Windows sniff the dongle answers to the same
> ==== question
> ==== something like
> ==== 23.128.00.00.00
> ==== ?
> ==== Alex - was it the same dongle?
> ==== Kevin or anyone: can you use putty to interact with the dongle
> ==== under Windows
> ==== and type some commands, like:
> ==== at+gmr
> ==== and other similar commands?
> ==== If the dongle reports different firmware versions under Linux
> ==== and Windows, then
> ==== guys... we need to figure out the Windows switch message.
> ==== Overmore - in the device installation sh*t, you can see there is
> ==== a firmware
> ==== updater... Why?
> ====
> ==== Alex: I used the
> ==== at^reset
> ==== command to get the modem back to normal state once; and so it
> ==== restored the
> ==== nvram to default or something.
> ==== If you reconnect it to windows ... i hope it gets re-setup as
> ==== before.
> ==== But - nothing harmful to the device, only to it's settings,
> ==== sorry.
> ==== I restored the relevant settings and it connects again, but no
> ==== dhcp. But - be
> ==== peaceful: other modems out there seems to not get dhcp anyway.
> ==== this is the state the modem arrives when you buy it, so windows
> ==== should know
> ==== Wwhat To Say To The Modem (TM).
> ==== Another thing - note that:
> ==== [14170.048693] cdc_ncm 1-2:1.2: GET_MAX_DATAGRAM_SIZE failed
> ====
> ==== Any ideas, comments, suggestions are highly appreciated guys.
> ==== Of any type.
> ====
> ==== Bjorn - unfortunately it seems this problem is related to E3727
> ==== and E3276
> ==== sticks; they can get IP from DHCP but not go ahead.
> ====
> ====
> ====
> ==
> ==
> ==This email and any files transmitted with it are confidential material. They
> ==are intended solely for the use of the designated individual or entity to
> ==whom they are addressed. If the reader of this message is not the intended
> ==recipient, you are hereby notified that any dissemination, use, distribution
> ==or copying of this communication is strictly prohibited and may be unlawful.
> ==
> ==If you have received this email in error please immediately notify the
> ==sender and delete or destroy any copy of this message
> ==
This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message
^ permalink raw reply
* RE: [PATCH net] gso: do GSO for local skb with size bigger than MTU
From: Du, Fan @ 2014-12-01 6:47 UTC (permalink / raw)
To: Florian Westphal; +Cc: netdev@vger.kernel.org, davem@davemloft.net, Du, Fan
In-Reply-To: <20141130151114.GA4462@breakpoint.cc>
>-----Original Message-----
>From: Florian Westphal [mailto:fw@strlen.de]
>Sent: Sunday, November 30, 2014 11:11 PM
>To: Du, Fan
>Cc: Florian Westphal; netdev@vger.kernel.org; davem@davemloft.net
>Subject: Re: [PATCH net] gso: do GSO for local skb with size bigger than MTU
>
>Du, Fan <fan.du@intel.com> wrote:
>> All interface MTU in the test scenario is the default one, 1500.
>
>Not really, unless I misunderstand the setup.
>
>You have a l2 network where part of the machines are connected by a
>l2 tunnel.
>
>All machines within that network ought to assume that MTU is equal for all
>machines within the same L2 network.
Based on what assumption do you think the test scenario use different MTU???
I think all your conclusion comes from the MTU configuration, as a matter of fact,
Like I stated before, ALL interface MTU is default 1500.
I elaborate this typical(!kludges) env a bit more:
Without vxlan tunnel, a typical standard env:
Guest -> Qemu/VirtIO -> tap0 -> linux bridge -> NIC
No tunneling trick here, no MTU change, packets come packets go, naked...
With vxlan tunnel, almost all the same topology as before, really no need to change any MTU
To make below env work.
Guest -> Qemu/VirtIO -> tap0 -> ovs bridge -> vxlan tunnel -> NIC
^^^^^^^^
^^^^^^^^
Encapsulation outer L234/VXLAN clothes before Guest frame,
Over-MTU-sized packet is locally created as *default* when Guest first attempts to try a big MSS *BEFORE* PMTU
is able to make guest sense this MSS is too big. Guest what, this over-MTU-sized packet is lost. That's the problem,
not because any different MTU configuration, but the code here rule out(based on what fact???) any such existing possibility
Anyway, setup such env is quite easy to see what's really going on inside the stack. You could even use docker to give a try.
It's the same effect as KVM guest, but easy to deploy.
Docker instance -> docker0 bridge -> vethA -> vethB -> ovs-br0 -> vxlan -> NIC
Any doubts about the env, please let me know.
>> >It seems to me to only clean solution is to set tap0 MTU so that it
>> >accounts for the bridge encap overhead.
>>
>> This will force _ALL_ deploy instances requiring tap0 MTU change in every cloud
>env.
>
>Yes, alternatively emply routing, then PMTU should work.
>
>> Current behavior leads over-mtu-sized packet push down to NIC, which
>> should not happen anyway. And as I putted in another threads:
>> Perform GSO for skb, then try to do ip segmentation if possible, If DF
>> set, send back ICMP message. If DF is not set, apparently user want
>> stack do ip segmentation, and All the GSO-ed skb will be sent out correctly as
>expected.
>
>Well, the linux bridge implementation (especially bridge netfilter) did/allows for a
>lot of layering violations and this has usually caused a myriad of followup kludges
>to make one-more scenario work.
>
>I still think that trying to make this work is a bad idea.
>If hosts have different MTUs they should be in different l2 networks.
>
>Alternatively, the Tunneling implementation should be opaque and do the needed
>fragmentation to provide the illusion of identical MTUs.
>
>That said, I don't see anything wrong with the patch per se, I just dislike the
>concept.
^ permalink raw reply
* [PATCH net] openvswitch: Fix flow mask validation.
From: Pravin B Shelar @ 2014-12-01 7:04 UTC (permalink / raw)
To: davem; +Cc: netdev, Pravin B Shelar
Following patch fixes typo in the flow validation. This prevented
installation of ARP and IPv6 flows.
Fixes: 19e7a3df72 ("openvswitch: Fix NDP flow mask validation")
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
---
net/openvswitch/flow_netlink.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
index 089b195..918e966 100644
--- a/net/openvswitch/flow_netlink.c
+++ b/net/openvswitch/flow_netlink.c
@@ -145,7 +145,7 @@ static bool match_validate(const struct sw_flow_match *match,
if (match->key->eth.type == htons(ETH_P_ARP)
|| match->key->eth.type == htons(ETH_P_RARP)) {
key_expected |= 1 << OVS_KEY_ATTR_ARP;
- if (match->mask && (match->mask->key.tp.src == htons(0xff)))
+ if (match->mask && (match->mask->key.eth.type == htons(0xffff)))
mask_allowed |= 1 << OVS_KEY_ATTR_ARP;
}
@@ -220,7 +220,7 @@ static bool match_validate(const struct sw_flow_match *match,
htons(NDISC_NEIGHBOUR_SOLICITATION) ||
match->key->tp.src == htons(NDISC_NEIGHBOUR_ADVERTISEMENT)) {
key_expected |= 1 << OVS_KEY_ATTR_ND;
- if (match->mask && (match->mask->key.tp.src == htons(0xffff)))
+ if (match->mask && (match->mask->key.tp.src == htons(0xff)))
mask_allowed |= 1 << OVS_KEY_ATTR_ND;
}
}
--
1.7.1
^ permalink raw reply related
* linux-next: manual merge of the driver-core tree with the net-next tree
From: Stephen Rothwell @ 2014-12-01 7:19 UTC (permalink / raw)
To: Greg KH, John W. Linville, David Miller, netdev
Cc: linux-next, linux-kernel, Arend van Spriel, Felix Fietkau,
Ben Greear
[-- Attachment #1: Type: text/plain, Size: 5787 bytes --]
Hi Greg,
Today's linux-next merge of the driver-core tree got a conflict in
drivers/net/wireless/ath/ath9k/debug.c between commits 70e535ed0029
("ath9k: clean up debugfs print of reset causes"), 7b8aaead958e
("ath9k: restart hardware after noise floor calibration failure") and
325e18817668 ("ath9k: fix misc debugfs when not using chan context")
from the net-next tree and commit 631bee257bd5 ("ath: use seq_file api
for ath9k debugfs files") from the driver-core tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
Greg, I am not sure why those 2 commits are even in your tree. Do they
depend on something else in your tree?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/net/wireless/ath/ath9k/debug.c
index 696e3d5309c6,a1f1614a05c2..000000000000
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@@ -832,57 -731,42 +731,46 @@@ static int read_file_misc(struct seq_fi
continue;
ath9k_calculate_iter_data(sc, ctx, &iter_data);
- len += scnprintf(buf + len, sizeof(buf) - len,
- "VIFS: CTX %i(%i) AP: %i STA: %i MESH: %i WDS: %i",
- i++, (int)(ctx->assigned), iter_data.naps,
- iter_data.nstations,
- iter_data.nmeshes, iter_data.nwds);
- len += scnprintf(buf + len, sizeof(buf) - len,
- " ADHOC: %i TOTAL: %hi BEACON-VIF: %hi\n",
- iter_data.nadhocs, sc->cur_chan->nvifs, sc->nbcnvifs);
+ seq_printf(file,
- "VIF-COUNTS: CTX %i AP: %i STA: %i MESH: %i WDS: %i",
- i++, iter_data.naps, iter_data.nstations,
++ "VIFS: CTX %i(%i) AP: %i STA: %i MESH: %i WDS: %i",
++ i++, (int)(ctx->assigned), iter_data.naps,
++ iter_data.nstations,
+ iter_data.nmeshes, iter_data.nwds);
+ seq_printf(file, " ADHOC: %i TOTAL: %hi BEACON-VIF: %hi\n",
+ iter_data.nadhocs, sc->cur_chan->nvifs,
+ sc->nbcnvifs);
}
- if (len > sizeof(buf))
- len = sizeof(buf);
-
- retval = simple_read_from_buffer(user_buf, count, ppos, buf, len);
- return retval;
+ return 0;
}
- static ssize_t read_file_reset(struct file *file, char __user *user_buf,
- size_t count, loff_t *ppos)
+ static int read_file_reset(struct seq_file *file, void *data)
{
- struct ath_softc *sc = file->private_data;
+ struct ath_softc *sc = dev_get_drvdata(file->private);
+ static const char * const reset_cause[__RESET_TYPE_MAX] = {
+ [RESET_TYPE_BB_HANG] = "Baseband Hang",
+ [RESET_TYPE_BB_WATCHDOG] = "Baseband Watchdog",
+ [RESET_TYPE_FATAL_INT] = "Fatal HW Error",
+ [RESET_TYPE_TX_ERROR] = "TX HW error",
+ [RESET_TYPE_TX_GTT] = "Transmit timeout",
+ [RESET_TYPE_TX_HANG] = "TX Path Hang",
+ [RESET_TYPE_PLL_HANG] = "PLL RX Hang",
+ [RESET_TYPE_MAC_HANG] = "MAC Hang",
+ [RESET_TYPE_BEACON_STUCK] = "Stuck Beacon",
+ [RESET_TYPE_MCI] = "MCI Reset",
+ [RESET_TYPE_CALIBRATION] = "Calibration error",
+ };
- char buf[512];
- unsigned int len = 0;
+ int i;
- seq_printf(file, "%17s: %2d\n", "Baseband Hang",
- sc->debug.stats.reset[RESET_TYPE_BB_HANG]);
- seq_printf(file, "%17s: %2d\n", "Baseband Watchdog",
- sc->debug.stats.reset[RESET_TYPE_BB_WATCHDOG]);
- seq_printf(file, "%17s: %2d\n", "Fatal HW Error",
- sc->debug.stats.reset[RESET_TYPE_FATAL_INT]);
- seq_printf(file, "%17s: %2d\n", "TX HW error",
- sc->debug.stats.reset[RESET_TYPE_TX_ERROR]);
- seq_printf(file, "%17s: %2d\n", "TX Path Hang",
- sc->debug.stats.reset[RESET_TYPE_TX_HANG]);
- seq_printf(file, "%17s: %2d\n", "PLL RX Hang",
- sc->debug.stats.reset[RESET_TYPE_PLL_HANG]);
- seq_printf(file, "%17s: %2d\n", "MAC Hang",
- sc->debug.stats.reset[RESET_TYPE_MAC_HANG]);
- seq_printf(file, "%17s: %2d\n", "Stuck Beacon",
- sc->debug.stats.reset[RESET_TYPE_BEACON_STUCK]);
- seq_printf(file, "%17s: %2d\n", "MCI Reset",
- sc->debug.stats.reset[RESET_TYPE_MCI]);
+ for (i = 0; i < ARRAY_SIZE(reset_cause); i++) {
+ if (!reset_cause[i])
+ continue;
+
- len += scnprintf(buf + len, sizeof(buf) - len,
- "%17s: %2d\n", reset_cause[i],
- sc->debug.stats.reset[i]);
++ seq_printf(file, "%17s: %2d\n", reset_cause[i],
++ sc->debug.stats.reset[i]);
+ }
- if (len > sizeof(buf))
- len = sizeof(buf);
-
- return simple_read_from_buffer(user_buf, count, ppos, buf, len);
+ return 0;
}
void ath_debug_stat_tx(struct ath_softc *sc, struct ath_buf *bf,
@@@ -1331,16 -1175,16 +1179,16 @@@ int ath9k_init_debug(struct ath_hw *ah
ath9k_dfs_init_debug(sc);
ath9k_tx99_init_debug(sc);
- ath9k_spectral_init_debug(sc);
+ ath9k_cmn_spectral_init_debug(&sc->spec_priv, sc->debug.debugfs_phy);
- debugfs_create_file("dma", S_IRUSR, sc->debug.debugfs_phy, sc,
- &fops_dma);
- debugfs_create_file("interrupt", S_IRUSR, sc->debug.debugfs_phy, sc,
- &fops_interrupt);
- debugfs_create_file("xmit", S_IRUSR, sc->debug.debugfs_phy, sc,
- &fops_xmit);
- debugfs_create_file("queues", S_IRUSR, sc->debug.debugfs_phy, sc,
- &fops_queues);
+ debugfs_create_devm_seqfile(sc->dev, "dma", sc->debug.debugfs_phy,
+ read_file_dma);
+ debugfs_create_devm_seqfile(sc->dev, "interrupt", sc->debug.debugfs_phy,
+ read_file_interrupt);
+ debugfs_create_devm_seqfile(sc->dev, "xmit", sc->debug.debugfs_phy,
+ read_file_xmit);
+ debugfs_create_devm_seqfile(sc->dev, "queues", sc->debug.debugfs_phy,
+ read_file_queues);
debugfs_create_u32("qlen_bk", S_IRUSR | S_IWUSR, sc->debug.debugfs_phy,
&sc->tx.txq_max_pending[IEEE80211_AC_BK]);
debugfs_create_u32("qlen_be", S_IRUSR | S_IWUSR, sc->debug.debugfs_phy,
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ 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