* Re: [RFC PATCH] xfrm: avoid to send/receive the exceeding hard lifetime data
From: RongQing Li @ 2012-12-14 6:58 UTC (permalink / raw)
To: Steffen Klassert; +Cc: netdev
In-Reply-To: <20121213101422.GF18940@secunet.com>
2012/12/13 Steffen Klassert <steffen.klassert@secunet.com>:
> On Thu, Dec 13, 2012 at 04:25:52PM +0800, roy.qing.li@gmail.com wrote:
>> From: Li RongQing <roy.qing.li@gmail.com>
>>
>> If setkey sets both bh and bs as 1024, and the total send and receive package
>> size is 1024, then if next package size is too large, this package should be
>> discard.
>>
>> Example, first package size is 1000, send success, then the second package
>> is 500, 1000+500 is larger than 1024, so the second package should be discard.
>>
>> Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
>> ---
>> net/xfrm/xfrm_input.c | 6 +++---
>> net/xfrm/xfrm_output.c | 6 +++---
>> 2 files changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
>> index ab2bb42..d0de8f3 100644
>> --- a/net/xfrm/xfrm_input.c
>> +++ b/net/xfrm/xfrm_input.c
>> @@ -178,6 +178,9 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
>> goto drop_unlock;
>> }
>>
>> + x->curlft.bytes += skb->len;
>> + x->curlft.packets++;
>> +
>
> This is a bit critical on input. We should only increment these values
> if the integrity check on this packet was successfull. Otherwise someone
> could spam us with invalid packets and trigger a state expiry.
>
> If a synchronous crypto algorithm is used, we send at most one packet too
> much. The maximal byte count was not yet reached and RFC 2401 says not
> much on how to handle the packet that reaches the maximal byte count,
> so this is probaply ok.
>
Yes, RFC does not say how to handle this packet.
But when I do a IPsec compliance test with IxANVL, the test case 5.3/5.11,
which reports a error because it expects this packet should be dropped, but not.
I do not know if it is bug, or if it is valuable to fix it?
-Li
> But if an asynchronous crypto algorithm is used, we can send a lot
> of packets too much. So we should probaply add a second expiry check
> after resume from asynchronous crypto. We do this already with the replay
> check.
>
^ permalink raw reply
* Re: [PATCH] xfrm: do not check x->km.state
From: RongQing Li @ 2012-12-14 7:02 UTC (permalink / raw)
To: David Miller; +Cc: steffen.klassert, netdev
In-Reply-To: <20121213.141922.2249665409902614569.davem@davemloft.net>
2012/12/14 David Miller <davem@davemloft.net>:
> From: Steffen Klassert <steffen.klassert@secunet.com>
> Date: Thu, 13 Dec 2012 11:19:48 +0100
>
>> On Thu, Dec 13, 2012 at 05:06:00PM +0800, roy.qing.li@gmail.com wrote:
>>> From: Li RongQing <roy.qing.li@gmail.com>
>>>
>>> do not check x->km.state, it will be checked by succedent
>>> xfrm_state_check_expire()
>>>
>>> Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
> ...
>> This would remove the only place where the LINUX_MIB_XFRMINSTATEINVALID
>> statistics counter is incremented. I think it would be better to ensure
>> a valid state before we call xfrm_state_check_expire(). This would make
>> the statistics more accurate and we can remove the x->km.state check
>> from xfrm_state_check_expire().
>
> Agreed.
Thanks.
since xfrm_output_one() calls xfrm_state_check_expire() too, but without
checking (x->km.state != XFRM_STATE_VALID), I think we can not directly
remove the check of km.state from xfrm_state_check_expire(). I have two
option, which one do you think it is better?
1. remove this check in xfrm_state_check_expire, and add a check in
xfrm_output_one
diff --git a/net/xfrm/xfrm_output.c b/net/xfrm/xfrm_output.c
index 95a338c..c245370 100644
--- a/net/xfrm/xfrm_output.c
+++ b/net/xfrm/xfrm_output.c
@@ -61,6 +61,12 @@ static int xfrm_output_one(struct sk_buff *skb, int err)
}
spin_lock_bh(&x->lock);
+
+ if (unlikely(x->km.state != XFRM_STATE_VALID)) {
+ XFRM_INC_STATS(net, LINUX_MIB_XFRMOUTSTATEINVALID);
+ goto drop_unlock;
+ }
+
err = xfrm_state_check_expire(x);
if (err) {
XFRM_INC_STATS(net, LINUX_MIB_XFRMOUTSTATEEXPIRED);
diff --git a/net/xfrm/xfrm_proc.c b/net/xfrm/xfrm_proc.c
index d0a1af8..e4cd441 100644
--- a/net/xfrm/xfrm_proc.c
+++ b/net/xfrm/xfrm_proc.c
@@ -39,6 +39,7 @@ static const struct snmp_mib xfrm_mib_list[] = {
SNMP_MIB_ITEM("XfrmOutStateModeError", LINUX_MIB_XFRMOUTSTATEMODEERROR),
SNMP_MIB_ITEM("XfrmOutStateSeqError", LINUX_MIB_XFRMOUTSTATESEQERROR),
SNMP_MIB_ITEM("XfrmOutStateExpired", LINUX_MIB_XFRMOUTSTATEEXPIRED),
+ SNMP_MIB_ITEM("XfrmOutStateInvalid", LINUX_MIB_XFRMOUTSTATEINVALID),
SNMP_MIB_ITEM("XfrmOutPolBlock", LINUX_MIB_XFRMOUTPOLBLOCK),
SNMP_MIB_ITEM("XfrmOutPolDead", LINUX_MIB_XFRMOUTPOLDEAD),
SNMP_MIB_ITEM("XfrmOutPolError", LINUX_MIB_XFRMOUTPOLERROR),
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 3459692..05db236 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -1370,9 +1370,6 @@ int xfrm_state_check_expire(struct xfrm_state *x)
if (!x->curlft.use_time)
x->curlft.use_time = get_seconds();
- if (x->km.state != XFRM_STATE_VALID)
- return -EINVAL;
-
if (x->curlft.bytes >= x->lft.hard_byte_limit ||
x->curlft.packets >= x->lft.hard_packet_limit) {
x->km.state = XFRM_STATE_EXPIRED;
2. Only remove this check in xfrm6_input.c
--- a/net/ipv6/xfrm6_input.c
+++ b/net/ipv6/xfrm6_input.c
@@ -109,7 +109,6 @@ int xfrm6_input_addr(struct sk_buff *skb,
xfrm_address_t *daddr,
if ((!i || (x->props.flags & XFRM_STATE_WILDRECV)) &&
- likely(x->km.state == XFRM_STATE_VALID) &&
!xfrm_state_check_expire(x)) {
spin_unlock(&x->lock);
if (x->type->input(x, skb) > 0) {
/* found a valid state */
^ permalink raw reply related
* Re: cpts: Fix build error caused by include of plat/clock.h
From: Richard Cochran @ 2012-12-14 7:13 UTC (permalink / raw)
To: Tony Lindgren; +Cc: David S. Miller, linux-arm-kernel, linux-omap, netdev
In-Reply-To: <20121213213641.GF4989@atomide.com>
On Thu, Dec 13, 2012 at 01:36:41PM -0800, Tony Lindgren wrote:
> Commit 87c0e764 (cpts: introduce time stamping code and a PTP hardware clock)
> mistakenly included plat/clock.h that should not be included by drivers
> even if it exists.
Hasn't this already been fixed?
https://patchwork.kernel.org/patch/1810481/
http://www.spinics.net/lists/linux-omap/msg83132.html
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH] add a `make dist` helper
From: Stephen Hemminger @ 2012-12-14 7:16 UTC (permalink / raw)
To: Mike Frysinger; +Cc: netdev
I appreciate the effort but there are a number of more steps to doing a release and I need to script them all together.
Mike Frysinger <vapier@gentoo.org> wrote:
>This makes sure the tarball is always created in the same way.
>Avoids accidental typos in path names for example.
>
>Signed-off-by: Mike Frysinger <vapier@gentoo.org>
>---
> .gitignore | 1 +
> Makefile | 10 ++++++++++
> 2 files changed, 11 insertions(+)
>
>diff --git a/.gitignore b/.gitignore
>index 3ba2632..e4490f4 100644
>--- a/.gitignore
>+++ b/.gitignore
>@@ -1,3 +1,4 @@
>+iproute2-*.tar*
> static-syms.h
> config.*
> Config
>diff --git a/Makefile b/Makefile
>index 46a5ad9..198abea 100644
>--- a/Makefile
>+++ b/Makefile
>@@ -75,6 +75,16 @@ clobber:
>
> distclean: clobber
>
>+GIT_ARCHIVE = git archive --prefix=iproute2-$(VER)/ v$(VER) | $(1) > iproute2-$(VER).tar.$(2)
>+dist.gz: ; $(call GIT_ARCHIVE,gzip,gz)
>+dist.bz2: ; $(call GIT_ARCHIVE,bzip2,bz2)
>+dist.xz: ; $(call GIT_ARCHIVE,xz,xz)
>+dist:
>+ifeq ($(VER),)
>+ @echo "Usage: make dist VER=3.7.0"; false
>+endif
>+ $(MAKE) dist.gz dist.bz2 dist.xz
>+
> cscope:
> cscope -b -q -R -Iinclude -sip -slib -smisc -snetem -stc
>
>--
>1.8.0
>
^ permalink raw reply
* Re: [PATCH] Fix: kmemleak in tcp_v4/6_syn_recv_sock and dccp_v4/6_request_recv_sock
From: Christoph Paasch @ 2012-12-14 7:59 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, Gerrit Renker, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, dccp
In-Reply-To: <1355441890.10504.4.camel@edumazet-glaptop>
Hi Eric,
On Thursday 13 December 2012 15:38:10 Eric Dumazet wrote:
> Are you sure the above commit is the bug origin ?
>
> It looks like bug was bring by transparent proxy in 2.6.37
>
> commit 093d282321daeb19c107e5f1f16d7f68484f3ade
> Author: Balazs Scheidler <bazsi@balabit.hu>
> Date: Thu Oct 21 13:06:43 2010 +0200
yes, you are right.
My patch would not easily apply on kernels < 3.0, as it depends on the
"put_and_exit"-goto.
Should I send a separate patch? And to whom? (I don't find any guidelines
about how to submit patches to older stable kernels)
Thanks,
Christoph
--
IP Networking Lab --- http://inl.info.ucl.ac.be
MultiPath TCP in the Linux Kernel --- http://mptcp.info.ucl.ac.be
UCLouvain
--
^ permalink raw reply
* Re: [RFC] net : add tx timestamp to packet mmap.
From: Paul Chavent @ 2012-12-14 7:57 UTC (permalink / raw)
To: Richard Cochran; +Cc: davem, edumazet, daniel.borkmann, xemul, ebiederm, netdev
In-Reply-To: <20121213181733.GA2312@netboy.at.omicron.at>
On 12/13/2012 07:17 PM, Richard Cochran wrote:
> On Thu, Dec 13, 2012 at 05:13:56PM +0100, Paul Chavent wrote:
>>>
>>> In order for time stamps to appear, somebody has to call
>>> skb_tx_timestamp() ...
>> Yes. "Somebody" means "the hardware driver" after completing xmit.
>> That's true ?
>
> Yes, the MAC driver must call this helper function, but not many
> drivers do this yet. You didn't say which MAC driver you are using and
> whether it supports Tx SO_TIMESTAMPING or not.
I'm using the uml net device (which recently gains tx timestamping),
e1000e (wich seems to support it according to my tests), and arm macb
(wich seems to support it too).
>
>> Yes, it only sets some flags. I thought that those flags was
>> required by the skb_tx_timestamp() in order to make the appropriate
>> timestamping (hardware, software, etc).
>>
>> So in order to have tx timestamp that work, both calls are needed ?
>
> Yes.
>
>> Why sock_tx_timestamp is called in packet_fill_skb and
>> packet_sendmsg_spkt and not in tpacket_fill_skb ?
>> Why i can retrieve timestamps when i add this call ?
>
> Sorry, I don't know much about packet mmap. Last time I tried it, some
> years ago, it wasn't really working.
I haven't measured the performance, but it works for me (however, not on
my arm platfrom yet).
>
> Richard
>
The af_packet implementation contains 3 "paths" for packets. Perhaps i'm
a bit confused by its complexity.
Paul.
^ permalink raw reply
* [PATCH] bridge: remove temporary variable for MLDv2 maximum response code computation
From: Ang Way Chuang @ 2012-12-14 9:08 UTC (permalink / raw)
To: netdev, Stephen Hemminger
As suggested by Stephen Hemminger, this remove the temporary variable introduced in commit
eca2a43bb0d2c6ebd528be6acb30a88435abe307
Signed-off-by: Ang Way Chuang <wcang@sfc.wide.ad.jp>
---
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 1093c89..2561af9 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1165,7 +1165,6 @@ static int br_ip6_multicast_query(struct net_bridge *br,
if (max_delay)
group = &mld->mld_mca;
} else if (skb->len >= sizeof(*mld2q)) {
- u16 mrc;
if (!pskb_may_pull(skb, sizeof(*mld2q))) {
err = -EINVAL;
goto out;
@@ -1173,8 +1172,7 @@ static int br_ip6_multicast_query(struct net_bridge *br,
mld2q = (struct mld2_query *)icmp6_hdr(skb);
if (!mld2q->mld2q_nsrcs)
group = &mld2q->mld2q_mca;
- mrc = ntohs(mld2q->mld2q_mrc);
- max_delay = mrc ? MLDV2_MRC(mrc) : 1;
+ max_delay = mld2q->mld2q_mrc ? MLDV2_MRC(ntohs(mld2q->mld2q_mrc)) : 1;
}
if (!group)
^ permalink raw reply related
* [PATCH] tuntap: fix ambigious multiqueue API
From: Jason Wang @ 2012-12-14 9:53 UTC (permalink / raw)
To: mst, davem, netdev, linux-kernel, pmoore; +Cc: mprivozn, wkevils, Jason Wang
The current multiqueue API is ambigious which may confuse both user and LSM to
do things correctly:
- Both TUNSETIFF and TUNSETQUEUE could be used to create the queues of a tuntap
device.
- TUNSETQUEUE were used to disable and enable a specific queue of the
device. But since the state of tuntap were completely removed from the queue,
it could be used to attach to another device (there's no such kind of
requirement currently, and it needs new kind of LSM policy.
- TUNSETQUEUE could be used to attach to a persistent device without any
queues. This kind of attching bypass the necessary checking during TUNSETIFF
and may lead unexpected result.
So this patch tries to make a cleaner and simpler API by:
- Only allow TUNSETIFF to create queues.
- TUNSETQUEUE could be only used to disable and enabled the queues of a device,
and the state of the tuntap device were not detachd from the queues when it
was disabled, so TUNSETQUEUE could be only used after TUNSETIFF and with the
same device.
This is done by introducing a list which keeps track of all queues which were
disabled. The queue would be moved between this list and tfiles[] array when it
was enabled/disabled. A pointer of the tun_struct were also introdued to track
the device it belongs to when it was disabled.
After the change, the isolation between management and application could be done
through: TUNSETIFF were only called by management software and TUNSETQUEUE were
only called by application.For LSM/SELinux, the things left is to do proper
check during tun_set_queue() if needed.
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/tun.c | 86 ++++++++++++++++++++++++++++++++++++++--------------
1 files changed, 63 insertions(+), 23 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 2ac2164..6f2053d 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -138,6 +138,8 @@ struct tun_file {
/* only used for fasnyc */
unsigned int flags;
u16 queue_index;
+ struct list_head next;
+ struct tun_struct *detached;
};
struct tun_flow_entry {
@@ -182,6 +184,8 @@ struct tun_struct {
struct hlist_head flows[TUN_NUM_FLOW_ENTRIES];
struct timer_list flow_gc_timer;
unsigned long ageing_time;
+ unsigned int numdisabled;
+ struct list_head disabled;
};
static inline u32 tun_hashfn(u32 rxhash)
@@ -386,6 +390,23 @@ static void tun_set_real_num_queues(struct tun_struct *tun)
netif_set_real_num_rx_queues(tun->dev, tun->numqueues);
}
+static void tun_disable_queue(struct tun_struct *tun, struct tun_file *tfile)
+{
+ tfile->detached = tun;
+ list_add_tail(&tfile->next, &tun->disabled);
+ ++tun->numdisabled;
+}
+
+struct tun_struct *tun_enable_queue(struct tun_file *tfile)
+{
+ struct tun_struct *tun = tfile->detached;
+
+ tfile->detached = NULL;
+ list_del_init(&tfile->next);
+ --tun->numdisabled;
+ return tun;
+}
+
static void __tun_detach(struct tun_file *tfile, bool clean)
{
struct tun_file *ntfile;
@@ -407,20 +428,25 @@ static void __tun_detach(struct tun_file *tfile, bool clean)
ntfile->queue_index = index;
--tun->numqueues;
- sock_put(&tfile->sk);
+ if (clean)
+ sock_put(&tfile->sk);
+ else
+ tun_disable_queue(tun, tfile);
synchronize_net();
tun_flow_delete_by_queue(tun, tun->numqueues + 1);
/* Drop read queue */
skb_queue_purge(&tfile->sk.sk_receive_queue);
tun_set_real_num_queues(tun);
-
- if (tun->numqueues == 0 && !(tun->flags & TUN_PERSIST))
- if (dev->reg_state == NETREG_REGISTERED)
- unregister_netdevice(dev);
- }
+ } else if (tfile->detached && clean)
+ tun = tun_enable_queue(tfile);
if (clean) {
+ if (tun && tun->numqueues == 0 && tun->numdisabled == 0 &&
+ !(tun->flags & TUN_PERSIST))
+ if (tun->dev->reg_state == NETREG_REGISTERED)
+ unregister_netdevice(tun->dev);
+
BUG_ON(!test_bit(SOCK_EXTERNALLY_ALLOCATED,
&tfile->socket.flags));
sk_release_kernel(&tfile->sk);
@@ -437,7 +463,7 @@ static void tun_detach(struct tun_file *tfile, bool clean)
static void tun_detach_all(struct net_device *dev)
{
struct tun_struct *tun = netdev_priv(dev);
- struct tun_file *tfile;
+ struct tun_file *tfile, *tmp;
int i, n = tun->numqueues;
for (i = 0; i < n; i++) {
@@ -458,6 +484,12 @@ static void tun_detach_all(struct net_device *dev)
skb_queue_purge(&tfile->sk.sk_receive_queue);
sock_put(&tfile->sk);
}
+ list_for_each_entry_safe(tfile, tmp, &tun->disabled, next) {
+ tun_enable_queue(tfile);
+ skb_queue_purge(&tfile->sk.sk_receive_queue);
+ sock_put(&tfile->sk);
+ }
+ BUG_ON(tun->numdisabled != 0);
}
static int tun_attach(struct tun_struct *tun, struct file *file)
@@ -474,7 +506,8 @@ static int tun_attach(struct tun_struct *tun, struct file *file)
goto out;
err = -E2BIG;
- if (tun->numqueues == MAX_TAP_QUEUES)
+ if (!tfile->detached &&
+ tun->numqueues + tun->numdisabled == MAX_TAP_QUEUES)
goto out;
err = 0;
@@ -488,9 +521,13 @@ static int tun_attach(struct tun_struct *tun, struct file *file)
tfile->queue_index = tun->numqueues;
rcu_assign_pointer(tfile->tun, tun);
rcu_assign_pointer(tun->tfiles[tun->numqueues], tfile);
- sock_hold(&tfile->sk);
tun->numqueues++;
+ if (tfile->detached)
+ tun_enable_queue(tfile);
+ else
+ sock_hold(&tfile->sk);
+
tun_set_real_num_queues(tun);
/* device is allowed to go away first, so no need to hold extra
@@ -1348,6 +1385,7 @@ static void tun_free_netdev(struct net_device *dev)
{
struct tun_struct *tun = netdev_priv(dev);
+ BUG_ON(!(list_empty(&tun->disabled)));
tun_flow_uninit(tun);
free_netdev(dev);
}
@@ -1542,6 +1580,10 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
err = tun_attach(tun, file);
if (err < 0)
return err;
+
+ if (tun->flags & TUN_TAP_MQ &&
+ (tun->numqueues + tun->numdisabled > 1))
+ return err;
}
else {
char *name;
@@ -1600,6 +1642,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
TUN_USER_FEATURES;
dev->features = dev->hw_features;
+ INIT_LIST_HEAD(&tun->disabled);
err = tun_attach(tun, file);
if (err < 0)
goto err_free_dev;
@@ -1754,32 +1797,28 @@ static int tun_set_queue(struct file *file, struct ifreq *ifr)
{
struct tun_file *tfile = file->private_data;
struct tun_struct *tun;
- struct net_device *dev;
int ret = 0;
rtnl_lock();
if (ifr->ifr_flags & IFF_ATTACH_QUEUE) {
- dev = __dev_get_by_name(tfile->net, ifr->ifr_name);
- if (!dev) {
- ret = -EINVAL;
- goto unlock;
- }
-
- tun = netdev_priv(dev);
- if (dev->netdev_ops != &tap_netdev_ops &&
- dev->netdev_ops != &tun_netdev_ops)
+ tun = tfile->detached;
+ if (!tun)
ret = -EINVAL;
else if (tun_not_capable(tun))
ret = -EPERM;
else
ret = tun_attach(tun, file);
- } else if (ifr->ifr_flags & IFF_DETACH_QUEUE)
- __tun_detach(tfile, false);
- else
+ } else if (ifr->ifr_flags & IFF_DETACH_QUEUE) {
+ tun = rcu_dereference_protected(tfile->tun,
+ lockdep_rtnl_is_held());
+ if (!tun || !(tun->flags & TUN_TAP_MQ))
+ ret = -EINVAL;
+ else
+ __tun_detach(tfile, false);
+ } else
ret = -EINVAL;
-unlock:
rtnl_unlock();
return ret;
}
@@ -2091,6 +2130,7 @@ static int tun_chr_open(struct inode *inode, struct file * file)
file->private_data = tfile;
set_bit(SOCK_EXTERNALLY_ALLOCATED, &tfile->socket.flags);
+ INIT_LIST_HEAD(&tfile->next);
return 0;
}
--
1.7.1
^ permalink raw reply related
* Re: cpts: Fix build error caused by include of plat/clock.h
From: Koen Kooi @ 2012-12-14 9:55 UTC (permalink / raw)
To: Richard Cochran
Cc: Tony Lindgren, David S. Miller, linux-arm-kernel, linux-omap,
netdev
In-Reply-To: <20121214071300.GA2253@netboy.at.omicron.at>
Op 14 dec. 2012, om 08:13 heeft Richard Cochran <richardcochran@gmail.com> het volgende geschreven:
> On Thu, Dec 13, 2012 at 01:36:41PM -0800, Tony Lindgren wrote:
>> Commit 87c0e764 (cpts: introduce time stamping code and a PTP hardware clock)
>> mistakenly included plat/clock.h that should not be included by drivers
>> even if it exists.
>
> Hasn't this already been fixed?
>
> https://patchwork.kernel.org/patch/1810481/
> http://www.spinics.net/lists/linux-omap/msg83132.html
That patch didn't get applied, so it's still broken in Linus' tree :(
regards,
Koen
^ permalink raw reply
* [Netperf PATCH] output remote_send_size in TCP_MAERTS result
From: Amos Kong @ 2012-12-14 10:49 UTC (permalink / raw)
To: rick.jones2; +Cc: netdev, Amos Kong
When I executed TCP_MAERTS by following command line:
netperf-2.6.0 -H 192.168.58.23 -l 10 -C -t TCP_MAERTS -- -m 512,1024
The outputed send size is '512'.
When I executed TCP_MAERTS by following command line:
netperf-2.6.0 -H 192.168.58.23 -l 10 -t TCP_MAERTS -- -m 512,1024
The outputed send size is '1024'.
In TCP_MAERTS test, we should output the remote send size '1024',
this patch fixed this issue.
Reported-by: Wenli Quan <wquan@redhat.com>
Signed-off-by: Amos Kong <akong@redhat.com>
---
src/nettest_omni.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/nettest_omni.c b/src/nettest_omni.c
index 826167a..b0b1500 100644
--- a/src/nettest_omni.c
+++ b/src/nettest_omni.c
@@ -5951,7 +5951,7 @@ Size (bytes)\n\
cpu_fmt_1, /* the format string */
rsr_size, /* remote recvbuf size */
lss_size, /* local sendbuf size */
- send_size, /* how large were the recvs */
+ remote_send_size, /* how large were the recvs */
elapsed_time, /* how long was the test */
thruput, /* what was the xfer rate */
local_cpu_utilization, /* local cpu */
@@ -5983,7 +5983,7 @@ Size (bytes)\n\
tput_fmt_1, /* the format string */
lsr_size, /* local recvbuf size */
rss_size, /* remot sendbuf size */
- remote_send_size, /* how large were the recvs */
+ remote_send_size, /* how large were the recvs */
elapsed_time, /* how long did it take */
thruput, /* how fast did it go */
((print_headers) ||
--
1.7.1
^ permalink raw reply related
* [PATCH] Fix comment for packets without data
From: Florent Fourcot @ 2012-12-14 10:53 UTC (permalink / raw)
To: rick.jones2; +Cc: pablo, yoshfuji, netdev, netfilter-devel, Florent Fourcot
In-Reply-To: <50CA23AA.1040501@hp.com>
Remove ambiguity of double negation
Signed-off-by: Florent Fourcot <florent.fourcot@enst-bretagne.fr>
---
net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c b/net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c
index 00ee17c..137e245 100644
--- a/net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c
+++ b/net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c
@@ -81,8 +81,8 @@ static int ipv6_get_l4proto(const struct sk_buff *skb, unsigned int nhoff,
}
protoff = ipv6_skip_exthdr(skb, extoff, &nexthdr, &frag_off);
/*
- * (protoff == skb->len) mean that the packet doesn't have no data
- * except of IPv6 & ext headers. but it's tracked anyway. - YK
+ * (protoff == skb->len) means the packet has not data, just
+ * IPv6 and possibly extensions headers, but it is tracked anyway
*/
if (protoff < 0 || (frag_off & htons(~0x7)) != 0) {
pr_debug("ip6_conntrack_core: can't find proto in pkt\n");
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] Fix comment for packets without data
From: Florent Fourcot @ 2012-12-14 10:56 UTC (permalink / raw)
To: Rick Jones; +Cc: pablo, yoshfuji, netdev, netfilter-devel
In-Reply-To: <50CA23AA.1040501@hp.com>
> Perhaps "(protoff == skb->len) means the packet has no
> data, just IPv6 and extension headers, but it is tracked anyway."
>
I agree, and I send a new patch. But I was not sure if I should add you
in "Signed-off-by" list.
Regards,
--
Florent.
^ permalink raw reply
* [PATCH 03/12] mISDN: fix race in timer canceling on module unloading
From: Konstantin Khlebnikov @ 2012-12-14 11:02 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, Karsten Keil, David S. Miller
In-Reply-To: <20121214110229.11019.63713.stgit@zurg>
Using timer_pending() without additional syncronization is racy,
del_timer_sync() must be used here for waiting in-flight handler.
Bug caught with help from "debug-objects" during random insmod/rmmod.
Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Cc: Karsten Keil <isdn@linux-pingi.de>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev <netdev@vger.kernel.org>
---
<4>[ 459.470685] ------------[ cut here ]------------
<4>[ 459.471144] WARNING: at lib/debugobjects.c:255 debug_print_object+0x50/0x60() (Tainted: P WC --------------- T)
<4>[ 459.471144] Hardware name: System Product Name
<3>[ 459.471144] ODEBUG: free active object type: timer_list
<4>[ 459.471144] Modules linked in: [a lot] [last unloaded: mISDN_dsp]
<4>[ 459.471144] Pid: 86812, comm: rmmod veid: 0 Tainted: P WC --------------- T 2.6.32-279.5.1.el6-042stab061.7-vz #112
<4>[ 459.471144] Call Trace:
<4>[ 459.471144] [<ffffffff81073407>] ? warn_slowpath_common+0x87/0xc0
<4>[ 459.471144] [<ffffffff810734f6>] ? warn_slowpath_fmt+0x46/0x50
<4>[ 459.471144] [<ffffffff81541b71>] ? _spin_lock_irqsave+0x91/0xb0
<4>[ 459.471144] [<ffffffff812b59b8>] ? debug_check_no_obj_freed+0x88/0x210
<4>[ 459.471144] [<ffffffff812b54d0>] ? debug_print_object+0x50/0x60
<4>[ 459.471144] [<ffffffff812b5a55>] ? debug_check_no_obj_freed+0x125/0x210
<4>[ 459.471144] [<ffffffff81188d66>] ? __vunmap+0x56/0x130
<4>[ 459.471144] [<ffffffff81188edf>] ? vfree+0x3f/0x50
<4>[ 459.471144] [<ffffffff81035a71>] ? module_free+0x11/0x20
<4>[ 459.471144] [<ffffffff810d1eea>] ? free_module+0x12a/0x180
<4>[ 459.471144] [<ffffffff810d216b>] ? sys_delete_module+0x1db/0x260
<4>[ 459.471144] [<ffffffff81541102>] ? trace_hardirqs_on_thunk+0x3a/0x3f
<4>[ 459.471144] [<ffffffff8100b1c2>] ? system_call_fastpath+0x16/0x1b
<4>[ 459.471144] ---[ end trace e17743cc12462133 ]---
---
drivers/isdn/mISDN/dsp_core.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/isdn/mISDN/dsp_core.c b/drivers/isdn/mISDN/dsp_core.c
index 28c99c6..22b720e 100644
--- a/drivers/isdn/mISDN/dsp_core.c
+++ b/drivers/isdn/mISDN/dsp_core.c
@@ -1217,8 +1217,7 @@ static void __exit dsp_cleanup(void)
{
mISDN_unregister_Bprotocol(&DSP);
- if (timer_pending(&dsp_spl_tl))
- del_timer(&dsp_spl_tl);
+ del_timer_sync(&dsp_spl_tl);
if (!list_empty(&dsp_ilist)) {
printk(KERN_ERR "mISDN_dsp: Audio DSP object inst list not "
^ permalink raw reply related
* [PATCH 07/12] stmmac: fix platform driver unregistering
From: Konstantin Khlebnikov @ 2012-12-14 11:02 UTC (permalink / raw)
To: linux-kernel; +Cc: Giuseppe Cavallaro, netdev
In-Reply-To: <20121214110229.11019.63713.stgit@zurg>
This patch fixes platform device drivers unregistering and adds proper error
handing on module loading.
Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: netdev@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 6 +++---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 22 +++++++++++----------
2 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index 023a4fb..b05df89 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -127,14 +127,14 @@ static inline int stmmac_register_platform(void)
}
static inline void stmmac_unregister_platform(void)
{
- platform_driver_register(&stmmac_pltfr_driver);
+ platform_driver_unregister(&stmmac_pltfr_driver);
}
#else
static inline int stmmac_register_platform(void)
{
pr_debug("stmmac: do not register the platf driver\n");
- return -EINVAL;
+ return 0;
}
static inline void stmmac_unregister_platform(void)
{
@@ -162,7 +162,7 @@ static inline int stmmac_register_pci(void)
{
pr_debug("stmmac: do not register the PCI driver\n");
- return -EINVAL;
+ return 0;
}
static inline void stmmac_unregister_pci(void)
{
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 542edbc..f07c061 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2194,18 +2194,20 @@ int stmmac_restore(struct net_device *ndev)
*/
static int __init stmmac_init(void)
{
- int err_plt = 0;
- int err_pci = 0;
-
- err_plt = stmmac_register_platform();
- err_pci = stmmac_register_pci();
-
- if ((err_pci) && (err_plt)) {
- pr_err("stmmac: driver registration failed\n");
- return -EINVAL;
- }
+ int ret;
+ ret = stmmac_register_platform();
+ if (ret)
+ goto err;
+ ret = stmmac_register_pci();
+ if (ret)
+ goto err_pci;
return 0;
+err_pci:
+ stmmac_unregister_platform();
+err:
+ pr_err("stmmac: driver registration failed\n");
+ return ret;
}
static void __exit stmmac_exit(void)
^ permalink raw reply related
* [PATCH 08/12] bonding: do not cancel works in bond_uninit()
From: Konstantin Khlebnikov @ 2012-12-14 11:02 UTC (permalink / raw)
To: linux-kernel; +Cc: Nikolay Aleksandrov, netdev, Jay Vosburgh, Andy Gospodarek
In-Reply-To: <20121214110229.11019.63713.stgit@zurg>
Bonding initializes these works in bond_open() and cancels in bond_close(),
thus in bond_uninit() they are already canceled but may be unitialized yet.
Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Cc: Nikolay Aleksandrov <nikolay@redhat.com>
Cc: Jay Vosburgh <fubar@us.ibm.com>
Cc: Andy Gospodarek <andy@greyhouse.net>
Cc: netdev@vger.kernel.org
---
drivers/net/bonding/bond_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index ef2cb24..b7d45f3 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -4431,8 +4431,6 @@ static void bond_uninit(struct net_device *bond_dev)
list_del(&bond->bond_list);
- bond_work_cancel_all(bond);
-
bond_debug_unregister(bond);
__hw_addr_flush(&bond->mc_list);
^ permalink raw reply related
* [PATCH 10/12] mac802154: fix destructon ordering for ieee802154 devices
From: Konstantin Khlebnikov @ 2012-12-14 11:03 UTC (permalink / raw)
To: linux-kernel
Cc: Dmitry Eremin-Solenikov, netdev, Alexander Smirnov,
David S. Miller, linux-zigbee-devel
In-Reply-To: <20121214110229.11019.63713.stgit@zurg>
mutex_destroy() must be called before wpan_phy_free(), because it puts the last
reference and frees memory. Catched as overwritten poison in kmalloc-2048.
Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Cc: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: linux-zigbee-devel@lists.sourceforge.net
Cc: netdev@vger.kernel.org
---
net/mac802154/ieee802154_dev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/mac802154/ieee802154_dev.c b/net/mac802154/ieee802154_dev.c
index e748aed..b7c7f81 100644
--- a/net/mac802154/ieee802154_dev.c
+++ b/net/mac802154/ieee802154_dev.c
@@ -224,9 +224,9 @@ void ieee802154_free_device(struct ieee802154_dev *hw)
BUG_ON(!list_empty(&priv->slaves));
- wpan_phy_free(priv->phy);
-
mutex_destroy(&priv->slaves_mtx);
+
+ wpan_phy_free(priv->phy);
}
EXPORT_SYMBOL(ieee802154_free_device);
^ permalink raw reply related
* Re: cpts: Fix build error caused by include of plat/clock.h
From: Richard Cochran @ 2012-12-14 11:09 UTC (permalink / raw)
To: Koen Kooi
Cc: Tony Lindgren, David S. Miller, linux-arm-kernel, linux-omap,
netdev
In-Reply-To: <45364223-10C6-430A-9085-9DE1C79030AF@dominion.thruhere.net>
On Fri, Dec 14, 2012 at 10:55:56AM +0100, Koen Kooi wrote:
>
> Op 14 dec. 2012, om 08:13 heeft Richard Cochran <richardcochran@gmail.com> het volgende geschreven:
>
> > On Thu, Dec 13, 2012 at 01:36:41PM -0800, Tony Lindgren wrote:
> >> Commit 87c0e764 (cpts: introduce time stamping code and a PTP hardware clock)
> >> mistakenly included plat/clock.h that should not be included by drivers
> >> even if it exists.
> >
> > Hasn't this already been fixed?
> >
> > https://patchwork.kernel.org/patch/1810481/
> > http://www.spinics.net/lists/linux-omap/msg83132.html
>
> That patch didn't get applied, so it's still broken in Linus' tree :(
In netdev's patchwork, this was marked "Not Applicable." Dave, can you
possibly take this patch? If not, who should I ask next?
Thanks,
Richard
^ permalink raw reply
* Re: [RFC PATCH] xfrm: avoid to send/receive the exceeding hard lifetime data
From: Steffen Klassert @ 2012-12-14 11:39 UTC (permalink / raw)
To: RongQing Li; +Cc: netdev
In-Reply-To: <CAJFZqHyUSHS3-TjkGQ3WiD486MCCTbiRd4vXUAcbJ=ZqqsnQoA@mail.gmail.com>
On Fri, Dec 14, 2012 at 02:58:03PM +0800, RongQing Li wrote:
>
> Yes, RFC does not say how to handle this packet.
>
> But when I do a IPsec compliance test with IxANVL, the test case 5.3/5.11,
> which reports a error because it expects this packet should be dropped, but not.
>
>
> I do not know if it is bug, or if it is valuable to fix it?
>
As long as the RFC does not state anything else, we ar ok in the
synchronous code path. But we need a fix for the asynchronous
code path.
^ permalink raw reply
* Re: [PATCH] xfrm: do not check x->km.state
From: Steffen Klassert @ 2012-12-14 11:45 UTC (permalink / raw)
To: RongQing Li; +Cc: David Miller, netdev
In-Reply-To: <CAJFZqHxZDAeZxLyxddtxCB6ucU6hMxH1TtWcMD2TZGRRA52-_g@mail.gmail.com>
On Fri, Dec 14, 2012 at 03:02:32PM +0800, RongQing Li wrote:
>
> since xfrm_output_one() calls xfrm_state_check_expire() too, but without
> checking (x->km.state != XFRM_STATE_VALID), I think we can not directly
> remove the check of km.state from xfrm_state_check_expire(). I have two
> option, which one do you think it is better?
>
> 1. remove this check in xfrm_state_check_expire, and add a check in
> xfrm_output_one
>
I think the first option ist the better one. It removes a superfluous
check and we get some more statistics.
^ permalink raw reply
* userspace utils for linux-can
From: Marc Kleine-Budde @ 2012-12-14 12:02 UTC (permalink / raw)
To: ftpadmin; +Cc: linux-can@vger.kernel.org, Linux Netdev List
[-- Attachment #1: Type: text/plain, Size: 529 bytes --]
Hello kernel.org Admins,
I'd like to put the tarballs of the linux-can userspace testing
utilities on the kernel.org infrastructure, it this possible? I was
thinking about:
http://kernel.org/pub/linux/utils/net/can-utils
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]
^ permalink raw reply
* [RFT PATCH] 8139cp: Fix possible dev_close / cp_interrupt race during MTU change
From: John Greene @ 2012-12-14 12:14 UTC (permalink / raw)
To: netdev; +Cc: John Greene, David S. Miller, David Woodhouse
commit: cb64edb6b89491edfdbae52ba7db9a8b8391d339 upstream
Above commit may introduce a race between cp_interrupt and dev_close
/ change MTU / dev_open up state. Changes cp_interrupt to tolerate
this. Change spin_locking in cp_interrupt to avoid possible
but unobserved race.
Reported-by: "Francois Romieu" <romieu@fr.zoreil.com>
Tested on virtual hardware, Tx MTU size up to 4096, max tx payload
was ping -s 4068 for MTU of 4096. No real hardware, need test
assist.
Signed-off-by: "John Greene" <jogreene@redhat.com>
CC: "David S. Miller" <davem@davemloft.net>
CC: "David Woodhouse" <David.Woodhouse@intel.com>
---
drivers/net/ethernet/realtek/8139cp.c | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/realtek/8139cp.c b/drivers/net/ethernet/realtek/8139cp.c
index 0da3f5e..585c35c 100644
--- a/drivers/net/ethernet/realtek/8139cp.c
+++ b/drivers/net/ethernet/realtek/8139cp.c
@@ -577,28 +577,30 @@ static irqreturn_t cp_interrupt (int irq, void *dev_instance)
{
struct net_device *dev = dev_instance;
struct cp_private *cp;
+ int handled = 0;
u16 status;
if (unlikely(dev == NULL))
return IRQ_NONE;
cp = netdev_priv(dev);
+ spin_lock(&cp->lock);
+
status = cpr16(IntrStatus);
if (!status || (status == 0xFFFF))
- return IRQ_NONE;
+ goto out_unlock;
+
+ handled = 1;
netif_dbg(cp, intr, dev, "intr, status %04x cmd %02x cpcmd %04x\n",
status, cpr8(Cmd), cpr16(CpCmd));
cpw16(IntrStatus, status & ~cp_rx_intr_mask);
- spin_lock(&cp->lock);
-
/* close possible race's with dev_close */
if (unlikely(!netif_running(dev))) {
cpw16(IntrMask, 0);
- spin_unlock(&cp->lock);
- return IRQ_HANDLED;
+ goto out_unlock;
}
if (status & (RxOK | RxErr | RxEmpty | RxFIFOOvr))
@@ -612,7 +614,6 @@ static irqreturn_t cp_interrupt (int irq, void *dev_instance)
if (status & LinkChg)
mii_check_media(&cp->mii_if, netif_msg_link(cp), false);
- spin_unlock(&cp->lock);
if (status & PciErr) {
u16 pci_status;
@@ -625,7 +626,10 @@ static irqreturn_t cp_interrupt (int irq, void *dev_instance)
/* TODO: reset hardware */
}
- return IRQ_HANDLED;
+out_unlock:
+ spin_unlock(&cp->lock);
+
+ return IRQ_RETVAL(handled);
}
#ifdef CONFIG_NET_POLL_CONTROLLER
--
1.7.11.7
^ permalink raw reply related
* [PATCH v3] ipv6: Change skb->data before using icmpv6_notify() to propagate redirect
From: Duan Jiong @ 2012-12-14 12:59 UTC (permalink / raw)
To: davem; +Cc: Steffen Klassert, netdev
In function ndisc_redirect_rcv(), the skb->data points to the transport
header, but function icmpv6_notify() need the skb->data points to the
inner IP packet. So before using icmpv6_notify() to propagate redirect,
change skb->data to point the inner IP packet that triggered the sending
of the Redirect, and introduce struct rd_msg to make it easy.
Signed-off-by: Duan Jiong <djduanjiong@gmail.com>
---
include/net/ndisc.h | 7 +++++++
net/ipv6/ndisc.c | 17 +++++++++++++++++
2 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/include/net/ndisc.h b/include/net/ndisc.h
index 980d263..6b305d7 100644
--- a/include/net/ndisc.h
+++ b/include/net/ndisc.h
@@ -78,6 +78,13 @@ struct ra_msg {
__be32 retrans_timer;
};
+struct rd_msg {
+ struct icmp6hdr icmph;
+ struct in6_addr target;
+ struct in6_addr dest;
+ __u8 opt[0];
+};
+
struct nd_opt_hdr {
__u8 nd_opt_type;
__u8 nd_opt_len;
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 2edce30..89dab79 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -1314,6 +1314,12 @@ out:
static void ndisc_redirect_rcv(struct sk_buff *skb)
{
+ u8 *hdr;
+ struct ndisc_options ndopts;
+ struct rd_msg *msg = (struct rd_msg *)skb_transport_header(skb);
+ u32 ndoptlen = skb->tail - (skb->transport_header +
+ offsetof(struct rd_msg, opt));
+
#ifdef CONFIG_IPV6_NDISC_NODETYPE
switch (skb->ndisc_nodetype) {
case NDISC_NODETYPE_HOST:
@@ -1330,6 +1336,17 @@ static void ndisc_redirect_rcv(struct sk_buff *skb)
return;
}
+ if (!ndisc_parse_options(msg->opt, ndoptlen, &ndopts))
+ return;
+
+ if (!ndopts.nd_opts_rh)
+ return;
+
+ hdr = (u8 *)ndopts.nd_opts_rh;
+ hdr += 8;
+ if (!pskb_pull(skb, hdr - skb_transport_header(skb)))
+ return;
+
icmpv6_notify(skb, NDISC_REDIRECT, 0, 0);
}
--
1.7.1
^ permalink raw reply related
* [PATCH] netlink: align attributes on 64-bits
From: Nicolas Dichtel @ 2012-12-14 13:16 UTC (permalink / raw)
To: tgraf; +Cc: netdev, davem, David.Laight, Nicolas Dichtel
In-Reply-To: <20121211184013.GD27746@casper.infradead.org>
On 64 bits arch, we must ensure that attributes are always aligned on 64-bits
boundary. 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>
---
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..aeb9fba 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 (sizeof(void *) > 4 && 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..29ace9f 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), 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);
+ }
+
__nla_put(skb, attrtype, attrlen, data);
return 0;
}
--
1.8.0.1
^ permalink raw reply related
* Re: [PATCH] Fix: kmemleak in tcp_v4/6_syn_recv_sock and dccp_v4/6_request_recv_sock
From: Eric Dumazet @ 2012-12-14 13:26 UTC (permalink / raw)
To: Christoph Paasch
Cc: David Miller, Gerrit Renker, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, dccp
In-Reply-To: <15583655.5x5gqCFMiY@cpaasch-mac>
On Fri, 2012-12-14 at 08:59 +0100, Christoph Paasch wrote:
> Hi Eric,
>
> On Thursday 13 December 2012 15:38:10 Eric Dumazet wrote:
> > Are you sure the above commit is the bug origin ?
> >
> > It looks like bug was bring by transparent proxy in 2.6.37
> >
> > commit 093d282321daeb19c107e5f1f16d7f68484f3ade
> > Author: Balazs Scheidler <bazsi@balabit.hu>
> > Date: Thu Oct 21 13:06:43 2010 +0200
>
> yes, you are right.
>
> My patch would not easily apply on kernels < 3.0, as it depends on the
> "put_and_exit"-goto.
> Should I send a separate patch? And to whom? (I don't find any guidelines
> about how to submit patches to older stable kernels)
>
Please correct the changelog to include the right commit, so that we can
backport it to needed kernels later. This backport could be done by you
or someone else, don't worry. First step is to get the first patch in
current Linus tree, but with exact information in changelog.
Thanks
^ permalink raw reply
* Re: [PATCH] Fix: kmemleak in tcp_v4/6_syn_recv_sock and dccp_v4/6_request_recv_sock
From: Christoph Paasch @ 2012-12-14 13:34 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, Gerrit Renker, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, dccp
In-Reply-To: <1355491565.10504.7.camel@edumazet-glaptop>
On Friday 14 December 2012 05:26:05 Eric Dumazet wrote:
> Please correct the changelog to include the right commit, so that we can
> backport it to needed kernels later. This backport could be done by you
> or someone else, don't worry. First step is to get the first patch in
> current Linus tree, but with exact information in changelog.
Ok, will resubmit soon. Thanks for your help.
--
IP Networking Lab --- http://inl.info.ucl.ac.be
MultiPath TCP in the Linux Kernel --- http://mptcp.info.ucl.ac.be
UCLouvain
--
^ 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