All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] drivers: of: removing assignment of 0 to static variable
       [not found] <saurabh.truth@gmail.com>
@ 2015-10-27  3:42 ` Saurabh Sengar
  0 siblings, 0 replies; 28+ messages in thread
From: Saurabh Sengar @ 2015-10-27  3:42 UTC (permalink / raw)
  To: robh+dt, frowand.list, grant.likely, devicetree, linux-kernel
  Cc: Saurabh Sengar

no need to initialise static variable with 0, hence correcting it.

Signed-off-by: Saurabh Sengar <saurabh.truth@gmail.com>
---
 drivers/of/fdt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 6e82bc42..63699dd 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -184,7 +184,7 @@ static void * unflatten_dt_node(const void *blob,
 	struct property *pp, **prev_pp = NULL;
 	const char *pathp;
 	unsigned int l, allocl;
-	static int depth = 0;
+	static int depth;
 	int old_depth;
 	int offset;
 	int has_name = 0;
-- 
1.9.1


^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH] drivers: of: removing assignment of 0 to static variable
@ 2015-10-27  3:42 ` Saurabh Sengar
  0 siblings, 0 replies; 28+ messages in thread
From: Saurabh Sengar @ 2015-10-27  3:42 UTC (permalink / raw)
  To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
	frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
	grant.likely-QSEj5FYQhm4dnm+yROfE0A,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
  Cc: Saurabh Sengar

no need to initialise static variable with 0, hence correcting it.

Signed-off-by: Saurabh Sengar <saurabh.truth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 drivers/of/fdt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 6e82bc42..63699dd 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -184,7 +184,7 @@ static void * unflatten_dt_node(const void *blob,
 	struct property *pp, **prev_pp = NULL;
 	const char *pathp;
 	unsigned int l, allocl;
-	static int depth = 0;
+	static int depth;
 	int old_depth;
 	int offset;
 	int has_name = 0;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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	[flat|nested] 28+ messages in thread

* [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC
@ 2015-10-27 15:47   ` Saurabh Sengar
  0 siblings, 0 replies; 28+ messages in thread
From: Saurabh Sengar @ 2015-10-27 15:47 UTC (permalink / raw)
  To: dledford-H+wXaHxf7aLQT0dZR+AlfA,
	sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
	hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
	ira.weiny-ral2JQCrhuEAvxtiuMwx3w,
	jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/,
	yun.wang-EIkl63zCoXaH+58JC4qpiA,
	kaike.wan-ral2JQCrhuEAvxtiuMwx3w,
	linux-rdma-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
  Cc: Saurabh Sengar

replace GFP_KERNEL with GFP_ATOMIC, as code while holding a spinlock
should be atomic
GFP_KERNEL may sleep and can cause deadlock, where as GFP_ATOMIC may
fail but certainly avoids deadlock

Signed-off-by: Saurabh Sengar <saurabh.truth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 drivers/infiniband/core/sa_query.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/infiniband/core/sa_query.c b/drivers/infiniband/core/sa_query.c
index 8c014b3..cd1f911 100644
--- a/drivers/infiniband/core/sa_query.c
+++ b/drivers/infiniband/core/sa_query.c
@@ -526,7 +526,7 @@ static int ib_nl_send_msg(struct ib_sa_query *query)
 	if (len <= 0)
 		return -EMSGSIZE;
 
-	skb = nlmsg_new(len, GFP_KERNEL);
+	skb = nlmsg_new(len, GFP_ATOMIC);
 	if (!skb)
 		return -ENOMEM;
 
@@ -544,7 +544,7 @@ static int ib_nl_send_msg(struct ib_sa_query *query)
 	/* Repair the nlmsg header length */
 	nlmsg_end(skb, nlh);
 
-	ret = ibnl_multicast(skb, nlh, RDMA_NL_GROUP_LS, GFP_KERNEL);
+	ret = ibnl_multicast(skb, nlh, RDMA_NL_GROUP_LS, GFP_ATOMIC);
 	if (!ret)
 		ret = len;
 	else
-- 
1.9.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	[flat|nested] 28+ messages in thread

* [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC
@ 2015-10-27 15:47   ` Saurabh Sengar
  0 siblings, 0 replies; 28+ messages in thread
From: Saurabh Sengar @ 2015-10-27 15:47 UTC (permalink / raw)
  To: dledford, sean.hefty, hal.rosenstock, ira.weiny, jgunthorpe,
	yun.wang, kaike.wan, linux-rdma, linux-kernel
  Cc: Saurabh Sengar

replace GFP_KERNEL with GFP_ATOMIC, as code while holding a spinlock
should be atomic
GFP_KERNEL may sleep and can cause deadlock, where as GFP_ATOMIC may
fail but certainly avoids deadlock

Signed-off-by: Saurabh Sengar <saurabh.truth@gmail.com>
---
 drivers/infiniband/core/sa_query.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/infiniband/core/sa_query.c b/drivers/infiniband/core/sa_query.c
index 8c014b3..cd1f911 100644
--- a/drivers/infiniband/core/sa_query.c
+++ b/drivers/infiniband/core/sa_query.c
@@ -526,7 +526,7 @@ static int ib_nl_send_msg(struct ib_sa_query *query)
 	if (len <= 0)
 		return -EMSGSIZE;
 
-	skb = nlmsg_new(len, GFP_KERNEL);
+	skb = nlmsg_new(len, GFP_ATOMIC);
 	if (!skb)
 		return -ENOMEM;
 
@@ -544,7 +544,7 @@ static int ib_nl_send_msg(struct ib_sa_query *query)
 	/* Repair the nlmsg header length */
 	nlmsg_end(skb, nlh);
 
-	ret = ibnl_multicast(skb, nlh, RDMA_NL_GROUP_LS, GFP_KERNEL);
+	ret = ibnl_multicast(skb, nlh, RDMA_NL_GROUP_LS, GFP_ATOMIC);
 	if (!ret)
 		ret = len;
 	else
-- 
1.9.1


^ permalink raw reply related	[flat|nested] 28+ messages in thread

* Re: [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC
  2015-10-27 15:47   ` Saurabh Sengar
@ 2015-10-27 18:12       ` ira.weiny
  -1 siblings, 0 replies; 28+ messages in thread
From: ira.weiny @ 2015-10-27 18:12 UTC (permalink / raw)
  To: Saurabh Sengar
  Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA,
	sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
	hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
	jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/,
	yun.wang-EIkl63zCoXaH+58JC4qpiA,
	kaike.wan-ral2JQCrhuEAvxtiuMwx3w,
	linux-rdma-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA

On Tue, Oct 27, 2015 at 09:17:40PM +0530, Saurabh Sengar wrote:
> replace GFP_KERNEL with GFP_ATOMIC, as code while holding a spinlock
> should be atomic
> GFP_KERNEL may sleep and can cause deadlock, where as GFP_ATOMIC may
> fail but certainly avoids deadlock

Great catch.  Thanks!

However, gfp_t is passed to send_mad and we should pass that down and use it.

Compile tested only, suggestion below,
Ira


14:09:12 > git di
diff --git a/drivers/infiniband/core/sa_query.c
b/drivers/infiniband/core/sa_query.c
index 8c014b33d8e0..54d454042b28 100644
--- a/drivers/infiniband/core/sa_query.c
+++ b/drivers/infiniband/core/sa_query.c
@@ -512,7 +512,7 @@ static int ib_nl_get_path_rec_attrs_len(ib_sa_comp_mask comp_mask)
        return len;
 }
 
-static int ib_nl_send_msg(struct ib_sa_query *query)
+static int ib_nl_send_msg(struct ib_sa_query *query, gfp_t gfp_mask)
 {
        struct sk_buff *skb = NULL;
        struct nlmsghdr *nlh;
@@ -526,7 +526,7 @@ static int ib_nl_send_msg(struct ib_sa_query *query)
        if (len <= 0)
                return -EMSGSIZE;
 
-       skb = nlmsg_new(len, GFP_KERNEL);
+       skb = nlmsg_new(len, gfp_mask);
        if (!skb)
                return -ENOMEM;
 
@@ -544,7 +544,7 @@ static int ib_nl_send_msg(struct ib_sa_query *query)
        /* Repair the nlmsg header length */
        nlmsg_end(skb, nlh);
 
-       ret = ibnl_multicast(skb, nlh, RDMA_NL_GROUP_LS, GFP_KERNEL);
+       ret = ibnl_multicast(skb, nlh, RDMA_NL_GROUP_LS, gfp_mask);
        if (!ret)
                ret = len;
        else
@@ -553,7 +553,7 @@ static int ib_nl_send_msg(struct ib_sa_query *query)
        return ret;
 }
 
-static int ib_nl_make_request(struct ib_sa_query *query)
+static int ib_nl_make_request(struct ib_sa_query *query, gfp_t gfp_mask)
 {
        unsigned long flags;
        unsigned long delay;
@@ -563,7 +563,7 @@ static int ib_nl_make_request(struct ib_sa_query *query)
        query->seq = (u32)atomic_inc_return(&ib_nl_sa_request_seq);
 
        spin_lock_irqsave(&ib_nl_request_lock, flags);
-       ret = ib_nl_send_msg(query);
+       ret = ib_nl_send_msg(query, gfp_mask);
        if (ret <= 0) {
                ret = -EIO;
                goto request_out;
@@ -1105,7 +1105,7 @@ static int send_mad(struct ib_sa_query *query, int timeout_ms, gfp_t gfp_mask)
 
        if (query->flags & IB_SA_ENABLE_LOCAL_SERVICE) {
                if (!ibnl_chk_listeners(RDMA_NL_GROUP_LS)) {
-                       if (!ib_nl_make_request(query))
+                       if (!ib_nl_make_request(query, gfp_mask))
                                return id;
                }
                ib_sa_disable_local_svc(query);

--
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	[flat|nested] 28+ messages in thread

* Re: [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC
@ 2015-10-27 18:12       ` ira.weiny
  0 siblings, 0 replies; 28+ messages in thread
From: ira.weiny @ 2015-10-27 18:12 UTC (permalink / raw)
  To: Saurabh Sengar
  Cc: dledford, sean.hefty, hal.rosenstock, jgunthorpe, yun.wang,
	kaike.wan, linux-rdma, linux-kernel

On Tue, Oct 27, 2015 at 09:17:40PM +0530, Saurabh Sengar wrote:
> replace GFP_KERNEL with GFP_ATOMIC, as code while holding a spinlock
> should be atomic
> GFP_KERNEL may sleep and can cause deadlock, where as GFP_ATOMIC may
> fail but certainly avoids deadlock

Great catch.  Thanks!

However, gfp_t is passed to send_mad and we should pass that down and use it.

Compile tested only, suggestion below,
Ira


14:09:12 > git di
diff --git a/drivers/infiniband/core/sa_query.c
b/drivers/infiniband/core/sa_query.c
index 8c014b33d8e0..54d454042b28 100644
--- a/drivers/infiniband/core/sa_query.c
+++ b/drivers/infiniband/core/sa_query.c
@@ -512,7 +512,7 @@ static int ib_nl_get_path_rec_attrs_len(ib_sa_comp_mask comp_mask)
        return len;
 }
 
-static int ib_nl_send_msg(struct ib_sa_query *query)
+static int ib_nl_send_msg(struct ib_sa_query *query, gfp_t gfp_mask)
 {
        struct sk_buff *skb = NULL;
        struct nlmsghdr *nlh;
@@ -526,7 +526,7 @@ static int ib_nl_send_msg(struct ib_sa_query *query)
        if (len <= 0)
                return -EMSGSIZE;
 
-       skb = nlmsg_new(len, GFP_KERNEL);
+       skb = nlmsg_new(len, gfp_mask);
        if (!skb)
                return -ENOMEM;
 
@@ -544,7 +544,7 @@ static int ib_nl_send_msg(struct ib_sa_query *query)
        /* Repair the nlmsg header length */
        nlmsg_end(skb, nlh);
 
-       ret = ibnl_multicast(skb, nlh, RDMA_NL_GROUP_LS, GFP_KERNEL);
+       ret = ibnl_multicast(skb, nlh, RDMA_NL_GROUP_LS, gfp_mask);
        if (!ret)
                ret = len;
        else
@@ -553,7 +553,7 @@ static int ib_nl_send_msg(struct ib_sa_query *query)
        return ret;
 }
 
-static int ib_nl_make_request(struct ib_sa_query *query)
+static int ib_nl_make_request(struct ib_sa_query *query, gfp_t gfp_mask)
 {
        unsigned long flags;
        unsigned long delay;
@@ -563,7 +563,7 @@ static int ib_nl_make_request(struct ib_sa_query *query)
        query->seq = (u32)atomic_inc_return(&ib_nl_sa_request_seq);
 
        spin_lock_irqsave(&ib_nl_request_lock, flags);
-       ret = ib_nl_send_msg(query);
+       ret = ib_nl_send_msg(query, gfp_mask);
        if (ret <= 0) {
                ret = -EIO;
                goto request_out;
@@ -1105,7 +1105,7 @@ static int send_mad(struct ib_sa_query *query, int timeout_ms, gfp_t gfp_mask)
 
        if (query->flags & IB_SA_ENABLE_LOCAL_SERVICE) {
                if (!ibnl_chk_listeners(RDMA_NL_GROUP_LS)) {
-                       if (!ib_nl_make_request(query))
+                       if (!ib_nl_make_request(query, gfp_mask))
                                return id;
                }
                ib_sa_disable_local_svc(query);


^ permalink raw reply related	[flat|nested] 28+ messages in thread

* Re: [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC
  2015-10-27 18:12       ` ira.weiny
@ 2015-10-27 18:16           ` Jason Gunthorpe
  -1 siblings, 0 replies; 28+ messages in thread
From: Jason Gunthorpe @ 2015-10-27 18:16 UTC (permalink / raw)
  To: ira.weiny
  Cc: Saurabh Sengar, dledford-H+wXaHxf7aLQT0dZR+AlfA,
	sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
	hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
	yun.wang-EIkl63zCoXaH+58JC4qpiA,
	kaike.wan-ral2JQCrhuEAvxtiuMwx3w,
	linux-rdma-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA

On Tue, Oct 27, 2015 at 02:12:36PM -0400, ira.weiny wrote:
> On Tue, Oct 27, 2015 at 09:17:40PM +0530, Saurabh Sengar wrote:
> > replace GFP_KERNEL with GFP_ATOMIC, as code while holding a spinlock
> > should be atomic
> > GFP_KERNEL may sleep and can cause deadlock, where as GFP_ATOMIC may
> > fail but certainly avoids deadlock
> 
> Great catch.  Thanks!
> 
> However, gfp_t is passed to send_mad and we should pass that down and use it.

>         spin_lock_irqsave(&ib_nl_request_lock, flags);
> -       ret = ib_nl_send_msg(query);
> +       ret = ib_nl_send_msg(query, gfp_mask);

A spin lock is guarenteed held around ib_nl_send_msg, so it's
allocations have to be atomic, can't use gfp_mask here..

I do wonder if it is a good idea to call ib_nl_send_msg with a spinlock
held though.. Would be nice to see that go away.

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC
@ 2015-10-27 18:16           ` Jason Gunthorpe
  0 siblings, 0 replies; 28+ messages in thread
From: Jason Gunthorpe @ 2015-10-27 18:16 UTC (permalink / raw)
  To: ira.weiny
  Cc: Saurabh Sengar, dledford, sean.hefty, hal.rosenstock, yun.wang,
	kaike.wan, linux-rdma, linux-kernel

On Tue, Oct 27, 2015 at 02:12:36PM -0400, ira.weiny wrote:
> On Tue, Oct 27, 2015 at 09:17:40PM +0530, Saurabh Sengar wrote:
> > replace GFP_KERNEL with GFP_ATOMIC, as code while holding a spinlock
> > should be atomic
> > GFP_KERNEL may sleep and can cause deadlock, where as GFP_ATOMIC may
> > fail but certainly avoids deadlock
> 
> Great catch.  Thanks!
> 
> However, gfp_t is passed to send_mad and we should pass that down and use it.

>         spin_lock_irqsave(&ib_nl_request_lock, flags);
> -       ret = ib_nl_send_msg(query);
> +       ret = ib_nl_send_msg(query, gfp_mask);

A spin lock is guarenteed held around ib_nl_send_msg, so it's
allocations have to be atomic, can't use gfp_mask here..

I do wonder if it is a good idea to call ib_nl_send_msg with a spinlock
held though.. Would be nice to see that go away.

Jason

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC
  2015-10-27 18:16           ` Jason Gunthorpe
@ 2015-10-27 18:20               ` ira.weiny
  -1 siblings, 0 replies; 28+ messages in thread
From: ira.weiny @ 2015-10-27 18:20 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: Saurabh Sengar, dledford-H+wXaHxf7aLQT0dZR+AlfA,
	sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
	hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
	yun.wang-EIkl63zCoXaH+58JC4qpiA,
	kaike.wan-ral2JQCrhuEAvxtiuMwx3w,
	linux-rdma-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA

On Tue, Oct 27, 2015 at 12:16:52PM -0600, Jason Gunthorpe wrote:
> On Tue, Oct 27, 2015 at 02:12:36PM -0400, ira.weiny wrote:
> > On Tue, Oct 27, 2015 at 09:17:40PM +0530, Saurabh Sengar wrote:
> > > replace GFP_KERNEL with GFP_ATOMIC, as code while holding a spinlock
> > > should be atomic
> > > GFP_KERNEL may sleep and can cause deadlock, where as GFP_ATOMIC may
> > > fail but certainly avoids deadlock
> > 
> > Great catch.  Thanks!
> > 
> > However, gfp_t is passed to send_mad and we should pass that down and use it.
> 
> >         spin_lock_irqsave(&ib_nl_request_lock, flags);
> > -       ret = ib_nl_send_msg(query);
> > +       ret = ib_nl_send_msg(query, gfp_mask);
> 
> A spin lock is guarenteed held around ib_nl_send_msg, so it's
> allocations have to be atomic, can't use gfp_mask here..
> 
> I do wonder if it is a good idea to call ib_nl_send_msg with a spinlock
> held though.. Would be nice to see that go away.

Ah, yea my bad.

Ira

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC
@ 2015-10-27 18:20               ` ira.weiny
  0 siblings, 0 replies; 28+ messages in thread
From: ira.weiny @ 2015-10-27 18:20 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: Saurabh Sengar, dledford, sean.hefty, hal.rosenstock, yun.wang,
	kaike.wan, linux-rdma, linux-kernel

On Tue, Oct 27, 2015 at 12:16:52PM -0600, Jason Gunthorpe wrote:
> On Tue, Oct 27, 2015 at 02:12:36PM -0400, ira.weiny wrote:
> > On Tue, Oct 27, 2015 at 09:17:40PM +0530, Saurabh Sengar wrote:
> > > replace GFP_KERNEL with GFP_ATOMIC, as code while holding a spinlock
> > > should be atomic
> > > GFP_KERNEL may sleep and can cause deadlock, where as GFP_ATOMIC may
> > > fail but certainly avoids deadlock
> > 
> > Great catch.  Thanks!
> > 
> > However, gfp_t is passed to send_mad and we should pass that down and use it.
> 
> >         spin_lock_irqsave(&ib_nl_request_lock, flags);
> > -       ret = ib_nl_send_msg(query);
> > +       ret = ib_nl_send_msg(query, gfp_mask);
> 
> A spin lock is guarenteed held around ib_nl_send_msg, so it's
> allocations have to be atomic, can't use gfp_mask here..
> 
> I do wonder if it is a good idea to call ib_nl_send_msg with a spinlock
> held though.. Would be nice to see that go away.

Ah, yea my bad.

Ira

> 
> Jason

^ permalink raw reply	[flat|nested] 28+ messages in thread

* [PATCH] efi: replace GFP_KERNEL with GFP_ATOMIC
       [not found] <saurabh.truth@gmail.com>
@ 2015-10-27 18:42 ` Saurabh Sengar
  0 siblings, 0 replies; 28+ messages in thread
From: Saurabh Sengar @ 2015-10-27 18:42 UTC (permalink / raw)
  To: matt, linux-efi, linux-kernel; +Cc: Saurabh Sengar

replace GFP_KERNEL with GFP_ATOMIC, as code while holding a spinlock
should be atomic
GFP_KERNEL may sleep and can cause deadlock, where as GFP_ATOMIC may
fail but certainly avoids deadlock

Signed-off-by: Saurabh Sengar <saurabh.truth@gmail.com>
---
 drivers/firmware/efi/vars.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/vars.c b/drivers/firmware/efi/vars.c
index 70a0fb1..c07de85 100644
--- a/drivers/firmware/efi/vars.c
+++ b/drivers/firmware/efi/vars.c
@@ -334,7 +334,7 @@ static void dup_variable_bug(efi_char16_t *str16, efi_guid_t *vendor_guid,
 	 */
 	efivar_wq_enabled = false;
 
-	str8 = kzalloc(len8, GFP_KERNEL);
+	str8 = kzalloc(len8, GFP_ATOMIC);
 	if (!str8)
 		return;
 
-- 
1.9.1


^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH] efi: replace GFP_KERNEL with GFP_ATOMIC
@ 2015-10-27 18:42 ` Saurabh Sengar
  0 siblings, 0 replies; 28+ messages in thread
From: Saurabh Sengar @ 2015-10-27 18:42 UTC (permalink / raw)
  To: matt-mF/unelCI9GS6iBeEJttW/XRex20P6io,
	linux-efi-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
  Cc: Saurabh Sengar

replace GFP_KERNEL with GFP_ATOMIC, as code while holding a spinlock
should be atomic
GFP_KERNEL may sleep and can cause deadlock, where as GFP_ATOMIC may
fail but certainly avoids deadlock

Signed-off-by: Saurabh Sengar <saurabh.truth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 drivers/firmware/efi/vars.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/vars.c b/drivers/firmware/efi/vars.c
index 70a0fb1..c07de85 100644
--- a/drivers/firmware/efi/vars.c
+++ b/drivers/firmware/efi/vars.c
@@ -334,7 +334,7 @@ static void dup_variable_bug(efi_char16_t *str16, efi_guid_t *vendor_guid,
 	 */
 	efivar_wq_enabled = false;
 
-	str8 = kzalloc(len8, GFP_KERNEL);
+	str8 = kzalloc(len8, GFP_ATOMIC);
 	if (!str8)
 		return;
 
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 28+ messages in thread

* RE: [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC
  2015-10-27 18:16           ` Jason Gunthorpe
@ 2015-10-27 18:56               ` Wan, Kaike
  -1 siblings, 0 replies; 28+ messages in thread
From: Wan, Kaike @ 2015-10-27 18:56 UTC (permalink / raw)
  To: Jason Gunthorpe, Weiny, Ira
  Cc: Saurabh Sengar, dledford-H+wXaHxf7aLQT0dZR+AlfA, Hefty, Sean,
	hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
	yun.wang-EIkl63zCoXaH+58JC4qpiA,
	linux-rdma-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA



> -----Original Message-----
> From: Jason Gunthorpe [mailto:jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org]
> Sent: Tuesday, October 27, 2015 2:17 PM
> To: Weiny, Ira
> Cc: Saurabh Sengar; dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org; Hefty, Sean;
> hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; yun.wang-EIkl63zCoXaH+58JC4qpiA@public.gmane.org; Wan, Kaike; linux-
> rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Subject: Re: [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC
> 
> On Tue, Oct 27, 2015 at 02:12:36PM -0400, ira.weiny wrote:
> > On Tue, Oct 27, 2015 at 09:17:40PM +0530, Saurabh Sengar wrote:
> > > replace GFP_KERNEL with GFP_ATOMIC, as code while holding a spinlock
> > > should be atomic GFP_KERNEL may sleep and can cause deadlock, where
> > > as GFP_ATOMIC may fail but certainly avoids deadlock
> >
> > Great catch.  Thanks!
> >
> > However, gfp_t is passed to send_mad and we should pass that down and
> use it.
> 
> >         spin_lock_irqsave(&ib_nl_request_lock, flags);
> > -       ret = ib_nl_send_msg(query);
> > +       ret = ib_nl_send_msg(query, gfp_mask);
> 
> A spin lock is guarenteed held around ib_nl_send_msg, so it's allocations
> have to be atomic, can't use gfp_mask here..
> 
> I do wonder if it is a good idea to call ib_nl_send_msg with a spinlock held
> though.. Would be nice to see that go away.

We have to hold the lock to protect against a race condition that a quick response will try to free the request from the ib_nl_request_list before we even put it on the list.

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* RE: [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC
@ 2015-10-27 18:56               ` Wan, Kaike
  0 siblings, 0 replies; 28+ messages in thread
From: Wan, Kaike @ 2015-10-27 18:56 UTC (permalink / raw)
  To: Jason Gunthorpe, Weiny, Ira
  Cc: Saurabh Sengar, dledford, Hefty, Sean, hal.rosenstock, yun.wang,
	linux-rdma, linux-kernel



> -----Original Message-----
> From: Jason Gunthorpe [mailto:jgunthorpe@obsidianresearch.com]
> Sent: Tuesday, October 27, 2015 2:17 PM
> To: Weiny, Ira
> Cc: Saurabh Sengar; dledford@redhat.com; Hefty, Sean;
> hal.rosenstock@gmail.com; yun.wang@profitbricks.com; Wan, Kaike; linux-
> rdma@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC
> 
> On Tue, Oct 27, 2015 at 02:12:36PM -0400, ira.weiny wrote:
> > On Tue, Oct 27, 2015 at 09:17:40PM +0530, Saurabh Sengar wrote:
> > > replace GFP_KERNEL with GFP_ATOMIC, as code while holding a spinlock
> > > should be atomic GFP_KERNEL may sleep and can cause deadlock, where
> > > as GFP_ATOMIC may fail but certainly avoids deadlock
> >
> > Great catch.  Thanks!
> >
> > However, gfp_t is passed to send_mad and we should pass that down and
> use it.
> 
> >         spin_lock_irqsave(&ib_nl_request_lock, flags);
> > -       ret = ib_nl_send_msg(query);
> > +       ret = ib_nl_send_msg(query, gfp_mask);
> 
> A spin lock is guarenteed held around ib_nl_send_msg, so it's allocations
> have to be atomic, can't use gfp_mask here..
> 
> I do wonder if it is a good idea to call ib_nl_send_msg with a spinlock held
> though.. Would be nice to see that go away.

We have to hold the lock to protect against a race condition that a quick response will try to free the request from the ib_nl_request_list before we even put it on the list.

> 
> Jason

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC
  2015-10-27 18:56               ` Wan, Kaike
@ 2015-10-27 20:00                   ` Jason Gunthorpe
  -1 siblings, 0 replies; 28+ messages in thread
From: Jason Gunthorpe @ 2015-10-27 20:00 UTC (permalink / raw)
  To: Wan, Kaike
  Cc: Weiny, Ira, Saurabh Sengar, dledford-H+wXaHxf7aLQT0dZR+AlfA,
	Hefty, Sean, hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
	yun.wang-EIkl63zCoXaH+58JC4qpiA,
	linux-rdma-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA

On Tue, Oct 27, 2015 at 06:56:50PM +0000, Wan, Kaike wrote:
 
> > I do wonder if it is a good idea to call ib_nl_send_msg with a spinlock held
> > though.. Would be nice to see that go away.
> 
> We have to hold the lock to protect against a race condition that a
> quick response will try to free the request from the
> ib_nl_request_list before we even put it on the list.

Put is on the list first? Use a kref? Doesn't look like a big deal to
clean this up.

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC
@ 2015-10-27 20:00                   ` Jason Gunthorpe
  0 siblings, 0 replies; 28+ messages in thread
From: Jason Gunthorpe @ 2015-10-27 20:00 UTC (permalink / raw)
  To: Wan, Kaike
  Cc: Weiny, Ira, Saurabh Sengar, dledford, Hefty, Sean,
	hal.rosenstock, yun.wang, linux-rdma, linux-kernel

On Tue, Oct 27, 2015 at 06:56:50PM +0000, Wan, Kaike wrote:
 
> > I do wonder if it is a good idea to call ib_nl_send_msg with a spinlock held
> > though.. Would be nice to see that go away.
> 
> We have to hold the lock to protect against a race condition that a
> quick response will try to free the request from the
> ib_nl_request_list before we even put it on the list.

Put is on the list first? Use a kref? Doesn't look like a big deal to
clean this up.

Jason

^ permalink raw reply	[flat|nested] 28+ messages in thread

* [PATCH v2] efi: replace GFP_KERNEL with GFP_ATOMIC
@ 2015-10-28  3:42 Saurabh Sengar
  2015-11-03 16:36   ` Matt Fleming
  0 siblings, 1 reply; 28+ messages in thread
From: Saurabh Sengar @ 2015-10-28  3:42 UTC (permalink / raw)
  To: matt, linux-efi, linux-kernel; +Cc: Saurabh Sengar

replace GFP_KERNEL with GFP_ATOMIC, as code while holding a spinlock
should be atomic
GFP_KERNEL may sleep and can cause deadlock, where as GFP_ATOMIC may
fail but certainly avoids deadlock

Signed-off-by: Saurabh Sengar <saurabh.truth@gmail.com>
---
 drivers/firmware/efi/vars.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/firmware/efi/vars.c b/drivers/firmware/efi/vars.c
index 70a0fb1..d4eeebf 100644
--- a/drivers/firmware/efi/vars.c
+++ b/drivers/firmware/efi/vars.c
@@ -322,10 +322,11 @@ static unsigned long var_name_strnsize(efi_char16_t *variable_name,
  * disable the sysfs workqueue since the firmware is buggy.
  */
 static void dup_variable_bug(efi_char16_t *str16, efi_guid_t *vendor_guid,
-			     unsigned long len16)
+			     unsigned long len16, bool atomic)
 {
 	size_t i, len8 = len16 / sizeof(efi_char16_t);
 	char *str8;
+	int gfp_mask;
 
 	/*
 	 * Disable the workqueue since the algorithm it uses for
@@ -334,7 +335,12 @@ static void dup_variable_bug(efi_char16_t *str16, efi_guid_t *vendor_guid,
 	 */
 	efivar_wq_enabled = false;
 
-	str8 = kzalloc(len8, GFP_KERNEL);
+	if (atomic)
+		gfp_mask = GFP_ATOMIC;
+	else
+		gfp_mask = GFP_KERNEL;
+
+	str8 = kzalloc(len8, gfp_mask);
 	if (!str8)
 		return;
 
@@ -408,7 +414,7 @@ int efivar_init(int (*func)(efi_char16_t *, efi_guid_t, unsigned long, void *),
 			if (duplicates &&
 			    variable_is_present(variable_name, &vendor_guid, head)) {
 				dup_variable_bug(variable_name, &vendor_guid,
-						 variable_name_size);
+						 variable_name_size, atomic);
 				if (!atomic)
 					spin_lock_irq(&__efivars->lock);
 
-- 
1.9.1


^ permalink raw reply related	[flat|nested] 28+ messages in thread

* RE: [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC
  2015-10-27 20:00                   ` Jason Gunthorpe
  (?)
@ 2015-10-28  4:30                   ` Weiny, Ira
       [not found]                     ` <2807E5FD2F6FDA4886F6618EAC48510E1CBD4369-8k97q/ur5Z2krb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
  -1 siblings, 1 reply; 28+ messages in thread
From: Weiny, Ira @ 2015-10-28  4:30 UTC (permalink / raw)
  To: Jason Gunthorpe, Wan, Kaike
  Cc: Saurabh Sengar, dledford, Hefty, Sean, hal.rosenstock, yun.wang,
	linux-rdma, linux-kernel

> 
> On Tue, Oct 27, 2015 at 06:56:50PM +0000, Wan, Kaike wrote:
> 
> > > I do wonder if it is a good idea to call ib_nl_send_msg with a
> > > spinlock held though.. Would be nice to see that go away.
> >
> > We have to hold the lock to protect against a race condition that a
> > quick response will try to free the request from the
> > ib_nl_request_list before we even put it on the list.
> 
> Put is on the list first? Use a kref? Doesn't look like a big deal to clean this up.
> 
> Jason

Not sure what "Put is on the list first?" means.  I think it is valid to build the request, 
if success, add to the list, then send it.  That would solve the problem you mention 
above.  Was that what you hand in mind, Jason?

I don't have time to work on this right now, not sure about Kaike.  Until we can remove 
the spinlock the current proposed patch should be applied in the interim.  Sorry for the
noise before.

Reviewed-By: Ira Weiny <ira.weiny@intel.com>

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH] drivers: of: removing assignment of 0 to static variable
  2015-10-27  3:42 ` Saurabh Sengar
  (?)
@ 2015-10-30 18:30 ` Rob Herring
  -1 siblings, 0 replies; 28+ messages in thread
From: Rob Herring @ 2015-10-30 18:30 UTC (permalink / raw)
  To: Saurabh Sengar; +Cc: Frank Rowand, Grant Likely, devicetree, linux-kernel

On Mon, Oct 26, 2015 at 10:42 PM, Saurabh Sengar
<saurabh.truth@gmail.com> wrote:
> no need to initialise static variable with 0, hence correcting it.
>
> Signed-off-by: Saurabh Sengar <saurabh.truth@gmail.com>

Applied. Thanks.

Rob

> ---
>  drivers/of/fdt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 6e82bc42..63699dd 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -184,7 +184,7 @@ static void * unflatten_dt_node(const void *blob,
>         struct property *pp, **prev_pp = NULL;
>         const char *pathp;
>         unsigned int l, allocl;
> -       static int depth = 0;
> +       static int depth;
>         int old_depth;
>         int offset;
>         int has_name = 0;
> --
> 1.9.1
>

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2] efi: replace GFP_KERNEL with GFP_ATOMIC
@ 2015-11-03 16:36   ` Matt Fleming
  0 siblings, 0 replies; 28+ messages in thread
From: Matt Fleming @ 2015-11-03 16:36 UTC (permalink / raw)
  To: Saurabh Sengar; +Cc: linux-efi, linux-kernel

On Wed, 28 Oct, at 09:12:27AM, Saurabh Sengar wrote:
> replace GFP_KERNEL with GFP_ATOMIC, as code while holding a spinlock
> should be atomic
> GFP_KERNEL may sleep and can cause deadlock, where as GFP_ATOMIC may
> fail but certainly avoids deadlock
> 
> Signed-off-by: Saurabh Sengar <saurabh.truth@gmail.com>
> ---
>  drivers/firmware/efi/vars.c | 12 +++++++++---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/firmware/efi/vars.c b/drivers/firmware/efi/vars.c
> index 70a0fb1..d4eeebf 100644
> --- a/drivers/firmware/efi/vars.c
> +++ b/drivers/firmware/efi/vars.c
> @@ -322,10 +322,11 @@ static unsigned long var_name_strnsize(efi_char16_t *variable_name,
>   * disable the sysfs workqueue since the firmware is buggy.
>   */
>  static void dup_variable_bug(efi_char16_t *str16, efi_guid_t *vendor_guid,
> -			     unsigned long len16)
> +			     unsigned long len16, bool atomic)
>  {
>  	size_t i, len8 = len16 / sizeof(efi_char16_t);
>  	char *str8;
> +	int gfp_mask;
>  
>  	/*
>  	 * Disable the workqueue since the algorithm it uses for
> @@ -334,7 +335,12 @@ static void dup_variable_bug(efi_char16_t *str16, efi_guid_t *vendor_guid,
>  	 */
>  	efivar_wq_enabled = false;
>  
> -	str8 = kzalloc(len8, GFP_KERNEL);
> +	if (atomic)
> +		gfp_mask = GFP_ATOMIC;
> +	else
> +		gfp_mask = GFP_KERNEL;
> +
> +	str8 = kzalloc(len8, gfp_mask);
>  	if (!str8)
>  		return;
>  
> @@ -408,7 +414,7 @@ int efivar_init(int (*func)(efi_char16_t *, efi_guid_t, unsigned long, void *),
>  			if (duplicates &&
>  			    variable_is_present(variable_name, &vendor_guid, head)) {
>  				dup_variable_bug(variable_name, &vendor_guid,
> -						 variable_name_size);
> +						 variable_name_size, atomic);
>  				if (!atomic)
>  					spin_lock_irq(&__efivars->lock);

It's slightly winding code, but if you look at the callers of
efivar_init() you'll see that none of them set both 'atomic' and
'duplicates', so dup_variable_bug() will never be called while holding
a spinlock.

Or am I missing something?

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2] efi: replace GFP_KERNEL with GFP_ATOMIC
@ 2015-11-03 16:36   ` Matt Fleming
  0 siblings, 0 replies; 28+ messages in thread
From: Matt Fleming @ 2015-11-03 16:36 UTC (permalink / raw)
  To: Saurabh Sengar
  Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA

On Wed, 28 Oct, at 09:12:27AM, Saurabh Sengar wrote:
> replace GFP_KERNEL with GFP_ATOMIC, as code while holding a spinlock
> should be atomic
> GFP_KERNEL may sleep and can cause deadlock, where as GFP_ATOMIC may
> fail but certainly avoids deadlock
> 
> Signed-off-by: Saurabh Sengar <saurabh.truth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
>  drivers/firmware/efi/vars.c | 12 +++++++++---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/firmware/efi/vars.c b/drivers/firmware/efi/vars.c
> index 70a0fb1..d4eeebf 100644
> --- a/drivers/firmware/efi/vars.c
> +++ b/drivers/firmware/efi/vars.c
> @@ -322,10 +322,11 @@ static unsigned long var_name_strnsize(efi_char16_t *variable_name,
>   * disable the sysfs workqueue since the firmware is buggy.
>   */
>  static void dup_variable_bug(efi_char16_t *str16, efi_guid_t *vendor_guid,
> -			     unsigned long len16)
> +			     unsigned long len16, bool atomic)
>  {
>  	size_t i, len8 = len16 / sizeof(efi_char16_t);
>  	char *str8;
> +	int gfp_mask;
>  
>  	/*
>  	 * Disable the workqueue since the algorithm it uses for
> @@ -334,7 +335,12 @@ static void dup_variable_bug(efi_char16_t *str16, efi_guid_t *vendor_guid,
>  	 */
>  	efivar_wq_enabled = false;
>  
> -	str8 = kzalloc(len8, GFP_KERNEL);
> +	if (atomic)
> +		gfp_mask = GFP_ATOMIC;
> +	else
> +		gfp_mask = GFP_KERNEL;
> +
> +	str8 = kzalloc(len8, gfp_mask);
>  	if (!str8)
>  		return;
>  
> @@ -408,7 +414,7 @@ int efivar_init(int (*func)(efi_char16_t *, efi_guid_t, unsigned long, void *),
>  			if (duplicates &&
>  			    variable_is_present(variable_name, &vendor_guid, head)) {
>  				dup_variable_bug(variable_name, &vendor_guid,
> -						 variable_name_size);
> +						 variable_name_size, atomic);
>  				if (!atomic)
>  					spin_lock_irq(&__efivars->lock);

It's slightly winding code, but if you look at the callers of
efivar_init() you'll see that none of them set both 'atomic' and
'duplicates', so dup_variable_bug() will never be called while holding
a spinlock.

Or am I missing something?

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH] efi: replace GFP_KERNEL with GFP_ATOMIC
  2015-11-03 16:36   ` Matt Fleming
  (?)
@ 2015-11-03 17:38   ` Saurabh Sengar
  -1 siblings, 0 replies; 28+ messages in thread
From: Saurabh Sengar @ 2015-11-03 17:38 UTC (permalink / raw)
  To: matt, linux-kernel

>It's slightly winding code, but if you look at the callers of
>efivar_init() you'll see that none of them set both 'atomic' and
>'duplicates', so dup_variable_bug() will never be called while holding
>a spinlock.

>Or am I missing something?

I was assuming that there could be a possibility when both 'atomic' and 'duplicates' are set.
If both can never be set, then this patch does not make any sense, you are correct.
Thank you for review

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC
  2015-10-28  4:30                   ` Weiny, Ira
@ 2015-11-13  7:42                         ` Saurabh Sengar
  0 siblings, 0 replies; 28+ messages in thread
From: Saurabh Sengar @ 2015-11-13  7:42 UTC (permalink / raw)
  To: ira.weiny-ral2JQCrhuEAvxtiuMwx3w, kaike.wan-ral2JQCrhuEAvxtiuMwx3w
  Cc: sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
	hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
	dledford-H+wXaHxf7aLQT0dZR+AlfA,
	linux-rdma-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA

On Wed, 28 Oct 2015  at 04:30:10 +0000, Weiny, Ira wrote:
> Until we can remove the spinlock the current proposed patch should be applied 
> in the interim.  Sorry for the noise before.

> Reviewed-By: Ira Weiny <ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

Hi,

is this patch expected to be applied ?
--
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	[flat|nested] 28+ messages in thread

* Re: [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC
@ 2015-11-13  7:42                         ` Saurabh Sengar
  0 siblings, 0 replies; 28+ messages in thread
From: Saurabh Sengar @ 2015-11-13  7:42 UTC (permalink / raw)
  To: ira.weiny, kaike.wan
  Cc: sean.hefty, hal.rosenstock, dledford, linux-rdma, linux-kernel

On Wed, 28 Oct 2015  at 04:30:10 +0000, Weiny, Ira wrote:
> Until we can remove the spinlock the current proposed patch should be applied 
> in the interim.  Sorry for the noise before.

> Reviewed-By: Ira Weiny <ira.weiny@intel.com>

Hi,

is this patch expected to be applied ?

^ permalink raw reply	[flat|nested] 28+ messages in thread

* RE: [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC
  2015-11-13  7:42                         ` Saurabh Sengar
@ 2015-11-13 10:47                             ` Wan, Kaike
  -1 siblings, 0 replies; 28+ messages in thread
From: Wan, Kaike @ 2015-11-13 10:47 UTC (permalink / raw)
  To: Saurabh Sengar, Weiny, Ira
  Cc: Hefty, Sean, hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
	dledford-H+wXaHxf7aLQT0dZR+AlfA,
	linux-rdma-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA

I don't think so. 

The following patch has rendered this patch unnecessary:

https://patchwork.kernel.org/patch/7526811/

Kaike

> -----Original Message-----
> From: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [mailto:linux-rdma-
> owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org] On Behalf Of Saurabh Sengar
> Sent: Friday, November 13, 2015 2:42 AM
> To: Weiny, Ira; Wan, Kaike
> Cc: Hefty, Sean; hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org; linux-
> rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Subject: Re: [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC
> 
> On Wed, 28 Oct 2015  at 04:30:10 +0000, Weiny, Ira wrote:
> > Until we can remove the spinlock the current proposed patch should be
> > applied in the interim.  Sorry for the noise before.
> 
> > Reviewed-By: Ira Weiny <ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> 
> Hi,
> 
> is this patch expected to be applied ?
> --
> 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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* RE: [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC
@ 2015-11-13 10:47                             ` Wan, Kaike
  0 siblings, 0 replies; 28+ messages in thread
From: Wan, Kaike @ 2015-11-13 10:47 UTC (permalink / raw)
  To: Saurabh Sengar, Weiny, Ira
  Cc: Hefty, Sean, hal.rosenstock, dledford, linux-rdma, linux-kernel

I don't think so. 

The following patch has rendered this patch unnecessary:

https://patchwork.kernel.org/patch/7526811/

Kaike

> -----Original Message-----
> From: linux-rdma-owner@vger.kernel.org [mailto:linux-rdma-
> owner@vger.kernel.org] On Behalf Of Saurabh Sengar
> Sent: Friday, November 13, 2015 2:42 AM
> To: Weiny, Ira; Wan, Kaike
> Cc: Hefty, Sean; hal.rosenstock@gmail.com; dledford@redhat.com; linux-
> rdma@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC
> 
> On Wed, 28 Oct 2015  at 04:30:10 +0000, Weiny, Ira wrote:
> > Until we can remove the spinlock the current proposed patch should be
> > applied in the interim.  Sorry for the noise before.
> 
> > Reviewed-By: Ira Weiny <ira.weiny@intel.com>
> 
> Hi,
> 
> is this patch expected to be applied ?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the
> body of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC
  2015-11-13 10:47                             ` Wan, Kaike
@ 2015-11-13 12:37                                 ` Saurabh Sengar
  -1 siblings, 0 replies; 28+ messages in thread
From: Saurabh Sengar @ 2015-11-13 12:37 UTC (permalink / raw)
  To: kaike.wan-ral2JQCrhuEAvxtiuMwx3w
  Cc: ira.weiny-ral2JQCrhuEAvxtiuMwx3w,
	sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
	hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
	dledford-H+wXaHxf7aLQT0dZR+AlfA,
	linux-rdma-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA

On Fri, 13 Nov 2015  at 10:47:52 +0000, Wan, Kaike wrote:
> I don't think so.
> The following patch has rendered this patch unnecessary:
> https://patchwork.kernel.org/patch/7526811/
> Kaike

OK, could you please use "Reported-by" tag of my name in your patch

Regards,
Saurabh
--
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	[flat|nested] 28+ messages in thread

* Re: [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC
@ 2015-11-13 12:37                                 ` Saurabh Sengar
  0 siblings, 0 replies; 28+ messages in thread
From: Saurabh Sengar @ 2015-11-13 12:37 UTC (permalink / raw)
  To: kaike.wan
  Cc: ira.weiny, sean.hefty, hal.rosenstock, dledford, linux-rdma,
	linux-kernel

On Fri, 13 Nov 2015  at 10:47:52 +0000, Wan, Kaike wrote:
> I don't think so.
> The following patch has rendered this patch unnecessary:
> https://patchwork.kernel.org/patch/7526811/
> Kaike

OK, could you please use "Reported-by" tag of my name in your patch

Regards,
Saurabh

^ permalink raw reply	[flat|nested] 28+ messages in thread

end of thread, other threads:[~2015-11-13 12:37 UTC | newest]

Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-10-28  3:42 [PATCH v2] efi: replace GFP_KERNEL with GFP_ATOMIC Saurabh Sengar
2015-11-03 16:36 ` Matt Fleming
2015-11-03 16:36   ` Matt Fleming
2015-11-03 17:38   ` [PATCH] " Saurabh Sengar
  -- strict thread matches above, loose matches on Subject: below --
2015-10-27 18:42 Saurabh Sengar
2015-10-27 18:42 ` Saurabh Sengar
     [not found] <saurabh.truth@gmail.com>
2015-10-27 15:47 ` [PATCH] IB/sa: " Saurabh Sengar
2015-10-27 15:47   ` Saurabh Sengar
     [not found]   ` <1445960860-3396-1-git-send-email-saurabh.truth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-10-27 18:12     ` ira.weiny
2015-10-27 18:12       ` ira.weiny
     [not found]       ` <20151027181235.GA27038-W4f6Xiosr+yv7QzWx2u06xL4W9x8LtSr@public.gmane.org>
2015-10-27 18:16         ` Jason Gunthorpe
2015-10-27 18:16           ` Jason Gunthorpe
     [not found]           ` <20151027181652.GA6879-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2015-10-27 18:20             ` ira.weiny
2015-10-27 18:20               ` ira.weiny
2015-10-27 18:56             ` Wan, Kaike
2015-10-27 18:56               ` Wan, Kaike
     [not found]               ` <3F128C9216C9B84BB6ED23EF16290AFB18571E3F-8k97q/ur5Z2krb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
2015-10-27 20:00                 ` Jason Gunthorpe
2015-10-27 20:00                   ` Jason Gunthorpe
2015-10-28  4:30                   ` Weiny, Ira
     [not found]                     ` <2807E5FD2F6FDA4886F6618EAC48510E1CBD4369-8k97q/ur5Z2krb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
2015-11-13  7:42                       ` Saurabh Sengar
2015-11-13  7:42                         ` Saurabh Sengar
     [not found]                         ` <1447400547-11490-1-git-send-email-saurabh.truth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-11-13 10:47                           ` Wan, Kaike
2015-11-13 10:47                             ` Wan, Kaike
     [not found]                             ` <3F128C9216C9B84BB6ED23EF16290AFB1857D86D-8k97q/ur5Z2krb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
2015-11-13 12:37                               ` Saurabh Sengar
2015-11-13 12:37                                 ` Saurabh Sengar
2015-10-27  3:42 [PATCH] drivers: of: removing assignment of 0 to static variable Saurabh Sengar
2015-10-27  3:42 ` Saurabh Sengar
2015-10-30 18:30 ` Rob Herring

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.