4.13 ib_mthca NULL pointer dereference with OpenSM

4.13 ib_mthca NULL pointer dereference with OpenSM

[Chris Blake]

Hello linux-rmda,

I recently upgraded one of my boxes to 4.13, and have started
experiencing issues with ib_mthca. To start, my setup is Infiniband
direct between 2 servers using older Mellanox Technologies MT25208
cards for ipoib as well as NFS over RDMA. After upgrading, the
following has been experienced:

1. On my NAS host running OpenSM, as soon as it starts I get a NULL
pointer dereference which makes infiniband unusable. [0] This only
occurs on kernel 4.13 or newer.

2. On my compute host not running OpenSM, connectivity works for a bit
but shortly after dmesg is full of the following message:
infiniband mthca0: ib_post_send_mad error
This occurs when my compute host is on kernel 4.13 or newer.

I went ahead and tested some mainline kernel versions on both of my
nodes, and here are my findings:
4.13.8 = NULL pointer dereference on NAS, IPoIB not working
4.12.14 = Works as expected
4.14.0-rc5 = NULL pointer dereference on NAS, IPoIB not working

I have tried to see if I could find the patch responsible for this,
but sadly I have not had much luck.

As for my systems, the following modules are loaded:
ib_uverbs
ib_umad
rdma_ucm
ib_mthca
ib_ipoib

Let me know if there is anything I can test to help diagnose what is
causing this issue.

Regards,
Chris Blake

[0]: https://gist.github.com/riptidewave93/48595b8bc3bca669251db7d8a8e8a803
--
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

Re: 4.13 ib_mthca NULL pointer dereference with OpenSM

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 1783 bytes --]

On Thu, Oct 26, 2017 at 12:17:18PM -0500, Chris Blake wrote:
> Hello linux-rmda,
>
> I recently upgraded one of my boxes to 4.13, and have started
> experiencing issues with ib_mthca. To start, my setup is Infiniband
> direct between 2 servers using older Mellanox Technologies MT25208
> cards for ipoib as well as NFS over RDMA. After upgrading, the
> following has been experienced:
>
> 1. On my NAS host running OpenSM, as soon as it starts I get a NULL
> pointer dereference which makes infiniband unusable. [0] This only
> occurs on kernel 4.13 or newer.
>
> 2. On my compute host not running OpenSM, connectivity works for a bit
> but shortly after dmesg is full of the following message:
> infiniband mthca0: ib_post_send_mad error
> This occurs when my compute host is on kernel 4.13 or newer.
>
> I went ahead and tested some mainline kernel versions on both of my
> nodes, and here are my findings:
> 4.13.8 = NULL pointer dereference on NAS, IPoIB not working
> 4.12.14 = Works as expected
> 4.14.0-rc5 = NULL pointer dereference on NAS, IPoIB not working
>
> I have tried to see if I could find the patch responsible for this,
> but sadly I have not had much luck.
>
> As for my systems, the following modules are loaded:
> ib_uverbs
> ib_umad
> rdma_ucm
> ib_mthca
> ib_ipoib
>
> Let me know if there is anything I can test to help diagnose what is
> causing this issue.

Do you have CONFIG_SECURITY_INFINIBAND in your .config?

Thanks

>
> Regards,
> Chris Blake
>
> [0]: https://gist.github.com/riptidewave93/48595b8bc3bca669251db7d8a8e8a803
> --
> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: 4.13 ib_mthca NULL pointer dereference with OpenSM

[Chris Blake]

On Sun, Oct 29, 2017 at 2:11 PM, Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>
> Do you have CONFIG_SECURITY_INFINIBAND in your .config?
>
> Thanks
>

Hello,

CONFIG_SECURITY_INFINIBAND is enabled on my kernel. All infiniband
config settings can be found here [0].

Thanks,
Chris Blake

[0]: https://gist.github.com/riptidewave93/b3b83c13e93ab3be4254c855885f5b3a
--
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

Re: 4.13 ib_mthca NULL pointer dereference with OpenSM

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 658 bytes --]

On Sun, Oct 29, 2017 at 02:35:23PM -0500, Chris Blake wrote:
> On Sun, Oct 29, 2017 at 2:11 PM, Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> >
> > Do you have CONFIG_SECURITY_INFINIBAND in your .config?
> >
> > Thanks
> >
>
> Hello,
>
> CONFIG_SECURITY_INFINIBAND is enabled on my kernel. All infiniband
> config settings can be found here [0].

I did another glance to try and find the patch which affected it, but
didn't really find it.

Can you please try to set CONFIG_SECURITY_INFINIBAND=n and see if it
helps?

Thanks

>
> Thanks,
> Chris Blake
>
> [0]: https://gist.github.com/riptidewave93/b3b83c13e93ab3be4254c855885f5b3a

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: 4.13 ib_mthca NULL pointer dereference with OpenSM

[Chris Blake]

On Mon, Oct 30, 2017 at 2:19 AM, Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>
> Can you please try to set CONFIG_SECURITY_INFINIBAND=n and see if it
> helps?
>
> Thanks
>

Hello Leon,

I went ahead and set CONFIG_SECURITY_INFINIBAND=n in my kernel, and so
far the issue seems resolved. I will run this for a week or so and
will get back to you, but things are looking promising. :)

Regards,
Chris Blake
--
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

Re: 4.13 ib_mthca NULL pointer dereference with OpenSM

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 756 bytes --]

On Mon, Oct 30, 2017 at 01:39:42PM -0500, Chris Blake wrote:
> On Mon, Oct 30, 2017 at 2:19 AM, Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> >
> > Can you please try to set CONFIG_SECURITY_INFINIBAND=n and see if it
> > helps?
> >
> > Thanks
> >
>
> Hello Leon,
>
> I went ahead and set CONFIG_SECURITY_INFINIBAND=n in my kernel, and so
> far the issue seems resolved. I will run this for a week or so and
> will get back to you, but things are looking promising. :)

Thanks

>
> Regards,
> Chris Blake
> --
> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: 4.13 ib_mthca NULL pointer dereference with OpenSM

[Jason Gunthorpe]

On Mon, Oct 30, 2017 at 01:39:42PM -0500, Chris Blake wrote:
> On Mon, Oct 30, 2017 at 2:19 AM, Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> >
> > Can you please try to set CONFIG_SECURITY_INFINIBAND=n and see if it
> > helps?
> >
> > Thanks
> >
> 
> Hello Leon,
> 
> I went ahead and set CONFIG_SECURITY_INFINIBAND=n in my kernel, and so
> far the issue seems resolved. I will run this for a week or so and
> will get back to you, but things are looking promising. :)

I certainly don't expect this setting to break any drivers..

Parav?

Jason
--
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

RE: 4.13 ib_mthca NULL pointer dereference with OpenSM

[Parav Pandit]

Hi Jason,

> -----Original Message-----
> From: Jason Gunthorpe [mailto:jgg-uk2M96/98Pc@public.gmane.org]
> Sent: Monday, October 30, 2017 6:02 PM
> To: Chris Blake <chrisrblake93-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>; linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Parav
> Pandit <parav-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> Subject: Re: 4.13 ib_mthca NULL pointer dereference with OpenSM
> 
> On Mon, Oct 30, 2017 at 01:39:42PM -0500, Chris Blake wrote:
> > On Mon, Oct 30, 2017 at 2:19 AM, Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> wrote:
> > >
> > > Can you please try to set CONFIG_SECURITY_INFINIBAND=n and see if it
> > > helps?
> > >
> > > Thanks
> > >
> >
> > Hello Leon,
> >
> > I went ahead and set CONFIG_SECURITY_INFINIBAND=n in my kernel, and so
> > far the issue seems resolved. I will run this for a week or so and
> > will get back to you, but things are looking promising. :)
> 
> I certainly don't expect this setting to break any drivers..
>
I looked the back trace - happening in freeing ib_free_recv_mad().
It doesn't look a driver issue certainly.

Post_send failure seems to indicate that security enforcement checks likely would have failed on QP0/1.
I tried ib_ipoib and rping with 4.13.10 and ConnectX4 but that didn't help with reproduction.
I tried injecting error locally on recv mad, based on suspect and I was able to crash a host and with below patch I was able to avoid it.

I am yet to review my below patch with Dan as he did most security dev, but I suspect this might be the cause where rmpp list is not initialized and mad processing is continued when security check fails.

Let see if Chris has same issue or different one.

Chris,
Can you try below patch and see if that avoids the crash?

diff --git a/drivers/infiniband/core/mad.c b/drivers/infiniband/core/mad.c
index f8f53bb..cb91245 100644
--- a/drivers/infiniband/core/mad.c
+++ b/drivers/infiniband/core/mad.c
@@ -1974,14 +1974,15 @@ static void ib_mad_complete_recv(struct ib_mad_agent_private *mad_agent_priv,
        unsigned long flags;
        int ret;

+       INIT_LIST_HEAD(&mad_recv_wc->rmpp_list);
        ret = ib_mad_enforce_security(mad_agent_priv,
                                      mad_recv_wc->wc->pkey_index);
        if (ret) {
                ib_free_recv_mad(mad_recv_wc);
                deref_mad_agent(mad_agent_priv);
+               return;
        }

-       INIT_LIST_HEAD(&mad_recv_wc->rmpp_list);
        list_add(&mad_recv_wc->recv_buf.list, &mad_recv_wc->rmpp_list);
--
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

Re: 4.13 ib_mthca NULL pointer dereference with OpenSM

[Jason Gunthorpe]

On Tue, Oct 31, 2017 at 03:16:42AM +0000, Parav Pandit wrote:

> I am yet to review my below patch with Dan as he did most security
> dev, but I suspect this might be the cause where rmpp list is not
> initialized and mad processing is continued when security check
> fails.

This patch sure looks needed to me, ib_free_recv_mad touches
rmpp_list, so if it needs initializion then it certainly has to be
done earlier..

Adding the new return sure makes alot of sense as well..

Hal, Ira, would you check this routine too? kernel oops's are bad..

> diff --git a/drivers/infiniband/core/mad.c b/drivers/infiniband/core/mad.c
> index f8f53bb..cb91245 100644
> +++ b/drivers/infiniband/core/mad.c
> @@ -1974,14 +1974,15 @@ static void ib_mad_complete_recv(struct ib_mad_agent_private *mad_agent_priv,
>         unsigned long flags;
>         int ret;
> 
> +       INIT_LIST_HEAD(&mad_recv_wc->rmpp_list);
>         ret = ib_mad_enforce_security(mad_agent_priv,
>                                       mad_recv_wc->wc->pkey_index);
>         if (ret) {
>                 ib_free_recv_mad(mad_recv_wc);
>                 deref_mad_agent(mad_agent_priv);
> +               return;
>         }
> 
> -       INIT_LIST_HEAD(&mad_recv_wc->rmpp_list);
>         list_add(&mad_recv_wc->recv_buf.list, &mad_recv_wc->rmpp_list);
--
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

Re: 4.13 ib_mthca NULL pointer dereference with OpenSM

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 1480 bytes --]

On Mon, Oct 30, 2017 at 10:24:35PM -0600, Jason Gunthorpe wrote:
> On Tue, Oct 31, 2017 at 03:16:42AM +0000, Parav Pandit wrote:
>
> > I am yet to review my below patch with Dan as he did most security
> > dev, but I suspect this might be the cause where rmpp list is not
> > initialized and mad processing is continued when security check
> > fails.
>
> This patch sure looks needed to me, ib_free_recv_mad touches
> rmpp_list, so if it needs initializion then it certainly has to be
> done earlier..

Right, it aligns with my analysis too.

>
> Adding the new return sure makes alot of sense as well..
>
> Hal, Ira, would you check this routine too? kernel oops's are bad..
>
> > diff --git a/drivers/infiniband/core/mad.c b/drivers/infiniband/core/mad.c
> > index f8f53bb..cb91245 100644
> > +++ b/drivers/infiniband/core/mad.c
> > @@ -1974,14 +1974,15 @@ static void ib_mad_complete_recv(struct ib_mad_agent_private *mad_agent_priv,
> >         unsigned long flags;
> >         int ret;
> >
> > +       INIT_LIST_HEAD(&mad_recv_wc->rmpp_list);
> >         ret = ib_mad_enforce_security(mad_agent_priv,
> >                                       mad_recv_wc->wc->pkey_index);
> >         if (ret) {
> >                 ib_free_recv_mad(mad_recv_wc);
> >                 deref_mad_agent(mad_agent_priv);
> > +               return;
> >         }
> >
> > -       INIT_LIST_HEAD(&mad_recv_wc->rmpp_list);
> >         list_add(&mad_recv_wc->recv_buf.list, &mad_recv_wc->rmpp_list);

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: 4.13 ib_mthca NULL pointer dereference with OpenSM

[Hal Rosenstock]

On 10/31/2017 12:24 AM, Jason Gunthorpe wrote:
> On Tue, Oct 31, 2017 at 03:16:42AM +0000, Parav Pandit wrote:
> 
>> I am yet to review my below patch with Dan as he did most security
>> dev, but I suspect this might be the cause where rmpp list is not
>> initialized and mad processing is continued when security check
>> fails.
> 
> This patch sure looks needed to me, ib_free_recv_mad touches
> rmpp_list, so if it needs initializion then it certainly has to be
> done earlier..
Agreed.

> Adding the new return sure makes alot of sense as well..
> 
> Hal, Ira, would you check this routine too? kernel oops's are bad..

Patch looks needed for just the point that Parav made above (that if
security check fails, then ib_free_recv_mad will cause the
mad_recv_wc->rmpp_list to be accessed so it needs to be initialized
before security is enforced).

I don't have mthca to try this. Maybe Chris can try this patch (with
CONFIG_SECURITY_INFINIBAND=y).

-- Hal

>> diff --git a/drivers/infiniband/core/mad.c b/drivers/infiniband/core/mad.c
>> index f8f53bb..cb91245 100644
>> +++ b/drivers/infiniband/core/mad.c
>> @@ -1974,14 +1974,15 @@ static void ib_mad_complete_recv(struct ib_mad_agent_private *mad_agent_priv,
>>         unsigned long flags;
>>         int ret;
>>
>> +       INIT_LIST_HEAD(&mad_recv_wc->rmpp_list);
>>         ret = ib_mad_enforce_security(mad_agent_priv,
>>                                       mad_recv_wc->wc->pkey_index);
>>         if (ret) {
>>                 ib_free_recv_mad(mad_recv_wc);
>>                 deref_mad_agent(mad_agent_priv);
>> +               return;
>>         }
>>
>> -       INIT_LIST_HEAD(&mad_recv_wc->rmpp_list);
>>         list_add(&mad_recv_wc->recv_buf.list, &mad_recv_wc->rmpp_list);
> --
> 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
> 
--
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

Re: 4.13 ib_mthca NULL pointer dereference with OpenSM

[Daniel Jurgens]

On 10/31/2017 7:49 AM, Hal Rosenstock wrote:
> On 10/31/2017 12:24 AM, Jason Gunthorpe wrote:
>> On Tue, Oct 31, 2017 at 03:16:42AM +0000, Parav Pandit wrote:
>>
>>> I am yet to review my below patch with Dan as he did most security
>>> dev, but I suspect this might be the cause where rmpp list is not
>>> initialized and mad processing is continued when security check
>>> fails.
>> This patch sure looks needed to me, ib_free_recv_mad touches
>> rmpp_list, so if it needs initializion then it certainly has to be
>> done earlier..
> Agreed.
>
>> Adding the new return sure makes alot of sense as well..
>>
>> Hal, Ira, would you check this routine too? kernel oops's are bad..
> Patch looks needed for just the point that Parav made above (that if
> security check fails, then ib_free_recv_mad will cause the
> mad_recv_wc->rmpp_list to be accessed so it needs to be initialized
> before security is enforced).

Agree the patch is needed regardless.

>
> I don't have mthca to try this. Maybe Chris can try this patch (with
> CONFIG_SECURITY_INFINIBAND=y).

Chris, are you running with SELinux enabled? If this addresses your issue it means permission is denied, so once the crash is resolved additional policy will be required in order for it to work as expected.

> -- Hal
>
>>> diff --git a/drivers/infiniband/core/mad.c b/drivers/infiniband/core/mad.c
>>> index f8f53bb..cb91245 100644
>>> +++ b/drivers/infiniband/core/mad.c
>>> @@ -1974,14 +1974,15 @@ static void ib_mad_complete_recv(struct ib_mad_agent_private *mad_agent_priv,
>>>         unsigned long flags;
>>>         int ret;
>>>
>>> +       INIT_LIST_HEAD(&mad_recv_wc->rmpp_list);
>>>         ret = ib_mad_enforce_security(mad_agent_priv,
>>>                                       mad_recv_wc->wc->pkey_index);
>>>         if (ret) {
>>>                 ib_free_recv_mad(mad_recv_wc);
>>>                 deref_mad_agent(mad_agent_priv);
>>> +               return;
>>>         }
>>>
>>> -       INIT_LIST_HEAD(&mad_recv_wc->rmpp_list);
>>>         list_add(&mad_recv_wc->recv_buf.list, &mad_recv_wc->rmpp_list);
>> --
>> 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  https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvger.kernel.org%2Fmajordomo-info.html&data=02%7C01%7Cdanielj%40mellanox.com%7C0c1d5cc98d224d5f21ca08d5205dceb0%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636450509634819485&sdata=RANgNBE48saDXft%2BfCIIS3qWZT8PK5imlXnoCKnWdkU%3D&reserved=0
>>

--
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

Re: 4.13 ib_mthca NULL pointer dereference with OpenSM

[Jason Gunthorpe]

On Tue, Oct 31, 2017 at 10:01:49AM -0500, Daniel Jurgens wrote:

> >> Adding the new return sure makes alot of sense as well..
> >>
> >> Hal, Ira, would you check this routine too? kernel oops's are bad..
> > Patch looks needed for just the point that Parav made above (that if
> > security check fails, then ib_free_recv_mad will cause the
> > mad_recv_wc->rmpp_list to be accessed so it needs to be initialized
> > before security is enforced).
> 
> Agree the patch is needed regardless.

Someone please send it..

> > I don't have mthca to try this. Maybe Chris can try this patch (with
> > CONFIG_SECURITY_INFINIBAND=y).
> 
> Chris, are you running with SELinux enabled? If this addresses your issue it means permission is denied, so once the crash is resolved additional policy will be required in order for it to work as expected.

If Chris has selinux turned on in his distro would you expect this
test to just fail? Doesn't that mean we have missed installing security labels
for things like opensm?

Jason
--
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

Re: 4.13 ib_mthca NULL pointer dereference with OpenSM

[Daniel Jurgens]

On 10/31/2017 10:09 AM, Jason Gunthorpe wrote:
> On Tue, Oct 31, 2017 at 10:01:49AM -0500, Daniel Jurgens wrote:
>
>>>> Adding the new return sure makes alot of sense as well..
>>>>
>>>> Hal, Ira, would you check this routine too? kernel oops's are bad..
>>> Patch looks needed for just the point that Parav made above (that if
>>> security check fails, then ib_free_recv_mad will cause the
>>> mad_recv_wc->rmpp_list to be accessed so it needs to be initialized
>>> before security is enforced).
>> Agree the patch is needed regardless.
> Someone please send it..
>
>>> I don't have mthca to try this. Maybe Chris can try this patch (with
>>> CONFIG_SECURITY_INFINIBAND=y).
>> Chris, are you running with SELinux enabled? If this addresses your issue it means permission is denied, so once the crash is resolved additional policy will be required in order for it to work as expected.
> If Chris has selinux turned on in his distro would you expect this
> test to just fail? Doesn't that mean we have missed installing security labels
> for things like opensm?
I suspect his policy doesn't have have the necessary allow rules for opensm to receive MADs.
> Jason


--
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

Re: 4.13 ib_mthca NULL pointer dereference with OpenSM

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 1305 bytes --]

On Tue, Oct 31, 2017 at 09:09:01AM -0600, Jason Gunthorpe wrote:
> On Tue, Oct 31, 2017 at 10:01:49AM -0500, Daniel Jurgens wrote:
>
> > >> Adding the new return sure makes alot of sense as well..
> > >>
> > >> Hal, Ira, would you check this routine too? kernel oops's are bad..
> > > Patch looks needed for just the point that Parav made above (that if
> > > security check fails, then ib_free_recv_mad will cause the
> > > mad_recv_wc->rmpp_list to be accessed so it needs to be initialized
> > > before security is enforced).
> >
> > Agree the patch is needed regardless.
>
> Someone please send it..

Parav/Daniel,

Please send it directly to the mailing list.

>
> > > I don't have mthca to try this. Maybe Chris can try this patch (with
> > > CONFIG_SECURITY_INFINIBAND=y).
> >
> > Chris, are you running with SELinux enabled? If this addresses your issue it means permission is denied, so once the crash is resolved additional policy will be required in order for it to work as expected.
>
> If Chris has selinux turned on in his distro would you expect this
> test to just fail? Doesn't that mean we have missed installing security labels
> for things like opensm?

Chris has SELinux enabled, see his gist: https://gist.github.com/riptidewave93/b3b83c13e93ab3be4254c855885f5b3a

Thanks

>
> Jason

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: 4.13 ib_mthca NULL pointer dereference with OpenSM

[Chris Blake]

On Tue, Oct 31, 2017 at 10:15 AM, Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Tue, Oct 31, 2017 at 09:09:01AM -0600, Jason Gunthorpe wrote:
>> On Tue, Oct 31, 2017 at 10:01:49AM -0500, Daniel Jurgens wrote:
>>
>> > >> Adding the new return sure makes alot of sense as well..
>> > >>
>> > >> Hal, Ira, would you check this routine too? kernel oops's are bad..
>> > > Patch looks needed for just the point that Parav made above (that if
>> > > security check fails, then ib_free_recv_mad will cause the
>> > > mad_recv_wc->rmpp_list to be accessed so it needs to be initialized
>> > > before security is enforced).
>> >
>> > Agree the patch is needed regardless.
>>
>> Someone please send it..
>
> Parav/Daniel,
>
> Please send it directly to the mailing list.
>
>>
>> > > I don't have mthca to try this. Maybe Chris can try this patch (with
>> > > CONFIG_SECURITY_INFINIBAND=y).
>> >
>> > Chris, are you running with SELinux enabled? If this addresses your issue it means permission is denied, so once the crash is resolved additional policy will be required in order for it to work as expected.
>>
>> If Chris has selinux turned on in his distro would you expect this
>> test to just fail? Doesn't that mean we have missed installing security labels
>> for things like opensm?
>
> Chris has SELinux enabled, see his gist: https://gist.github.com/riptidewave93/b3b83c13e93ab3be4254c855885f5b3a
>
> Thanks
>
>>
>> Jason

I applied this patch and re-enabled CONFIG_SECURITY_INFINIBAND, and
have a kernel build in progress. I will run this for a few days and
will report back my findings.

As for SELinux, it's not being used on my systems at this time, but I
am using apparmor for some lxc containers.

Regards,
Chris Blake
--
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

Re: 4.13 ib_mthca NULL pointer dereference with OpenSM

[Daniel Jurgens]

On 10/31/2017 10:15 AM, Leon Romanovsky wrote:
> On Tue, Oct 31, 2017 at 09:09:01AM -0600, Jason Gunthorpe wrote:
>> On Tue, Oct 31, 2017 at 10:01:49AM -0500, Daniel Jurgens wrote:
>>
>>>>> Adding the new return sure makes alot of sense as well..
>>>>>
>>>>> Hal, Ira, would you check this routine too? kernel oops's are bad..
>>>> Patch looks needed for just the point that Parav made above (that if
>>>> security check fails, then ib_free_recv_mad will cause the
>>>> mad_recv_wc->rmpp_list to be accessed so it needs to be initialized
>>>> before security is enforced).
>>> Agree the patch is needed regardless.
>> Someone please send it..
> Parav/Daniel,
>
> Please send it directly to the mailing list.
>
>>>> I don't have mthca to try this. Maybe Chris can try this patch (with
>>>> CONFIG_SECURITY_INFINIBAND=y).
>>> Chris, are you running with SELinux enabled? If this addresses your issue it means permission is denied, so once the crash is resolved additional policy will be required in order for it to work as expected.
>> If Chris has selinux turned on in his distro would you expect this
>> test to just fail? Doesn't that mean we have missed installing security labels
>> for things like opensm?
> Chris has SELinux enabled, see his gist: https://gist.github.com/riptidewave93/b3b83c13e93ab3be4254c855885f5b3a

That doesn't indicate if he has SELinux enabled or not, just that CONFIG_SECURITY_INFINIBAND is enabled.  Also, even if SELinux enabled in the kernel config it must be turned on via /etc/selinux/config, and also set into enforcing mode, if it were to cause this problem.  There's no enough info there to determine any of that.

> Thanks
>
>> Jason


--
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

Re: 4.13 ib_mthca NULL pointer dereference with OpenSM

[Chris Blake]

On Tue, Oct 31, 2017 at 10:20 AM, Daniel Jurgens <danielj-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> wrote:
> On 10/31/2017 10:15 AM, Leon Romanovsky wrote:
>> On Tue, Oct 31, 2017 at 09:09:01AM -0600, Jason Gunthorpe wrote:
>>> On Tue, Oct 31, 2017 at 10:01:49AM -0500, Daniel Jurgens wrote:
>>>
>>>>>> Adding the new return sure makes alot of sense as well..
>>>>>>
>>>>>> Hal, Ira, would you check this routine too? kernel oops's are bad..
>>>>> Patch looks needed for just the point that Parav made above (that if
>>>>> security check fails, then ib_free_recv_mad will cause the
>>>>> mad_recv_wc->rmpp_list to be accessed so it needs to be initialized
>>>>> before security is enforced).
>>>> Agree the patch is needed regardless.
>>> Someone please send it..
>> Parav/Daniel,
>>
>> Please send it directly to the mailing list.
>>
>>>>> I don't have mthca to try this. Maybe Chris can try this patch (with
>>>>> CONFIG_SECURITY_INFINIBAND=y).
>>>> Chris, are you running with SELinux enabled? If this addresses your issue it means permission is denied, so once the crash is resolved additional policy will be required in order for it to work as expected.
>>> If Chris has selinux turned on in his distro would you expect this
>>> test to just fail? Doesn't that mean we have missed installing security labels
>>> for things like opensm?
>> Chris has SELinux enabled, see his gist: https://gist.github.com/riptidewave93/b3b83c13e93ab3be4254c855885f5b3a
>
> That doesn't indicate if he has SELinux enabled or not, just that CONFIG_SECURITY_INFINIBAND is enabled.  Also, even if SELinux enabled in the kernel config it must be turned on via /etc/selinux/config, and also set into enforcing mode, if it were to cause this problem.  There's no enough info there to determine any of that.
>
>> Thanks
>>
>>> Jason
>
>

Hello All,

I have installed the kernel with the mentioned patch, as well as
CONFIG_SECURITY_INFINIBAND enabled. Sadly I am back to the issue where
my compute node is reporting:

kernel: infiniband mthca0: ib_post_send_mad error

As soon as I roll back to a kernel with CONFIG_SECURITY_INFINIBAND
disabled, the issue goes away and things work as expected.

Regards,
Chris Blake
--
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

RE: 4.13 ib_mthca NULL pointer dereference with OpenSM

[Parav Pandit]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 3439 bytes --]

Hi Chris,

> -----Original Message-----
> From: Chris Blake [mailto:chrisrblake93@gmail.com]
> Sent: Tuesday, October 31, 2017 12:50 PM
> To: Daniel Jurgens <danielj@mellanox.com>
> Cc: Leon Romanovsky <leon@kernel.org>; Jason Gunthorpe <jgg@ziepe.ca>;
> Hal Rosenstock <hal@dev.mellanox.co.il>; Parav Pandit
> <parav@mellanox.com>; linux-rdma@vger.kernel.org; Hal Rosenstock
> <hal@mellanox.com>; Ira Weiny <ira.weiny@intel.com>
> Subject: Re: 4.13 ib_mthca NULL pointer dereference with OpenSM
> 
> On Tue, Oct 31, 2017 at 10:20 AM, Daniel Jurgens <danielj@mellanox.com>
> wrote:
> > On 10/31/2017 10:15 AM, Leon Romanovsky wrote:
> >> On Tue, Oct 31, 2017 at 09:09:01AM -0600, Jason Gunthorpe wrote:
> >>> On Tue, Oct 31, 2017 at 10:01:49AM -0500, Daniel Jurgens wrote:
> >>>
> >>>>>> Adding the new return sure makes alot of sense as well..
> >>>>>>
> >>>>>> Hal, Ira, would you check this routine too? kernel oops's are bad..
> >>>>> Patch looks needed for just the point that Parav made above (that
> >>>>> if security check fails, then ib_free_recv_mad will cause the
> >>>>> mad_recv_wc->rmpp_list to be accessed so it needs to be
> >>>>> initialized before security is enforced).
> >>>> Agree the patch is needed regardless.
> >>> Someone please send it..
> >> Parav/Daniel,
> >>
> >> Please send it directly to the mailing list.
> >>
> >>>>> I don't have mthca to try this. Maybe Chris can try this patch
> >>>>> (with CONFIG_SECURITY_INFINIBAND=y).
> >>>> Chris, are you running with SELinux enabled? If this addresses your issue it
> means permission is denied, so once the crash is resolved additional policy will
> be required in order for it to work as expected.
> >>> If Chris has selinux turned on in his distro would you expect this
> >>> test to just fail? Doesn't that mean we have missed installing
> >>> security labels for things like opensm?
> >> Chris has SELinux enabled, see his gist:
> >> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> >>
> st.github.com%2Friptidewave93%2Fb3b83c13e93ab3be4254c855885f5b3a&dat
> a
> >>
> =02%7C01%7Cparav%40mellanox.com%7Cf968df072f7143ca1aa708d52087c6b
> 8%7C
> >>
> a652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636450689891416237&sd
> ata=W
> >> 74Qn4lOs2MBgV3uHPSngmvtLCxp%2F8kDkyZ1cIIhGQ0%3D&reserved=0
> >
> > That doesn't indicate if he has SELinux enabled or not, just that
> CONFIG_SECURITY_INFINIBAND is enabled.  Also, even if SELinux enabled in the
> kernel config it must be turned on via /etc/selinux/config, and also set into
> enforcing mode, if it were to cause this problem.  There's no enough info there
> to determine any of that.
> >
> >> Thanks
> >>
> >>> Jason
> >
> >
> 
> Hello All,
> 
> I have installed the kernel with the mentioned patch, as well as
> CONFIG_SECURITY_INFINIBAND enabled. Sadly I am back to the issue where my
> compute node is reporting:
> 
> kernel: infiniband mthca0: ib_post_send_mad error
There were two issues in your report.
1. Post send failure.
2. Kernel crash on receiving mad.
I provided fix for 2nd issue.
Do you still 2nd issue (crash) after applying the fix?

For 1st problem, Dan has few questions/suggestions regarding configuration of selinux policy.
Can you please go through it?

N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±­ÙšŠ{ayº\x1dʇڙë,j\a­¢f£¢·hš‹»öì\x17/oSc¾™Ú³9˜uÀ¦æå‰È&jw¨®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿïêäz¹Þ–Šàþf£¢·hšˆ§~ˆmš

Re: 4.13 ib_mthca NULL pointer dereference with OpenSM

[Daniel Jurgens]

On 10/31/2017 12:49 PM, Chris Blake wrote:
> Hello All,
>
> I have installed the kernel with the mentioned patch, as well as
> CONFIG_SECURITY_INFINIBAND enabled. Sadly I am back to the issue where
> my compute node is reporting:
>
> kernel: infiniband mthca0: ib_post_send_mad error
>
> As soon as I roll back to a kernel with CONFIG_SECURITY_INFINIBAND
> disabled, the issue goes away and things work as expected.
>
> Regards,
> Chris Blake

Sounds like the crash is resolved and now you're getting a denial from a security module.  I looked in the code, it looks like AppArmor doesn't register any callbacks for the ib_* security hooks, and if no hook is registered it should return 0.  Can you tell me more about your setup so I can create a reproducer? What OS are you using? Can you double check that SELinux isn't enabled (see output of sestatus).

--
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

Re: 4.13 ib_mthca NULL pointer dereference with OpenSM

[Chris Blake]

On Tue, Oct 31, 2017 at 1:22 PM, Daniel Jurgens <danielj-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> wrote:
> On 10/31/2017 12:49 PM, Chris Blake wrote:
>> Hello All,
>>
>> I have installed the kernel with the mentioned patch, as well as
>> CONFIG_SECURITY_INFINIBAND enabled. Sadly I am back to the issue where
>> my compute node is reporting:
>>
>> kernel: infiniband mthca0: ib_post_send_mad error
>>
>> As soon as I roll back to a kernel with CONFIG_SECURITY_INFINIBAND
>> disabled, the issue goes away and things work as expected.
>>
>> Regards,
>> Chris Blake
>
> Sounds like the crash is resolved and now you're getting a denial from a security module.  I looked in the code, it looks like AppArmor doesn't register any callbacks for the ib_* security hooks, and if no hook is registered it should return 0.  Can you tell me more about your setup so I can create a reproducer? What OS are you using? Can you double check that SELinux isn't enabled (see output of sestatus).
>

Hello,

I am not using SELinux on my system. I do have apparmor, but it is
only configured for lxc.

# apparmor_status
apparmor module is loaded.
5 profiles are loaded.
5 profiles are in enforce mode.
   /usr/bin/lxc-start
   lxc-container-default
   lxc-container-default-cgns
   lxc-container-default-with-mounting
   lxc-container-default-with-nesting
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.

# sestatus
SELinux status:                 disabled

As for the crash issue I was seeing for #2, so far I have not been
able to replicate it with the patch. :)

Regarding my OS, my "NAS" box is running Debian 9.2 with it's default
distro kernel (currently 4.9.51-1), and my "Compute" nodes are on
Proxmox, which is based on Debian 9.1 and it's kernel is based on
ubuntu-artful and is version 4.13.4. Source is at
https://git.proxmox.com/?p=pve-kernel.git;a=summary. This is the
kernel I have tested the patch on, and have been running with
CONFIG_SECURITY_INFINIBAND disabled to resolve the issue.

Regards,
Chris Blake
--
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

Re: 4.13 ib_mthca NULL pointer dereference with OpenSM

[Chris Blake]

On Tue, Oct 31, 2017 at 1:29 PM, Chris Blake <chrisrblake93-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Tue, Oct 31, 2017 at 1:22 PM, Daniel Jurgens <danielj-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> wrote:
>> On 10/31/2017 12:49 PM, Chris Blake wrote:
>>> Hello All,
>>>
>>> I have installed the kernel with the mentioned patch, as well as
>>> CONFIG_SECURITY_INFINIBAND enabled. Sadly I am back to the issue where
>>> my compute node is reporting:
>>>
>>> kernel: infiniband mthca0: ib_post_send_mad error
>>>
>>> As soon as I roll back to a kernel with CONFIG_SECURITY_INFINIBAND
>>> disabled, the issue goes away and things work as expected.
>>>
>>> Regards,
>>> Chris Blake
>>
>> Sounds like the crash is resolved and now you're getting a denial from a security module.  I looked in the code, it looks like AppArmor doesn't register any callbacks for the ib_* security hooks, and if no hook is registered it should return 0.  Can you tell me more about your setup so I can create a reproducer? What OS are you using? Can you double check that SELinux isn't enabled (see output of sestatus).
>>
>
> Hello,
>
> I am not using SELinux on my system. I do have apparmor, but it is
> only configured for lxc.
>
> # apparmor_status
> apparmor module is loaded.
> 5 profiles are loaded.
> 5 profiles are in enforce mode.
>    /usr/bin/lxc-start
>    lxc-container-default
>    lxc-container-default-cgns
>    lxc-container-default-with-mounting
>    lxc-container-default-with-nesting
> 0 profiles are in complain mode.
> 0 processes have profiles defined.
> 0 processes are in enforce mode.
> 0 processes are in complain mode.
> 0 processes are unconfined but have a profile defined.
>
> # sestatus
> SELinux status:                 disabled
>
> As for the crash issue I was seeing for #2, so far I have not been
> able to replicate it with the patch. :)
>
> Regarding my OS, my "NAS" box is running Debian 9.2 with it's default
> distro kernel (currently 4.9.51-1), and my "Compute" nodes are on
> Proxmox, which is based on Debian 9.1 and it's kernel is based on
> ubuntu-artful and is version 4.13.4. Source is at
> https://git.proxmox.com/?p=pve-kernel.git;a=summary. This is the
> kernel I have tested the patch on, and have been running with
> CONFIG_SECURITY_INFINIBAND disabled to resolve the issue.
>
> Regards,
> Chris Blake

Hello,

Forgot to mention, on my compute nodes I was testing with mainline
kernels, such as 4.14.0-rc5, per my original email. If there are any
specific kernels you prefer I test with on my NAS or compute nodes,
please let me know.

Regards,
Chris Blake
--
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

Re: 4.13 ib_mthca NULL pointer dereference with OpenSM

[Jason Gunthorpe]

On Tue, Oct 31, 2017 at 12:22 PM, Daniel Jurgens <danielj-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> wrote:

> Sounds like the crash is resolved and now you're getting a denial
> from a security module.  I looked in the code, it looks like

If Chris was hitting that crash it means his security module failed the
mad action, as that is the only way to trigger it.

> AppArmor doesn't register any callbacks for the ib_* security hooks,
> and if no hook is registered it should return 0.  Can you tell me
> more about your setup so I can create a reproducer? What OS are you
> using? Can you double check that SELinux isn't enabled (see output
> of sestatus).

Which suggests to me that apparmour is not working properly with the
rdma selinux patches??

Jason

--
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

Re: 4.13 ib_mthca NULL pointer dereference with OpenSM

[Daniel Jurgens]

On 10/31/2017 2:23 PM, Jason Gunthorpe wrote:
> On Tue, Oct 31, 2017 at 12:22 PM, Daniel Jurgens <danielj-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> wrote:
>
>> Sounds like the crash is resolved and now you're getting a denial
>> from a security module.  I looked in the code, it looks like
> If Chris was hitting that crash it means his security module failed the
> mad action, as that is the only way to trigger it.
>
>> AppArmor doesn't register any callbacks for the ib_* security hooks,
>> and if no hook is registered it should return 0.  Can you tell me
>> more about your setup so I can create a reproducer? What OS are you
>> using? Can you double check that SELinux isn't enabled (see output
>> of sestatus).
> Which suggests to me that apparmour is not working properly with the
> rdma selinux patches??

It seems that way.  I can't explain it looking at the code, I'm trying to reproduce it for debug.

 A point of clarification, the RDMA "SELinux" patches aren't SELinux specific.  They interact with the LSM, a layer of abstraction between the security modules and the rest of the kernel.   Zero or more security modules like SELinux or AppArmor can implement the security hooks.  The default return value for the hook in question is 0 if no modules implement it.  It doesn't look like AppArmor implements it.

> Jason
>

--
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

Re: 4.13 ib_mthca NULL pointer dereference with OpenSM

[Chris Blake]

On Tue, Oct 31, 2017 at 2:44 PM, Daniel Jurgens <danielj-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> wrote:
> On 10/31/2017 2:23 PM, Jason Gunthorpe wrote:
>> On Tue, Oct 31, 2017 at 12:22 PM, Daniel Jurgens <danielj-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> wrote:
>>
>>> Sounds like the crash is resolved and now you're getting a denial
>>> from a security module.  I looked in the code, it looks like
>> If Chris was hitting that crash it means his security module failed the
>> mad action, as that is the only way to trigger it.
>>
>>> AppArmor doesn't register any callbacks for the ib_* security hooks,
>>> and if no hook is registered it should return 0.  Can you tell me
>>> more about your setup so I can create a reproducer? What OS are you
>>> using? Can you double check that SELinux isn't enabled (see output
>>> of sestatus).
>> Which suggests to me that apparmour is not working properly with the
>> rdma selinux patches??
>
> It seems that way.  I can't explain it looking at the code, I'm trying to reproduce it for debug.
>
>  A point of clarification, the RDMA "SELinux" patches aren't SELinux specific.  They interact with the LSM, a layer of abstraction between the security modules and the rest of the kernel.   Zero or more security modules like SELinux or AppArmor can implement the security hooks.  The default return value for the hook in question is 0 if no modules implement it.  It doesn't look like AppArmor implements it.
>
>> Jason
>>
>

Hello All,

As a follow up to this issue, I went ahead and installed v4.14-rc8
mainline from http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.14-rc8/
to do some testing. I disabled apparmor via the cmdline (I added
apparmor=0 security="") and this seems to have worked:

root@C6100-1-N4:~# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.14.0-041400rc8-generic
root=/dev/mapper/pve-root ro apparmor=0 security= quiet
root@C6100-1-N4:~# apparmor_status
apparmor module is loaded.
apparmor filesystem is not mounted.

However, I am still having the issue with up_post_send_mad error:

root@C6100-1-N4:~# uptime
 17:36:30 up 35 min,  1 user,  load average: 0.13, 0.06, 0.01
root@C6100-1-N4:~# dmesg | grep "infiniband mthca0: ib_post_send_mad
error" | wc -l
848

I will admit that I have little knowledge of apparmor, but from the
above if "ib_post_send_mad error" is caused by apparmor as previously
suggested, wouldn't disabling it resolve the issue?

Let me know if you have any other things you would like me to test.

Regards,
Chris Blake
--
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

Re: 4.13 ib_mthca NULL pointer dereference with OpenSM

[Daniel Jurgens]

On 11/12/2017 5:38 PM, Chris Blake wrote:
> I will admit that I have little knowledge of apparmor, but from the
> above if "ib_post_send_mad error" is caused by apparmor as previously
> suggested, wouldn't disabling it resolve the issue?
>
> Let me know if you have any other things you would like me to test.

Hi Chris, I sent you a patch in a separate email that will isolate which check is failing. Can you try that and send me the output? Sorry to ask you to do this, I've still not been able to reproduce.

> Regards,
> Chris Blake


--
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