[patch] IB/hfi1: checking for NULL instead of IS_ERR

[patch] IB/hfi1: checking for NULL instead of IS_ERR

[Dan Carpenter]

__get_txreq() returns an ERR_PTR() but this checks for NULL so it would
oops on failure.

Signed-off-by: Dan Carpenter <dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>

diff --git a/drivers/staging/rdma/hfi1/verbs.c b/drivers/staging/rdma/hfi1/verbs.c
index 53ac214..41bb59e 100644
--- a/drivers/staging/rdma/hfi1/verbs.c
+++ b/drivers/staging/rdma/hfi1/verbs.c
@@ -749,11 +749,13 @@ static inline struct verbs_txreq *get_txreq(struct hfi1_ibdev *dev,
 	struct verbs_txreq *tx;
 
 	tx = kmem_cache_alloc(dev->verbs_txreq_cache, GFP_ATOMIC);
-	if (!tx)
+	if (!tx) {
 		/* call slow path to get the lock */
 		tx =  __get_txreq(dev, qp);
-	if (tx)
-		tx->qp = qp;
+		if (IS_ERR(tx))
+			return tx;
+	}
+	tx->qp = qp;
 	return tx;
 }
 
--
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: [patch] IB/hfi1: checking for NULL instead of IS_ERR

[Doug Ledford]

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

On 09/16/2015 02:22 AM, Dan Carpenter wrote:
> __get_txreq() returns an ERR_PTR() but this checks for NULL so it would
> oops on failure.
> 
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>

Thanks, applied.


-- 
Doug Ledford <dledford@redhat.com>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

Re: [patch] IB/hfi1: checking for NULL instead of IS_ERR

[Greg Kroah-Hartman]

On Fri, Sep 18, 2015 at 11:51:09AM -0400, Doug Ledford wrote:
> On 09/16/2015 02:22 AM, Dan Carpenter wrote:
> > __get_txreq() returns an ERR_PTR() but this checks for NULL so it would
> > oops on failure.
> > 
> > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> 
> Thanks, applied.

Applied to what?  Should I just ignore these types of patches and not
take them in my tree and you will send them on later on?  I don't
remember what we agreed to do, sorry.

thanks,

greg k-h

RE: [patch] IB/hfi1: checking for NULL instead of IS_ERR

[Weiny, Ira]

> 
> On Fri, Sep 18, 2015 at 11:51:09AM -0400, Doug Ledford wrote:
> > On 09/16/2015 02:22 AM, Dan Carpenter wrote:
> > > __get_txreq() returns an ERR_PTR() but this checks for NULL so it
> > > would oops on failure.
> > >
> > > Signed-off-by: Dan Carpenter <dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
> >
> > Thanks, applied.
> 
> Applied to what?  Should I just ignore these types of patches and not take them
> in my tree and you will send them on later on?  I don't remember what we
> agreed to do, sorry.

My recollection was that Doug was going to handle the staging/rdma sub-tree because of the large churn he expected between the rdma subsystem and those drivers.

Therefore, I have been submitting my patches against staging/rdma/hfi directly to Doug and Linux-rdma.

Ira

> 
> thanks,
> 
> greg k-h
> --
> 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: [patch] IB/hfi1: checking for NULL instead of IS_ERR

[Greg Kroah-Hartman]

On Sat, Sep 19, 2015 at 10:49:52PM +0000, Weiny, Ira wrote:
> > 
> > On Fri, Sep 18, 2015 at 11:51:09AM -0400, Doug Ledford wrote:
> > > On 09/16/2015 02:22 AM, Dan Carpenter wrote:
> > > > __get_txreq() returns an ERR_PTR() but this checks for NULL so it
> > > > would oops on failure.
> > > >
> > > > Signed-off-by: Dan Carpenter <dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
> > >
> > > Thanks, applied.
> > 
> > Applied to what?  Should I just ignore these types of patches and not take them
> > in my tree and you will send them on later on?  I don't remember what we
> > agreed to do, sorry.
> 
> My recollection was that Doug was going to handle the staging/rdma sub-tree because of the large churn he expected between the rdma subsystem and those drivers.
> 
> Therefore, I have been submitting my patches against staging/rdma/hfi directly to Doug and Linux-rdma.

Ok, but Doug better start syncing up with me soon, as we are about to
start to get a ton of staging patches due to the Outreachy application
process, and we will start to get merge errors very quickly.

Doug, what's the plan for this?  Can you just forward me patches every
so often to sync up?  Or I can take anything that is cc: me and/or the
driverdevel mailing list.

thanks,

greg k-h
--
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: [patch] IB/hfi1: checking for NULL instead of IS_ERR

[Doug Ledford]

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

On 09/18/2015 11:01 PM, Greg Kroah-Hartman wrote:
> On Fri, Sep 18, 2015 at 11:51:09AM -0400, Doug Ledford wrote:
>> On 09/16/2015 02:22 AM, Dan Carpenter wrote:
>>> __get_txreq() returns an ERR_PTR() but this checks for NULL so it would
>>> oops on failure.
>>>
>>> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>>
>> Thanks, applied.
> 
> Applied to what?  Should I just ignore these types of patches and not
> take them in my tree and you will send them on later on?  I don't
> remember what we agreed to do, sorry.

My understanding was that I would handle everything in the staging/rdma
area.  To that end, I tried to make it explicit so that people would
know that via the following things:

From MAINTAINERS:

INFINIBAND SUBSYSTEM
M:      Doug Ledford <dledford@redhat.com>
M:      Sean Hefty <sean.hefty@intel.com>
M:      Hal Rosenstock <hal.rosenstock@gmail.com>
L:      linux-rdma@vger.kernel.org
W:      http://www.openfabrics.org/
Q:      http://patchwork.kernel.org/project/linux-rdma/list/
T:      git git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git
S:      Supported
F:      Documentation/infiniband/
F:      drivers/infiniband/
F:      drivers/staging/rdma/
F:      include/uapi/linux/if_infiniband.h
F:      include/uapi/rdma/
F:      include/rdma/


And from drivers/staging/rdma/Kconfig:

menuconfig STAGING_RDMA
        bool "RDMA staging drivers"
	depends on INFINIBAND
	depends on PCI || BROKEN
	depends on HAS_IOMEM
	depends on NET
	depends on INET
        default n
        ---help---
          This option allows you to select a number of RDMA drivers that
	  fall into one of two categories: deprecated drivers being held
	  here before finally being removed or new drivers that still need
	  some work before being moved to the normal RDMA driver area.

          If you wish to work on these drivers, to help improve them, or
          to report problems you have with them, please use the
	  linux-rdma@vger.kernel.org mailing list.

          If in doubt, say N here.

I was hoping those two items would be sufficient to keep people from
flooding devel@ and yourself personally with fixups for these items and
instead they would send them through linux-rdma@.


-- 
Doug Ledford <dledford@redhat.com>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

Re: [patch] IB/hfi1: checking for NULL instead of IS_ERR

[Greg Kroah-Hartman]

On Mon, Sep 21, 2015 at 11:42:28AM -0400, Doug Ledford wrote:
> On 09/18/2015 11:01 PM, Greg Kroah-Hartman wrote:
> > On Fri, Sep 18, 2015 at 11:51:09AM -0400, Doug Ledford wrote:
> >> On 09/16/2015 02:22 AM, Dan Carpenter wrote:
> >>> __get_txreq() returns an ERR_PTR() but this checks for NULL so it would
> >>> oops on failure.
> >>>
> >>> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> >>
> >> Thanks, applied.
> > 
> > Applied to what?  Should I just ignore these types of patches and not
> > take them in my tree and you will send them on later on?  I don't
> > remember what we agreed to do, sorry.
> 
> My understanding was that I would handle everything in the staging/rdma
> area.  To that end, I tried to make it explicit so that people would
> know that via the following things:
> 
> From MAINTAINERS:
> 
> INFINIBAND SUBSYSTEM
> M:      Doug Ledford <dledford@redhat.com>
> M:      Sean Hefty <sean.hefty@intel.com>
> M:      Hal Rosenstock <hal.rosenstock@gmail.com>
> L:      linux-rdma@vger.kernel.org
> W:      http://www.openfabrics.org/
> Q:      http://patchwork.kernel.org/project/linux-rdma/list/
> T:      git git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git
> S:      Supported
> F:      Documentation/infiniband/
> F:      drivers/infiniband/
> F:      drivers/staging/rdma/
> F:      include/uapi/linux/if_infiniband.h
> F:      include/uapi/rdma/
> F:      include/rdma/
> 
> 
> And from drivers/staging/rdma/Kconfig:
> 
> menuconfig STAGING_RDMA
>         bool "RDMA staging drivers"
> 	depends on INFINIBAND
> 	depends on PCI || BROKEN
> 	depends on HAS_IOMEM
> 	depends on NET
> 	depends on INET
>         default n
>         ---help---
>           This option allows you to select a number of RDMA drivers that
> 	  fall into one of two categories: deprecated drivers being held
> 	  here before finally being removed or new drivers that still need
> 	  some work before being moved to the normal RDMA driver area.
> 
>           If you wish to work on these drivers, to help improve them, or
>           to report problems you have with them, please use the
> 	  linux-rdma@vger.kernel.org mailing list.
> 
>           If in doubt, say N here.
> 
> I was hoping those two items would be sufficient to keep people from
> flooding devel@ and yourself personally with fixups for these items and
> instead they would send them through linux-rdma@.

But, that's already not happening, as is obvious by my inbox.

So, how about you forward on what you have so far to me, and I'll keep
these.  Otherwise you will end up with nasty merge issues very quickly
as people will continue to send stuff to me.

thanks,

greg k-h

Re: [patch] IB/hfi1: checking for NULL instead of IS_ERR

[Doug Ledford]

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

On 09/21/2015 12:48 PM, Greg Kroah-Hartman wrote:

> But, that's already not happening, as is obvious by my inbox.

Yeah, I see that.

> So, how about you forward on what you have so far to me, and I'll keep
> these.  Otherwise you will end up with nasty merge issues very quickly
> as people will continue to send stuff to me.

As you wish.  I pulled in a number of patches related to hfi1, but I've
already sent the pull request to Linus and they made it as of 4.1-rc2.
So, just start from there and you will have all the patches I've taken.


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

Re: [patch] IB/hfi1: checking for NULL instead of IS_ERR

[Greg Kroah-Hartman]

On Mon, Sep 21, 2015 at 01:03:52PM -0400, Doug Ledford wrote:
> On 09/21/2015 12:48 PM, Greg Kroah-Hartman wrote:
> 
> > But, that's already not happening, as is obvious by my inbox.
> 
> Yeah, I see that.
> 
> > So, how about you forward on what you have so far to me, and I'll keep
> > these.  Otherwise you will end up with nasty merge issues very quickly
> > as people will continue to send stuff to me.
> 
> As you wish.  I pulled in a number of patches related to hfi1, but I've
> already sent the pull request to Linus and they made it as of 4.1-rc2.
> So, just start from there and you will have all the patches I've taken.

Sounds good, thanks.

greg k-h
--
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