* strange behaviour in ping when specifying timeout in msec
From: Michele BOLOGNA @ 2009-08-05 23:27 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev
Dear Mr. Yoshifuji,
I recently noticed a strange behaviour in ping from iputils.
First of all some information:
mbologna@neptune:~$ ping -V
ping utility, iputils-sss20071127
Now, I want to specify a timeout and after it expires I would like
that ping exits, regardless of the packets received, so I use the -W
option:
-W timeout
Time to wait for a response, in seconds. The option affects only
timeout in absense of any responses, otherwise ping waits for
two RTTs.
So, if I decide to wait 1s for 5 packets, the ping works fine and
exits after 5s:
mbologna@neptune:~$ ping -c 5 -W 1 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
--- 1.1.1.1 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 3999ms
However, if I want to specify a timeout that is less than 1s, the ping
does not exit after 5*0.5 s and keeps staying active (notice the ^C):
mbologna@neptune:~$ ping -c 5 -W 0.5 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
^C
--- 1.1.1.1 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 3999ms
I also tried escaping the timeout with \ '' "" and so on, with no luck.
In a few words, is possible to specify a timeout that is less than 1 s?
Where am I wrong?
Thank you very much for your answer.
Best regards,
Michele Bologna
--
Michele BOLOGNA
Email/GTalk: michele.bologna@gmail.com
Skype: michele-mb
PGP: 0x0BA55536
Web: www.mb.netsons.org
^ permalink raw reply
* Re: Low latency diagnostic tools
From: Mark Smith @ 2009-08-06 0:17 UTC (permalink / raw)
To: Christoph Lameter; +Cc: netdev
In-Reply-To: <alpine.DEB.1.10.0908051706050.30180@gentwo.org>
Hi Christoph,
On Wed, 5 Aug 2009 17:10:09 -0400 (EDT)
Christoph Lameter <cl@linux-foundation.org> wrote:
> I am starting a collection of tools / tips for low latency networking.
>
> lldiag-0.12 is available from
> http://www.kernel.org/pub/linux/kernel/people/christoph/lldiag
>
> Corrections and additional tools or references to additional material
> welcome.
>
This implementation of One Way Active Measurement Protocol might be of
interest:
http://www.internet2.edu/performance/owamp/
Some of the performance tuning parts of the README below would also be
useful in the Net area of the Linux Foundation wiki. Possibly the
"Testing" section could be changed to "Testing and Measurement"
http://www.linuxfoundation.org/en/Net:Main_Page
Regards,
Mark.
> README:
>
>
> This tarball contains a series of test programs that have turned out to
> be useful for testing latency issues on networks and Linux systems.
>
> Tools can be roughly separated into those dealing with networking,
> those used for scheduling and for cpu cache issues.
>
>
> Scheduling related tools:
> -------------------------
>
> latencytest Basic tool to measure the impact of scheduling activity.
> Continually samples TSC and displays statistics on how OS
> scheduling impacted it.
>
> latencystat Query the Linux scheduling counters of a running process.
> This allows the observation on how the scheduler treats
> a running process.
>
>
> Cpu cache related tools
> -----------------------
>
> trashcache Clears all cpu caches. Run this before a test
> to avoid caching effects or to see the worst case
> caching situation for latency critical code.
>
>
> Network related tools
> ---------------------
>
> udpping Measure ping pong times for UDP between two hosts.
> (mostly used for unicast)
>
> mcast Generate and analyze multicast traffic on a mesh
> of senders and receivers. mcast is designed to create
> multicast loads that allow one to explore the multicast
> limitations of a network infrastructure. It can create
> lots of multicast traffic at high rates.
>
> mcasttest Simple multicast latency test with a single
> multicast group between two machines.
>
>
> Libraries:
> ----------
>
> ll.* Low latency library. Allows timestamp determination and
> determination of cpu caches for an application.
>
>
>
> Linux configuration for large amounts of multicast groups
> ---------------------------------------------------------
>
> /proc/sys/net/core/optmem_max
>
> Required for multicast metadata storage
> -ENBUFS will result if this is loo low.
>
> /proc/sys/net/ipv4/igmp_max_memberships
>
> Limit on the number of MC groups that a single
> socket can join. If more MC groups are joined
> -ENOBUFS will result.
>
> /proc/sys/net/ipv4/neigh/default/gc_thresh*
>
> These settings are often too low for heavy
> multicast usage. Each MC groups counts as a neighbor.
> Heavy MC use can result in thrashing of the neighbor
> cache. If usage reaches gc_thresh3 then again
> -ENOBUFS will be returned by some system calls.
>
>
> Reducing network latency
> ------------------------
>
> Most NICs have receive delays that cause additional latency.
> ethtool can be used to switch those off. F.e.
>
> ethtool -C eth0 rx-delay 0
> ethtool -C eth0 rx-frames 1
>
> WARNING: This may cause high interrupt and network processing
> load. May limit the throughput of the NIC. Higher values reduce
> the frequency of NIC interrupts and batch transfers from the NIC.
>
> The default behavior of Linux is to send UDP packets immediately. This
> means that each sendto() results in NIC interaction. In order to reduce
> send delays multiple sendto()s can be coalesced into a single NIC
> interaction. This can be accomplished by setting the MSG_MORE option
> if it is know that there will be additional data sent. This creates
> larger packets which reduce the load on the network infrastructure.
>
>
> Configuring receive and send buffer sizes to reduce packet loss
> ---------------------------------------------------------------
>
> In general large receive buffer sizes are recommended in order to
> avoid packet loss when receiving data. The lower the buffer sizes
> the lower the time until the application must pickup data from
> the network socket to avoid packet loss.
>
> For the send side the requirements are opposite due to the broken
> flow control behavior of the Linux network stack (observed at least
> in 2.6.22 - 2.6.30). Packets are accounted for by the SO_SNDBUF limit
> and sendto() and friends block a process if more than SO_SNDBUF
> bytes are queued on the socket. In theory this should result in the
> application being blocked so that the NIC can send at full speed.
>
> However this is usually jeopardized by the device drivers. These have
> a fixed TX ring size and throw packet away that are pushed to the
> driver when the count of packets exceeds TX ring size. A fast
> cpu can loose huge amounts of packets by just sending at a rate
> that the device does not support.
>
> Outbound blocking only works if the SO_SNDBUF limit is lower than
> the TX ring size. If SO_SNDBUF sizes are bigger than the TX ring then
> the kernel will forward packets to the network device and it will queue
> it until the TX ring is full. The additional packets after that are
> tossed by the device driver. It is therefore recommended to configure
> the send buffer sizes as small as possible to avoid this problem.
>
> (Some device drivers --including the IPoIB layer-- behave in
> a moronic way by queuing a few early packets and then throwing
> away the rest until the packets queued first have been send.
> This means outdated data will be send on the network. NIC should
> toss the oldest packets. Best would be not to drop until the limit
> established by the user through SO_SNDBUF is reached)
>
> August 5, 2009
> Christoph Lameter <cl@linux-foundation.org>
>
>
> --
> 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
* Re: [PATCH] sky2: Add a mutex around ethtools operations
From: Stephen Hemminger @ 2009-08-06 0:42 UTC (permalink / raw)
To: Mike McCormack; +Cc: netdev, Rene Mayrhofer, Richard Leitner
In-Reply-To: <4A7A0BAA.7020104@ring3k.org>
On Thu, 06 Aug 2009 07:46:02 +0900
Mike McCormack <mikem@ring3k.org> wrote:
> As multiple sky2 devices share some of the same hardware, and ethtool
> operations are per device, access to transmit timers, eeprom access,
> coalesce, etc. should be serialized.
>
> Only tested on a single port card, as my sky2 doesn't have dual ports.
>
> Signed-off-by: Mike McCormack <mikem@ring3k.org>
NAK.
The ethtool operations are already serialized by rtnl mutex at
higher level. See net/core/dev.c
--
^ permalink raw reply
* Re: [PATCH] sky2: Add a mutex around ethtools operations
From: Stephen Hemminger @ 2009-08-06 0:41 UTC (permalink / raw)
To: Mike McCormack; +Cc: netdev, Rene Mayrhofer, Richard Leitner
In-Reply-To: <4A7A0BAA.7020104@ring3k.org>
On Thu, 06 Aug 2009 07:46:02 +0900
Mike McCormack <mikem@ring3k.org> wrote:
> As multiple sky2 devices share some of the same hardware, and ethtool
> operations are per device, access to transmit timers, eeprom access,
> coalesce, etc. should be serialized.
>
> Only tested on a single port card, as my sky2 doesn't have dual ports.
>
> Signed-off-by: Mike McCormack <mikem@ring3k.org>
NAK.
The ethtool operations are already serialized by rtnl mutex at
higher level. See net/core/dev.c
^ permalink raw reply
* Re: [RFC PATCH v1 1/2] lsm: Add hooks to the TUN driver
From: Serge E. Hallyn @ 2009-08-06 2:15 UTC (permalink / raw)
To: Paul Moore; +Cc: eparis, netdev, linux-security-module, selinux
In-Reply-To: <200908051758.39051.paul.moore@hp.com>
Quoting Paul Moore (paul.moore@hp.com):
> On Wednesday 05 August 2009 10:13:50 am Serge E. Hallyn wrote:
> > Quoting Paul Moore (paul.moore@hp.com):
>
> [NOTE: my email has been out all day due to some mysterious FS issue so my
> apologies for not replying sooner]
>
> ...
>
> > The checks before and after this patch are not equivalent. Post-patch,
> > one must always have CAP_NET_ADMIN to do the attach, whereas pre-patch
> > you only needed those if current_cred() did not own the tun device. Is
> > that intentional?
>
> Nope, just a goof on my part; I misread the booleans and haven't fully tested
> the patch yet so it slipped out, thanks for catching it. This brings up a
> good point, would we rather move the TUN owner/group checks into the cap_tun_*
> functions or move the capable() call back into the TUN driver? The answer
> wasn't clear to me when I was looking at the code before and the uniqueness of
> the TUN driver doesn't help much in this regard.
I see the question being asked as: Does this device belong to
the caller and, if not, is the caller privileged to act
anyway?' So I think the capable call should be moved back
into the tun driver, followed by a separate security_tun_dev_attach()
check, since that is a separate, restrictive question.
thanks,
-serge
^ permalink raw reply
* Re: [PATCH 2/3] af_ieee802154: provide dummy get/setsockopt
From: David Miller @ 2009-08-06 3:19 UTC (permalink / raw)
To: dbaryshkov; +Cc: netdev, slapin, linux-zigbee-devel
In-Reply-To: <20090805214139.GA6553@doriath.ww600.siemens.net>
From: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Date: Thu, 6 Aug 2009 01:41:39 +0400
> On Wed, Aug 05, 2009 at 12:17:14PM -0700, David Miller wrote:
>> From: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
>> Date: Wed, 5 Aug 2009 11:28:16 +0400
>>
>> > Provide dummt get/setsockopt implementations to stop these
>> > syscalls from oopsing on our sockets.
>> >
>> > Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
>>
>> See "sock_no_getsockopt()" and "sock_no_setsockopt()" which are
>> provided specifically for this situation.
>
> There functions are to be used in struct proto_ops and not in the
> struct proto. I'd like to use sock_common_get/setsockopt() from the
> beginning, as there will be sockopts at least for dgram protocols.
Ok, my bad. The patch is fine.
^ permalink raw reply
* Re: [PATCH 3/3] documentation: fix wrt. headers rename
From: David Miller @ 2009-08-06 3:22 UTC (permalink / raw)
To: dbaryshkov; +Cc: netdev, slapin, linux-zigbee-devel
In-Reply-To: <1249457297-8355-4-git-send-email-dbaryshkov@gmail.com>
From: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Date: Wed, 5 Aug 2009 11:28:17 +0400
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
What are you generating these patches against?
> @@ -72,5 +72,4 @@ SoftMAC
> We are going to provide intermediate layer implementing IEEE 802.15.4 MAC
> in software. This is currently WIP.
>
> -See header include/net/ieee802154/mac802154.h and several drivers in
> -drivers/ieee802154/
> +See header include/net/mac802154.h and several drivers in drivers/ieee802154/.
In net-2.6, and in Linus's tree as well, that first sentence quoted has
a typo, "implementing" is misspelled, but in whatever you're patching
against the misspelling is fixed.
Looking at your pull request:
--------------------
The following changes since commit db71789c01ae7b641f83c5aa64e7df25122f4b28:
David S. Miller (1):
xfrm6: Fix xfrm6_policy.c build when SYSCTL disabled.
--------------------
You're submitting these for net-next-2.6? Didn't we just go back and
forth about trimming this patch series down to only pure bug fixes so
that they could go into net-2.6? Given that, why are you generating
this stuff against net-next-2.6?
I'm tossing this entire series again, this is beyond frustrating.
^ permalink raw reply
* Re: [PATCH] Add IDs for 3C905B-TX Fast Etherlink XL PCI
From: David Miller @ 2009-08-06 3:24 UTC (permalink / raw)
To: klassert; +Cc: pterjan, netdev
In-Reply-To: <20090805144100.GA9346@skl-net.de>
From: Steffen Klassert <klassert@mathematik.tu-chemnitz.de>
Date: Wed, 5 Aug 2009 16:41:00 +0200
> On Wed, Aug 05, 2009 at 04:11:39PM +0200, Pascal Terjan wrote:
>> We found this old card which was not supported, and physically
>> looks similar to the other 3C905B we have (9055).
>>
>> After adding the IDs it seems to work fine (MII report, dhcp, scp, ...)
>
> The patch looks sane.
> Btw. you should add a Signed-off-by line to your patches.
>
> Acked-by: Steffen Klassert <klassert@mathematik.tu-chemnitz.de>
Applied, and yes please provide a proper Signed-off-by tag
in your commit message next time.
^ permalink raw reply
* Re: [PATCH net-next-2.6] cxgb3: fix 2 ports 1G regression
From: David Miller @ 2009-08-06 3:28 UTC (permalink / raw)
To: divy; +Cc: netdev, linux-kernel, swise
In-Reply-To: <20090805215923.21467.99484.stgit@speedy5>
From: Divy Le Ray <divy@chelsio.com>
Date: Wed, 05 Aug 2009 14:59:23 -0700
> commit 88045b3cf0f8981129cb489c7b6bc36c21dd33a7
> cxgb3: fix mac index mapping
>
> Override the mac index computation for the gen2 adapter,
> as each port is expected to use index 0.
>
> introduces a regression on 2 port 1G adapter
> as its xauicfg vpd value is null.
> Add a check on the device id.
>
> Signed-off-by: Divy Le Ray <divy@chelsio.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 5/5] net: smsc911x: switch to new dev_pm_ops
From: David Miller @ 2009-08-06 3:29 UTC (permalink / raw)
To: daniel; +Cc: linux-kernel, linux-pm, steve.glendinning, netdev
In-Reply-To: <1249496971-9019-5-git-send-email-daniel@caiaq.de>
From: Daniel Mack <daniel@caiaq.de>
Date: Wed, 5 Aug 2009 20:29:31 +0200
> Hibernation is unsupported for now, which meets the actual
> implementation in the driver. For free/thaw, the chip's D2 state should
> be entered.
>
> Signed-off-by: Daniel Mack <daniel@caiaq.de>
Steve, if it looks good to you I can toss this into net-next-2.6
Just let me know.
^ permalink raw reply
* Re: [PATCH 1/2] net/rds: Use AF_INET for sin_family field
From: David Miller @ 2009-08-06 3:30 UTC (permalink / raw)
To: julia; +Cc: andy.grover, netdev, rds-devel, linux-kernel, kernel-janitors
In-Reply-To: <Pine.LNX.4.64.0908051434110.20453@pc-004.diku.dk>
From: Julia Lawall <julia@diku.dk>
Date: Wed, 5 Aug 2009 14:34:34 +0200 (CEST)
> Elsewhere the sin_family field holds a value with a name of the form
> AF_..., so it seems reasonable to do so here as well. Also the values of
> PF_INET and AF_INET are the same.
>
> The semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)
..
> Signed-off-by: Julia Lawall <julia@diku.dk>
This is obvious enough that I've just tossed it into net-next-2.6
Thanks!
^ permalink raw reply
* Re: [PATCH] xfrm: xfrm hash to use Jenkins' hash
From: Jussi Maki @ 2009-08-06 6:32 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20090805.120831.66033097.davem@davemloft.net>
Hi David,
Changing the (h >> 16) to ((h >> 16) ^ (h >> 24)) still has the same
problem as given in the example,
that is if you have a set of transports with incrementing addresses
(192.168.0.1-172.16.0.1, 192.168.0.2-172.16.0.2,..) they
still hash to the same value. The reason to this is that it's doing
src^dst in __xfrm4_daddr_saddr_hash.
Should I pursue with fixing the inlining issue in my patch or would
you have any suggestions how I could
fix this by perhaps modifying __xfrm4_daddr_saddr_hash?
On Wed, Aug 5, 2009 at 10:08 PM, David Miller<davem@davemloft.net> wrote:
> From: Jussi Mäki <joamaki@gmail.com>
> Date: Wed, 5 Aug 2009 10:41:42 +0300
>
>> Hi,
>>
>> The current xfrm hash functions perform very poorly when a number of
>> policies have the same
>> last byte in source and destination addresses.
>>
>> For example with __xfrm_dst_hash, hmask of 0xfff:
>>
>> 192.168.0.1-172.16.0.1 hashes to 3258
>> 192.168.0.2-172.16.0.2 hashes to 3258
>> ... and so on.
>>
>> This patch addresses the issue by rewriting the xfrm
>> hash functions to use the Jenkins' hash function.
>>
>> Signed-off-by: Jussi Maki <joamaki@gmail.com>
>
> jhash expands to a lot of code, and given your description of the
> problem, you could have fixed it by adding 2 instructions (see below)
> instead of 20 or 30 (jhash instruction count) at every hash
> calculation site.
>
> Simply change every instance of:
>
> (h >> 16)
>
> with
>
> ((h >> 16) ^ (h >> 24))
>
> As much as I love jhash, it's overkill for fixing this problem.
>
> And if we do end up using jhash, it should get inlined into a
> seperate non-inline function instead of expanding that monster
> 4 or 5 times throughout the XFRM code.
>
> I'm not applying this, either make the simple one-liner fix I
> suggested above work or move the jhash into a non-inline expansion.
>
^ permalink raw reply
* Fwd: [RFC v3] net: Introduce recvmmsg socket syscall
From: Nir Tzachar @ 2009-08-06 7:15 UTC (permalink / raw)
To: netdev
In-Reply-To: <9b2db90b0908060014r6a1763e8t1b3ee9310e012c25@mail.gmail.com>
Hello.
Is there anything new with this patch? What are the plans for merging
it upstream?
Cheers.
p.s. please cc me, I am not registered to linux-netdev.
^ permalink raw reply
* mii ioctls and copy_to_user
From: John Paul Foster @ 2009-08-06 7:42 UTC (permalink / raw)
To: Netdev
[-- Attachment #1: Type: text/plain, Size: 1844 bytes --]
Hello all,
I've written a program that uses SIOCGMIIREG to query
various mii interfaces on my board. We have a switch chip
with multiple PHYs MACs and switch fabrics on the mii bus.
I'm using kernel 2.6.23
I set the ifru_data up like this in user space
#include <linux/mii.h> // The user side if.h
struct mii_ioctl_data mii;
mii.phy_addr=myphy;
mii.reg_num=myreg;
ifr.ifr_data=(__caddr_t)&mii;
as according to my libc (uclibc) <net/if.h> that is what ifr_data is a
pointer not a structure.
This doesn't work. I get garbage in the ifr_data used by the network
driver. (kernel space)
If I add a copy_from/to_user around the call to generic_mii_ioctl(),
then it works. My driver isn't in the main kernel it is the stmmac
driver at stlinux.org but the ioctl function is the same as many in main
tree, pcnet32_ioctl() for example.
mii-tool works without me patching the driver.
mii-tool sets the ioctl up like this.
#include "mii.h" // it's own mmi structure
struct mii_data *mii = (struct mii_data *)&ifr.ifr_data;
mii->reg_num = location;
in mii-tool ifr_data is a pointer not allocated storage so you shouldn't
do that. However ifr_data is part of a union and the biggest thing in it
is bigger than struct mii_data, so we are not going to crap on our
stack/heap. Not safe though if the structure of mii_data grows, or the
union changes size.
looking at <linux/if.h> (the kernel side if.h)
ifru_data is a
void __user *ifru_data;
i.e. it needs copy_to/from_user.
Are the drivers AND mii-tool wrong? I'm feeling like either I've
uncovered a long standing bug (in both mii ioctls and mmi-tool) or I'm
missing something.
Apologies for the verbose message but I'm trying to tell it
as thoroughly as I can.
Cross posted on the linux-net list but it looks a pretty dead list.
JP
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 0/7] AlacrityVM guest drivers Reply-To:
From: Michael S. Tsirkin @ 2009-08-06 8:19 UTC (permalink / raw)
To: Gregory Haskins; +Cc: linux-kernel, alacrityvm-devel, netdev, kvm
In-Reply-To: <20090803171030.17268.26962.stgit@dev.haskins.net>
On Mon, Aug 03, 2009 at 01:17:30PM -0400, Gregory Haskins wrote:
> (Applies to v2.6.31-rc5, proposed for linux-next after review is complete)
These are guest drivers, right? Merging the guest first means relying on
kernel interface from an out of tree driver, which well might change
before it goes in. Would it make more sense to start merging with the
host side of the project?
> This series implements the guest-side drivers for accelerated IO
> when running on top of the AlacrityVM hypervisor, the details of
> which you can find here:
>
> http://developer.novell.com/wiki/index.php/AlacrityVM
Since AlacrityVM is kvm based, Cc kvm@vger.kernel.org.
> This series includes the basic plumbing, as well as the driver for
> accelerated 802.x (ethernet) networking.
The graphs comparing virtio with vbus look interesting.
However, they do not compare apples to apples, do they?
These compare userspace virtio with kernel vbus, where for
apples to apples comparison one would need to compare
kernel virtio with kernel vbus. Right?
> Regards,
> -Greg
>
> ---
>
> Gregory Haskins (7):
> venet: add scatter-gather/GSO support
> net: Add vbus_enet driver
> ioq: add driver-side vbus helpers
> vbus-proxy: add a pci-to-vbus bridge
> vbus: add a "vbus-proxy" bus model for vbus_driver objects
> ioq: Add basic definitions for a shared-memory, lockless queue
> shm-signal: shared-memory signals
>
>
> arch/x86/Kconfig | 2
> drivers/Makefile | 1
> drivers/net/Kconfig | 14 +
> drivers/net/Makefile | 1
> drivers/net/vbus-enet.c | 899 +++++++++++++++++++++++++++++++++++++++++++
> drivers/vbus/Kconfig | 24 +
> drivers/vbus/Makefile | 6
> drivers/vbus/bus-proxy.c | 216 ++++++++++
> drivers/vbus/pci-bridge.c | 824 +++++++++++++++++++++++++++++++++++++++
> include/linux/Kbuild | 4
> include/linux/ioq.h | 415 ++++++++++++++++++++
> include/linux/shm_signal.h | 189 +++++++++
> include/linux/vbus_driver.h | 80 ++++
> include/linux/vbus_pci.h | 127 ++++++
> include/linux/venet.h | 84 ++++
> lib/Kconfig | 21 +
> lib/Makefile | 2
> lib/ioq.c | 294 ++++++++++++++
> lib/shm_signal.c | 192 +++++++++
> 19 files changed, 3395 insertions(+), 0 deletions(-)
> create mode 100644 drivers/net/vbus-enet.c
> create mode 100644 drivers/vbus/Kconfig
> create mode 100644 drivers/vbus/Makefile
> create mode 100644 drivers/vbus/bus-proxy.c
> create mode 100644 drivers/vbus/pci-bridge.c
> create mode 100644 include/linux/ioq.h
> create mode 100644 include/linux/shm_signal.h
> create mode 100644 include/linux/vbus_driver.h
> create mode 100644 include/linux/vbus_pci.h
> create mode 100644 include/linux/venet.h
> create mode 100644 lib/ioq.c
> create mode 100644 lib/shm_signal.c
>
> --
> Signature
> --
> 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
* Re: [PATCH] net: Fix spinlock use in alloc_netdev_mq()
From: Jiri Pirko @ 2009-08-06 8:31 UTC (permalink / raw)
To: Andrew Morton
Cc: Ingo Molnar, David Miller, Peter Zijlstra, torvalds, netdev,
linux-kernel, eric.dumazet
In-Reply-To: <20090805101327.2c49cc62.akpm@linux-foundation.org>
Wed, Aug 05, 2009 at 07:13:27PM CEST, akpm@linux-foundation.org wrote:
>On Wed, 5 Aug 2009 10:47:47 +0200 Jiri Pirko <jpirko@redhat.com> wrote:
>
>> >it's using an zero-initialized spinlock. This is a side-effect of:
>> >
>> > dev_unicast_init(dev);
>> >
>> >in alloc_netdev_mq() making use of dev->addr_list_lock.
>> >
>> >The device has just been allocated freshly, it's not accessible
>> >anywhere yet so no locking is needed at all - in fact it's wrong
>> >to lock it here (the lock isnt initialized yet).
>>
>> Yes this looks like the right approach. Sorry for this bug :(
>
>Really?
>
>> >--- a/net/core/dev.c
>> >+++ b/net/core/dev.c
>> >@@ -4007,9 +4007,7 @@ static void dev_unicast_flush(struct net_device *dev)
>> >
>> > static void dev_unicast_init(struct net_device *dev)
>> > {
>> >- netif_addr_lock_bh(dev);
>> > __hw_addr_init(&dev->uc);
>> >- netif_addr_unlock_bh(dev);
>> > }
>
>This means that the net_device is still floating around for quite a
>long time with an uninitialised spinlock, so it will be quite easy for
>the same problem to reoccur as the code evolves.
>
>It would be more robust were we to initialise that lock close to the
>netdev's allocation site.
Hmm, I see your point here. Eric previously posted patch which moved spin lock
init into alloc_netdev_mq(). But he was worried about having it here and
netdev_set_addr_lockdep_class() in register_netdevice() (because before
dev_unicast_init() dev->type is not set). So how about the following patch?
[PATCH net-2.6] net: move address lists spinlock closer to alloc and do unicast_init locking
Move spin_lock_init(), netdev_set_addr_lockdep_class() and dev_unicast_init()
right after setup is called from alloc_netdev_mq(). In that moment dev->type is
initialized. List is not needed to be initialized earlier. Also restore
previously removed locking in dev_unicast_init().
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
diff --git a/net/core/dev.c b/net/core/dev.c
index 6a94475..916a6d0 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4007,7 +4007,9 @@ static void dev_unicast_flush(struct net_device *dev)
static void dev_unicast_init(struct net_device *dev)
{
+ netif_addr_lock_bh(dev);
__hw_addr_init(&dev->uc);
+ netif_addr_unlock_bh(dev);
}
@@ -4726,8 +4728,6 @@ int register_netdevice(struct net_device *dev)
BUG_ON(dev->reg_state != NETREG_UNINITIALIZED);
BUG_ON(!net);
- spin_lock_init(&dev->addr_list_lock);
- netdev_set_addr_lockdep_class(dev);
netdev_init_queue_locks(dev);
dev->iflink = -1;
@@ -5107,8 +5107,6 @@ struct net_device *alloc_netdev_mq(int sizeof_priv, const char *name,
if (dev_addr_init(dev))
goto free_tx;
- dev_unicast_init(dev);
-
dev_net_set(dev, &init_net);
dev->_tx = tx;
@@ -5123,6 +5121,11 @@ struct net_device *alloc_netdev_mq(int sizeof_priv, const char *name,
dev->priv_flags = IFF_XMIT_DST_RELEASE;
setup(dev);
strcpy(dev->name, name);
+
+ spin_lock_init(&dev->addr_list_lock);
+ netdev_set_addr_lockdep_class(dev);
+ dev_unicast_init(dev);
+
return dev;
free_tx:
>
^ permalink raw reply related
* Re: system hangs while executing 'rmmod ehea'
From: Hannes Hering @ 2009-08-06 8:33 UTC (permalink / raw)
To: Pavan Naregundi; +Cc: netdev, HERING2, THEMANN, TKLEIN
In-Reply-To: <4A699E70.2090900@linux.vnet.ibm.com>
Hello,
this problem has been fixed by a patch I sent out on tuesday:
http://lkml.org/lkml/2009/8/4/174
Thanks for pointing out this.
Regards
Hannes
^ permalink raw reply
* some bug in iproute2
From: Sergey Popov @ 2009-08-06 8:50 UTC (permalink / raw)
To: netdev
# tc f add dev eth0 parent 1: proto ip prio 2 u32 match u32 0 0 action ipt -j MARK --set-mark 1
/usr/lib64/iptables/libipt_mark.so: cannot open shared object file: No such file or directory
failed to find target MARK
bad action parsing
parse_action: bad value (5:ipt)!
Illegal "action"
But mark target is compiled in kernel (not a module)
# iptables -t mangle -A PREROUTING -i eth1 -j MARK --set-mark 1
# iptables -t mangle -L PREROUTING
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
MARK all -- anywhere anywhere MARK xset
0x1/0xffffffff
This shouldn't be.
^ permalink raw reply
* Re: [PATCH] xfrm: xfrm hash to use Jenkins' hash
From: Jussi Maki @ 2009-08-06 8:58 UTC (permalink / raw)
To: Jussi Maki; +Cc: David Miller, netdev
In-Reply-To: <ce10d01f0908052332o1db16460k58ed47849670c6de@mail.gmail.com>
Hi,
Did some testing and one possible fix to this problem
would be to change the xor to addition. Would this be OK?
---
net/xfrm/xfrm_hash.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/xfrm/xfrm_hash.h b/net/xfrm/xfrm_hash.h
index d401dc8..e5195c9 100644
--- a/net/xfrm/xfrm_hash.h
+++ b/net/xfrm/xfrm_hash.h
@@ -16,7 +16,7 @@ static inline unsigned int __xfrm6_addr_hash(xfrm_address_t *addr)
static inline unsigned int __xfrm4_daddr_saddr_hash(xfrm_address_t *daddr, xfrm_address_t *saddr)
{
- return ntohl(daddr->a4 ^ saddr->a4);
+ return ntohl(daddr->a4 + saddr->a4);
}
static inline unsigned int __xfrm6_daddr_saddr_hash(xfrm_address_t *daddr, xfrm_address_t *saddr)
--
1.5.6.5
On Thu, 6 Aug 2009, Jussi Maki wrote:
> Hi David,
>
> Changing the (h >> 16) to ((h >> 16) ^ (h >> 24)) still has the same
> problem as given in the example,
> that is if you have a set of transports with incrementing addresses
> (192.168.0.1-172.16.0.1, 192.168.0.2-172.16.0.2,..) they
> still hash to the same value. The reason to this is that it's doing
> src^dst in __xfrm4_daddr_saddr_hash.
>
> Should I pursue with fixing the inlining issue in my patch or would
> you have any suggestions how I could
> fix this by perhaps modifying __xfrm4_daddr_saddr_hash?
^ permalink raw reply related
* Re: [PATCH 3/3] documentation: fix wrt. headers rename
From: Dmitry Eremin-Solenikov @ 2009-08-06 9:26 UTC (permalink / raw)
To: David Miller; +Cc: netdev, slapin, linux-zigbee-devel
In-Reply-To: <20090805.202226.24204308.davem@davemloft.net>
On Wed, Aug 05, 2009 at 08:22:26PM -0700, David Miller wrote:
> From: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> Date: Wed, 5 Aug 2009 11:28:17 +0400
>
> > Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
>
> What are you generating these patches against?
>
> > @@ -72,5 +72,4 @@ SoftMAC
> > We are going to provide intermediate layer implementing IEEE 802.15.4 MAC
> > in software. This is currently WIP.
> >
> > -See header include/net/ieee802154/mac802154.h and several drivers in
> > -drivers/ieee802154/
> > +See header include/net/mac802154.h and several drivers in drivers/ieee802154/.
>
> In net-2.6, and in Linus's tree as well, that first sentence quoted has
> a typo, "implementing" is misspelled, but in whatever you're patching
> against the misspelling is fixed.
>
> Looking at your pull request:
>
> --------------------
> The following changes since commit db71789c01ae7b641f83c5aa64e7df25122f4b28:
> David S. Miller (1):
> xfrm6: Fix xfrm6_policy.c build when SYSCTL disabled.
> --------------------
>
> You're submitting these for net-next-2.6? Didn't we just go back and
> forth about trimming this patch series down to only pure bug fixes so
> that they could go into net-2.6? Given that, why are you generating
> this stuff against net-next-2.6?
Damn. It seems I missed the difference between net-next-2.6 and net-2.6.
BTW: how should I differentiate my poll requests for net-next-2.6 and
for net-2.6 ?
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [RFC PATCH v1] tun: Cleanup error handling in tun_set_iff()
From: Herbert Xu @ 2009-08-06 10:10 UTC (permalink / raw)
To: Paul Moore; +Cc: Eric W. Biederman, netdev, David Miller
In-Reply-To: <200908051738.43134.paul.moore@hp.com>
On Wed, Aug 05, 2009 at 05:38:42PM -0400, Paul Moore wrote:
>
> My concern is that I believe that if the kernel fails at an operation it
> should do all it can to unwind any actions it took in the course of attempting
> to perform the requested operation. Leaving a TUN device around in the case
> of a tun_attach() failure seems like the kernel is being lazy, sure a user can
> cleanup the device but why should they have to?
That particular tun_attach should never fail. Perhaps you can
just add a WARN_ON.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 0/7] AlacrityVM guest drivers Reply-To:
From: Michael S. Tsirkin @ 2009-08-06 10:17 UTC (permalink / raw)
To: Gregory Haskins; +Cc: linux-kernel, alacrityvm-devel, netdev, kvm
In-Reply-To: <20090806081955.GA9752@redhat.com>
On Thu, Aug 06, 2009 at 11:19:56AM +0300, Michael S. Tsirkin wrote:
> On Mon, Aug 03, 2009 at 01:17:30PM -0400, Gregory Haskins wrote:
> > (Applies to v2.6.31-rc5, proposed for linux-next after review is complete)
>
> These are guest drivers, right? Merging the guest first means relying on
> kernel interface from an out of tree driver, which well might change
> before it goes in. Would it make more sense to start merging with the
> host side of the project?
>
> > This series implements the guest-side drivers for accelerated IO
> > when running on top of the AlacrityVM hypervisor, the details of
> > which you can find here:
> >
> > http://developer.novell.com/wiki/index.php/AlacrityVM
>
> Since AlacrityVM is kvm based, Cc kvm@vger.kernel.org.
>
> > This series includes the basic plumbing, as well as the driver for
> > accelerated 802.x (ethernet) networking.
>
> The graphs comparing virtio with vbus look interesting.
> However, they do not compare apples to apples, do they?
> These compare userspace virtio with kernel vbus, where for
> apples to apples comparison one would need to compare
> kernel virtio with kernel vbus. Right?
Or userspace virtio with userspace vbus.
> > Regards,
> > -Greg
> >
> > ---
> >
> > Gregory Haskins (7):
> > venet: add scatter-gather/GSO support
> > net: Add vbus_enet driver
> > ioq: add driver-side vbus helpers
> > vbus-proxy: add a pci-to-vbus bridge
> > vbus: add a "vbus-proxy" bus model for vbus_driver objects
> > ioq: Add basic definitions for a shared-memory, lockless queue
> > shm-signal: shared-memory signals
> >
> >
> > arch/x86/Kconfig | 2
> > drivers/Makefile | 1
> > drivers/net/Kconfig | 14 +
> > drivers/net/Makefile | 1
> > drivers/net/vbus-enet.c | 899 +++++++++++++++++++++++++++++++++++++++++++
> > drivers/vbus/Kconfig | 24 +
> > drivers/vbus/Makefile | 6
> > drivers/vbus/bus-proxy.c | 216 ++++++++++
> > drivers/vbus/pci-bridge.c | 824 +++++++++++++++++++++++++++++++++++++++
> > include/linux/Kbuild | 4
> > include/linux/ioq.h | 415 ++++++++++++++++++++
> > include/linux/shm_signal.h | 189 +++++++++
> > include/linux/vbus_driver.h | 80 ++++
> > include/linux/vbus_pci.h | 127 ++++++
> > include/linux/venet.h | 84 ++++
> > lib/Kconfig | 21 +
> > lib/Makefile | 2
> > lib/ioq.c | 294 ++++++++++++++
> > lib/shm_signal.c | 192 +++++++++
> > 19 files changed, 3395 insertions(+), 0 deletions(-)
> > create mode 100644 drivers/net/vbus-enet.c
> > create mode 100644 drivers/vbus/Kconfig
> > create mode 100644 drivers/vbus/Makefile
> > create mode 100644 drivers/vbus/bus-proxy.c
> > create mode 100644 drivers/vbus/pci-bridge.c
> > create mode 100644 include/linux/ioq.h
> > create mode 100644 include/linux/shm_signal.h
> > create mode 100644 include/linux/vbus_driver.h
> > create mode 100644 include/linux/vbus_pci.h
> > create mode 100644 include/linux/venet.h
> > create mode 100644 lib/ioq.c
> > create mode 100644 lib/shm_signal.c
> >
> > --
> > Signature
> > --
> > 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
* Re: [RFC PATCH v1] tun: Cleanup error handling in tun_set_iff()
From: Eric W. Biederman @ 2009-08-06 10:21 UTC (permalink / raw)
To: Herbert Xu; +Cc: Paul Moore, netdev, David Miller
In-Reply-To: <20090806101044.GA26589@gondor.apana.org.au>
Herbert Xu <herbert@gondor.apana.org.au> writes:
> On Wed, Aug 05, 2009 at 05:38:42PM -0400, Paul Moore wrote:
>>
>> My concern is that I believe that if the kernel fails at an operation it
>> should do all it can to unwind any actions it took in the course of attempting
>> to perform the requested operation. Leaving a TUN device around in the case
>> of a tun_attach() failure seems like the kernel is being lazy, sure a user can
>> cleanup the device but why should they have to?
>
> That particular tun_attach should never fail. Perhaps you can
> just add a WARN_ON.
Two threads one file descriptor. Both simultaneously attempt to
attach to a tun device. One will fail, the other succeed.
At least that is how I read the locking.
Eric
^ permalink raw reply
* Re: [PATCH, RFC] bonding: prevent outgoing packets on inactive slaves
From: Jiri Bohac @ 2009-08-06 10:43 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Jiri Bohac, fubar, davem, netdev
In-Reply-To: <4A79BA01.502@gmail.com>
On Wed, Aug 05, 2009 at 06:57:37PM +0200, Eric Dumazet wrote:
> Jiri Bohac a écrit :
> > This patch makes sure the TX queues on inactive slaves are
> > deactivated.
> >
>
> Wont this break ARP link monitoring ?
No, ARP monitoring sends the ARP requests from the active slave.
--
Jiri Bohac <jbohac@suse.cz>
SUSE Labs, SUSE CZ
^ permalink raw reply
* [PATCH] sky2: Serialize access to PCI config space
From: Mike McCormack @ 2009-08-06 11:10 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Rene Mayrhofer, Richard Leitner
PCI config space may be shared across two device instances,
or accessed from an interrupt
, so serialize access so
read-update-write operations do not interfere with each other.
Only tested on a single port card, as my sky2 doesn't have dual ports.
Signed-off-by: Mike McCormack <mikem@ring3k.org>
---
drivers/net/sky2.c | 23 ++++++++++++++++-------
drivers/net/sky2.h | 1 +
2 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
index 1415a83..4d09632 100644
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -618,6 +618,7 @@ static void sky2_phy_power_up(struct sky2_hw *hw, unsigned port)
{
u32 reg1;
+ spin_lock(&hw->pci_cfg_lock);
sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
reg1 = sky2_pci_read32(hw, PCI_DEV_REG1);
reg1 &= ~phy_power[port];
@@ -628,6 +629,7 @@ static void sky2_phy_power_up(struct sky2_hw *hw, unsigned port)
sky2_pci_write32(hw, PCI_DEV_REG1, reg1);
sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
sky2_pci_read32(hw, PCI_DEV_REG1);
+ spin_unlock(&hw->pci_cfg_lock);
if (hw->chip_id == CHIP_ID_YUKON_FE)
gm_phy_write(hw, port, PHY_MARV_CTRL, PHY_CT_ANE);
@@ -681,11 +683,13 @@ static void sky2_phy_power_down(struct sky2_hw *hw, unsigned port)
gm_phy_write(hw, port, PHY_MARV_CTRL, PHY_CT_PDOWN);
}
+ spin_lock(&hw->pci_cfg_lock);
sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
reg1 = sky2_pci_read32(hw, PCI_DEV_REG1);
reg1 |= phy_power[port]; /* set PHY to PowerDown/COMA Mode */
sky2_pci_write32(hw, PCI_DEV_REG1, reg1);
sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
+ spin_unlock(&hw->pci_cfg_lock);
}
/* Force a renegotiation */
@@ -2596,30 +2600,34 @@ static void sky2_hw_intr(struct sky2_hw *hw)
if (status & (Y2_IS_MST_ERR | Y2_IS_IRQ_STAT)) {
u16 pci_err;
+ spin_lock(&hw->pci_cfg_lock);
sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
pci_err = sky2_pci_read16(hw, PCI_STATUS);
- if (net_ratelimit())
- dev_err(&pdev->dev, "PCI hardware error (0x%x)\n",
- pci_err);
-
sky2_pci_write16(hw, PCI_STATUS,
pci_err | PCI_STATUS_ERROR_BITS);
sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
+ spin_unlock(&hw->pci_cfg_lock);
+
+ if (net_ratelimit())
+ dev_err(&pdev->dev, "PCI hardware error (0x%x)\n",
+ pci_err);
}
if (status & Y2_IS_PCI_EXP) {
/* PCI-Express uncorrectable Error occurred */
u32 err;
+ spin_lock(&hw->pci_cfg_lock);
sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
err = sky2_read32(hw, Y2_CFG_AER + PCI_ERR_UNCOR_STATUS);
sky2_write32(hw, Y2_CFG_AER + PCI_ERR_UNCOR_STATUS,
0xfffffffful);
- if (net_ratelimit())
- dev_err(&pdev->dev, "PCI Express error (0x%x)\n", err);
-
sky2_read32(hw, Y2_CFG_AER + PCI_ERR_UNCOR_STATUS);
sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
+ spin_unlock(&hw->pci_cfg_lock);
+
+ if (net_ratelimit())
+ dev_err(&pdev->dev, "PCI Express error (0x%x)\n", err);
}
if (status & Y2_HWE_L1_MASK)
@@ -4485,6 +4493,7 @@ static int __devinit sky2_probe(struct pci_dev *pdev,
}
hw->pdev = pdev;
+ spin_lock_init(&hw->pci_cfg_lock);
hw->regs = ioremap_nocache(pci_resource_start(pdev, 0), 0x4000);
if (!hw->regs) {
diff --git a/drivers/net/sky2.h b/drivers/net/sky2.h
index 4486b06..5a9b0cf 100644
--- a/drivers/net/sky2.h
+++ b/drivers/net/sky2.h
@@ -2087,6 +2087,7 @@ struct sky2_hw {
struct timer_list watchdog_timer;
struct work_struct restart_work;
wait_queue_head_t msi_wait;
+ spinlock_t pci_cfg_lock;
};
static inline int sky2_is_copper(const struct sky2_hw *hw)
--
1.5.6.5
^ permalink raw reply related
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