* Re: [PATCH net-2.6 v2] gre: fix improper error handling
From: Eric Dumazet @ 2011-07-23 8:32 UTC (permalink / raw)
To: xeb; +Cc: davem, netdev
In-Reply-To: <201107231049.40603.xeb@mail.ru>
Le samedi 23 juillet 2011 à 10:49 +0400, xeb@mail.ru a écrit :
> Fix improper protocol err_handler, current implementation is fully
> unapplicable and may cause kernel crash due to double kfree_skb.
>
> Signed-off-by: Dmitry Kozlov <xeb@mail.ru>
> ---
> net/ipv4/gre.c | 21 ++++++---------------
> 1 files changed, 6 insertions(+), 15 deletions(-)
>
Good catch !
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* write() udp socket
From: ZHOU Xiaobo @ 2011-07-23 9:29 UTC (permalink / raw)
To: netdev
question No1:
When I call
ssize_t write(int fd, const void *buf, size_t count);
on a nonblocking UDP socket, is the return value always equal to 'count'?
question No2:
Can I write() a UDP socket in multiple threads without locking?
thanks
------------------
Sincerely yours
ZHOU Xiaobo
^ permalink raw reply
* Transfer partnership
From: Transfer partnership @ 2011-07-23 10:01 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 18 bytes --]
OPEN ATTACH FILE.
[-- Attachment #2: Transfer partnership.docx --]
[-- Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document, Size: 12528 bytes --]
^ permalink raw reply
* Re: [PATCH] net: Fix security_socket_sendmsg() bypass problem.
From: Tetsuo Handa @ 2011-07-23 10:39 UTC (permalink / raw)
To: mjt; +Cc: davem, casey, anton, netdev, linux-security-module
In-Reply-To: <4E2A7273.7030504@msgid.tls.msk.ru>
Michael Tokarev wrote:
> (I noticed samba.org address in the Cc list).
That's because Anton Blanchard is author of sendmmsg() system call.
> When I saw recvmmsg()/sendmmsg() here, my first thought was an
> authoritative DNS server which can read several requests at a
> time and answer them all at once too - this way it all will go
> to different addresses.
I don't know what application wants sendmmsg(). Since users can send up to
UIO_MAXIOV (= 1024) "struct iovec" blocks using sendmsg(), they will use
sendmsg() rather than sendmmsg() if the destination address are the same.
Therefore, I guess users will use sendmmsg() for sending to multiple different
destination addresses. If so, optimization based on destination address will do
more harm than benefit; simply passing nosec flag down to LSM modules (so that
SELinux will skip sock_has_perm() call and SMACK will not skip
smack_netlabel_send() call) will be sufficient for 3.0.x stable release.
Anton, how do you want to use sendmmsg()?
^ permalink raw reply
* [PATCH] ipv4: use RT_TOS after some rt_tos conversions
From: Julian Anastasov @ 2011-07-23 12:00 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
rt_tos was changed to iph->tos but it must be filtered by RT_TOS
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
diff -urp v3.0/linux/net/ipv4/ipmr.c linux/net/ipv4/ipmr.c
--- v3.0/linux/net/ipv4/ipmr.c 2011-07-23 14:35:17.551351207 +0300
+++ linux/net/ipv4/ipmr.c 2011-07-23 14:36:05.293350956 +0300
@@ -1796,7 +1796,7 @@ static struct mr_table *ipmr_rt_fib_look
struct flowi4 fl4 = {
.daddr = iph->daddr,
.saddr = iph->saddr,
- .flowi4_tos = iph->tos,
+ .flowi4_tos = RT_TOS(iph->tos),
.flowi4_oif = rt->rt_oif,
.flowi4_iif = rt->rt_iif,
.flowi4_mark = rt->rt_mark,
diff -urp v3.0/linux/net/ipv4/route.c linux/net/ipv4/route.c
--- v3.0/linux/net/ipv4/route.c 2011-07-23 14:35:17.183352539 +0300
+++ linux/net/ipv4/route.c 2011-07-23 14:36:18.488350045 +0300
@@ -1740,7 +1740,7 @@ void ip_rt_get_source(u8 *addr, struct s
memset(&fl4, 0, sizeof(fl4));
fl4.daddr = iph->daddr;
fl4.saddr = iph->saddr;
- fl4.flowi4_tos = iph->tos;
+ fl4.flowi4_tos = RT_TOS(iph->tos);
fl4.flowi4_oif = rt->dst.dev->ifindex;
fl4.flowi4_iif = skb->dev->ifindex;
fl4.flowi4_mark = skb->mark;
^ permalink raw reply
* Contact ming-yang3@live.com
From: Omar Said Ali Al Habsi @ 2011-07-23 12:13 UTC (permalink / raw)
I am Mr. Ming Yang,I have an obscured business suggestion for you.Your services will be paid for.Contact ming-yang3@live.com
^ permalink raw reply
* Your Mail Quota Has Exceeded The Set Quota
From: System Administrator @ 2011-07-23 14:02 UTC (permalink / raw)
Your Mail Quota Has Exceeded The Set Quota/Limit. You Are Currently
Running On 23GB Due To Hidden Files And Folder On Your Mailbox,
you may not be able to receive or send new mails until you re-validate.
Please Click the Link Below To Validate Your Mailbox And Increase Your Quota.
http://buzurl.com/ao70
Failure To Validate Your Quota May Result In Loss Of Important Information
In Your Mailbox Or Cause Limited Access To It.
Mail Quota alert -Error Code #1997142DDE
System Administrator
192.168.0.1
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
^ permalink raw reply
* Re: IPv6: autoconfiguration and suspend/resume or link down/up
From: Nicolas de Pesloüan @ 2011-07-23 14:31 UTC (permalink / raw)
To: Herbert Xu; +Cc: David Miller, jbohac, netdev, shemminger
In-Reply-To: <20110722092159.GA20722@gondor.apana.org.au>
Le 22/07/2011 11:21, Herbert Xu a écrit :
> On Fri, Jul 22, 2011 at 01:06:28AM -0700, David Miller wrote:
>>
>> Suspend is even more important because while we were suspended we
>> could be on the same network but the routers present and available
>> might have changed completely.
>
> Unfortunately virtual machine live migration also uses the suspend
> & resume mechanism. In that case we don't wish to renegotiate
> everything, since the goal is to minimise the outage window.
>
> This would suggest that putting the policy in user-space may be the
> best option.
For the particular situation where we use suspend/resume to migrate a virtual machine, we might have
a kernel parameter or sysfs entry that instruct the kernel not to renegotiate anything on resume.
That being said, the time to renegotiate a network setup sounds very short, compared to the time for
a full suspend-migrate-resume cycle. I'm not sure VM migration would really suffer from such
renegotiation.
And because the local network may change while we migrate the VM (in particular if the migration
happens because of some failover), I think we should enforce renegotiation on resume anyway.
Nicolas.
^ permalink raw reply
* Re: IPv6: autoconfiguration and suspend/resume or link down/up
From: Herbert Xu @ 2011-07-23 15:27 UTC (permalink / raw)
To: Nicolas de Pesloüan; +Cc: David Miller, jbohac, netdev, shemminger
In-Reply-To: <4E2ADB39.9070409@gmail.com>
On Sat, Jul 23, 2011 at 04:31:21PM +0200, Nicolas de Pesloüan wrote:
>
> That being said, the time to renegotiate a network setup sounds very
> short, compared to the time for a full suspend-migrate-resume cycle. I'm
> not sure VM migration would really suffer from such renegotiation.
Live migration certainly would suffer from multiple RTTs that
result from renegotiation.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* loopback interface - why checksum on header?
From: Pierre Louis Aublin @ 2011-07-23 16:30 UTC (permalink / raw)
To: netdev
Hello everybody
I am wondering why the checksum of packets sent through the loopback
interface is computed on the header only.
If I understand correctly, it is assumed that a message cannot be
corrupted in RAM, thus there is no need to verify the integrity of the
whole message.
However, in that case, there is also no need to compute it on the header.
Consequently, why is it not the case?
Thank you in advance
Pierre Louis Aublin
^ permalink raw reply
* Re: IPv6: autoconfiguration and suspend/resume or link down/up
From: Stephen Hemminger @ 2011-07-23 16:37 UTC (permalink / raw)
To: Herbert Xu; +Cc: Nicolas de Pesloüan, David Miller, jbohac, netdev
In-Reply-To: <20110723152724.GA11028@gondor.apana.org.au>
On Sat, 23 Jul 2011 23:27:24 +0800
Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Sat, Jul 23, 2011 at 04:31:21PM +0200, Nicolas de Pesloüan wrote:
> >
> > That being said, the time to renegotiate a network setup sounds very
> > short, compared to the time for a full suspend-migrate-resume cycle. I'm
> > not sure VM migration would really suffer from such renegotiation.
>
> Live migration certainly would suffer from multiple RTTs that
> result from renegotiation.
>
> Cheers,
Would it be possible to do live migration without dropping carrier
or setting interface down?
^ permalink raw reply
* Re: loopback interface - why checksum on header?
From: Stephen Hemminger @ 2011-07-23 16:40 UTC (permalink / raw)
To: Pierre Louis Aublin; +Cc: netdev
In-Reply-To: <4E2AF71A.6080703@inria.fr>
On Sat, 23 Jul 2011 18:30:18 +0200
Pierre Louis Aublin <pierre-louis.aublin@inria.fr> wrote:
> Hello everybody
>
> I am wondering why the checksum of packets sent through the loopback
> interface is computed on the header only.
> If I understand correctly, it is assumed that a message cannot be
> corrupted in RAM, thus there is no need to verify the integrity of the
> whole message.
> However, in that case, there is also no need to compute it on the header.
> Consequently, why is it not the case?
>
> Thank you in advance
> Pierre Louis Aublin
Linux doesn't bother worrying about the cost of IPv4 header checksum.
The expense of checksumming is the overhead of taking the cache miss
to read the data. Since the header is going to be read anyway, doing
the checksum is equivalent to prefetching the header.
^ permalink raw reply
* LInux kernel 3.0 sit creation bug report
From: Jay Rouman @ 2011-07-23 16:27 UTC (permalink / raw)
To: netdev, davem
Kernel 3.0 (release version)
Summary: sit tunnel creation fails with "No buffer space available"
Example:
icebox:/home/u/jsr(3)# /sbin/ip tunnel add sit0 mode sit local 216.111.203.89 remote 209.51.18.1 ttl 255
add tunnel sit0 failed: No buffer space available
icebox:/home/u/jsr(8)# /sbin/ifconfig sit0 inet6 tunnel ::209.51.18.1
SIOCSIFDSTADDR: No buffer space available
Notes:
Oddly, the ifconfig example creates a working sit0. The "ip" example
does not. The problem existed in rc1 but unfortunately I did not test
sit creation then. This was discovered when I upgraded a machine with
an HE tunnel to the 3.0 kernel. I am happy to do further testing or
provide whatever additional info I can.
Environment:
icebox:/home/u/jsr(12)# cat /etc/slackware-version
Slackware 13.37.0
icebox:/home/u/jsr(11)# /usr/src/linux/scripts/ver_linux
Linux icebox 3.0.0 #1 SMP Fri Jul 22 08:07:55 EDT 2011 i686 AMD Duron(tm) processor AuthenticAMD GNU/Linux
Gnu C 4.5.2
Gnu make 3.82
binutils 2.21.51.0.6.20110118
util-linux 2.19
mount support
module-init-tools 3.12
e2fsprogs 1.41.14
jfsutils 1.1.15
reiserfsprogs 3.6.21
xfsprogs 3.1.4
pcmciautils 017
quota-tools 3.17.
PPP 2.4.5
Linux C Library 2.13
Dynamic linker (ldd) 2.13
Linux C++ Library 6.0.14
Procps 3.2.8
Net-tools 1.60
Kbd 1.15.2
oprofile 0.9.6
Sh-utils 8.11
icebox:/home/u/jsr(14)# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 8
model name : AMD Duron(tm) processor
stepping : 1
cpu MHz : 1797.443
cache size : 64 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up
bogomips : 3594.88
clflush size : 32
cache_alignment : 32
address sizes : 34 bits physical, 32 bits virtual
power management: ts
--
Jay Rouman (jsr@dexter.mi.org jsr@edzone.net)
^ permalink raw reply
* Re: IPv6: autoconfiguration and suspend/resume or link down/up
From: Herbert Xu @ 2011-07-24 0:18 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Nicolas de Pesloüan, David Miller, jbohac, netdev
In-Reply-To: <20110723093743.7c90b78f@nehalam.ftrdhcpuser.net>
On Sat, Jul 23, 2011 at 09:37:43AM -0700, Stephen Hemminger wrote:
>
> Would it be possible to do live migration without dropping carrier
> or setting interface down?
I think LM uses the same mechanism as suspend and resume so whatever
happens in one case will happen in the other case as well.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* PMTU problem with >2.6.38 and IPIP tunnels
From: Dan Siemon @ 2011-07-24 1:40 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]
I'm running into some MTU related problems with kernels newer than
2.6.38. I've tried bisecting and it appears the problem was introduced
between 2.6.39rc2 and rc3 but I'm not 100% certain because the problem
does not always present itself immediately. I am certain this does not
occur with 2.6.38.8.
I tunnel all of my home network traffic over an IPIP tunnel. My Internet
access is DSL based so there's a PPPoE connection as well. Both ends of
the IPIP tunnel are Linux.
When the gateway is first booted with the problem kernel everything is
fine. Using 'show ip route cache' I see MTU entries with the correct
values. After a short period the MTU on all the routes starts dropping
in what often appears to be 20 byte increments.
show ip route cache | egrep -i mtu
cache <src-direct> expires 435sec ipid 0x28de mtu 712 iif eth1
cache <src-direct> expires 542sec ipid 0x66e8 mtu 672 iif eth1
Until eventually all routes show a MTU of 552.
I'd be happy to run tests if anyone has an idea of what is causing this.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] bnad: remove duplicated #include
From: David Miller @ 2011-07-24 3:01 UTC (permalink / raw)
To: weiyi.huang; +Cc: netdev
In-Reply-To: <1311409152-668-1-git-send-email-weiyi.huang@gmail.com>
From: Huang Weiyi <weiyi.huang@gmail.com>
Date: Sat, 23 Jul 2011 16:19:12 +0800
> Remove duplicated #include('s) in
> drivers/net/bna/bnad.c
>
> Signed-off-by: Huang Weiyi <weiyi.huang@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] can: c_can: remove duplicated #include
From: David Miller @ 2011-07-24 3:01 UTC (permalink / raw)
To: weiyi.huang; +Cc: netdev
In-Reply-To: <1311409180-2988-1-git-send-email-weiyi.huang@gmail.com>
From: Huang Weiyi <weiyi.huang@gmail.com>
Date: Sat, 23 Jul 2011 16:19:40 +0800
> Remove duplicated #include('s) in
> drivers/net/can/c_can/c_can.c
> drivers/net/can/c_can/c_can_platform.c
>
> Signed-off-by: Huang Weiyi <weiyi.huang@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] igb: remove duplicated #include
From: David Miller @ 2011-07-24 3:02 UTC (permalink / raw)
To: weiyi.huang; +Cc: jeffrey.t.kirsher, netdev
In-Reply-To: <1311409201-2324-1-git-send-email-weiyi.huang@gmail.com>
From: Huang Weiyi <weiyi.huang@gmail.com>
Date: Sat, 23 Jul 2011 16:20:01 +0800
> Remove duplicated #include('s) in
> drivers/net/igb/igb_main.c
>
> Signed-off-by: Huang Weiyi <weiyi.huang@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] qlge: remove duplicated #include
From: David Miller @ 2011-07-24 3:02 UTC (permalink / raw)
To: weiyi.huang; +Cc: linux-driver, netdev
In-Reply-To: <1311409225-2340-1-git-send-email-weiyi.huang@gmail.com>
From: Huang Weiyi <weiyi.huang@gmail.com>
Date: Sat, 23 Jul 2011 16:20:25 +0800
> Remove duplicated #include('s) in
> drivers/net/qlge/qlge_main.c
>
> Signed-off-by: Huang Weiyi <weiyi.huang@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] via-velocity: remove duplicated #include
From: David Miller @ 2011-07-24 3:02 UTC (permalink / raw)
To: weiyi.huang; +Cc: netdev
In-Reply-To: <1311409245-3324-1-git-send-email-weiyi.huang@gmail.com>
From: Huang Weiyi <weiyi.huang@gmail.com>
Date: Sat, 23 Jul 2011 16:20:45 +0800
> Remove duplicated #include('s) in
> drivers/net/via-velocity.c
>
> Signed-off-by: Huang Weiyi <weiyi.huang@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ipv4: use RT_TOS after some rt_tos conversions
From: David Miller @ 2011-07-24 3:05 UTC (permalink / raw)
To: ja; +Cc: netdev
In-Reply-To: <alpine.LFD.2.00.1107231455220.1537@ja.ssi.bg>
From: Julian Anastasov <ja@ssi.bg>
Date: Sat, 23 Jul 2011 15:00:41 +0300 (EEST)
> rt_tos was changed to iph->tos but it must be filtered by RT_TOS
>
> Signed-off-by: Julian Anastasov <ja@ssi.bg>
Applied, thanks Julian.
^ permalink raw reply
* Re: [PATCH net-2.6 v2] gre: fix improper error handling
From: David Miller @ 2011-07-24 3:06 UTC (permalink / raw)
To: eric.dumazet; +Cc: xeb, netdev
In-Reply-To: <1311409964.6669.9.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 23 Jul 2011 10:32:44 +0200
> Le samedi 23 juillet 2011 à 10:49 +0400, xeb@mail.ru a écrit :
>> Fix improper protocol err_handler, current implementation is fully
>> unapplicable and may cause kernel crash due to double kfree_skb.
>>
>> Signed-off-by: Dmitry Kozlov <xeb@mail.ru>
>> ---
>> net/ipv4/gre.c | 21 ++++++---------------
>> 1 files changed, 6 insertions(+), 15 deletions(-)
>>
>
> Good catch !
>
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks everyone.
^ permalink raw reply
* [PATCH] drivers:connector:remove an unused variable *tracer*
From: Wanlong Gao @ 2011-07-24 3:06 UTC (permalink / raw)
To: zbr, Jiri Kosina; +Cc: netdev, linux-kernel, Wanlong Gao
From: Wanlong Gao <gaowanlong@cn.fujitsu.com>
The variable 'tracer' never be used, so remove it.
Added by f701e5b73a1a79ea62ffd45d9e2bed4c7d5c1fd2.
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
---
drivers/connector/cn_proc.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/connector/cn_proc.c b/drivers/connector/cn_proc.c
index 281902d..0debc17 100644
--- a/drivers/connector/cn_proc.c
+++ b/drivers/connector/cn_proc.c
@@ -173,7 +173,6 @@ void proc_ptrace_connector(struct task_struct *task, int ptrace_id)
struct proc_event *ev;
struct timespec ts;
__u8 buffer[CN_PROC_MSG_SIZE];
- struct task_struct *tracer;
if (atomic_read(&proc_event_num_listeners) < 1)
return;
--
1.7.4.1
^ permalink raw reply related
* GREETINGS
From: MICROSOFT AWARD @ 2011-07-24 5:38 UTC (permalink / raw)
To: info
Your Email Id has won 1,000,000.00 GBP in the British MICROSOFT Promo 2011. send your
Names.
Address.
Sex.
Age.
Tel.
Occupation.
^ permalink raw reply
* Re: write() udp socket
From: Huajun Li @ 2011-07-24 8:33 UTC (permalink / raw)
To: ZHOU Xiaobo; +Cc: netdev
In-Reply-To: <tencent_287F494544728EDB6DA9C8ED@qq.com>
2011/7/23 ZHOU Xiaobo <xb.zhou@qq.com>:
> question No1:
> When I call
> ssize_t write(int fd, const void *buf, size_t count);
>
>
> on a nonblocking UDP socket, is the return value always equal to 'count'?
>
>
I don't think so. The function may be interrupt by signal or return
due to other reason, so the return value only represents the size it
writes successfully to the fd.
> question No2:
> Can I write() a UDP socket in multiple threads without locking?
>
In my opinion, you could. However, the receiver may not get what you expected.
>
> thanks
>
>
> ------------------
> Sincerely yours
> ZHOU Xiaobo
^ 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