* Destroying alive neighbour
From: Sergey Senozhatsky @ 2011-04-29 19:44 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1969 bytes --]
Hello,
.39-rc5-git2
Not sure whether I can reproduce this easily:
[ 845.225899] Destroying alive neighbour ffff88015736b400
[ 845.225910] Pid: 0, comm: kworker/0:1 Not tainted 2.6.39-rc5-dbg-git2-00495-g48c9216-dirty #543
[ 845.225917] Call Trace:
[ 845.225922] <IRQ> [<ffffffff813dee2f>] neigh_destroy+0x3c/0x115
[ 845.225950] [<ffffffff81400326>] ipv4_dst_check+0xae/0x158
[ 845.225963] [<ffffffff813c6f67>] __sk_dst_check+0xa5/0xd4
[ 845.225975] [<ffffffff8142e772>] inet_sk_rebuild_header+0x15/0x2b7
[ 845.225989] [<ffffffff8141c762>] ? tcp_write_timer+0x19/0x1a4
[ 845.225999] [<ffffffff8141ac3b>] tcp_retransmit_skb+0x8f/0x522
[ 845.226010] [<ffffffff81241579>] ? do_raw_spin_lock+0x6b/0x122
[ 845.226020] [<ffffffff8141c598>] tcp_retransmit_timer+0x4d5/0x686
[ 845.226030] [<ffffffff8141c7e7>] tcp_write_timer+0x9e/0x1a4
[ 845.226043] [<ffffffff8104c1f6>] run_timer_softirq+0x319/0x4f5
[ 845.226053] [<ffffffff8104c0c4>] ? run_timer_softirq+0x1e7/0x4f5
[ 845.226065] [<ffffffff8105fcf2>] ? __run_hrtimer+0x2ac/0x357
[ 845.226076] [<ffffffff8141c749>] ? tcp_retransmit_timer+0x686/0x686
[ 845.226091] [<ffffffff81044e73>] __do_softirq+0x170/0x301
[ 845.226104] [<ffffffff8106a257>] ? tick_dev_program_event+0x37/0xf6
[ 845.226115] [<ffffffff8106a330>] ? tick_program_event+0x1a/0x1c
[ 845.226127] [<ffffffff814791dc>] call_softirq+0x1c/0x30
[ 845.226140] [<ffffffff810031d7>] do_softirq+0x46/0x9f
[ 845.226151] [<ffffffff8104525a>] irq_exit+0x4e/0xa0
[ 845.226166] [<ffffffff8101954c>] smp_apic_timer_interrupt+0x87/0x95
[ 845.226212] [<ffffffff81478d13>] apic_timer_interrupt+0x13/0x20
[ 845.226216] <EOI> [<ffffffff8126d3b7>] ? intel_idle+0xe0/0x105
[ 845.226232] [<ffffffff8126d3b0>] ? intel_idle+0xd9/0x105
[ 845.226242] [<ffffffff813b93d4>] cpuidle_idle_call+0x157/0x288
[ 845.226250] [<ffffffff810007aa>] cpu_idle+0xa2/0xf3
[ 845.226259] [<ffffffff8146244b>] start_secondary+0x1ee/0x1f7
Sergey
[-- Attachment #2: Type: application/pgp-signature, Size: 316 bytes --]
^ permalink raw reply
* Re: [PATCH net-next-2.6] ipv4,ipv6,bonding: Restore control over number of peer notifications
From: David Miller @ 2011-04-29 19:44 UTC (permalink / raw)
To: bhutchings; +Cc: fubar, andy, kaber, netdev, brian.haley
In-Reply-To: <1303867552.2850.39.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 27 Apr 2011 02:25:52 +0100
> For backward compatibility, we should retain the module parameters and
> sysfs attributes to control the number of peer notifications
> (gratuitous ARPs and unsolicited NAs) sent after bonding failover.
> Also, it is possible for failover to take place even though the new
> active slave does not have link up, and in that case the peer
> notification should be deferred until it does.
>
> Change ipv4 and ipv6 so they do not automatically send peer
> notifications on bonding failover.
>
> Change the bonding driver to send separate NETDEV_NOTIFY_PEERS
> notifications when the link is up, as many times as requested. Since
> it does not directly control which protocols send notifications, make
> num_grat_arp and num_unsol_na aliases for a single parameter. Bump
> the bonding version number and update its documentation.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCHv3 NEXT 0/2]qlcnic: updates
From: David Miller @ 2011-04-29 20:00 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman, anirban.chakraborty
In-Reply-To: <1304027299-1960-1-git-send-email-amit.salecha@qlogic.com>
From: amit.salecha@qlogic.com
Date: Thu, 28 Apr 2011 14:48:17 -0700
> Hi,
> Please discard series 2 as sendmail fail to send mail to netdev list.
> This is v3 to remove any ambiguity.
Both applied, thanks.
^ permalink raw reply
* Re: [RFC PATCH 1/2] net: Add multiqueue support
From: Anthony Liguori @ 2011-04-29 20:07 UTC (permalink / raw)
To: Jason Wang; +Cc: krkumar2, kvm, mst, netdev, rusty, qemu-devel
In-Reply-To: <20110420083318.32157.63955.stgit@dhcp-91-7.nay.redhat.com.englab.nay.redhat.com>
On 04/20/2011 03:33 AM, Jason Wang wrote:
> This patch adds the multiqueues support for emulated nics. Each VLANClientState
> pairs are now abstract as a queue instead of a nic, and multiple VLANClientState
> pointers were stored in the NICState and treated as the multiple queues of a
> single nic. The netdev options of qdev were now expanded to accept more than one
> netdev ids. A queue_index were also introduced to let the emulated nics know
> which queue the packet were came from or sent out. Virtio-net would be the first
> user.
>
> The legacy single queue nics can still run happily without modification as the
> the compatibility were kept.
>
> Signed-off-by: Jason Wang<jasowang@redhat.com>
> ---
> hw/qdev-properties.c | 37 ++++++++++++++++++++++++++++++-------
> hw/qdev.h | 3 ++-
> net.c | 34 ++++++++++++++++++++++++++--------
> net.h | 15 +++++++++++----
> 4 files changed, 69 insertions(+), 20 deletions(-)
>
> diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
> index 1088a26..dd371e1 100644
> --- a/hw/qdev-properties.c
> +++ b/hw/qdev-properties.c
> @@ -384,14 +384,37 @@ PropertyInfo qdev_prop_chr = {
>
> static int parse_netdev(DeviceState *dev, Property *prop, const char *str)
> {
> - VLANClientState **ptr = qdev_get_prop_ptr(dev, prop);
> + VLANClientState ***nc = qdev_get_prop_ptr(dev, prop);
> + const char *ptr = str;
> + int i = 0;
> + size_t len = strlen(str);
> + *nc = qemu_malloc(MAX_QUEUE_NUM * sizeof(VLANClientState *));
> +
> + while (i< MAX_QUEUE_NUM&& ptr< str + len) {
> + char *name = NULL;
> + char *this = strchr(ptr, '#');
However this is being used is not going to be right. Is this taking
netdev=a#b#c#d?
I sort of agree with Michael about using multiple netdevs for this but I
don't yet understand how this gets sets up from userspace.
Can you give an example of usage that involves the full tap device setup?
Ideally, a user/management tool would never need to know about any of this.
In a perfect world, we could just dup() the tap fd a few times to create
multiple queues.
Regards,
Anthony Liguori
^ permalink raw reply
* Re: [Qemu-devel] [RFC PATCH 0/2] Multiqueue support for qemu(virtio-net)
From: Anthony Liguori @ 2011-04-29 20:10 UTC (permalink / raw)
To: Jason Wang; +Cc: Krishna Kumar2, kvm, mst, netdev, rusty, qemu-devel
In-Reply-To: <19887.42381.34145.956833@gargle.gargle.HOWL>
On 04/20/2011 10:33 PM, Jason Wang wrote:
> Krishna Kumar2 writes:
> > Thanks Jason!
> >
> > So I can use my virtio-net guest driver and test with this patch?
> > Please provide the script you use to start MQ guest.
> >
>
> Yes and thanks. Following is a simple script may help you start macvtap mq
> guest.
>
> qemu_path=./qemu-system-x86_64
> img_path=/home/kvm_autotest_root/images/mq.qcow2
> vtap_dev=/dev/tap104
> mac=96:88:12:1C:27:83
> smp=2
> mq=4
>
> for i in `seq $mq`
> do
> vtap+=" -netdev tap,id=hn$i,fd=$((i+100)) $((i+100))<>$vtap_dev"
So you are basically dup()'ing the tap device.
Does this actually improve performance at all?
Regards,
Anthony Liguori
> netdev+="hn$i#"
> done
>
> eval "$qemu_path $img_path $vtap -device virtio-net-pci,queues=$mq,netdev=$netdev,mac=$mac,vectors=32 -enable-kvm -smp $smp"
>
>
> > Regards,
> >
> > - KK
> >
> > Jason Wang<jasowang@redhat.com> wrote on 04/20/2011 02:03:07 PM:
> >
> > > Jason Wang<jasowang@redhat.com>
> > > 04/20/2011 02:03 PM
> > >
> > > To
> > >
> > > Krishna Kumar2/India/IBM@IBMIN, kvm@vger.kernel.org, mst@redhat.com,
> > > netdev@vger.kernel.org, rusty@rustcorp.com.au, qemu-
> > > devel@nongnu.org, anthony@codemonkey.ws
> > >
> > > cc
> > >
> > > Subject
> > >
> > > [RFC PATCH 0/2] Multiqueue support for qemu(virtio-net)
> > >
> > > Inspired by Krishna's patch
> > (http://www.spinics.net/lists/kvm/msg52098.html
> > > ) and
> > > Michael's suggestions. The following series adds the multiqueue support
> > for
> > > qemu and enable it for virtio-net (both userspace and vhost).
> > >
> > > The aim for this series is to simplified the management and achieve the
> > same
> > > performacne with less codes.
> > >
> > > Follows are the differences between this series and Krishna's:
> > >
> > > - Add the multiqueue support for qemu and also for userspace virtio-net
> > > - Instead of hacking the vhost module to manipulate kthreads, this patch
> > just
> > > implement the userspace based multiqueues and thus can re-use the
> > > existed vhost kernel-side codes without any modification.
> > > - Use 1:1 mapping between TX/RX pairs and vhost kthread because the
> > > implementation is based on usersapce.
> > > - The cli is also changed to make the mgmt easier, the -netdev option of
> > qdev
> > > can now accpet more than one ids. You can start a multiqueue virtio-net
> > device
> > > through:
> > > ./qemu-system-x86_64 -netdev tap,id=hn0,vhost=on,fd=X -netdev
> > > tap,id=hn0,vhost=on,fd=Y -device
> > virtio-net-pci,netdev=hn0#hn1,queues=2 ...
> > >
> > > The series is very primitive and still need polished.
> > >
> > > Suggestions are welcomed.
> > > ---
> > >
> > > Jason Wang (2):
> > > net: Add multiqueue support
> > > virtio-net: add multiqueue support
> > >
> > >
> > > hw/qdev-properties.c | 37 ++++-
> > > hw/qdev.h | 3
> > > hw/vhost.c | 26 ++-
> > > hw/vhost.h | 1
> > > hw/vhost_net.c | 7 +
> > > hw/vhost_net.h | 2
> > > hw/virtio-net.c | 409 +++++++++++++++++++++++++++++++
> > > +------------------
> > > hw/virtio-net.h | 2
> > > hw/virtio-pci.c | 1
> > > hw/virtio.h | 1
> > > net.c | 34 +++-
> > > net.h | 15 +-
> > > 12 files changed, 353 insertions(+), 185 deletions(-)
> > >
> > > --
> > > Jason Wang
> >
>
^ permalink raw reply
* Re: linux-next: manual merge of the suspend tree with the net tree
From: Rafael J. Wysocki @ 2011-04-29 20:36 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Eric Dumazet, David Miller, netdev
In-Reply-To: <20110429120541.c27998c2.sfr@canb.auug.org.au>
On Friday, April 29, 2011, Stephen Rothwell wrote:
> Hi Rafael,
>
> Today's linux-next merge of the suspend tree got a conflict in
> arch/x86/Kconfig between commit 0a14842f5a3c ("net: filter: Just In Time
> compiler for x86-64") from the tree and commit d9f1ce017fcf ("PM: Remove
> sysdev suspend, resume and shutdown operations") from the suspend tree.
>
> Just context changes. I fixed it up (see below) and can carry the fix as
> necessary.
Please do, thanks a lot!
Rafael
^ permalink raw reply
* Re: [PATCH] ipv6: fix incorrect unregistration of sysctl when last ip deleted
From: David Miller @ 2011-04-29 20:45 UTC (permalink / raw)
To: jgmyers; +Cc: kuznet, pekkas, jmorris, yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <201104272312.p3RNCcl6002068@jgmyers-vm1.eng.proofpoint.com>
From: John Myers <jgmyers@proofpoint.com>
Date: Wed, 27 Apr 2011 16:12:38 -0700
> When the last ip address is deleted, the kernel disables IPv6 on the
> interface. (Not sure why, but that's beside the point.) The call that
> does this is over-aggressive--it indicates the interface is about to
> be removed even though that isn't necessarily so.
>
> This causes IPv6 to, among other things, unregister its sysctl
> parameters for the interface. Thus, the "accept_ra" and "addrconf"
> settings can't be set on the interface until after the interface has
> been brought back up, which is too late.
>
> Signed-off-by: John Gardiner Myers <jgmyers@proofpoint.com>
> Cc: stable@kernel.org
I'm not applying this, at least without some more discussion.
I can't see what you gain from this change.
First of all, when the machine boots up, you already have the problem
that you cannot set the accept_ra and addrconf sysctl settings before
the first ipv6 address is added to the interface.
So by definition you already cannot make the settings before it is
"too late" and the device is already engaging in ipv6 activity.
Giving you the capability to handle this across full ipv6 address
deletions on the device later on doesn't add anything, and at best it
gives people a false sense of security about being able to preserve
these settings across an ipv6 disable on the device.
If people are going to use this new behavior to do some trick like:
1) Let device come up and assign ipv6 addresses so that sysctls appear
2) Set ipv6 sysctls how actually desired
3) Delete all ipv6 addresses
4) Add them all back
Then I doubly do not want to set a precedent for this kind of usage
by applying this patch. Fix the real problem.
This behavior has been here, and intentionally so, since Alexey added
the "how" parameter to addrconf_ifdown() back in 1997.
Furthermore, there are other side effects to changing the 'how' parameter
to zero in this case and I haven't seen any analysis that those won't
cause any other undesirable side effects either.
So again, I'm not applying this patch, sorry.
^ permalink raw reply
* Re: [PATCH] net: fix rtnl even race in register_netdevice()
From: David Miller @ 2011-04-29 20:53 UTC (permalink / raw)
To: kvalo-BkwN83ws05HQT0dZR+AlfA
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110429172634.27130.25375.stgit@x201>
From: Kalle Valo <kvalo-BkwN83ws05HQT0dZR+AlfA@public.gmane.org>
Date: Fri, 29 Apr 2011 20:26:34 +0300
> From: Kalle Valo <kalle.valo-DlyHzToyqoxBDgjK7y7TUQ@public.gmane.org>
>
> There's a race in register_netdevice so that the rtnl event is sent before
> the device is actually ready. This was visible with flimflam, chrome os
> connection manager:
>
> 00:21:35 roska flimflamd[2598]: src/udev.c:add_net_device()
> 00:21:35 roska flimflamd[2598]: connman_inet_ifname: SIOCGIFNAME(index
> 4): No such device
> 00:21:45 roska flimflamd[2598]: src/rtnl.c:rtnl_message() buf
> 0xbfefda3c len 1004
> 00:21:45 roska flimflamd[2598]: src/rtnl.c:rtnl_message()
> NEWLINK len 1004 type 16 flags 0x0000 seq 0
>
> So the kobject is visible in udev before the device is ready.
>
> (ignore the 10 s delay, I added that to reproduce the issue easily)
>
> The issue is reported here:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=15606
>
> The fix is to call netdev_register_kobject() after the device is added
> to the list.
>
> Signed-off-by: Kalle Valo <kalle.valo-DlyHzToyqoxBDgjK7y7TUQ@public.gmane.org>
This is not correct.
If you move the kobject registry around, you have to change the
error handling cleanup to match.
This change will leave the netdevice on all sorts of lists, it will
also leak a reference to the device.
I also think this points a fundamental problem with this change, in
that you can't register the kobject after the device is added to
the various lists in list_netdevice().
Once it's in those lists, any thread of control can find the device
and those threads of control may try to get at the data backed by
the kobject and therefore they really expect it to be there by
then.
What you can do instead is try to delay the NETREG_REGISTERED
setting, and block the problematic notifications by testing
reg_state or similar.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH rfc] atm/iphase : removal of PCI space dereferences.
From: David Miller @ 2011-04-29 20:54 UTC (permalink / raw)
To: romieu; +Cc: netdev, chas
In-Reply-To: <20110427203805.GI19708@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Wed, 27 Apr 2011 22:38:05 +0200
> Mostly PHY access and a few (ugly) debug statements for DMA control.
>
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
> ---
>
> Really RFCish. I ought to be able to give it some trivial crash testing.
I like this change, please give it some testing and submit formally.
Thanks!
^ permalink raw reply
* Re: [PATCH 2.6.38.4] mii: add support of pause frames in mii_get_an
From: David Miller @ 2011-04-29 20:57 UTC (permalink / raw)
To: artpol84; +Cc: linux-kernel, bhutchings, netdev
In-Reply-To: <1303962554.15395.1.camel@artpol-thinkpad>
From: artpol <artpol84@gmail.com>
Date: Thu, 28 Apr 2011 10:49:14 +0700
> Add support of pause frames advertise in mii_get_an. This provides all drivers
> that use mii_ethtool_gset to represent their own and Link partner flow control
> abilities in ethtool.
>
> Signed-off-by: Artem Polyakov <artpol84@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCHv3 0/7] ethtool: generalize use of ethtool_cmd_speed API
From: David Miller @ 2011-04-29 21:12 UTC (permalink / raw)
To: decot
Cc: sgruszka, grundler, e1000-devel, linux-kernel, eilong, mirq-linux,
netdev, bhutchings
In-Reply-To: <1303954043-17440-1-git-send-email-decot@google.com>
From: David Decotigny <decot@google.com>
Date: Wed, 27 Apr 2011 18:27:16 -0700
> Third version of the patch series ensuring ethtool_cmd::speed/_hi
> fields are accessed using ethtool_cmd_speed/_set API. Thanks to Ben
> and Stephen for their feedbacks that have been integrated here,
> including some from Ben suggested in PATCHv1 and added here (intel GbE
> drivers: last patch in the series).
Great work David, all applied to net-next-2.6
Thanks!
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH] ipv6: fix incorrect unregistration of sysctl when last ip deleted
From: John Gardiner Myers @ 2011-04-29 21:58 UTC (permalink / raw)
To: David Miller
Cc: kuznet, pekkas, jmorris, yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <20110429.134524.116375005.davem@davemloft.net>
On 4/29/2011 1:45 PM, David Miller wrote:
> First of all, when the machine boots up, you already have the problem
> that you cannot set the accept_ra and addrconf sysctl settings before
> the first ipv6 address is added to the interface.
What do you mean? I see no problem.
One does not need to set the accept_ra and addrconf sysctl settings
before the first ipv6 address is added to the interface, one needs to
set them before the interface is brought up. DAD (and thus router
solicitation) does not happen on down interfaces.
When the machine boots up and the interface is discovered, it starts in
the down state but with the sysctls registered. There is no problem
adjusting the settings before bringing the interface up.
> So by definition you already cannot make the settings before it is
> "too late" and the device is already engaging in ipv6 activity.
>
> Giving you the capability to handle this across full ipv6 address
> deletions on the device later on doesn't add anything, and at best it
> gives people a false sense of security about being able to preserve
> these settings across an ipv6 disable on the device.
>
> If people are going to use this new behavior to do some trick like:
>
> 1) Let device come up and assign ipv6 addresses so that sysctls appear
> 2) Set ipv6 sysctls how actually desired
> 3) Delete all ipv6 addresses
> 4) Add them all back
>
> Then I doubly do not want to set a precedent for this kind of usage
> by applying this patch. Fix the real problem.
This is all nonsense.
> This behavior has been here, and intentionally so, since Alexey added
> the "how" parameter to addrconf_ifdown() back in 1997.
The "how" parameter indicates the device is being deleted. In this case,
the device is not being deleted.
This does bring up the issue that the call to addrconf_ifdown() when the
MTU goes below IPV6_MIN_MTU probably also needs to be fixed.
Furthermore, there are other side effects to changing the 'how' parameter
> to zero in this case and I haven't seen any analysis that those won't
> cause any other undesirable side effects either.
If the device isn't going away, then the ip6_ptr shouldn't be zeroed,
the /proc/net/dev_snmp6 entry shouldn't be deregistered, the stateless
addrconf flags should be cleared, the regen timer shouldn't be deleted,
ipv6 multicast shouldn't mark the device down instead of being
destroyed, and the nd_parms shouldn't be freed.
^ permalink raw reply
* Re: [Linux-ATM-General] [PATCH v2 1/1] solos-pci: Fix regression introduced by newest firmware
From: David Woodhouse @ 2011-04-29 23:09 UTC (permalink / raw)
To: Philip Prindeville; +Cc: David Miller, bhutchings, netdev, linux-atm-general
In-Reply-To: <4D86FD63.1090405@redfish-solutions.com>
On Mon, 2011-03-21 at 00:25 -0700, Philip Prindeville wrote:
> On 3/20/11 11:04 PM, David Miller wrote:
> > From: Philip Prindeville<philipp_subx@redfish-solutions.com>
> > Date: Sun, 20 Mar 2011 22:56:43 -0700
> >
> >> It's not clear that dropping all VCs abruptly when carrier flapped was
> >> ever the right thing to do.
> > So you've tested your change with the older firmware present?
>
> I haven't, no: back-revving firmware has been known to brick cards.
>
> I'm waiting to hear back from Guy and Nathan, they have old cards on hand that they can test.
I have JTAG on one of mine and can test, but there's no real need in
this case. If you want to simulate the absence of the 'state changed'
notification, just *ignore* it when it does arrive.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply
* Re: [PATCH] ipv6: fix incorrect unregistration of sysctl when last ip deleted
From: Alexey Kuznetsov @ 2011-04-30 0:07 UTC (permalink / raw)
To: John Gardiner Myers
Cc: David Miller, pekkas, jmorris, yoshfuji, kaber, netdev,
linux-kernel
In-Reply-To: <4DBB3480.9020708@proofpoint.com>
On Fri, Apr 29, 2011 at 02:58:24PM -0700, John Gardiner Myers wrote:
> If the device isn't going away, then the ip6_ptr shouldn't be zeroed,
> the /proc/net/dev_snmp6 entry shouldn't be deregistered,
Actually, you are right. Tuned interface parameters and disabling/enabling IPv6
(or IP, or whatever) should be different things. We just did not have an interface
to disable protocol, but leave in*_dev, so that they were merged.
When doing this just keep in mind that addrconf_ifdown(how = 0) did _not_ mean
disabling IPv6. (Probably, it does now in fact, I do not know. But it definitely
did not mean this in the past).
Look, addrconf_ifdown(how = 0) was executed only when the physical device is down, so that we could
neither receive nor send over this interface. If the device is UP, addrconf_ifdown(how = 0)
did not prohibit sending/receiving IPv6. Actually, logically, addrconf_ifdown(how = 0)
on UP interface must be followed by immediate restart of autoconfiguration,
because interface is still actually UP. See?
So, to implement this you should verify that IPv6 packets are not sent/received over
disabled interface (at least over interface with illegal mtu :-)). And add some flag in in6_dev
meaning that IPv6 is actually disabled. So that f.e. after occasional
ifconfig eth0 down; ifconfig eth0 up autoconfiguration would not resume IPv6
(the thing which we could not even implement with destroying in6_dev, but definitely wanted).
Alexey
^ permalink raw reply
* CONGRATULATIONS
From: mcrosft06 @ 2011-04-30 0:27 UTC (permalink / raw)
Dear Recipient,
We are pleased to inform you that you won the sum of 1,000,000.00 Euros on the
Microsoft Promo Commission.your e-mail address attached to:Ticket Number:03-02-1,
Reference Number:SL/07/4009,Please acknowledge the receipt of this mail to
Pastor Alan Jonathan With the details below:
EMAIL: mcrawrdprtmnt@aol.com
1.) Name...
2.) Address..
3.) Phone...
4.) Sex...
5.) Occupation....
6.) Age...
7.) Country Of Origin....
Sir Ivan Smith
Mircosoft © Promo Cordinator
^ permalink raw reply
* [PATCHv2 2/2] tg3: Add code to allow ethtool to enable/disable loopback.
From: Mahesh Bandewar @ 2011-04-30 1:03 UTC (permalink / raw)
To: David Miller, Matt Carlson
Cc: netdev, Michael Chan, Ben Hutchings, Michał Mirosław,
Mahesh Bandewar
In-Reply-To: <1304033599-8395-3-git-send-email-maheshb@google.com>
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
---
Changes since v1:
Implemented Matt's suggestions.
(a) Enable this capability on the devices which are capable of MAC-loopback
mode.
(b) check if the device is running before making changes.
(c) check bits before making changes.
drivers/net/tg3.c | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 57 insertions(+), 0 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index fa57e3d..f6e4c10 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -6319,6 +6319,51 @@ static u32 tg3_fix_features(struct net_device *dev, u32 features)
return features;
}
+static int tg3_set_features(struct net_device *dev, u32 features)
+{
+ struct tg3 *tp = netdev_priv(dev);
+ u32 cur_mode = 0;
+ int err = 0;
+
+ if (!netif_running(dev)) {
+ err = -EAGAIN;
+ goto sfeatures_out;
+ }
+
+ spin_lock_bh(&tp->lock);
+ cur_mode = tr32(MAC_MODE);
+
+ if (features & NETIF_F_LOOPBACK) {
+ if (cur_mode & MAC_MODE_PORT_INT_LPBACK)
+ goto sfeatures_unlock;
+
+ /*
+ * Clear MAC_MODE_HALF_DUPLEX or you won't get packets back in
+ * loopback mode if Half-Duplex mode was negotiated earlier.
+ */
+ cur_mode &= ~MAC_MODE_HALF_DUPLEX;
+
+ /* Enable internal MAC loopback mode */
+ tw32(MAC_MODE, cur_mode | MAC_MODE_PORT_INT_LPBACK);
+ netif_carrier_on(tp->dev);
+ netdev_info(dev, "Internal MAC loopback mode enabled.\n");
+ } else {
+ if (!(cur_mode & MAC_MODE_PORT_INT_LPBACK))
+ goto sfeatures_unlock;
+
+ /* Disable internal MAC loopback mode */
+ tw32(MAC_MODE, cur_mode & ~MAC_MODE_PORT_INT_LPBACK);
+ /* Force link status check */
+ tg3_setup_phy(tp, 1);
+ netdev_info(dev, "Internal MAC loopback mode disabled.\n");
+ }
+sfeatures_unlock:
+ spin_unlock_bh(&tp->lock);
+
+sfeatures_out:
+ return err;
+}
+
static inline void tg3_set_mtu(struct net_device *dev, struct tg3 *tp,
int new_mtu)
{
@@ -15028,6 +15073,7 @@ static const struct net_device_ops tg3_netdev_ops = {
.ndo_tx_timeout = tg3_tx_timeout,
.ndo_change_mtu = tg3_change_mtu,
.ndo_fix_features = tg3_fix_features,
+ .ndo_set_features = tg3_set_features,
#ifdef CONFIG_NET_POLL_CONTROLLER
.ndo_poll_controller = tg3_poll_controller,
#endif
@@ -15044,6 +15090,7 @@ static const struct net_device_ops tg3_netdev_ops_dma_bug = {
.ndo_do_ioctl = tg3_ioctl,
.ndo_tx_timeout = tg3_tx_timeout,
.ndo_change_mtu = tg3_change_mtu,
+ .ndo_set_features = tg3_set_features,
#ifdef CONFIG_NET_POLL_CONTROLLER
.ndo_poll_controller = tg3_poll_controller,
#endif
@@ -15241,6 +15288,16 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
dev->features |= hw_features;
dev->vlan_features |= hw_features;
+ /*
+ * Add loopback capability only for a subset of devices that support
+ * MAC-LOOPBACK. Eventually this need to be enhanced to allow INT-PHY
+ * loopback for the remaining devices.
+ */
+ if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5780 ||
+ !tg3_flag(tp, CPMU_PRESENT))
+ /* Add the loopback capability */
+ dev->hw_features |= NETIF_F_LOOPBACK;
+
if (tp->pci_chip_rev_id == CHIPREV_ID_5705_A1 &&
!tg3_flag(tp, TSO_CAPABLE) &&
!(tr32(TG3PCI_PCISTATE) & PCISTATE_BUS_SPEED_HIGH)) {
--
1.7.3.1
^ permalink raw reply related
* Re: [PATCH] ipv6: fix incorrect unregistration of sysctl when last ip deleted
From: David Miller @ 2011-04-30 3:47 UTC (permalink / raw)
To: jgmyers; +Cc: kuznet, pekkas, jmorris, yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <4DBB3480.9020708@proofpoint.com>
From: John Gardiner Myers <jgmyers@proofpoint.com>
Date: Fri, 29 Apr 2011 14:58:24 -0700
> The "how" parameter indicates the device is being deleted. In this
> case, the device is not being deleted.
It means that ipv6 is being disabled on the device.
Which is what happens when one of the following happens:
1) the MTU is too small to support ipv6 properly
2) no configured ipv6 addresses remain on the device
3) the device is being unregistered
^ permalink raw reply
* WoL stopped working after power off with 2.6.38 (e1000e specific?)
From: Kamil Iskra @ 2011-04-30 5:45 UTC (permalink / raw)
To: netdev, e1000-devel
[ Note: I'm not on these mailing lists, so be sure to Cc: me if you want
more info from me ]
After upgrading from kernel 2.6.37 to 2.6.38, Wake on LAN after shutdown
stopped working for me on both of my Thinkpad laptops. Both systems use
the e1000e driver. One (a T61) has an 82566MM NIC, the other (an X201) an
82577LM. I'm running 64-bit Gentoo Linux with a custom compiled kernel.
The network driver is built into the kernel.
Wake on LAN still works after suspend (S3), but not after a complete
shutdown (with power supply connected).
I figured the updated e1000e driver in 2.6.38 was probably to blame,
however, after I copied the whole drivers/net/e1000e directory from the
2.6.37 over to the 2.6.38 tree and recompiled, the problem persisted, so I
don't know anymore.
I modified the system shutdown sequence to invoke ifconfig and ethtool
right before the final halt. According to ifconfig, eth0 is down at that
point. According to ethtool, WoL is configured correctly ("Wake-on: g").
There is, however, a difference in the output of ethtool between the two
kernel versions. "Link detected:" shows "yes" with 2.6.37, but "no" with
2.6.38.
A workaround that I found to work was to invoke "ifconfig eth0 up" right
before the halt.
Any suggestions? Is this new behavior expected or is it a bug?
Kamil
--
Kamil Iskra kamil@iskra.name
^ permalink raw reply
* Re: [PATCH net-next-2.6] veth: remove unneeded ifname code from veth_newlink()
From: Jiri Pirko @ 2011-04-30 9:02 UTC (permalink / raw)
To: Michał Mirosław; +Cc: netdev, davem, xemul
In-Reply-To: <BANLkTi=x8xi7-g3SZdva7Ndg0a4EY1NK8g@mail.gmail.com>
Fri, Apr 22, 2011 at 11:43:10AM CEST, mirqus@gmail.com wrote:
>2011/1/24 Jiri Pirko <jpirko@redhat.com>:
>> The code is not needed because tb[IFLA_IFNAME] is already
>> processed in rtnl_newlink(). Remove this redundancy.
>>
>> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>
>Hi. This patch broke creation of veth devices. Reverting it fixes the issue.
>
>Symptoms:
>
>icybox:~# ip link add type veth
>RTNETLINK answers: File exists
>icybox:~# ip link add type veth peer veth1
>icybox:~# ip addr
>[...]
>56: D: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
> link/ether e6:57:58:52:03:50 brd ff:ff:ff:ff:ff:ff
>57: veth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
> link/ether c2:c2:a2:d5:d5:3a brd ff:ff:ff:ff:ff:ff
interesting, on net-next I get following with or without this patch
applied:
[root@f14 ~]# ip link add type veth peer veth1
Error: either "dev" is duplicate, or "veth1" is a garbage.
Trying original F14 ip and currect git one gives the same
>
>Best Regards,
>Michał Mirosław
^ permalink raw reply
* Re: [PATCH net-next-2.6] veth: remove unneeded ifname code from veth_newlink()
From: Jiri Pirko @ 2011-04-30 10:16 UTC (permalink / raw)
To: Michał Mirosław; +Cc: netdev, davem, xemul
In-Reply-To: <BANLkTikUAGWhNnCrebQpVttorqVxfD6KWw@mail.gmail.com>
Fri, Apr 22, 2011 at 11:49:40AM CEST, mirqus@gmail.com wrote:
>W dniu 22 kwietnia 2011 11:43 użytkownik Michał Mirosław
><mirqus@gmail.com> napisał:
>> 2011/1/24 Jiri Pirko <jpirko@redhat.com>:
>>> The code is not needed because tb[IFLA_IFNAME] is already
>>> processed in rtnl_newlink(). Remove this redundancy.
>> Hi. This patch broke creation of veth devices. Reverting it fixes the issue.
>>
>> Symptoms:
>>
>> icybox:~# ip link add type veth
>> RTNETLINK answers: File exists
>> icybox:~# ip link add type veth peer veth1
>> icybox:~# ip addr
>> [...]
>> 56: D: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
>> link/ether e6:57:58:52:03:50 brd ff:ff:ff:ff:ff:ff
>> 57: veth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
>> link/ether c2:c2:a2:d5:d5:3a brd ff:ff:ff:ff:ff:ff
>
>Hmm. I was too quick. Reverting it fixes only first problem - "ip link
>add type veth" adds new veth pair now, but "ip link add type veth peer
>veth1" gives the same result as above.
I gusee you should do:
ip link add type veth peer name veth1
>
>Best Regards,
>Michał Mirosław
^ permalink raw reply
* [patch net-next-2.6] net: call dev_alloc_name from register_netdevice
From: Jiri Pirko @ 2011-04-30 11:21 UTC (permalink / raw)
To: netdev; +Cc: davem, eric.dumazet, mirqus, xemul
Force dev_alloc_name() to be called from register_netdevice() by
dev_get_valid_name(). That allows to remove multiple explicit
dev_alloc_name() calls.
The possibility to call dev_alloc_name in advance remains.
This also fixes veth creation regresion caused by
84c49d8c3e4abefb0a41a77b25aa37ebe8d6b743
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
---
drivers/ieee802154/fakehard.c | 10 ----------
drivers/net/bonding/bond_main.c | 21 +++------------------
drivers/net/dummy.c | 4 ----
drivers/net/hamradio/bpqether.c | 4 ----
drivers/net/ifb.c | 4 ----
drivers/net/tun.c | 6 ------
drivers/net/wan/dlci.c | 4 ----
drivers/net/wan/hdlc_fr.c | 9 +--------
drivers/net/wan/lapbether.c | 4 ----
drivers/net/wireless/hostap/hostap_main.c | 7 +------
drivers/net/wireless/mac80211_hwsim.c | 11 +----------
drivers/net/wireless/mwifiex/main.c | 4 ----
drivers/s390/net/netiucv.c | 2 --
net/core/dev.c | 24 ++++++------------------
net/core/rtnetlink.c | 8 --------
net/ipv4/ip_gre.c | 5 -----
net/ipv4/ipip.c | 5 -----
net/ipv6/ip6_tunnel.c | 5 -----
net/ipv6/sit.c | 5 -----
net/mac80211/iface.c | 4 ----
20 files changed, 12 insertions(+), 134 deletions(-)
diff --git a/drivers/ieee802154/fakehard.c b/drivers/ieee802154/fakehard.c
index d9d0e13..a5a49a1 100644
--- a/drivers/ieee802154/fakehard.c
+++ b/drivers/ieee802154/fakehard.c
@@ -393,16 +393,6 @@ static int __devinit ieee802154fake_probe(struct platform_device *pdev)
priv = netdev_priv(dev);
priv->phy = phy;
- /*
- * If the name is a format string the caller wants us to do a
- * name allocation.
- */
- if (strchr(dev->name, '%')) {
- err = dev_alloc_name(dev, dev->name);
- if (err < 0)
- goto out;
- }
-
wpan_phy_set_dev(phy, &pdev->dev);
SET_NETDEV_DEV(dev, &phy->dev);
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 66d9dc6..fa5382e0 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -4858,8 +4858,9 @@ int bond_create(struct net *net, const char *name)
rtnl_lock();
- bond_dev = alloc_netdev_mq(sizeof(struct bonding), name ? name : "",
- bond_setup, tx_queues);
+ bond_dev = alloc_netdev_mq(sizeof(struct bonding),
+ name ? name : "bond%d",
+ bond_setup, tx_queues);
if (!bond_dev) {
pr_err("%s: eek! can't alloc netdev!\n", name);
rtnl_unlock();
@@ -4869,26 +4870,10 @@ int bond_create(struct net *net, const char *name)
dev_net_set(bond_dev, net);
bond_dev->rtnl_link_ops = &bond_link_ops;
- if (!name) {
- res = dev_alloc_name(bond_dev, "bond%d");
- if (res < 0)
- goto out;
- } else {
- /*
- * If we're given a name to register
- * we need to ensure that its not already
- * registered
- */
- res = -EEXIST;
- if (__dev_get_by_name(net, name) != NULL)
- goto out;
- }
-
res = register_netdevice(bond_dev);
netif_carrier_off(bond_dev);
-out:
rtnl_unlock();
if (res < 0)
bond_destructor(bond_dev);
diff --git a/drivers/net/dummy.c b/drivers/net/dummy.c
index ff2d29b..39cf9b9 100644
--- a/drivers/net/dummy.c
+++ b/drivers/net/dummy.c
@@ -168,10 +168,6 @@ static int __init dummy_init_one(void)
if (!dev_dummy)
return -ENOMEM;
- err = dev_alloc_name(dev_dummy, dev_dummy->name);
- if (err < 0)
- goto err;
-
dev_dummy->rtnl_link_ops = &dummy_link_ops;
err = register_netdevice(dev_dummy);
if (err < 0)
diff --git a/drivers/net/hamradio/bpqether.c b/drivers/net/hamradio/bpqether.c
index 8931168..18d8aff 100644
--- a/drivers/net/hamradio/bpqether.c
+++ b/drivers/net/hamradio/bpqether.c
@@ -516,10 +516,6 @@ static int bpq_new_device(struct net_device *edev)
memcpy(bpq->dest_addr, bcast_addr, sizeof(bpq_eth_addr));
memcpy(bpq->acpt_addr, bcast_addr, sizeof(bpq_eth_addr));
- err = dev_alloc_name(ndev, ndev->name);
- if (err < 0)
- goto error;
-
err = register_netdevice(ndev);
if (err)
goto error;
diff --git a/drivers/net/ifb.c b/drivers/net/ifb.c
index e07d487..4fecaed 100644
--- a/drivers/net/ifb.c
+++ b/drivers/net/ifb.c
@@ -233,10 +233,6 @@ static int __init ifb_init_one(int index)
if (!dev_ifb)
return -ENOMEM;
- err = dev_alloc_name(dev_ifb, dev_ifb->name);
- if (err < 0)
- goto err;
-
dev_ifb->rtnl_link_ops = &ifb_link_ops;
err = register_netdevice(dev_ifb);
if (err < 0)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index ade3cf9..334b5ad 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1099,12 +1099,6 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
tun_net_init(dev);
- if (strchr(dev->name, '%')) {
- err = dev_alloc_name(dev, dev->name);
- if (err < 0)
- goto err_free_sk;
- }
-
dev->hw_features = NETIF_F_SG | NETIF_F_FRAGLIST |
TUN_USER_FEATURES;
dev->features = dev->hw_features;
diff --git a/drivers/net/wan/dlci.c b/drivers/net/wan/dlci.c
index 1481a44..21b104d 100644
--- a/drivers/net/wan/dlci.c
+++ b/drivers/net/wan/dlci.c
@@ -341,10 +341,6 @@ static int dlci_add(struct dlci_add *dlci)
}
}
- err = dev_alloc_name(master, master->name);
- if (err < 0)
- goto err2;
-
*(short *)(master->dev_addr) = dlci->dlci;
dlp = netdev_priv(master);
diff --git a/drivers/net/wan/hdlc_fr.c b/drivers/net/wan/hdlc_fr.c
index 0edb535..fc433f2 100644
--- a/drivers/net/wan/hdlc_fr.c
+++ b/drivers/net/wan/hdlc_fr.c
@@ -1070,7 +1070,7 @@ static int fr_add_pvc(struct net_device *frad, unsigned int dlci, int type)
hdlc_device *hdlc = dev_to_hdlc(frad);
pvc_device *pvc;
struct net_device *dev;
- int result, used;
+ int used;
if ((pvc = add_pvc(frad, dlci)) == NULL) {
printk(KERN_WARNING "%s: Memory squeeze on fr_add_pvc()\n",
@@ -1106,13 +1106,6 @@ static int fr_add_pvc(struct net_device *frad, unsigned int dlci, int type)
dev->tx_queue_len = 0;
dev->ml_priv = pvc;
- result = dev_alloc_name(dev, dev->name);
- if (result < 0) {
- free_netdev(dev);
- delete_unused_pvcs(hdlc);
- return result;
- }
-
if (register_netdevice(dev) != 0) {
free_netdev(dev);
delete_unused_pvcs(hdlc);
diff --git a/drivers/net/wan/lapbether.c b/drivers/net/wan/lapbether.c
index 7f5bb91..eec463f 100644
--- a/drivers/net/wan/lapbether.c
+++ b/drivers/net/wan/lapbether.c
@@ -338,10 +338,6 @@ static int lapbeth_new_device(struct net_device *dev)
dev_hold(dev);
lapbeth->ethdev = dev;
- rc = dev_alloc_name(ndev, ndev->name);
- if (rc < 0)
- goto fail;
-
rc = -EIO;
if (register_netdevice(ndev))
goto fail;
diff --git a/drivers/net/wireless/hostap/hostap_main.c b/drivers/net/wireless/hostap/hostap_main.c
index 1d9aed6..d508482 100644
--- a/drivers/net/wireless/hostap/hostap_main.c
+++ b/drivers/net/wireless/hostap/hostap_main.c
@@ -79,13 +79,8 @@ struct net_device * hostap_add_interface(struct local_info *local,
if (!rtnl_locked)
rtnl_lock();
- ret = 0;
- if (strchr(dev->name, '%'))
- ret = dev_alloc_name(dev, dev->name);
-
SET_NETDEV_DEV(dev, mdev->dev.parent);
- if (ret >= 0)
- ret = register_netdevice(dev);
+ ret = register_netdevice(dev);
if (!rtnl_locked)
rtnl_unlock();
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index f4f4257..9d4a40e 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -1515,19 +1515,10 @@ static int __init init_mac80211_hwsim(void)
if (hwsim_mon == NULL)
goto failed;
- rtnl_lock();
-
- err = dev_alloc_name(hwsim_mon, hwsim_mon->name);
+ err = register_netdev(hwsim_mon);
if (err < 0)
goto failed_mon;
-
- err = register_netdevice(hwsim_mon);
- if (err < 0)
- goto failed_mon;
-
- rtnl_unlock();
-
return 0;
failed_mon:
diff --git a/drivers/net/wireless/mwifiex/main.c b/drivers/net/wireless/mwifiex/main.c
index c597188..d16cea7 100644
--- a/drivers/net/wireless/mwifiex/main.c
+++ b/drivers/net/wireless/mwifiex/main.c
@@ -706,10 +706,6 @@ static struct mwifiex_private *mwifiex_add_interface(
dev_err(adapter->dev, "no memory available for netdevice\n");
goto error;
}
- if (dev_alloc_name(dev, dev->name)) {
- dev_err(adapter->dev, "unable to alloc name for netdevice\n");
- goto error;
- }
if (mwifiex_register_cfg80211(dev, adapter->priv[bss_index]->curr_addr,
adapter->priv[bss_index]) != 0) {
diff --git a/drivers/s390/net/netiucv.c b/drivers/s390/net/netiucv.c
index b6a6356..3251333 100644
--- a/drivers/s390/net/netiucv.c
+++ b/drivers/s390/net/netiucv.c
@@ -1994,8 +1994,6 @@ static struct net_device *netiucv_init_netdevice(char *username)
netiucv_setup_netdevice);
if (!dev)
return NULL;
- if (dev_alloc_name(dev, dev->name) < 0)
- goto out_netdev;
privptr = netdev_priv(dev);
privptr->fsm = init_fsm("netiucvdev", dev_state_names,
diff --git a/net/core/dev.c b/net/core/dev.c
index 7db99b5..992574a 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -948,7 +948,7 @@ int dev_alloc_name(struct net_device *dev, const char *name)
}
EXPORT_SYMBOL(dev_alloc_name);
-static int dev_get_valid_name(struct net_device *dev, const char *name, bool fmt)
+static int dev_get_valid_name(struct net_device *dev, const char *name)
{
struct net *net;
@@ -958,7 +958,7 @@ static int dev_get_valid_name(struct net_device *dev, const char *name, bool fmt
if (!dev_valid_name(name))
return -EINVAL;
- if (fmt && strchr(name, '%'))
+ if (strchr(name, '%'))
return dev_alloc_name(dev, name);
else if (__dev_get_by_name(net, name))
return -EEXIST;
@@ -995,7 +995,7 @@ int dev_change_name(struct net_device *dev, const char *newname)
memcpy(oldname, dev->name, IFNAMSIZ);
- err = dev_get_valid_name(dev, newname, 1);
+ err = dev_get_valid_name(dev, newname);
if (err < 0)
return err;
@@ -5396,8 +5396,8 @@ int register_netdevice(struct net_device *dev)
}
}
- ret = dev_get_valid_name(dev, dev->name, 0);
- if (ret)
+ ret = dev_get_valid_name(dev, dev->name);
+ if (ret < 0)
goto err_uninit;
dev->ifindex = dev_new_index(net);
@@ -5538,19 +5538,7 @@ int register_netdev(struct net_device *dev)
int err;
rtnl_lock();
-
- /*
- * If the name is a format string the caller wants us to do a
- * name allocation.
- */
- if (strchr(dev->name, '%')) {
- err = dev_alloc_name(dev, dev->name);
- if (err < 0)
- goto out;
- }
-
err = register_netdevice(dev);
-out:
rtnl_unlock();
return err;
}
@@ -6032,7 +6020,7 @@ int dev_change_net_namespace(struct net_device *dev, struct net *net, const char
/* We get here if we can't use the current device name */
if (!pat)
goto out;
- if (dev_get_valid_name(dev, pat, 1))
+ if (dev_get_valid_name(dev, pat) < 0)
goto out;
}
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index d7c4bb4..d4dec8c 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1570,12 +1570,6 @@ struct net_device *rtnl_create_link(struct net *src_net, struct net *net,
dev->rtnl_link_state = RTNL_LINK_INITIALIZING;
dev->real_num_tx_queues = real_num_queues;
- if (strchr(dev->name, '%')) {
- err = dev_alloc_name(dev, dev->name);
- if (err < 0)
- goto err_free;
- }
-
if (tb[IFLA_MTU])
dev->mtu = nla_get_u32(tb[IFLA_MTU]);
if (tb[IFLA_ADDRESS])
@@ -1595,8 +1589,6 @@ struct net_device *rtnl_create_link(struct net *src_net, struct net *net,
return dev;
-err_free:
- free_netdev(dev);
err:
return ERR_PTR(err);
}
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 24efd35..0d536f2 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -413,11 +413,6 @@ static struct ip_tunnel *ipgre_tunnel_locate(struct net *net,
dev_net_set(dev, net);
- if (strchr(name, '%')) {
- if (dev_alloc_name(dev, name) < 0)
- goto failed_free;
- }
-
nt = netdev_priv(dev);
nt->parms = *parms;
dev->rtnl_link_ops = &ipgre_link_ops;
diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c
index ef16377..f0e0fb2 100644
--- a/net/ipv4/ipip.c
+++ b/net/ipv4/ipip.c
@@ -276,11 +276,6 @@ static struct ip_tunnel * ipip_tunnel_locate(struct net *net,
dev_net_set(dev, net);
- if (strchr(name, '%')) {
- if (dev_alloc_name(dev, name) < 0)
- goto failed_free;
- }
-
nt = netdev_priv(dev);
nt->parms = *parms;
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 9dd0e96..ae244d3 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -280,11 +280,6 @@ static struct ip6_tnl *ip6_tnl_create(struct net *net, struct ip6_tnl_parm *p)
dev_net_set(dev, net);
- if (strchr(name, '%')) {
- if (dev_alloc_name(dev, name) < 0)
- goto failed_free;
- }
-
t = netdev_priv(dev);
t->parms = *p;
err = ip6_tnl_dev_init(dev);
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index 34d8964..87a547e 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -250,11 +250,6 @@ static struct ip_tunnel *ipip6_tunnel_locate(struct net *net,
dev_net_set(dev, net);
- if (strchr(name, '%')) {
- if (dev_alloc_name(dev, name) < 0)
- goto failed_free;
- }
-
nt = netdev_priv(dev);
nt->parms = *parms;
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 4054399..80c29d6 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -1144,10 +1144,6 @@ int ieee80211_if_add(struct ieee80211_local *local, const char *name,
+ IEEE80211_ENCRYPT_HEADROOM;
ndev->needed_tailroom = IEEE80211_ENCRYPT_TAILROOM;
- ret = dev_alloc_name(ndev, ndev->name);
- if (ret < 0)
- goto fail;
-
ieee80211_assign_perm_addr(local, ndev, type);
memcpy(ndev->dev_addr, ndev->perm_addr, ETH_ALEN);
SET_NETDEV_DEV(ndev, wiphy_dev(local->hw.wiphy));
--
1.7.4.2
^ permalink raw reply related
* Re: [PATCH net-next-2.6] veth: remove unneeded ifname code from veth_newlink()
From: Jiri Pirko @ 2011-04-30 11:28 UTC (permalink / raw)
To: Michał Mirosław; +Cc: netdev, davem, xemul
In-Reply-To: <BANLkTi=x8xi7-g3SZdva7Ndg0a4EY1NK8g@mail.gmail.com>
Fri, Apr 22, 2011 at 11:43:10AM CEST, mirqus@gmail.com wrote:
>2011/1/24 Jiri Pirko <jpirko@redhat.com>:
>> The code is not needed because tb[IFLA_IFNAME] is already
>> processed in rtnl_newlink(). Remove this redundancy.
>>
>> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>
>Hi. This patch broke creation of veth devices. Reverting it fixes the issue.
Sorry for troubles.
For net-next-2.6 this is fixed by:
http://patchwork.ozlabs.org/patch/93498/
For net-2.6 I suggest to revert this patch:
Subject: [PATCH net-2.6] Revert: veth: remove unneeded ifname code from veth_newlink()
84c49d8c3e4abefb0a41a77b25aa37ebe8d6b743 caused regression on veth
creation. This patch reverts the original one.
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
---
drivers/net/veth.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index 2de9b90..3b99f64 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -403,6 +403,17 @@ static int veth_newlink(struct net *src_net, struct net_device *dev,
if (tb[IFLA_ADDRESS] == NULL)
random_ether_addr(dev->dev_addr);
+ if (tb[IFLA_IFNAME])
+ nla_strlcpy(dev->name, tb[IFLA_IFNAME], IFNAMSIZ);
+ else
+ snprintf(dev->name, IFNAMSIZ, DRV_NAME "%%d");
+
+ if (strchr(dev->name, '%')) {
+ err = dev_alloc_name(dev, dev->name);
+ if (err < 0)
+ goto err_alloc_name;
+ }
+
err = register_netdevice(dev);
if (err < 0)
goto err_register_dev;
@@ -422,6 +433,7 @@ static int veth_newlink(struct net *src_net, struct net_device *dev,
err_register_dev:
/* nothing to do */
+err_alloc_name:
err_configure_peer:
unregister_netdevice(peer);
return err;
--
1.7.4.2
^ permalink raw reply related
* Re: [RFC PATCH 0/2] Multiqueue support for qemu(virtio-net)
From: Jason Wang @ 2011-04-30 14:55 UTC (permalink / raw)
To: Anthony Liguori
Cc: Krishna Kumar2, kvm, mst, netdev, Jason Wang, rusty, qemu-devel
In-Reply-To: <4DBB1B25.1020300@codemonkey.ws>
Anthony Liguori writes:
> On 04/20/2011 10:33 PM, Jason Wang wrote:
> > Krishna Kumar2 writes:
> > > Thanks Jason!
> > >
> > > So I can use my virtio-net guest driver and test with this patch?
> > > Please provide the script you use to start MQ guest.
> > >
> >
> > Yes and thanks. Following is a simple script may help you start macvtap mq
> > guest.
> >
> > qemu_path=./qemu-system-x86_64
> > img_path=/home/kvm_autotest_root/images/mq.qcow2
> > vtap_dev=/dev/tap104
> > mac=96:88:12:1C:27:83
> > smp=2
> > mq=4
> >
> > for i in `seq $mq`
> > do
> > vtap+=" -netdev tap,id=hn$i,fd=$((i+100)) $((i+100))<>$vtap_dev"
>
> So you are basically dup()'ing the tap device.
>
> Does this actually improve performance at all?
>
The script maybe not clear. It works only for macvtap (tap does not have
multiqueue support and I plan to add it). A macvtap device needs to be created
first by ip command.
The multiqueue was achieved by opening the macvtap device many times. Each time
the user open to macvtap device, a new queue (sock) was created. Then macvtap
device then can forward the packets to different sock/fd based on their RX
queue of physical nics. So the fd could be used to registered as a backend for
vhost/qemu.
Performance improvement is expected when using smp guest with mq virtio-net and
mq nic.
> Regards,
>
> Anthony Liguori
>
--
Jason Wang
^ permalink raw reply
* Re: [RFC PATCH 1/2] net: Add multiqueue support
From: Jason Wang @ 2011-04-30 15:15 UTC (permalink / raw)
To: Anthony Liguori; +Cc: krkumar2, kvm, mst, netdev, Jason Wang, rusty, qemu-devel
In-Reply-To: <4DBB1A9F.2050803@codemonkey.ws>
Anthony Liguori writes:
> On 04/20/2011 03:33 AM, Jason Wang wrote:
> > This patch adds the multiqueues support for emulated nics. Each VLANClientState
> > pairs are now abstract as a queue instead of a nic, and multiple VLANClientState
> > pointers were stored in the NICState and treated as the multiple queues of a
> > single nic. The netdev options of qdev were now expanded to accept more than one
> > netdev ids. A queue_index were also introduced to let the emulated nics know
> > which queue the packet were came from or sent out. Virtio-net would be the first
> > user.
> >
> > The legacy single queue nics can still run happily without modification as the
> > the compatibility were kept.
> >
> > Signed-off-by: Jason Wang<jasowang@redhat.com>
> > ---
> > hw/qdev-properties.c | 37 ++++++++++++++++++++++++++++++-------
> > hw/qdev.h | 3 ++-
> > net.c | 34 ++++++++++++++++++++++++++--------
> > net.h | 15 +++++++++++----
> > 4 files changed, 69 insertions(+), 20 deletions(-)
> >
> > diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
> > index 1088a26..dd371e1 100644
> > --- a/hw/qdev-properties.c
> > +++ b/hw/qdev-properties.c
> > @@ -384,14 +384,37 @@ PropertyInfo qdev_prop_chr = {
> >
> > static int parse_netdev(DeviceState *dev, Property *prop, const char *str)
> > {
> > - VLANClientState **ptr = qdev_get_prop_ptr(dev, prop);
> > + VLANClientState ***nc = qdev_get_prop_ptr(dev, prop);
> > + const char *ptr = str;
> > + int i = 0;
> > + size_t len = strlen(str);
> > + *nc = qemu_malloc(MAX_QUEUE_NUM * sizeof(VLANClientState *));
> > +
> > + while (i< MAX_QUEUE_NUM&& ptr< str + len) {
> > + char *name = NULL;
> > + char *this = strchr(ptr, '#');
>
> However this is being used is not going to be right. Is this taking
> netdev=a#b#c#d?
>
Yes, through this current netdev codes could be reused but it would bring extra
complexity of link status handling because it makes every queue visible from
monitor. Do you have any suggestions on this kind of cli? Another method is let
netdev accept multiple fd/vhostfd, but the tap fd handling codes need to be
refactored.
You can refer Krishna's patch http://www.spinics.net/lists/kvm/msg52098.html.
His patch make multiqueue only works for vhost while my patch also make the
multiqueue works for userspace and also let it could be used by other nic model.
> I sort of agree with Michael about using multiple netdevs for this but I
> don't yet understand how this gets sets up from userspace.
>
> Can you give an example of usage that involves the full tap device setup?
>
> Ideally, a user/management tool would never need to know about any of this.
>
For macvtap, what user/management tool need is:
1 create a macvtap device by either netlink or ip command
2 open the device many times and pass the fd to the qemu
In fact, qemu can do all of this, but for the sake of management, keep the
current tap implementation and accpet a file descriptor from libvirt may be a
better choice.
> In a perfect world, we could just dup() the tap fd a few times to create
> multiple queues.
But dup() can only create file descriptors pointed to the same file which is
hard to implement real multi queues.
>
> Regards,
>
> Anthony Liguori
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Jason Wang
^ permalink raw reply
* Re: [patch net-next-2.6] net: call dev_alloc_name from register_netdevice
From: Stephen Hemminger @ 2011-04-30 17:34 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem, eric.dumazet, mirqus, xemul
In-Reply-To: <1304162492-6606-1-git-send-email-jpirko@redhat.com>
On Sat, 30 Apr 2011 13:21:32 +0200
Jiri Pirko <jpirko@redhat.com> wrote:
> Force dev_alloc_name() to be called from register_netdevice() by
> dev_get_valid_name(). That allows to remove multiple explicit
> dev_alloc_name() calls.
>
> The possibility to call dev_alloc_name in advance remains.
>
> This also fixes veth creation regresion caused by
> 84c49d8c3e4abefb0a41a77b25aa37ebe8d6b743
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
The problem with this then you have to audit all the calls
to register_netdevice to make sure that user can't provide a bad
value which then is passed a format string. Why not just fix
just veth which would be safer.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox