* 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] 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
* 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: 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
* 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: 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
* 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
* 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: 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
* 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
* 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
* 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
* [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
* 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
* 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
* 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
* 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
* Re: [PATCH] igb: remove duplicated #include
From: Jeff Kirsher @ 2011-07-23 8:24 UTC (permalink / raw)
To: Huang Weiyi; +Cc: netdev@vger.kernel.org
In-Reply-To: <1311409201-2324-1-git-send-email-weiyi.huang@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 726 bytes --]
On Sat, 2011-07-23 at 01:20 -0700, Huang Weiyi wrote:
> Remove duplicated #include('s) in
> drivers/net/igb/igb_main.c
>
> Signed-off-by: Huang Weiyi <weiyi.huang@gmail.com>
> ---
> drivers/net/igb/igb_main.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
> index cb8c6bb..dc59905 100644
> --- a/drivers/net/igb/igb_main.c
> +++ b/drivers/net/igb/igb_main.c
> @@ -47,7 +47,6 @@
> #include <linux/if_ether.h>
> #include <linux/aer.h>
> #include <linux/prefetch.h>
> -#include <linux/if_vlan.h>
> #ifdef CONFIG_IGB_DCA
> #include <linux/dca.h>
> #endif
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [PATCH] via-velocity: remove duplicated #include
From: Huang Weiyi @ 2011-07-23 8:20 UTC (permalink / raw)
To: davem; +Cc: netdev, Huang Weiyi
Remove duplicated #include('s) in
drivers/net/via-velocity.c
Signed-off-by: Huang Weiyi <weiyi.huang@gmail.com>
---
drivers/net/via-velocity.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/via-velocity.c b/drivers/net/via-velocity.c
index a9aa4a3..deb1eca 100644
--- a/drivers/net/via-velocity.c
+++ b/drivers/net/via-velocity.c
@@ -77,7 +77,6 @@
#include <linux/udp.h>
#include <linux/crc-ccitt.h>
#include <linux/crc32.h>
-#include <linux/if_vlan.h>
#include "via-velocity.h"
--
1.5.6.4
^ permalink raw reply related
* [PATCH] qlge: remove duplicated #include
From: Huang Weiyi @ 2011-07-23 8:20 UTC (permalink / raw)
To: linux-driver; +Cc: netdev, Huang Weiyi
Remove duplicated #include('s) in
drivers/net/qlge/qlge_main.c
Signed-off-by: Huang Weiyi <weiyi.huang@gmail.com>
---
drivers/net/qlge/qlge_main.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/qlge/qlge_main.c b/drivers/net/qlge/qlge_main.c
index 743e3ec..f07e96e 100644
--- a/drivers/net/qlge/qlge_main.c
+++ b/drivers/net/qlge/qlge_main.c
@@ -36,7 +36,6 @@
#include <linux/ethtool.h>
#include <linux/if_vlan.h>
#include <linux/skbuff.h>
-#include <linux/if_vlan.h>
#include <linux/delay.h>
#include <linux/mm.h>
#include <linux/vmalloc.h>
--
1.5.6.4
^ permalink raw reply related
* [PATCH] igb: remove duplicated #include
From: Huang Weiyi @ 2011-07-23 8:20 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, Huang Weiyi
Remove duplicated #include('s) in
drivers/net/igb/igb_main.c
Signed-off-by: Huang Weiyi <weiyi.huang@gmail.com>
---
drivers/net/igb/igb_main.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
index cb8c6bb..dc59905 100644
--- a/drivers/net/igb/igb_main.c
+++ b/drivers/net/igb/igb_main.c
@@ -47,7 +47,6 @@
#include <linux/if_ether.h>
#include <linux/aer.h>
#include <linux/prefetch.h>
-#include <linux/if_vlan.h>
#ifdef CONFIG_IGB_DCA
#include <linux/dca.h>
#endif
--
1.5.6.4
^ permalink raw reply related
* [PATCH] can: c_can: remove duplicated #include
From: Huang Weiyi @ 2011-07-23 8:19 UTC (permalink / raw)
To: davem; +Cc: netdev, Huang Weiyi
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>
---
drivers/net/can/c_can/c_can.c | 1 -
drivers/net/can/c_can/c_can_platform.c | 1 -
2 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index 80adc83..536bda0 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -33,7 +33,6 @@
#include <linux/if_arp.h>
#include <linux/if_ether.h>
#include <linux/list.h>
-#include <linux/delay.h>
#include <linux/io.h>
#include <linux/can.h>
diff --git a/drivers/net/can/c_can/c_can_platform.c b/drivers/net/can/c_can/c_can_platform.c
index 0e300cf..0b5c6f8 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -27,7 +27,6 @@
#include <linux/if_arp.h>
#include <linux/if_ether.h>
#include <linux/list.h>
-#include <linux/delay.h>
#include <linux/io.h>
#include <linux/platform_device.h>
#include <linux/clk.h>
--
1.5.6.4
^ permalink raw reply related
* [PATCH] bnad: remove duplicated #include
From: Huang Weiyi @ 2011-07-23 8:19 UTC (permalink / raw)
To: davem; +Cc: netdev, Huang Weiyi
Remove duplicated #include('s) in
drivers/net/bna/bnad.c
Signed-off-by: Huang Weiyi <weiyi.huang@gmail.com>
---
drivers/net/bna/bnad.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/bna/bnad.c b/drivers/net/bna/bnad.c
index c89c9b2..b7e80ac 100644
--- a/drivers/net/bna/bnad.c
+++ b/drivers/net/bna/bnad.c
@@ -25,7 +25,6 @@
#include <linux/if_ether.h>
#include <linux/ip.h>
#include <linux/prefetch.h>
-#include <linux/if_vlan.h>
#include "bnad.h"
#include "bna.h"
--
1.5.6.4
^ permalink raw reply related
* Re: [ath9k-devel] [PATCH] ath9k: use pci_dev->subsystem_device
From: Pavel Roskin @ 2011-07-23 7:53 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linville-2XuSBdqkA4R54TAoqtyWWQ,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
ath9k-devel-xDcbHBWguxHbcTqmT+pZeQ,
senthilkumar-DlyHzToyqoxBDgjK7y7TUQ,
vasanth-DlyHzToyqoxBDgjK7y7TUQ, jmalinen-DlyHzToyqoxBDgjK7y7TUQ
In-Reply-To: <201107221958.23408.sshtylyov-hkdhdckH98+B+jHODAdFcQ@public.gmane.org>
On 07/22/2011 11:58 AM, Sergei Shtylyov wrote:
> The driver reads PCI subsystem ID from the PCI configuration register while it's
> already stored by the PCI subsystem in the 'subsystem_device' field of 'struct
> pci_dev'...
>
> Signed-off-by: Sergei Shtylyov<sshtylyov-hkdhdckH98+B+jHODAdFcQ@public.gmane.org>
subsysid doesn't appear to be used anywhere. It can be removed easily.
The patch will be sent separately.
--
Regards,
Pavel Roskin
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net: Fix security_socket_sendmsg() bypass problem.
From: Michael Tokarev @ 2011-07-23 7:04 UTC (permalink / raw)
To: David Miller; +Cc: penguin-kernel, casey, anton, netdev, linux-security-module
In-Reply-To: <20110722.082224.688620059032914637.davem@davemloft.net>
22.07.2011 19:22, David Miller wrote:
> From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Date: Sat, 23 Jul 2011 00:12:53 +0900
>
>> I think the regression for SMACK can be fixed with below patch.
>>
>> Should I pass nosec flags down to "struct security_operations"->sendmsg()
>> so that SELinux checks sock_has_perm() for only once when multiple different
>> destination's addresses are passed to sendmmsg()?
>>
>> static int selinux_socket_sendmsg(struct socket *sock, struct msghdr *msg,
>> int size, int nosec)
>> {
>> return nosec ? 0 : sock_has_perm(current, sock->sk, SOCKET__WRITE);
>> }
>
> Ugh, this takes away a non-trivial part of the performance gain of
> sendmmsg().
>
> I would instead rather that you check ahead of time whether this
> actually is a send to different addresses. If they are all the
> same, keep the nosec code path.
Why to optimize for this case when destination addresses are the
same? How common this usage case is, or even where it _can_
happen alot (I noticed samba.org address in the Cc list).
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 understand the initial change takes away good portion of
performance improvement, but I think the optimisation should
be performed in a different place than for a not-so-common
cenario.
Thanks,
/mjt
^ 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