Re: [stable] [PATCH 2/3] sky2: fix VLAN receive processing
* Stephen Hemminger ([EMAIL PROTECTED]) wrote:
The length check for truncated frames was not correctly handling
the case where VLAN acceleration had already read the tag.
Also, the Yukon EX has some features that use high bit of status
as security tag.
Did you leave out the GMR_FS_LEN change on purpose? AFAICT, w/out
that you miss the Yukon EX high bit usage. The upstream patch applies,
can we simply use that one (below rediffed for stable)?
thanks,
-chris
--
From d6532232cd3de79c852685823a9c52f723816d0a Mon Sep 17 00:00:00 2001
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Wed, 19 Sep 2007 15:36:42 -0700
Subject: sky2: fix VLAN receive processing (resend)
The length check for truncated frames was not correctly handling
the case where VLAN acceleration had already read the tag.
Also, the Yukon EX has some features that use high bit of status
as security tag.
Signed-off-by: Pierre-Yves Ritschard [EMAIL PROTECTED]
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
Signed-off-by: Jeff Garzik [EMAIL PROTECTED]
---
drivers/net/sky2.c | 14 +-
drivers/net/sky2.h |2 +-
2 files changed, 14 insertions(+), 2 deletions(-)
--- linux-2.6.22.9.orig/drivers/net/sky2.c
+++ linux-2.6.22.9/drivers/net/sky2.c
@@ -2049,6 +2049,13 @@ static struct sk_buff *sky2_receive(stru
struct sky2_port *sky2 = netdev_priv(dev);
struct rx_ring_info *re = sky2-rx_ring + sky2-rx_next;
struct sk_buff *skb = NULL;
+ u16 count = (status GMR_FS_LEN) 16;
+
+#ifdef SKY2_VLAN_TAG_USED
+ /* Account for vlan tag */
+ if (sky2-vlgrp (status GMR_FS_VLAN))
+ count -= VLAN_HLEN;
+#endif
if (unlikely(netif_msg_rx_status(sky2)))
printk(KERN_DEBUG PFX %s: rx slot %u status 0x%x len %d\n,
@@ -2063,7 +2070,8 @@ static struct sk_buff *sky2_receive(stru
if (!(status GMR_FS_RX_OK))
goto resubmit;
- if (status 16 != length)
+ /* if length reported by DMA does not match PHY, packet was truncated */
+ if (length != count)
goto len_mismatch;
if (length copybreak)
@@ -2079,6 +2087,10 @@ len_mismatch:
/* Truncation of overlength packets
causes PHY length to not match MAC length */
++sky2-net_stats.rx_length_errors;
+ if (netif_msg_rx_err(sky2) net_ratelimit())
+ pr_info(PFX %s: rx length mismatch: length %d status %#x\n,
+ dev-name, length, status);
+ goto resubmit;
error:
++sky2-net_stats.rx_errors;
--- linux-2.6.22.9.orig/drivers/net/sky2.h
+++ linux-2.6.22.9/drivers/net/sky2.h
@@ -1579,7 +1579,7 @@ enum {
/* Receive Frame Status Encoding */
enum {
- GMR_FS_LEN = 0x16, /* Bit 31..16:Rx Frame Length */
+ GMR_FS_LEN = 0x7fff16, /* Bit 30..16:Rx Frame Length */
GMR_FS_VLAN = 113, /* VLAN Packet */
GMR_FS_JABBER = 112, /* Jabber Packet */
GMR_FS_UN_SIZE = 111, /* Undersize Packet */
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [stable] [PATCH 2/3] sky2: fix VLAN receive processing
* Stephen Hemminger ([EMAIL PROTECTED]) wrote: I left it out on purpose because 2.6.22 doesn't support Yukon EX. OK, thanks. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bonding: Fix use after free in unregister path
* Jeff Garzik ([EMAIL PROTECTED]) wrote: Jay Vosburgh wrote: The following patch (based on a patch from Stephen Hemminger [EMAIL PROTECTED]) removes use after free conditions in the unregister path for the bonding master. Without this patch, an operation of the form echo -bond0 /sys/class/net/bonding_masters would trigger a NULL pointer dereference in sysfs. I was not able to induce the failure with the non-sysfs code path, but for consistency I updated that code as well. I also did some testing of the bonding /proc file being open while the bond is being deleted, and didn't see any problems there. Signed-off-by: Jay Vosburgh [EMAIL PROTECTED] applied to #upstream-fixes This was originally discovered on 2.6.21.5 IIRC, so plan to send this to -stable as well? thanks, -chris - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [stable] [IPV6]: Fix routing round-robin locking. breaks manual default route (bug 8349)
* Simon Arlott ([EMAIL PROTECTED]) wrote: Adding a ::/0 route doesn't work: # ip -6 r a ::/0 via fe80::230:18ff:feb0:25c2 dev eth0 # ping6 -c 1 2001:4b10:1005:0:205:b4ff:fe12:530 connect: Network is unreachable A route assigned by addrconf works. Reverting this patch from 2.6.22-rc3 fixes it: commit f11e6659ce9058928d73ff440f9b40a818d628ab Author: David S. Miller [EMAIL PROTECTED] Date: Sat Mar 24 20:36:25 2007 -0700 [IPV6]: Fix routing round-robin locking. This patch is was added to 2.6.20.5, breaking -stable too. Rather than reverting that patch, applying this patch should fix your ipv6 issue: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=7ebba6d14f8d63cad583bf1cc0330b601d5a8171 I'll wait for Dave or Yoshifuji to decide if this is a proper -stable patch. thanks, -chris - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] e1000: Don't enable polling in open() (was: e1000: assertion hit in e1000_clean(), kernel 2.6.21.1)
* Herbert Xu ([EMAIL PROTECTED]) wrote: On Tue, May 22, 2007 at 10:02:53AM -0700, Kok, Auke wrote: I've posted that before and it's up to the stable team. I think that it's a seriously toolarge change unless Herbert posts his short version of the fix for 2.6.21.1. I would be OK with that. This patch should work for 2.6.21. Mind adding an updated changelog and signed-off-by please? thanks, -chris - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] e1000: Don't enable polling in open() (was: e1000: assertion hit in e1000_clean(), kernel 2.6.21.1)
* Herbert Xu ([EMAIL PROTECTED]) wrote: On Wed, May 23, 2007 at 04:38:20PM -0700, Kok, Auke wrote: With that, please add my Acked-By... Sorry, I only read yours after Chris's message :) Chris, please add that Acked-By by Auke. Got it, thanks. -chris - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 62/69] sky2: fix oops on shutdown
-stable review patch. If anyone has any objections, please let us know. - From: Stephen Hemminger [EMAIL PROTECTED] If the device fails during module startup for some reason like unsupported chip version then the driver would crash dereferencing a null pointer, on shutdown or suspend/resume. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] Signed-off-by: Chris Wright [EMAIL PROTECTED] --- drivers/net/sky2.c | 10 ++ 1 file changed, 10 insertions(+) --- linux-2.6.21.1.orig/drivers/net/sky2.c +++ linux-2.6.21.1/drivers/net/sky2.c @@ -3719,6 +3719,7 @@ err_out_free_regions: pci_release_regions(pdev); pci_disable_device(pdev); err_out: + pci_set_drvdata(pdev, NULL); return err; } @@ -3771,6 +3772,9 @@ static int sky2_suspend(struct pci_dev * struct sky2_hw *hw = pci_get_drvdata(pdev); int i, wol = 0; + if (!hw) + return 0; + del_timer_sync(hw-idle_timer); netif_poll_disable(hw-dev[0]); @@ -3802,6 +3806,9 @@ static int sky2_resume(struct pci_dev *p struct sky2_hw *hw = pci_get_drvdata(pdev); int i, err; + if (!hw) + return 0; + err = pci_set_power_state(pdev, PCI_D0); if (err) goto out; @@ -3848,6 +3855,9 @@ static void sky2_shutdown(struct pci_dev struct sky2_hw *hw = pci_get_drvdata(pdev); int i, wol = 0; + if (!hw) + return; + del_timer_sync(hw-idle_timer); netif_poll_disable(hw-dev[0]); -- - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 59/69] sky2: allow 88E8056
-stable review patch. If anyone has any objections, please let us know.
-
From: Stephen Hemminger [EMAIL PROTECTED]
It looks like the problems of Gigabyte 88E8056 are unique to that chip
motherboard and maybe fixable by EEPROM update.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
Signed-off-by: Chris Wright [EMAIL PROTECTED]
---
drivers/net/sky2.c |3 ---
1 file changed, 3 deletions(-)
--- linux-2.6.21.1.orig/drivers/net/sky2.c
+++ linux-2.6.21.1/drivers/net/sky2.c
@@ -123,10 +123,7 @@ static const struct pci_device_id sky2_i
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4361) }, /* 88E8050 */
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4362) }, /* 88E8053 */
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4363) }, /* 88E8055 */
-#ifdef broken
- /* This device causes data corruption problems that are not resolved */
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4364) }, /* 88E8056 */
-#endif
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4366) }, /* 88EC036 */
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4367) }, /* 88EC032 */
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4368) }, /* 88EC034 */
--
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 60/69] sky2: 88e8071 support not ready
-stable review patch. If anyone has any objections, please let us know.
-
From: Stephen Hemminger [EMAIL PROTECTED]
The driver is not ready to support 88e8071 chip, it requires several
more changes (not done yet). If this chip is present, system will hang on boot.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
drivers/net/sky2.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.21.1.orig/drivers/net/sky2.c
+++ linux-2.6.21.1/drivers/net/sky2.c
@@ -129,7 +129,7 @@ static const struct pci_device_id sky2_i
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4368) }, /* 88EC034 */
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4369) }, /* 88EC042 */
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x436A) }, /* 88E8058 */
- { PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x436B) }, /* 88E8071 */
+// { PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x436B) }, /* 88E8071 */
{ 0 }
};
--
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 61/69] skge: crash on shutdown/suspend
-stable review patch. If anyone has any objections, please let us know.
-
From: Stephen Hemminger [EMAIL PROTECTED]
If device fails during module startup for some reason (like unsupported chip
version) then driver would crash dereferencing a null pointer, on shutdown
or suspend/resume.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
Signed-off-by: Chris Wright [EMAIL PROTECTED]
---
drivers/net/skge.c |9 +
1 file changed, 9 insertions(+)
--- linux-2.6.21.1.orig/drivers/net/skge.c
+++ linux-2.6.21.1/drivers/net/skge.c
@@ -3794,6 +3794,9 @@ static int skge_suspend(struct pci_dev *
struct skge_hw *hw = pci_get_drvdata(pdev);
int i, err, wol = 0;
+ if (!hw)
+ return 0;
+
err = pci_save_state(pdev);
if (err)
return err;
@@ -3822,6 +3825,9 @@ static int skge_resume(struct pci_dev *p
struct skge_hw *hw = pci_get_drvdata(pdev);
int i, err;
+ if (!hw)
+ return 0;
+
err = pci_set_power_state(pdev, PCI_D0);
if (err)
goto out;
@@ -3860,6 +3866,9 @@ static void skge_shutdown(struct pci_dev
struct skge_hw *hw = pci_get_drvdata(pdev);
int i, wol = 0;
+ if (!hw)
+ return;
+
for (i = 0; i hw-ports; i++) {
struct net_device *dev = hw-dev[i];
struct skge_port *skge = netdev_priv(dev);
--
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [stable] [PATCH 3/6] sky2: allow 88E8056
* Stephen Hemminger ([EMAIL PROTECTED]) wrote: It looks like the problems of Gigabyte 88E8056 are unique to that chip motherboard and maybe fixable by EEPROM update. So, drop the Gigabyte hunks in the original patch...ok, thanks. -chris - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [stable] [PATCH 4/6] sky2: 88e8071 support not ready
* Stephen Hemminger ([EMAIL PROTECTED]) wrote:
- { PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x436B) }, /* 88E8071 */
+// { PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x436B) }, /* 88E8071 */
Where-o-where are the CodingStyle police? ;-)
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [stable] PROBLEM: SIS900 Driver change in Linux Kernel 2.6.21 causes kernel panic.
* Dave Jones ([EMAIL PROTECTED]) wrote: You need this.. http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=dc5a144991ba803bc8afded105c9db1dea0e57ab Which is queued for -stable afaik, but no sign of 2.6.21.2 yet. Greg/Chris? Yes, it is queued, pushing out the current queue now. Once Greg and I compare notes we'll be ready to run the next review cycle. thanks, -chris - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [stable] [PATCH 2.6.21-stable] [IPV6]: Restore semantics of Routing Header processing.
* YOSHIFUJI Hideaki / 吉藤英明 ([EMAIL PROTECTED]) wrote: In article [EMAIL PROTECTED] (at Fri, 11 May 2007 09:22:43 -0700), Chris Wright [EMAIL PROTECTED] says: * YOSHIFUJI Hideaki / 吉藤英明 ([EMAIL PROTECTED]) wrote: The fix for emerging security threats was overkill and it broke basic semantic of IPv6 routing header processing. We should assume RT0 (or even RT2, depends on configuration) as unknown RH type so that we - silently ignore the routing header if segleft == 0 - or, send ICMPv6 Parameter Problem message back to the sender, otherwise. Does that mean this one has received testing and is good for -stable now, or does it need some bake time? Chris, I think it is okay, but please wait for Dave's approval. Any update on this one? thanks, -chris - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [stable] [PATCH 2.6.21-stable] [IPV6]: Restore semantics of Routing Header processing.
* David Miller ([EMAIL PROTECTED]) wrote: We're not pushing this in, even the ipv6 working group is unsure how this should be handled and one of the possibilities they might choose matches how things currently are. Alright, I'll drop this one from the -stable radar, thanks. -chris - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [stable] [PATCH 2.6.21-stable] [IPV6]: Restore semantics of Routing Header processing.
* YOSHIFUJI Hideaki / 吉藤英明 ([EMAIL PROTECTED]) wrote: Chris, I think it is okay, but please wait for Dave's approval. Alright, will do. thanks, -chris - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [stable] [PATCH 2.6.21-stable] [IPV6]: Restore semantics of Routing Header processing.
* YOSHIFUJI Hideaki / 吉藤英明 ([EMAIL PROTECTED]) wrote: The fix for emerging security threats was overkill and it broke basic semantic of IPv6 routing header processing. We should assume RT0 (or even RT2, depends on configuration) as unknown RH type so that we - silently ignore the routing header if segleft == 0 - or, send ICMPv6 Parameter Problem message back to the sender, otherwise. Does that mean this one has received testing and is good for -stable now, or does it need some bake time? thanks, -chris - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [1/2] [NET] link_watch: Move link watch list into net_device
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote: Yep, this patch gets rid of my spinning thread. I can't find this patch or any discussion on marc.info; is there a better netdev list archive? See the linkwatch bustage in git-net thread on netdev http://thread.gmane.org/gmane.linux.network/61800/focus=61812 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Security] [PATCH] infinite recursion in netlink
* Chris Wright ([EMAIL PROTECTED]) wrote: * Greg KH ([EMAIL PROTECTED]) wrote: fyi, here's the patch that I applied, perhaps 2.6.20 needed something else too? snip @@ -809,7 +815,7 @@ static void nl_fib_input(struct sock *sk nl_fib_lookup(frn, tb); - pid = nlh-nlmsg_pid; /*pid of sending process */ + pid = NETLINK_CB(skb).pid; /* pid of sending process */ That's the important bit. I'm testing against 2.6.20.8 right now. Working fine here. Any chance you booted a stale kernel? If not, what's your nl_fib_input+0xe4. Any chance that's actually in nl_fib_lookup? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Security] [PATCH] infinite recursion in netlink
* Greg KH ([EMAIL PROTECTED]) wrote: On Wed, Apr 25, 2007 at 01:15:12PM -0700, Linus Torvalds wrote: On Wed, 25 Apr 2007, Alexey Kuznetsov wrote: Reply to NETLINK_FIB_LOOKUP messages were misrouted back to kernel, which resulted in infinite recursion and stack overflow. Wait, I just had the bright idea of actually testing this before I pushed out a 2.6.20.9 kernel with another fix in it, and nope, still crashes, even with this patch :( Odd, I tested it too (on linus-git), and it's fixed (it was definitely the problem, of sending back to kernel). thanks, -chris - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Security] [PATCH] infinite recursion in netlink
* Greg KH ([EMAIL PROTECTED]) wrote: fyi, here's the patch that I applied, perhaps 2.6.20 needed something else too? snip @@ -809,7 +815,7 @@ static void nl_fib_input(struct sock *sk nl_fib_lookup(frn, tb); - pid = nlh-nlmsg_pid; /*pid of sending process */ + pid = NETLINK_CB(skb).pid; /* pid of sending process */ That's the important bit. I'm testing against 2.6.20.8 right now. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable
* Eric W. Biederman ([EMAIL PROTECTED]) wrote:
Is it truly critical to inline any of these instructions?
I don't have any current measurements. But we'd been aiming
at getting irq_{en,dis}able to a simple memory write to pda.
But simplicity, maintenance, etc. win over trimming a couple
cycles, so still worth real look.
thanks,
-chris
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [IPV6]: Ensure to truncate result and return full length for sticky options.
* David Miller ([EMAIL PROTECTED]) wrote: From: YOSHIFUJI Hideaki / 吉藤英明 [EMAIL PROTECTED] Date: Fri, 09 Mar 2007 10:13:28 +0900 (JST) Bug noticed by Chris Wright [EMAIL PROTECTED]. Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED] Applied, thanks a lot. Crud, I should have noticed this earlier. This has a problem, min_t(int) means user supplied 0 is a large copy_to_user (back to leaking memory on arch's that don't protect 0 copy_to_user like i386 does). Here's a simple fix ontop of yoshifuji's two changes. Hope that's it ;-) thanks, -chris -- From: Chris Wright [EMAIL PROTECTED] Subject: [IPV6] fix ipv6_getsockopt_sticky copy_to_user leak User supplied len 0 can cause leak of kernel memory. Use unsigned compare instead. Signed-off-by: Chris Wright [EMAIL PROTECTED] --- net/ipv6/ipv6_sockglue.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c index a4f06ce..321287b 100644 --- a/net/ipv6/ipv6_sockglue.c +++ b/net/ipv6/ipv6_sockglue.c @@ -824,7 +824,7 @@ static int ipv6_getsockopt_sticky(struct sock *sk, struct ipv6_txoptions *opt, if (!hdr) return 0; - len = min_t(int, len, ipv6_optlen(hdr)); + len = min_t(unsigned, len, ipv6_optlen(hdr)); if (copy_to_user(optval, hdr, len)); return -EFAULT; return ipv6_optlen(hdr); - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] [IPV6]: Return correct result for sticky options.
* YOSHIFUJI Hideaki / 吉藤英明 ([EMAIL PROTECTED]) wrote: We returned incorrect result with IPV6_RTHDRDSTOPTS, IPV6_RTHDR and IPV6_DSTOPTS. This makes a lot more sense. I wondered about that, thanks. -chris - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
IPV6: make ipv6_getsockopt_sticky honor user's buffer size
Make sure not to copy_to_user more than user's buffer can handle (we
already checked the min, just use it) in ipv6_getsockopt_sticky. And
while there, minor whitespace cleanup now that ipv6_getsockopt_sticky
call can nicely fit on one line.
Signed-off-by: Chris Wright [EMAIL PROTECTED]
---
diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index 4e0561a..9396551 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -805,7 +805,7 @@ static int ipv6_getsockopt_sticky(struct sock *sk, struct
ipv6_txoptions *opt,
hdr = opt-hopopt;
len = min_t(int, len, ipv6_optlen(hdr));
- if (copy_to_user(optval, hdr, ipv6_optlen(hdr)))
+ if (copy_to_user(optval, hdr, len))
return -EFAULT;
return len;
}
@@ -944,8 +944,7 @@ static int do_ipv6_getsockopt(struct sock *sk, int level,
int optname,
{
lock_sock(sk);
- len = ipv6_getsockopt_sticky(sk, np-opt,
-optval, len);
+ len = ipv6_getsockopt_sticky(sk, np-opt, optval, len);
release_sock(sk);
return put_user(len, optlen);
}
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Arp announce (for Xen)
* Stephen Hemminger ([EMAIL PROTECTED]) wrote: + case NETDEV_CHANGEADDR: + /* Send gratuitous ARP in case of address change or new device */ + if (IN_DEV_ARP_ANNOUNCE(in_dev)) Conceptually right on, but it looks like improper hijacking of arp_announce sysctl. Could introduce another thanks, -chris - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 26/26] Xen-paravirt_ops: Add the Xen virtual network device driver.
* Christoph Hellwig ([EMAIL PROTECTED]) wrote: Actually the right way to do it is in userspace, as all clustering solutions do. That's whay everyone told the Xen folks by the just refuse to rip this junk out. I'm ripping it out. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ARP notify option
* Stephen Hemminger ([EMAIL PROTECTED]) wrote: This adds another inet device option to enable gratuitous ARP when device is brought up or address change. This is handy for clusters or virtualization. This looks good. I'll test with Xen. What about the source addr selection? thanks, -chris - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 10/23] bcm43xx: Drain TX status before starting IRQs
-stable review patch. If anyone has any objections, please let us know.
--
From: Michael Buesch [EMAIL PROTECTED]
Drain the Microcode TX-status-FIFO before we enable IRQs.
This is required, because the FIFO may still have entries left
from a previous run. Those would immediately fire after enabling
IRQs and would lead to an oops in the DMA TXstatus handling code.
Cc: John W. Linville [EMAIL PROTECTED]
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Signed-off-by: Larry Finger [EMAIL PROTECTED]
Signed-off-by: Chris Wright [EMAIL PROTECTED]
---
drivers/net/wireless/bcm43xx/bcm43xx_main.c | 18 ++
1 file changed, 18 insertions(+)
--- linux-2.6.18.4.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ linux-2.6.18.4/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -1463,6 +1463,23 @@ static void handle_irq_transmit_status(s
}
}
+static void drain_txstatus_queue(struct bcm43xx_private *bcm)
+{
+ u32 dummy;
+
+ if (bcm-current_core-rev 5)
+ return;
+ /* Read all entries from the microcode TXstatus FIFO
+* and throw them away.
+*/
+ while (1) {
+ dummy = bcm43xx_read32(bcm, BCM43xx_MMIO_XMITSTAT_0);
+ if (!dummy)
+ break;
+ dummy = bcm43xx_read32(bcm, BCM43xx_MMIO_XMITSTAT_1);
+ }
+}
+
static void bcm43xx_generate_noise_sample(struct bcm43xx_private *bcm)
{
bcm43xx_shm_write16(bcm, BCM43xx_SHM_SHARED, 0x408, 0x7F7F);
@@ -3517,6 +3534,7 @@ int bcm43xx_select_wireless_core(struct
bcm43xx_macfilter_clear(bcm, BCM43xx_MACFILTER_ASSOC);
bcm43xx_macfilter_set(bcm, BCM43xx_MACFILTER_SELF, (u8
*)(bcm-net_dev-dev_addr));
bcm43xx_security_init(bcm);
+ drain_txstatus_queue(bcm);
ieee80211softmac_start(bcm-net_dev);
/* Let's go! Be careful after enabling the IRQs.
--
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 07/30] bcm43xx: Drain TX status before starting IRQs
* Larry Finger ([EMAIL PROTECTED]) wrote: The regression turns out to be a locking problem involving bcm43xx, wpa_supplicant, and NetworkManager. The exact cause is unknown; however, this patch is clearly not the problem. Please reinstate it for inclusion in -stable. Thanks for the follow-up, Larry. It's queued for next -stable. thanks, -chris - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 07/30] bcm43xx: Drain TX status before starting IRQs
* Larry Finger ([EMAIL PROTECTED]) wrote: We have a report of a regression between 2.6.19-rc3 and -rc5. As this patch seems to be the only one that could cause the problem, please pull it from -stable while we sort out the difficulty. Thanks a lot for the heads up Larry, dropping this one. -chris - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 07/30] bcm43xx: Drain TX status before starting IRQs
-stable review patch. If anyone has any objections, please let us know.
--
From: Michael Buesch [EMAIL PROTECTED]
Drain the Microcode TX-status-FIFO before we enable IRQs.
This is required, because the FIFO may still have entries left
from a previous run. Those would immediately fire after enabling
IRQs and would lead to an oops in the DMA TXstatus handling code.
Cc: John W. Linville [EMAIL PROTECTED]
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Signed-off-by: Larry Finger [EMAIL PROTECTED]
Signed-off-by: Chris Wright [EMAIL PROTECTED]
---
drivers/net/wireless/bcm43xx/bcm43xx_main.c | 18 ++
1 file changed, 18 insertions(+)
--- linux-2.6.18.2.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ linux-2.6.18.2/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -1463,6 +1463,23 @@ static void handle_irq_transmit_status(s
}
}
+static void drain_txstatus_queue(struct bcm43xx_private *bcm)
+{
+ u32 dummy;
+
+ if (bcm-current_core-rev 5)
+ return;
+ /* Read all entries from the microcode TXstatus FIFO
+* and throw them away.
+*/
+ while (1) {
+ dummy = bcm43xx_read32(bcm, BCM43xx_MMIO_XMITSTAT_0);
+ if (!dummy)
+ break;
+ dummy = bcm43xx_read32(bcm, BCM43xx_MMIO_XMITSTAT_1);
+ }
+}
+
static void bcm43xx_generate_noise_sample(struct bcm43xx_private *bcm)
{
bcm43xx_shm_write16(bcm, BCM43xx_SHM_SHARED, 0x408, 0x7F7F);
@@ -3517,6 +3534,7 @@ int bcm43xx_select_wireless_core(struct
bcm43xx_macfilter_clear(bcm, BCM43xx_MACFILTER_ASSOC);
bcm43xx_macfilter_set(bcm, BCM43xx_MACFILTER_SELF, (u8
*)(bcm-net_dev-dev_addr));
bcm43xx_security_init(bcm);
+ drain_txstatus_queue(bcm);
ieee80211softmac_start(bcm-net_dev);
/* Let's go! Be careful after enabling the IRQs.
--
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix verify_iovec() to not allow overflow of iov_len values
* Sridhar Samudrala ([EMAIL PROTECTED]) wrote:
-int verify_iovec(struct msghdr *m, struct iovec *iov, char *address, int
mode)
+ssize_t verify_iovec(struct msghdr *m, struct iovec *iov, char *address, int
mode)
{
int size, err, ct;
+ ssize_t tot_len = 0;
if (m-msg_namelen) {
if (mode == VERIFY_READ) {
@@ -61,17 +62,22 @@ int verify_iovec(struct msghdr *m, struc
err = 0;
for (ct = 0; ct m-msg_iovlen; ct++) {
- err += iov[ct].iov_len;
+ ssize_t len;
+
/*
- * Goal is not to verify user data, but to prevent returning
- * negative value, which is interpreted as errno.
- * Overflow is still possible, but it is harmless.
+ * Goal is not to verify user data, but to prevent the cases
+ * where an iov_len value or the sum of all iov_len values
+ * overflows ssize_t.
*/
- if (err 0)
- return -EMSGSIZE;
+ len = (ssize_t)iov[ct].iov_len;
+ if (len 0)
+ return -EINVAL;
+ tot_len += len;
+ if (tot_len 0)
I specifically used size_t here, because signed integer overflow is not
defined in C.
thanks,
-chris
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][SECURITY] secmark: nul-terminate secdata
* James Morris ([EMAIL PROTECTED]) wrote: cc'd Chris Wright, as this patch seems like a candidate for the stable tree. Would be, but I thought secmark went in post 2.6.17. And I expect Dave will push this well before 2.6.18. thanks, -chris - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 32/33] Add the Xen virtual network device driver.
The network device frontend driver allows the kernel to access network devices exported exported by a virtual machine containing a physical network device driver. Signed-off-by: Ian Pratt [EMAIL PROTECTED] Signed-off-by: Christian Limpach [EMAIL PROTECTED] Signed-off-by: Chris Wright [EMAIL PROTECTED] Cc: netdev@vger.kernel.org --- drivers/net/Kconfig |2 drivers/xen/Kconfig.net | 14 drivers/xen/Makefile|3 drivers/xen/net_driver_util.c | 58 + drivers/xen/netfront/Makefile |4 drivers/xen/netfront/netfront.c | 1326 include/xen/net_driver_util.h | 48 + 7 files changed, 1455 insertions(+) diff -r eadc12b20f35 drivers/net/Kconfig --- a/drivers/net/Kconfig Fri Jun 09 15:02:44 2006 -0400 +++ b/drivers/net/Kconfig Fri Jun 09 15:03:12 2006 -0400 @@ -2325,6 +2325,8 @@ source drivers/atm/Kconfig source drivers/s390/net/Kconfig +source drivers/xen/Kconfig.net + config ISERIES_VETH tristate iSeries Virtual Ethernet driver support depends on PPC_ISERIES diff -r eadc12b20f35 drivers/xen/Makefile --- a/drivers/xen/Makefile Fri Jun 09 15:02:44 2006 -0400 +++ b/drivers/xen/Makefile Fri Jun 09 15:03:12 2006 -0400 @@ -5,3 +5,5 @@ obj-y += console/ obj-y += console/ obj-y += xenbus/ +obj-$(CONFIG_XEN_NETDEV_FRONTEND) += netfront/ + diff -r eadc12b20f35 drivers/xen/Kconfig.net --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/drivers/xen/Kconfig.net Fri Jun 09 15:03:12 2006 -0400 @@ -0,0 +1,14 @@ +menu Xen network device drivers +depends on NETDEVICES XEN + +config XEN_NETDEV_FRONTEND + tristate Network-device frontend driver + depends on XEN + default y + help + The network-device frontend driver allows the kernel to access + network interfaces within another guest OS. Unless you are building a + dedicated device-driver domain, or your master control domain + (domain 0), then you almost certainly want to say Y here. + +endmenu diff -r eadc12b20f35 drivers/xen/netfront/Makefile --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/drivers/xen/netfront/Makefile Fri Jun 09 15:03:12 2006 -0400 @@ -0,0 +1,4 @@ + +obj-$(CONFIG_XEN_NETDEV_FRONTEND) := xennet.o + +xennet-objs := netfront.o diff -r eadc12b20f35 drivers/xen/netfront/netfront.c --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/drivers/xen/netfront/netfront.c Fri Jun 09 15:03:12 2006 -0400 @@ -0,0 +1,1584 @@ +/** + * Virtual network driver for conversing with remote driver backends. + * + * Copyright (c) 2002-2005, K A Fraser + * Copyright (c) 2005, XenSource Ltd + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License version 2 + * as published by the Free Software Foundation; or, when distributed + * separately from the Linux kernel or incorporated into other + * software packages, subject to the following license: + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this source file (the Software), to deal in the Software without + * restriction, including without limitation the rights to use, copy, modify, + * merge, publish, distribute, sublicense, and/or sell copies of the Software, + * and to permit persons to whom the Software is furnished to do so, subject to + * the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS + * IN THE SOFTWARE. + */ + +#include linux/config.h +#include linux/module.h +#include linux/version.h +#include linux/kernel.h +#include linux/sched.h +#include linux/slab.h +#include linux/string.h +#include linux/errno.h +#include linux/netdevice.h +#include linux/inetdevice.h +#include linux/etherdevice.h +#include linux/skbuff.h +#include linux/init.h +#include linux/bitops.h +#include linux/ethtool.h +#include linux/in.h +#include linux/if_ether.h +#include net/sock.h +#include net/pkt_sched.h +#include net/arp.h +#include net/route.h +#include asm/io.h +#include asm/uaccess.h +#include xen/evtchn.h +#include xen/xenbus.h +#include xen/interface/io/netif.h +#include xen/interface/memory.h +#ifdef CONFIG_XEN_BALLOON +#include xen/balloon.h +#endif +#include asm/page.h +#include asm/uaccess.h +#include xen/interface/grant_table.h +#include xen
Re: [RFC PATCH 32/33] Add the Xen virtual network device driver.
* David Miller ([EMAIL PROTECTED]) wrote: From: Chris Wright [EMAIL PROTECTED] Date: Tue, 18 Jul 2006 00:00:32 -0700 +#ifdef CONFIG_XEN_BALLOON +#include xen/balloon.h +#endif Let's put the ifdefs in xen/balloon.h not in the files including it. +#ifdef CONFIG_XEN_BALLOON + /* Tell the ballon driver what is going on. */ + balloon_update_driver_allowance(i); +#endif Similarly let's define empty do-nothing functions in xen/balloon.h when the config option isn't set so we don't need to crap up the C sources with these ifdefs. Yeah, sorry it's kept more as a reminder to me. Upstream Xen doesn't do this, but this patchset doesn't support ballooning yet, so there just is not xen/balloon.h in the set. When merging with upstream Xen there's patch rejects either way, so I agree, better to just drop this since it's just future placeholder. thanks, -chris - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 34/35] Add the Xen virtual network device driver.
The network device frontend driver allows the kernel to access network
devices exported exported by a virtual machine containing a physical
network device driver.
Signed-off-by: Ian Pratt [EMAIL PROTECTED]
Signed-off-by: Christian Limpach [EMAIL PROTECTED]
Signed-off-by: Chris Wright [EMAIL PROTECTED]
Cc: netdev@vger.kernel.org
---
TODO:
- drop proc
- more ethtool ops
- s/g support
drivers/net/Kconfig |2
drivers/xen/Kconfig.net | 14
drivers/xen/Makefile|3
drivers/xen/net_driver_util.c | 58 +
drivers/xen/netfront/Makefile |4
drivers/xen/netfront/netfront.c | 1510
include/xen/net_driver_util.h | 48 +
7 files changed, 1639 insertions(+)
--- linus-2.6.orig/drivers/net/Kconfig
+++ linus-2.6/drivers/net/Kconfig
@@ -2325,6 +2325,8 @@ source drivers/atm/Kconfig
source drivers/s390/net/Kconfig
+source drivers/xen/Kconfig.net
+
config ISERIES_VETH
tristate iSeries Virtual Ethernet driver support
depends on PPC_ISERIES
--- linus-2.6.orig/drivers/xen/Makefile
+++ linus-2.6/drivers/xen/Makefile
@@ -1,7 +1,10 @@
+obj-y += net_driver_util.o
obj-y += util.o
obj-y += core/
obj-y += console/
obj-y += xenbus/
+obj-$(CONFIG_XEN_NETDEV_FRONTEND) += netfront/
+
--- /dev/null
+++ linus-2.6/drivers/xen/Kconfig.net
@@ -0,0 +1,14 @@
+menu Xen network device drivers
+depends on NETDEVICES XEN
+
+config XEN_NETDEV_FRONTEND
+ tristate Network-device frontend driver
+ depends on XEN
+ default y
+ help
+ The network-device frontend driver allows the kernel to access
+ network interfaces within another guest OS. Unless you are building a
+ dedicated device-driver domain, or your master control domain
+ (domain 0), then you almost certainly want to say Y here.
+
+endmenu
--- /dev/null
+++ linus-2.6/drivers/xen/net_driver_util.c
@@ -0,0 +1,58 @@
+/*
+ *
+ * Utility functions for Xen network devices.
+ *
+ * Copyright (c) 2005 XenSource Ltd.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this source file (the Software), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject
+ * to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include linux/if_ether.h
+#include linux/err.h
+#include linux/module.h
+#include xen/net_driver_util.h
+
+
+int xen_net_read_mac(struct xenbus_device *dev, u8 mac[])
+{
+ char *s;
+ int i;
+ char *e;
+ char *macstr = xenbus_read(XBT_NULL, dev-nodename, mac, NULL);
+ if (IS_ERR(macstr))
+ return PTR_ERR(macstr);
+ s = macstr;
+ for (i = 0; i ETH_ALEN; i++) {
+ mac[i] = simple_strtoul(s, e, 16);
+ if (s == e || (e[0] != ':' e[0] != 0)) {
+ kfree(macstr);
+ return -ENOENT;
+ }
+ s = e[1];
+ }
+ kfree(macstr);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(xen_net_read_mac);
--- /dev/null
+++ linus-2.6/drivers/xen/netfront/Makefile
@@ -0,0 +1,4 @@
+
+obj-$(CONFIG_XEN_NETDEV_FRONTEND) := xennet.o
+
+xennet-objs := netfront.o
--- /dev/null
+++ linus-2.6/drivers/xen/netfront/netfront.c
@@ -0,0 +1,1510 @@
+/**
+ * Virtual network driver for conversing with remote driver backends.
+ *
+ * Copyright (c) 2002-2005, K A Fraser
+ * Copyright (c) 2005, XenSource Ltd
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux
Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
* Stephen Hemminger ([EMAIL PROTECTED]) wrote: + info-irq = bind_evtchn_to_irqhandler( + info-evtchn, netif_int, SA_SAMPLE_RANDOM, netdev-name, This doesn't look like a real random entropy source. packets arriving from another domain are easily timed. Heh, given the path they take, that sadly may not be the case ;-) But point well-taken, that's easy to drop. thanks, -chris - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
* Christoph Hellwig ([EMAIL PROTECTED]) wrote: On Tue, May 09, 2006 at 12:00:34AM -0700, Chris Wright wrote: The network device frontend driver allows the kernel to access network devices exported exported by a virtual machine containing a physical network device driver. Please don't add procfs code to new network drivers. Especially if it's oopsable like the code in this driver by simple device renaming. Agreed, no reason to keep the cruft around. I thought I had a comment of the sort in there. thanks, -chris - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.
* Stephen Hemminger ([EMAIL PROTECTED]) wrote:
The stuff in /proc could easily just be added attributes to the class_device
kobject
of the net device (and then show up in sysfs).
Agreed, it's on the todo list to drop proc support there. Thought that
was marked in the patch.
+#define GRANT_INVALID_REF 0
+
+#define NET_TX_RING_SIZE __RING_SIZE((struct netif_tx_sring *)0, PAGE_SIZE)
+#define NET_RX_RING_SIZE __RING_SIZE((struct netif_rx_sring *)0, PAGE_SIZE)
+
+static inline void init_skb_shinfo(struct sk_buff *skb)
+{
+ atomic_set((skb_shinfo(skb)-dataref), 1);
+ skb_shinfo(skb)-nr_frags = 0;
+ skb_shinfo(skb)-frag_list = NULL;
+}
Could you use existing sk_buff_head instead of inventing your
own skb queue?
Hmm, there is some standard skb_queue_tail happening. I don't have a
clear idea what you mean.
+ u8 mac[ETH_ALEN];
Isn't mac address already stored in dev-dev_addr and/or dev-perm_addr?
Yes, I don't see the reason to keep in twice. It's basically a temp
buffer, but it certainly appears we can eliminate it.
thanks,
-chris
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Xen-devel] [RFC PATCH 34/35] Add the Xen virtual network device driver.
* Herbert Xu ([EMAIL PROTECTED]) wrote: Chris Wright [EMAIL PROTECTED] wrote: + netdev-features= NETIF_F_IP_CSUM; Any reason why IP_CSUM was chosen instead of HW_CSUM? Doing the latter would seem to be in fact easier for a virtual driver, no? That, I really don't know. thanks, -chris - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] scm: fold __scm_send() into scm_send()
* Chris Wright ([EMAIL PROTECTED]) wrote:
* Ingo Oeser ([EMAIL PROTECTED]) wrote:
Hi Chris,
Andrew Morton wrote:
Ingo Oeser [EMAIL PROTECTED] wrote:
-int scm_send(struct socket *sock, struct msghdr *msg, struct
scm_cookie *scm)
-{
- struct task_struct *p = current;
- scm-creds = (struct ucred) {
- .uid = p-uid,
- .gid = p-gid,
- .pid = p-tgid
- };
- scm-fp = NULL;
- scm-sid = security_sk_sid(sock-sk, NULL, 0);
- scm-seq = 0;
- if (msg-msg_controllen = 0)
- return 0;
- return __scm_send(sock, msg, scm);
-}
It's worth noting that scm_send() will call security_sk_sid() even if
(msg-msg_controllen = 0).
Chris, do you know if this is needed in this case?
This whole thing is looking broken. I'm still trying to find the original
patch which caused the series of broken patches on top.
OK, it starts here from Catherine's patch:
include/net/scm.h::scm_recv()
+ if (test_bit(SOCK_PASSSEC, sock-flags)) {
+ err = security_sid_to_context(scm-sid, scontext,
scontext_len);
+ if (!err)
+ put_cmsg(msg, SOL_SOCKET, SCM_SECURITY, scontext_len,
scontext);
+ }
Catherine, the security_sid_to_context() is a raw SELinux function which
crept into core code and should not have been there. The fallout fixes
included conditionally exporting security_sid_to_context, and finally
scm_send/recv unlining. The end result in -mm looks broken to me.
Specifically, it now does:
ucred-uid = tsk-uid;
ucred-gid = tsk-gid;
ucred-pid = tsk-tgid;
scm-fp = NULL;
scm-seq = 0;
if (msg-msg_controllen = 0)
return 0;
scm-sid = security_sk_sid(sock-sk, NULL, 0);
The point of Catherine's original patch was to make sure there's always
a security identifier associated with AF_UNIX messages. So receiver
can always check it (same as having credentials even w/out sender
control message passing them). Now we will have garbage for sid.
thanks,
-chris
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] scm: fold __scm_send() into scm_send()
* Andrew Morton ([EMAIL PROTECTED]) wrote: Chris Wright [EMAIL PROTECTED] wrote: Catherine, the security_sid_to_context() is a raw SELinux function which crept into core code and should not have been there. The fallout fixes included conditionally exporting security_sid_to_context, and finally scm_send/recv unlining. Yes. So we're OK up the uninlining, right? Yes, although sid_to_context is meant to be analog to the other get_peersec calls, and should really be made a proper part of the interface (can be done later, correctness is the issue at hand). The end result in -mm looks broken to me. Specifically, it now does: ucred-uid = tsk-uid; ucred-gid = tsk-gid; ucred-pid = tsk-tgid; scm-fp = NULL; scm-seq = 0; if (msg-msg_controllen = 0) return 0; scm-sid = security_sk_sid(sock-sk, NULL, 0); The point of Catherine's original patch was to make sure there's always a security identifier associated with AF_UNIX messages. So receiver can always check it (same as having credentials even w/out sender control message passing them). Now we will have garbage for sid. This answers the question I've been asking all and sundry for a week, thanks ;) So: - scm-fold-__scm_send-into-scm_send.patch is OK Yes. - scm_send-speedup.patch is wrong Yes. - Catherine's patch introduces a possibly-significant performance problem: we're now calling the expensive-on-SELinux security_sk_sid() more frequently than we used to. I don't expect security_sk_sid() to be terribly expensive. It's not an AVC check, it's just propagating a label. But I've not done any benchmarking on that. thanks, -chris - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] scm: fold __scm_send() into scm_send()
* David S. Miller ([EMAIL PROTECTED]) wrote: From: Chris Wright [EMAIL PROTECTED] Date: Mon, 20 Mar 2006 13:36:36 -0800 The point of Catherine's original patch was to make sure there's always a security identifier associated with AF_UNIX messages. So receiver can always check it (same as having credentials even w/out sender control message passing them). Now we will have garbage for sid. I'm seriously considering backing out Catherine's AF_UNIX patch from the net-2.6.17 tree before submitting it to Linus later today so that none of this crap goes in right now. It appears that this needs a lot more sorting out, so for now that's probably the right thing to do. I won't object. I checked your tree, it looks OK to me. The actual broken patch appears in -mm, and the security_sid_to_context snafu is primarily cosmetic at this point (the exports, etc fixed the real compilation issues AFAICT). But, again, if you want to drop that's fine w/ me. I'm sure Catherine can cleanup and resend as needed. thanks, -chris - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 04/39] [PATCH] [BRIDGE]: netfilter missing symbol has_bridge_parent
-stable review patch. If anyone has any objections, please let us know.
--
5dce971acf2ae20c80d5e9d1f6bbf17376870911 in Linus' tree,
otherwise known as bridge-netfilter-races-on-device-removal.patch in
2.5.15.4 removed has_bridge_parent, however this symbol is still
called with NETFILTER_DEBUG is enabled.
This patch uses the already seeded realoutdev value to detect if a parent
exists, and if so, the value of the parent.
Signed-Off-By: Horms [EMAIL PROTECTED]
Acked-by: Stephen Hemminger [EMAIL PROTECTED]
Signed-off-by: Chris Wright [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
---
net/bridge/br_netfilter.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.15.4.orig/net/bridge/br_netfilter.c
+++ linux-2.6.15.4/net/bridge/br_netfilter.c
@@ -794,8 +794,8 @@ static unsigned int br_nf_post_routing(u
print_error:
if (skb-dev != NULL) {
printk([%s], skb-dev-name);
- if (has_bridge_parent(skb-dev))
- printk([%s], bridge_parent(skb-dev)-name);
+ if (realoutdev)
+ printk([%s], realoutdev-name);
}
printk( head:%p, raw:%p, data:%p\n, skb-head, skb-mac.raw,
skb-data);
--
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [stable] [PATCH] [BRIDGE]: netfilter missing symbol has_bridge_parent
* Stephen Hemminger ([EMAIL PROTECTED]) wrote: Horms patch was the best of the three fixes. Dave, already applied Harald's version, so this patch converts that to the better one. Thanks, added Horms' patch to -stable. -chris - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 19/23] [PATCH] bridge: netfilter races on device removal
-stable review patch. If anyone has any objections, please let us know.
--
Fix bridge netfilter to handle case where interface is deleted
from bridge while packet is being processed (on other CPU).
Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=5803
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
Signed-off-by: Chris Wright [EMAIL PROTECTED]
---
net/bridge/br_netfilter.c | 55 +++---
1 files changed, 38 insertions(+), 17 deletions(-)
Index: linux-2.6.15.3/net/bridge/br_netfilter.c
===
--- linux-2.6.15.3.orig/net/bridge/br_netfilter.c
+++ linux-2.6.15.3/net/bridge/br_netfilter.c
@@ -47,9 +47,6 @@
#define store_orig_dstaddr(skb) (skb_origaddr(skb) =
(skb)-nh.iph-daddr)
#define dnat_took_place(skb)(skb_origaddr(skb) != (skb)-nh.iph-daddr)
-#define has_bridge_parent(device) ((device)-br_port != NULL)
-#define bridge_parent(device) ((device)-br_port-br-dev)
-
#ifdef CONFIG_SYSCTL
static struct ctl_table_header *brnf_sysctl_header;
static int brnf_call_iptables = 1;
@@ -94,6 +91,12 @@ static struct rtable __fake_rtable = {
.rt_flags = 0,
};
+static inline struct net_device *bridge_parent(const struct net_device *dev)
+{
+ struct net_bridge_port *port = rcu_dereference(dev-br_port);
+
+ return port ? port-br-dev : NULL;
+}
/* PF_BRIDGE/PRE_ROUTING */
/* Undo the changes made for ip6tables PREROUTING and continue the
@@ -185,11 +188,15 @@ static int br_nf_pre_routing_finish_brid
skb-nf_bridge-mask ^= BRNF_NF_BRIDGE_PREROUTING;
skb-dev = bridge_parent(skb-dev);
- if (skb-protocol == __constant_htons(ETH_P_8021Q)) {
- skb_pull(skb, VLAN_HLEN);
- skb-nh.raw += VLAN_HLEN;
+ if (!skb-dev)
+ kfree_skb(skb);
+ else {
+ if (skb-protocol == __constant_htons(ETH_P_8021Q)) {
+ skb_pull(skb, VLAN_HLEN);
+ skb-nh.raw += VLAN_HLEN;
+ }
+ skb-dst-output(skb);
}
- skb-dst-output(skb);
return 0;
}
@@ -266,7 +273,7 @@ bridged_dnat:
}
/* Some common code for IPv4/IPv6 */
-static void setup_pre_routing(struct sk_buff *skb)
+static struct net_device *setup_pre_routing(struct sk_buff *skb)
{
struct nf_bridge_info *nf_bridge = skb-nf_bridge;
@@ -278,6 +285,8 @@ static void setup_pre_routing(struct sk_
nf_bridge-mask |= BRNF_NF_BRIDGE_PREROUTING;
nf_bridge-physindev = skb-dev;
skb-dev = bridge_parent(skb-dev);
+
+ return skb-dev;
}
/* We only check the length. A bridge shouldn't do any hop-by-hop stuff anyway
*/
@@ -372,7 +381,8 @@ static unsigned int br_nf_pre_routing_ip
nf_bridge_put(skb-nf_bridge);
if ((nf_bridge = nf_bridge_alloc(skb)) == NULL)
return NF_DROP;
- setup_pre_routing(skb);
+ if (!setup_pre_routing(skb))
+ return NF_DROP;
NF_HOOK(PF_INET6, NF_IP6_PRE_ROUTING, skb, skb-dev, NULL,
br_nf_pre_routing_finish_ipv6);
@@ -409,7 +419,6 @@ static unsigned int br_nf_pre_routing(un
if (skb-protocol == __constant_htons(ETH_P_8021Q)) {
skb_pull(skb, VLAN_HLEN);
- (skb)-nh.raw += VLAN_HLEN;
}
return br_nf_pre_routing_ipv6(hook, skb, in, out, okfn);
}
@@ -426,7 +435,6 @@ static unsigned int br_nf_pre_routing(un
if (skb-protocol == __constant_htons(ETH_P_8021Q)) {
skb_pull(skb, VLAN_HLEN);
- (skb)-nh.raw += VLAN_HLEN;
}
if (!pskb_may_pull(skb, sizeof(struct iphdr)))
@@ -456,7 +464,8 @@ static unsigned int br_nf_pre_routing(un
nf_bridge_put(skb-nf_bridge);
if ((nf_bridge = nf_bridge_alloc(skb)) == NULL)
return NF_DROP;
- setup_pre_routing(skb);
+ if (!setup_pre_routing(skb))
+ return NF_DROP;
store_orig_dstaddr(skb);
NF_HOOK(PF_INET, NF_IP_PRE_ROUTING, skb, skb-dev, NULL,
@@ -530,11 +539,16 @@ static unsigned int br_nf_forward_ip(uns
struct sk_buff *skb = *pskb;
struct nf_bridge_info *nf_bridge;
struct vlan_ethhdr *hdr = vlan_eth_hdr(skb);
+ struct net_device *parent;
int pf;
if (!skb-nf_bridge)
return NF_ACCEPT;
+ parent = bridge_parent(out);
+ if (!parent)
+ return NF_DROP;
+
if (skb-protocol == __constant_htons(ETH_P_IP) || IS_VLAN_IP)
pf = PF_INET;
else
@@ -555,8 +569,8 @@ static unsigned int br_nf_forward_ip(uns
nf_bridge-mask |= BRNF_BRIDGED;
nf_bridge-physoutdev = skb-dev;
- NF_HOOK(pf, NF_IP_FORWARD, skb, bridge_parent(in),
- bridge_parent(out), br_nf_forward_finish
Re: [PATCH 2/2] LSM-IPSec Network Hooks
* Trent Jaeger ([EMAIL PROTECTED]) wrote: Patch with sock callback lock made unconditional. Previous send (earlier today, 11/17) was not the latest patch -- please disregard that patch. Little heavy on KERN_DEBUG printk's. Could you drop them (or perhaps use pr_debug instead)? thanks, -chris - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
