* [PATCH 1/2] ks8842: Add flags in the platform data
From: Richard Röjfors @ 2010-07-24 20:25 UTC (permalink / raw)
To: netdev; +Cc: davem
Previously the driver did a write to a timberdale specific register.
Timberdale is a FPGA used in some hardware setup which communicates
to the ks8842 via VLB.
A flag field is introduced where it is possible to pass a flag if
the ks8842 is connected via timberdale. Otherwise the driver won't
try to access timberdale registers.
If the timberdale flag is passed the driver also acks interrupts
in the FPGA, this is a bit more polite to the FPGA state machine.
Signed-off-by: Richard Röjfors <richard.rojfors@pelagicore.com>
---
diff --git a/drivers/net/ks8842.c b/drivers/net/ks8842.c
index 0be9261..48e4582 100644
--- a/drivers/net/ks8842.c
+++ b/drivers/net/ks8842.c
@@ -33,7 +33,13 @@
#define DRV_NAME "ks8842"
/* Timberdale specific Registers */
-#define REG_TIMB_RST 0x1c
+#define REG_TIMB_RST 0x1c
+#define REG_TIMB_FIFO 0x20
+#define REG_TIMB_ISR 0x24
+#define REG_TIMB_IER 0x28
+#define REG_TIMB_IAR 0x2C
+#define REQ_TIMB_DMA_RESUME 0x30
+
/* KS8842 registers */
@@ -121,6 +127,7 @@ struct ks8842_adapter {
spinlock_t lock; /* spinlock to be interrupt safe */
struct work_struct timeout_work;
struct net_device *netdev;
+ u8 flags;
};
static inline void ks8842_select_bank(struct ks8842_adapter *adapter, u16 bank)
@@ -195,12 +202,15 @@ static void ks8842_reset(struct ks8842_adapter *adapter)
/* The KS8842 goes haywire when doing softare reset
* a work around in the timberdale IP is implemented to
* do a hardware reset instead
- ks8842_write16(adapter, 3, 1, REG_GRR);
- msleep(10);
- iowrite16(0, adapter->hw_addr + REG_GRR);
- */
- iowrite32(0x1, adapter->hw_addr + REG_TIMB_RST);
- msleep(20);
+ */
+ if (adapter->flags & KS8842_FLAGS_TIMB) {
+ iowrite32(0x1, adapter->hw_addr + REG_TIMB_RST);
+ msleep(20);
+ } else {
+ ks8842_write16(adapter, 3, 1, REG_GRR);
+ msleep(10);
+ iowrite16(0, adapter->hw_addr + REG_GRR);
+ }
}
static void ks8842_update_link_status(struct net_device *netdev,
@@ -463,6 +473,10 @@ void ks8842_tasklet(unsigned long arg)
/* Ack */
ks8842_write16(adapter, 18, isr, REG_ISR);
+ /* Ack in the timberdale IP as well */
+ if (adapter->flags & KS8842_FLAGS_TIMB)
+ iowrite32(0x1, adapter->hw_addr + REG_TIMB_IAR);
+
if (!netif_running(netdev))
return;
@@ -687,6 +701,8 @@ static int __devinit ks8842_probe(struct platform_device *pdev)
/* Check if a mac address was given */
i = netdev->addr_len;
if (pdata) {
+ adapter->flags = pdata->flags;
+
for (i = 0; i < netdev->addr_len; i++)
if (pdata->macaddr[i] != 0)
break;
diff --git a/include/linux/ks8842.h b/include/linux/ks8842.h
index da0341b..12b4bda 100644
--- a/include/linux/ks8842.h
+++ b/include/linux/ks8842.h
@@ -21,14 +21,18 @@
#include <linux/if_ether.h>
+#define KS8842_FLAGS_TIMB 0x01
+
/**
* struct ks8842_platform_data - Platform data of the KS8842 network driver
* @macaddr: The MAC address of the device, set to all 0:s to use the on in
* the chip.
+ * @flags: Flags to the drivers which configures the hardware setup
*
*/
struct ks8842_platform_data {
u8 macaddr[ETH_ALEN];
+ u8 flags;
};
#endif
^ permalink raw reply related
* [PATCH 0/2] ks8842: Support for passing flags via platform data and 100 Mbps support
From: Richard Röjfors @ 2010-07-24 20:25 UTC (permalink / raw)
To: netdev; +Cc: davem
To follow are two patches
* Introduce a flags field in the platform data.
* removes flow control and advertise 100Mbps
^ permalink raw reply
* Re: [PATCH UPDATED 1/3] vhost: replace vhost_workqueue with per-vhost kthread
From: Michael S. Tsirkin @ 2010-07-24 19:14 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: <4C48B664.9000109@kernel.org>
On Thu, Jul 22, 2010 at 11:21:40PM +0200, Tejun Heo wrote:
> Hello,
>
> On 07/22/2010 05:58 PM, Michael S. Tsirkin wrote:
> > All the tricky barrier pairing made me uncomfortable. So I came up with
> > this on top (untested): if we do all operations under the spinlock, we
> > can get by without barriers and atomics. And since we need the lock for
> > list operations anyway, this should have no paerformance impact.
> >
> > What do you think?
>
> 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.
> > @@ -151,37 +161,37 @@ static void vhost_vq_reset(struct vhost_dev *dev,
> > static int vhost_worker(void *data)
> > {
> > struct vhost_dev *dev = data;
> > - struct vhost_work *work;
> > + struct vhost_work *work = NULL;
> >
> > -repeat:
> > - set_current_state(TASK_INTERRUPTIBLE); /* mb paired w/ kthread_stop */
> > + for (;;) {
> > + set_current_state(TASK_INTERRUPTIBLE); /* mb paired w/ kthread_stop */
> >
> > - if (kthread_should_stop()) {
> > - __set_current_state(TASK_RUNNING);
> > - return 0;
> > - }
> > + if (kthread_should_stop()) {
> > + __set_current_state(TASK_RUNNING);
> > + return 0;
> > + }
> >
> > - work = NULL;
> > - spin_lock_irq(&dev->work_lock);
> > - if (!list_empty(&dev->work_list)) {
> > - work = list_first_entry(&dev->work_list,
> > - struct vhost_work, node);
> > - list_del_init(&work->node);
> > - }
> > - spin_unlock_irq(&dev->work_lock);
> > + spin_lock_irq(&dev->work_lock);
> > + if (work) {
> > + work->done_seq = work->queue_seq;
> > + if (work->flushing)
> > + wake_up_all(&work->done);
>
> 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?
> --
> tejun
^ permalink raw reply
* Re: [patch -next v2] mv643xx_eth: potential null dereference
From: Lennert Buytenhek @ 2010-07-24 19:00 UTC (permalink / raw)
To: walter harms
Cc: Dan Carpenter, Joe Perches, David S. Miller, Jiri Pirko,
Denis Kirjanov, Saeed Bishara, netdev, kernel-janitors
In-Reply-To: <4C4AAB5B.2050901@bfs.de>
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.
^ permalink raw reply
* Re: [PATCH NEXT 2/2] qlcnic: diag fixes
From: Gustavo F. Padovan @ 2010-07-24 16:53 UTC (permalink / raw)
To: amit.salecha; +Cc: davem, netdev, ameen.rahman
In-Reply-To: <1279956266-23445-3-git-send-email-amit.salecha@qlogic.com>
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.
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* Re: [PATCH net-next-2.6] pktgen: Optionally leak kernel memory
From: Ben Greear @ 2010-07-24 15:35 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, NetDev
In-Reply-To: <1279980795.2451.157.camel@edumazet-laptop>
On 07/24/2010 07:13 AM, Eric Dumazet wrote:
> Le samedi 24 juillet 2010 à 06:18 -0700, Ben Greear a écrit :
>
>> I think most users of pktgen wouldn't be too concerned about leaking
>> memory content to the network. It's a root-only test tool that can easily
>> saturate most networks and do horrible things like overflow switch CAM tables
>> by randomizing source/dest macs etc. So, this warning might could be a bit
>> more descriptive of how it is a security problem "arbitrary contents of memory can be
>> sent across the network and may be sniffed by devices on the network, potentially
>> revealing private information such as passwords and application data for applications
>> running on the machine running pktgen" instead of telling folks not to use it unless it's
>> really needed.
>
> Most of the horrible things you mention are not related to the memset()
> thing, arent they ?
>
>
> Being root means : "I am a trusted user on this machine, and as such,
> must know a bit what security means".
>
> It doesnt mean : "I am allowed to steal passwords, credit card numbers,
> from gentle users. I am allowed to blow up the LAN with billions of evil
> frames". Still, pktgen is there and might be used by a fool.
Out of curiosity, couldn't root just use gdb, strace or similar means to
get access to user's programs? Or add a simple module to the kernel to
dump memory pages for that matter?
It would seem to me that this UNSAFE flag is only to protect root users from
accidentally sharing their own private memory accidentally.
> The "UNSAFE" label should be more than enough to warn the fool admin ;)
>
> Note this "UNSAFE" thing is really bad. Nowhere in the kernel we are
> allowed to make this sort of thing : No special mmap() flag asking
> kernel to give non cleared memory pages, even to root user.
Ok, I don't mind either way. I have a bunch of hacks to pktgen in
my tree already, so one more isn't a big deal.
> Anyway, as I said, if you want to saturate a 10Gb+ network with pktgen,
> you probably need clone_skb ?
I can get bi-directional 9.6Gbps or so using 1514 byte pkts and clone-skb == 0
on two ports using Intel 82599 10G NIC on core-i7 3.33Ghz (6GT/s pci-e bus).
(with memsets commented out). This is around 40Gbps total data across the network
interfaces.
Some day I'll get a quad or 6-port 10G and see what it can do :)
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH net-next-2.6] pktgen: Optionally leak kernel memory
From: Eric Dumazet @ 2010-07-24 14:13 UTC (permalink / raw)
To: Ben Greear; +Cc: David Miller, NetDev
In-Reply-To: <4C4AE80F.1040406@candelatech.com>
Le samedi 24 juillet 2010 à 06:18 -0700, Ben Greear a écrit :
> I think most users of pktgen wouldn't be too concerned about leaking
> memory content to the network. It's a root-only test tool that can easily
> saturate most networks and do horrible things like overflow switch CAM tables
> by randomizing source/dest macs etc. So, this warning might could be a bit
> more descriptive of how it is a security problem "arbitrary contents of memory can be
> sent across the network and may be sniffed by devices on the network, potentially
> revealing private information such as passwords and application data for applications
> running on the machine running pktgen" instead of telling folks not to use it unless it's
> really needed.
Most of the horrible things you mention are not related to the memset()
thing, arent they ?
Being root means : "I am a trusted user on this machine, and as such,
must know a bit what security means".
It doesnt mean : "I am allowed to steal passwords, credit card numbers,
from gentle users. I am allowed to blow up the LAN with billions of evil
frames". Still, pktgen is there and might be used by a fool.
The "UNSAFE" label should be more than enough to warn the fool admin ;)
Note this "UNSAFE" thing is really bad. Nowhere in the kernel we are
allowed to make this sort of thing : No special mmap() flag asking
kernel to give non cleared memory pages, even to root user.
I am not sure David will accept the patch !
Anyway, as I said, if you want to saturate a 10Gb+ network with pktgen,
you probably need clone_skb ?
^ permalink raw reply
* Re: [PATCH net-next-2.6] pktgen: Optionally leak kernel memory
From: Ben Greear @ 2010-07-24 13:18 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, NetDev
In-Reply-To: <1279949024.2451.43.camel@edumazet-laptop>
On 07/23/2010 10:23 PM, Eric Dumazet wrote:
> Le vendredi 23 juillet 2010 à 16:14 -0700, Ben Greear a écrit :
>> Some time back, someone added some memset() calls to pktgen to
>> keep from leaking memory contents to the network.
>>
>
> Well, someone might be me ;)
>
>> At least in our modified version of pktgen, this caused about 25%
>> performance degradation when sending 1514 byte pkts (multi-pkt == 0)
>> on a pair of 10G ports. It was easy enough to comment these memset
>> calls out of course.
>>
>> I don't mind if this patch stays in,
>> but thought I'd post my findings in case anyone else wonders why
>> their pktgen slowed down...
>>
>
> Thanks Ben
>
> Here is a patch adding a new pktgen flag, so that admins can choose
> speed if they want to, if they dont use clone_skb to reduce skb setup
> costs.
It looks fine to me, though I have not actually tested it.
> +Very fast mode
> +==============
> +One knob to get very fast pktgen is the UNSAFE flag :
> +
> +flag UNSAFE
> +
> +This ask to pktgen to not clear content of packets before sending them.
> +Note this is a security problem, and should be used only if really needed.
> +If packets are cloned (clone_skb 1000), clearing data cost is amortized so
> +this UNSAFE mode is less interesting.
I think most users of pktgen wouldn't be too concerned about leaking
memory content to the network. It's a root-only test tool that can easily
saturate most networks and do horrible things like overflow switch CAM tables
by randomizing source/dest macs etc. So, this warning might could be a bit
more descriptive of how it is a security problem "arbitrary contents of memory can be
sent across the network and may be sniffed by devices on the network, potentially
revealing private information such as passwords and application data for applications
running on the machine running pktgen" instead of telling folks not to use it unless it's
really needed.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Winning Notification!!!
From: A .Baloteli @ 2010-07-24 10:26 UTC (permalink / raw)
To: tel.inters.p.a
Dear Client
You have been sent a payment order, here is your payment information:
PAYMENT N°: 965412070
PAYMENT APPROVAL DATE: 04/06/2010
PAYMENT REF: VD06/EUSA/2010
PAYMENT VALUE: EUR 225.500.00 (Euro)
In order to receive you payment please confirm you identification in our
verification office below:
Voda Telecom Inc.
Betolini 14 - Point 7002
Villa Ugo Ojetti 32, 00137
e-mail: voda.com2010@gmail.it
Payment Logistic Officer: Andrea M. Baloteli (Mr)
Copy the Payment Verification Information's above and submit to the above
office and officer. After we receive your email confirmation, your payment
would be processed we will send you the payment paying bank for cashing
your funds.
REASON OF PAYMENT: This e-mail draw is to promote the official
communication network for the 2010 World Cup and our network's
Anniversary.
On behalf of the Board kindly, accept our warmest congratulations.
Regards.
MANAGEMENT.
All information is strictly confidential and will only be used for the
purpose to which it is been requested.. Finally, all funds should be
claimed by their respective beneficiaries, not later than 12 days after
notification. Failure to do so will result to outright cancellation.
Copyright © 2008 telecom.it;Privacy & P.IVA...
^ permalink raw reply
* e1000e crashes with 2.6.34.x and ThinkPad T60
From: Marc Haber @ 2010-07-24 9:26 UTC (permalink / raw)
To: Linux Kernel Developers, Linux Kernel Network Developers
Hi,
I have a new notebook, a Thinkpad T60, which is freezing in random
intervals (like 30 minutes to two days) as long as I am using the
on-board wired ethernet interface, which is an e1000e, [8086:109a]. As
long as I keep using the WLAN, the system runs for weeks despite
frequent suspend/resume cycles etc. The crashes seem really to be tied
to using the wired ethernet. This is a hard freeze, with nothing
happening on the system, only a long push on the power button helps.
Additionally, sometimes, probably after suspend/resume, the wired
ethernet does not come up properly again, ip addr claims "NO CARRIER"
even if the LEDs on the interface and on the switch claim that there
was a link. No packets are received by the interface when it's at this
stage.
Both issues appear with 2.6.34 and 2.6.34.1. I didn't try any of these
issues with an older kernel, 2.6.34 was already out when I started
using the T60.
To rule out defective hardware, I have tried with a second T60, with
the same results.
Full dmesg and lspci-nn attached, please say if you need more.
Greetings
Marc
P.S.: Please Cc: me on replies, both linux-kernel and netdev are too
big for me to timely follow. I am subscribed to both lists, but a Cc
helps in getting a faster reply.
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190
^ permalink raw reply
* Re: [patch -next v2] mv643xx_eth: potential null dereference
From: walter harms @ 2010-07-24 8:59 UTC (permalink / raw)
To: Dan Carpenter
Cc: Joe Perches, Lennert Buytenhek, David S. Miller, Jiri Pirko,
Denis Kirjanov, Saeed Bishara, netdev, kernel-janitors
In-Reply-To: <20100723221514.GJ26313@bicker>
Dan Carpenter schrieb:
> On Fri, Jul 23, 2010 at 06:30:22PM +0200, walter harms wrote:
>> this is a bit complicated, IMHO ppl have a bigger chance to discover what is going on
>> with this version:
>>
>> if (!pd ) {
>> msp->t_clk = 133000000;
>> msp->tx_csum_limit = 9 * 1024;
>> }
>> else
>> {
>> msp->t_clk = pd->t_clk ? pd->t_clk : 133000000 ;
>> msp->tx_csum_limit = pd->tx_csum_limit ? pd->tx_csum_limit : 9 * 1024;
>> }
>>
>
> But then instead of 2 magic numbers we would have 4. :/
>
Yes it can be shorten,
msp->t_clk = 133000000;
msp->tx_csum_limit = 9 * 1024;
if (pd) {
if (pd->t_clk) msp->t_clk = pd->t_clk ;
if (pd->tx_csum_limit) sp->tx_csum_limit = pd->tx_csum_limit;
}
pd->t_clk
i was thinking about that in my first posting but i have the feeling that ppl
tend to overlook the "if (pd)" but in this case it is important since the
behavier is different.
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.
re,
wh
^ permalink raw reply
* Re: Linux 2.6.35-rc6
From: Jiri Slaby @ 2010-07-24 8:06 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Linus Torvalds, Linux Kernel Mailing List, Russell King,
James Bottomley, David Miller, netdev, John W. Linville,
Michal Marek, Greg KH
In-Reply-To: <20100723112142.f698394e.sfr@canb.auug.org.au>
On 07/23/2010 03:21 AM, Stephen Rothwell wrote:
> On Thu, 22 Jul 2010 12:26:13 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>>
> I actually hope/think that this is going to be the last -rc. Things
>> have been pretty quiet, and while this -rc has more commits than -rc5
>> had, it's not by a large amount, nor does it look scary to me. So
>> there doesn't seem to be any point in dragging out the release any
>> more, unless we find something new that calls for it.
>
> I have no idea how important this stuff is, but I still have the
> following in linux-next that are (in theory) destined for v2.6.35:
Hi, and probably this one as well (introduced in rc1):
http://lkml.org/lkml/2010/7/9/287
Tim Gardner
i915: Use the correct mask to detect i830 aperture size.
--
js
^ permalink raw reply
* [PATCH NEXT 2/2] qlcnic: diag fixes
From: amit.salecha @ 2010-07-24 7:24 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, Amit Kumar Salecha
In-Reply-To: <1279956266-23445-1-git-send-email-amit.salecha@qlogic.com>
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
Acked-by: Sony Chacko <sony.chacko@qlogic.com>
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 | 19 +------------------
3 files changed, 9 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..ecce364 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 is 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..3002a7f 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
};
@@ -1181,6 +1175,7 @@ int qlcnic_diag_alloc_res(struct net_device *netdev, int test)
ret = qlcnic_fw_create_ctx(adapter);
if (ret) {
+ netif_device_attach(netdev);
qlcnic_detach(adapter);
return ret;
}
@@ -2841,18 +2836,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
* [PATCH NEXT 1/2] qlcnic: fix bandwidth check
From: amit.salecha @ 2010-07-24 7:24 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, Rajesh Borundia, Amit Kumar Salecha
In-Reply-To: <1279956266-23445-1-git-send-email-amit.salecha@qlogic.com>
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>
---
drivers/net/qlcnic/qlcnic.h | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/qlcnic/qlcnic.h b/drivers/net/qlcnic/qlcnic.h
index e189477..fad8e9a 100644
--- a/drivers/net/qlcnic/qlcnic.h
+++ b/drivers/net/qlcnic/qlcnic.h
@@ -1074,8 +1074,8 @@ struct qlcnic_eswitch {
/* Return codes for Error handling */
#define QL_STATUS_INVALID_PARAM -1
-#define MAX_BW 10000
-#define MIN_BW 100
+#define MAX_BW 100
+#define MIN_BW 1
#define MAX_VLAN_ID 4095
#define MIN_VLAN_ID 2
#define MAX_TX_QUEUES 1
@@ -1083,8 +1083,7 @@ struct qlcnic_eswitch {
#define DEFAULT_MAC_LEARN 1
#define IS_VALID_VLAN(vlan) (vlan >= MIN_VLAN_ID && vlan <= MAX_VLAN_ID)
-#define IS_VALID_BW(bw) (bw >= MIN_BW && bw <= MAX_BW \
- && (bw % 100) == 0)
+#define IS_VALID_BW(bw) (bw >= MIN_BW && bw <= MAX_BW)
#define IS_VALID_TX_QUEUES(que) (que > 0 && que <= MAX_TX_QUEUES)
#define IS_VALID_RX_QUEUES(que) (que > 0 && que <= MAX_RX_QUEUES)
#define IS_VALID_MODE(mode) (mode == 0 || mode == 1)
--
1.6.0.2
^ permalink raw reply related
* [PATCH NEXT 0/2]qlcnic: bug fixes
From: amit.salecha @ 2010-07-24 7:24 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman
Hi
Sending series of 2 minor fixes.
Apply them on net-next.
-Amit
^ permalink raw reply
* [PATCH net-next-2.6] pktgen: Optionally leak kernel memory
From: Eric Dumazet @ 2010-07-24 5:23 UTC (permalink / raw)
To: Ben Greear, David Miller; +Cc: NetDev
In-Reply-To: <4C4A224B.8080806@candelatech.com>
Le vendredi 23 juillet 2010 à 16:14 -0700, Ben Greear a écrit :
> Some time back, someone added some memset() calls to pktgen to
> keep from leaking memory contents to the network.
>
Well, someone might be me ;)
> At least in our modified version of pktgen, this caused about 25%
> performance degradation when sending 1514 byte pkts (multi-pkt == 0)
> on a pair of 10G ports. It was easy enough to comment these memset
> calls out of course.
>
> I don't mind if this patch stays in,
> but thought I'd post my findings in case anyone else wonders why
> their pktgen slowed down...
>
Thanks Ben
Here is a patch adding a new pktgen flag, so that admins can choose
speed if they want to, if they dont use clone_skb to reduce skb setup
costs.
Oc course, admins could change pktgen code themselves, but as you said,
better document it so that admins are aware of this possible speed
increase.
[PATCH net-next-2.6] pktgen: Optionally leak kernel memory
Commit 66ed1e5ec1d979 (pktgen: Dont leak kernel memory)
closed a security hole, by making sure data sent to network was cleared,
instead of using previous content of pages.
As Ben Greear noticed, this can slow down pktgen as much as 25%.
Add a new pktgen flag, UNSAFE, to ask pktgen to not clear data and use
previous content of memory.
Also add documentation for UNSAFE and NODE_ALLOC flags
Reported-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
Documentation/networking/pktgen.txt | 24 ++++++++++++++++++++++-
net/core/pktgen.c | 27 +++++++++++++++++++++-----
2 files changed, 45 insertions(+), 6 deletions(-)
diff --git a/Documentation/networking/pktgen.txt b/Documentation/networking/pktgen.txt
index 75e4fd7..88e2e6f 100644
--- a/Documentation/networking/pktgen.txt
+++ b/Documentation/networking/pktgen.txt
@@ -108,7 +108,10 @@ Examples:
MPLS_RND, VID_RND, SVID_RND
QUEUE_MAP_RND # queue map random
QUEUE_MAP_CPU # queue map mirrors smp_processor_id()
-
+ NODE_ALLOC # NUMA aware skb allocations
+ UNSAFE # Dont clear packets payload
+ (Might be 25% faster, but can leak sensitive
+ data to network. Use at your own risk !)
pgset "udp_src_min 9" set UDP source port min, If < udp_src_max, then
cycle through the port range.
@@ -178,6 +181,18 @@ Note when adding devices to a specific CPU there good idea to also assign
as this reduces cache bouncing when freeing skb's.
+Very fast mode
+==============
+One knob to get very fast pktgen is the UNSAFE flag :
+
+flag UNSAFE
+
+This ask to pktgen to not clear content of packets before sending them.
+Note this is a security problem, and should be used only if really needed.
+If packets are cloned (clone_skb 1000), clearing data cost is amortized so
+this UNSAFE mode is less interesting.
+
+
Current commands and configuration options
==========================================
@@ -225,6 +240,13 @@ flag
UDPDST_RND
MACSRC_RND
MACDST_RND
+ MPLS_RND
+ VID_RND
+ SVID_RND
+ FLOW_SEQ
+ IPSEC
+ NODE_ALLOC
+ UNSAFE
dst_min
dst_max
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 24a19de..01990cb 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -172,7 +172,7 @@
#include <asm/dma.h>
#include <asm/div64.h> /* do_div */
-#define VERSION "2.74"
+#define VERSION "2.75"
#define IP_NAME_SZ 32
#define MAX_MPLS_LABELS 16 /* This is the max label stack depth */
#define MPLS_STACK_BOTTOM htonl(0x00000100)
@@ -196,6 +196,7 @@
#define F_QUEUE_MAP_RND (1<<13) /* queue map Random */
#define F_QUEUE_MAP_CPU (1<<14) /* queue map mirrors smp_processor_id() */
#define F_NODE (1<<15) /* Node memory alloc*/
+#define F_UNSAFE (1<<16) /* Payload of packets is left uninitialized */
/* Thread control flag bits */
#define T_STOP (1<<0) /* Stop run */
@@ -674,6 +675,9 @@ static int pktgen_if_show(struct seq_file *seq, void *v)
if (pkt_dev->flags & F_NODE)
seq_printf(seq, "NODE_ALLOC ");
+ if (pkt_dev->flags & F_UNSAFE)
+ seq_printf(seq, "UNSAFE ");
+
seq_puts(seq, "\n");
/* not really stopped, more like last-running-at */
@@ -1231,12 +1235,20 @@ static ssize_t pktgen_if_write(struct file *file,
else if (strcmp(f, "!NODE_ALLOC") == 0)
pkt_dev->flags &= ~F_NODE;
+ else if (strcmp(f, "UNSAFE") == 0)
+ pkt_dev->flags |= F_UNSAFE;
+
+ else if (strcmp(f, "!UNSAFE") == 0)
+ pkt_dev->flags &= ~F_UNSAFE;
+
else {
sprintf(pg_result,
"Flag -:%s:- unknown\nAvailable flags, (prepend ! to un-set flag):\n%s",
f,
"IPSRC_RND, IPDST_RND, UDPSRC_RND, UDPDST_RND, "
- "MACSRC_RND, MACDST_RND, TXSIZE_RND, IPV6, MPLS_RND, VID_RND, SVID_RND, FLOW_SEQ, IPSEC, NODE_ALLOC\n");
+ "MACSRC_RND, MACDST_RND, TXSIZE_RND, IPV6, "
+ "MPLS_RND, VID_RND, SVID_RND, FLOW_SEQ, IPSEC, "
+ "NODE_ALLOC, UNSAFE\n");
return count;
}
sprintf(pg_result, "OK: flags=0x%x", pkt_dev->flags);
@@ -2723,7 +2735,8 @@ static struct sk_buff *fill_packet_ipv4(struct net_device *odev,
if (pkt_dev->nfrags <= 0) {
pgh = (struct pktgen_hdr *)skb_put(skb, datalen);
- memset(pgh + 1, 0, datalen - sizeof(struct pktgen_hdr));
+ if (!(pkt_dev->flags & F_UNSAFE))
+ memset(pgh + 1, 0, datalen - sizeof(struct pktgen_hdr));
} else {
int frags = pkt_dev->nfrags;
int i, len;
@@ -2734,13 +2747,17 @@ static struct sk_buff *fill_packet_ipv4(struct net_device *odev,
frags = MAX_SKB_FRAGS;
if (datalen > frags * PAGE_SIZE) {
len = datalen - frags * PAGE_SIZE;
- memset(skb_put(skb, len), 0, len);
+ if (!(pkt_dev->flags & F_UNSAFE))
+ memset(skb_put(skb, len), 0, len);
datalen = frags * PAGE_SIZE;
}
i = 0;
while (datalen > 0) {
- struct page *page = alloc_pages(GFP_KERNEL | __GFP_ZERO, 0);
+ struct page *page = alloc_pages((pkt_dev->flags & F_UNSAFE) ?
+ GFP_KERNEL :
+ GFP_KERNEL | __GFP_ZERO,
+ 0);
skb_shinfo(skb)->frags[i].page = page;
skb_shinfo(skb)->frags[i].page_offset = 0;
skb_shinfo(skb)->frags[i].size =
^ permalink raw reply related
* [PATCH] xt_length: support ipv6 jumbo frames
From: Changli Gao @ 2010-07-24 3:32 UTC (permalink / raw)
To: Patrick McHardy; +Cc: David S. Miller, netfilter-devel, netdev, Changli Gao
In order to support ipv6 jumbo frames, the type of min and max in xt_length_info
is changed to __u32. Since the structure xt_length_info is updated, the revision
is updated to 1 from 0, and the old revision is still reserved to keep binary
compatible with the older version of iptables.
skb->len is used to keep consistency.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
----
include/linux/netfilter/xt_length.h | 2 +-
net/netfilter/xt_length.c | 36 +++++++++++++++++++++++++++---------
2 files changed, 28 insertions(+), 10 deletions(-)
diff --git a/include/linux/netfilter/xt_length.h b/include/linux/netfilter/xt_length.h
index b82ed7c..a12785c 100644
--- a/include/linux/netfilter/xt_length.h
+++ b/include/linux/netfilter/xt_length.h
@@ -4,7 +4,7 @@
#include <linux/types.h>
struct xt_length_info {
- __u16 min, max;
+ __u32 min, max;
__u8 invert;
};
diff --git a/net/netfilter/xt_length.c b/net/netfilter/xt_length.c
index 176e557..579f340 100644
--- a/net/netfilter/xt_length.c
+++ b/net/netfilter/xt_length.c
@@ -20,21 +20,23 @@ MODULE_LICENSE("GPL");
MODULE_ALIAS("ipt_length");
MODULE_ALIAS("ip6t_length");
-static bool
-length_mt(const struct sk_buff *skb, struct xt_action_param *par)
+struct xt_length_info_v0 {
+ __u16 min, max;
+ __u8 invert;
+};
+
+static bool length_mt_v0(const struct sk_buff *skb, struct xt_action_param *par)
{
- const struct xt_length_info *info = par->matchinfo;
- u_int16_t pktlen = ntohs(ip_hdr(skb)->tot_len);
+ const struct xt_length_info_v0 *info = par->matchinfo;
+ u_int16_t pktlen = skb->len;
return (pktlen >= info->min && pktlen <= info->max) ^ info->invert;
}
-static bool
-length_mt6(const struct sk_buff *skb, struct xt_action_param *par)
+static bool length_mt(const struct sk_buff *skb, struct xt_action_param *par)
{
const struct xt_length_info *info = par->matchinfo;
- const u_int16_t pktlen = ntohs(ipv6_hdr(skb)->payload_len) +
- sizeof(struct ipv6hdr);
+ u_int32_t pktlen = skb->len;
return (pktlen >= info->min && pktlen <= info->max) ^ info->invert;
}
@@ -43,16 +45,32 @@ static struct xt_match length_mt_reg[] __read_mostly = {
{
.name = "length",
.family = NFPROTO_IPV4,
+ .match = length_mt_v0,
+ .matchsize = sizeof(struct xt_length_info_v0),
+ .me = THIS_MODULE,
+ },
+ {
+ .name = "length",
+ .family = NFPROTO_IPV6,
+ .match = length_mt_v0,
+ .matchsize = sizeof(struct xt_length_info_v0),
+ .me = THIS_MODULE,
+ },
+ {
+ .name = "length",
+ .family = NFPROTO_IPV4,
.match = length_mt,
.matchsize = sizeof(struct xt_length_info),
.me = THIS_MODULE,
+ .revision = 1,
},
{
.name = "length",
.family = NFPROTO_IPV6,
- .match = length_mt6,
+ .match = length_mt,
.matchsize = sizeof(struct xt_length_info),
.me = THIS_MODULE,
+ .revision = 1,
},
};
^ permalink raw reply related
* Re: pktgen performance hit due to memset.
From: David Miller @ 2010-07-24 1:51 UTC (permalink / raw)
To: greearb; +Cc: netdev
In-Reply-To: <4C4A224B.8080806@candelatech.com>
From: Ben Greear <greearb@candelatech.com>
Date: Fri, 23 Jul 2010 16:14:19 -0700
> Some time back, someone added some memset() calls to pktgen to
> keep from leaking memory contents to the network.
>
> At least in our modified version of pktgen, this caused about 25%
> performance degradation when sending 1514 byte pkts (multi-pkt == 0)
> on a pair of 10G ports. It was easy enough to comment these memset
> calls out of course.
>
> I don't mind if this patch stays in,
> but thought I'd post my findings in case anyone else wonders why
> their pktgen slowed down...
Thanks for the data point Ben.
^ permalink raw reply
* [net-next-2.6 PATCH] ixgbe: fix ethtool stats
From: Jeff Kirsher @ 2010-07-23 23:44 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, bphilips, Eric Dumazet, Jeff Kirsher
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>
---
drivers/net/ixgbe/ixgbe_ethtool.c | 42 +++++++++++++++++++------------------
1 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethtool.c b/drivers/net/ixgbe/ixgbe_ethtool.c
index da54b38..dcebc82 100644
--- a/drivers/net/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ixgbe/ixgbe_ethtool.c
@@ -54,14 +54,14 @@ struct ixgbe_stats {
sizeof(((struct ixgbe_adapter *)0)->m), \
offsetof(struct ixgbe_adapter, m)
#define IXGBE_NETDEV_STAT(m) NETDEV_STATS, \
- sizeof(((struct net_device *)0)->m), \
- offsetof(struct net_device, m) - offsetof(struct net_device, stats)
+ sizeof(((struct rtnl_link_stats64 *)0)->m), \
+ offsetof(struct rtnl_link_stats64, m)
static struct ixgbe_stats ixgbe_gstrings_stats[] = {
- {"rx_packets", IXGBE_NETDEV_STAT(stats.rx_packets)},
- {"tx_packets", IXGBE_NETDEV_STAT(stats.tx_packets)},
- {"rx_bytes", IXGBE_NETDEV_STAT(stats.rx_bytes)},
- {"tx_bytes", IXGBE_NETDEV_STAT(stats.tx_bytes)},
+ {"rx_packets", IXGBE_NETDEV_STAT(rx_packets)},
+ {"tx_packets", IXGBE_NETDEV_STAT(tx_packets)},
+ {"rx_bytes", IXGBE_NETDEV_STAT(rx_bytes)},
+ {"tx_bytes", IXGBE_NETDEV_STAT(tx_bytes)},
{"rx_pkts_nic", IXGBE_STAT(stats.gprc)},
{"tx_pkts_nic", IXGBE_STAT(stats.gptc)},
{"rx_bytes_nic", IXGBE_STAT(stats.gorc)},
@@ -69,27 +69,27 @@ static struct ixgbe_stats ixgbe_gstrings_stats[] = {
{"lsc_int", IXGBE_STAT(lsc_int)},
{"tx_busy", IXGBE_STAT(tx_busy)},
{"non_eop_descs", IXGBE_STAT(non_eop_descs)},
- {"rx_errors", IXGBE_NETDEV_STAT(stats.rx_errors)},
- {"tx_errors", IXGBE_NETDEV_STAT(stats.tx_errors)},
- {"rx_dropped", IXGBE_NETDEV_STAT(stats.rx_dropped)},
- {"tx_dropped", IXGBE_NETDEV_STAT(stats.tx_dropped)},
- {"multicast", IXGBE_NETDEV_STAT(stats.multicast)},
+ {"rx_errors", IXGBE_NETDEV_STAT(rx_errors)},
+ {"tx_errors", IXGBE_NETDEV_STAT(tx_errors)},
+ {"rx_dropped", IXGBE_NETDEV_STAT(rx_dropped)},
+ {"tx_dropped", IXGBE_NETDEV_STAT(tx_dropped)},
+ {"multicast", IXGBE_NETDEV_STAT(multicast)},
{"broadcast", IXGBE_STAT(stats.bprc)},
{"rx_no_buffer_count", IXGBE_STAT(stats.rnbc[0]) },
- {"collisions", IXGBE_NETDEV_STAT(stats.collisions)},
- {"rx_over_errors", IXGBE_NETDEV_STAT(stats.rx_over_errors)},
- {"rx_crc_errors", IXGBE_NETDEV_STAT(stats.rx_crc_errors)},
- {"rx_frame_errors", IXGBE_NETDEV_STAT(stats.rx_frame_errors)},
+ {"collisions", IXGBE_NETDEV_STAT(collisions)},
+ {"rx_over_errors", IXGBE_NETDEV_STAT(rx_over_errors)},
+ {"rx_crc_errors", IXGBE_NETDEV_STAT(rx_crc_errors)},
+ {"rx_frame_errors", IXGBE_NETDEV_STAT(rx_frame_errors)},
{"hw_rsc_aggregated", IXGBE_STAT(rsc_total_count)},
{"hw_rsc_flushed", IXGBE_STAT(rsc_total_flush)},
{"fdir_match", IXGBE_STAT(stats.fdirmatch)},
{"fdir_miss", IXGBE_STAT(stats.fdirmiss)},
- {"rx_fifo_errors", IXGBE_NETDEV_STAT(stats.rx_fifo_errors)},
- {"rx_missed_errors", IXGBE_NETDEV_STAT(stats.rx_missed_errors)},
- {"tx_aborted_errors", IXGBE_NETDEV_STAT(stats.tx_aborted_errors)},
- {"tx_carrier_errors", IXGBE_NETDEV_STAT(stats.tx_carrier_errors)},
- {"tx_fifo_errors", IXGBE_NETDEV_STAT(stats.tx_fifo_errors)},
- {"tx_heartbeat_errors", IXGBE_NETDEV_STAT(stats.tx_heartbeat_errors)},
+ {"rx_fifo_errors", IXGBE_NETDEV_STAT(rx_fifo_errors)},
+ {"rx_missed_errors", IXGBE_NETDEV_STAT(rx_missed_errors)},
+ {"tx_aborted_errors", IXGBE_NETDEV_STAT(tx_aborted_errors)},
+ {"tx_carrier_errors", IXGBE_NETDEV_STAT(tx_carrier_errors)},
+ {"tx_fifo_errors", IXGBE_NETDEV_STAT(tx_fifo_errors)},
+ {"tx_heartbeat_errors", IXGBE_NETDEV_STAT(tx_heartbeat_errors)},
{"tx_timeout_count", IXGBE_STAT(tx_timeout_count)},
{"tx_restart_queue", IXGBE_STAT(restart_queue)},
{"rx_long_length_errors", IXGBE_STAT(stats.roc)},
^ permalink raw reply related
* pktgen performance hit due to memset.
From: Ben Greear @ 2010-07-23 23:14 UTC (permalink / raw)
To: NetDev
Some time back, someone added some memset() calls to pktgen to
keep from leaking memory contents to the network.
At least in our modified version of pktgen, this caused about 25%
performance degradation when sending 1514 byte pkts (multi-pkt == 0)
on a pair of 10G ports. It was easy enough to comment these memset
calls out of course.
I don't mind if this patch stays in,
but thought I'd post my findings in case anyone else wonders why
their pktgen slowed down...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [patch -next v2] mv643xx_eth: potential null dereference
From: Dan Carpenter @ 2010-07-23 22:15 UTC (permalink / raw)
To: walter harms
Cc: Joe Perches, Lennert Buytenhek, David S. Miller, Jiri Pirko,
Denis Kirjanov, Saeed Bishara, netdev, kernel-janitors
In-Reply-To: <4C49C39E.8020502@bfs.de>
On Fri, Jul 23, 2010 at 06:30:22PM +0200, walter harms wrote:
> this is a bit complicated, IMHO ppl have a bigger chance to discover what is going on
> with this version:
>
> if (!pd ) {
> msp->t_clk = 133000000;
> msp->tx_csum_limit = 9 * 1024;
> }
> else
> {
> msp->t_clk = pd->t_clk ? pd->t_clk : 133000000 ;
> msp->tx_csum_limit = pd->tx_csum_limit ? pd->tx_csum_limit : 9 * 1024;
> }
>
But then instead of 2 magic numbers we would have 4. :/
regards,
dan carpenter
^ permalink raw reply
* RE: 2.6.34.1: kernel warning at igb_main.c:2080
From: Wyborny, Carolyn @ 2010-07-23 21:59 UTC (permalink / raw)
To: Ben Greear; +Cc: NetDev
In-Reply-To: <4C4A1038.5020707@candelatech.com>
>-----Original Message-----
>From: Ben Greear [mailto:greearb@candelatech.com]
>Sent: Friday, July 23, 2010 2:57 PM
>To: Wyborny, Carolyn
>Cc: NetDev
>Subject: Re: 2.6.34.1: kernel warning at igb_main.c:2080
>
>On 07/23/2010 02:48 PM, Wyborny, Carolyn wrote:
>> Hello Ben,
>>
>> I'm not exactly sure why this happened and there's not a lot
>of info from the kernel, unfortunately. I've looked at the
>location in the code and it doesn't give me much more. Let me
>know if it is happening regularly and if you have steps to
>reliably reproduce it and we can look at it further.
>>
>> We do appreciate the report.
>
>Thanks for looking. We haven't noticed this again.
>
>If we figure out how to reproduce it reliably, I'll
>let you know.
>
>Thanks,
>Ben
>
>--
>Ben Greear <greearb@candelatech.com>
>Candela Technologies Inc http://www.candelatech.com
>
>
Thanks Ben,
Sounds good.
Carolyn
^ permalink raw reply
* Re: 2.6.34.1: kernel warning at igb_main.c:2080
From: Ben Greear @ 2010-07-23 21:57 UTC (permalink / raw)
To: Wyborny, Carolyn; +Cc: NetDev
In-Reply-To: <EDC0E76513226749BFBC9C3FB031318FE1DF9DC1@orsmsx508.amr.corp.intel.com>
On 07/23/2010 02:48 PM, Wyborny, Carolyn wrote:
> Hello Ben,
>
> I'm not exactly sure why this happened and there's not a lot of info from the kernel, unfortunately. I've looked at the location in the code and it doesn't give me much more. Let me know if it is happening regularly and if you have steps to reliably reproduce it and we can look at it further.
>
> We do appreciate the report.
Thanks for looking. We haven't noticed this again.
If we figure out how to reproduce it reliably, I'll
let you know.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* RE: 2.6.34.1: kernel warning at igb_main.c:2080
From: Wyborny, Carolyn @ 2010-07-23 21:48 UTC (permalink / raw)
To: Ben Greear, NetDev
In-Reply-To: <4C3FA03E.9090802@candelatech.com>
Hello Ben,
I'm not exactly sure why this happened and there's not a lot of info from the kernel, unfortunately. I've looked at the location in the code and it doesn't give me much more. Let me know if it is happening regularly and if you have steps to reliably reproduce it and we can look at it further.
We do appreciate the report.
Thanks,
Carolyn
>-----Original Message-----
>From: netdev-owner@vger.kernel.org
>[mailto:netdev-owner@vger.kernel.org] On Behalf Of Ben Greear
>Sent: Thursday, July 15, 2010 4:57 PM
>To: NetDev
>Subject: igb: 2.6.34.1: kernel warning at igb_main.c:2080
>
>We just saw this kernel warning on 2.6.34.1 + a few patches
>from the pending stable queue,
>plus our own hacks (though none to igb).
>
>We were running a modified version of pktgen traffic and at
>the same time
>bounced the port.
>
>This warning didn't seem to cause any real problems.
>
>Please let us know if you would like any additional information.
>
>]# lspci|grep Ethern
>01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit
>Network Connection
>02:00.0 Ethernet controller: Intel Corporation 82574L Gigabit
>Network Connection
>05:00.0 Ethernet controller: Intel Corporation 82575EB Gigabit
>Network Connection (rev 02)
>05:00.1 Ethernet controller: Intel Corporation 82575EB Gigabit
>Network Connection (rev 02)
>06:00.0 Ethernet controller: Intel Corporation 82575EB Gigabit
>Network Connection (rev 02)
>06:00.1 Ethernet controller: Intel Corporation 82575EB Gigabit
>Network Connection (rev 02)
>
>
>Jul 15 16:36:01 localhost kernel: ------------[ cut here ]------------
>Jul 15 16:36:01 localhost kernel: WARNING: at
>/home/greearb/git/linux-2.6.dev.34.y/drivers/net/igb/igb_main.c
>:2080 igb_close+0x28/0x9f [igb]()
>Jul 15 16:36:01 localhost kernel: Hardware name: X8STi
>Jul 15 16:36:01 localhost kernel: Modules linked in: bridge
>arc4 michael_mic wanlink(P) 8021q garp xt_CT iptable_raw
>ipt_addrtype xt_DSCP xt_dscp xt_string
>xt_owner xt_NFQUEUE xt_multiport xt_mark xt_iprange
>xt_hashlimit xt_CONNMARK xt_connmark stp llc veth fuse macvlan
>bpctl_mod pktgen iscsi_tcp libiscsi_tcp
>libiscsi scsi_transport_iscsi nfs lockd fscache nfs_acl
>auth_rpcgss sunrpc ipv6 dm_multipath uinput i2c_i801 iTCO_wdt
>i2c_core ioatdma e1000e igb pcspkr
>iTCO_vendor_support dca ata_generic pata_acpi [last unloaded: nf_nat]
>Jul 15 16:36:01 localhost kernel: Pid: 17516, comm: ip
>Tainted: P 2.6.34.1 #2
>Jul 15 16:36:01 localhost kernel: Call Trace:
>Jul 15 16:36:01 localhost kernel: [<ffffffffa002a37f>] ?
>igb_close+0x28/0x9f [igb]
>Jul 15 16:36:01 localhost kernel: [<ffffffff81041bb6>]
>warn_slowpath_common+0x77/0x8f
>Jul 15 16:36:01 localhost kernel: [<ffffffff81041bdd>]
>warn_slowpath_null+0xf/0x11
>Jul 15 16:36:01 localhost kernel: [<ffffffffa002a37f>]
>igb_close+0x28/0x9f [igb]
>Jul 15 16:36:01 localhost kernel: [<ffffffff8133c626>]
>__dev_close+0x73/0x86
>Jul 15 16:36:01 localhost kernel: [<ffffffff8133a719>]
>__dev_change_flags+0xa8/0x12b
>Jul 15 16:36:01 localhost kernel: [<ffffffff8133c2aa>]
>dev_change_flags+0x1c/0x51
>Jul 15 16:36:01 localhost kernel: [<ffffffff813466bc>]
>do_setlink+0x273/0x482
>Jul 15 16:36:01 localhost kernel: [<ffffffff810ab1bb>] ?
>zone_statistics+0x5e/0x63
>Jul 15 16:36:01 localhost kernel: [<ffffffff8134755e>]
>rtnl_newlink+0x26c/0x422
>Jul 15 16:36:01 localhost kernel: [<ffffffff81345a06>] ?
>nla_nest_start+0x1d/0x31
>Jul 15 16:36:01 localhost kernel: [<ffffffff810ca997>] ?
>virt_to_head_page+0x9/0x2a
>Jul 15 16:36:01 localhost kernel: [<ffffffff813dd1f5>] ?
>__mutex_lock_common+0x38e/0x3ac
>Jul 15 16:36:01 localhost kernel: [<ffffffff81346ffb>]
>rtnetlink_rcv_msg+0x1d9/0x1f7
>Jul 15 16:36:01 localhost kernel: [<ffffffff81346e22>] ?
>rtnetlink_rcv_msg+0x0/0x1f7
>Jul 15 16:36:01 localhost kernel: [<ffffffff81356939>]
>netlink_rcv_skb+0x3e/0x8e
>Jul 15 16:36:01 localhost kernel: [<ffffffff81346cc9>]
>rtnetlink_rcv+0x20/0x29
>Jul 15 16:36:01 localhost kernel: [<ffffffff813567b2>]
>netlink_unicast+0xea/0x151
>Jul 15 16:36:01 localhost kernel: [<ffffffff8133545c>] ?
>memcpy_fromiovec+0x42/0x73
>Jul 15 16:36:01 localhost kernel: [<ffffffff81357bc8>]
>netlink_sendmsg+0x242/0x255
>Jul 15 16:36:01 localhost kernel: [<ffffffff8132a771>] ?
>__sock_recvmsg_nosec+0x29/0x2b
>Jul 15 16:36:01 localhost kernel: [<ffffffff8132bd02>]
>__sock_sendmsg+0x56/0x5f
>Jul 15 16:36:01 localhost kernel: [<ffffffff8132c127>]
>sock_sendmsg+0xa3/0xbc
>Jul 15 16:36:01 localhost kernel: [<ffffffff813351e5>] ?
>copy_from_user+0x28/0x30
>Jul 15 16:36:01 localhost kernel: [<ffffffff8133555e>] ?
>verify_iovec+0x52/0x95
>Jul 15 16:36:01 localhost kernel: [<ffffffff8132c368>]
>sys_sendmsg+0x1c6/0x22a
>Jul 15 16:36:01 localhost kernel: [<ffffffff810a277f>] ?
>lru_cache_add_lru+0x38/0x3d
>Jul 15 16:36:01 localhost kernel: [<ffffffff813de23e>] ?
>_raw_spin_unlock+0x2d/0x38
>Jul 15 16:36:01 localhost kernel: [<ffffffff810ad802>] ?
>spin_unlock+0x9/0xb
>Jul 15 16:36:01 localhost kernel: [<ffffffff810b0138>] ?
>handle_mm_fault+0x6d3/0x6f3
>Jul 15 16:36:01 localhost kernel: [<ffffffff810b3a0a>] ?
>__vma_link_rb+0x2b/0x2d
>Jul 15 16:36:01 localhost kernel: [<ffffffff810b45f7>] ?
>vma_link+0xcd/0xcf
>Jul 15 16:36:01 localhost kernel: [<ffffffff810d9369>] ?
>fget_light+0x39/0x87
>Jul 15 16:36:01 localhost kernel: [<ffffffff81083b91>] ?
>audit_syscall_entry+0xfe/0x12a
>Jul 15 16:36:01 localhost kernel: [<ffffffff81009ac2>]
>system_call_fastpath+0x16/0x1b
>Jul 15 16:36:01 localhost kernel: ---[ end trace 75242fae6dbfdf6d ]---
>
>
>Thanks,
>Ben
>
>--
>Ben Greear <greearb@candelatech.com>
>Candela Technologies Inc http://www.candelatech.com
>
>--
>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: pull request: wireless-next-2.6 2010-07-23
From: John W. Linville @ 2010-07-23 21:39 UTC (permalink / raw)
To: David Miller
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100723.140320.116366019.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Fri, Jul 23, 2010 at 02:03:20PM -0700, David Miller wrote:
> From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
> Date: Fri, 23 Jul 2010 16:40:29 -0400
>
> > Yet another batch intended for 2.6.36... Mostly the usual random lot
> > of stuff, mostly driver updates. This batch also includes a flurry
> > of Sparse-inspired patches from me -- it is hard to resist once the
> > "bug" bites! As usual, all of these have been cooking in linux-next
> > for at least several days.
> >
> > Please let me know if there are problems!
>
> Auto-merging drivers/net/wireless/iwlwifi/iwl-commands.h
> CONFLICT (content): Merge conflict in drivers/net/wireless/iwlwifi/iwl-commands.h
>
> I don't even have to look at the file to know that it's
> another one of those __packed things.
>
> I'll fix it up again, but I know you can sense how tiring
> this has become for me.
I'm sorry, Dave! I should have done a for-davem branch. FWIW,
I intended to do a test merge but it must have slipped my fragile
mind. :-(
John
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
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