* Re: ixgbe: normalize frag_list usage
From: Alexander Duyck @ 2010-10-04 19:49 UTC (permalink / raw)
To: David Miller
Cc: Kirsher, Jeffrey T, Brandeburg, Jesse, Allan, Bruce W,
netdev@vger.kernel.org
In-Reply-To: <20101004.113258.212671454.davem@davemloft.net>
David Miller wrote:
> From: Alexander Duyck <alexander.h.duyck@intel.com>
> Date: Mon, 04 Oct 2010 11:04:18 -0700
>
>> This will not work for RSC due to the fact that it assumes only one
>> RSC context is active per ring and that is not the case. There can be
>> multiple RSC combined flows interlaced on the ring.
>
> Thanks for looking at this Alexander.
>
> I must have mis-understood what the current code is doing.
>
> It looked like RSC packets always show up in-order in the RX ring.
>
> And that they are scanned for by simply combining any sequence of
> non-EOP packets up to and including the final EOP one into a frag
> list.
>
> Are the RSC packets are identified via something else entirely?
They show up in order, but they are not necessarily linear. You can
have other packets show up in the middle of the flow and RSC just jumps
over them. The determination for the jump is handled via nextp in
ixgbe_clean_rx_irq.
I'll look into this and see if I can come up with a counter-proposal
patch based on the suggestions I was making. The key item though is
that the tail would need some means of referencing head which I think
can probably be accomplished via skb->next.
Thanks,
Alex
^ permalink raw reply
* Re: VLAN packets silently dropped in promiscuous mode
From: Jesse Gross @ 2010-10-04 20:21 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Roger Luethi, netdev, Patrick McHardy
In-Reply-To: <1285922469.2641.1.camel@edumazet-laptop>
On Fri, Oct 1, 2010 at 1:41 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le vendredi 01 octobre 2010 à 07:10 +0200, Eric Dumazet a écrit :
>> Le jeudi 30 septembre 2010 à 19:37 -0700, Jesse Gross a écrit :
>>
>> > That's true. Dropping here seems roughly equivalent to the effects of
>> > a hardware VLAN filter, which will also not be tracked by a counter,
>> > so that seems not too bad to me.
>> >
>> > The thing that concerns me though is why so many drivers seem to have
>> > this problem with completely dropping the VLAN header. I know that
>> > even several of the ones that work now were broken initially and had
>> > to be fixed. Seeing as the driver drops the VLAN information before
>> > it gets to the general networking code I don't see a generic fix to
>> > this as it is currently setup. However, perhaps we could make it so
>> > that it is harder to get wrong. Something like this:
>> >
>> > * Allow vlan_gro_receive() to take a NULL VLAN group and a tag of 0
>> > (and do the same thing for vlan_hwaccel_rx())
>> > * Now that the vlan functions can deal with non-VLAN packets, merge
>> > them into their non-VLAN counterparts.
>> > * We can now demultiplex between the VLAN/non-VLAN case in core
>> > networking. This is done anyways, it just prevents every driver from
>> > needing that code block I copied above and allows us to fix these
>> > types of problems centrally.
>> > * Dump the VLAN tag into the SKB and hand off the packet to the
>> > various consumers: VLAN devices, libpcap, bridge hook (not currently
>> > done but should be for trunking).
>> >
>> > I see a number of advantages of this:
>> > * Fixes all the problems with cards dropping VLAN headers at once.
>> > * Avoids having to disable VLAN acceleration when in promiscuous mode
>> > (good for bridging since it always puts devices in promiscuous mode).
>> > * Keeps VLAN tag separate until given to ultimate consumer, which
>> > avoids needing to do header reconstruction as in tg3 unless absolutely
>> > necessary.
>> > * Consolidates common driver code in core networking.
>>
>> This seems very reasonable ;)
>
> Jesse, do you plan to work on this stuff yourself in a near future ?
I'm a little bit busy at the moment but I'm hoping to have some time
to work on it towards the end of this week/beginning of next week.
Thanks for looking over the idea.
^ permalink raw reply
* [PATCH] bonding: fix WARN_ON when writing to bond_master sysfs file
From: Neil Horman @ 2010-10-04 20:21 UTC (permalink / raw)
To: netdev; +Cc: bonding-devel, fubar, davem, nhorman
Fix a WARN_ON failure in bond_masters sysfs file
Got a report of this warning recently
bonding: bond0 is being created...
------------[ cut here ]------------
WARNING: at fs/proc/generic.c:590 proc_register+0x14d/0x185()
Hardware name: ProLiant BL465c G1
proc_dir_entry 'bonding/bond0' already registered
Modules linked in: bonding ipv6 tg3 bnx2 shpchp amd64_edac_mod edac_core
ipmi_si
ipmi_msghandler serio_raw i2c_piix4 k8temp edac_mce_amd hpwdt microcode hpsa
cc
iss radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded:
scsi_wai
t_scan]
Pid: 935, comm: ifup-eth Not tainted 2.6.33.5-124.fc13.x86_64 #1
Call Trace:
[<ffffffff8104b54c>] warn_slowpath_common+0x77/0x8f
[<ffffffff8104b5b1>] warn_slowpath_fmt+0x3c/0x3e
[<ffffffff8114bf0b>] proc_register+0x14d/0x185
[<ffffffff8114c20c>] proc_create_data+0x87/0xa1
[<ffffffffa0211e9b>] bond_create_proc_entry+0x55/0x95 [bonding]
[<ffffffffa0215e5d>] bond_init+0x95/0xd0 [bonding]
[<ffffffff8138cd97>] register_netdevice+0xdd/0x29e
[<ffffffffa021240b>] bond_create+0x8e/0xb8 [bonding]
[<ffffffffa021c4be>] bonding_store_bonds+0xb3/0x1c1 [bonding]
[<ffffffff812aec85>] class_attr_store+0x27/0x29
[<ffffffff8115423d>] sysfs_write_file+0x10f/0x14b
[<ffffffff81101acf>] vfs_write+0xa9/0x106
[<ffffffff81101be2>] sys_write+0x45/0x69
[<ffffffff81009b02>] system_call_fastpath+0x16/0x1b
---[ end trace a677c3f7f8b16b1e ]---
bonding: Bond creation failed.
It happens because a user space writer to bond_master can try to register and
already existing bond interface name. Fix it by teaching bond_create to check
for the existance of devices with that name first in cases where a non-NULL name
parameter has been passed in
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
bond_main.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index fb70c3e..10e4ffe 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -5148,7 +5148,7 @@ static struct rtnl_link_ops bond_link_ops __read_mostly = {
*/
int bond_create(struct net *net, const char *name)
{
- struct net_device *bond_dev;
+ struct net_device *bond_dev, *check_dev;
int res;
rtnl_lock();
@@ -5168,6 +5168,20 @@ int bond_create(struct net *net, const char *name)
res = dev_alloc_name(bond_dev, "bond%d");
if (res < 0)
goto out;
+ } else {
+ /*
+ * If we're given a name to register
+ * we need to ensure that its not already
+ * registered
+ */
+ check_dev = dev_get_by_name(net, name);
+
+ res = (check_dev) ? 0 : -EEXIST;
+
+ dev_put(check_dev);
+
+ if (res)
+ goto out;
}
res = register_netdevice(bond_dev);
^ permalink raw reply related
* Re: [PATCH] netfilter: unregister nf hooks, matches and targets in the reverse order
From: Patrick McHardy @ 2010-10-04 20:26 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Changli Gao, David S. Miller, netfilter-devel, netdev
In-Reply-To: <alpine.LNX.2.01.1010020157010.26371@obet.zrqbmnf.qr>
Am 02.10.2010 01:57, schrieb Jan Engelhardt:
> On Sunday 2010-09-19 07:58, Changli Gao wrote:
>
>> On Thu, Sep 16, 2010 at 1:32 AM, Patrick McHardy <kaber@trash.net> wrote:
>>> Am 02.09.2010 16:15, schrieb Changli Gao:
>>>> Since we register nf hooks, matches and targets in order, we'd better
>>>> unregister them in the reverse order.
>>>
>>> Why? Is there a specific bug you've noticed?
>>>
>>
>> No, there isn't any bug. I just think unregistering them in the
>> reverse order is more resonable, like the rollback when failing. And
>> the code patched generates less object:
>
> I support this.
Yeah, it seems reasonable, although I don't like changing things
without a concrete reason. Anyways, applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH net-next] net: add a core netdev->rx_dropped counter
From: Jesse Gross @ 2010-10-04 20:27 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Roger Luethi, netdev, Patrick McHardy
In-Reply-To: <1285916815.2705.152.camel@edumazet-laptop>
On Fri, Oct 1, 2010 at 12:06 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le vendredi 01 octobre 2010 à 07:10 +0200, Eric Dumazet a écrit :
>
>> This seems very reasonable ;)
>>
>> I'll add a counter, a core generalization of
>> commit 8990f468a (net: rx_dropped accounting)
>>
>> Because we can drop packets _after_ netif_rx() if RPS is in action
>> anyway.
>>
>>
>
> In this patch I fold the additional dev->rx_dropped into get_stats()
> structure. We might chose to not fold it, and provides this counter in a
> new /proc/net/dev column, a new rtnetlink attribute (and appropriate
> iproute2 change)
>
> What do you think ?
This patch makes sense to me. I think combining the dropped stats
with those from the driver makes sense, at least at the moment, since
both the counters from both sources are from a combination of
different causes anyways.
^ permalink raw reply
* Re: [PATCHv4 net-next-2.6 1/5] XFRM,IPv6: Remove xfrm_spi_hash() dependency on destination address
From: Arnaud Ebalard @ 2010-10-04 20:51 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, Eric Dumazet, Hideaki YOSHIFUJI, netdev
In-Reply-To: <20101004083306.GA17939@gondor.apana.org.au>
Hi,
Herbert Xu <herbert@gondor.apana.org.au> writes:
> On Mon, Oct 04, 2010 at 08:25:07AM +0200, Arnaud Ebalard wrote:
>>
>> At the moment, Linux XFRM stack includes the address when computing
>> the hash to perform state lookup by SPI. This patch changes XFRM
>> state hash computation to prevent destination address to be
>> used. This will later allow finding states for packets w/ mangled
>> destination addresses.
>
> I'm fine with doing this for inbound SAs. However, I can't see
> how we can do this for outbound SAs where the SPI is chosen by
> the remote end.
The change *does not* make the lookup in the hash table rely only on the
spi, i.e. __xfrm_state_lookup() is still passed the address. It only
removes the destination address from the computation of the hash. This
allows passing NULL to __xfrm_state_lookup() specifically for input path
and make the lookup only based on the SPI. The destination address check
is done later (possibly after IRO remapping).
Except if I really missed something, this has no impact on outbound SA
(other hashtables are used in that case).
> Incidentally, it appears that our hash could do with some
> strengthening.
After the change, xfrm_spi_hash() would contain:
unsigned int h = (__force u32)spi ^ proto;
return ((h ^ (h >> 10) ^ (h >> 20)) & hmask)
which seems to spread the bits h correctly into hmask bits (I mean for
the effort ;-) ). Are you thinking about something like changing the
shifts based on the length of the mask?
Cheers,
a+
^ permalink raw reply
* Re: [PATCHv4 net-next-2.6 4/5] XFRM,IPv6: Add IRO remapping hook in xfrm_input()
From: Arnaud Ebalard @ 2010-10-04 20:51 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, Eric Dumazet, Hideaki YOSHIFUJI, netdev
In-Reply-To: <20101004084041.GB17939@gondor.apana.org.au>
Hi,
Herbert Xu <herbert@gondor.apana.org.au> writes:
> On Mon, Oct 04, 2010 at 08:25:23AM +0200, Arnaud Ebalard wrote:
>> Add a hook in xfrm_input() to allow IRO remapping to occur when
>> an incoming packet matching an existing SA (based on SPI) with
>> an unexpected destination or source address is received.
>> Because IRO does not consume additional bits in a packet (that's
>> the point), there is no way to demultiplex based on something
>> like nh or spi. Instead, IRO input handlers (for source and
>> destination address remapping) are called upon address mismatch
>> during IPsec processing.
>> For that to work, we rely on the fact that SPI values generated
>> locally are no more linked to destination address (first patch
>> of the set) and we postpone a bit the expected address check in
>> xfrm_input() (inside xfrm_state_lookup() against daddr param) by
>> introducing a call to the input_addr_check() handler from the
>> struct xfrm_state_afinfo associated with the address family.
>>
>> Signed-off-by: Arnaud Ebalard <arno@natisbad.org>
>
> I would prefer for this check to go into x->type->input since
> it does not apply to IPsec.
Either I don't understand the sentence or this is not feasible: the
thing is there is nothing in the packet to demultiplex like nh for
RH2/HAO. Here, we only lookup for a remapping state when there is a
mismatch in the source/destination addresses expected for the SA.
That's the reason IRO remapping states only apply to IPsec traffic.
> Just because the SPI is unique for inbound SAs, it doesn't mean
> that we should ignore the destination IP address in the packet for
> IPsec.
I don't ignore it. Before the change, for input IPsec traffic, the SA
lookup is done as follows:
- SA lookup based mostly on SPI
- Destination address check (done simultaneously during lookup)
fatal if mismatch
After the change, there are three steps for IPv6:
- SA lookup based on SPI
- Destination Address check
mismatch => lookup for destination remapping state
call for associated input handler
fatal if mismatch
- Source Address check
mismatch => lookup for source remapping state
call for associated input handler
Explanation makes it looks more complex than it is:
- IPv4 IPsec is basically untouched
- IPv6 IPsec is basically untouched when CONFIG_XFRM_SUB_POLICY is not
enabled,
- when CONFIG_XFRM_SUB_POLICY is enabled additional work is done only
for IPv6 upon address mismatch.
> I think another way of getting what you want is to simply add
> inbound SAs with a zero destination address in your case which
> can then be made to match any destination IP address. You can
> then follow that up with additional checks in x->type->input.
The idea is to allow the optimization for unmodified IPsec SA
(between stable addresses, i.e. HoA). Updating IRO src/dst remapping
states allow changing the src/dst on-wire address for unmodifed SA w/o
the need to explicitly add RH2 and/or HAO. Additionally, because source
and destination remapping are not linked, your proposal would not solve
the source remapping case, would it?
Thanks for your feedback and patience, Herbert!
Cheers,
a+
^ permalink raw reply
* Re: [Bugme-new] [Bug 19692] New: linux-2.6.36-rc5 crash with gianfar ethernet at full line rate traffic
From: Andrew Morton @ 2010-10-04 20:53 UTC (permalink / raw)
To: netdev; +Cc: bugzilla-daemon, bugme-daemon, eminak71, Anton Vorontsov
In-Reply-To: <bug-19692-10286@https.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Mon, 4 Oct 2010 06:25:14 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=19692
>
> Summary: linux-2.6.36-rc5 crash with gianfar ethernet at full
> line rate traffic
> Product: Drivers
> Version: 2.5
> Kernel Version: 2.6.36-rc5
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: blocking
> Priority: P1
> Component: Network
> AssignedTo: drivers_network@kernel-bugs.osdl.org
> ReportedBy: eminak71@gmail.com
> CC: eminak71@gmail.com
> Regression: Yes
>
>
> My problem is kernel crash under full line rate random packet length
> ip network traffic.
> I'am using default unmodified kernel and default SMP kernel
> configuration, MPC8572DS development board and also using a hardware
> packet generator.
> My test is ip forwarding between eth0 and eth1, and Hardware packet
> generator produces full duplex, full line rate traffic with random
> packet length and random payload . After a few millions of packets
> passed, kernel produces this bellow two different crash messages . I
> have retry this scenario many times, crash occurs sometimes on
> skb_put, but mostly occurs on ip_rcv function. I have aplied same
> test to latest stable linux 2.6.35.6 kernel. Same errors produced.
>
>
> Here is crash logs:
>
>
>
> Thanks.
>
> Emin
>
>
> First type of crash:
>
> root@mpc8572ds:~# skb_over_panic: text:c0226280 len:1171 put:1171
> head:eed6d000 data:eed63040 tail:0xeed6d4d3 end:0xeed63660 dev:<NULL>
> ------------[ cut here ]------------
> kernel BUG at net/core/skbuff.c:127!
> Oops: Exception in kernel mode, sig: 5 [#1]
> SMP NR_CPUS=2 MPC8572 DS
> last sysfs file: /sys/devices/pci0002:03/0002:03:00.0/subsystem_device
> Modules linked in:
> NIP: c023bdcc LR: c023bdcc CTR: c01f3ff8
> REGS: effe7d70 TRAP: 0700 Not tainted (2.6.36-rc5)
> MSR: 00029000 <EE,ME,CE> CR: 22028024 XER: 20000000
> TASK = ef83e9a0[9] 'ksoftirqd/1' THREAD: ef856000 CPU: 1
> GPR00: c023bdcc effe7e20 ef83e9a0 0000007c 00021000 ffffffff c01f7b98 c03ccf1c
> GPR08: c03c69d4 c03f94b4 00c4e000 00000004 20028048 1001a108 ef211000 efb52d90
> GPR16: efb52e38 efb52870 00000000 ef211800 00000008 00000009 efb52800 00000037
> GPR24: ef24e180 ef2be040 00000000 ef211948 efb52b80 00000493 ef015940 ef386600
> NIP [c023bdcc] skb_put+0x8c/0x94
> LR [c023bdcc] skb_put+0x8c/0x94
> Call Trace:
> [effe7e20] [c023bdcc] skb_put+0x8c/0x94 (unreliable)
> [effe7e30] [c0226280] gfar_clean_rx_ring+0x104/0x4b8
> [effe7e90] [c02269dc] gfar_poll+0x3a8/0x60c
> [effe7f60] [c024928c] net_rx_action+0xf8/0x1a4
> [effe7fa0] [c0042524] __do_softirq+0xe0/0x178
> [effe7ff0] [c000e59c] call_do_softirq+0x14/0x24
> [ef857f50] [c0004840] do_softirq+0x90/0xa0
> [ef857f70] [c00430e4] run_ksoftirqd+0xb4/0x164
> [ef857fb0] [c00586b4] kthread+0x7c/0x80
> [ef857ff0] [c000e9a8] kernel_thread+0x4c/0x68
> Instruction dump:
> 81030098 2f800000 409e000c 3d20c037 3809a19c 3c60c037 7c8802a6 7d695b78
> 3863b010 90010008 4cc63182 4be016c5 <0fe00000> 48000000 9421fff0 7c0802a6
> Kernel panic - not syncing: Fatal exception in interrupt
> ---------------
>
> second type of crash:
>
> Faulting instruction address: 0xc026c1dc
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=2 MPC8572 DS
> last sysfs file: /sys/devices/pci0002:03/0002:03:00.0/subsystem_device
> Modules linked in:
> NIP: c026c1dc LR: c026bfac CTR: 00000000
> REGS: effebd00 TRAP: 0300 Not tainted (2.6.36-rc5)
> MSR: 00029000 <EE,ME,CE> CR: 42028042 XER: 00000000
> DEAR: 0000cad8, ESR: 00000000
> TASK = ef83cde0[3] 'ksoftirqd/0' THREAD: ef84a000 CPU: 0
> GPR00: 00000005 effebdb0 ef83cde0 00000000 000001b9 00000000 c1008060 00000000
> GPR08: 02c3f605 0000ca00 000005b9 0000ca00 b653a6c7 7af823f0 ef217000 efbab590
> GPR16: efbab638 efbab070 00000000 ef217800 00000008 00000018 efbab000 00000028
> GPR24: c03f971c c0410000 c0400000 c03f94b4 effea000 ef316e40 00000000 eecb685e
> NIP [c026c1dc] ip_rcv+0x3f8/0x808
> LR [c026bfac] ip_rcv+0x1c8/0x808
> Call Trace:
> [effebdb0] [c026c204] ip_rcv+0x420/0x808 (unreliable)
> [effebde0] [c02482dc] __netif_receive_skb+0x2f8/0x324
> [effebe10] [c02483a4] netif_receive_skb+0x9c/0xb0
> [effebe30] [c0226308] gfar_clean_rx_ring+0x18c/0x4b8
> [effebe90] [c02269dc] gfar_poll+0x3a8/0x60c
> [effebf60] [c024928c] net_rx_action+0xf8/0x1a4
> [effebfa0] [c0042524] __do_softirq+0xe0/0x178
> [effebff0] [c000e59c] call_do_softirq+0x14/0x24
> [ef84bf50] [c0004840] do_softirq+0x90/0xa0
> [ef84bf70] [c00430e4] run_ksoftirqd+0xb4/0x164
> [ef84bfb0] [c00586b4] kthread+0x7c/0x80
> [ef84bff0] [c000e9a8] kernel_thread+0x4c/0x68
> Instruction dump:
> 8148003c 318a0001 7d690194 91680038 9188003c 4bfffd78 7fa3eb78 48002a29
> 2f830000 40beff50 817d0048 5569003c <a00900d8> 2f800005 419e0034 2f800003
> Kernel panic - not syncing: Fatal exception in interrupt
>
^ permalink raw reply
* Re: [PATCH] ibmtr: fix tr%d in dmesg
From: Meelis Roos @ 2010-10-04 21:12 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20101003.205632.104074109.davem@davemloft.net>
> Instead, the more correct way to fit this is to use dev_info(),
> dev_err(), and friends. It will both print the correct stuff,
> and also document the probing path messages that occur before
> the net device is registered.
OK, fair enough.
I remember trying dev_info first and getting null from it. Retried, got
(null): ISA P&P 16/4 Adapter/A (short) | 16/4 ISA-16 Adapter found
So it seems dev_info does not know about 16-bit pcmcia devices or
buses... dev_driver_string() finds neither dev->name, dev->bus->name nor
dev->class->name. Will dig into this some other day.
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* Re: [PATCH] tms380tr: fix long delays in initialization
From: Meelis Roos @ 2010-10-04 21:15 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20101004.094254.35052481.davem@davemloft.net>
> tms380tr_init_adapter() gets called from tms380tr_chk_irq() which is
> invoked from the interrupt handler.
Oops, yes, sorry for repeatedly not noticing it even when I was
explicitly searching for it :(
What is the general course from here? Defer the long reset to a work
queue, or some other kind of background task?
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* Re: [PATCH] tms380tr: fix long delays in initialization
From: David Miller @ 2010-10-04 21:33 UTC (permalink / raw)
To: mroos; +Cc: netdev
In-Reply-To: <alpine.SOC.1.00.1010050012380.5418@math.ut.ee>
From: Meelis Roos <mroos@linux.ee>
Date: Tue, 5 Oct 2010 00:15:17 +0300 (EEST)
>> tms380tr_init_adapter() gets called from tms380tr_chk_irq() which is
>> invoked from the interrupt handler.
>
> Oops, yes, sorry for repeatedly not noticing it even when I was
> explicitly searching for it :(
>
> What is the general course from here? Defer the long reset to a work
> queue, or some other kind of background task?
Yes, very likely a workqueue is the best course of action.
^ permalink raw reply
* [net-next-2.6 PATCH] net: netif_set_real_num_rx_queues may cap num_rx_queues at init time
From: John Fastabend @ 2010-10-04 22:00 UTC (permalink / raw)
To: bhutchings, netdev; +Cc: john.r.fastabend, therbert
The logic for netif_set_real_num_rx_queues is the following,
netif_set_real_num_rx_queues(dev, rxq)
{
...
if (dev->reg_state == NETREG_REGISTERED) {
...
} else {
dev->num_rx_queues = rxq;
}
dev->real_num_rx_queues = rxq;
return 0;
}
Some drivers init path looks like the following,
alloc_etherdev_mq(priv_sz, max_num_queues_ever);
...
netif_set_real_num_rx_queues(dev, queues_to_use_now);
...
register_netdev(dev);
...
Because netif_set_real_num_rx_queues sets num_rx_queues if the
reg state is not NETREG_REGISTERED we end up with the incorrect
max number of rx queues. This patch proposes to remove the else
clause above so this does not occur. Also just reading the
function set_real_num it seems a bit unexpected that num_rx_queues
gets set.
CC: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
---
net/core/dev.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index a313bab..f78d996 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1592,8 +1592,6 @@ int netif_set_real_num_rx_queues(struct net_device *dev, unsigned int rxq)
rxq);
if (rc)
return rc;
- } else {
- dev->num_rx_queues = rxq;
}
dev->real_num_rx_queues = rxq;
^ permalink raw reply related
* Re: [Bugme-new] [Bug 19492] New: sky2 wake on line stopped working in 2.6.34/2.6.35
From: Andrew Morton @ 2010-10-04 22:14 UTC (permalink / raw)
To: arekm
Cc: bugzilla-daemon, bugme-daemon, netdev, Stephen Hemminger,
Ben Hutchings
In-Reply-To: <bug-19492-10286@https.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Sat, 2 Oct 2010 08:30:14 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=19492
>
> Summary: sky2 wake on line stopped working in 2.6.34/2.6.35
> Product: Drivers
> Version: 2.5
> Kernel Version: 2.6.34, 2.6.35
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Network
> AssignedTo: drivers_network@kernel-bugs.osdl.org
> ReportedBy: arekm@maven.pl
> Regression: Yes
>
A regression.
> sky2 WOL feature stopped working in 2.6.34 kernel. It was working fine in
> 2.6.33. ethtool 2.6.35 (and some earlier version before).
>
> # ethtool -s eth0 wol g
> # ethtool eth0|grep Wake
> Supports Wake-on: pg
> Wake-on: g
> # ethtool -i eth0
> driver: sky2
> version: 1.28
> firmware-version: N/A
> bus-info: 0000:05:00.0
> # poweroff
>
> When googling for solution I found /sys/class/net/eth0/device/power/wakeup
> which contains "disabled" before AND after I run ethtool. So I echoed "enabled"
> there, too but it didn't help. The machine doesn't wake up on magick packet.
>
> ...
>
I can't immediately see any recent changes to the driver in that area
apart from "ethtool: Change ethtool_op_set_flags to validate flags".
Perhaps you could run
strace -f ethtool -s eth0 wol g
and see if it's getting an error when setting WOL mode. If so, ethtool
is broken ;)
^ permalink raw reply
* Re: pull-request: bluetooth-2.6 2010-09-27
From: Gustavo F. Padovan @ 2010-10-04 22:35 UTC (permalink / raw)
To: David Miller; +Cc: linville, marcel, linux-bluetooth, netdev
In-Reply-To: <20101001012203.GE3048@vigoh>
Hi Dave,
* Gustavo F. Padovan <padovan@profusion.mobi> [2010-09-30 22:22:03 -0300]:
> Hi Dave,
>
> * David Miller <davem@davemloft.net> [2010-09-30 17:26:57 -0700]:
>
> > From: "Gustavo F. Padovan" <padovan@profusion.mobi>
> > Date: Tue, 28 Sep 2010 19:49:41 -0300
> >
> > > Actually sk_stream_wait_memory is another point why it's safe to release
> > > the lock and block waiting for memory. We've been doing that safely in
> > > protocols like TCP, SCTP and DCCP for a long time.
> >
> > Do you notice what TCP does when sk_stream_wait_memory() returns?
> >
> > It reloads all volatile state that might have changed in the socket
> > while the lock was dropped.
> >
> > For example, TCP will reload the current MSS that can change
> > asynchronously while we don't have the socket lock.
>
> I got your point. And what I tried to say in the last e-mail is that
> ERTM doesn't have such volatile states that need to restore after get
> the lock back. The others code path it affect are very simple and also
> doesn't have such problem. So we are safe against asynchronous changes.
> We obvious have volatiles states, but the code paths where
> bt_skb_send_alloc() is used doesn't rely on that states. I'm seeing no
> problem on release the lock, alloc memory, and lock it again.
I did a proper audit of the code paths:
sco_send_frame(): after bt_skb_send_alloc() returns the function doesn't
touch any sk state anymore, it just picks the skb and sends it to the
HCI.
l2cap_create_connless_pdu(): after bt_skb_send_alloc() returns the
function only reads l2cap_pi(sk)->dcid and l2cap_pi(sk)->psm, those
value are static and don't change with the connection alive
l2cap_create_connless_pdu(): after bt_skb_send_alloc() returns the
function only reads l2cap_pi(sk)->dcid, that value is static and doesn't
change with the connection alive.
l2cap_create_iframe_pdu(): after bt_skb_send_alloc() returns, we only
reads l2cap_pi(sk)->dcid and l2cap_pi(sk)->fcs which doesn change with
the connection alive, l2cap_create_iframe_pdu() returns the skb to
l2cap_sar_segment_sdu(), which changes only the TX_QUEUE(sk), but it
only appends in the end while the rest of the L2CAP code reads from
the begin. After that we have the process of sending of ERTM and
Streaming Mode, this process is independent from the skb alloc process,
so no problem here.
Other point already discussed are the check after get the lock again,
they guarantee that the socket is still connected, otherwise returns
error.
An extra check will be added to setsockopt() just to make sure that
l2cap_pi(sk)->fcs won't change while the sk_state is BT_CONNECTED. That
was an issue even before this backlog queue issue.
Follow the output of git show for that change, if we agree on the change I
can append it to the bluetooth pull request.
Author: Gustavo F. Padovan <padovan@profusion.mobi>
Date: Mon Oct 4 19:28:52 2010 -0300
Bluetooth: Disallow to change L2CAP_OPTIONS values when connected
L2CAP doesn't permit change like MTU, FCS, TxWindow values while the
connection is alive, we can only set that before the
connection/configuration process. That can lead to bugs in the L2CAP
operation.
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 44a8fb0..0b54b7d 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -1950,6 +1950,11 @@ static int l2cap_sock_setsockopt_old(struct socket *sock, int optname, char __us
switch (optname) {
case L2CAP_OPTIONS:
+ if (sk->sk_state == BT_CONNECTED) {
+ err = -EINVAL;
+ break;
+ }
+
opts.imtu = l2cap_pi(sk)->imtu;
opts.omtu = l2cap_pi(sk)->omtu;
opts.flush_to = l2cap_pi(sk)->flush_to;
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply related
* Re: [patch v2 03/12] [PATCH 03/12] IPVS: compact ip_vs_sched_persist()
From: Julian Anastasov @ 2010-10-04 22:36 UTC (permalink / raw)
To: Simon Horman
Cc: lvs-devel, netdev, netfilter, netfilter-devel, Jan Engelhardt,
Stephen Hemminger, Wensong Zhang, Patrick McHardy
In-Reply-To: <20101002080850.GC2248@verge.net.au>
Hello,
On Sat, 2 Oct 2010, Simon Horman wrote:
>> I'm still wondering, may be it needs separate patch
>> but we do not support NAT to different dest->port in the
>> case for fwmark. May be the above logic can be changed to
>> support it. By this way web to different VIPs and VPORTs
>> in a single virtual service (fwmark) can use single NAT
>> real server for name-based virtual hosting. But such change
>> can create compatibility problems for setups that used
>> different vports for the fwmark service and still expect
>> it in that way (vport to same dport).
>
> Hi Julian,
>
> I think that this sounds line a new flavour of fwmark virtual services to me.
> Perhaps yet another flag is in order?
>
> To be clear, what you have in mind is essentially to nat *:* (as matched by
> a fwmark) to x:y, where as at this time *:y may be natted to x:y.
Yes, the difference is here, persistent services with fwmark
ignore dest->port while non-persistent services with fwmark prefer
dest->port:
ip_vs_sched_persist:
dport = ports[1];
if (dport == svc->port && dest->port)
dport = dest->port;
- before the PE changes even dest->port=0 was selected
for non-fwmark
ip_vs_schedule:
dport set as: dest->port ? dest->port : pptr[1]
It is inconsistent. If we add new option for dest
it should have 3 states:
0: default (current, compatible)
1: prefer real server port
2: keep dport in packet
But the same can be done with rport or that was the
goal before:
- rport=0 (zero port) - keep dport from packet
- rport>0 - use this real server port
It works perfectly for ip_vs_schedule but not for
ip_vs_sched_persist, rport>0 is ignored for persistent
fwmark and this is wrong for NAT. Persistence should just
select dest but now it changes the rport semantic. The
right thing is ip_vs_sched_persist to work as ip_vs_schedule
but it can break some setups with persistence and fwmark.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [Bugme-new] [Bug 19492] New: sky2 wake on line stopped working in 2.6.34/2.6.35
From: Stephen Hemminger @ 2010-10-05 0:10 UTC (permalink / raw)
To: Andrew Morton; +Cc: arekm, bugzilla-daemon, bugme-daemon, netdev, Ben Hutchings
In-Reply-To: <20101004151404.df90d70b.akpm@linux-foundation.org>
On Mon, 4 Oct 2010 15:14:04 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:
>
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Sat, 2 Oct 2010 08:30:14 GMT
> bugzilla-daemon@bugzilla.kernel.org wrote:
>
> > https://bugzilla.kernel.org/show_bug.cgi?id=19492
> >
> > Summary: sky2 wake on line stopped working in 2.6.34/2.6.35
> > Product: Drivers
> > Version: 2.5
> > Kernel Version: 2.6.34, 2.6.35
> > Platform: All
> > OS/Version: Linux
> > Tree: Mainline
> > Status: NEW
> > Severity: normal
> > Priority: P1
> > Component: Network
> > AssignedTo: drivers_network@kernel-bugs.osdl.org
> > ReportedBy: arekm@maven.pl
> > Regression: Yes
> >
>
> A regression.
>
> > sky2 WOL feature stopped working in 2.6.34 kernel. It was working fine in
> > 2.6.33. ethtool 2.6.35 (and some earlier version before).
> >
> > # ethtool -s eth0 wol g
> > # ethtool eth0|grep Wake
> > Supports Wake-on: pg
> > Wake-on: g
> > # ethtool -i eth0
> > driver: sky2
> > version: 1.28
> > firmware-version: N/A
> > bus-info: 0000:05:00.0
> > # poweroff
> >
> > When googling for solution I found /sys/class/net/eth0/device/power/wakeup
> > which contains "disabled" before AND after I run ethtool. So I echoed "enabled"
> > there, too but it didn't help. The machine doesn't wake up on magick packet.
> >
> > ...
> >
>
> I can't immediately see any recent changes to the driver in that area
> apart from "ethtool: Change ethtool_op_set_flags to validate flags".
> Perhaps you could run
>
> strace -f ethtool -s eth0 wol g
>
> and see if it's getting an error when setting WOL mode. If so, ethtool
> is broken ;)
>
There have been changes in the core power management layer, that is
where I would look. Usually the problem is the incorrectly BIOS marks the device
as unable to do PM. Probably the old kernel ignored the BIOS, and newer
kernels look at it more closely?
Last WoL changes were to make driver follow vendor driver which happened
between 2.6.33 and 2.6.34
commit 5f8ae5c537d937bab9cfeb83a30a9b670c3cfb35
Author: stephen hemminger <shemminger@vyatta.com>
Date: Fri Feb 12 06:57:59 2010 +0000
sky2: WoL changes
Change Wake On Lan code to be similar to vendor driver. The definition
of Y2_HW_WOL_ON is confusing; what it means is transition to firmware SPI
setting when doing power change.
Since same code is done for both shutdown and suspend, use common
code path.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 87b09f1f25cd1e01d7c50bf423c7fe33027d7511
Author: stephen hemminger <shemminger@vyatta.com>
Date: Fri Feb 12 06:58:00 2010 +0000
sky2: dont enable PME legacy mode
This bit is not changed by vendor driver, and should be left alone.
The documentation implies this a debug bit.
0 = WAKE# only asserted when VMAIN not available
1 = WAKE# is depend on wake events and independent of VMAIN.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* WINNING NOTIFICATION
From: Dr R L Bhatia, CEO @ 2010-10-05 0:17 UTC (permalink / raw)
CONGRATULATION FROM CMO ASIA AWARD YOUR EMAILL ADDRESS HAVE WON $1.1 MILLION USD AWARD
^ permalink raw reply
* Re: [Bonding-devel] [PATCH] bonding: fix WARN_ON when writing to bond_master sysfs file
From: Stephen Hemminger @ 2010-10-05 0:57 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev, fubar, bonding-devel, davem
In-Reply-To: <20101004202112.GA27897@hmsreliant.think-freely.org>
On Mon, 4 Oct 2010 16:21:12 -0400
Neil Horman <nhorman@tuxdriver.com> wrote:
> Fix a WARN_ON failure in bond_masters sysfs file
>
> Got a report of this warning recently
>
> bonding: bond0 is being created...
> ------------[ cut here ]------------
> WARNING: at fs/proc/generic.c:590 proc_register+0x14d/0x185()
> Hardware name: ProLiant BL465c G1
> proc_dir_entry 'bonding/bond0' already registered
> Modules linked in: bonding ipv6 tg3 bnx2 shpchp amd64_edac_mod edac_core
> ipmi_si
> ipmi_msghandler serio_raw i2c_piix4 k8temp edac_mce_amd hpwdt microcode hpsa
> cc
> iss radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded:
> scsi_wai
> t_scan]
> Pid: 935, comm: ifup-eth Not tainted 2.6.33.5-124.fc13.x86_64 #1
> Call Trace:
> [<ffffffff8104b54c>] warn_slowpath_common+0x77/0x8f
> [<ffffffff8104b5b1>] warn_slowpath_fmt+0x3c/0x3e
> [<ffffffff8114bf0b>] proc_register+0x14d/0x185
> [<ffffffff8114c20c>] proc_create_data+0x87/0xa1
> [<ffffffffa0211e9b>] bond_create_proc_entry+0x55/0x95 [bonding]
> [<ffffffffa0215e5d>] bond_init+0x95/0xd0 [bonding]
> [<ffffffff8138cd97>] register_netdevice+0xdd/0x29e
> [<ffffffffa021240b>] bond_create+0x8e/0xb8 [bonding]
> [<ffffffffa021c4be>] bonding_store_bonds+0xb3/0x1c1 [bonding]
> [<ffffffff812aec85>] class_attr_store+0x27/0x29
> [<ffffffff8115423d>] sysfs_write_file+0x10f/0x14b
> [<ffffffff81101acf>] vfs_write+0xa9/0x106
> [<ffffffff81101be2>] sys_write+0x45/0x69
> [<ffffffff81009b02>] system_call_fastpath+0x16/0x1b
> ---[ end trace a677c3f7f8b16b1e ]---
> bonding: Bond creation failed.
>
> It happens because a user space writer to bond_master can try to register and
> already existing bond interface name. Fix it by teaching bond_create to check
> for the existance of devices with that name first in cases where a non-NULL name
> parameter has been passed in
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
>
> bond_main.c | 16 +++++++++++++++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index fb70c3e..10e4ffe 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -5148,7 +5148,7 @@ static struct rtnl_link_ops bond_link_ops __read_mostly = {
> */
> int bond_create(struct net *net, const char *name)
> {
> - struct net_device *bond_dev;
> + struct net_device *bond_dev, *check_dev;
> int res;
>
> rtnl_lock();
> @@ -5168,6 +5168,20 @@ int bond_create(struct net *net, const char *name)
> res = dev_alloc_name(bond_dev, "bond%d");
> if (res < 0)
> goto out;
> + } else {
> + /*
> + * If we're given a name to register
> + * we need to ensure that its not already
> + * registered
> + */
> + check_dev = dev_get_by_name(net, name);
> +
> + res = (check_dev) ? 0 : -EEXIST;
> +
> + dev_put(check_dev);
> +
> + if (res)
> + goto out;
> }
>
> res = register_netdevice(bond_dev);
Why is this necessary?
register_netdevice does already check for duplicate name so please
use it's return value instead
If that doesn't work then use __dev_get_by_name to avoid
ref count (ie dev_put).
^ permalink raw reply
* [PATCH net-next] qlcnic: remove dead code
From: Stephen Hemminger @ 2010-10-05 1:44 UTC (permalink / raw)
To: Amit Kumar Salecha
Cc: davem, netdev, ameen.rahman, anirban.chakraborty, Sritej Velaga
In-Reply-To: <1286202016-18026-9-git-send-email-amit.salecha@qlogic.com>
This driver has several pieces of dead code (found by running
make namespacecheck). This patch removes them.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
Applies after Amit's earlier patches.
--- a/drivers/net/qlcnic/qlcnic.h 2010-10-05 10:37:07.442332958 +0900
+++ b/drivers/net/qlcnic/qlcnic.h 2010-10-05 10:38:04.459818979 +0900
@@ -1323,19 +1323,12 @@ netdev_tx_t qlcnic_xmit_frame(struct sk_
void qlcnic_process_rcv_ring_diag(struct qlcnic_host_sds_ring *sds_ring);
/* Management functions */
-int qlcnic_set_mac_address(struct qlcnic_adapter *, u8*);
int qlcnic_get_mac_address(struct qlcnic_adapter *, u8*);
int qlcnic_get_nic_info(struct qlcnic_adapter *, struct qlcnic_info *, u8);
int qlcnic_set_nic_info(struct qlcnic_adapter *, struct qlcnic_info *);
int qlcnic_get_pci_info(struct qlcnic_adapter *, struct qlcnic_pci_info*);
-int qlcnic_reset_partition(struct qlcnic_adapter *, u8);
/* eSwitch management functions */
-int qlcnic_get_eswitch_capabilities(struct qlcnic_adapter *, u8,
- struct qlcnic_eswitch *);
-int qlcnic_get_eswitch_status(struct qlcnic_adapter *, u8,
- struct qlcnic_eswitch *);
-int qlcnic_toggle_eswitch(struct qlcnic_adapter *, u8, u8);
int qlcnic_config_switch_port(struct qlcnic_adapter *,
struct qlcnic_esw_func_cfg *);
int qlcnic_get_eswitch_port_config(struct qlcnic_adapter *,
--- a/drivers/net/qlcnic/qlcnic_ctx.c 2010-10-05 10:37:00.492317319 +0900
+++ b/drivers/net/qlcnic/qlcnic_ctx.c 2010-10-05 10:38:04.459818979 +0900
@@ -556,32 +556,6 @@ void qlcnic_free_hw_resources(struct qlc
}
}
-/* Set MAC address of a NIC partition */
-int qlcnic_set_mac_address(struct qlcnic_adapter *adapter, u8* mac)
-{
- int err = 0;
- u32 arg1, arg2, arg3;
-
- arg1 = adapter->ahw.pci_func | BIT_9;
- arg2 = mac[0] | (mac[1] << 8) | (mac[2] << 16) | (mac[3] << 24);
- arg3 = mac[4] | (mac[5] << 16);
-
- err = qlcnic_issue_cmd(adapter,
- adapter->ahw.pci_func,
- adapter->fw_hal_version,
- arg1,
- arg2,
- arg3,
- QLCNIC_CDRP_CMD_MAC_ADDRESS);
-
- if (err != QLCNIC_RCODE_SUCCESS) {
- dev_err(&adapter->pdev->dev,
- "Failed to set mac address%d\n", err);
- err = -EIO;
- }
-
- return err;
-}
/* Get MAC address of a NIC partition */
int qlcnic_get_mac_address(struct qlcnic_adapter *adapter, u8 *mac)
@@ -764,149 +738,6 @@ int qlcnic_get_pci_info(struct qlcnic_ad
return err;
}
-/* Reset a NIC partition */
-
-int qlcnic_reset_partition(struct qlcnic_adapter *adapter, u8 func_no)
-{
- int err = -EIO;
-
- if (adapter->op_mode != QLCNIC_MGMT_FUNC)
- return err;
-
- err = qlcnic_issue_cmd(adapter,
- adapter->ahw.pci_func,
- adapter->fw_hal_version,
- func_no,
- 0,
- 0,
- QLCNIC_CDRP_CMD_RESET_NPAR);
-
- if (err != QLCNIC_RCODE_SUCCESS) {
- dev_err(&adapter->pdev->dev,
- "Failed to issue reset partition%d\n", err);
- err = -EIO;
- }
-
- return err;
-}
-
-/* Get eSwitch Capabilities */
-int qlcnic_get_eswitch_capabilities(struct qlcnic_adapter *adapter, u8 port,
- struct qlcnic_eswitch *eswitch)
-{
- int err = -EIO;
- u32 arg1, arg2;
-
- if (adapter->op_mode == QLCNIC_NON_PRIV_FUNC)
- return err;
-
- err = qlcnic_issue_cmd(adapter,
- adapter->ahw.pci_func,
- adapter->fw_hal_version,
- port,
- 0,
- 0,
- QLCNIC_CDRP_CMD_GET_ESWITCH_CAPABILITY);
-
- if (err == QLCNIC_RCODE_SUCCESS) {
- arg1 = QLCRD32(adapter, QLCNIC_ARG1_CRB_OFFSET);
- arg2 = QLCRD32(adapter, QLCNIC_ARG2_CRB_OFFSET);
-
- eswitch->port = arg1 & 0xf;
- eswitch->max_ucast_filters = LSW(arg2);
- eswitch->max_active_vlans = MSW(arg2) & 0xfff;
- if (arg1 & BIT_6)
- eswitch->flags |= QLCNIC_SWITCH_VLAN_FILTERING;
- if (arg1 & BIT_7)
- eswitch->flags |= QLCNIC_SWITCH_PROMISC_MODE;
- if (arg1 & BIT_8)
- eswitch->flags |= QLCNIC_SWITCH_PORT_MIRRORING;
- } else {
- dev_err(&adapter->pdev->dev,
- "Failed to get eswitch capabilities%d\n", err);
- }
-
- return err;
-}
-
-/* Get current status of eswitch */
-int qlcnic_get_eswitch_status(struct qlcnic_adapter *adapter, u8 port,
- struct qlcnic_eswitch *eswitch)
-{
- int err = -EIO;
- u32 arg1, arg2;
-
- if (adapter->op_mode != QLCNIC_MGMT_FUNC)
- return err;
-
- err = qlcnic_issue_cmd(adapter,
- adapter->ahw.pci_func,
- adapter->fw_hal_version,
- port,
- 0,
- 0,
- QLCNIC_CDRP_CMD_GET_ESWITCH_STATUS);
-
- if (err == QLCNIC_RCODE_SUCCESS) {
- arg1 = QLCRD32(adapter, QLCNIC_ARG1_CRB_OFFSET);
- arg2 = QLCRD32(adapter, QLCNIC_ARG2_CRB_OFFSET);
-
- eswitch->port = arg1 & 0xf;
- eswitch->active_vports = LSB(arg2);
- eswitch->active_ucast_filters = MSB(arg2);
- eswitch->active_vlans = LSB(MSW(arg2));
- if (arg1 & BIT_6)
- eswitch->flags |= QLCNIC_SWITCH_VLAN_FILTERING;
- if (arg1 & BIT_8)
- eswitch->flags |= QLCNIC_SWITCH_PORT_MIRRORING;
-
- } else {
- dev_err(&adapter->pdev->dev,
- "Failed to get eswitch status%d\n", err);
- }
-
- return err;
-}
-
-/* Enable/Disable eSwitch */
-int qlcnic_toggle_eswitch(struct qlcnic_adapter *adapter, u8 id, u8 enable)
-{
- int err = -EIO;
- u32 arg1, arg2;
- struct qlcnic_eswitch *eswitch;
-
- if (adapter->op_mode != QLCNIC_MGMT_FUNC)
- return err;
-
- eswitch = &adapter->eswitch[id];
- if (!eswitch)
- return err;
-
- arg1 = eswitch->port | (enable ? BIT_4 : 0);
- arg2 = eswitch->active_vports | (eswitch->max_ucast_filters << 8) |
- (eswitch->max_active_vlans << 16);
- err = qlcnic_issue_cmd(adapter,
- adapter->ahw.pci_func,
- adapter->fw_hal_version,
- arg1,
- arg2,
- 0,
- QLCNIC_CDRP_CMD_TOGGLE_ESWITCH);
-
- if (err != QLCNIC_RCODE_SUCCESS) {
- dev_err(&adapter->pdev->dev,
- "Failed to enable eswitch%d\n", eswitch->port);
- eswitch->flags &= ~QLCNIC_SWITCH_ENABLE;
- err = -EIO;
- } else {
- eswitch->flags |= QLCNIC_SWITCH_ENABLE;
- dev_info(&adapter->pdev->dev,
- "Enabled eSwitch for port %d\n", eswitch->port);
- }
-
- return err;
-}
-
/* Configure eSwitch for port mirroring */
int qlcnic_config_port_mirroring(struct qlcnic_adapter *adapter, u8 id,
u8 enable_mirroring, u8 pci_func)
^ permalink raw reply
* Re: [PATCHv4 net-next-2.6 1/5] XFRM,IPv6: Remove xfrm_spi_hash() dependency on destination address
From: Herbert Xu @ 2010-10-05 2:11 UTC (permalink / raw)
To: Arnaud Ebalard; +Cc: David S. Miller, Eric Dumazet, Hideaki YOSHIFUJI, netdev
In-Reply-To: <8739sl8yw5.fsf@small.ssi.corp>
On Mon, Oct 04, 2010 at 10:51:38PM +0200, Arnaud Ebalard wrote:
>
> Herbert Xu <herbert@gondor.apana.org.au> writes:
>
> > I'm fine with doing this for inbound SAs. However, I can't see
> > how we can do this for outbound SAs where the SPI is chosen by
> > the remote end.
>
> The change *does not* make the lookup in the hash table rely only on the
> spi, i.e. __xfrm_state_lookup() is still passed the address. It only
> removes the destination address from the computation of the hash. This
> allows passing NULL to __xfrm_state_lookup() specifically for input path
> and make the lookup only based on the SPI. The destination address check
> is done later (possibly after IRO remapping).
>
> Except if I really missed something, this has no impact on outbound SA
> (other hashtables are used in that case).
I'm thinking about the case where each remote end (or one remote
end with many IP addresses) chooses to use a single SPI which then
all gets hashed to the same bucket.
Outbound SAs are hashed into the same SPI hash table as inbound SAs.
> > Incidentally, it appears that our hash could do with some
> > strengthening.
>
> After the change, xfrm_spi_hash() would contain:
>
> unsigned int h = (__force u32)spi ^ proto;
> return ((h ^ (h >> 10) ^ (h >> 20)) & hmask)
>
> which seems to spread the bits h correctly into hmask bits (I mean for
> the effort ;-) ). Are you thinking about something like changing the
> shifts based on the length of the mask?
What I meant here is that even without your change, it is relatively
easy to cause many SAs to be hashed to the same bucket.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [Bonding-devel] [PATCH] bonding: fix WARN_ON when writing to bond_master sysfs file
From: Neil Horman @ 2010-10-05 2:26 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, fubar, bonding-devel, davem
In-Reply-To: <20101005095713.624ca320@s6510>
On Tue, Oct 05, 2010 at 09:57:13AM +0900, Stephen Hemminger wrote:
> On Mon, 4 Oct 2010 16:21:12 -0400
> Neil Horman <nhorman@tuxdriver.com> wrote:
>
> > Fix a WARN_ON failure in bond_masters sysfs file
> >
> > Got a report of this warning recently
> >
> > bonding: bond0 is being created...
> > ------------[ cut here ]------------
> > WARNING: at fs/proc/generic.c:590 proc_register+0x14d/0x185()
> > Hardware name: ProLiant BL465c G1
> > proc_dir_entry 'bonding/bond0' already registered
> > Modules linked in: bonding ipv6 tg3 bnx2 shpchp amd64_edac_mod edac_core
> > ipmi_si
> > ipmi_msghandler serio_raw i2c_piix4 k8temp edac_mce_amd hpwdt microcode hpsa
> > cc
> > iss radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded:
> > scsi_wai
> > t_scan]
> > Pid: 935, comm: ifup-eth Not tainted 2.6.33.5-124.fc13.x86_64 #1
> > Call Trace:
> > [<ffffffff8104b54c>] warn_slowpath_common+0x77/0x8f
> > [<ffffffff8104b5b1>] warn_slowpath_fmt+0x3c/0x3e
> > [<ffffffff8114bf0b>] proc_register+0x14d/0x185
> > [<ffffffff8114c20c>] proc_create_data+0x87/0xa1
> > [<ffffffffa0211e9b>] bond_create_proc_entry+0x55/0x95 [bonding]
> > [<ffffffffa0215e5d>] bond_init+0x95/0xd0 [bonding]
> > [<ffffffff8138cd97>] register_netdevice+0xdd/0x29e
> > [<ffffffffa021240b>] bond_create+0x8e/0xb8 [bonding]
> > [<ffffffffa021c4be>] bonding_store_bonds+0xb3/0x1c1 [bonding]
> > [<ffffffff812aec85>] class_attr_store+0x27/0x29
> > [<ffffffff8115423d>] sysfs_write_file+0x10f/0x14b
> > [<ffffffff81101acf>] vfs_write+0xa9/0x106
> > [<ffffffff81101be2>] sys_write+0x45/0x69
> > [<ffffffff81009b02>] system_call_fastpath+0x16/0x1b
> > ---[ end trace a677c3f7f8b16b1e ]---
> > bonding: Bond creation failed.
> >
> > It happens because a user space writer to bond_master can try to register and
> > already existing bond interface name. Fix it by teaching bond_create to check
> > for the existance of devices with that name first in cases where a non-NULL name
> > parameter has been passed in
> >
> > Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> >
> > bond_main.c | 16 +++++++++++++++-
> > 1 file changed, 15 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> > index fb70c3e..10e4ffe 100644
> > --- a/drivers/net/bonding/bond_main.c
> > +++ b/drivers/net/bonding/bond_main.c
> > @@ -5148,7 +5148,7 @@ static struct rtnl_link_ops bond_link_ops __read_mostly = {
> > */
> > int bond_create(struct net *net, const char *name)
> > {
> > - struct net_device *bond_dev;
> > + struct net_device *bond_dev, *check_dev;
> > int res;
> >
> > rtnl_lock();
> > @@ -5168,6 +5168,20 @@ int bond_create(struct net *net, const char *name)
> > res = dev_alloc_name(bond_dev, "bond%d");
> > if (res < 0)
> > goto out;
> > + } else {
> > + /*
> > + * If we're given a name to register
> > + * we need to ensure that its not already
> > + * registered
> > + */
> > + check_dev = dev_get_by_name(net, name);
> > +
> > + res = (check_dev) ? 0 : -EEXIST;
> > +
> > + dev_put(check_dev);
> > +
> > + if (res)
> > + goto out;
> > }
> >
> > res = register_netdevice(bond_dev);
>
> Why is this necessary?
> register_netdevice does already check for duplicate name so please
> use it's return value instead
>
No, its the call to register_netdev that causes the WARN_ON. Check the stack
trace, register_netdev call bond_init which in turn registers a proc interface
by an existing name, which causes the WARN_ON
> If that doesn't work then use __dev_get_by_name to avoid
> ref count (ie dev_put).
>
Yeah, thats a good idea. I'll respin this in the AM. Thanks!
Regards
Neil
^ permalink raw reply
* Letter To You.
From: Andrias Ewat @ 2010-10-05 3:03 UTC (permalink / raw)
Attn,
I am Andrias Ewat,a trained external auditor working for MayBank Malaysia.I am contacting you to assist in regrads of the money left behind by one of our investor who shares the same last name as yours before it is confiscated or declared unserviceable by Maybank where this deposit valued at US$10 Million is lodged
Best regards,
Andrias Ewat
^ permalink raw reply
* (unknown)
From: 7parks @ 2010-10-05 3:31 UTC (permalink / raw)
Your Email ID has been awarded 1,000,000.00 Pounds in the British Promo send your:Names...Address...Tel...
^ permalink raw reply
* Re: [PATCHv4 net-next-2.6 1/5] XFRM,IPv6: Remove xfrm_spi_hash() dependency on destination address
From: Herbert Xu @ 2010-10-05 4:17 UTC (permalink / raw)
To: Arnaud Ebalard; +Cc: David S. Miller, Eric Dumazet, Hideaki YOSHIFUJI, netdev
In-Reply-To: <20101005021114.GA25681@gondor.apana.org.au>
On Tue, Oct 05, 2010 at 10:11:14AM +0800, Herbert Xu wrote:
>
> I'm thinking about the case where each remote end (or one remote
> end with many IP addresses) chooses to use a single SPI which then
> all gets hashed to the same bucket.
>
> Outbound SAs are hashed into the same SPI hash table as inbound SAs.
Another solution would be to create a hash table for inbound SAs
only. Unfortunately I don't think we have anything in our current
user-interface to indicate whether an SA is inbound or outbound.
So to do this you'll need to use a heuristic such as doing a
lookup on the source/destination address at insertion time.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [net-next-2.6 PATCH] net: netif_set_real_num_rx_queues may cap num_rx_queues at init time
From: Eric Dumazet @ 2010-10-05 5:35 UTC (permalink / raw)
To: John Fastabend; +Cc: bhutchings, netdev, therbert
In-Reply-To: <20101004220042.3471.92774.stgit@jf-dev1-dcblab>
Le lundi 04 octobre 2010 à 15:00 -0700, John Fastabend a écrit :
> The logic for netif_set_real_num_rx_queues is the following,
>
> netif_set_real_num_rx_queues(dev, rxq)
> {
> ...
> if (dev->reg_state == NETREG_REGISTERED) {
> ...
> } else {
> dev->num_rx_queues = rxq;
> }
>
> dev->real_num_rx_queues = rxq;
> return 0;
> }
>
> Some drivers init path looks like the following,
>
> alloc_etherdev_mq(priv_sz, max_num_queues_ever);
> ...
> netif_set_real_num_rx_queues(dev, queues_to_use_now);
> ...
> register_netdev(dev);
> ...
>
> Because netif_set_real_num_rx_queues sets num_rx_queues if the
> reg state is not NETREG_REGISTERED we end up with the incorrect
> max number of rx queues. This patch proposes to remove the else
> clause above so this does not occur. Also just reading the
> function set_real_num it seems a bit unexpected that num_rx_queues
> gets set.
>
You dont tell why its "incorrect".
Why should we keep num_rx_queues > real_num_rx_queues ?
It creates /sys files, and Qdisc stuff for nothing...
> CC: Ben Hutchings <bhutchings@solarflare.com>
>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> ---
>
> net/core/dev.c | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index a313bab..f78d996 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -1592,8 +1592,6 @@ int netif_set_real_num_rx_queues(struct net_device *dev, unsigned int rxq)
> rxq);
> if (rc)
> return rc;
> - } else {
> - dev->num_rx_queues = rxq;
> }
>
> dev->real_num_rx_queues = rxq;
>
> --
^ 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