* Re: [PATCH 2/3] net/rfkill/core.c: Avoid leaving freed data in a list
From: Johannes Berg @ 2011-05-13 13:55 UTC (permalink / raw)
To: Julia Lawall
Cc: kernel-janitors, John W. Linville, David S. Miller,
linux-wireless, netdev, linux-kernel
In-Reply-To: <1305294731-12127-2-git-send-email-julia@diku.dk>
On Fri, 2011-05-13 at 15:52 +0200, Julia Lawall wrote:
> The list_for_each_entry loop can fail, in which case the list element is
> not removed from the list rfkill_fds. Since this list is not accessed by
> the loop, the addition of &data->list into the list is just moved after the
> loop.
>
> The sematic match that finds this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @@
> expression E,E1,E2;
> identifier l;
> @@
>
> *list_add(&E->l,E1);
> ... when != E1
> when != list_del(&E->l)
> when != list_del_init(&E->l)
> when != E = E2
> *kfree(E);// </smpl>
>
> Signed-off-by: Julia Lawall <julia@diku.dk>
>
> ---
> I have only verified that rfkill_fds is not accessed by the loop by
> inspecting the code. If this analysis is not correct, the other solution
> would be to leave the list_add where it is and delete the element from the
> list explicitly.
Looks right to me, thanks!
johannes
^ permalink raw reply
* [PATCH] drivers/isdn/hisax: Drop unused list
From: Julia Lawall @ 2011-05-13 14:15 UTC (permalink / raw)
To: Karsten Keil; +Cc: kernel-janitors, netdev, linux-kernel
The file st5481_init.c locally defines and initializes the adapter_list
variable, but does not use it for anything. Removing the list makes it
possible to remove the list field from the st5481_adapter data structure.
In the function probe_st5481, it also makes it possible to free the locally
allocated adapter value on an error exit.
Signed-off-by: Julia Lawall <julia@diku.dk>
---
drivers/isdn/hisax/st5481.h | 1 -
drivers/isdn/hisax/st5481_init.c | 6 +-----
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/isdn/hisax/st5481.h b/drivers/isdn/hisax/st5481.h
index 64f78a8..b9054cb 100644
--- a/drivers/isdn/hisax/st5481.h
+++ b/drivers/isdn/hisax/st5481.h
@@ -377,7 +377,6 @@ struct st5481_bcs {
};
struct st5481_adapter {
- struct list_head list;
int number_of_leds;
struct usb_device *usb_dev;
struct hisax_d_if hisax_d_if;
diff --git a/drivers/isdn/hisax/st5481_init.c b/drivers/isdn/hisax/st5481_init.c
index 1375123..9f7fd18 100644
--- a/drivers/isdn/hisax/st5481_init.c
+++ b/drivers/isdn/hisax/st5481_init.c
@@ -46,8 +46,6 @@ module_param(debug, int, 0);
#endif
int st5481_debug;
-static LIST_HEAD(adapter_list);
-
/* ======================================================================
* registration/deregistration with the USB layer
*/
@@ -86,7 +84,6 @@ static int probe_st5481(struct usb_interface *intf,
adapter->bcs[i].b_if.ifc.priv = &adapter->bcs[i];
adapter->bcs[i].b_if.ifc.l2l1 = st5481_b_l2l1;
}
- list_add(&adapter->list, &adapter_list);
retval = st5481_setup_usb(adapter);
if (retval < 0)
@@ -125,6 +122,7 @@ static int probe_st5481(struct usb_interface *intf,
err_usb:
st5481_release_usb(adapter);
err:
+ kfree(adapter);
return -EIO;
}
@@ -142,8 +140,6 @@ static void disconnect_st5481(struct usb_interface *intf)
if (!adapter)
return;
- list_del(&adapter->list);
-
st5481_stop(adapter);
st5481_release_b(&adapter->bcs[1]);
st5481_release_b(&adapter->bcs[0]);
^ permalink raw reply related
* [PATCH] ethtool: FLOW_EXT may confuse drivers
From: Sebastian.Poehn @ 2011-05-13 14:19 UTC (permalink / raw)
To: netdev
The FLOW_EXT bit must be masked out. Otherwise if e.g. vlan is set a driver receiving the ntuple may not detect the flow_type correctly!
Signed-off-by: Sebastian Poehn <sebastian.poehn@belden.com>
diff --git a/ethtool.c b/ethtool.c
index 34fe107..0b7ec05 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -3134,6 +3134,9 @@ static int flow_spec_to_ntuple(struct ethtool_rx_flow_spec *fsp,
(u64)ntohl(~fsp->m_ext.data[1]);
}
}
+
+ /*Mask out the extended bit, because ntuple does not know it!*/
+ ntuple->flow_type &= ~FLOW_EXT;
return 0;
}
DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.
^ permalink raw reply related
* Re: question about UFO behavior for bridge device
From: Herbert Xu @ 2011-05-13 14:36 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Shan Wei, netdev
In-Reply-To: <1305292012.4065.441.camel@localhost>
On Fri, May 13, 2011 at 02:06:52PM +0100, Ben Hutchings wrote:
>
> > But, actually, i saw original big skb in eth0's tcpdump file, but not segmented skbs.
> > The behavior is right or what we want?
> > Is there anything missed about my analysis?
>
> I assume that packet capturing is handled earlier in the transmit path.
Yes it is. It's the same with TSO.
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: AAARGH bisection is hard (Re: [2.6.39 regression] X locks up hard right after logging in)
From: Andrew Lutomirski @ 2011-05-13 14:56 UTC (permalink / raw)
To: Christian Couder; +Cc: linux-kernel, netdev, git, Linus Torvalds, Shuang He
In-Reply-To: <BANLkTi=dL+KyQ3Bm58_Uj4LP9WSpbzAfJA@mail.gmail.com>
On Fri, May 13, 2011 at 9:38 AM, Andrew Lutomirski <luto@mit.edu> wrote:
> On Fri, May 13, 2011 at 4:20 AM, Christian Couder
> <christian.couder@gmail.com> wrote:
>> On Thu, May 12, 2011 at 7:15 PM, Andrew Lutomirski <luto@mit.edu> wrote:
>>>
>>> OK, this sucks. In the course of bisecting this, I've hit two other
>>> apparently unrelated bugs that prevent my from testing large numbers
>>> of kernels. Do I have two questions:
>>>
>>> 1. Anyone have any ideas from looking at the log?
>>>
>>> It looks like most of what's left is network code, so cc netdev.
>>>
>>> 2. The !&$#@ bisection is skipping all over the place. I've seen
>>> 2.6.37 versions and all manner of -rc's out of order. Linus, and
>>> other people who like pontificating about git bisection: is there any
>>> way to get the bisection to follow Linus' tree? I think that if
>>> bisect could be persuaded to consider only changes that are reached by
>>> following only the *first* merge parent all the way from the bad
>>> revision to the good revision, then the bisection would build versions
>>> that were at least good enough for Linus to pull and might have fewer
>>> bisection-killing bugs.
>>>
>>> (This isn't a new idea [1], and git rev-list --bisect --first-parent
>>> isn't so bad except that it doesn't bisect.)
>>
>> Did you forget to put the reference [1] in your email? Was it this one
>> you were thinking about:
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/165433/
>
> No, it was this:
>
> http://stackoverflow.com/questions/5638211/how-do-you-get-git-bisect-to-ignore-merged-branches
>
Sadly even that's not enough. I finished the bisection (by
standard-ish techniques but with a bit of overriding of git bisect's
choices and occasional merging of newer versions of -linus to get
something that would boot) and it pointed to a commit that wasn't the
culprit.
The problem is that 2.6.39-rc7 is bad, 2.6.38 (and 2.6.38.{5,6}) is
good, but 2.6.38-rc5 is bad and fails identically to 2.6.39-rc7. I
think that git bisect makes the assumption that ancestors of a good
commit are good, and that just isn't true for this bug.
So what I really want is a fancy version of git bisect that makes no
assumptions about the relationship of good and bad commits in the
graph and just finds me a commit that is bad but for which all parents
are good or vice versa.
I'm currently bisecting the other way to find the commit before 2.6.38
that fixed the bug, since there's presumably less churn there than in
the early bits of 2.6.39.
--Andy
^ permalink raw reply
* Re: [PATCH] ethtool: FLOW_EXT may confuse drivers
From: Ben Hutchings @ 2011-05-13 15:01 UTC (permalink / raw)
To: Sebastian.Poehn; +Cc: netdev
In-Reply-To: <OFDA6F039C.B25E3B43-ON8525788F.004EA678-8525788F.004EA67B@BeldenCDT.com>
Please send ethtool patches directly to me as well as to netdev.
On Fri, 2011-05-13 at 10:19 -0400, Sebastian.Poehn@Belden.com wrote:
> The FLOW_EXT bit must be masked out. Otherwise if e.g. vlan is set a
> driver receiving the ntuple may not detect the flow_type correctly!
>
> Signed-off-by: Sebastian Poehn <sebastian.poehn@belden.com>
>
> diff --git a/ethtool.c b/ethtool.c
> index 34fe107..0b7ec05 100644
> --- a/ethtool.c
> +++ b/ethtool.c
> @@ -3134,6 +3134,9 @@ static int flow_spec_to_ntuple(struct ethtool_rx_flow_spec *fsp,
> (u64)ntohl(~fsp->m_ext.data[1]);
> }
> }
> +
> + /*Mask out the extended bit, because ntuple does not know it!*/
> + ntuple->flow_type &= ~FLOW_EXT;
>
> return 0;
> }
>
> DISCLAIMER:
>
> Privileged and/or Confidential information may be contained in this
> message. If you are not the addressee of this message, you may not
> copy, use or deliver this message to anyone. In such event, you
> should destroy the message and kindly notify the sender by reply
> e-mail. It is understood that opinions or conclusions that do not
> relate to the official business of the company are neither given
> nor endorsed by the company.
I am not the addressee, so I won't apply this (even though it looks
right). Please get rid of this disclaimer on messages to public mailing
lists.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH 03/16] add driver for C64x+ ethernet driver
From: Ben Hutchings @ 2011-05-13 15:30 UTC (permalink / raw)
To: Mark Salter; +Cc: linux-kernel, netdev
In-Reply-To: <1305144843-5058-4-git-send-email-msalter@redhat.com>
Please send network drivers to netdev for review.
I haven't looked at this thoroughly, but I noticed a few things:
On Wed, 2011-05-11 at 16:13 -0400, Mark Salter wrote:
> From: Aurelien Jacquiot <a-jacquiot@ti.com>
>
> This patch adds a network driver to support the ethernet interface found on
> several Texas Instruments C64X+ based System on Chips. In particular, this
> driver has been tested on the TMS320C6455, TMS320C6457, TMS320C6472, and
> TMS320C6474 parts.
[...]
> --- /dev/null
> +++ b/drivers/net/c6x_gemac.c
[...]
> +static int __init get_mac_addr_from_cmdline(char *str)
> +{
> + const char *start = (const char *) str;
> + const char *end;
> + int count;
> +
> + for (count = 0; count < 6; count++) {
> + config.enetaddr[count] = _hex_strtoul(start, &end);
> + if (end == start)
> + return 0;
> + if ((*end != ':') && (count != 5))
> + return 0;
> + start = end + 1;
> + }
> + return 1;
> +}
> +
> +__setup("emac_addr=", get_mac_addr_from_cmdline);
> +
> +static int __init set_emac_shared(char *str)
> +{
> + emac_shared = 1;
> + return 1;
> +}
> +
> +__setup("emac_shared", set_emac_shared);
These parameters should be provided by platform data.
> +/*
> + * Get the device statistic
> + */
> +static struct net_device_stats *emac_get_stats(struct net_device *dev)
> +{
> + struct emac_private *ep = netdev_priv(dev);
> + unsigned int reg;
> + unsigned int dummy;
> + int i;
> +
> + emac_set_stat(dev->stats.multicast, EMAC_RXMCASTFRAMES);
> + emac_set_stat(dev->stats.collisions, EMAC_TXCOLLISION);
> + emac_set_stat(dev->stats.rx_length_errors, EMAC_RXOVERSIZED);
> + emac_set_stat(dev->stats.rx_length_errors, EMAC_RXUNDERSIZED);
> + emac_set_stat(dev->stats.rx_crc_errors, EMAC_RXCRCERRORS);
> + emac_set_stat(dev->stats.rx_frame_errors, EMAC_RXALIGNCODEERRORS);
> + emac_set_stat(dev->stats.tx_carrier_errors, EMAC_TXCARRIERSLOSS);
> + emac_set_stat(dev->stats.tx_fifo_errors, EMAC_TXUNDERRUN);
> + emac_set_stat(dev->stats.tx_window_errors, EMAC_TXLATECOLL);
> +
> + /* ACK statistic by write-to-decrement */
> + reg = EMAC_RXGOODFRAMES;
> + for (i = 0; i < EMAC_NUM_STATREGS; i++) {
> + dummy = emac_get_reg(reg);
> + emac_set_reg(reg, dummy);
> + reg += 4;
> + }
This looks wrong. Surely you should be decrementing stats by the values
that were read above, not the 'dummy' value read later.
> + return &dev->stats;
> +}
> +
> +/*
> + * Receive packets
> + */
> +static int emac_rx(struct net_device *dev, struct emac_desc *desc_ack)
> +{
[...]
> + /* Give back old sk_buff */
> + netif_rx(skb_old);
> + dev->last_rx = jiffies;
No need to set last_rx; the networking core does it.
> + /* Fill statistic */
> + dev->stats.rx_packets++;
> + dev->stats.rx_bytes += pkt_len;
> + } else {
> + printk(KERN_WARNING "%s: Memory squeeze, dropping packet.\n", dev->name);
Should be rate-limited or controlled by message-level (see netif_info()
and related macros in netdevice.h).
[...]
> +static int emac_start_xmit(struct sk_buff *skb, struct net_device *dev)
> +{
> + struct emac_private *ep = netdev_priv(dev);
> + volatile struct emac_desc *desc;
> + volatile struct emac_desc *prev_desc = NULL;
> + ushort pkt_len = skb->len;
> + unsigned long flags;
> +
> + if (ep->tx_full) {
> + printk(KERN_WARNING "%s: tx queue full\n", dev->name);
Definitely don't log this by default.
> + dev->stats.tx_dropped++;
No, the packet is not dropped in this case.
> + return NETDEV_TX_BUSY;
> + }
> +
> + /* Pad short frame */
> + if (unlikely(pkt_len < ETH_ZLEN)) {
> + if (skb_padto(skb, ETH_ZLEN)) {
> + netif_wake_queue(dev);
The queue is already awake!
And in this case you *are* dropping the packet, so you could increment
tx_dropped.
> + return NETDEV_TX_OK;
> + }
> + pkt_len = ETH_ZLEN;
> + }
[...]
> +static void emac_handle_host_interrupt(struct net_device *dev)
> +{
> + struct emac_private *ep = netdev_priv(dev);
> + unsigned long status;
> +
> + /* Handle host error */
> + status = emac_get_reg(EMAC_MACSTATUS);
> +
> + /* Check if the problem occurs on our channel when we are slave */
> + if ((ep->slave)
> + && (((status & EMAC_M_RXERRCH) >> EMAC_S_RXERRCH) != IDX_TO_CHAN(emac_idx))
> + && (((status & EMAC_M_TXERRCH) >> EMAC_S_TXERRCH) != IDX_TO_CHAN(emac_idx)))
> + return;
> +
> + if ((status & EMAC_M_RXERRCODE) == (EMAC_V_OWNERSHIP << EMAC_S_RXERRCODE)) {
> + printk(KERN_ERR "%s: EMAC rx ring full\n", dev->name);
Should be rate-limited or controlled by message-level.
> + dev->stats.rx_fifo_errors++;
> + } else
> + printk(KERN_ERR "%s: EMAC fatal host error 0x%lx\n",
> + dev->name, status);
> +
> + DPRINTK(KERN_ERR "%s: Error head=%p desc=%p dirty=%p skb_tx_dirty=%ld count=%ld\n",
> + dev->name, ep->head_tx, ep->cur_tx,
> + ep->dirty_tx, ep->skb_tx_dirty, ep->count_tx);
> +
> + if (!ep->slave) {
> + /* Reconfigure the device */
> + ep->fatal_error = 1;
> + emac_reconfigure_device(dev);
> + }
> +}
[...]
> +#ifdef EMAC_HAS_ALE_SUPPORT
[...]
> +static void emac_set_rx_mode(struct net_device *dev)
[...]
> + /* Set mcast from a list */
> + for (i = 0; i < dev->mc_count; i++, dmi = dmi->next) {
> + u8 *p_dmi = dmi->dmi_addr;
This is the old multicast list format; the code won't even compile now.
It needs to be updated like the !EMAC_HAS_ALE_SUPPORT version has been.
[...]
> +#ifdef EMAC_TIMER_TICK_MDIO
> +/*
> + * This function should be called for each device in the system on a
> + * periodic basis of 100mS (10 times a second). It is used to check the
> + * status of the EMAC and MDIO device.
> + */
> +static void emac_timer_tick(unsigned long data)
That seems excessive! It might be worth checking whether this takes
significant CPU time, and increasing the period when all links are in a
steady state.
[...]
> +static const struct ethtool_ops gemac_ethtool_ops = {
> +};
We (that is, netdev regulars) should make more of the default ethtool
operations work without dev->ethtool_ops set, so you don't have to do
this!
[...]
> +#ifdef EMAC_ARCH_HAS_MAC_ADDR
> + /* SoC or board hw has MAC address */
> + if (config.enetaddr[0] == 0 && config.enetaddr[1] == 0 &&
> + config.enetaddr[2] == 0 && config.enetaddr[3] == 0 &&
> + config.enetaddr[4] == 0 && config.enetaddr[5] == 0) {
[...]
is_zero_ether_addr(config.enetaddr)
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* dl2k/stmmac patches (was Re: [PATCH 2/2] net/dl2k: Don't reconfigure link @100Mbps when disabling autoneg @1Gbps)
From: David Decotigny @ 2011-05-13 15:54 UTC (permalink / raw)
To: netdev
Cc: Florian Weimer, Giuseppe Cavallaro, David S. Miller, Joe Perches,
Stanislaw Gruszka, linux-kernel
In-Reply-To: <82y62dk1qz.fsf@mid.bfk.de>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
An update on the patch series I posted earlier (dl2k/stmmac autoneg
minor changes: see my posts on 05/09/11 17:19 PST)...
I'd suggest dropping the patch concerning dl2k, as I don't have any way
to claim it's any good at all (though I'm pretty confident it doesn't
make things any worse).
However, for the other patch of the same series (stmmac), please
consider for inclusion the new version prepared by Giuseppe instead of
my initial patch, for his version readily integrates my patch and has
been tested on real hardware:
stmmac: don't go through ethtool to start auto-negotiation
stmmac: fix autoneg in set_pauseparam
Regards,
Thank you!
On 05/11/11 02:47, Florian Weimer wrote:
> * David Decotigny:
>
>> Tested: module compiling, NOT tested on real hardware.
>
> To my knowledge, dl2k is broken. Some sort of synchronization
> primitives are missing. Under load, the NIC's notion of ring buffer
> status diverges from the host's view. 8-(
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk3NVCYACgkQld7vhusVrCHUEACggeKyCmoEHy9AzYec/aW8cDjU
GyAAoIiESxUAFWuKBmCOA31X/V0fvC+Y
=6hXY
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: AAARGH bisection is hard (Re: [2.6.39 regression] X locks up hard right after logging in)
From: Linus Torvalds @ 2011-05-13 16:11 UTC (permalink / raw)
To: Andrew Lutomirski; +Cc: Christian Couder, linux-kernel, netdev, git, Shuang He
In-Reply-To: <BANLkTi=NdVUUZ=_bACzyeMGS3JWs0EMbWA@mail.gmail.com>
On Fri, May 13, 2011 at 7:56 AM, Andrew Lutomirski <luto@mit.edu> wrote:
>
> So what I really want is a fancy version of git bisect that makes no
> assumptions about the relationship of good and bad commits in the
> graph and just finds me a commit that is bad but for which all parents
> are good or vice versa.
Ehh. That's the "non-fancy" way of testing, I'm afraid: if you cannot
make assumption about the relationship between good and bad commits,
then you have to test _every_ commit.
So yes, bisection has its problems. But they really do come from the
fact that it's very efficient. When you have (on average) about ten
thousand commits between releases, you have to make assumptions about
the relationships. But once you do that, the efficiency also results
in a certain fragility.
Think of it as a compression method: it generates the smallest
possible set of test points for you. But it's a "lossy" compression -
you don't test everything. And it's extreme: it boils down 10k commit
events to about 13 bisection events. If anything goes wrong (like the
bug not being entirely repeatable, or the bug comes and goes), it will
give the wrong answer.
The good news is that _usually_ it works really well. And when the
choice is between "works really well for 10k commits but can have
problems" and "you need to test all 10k commits", the "can have
problems" part turns out to be a pretty small downside ;)
Linus
^ permalink raw reply
* Re: AAARGH bisection is hard (Re: [2.6.39 regression] X locks up hard right after logging in)
From: Andrew Lutomirski @ 2011-05-13 16:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Christian Couder, linux-kernel, netdev, git, Shuang He
In-Reply-To: <BANLkTimE2GkkhcFZtNrYZASWp0LDhUx=GQ@mail.gmail.com>
On Fri, May 13, 2011 at 12:11 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Fri, May 13, 2011 at 7:56 AM, Andrew Lutomirski <luto@mit.edu> wrote:
>>
>> So what I really want is a fancy version of git bisect that makes no
>> assumptions about the relationship of good and bad commits in the
>> graph and just finds me a commit that is bad but for which all parents
>> are good or vice versa.
>
> Ehh. That's the "non-fancy" way of testing, I'm afraid: if you cannot
> make assumption about the relationship between good and bad commits,
> then you have to test _every_ commit.
>
> So yes, bisection has its problems. But they really do come from the
> fact that it's very efficient. When you have (on average) about ten
> thousand commits between releases, you have to make assumptions about
> the relationships. But once you do that, the efficiency also results
> in a certain fragility.
>
> Think of it as a compression method: it generates the smallest
> possible set of test points for you. But it's a "lossy" compression -
> you don't test everything. And it's extreme: it boils down 10k commit
> events to about 13 bisection events. If anything goes wrong (like the
> bug not being entirely repeatable, or the bug comes and goes), it will
> give the wrong answer.
>
> The good news is that _usually_ it works really well. And when the
> choice is between "works really well for 10k commits but can have
> problems" and "you need to test all 10k commits", the "can have
> problems" part turns out to be a pretty small downside ;)
In conclusion, I found the problem. It's a clusterfuck and I think
there's no way that any bisection tool under any sane assumptions
could have found it. Patch coming in a couple seconds b/c I think it
needs to go in to 2.6.39.
--Andy
>
> Linus
>
^ permalink raw reply
* [RFC 0/3] RDMA: Add netlink infrastructure
From: Roland Dreier @ 2011-05-13 16:18 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA
From: Roland Dreier <roland-BHEL68pLQRGGvPXPguhicg@public.gmane.org>
Hi,
Here are the highlights of a patch series adding support for getting
information on active RDMA connections via netlink. I would really
appreciate it if netlink experts could take a look and make sure we
are doing this the right way and using a suitably extensible
structure.
I'm by no means particularly knowledgeable about netlink, so although
the RDMA side of things looks OK to me, I hope we can get some level
of review of the netlink side of things; the changelog for patch 2/3
tries to explain the messages we're using.
The full series based on 2.6.39-rc7 is also available at:
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git netlink
Thanks!
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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
* [RFC 2/3] RDMA/cma: Add support for netlink statistics export
From: Roland Dreier @ 2011-05-13 16:18 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1305303525-11113-1-git-send-email-roland-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
From: Nir Muchtar <nirm-smomgflXvOZWk0Htik3J/w@public.gmane.org>
[Dave please do not apply even if this ends up in netdev patchwork!]
Add callbacks and data types for statistics export of all current
devices/ids. The schema for RDMA CM is a series of netlink messages.
Each one contains an rdma_cm_stat struct. Additionally, two netlink
attributes are created for the addresses for each message (if
applicable).
Their types used are:
RDMA_NL_RDMA_CM_ATTR_SRC_ADDR (The source address for this ID)
RDMA_NL_RDMA_CM_ATTR_DST_ADDR (The destination address for this ID)
sockaddr_* structs are encapsulated within these attributes.
In other words, every transaction contains a series of messages like:
-------message 1-------
struct rdma_cm_id_stats {
__u32 qp_num;
__u32 bound_dev_if;
__u32 port_space;
__s32 pid;
__u8 cm_state;
__u8 node_type;
__u8 port_num;
__u8 reserved;
}
RDMA_NL_RDMA_CM_ATTR_SRC_ADDR attribute - contains the source address
RDMA_NL_RDMA_CM_ATTR_DST_ADDR attribute - contains the destination address
-------end 1-------
-------message 2-------
struct rdma_cm_id_stats
RDMA_NL_RDMA_CM_ATTR_SRC_ADDR attribute
RDMA_NL_RDMA_CM_ATTR_DST_ADDR attribute
-------end 2-------
NOT-Signed-off-by: Nir Muchtar <nirm-smomgflXvOZWk0Htik3J/w@public.gmane.org>
NOT-Signed-off-by: Roland Dreier <roland-BHEL68pLQRGGvPXPguhicg@public.gmane.org>
---
drivers/infiniband/core/cma.c | 98 +++++++++++++++++++++++++++++++++++++++++
include/rdma/rdma_netlink.h | 28 ++++++++++++
2 files changed, 126 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index 05b55e4..d4701a8 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -47,6 +47,7 @@
#include <rdma/rdma_cm.h>
#include <rdma/rdma_cm_ib.h>
+#include <rdma/rdma_netlink.h>
#include <rdma/ib_cache.h>
#include <rdma/ib_cm.h>
#include <rdma/ib_sa.h>
@@ -3247,6 +3248,98 @@ static void cma_remove_one(struct ib_device *device)
kfree(cma_dev);
}
+static int cma_get_id_stats(struct sk_buff *skb, struct netlink_callback *cb)
+{
+ struct nlmsghdr *nlh;
+ struct rdma_cm_id_stats *id_stats;
+ struct rdma_id_private *id_priv;
+ struct rdma_cm_id *id = NULL;
+ struct cma_device *cma_dev;
+ int i_dev = 0, i_id = 0;
+
+ /*
+ * We export all of the IDs as a sequence of messages. Each
+ * ID gets its own netlink message.
+ */
+ mutex_lock(&lock);
+
+ list_for_each_entry(cma_dev, &dev_list, list) {
+ if (i_dev < cb->args[0]) {
+ i_dev++;
+ continue;
+ }
+
+ i_id = 0;
+ list_for_each_entry(id_priv, &cma_dev->id_list, list) {
+ if (i_id < cb->args[1]) {
+ i_id++;
+ continue;
+ }
+
+ id_stats = ibnl_put_msg(skb, &nlh, cb->nlh->nlmsg_seq,
+ sizeof *id_stats, RDMA_NL_RDMA_CM,
+ RDMA_NL_RDMA_CM_ID_STATS);
+ if (!id_stats)
+ goto out;
+
+ memset(id_stats, 0, sizeof *id_stats);
+ id = &id_priv->id;
+ id_stats->node_type = id->route.addr.dev_addr.dev_type;
+ id_stats->port_num = id->port_num;
+ id_stats->bound_dev_if =
+ id->route.addr.dev_addr.bound_dev_if;
+
+ if (id->route.addr.src_addr.ss_family == AF_INET) {
+ if (ibnl_put_attr(skb, nlh,
+ sizeof(struct sockaddr_in),
+ &id->route.addr.src_addr,
+ RDMA_NL_RDMA_CM_ATTR_SRC_ADDR)) {
+ goto out;
+ }
+ if (ibnl_put_attr(skb, nlh,
+ sizeof(struct sockaddr_in),
+ &id->route.addr.dst_addr,
+ RDMA_NL_RDMA_CM_ATTR_DST_ADDR)) {
+ goto out;
+ }
+ } else if (id->route.addr.src_addr.ss_family == AF_INET6) {
+ if (ibnl_put_attr(skb, nlh,
+ sizeof(struct sockaddr_in6),
+ &id->route.addr.src_addr,
+ RDMA_NL_RDMA_CM_ATTR_SRC_ADDR)) {
+ goto out;
+ }
+ if (ibnl_put_attr(skb, nlh,
+ sizeof(struct sockaddr_in6),
+ &id->route.addr.dst_addr,
+ RDMA_NL_RDMA_CM_ATTR_DST_ADDR)) {
+ goto out;
+ }
+ }
+
+ id_stats->port_space = id->ps;
+ id_stats->cm_state = id_priv->state;
+ id_stats->qp_num = id_priv->qp_num;
+
+ i_id++;
+ }
+
+ cb->args[1] = 0;
+ i_dev++;
+ }
+
+out:
+ mutex_unlock(&lock);
+ cb->args[0] = i_dev;
+ cb->args[1] = i_id;
+
+ return skb->len;
+}
+
+static const struct ibnl_client_cbs cma_cb_table[] = {
+ [RDMA_NL_RDMA_CM_ID_STATS] = { .dump = cma_get_id_stats },
+};
+
static int __init cma_init(void)
{
int ret;
@@ -3262,6 +3355,10 @@ static int __init cma_init(void)
ret = ib_register_client(&cma_client);
if (ret)
goto err;
+
+ if (ibnl_add_client(RDMA_NL_RDMA_CM, RDMA_NL_RDMA_CM_NUM_OPS, cma_cb_table))
+ printk(KERN_WARNING "RDMA CMA: failed to add netlink callback\n");
+
return 0;
err:
@@ -3274,6 +3371,7 @@ err:
static void __exit cma_cleanup(void)
{
+ ibnl_remove_client(RDMA_NL_RDMA_CM);
ib_unregister_client(&cma_client);
unregister_netdevice_notifier(&cma_nb);
rdma_addr_unregister_client(&addr_client);
diff --git a/include/rdma/rdma_netlink.h b/include/rdma/rdma_netlink.h
index c983a19..fa318af 100644
--- a/include/rdma/rdma_netlink.h
+++ b/include/rdma/rdma_netlink.h
@@ -1,10 +1,38 @@
#ifndef _RDMA_NETLINK_H
#define _RDMA_NETLINK_H
+#include <linux/types.h>
+
+enum {
+ RDMA_NL_RDMA_CM = 1
+};
+
#define RDMA_NL_GET_CLIENT(type) ((type & (((1 << 6) - 1) << 10)) >> 10)
#define RDMA_NL_GET_OP(type) (type & ((1 << 10) - 1))
#define RDMA_NL_GET_TYPE(client, op) ((client << 10) + op)
+enum {
+ RDMA_NL_RDMA_CM_ID_STATS = 0,
+ RDMA_NL_RDMA_CM_NUM_OPS
+};
+
+enum {
+ RDMA_NL_RDMA_CM_ATTR_SRC_ADDR = 1,
+ RDMA_NL_RDMA_CM_ATTR_DST_ADDR,
+ RDMA_NL_RDMA_CM_NUM_ATTR,
+};
+
+struct rdma_cm_id_stats {
+ __u32 qp_num;
+ __u32 bound_dev_if;
+ __u32 port_space;
+ __s32 pid;
+ __u8 cm_state;
+ __u8 node_type;
+ __u8 port_num;
+ __u8 reserved;
+};
+
#ifdef __KERNEL__
#include <linux/netlink.h>
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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 related
* [RFC 1/3] RDMA: Add netlink infrastructure
From: Roland Dreier @ 2011-05-13 16:18 UTC (permalink / raw)
To: netdev, linux-rdma
In-Reply-To: <1305303525-11113-1-git-send-email-roland@kernel.org>
From: Roland Dreier <roland@purestorage.com>
[Dave please do not apply even if this ends up in netdev patchwork!]
Add basic RDMA netlink infrastructure that allows for registration of
RDMA clients for which data is to be exported and supplies message
construction callbacks.
NOT-Signed-off-by: Nir Muchtar <nirm@voltaire.com>
[ Rename and reorganize a few things. - Roland ]
NOT-Signed-off-by: Roland Dreier <roland@purestorage.com>
---
drivers/infiniband/core/Makefile | 2 +-
drivers/infiniband/core/device.c | 11 ++
drivers/infiniband/core/netlink.c | 190 +++++++++++++++++++++++++++++++++++++
include/linux/netlink.h | 1 +
include/rdma/rdma_netlink.h | 64 +++++++++++++
5 files changed, 267 insertions(+), 1 deletions(-)
create mode 100644 drivers/infiniband/core/netlink.c
create mode 100644 include/rdma/rdma_netlink.h
diff --git a/drivers/infiniband/core/Makefile b/drivers/infiniband/core/Makefile
index cb1ab3e..c8bbaef 100644
--- a/drivers/infiniband/core/Makefile
+++ b/drivers/infiniband/core/Makefile
@@ -8,7 +8,7 @@ obj-$(CONFIG_INFINIBAND_USER_ACCESS) += ib_uverbs.o ib_ucm.o \
$(user_access-y)
ib_core-y := packer.o ud_header.o verbs.o sysfs.o \
- device.o fmr_pool.o cache.o
+ device.o fmr_pool.o cache.o netlink.o
ib_core-$(CONFIG_INFINIBAND_USER_MEM) += umem.o
ib_mad-y := mad.o smi.o agent.o mad_rmpp.o
diff --git a/drivers/infiniband/core/device.c b/drivers/infiniband/core/device.c
index 46a7a3f..635c338 100644
--- a/drivers/infiniband/core/device.c
+++ b/drivers/infiniband/core/device.c
@@ -38,6 +38,7 @@
#include <linux/slab.h>
#include <linux/init.h>
#include <linux/mutex.h>
+#include <rdma/rdma_netlink.h>
#include "core_priv.h"
@@ -736,8 +737,17 @@ static int __init ib_core_init(void)
goto err_sysfs;
}
+ ret = ibnl_init();
+ if (ret) {
+ printk(KERN_WARNING "Couldn't init IB netlink interface\n");
+ goto err_cache;
+ }
+
return 0;
+err_cache:
+ ib_cache_cleanup();
+
err_sysfs:
ib_sysfs_cleanup();
@@ -748,6 +758,7 @@ err:
static void __exit ib_core_cleanup(void)
{
+ ibnl_cleanup();
ib_cache_cleanup();
ib_sysfs_cleanup();
/* Make sure that any pending umem accounting work is done. */
diff --git a/drivers/infiniband/core/netlink.c b/drivers/infiniband/core/netlink.c
new file mode 100644
index 0000000..361e29f
--- /dev/null
+++ b/drivers/infiniband/core/netlink.c
@@ -0,0 +1,190 @@
+/*
+ * Copyright (c) 2010 Voltaire Inc. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses. You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above
+ * copyright notice, this list of conditions and the following
+ * disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ * copyright notice, this list of conditions and the following
+ * disclaimer in the documentation and/or other materials
+ * provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#define pr_fmt(fmt) "%s:%s: " fmt, KBUILD_MODNAME, __func__
+
+#include <net/netlink.h>
+#include <net/net_namespace.h>
+#include <net/sock.h>
+#include <rdma/rdma_netlink.h>
+
+struct ibnl_client {
+ struct list_head list;
+ int index;
+ int nops;
+ const struct ibnl_client_cbs *cb_table;
+};
+
+static DEFINE_MUTEX(ibnl_mutex);
+static struct sock *nls;
+static LIST_HEAD(client_list);
+
+int ibnl_add_client(int index, int nops,
+ const struct ibnl_client_cbs cb_table[])
+{
+ struct ibnl_client *cur;
+ struct ibnl_client *nl_client;
+
+ nl_client = kmalloc(sizeof *nl_client, GFP_KERNEL);
+ if (!nl_client)
+ return -ENOMEM;
+
+ nl_client->index = index;
+ nl_client->nops = nops;
+ nl_client->cb_table = cb_table;
+
+ mutex_lock(&ibnl_mutex);
+
+ list_for_each_entry(cur, &client_list, list) {
+ if (cur->index == index) {
+ pr_warn("Client for %d already exists\n", index);
+ mutex_unlock(&ibnl_mutex);
+ kfree(nl_client);
+ return -EINVAL;
+ }
+ }
+
+ list_add_tail(&nl_client->list, &client_list);
+
+ mutex_unlock(&ibnl_mutex);
+
+ return 0;
+}
+EXPORT_SYMBOL(ibnl_add_client);
+
+int ibnl_remove_client(int index)
+{
+ struct ibnl_client *cur, *next;
+
+ mutex_lock(&ibnl_mutex);
+ list_for_each_entry_safe(cur, next, &client_list, list) {
+ if (cur->index == index) {
+ list_del(&(cur->list));
+ mutex_unlock(&ibnl_mutex);
+ kfree(cur);
+ return 0;
+ }
+ }
+ pr_warn("Can't remove callback for client idx %d. Not found\n", index);
+ mutex_unlock(&ibnl_mutex);
+
+ return -EINVAL;
+}
+EXPORT_SYMBOL(ibnl_remove_client);
+
+void *ibnl_put_msg(struct sk_buff *skb, struct nlmsghdr **nlh, int seq,
+ int len, int client, int op)
+{
+ unsigned char *prev_tail;
+
+ prev_tail = skb_tail_pointer(skb);
+ *nlh = NLMSG_NEW(skb, 0, seq, RDMA_NL_GET_TYPE(client, op),
+ len, NLM_F_MULTI);
+ (*nlh)->nlmsg_len = skb_tail_pointer(skb) - prev_tail;
+ return NLMSG_DATA(*nlh);
+
+nlmsg_failure:
+ nlmsg_trim(skb, prev_tail);
+ return NULL;
+}
+EXPORT_SYMBOL(ibnl_put_msg);
+
+int ibnl_put_attr(struct sk_buff *skb, struct nlmsghdr *nlh,
+ int len, void *data, int type)
+{
+ unsigned char *prev_tail;
+
+ prev_tail = skb_tail_pointer(skb);
+ NLA_PUT(skb, type, len, data);
+ nlh->nlmsg_len += skb_tail_pointer(skb) - prev_tail;
+ return 0;
+
+nla_put_failure:
+ nlmsg_trim(skb, prev_tail - nlh->nlmsg_len);
+ return -EMSGSIZE;
+}
+EXPORT_SYMBOL(ibnl_put_attr);
+
+static int ibnl_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
+{
+ struct ibnl_client *client;
+ int type = nlh->nlmsg_type;
+ int index = RDMA_NL_GET_CLIENT(type);
+ int op = RDMA_NL_GET_OP(type);
+
+ list_for_each_entry(client, &client_list, list) {
+ if (client->index == index) {
+ if (op < 0 || op >= client->nops ||
+ !client->cb_table[RDMA_NL_GET_OP(op)].dump)
+ return -EINVAL;
+ return netlink_dump_start(nls, skb, nlh,
+ client->cb_table[op].dump,
+ NULL);
+ }
+ }
+
+ pr_info("Index %d wasn't found in client list\n", index);
+ return -EINVAL;
+}
+
+static void ibnl_rcv(struct sk_buff *skb)
+{
+ mutex_lock(&ibnl_mutex);
+ netlink_rcv_skb(skb, &ibnl_rcv_msg);
+ mutex_unlock(&ibnl_mutex);
+}
+
+int ibnl_init(void)
+{
+ nls = netlink_kernel_create(&init_net, NETLINK_INFINIBAND, 0, ibnl_rcv,
+ NULL, THIS_MODULE);
+ if (!nls) {
+ pr_warn("Failed to create netlink socket\n");
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+
+void ibnl_cleanup(void)
+{
+ struct ibnl_client *cur, *next;
+
+ mutex_lock(&ibnl_mutex);
+ list_for_each_entry_safe(cur, next, &client_list, list) {
+ list_del(&(cur->list));
+ kfree(cur);
+ }
+ mutex_unlock(&ibnl_mutex);
+
+ netlink_kernel_release(nls);
+}
diff --git a/include/linux/netlink.h b/include/linux/netlink.h
index 4c4ac3f..b1e3e59 100644
--- a/include/linux/netlink.h
+++ b/include/linux/netlink.h
@@ -24,6 +24,7 @@
/* leave room for NETLINK_DM (DM Events) */
#define NETLINK_SCSITRANSPORT 18 /* SCSI Transports */
#define NETLINK_ECRYPTFS 19
+#define NETLINK_INFINIBAND 20
#define MAX_LINKS 32
diff --git a/include/rdma/rdma_netlink.h b/include/rdma/rdma_netlink.h
new file mode 100644
index 0000000..c983a19
--- /dev/null
+++ b/include/rdma/rdma_netlink.h
@@ -0,0 +1,64 @@
+#ifndef _RDMA_NETLINK_H
+#define _RDMA_NETLINK_H
+
+#define RDMA_NL_GET_CLIENT(type) ((type & (((1 << 6) - 1) << 10)) >> 10)
+#define RDMA_NL_GET_OP(type) (type & ((1 << 10) - 1))
+#define RDMA_NL_GET_TYPE(client, op) ((client << 10) + op)
+
+#ifdef __KERNEL__
+
+#include <linux/netlink.h>
+
+struct ibnl_client_cbs {
+ int (*dump)(struct sk_buff *skb, struct netlink_callback *nlcb);
+};
+
+int ibnl_init(void);
+void ibnl_cleanup(void);
+
+/**
+ * Add a a client to the list of IB netlink exporters.
+ * @index: Index of the added client
+ * @nops: Number of supported ops by the added client.
+ * @cb_table: A table for op->callback
+ *
+ * Returns 0 on success or a negative error code.
+ */
+int ibnl_add_client(int index, int nops,
+ const struct ibnl_client_cbs cb_table[]);
+
+/**
+ * Remove a client from IB netlink.
+ * @index: Index of the removed IB client.
+ *
+ * Returns 0 on success or a negative error code.
+ */
+int ibnl_remove_client(int index);
+
+/**
+ * Put a new message in a supplied skb.
+ * @skb: The netlink skb.
+ * @nlh: Pointer to put the header of the new netlink message.
+ * @seq: The message sequence number.
+ * @len: The requested message length to allocate.
+ * @client: Calling IB netlink client.
+ * @op: message content op.
+ * Returns the allocated buffer on success and NULL on failure.
+ */
+void *ibnl_put_msg(struct sk_buff *skb, struct nlmsghdr **nlh, int seq,
+ int len, int client, int op);
+/**
+ * Put a new attribute in a supplied skb.
+ * @skb: The netlink skb.
+ * @nlh: Header of the netlink message to append the attribute to.
+ * @len: The length of the attribute data.
+ * @data: The attribute data to put.
+ * @type: The attribute type.
+ * Returns the 0 and a negative error code on failure.
+ */
+int ibnl_put_attr(struct sk_buff *skb, struct nlmsghdr *nlh,
+ int len, void *data, int type);
+
+#endif /* __KERNEL__ */
+
+#endif /* _RDMA_NETLINK_H */
--
1.7.4.1
^ permalink raw reply related
* [RFC 3/3] RDMA/cma: Save PID of ID's owner
From: Roland Dreier @ 2011-05-13 16:18 UTC (permalink / raw)
To: netdev, linux-rdma
In-Reply-To: <1305303525-11113-1-git-send-email-roland@kernel.org>
From: Nir Muchtar <nirm@voltaire.com>
[Dave please do not apply even if this ends up in netdev patchwork!]
Save the PID associated with an RDMA CM ID for reporting via netlink.
NOT-Signed-off-by: Nir Muchtar <nirm@voltaire.com>
NOT-Signed-off-by: Roland Dreier <roland@purestorage.com>
---
drivers/infiniband/core/cma.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index d4701a8..1e25434 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -133,6 +133,7 @@ struct rdma_id_private {
u32 seq_num;
u32 qkey;
u32 qp_num;
+ pid_t owner;
u8 srq;
u8 tos;
};
@@ -423,6 +424,7 @@ struct rdma_cm_id *rdma_create_id(rdma_cm_event_handler event_handler,
if (!id_priv)
return ERR_PTR(-ENOMEM);
+ id_priv->owner = task_pid_nr(current);
id_priv->state = RDMA_CM_IDLE;
id_priv->id.context = context;
id_priv->id.event_handler = event_handler;
@@ -2678,6 +2680,9 @@ int rdma_accept(struct rdma_cm_id *id, struct rdma_conn_param *conn_param)
int ret;
id_priv = container_of(id, struct rdma_id_private, id);
+
+ id_priv->owner = task_pid_nr(current);
+
if (!cma_comp(id_priv, RDMA_CM_CONNECT))
return -EINVAL;
@@ -3320,6 +3325,7 @@ static int cma_get_id_stats(struct sk_buff *skb, struct netlink_callback *cb)
id_stats->port_space = id->ps;
id_stats->cm_state = id_priv->state;
id_stats->qp_num = id_priv->qp_num;
+ id_stats->pid = id_priv->owner;
i_id++;
}
--
1.7.4.1
^ permalink raw reply related
* Re: [RFC 1/3] RDMA: Add netlink infrastructure
From: Joe Perches @ 2011-05-13 16:44 UTC (permalink / raw)
To: Roland Dreier, Nir Muchtar
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1305303525-11113-2-git-send-email-roland-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
On Fri, 2011-05-13 at 09:18 -0700, Roland Dreier wrote:
> From: Roland Dreier <roland-BHEL68pLQRGGvPXPguhicg@public.gmane.org>
> [Dave please do not apply even if this ends up in netdev patchwork!]
Just trivia:
> diff --git a/drivers/infiniband/core/netlink.c b/drivers/infiniband/core/netlink.c
[]
> +#define pr_fmt(fmt) "%s:%s: " fmt, KBUILD_MODNAME, __func__
Using #define pr_fmt(fmt) KBUILD_MODNAME ":%s: " fmt, __func__
generally produces smaller overall object size, especially
at 64 bit.
For instance, here's the size of netlink.o at 32 bit:
$ size drivers/infiniband/core/netlink.o.*
text data bss dec hex filename
2663 153 736 3552 de0 drivers/infiniband/core/netlink.o.old
2640 153 736 3529 dc9 drivers/infiniband/core/netlink.o.new
Also, I rarely find __func__ useful in message output.
It may be more useful for active development/debugging.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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
* kernel BUG at net/ipv4/tcp_output.c:1006!
From: TB @ 2011-05-13 17:11 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev
This is the 2.6.38.5 kernel with the patch in
[PATCH] tcp_cubic: limit delayed_ack ratio to prevent divide error
Had this crash a few days ago, but never got any response to subsequent
emails. Another server crashed today with a network related backtrace,
but netconsole did not work.
The network switch is a
HP ProCurve J9147A 2910al-48G Switch, revision W.14.49, ROM W.14.04
MTU is set at 1500
No firewall rules in the filter chain
No mangle or NAT loaded or compiled in the kernel.
Bonding on 2 igb gigabit ethernet is activated.
Network traffic was at 700mbit and 900mbit in each instance.
[405542.454073] ------------[ cut here ]------------
[405542.454109] kernel BUG at net/ipv4/tcp_output.c:1006!
[405542.454136] invalid opcode: 0000 [#1]
[405542.454166] last sysfs file:
/sys/devices/pci0000:00/0000:00:1f.2/host6/scsi_host/host6/proc_name
[405542.454213] CPU 0
[405542.454220] Modules linked in:
i2c_i801
evdev
i2c_core
button
[last unloaded: scsi_wait_scan]
[405542.454300]
[405542.454320] Pid: 0, comm: swapper Not tainted 2.6.38.5 #8
/
[405542.454379] RIP: 0010:[<ffffffff814e7ed2>]
[<ffffffff814e7ed2>] tcp_fragment+0x22/0x29a
[405542.454433] RSP: 0018:ffff8800bf403a30 EFLAGS: 00010202
[405542.454460] RAX: ffff88000cd35000 RBX: ffff88006b84f480 RCX:
0000000000000218
[405542.454504] RDX: 0000000000001708 RSI: ffff88006b84f480 RDI:
ffff880008d6b200
[405542.454548] RBP: 0000000000001540 R08: 0000000000000002 R09:
000000001027984a
[405542.454592] R10: ffff8800b915f428 R11: ffff880008d6b200 R12:
ffff88006b84f4a8
[405542.454636] R13: 0000000000001708 R14: 0000000000000000 R15:
ffff880008d6b200
[405542.454680] FS: 0000000000000000(0000) GS:ffff8800bf400000(0000)
knlGS:0000000000000000
[405542.454726] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[405542.454754] CR2: 00007f94055c7000 CR3: 000000083e0bd000 CR4:
00000000000006f0
[405542.454798] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[405542.454842] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[405542.454886] Process swapper (pid: 0, threadinfo ffffffff8176c000,
task ffffffff81777020)
[405542.454931] Stack:
[405542.454951] 0000000000000000
0000021808d6b798
00000002000005b4
ffff88006b84f480
[405542.455006] ffff880008d6b200
ffff88006b84f4a8
0000000000000015
0000000000000000
[405542.455061] ffff880008d6b300
ffffffff814df7a4
ffff8802a3965140
00000000000001a0
[405542.455115] Call Trace:
[405542.455137] <IRQ>
[405542.455162] [<ffffffff814df7a4>] ? tcp_mark_head_lost+0x13c/0x202
[405542.455192] [<ffffffff814e33a8>] ? tcp_ack+0xe98/0x1a89
[405542.455220] [<ffffffff814e42ca>] ? tcp_validate_incoming+0x69/0x290
[405542.455250] [<ffffffff814e4c9b>] ? tcp_rcv_established+0x7aa/0xa13
[405542.455281] [<ffffffff814ec60b>] ? tcp_v4_do_rcv+0x1b2/0x382
[405542.455310] [<ffffffff814c95d4>] ? nf_iterate+0x40/0x78
[405542.455338] [<ffffffff814ecc5f>] ? tcp_v4_rcv+0x484/0x797
[405542.455368] [<ffffffff814d11c7>] ? ip_local_deliver_finish+0xab/0x139
[405542.455398] [<ffffffff814ae2b3>] ? __netif_receive_skb+0x31c/0x349
[405542.455428] [<ffffffff814aec82>] ? netif_receive_skb+0x67/0x6d
[405542.455457] [<ffffffff814af1fb>] ? napi_gro_receive+0x9d/0xab
[405542.455485] [<ffffffff814aed57>] ? napi_skb_finish+0x1c/0x31
[405542.455516] [<ffffffff813e4248>] ? igb_poll+0x7d5/0xb2e
[405542.455544] [<ffffffff813e432f>] ? igb_poll+0x8bc/0xb2e
[405542.455572] [<ffffffff813e211a>] ? igb_msix_ring+0x6e/0x75
[405542.455602] [<ffffffff8106749c>] ? handle_IRQ_event+0x51/0x119
[405542.455631] [<ffffffff814af337>] ? net_rx_action+0xa7/0x212
[405542.455661] [<ffffffff8103b6c2>] ? __do_softirq+0xbe/0x184
[405542.455690] [<ffffffff8100364c>] ? call_softirq+0x1c/0x28
[405542.455719] [<ffffffff81005085>] ? do_softirq+0x31/0x63
[405542.455746] [<ffffffff8103b56c>] ? irq_exit+0x36/0x78
[405542.455773] [<ffffffff81004784>] ? do_IRQ+0x98/0xae
[405542.455802] [<ffffffff81562ed3>] ? ret_from_intr+0x0/0xe
[405542.455829] <EOI>
[405542.455860] [<ffffffff81009a41>] ? mwait_idle+0xb9/0xf3
[405542.455888] [<ffffffff81001c6e>] ? cpu_idle+0x57/0x8d
[405542.455921] [<ffffffff81801c49>] ? start_kernel+0x34e/0x35a
[405542.455950] [<ffffffff81801398>] ? x86_64_start_kernel+0xf3/0xf9
[405542.455977] Code:
f>
[405542.456239] RIP
[<ffffffff814e7ed2>] tcp_fragment+0x22/0x29a
[405542.456270] RSP <ffff8800bf403a30>
[405542.456543] ---[ end trace 231aaa222f893065 ]---
[405542.456600] Kernel panic - not syncing: Fatal exception in interrupt
[405542.456659] Pid: 0, comm: swapper Tainted: G D 2.6.38.5 #8
[405542.456719] Call Trace:
[405542.456770] <IRQ>
[<ffffffff81560960>] ? panic+0x9d/0x1a0
[405542.456863] [<ffffffff81562ed3>] ? ret_from_intr+0x0/0xe
[405542.456923] [<ffffffff810365bb>] ? kmsg_dump+0x46/0xec
[405542.456981] [<ffffffff81006176>] ? oops_end+0x9f/0xac
[405542.457039] [<ffffffff81003f83>] ? do_invalid_op+0x85/0x8f
[405542.457097] [<ffffffff814e7ed2>] ? tcp_fragment+0x22/0x29a
[405542.457156] [<ffffffff814e80a9>] ? tcp_fragment+0x1f9/0x29a
[405542.457216] [<ffffffff810033d5>] ? invalid_op+0x15/0x20
[405542.457276] [<ffffffff814e7ed2>] ? tcp_fragment+0x22/0x29a
[405542.457337] [<ffffffff814df7a4>] ? tcp_mark_head_lost+0x13c/0x202
[405542.457400] [<ffffffff814e33a8>] ? tcp_ack+0xe98/0x1a89
[405542.457461] [<ffffffff814e42ca>] ? tcp_validate_incoming+0x69/0x290
[405542.457524] [<ffffffff814e4c9b>] ? tcp_rcv_established+0x7aa/0xa13
[405542.457586] [<ffffffff814ec60b>] ? tcp_v4_do_rcv+0x1b2/0x382
[405542.457645] [<ffffffff814c95d4>] ? nf_iterate+0x40/0x78
[405542.457703] [<ffffffff814ecc5f>] ? tcp_v4_rcv+0x484/0x797
[405542.457761] [<ffffffff814d11c7>] ? ip_local_deliver_finish+0xab/0x139
[405542.457827] [<ffffffff814ae2b3>] ? __netif_receive_skb+0x31c/0x349
[405542.457894] [<ffffffff814aec82>] ? netif_receive_skb+0x67/0x6d
[405542.457953] [<ffffffff814af1fb>] ? napi_gro_receive+0x9d/0xab
[405542.458021] [<ffffffff814aed57>] ? napi_skb_finish+0x1c/0x31
[405542.458080] [<ffffffff813e4248>] ? igb_poll+0x7d5/0xb2e
[405542.458138] [<ffffffff813e432f>] ? igb_poll+0x8bc/0xb2e
[405542.458196] [<ffffffff813e211a>] ? igb_msix_ring+0x6e/0x75
[405542.458254] [<ffffffff8106749c>] ? handle_IRQ_event+0x51/0x119
[405542.458313] [<ffffffff814af337>] ? net_rx_action+0xa7/0x212
[405542.458371] [<ffffffff8103b6c2>] ? __do_softirq+0xbe/0x184
[405542.458430] [<ffffffff8100364c>] ? call_softirq+0x1c/0x28
[405542.458488] [<ffffffff81005085>] ? do_softirq+0x31/0x63
[405542.458545] [<ffffffff8103b56c>] ? irq_exit+0x36/0x78
[405542.458602] [<ffffffff81004784>] ? do_IRQ+0x98/0xae
[405542.458660] [<ffffffff81562ed3>] ? ret_from_intr+0x0/0xe
[405542.458717] <EOI>
[<ffffffff81009a41>] ? mwait_idle+0xb9/0xf3
[405542.458810] [<ffffffff81001c6e>] ? cpu_idle+0x57/0x8d
[405542.458867] [<ffffffff81801c49>] ? start_kernel+0x34e/0x35a
[405542.458926] [<ffffffff81801398>] ? x86_64_start_kernel+0xf3/0xf9
^ permalink raw reply
* Re: [RFC 1/3] RDMA: Add netlink infrastructure
From: Bart Van Assche @ 2011-05-13 17:18 UTC (permalink / raw)
To: Joe Perches
Cc: Roland Dreier, Nir Muchtar, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1305305065.8178.9.camel@Joe-Laptop>
On Fri, May 13, 2011 at 6:44 PM, Joe Perches <joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org> wrote:
> On Fri, 2011-05-13 at 09:18 -0700, Roland Dreier wrote:
>> From: Roland Dreier <roland-BHEL68pLQRGGvPXPguhicg@public.gmane.org>
>> [Dave please do not apply even if this ends up in netdev patchwork!]
>
> Just trivia:
>
>> diff --git a/drivers/infiniband/core/netlink.c b/drivers/infiniband/core/netlink.c
> []
>> +#define pr_fmt(fmt) "%s:%s: " fmt, KBUILD_MODNAME, __func__
>
> Using #define pr_fmt(fmt) KBUILD_MODNAME ":%s: " fmt, __func__
> generally produces smaller overall object size, especially
> at 64 bit.
>
> For instance, here's the size of netlink.o at 32 bit:
>
> $ size drivers/infiniband/core/netlink.o.*
> text data bss dec hex filename
> 2663 153 736 3552 de0 drivers/infiniband/core/netlink.o.old
> 2640 153 736 3529 dc9 drivers/infiniband/core/netlink.o.new
>
> Also, I rarely find __func__ useful in message output.
> It may be more useful for active development/debugging.
A recent dynamic debug patch made it possible to enable/disable at
runtime whether or not the function name (and more) should be included
in the output. See also http://lwn.net/Articles/434833/ for more
information.
Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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
* RE: [RFC 1/3] RDMA: Add netlink infrastructure
From: Hefty, Sean @ 2011-05-13 17:19 UTC (permalink / raw)
To: Roland Dreier, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1305303525-11113-2-git-send-email-roland-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> +#define NETLINK_INFINIBAND 20
Would NETLINK_RDMA be better?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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
* Re: kernel BUG at net/ipv4/tcp_output.c:1006!
From: Ben Greear @ 2011-05-13 17:20 UTC (permalink / raw)
To: TB; +Cc: linux-kernel, netdev
In-Reply-To: <4DCD6658.3020901@techboom.com>
On 05/13/2011 10:11 AM, TB wrote:
> This is the 2.6.38.5 kernel with the patch in
> [PATCH] tcp_cubic: limit delayed_ack ratio to prevent divide error
>
> Had this crash a few days ago, but never got any response to subsequent
> emails. Another server crashed today with a network related backtrace,
> but netconsole did not work.
We've seen some funny things with the in-kernel igb driver.
Not crashes, but just strange performance issues and CRC errors
on the wire and such. Intel's igb driver seems to work fine
for us.
If you have no other things to try..you might try using the
out-of-kernel igb driver from Intel and see if that makes
any difference.
Thanks,
Ben
>
> The network switch is a
> HP ProCurve J9147A 2910al-48G Switch, revision W.14.49, ROM W.14.04
>
> MTU is set at 1500
> No firewall rules in the filter chain
> No mangle or NAT loaded or compiled in the kernel.
> Bonding on 2 igb gigabit ethernet is activated.
> Network traffic was at 700mbit and 900mbit in each instance.
>
> [405542.454073] ------------[ cut here ]------------
> [405542.454109] kernel BUG at net/ipv4/tcp_output.c:1006!
> [405542.454136] invalid opcode: 0000 [#1]
>
> [405542.454166] last sysfs file:
> /sys/devices/pci0000:00/0000:00:1f.2/host6/scsi_host/host6/proc_name
> [405542.454213] CPU 0
>
> [405542.454220] Modules linked in:
> i2c_i801
> evdev
> i2c_core
> button
> [last unloaded: scsi_wait_scan]
>
> [405542.454300]
> [405542.454320] Pid: 0, comm: swapper Not tainted 2.6.38.5 #8
>
> /
>
> [405542.454379] RIP: 0010:[<ffffffff814e7ed2>]
> [<ffffffff814e7ed2>] tcp_fragment+0x22/0x29a
> [405542.454433] RSP: 0018:ffff8800bf403a30 EFLAGS: 00010202
> [405542.454460] RAX: ffff88000cd35000 RBX: ffff88006b84f480 RCX:
> 0000000000000218
> [405542.454504] RDX: 0000000000001708 RSI: ffff88006b84f480 RDI:
> ffff880008d6b200
> [405542.454548] RBP: 0000000000001540 R08: 0000000000000002 R09:
> 000000001027984a
> [405542.454592] R10: ffff8800b915f428 R11: ffff880008d6b200 R12:
> ffff88006b84f4a8
> [405542.454636] R13: 0000000000001708 R14: 0000000000000000 R15:
> ffff880008d6b200
> [405542.454680] FS: 0000000000000000(0000) GS:ffff8800bf400000(0000)
> knlGS:0000000000000000
> [405542.454726] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [405542.454754] CR2: 00007f94055c7000 CR3: 000000083e0bd000 CR4:
> 00000000000006f0
> [405542.454798] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> [405542.454842] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000400
> [405542.454886] Process swapper (pid: 0, threadinfo ffffffff8176c000,
> task ffffffff81777020)
> [405542.454931] Stack:
> [405542.454951] 0000000000000000
> 0000021808d6b798
> 00000002000005b4
> ffff88006b84f480
>
> [405542.455006] ffff880008d6b200
> ffff88006b84f4a8
> 0000000000000015
> 0000000000000000
>
> [405542.455061] ffff880008d6b300
> ffffffff814df7a4
> ffff8802a3965140
> 00000000000001a0
>
> [405542.455115] Call Trace:
> [405542.455137]<IRQ>
>
> [405542.455162] [<ffffffff814df7a4>] ? tcp_mark_head_lost+0x13c/0x202
> [405542.455192] [<ffffffff814e33a8>] ? tcp_ack+0xe98/0x1a89
> [405542.455220] [<ffffffff814e42ca>] ? tcp_validate_incoming+0x69/0x290
> [405542.455250] [<ffffffff814e4c9b>] ? tcp_rcv_established+0x7aa/0xa13
> [405542.455281] [<ffffffff814ec60b>] ? tcp_v4_do_rcv+0x1b2/0x382
> [405542.455310] [<ffffffff814c95d4>] ? nf_iterate+0x40/0x78
> [405542.455338] [<ffffffff814ecc5f>] ? tcp_v4_rcv+0x484/0x797
> [405542.455368] [<ffffffff814d11c7>] ? ip_local_deliver_finish+0xab/0x139
> [405542.455398] [<ffffffff814ae2b3>] ? __netif_receive_skb+0x31c/0x349
> [405542.455428] [<ffffffff814aec82>] ? netif_receive_skb+0x67/0x6d
> [405542.455457] [<ffffffff814af1fb>] ? napi_gro_receive+0x9d/0xab
> [405542.455485] [<ffffffff814aed57>] ? napi_skb_finish+0x1c/0x31
> [405542.455516] [<ffffffff813e4248>] ? igb_poll+0x7d5/0xb2e
> [405542.455544] [<ffffffff813e432f>] ? igb_poll+0x8bc/0xb2e
> [405542.455572] [<ffffffff813e211a>] ? igb_msix_ring+0x6e/0x75
> [405542.455602] [<ffffffff8106749c>] ? handle_IRQ_event+0x51/0x119
> [405542.455631] [<ffffffff814af337>] ? net_rx_action+0xa7/0x212
> [405542.455661] [<ffffffff8103b6c2>] ? __do_softirq+0xbe/0x184
> [405542.455690] [<ffffffff8100364c>] ? call_softirq+0x1c/0x28
> [405542.455719] [<ffffffff81005085>] ? do_softirq+0x31/0x63
> [405542.455746] [<ffffffff8103b56c>] ? irq_exit+0x36/0x78
> [405542.455773] [<ffffffff81004784>] ? do_IRQ+0x98/0xae
> [405542.455802] [<ffffffff81562ed3>] ? ret_from_intr+0x0/0xe
> [405542.455829]<EOI>
>
> [405542.455860] [<ffffffff81009a41>] ? mwait_idle+0xb9/0xf3
> [405542.455888] [<ffffffff81001c6e>] ? cpu_idle+0x57/0x8d
> [405542.455921] [<ffffffff81801c49>] ? start_kernel+0x34e/0x35a
> [405542.455950] [<ffffffff81801398>] ? x86_64_start_kernel+0xf3/0xf9
> [405542.455977] Code:
> f>
>
> [405542.456239] RIP
> [<ffffffff814e7ed2>] tcp_fragment+0x22/0x29a
> [405542.456270] RSP<ffff8800bf403a30>
> [405542.456543] ---[ end trace 231aaa222f893065 ]---
> [405542.456600] Kernel panic - not syncing: Fatal exception in interrupt
> [405542.456659] Pid: 0, comm: swapper Tainted: G D 2.6.38.5 #8
> [405542.456719] Call Trace:
> [405542.456770]<IRQ>
> [<ffffffff81560960>] ? panic+0x9d/0x1a0
> [405542.456863] [<ffffffff81562ed3>] ? ret_from_intr+0x0/0xe
> [405542.456923] [<ffffffff810365bb>] ? kmsg_dump+0x46/0xec
> [405542.456981] [<ffffffff81006176>] ? oops_end+0x9f/0xac
> [405542.457039] [<ffffffff81003f83>] ? do_invalid_op+0x85/0x8f
> [405542.457097] [<ffffffff814e7ed2>] ? tcp_fragment+0x22/0x29a
> [405542.457156] [<ffffffff814e80a9>] ? tcp_fragment+0x1f9/0x29a
> [405542.457216] [<ffffffff810033d5>] ? invalid_op+0x15/0x20
> [405542.457276] [<ffffffff814e7ed2>] ? tcp_fragment+0x22/0x29a
> [405542.457337] [<ffffffff814df7a4>] ? tcp_mark_head_lost+0x13c/0x202
> [405542.457400] [<ffffffff814e33a8>] ? tcp_ack+0xe98/0x1a89
> [405542.457461] [<ffffffff814e42ca>] ? tcp_validate_incoming+0x69/0x290
> [405542.457524] [<ffffffff814e4c9b>] ? tcp_rcv_established+0x7aa/0xa13
> [405542.457586] [<ffffffff814ec60b>] ? tcp_v4_do_rcv+0x1b2/0x382
> [405542.457645] [<ffffffff814c95d4>] ? nf_iterate+0x40/0x78
> [405542.457703] [<ffffffff814ecc5f>] ? tcp_v4_rcv+0x484/0x797
> [405542.457761] [<ffffffff814d11c7>] ? ip_local_deliver_finish+0xab/0x139
> [405542.457827] [<ffffffff814ae2b3>] ? __netif_receive_skb+0x31c/0x349
> [405542.457894] [<ffffffff814aec82>] ? netif_receive_skb+0x67/0x6d
> [405542.457953] [<ffffffff814af1fb>] ? napi_gro_receive+0x9d/0xab
> [405542.458021] [<ffffffff814aed57>] ? napi_skb_finish+0x1c/0x31
> [405542.458080] [<ffffffff813e4248>] ? igb_poll+0x7d5/0xb2e
> [405542.458138] [<ffffffff813e432f>] ? igb_poll+0x8bc/0xb2e
> [405542.458196] [<ffffffff813e211a>] ? igb_msix_ring+0x6e/0x75
> [405542.458254] [<ffffffff8106749c>] ? handle_IRQ_event+0x51/0x119
> [405542.458313] [<ffffffff814af337>] ? net_rx_action+0xa7/0x212
> [405542.458371] [<ffffffff8103b6c2>] ? __do_softirq+0xbe/0x184
> [405542.458430] [<ffffffff8100364c>] ? call_softirq+0x1c/0x28
> [405542.458488] [<ffffffff81005085>] ? do_softirq+0x31/0x63
> [405542.458545] [<ffffffff8103b56c>] ? irq_exit+0x36/0x78
> [405542.458602] [<ffffffff81004784>] ? do_IRQ+0x98/0xae
> [405542.458660] [<ffffffff81562ed3>] ? ret_from_intr+0x0/0xe
> [405542.458717]<EOI>
> [<ffffffff81009a41>] ? mwait_idle+0xb9/0xf3
> [405542.458810] [<ffffffff81001c6e>] ? cpu_idle+0x57/0x8d
> [405542.458867] [<ffffffff81801c49>] ? start_kernel+0x34e/0x35a
> [405542.458926] [<ffffffff81801398>] ? x86_64_start_kernel+0xf3/0xf9
>
> --
> 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
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* RE: [RFC 2/3] RDMA/cma: Add support for netlink statistics export
From: Hefty, Sean @ 2011-05-13 17:21 UTC (permalink / raw)
To: Roland Dreier, netdev@vger.kernel.org, linux-rdma@vger.kernel.org
In-Reply-To: <1305303525-11113-3-git-send-email-roland@kernel.org>
> +struct rdma_cm_id_stats {
> + __u32 qp_num;
> + __u32 bound_dev_if;
> + __u32 port_space;
> + __s32 pid;
> + __u8 cm_state;
> + __u8 node_type;
> + __u8 port_num;
> + __u8 reserved;
> +};
We may also want to add qp_type
^ permalink raw reply
* Re: AAARGH bisection is hard (Re: [2.6.39 regression] X locks up hard right after logging in)
From: Andrew Lutomirski @ 2011-05-13 17:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Christian Couder, linux-kernel, netdev, git, Shuang He
In-Reply-To: <BANLkTimE2GkkhcFZtNrYZASWp0LDhUx=GQ@mail.gmail.com>
On Fri, May 13, 2011 at 12:11 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Fri, May 13, 2011 at 7:56 AM, Andrew Lutomirski <luto@mit.edu> wrote:
>>
>> So what I really want is a fancy version of git bisect that makes no
>> assumptions about the relationship of good and bad commits in the
>> graph and just finds me a commit that is bad but for which all parents
>> are good or vice versa.
>
> Ehh. That's the "non-fancy" way of testing, I'm afraid: if you cannot
> make assumption about the relationship between good and bad commits,
> then you have to test _every_ commit.
Actually, I disagree. I suspect, although I haven't convinced myself
very well yet, that if you assume that the bug was caused one or more
times by some commit C that works but where all of C's parents don't
work (or vice versa), then there exists an algorithm that, at least
for most histories, will find such a commit in polylog tries given a
starting commit that works and another one that fails. But I have to
do real work before I think too much more about that.
That being said, even the fairly weak requirement I wanted wasn't really true...
[I said in a different email:]
>
> In conclusion, I found the problem. It's a clusterfuck and I think
> there's no way that any bisection tool under any sane assumptions
> could have found it. Patch coming in a couple seconds b/c I think it
> needs to go in to 2.6.39.
I should clarify what the problem was for people who don't want to dig
around the archives:
I have a Sandy Bridge box, which means that I need to run a recent
kernel for things to work decently. The bug was introduced once way
back in the depths of time (i.e. before any kernel that I ever tried
since I got the machine). It was fixed shortly before 2.6.38 by
commit A. It was reintroduced in a merge B that was a little past A.
B went in to 2.6.39-something via airlied's tree. B's other parent
was bad because it didn't contain A. It looks like this:
-------------------------------.
\
(bad pre-2.6.38-rc2)--. \ (etc)
\ \
.--(good)-----B--(bad)-. \
/ \ \
(bad)---A--(good)--v2.6.38---------x-x-v2.6.39-rc7
(A is a1656b9090f7008d2941c314f5a64724bea2ae37 and B is
47ae63e0c2e5fdb582d471dc906eb29be94c732f)
The offending commit is B, but the bisection is screwed, because the
series of nonworking commits dangling off B looks just like any other
series of nonworking commits like the top line that have nothing to do
with the problem. Sure enough, my bisection ended up wandering into
dark corners (like the networking tree), which were innocent.
I found the problem by manually bisecting the --first-parent chain
from v2.6.39-rc7 to v2.6.38 to figure out that the problem came from a
drm merge and then noticing that something was screwed up when the
bisection pointed to a commit (in the right driver, even) that wasn't
the problem. (I even tried reverting it to no avail.) Bisection was
*sure* it was the problem, though, because its parent was in v2.6.38.
I thought that maybe the problem had been introduced more than once,
so I tried v2.6.38-rc5, and it *failed*. (That's what caused a lot of
my confusion the first time around -- lots of commits that were "good"
(in the sense that they would work if merged correctly into the
v2.6.39 branch before B got there) failed instead.
So I bisected between v2.6.38 and v2.6.38-rc5 to find the commit that
fixed the problem, since there had to be something. Once I found it,
a bunch of confused calls to git blame found the merge that undid the
fix.
> Think of it as a compression method: it generates the smallest
> possible set of test points for you. But it's a "lossy" compression -
> you don't test everything. And it's extreme: it boils down 10k commit
> events to about 13 bisection events. If anything goes wrong (like the
> bug not being entirely repeatable, or the bug comes and goes), it will
> give the wrong answer.
As I just learned :)
--Andy
^ permalink raw reply
* Re: [RFC 1/3] RDMA: Add netlink infrastructure
From: Roland Dreier @ 2011-05-13 17:26 UTC (permalink / raw)
To: Hefty, Sean
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1828884A29C6694DAF28B7E6B8A82373F414-P5GAC/sN6hmkrb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
On Fri, May 13, 2011 at 10:19 AM, Hefty, Sean <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
>> +#define NETLINK_INFINIBAND 20
>
> Would NETLINK_RDMA be better?
Yes, I tried to change all the externally visible examples of IB to RDMA, but I
missed that one (I figure internal kernel APIs can be cleaned up
later). I'll update my tree.
- R.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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
* Re: kernel BUG at net/ipv4/tcp_output.c:1006!
From: Eric Dumazet @ 2011-05-13 17:27 UTC (permalink / raw)
To: TB; +Cc: linux-kernel, netdev
In-Reply-To: <4DCD6658.3020901@techboom.com>
Le vendredi 13 mai 2011 à 13:11 -0400, TB a écrit :
> This is the 2.6.38.5 kernel with the patch in
> [PATCH] tcp_cubic: limit delayed_ack ratio to prevent divide error
>
> Had this crash a few days ago, but never got any response to subsequent
> emails. Another server crashed today with a network related backtrace,
> but netconsole did not work.
I understand you are anxious, but sending this message to lkml will
hardly find more people to look at this problem.
You sent your messages two days ago on netdev, thats not like its one or
two months.
Please send us full disassembly of tcp_fragment (from vmlinux file)
^ permalink raw reply
* Re: [RFC 1/3] RDMA: Add netlink infrastructure
From: Joe Perches @ 2011-05-13 17:36 UTC (permalink / raw)
To: Bart Van Assche
Cc: Roland Dreier, Nir Muchtar, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <BANLkTikpzn6R-QH__dtmwz=fO1QMUN+qag-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, 2011-05-13 at 19:18 +0200, Bart Van Assche wrote:
> On Fri, May 13, 2011 at 6:44 PM, Joe Perches <joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org> wrote:
> > On Fri, 2011-05-13 at 09:18 -0700, Roland Dreier wrote:
> >> From: Roland Dreier <roland-BHEL68pLQRGGvPXPguhicg@public.gmane.org>
> >> [Dave please do not apply even if this ends up in netdev patchwork!]
> >> diff --git a/drivers/infiniband/core/netlink.c b/drivers/infiniband/core/netlink.c
> > []
> >> +#define pr_fmt(fmt) "%s:%s: " fmt, KBUILD_MODNAME, __func__
> > Using #define pr_fmt(fmt) KBUILD_MODNAME ":%s: " fmt, __func__
> > generally produces smaller overall object size, especially
> > at 64 bit.
> > For instance, here's the size of netlink.o at 32 bit:
> > $ size drivers/infiniband/core/netlink.o.*
> > text data bss dec hex filename
> > 2663 153 736 3552 de0 drivers/infiniband/core/netlink.o.old
> > 2640 153 736 3529 dc9 drivers/infiniband/core/netlink.o.new
> > Also, I rarely find __func__ useful in message output.
> > It may be more useful for active development/debugging.
> A recent dynamic debug patch made it possible to enable/disable at
> runtime whether or not the function name (and more) should be included
> in the output. See also http://lwn.net/Articles/434833/ for more
> information.
One long term goal for me is a generic run-time mechanism
to prefix all pr_<level> uses not just the <foo>_dbg ones
with or without module or function name.
It will also allow the removal of all the uses of
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
New #define pr_fmt lines need to be added to the current
files that use pr_<level> without a prefix so it could
take awhile.
Eventually.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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
* Re: [PATCH net-next] netdevice.h: Align struct netdevices members
From: Eric Dumazet @ 2011-05-13 17:47 UTC (permalink / raw)
To: David Miller; +Cc: joe, netdev
In-Reply-To: <20110512.150539.189697453.davem@davemloft.net>
Le jeudi 12 mai 2011 à 15:05 -0700, David Miller a écrit :
> I think this is sane, Eric do you still have objections?
No objection, thanks
^ 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