And by the way, this current patch has a deadlock I think:
> @@ -724,6 +724,8 @@ int ipoib_ib_dev_down(struct net_device *dev, int flush)
> ipoib_dbg(priv, "downing ib_dev\n");
>
> clear_bit(IPOIB_FLAG_OPER_UP, &priv->flags);
> +cancel_delayed_work(&priv->carrier_on_task);
ip
> > > Hmm, or are you saying you can only get 1 event per registered range and
> > > allocate the thing on registration? That'd need some registration limit
> > > to avoid DoS scenarios.
> >
> > Yes, that's what I do. You're right, I should add a limit... although
> > their are lots of way
On Thu, 2009-09-17 at 08:03 -0700, Roland Dreier wrote:
> > Hmm, or are you saying you can only get 1 event per registered range and
> > allocate the thing on registration? That'd need some registration limit
> > to avoid DoS scenarios.
>
> Yes, that's what I do. You're right, I should add a li
> Hmm, or are you saying you can only get 1 event per registered range and
> allocate the thing on registration? That'd need some registration limit
> to avoid DoS scenarios.
Yes, that's what I do. You're right, I should add a limit... although
their are lots of ways for userspace to consume
> +if (ib_query_port(priv->ca, priv->port, &attr) ||
> +attr.state != IB_PORT_ACTIVE) {
> +ipoib_dbg(priv, "wait with carrier until IB port is active\n");
> +if (test_bit(IPOIB_FLAG_OPER_UP, &priv->flags))
> +queue_delayed_work(ipoib
On Thu, 2009-09-17 at 07:32 -0700, Roland Dreier wrote:
> > So getting those events in the kernel is no problem -- we have the MMU
> > notifier hooks that tell us exactly what we need to know. The issue is
> > purely the way userspace registers interest in address ranges, and how
> > to kernel
On Thu, 2009-09-17 at 07:24 -0700, Roland Dreier wrote:
> > Anton Blanchard suggested a while back that this might be integrated
> > with perf-counters, since perf-counters already does mmap() tracking and
> > also provides events through an mmap()'ed buffer.
> >
> > Has anybody looked into th
> So getting those events in the kernel is no problem -- we have the MMU
> notifier hooks that tell us exactly what we need to know. The issue is
> purely the way userspace registers interest in address ranges, and how
> to kernel returns the events.
>
> For perf counters it seems that one
> Anton Blanchard suggested a while back that this might be integrated
> with perf-counters, since perf-counters already does mmap() tracking and
> also provides events through an mmap()'ed buffer.
>
> Has anybody looked into this?
I didn't see the original suggestion. Certainly hooking in
On Thu, 2009-09-10 at 21:38 -0700, Roland Dreier wrote:
> Linus, please consider pulling from
>
> master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
> ummunotify
>
> This tree is also available from kernel.org mirrors at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/
On Wed, Sep 16, 2009 at 4:46 PM, Or Gerlitz wrote:
>
> Bart Van Assche wrote:
>>
>> I would like to contact the author of the fourth patch. But unfortunately I
>> could not find any author information in that patch.
>
> yes, non signed and unreviewed patches is a common practice of ofed, does
>
On Wed, Sep 16, 2009 at 9:41 PM, Chris Worley wrote:
>
> On Wed, Sep 16, 2009 at 12:15 PM, Vladislav Bolkhovitin wrote:
> > Chris Worley, on 09/16/2009 12:51 AM wrote:
> > >
> > > On Tue, Sep 15, 2009 at 11:10 AM, Vladislav Bolkhovitin
> > > wrote:
> > > [ ... ]
> > > [ 357.250550] ib_srpt: srp
This patch fixes https://bugs.openfabrics.org/show_bug.cgi?id=1726
Multicast join can succeed even if IB port is down. This happens when OpenSM
runs on the same port as the requesting port. IPoIB on the other hand, calls
netif_carrier_on() when join succeeded without caring about the state of
the
13 matches
Mail list logo
