On 09/03/2015 05:23 PM, Jason Gunthorpe wrote:
> On Thu, Sep 03, 2015 at 05:17:31PM -0400, Doug Ledford wrote:
>> On 08/27/2015 07:33 PM, Jason Gunthorpe wrote:
>>> On Wed, Aug 26, 2015 at 12:43:15PM -0400, Doug Ledford wrote:
>>>
That still takes us back to the fact that the locking changes a
On Thu, Sep 03, 2015 at 05:17:31PM -0400, Doug Ledford wrote:
> On 08/27/2015 07:33 PM, Jason Gunthorpe wrote:
> > On Wed, Aug 26, 2015 at 12:43:15PM -0400, Doug Ledford wrote:
> >
> >> That still takes us back to the fact that the locking changes are
> >> unneeded. I'm not opposed to them, but a
On 08/27/2015 07:33 PM, Jason Gunthorpe wrote:
> On Wed, Aug 26, 2015 at 12:43:15PM -0400, Doug Ledford wrote:
>
>> That still takes us back to the fact that the locking changes are
>> unneeded. I'm not opposed to them, but as you mentioned in your first
>> email, they should go with the changes
On Fri, 21 Aug 2015, Jason Gunthorpe wrote:
> Even though we don't expect the group to be created by the SM we
> sill need to provide all the parameters to force the SM to validate
> they are correct.
Just ran into this issue with Redhat 7.1. Earlier code base. Same
problem. qkey etc not set. OFE
On Wed, Aug 26, 2015 at 12:43:15PM -0400, Doug Ledford wrote:
> That still takes us back to the fact that the locking changes are
> unneeded. I'm not opposed to them, but as you mentioned in your first
> email, they should go with the changes that require them, and none of
> the changes in the fi
On 08/26/2015 12:18 PM, Jason Gunthorpe wrote:
> On Wed, Aug 26, 2015 at 09:37:50AM -0400, Doug Ledford wrote:
>
>>> Sure looks like these two race:
>>>
>>> if (test_and_set_bit(IPOIB_MCAST_FLAG_ATTACHED,
>>> &mcast->flags))..
>>> clear_bit(IPOIB_MCAST_FLAG_FOUND, &mcast->
On Wed, Aug 26, 2015 at 09:37:50AM -0400, Doug Ledford wrote:
> > Sure looks like these two race:
> >
> > if (test_and_set_bit(IPOIB_MCAST_FLAG_ATTACHED,
> > &mcast->flags))..
> > clear_bit(IPOIB_MCAST_FLAG_FOUND, &mcast->flags);
> >
> > Resulting in corruption of the fl
On 08/25/2015 03:49 PM, Jason Gunthorpe wrote:
> On Tue, Aug 25, 2015 at 02:35:27PM -0400, Doug Ledford wrote:
>> On 08/25/2015 02:22 PM, Jason Gunthorpe wrote:
>>> On Tue, Aug 25, 2015 at 01:50:05PM -0400, Doug Ledford wrote:
On 08/21/2015 07:34 PM, Jason Gunthorpe wrote:
> Even though we
On Tue, Aug 25, 2015 at 02:35:27PM -0400, Doug Ledford wrote:
> On 08/25/2015 02:22 PM, Jason Gunthorpe wrote:
> > On Tue, Aug 25, 2015 at 01:50:05PM -0400, Doug Ledford wrote:
> >> On 08/21/2015 07:34 PM, Jason Gunthorpe wrote:
> >>> Even though we don't expect the group to be created by the SM we
On 08/25/2015 02:22 PM, Jason Gunthorpe wrote:
> On Tue, Aug 25, 2015 at 01:50:05PM -0400, Doug Ledford wrote:
>> On 08/21/2015 07:34 PM, Jason Gunthorpe wrote:
>>> Even though we don't expect the group to be created by the SM we
>>> sill need to provide all the parameters to force the SM to valida
On Tue, Aug 25, 2015 at 01:50:05PM -0400, Doug Ledford wrote:
> On 08/21/2015 07:34 PM, Jason Gunthorpe wrote:
> > Even though we don't expect the group to be created by the SM we
> > sill need to provide all the parameters to force the SM to validate
> > they are correct.
>
> Why does this patch
On 08/21/2015 07:34 PM, Jason Gunthorpe wrote:
> Even though we don't expect the group to be created by the SM we
> sill need to provide all the parameters to force the SM to validate
> they are correct.
Why does this patch embed locking changes that, as far I can tell, are
not needed by the rest
On Tue, Aug 25, 2015 at 08:58:34AM -0400, Hal Rosenstock wrote:
> On 8/21/2015 7:34 PM, Jason Gunthorpe wrote:
> > Even though we don't expect the group to be created by the SM we
> > sill need to provide all the parameters to force the SM to validate
> > they are correct.
>
> Out of curiosity, ha
On 8/21/2015 7:34 PM, Jason Gunthorpe wrote:
> Even though we don't expect the group to be created by the SM we
> sill need to provide all the parameters to force the SM to validate
> they are correct.
Out of curiosity, has it been observed that there was inconsistency in
these additional IPoIB pa
Even though we don't expect the group to be created by the SM we
sill need to provide all the parameters to force the SM to validate
they are correct.
Signed-off-by: Jason Gunthorpe
---
drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 47 +-
1 file changed, 31 insertions(
15 matches
Mail list logo