* Re: [patch -next v2] mv643xx_eth: potential null dereference
From: walter harms @ 2010-07-25 14:47 UTC (permalink / raw)
To: Lennert Buytenhek
Cc: Dan Carpenter, Joe Perches, David S. Miller, Jiri Pirko,
Denis Kirjanov, Saeed Bishara, netdev, kernel-janitors
In-Reply-To: <20100724190036.GA21121@mail.wantstofly.org>
Lennert Buytenhek schrieb:
> On Sat, Jul 24, 2010 at 10:59:07AM +0200, walter harms wrote:
>
>> IMHO it would be better to make sure that pd->t_clk,pd->tx_csum_limit
>> have usefull values than adding a check but this is up to the maintainer.
>
> I don't see the point of that at all. We check against zero to see
> whether the caller bothered to fill in the field at all, but if the
> caller wants to pass in bogus values, that's up to the caller.
>
at first i have to admit i looked only at the patch.
for me the situation looks this way:
You check the values for 0 (and uses default) or take what ever in pd is.
The current code is setup like:
1. check if pd is set
2. check if pd->value is non zero and use it
the whole "check X" can be avoided if you could create a pd with all values
set to default and just take what comes from the user.
my objection agains this kind of code is that it is not obvious
what some one is trying to archive
(pd != NULL && pd->t_clk != 0) ? pd->t_clk : 133000000;
the pd check means: do i have a configuration ?
the pd->t_clk != 0 means: should i use then or default ?
This is mixing two very different questions. therefore my idea in the last
posting to have a default init if (!pd) and then use the else to make clear
that additional checks for pd->value are expected.
this this is the init code readability and simplicity should be king.
hope that helps,
re,
wh
^ permalink raw reply
* [PATCH] nf_conntrack_extend: introduce __nf_ct_ext_exist()
From: Changli Gao @ 2010-07-25 14:38 UTC (permalink / raw)
To: Patrick McHardy; +Cc: David S. Miller, netfilter-devel, netdev, Changli Gao
some users of nf_ct_ext_exist() know ct->ext isn't NULL. For these users, the
check for ct->ext isn't necessary, the function __nf_ct_ext_exist() can be
used instead.
the type of the return value of nf_ct_ext_exist() is changed to bool.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
----
include/net/netfilter/nf_conntrack_extend.h | 9 +++++++--
net/netfilter/nf_conntrack_extend.c | 22 ++++++++++++----------
2 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/include/net/netfilter/nf_conntrack_extend.h b/include/net/netfilter/nf_conntrack_extend.h
index 32d15bd..0772d29 100644
--- a/include/net/netfilter/nf_conntrack_extend.h
+++ b/include/net/netfilter/nf_conntrack_extend.h
@@ -28,9 +28,14 @@ struct nf_ct_ext {
char data[0];
};
-static inline int nf_ct_ext_exist(const struct nf_conn *ct, u8 id)
+static inline bool __nf_ct_ext_exist(const struct nf_ct_ext *ext, u8 id)
{
- return (ct->ext && ct->ext->offset[id]);
+ return !!ext->offset[id];
+}
+
+static inline bool nf_ct_ext_exist(const struct nf_conn *ct, u8 id)
+{
+ return (ct->ext && __nf_ct_ext_exist(ct->ext, id));
}
static inline void *__nf_ct_ext_find(const struct nf_conn *ct, u8 id)
diff --git a/net/netfilter/nf_conntrack_extend.c b/net/netfilter/nf_conntrack_extend.c
index fdc8fb4..7dcf7a4 100644
--- a/net/netfilter/nf_conntrack_extend.c
+++ b/net/netfilter/nf_conntrack_extend.c
@@ -23,9 +23,10 @@ void __nf_ct_ext_destroy(struct nf_conn *ct)
{
unsigned int i;
struct nf_ct_ext_type *t;
+ struct nf_ct_ext *ext = ct->ext;
for (i = 0; i < NF_CT_EXT_NUM; i++) {
- if (!nf_ct_ext_exist(ct, i))
+ if (!__nf_ct_ext_exist(ext, i))
continue;
rcu_read_lock();
@@ -73,44 +74,45 @@ static void __nf_ct_ext_free_rcu(struct rcu_head *head)
void *__nf_ct_ext_add(struct nf_conn *ct, enum nf_ct_ext_id id, gfp_t gfp)
{
- struct nf_ct_ext *new;
+ struct nf_ct_ext *old, *new;
int i, newlen, newoff;
struct nf_ct_ext_type *t;
/* Conntrack must not be confirmed to avoid races on reallocation. */
NF_CT_ASSERT(!nf_ct_is_confirmed(ct));
- if (!ct->ext)
+ old = ct->ext;
+ if (!old)
return nf_ct_ext_create(&ct->ext, id, gfp);
- if (nf_ct_ext_exist(ct, id))
+ if (__nf_ct_ext_exist(old, id))
return NULL;
rcu_read_lock();
t = rcu_dereference(nf_ct_ext_types[id]);
BUG_ON(t == NULL);
- newoff = ALIGN(ct->ext->len, t->align);
+ newoff = ALIGN(old->len, t->align);
newlen = newoff + t->len;
rcu_read_unlock();
- new = __krealloc(ct->ext, newlen, gfp);
+ new = __krealloc(old, newlen, gfp);
if (!new)
return NULL;
- if (new != ct->ext) {
+ if (new != old) {
for (i = 0; i < NF_CT_EXT_NUM; i++) {
- if (!nf_ct_ext_exist(ct, i))
+ if (!__nf_ct_ext_exist(old, i))
continue;
rcu_read_lock();
t = rcu_dereference(nf_ct_ext_types[i]);
if (t && t->move)
t->move((void *)new + new->offset[i],
- (void *)ct->ext + ct->ext->offset[i]);
+ (void *)old + old->offset[i]);
rcu_read_unlock();
}
- call_rcu(&ct->ext->rcu, __nf_ct_ext_free_rcu);
+ call_rcu(&old->rcu, __nf_ct_ext_free_rcu);
ct->ext = new;
}
^ permalink raw reply related
* Re: Question about way that NICs deliver packets to the kernel
From: Junchang Wang @ 2010-07-25 14:18 UTC (permalink / raw)
To: Rick Jones, netdev; +Cc: Ben Hutchings, romieu
In-Reply-To: <4C45D9FA.5090108@hp.com>
Hi list,
> Clearly something is out of joint - let's go off-list (or on to
> netperf-talk@netperf.org) and hash that out to see what may be happening.
> It will probably involve variations on grabbing the top-of-trunk, adding
> the debug option etc.
>
The discrepancy between netperf and top has been worked out.
It seems top produce buggy data when I try to send output to a file.
For example, "top -b > output" gives out my previous buggy data in its
first iteration.
Actually, the report of top should be:
top - 21:37:15 up 21 min, 6 users, load average: 0.43, 0.28, 0.19
Tasks: 152 total, 2 running, 149 sleeping, 0 stopped, 1 zombie
Cpu(s): 0.2%us, 5.4%sy, 0.0%ni, 50.9%id, 0.0%wa, 0.0%hi, 43.5%si, 0.0%
Mem: 2074064k total, 690192k used, 1383872k free, 39372k buffers
Swap: 2096476k total, 0k used, 2096476k free, 435056k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3916 root 20 0 2228 584 296 R 86.3 0.0 0:09.72 netserver
I think 50.9% system idle makes sense because this is a dual-core system
and netserver is consuming 86.3% of a core. On average, the CPU usage
of the whole system reported by top can be regarded as from 46.2% to
50.1%.
netperf's report of 48% is right and testifies that "there is no huge
discrepancy
between the overall CPU utilization reported by top and the CPU utilization
reported by netperf."
Thanks Rick.
--
--Junchang
^ permalink raw reply
* Re: [PATCH 0/2] ks8842: Support for passing flags via platform data and 100 Mbps support
From: Richard Röjfors @ 2010-07-25 12:13 UTC (permalink / raw)
To: netdev; +Cc: davem
In-Reply-To: <1280003108.28285.279.camel@debian>
On 07/24/2010 10:25 PM, Richard Röjfors wrote:
> To follow are two patches
> * Introduce a flags field in the platform data.
> * removes flow control and advertise 100Mbps
Forget these two patches, I missed the patch from David Choi.
My patches won't apply after his.
--Richard
^ permalink raw reply
* Re: [PATCH] CAN: Add Flexcan CAN controller driver
From: Marc Kleine-Budde @ 2010-07-25 12:01 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: wg, socketcan-core, netdev, davem
In-Reply-To: <4C4C1EDE.7020400@hartkopp.net>
[-- Attachment #1: Type: text/plain, Size: 3025 bytes --]
Oliver Hartkopp wrote:
> first of all thanks for your contribution of the flexcan driver!
You're welcome!
> But i have a question regarding the Kconfig change that has been finally
> committed to net-next-2.6.
> It looks like the pulled code has some extra HAVE_CAN_FLEXCAN config option -
> which may be something of your debugging environment - which was not part of
> the original posted patch, where CAN_FLEXCAN depended on (ARCH_MX25 || ARCH_MX35).
Indeed this was not in the patch that Wolfgang Acked.
However, after Wolfgang's Ack I discussed the arm patches with the imx
people. I switched to dynamically registered devies, which is a more
modern way of registering them. And this led to the
"IMX_HAVE_PLATFORM_FLEXCAN" symbol (see below) and then we thought a
platform independent "HAVE_CAN_FLEXCAN" is even better.
So this was intentional (and in the latest patch I posed with the final
pull request.)
> Please see the two posted sections below ...
> The depency of (ARCH_MX25 || ARCH_MX35) makes more sense to me ;-)
The idea behind the "HAVE_CAN_FLEXCAN" is that all architectures select
this symbol if they have a flexcan core (which is supported by this
driver). On the imx platform we make this even in finer granularity.
BTW: If we on ARM finally have OF tree support we can change this easily
without needing to go over the net-next-2.6 tree.
Have a look at the corresponding ARM commits:
http://git.pengutronix.de/?p=imx/linux-2.6.git;a=commit;h=d7aec06a0decceabde9d9be6957229485568964b
http://git.pengutronix.de/?p=imx/linux-2.6.git;a=commit;h=b5a326c8c0a01692e710fc6086ddf84128b7a7d3
Here in detail+
http://git.pengutronix.de/?p=imx/linux-2.6.git;a=blob;f=arch/arm/plat-mxc/devices/Kconfig;h=9ab784b776f9192a33feaff37ff21be99b0a3691;hb=d7aec06a0decceabde9d9be6957229485568964b
We define a symbol without a prompt "IMX_HAVE_PLATFORM_FLEXCAN" for the
imx arm platform. This symbol selects "HAVE_CAN_FLEXCAN".
http://git.pengutronix.de/?p=imx/linux-2.6.git;a=blob;f=arch/arm/plat-mxc/devices/platform-flexcan.c;h=5e97a01f14f3eb106750f00d8a0fffb66f2c9563;hb=d7aec06a0decceabde9d9be6957229485568964b
A selected "IMX_HAVE_PLATFORM_FLEXCAN" symbol activates some glue code
that's used to create the individual flexcan devices.
It's up to the individual board code to select the
"IMX_HAVE_PLATFORM_FLEXCAN" symbol. This patch adds the flexcan support
on the pcm043:
http://git.pengutronix.de/?p=imx/linux-2.6.git;a=blobdiff;f=arch/arm/mach-mx3/Kconfig;h=03563eb997c0f761ea7d7e14d155facfce880e03;hp=e063657e1bf4c3f3d56a67e70bc3f17b333cfb55;hb=b5a326c8c0a01692e710fc6086ddf84128b7a7d3;hpb=d7aec06a0decceabde9d9be6957229485568964b
I hope that answers you question,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
^ permalink raw reply
* Re: [PATCH] CAN: Add Flexcan CAN controller driver
From: Oliver Hartkopp @ 2010-07-25 11:24 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: wg, socketcan-core, netdev, davem
In-Reply-To: <1279816844-12138-1-git-send-email-mkl@pengutronix.de>
Hello Marc,
first of all thanks for your contribution of the flexcan driver!
But i have a question regarding the Kconfig change that has been finally
committed to net-next-2.6.
It looks like the pulled code has some extra HAVE_CAN_FLEXCAN config option -
which may be something of your debugging environment - which was not part of
the original posted patch, where CAN_FLEXCAN depended on (ARCH_MX25 || ARCH_MX35).
Please see the two posted sections below ...
The depency of (ARCH_MX25 || ARCH_MX35) makes more sense to me ;-)
Regards,
Oliver
On 22.07.2010 18:40, Marc Kleine-Budde wrote:
> Hello,
>
> sorry for the confusion about the last minute problem with the driver,
> it was false alarm. Someone had troubles a driver derived from fsl's
> original one.
>
> David, please feel free to merge the driver now. :)
>
> Cheers, Marc
> diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
> index 2c5227c..9d9e453 100644
> --- a/drivers/net/can/Kconfig
> +++ b/drivers/net/can/Kconfig
> @@ -73,6 +73,15 @@ config CAN_JANZ_ICAN3
> This driver can also be built as a module. If so, the module will be
> called janz-ican3.ko.
>
> +config HAVE_CAN_FLEXCAN
> + bool
> +
> +config CAN_FLEXCAN
> + tristate "Support for Freescale FLEXCAN based chips"
> + depends on CAN_DEV && HAVE_CAN_FLEXCAN
> + ---help---
> + Say Y here if you want to support for Freescale FlexCAN.
> +
> source "drivers/net/can/mscan/Kconfig"
>
> source "drivers/net/can/sja1000/Kconfig"
On 21.07.2010 23:04, Marc Kleine-Budde wrote:
> diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
> index 2c5227c..25924dd 100644
> --- a/drivers/net/can/Kconfig
> +++ b/drivers/net/can/Kconfig
> @@ -73,6 +73,12 @@ config CAN_JANZ_ICAN3
> This driver can also be built as a module. If so, the module will be
> called janz-ican3.ko.
>
> +config CAN_FLEXCAN
> + tristate "Support for Freescale FLEXCAN based chips"
> + depends on CAN_DEV && (ARCH_MX25 || ARCH_MX35)
> + ---help---
> + Say Y here if you want to support for Freescale FlexCAN.
> +
> source "drivers/net/can/mscan/Kconfig"
>
> source "drivers/net/can/sja1000/Kconfig"
^ permalink raw reply
* Re: [PATCH UPDATED 1/3] vhost: replace vhost_workqueue with per-vhost kthread
From: Michael S. Tsirkin @ 2010-07-25 10:04 UTC (permalink / raw)
To: Tejun Heo
Cc: Oleg Nesterov, Sridhar Samudrala, netdev, lkml,
kvm@vger.kernel.org, Andrew Morton, Dmitri Vorobiev, Jiri Kosina,
Thomas Gleixner, Ingo Molnar, Andi Kleen
In-Reply-To: <4C4BEAA2.6040301@kernel.org>
On Sun, Jul 25, 2010 at 09:41:22AM +0200, Tejun Heo wrote:
> Hello,
>
> On 07/24/2010 09:14 PM, Michael S. Tsirkin wrote:
> >> I've created kthread_worker in wq#for-next tree and already converted
> >> ivtv to use it. Once this lands in mainline, I think converting vhost
> >> to use it would be better choice. kthread worker code uses basically
> >> the same logic used in the vhost_workqueue code but is better
> >> organized and documented. So, I think it would be better to stick
> >> with the original implementation, as otherwise we're likely to just
> >> decrease test coverage without much gain.
> >>
> >> http://git.kernel.org/?p=linux/kernel/git/tj/wq.git;a=commitdiff;h=b56c0d8937e665a27d90517ee7a746d0aa05af46;hp=53c5f5ba42c194cb13dd3083ed425f2c5b1ec439
> >
> > Sure, if we keep using workqueue. But I'd like to investigate this
> > direction a bit more because there's discussion to switching from kthread to
> > regular threads altogether.
>
> Hmmm? It doesn't have much to do with workqueue. kthread_worker is a
> simple wrapper around kthread. It now assumes kthread but changing it
> to be useable with any thread shouldn't be too hard. Wouldn't that be
> better?
Yes, of course, when common code becomes available we should
switch to that.
> >> I don't think doing this before executing the function is correct,
> >
> > Well, before I execute the function work is NULL, so this is skipped.
> > Correct?
> >
> >> so
> >> you'll have to release the lock, execute the function, regrab the lock
> >> and then do the flush processing.
> >>
> >> Thanks.
> >
> > It's done in the loop, so I thought we can reuse the locking
> > done for the sake of processing the next work item.
> > Makes sense?
>
> Yeap, right. I think it would make much more sense to use common code
> when it becomes available but if you think the posted change is
> necessary till then, please feel free to go ahead.
>
> Thanks.
>
> --
> tejun
^ permalink raw reply
* Re: [PATCH net-next-2.6] pktgen: Optionally leak kernel memory
From: Eric Dumazet @ 2010-07-25 8:27 UTC (permalink / raw)
To: David Miller; +Cc: greearb, netdev
In-Reply-To: <20100724.213519.260107516.davem@davemloft.net>
Le samedi 24 juillet 2010 à 21:35 -0700, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Sat, 24 Jul 2010 16:13:15 +0200
>
> > I am not sure David will accept the patch !
>
> I don't think I can apply this, sorry :-)
Absolutely.
It might be possible for pktgen to use a pool of prebuilt pages to avoid
the cost of clearing pages. This wont work for skb without frags, unless
we change skb_release_data() (it calls kfree(skb->head), I dont think we
can trap this one...)
One better idea would be to take an extra reference on skb before giving
it to transmit, and maintain a list of skbs to recycle once their
refcount hits 1 (our reference). We could avoid most of the skb
setup/freeing costs (no more memory allocations/freeing)
I'll take a look after my vacations, unless someone motivated enough
beats me of course :)
Thanks !
^ permalink raw reply
* Re: [PATCH UPDATED 1/3] vhost: replace vhost_workqueue with per-vhost kthread
From: Tejun Heo @ 2010-07-25 7:41 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Oleg Nesterov, Sridhar Samudrala, netdev, lkml,
kvm@vger.kernel.org, Andrew Morton, Dmitri Vorobiev, Jiri Kosina,
Thomas Gleixner, Ingo Molnar, Andi Kleen
In-Reply-To: <20100724191447.GA4972@redhat.com>
Hello,
On 07/24/2010 09:14 PM, Michael S. Tsirkin wrote:
>> I've created kthread_worker in wq#for-next tree and already converted
>> ivtv to use it. Once this lands in mainline, I think converting vhost
>> to use it would be better choice. kthread worker code uses basically
>> the same logic used in the vhost_workqueue code but is better
>> organized and documented. So, I think it would be better to stick
>> with the original implementation, as otherwise we're likely to just
>> decrease test coverage without much gain.
>>
>> http://git.kernel.org/?p=linux/kernel/git/tj/wq.git;a=commitdiff;h=b56c0d8937e665a27d90517ee7a746d0aa05af46;hp=53c5f5ba42c194cb13dd3083ed425f2c5b1ec439
>
> Sure, if we keep using workqueue. But I'd like to investigate this
> direction a bit more because there's discussion to switching from kthread to
> regular threads altogether.
Hmmm? It doesn't have much to do with workqueue. kthread_worker is a
simple wrapper around kthread. It now assumes kthread but changing it
to be useable with any thread shouldn't be too hard. Wouldn't that be
better?
>> I don't think doing this before executing the function is correct,
>
> Well, before I execute the function work is NULL, so this is skipped.
> Correct?
>
>> so
>> you'll have to release the lock, execute the function, regrab the lock
>> and then do the flush processing.
>>
>> Thanks.
>
> It's done in the loop, so I thought we can reuse the locking
> done for the sake of processing the next work item.
> Makes sense?
Yeap, right. I think it would make much more sense to use common code
when it becomes available but if you think the posted change is
necessary till then, please feel free to go ahead.
Thanks.
--
tejun
^ permalink raw reply
* [PATCH] Driver-core: Always create class directories for classses that support namespaces.
From: Eric W. Biederman @ 2010-07-25 5:43 UTC (permalink / raw)
To: Linus Torvalds
Cc: Johannes Berg, Kay Sievers, Andrew Morton, Greg KH,
Rafael J. Wysocki, Maciej W. Rozycki, netdev,
<linux-kernel@vger.kernel.org> Marcel Holtmann,
linux-bluetooth, Greg KH
In-Reply-To: <20100722185449.GB528@suse.de>
This fixes the regression in 2.6.35-rcX where bluetooth network devices would
fail to be deleted from sysfs, causing their destruction and recreation to
fail. In addition this fixes the mac80211_hwsim driver where it would leave
around sysfs files when the driver was removed. This problem is discussed at
https://bugzilla.kernel.org/show_bug.cgi?id=16257
The reason for the regression is that the network namespace support added to
sysfs expects and requires that network devices be put in directories that can
contain only network devices. Today get_device_parent almost provides that
guarantee for all class devices, except for a specific exception when the
parent of a class devices is a class device. It would be nice to simply
remove that arguably incorrect special case, but apparently the input devices
depend on it being there. So I have only removed it for class devices with
network namespace support. Which today are the network devices.
It has been suggested that a better fix would be to change the parent device
from a class device to a bus device, which in the case of the bluetooth driver
would change /sys/class/bluetooth to /sys/bus/bluetoth, I can not see how we
would avoid significant userspace breakage if we were to make that change.
Adding an extra directory in the path to the device will also be userspace
visible but it is much less likely to break things. Everything is still
accessible from /sys/class (for example), and it fixes two bugs. Adding an
extra directory fixes a 3 year old regression introduced with the new sysfs
layout that makes if impossible to rename bnep0 network devices to names that
conflict with hci device attributes like hci_revsion. Adding an additional
directory remove the new failure modes introduced by the network namespace
code.
If it weren't for the regession in the renaming of network devices I would
figure out how to just make the sysfs code deal with this configuration of
devices.
In summary this patch fixes regressions by changing:
"/sys/class/bluetooth/hci0/bnep0" to "/sys/class/bluetooth/hci0/net/bnep0".
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Reported-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
p.s. Linus my apologies for sending this directly but I have gotten an
incredible amount of flak trying to fix this problem, and I would like
not to leave an accidental regression whose cause is well known in
2.6.35 if I can help it.
drivers/base/core.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 9630fbd..9b9d3bd 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -673,7 +673,7 @@ static struct kobject *get_device_parent(struct device *dev,
*/
if (parent == NULL)
parent_kobj = virtual_device_parent(dev);
- else if (parent->class)
+ else if (parent->class && !dev->class->ns_type)
return &parent->kobj;
else
parent_kobj = &parent->kobj;
--
1.6.5.2.143.g8cc62
^ permalink raw reply related
* Re: [PATCH net-next-2.6] pktgen: Optionally leak kernel memory
From: David Miller @ 2010-07-25 4:35 UTC (permalink / raw)
To: eric.dumazet; +Cc: greearb, netdev
In-Reply-To: <1279980795.2451.157.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 24 Jul 2010 16:13:15 +0200
> I am not sure David will accept the patch !
I don't think I can apply this, sorry :-)
^ permalink raw reply
* [PATCHv2 NEXT 1/2] qlcnic: fix loopback test
From: Amit Kumar Salecha @ 2010-07-25 4:32 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman
In-Reply-To: <1280032338-7002-1-git-send-email-amit.salecha@qlogic.com>
o Loopback not supported for virtual function.
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/qlcnic/qlcnic.h | 2 --
drivers/net/qlcnic/qlcnic_ethtool.c | 10 ++++++++--
drivers/net/qlcnic/qlcnic_main.c | 18 ------------------
3 files changed, 8 insertions(+), 22 deletions(-)
diff --git a/drivers/net/qlcnic/qlcnic.h b/drivers/net/qlcnic/qlcnic.h
index fad8e9a..9703893 100644
--- a/drivers/net/qlcnic/qlcnic.h
+++ b/drivers/net/qlcnic/qlcnic.h
@@ -1301,8 +1301,6 @@ struct qlcnic_nic_template {
int (*get_mac_addr) (struct qlcnic_adapter *, u8*);
int (*config_bridged_mode) (struct qlcnic_adapter *, u32);
int (*config_led) (struct qlcnic_adapter *, u32, u32);
- int (*set_ilb_mode) (struct qlcnic_adapter *);
- void (*clear_ilb_mode) (struct qlcnic_adapter *);
int (*start_firmware) (struct qlcnic_adapter *);
};
diff --git a/drivers/net/qlcnic/qlcnic_ethtool.c b/drivers/net/qlcnic/qlcnic_ethtool.c
index 7d6558e..9328d59 100644
--- a/drivers/net/qlcnic/qlcnic_ethtool.c
+++ b/drivers/net/qlcnic/qlcnic_ethtool.c
@@ -678,6 +678,12 @@ static int qlcnic_loopback_test(struct net_device *netdev)
int max_sds_rings = adapter->max_sds_rings;
int ret;
+ if (adapter->op_mode == QLCNIC_NON_PRIV_FUNC) {
+ dev_warn(&adapter->pdev->dev, "Loopback test not supported"
+ "for non privilege function\n");
+ return 0;
+ }
+
if (test_and_set_bit(__QLCNIC_RESETTING, &adapter->state))
return -EIO;
@@ -685,13 +691,13 @@ static int qlcnic_loopback_test(struct net_device *netdev)
if (ret)
goto clear_it;
- ret = adapter->nic_ops->set_ilb_mode(adapter);
+ ret = qlcnic_set_ilb_mode(adapter);
if (ret)
goto done;
ret = qlcnic_do_ilb_test(adapter);
- adapter->nic_ops->clear_ilb_mode(adapter);
+ qlcnic_clear_ilb_mode(adapter);
done:
qlcnic_diag_free_res(netdev, max_sds_rings);
diff --git a/drivers/net/qlcnic/qlcnic_main.c b/drivers/net/qlcnic/qlcnic_main.c
index f1f7acf..f147958 100644
--- a/drivers/net/qlcnic/qlcnic_main.c
+++ b/drivers/net/qlcnic/qlcnic_main.c
@@ -107,8 +107,6 @@ static void qlcnic_config_indev_addr(struct net_device *dev, unsigned long);
static int qlcnic_start_firmware(struct qlcnic_adapter *);
static void qlcnic_dev_set_npar_ready(struct qlcnic_adapter *);
-static void qlcnicvf_clear_ilb_mode(struct qlcnic_adapter *);
-static int qlcnicvf_set_ilb_mode(struct qlcnic_adapter *);
static int qlcnicvf_config_led(struct qlcnic_adapter *, u32, u32);
static int qlcnicvf_config_bridged_mode(struct qlcnic_adapter *, u32);
static int qlcnicvf_start_firmware(struct qlcnic_adapter *);
@@ -381,8 +379,6 @@ static struct qlcnic_nic_template qlcnic_ops = {
.get_mac_addr = qlcnic_get_mac_address,
.config_bridged_mode = qlcnic_config_bridged_mode,
.config_led = qlcnic_config_led,
- .set_ilb_mode = qlcnic_set_ilb_mode,
- .clear_ilb_mode = qlcnic_clear_ilb_mode,
.start_firmware = qlcnic_start_firmware
};
@@ -390,8 +386,6 @@ static struct qlcnic_nic_template qlcnic_vf_ops = {
.get_mac_addr = qlcnic_get_mac_address,
.config_bridged_mode = qlcnicvf_config_bridged_mode,
.config_led = qlcnicvf_config_led,
- .set_ilb_mode = qlcnicvf_set_ilb_mode,
- .clear_ilb_mode = qlcnicvf_clear_ilb_mode,
.start_firmware = qlcnicvf_start_firmware
};
@@ -2841,18 +2835,6 @@ qlcnicvf_config_led(struct qlcnic_adapter *adapter, u32 state, u32 rate)
return -EOPNOTSUPP;
}
-static int
-qlcnicvf_set_ilb_mode(struct qlcnic_adapter *adapter)
-{
- return -EOPNOTSUPP;
-}
-
-static void
-qlcnicvf_clear_ilb_mode(struct qlcnic_adapter *adapter)
-{
- return;
-}
-
static ssize_t
qlcnic_store_bridged_mode(struct device *dev,
struct device_attribute *attr, const char *buf, size_t len)
--
1.6.0.2
^ permalink raw reply related
* [PATCHv2 NEXT 2/2] qlcnic: fix diag resource allocation
From: Amit Kumar Salecha @ 2010-07-25 4:32 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, Sony Chacko
In-Reply-To: <1280032338-7002-1-git-send-email-amit.salecha@qlogic.com>
From: Sony Chacko <sony.chacko@qlogic.com>
netif_device_attach missing from error path in qlcnic_diag_alloc_res
Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/qlcnic/qlcnic_main.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/qlcnic/qlcnic_main.c b/drivers/net/qlcnic/qlcnic_main.c
index f147958..b9615bd 100644
--- a/drivers/net/qlcnic/qlcnic_main.c
+++ b/drivers/net/qlcnic/qlcnic_main.c
@@ -1176,6 +1176,7 @@ int qlcnic_diag_alloc_res(struct net_device *netdev, int test)
ret = qlcnic_fw_create_ctx(adapter);
if (ret) {
qlcnic_detach(adapter);
+ netif_device_attach(netdev);
return ret;
}
--
1.6.0.2
^ permalink raw reply related
* [PATCHv2 0/2]qlcnic: diagnostic fixes
From: Amit Kumar Salecha @ 2010-07-25 4:32 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman
Hi
Series v2 of 2 patches to fix diagnostic test.
Apply them on net-next.
-Amit
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: pskb_expand_head() optimization
From: David Miller @ 2010-07-25 4:06 UTC (permalink / raw)
To: eric.dumazet; +Cc: andrea, netdev
In-Reply-To: <1279861748.2482.13.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 23 Jul 2010 07:09:08 +0200
> [PATCH net-next-2.6] net: pskb_expand_head() optimization
>
> Move frags[] at the end of struct skb_shared_info, and make
> pskb_expand_head() copy only the used part of it instead of whole array.
>
> This should avoid kmemcheck warnings and speedup pskb_expand_head() as
> well, avoiding a lot of cache misses.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Maybe it's just that people aren't running kmemcheck when a
pskb_expand_head() triggers, who knows.
Anyways, since we skip the ->frag[] array in skb alloc, etc.,
your patch is of course fine.
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] net sched: fix race in mirred device removal
From: David Miller @ 2010-07-25 4:04 UTC (permalink / raw)
To: shemminger; +Cc: hadi, netdev
In-Reply-To: <20100722214504.42e0e7de@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 22 Jul 2010 21:45:04 -0700
> This fixes hang when target device of mirred packet classifier
> action is removed.
>
> If a mirror or redirection action is configured to cause packets
> to go to another device, the classifier holds a ref count, but was assuming
> the adminstrator cleaned up all redirections before removing. The fix
> is to add a notifier and cleanup during unregister.
>
> The new list is implicitly protected by RTNL mutex because
> it is held during filter add/delete as well as notifier.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> Acked-by: Jamal Hadi Salim <hadi@cyberus.ca>
Applied to net-2.6, thanks.
^ permalink raw reply
* Re: [PATCH] ipv6: remove sysctl jiffies conversion on gc_elasticity and min_adv_ms
From: David Miller @ 2010-07-25 4:03 UTC (permalink / raw)
To: mzhang; +Cc: netdev
In-Reply-To: <4C48BA82.6020904@mvista.com>
From: Min Zhang <mzhang@mvista.com>
Date: Thu, 22 Jul 2010 14:39:14 -0700
> sysctl output ipv6 gc_elasticity and min_adv_mss as values divided by
> HZ. However, they are not in unit of jiffies, since ip6_rt_min_advmss
> refers to packet size and ip6_rt_fc_elasticity is used as scaler as in
> expire>>ip6_rt_gc_elasticity, so replace the jiffies conversion
> handler will regular handler for them.
>
> This has impact on scripts that are currently working assuming the
> divide by HZ, will yield different results with this patch in place.
>
> Signed-off-by: Min Zhang <mzhang@mvista.com>
Your email client corrupted your patch, turning tab characters into
spaces. This makes your patch unusable.
Please resubmit this patch properly so that I can use it.
Thanks.
^ permalink raw reply
* Re: [patch 2.6.35] WiMAX pull request
From: David Miller @ 2010-07-25 3:52 UTC (permalink / raw)
To: inaky; +Cc: netdev, wimax, inaky.perez-gonzalez
In-Reply-To: <cover.1279843906.git.inaky.perez-gonzalez@intel.com>
From: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Date: Thu, 22 Jul 2010 17:15:13 -0700
> The following changes since commit a385a53e659b35ebee604889e21c40e5c336941f:
> Inaky Perez-Gonzalez (1):
> wimax/i2400m: fix missing endian correction read in fw loader
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/inaky/wimax.git wimax-2.6.35.y
>
> Patches follow for reviewing convenience.
>
> Alexey Shvetsov (1):
> wimax/i2400m: Add PID & VID for Intel WiMAX 6250
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH net-next] sysfs: add attribute to indicate hw address assignment type
From: David Miller @ 2010-07-25 3:50 UTC (permalink / raw)
To: sassmann
Cc: bhutchings, abadea, netdev, linux-kernel, gospo, gregory.v.rose,
alexander.h.duyck, leedom, harald
In-Reply-To: <4C485A0C.7020500@redhat.com>
From: Stefan Assmann <sassmann@redhat.com>
Date: Thu, 22 Jul 2010 16:47:40 +0200
> On 22.07.2010 16:07, Ben Hutchings wrote:
>> On Thu, 2010-07-22 at 14:50 +0200, Stefan Assmann wrote:
>>> On 21.07.2010 15:54, Ben Hutchings wrote:
>>>> On Wed, 2010-07-21 at 10:10 +0200, Stefan Assmann wrote:
>>>>> I put Alex' idea into code for further discussion, keeping the names
>>>>> mentioned here until we agree on the scope of this attribute. When we
>>>>> have settled I'll post a patch with proper patch description.
>>>> [...]
>>>>
>>>> Just a little nitpick: I think it would be clearer to use a more
>>>> specific term like 'address source' or 'address assignment type' rather
>>>> than 'address type'.
>>>
>>> Here's a proposal for the final patch.
>>
>> Looks good, but...
...
>> ...why '|=' and not '='?
>
> The intention is to use addr_assign_type as a bit field.
>
> Okay it it might not make too much sense to 'steal' a random MAC
> address but in case we add more types later it might get useful.
I think the patch is good enough to go into net-next-2.6 as-is, anything
remaining is a refinement or one sort or another.
So applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCH for-2.6.35] tun: avoid BUG, dump packet on GSO errors
From: David Miller @ 2010-07-25 3:47 UTC (permalink / raw)
To: herbert; +Cc: mst, netdev
In-Reply-To: <20100722130512.GA29088@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 22 Jul 2010 21:05:12 +0800
> Michael S. Tsirkin <mst@redhat.com> wrote:
>> There are still some LRO cards that cause GSO errors in tun,
>> and BUG on this is an unfriendly way to tell the admin
>> to disable LRO.
>>
>> Further, experience shows we might have more GSO bugs lurking.
>> See https://bugzilla.kernel.org/show_bug.cgi?id=16413
>> as a recent example.
>> dumping a packet will make it easier to figure it out.
>>
>> Replace BUG with warning+dump+drop the packet to make
>> GSO errors in tun less critical and easier to debug.
>>
>> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>> Tested-by: Alex Unigovsky <unik@compot.ru>
>
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks everyone.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] ixgbe: fix ethtool stats
From: David Miller @ 2010-07-25 3:43 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, eric.dumazet
In-Reply-To: <20100723234252.18203.56378.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 23 Jul 2010 16:44:21 -0700
> From: Eric Dumazet <eric.dumazet@gmail.com>
>
> In latest changes about 64bit stats on 32bit arches,
> [commit 28172739f0a276eb8 (net: fix 64 bit counters on 32 bit arches)],
> I missed ixgbe uses a bit of magic in its ixgbe_gstrings_stats
> definition.
>
> IXGBE_NETDEV_STAT() must now assume offsets relative to
> rtnl_link_stats64, not relative do dev->stats.
>
> As a bonus, we also get 64bit stats on ethtool -S
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Tested-by: Stephen Ko <stephen.s.ko@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH NEXT 2/2] qlcnic: diag fixes
From: David Miller @ 2010-07-25 3:42 UTC (permalink / raw)
To: gustavo; +Cc: amit.salecha, netdev, ameen.rahman
In-Reply-To: <20100724165343.GC9787@vigoh>
From: "Gustavo F. Padovan" <gustavo@padovan.org>
Date: Sat, 24 Jul 2010 13:53:43 -0300
> Hi Amit,
>
> * amit.salecha@qlogic.com <amit.salecha@qlogic.com> [2010-07-24 00:24:26 -0700]:
>
>> From: Amit Kumar Salecha <amit.salecha@qlogic.com>
>>
>> o Loopback not supported for virtual function.
>> o netif_device_attach was missing in error path from
>> qlcnic_diag_alloc_res
>
> This second part should be a new commit actually. It fixes a different
> thing.
Agreed.
^ permalink raw reply
* Re: [PATCH NEXT 1/2] qlcnic: fix bandwidth check
From: David Miller @ 2010-07-25 3:42 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman, rajesh.borundia
In-Reply-To: <1279956266-23445-2-git-send-email-amit.salecha@qlogic.com>
From: amit.salecha@qlogic.com
Date: Sat, 24 Jul 2010 00:24:25 -0700
> From: Rajesh Borundia <rajesh.borundia@qlogic.com>
>
> Fix maximum and minmum bandwith value.
>
> Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] bonding: set device in RLB ARP packet handler
From: David Miller @ 2010-07-25 3:38 UTC (permalink / raw)
To: andy; +Cc: fubar, greg.edwards, netdev, bonding-devel, linux-kernel
In-Reply-To: <20100723202648.GU7497@gospo.rdu.redhat.com>
From: Andy Gospodarek <andy@greyhouse.net>
Date: Fri, 23 Jul 2010 16:26:48 -0400
> On Fri, Jul 23, 2010 at 01:02:04PM -0700, Jay Vosburgh wrote:
>>
>> From: Greg Edwards <greg.edwards@hp.com>
>>
>> After:
>>
>> commit 6146b1a4da98377e4abddc91ba5856bef8f23f1e
>> Author: Jay Vosburgh <fubar@us.ibm.com>
>> Date: Tue Nov 4 17:51:15 2008 -0800
>>
>> bonding: Fix ALB mode to balance traffic on VLANs
>>
>> the dev field in the RLB ARP packet handler was set to NULL to wildcard
>> and accommodate balancing VLANs on top of bonds.
>>
>> This has the side-effect of the packet handler being called against
>> other, non RLB-enabled bonds, and a kernel oops results when it tries to
>> dereference rx_hashtbl in rlb_update_entry_from_arp(), which won't be
>> set for those bonds, e.g. active-backup.
>>
>> With the __netif_receive_skb() changes from:
>>
>> commit 1f3c8804acba841b5573b953f5560d2683d2db0d
>> Author: Andy Gospodarek <andy@greyhouse.net>
>> Date: Mon Dec 14 10:48:58 2009 +0000
>>
>> bonding: allow arp_ip_targets on separate vlans to use arp validation
>>
>> frames received on VLANs correctly make their way to the bond's handler,
>> so we no longer need to wildcard the device.
>>
>> The oops can be reproduced by:
>>
>> modprobe bonding
>>
>> echo active-backup > /sys/class/net/bond0/bonding/mode
>> echo 100 > /sys/class/net/bond0/bonding/miimon
>> ifconfig bond0 xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx
>> echo +eth0 > /sys/class/net/bond0/bonding/slaves
>> echo +eth1 > /sys/class/net/bond0/bonding/slaves
>>
>> echo +bond1 > /sys/class/net/bonding_masters
>> echo balance-alb > /sys/class/net/bond1/bonding/mode
>> echo 100 > /sys/class/net/bond1/bonding/miimon
>> ifconfig bond1 xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx
>> echo +eth2 > /sys/class/net/bond1/bonding/slaves
>> echo +eth3 > /sys/class/net/bond1/bonding/slaves
>>
>> Pass some traffic on bond0. Boom.
>>
>> [ Tested, behaves as advertised. I do not believe a test of the bonding
>> mode is necessary, as there is no race between the packet handler and
>> the bonding mode changing (the mode can only change when the device is
>> closed). Also updated the log message to include the reproduction and
>> full commit ids. -J ]
>>
>> Signed-off-by: Greg Edwards <greg.edwards@hp.com>
>> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
>
> Acked-by: Andy Gospodarek <andy@greyhouse.net>
This seems serious enough to put into net-2.6, so that's where I applied
it.
Thanks!
^ permalink raw reply
* [PATCH] 3c59x: Add ethtool WOL support
From: Andrew O. Shadoura @ 2010-07-25 2:24 UTC (permalink / raw)
To: Andrew Morton; +Cc: Netdev mailing list, Linux kernel mailing list
This patch adds wrappers for ethtool to get or set wake-on-LAN
setting without re-inserting the kernel module.
Signed-off-by: Andrew O. Shadoura <andrew@beldisplaytech.com>
---
Hello.
I've actually tested this patch on a machine with a network
card that's idenfied by lsusb as "3c905C-TX/TX-M", and it seems
to work.
---
diff --git a/drivers/net/3c59x.c b/drivers/net/3c59x.c
index d75803e..a452dfe 100644
--- a/drivers/net/3c59x.c
+++ b/drivers/net/3c59x.c
@@ -2909,6 +2909,36 @@ static void vortex_get_drvinfo(struct net_device *dev,
}
}
+static void vortex_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
+{
+ struct vortex_private *vp = netdev_priv(dev);
+
+ spin_lock_irq(&vp->lock);
+ wol->supported = WAKE_MAGIC;
+
+ wol->wolopts = 0;
+ if (vp->enable_wol)
+ wol->wolopts |= WAKE_MAGIC;
+ spin_unlock_irq(&vp->lock);
+}
+
+static int vortex_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
+{
+ struct vortex_private *vp = netdev_priv(dev);
+ if (wol->wolopts & ~WAKE_MAGIC)
+ return -EINVAL;
+
+ spin_lock_irq(&vp->lock);
+ if (wol->wolopts & WAKE_MAGIC)
+ vp->enable_wol = 1;
+ else
+ vp->enable_wol = 0;
+ acpi_set_WOL(dev);
+ spin_unlock_irq(&vp->lock);
+
+ return 0;
+}
+
static const struct ethtool_ops vortex_ethtool_ops = {
.get_drvinfo = vortex_get_drvinfo,
.get_strings = vortex_get_strings,
@@ -2920,6 +2950,8 @@ static const struct ethtool_ops vortex_ethtool_ops = {
.set_settings = vortex_set_settings,
.get_link = ethtool_op_get_link,
.nway_reset = vortex_nway_reset,
+ .get_wol = vortex_get_wol,
+ .set_wol = vortex_set_wol,
};
#ifdef CONFIG_PCI
--
WBR, Andrew
^ 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