* 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 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 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: [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] 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: [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: 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
* 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: [RFC PATCH v1] tun: Cleanup error handling in tun_set_iff()
From: Eric W. Biederman @ 2009-08-05 23:14 UTC (permalink / raw)
To: Paul Moore; +Cc: netdev, David Miller, Herbert Xu
In-Reply-To: <200908051738.43134.paul.moore@hp.com>
Paul Moore <paul.moore@hp.com> writes:
> On Wednesday 05 August 2009 01:32:49 am Eric W. Biederman wrote:
>> Paul Moore <paul.moore@hp.com> writes:
>> > Convert some pointless gotos into returns and ensure tun_attach() errors
>> > are handled correctly.
>> >
>> > Signed-off-by: Paul Moore <paul.moore@hp.com>
>>
>> This patch appears slightly wrong. Comments inline.
>
> Thanks for taking a look ...
>
>> > I'm sending this as an RFC patch because I'm not entirely certain that
>> > the changes to the tun_attach() error handling code are 100% correct,
>> > although I strongly suspect that the current behavor of simply returning
>> > an error code without any cleanup is broken. Can anyone comment on this?
>> > ---
>> >
>> > drivers/net/tun.c | 19 ++++++++++---------
>> > 1 files changed, 10 insertions(+), 9 deletions(-)
>> >
>> > diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>> > index 4a0db7a..b6d06fd 100644
>> > --- a/drivers/net/tun.c
>> > +++ b/drivers/net/tun.c
>> > @@ -976,10 +973,11 @@ static int tun_set_iff(struct net *net, struct file
>> > *file, struct ifreq *ifr) tun->flags = flags;
>> > tun->txflt.count = 0;
>> >
>> > - err = -ENOMEM;
>> > sk = sk_alloc(net, AF_UNSPEC, GFP_KERNEL, &tun_proto);
>> > - if (!sk)
>> > + if (!sk) {
>> > + err = -ENOMEM;
>> > goto err_free_dev;
>> > + }
>>
>> Trivially correct but I would argue uglier.
>
> My reasoning behind the change was that code related to the error handling
> should be moved outside the common path as much as possible similar to what we
> do now with the gotos.
I don't understand. Generating less readable and less efficient code is
preferable?
>> > @@ -1010,7 +1008,7 @@ static int tun_set_iff(struct net *net, struct file
>> > *file, struct ifreq *ifr)
>> >
>> > err = tun_attach(tun, file);
>> > if (err < 0)
>> > - goto failed;
>> > + goto err_unreg_dev;
>> > }
>>
>> This is the interesting one. And several problems with it. When
>> Herbert reworked the reference counting here he introduced the goto
>> failed; Instead of err_free_dev.
>>
>> I think there were more possible races when I introduced the check
>> of the return code of tun_attach, the only case I can see currently
>> is if the file was attached to another tun device before we grabbed the
>> rtnl_lock.
>
> ...
>
>> > @@ -1039,11 +1037,14 @@ static int tun_set_iff(struct net *net, struct
>> > file *file, struct ifreq *ifr) strcpy(ifr->ifr_name, tun->dev->name);
>> > return 0;
>> >
>> > + err_unreg_dev:
>> > + rtnl_lock();
>> > + unregister_netdevice(tun->dev);
>> > + rtnl_unlock();
>>
>> This is a guaranteed deadlock. We already hold the rtnl_lock here.
>> Furthermore all I should need to do in this case is to call
>> unregister_netdevice(...). As all of the rest of the pieces should
>> happen in the cleanup routines called from unregister_netdevice.
>
> Okay, so at the very least the rtnl_[un]lock() calls need to be removed and we
> can safely return after calling unregister_netdevice() without having to
> free/release anything else. The thing that concerns me the most are the
> potential races you talked about.
>
> I'll admit there are many dark places here that I still don't understand but
> looking at the code it appears that the only way to get into tun_set_iff() is
> if the file is not currently attached to a TUN device which is further checked
> in tun_attach().
Yes. But how many times can you come into tun_set_iff on the same file?
Think multiple threads trying to do the same thing at the same time.
> Also, I'm not sure what refcounting you are talking about -
> do you mean the tun_file->count refcount? I think we should be okay in this
> regard as the only way we would end up changing tun_file->count is if
> tun_attach() completed successfully; if tun_attach() fails there is not change
> in the refcount. I could be way off here but it _seems_ safe ... :)
I totally agree that things are not as obvious as they should be. I made
things more complex when I added support for ip link del. Then Herbert's
patches collided and broke things when he added the socket support.
Herbert change the refcount scheme that made things simpler and easier
to get correct.
Things are mostly good now, but think the tun code could use good audit,
cleanup, simplification. Which takes advantage of everything that Herbert
did. All of which requires someone to spend enough time looking at the
code to understand what is going on. Not hard but a bit time consuming.
>> The current behavior of returning an error code is a little bit off
>> as it creates a persistent tun device without setting tun->flags |
>> TUN_PERSIST. And it leaves a tun device for someone else to clean up.
>>
>> At the same time it should be perfectly legitimate for someone else to
>> come along and attach to the tun device and delete it or to call
>> ip link del <tun>
>
> 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?
Sure. I am all for that and that is how I originally coded it.
My point is that this is not harmful and that it can really only be triggered
by a buggy or hostile user. So it isn't critical to get fixed. It is an
imperfect so a fix is desirable.
Eric
^ permalink raw reply
* Re: Kernel oops on setting sky2 interfaces down
From: Mike McCormack @ 2009-08-05 22:50 UTC (permalink / raw)
To: Rene Mayrhofer; +Cc: netdev, Richard Leitner, Stephen Hemminger
In-Reply-To: <4A7977A0.7070807@mayrhofer.eu.org>
Rene Mayrhofer wrote:
> What would be the simplest change to stop disabling phy when the last
> device goes down?
Commenting out the following line should stop all the phys from powering off:
sky2_phy_power_down(hw, port);
If you have a chance, please test "sky2: Add a mutex around ethtools operations" also.
it probably won't fix the problem you're seeing, but you never know...
thanks,
Mike
^ permalink raw reply
* [PATCH] sky2: Add a mutex around ethtools operations
From: Mike McCormack @ 2009-08-05 22:46 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger, Rene Mayrhofer, Richard Leitner
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>
---
drivers/net/sky2.c | 15 +++++++++++++++
drivers/net/sky2.h | 1 +
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
index 1415a83..96aad19 100644
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -3923,6 +3923,18 @@ static int sky2_set_eeprom(struct net_device *dev, struct ethtool_eeprom *eeprom
return sky2_vpd_write(sky2->hw, cap, data, eeprom->offset, eeprom->len);
}
+static int sky2_ethtool_begin(struct net_device *dev)
+{
+ struct sky2_port *sky2 = netdev_priv(dev);
+ mutex_lock(&sky2->hw->ethtool_mutex);
+ return 0;
+}
+
+static void sky2_ethtool_complete(struct net_device *dev)
+{
+ struct sky2_port *sky2 = netdev_priv(dev);
+ mutex_unlock(&sky2->hw->ethtool_mutex);
+}
static const struct ethtool_ops sky2_ethtool_ops = {
.get_settings = sky2_get_settings,
@@ -3954,6 +3966,8 @@ static const struct ethtool_ops sky2_ethtool_ops = {
.phys_id = sky2_phys_id,
.get_sset_count = sky2_get_sset_count,
.get_ethtool_stats = sky2_get_ethtool_stats,
+ .begin = sky2_ethtool_begin,
+ .complete = sky2_ethtool_complete,
};
#ifdef CONFIG_SKY2_DEBUG
@@ -4485,6 +4499,7 @@ static int __devinit sky2_probe(struct pci_dev *pdev,
}
hw->pdev = pdev;
+ mutex_init(&hw->ethtool_mutex);
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..199fb4a 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;
+ struct mutex ethtool_mutex;
};
static inline int sky2_is_copper(const struct sky2_hw *hw)
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH 1/1] veth: don't free priv->status until dev->destructor (v2)
From: Eric W. Biederman @ 2009-08-05 22:43 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Serge E. Hallyn, Linux Containers, Sachin Sant, netdev,
David Miller, matthltc, lkml
In-Reply-To: <20090805101005.6a02f0ae@nehalam>
Stephen Hemminger <shemminger@vyatta.com> writes:
>
> Sysfs must be safer than it used to be.
Definitely. A lot of this dates to Tejun's cleanups which merged
2-3 years agos now. Just before I started working on sysfs.
Eric
^ permalink raw reply
* [PATCH net-next-2.6] cxgb3: fix 2 ports 1G regression
From: Divy Le Ray @ 2009-08-05 21:59 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, swise
From: Divy Le Ray <divy@chelsio.com>
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>
---
drivers/net/cxgb3/t3_hw.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/net/cxgb3/t3_hw.c b/drivers/net/cxgb3/t3_hw.c
index 526e144..032cfe0 100644
--- a/drivers/net/cxgb3/t3_hw.c
+++ b/drivers/net/cxgb3/t3_hw.c
@@ -3692,8 +3692,12 @@ static void mc7_prep(struct adapter *adapter, struct mc7 *mc7,
void mac_prep(struct cmac *mac, struct adapter *adapter, int index)
{
+ u16 devid;
+
mac->adapter = adapter;
- if (!adapter->params.vpd.xauicfg[1])
+ pci_read_config_word(adapter->pdev, 0x2, &devid);
+
+ if (devid == 0x37 && !adapter->params.vpd.xauicfg[1])
index = 0;
mac->offset = (XGMAC0_1_BASE_ADDR - XGMAC0_0_BASE_ADDR) * index;
mac->nucast = 1;
^ permalink raw reply related
* Re: [RFC PATCH v1 1/2] lsm: Add hooks to the TUN driver
From: Paul Moore @ 2009-08-05 21:58 UTC (permalink / raw)
To: Serge E. Hallyn, eparis; +Cc: netdev, linux-security-module, selinux
In-Reply-To: <20090805141350.GA353@us.ibm.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.
> Also as Eric said this patch needs to set the cap_ hooks. This patch
> isn't yet introducing the selinux hooks, so iiuc actually this patch should
> always oops if CONFIG_SECURITY=y.
Yep, another symptom of not enough testing as I mentioned out in the original
posting, thanks to both of you for pointing this out ... now somebody just
needs to fix Rawhide so I can actually get a KVM instance running :)
--
paul moore
linux @ hp
^ permalink raw reply
* Re: [PATCH 2/3] af_ieee802154: provide dummy get/setsockopt
From: Dmitry Eremin-Solenikov @ 2009-08-05 21:41 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20090805.121714.182898812.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Wed, Aug 05, 2009 at 12:17:14PM -0700, David Miller wrote:
> From: Dmitry Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> 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.
If you say so, I can, of course, replace this patch with the one you
suggested. However I really don't see a point in doing this.
--
With best wishes
Dmitry
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ permalink raw reply
* Re: [RFC PATCH v1] tun: Cleanup error handling in tun_set_iff()
From: Paul Moore @ 2009-08-05 21:38 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: netdev, David Miller, Herbert Xu
In-Reply-To: <m1ljlyvn9a.fsf@fess.ebiederm.org>
On Wednesday 05 August 2009 01:32:49 am Eric W. Biederman wrote:
> Paul Moore <paul.moore@hp.com> writes:
> > Convert some pointless gotos into returns and ensure tun_attach() errors
> > are handled correctly.
> >
> > Signed-off-by: Paul Moore <paul.moore@hp.com>
>
> This patch appears slightly wrong. Comments inline.
Thanks for taking a look ...
> > I'm sending this as an RFC patch because I'm not entirely certain that
> > the changes to the tun_attach() error handling code are 100% correct,
> > although I strongly suspect that the current behavor of simply returning
> > an error code without any cleanup is broken. Can anyone comment on this?
> > ---
> >
> > drivers/net/tun.c | 19 ++++++++++---------
> > 1 files changed, 10 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> > index 4a0db7a..b6d06fd 100644
> > --- a/drivers/net/tun.c
> > +++ b/drivers/net/tun.c
> > @@ -976,10 +973,11 @@ static int tun_set_iff(struct net *net, struct file
> > *file, struct ifreq *ifr) tun->flags = flags;
> > tun->txflt.count = 0;
> >
> > - err = -ENOMEM;
> > sk = sk_alloc(net, AF_UNSPEC, GFP_KERNEL, &tun_proto);
> > - if (!sk)
> > + if (!sk) {
> > + err = -ENOMEM;
> > goto err_free_dev;
> > + }
>
> Trivially correct but I would argue uglier.
My reasoning behind the change was that code related to the error handling
should be moved outside the common path as much as possible similar to what we
do now with the gotos.
> > @@ -1010,7 +1008,7 @@ static int tun_set_iff(struct net *net, struct file
> > *file, struct ifreq *ifr)
> >
> > err = tun_attach(tun, file);
> > if (err < 0)
> > - goto failed;
> > + goto err_unreg_dev;
> > }
>
> This is the interesting one. And several problems with it. When
> Herbert reworked the reference counting here he introduced the goto
> failed; Instead of err_free_dev.
>
> I think there were more possible races when I introduced the check
> of the return code of tun_attach, the only case I can see currently
> is if the file was attached to another tun device before we grabbed the
> rtnl_lock.
...
> > @@ -1039,11 +1037,14 @@ static int tun_set_iff(struct net *net, struct
> > file *file, struct ifreq *ifr) strcpy(ifr->ifr_name, tun->dev->name);
> > return 0;
> >
> > + err_unreg_dev:
> > + rtnl_lock();
> > + unregister_netdevice(tun->dev);
> > + rtnl_unlock();
>
> This is a guaranteed deadlock. We already hold the rtnl_lock here.
> Furthermore all I should need to do in this case is to call
> unregister_netdevice(...). As all of the rest of the pieces should
> happen in the cleanup routines called from unregister_netdevice.
Okay, so at the very least the rtnl_[un]lock() calls need to be removed and we
can safely return after calling unregister_netdevice() without having to
free/release anything else. The thing that concerns me the most are the
potential races you talked about.
I'll admit there are many dark places here that I still don't understand but
looking at the code it appears that the only way to get into tun_set_iff() is
if the file is not currently attached to a TUN device which is further checked
in tun_attach(). Also, I'm not sure what refcounting you are talking about -
do you mean the tun_file->count refcount? I think we should be okay in this
regard as the only way we would end up changing tun_file->count is if
tun_attach() completed successfully; if tun_attach() fails there is not change
in the refcount. I could be way off here but it _seems_ safe ... :)
> The current behavior of returning an error code is a little bit off
> as it creates a persistent tun device without setting tun->flags |
> TUN_PERSIST. And it leaves a tun device for someone else to clean up.
>
> At the same time it should be perfectly legitimate for someone else to
> come along and attach to the tun device and delete it or to call
> ip link del <tun>
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?
--
paul moore
linux @ hp
^ permalink raw reply
* Low latency diagnostic tools
From: Christoph Lameter @ 2009-08-05 21:10 UTC (permalink / raw)
To: netdev
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.
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>
^ permalink raw reply
* Re: [PATCH] dccp: missing destroy of percpu counter variable while unload module
From: Gerrit Renker @ 2009-08-05 20:18 UTC (permalink / raw)
To: Wei Yongjun; +Cc: dccp, Netdev, oakad
In-Reply-To: <4A793BE8.1060101@gmail.com>
| > WARNING: at lib/list_debug.c:26 __list_add+0x27/0x5c()
| > Hardware name: VMware Virtual Platform
| > list_add corruption. next->prev should be prev (c080c0c4), but was (null). (next
| > =ca7188cc).
| > Modules linked in: dccp(+) nfsd lockd nfs_acl auth_rpcgss exportfs sunrpc
| > Pid: 1956, comm: modprobe Not tainted 2.6.31-rc5 #55
| > Call Trace:
| > [<c042f8fa>] warn_slowpath_common+0x6a/0x81
| > [<c053a6cb>] ? __list_add+0x27/0x5c
| > [<c042f94f>] warn_slowpath_fmt+0x29/0x2c
| > [<c053a6cb>] __list_add+0x27/0x5c
| > [<c053c9b3>] __percpu_counter_init+0x4d/0x5d
| > [<ca9c90c7>] dccp_init+0x19/0x2ed [dccp]
| > [<c0401141>] do_one_initcall+0x4f/0x111
| > [<ca9c90ae>] ? dccp_init+0x0/0x2ed [dccp]
| > [<c06971b5>] ? notifier_call_chain+0x26/0x48
| > [<c0444943>] ? __blocking_notifier_call_chain+0x45/0x51
| > [<c04516f7>] sys_init_module+0xac/0x1bd
| > [<c04028e4>] sysenter_do_call+0x12/0x22
| >
| > Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
| > ---
Thanks a lot -- I have added this to the test-tree (which is still
2.6.31-rc1), until the patch is in net-2.6,
http://eden-feed.erg.abdn.ac.uk/cgi-bin/gitweb.cgi?p=dccp_exp.git;a=shortlog;h=dccp
git://eden-feed.erg.abdn.ac.uk/dccp_exp [subtree dccp]
I am wondering whether there is a relationship with
http://bugzilla.kernel.org/show_bug.cgi?id=13692
and am cc:ing Alex Dubov, who reported it.
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: Changes to support the "-f" option of ethtool.
From: David Miller @ 2009-08-05 20:17 UTC (permalink / raw)
To: bhutchings; +Cc: ajitk, jgarzik, netdev
In-Reply-To: <1249477567.2781.21.camel@achroite>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 05 Aug 2009 14:06:07 +0100
> request_firmware() is meant for loading firmware that is stored in
> volatile memory (RAM) on the device and therefore needs to be installed
> on the host.
>
> When the firmware is stored in flash on the device, updates only need to
> be used once, and there should be no need to install them on the host.
> So request_firmware() does not seem suitable.
>
> I believe the ethtool EEPROM commands were meant for updating firmware
> on NICs. Although they assume random access and so are unsuitable for
> flash-based firmware, they might be a better model for adding flash
> update commands. However, this command set is already available through
> the MTD device class, which is what we use for firmware update as far as
> possible. Not only does this allow for an arbitrary number of separate
> firmware partitions per network device, but it can be used in an
> out-of-tree driver for older kernel versions.
I mostly agree with this. Either use MTD or create an ethtool
operation that explicitly specifies the file to flash onto the
chip. If you want, I suppose you can take no explicit file
specification to mean "whatever firmware was loaded into the
chip by the driver and is running right now"
^ permalink raw reply
* Re: [0/6] vxge: a few bug fixes and performance tweaks for vxge
From: David Miller @ 2009-08-05 20:11 UTC (permalink / raw)
To: ben.lahaise; +Cc: netdev
In-Reply-To: <20090804202013.GA9924@neterion.com>
From: Benjamin LaHaise <ben.lahaise@neterion.com>
Date: Tue, 4 Aug 2009 16:20:13 -0400
> This patch series consists of several bug fixes and performance enhancements
> for the vxge driver. They have passed internal QA. Please apply.
>
> [1/6] vxge: don't drop frame on tx queue full
> [2/6] vxge: fix pktgen hangs (don't abuse skb->cb[])
> [3/6] vxge: improve tx performance by using mmiowb() instead of wmb()
> [4/6] vxge: prefetch RxD descriptors
> [5/6] vxge: prefetch skb->data
> [6/6] vxge: Version update
>
> Signed-off-by: Benjamin LaHaise <ben.lahaise@neterion.com>
All applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [net-2.6 PATCH] ixgbe: allow vlan egress priority mapping in DCB mode
From: David Miller @ 2009-08-05 20:06 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, lucy.liu
In-Reply-To: <20090805012726.24350.63928.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 04 Aug 2009 18:27:28 -0700
> The skb priority to vlan-qos egress mapping that can be configured using
> set_egress_map with vconfig is overriden by the DCB code in the driver.
>
> This patch allows this existing mechanism to work and will increase the
> configuration flexibility of DCB mode on Linux.
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] be2net:Patch to perform function reset at initialization
From: David Miller @ 2009-08-05 20:05 UTC (permalink / raw)
To: sarveshwarb; +Cc: netdev
In-Reply-To: <20090805113923.GA15874@serverengines.com>
From: Sarveshwar Bandi <sarveshwarb@serverengines.com>
Date: Wed, 5 Aug 2009 17:09:32 +0530
> This patch is a bug fix to avoid system going into a bad state when driver
> is loaded in context of kdump kernel. The patch fixes the issue by performing
> a soft reset of pci function at probe time.
>
> Signed-off-by: sarveshwarb <sarveshwarb@serverengines.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 2/2] net: implement a SO_DOMAIN getsockoption
From: David Miller @ 2009-08-05 20:04 UTC (permalink / raw)
To: jengelh; +Cc: netdev
In-Reply-To: <1249406909-24161-2-git-send-email-jengelh@medozas.de>
From: Jan Engelhardt <jengelh@medozas.de>
Date: Tue, 4 Aug 2009 19:28:29 +0200
> This sockopt goes in line with SO_TYPE and SO_PROTOCOL. It makes it
> possible for userspace programs to pass around file descriptors — I
> am referring to arguments-to-functions, but it may even work for the
> fd passing over UNIX sockets — without needing to also pass the
> auxiliary information (PF_INET6/IPPROTO_TCP).
>
> Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
Also applied to net-next-2.6
Thanks
^ permalink raw reply
* Re: [PATCH 1/2] net: implement a SO_PROTOCOL getsockoption
From: David Miller @ 2009-08-05 20:04 UTC (permalink / raw)
To: jengelh; +Cc: netdev
In-Reply-To: <1249406909-24161-1-git-send-email-jengelh@medozas.de>
From: Jan Engelhardt <jengelh@medozas.de>
Date: Tue, 4 Aug 2009 19:28:28 +0200
> Similar to SO_TYPE returning the socket type, SO_PROTOCOL allows to
> retrieve the protocol used with a given socket.
>
> I am not quite sure why we have that-many copies of socket.h, and why
> the values are not the same on all arches either, but for where hex
> numbers dominate, I use 0x1029 for SO_PROTOCOL as that seems to be
> the next free unused number across a bunch of operating systems, or
> so Google results make me want to believe. SO_PROTOCOL for others
> just uses the next free Linux number, 38.
>
> Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH NEXT 3/3] netxen: add hardware LRO support
From: David Miller @ 2009-08-05 19:41 UTC (permalink / raw)
To: dhananjay; +Cc: davem, netdev, narender.kumar
In-Reply-To: <1249493649-26336-3-git-send-email-dhananjay@netxen.com>
From: Dhananjay Phadke <dhananjay@netxen.com>
Date: Wed, 5 Aug 2009 10:34:09 -0700
> Add support to handle aggregate packets from firmware.
> Local TCP flows are automatically identified by firmware
> based on the dest IP hash added by driver for local IP
> addresses.
>
> The packets are sent down on the jumbo rx ring.
>
> Signed-off-by: Narender Kumar <narender.kumar@qlogic.com>
> Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Applied.
^ 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