Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH 2/3] net: packet: fix information leak to userland
From: walter harms @ 2010-11-01  9:14 UTC (permalink / raw)
  To: Vasiliy Kulikov
  Cc: kernel-janitors, David S. Miller, Jiri Pirko, Eric Dumazet,
	netdev, linux-kernel
In-Reply-To: <1288545028-16436-1-git-send-email-segooon@gmail.com>



Vasiliy Kulikov schrieb:
> packet_getname_spkt() doesn't initialize all members of sa_data field of
> sockaddr struct if strlen(dev->name) < 13.  This structure is then copied
> to userland.  It leads to leaking of contents of kernel stack memory.
> We have to fully fill sa_data with strncpy() instead of strlcpy().
> 
> The same with packet_getname(): it doesn't initialize sll_pkttype field of
> sockaddr_ll.  Set it to zero.
> 
> Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
> ---
>  net/packet/af_packet.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
> index 3616f27..0856a13 100644
> --- a/net/packet/af_packet.c
> +++ b/net/packet/af_packet.c
> @@ -1719,7 +1719,7 @@ static int packet_getname_spkt(struct socket *sock, struct sockaddr *uaddr,
>  	rcu_read_lock();
>  	dev = dev_get_by_index_rcu(sock_net(sk), pkt_sk(sk)->ifindex);
>  	if (dev)
> -		strlcpy(uaddr->sa_data, dev->name, 15);
> +		strncpy(uaddr->sa_data, dev->name, 14);
>  	else
>  		memset(uaddr->sa_data, 0, 14);

if i understand the code correcly the max size for dev->name is IFNAMSIZ.
You can simply that part:

memset(uaddr->sa_data, 0, IFNAMSIZ);
dev = dev_get_by_index_rcu(sock_net(sk), pkt_sk(sk)->ifindex);
if (dev)
	strlcpy(uaddr->sa_data, dev->name, IFNAMSIZ);


you should send that as separate patch.
re,
 wh


>  	rcu_read_unlock();
> @@ -1742,6 +1742,7 @@ static int packet_getname(struct socket *sock, struct sockaddr *uaddr,
>  	sll->sll_family = AF_PACKET;
>  	sll->sll_ifindex = po->ifindex;
>  	sll->sll_protocol = po->num;
> +	sll->sll_pkttype = 0;
>  	rcu_read_lock();
>  	dev = dev_get_by_index_rcu(sock_net(sk), po->ifindex);
>  	if (dev) {

^ permalink raw reply

* Re: [RFC PATCH] macvlan: Introduce a PASSTHRU mode to takeover the underlying device
From: Michael S. Tsirkin @ 2010-11-01  8:28 UTC (permalink / raw)
  To: Sridhar Samudrala; +Cc: kaber, Arnd Bergmann, netdev, kvm@vger.kernel.org
In-Reply-To: <1288131578.7582.49.camel@sridhar.beaverton.ibm.com>

On Tue, Oct 26, 2010 at 03:19:38PM -0700, Sridhar Samudrala wrote:
> With the current default macvtap mode, a KVM guest using virtio with 
> macvtap backend has the following limitations.
> - cannot change/add a mac address on the guest virtio-net
> - cannot create a vlan device on the guest virtio-net
> - cannot enable promiscuous mode on guest virtio-net
> 
> This patch introduces a new mode called 'passthru' when creating a 
> macvlan device which allows takeover of the underlying device and 
> passing it to a guest using virtio with macvtap backend.
> 
> Only one macvlan device is allowed in passthru mode and it inherits
> the mac address from the underlying device and sets it in promiscuous 
> mode to receive and forward all the packets.
> 
> Thanks
> Sridhar

One concern with promisc mode is that for the common case,
which is a single mac and no vlans, we will be getting
extra packets that will get dropped in userspace/guest
as compared to the case where same mac is programmed
in hardware and by guest.

We could let userspace supply a list of mac/vlan addresses through
an ioctl on macvtap, and then
1. for a single mac, program it in hardware
2. for other configurations, set promisc mode

tun already has TUNSETTXFILTER which might come in handy here.
We don't pass in vlans with the filter now but maybe we should.
How does this sound?

> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
> index 0ef0eb0..bca3cb7 100644
> --- a/drivers/net/macvlan.c
> +++ b/drivers/net/macvlan.c
> @@ -38,6 +38,7 @@ struct macvlan_port {
>  	struct hlist_head	vlan_hash[MACVLAN_HASH_SIZE];
>  	struct list_head	vlans;
>  	struct rcu_head		rcu;
> +	bool 			passthru;
>  };
>  
>  #define macvlan_port_get_rcu(dev) \
> @@ -169,6 +170,7 @@ static struct sk_buff *macvlan_handle_frame(struct sk_buff *skb)
>  			macvlan_broadcast(skb, port, NULL,
>  					  MACVLAN_MODE_PRIVATE |
>  					  MACVLAN_MODE_VEPA    |
> +					  MACVLAN_MODE_PASSTHRU|
>  					  MACVLAN_MODE_BRIDGE);
>  		else if (src->mode == MACVLAN_MODE_VEPA)
>  			/* flood to everyone except source */
> @@ -185,7 +187,10 @@ static struct sk_buff *macvlan_handle_frame(struct sk_buff *skb)
>  		return skb;
>  	}
>  
> -	vlan = macvlan_hash_lookup(port, eth->h_dest);
> +	if (port->passthru)
> +		vlan = list_first_entry(&port->vlans, struct macvlan_dev, list);
> +	else
> +		vlan = macvlan_hash_lookup(port, eth->h_dest);
>  	if (vlan == NULL)
>  		return skb;
>  
> @@ -284,6 +289,11 @@ static int macvlan_open(struct net_device *dev)
>  	struct net_device *lowerdev = vlan->lowerdev;
>  	int err;
>  
> +	if (vlan->port->passthru) {
> +		dev_set_promiscuity(lowerdev, 1);
> +		goto hash_add;
> +	}
> +
>  	err = -EBUSY;
>  	if (macvlan_addr_busy(vlan->port, dev->dev_addr))
>  		goto out;
> @@ -296,6 +306,8 @@ static int macvlan_open(struct net_device *dev)
>  		if (err < 0)
>  			goto del_unicast;
>  	}
> +
> +hash_add:
>  	macvlan_hash_add(vlan);
>  	return 0;
>  
> @@ -310,12 +322,18 @@ static int macvlan_stop(struct net_device *dev)
>  	struct macvlan_dev *vlan = netdev_priv(dev);
>  	struct net_device *lowerdev = vlan->lowerdev;
>  
> +	if (vlan->port->passthru) {
> +		dev_set_promiscuity(lowerdev, -1);
> +		goto hash_del;
> +	}
> +
>  	dev_mc_unsync(lowerdev, dev);
>  	if (dev->flags & IFF_ALLMULTI)
>  		dev_set_allmulti(lowerdev, -1);
>  
>  	dev_uc_del(lowerdev, dev->dev_addr);
>  
> +hash_del:
>  	macvlan_hash_del(vlan);
>  	return 0;
>  }
> @@ -549,6 +567,7 @@ static int macvlan_port_create(struct net_device *dev)
>  	if (port == NULL)
>  		return -ENOMEM;
>  
> +	port->passthru = false;
>  	port->dev = dev;
>  	INIT_LIST_HEAD(&port->vlans);
>  	for (i = 0; i < MACVLAN_HASH_SIZE; i++)
> @@ -593,6 +612,7 @@ static int macvlan_validate(struct nlattr *tb[], struct nlattr *data[])
>  		case MACVLAN_MODE_PRIVATE:
>  		case MACVLAN_MODE_VEPA:
>  		case MACVLAN_MODE_BRIDGE:
> +		case MACVLAN_MODE_PASSTHRU:
>  			break;
>  		default:
>  			return -EINVAL;
> @@ -661,6 +681,10 @@ int macvlan_common_newlink(struct net *src_net, struct net_device *dev,
>  	}
>  	port = macvlan_port_get(lowerdev);
>  
> +	/* Only 1 macvlan device can be created in passthru mode */
> +	if (port->passthru)
> +		return -EINVAL;
> +
>  	vlan->lowerdev = lowerdev;
>  	vlan->dev      = dev;
>  	vlan->port     = port;
> @@ -671,6 +695,13 @@ int macvlan_common_newlink(struct net *src_net, struct net_device *dev,
>  	if (data && data[IFLA_MACVLAN_MODE])
>  		vlan->mode = nla_get_u32(data[IFLA_MACVLAN_MODE]);
>  
> +	if (vlan->mode == MACVLAN_MODE_PASSTHRU) {
> +		if (!list_empty(&port->vlans))
> +			return -EINVAL;
> +		port->passthru = true;
> +		memcpy(dev->dev_addr, lowerdev->dev_addr, ETH_ALEN);
> +	}
> +
>  	err = register_netdevice(dev);
>  	if (err < 0)
>  		goto destroy_port;
> diff --git a/include/linux/if_link.h b/include/linux/if_link.h
> index 2fc66dd..8454805 100644
> --- a/include/linux/if_link.h
> +++ b/include/linux/if_link.h
> @@ -232,6 +232,7 @@ enum macvlan_mode {
>  	MACVLAN_MODE_PRIVATE = 1, /* don't talk to other macvlans */
>  	MACVLAN_MODE_VEPA    = 2, /* talk to other ports through ext bridge */
>  	MACVLAN_MODE_BRIDGE  = 4, /* talk to bridge ports directly */
> +	MACVLAN_MODE_PASSTHRU = 8,/* take over the underlying device */
>  };
>  
>  /* SR-IOV virtual function management section */
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* [PATCH RFC] tun: remove of user-controlled memory allocation
From: Michael S. Tsirkin @ 2010-11-01  8:27 UTC (permalink / raw)
  Cc: David S. Miller, Michael S. Tsirkin, Herbert Xu, Eric Dumazet,
	Joe Perches, netdev, linux-kernel

Untested, this is just an RFC.

tun does a kmalloc where userspace controls the length. This will
produce warnings in kernel log when the length is too large, or might
block for a long while. A simple fix is to avoid the allocatiuon
altogether, and copy from user in a loop.

However, with this patch an illegal address passed to the ioctl might
leave the filter disabled.  Is this something we care about?  If
yes we could recover by creating a copy of the filter.  Thoughts?

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
 drivers/net/tun.c |   30 ++++++++++++++----------------
 1 files changed, 14 insertions(+), 16 deletions(-)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 55f3a3e..ea36888 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -220,28 +220,23 @@ static unsigned int addr_hash_test(const u32 *mask, const u8 *addr)
 
 static int update_filter(struct tap_filter *filter, void __user *arg)
 {
-	struct { u8 u[ETH_ALEN]; } *addr;
+	struct { u8 u[ETH_ALEN]; } __user *addr;
 	struct tun_filter uf;
-	int err, alen, n, nexact;
+	int err = -EFAULT, n, nexact;
 
 	if (copy_from_user(&uf, arg, sizeof(uf)))
-		return -EFAULT;
+		goto done;
 
 	if (!uf.count) {
 		/* Disabled */
 		filter->count = 0;
-		return 0;
+		err = 0;
+		goto done;
 	}
 
-	alen = ETH_ALEN * uf.count;
-	addr = kmalloc(alen, GFP_KERNEL);
-	if (!addr)
-		return -ENOMEM;
-
-	if (copy_from_user(addr, arg + sizeof(uf), alen)) {
-		err = -EFAULT;
+	addr = arg + sizeof(uf);
+	if (!access_ok(VERIFY_READ, addr, ETH_ALEN * uf.count))
 		goto done;
-	}
 
 	/* The filter is updated without holding any locks. Which is
 	 * perfectly safe. We disable it first and in the worst
@@ -251,7 +246,8 @@ static int update_filter(struct tap_filter *filter, void __user *arg)
 
 	/* Use first set of addresses as an exact filter */
 	for (n = 0; n < uf.count && n < FLT_EXACT_COUNT; n++)
-		memcpy(filter->addr[n], addr[n].u, ETH_ALEN);
+		if (__copy_from_user(filter->addr[n], addr[n].u, ETH_ALEN))
+			goto done;
 
 	nexact = n;
 
@@ -259,11 +255,14 @@ static int update_filter(struct tap_filter *filter, void __user *arg)
 	 * unicast will leave the filter disabled. */
 	memset(filter->mask, 0, sizeof(filter->mask));
 	for (; n < uf.count; n++) {
-		if (!is_multicast_ether_addr(addr[n].u)) {
+		u8 u[ETH_ALEN];
+		if (__copy_from_user(u, addr[n].u, ETH_ALEN))
+			goto done;
+		if (!is_multicast_ether_addr(u)) {
 			err = 0; /* no filter */
 			goto done;
 		}
-		addr_hash_set(filter->mask, addr[n].u);
+		addr_hash_set(filter->mask, u);
 	}
 
 	/* For ALLMULTI just set the mask to all ones.
@@ -279,7 +278,6 @@ static int update_filter(struct tap_filter *filter, void __user *arg)
 	err = nexact;
 
 done:
-	kfree(addr);
 	return err;
 }
 
-- 
1.7.3.2.91.g446ac

^ permalink raw reply related

* Re: [patch] netlink: use TID instead of PID for automatic id assignment
From: Jan Engelhardt @ 2010-11-01  8:27 UTC (permalink / raw)
  To: Herbert Xu; +Cc: David S. Miller, netdev
In-Reply-To: <20101101022548.GA27367@gondor.apana.org.au>


On Monday 2010-11-01 03:25, Herbert Xu wrote:
>> 
>> netlink: use TID instead of PID for automatic id assignment
>> 
>> This makes it easier to identify processes in the output of `ss -af
>> netlink` - as I see no reason to force negative space numbers upon
>> all but the first socket in a thread group.
>> 
>> Turns out this reverts v2.6.15-rc4~65.
>> 
>> Cc: Herbert Xu <herbert@gondor.apana.org.au>
>> Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
>
>Nack.  Sockets are typically shared amongst threads so using the
>ID of the thread that created it doesn't make much sense when
>all the threads in that group use it to send/receive messages.

That would be fine, because they are in the same process.

>In any case, this field should not be relied on (please google
>the thread "netlink nlmsg_pid supposed to be pid or tid?") as
>anybody can claim your PID in the netlink name space.

I am aware of that. But then it raises the question why we are
giving the first socket a non-negative value in the first place.

^ permalink raw reply

* Re: [PATCH net-next-2.6 v2] can: Topcliff: PCH_CAN driver: Fix build warnings
From: Tomoya MORINAGA @ 2010-11-01  7:15 UTC (permalink / raw)
  To: Marc Kleine-Budde
  Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w, Masayuki Ohtake,
	Samuel Ortiz, margie.foster-ral2JQCrhuEAvxtiuMwx3w,
	netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
	yong.y.wang-ral2JQCrhuEAvxtiuMwx3w,
	kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w, Wolfgang Grandegger,
	joel.clark-ral2JQCrhuEAvxtiuMwx3w, David S. Miller,
	Christian Pellegrin, qi.wang-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <4CCAC4CD.7000503@pengutronix.de>

On Friday, October 29, 2010 9:57 PM : Marc Kleine-Budde wrote:
>>>> SW must check busy flag of CAN register.
>>>> This is a Topcliff HW specification.
>>> Maybe the busy check could also be done *before* the Message RAM is
>>> accessed to avoid (or minimize) waiting.
>> Yes, *before* is right.
>> If there is *after* processing, this is a bug.
>> Can you see anyway ?
>Sorry I don't understand what you mean.

Sorry, my English had mistake. I show my comment below again.
 - If there is *after* processing, this is a bug.
 - Can you see the point anywhere ?

> You probably know the datasheet, but I don't, although I've printed
> chapter 13 from the Intel Controller Hub EG20T datasheet, but it's 50+
> pages. If the hardware needs the busy waiting in the hot tx path a
> pointer to the respective section in the manual is a good idea. Just
> something like:

Though "Oliver Hartkopp" found the place of Datasheet EG20T and notified with the mailing-list,
Have you read the following ?
http://edc.intel.com/Platforms/Atom-E6xx/#hardware

>>> You have to change the definition of the regs struct a bit:
>>>>  u32 if1_mcont;
>>>>  u32 if1_data[4];
>>>>  u32 reserve2;
>> Uh, I can't find this. Where is this ?
>Here's a patch to illustrate what I meant:
I understand.


Thanks, Tomoya(OKI SEMICONDUCTOR CO., LTD.)

^ permalink raw reply

* Re: [PATCH] OF device tree: Move of_get_mac_address() to a common source file.
From: Grant Likely @ 2010-11-01  5:17 UTC (permalink / raw)
  To: David Daney
  Cc: linux-mips, Corey Minyard, Anton Vorontsov, Paul Mackerras,
	Sadanand Mutyala, Sergey Matyukevich, Sean MacLennan,
	Wolfgang Denk, microblaze-uclinux, devicetree-discuss,
	Andres Salomon, Michal Simek, Anatolij Gustschin, Eric Dumazet,
	Jiri Pirko, netdev, linux-kernel, ralf, Sandeep Gopalpet,
	Vitaly Bordug, linuxppc-dev, David S. Miller
In-Reply-To: <1288130833-16421-1-git-send-email-ddaney@caviumnetworks.com>

On Tue, Oct 26, 2010 at 03:07:13PM -0700, David Daney wrote:
> There are two identical implementations of of_get_mac_address(), one
> each in arch/powerpc/kernel/prom_parse.c and
> arch/microblaze/kernel/prom_parse.c.  Move this function to a new
> common file of_net.{c,h} and adjust all the callers to include the new
> header.

Applied, thanks; but made some changes to protect this code because it
does not work on little endian (it can be fixed in a separate patch)

Also...

> 
> Signed-off-by: David Daney <ddaney@caviumnetworks.com>
> Cc: Michal Simek <monstr@monstr.eu>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Wolfram Sang <w.sang@pengutronix.de>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Corey Minyard <cminyard@mvista.com>
> Cc: Pantelis Antoniou <pantelis.antoniou@gmail.com>
> Cc: Vitaly Bordug <vbordug@ru.mvista.com>
> Cc: Anatolij Gustschin <agust@denx.de>
> Cc: John Rigby <jcrigby@gmail.com>
> Cc: Wolfgang Denk <wd@denx.de>
> Cc: Anton Vorontsov <avorontsov@mvista.com>
> Cc: Sandeep Gopalpet <Sandeep.Kumar@freescale.com>
> Cc: Kumar Gala <galak@kernel.crashing.org>
> Cc: Li Yang <leoli@freescale.com>
> Cc: Sergey Matyukevich <geomatsi@gmail.com>
> Cc: Jiri Pirko <jpirko@redhat.com>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Sean MacLennan <smaclennan@pikatech.com>
> Cc: Sadanand Mutyala <Sadanand.Mutyala@xilinx.com>
> Cc: Andres Salomon <dilinger@queued.net>
> Cc: microblaze-uclinux@itee.uq.edu.au
> Cc: linux-kernel@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: netdev@vger.kernel.org
> Cc: devicetree-discuss@lists.ozlabs.org

You don't need to believe everything that get_maintainers is telling
you.  When you get a large list like this, don't Cc everyone, but
apply some educated guesses.  You can guess that the PowerPC and
Microblaze maintainers care because it touches their trees, and you
can guess that I care because I'm the dt maintainer. David Miller
isn't a bad guess because of networking.  But 22 people is excessive.

g.

^ permalink raw reply

* RE: [PATCH] qlcnic: fix panic on load
From: Amit Salecha @ 2010-11-01  4:58 UTC (permalink / raw)
  To: Eric Dumazet, David Miller; +Cc: netdev
In-Reply-To: <1288540238.2660.50.camel@edumazet-laptop>

> From: Eric Dumazet [eric.dumazet@gmail.com]
> Sent: Sunday, October 31, 2010 9:20 PM
> To: David Miller
> Cc: netdev; Amit Salecha
> Subject: [PATCH] qlcnic: fix panic on load
> 
> Its now illegal to call netif_stop_queue() before register_netdev()
> 
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Amit Kumar Salecha <amit.salecha@qlogic.com>
> ---
> drivers/net/qlcnic/qlcnic_main.c |    1 -
> 1 file changed, 1 deletion(-)

Thanks Eric.

^ permalink raw reply

* RE: NULL pointer dereference at netxen_nic_probe+0x813/0x9a0
From: Amit Salecha @ 2010-11-01  4:56 UTC (permalink / raw)
  To: Denis Kirjanov, David Miller
  Cc: bjorn.helgaas@hp.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
In-Reply-To: <4CCC7868.60104@kernel.org>

> Ok, thanks Dave, now I see.
>
> [PATCH] netxen_nic: Fix the tx queue manipulation bug in netxen_nic_probe
>
> We should not stop the egress queue during probe because it is wrong.
>
>Signed-off-by: Denis Kirjanov <dkirjanov@kernel.org>
> ---
> drivers/net/netxen/netxen_nic_main.c |    1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)

Thanks Denis, for fixing this.

^ permalink raw reply

* Re: [patch v3] fix stack overflow in pktgen_if_write()
From: Dan Carpenter @ 2010-11-01  3:47 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Nelson Elhage, Eric Dumazet, David S. Miller, Robert Olsson,
	Andy Shevchenko, netdev
In-Reply-To: <87lj5hud36.fsf@basil.nowhere.org>

> > @@ -887,12 +887,17 @@ static ssize_t pktgen_if_write(struct file *file,
> >  	i += len;
> >  
> >  	if (debug) {
> > -		char tb[count + 1];
> > +		char *tb;
> > +
> > +		tb = kmalloc(count + 1, GFP_KERNEL);
> 
> 
> This is still trivially exploitable (for root) -- think what happens
> when count is near ULONG_MAX
> 

In vfs_write() we call rw_verify_area() which caps count at INT_MAX or
LONG_MAX.

        if (unlikely((ssize_t) count < 0))
                return retval;

So I get lucky this time...  ;)

regards,
dan carpenter

^ permalink raw reply

* RE: About the Davicom PHY in drivers/net/phy in Linux kernel
From: Joseph Chang @ 2010-11-01  2:27 UTC (permalink / raw)
  To: macpaul, netdev; +Cc: afleming, jeff, f.rodo
In-Reply-To: <50FD90C65C53FB45BADEEBCD84FF07F202A62479@ATCPCS06.andestech.com>

Dear MacPaul,

   1.Yes. I have downloaded it. And below is the know items.
   
     DM9161A
     cpu: Faraday A320 (arm920t) + Andes AG101 (NDS32) ;SoC
     OS: Linux: 2.6.32
     Actions:
       - davicom.c             // Download from LXR
       - include-linux-mii.h   // Download from LXR

   2.Your quote is right. Please tell us the test result.

   3.I have a question for you,
   Where is your company? I browse for andestech, And found that andestech located at
    SiSoft SIPP Center! (Address: 2F, No.1, Li-Hsin First Road, Science-Based Industrial Park) 
    Is it right? 

Best Regards,
Joseph CHANG 
System Application Engineering Division 
Davicom Semiconductor, Inc. 
No. 6 Li-Hsin Rd. VI, Science-Based Park, 
Hsin-Chu, Taiwan. 
Tel: 886-3-5798797 Ex 8534
Fax: 886-3-5646929 
Web: http://www.davicom.com.tw 

-----Original Message-----
From: macpaul@andestech.com [mailto:macpaul@andestech.com] 
Sent: Friday, October 29, 2010 3:47 PM
To: joseph_chang@mail.davicom.com.tw; netdev@vger.kernel.org
Cc: afleming@freescale.com; jeff@garzik.org; f.rodo@til-technologies.fr
Subject: RE: About the Davicom PHY in drivers/net/phy in Linux kernel

Hi Joseph,

I just followed up your suggestion in previous mail, let me quote them here:

# quote
The recommend is changed to be as below:
 err = phy_write(phydev, MII_BMCR, BMCR_RESET);
    //err = phy_write(phydev, MII_BMCR, BMCR_ISOLATE);
   err = phy_write(phydev, MII_DM9161_SCR, MII_DM9161_SCR_INIT);
   err = phy_write(phydev, MII_DM9161_10BTCSR, MII_DM9161_10BTCSR_INIT);
  // err = phy_write(phydev, MII_NWAYTEST, 0x10);
    err = phy_write(phydev, MII_BMCR, BMCR_ANENABLE | BMCR_ANRESTART);
  *Note: Added a PHY reset command.
# end quote
> 
>  * == > Would you tell us your:
> 	CPU = ?
SoC: Faraday A320 (arm920t) / Andes AG101 (NDS32)
> 	Linux Kernel version= ?
Linux: 2.6.32
>       I will like to download the same source code from LXR.
>       And can check more detail for you.

I've believed that you have download the source already. :-)



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



^ permalink raw reply

* Re: [patch] netlink: use TID instead of PID for automatic id assignment
From: Herbert Xu @ 2010-11-01  2:25 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: David S. Miller, netdev
In-Reply-To: <alpine.LNX.2.01.1010312013100.20872@obet.zrqbmnf.qr>

On Sun, Oct 31, 2010 at 08:14:00PM +0100, Jan Engelhardt wrote:
> parent 3985c7ce85039adacdf882904ca096f091d39346 (v2.6.36-9871-g3985c7c)
> commit 183ded547d51508f23f6c18a999f6c165e66c99e
> Author: Jan Engelhardt <jengelh@medozas.de>
> Date:   Sun Oct 31 20:09:36 2010 +0100
> 
> netlink: use TID instead of PID for automatic id assignment
> 
> This makes it easier to identify processes in the output of `ss -af
> netlink` - as I see no reason to force negative space numbers upon
> all but the first socket in a thread group.
> 
> Turns out this reverts v2.6.15-rc4~65.
> 
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Signed-off-by: Jan Engelhardt <jengelh@medozas.de>

Nack.  Sockets are typically shared amongst threads so using the
ID of the thread that created it doesn't make much sense when
all the threads in that group use it to send/receive messages.

In any case, this field should not be relied on (please google
the thread "netlink nlmsg_pid supposed to be pid or tid?") as
anybody can claim your PID in the netlink name space.

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

* Attention
From: EXXON MOBIL OIL&GAS COMPANY @ 2010-10-31 23:56 UTC (permalink / raw)






You have been awarded the sum of 850.000.00 USD. in the EXXON-MOBIL OIL AND GAS COMPANY AWARD 2010.Cont Mr. Fred Peterson with your Names, Address, Phone No to Email: noticeofclaims01@gala.net or call:+2348073988052 for more info on this award

^ permalink raw reply

* Re: [ANNOUNCE] Host Fabric Interface (HFI) device driver available on sourceforge
From: Jim Dykman @ 2010-10-31 19:43 UTC (permalink / raw)
  To: David Miller; +Cc: netdev
In-Reply-To: <20101030.210806.232732630.davem@davemloft.net>

On 10/31/2010 12:08 AM, David Miller wrote:
> From: Jim Dykman<dykmanj@linux.vnet.ibm.com>
> Date: Sat, 30 Oct 2010 23:10:27 -0400
>
>> The HFI network interface is the internal cluster fabric of IBM's
>> PERCS supercomputer. The device driver patch for 2.6.36, hfi-utils,
>> and an introduction to the hardware are available on the sourceforge
>> page (http://sourceforge.net/projects/hfidevicedriver). The hardware
>> design is under US export control, so we cannot release hardware
>> specs.
>
> Nobody is going to look at your code, let alone help review it
> for inclusion, if you just say "go look at this stuff on this
> sourceforge web site."
>
> You have to post the kernel patches here, one by one.

Sorry, thought I was following the instructions for large patches in 
Documentation/SubmittingPatches. It is currently one patch of about 
22000 lines, around 630k.

Most of the patch is new files, I'm figuring one file per email.
There are 2 files just under 3000 lines, 4 in the 1000-1700 line range, 
and some smaller ones. Do I need to break any of those up further?

Jim Dykman


^ permalink raw reply

* [patch] netlink: use TID instead of PID for automatic id assignment
From: Jan Engelhardt @ 2010-10-31 19:14 UTC (permalink / raw)
  To: David S. Miller; +Cc: netdev, Herbert Xu

parent 3985c7ce85039adacdf882904ca096f091d39346 (v2.6.36-9871-g3985c7c)
commit 183ded547d51508f23f6c18a999f6c165e66c99e
Author: Jan Engelhardt <jengelh@medozas.de>
Date:   Sun Oct 31 20:09:36 2010 +0100

netlink: use TID instead of PID for automatic id assignment

This makes it easier to identify processes in the output of `ss -af
netlink` - as I see no reason to force negative space numbers upon
all but the first socket in a thread group.

Turns out this reverts v2.6.15-rc4~65.

Cc: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
---
 net/netlink/af_netlink.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 478181d..568d07c 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -545,7 +545,7 @@ static int netlink_autobind(struct socket *sock)
 	struct hlist_head *head;
 	struct sock *osk;
 	struct hlist_node *node;
-	s32 pid = task_tgid_vnr(current);
+	s32 pid = task_pid_vnr(current);
 	int err;
 	static s32 rover = -4097;
 
-- 
# Created with git-export-patch


^ permalink raw reply related

* Re: [PATCH 1/2] af_unix: fix unix_dgram_poll() behavior for EPOLLOUT event
From: Davide Libenzi @ 2010-10-31 19:07 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: Alban Crequy, David Miller, netdev
In-Reply-To: <1288539383.2660.38.camel@edumazet-laptop>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3498 bytes --]

On Sun, 31 Oct 2010, Eric Dumazet wrote:

> Le samedi 30 octobre 2010 à 22:47 +0100, Alban Crequy a écrit :
> > Le Sat, 30 Oct 2010 15:17:58 +0200,
> > Eric Dumazet <eric.dumazet@gmail.com> a écrit :
> > 
> > > > Problem is the peer_wait, that epoll doesnt seem to be plugged into.
> > > > 
> > > > Bug is in unix_dgram_poll()
> > > > 
> > > > It calls sock_poll_wait( ... &unix_sk(other)->peer_wait,) only if
> > > > socket is 'writable'. Its a clear bug
> > 
> > Yes, it looks weird...
> > 
> > > > Try this patch please ?
> > 
> > I will be away from computer and I will continue to work on this from
> > the 20th of November.
> 
> OK, no problem. I tried it and it solves the problem. Here is an
> official patch submission.
> 
> David, for your convenience, I cooked a patch serie for the 2 patches
> against af_unix unix_dgram_poll().

Looks good to me...

Acked-by: Davide Libenzi <davidel@xmailserver.org>




> The third patch (af_unix: unix_write_space() use keyed wakeups)) can be
> applied as is.
> 
> Thanks !
> 
> [PATCH 1/2] af_unix: fix unix_dgram_poll() behavior for EPOLLOUT event
> 
> Alban Crequy reported a problem with connected dgram af_unix sockets and
> provided a test program. epoll() would miss to send an EPOLLOUT event
> when a thread unqueues a packet from the other peer, making its receive
> queue not full.
> 
> This is because unix_dgram_poll() fails to call sock_poll_wait(file,
> &unix_sk(other)->peer_wait, wait);
> if the socket is not writeable at the time epoll_ctl(ADD) is called. 
> 
> We must call sock_poll_wait(), regardless of 'writable' status, so that
> epoll can be notified later of states changes.
> 
> Misc: avoids testing twice (sk->sk_shutdown & RCV_SHUTDOWN)
> 
> Reported-by: Alban Crequy <alban.crequy@collabora.co.uk>
> Cc: Davide Libenzi <davidel@xmailserver.org>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
>  net/unix/af_unix.c |   24 +++++++++---------------
>  1 file changed, 9 insertions(+), 15 deletions(-)
> 
> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
> index 0ebc777..7375131 100644
> --- a/net/unix/af_unix.c
> +++ b/net/unix/af_unix.c
> @@ -2072,13 +2072,12 @@ static unsigned int unix_dgram_poll(struct file *file, struct socket *sock,
>  	if (sk->sk_err || !skb_queue_empty(&sk->sk_error_queue))
>  		mask |= POLLERR;
>  	if (sk->sk_shutdown & RCV_SHUTDOWN)
> -		mask |= POLLRDHUP;
> +		mask |= POLLRDHUP | POLLIN | POLLRDNORM;
>  	if (sk->sk_shutdown == SHUTDOWN_MASK)
>  		mask |= POLLHUP;
>  
>  	/* readable? */
> -	if (!skb_queue_empty(&sk->sk_receive_queue) ||
> -	    (sk->sk_shutdown & RCV_SHUTDOWN))
> +	if (!skb_queue_empty(&sk->sk_receive_queue))
>  		mask |= POLLIN | POLLRDNORM;
>  
>  	/* Connection-based need to check for termination and startup */
> @@ -2090,20 +2089,15 @@ static unsigned int unix_dgram_poll(struct file *file, struct socket *sock,
>  			return mask;
>  	}
>  
> -	/* writable? */
>  	writable = unix_writable(sk);
> -	if (writable) {
> -		other = unix_peer_get(sk);
> -		if (other) {
> -			if (unix_peer(other) != sk) {
> -				sock_poll_wait(file, &unix_sk(other)->peer_wait,
> -					  wait);
> -				if (unix_recvq_full(other))
> -					writable = 0;
> -			}
> -
> -			sock_put(other);
> +	other = unix_peer_get(sk);
> +	if (other) {
> +		if (unix_peer(other) != sk) {
> +			sock_poll_wait(file, &unix_sk(other)->peer_wait, wait);
> +			if (unix_recvq_full(other))
> +				writable = 0;
>  		}
> +		sock_put(other);
>  	}
>  
>  	if (writable)
> 


- Davide


^ permalink raw reply

* [SECURITY] L2TP send buffer allocation size overflows
From: Dan Rosenberg @ 2010-10-31 18:14 UTC (permalink / raw)
  To: jchapman; +Cc: netdev, security

Both PPPoL2TP (in net/l2tp/l2tp_ppp.c, pppol2tp_sendmsg()) and IPoL2TP
(in net/l2tp/l2tp_ip.c, l2tp_ip_sendmsg()) make calls to sock_wmalloc()
that perform arithmetic on the size argument without any maximum bound.
As a result, by issuing sendto() calls with very large sizes, this
allocation size will wrap and result in a small buffer being allocated,
leading to ugliness immediately after (probably kernel panics due to bad
sk_buff tail position, but possibly kernel heap corruption).

This issue was just fixed in the core code with:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=253eacc070b114c2ec1f81b067d2fed7305467b0

Even though this won't be an issue for much longer, it should still be
fixed here just in case any paths to calling these functions with large
sizes are left open.

-Dan


^ permalink raw reply

* Re: [PATCH 1/3] net: ax25: fix information leak to userland
From: Eric Dumazet @ 2010-10-31 18:08 UTC (permalink / raw)
  To: Vasiliy Kulikov
  Cc: kernel-janitors, Joerg Reuter, Ralf Baechle, David S. Miller,
	linux-hams, netdev, linux-kernel
In-Reply-To: <1288545022-16393-1-git-send-email-segooon@gmail.com>

Le dimanche 31 octobre 2010 à 20:10 +0300, Vasiliy Kulikov a écrit :
> Sometimes ax25_getname() doesn't initialize all members of fsa_digipeater
> field of fsa struct.  This structure is then copied to userland.  It leads to
> leaking of contents of kernel stack memory.  We have to initialize them to zero.
> 
> Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
> ---
>  net/ax25/af_ax25.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c
> index 26eaebf..a324d83 100644
> --- a/net/ax25/af_ax25.c
> +++ b/net/ax25/af_ax25.c
> @@ -1392,6 +1392,7 @@ static int ax25_getname(struct socket *sock, struct sockaddr *uaddr,
>  	ax25_cb *ax25;
>  	int err = 0;
>  
> +	memset(&fsa->fsa_digipeater, 0, sizeof(fsa->fsa_digipeater));
>  	lock_sock(sk);
>  	ax25 = ax25_sk(sk);
>  

If you really want to fix this for good, please do it completely ?

sa_family_t is a short

ax25_address is 7 bytes.

Therefore, there is a hole before sax25_ndigis.

struct sockaddr_ax25 {
        sa_family_t     sax25_family;
        ax25_address    sax25_call;
<hole>
        int             sax25_ndigis;
        /* Digipeater ax25_address sets follow */
};
struct full_sockaddr_ax25 {
        struct sockaddr_ax25 fsa_ax25;
        ax25_address    fsa_digipeater[AX25_MAX_DIGIS];
};


So a correct patch is the following one. Note AX25 is probably used by
nobody at all, so a full memset() is not performance critical in this
path.


diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c
index 26eaebf..6da5dae 100644
--- a/net/ax25/af_ax25.c
+++ b/net/ax25/af_ax25.c
@@ -1392,6 +1392,7 @@ static int ax25_getname(struct socket *sock, struct sockaddr *uaddr,
 	ax25_cb *ax25;
 	int err = 0;
 
+	memset(fsa, 0, sizeof(*fsa));
 	lock_sock(sk);
 	ax25 = ax25_sk(sk);
 
@@ -1403,7 +1404,6 @@ static int ax25_getname(struct socket *sock, struct sockaddr *uaddr,
 
 		fsa->fsa_ax25.sax25_family = AF_AX25;
 		fsa->fsa_ax25.sax25_call   = ax25->dest_addr;
-		fsa->fsa_ax25.sax25_ndigis = 0;
 
 		if (ax25->digipeat != NULL) {
 			ndigi = ax25->digipeat->ndigi;



^ permalink raw reply related

* Re: [PATCH 1/3] net: ax25: fix information leak to userland
From: Ralf Baechle @ 2010-10-31 18:00 UTC (permalink / raw)
  To: Vasiliy Kulikov
  Cc: kernel-janitors, Joerg Reuter, David S. Miller, linux-hams,
	netdev, linux-kernel
In-Reply-To: <1288545022-16393-1-git-send-email-segooon@gmail.com>

On Sun, Oct 31, 2010 at 08:10:22PM +0300, Vasiliy Kulikov wrote:

> Sometimes ax25_getname() doesn't initialize all members of fsa_digipeater
> field of fsa struct.  This structure is then copied to userland.  It leads to
> leaking of contents of kernel stack memory.  We have to initialize them to zero.
> 
> Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>

Acked-by: Ralf Baechle <ralf@linux-mips.org>

  Ralf

^ permalink raw reply

* [PATCH] kzalloc with swapped params in l2tp_dfs_seq_open
From: Dr. David Alan Gilbert @ 2010-10-31 17:26 UTC (permalink / raw)
  To: linux-kernel; +Cc: jchapman, netdev

Hi,
  'sparse' spotted that the parameters to kzalloc in l2tp_dfs_seq_open
were swapped.

Tested on current git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
at 1792f17b7210280a3d7ff29da9614ba779cfcedb  build, boots and I can see that directory,
but there again I could see /sys/kernel/debug/l2tp with it swapped; I don't have
any l2tp in use.

Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
--
diff --git a/net/l2tp/l2tp_debugfs.c b/net/l2tp/l2tp_debugfs.c
index 104ec3b..b8dbae8 100644
--- a/net/l2tp/l2tp_debugfs.c
+++ b/net/l2tp/l2tp_debugfs.c
@@ -249,7 +249,7 @@ static int l2tp_dfs_seq_open(struct inode *inode, struct file *file)
 	struct seq_file *seq;
 	int rc = -ENOMEM;
 
-	pd = kzalloc(GFP_KERNEL, sizeof(*pd));
+	pd = kzalloc(sizeof(*pd), GFP_KERNEL);
 	if (pd == NULL)
 		goto out;
 
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\ gro.gilbert @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/

^ permalink raw reply related

* [PATCH 3/3] net: tipc: fix information leak to userland
From: Vasiliy Kulikov @ 2010-10-31 17:10 UTC (permalink / raw)
  To: kernel-janitors
  Cc: Jon Maloy, Allan Stephens, David S. Miller, tipc-discussion,
	netdev, linux-kernel

Structure sockaddr_tipc is copied to userland with padding bytes after
"id" field in union field "name" unitialized.  It leads to leaking of
contents of kernel stack memory.  We have to initialize them to zero.

Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
---
 net/tipc/socket.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index 33217fc..e9f0d50 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -396,6 +396,7 @@ static int get_name(struct socket *sock, struct sockaddr *uaddr,
 	struct sockaddr_tipc *addr = (struct sockaddr_tipc *)uaddr;
 	struct tipc_sock *tsock = tipc_sk(sock->sk);
 
+	memset(addr, 0, sizeof(*addr));
 	if (peer) {
 		if ((sock->state != SS_CONNECTED) &&
 			((peer != 2) || (sock->state != SS_DISCONNECTING)))
-- 
1.7.0.4


^ permalink raw reply related

* [PATCH 2/3] net: packet: fix information leak to userland
From: Vasiliy Kulikov @ 2010-10-31 17:10 UTC (permalink / raw)
  To: kernel-janitors
  Cc: David S. Miller, Jiri Pirko, Eric Dumazet, netdev, linux-kernel

packet_getname_spkt() doesn't initialize all members of sa_data field of
sockaddr struct if strlen(dev->name) < 13.  This structure is then copied
to userland.  It leads to leaking of contents of kernel stack memory.
We have to fully fill sa_data with strncpy() instead of strlcpy().

The same with packet_getname(): it doesn't initialize sll_pkttype field of
sockaddr_ll.  Set it to zero.

Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
---
 net/packet/af_packet.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 3616f27..0856a13 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1719,7 +1719,7 @@ static int packet_getname_spkt(struct socket *sock, struct sockaddr *uaddr,
 	rcu_read_lock();
 	dev = dev_get_by_index_rcu(sock_net(sk), pkt_sk(sk)->ifindex);
 	if (dev)
-		strlcpy(uaddr->sa_data, dev->name, 15);
+		strncpy(uaddr->sa_data, dev->name, 14);
 	else
 		memset(uaddr->sa_data, 0, 14);
 	rcu_read_unlock();
@@ -1742,6 +1742,7 @@ static int packet_getname(struct socket *sock, struct sockaddr *uaddr,
 	sll->sll_family = AF_PACKET;
 	sll->sll_ifindex = po->ifindex;
 	sll->sll_protocol = po->num;
+	sll->sll_pkttype = 0;
 	rcu_read_lock();
 	dev = dev_get_by_index_rcu(sock_net(sk), po->ifindex);
 	if (dev) {
-- 
1.7.0.4


^ permalink raw reply related

* [PATCH 1/3] net: ax25: fix information leak to userland
From: Vasiliy Kulikov @ 2010-10-31 17:10 UTC (permalink / raw)
  To: kernel-janitors
  Cc: Joerg Reuter, Ralf Baechle, David S. Miller, linux-hams, netdev,
	linux-kernel

Sometimes ax25_getname() doesn't initialize all members of fsa_digipeater
field of fsa struct.  This structure is then copied to userland.  It leads to
leaking of contents of kernel stack memory.  We have to initialize them to zero.

Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
---
 net/ax25/af_ax25.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c
index 26eaebf..a324d83 100644
--- a/net/ax25/af_ax25.c
+++ b/net/ax25/af_ax25.c
@@ -1392,6 +1392,7 @@ static int ax25_getname(struct socket *sock, struct sockaddr *uaddr,
 	ax25_cb *ax25;
 	int err = 0;
 
+	memset(&fsa->fsa_digipeater, 0, sizeof(fsa->fsa_digipeater));
 	lock_sock(sk);
 	ax25 = ax25_sk(sk);
 
-- 
1.7.0.4


^ permalink raw reply related

* AFFORDABLE LOAN OFFER!!!
From: ASIAWORLD LOAN COMPANY @ 2010-10-31 16:05 UTC (permalink / raw)




  We offer Loan to serious individuals or Organization with low  
interest rate of
  3%. Contact us via e-mail: asiaworldloan@yahoo.com.hk or Tel: +233543956345


^ permalink raw reply

* Re: [PATCH] text ematch: check for NULL pointer before destroying textsearch config
From: David Miller @ 2010-10-31 16:38 UTC (permalink / raw)
  To: tgraf; +Cc: netdev
In-Reply-To: <20101031080635.GA22639@canuck.infradead.org>

From: Thomas Graf <tgraf@infradead.org>
Date: Sun, 31 Oct 2010 04:06:35 -0400

> While validating the configuration em_ops is already set, thus the
> individual destroy functions are called, but the ematch data has
> not been allocated and associated with the ematch yet.
> 
> Signed-off-by: Thomas Graf <tgraf@infradead.org>

Applied, thanks Thomas.

^ permalink raw reply

* Re: [PATCH] qlcnic: fix panic on load
From: David Miller @ 2010-10-31 16:34 UTC (permalink / raw)
  To: eric.dumazet; +Cc: netdev, amit.salecha
In-Reply-To: <1288540238.2660.50.camel@edumazet-laptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 31 Oct 2010 16:50:38 +0100

> Its now illegal to call netif_stop_queue() before register_netdev()
> 
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>

Applied.

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox