* Re: [PATCH] ipv6: Fix Makefile offload objects
From: Vlad Yasevich @ 2012-12-17 15:40 UTC (permalink / raw)
To: Simon Arlott; +Cc: David Miller, Linux Kernel Mailing List, netdev
In-Reply-To: <50CDFB36.1020604@simon.arlott.org.uk>
On 12/16/2012 11:47 AM, Simon Arlott wrote:
> The following commit breaks IPv6 TCP transmission for me:
> Commit 75fe83c32248d99e6d5fe64155e519b78bb90481
> Author: Vlad Yasevich <vyasevic@redhat.com>
> Date: Fri Nov 16 09:41:21 2012 +0000
> ipv6: Preserve ipv6 functionality needed by NET
>
> This patch fixes the typo "ipv6_offload" which should be
> "ipv6-offload".
>
> I don't know why not including the offload modules should
> break TCP. Disabling all offload options on the NIC didn't
> help. Outgoing pulseaudio traffic kept stalling.
Did you restart your application to restart the socket?\
The trouble is that whe GSO is turned on, we try to perform
it on output. If the output path can't find the gso handler
for the protocol (in your case tcp over IPv6), it drops the
packet. This causes tcp to retransmit eventually withough GSO.
If you were in a VM, GSO is always used even though you might
disable it on the interface with ethtool. The only way I've been
able to disable it when using virtio driver is by passing gso=0
parameter to the module.
-vlad
>
> Signed-off-by: Simon Arlott <simon@fire.lp0.eu>
> ---
> net/ipv6/Makefile | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/ipv6/Makefile b/net/ipv6/Makefile
> index 2068ac4..4ea2448 100644
> --- a/net/ipv6/Makefile
> +++ b/net/ipv6/Makefile
> @@ -41,6 +41,6 @@ obj-$(CONFIG_IPV6_TUNNEL) += ip6_tunnel.o
> obj-$(CONFIG_IPV6_GRE) += ip6_gre.o
>
> obj-y += addrconf_core.o exthdrs_core.o
> -obj-$(CONFIG_INET) += output_core.o protocol.o $(ipv6_offload)
> +obj-$(CONFIG_INET) += output_core.o protocol.o $(ipv6-offload)
>
> obj-$(subst m,y,$(CONFIG_IPV6)) += inet6_hashtables.o
>
^ permalink raw reply
* [PATCH] atm: use scnprintf() instead of sprintf()
From: chas williams - CONTRACTOR @ 2012-12-17 16:00 UTC (permalink / raw)
To: davem; +Cc: netdev, Chen Gang
As reported by Chen Gang <gang.chen@asianux.com>, we should ensure there
is enough space when formatting the sysfs buffers.
Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil>
---
net/atm/atm_sysfs.c | 40 +++++++++++++++-------------------------
1 files changed, 15 insertions(+), 25 deletions(-)
diff --git a/net/atm/atm_sysfs.c b/net/atm/atm_sysfs.c
index f49da58..350bf62 100644
--- a/net/atm/atm_sysfs.c
+++ b/net/atm/atm_sysfs.c
@@ -14,49 +14,45 @@ static ssize_t show_type(struct device *cdev,
struct device_attribute *attr, char *buf)
{
struct atm_dev *adev = to_atm_dev(cdev);
- return sprintf(buf, "%s\n", adev->type);
+
+ return scnprintf(buf, PAGE_SIZE, "%s\n", adev->type);
}
static ssize_t show_address(struct device *cdev,
struct device_attribute *attr, char *buf)
{
- char *pos = buf;
struct atm_dev *adev = to_atm_dev(cdev);
- int i;
-
- for (i = 0; i < (ESI_LEN - 1); i++)
- pos += sprintf(pos, "%02x:", adev->esi[i]);
- pos += sprintf(pos, "%02x\n", adev->esi[i]);
- return pos - buf;
+ return scnprintf(buf, PAGE_SIZE, "%pM\n", adev->esi);
}
static ssize_t show_atmaddress(struct device *cdev,
struct device_attribute *attr, char *buf)
{
unsigned long flags;
- char *pos = buf;
struct atm_dev *adev = to_atm_dev(cdev);
struct atm_dev_addr *aaddr;
int bin[] = { 1, 2, 10, 6, 1 }, *fmt = bin;
- int i, j;
+ int i, j, count = 0;
spin_lock_irqsave(&adev->lock, flags);
list_for_each_entry(aaddr, &adev->local, entry) {
for (i = 0, j = 0; i < ATM_ESA_LEN; ++i, ++j) {
if (j == *fmt) {
- pos += sprintf(pos, ".");
+ count += scnprintf(buf + count,
+ PAGE_SIZE - count, ".");
++fmt;
j = 0;
}
- pos += sprintf(pos, "%02x",
- aaddr->addr.sas_addr.prv[i]);
+ count += scnprintf(buf + count,
+ PAGE_SIZE - count, "%02x",
+ aaddr->addr.sas_addr.prv[i]);
}
- pos += sprintf(pos, "\n");
+ count += scnprintf(buf + count, PAGE_SIZE - count, "\n");
}
spin_unlock_irqrestore(&adev->lock, flags);
- return pos - buf;
+ return count;
}
static ssize_t show_atmindex(struct device *cdev,
@@ -64,25 +60,21 @@ static ssize_t show_atmindex(struct device *cdev,
{
struct atm_dev *adev = to_atm_dev(cdev);
- return sprintf(buf, "%d\n", adev->number);
+ return scnprintf(buf, PAGE_SIZE, "%d\n", adev->number);
}
static ssize_t show_carrier(struct device *cdev,
struct device_attribute *attr, char *buf)
{
- char *pos = buf;
struct atm_dev *adev = to_atm_dev(cdev);
- pos += sprintf(pos, "%d\n",
- adev->signal == ATM_PHY_SIG_LOST ? 0 : 1);
-
- return pos - buf;
+ return scnprintf(buf, PAGE_SIZE, "%d\n",
+ adev->signal == ATM_PHY_SIG_LOST ? 0 : 1);
}
static ssize_t show_link_rate(struct device *cdev,
struct device_attribute *attr, char *buf)
{
- char *pos = buf;
struct atm_dev *adev = to_atm_dev(cdev);
int link_rate;
@@ -100,9 +92,7 @@ static ssize_t show_link_rate(struct device *cdev,
default:
link_rate = adev->link_rate * 8 * 53;
}
- pos += sprintf(pos, "%d\n", link_rate);
-
- return pos - buf;
+ return scnprintf(buf, PAGE_SIZE, "%d\n", link_rate);
}
static DEVICE_ATTR(address, S_IRUGO, show_address, NULL);
--
1.7.7.6
^ permalink raw reply related
* Re: [PATCH iproute2 6/6] ip/link_iptnl: fix indentation
From: Stephen Hemminger @ 2012-12-17 16:10 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev
In-Reply-To: <50CEDB8A.40303@6wind.com>
On Mon, 17 Dec 2012 09:44:58 +0100
Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
> Le 14/12/2012 19:02, Stephen Hemminger a écrit :
> > On Thu, 13 Dec 2012 14:42:54 +0100
> > Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
> >
> >> Use tabs instead of space when possible.
> >>
> >> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> >
> > Thanks applied all these.
> >
> Two patches are missing in your tree:
> 1/6 ip: update man pages and usage() for 'ip monitor'
> 2/6 ip: add man pages for netconf
>
> Should I resend them?
yes, probably got lost in the merge day.
^ permalink raw reply
* Re: RFC [PATCH] iproute2: temporary solution to fix xt breakage
From: Stephen Hemminger @ 2012-12-17 16:12 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Hasan Chowdhury, Jan Engelhardt, Yury Stankevich,
netdev@vger.kernel.org, pablo, netfilter-devel
In-Reply-To: <50CF1071.1050405@mojatatu.com>
On Mon, 17 Dec 2012 07:30:41 -0500
Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> On 12-12-16 03:41 PM, Jamal Hadi Salim wrote:
> >
> > There is an "intermediate solution" from Hasan which doesnt require
> > the kernel change. It changes the kernel endpoint to "ipt". I am
> > conflicted because it is a quick hack while otoh forcing people to
> > upgrade kernel is a usability issue.
> >
>
>
> Attached. Author is Hasan - I didnt sign it because i am looking for
> feedback and i find it distasteful but it solves the problem.
> This is needed until we have a proper fix in the kernel propagated.
> Once that kernel change is ubiquitous this change is noise and a
> maintanance pain. I am making it hard to even turn it on
> (i.e someone knowledgeable will have to compile with CONFIG_XT_HACK)
>
> cheers,
> jamal
>
>
Maybe xtables should have stable API/ABI and use shim routines there?
^ permalink raw reply
* Re: [PATCH] add a `make dist` helper
From: Stephen Hemminger @ 2012-12-17 16:13 UTC (permalink / raw)
To: Mike Frysinger; +Cc: Stephen Hemminger, netdev
In-Reply-To: <201212161657.15449.vapier@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 609 bytes --]
On Sun, 16 Dec 2012 16:57:14 -0500
Mike Frysinger <vapier@gentoo.org> wrote:
> On Friday 14 December 2012 12:09:35 Stephen Hemminger wrote:
> > On Thu, 13 Dec 2012 23:16:10 -0800 Stephen Hemminger wrote:
> > > I appreciate the effort but there are a number of more steps to doing a
> > > release and I need to script them all together.
>
> np
>
> > The tarball's have been rebased, and I built a iproute2-release script for
> > next time.
>
> commit it to the tree ? :)
> -mike
It has to many things that are unique to kernel.org and the package.
Plus at this time it only works for me
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] ip: add the type 'vxlan' in the output of "ip link help"
From: Stephen Hemminger @ 2012-12-17 16:16 UTC (permalink / raw)
To: zwu.kernel; +Cc: netdev, linux-kernel, Zhi Yong Wu
In-Reply-To: <1355588468-4964-1-git-send-email-zwu.kernel@gmail.com>
On Sun, 16 Dec 2012 00:21:08 +0800
zwu.kernel@gmail.com wrote:
> From: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
>
> The new type 'vxlan' is added in the output of "ip link help"
>
> Signed-off-by: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
> ---
> ip/iplink.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/ip/iplink.c b/ip/iplink.c
> index d73c705..5ff8f85 100644
> --- a/ip/iplink.c
> +++ b/ip/iplink.c
> @@ -84,7 +84,7 @@ void iplink_usage(void)
> if (iplink_have_newlink()) {
> fprintf(stderr, "\n");
> fprintf(stderr, "TYPE := { vlan | veth | vcan | dummy | ifb | macvlan | can |\n");
> - fprintf(stderr, " bridge | ipoib | ip6tnl | ipip | sit }\n");
> + fprintf(stderr, " bridge | ipoib | ip6tnl | ipip | sit | vxlan }\n");
> }
> exit(-1);
> }
Applied
^ permalink raw reply
* [PATCH lksctp-tools] sctp_send: fix msg_control data corruption
From: Daniel Borkmann @ 2012-12-17 16:32 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: netdev, lksctp-developers, Daniel Borkmann
The byte array outcmsg is allocated on the stack within the if-block
that test for a valif sctp_sndrcvinfo structure. There, it is assigned
to outmsg.msg_control, which is later on after leaving the if-block
passed to sendmsg. With this minimal example, the following is
happening:
int main(void)
{
int fd;
struct sctp_sndrcvinfo sndinfo;
fd = socket(AF_INET, SOCK_SEQPACKET, IPPROTO_SCTP);
assert(fd > 0);
sctp_send(fd, "bla", strlen("bla") + 1, &sndinfo, 0);
return 0;
}
strace ./a.out before this patch:
sendmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"bla\0", 4}],
msg_controllen=48, {cmsg_len=3364590592, cmsg_level=0x4003e8
/* SOL_??? */, cmsg_type=, ...}, msg_flags=0}, 0)
--> cmsg_len corrupted
strace ./a.out after this patch:
sendmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"bla\0", 4}],
msg_controllen=48, {cmsg_len=48, cmsg_level=0x84 /* SOL_??? */,
cmsg_type=, ...}, msg_flags=0}, 0)
This is basically the case since 2005, introduced in the commit 91239acf
("Add sctp_send() API support and testcases"). However, probably this
changed due to a different compiler behaviour / optimization (?), since
it was not visible / affected by older Linux versions.
Cc: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
---
src/lib/sendmsg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/lib/sendmsg.c b/src/lib/sendmsg.c
index 1de592d..9046174 100644
--- a/src/lib/sendmsg.c
+++ b/src/lib/sendmsg.c
@@ -76,6 +76,7 @@ sctp_send(int s, const void *msg, size_t len,
{
struct msghdr outmsg;
struct iovec iov;
+ char outcmsg[CMSG_SPACE(sizeof(struct sctp_sndrcvinfo))];
outmsg.msg_name = NULL;
outmsg.msg_namelen = 0;
@@ -86,7 +87,6 @@ sctp_send(int s, const void *msg, size_t len,
outmsg.msg_controllen = 0;
if (sinfo) {
- char outcmsg[CMSG_SPACE(sizeof(struct sctp_sndrcvinfo))];
struct cmsghdr *cmsg;
outmsg.msg_control = outcmsg;
--
1.7.11.7
^ permalink raw reply related
* [RESEND PATCH iproute2 2/2] ip: update man pages and usage() for 'ip monitor'
From: Nicolas Dichtel @ 2012-12-17 16:41 UTC (permalink / raw)
To: shemminger; +Cc: netdev, Nicolas Dichtel
In-Reply-To: <1355762487-4082-1-git-send-email-nicolas.dichtel@6wind.com>
Sync with the current code.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
ip/ipmonitor.c | 5 ++++-
man/man8/ip-monitor.8 | 15 +++++++++------
2 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/ip/ipmonitor.c b/ip/ipmonitor.c
index 09a339c..a9ff1e8 100644
--- a/ip/ipmonitor.c
+++ b/ip/ipmonitor.c
@@ -29,7 +29,10 @@ int prefix_banner;
static void usage(void)
{
- fprintf(stderr, "Usage: ip monitor [ all | LISTofOBJECTS ]\n");
+ fprintf(stderr, "Usage: ip monitor [ all | LISTofOBJECTS ] [ FILE ]\n");
+ fprintf(stderr, "LISTofOBJECTS := link | address | route | mroute | prefix |\n");
+ fprintf(stderr, " neigh | netconf\n");
+ fprintf(stderr, "FILE := file FILENAME\n");
exit(-1);
}
diff --git a/man/man8/ip-monitor.8 b/man/man8/ip-monitor.8
index 351a744..b07cb0e 100644
--- a/man/man8/ip-monitor.8
+++ b/man/man8/ip-monitor.8
@@ -1,4 +1,4 @@
-.TH IP\-MONITOR 8 "20 Dec 2011" "iproute2" "Linux"
+.TH IP\-MONITOR 8 "13 Dec 2012" "iproute2" "Linux"
.SH "NAME"
ip-monitor, rtmon \- state monitoring
.SH "SYNOPSIS"
@@ -6,8 +6,8 @@ ip-monitor, rtmon \- state monitoring
.ad l
.in +8
.ti -8
-.BR "ip monitor" " [ " all " |"
-.IR LISTofOBJECTS " ]"
+.BR "ip " " [ ip-OPTIONS ] " "monitor" " [ " all " |"
+.IR LISTofOBJECTS " ] [ file " FILENAME " ]
.sp
.SH DESCRIPTION
@@ -20,12 +20,13 @@ Namely, the
command is the first in the command line and then the object list follows:
.BR "ip monitor" " [ " all " |"
-.IR LISTofOBJECTS " ]"
+.IR LISTofOBJECTS " ] [ file " FILENAME " ]
.I OBJECT-LIST
is the list of object types that we want to monitor.
It may contain
-.BR link ", " address " and " route "."
+.BR link ", " address ", " route ", " mroute ", " prefix ", "
+.BR neigh " and " netconf "."
If no
.B file
argument is given,
@@ -34,7 +35,9 @@ opens RTNETLINK, listens on it and dumps state changes in the format
described in previous sections.
.P
-If a file name is given, it does not listen on RTNETLINK,
+If a
+.I FILENAME
+is given, it does not listen on RTNETLINK,
but opens the file containing RTNETLINK messages saved in binary format
and dumps them. Such a history file can be generated with the
.B rtmon
--
1.8.0.1
^ permalink raw reply related
* [RESEND PATCH iproute2 1/2] ip: add man pages for netconf
From: Nicolas Dichtel @ 2012-12-17 16:41 UTC (permalink / raw)
To: shemminger; +Cc: netdev, Nicolas Dichtel
In-Reply-To: <20121217081026.5acd58a4@nehalam.linuxnetplumber.net>
This patch add the documentation about 'ip netconf' command.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
man/man8/Makefile | 2 +-
man/man8/ip-netconf.8 | 36 ++++++++++++++++++++++++++++++++++++
2 files changed, 37 insertions(+), 1 deletion(-)
create mode 100644 man/man8/ip-netconf.8
diff --git a/man/man8/Makefile b/man/man8/Makefile
index 4bad9d6..d208f3b 100644
--- a/man/man8/Makefile
+++ b/man/man8/Makefile
@@ -9,7 +9,7 @@ MAN8PAGES = $(TARGETS) ip.8 arpd.8 lnstat.8 routel.8 rtacct.8 rtmon.8 ss.8 \
ip-addrlabel.8 ip-l2tp.8 \
ip-maddress.8 ip-monitor.8 ip-mroute.8 ip-neighbour.8 \
ip-netns.8 ip-ntable.8 ip-rule.8 ip-tunnel.8 ip-xfrm.8 \
- ip-tcp_metrics.8
+ ip-tcp_metrics.8 ip-netconf.8
all: $(TARGETS)
diff --git a/man/man8/ip-netconf.8 b/man/man8/ip-netconf.8
new file mode 100644
index 0000000..8041ea2
--- /dev/null
+++ b/man/man8/ip-netconf.8
@@ -0,0 +1,36 @@
+.TH IP\-NETCONF 8 "13 Dec 2012" "iproute2" "Linux"
+.SH "NAME"
+ip-netconf \- network configuration monitoring
+.SH "SYNOPSIS"
+.sp
+.ad l
+.in +8
+.ti -8
+.BR "ip " " [ ip-OPTIONS ] " "netconf show" " [ "
+.B dev
+.IR STRING " ]"
+
+.SH DESCRIPTION
+The
+.B ip netconf
+utility can monitor IPv4 and IPv6 parameters (see
+.BR "/proc/sys/net/ipv[4|6]/conf/[all|DEV]/" ")"
+like forwarding, rp_filter
+or mc_forwarding status.
+
+If no interface is specified, the entry
+.B all
+is displayed.
+
+.SS ip netconf show - display network parameters
+
+.TP
+.BI dev " STRING"
+the name of the device to display network parameters.
+
+.SH SEE ALSO
+.br
+.BR ip (8)
+
+.SH AUTHOR
+Original Manpage by Nicolas Dichtel <nicolas.dichtel@6wind.com>
--
1.8.0.1
^ permalink raw reply related
* Re: [RESEND PATCH iproute2 2/2] ip: update man pages and usage() for 'ip monitor'
From: Stephen Hemminger @ 2012-12-17 16:48 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: netdev
In-Reply-To: <1355762487-4082-2-git-send-email-nicolas.dichtel@6wind.com>
On Mon, 17 Dec 2012 17:41:27 +0100
Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
> Sync with the current code.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Ok applied
^ permalink raw reply
* Re: [PATCH] netlink: align attributes on 64-bits
From: Nicolas Dichtel @ 2012-12-17 16:53 UTC (permalink / raw)
To: David Laight; +Cc: tgraf, netdev, davem
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B70F0@saturn3.aculab.com>
Le 17/12/2012 10:59, David Laight a écrit :
>> - if (unlikely(skb_tailroom(skb) < nla_total_size(attrlen)))
>> + int align = IS_ALIGNED((unsigned long)skb_tail_pointer(skb), sizeof(void *)) ? 0 : 4;
>> +
>> + if (unlikely(skb_tailroom(skb) < nla_total_size(attrlen) + align))
>> return -EMSGSIZE;
>>
>> + if (align) {
>> + /* Goal is to add an attribute with size 4. We know that
>> + * NLA_HDRLEN is 4, hence payload is 0.
>> + */
>> + __nla_reserve(skb, 0, 0);
>> + }
>> +
>
> Shouldn't the size of the dummy parameter be based on the value
> of 'align' - and that be based on the amount of padding needed?
>
Align is 4 or 0. Instead of the comment and 0, I can put 'NLA_HDRLEN - align',
which will always be 0, because we made this patch because we don't want to
change values like NLA_HDRLEN, because many user apps have these values
/structures hardcoded.
> That aligns the write pointer, what guarantees the alignment of
> the start of the buffer - so that the reader will find aligned data?
As Thomas said, skb->head will be aligned, am I wrong?
>
> What guarantees that the reader will read the data into an
> 8-byte aligned buffer.
>
> There is also the lurking issue of items that require more
> than 8-byte alignment.
> (x86/amd64 requires 16-byte alignment for 16-byte SSE2 regs and
> 32-byte alignment for the AVX regs.)
>
> Will anyone ever want to put such items into a netlink message?
>
> David
^ permalink raw reply
* [PATCH v2] netlink: align attributes on 64-bits
From: Nicolas Dichtel @ 2012-12-17 16:49 UTC (permalink / raw)
To: bhutchings; +Cc: tgraf, netdev, davem, David.Laight, Nicolas Dichtel
In-Reply-To: <1355500160.2626.9.camel@bwh-desktop.uk.solarflarecom.com>
We must ensure that attributes are always aligned on 64-bits boundary because
some arch may trap when accessing unaligned 64 bits value. We do that by adding
attributes of type 0, size 4 (alignment on 32-bits is already done) when needed.
Attribute type 0 should be available and unused in all netlink families.
Some callers of nlmsg_new() calculates the exact length of the attributes they
want to add to their netlink messages. Because we may add some unexpected
attributes type 0, we should take more room for that.
Note that I made the choice to align all kind of netlink attributes (even u8,
u16, ...) to simplify netlink API. Having two sort of nla_put() functions will
certainly be a source of wrong usage. Moreover, it ensures that all existing
code will be fine.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
v2: align attributes on all arch, not only on 64-bits arch
include/net/netlink.h | 9 +++++++++
lib/nlattr.c | 11 ++++++++++-
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/include/net/netlink.h b/include/net/netlink.h
index 9690b0f..bd9e48f 100644
--- a/include/net/netlink.h
+++ b/include/net/netlink.h
@@ -492,6 +492,15 @@ static inline struct nlmsghdr *nlmsg_put_answer(struct sk_buff *skb,
*/
static inline struct sk_buff *nlmsg_new(size_t payload, gfp_t flags)
{
+ /* Because attributes may be aligned on 64-bits boundary with fake
+ * attribute (type 0, size 4 (attributes are 32-bits align by default)),
+ * an exact payload size cannot be calculated. Hence, we need to reserve
+ * more space for these attributes.
+ * 128 is arbitrary: it allows to align up to 32 attributes.
+ */
+ if (payload < NLMSG_DEFAULT_SIZE)
+ payload = min(payload + 128, (size_t)NLMSG_DEFAULT_SIZE);
+
return alloc_skb(nlmsg_total_size(payload), flags);
}
diff --git a/lib/nlattr.c b/lib/nlattr.c
index 18eca78..7440a80 100644
--- a/lib/nlattr.c
+++ b/lib/nlattr.c
@@ -450,9 +450,18 @@ EXPORT_SYMBOL(__nla_put_nohdr);
*/
int nla_put(struct sk_buff *skb, int attrtype, int attrlen, const void *data)
{
- if (unlikely(skb_tailroom(skb) < nla_total_size(attrlen)))
+ int align = IS_ALIGNED((unsigned long)skb_tail_pointer(skb), 8) ? 0 : 4;
+
+ if (unlikely(skb_tailroom(skb) < nla_total_size(attrlen) + align))
return -EMSGSIZE;
+ if (align) {
+ /* Goal is to add an attribute with size 4. We know that
+ * NLA_HDRLEN is 4, hence payload is 0.
+ */
+ __nla_reserve(skb, 0, 0);
+ }
+
__nla_put(skb, attrtype, attrlen, data);
return 0;
}
--
1.8.0.1
^ permalink raw reply related
* RE: [PATCH v2] netlink: align attributes on 64-bits
From: David Laight @ 2012-12-17 17:06 UTC (permalink / raw)
To: Nicolas Dichtel, bhutchings; +Cc: tgraf, netdev, davem
In-Reply-To: <1355762980-4285-1-git-send-email-nicolas.dichtel@6wind.com>
> int nla_put(struct sk_buff *skb, int attrtype, int attrlen, const void *data)
> {
> - if (unlikely(skb_tailroom(skb) < nla_total_size(attrlen)))
> + int align = IS_ALIGNED((unsigned long)skb_tail_pointer(skb), 8) ? 0 : 4;
I've just realised where you are adding this!
You only want to add pad if the attribute is a single 64bit item,
not whenever the destination is misaligned.
Eg what happens if you add a 4-byte item after an 8 byte one.
Are there are attributes that consist of a pair of 4 byte values?
...
> + if (align) {
> + /* Goal is to add an attribute with size 4. We know that
> + * NLA_HDRLEN is 4, hence payload is 0.
> + */
> + __nla_reserve(skb, 0, 0);
One of those zeros should be 'align - 4', then the comment
can be more descriptive.
David
^ permalink raw reply
* Re: [PATCH 3/3] configure: pull AR from the env too
From: Stephen Hemminger @ 2012-12-17 17:14 UTC (permalink / raw)
To: Mike Frysinger; +Cc: stephen.hemminger, netdev, jengelh
In-Reply-To: <1355695757-9957-3-git-send-email-vapier@gentoo.org>
On Sun, 16 Dec 2012 17:09:17 -0500
Mike Frysinger <vapier@gentoo.org> wrote:
> This matches the existing CC behavior.
>
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
> ---
> configure | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/configure b/configure
> index ea1038d..7c2db9b 100755
> --- a/configure
> +++ b/configure
> @@ -10,7 +10,9 @@ trap 'status=$?; rm -rf $TMPDIR; exit $status' EXIT HUP INT QUIT TERM
> check_toolchain()
> {
> : ${PKG_CONFIG:=pkg-config}
> +: ${AR=ar}
> : ${CC=gcc}
> +echo "AR:=${AR}" >>Config
> echo "CC:=${CC}" >>Config
> echo "PKG_CONFIG:=${PKG_CONFIG}" >>Config
> }
All applied
^ permalink raw reply
* Re: [PATCH] bugfix: network namespace & device dummy
From: Vitaly E. Lavrov @ 2012-12-17 17:25 UTC (permalink / raw)
To: netdev
In-Reply-To: <50CF1797.803@guap.ru>
On 17.12.2012 17:01, V. Lavrov wrote:
> If container has a network device dummyX (with lxc.network.type =
> phys), then it disappears from the system after you close the container.
> The patch returns the device dummyX to the initial network namespace
> after container is closed.
Do not use this patch. Network devices such as "ifb" and "dummy" can
re-create command "ip li add ..."
This feature should be documented in the LXC
^ permalink raw reply
* Re: [PATCH v2] netlink: align attributes on 64-bits
From: Nicolas Dichtel @ 2012-12-17 17:35 UTC (permalink / raw)
To: David Laight; +Cc: bhutchings, tgraf, netdev, davem
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B70F1@saturn3.aculab.com>
Le 17/12/2012 18:06, David Laight a écrit :
>> int nla_put(struct sk_buff *skb, int attrtype, int attrlen, const void *data)
>> {
>> - if (unlikely(skb_tailroom(skb) < nla_total_size(attrlen)))
>> + int align = IS_ALIGNED((unsigned long)skb_tail_pointer(skb), 8) ? 0 : 4;
>
> I've just realised where you are adding this!
> You only want to add pad if the attribute is a single 64bit item,
> not whenever the destination is misaligned.
As said in the commit log, I want to align all attributes. An attribute can be
like this:
struct foo {
__u32 bar1;
__u32 bar2;
__u64 bar3;
}
nla_put() don't know what is contained in the attribute.
>
> Eg what happens if you add a 4-byte item after an 8 byte one.
>
> Are there are attributes that consist of a pair of 4 byte values?
>
> ...
>> + if (align) {
>> + /* Goal is to add an attribute with size 4. We know that
>> + * NLA_HDRLEN is 4, hence payload is 0.
>> + */
>> + __nla_reserve(skb, 0, 0);
>
> One of those zeros should be 'align - 4', then the comment
> can be more descriptive.
I thought if you were to research why we use 0, you would know that the first 0
is the type and the second is the payload size...
^ permalink raw reply
* 3.6.10 tcp crash - net/ipv4/tcp.c:1667 & tcp.c:1655
From: Benjamin LaHaise @ 2012-12-17 17:41 UTC (permalink / raw)
To: netdev
Hi folks,
I just hit the following crash with Fedora's 3.6.10-2.fc17 kernel. I don't
have time to debug this myself at the moment, but can certainly test patches
or provide more info as needed. I wasn't doing anything unusual at the time,
just reading email/web browsing. I believe the network driver in use was
ipheth for tethering to an iPhone 4S over USB (the other driver being used
intermittently on this laptop is iwlwifi). Any ideas?
-ben
--
"Thought is the essence of where you are now."
Dec 17 12:28:40 lappy kernel: [ 4044.846922] ------------[ cut here ]------------
Dec 17 12:28:40 lappy kernel: [ 4044.846931] WARNING: at net/ipv4/tcp.c:1667 tcp_recvmsg+0xc25/0xd80()
Dec 17 12:28:40 lappy kernel: [ 4044.846933] Hardware name: HP Pavilion dv7 Notebook PC
Dec 17 12:28:40 lappy kernel: [ 4044.846935] recvmsg bug 2: copied DE50E114 seq 90D65A21 rcvnxt DE50E114 fl 0
Dec 17 12:28:40 lappy kernel: [ 4044.846936] Modules linked in: fuse lockd sunrpc rfcomm bnep ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack btusb bluetooth snd_hda_codec_hdmi arc4 iwldvm ipheth mac80211 iTCO_wdt iTCO_vendor_support hp_wmi sparse_keymap uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev media coretemp microcode i7core_edac edac_core snd_hda_codec_idt i2c_i801 ir_lirc_codec lirc_dev ir_mce_kbd_decoder ir_sanyo_decoder iwlwifi snd_hda_intel ir_sony_decoder snd_hda_codec cfg80211 snd_hwdep jmb38x_ms snd_seq snd_seq_device ir_jvc_decoder lpc_ich memstick mfd_core ir_rc6_decoder snd_pcm r8169 mii rfkill ir_rc5_decoder ir_nec_decoder snd_page_alloc snd_timer snd soundcore vhost_net t
un macvtap macvlan rc_rc6_mce kvm ene_ir rc_core hp_accel lis3lv02d input_polldev uinput crc32c_intel sdhci_pci firewire_ohci sdhci firewire_core mmc_core crc_itu_t nouveau mxm_wmi wmi video i2c_algo_bit drm_kms_helper ttm drm
Dec 17 12:28:40 lappy kernel: i2c_core
Dec 17 12:28:40 lappy kernel: [ 4044.847025] Pid: 2080, comm: Socket Thread Tainted: G W 3.6.10-2.fc17.x86_64 #1
Dec 17 12:28:40 lappy kernel: [ 4044.847030] Call Trace:
Dec 17 12:28:40 lappy kernel: [ 4044.847035] [<ffffffff8105c8ef>] warn_slowpath_common+0x7f/0xc0
Dec 17 12:28:40 lappy kernel: [ 4044.847038] [<ffffffff8105c9e6>] warn_slowpath_fmt+0x46/0x50
Dec 17 12:28:40 lappy kernel: [ 4044.847040] [<ffffffff815576c5>] tcp_recvmsg+0xc25/0xd80
Dec 17 12:28:40 lappy kernel: [ 4044.847043] [<ffffffff8157cb1b>] inet_recvmsg+0x6b/0x80
Dec 17 12:28:40 lappy kernel: [ 4044.847047] [<ffffffff814fa707>] sock_recvmsg+0xd7/0x110
Dec 17 12:28:40 lappy kernel: [ 4044.847051] [<ffffffff811a2fd0>] ? __pollwait+0xf0/0xf0
Dec 17 12:28:40 lappy kernel: [ 4044.847053] [<ffffffff811a2fd0>] ? __pollwait+0xf0/0xf0
Dec 17 12:28:40 lappy kernel: [ 4044.847055] [<ffffffff814fc11f>] sys_recvfrom+0xef/0x170
Dec 17 12:28:40 lappy kernel: [ 4044.847058] [<ffffffff811a2fd0>] ? __pollwait+0xf0/0xf0
Dec 17 12:28:40 lappy kernel: [ 4044.847062] [<ffffffff810d868c>] ? __audit_syscall_entry+0xcc/0x300
Dec 17 12:28:40 lappy kernel: [ 4044.847064] [<ffffffff810d8cac>] ? __audit_syscall_exit+0x3ec/0x450
Dec 17 12:28:40 lappy kernel: [ 4044.847067] [<ffffffff816270e9>] system_call_fastpath+0x16/0x1b
Dec 17 12:28:40 lappy kernel: [ 4044.847068] ---[ end trace 28d4acf1e1aa598d ]---
Dec 17 12:28:40 lappy kernel: [ 4044.847069] ------------[ cut here ]------------
Dec 17 12:28:40 lappy kernel: [ 4044.847071] WARNING: at net/ipv4/tcp.c:1655 tcp_recvmsg+0x671/0xd80()
Dec 17 12:28:40 lappy kernel: [ 4044.847072] Hardware name: HP Pavilion dv7 Notebook PC
Dec 17 12:28:40 lappy kernel: [ 4044.847073] recvmsg bug: copied DE50E114 seq 0 rcvnxt DE50E114 fl 0
Dec 17 12:28:40 lappy kernel: [ 4044.847074] Modules linked in: fuse lockd sunrpc rfcomm bnep ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack btusb bluetooth snd_hda_codec_hdmi arc4 iwldvm ipheth mac80211 iTCO_wdt iTCO_vendor_support hp_wmi sparse_keymap uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev media coretemp microcode i7core_edac edac_core snd_hda_codec_idt i2c_i801 ir_lirc_codec lirc_dev ir_mce_kbd_decDec 17 12:29:32 lappy kernel: imklog 5.8.10, log source = /proc/kmsg started.
^ permalink raw reply
* [PATCH 1/2 v2] qmi_wwan/cdc_ether: add Dell Wireless 5800 (Novatel E362) USB IDs
From: Dan Williams @ 2012-12-17 18:17 UTC (permalink / raw)
To: Bjørn Mork; +Cc: Aleksander Morgado, netdev
Signed-off-by: Dan Williams <dcbw@redhat.com>
Cc: stable@vger.kernel.org
---
drivers/net/usb/cdc_ether.c | 15 +++++++++++++++
drivers/net/usb/qmi_wwan.c | 14 ++++++++++++++
2 files changed, 29 insertions(+)
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index d012982..c4c593d 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -487,6 +487,7 @@ static const struct driver_info wwan_info = {
#define HUAWEI_VENDOR_ID 0x12D1
#define NOVATEL_VENDOR_ID 0x1410
#define ZTE_VENDOR_ID 0x19D2
+#define DELL_VENDOR_ID 0x413C
static const struct usb_device_id products [] = {
/*
@@ -618,6 +619,20 @@ static const struct usb_device_id products [] = {
.driver_info = 0,
},
+/* Dell Wireless 5800 (Novatel E362) - handled by qmi_wwan */
+{
+ USB_DEVICE_AND_INTERFACE_INFO(DELL_VENDOR_ID, 0x8195, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
+ .driver_info = 0,
+},
+
+/* Dell Wireless 5800 (Novatel E362) - handled by qmi_wwan */
+{
+ USB_DEVICE_AND_INTERFACE_INFO(DELL_VENDOR_ID, 0x8196, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
+ .driver_info = 0,
+},
+
/*
* WHITELIST!!!
*
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 1ea91f4..9b950f5 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -383,6 +383,20 @@ static const struct usb_device_id products[] = {
USB_CDC_PROTO_NONE),
.driver_info = (unsigned long)&qmi_wwan_info,
},
+ { /* Dell Wireless 5800 (Novatel E362) */
+ USB_DEVICE_AND_INTERFACE_INFO(0x413C, 0x8195,
+ USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET,
+ USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long)&qmi_wwan_info,
+ },
+ { /* Dell Wireless 5800 V2 (Novatel E362) */
+ USB_DEVICE_AND_INTERFACE_INFO(0x413C, 0x8196,
+ USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET,
+ USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long)&qmi_wwan_info,
+ },
/* 3. Combined interface devices matching on interface number */
{QMI_FIXED_INTF(0x12d1, 0x140c, 1)}, /* Huawei E173 */
--
1.7.11.7
^ permalink raw reply related
* [PATCH 2/2 v2] cdc_ether: cleanup: use USB_DEVICE_AND_INTERFACE_INFO for Novatel 551/E362
From: Dan Williams @ 2012-12-17 18:19 UTC (permalink / raw)
To: Bjørn Mork; +Cc: Aleksander Morgado, netdev
In-Reply-To: <1355768261.1424.50.camel@dcbw.foobar.com>
Signed-off-by: Dan Williams <dcbw@redhat.com>
---
drivers/net/usb/cdc_ether.c | 20 ++++----------------
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index c4c593d..a74f35f 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -595,27 +595,15 @@ static const struct usb_device_id products [] = {
/* Novatel USB551L and MC551 - handled by qmi_wwan */
{
- .match_flags = USB_DEVICE_ID_MATCH_VENDOR
- | USB_DEVICE_ID_MATCH_PRODUCT
- | USB_DEVICE_ID_MATCH_INT_INFO,
- .idVendor = NOVATEL_VENDOR_ID,
- .idProduct = 0xB001,
- .bInterfaceClass = USB_CLASS_COMM,
- .bInterfaceSubClass = USB_CDC_SUBCLASS_ETHERNET,
- .bInterfaceProtocol = USB_CDC_PROTO_NONE,
+ USB_DEVICE_AND_INTERFACE_INFO(NOVATEL_VENDOR_ID, 0xB001, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
.driver_info = 0,
},
/* Novatel E362 - handled by qmi_wwan */
{
- .match_flags = USB_DEVICE_ID_MATCH_VENDOR
- | USB_DEVICE_ID_MATCH_PRODUCT
- | USB_DEVICE_ID_MATCH_INT_INFO,
- .idVendor = NOVATEL_VENDOR_ID,
- .idProduct = 0x9010,
- .bInterfaceClass = USB_CLASS_COMM,
- .bInterfaceSubClass = USB_CDC_SUBCLASS_ETHERNET,
- .bInterfaceProtocol = USB_CDC_PROTO_NONE,
+ USB_DEVICE_AND_INTERFACE_INFO(NOVATEL_VENDOR_ID, 0x9010, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
.driver_info = 0,
},
--
1.7.11.7
^ permalink raw reply related
* Re: 3.6.10: Intel: ixgbe 0000:01:00.0 eth4: Detected Tx Unit Hang
From: devendra.aaru @ 2012-12-17 18:38 UTC (permalink / raw)
To: Justin Piszcz; +Cc: linux-kernel, netdev
In-Reply-To: <004101cddadb$b890e910$29b2bb30$@lucidpixels.com>
Ccing netdev
On Sat, Dec 15, 2012 at 10:49 AM, Justin Piszcz <jpiszcz@lucidpixels.com> wrote:
> Hello,
>
> Kernel 3.6.10, first time I have seen this that I can remember (on 10GbE)
> anyway, is this a known issue with 3.6.10?
>
> When the link went down is when I rebooted/etc the remote host attached on
> the other end.
> I've not changed anything physically with the hardware and have been on
> 3.6.0-3.6.9 and noticed this when I moved to 3.6.10.
>
> [10270.229200] ixgbe 0000:01:00.0 eth4: NIC Link is Down
> [10276.124937] ixgbe 0000:01:00.0 eth4: NIC Link is Up 10 Gbps, Flow
> Control: RX/TX
> [24529.430997] ixgbe 0000:01:00.0 eth4: Detected Tx Unit Hang
> [24529.430997] Tx Queue <10>
> [24529.430997] TDH, TDT <4e>, <51>
> [24529.430997] next_to_use <51>
> [24529.430997] next_to_clean <4e>
> [24529.430997] tx_buffer_info[next_to_clean]
> [24529.430997] time_stamp <10172668f>
> [24529.430997] jiffies <101726ea4>
> [24529.431011] ixgbe 0000:01:00.0 eth4: tx hang 1 detected on queue 10,
> resetting adapter
> [24529.431028] ixgbe 0000:01:00.0 eth4: Reset adapter
>
> Thoughts?
>
> lspci -vvxx
>
> 01:00.0 Ethernet controller: Intel Corporation 82598EB 10-Gigabit AT2 Server
> Adapter (rev 01)
> Subsystem: Intel Corporation 82598EB 10-Gigabit AT2 Server Adapter
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
> <MAbort- >SERR- <PERR- INTx-
> Latency: 0, Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 26
> Region 0: Memory at fbe40000 (32-bit, non-prefetchable) [size=128K]
> Region 1: Memory at fbe00000 (32-bit, non-prefetchable) [size=256K]
> Region 2: I/O ports at e000 [size=32]
> Region 3: Memory at fbe60000 (32-bit, non-prefetchable) [size=16K]
> Capabilities: [40] Power Management version 3
> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
> PME(D0+,D1-,D2-,D3hot+,D3cold-)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
> Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
> Address: 0000000000000000 Data: 0000
> Capabilities: [60] MSI-X: Enable+ Count=18 Masked-
> Vector table: BAR=3 offset=00000000
> PBA: BAR=3 offset=00002000
> Capabilities: [a0] Express (v2) Endpoint, MSI 00
> DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
> ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
> DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
> RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
> MaxPayload 256 bytes, MaxReadReq 512 bytes
> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
> LnkCap: Port #0, Speed 2.5GT/s, Width x8, ASPM L0s L1, Latency L0 <4us,
> L1 <64us
> ClockPM- Surprise- LLActRep- BwNot-
> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> LnkSta: Speed 2.5GT/s, Width x8, TrErr- Train- SlotClk+ DLActive-
> BWMgmt- ABWMgmt-
> DevCap2: Completion Timeout: Range ABCD, TimeoutDis+
> DevCtl2: Completion Timeout: 16ms to 55ms, TimeoutDis-
> LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-,
> Selectable De-emphasis: -6dB
> Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
> ComplianceSOS-
> Compliance De-emphasis: -6dB
> LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-,
> EqualizationPhase1-
> EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
> Capabilities: [100 v1] Advanced Error Reporting
> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
> MalfTLP- ECRC- UnsupReq- ACSViol-
> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
> MalfTLP- ECRC- UnsupReq+ ACSViol-
> UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+
> MalfTLP+ ECRC- UnsupReq- ACSViol-
> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
> AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
> Capabilities: [140 v1] Device Serial Number XX-XX-XX-XX-XX-XX-XX-XX
> (masked)
> Kernel driver in use: ixgbe
> 00: 86 80 0b 15 07 04 10 00 01 00 00 02 10 00 00 00
> 10: 00 00 e4 fb 00 00 e0 fb 01 e0 00 00 00 00 e6 fb
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 2c a1
> 30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 01 00 00
>
> Justin.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH v2 03/44] Add CONFIG_HAVE_64BIT_ALIGNED_STRUCT for taskstats
From: David Miller @ 2012-12-17 19:11 UTC (permalink / raw)
To: james.hogan
Cc: geert, hpa, linux-arch, linux-kernel, arnd, bsingharora, mingo,
akpm, eparis, wad, james.l.morris, netdev
In-Reply-To: <50CEEB08.1080707@imgtec.com>
From: James Hogan <james.hogan@imgtec.com>
Date: Mon, 17 Dec 2012 09:51:04 +0000
> On 10/12/12 12:55, Geert Uytterhoeven wrote:
>> On Mon, Dec 10, 2012 at 11:22 AM, James Hogan <james.hogan@imgtec.com> wrote:
>>> On 08/12/12 03:43, H. Peter Anvin wrote:
>>>> On 12/05/2012 08:08 AM, James Hogan wrote:
>>>>> On 64 bit architectures with no efficient unaligned access, taskstats
>>>>> has to add some padding to a reply to prevent unaligned access warnings.
>>>>> However this also needs to apply to 32 bit architectures with 64 bit
>>>>> struct alignment such as metag (which has 64 bit memory accesses).
>>>>
>>>> Wait... 64-bit struct alignment on structures with only 32-bit members?
>>>> That might be... interesting... in a number of places...
>>>
>>> I'll rewrite the description as it's a bit misleading. On metag 64bit
>>> struct alignment is required when it contains 64bit members, not if it
>>> only contains 32bit members. Although metag is a 32bit arch, it can do
>>> 64bit memory accesses which must be aligned.
>>
>> The C alignment rules should take care of this automatically (struct alignment
>> is the maximum alignment of its members).
>
> Hi Geert,
>
> Please see the comment in mk_reply in kernel/taskstats.c. The structure
> is being serialised after 2 NLA headers and a pid which is why the extra
> padding needs to be added manually.
Please solve netlink attribute 64-bit alignment issues fundamentally
rather on a case-by-case basis.
We were just discussing this very issue on the netdev list recently,
CC:'d
^ permalink raw reply
* Re: [PATCH] bugfix: network namespace & device dummy
From: David Miller @ 2012-12-17 19:13 UTC (permalink / raw)
To: lve; +Cc: netdev
In-Reply-To: <50CF1797.803@guap.ru>
From: "V. Lavrov" <lve@guap.ru>
Date: Mon, 17 Dec 2012 17:01:11 +0400
> If container has a network device dummyX (with lxc.network.type =
> phys), then it disappears from the system after you close the
> container.
> The patch returns the device dummyX to the initial network namespace
> after container is closed.
>
> Signed-off-by: Vitaly Lavrov <lve@guap.ru>
This patch is mangled by your email client.
Do not submit any new patches until you can successfully email
them to yourself, then successfully apply the patch that you
receive in that email.
Because that is exactly what you are asking us to do.
^ permalink raw reply
* Re: 3.6.10 tcp crash - net/ipv4/tcp.c:1667 & tcp.c:1655
From: Eric Dumazet @ 2012-12-17 19:34 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: netdev
In-Reply-To: <20121217174145.GH22452@kvack.org>
On Mon, 2012-12-17 at 12:41 -0500, Benjamin LaHaise wrote:
> Hi folks,
>
> I just hit the following crash with Fedora's 3.6.10-2.fc17 kernel. I don't
> have time to debug this myself at the moment, but can certainly test patches
> or provide more info as needed. I wasn't doing anything unusual at the time,
> just reading email/web browsing. I believe the network driver in use was
> ipheth for tethering to an iPhone 4S over USB (the other driver being used
> intermittently on this laptop is iwlwifi). Any ideas?
I see nothing really wrong on ipheth side.
I would be nice to know which driver is really in use when you have a
panic, as its probably a driver issue.
^ permalink raw reply
* Re: [tcpdump-workers] vlan tagged packets and libpcap breakage
From: Ani Sinha @ 2012-12-17 19:49 UTC (permalink / raw)
To: Guy Harris
Cc: David Laight, Daniel Borkmann, netdev, Michael Richardson,
tcpdump-workers, Francesco Ruggeri
In-Reply-To: <DE6D5B28-FA1E-4F04-9BDF-F6D35878776E@alum.mit.edu>
On Mon, Dec 17, 2012 at 2:35 AM, Guy Harris <guy@alum.mit.edu> wrote:
>
> On Dec 17, 2012, at 1:50 AM, "David Laight" <David.Laight@ACULAB.COM> wrote:
>
>> How are you going to tell whether a feature is present in a non-Linux
>> kernel ?
>
> The Linux memory-mapped capture mechanism is not present in a non-Linux kernel, so all the libpcap work involved here would, if necessary on other platforms, have to be done >differently on those platforms. Those platforms would have to have their own mechanisms to indicate whether any changes to filter code, processing of VLAN tags supplied out of >band, etc. would need to be done.
Actually lib-pcap has these pcap-<platform>.c files that are kind of
like platform specific drivers that plug into platform independent
code like gencode.c or bpf_filter.c. These platform specific drivers
are responsible for getting packets from the kernel and running
filters (kernel or userland) on it. So all linux specific code to get
a packet and packet metadata from the kernel can neatly reside in
pcap-linux.c.
Unfortunately though, in this specific problem involving filtering
with vlan tags, both code generation (gentags.c) and code running the
filter (bpf_filter.c) will have to be aware of linux specific
semantics. Due to the issues that Bill had explained earlier in the
thread, we can not rely on post processing before installing the
kernel filter. Therefore, we need to generate a filter that can be
directly installed in the kernel. For the same reason, bpf_filter()
code also needs to change - be aware of linux specific semantics.
^ permalink raw reply
* Re: 3.6.10 tcp crash - net/ipv4/tcp.c:1667 & tcp.c:1655
From: Benjamin LaHaise @ 2012-12-17 19:52 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1355772853.9380.10.camel@edumazet-glaptop>
On Mon, Dec 17, 2012 at 11:34:13AM -0800, Eric Dumazet wrote:
> On Mon, 2012-12-17 at 12:41 -0500, Benjamin LaHaise wrote:
> > Hi folks,
> >
> > I just hit the following crash with Fedora's 3.6.10-2.fc17 kernel. I don't
> > have time to debug this myself at the moment, but can certainly test patches
> > or provide more info as needed. I wasn't doing anything unusual at the time,
> > just reading email/web browsing. I believe the network driver in use was
> > ipheth for tethering to an iPhone 4S over USB (the other driver being used
> > intermittently on this laptop is iwlwifi). Any ideas?
>
> I see nothing really wrong on ipheth side.
>
> I would be nice to know which driver is really in use when you have a
> panic, as its probably a driver issue.
I double checked the logs, and the wifi was disabled at the time (~30
minutes beforehand), so it had to be ipheth. The warnings were the last
thing that made it to disk before the machine hung hard, so there may have
been a more serious crash after the warning that did not get logged.
One thing I have observed with tethering is that the MTU handling is munged
by the network in interesting ways. Although the device claims to be
ethernet with a 1500 byte MTU, a 'ping -s' works only up to 996 (with no
effect trying the various -M options). A number of website are broken by
this, as the network doesn't seem to send ICMP frag needed errors to my
tethered host (but I haven't traced this behaviour from both ends yet).
Things do work for 1500 byte packets to the gateway IP, but that seems
to be local to the phone.
-ben
--
"Thought is the essence of where you are now."
^ 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