[PATCH] qed: Fix potential use-after-free in qed_spq_post()

From: Roland Dreier <rol...@purestorage.com> We need to check if p_ent->comp_mode is QED_SPQ_MODE_EBLOCK before calling qed_spq_add_entry(). The test is fine is the mode is EBLOCK, but if it isn't then qed_spq_add_entry() might kfree(p_ent). Signed-off-by: Roland Dreier <rol...@pur

Re: [PATCH] PCI: Update ACS quirk for more Intel 10G NICs

> I think the conclusion is that a hard-wired ACS capability is a > positive indication of isolation for a multifunction device, the code > is intended to support this and appears to do so, and Roland was going > to investigate the sightings that inspired this patch in more detail. > Dropping for

Re: [PATCH] PCI: Update ACS quirk for more Intel 10G NICs

> Is there a misunderstanding of the code flow here? We're never setting > EC. In the first code block we're just masking out requested > capabilities where unimplemented capabilities is the same as > implemented + enabled. We're not adding EC to the request, we're > just not removing it based

Re: [PATCH] PCI: Update ACS quirk for more Intel 10G NICs

> I think that the device implementing ACS and not implementing certain > features that are "must be implemented if..." is a positive indication > that the device does not have that behavior and therefore the ability > to control that behavior is unnecessary. pci_acs_flags_enabled() is > coded

Re: [PATCH] PCI: Update ACS quirk for more Intel 10G NICs

On Thu, Jul 20, 2017 at 3:15 PM, Alex Williamson wrote: > Most of the ACS capabilities are worded as "Must be implemented by > devices that implement ..." Shouldn't a hard-wired ACS capability > sufficiently describe that, or is there something wrong with how >

[PATCH] PCI: Update ACS quirk for more Intel 10G NICs

From: Roland Dreier <rol...@purestorage.com> Add one more variant of the 82599 plus the device IDs for X540 and X550 variants. Intel has confirmed that none of these devices does peer-to-peer between functions. The X540 and X550 have added ACS capabilities in their PCI config space, but t

Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

On Fri, Jul 8, 2016 at 9:51 AM, Jason Gunthorpe wrote: > So, it appears, the dst and neigh can be used for all performances cases. > > For the non performance dst == null case, can we just burn cycles and > stuff the daddr in front of the packet at hardheader

Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

On Thu, Jul 7, 2016 at 4:14 PM, Jason Gunthorpe wrote: > We have neighbour_priv, and ndo_neigh_construct/destruct now .. > > A first blush that would seem to be enough to let ipoib store the AH > and other path information in the neigh and avoid the cb? At least

Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

>> struct skb_gso_cb { >> int mac_offset; >> int encap_level; >> __u16 csum_start; >> }; > This is based on an out-dated version of this struct. The 4.7 RC > kernel has a few more fields that were added to support local checksum > offload for encapsulated

Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

On Thu, Jan 7, 2016 at 3:00 AM, Konstantin Khlebnikov wrote: > Or just shift GSO CB and add couple checks like > BUILD_BUG_ON(sizeof(SKB_GSO_CB(skb)->room) < sizeof(*IPCB(skb))); Resurrecting this old thread, because the patch that ultimately went upstream (commit 9207f9d45b0a

[PATCH 3.19 and earlier] fib_rules: Fix dump_rules() not to exit early

From: Roland Dreier <rol...@purestorage.com> Backports of 41fc014332d9 ("fib_rules: fix fib rule dumps across multiple skbs") introduced a regression in "ip rule show" - it ends up dumping the first rule over and over and never exiting, because 3.19 and earlier are m

Re: [PATCH net] fib_rules: fix fib rule dumps across multiple skbs

On Tue, Sep 22, 2015 at 9:40 PM, Roopa Prabhu wrote: > + err = fib_nl_fill_rule(skb, rule, NETLINK_CB(cb->skb).portid, > + cb->nlh->nlmsg_seq, RTM_NEWRULE, > + NLM_F_MULTI, ops); > +

Re: [ofa-general] [PATCH 2.6.25] RDMA/cxgb3: Shift calculation wrong for single sge entries.

Thanks, applied, although I assume based on the Signed-off-by line that you left out a From: Bryan Rosenburg [EMAIL PROTECTED] at the top (to get the authorship in git correctly). RDMA/cxgb3: Shift calculation wrong for single sge entries. BTW, there's no need to duplicate the subject line

[PATCH RESEND] libertas: Remove unused exports

and there were no problems with undefined symbols. Signed-off-by: Roland Dreier [EMAIL PROTECTED] --- diff --git a/drivers/net/wireless/libertas/cmd.c b/drivers/net/wireless/libertas/cmd.c index eab0203..b3c1acb 100644 --- a/drivers/net/wireless/libertas/cmd.c +++ b/drivers/net/wireless/libertas/cmd.c

Re: [ofa-general] [PATCH 2.6.25] RDMA/cxgb3: Fail loopbackconnections.

how can a static void function return 0? good question... I've fixed the patch in my tree. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [ofa-general] [PATCH 2.6.25] RDMA/cxgb3: Fail loopbackconnections.

loopback connections The cxgb3 HW and driver don't support loopback RDMA connections. So fail any connection attempt where the destination address is local. Signed-off-by: Steve Wise [EMAIL PROTECTED] Signed-off-by: Roland Dreier [EMAIL PROTECTED] diff --git a/drivers

[PATCH] libertas: Remove unused exports

, so this is not run-tested, but I tested the build with CONFIG_LIBERTAS=y CONFIG_LIBERTAS_USB=m CONFIG_LIBERTAS_CS=m CONFIG_LIBERTAS_SDIO=m and there were no problems with undefined symbols. Signed-off-by: Roland Dreier [EMAIL PROTECTED] --- Here's the patch that removes the unused

Re: [ofa-general] [PATCH 2.6.25] RDMA/cxgb3: Fail loopback connections.

applied, although: +static void is_loopback_dst(struct iw_cm_id *cm_id) +{ +struct net_device *dev; + +dev = ip_dev_find(init_net, cm_id-remote_addr.sin_addr.s_addr); +if (!dev) +return 0; +dev_put(dev); +return 1; +} is there any way this

Re: [PATCH] mlx4: needs vmalloc.h for vmap()

thanks, just merged the same patch from Olof Johansson. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

[PATCH] libertas: Don't mark exported symbols as static

conflict Therefore, remove the static marking on lbs_remove_mesh and lbs_add_mesh. Signed-off-by: Roland Dreier [EMAIL PROTECTED] --- diff --git a/drivers/net/wireless/libertas/main.c b/drivers/net/wireless/libertas/main.c index 84fb49c..a688ce8 100644 --- a/drivers/net/wireless/libertas/main.c

Re: [PATCH] libertas: Don't mark exported symbols as static

Why not pull the exports? they aren't used anywhere in the existing kernel. I'm guessing there's some not-(yet-)merged mesh networking stuff that uses the symbols, but it doesn't matter much to me... - R. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a

Re: [PATCH] [1/2] Skip empty hash buckets faster in /proc/net/tcp

On a 2GB Core2 system here I see a time cat /proc/net/tcp /dev/null constently dropping from 0.44s to 0.4-0.8s system time with this change. Seems like there must be a typo in either the before or after times you report here? -- To unsubscribe from this list: send the line unsubscribe netdev

[PATCH] cxgb3: Remove incorrect __devinit annotations

that it calls, which fixes WARNING: drivers/net/cxgb3/built-in.o(.text+0x2427): Section mismatch in reference from the function t3_io_slot_reset() to the function .devinit.text:t3_prep_adapter() Signed-off-by: Roland Dreier [EMAIL PROTECTED] --- drivers/net/cxgb3/mc5.c |2 +- drivers/net

Re: [PATCH 2.6.25] RDMA/cxgb3: Fix the T3A workaround checks.

thanks, applied. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESEND 3/3] RDMA/cxgb3: Mark qp as privileged based on user capabilities.

thanks, applied 1-3 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

[RFC PATCH] IPoIB: improve IPv4/IPv6 to IB mcast mapping functions

-off-by: Roland Dreier [EMAIL PROTECTED] --- drivers/infiniband/core/cma.c |4 +--- drivers/infiniband/ulp/ipoib/ipoib_multicast.c |4 include/net/if_inet6.h | 11 +++ include/net/ip.h | 10

Bogus commit 70eba18b (make bnx2x select ZLIB_INFLATE)?

Commit 70eba18b (make bnx2x select ZLIB_INFLATE) in Linus's tree seems bogus. As far as I can tell, bnx2x is not upstream yet, and the commit in question actually adds select ZLIB_INFLATE to the TEHUTI config, since there is no BNX2X config option (and also I don't see any reference to zlib in

Re: [PATCH]: fix lro_gen_skb() alignment

- skb = netdev_alloc_skb(lro_mgr-dev, hlen); + skb = netdev_alloc_skb(lro_mgr-dev, hlen + NET_IP_ALIGN); NET_IP_ALIGN should only be used if you're DMAing into the skb head. Otherwise you should say 2. It would be nice to have another macro for that I suppose. It

Re: [PATCH 2.6.25 2/2] RDMA/cxgb3: Support 5.0 firmware.

OK, applied 1 and 2... Note: this change requires 5.0 firmware. I assume the change to the cxgb3 FW versions is pending in a net driver change for 2.6.25? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at

Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.

Agreed. On first glance, I was intrigued but: 1) Why is everyone so concerned that export symbol space is large? - does it cost cpu or running memory? - does it cause bugs? - or are you just worried about evil modules? 2) These aren't real namespaces - all

Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.

This patch allows to export symbols only for specific modules by introducing symbol name spaces. A module name space has a white list of modules that are allowed to import symbols for it; all others can't use the symbols. It adds two new macros:

Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.

Yes, and if a symbol is already used by multiple modules, it's generically useful. And if so, why restrict it to in-tree modules? I agree that we shouldn't make things too hard for out-of-tree modules, but I disagree with your first statement: there clearly is a large class of symbols that

Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.

I agree that we shouldn't make things too hard for out-of-tree modules, but I disagree with your first statement: there clearly is a large class of symbols that are used by multiple modules but which are not generically useful -- they are only useful by a certain small class of

Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.

Except C doesn't have namespaces and this mechanism doesn't create them. So this is just complete and utter makework; as I said before, noone's going to confuse all those udp_* functions if they're not in the udp namespace. I don't understand why you're so opposed to organizing the

Re: [PATCH 2.6.24] RDMA/cxgb3: Set the max_qp_init_rd_atom attribute.

thanks, applied. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 10/14 v2] nes: eeprom and phy routines

+/* TODO: deal with EEPROM endian issues */ This is pretty scary. Is the driver broken on big-endian systems now? +/* +Everything you wanted to know about CRC algorithms, but were afraid to ask + for fear that errors in your understanding might be detected. Version : 3. etc

Re: [PATCH 11/14 v2] nes: OpenFabrics kernel verbs

+/** + * nes_post_send + */ +static int nes_post_send(struct ib_qp *ibqp, struct ib_send_wr *ib_wr, +struct ib_send_wr **bad_wr) ... +switch (ib_wr-opcode) { ... +if (ib_wr-num_sge

Re: [PATCH 1/14 v2] nes: module and device initialization

Thanks Roland. Let me know when you have your branch ready. OK, I pushed out a neteffect branch at git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git This has the driver from your git tree plus some compile fixes and cleanups (added as separate commits, so you can see

Re: [PATCH 1/14 v2] nes: module and device initialization

OK, a couple quick review comments and a process comment too: - First step in the driver is to kill off a lot of the #ifdefs: +#ifdef IRQF_SHARED The upstream driver really shouldn't have compatibility gunk for older kernels... just make it build against the kernel it's in. +#ifdef

Re: [ofa-general] [PATCH 14/14 v2] nes: kernel build infrastructure

+ +EXTRA_CFLAGS += -DNES_MINICM I don't see anyplace NES_MINICM is used. Delete this line? + +obj-$(CONFIG_INFINIBAND_NES) += iw_nes.o + +iw_nes-objs := nes.o nes_hw.o nes_nic.o nes_utils.o nes_verbs.o nes_cm.o + Also the file has an extra blank line at the beginning and end.

Re: [PATCH 1/14 v2] nes: module and device initialization

Thanks... I am kind of overloaded trying to handle the last few things for the 2.6.24 merge window, but I will look at this next week, and I expect we should be able to merge the driver for 2.6.25 unless there are unexpected hangups. - To unsubscribe from this list: send the line unsubscribe

Re: [PATCH 2/14 v2] nes: device structures and defines

You are starting off on the wrong foot. ??? +if(!(expr)) { \ + printk(KERN_ERR PFX Assertion failed! %s, %s, %s, line %d\n, \ + #expr, __FILE__, __FUNCTION__,

Re: [PATCH 5/8] [MV643XX_ETH] Remove SHARED_REGS register address bias

+static void __iomem *mv643xx_eth_base; +return readl(((void __iomem *)mv643xx_eth_base) + offset); Given the declaration of mv643xx_eth_base as void __iomem * already, I don't understand why you need the cast to the same type here (and elsewhere in the driver). - R. - To unsubscribe

Re: Bonding support for eth1394?

The bonding sources have a few occurrences of EOPNOTSUPP. Unless I missed something, they are all related to setting the hardware address of the interface. AFAICS this is impossible with IP over FireWire. If it is crucial to bonding to be able to change the slaves' hardware addresses,

Re: [PATCH] IB/ipoib: Bound the net device to the ipoib_neigh structue

It happens only when ib interfaces are slaves of a bonding device. I thought before that the stuck is in napi_disable() but it's almost right. I put prints before and after call to napi_disable and see that it is called twice. I'll try to investigate in this direction. ib0:

Re: [PATCH] IB/ipoib: Bound the net device to the ipoib_neigh structue

I also ran a test for the code in the branch of 2.6.24 and found a problem. I see that ifconfig down doesn't return (for IPoIB interfaces) and it's stuck in napi_disable() in the kernel (any idea why?) For what it's worth, I took the upstream 2.6.23 git tree and merged in Dave's latest

Re: [PATCH 2/3][NET_BATCH] net core use batching

I'd say we can probably try to get rid of it in 2.6.25, this is assuming we get driver authors to cooperate and do the conversions or alternatively some other motivated person. I can just threaten to do them all and that should get the driver maintainers going :-) I can definitely

Re: [PATCH 2/3][NET_BATCH] net core use batching

Before you add new entries to your list, how is that ibm driver NAPI conversion coming along? :-) I still haven't done much. OK, I will try to get my board booting again this week. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED]

Re: [PATCH 2/3][NET_BATCH] net core use batching

Before you add new entries to your list, how is that ibm driver NAPI conversion coming along? :-) OK, thanks for the kick in the pants, I have a couple of patches for net-2.6.24 coming (including an unrelated trivial warning fix for IPoIB). - R. - To unsubscribe from this list: send the

[PATCH 2/4] ibm_emac: Convert to use napi_struct independent of struct net_device

structures for a single net_device. Tested with the internal MAC of a PowerPC 440SPe SoC with an AMCC 'Yucca' evaluation board. Signed-off-by: Roland Dreier [EMAIL PROTECTED] --- drivers/net/ibm_emac/ibm_emac_mal.c | 48 -- drivers/net/ibm_emac/ibm_emac_mal.h

[PATCH 3/4] ibm_new_emac: Nuke SET_MODULE_OWNER() use

Signed-off-by: Roland Dreier [EMAIL PROTECTED] --- drivers/net/ibm_newemac/core.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c index ce127b9..8ea5009 100644 --- a/drivers/net/ibm_newemac/core.c +++ b

[PATCH 4/4] ibm_emac: Convert to use napi_struct independent of struct net_device

multiple NAPI structures for a single net_device. Compile-tested only as I don't have a system that uses the ibm_newemac driver. This conversion the conversion for the ibm_emac driver that was tested on real PowerPC 440SPe hardware. Signed-off-by: Roland Dreier [EMAIL PROTECTED] --- drivers/net

Re: [ofa-general] [PATCH 4/4] ibm_emac: Convert to use napi_struct independent of struct net_device

Sorry... wrong subject here; it should have been ibm_newemac: ... - R. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [ofa-general] InfiniBand/RDMA merge plans for 2.6.24

I tested this by simulating a slow passive side responder, and it worked as expected for those tests. Using an MRA does add another MAD to the CM exchange, which is why it is sent only after seeing a duplicate request. Alternatively, we can take the OFED module parameter patch.

Vague maybe ppp-related panic report for 2.6.23-rc9

I'm running 2.6.23-rc9 on my laptop, and when in a coffee shop I use a Verizon EVDO card to get network access. This is a kyocera device that looks like a serial adapter behind an ohci usb controller, and uses the airprime driver (for usb device 0c88:17da). The actual IP networking is ppp over

Re: Vague maybe ppp-related panic report for 2.6.23-rc9

I don't want to jump the gun on the analysis but it just might be the packet sharing fixes Herbert put in a short time ago. What you could do is go back to say rc2 and see if you still get the panics, then bisect from there to narrow it down. If rc2 still gives the panic, it's

Re: [PATCH] mac80211: Fix TX after monitor interface is converted to managed

Programming with assertions (and BUG_ON is a form of that) is generally a good practice. Almost any book or other source on good programming practices will agree. Yes, it can be overdone. But I don't really think that is the case here, since the check is relatively inexpensive and the

Re: Vague maybe ppp-related panic report for 2.6.23-rc9

Just as a quick update -- I seem to only be able to reproduce this crash when my ppp session drops, which seems associated with marginal signal. And unfortunately I have great coverage at home so I haven't been able to reproduce this again today. Maybe on the train tomorrow I can crash my

Re: [ofa-general] InfiniBand/RDMA merge plans for 2.6.24

OK -- just to make sure I'm understanding what you're saying: have you confirmed that your proposed [CM MRA] patches actually fix the issue? Not directly. I cannot easily test kernel patches on our larger, production clusters. We've seen the issue with specific applications on 512 and

Re: tcp bw in 2.6

It would be really great to see numbers with a more recent kernel than 2.6.18 FWIW Debian has binaries for 2.6.21 in testing and for 2.6.22 in unstable so it should be very easy for Larry to try at least those. - R. - To unsubscribe from this list: send the line unsubscribe netdev in the

[PATCH] IPoIB: Convert to netdevice internal stats

Use the stats member of struct netdevice in IPoIB, so we can save memory by deleting the stats member of struct ipoib_dev_priv, and save code by deleting ipoib_get_stats(). Signed-off-by: Roland Dreier [EMAIL PROTECTED] --- Dave, can you queue this in net-2.6.24 please? I would ordinarily merge

Re: [PATCH] IPoIB: Convert to netdevice internal stats

How is that ibm_emac NAPI conversion coming along? :-) Sorry, trying to reduce my backlog first, but it is still on my list of things to work on :) - R. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at

Re: [PATCH V6 0/9] net/bonding: ADD IPoIB support for the bonding driver

Roland, are you comfortable with the IB changes in patches 1 and 2? Yes, they look fine to me. Feel free to apply, with Acked-by: Roland Dreier [EMAIL PROTECTED] - R. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More

Re: [ofa-general] Re: [PATCH V5 2/11] IB/ipoib: Notify the world before doing unregister

The action in bonding to a detach of slave is to unregister the master (see patch 10). This can't be done from the context of unregister_netdevice itself (it is protected by rtnl_lock). I'm confused. Your patch has: +ipoib_slave_detach(cpriv-dev);

Re: [PATCH 1/2] bnx2: factor out gzip unpacker

Just change the makefiles to always install gzip'ed modules modutils knows how to unzip them on the fly. But that leaves the uncompressed firmware blobs in .data that ends up in unswappable kernel memory. - R. - To unsubscribe from this list: send the line unsubscribe netdev in the body of

Re: [PATCH V5 2/11] IB/ipoib: Notify the world before doing unregister

+ipoib_slave_detach(cpriv-dev); unregister_netdev(cpriv-dev); Maybe you already answered this before, but I'm still not clear why this notifier call can't just be added to the start of unregister_netdevice(), so we can avoid having driver needing to know anything

Re: [PATCH] RDMA/CMA: Use neigh_event_send() to initiate neighbour discovery.

Roland - can you please queue this up for 2.6.24? Done, thanks. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: new NAPI interface broken

One other thing I observed is that I can not unload the module as the ref counter of the eth device is too low. I haven't tracked down the source of this problem yet. I suspect that this is because netif_rx_reschedule() was missing a dev_hold() to match the dev_put() in

Re: [ofa-general] [PATCH] RDMA/CMA: Implement rdma_resolve_ip retry enhancement.

Thanks for the patch... If an application is calling rdma_resolve_ip() and a status of -ENODATA is returned from addr_resolve_local/remote(), the timeout mechanism waits until the application's timeout occurs before rechecking the address resolution status; the application will wait

Re: [ofa-general] Re: [PATCH 02/11] IB/ipoib: Notify the world before doing unregister

I think that if there are no other comments, I will submit the entire 11 patches again (with changes) to make it easier to merge into the kernel. Since the most of the content in the patch series is in bonding I thought it would be right that Jay will push all the patches to

Re: [PATCH 1/2] IPoIB: Fix unregister_netdev hang

Thanks for testing on ehca... While using IPoIB over EHCA (rc6 bits), unregister_netdev hangs with I don't think you're actually using rc6 bits, since in your patch you have: -poll_more: and I think that is only in Dave's net-2.6.24 tree now, right? The problem is that the poll handler

Re: InfiniBand/RDMA merge plans for 2.6.24

Roland, could you merge the common TX CQ patch please? It actually fixes a real problem. Yes, I will, but it collides with the net-2.6.24 NAPI rework I think, so it may not go in until a few days after the merge window. Have you verified that the patch cures the interrupt overload issues? -

Re: [ofa-general] Re: [PATCH 02/11] IB/ipoib: Notify the world before doing unregister

Maybe this new notification function should be in net/core/dev.c instead of exporting call_netdevice_notifiers()? Or actually, does it work to add the call to the notifiers directly in unregister_netdev() so that device drivers don't have to worry about it? (And is the existing patch missing

[PATCH net-2.6.24] Fix documentation for dev_put()/dev_hold()

It looks like the comments for dev_put() and dev_hold() got reversed somehow. Signed-off-by: Roland Dreier [EMAIL PROTECTED] --- include/linux/netdevice.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h index

[PATCH net-2.6.24] Fix refcounting problem with netif_rx_reschedule()

by Krishna Kumar [EMAIL PROTECTED] with IPoIB waiting forever for netdev refcounts to become 0 during module unload. Signed-off-by: Roland Dreier [EMAIL PROTECTED] --- Dave, feel free to roll this up into earlier NAPI conversion patches (assuming I'm understanding things correctly and this patch

Re: [PATCH net-2.6.24] Fix refcounting problem with netif_rx_reschedule()

Further complicating things is that you need to setup a ppc32 cross-build environment to even build test a conversion, and I'm not comfortable doing the surgery until I can test build the thing. OK, I actually have a system with a ppc 440 SoC that uses this driver, so I'll try to get things

Re: [PATCH 1/2] IPoIB: Fix unregister_netdev hang

and I think that is only in Dave's net-2.6.24 tree now, right? Nope, that was what I downloaded yesterday: VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 23 EXTRAVERSION =-rc6 NAME = Pink Farting Weasel Please double check your tree. I just very carefully looked at my trees, and the

Re: InfiniBand/RDMA merge plans for 2.6.24

IPoIB CM handles this properly by gathering together single pages in skbs' fragment lists. Then can we reuse IPoIB CM code here? Yes, if possible, refactoring things so that the rx skb allocation code becomes common between CM and non-CM would definitely make sense. - To unsubscribe from

Re: [ofa-general] InfiniBand/RDMA merge plans for 2.6.24

The IGMP enabling patch posted by me on September 2nd isn't on your list http://lists.openfabrics.org/pipermail/general/2007-September/040250.html can you add it? Yes, I lost that somehow. I will add it to my list of things to take a look at (no opinion yet). - R. - To unsubscribe from

Re: [PATCH 01/11] IB/ipoib: Export call to call_netdevice_notifiers and add new private flag

I tried to look at the ipoib stuff in this series... this patch looks fine but it doesn't actually touch ipoib, so the subject line is a bit misleading... - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at

Re: [PATCH 04/11] IB/ipoib: Verify address handle validity on send

Looks fine overall, with one minor nitpick: -if (unlikely(memcmp(neigh-dgid.raw, +if (unlikely((memcmp(neigh-dgid.raw, skb-dst-neighbour-ha + 4, -sizeof(union

Re: [PATCH 02/11] IB/ipoib: Notify the world before doing unregister

Actually, thinking about this some more... would it be cleaner to more the knowledge about bonding out of the ipoib driver? in other words, export something similar to +static int ipoib_slave_detach(struct net_device *dev) +{ +int ret = 0; +if (dev-flags IFF_SLAVE) { +

Re: [PATCH 02/11] IB/ipoib: Notify the world before doing unregister

OK with me. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 03/11] IB/ipoib: Bound the net device to the ipoib_neigh structue

Overall idea looks good... one comment: +if (n-dev-flags IFF_MASTER) { +/* n-dev is not an IPoIB device and we have +to take priv from elsewhere */ +neigh = *to_ipoib_neigh(n); +if (neigh) { +priv =

Re: [PATCH 02/11] IB/ipoib: Notify the world before doing unregister

Conceptually, I see your point and I'm ok with doing it either way. My only question is, would this change would make the ipoib module dependent upon having the bonding module loaded (to resolve all of the symbols)? Yes, I guess so, if that function is in bonding. Hmm, that

Re: [PATCH v2] iw_cxgb3: Support iwarp-only interfaces to avoid 4-tuple conflicts.

Maybe you should automatically create an alias each time new interface is added so that admin would not care about proper aliases? I agree that makes much more sense from a user interface point of view. Unfortunately an alias without an address doesn't make sense, so there doesn't seem to be

Re: InfiniBand/RDMA merge plans for 2.6.24

The patch is just needed to pick up broadcast MTU size instead of hard coding 2K right now. SKB allocation shouldn't be different with Ethernet Jambo Frame and IPoIB-CM which 64K MTU. I don't understand why it's different. Could you please explain this? It's exactly the same problem as

Re: [ofa-general] InfiniBand/RDMA merge plans for 2.6.24

I've been meaning to track down the bnx2 iscsi offload patch to look and see if this issue is addressed, since the same problem seems to exist: it seems an iscsi connection and a main stack tcp connection might share the same 4-tuple unless something is done to avoid that happening.

InfiniBand/RDMA merge plans for 2.6.24

IB/mthca: Enable MSI-X by default Peter Oruba (1): IB/mthca: Use PCI-X/PCI-Express read control interfaces Roland Dreier (6): IPoIB: Make sure no receives are handled when stopping device IB: find_first_zero_bit() takes unsigned pointer mlx4_core: Don't free special

Re: InfiniBand/RDMA merge plans for 2.6.24

Since ehca can support 4K MTU, we would like to see a patch in IPoIB to allow link MTU to be up to 4K instead of current 2K for 2.6.24 kernel. The idea is IPoIB link MTU will pick up a return value from SM's default broadcast MTU. This patch should be a small patch, I hope you

Re: [ofa-general] InfiniBand/RDMA merge plans for 2.6.24

- My user_mad P_Key index support patch. I'll test the ioctl to change to the new mode and merge this I guess, since Hal and Sean have tested this out. I can give this patch a reviewed-by: too, and I will also try to review a couple of the pending ipoib patches. Thanks!

Re: [ofa-general] InfiniBand/RDMA merge plans for 2.6.24

I was about to post v2 of my patch to avoid port space collisions with the native stack. Can we get that 2.6.24? It is high priority IMO. I've tried to solicit review on it, but I think folks are reluctant... ;-) I would like to get this in, but I'm still at least a little reluctant,

Re: [ofa-general] InfiniBand/RDMA merge plans for 2.6.24

Well, if it involves /sharing/ port space with the native stack, i.e. where port 1234 is IB but 1235 is Linux, pretty much all the networking devs have NAK'd that approach AFAICS. Just to be clear, InfiniBand has no problem; the issue is port collisions involving iWARP connections. - R. -

Re: [PATCH RFC] iw_cxgb3: Support iwarp-only interfaces to avoid 4-tuple conflicts with the host stack.

What's wrong with my suggestion of having the iwarp driver create an iwX interface to go with the normal ethX interface? It seems simpler to me, and there's a somewhat similar precedent with how mac80211 devices create both wlan0 and wmaster0 interfaces. - R. It seemed much

Re: [PATCH RFC] iw_cxgb3: Support iwarp-only interfaces to avoid 4-tuple conflicts with the host stack.

The sysadmin creates for iwarp use only alias interfaces of the form devname:iw* where devname is the native interface name (eg eth0) for the iwarp netdev device. The alias label can be anything starting with iw. The iw immediately after the ':' is the key used by the iwarp driver.

Re: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCP ports from the host TCP port space.

Sorry for the long latency, I was at the beach all last week. And direct data placement really does give you a factor of two at least, because otherwise you're stuck receiving the data in one buffer, looking at some of the data at least, and then figuring out where to copy it. And

Re: [PATCH 2.6.23 RESEND] cxgb3 - Fix dev-priv usage

I take that back. Rejected -- it breaks infiniband build. To be more precise: drivers/infiniband/hw/cxgb3/cxio_hal.c: In function 'cxio_rdev_open': drivers/infiniband/hw/cxgb3/cxio_hal.c:919: error: implicit declaration of function 'T3CDEV' it seems the problem is that T3CDEV() has

Re: [PATCH 2.6.23 0/2] cxgb3 - Fix dev-priv usage

Looks OK to me but I would just roll up the second patch into the first patch and let Jeff merge it as one commit. There's no point in creating an intermediate tree that doesn't build -- it just breaks git bisect for no useful purpose. Also as a side note, when trying to test this I got the

Re: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCP ports from the host TCP port space.

[TSO / LRO discussion snipped -- it's not the main point so no sense spending energy arguing about it] Just be realistic and accept that RDMA is a point in time solution, and like any other such technology takes flexibility away from users. Horizontal scaling of cpus up to huge arity

Re: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCP ports from the host TCP port space.

Isn't RDMA _part_ of the software net stack within Linux? It very much is not so. This is just nit-picking. You can draw the boundary of the software net stack wherever you want, but I think Sean's point was just that RDMA drivers already are part of Linux, and we all want them to get

  1   2   3   >