Skip to contentSkip to conversation

drivers: of: removing assignment of 0 to static variable

PATCH Applied Saurabh Sengar 6 participants 16 messages Oct 27, 2015 – Nov 13, 2015 9 messages not in the archive

Subsystems (3)
lore
Share & tools
lore
#1 lore raw

PATCH 1/1 drivers: of: removing assignment of 0 to static variable

In reply to a message not in the archive

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

---
 drivers/of/fdt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/of/fdt.c +1 -1
index 6e82bc42..63699dd 100644
@@ -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;
Signature · 6 lines
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#3 lore raw

PATCH 1/1 IB/sa: replace GFP_KERNEL with GFP_ATOMIC

In reply to a message not in the archive

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

---
 drivers/infiniband/core/sa_query.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/infiniband/core/sa_query.c +2 -2
index 8c014b3..cd1f911 100644
@@ -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
Signature · 6 lines
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#5 lore raw

Re: [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC

In reply to a message not in the archive
Quoted 4 lines · 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

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

(quoted diff) +0 -0

b/drivers/infiniband/core/sa_query.c
index 8c014b33d8e0..54d454042b28 100644

drivers/infiniband/core/sa_query.c +6 -6
@@ -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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#7 lore raw

Re: [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC

In reply to a message not in the archive

drivers/infiniband/core/sa_query.c static int ib_nl_make_request(struct ib_sa_query *query) · line 566

Quoted 13 lines · ira.weiny
Quoted 4 lines · 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

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);
drivers/infiniband/core/sa_query.c +1 -1
-       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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#9 lore raw

Re: [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC

In reply to a message not in the archive
Quoted 15 lines · Jason Gunthorpe

drivers/infiniband/core/sa_query.c static int ib_nl_make_request(struct ib_sa_query *query) · line 566

Quoted 13 lines · ira.weiny
Quoted 4 lines · 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

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);
drivers/infiniband/core/sa_query.c +1 -1
-       ret = ib_nl_send_msg(query);
+       ret = ib_nl_send_msg(query, gfp_mask);
Quoted 5 lines

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

Quoted 2 lines

Jason

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#20 lore raw

PATCH 1/1 efi: replace GFP_KERNEL with GFP_ATOMIC

In reply to a message not in the archive

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

---
 drivers/firmware/efi/vars.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/firmware/efi/vars.c +1 -1
index 70a0fb1..c07de85 100644
@@ -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;
 
Signature · 1 line
1.9.1
#10 lore raw

RE: [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC

In reply to a message not in the archive
Quoted 26 lines

-----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; [email protected]; Hefty, Sean; [email protected]; [email protected]; Wan, Kaike; linux- [email protected]; [email protected]
Subject: Re: [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC

Quoted 8 lines · ira.weiny
Quoted 3 lines · 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

Great catch. Thanks!

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

use it.

drivers/infiniband/core/sa_query.c static int ib_nl_make_request(struct ib_sa_query *query) · line 566

Quoted 3 lines
        spin_lock_irqsave(&ib_nl_request_lock, flags);
drivers/infiniband/core/sa_query.c +1 -1
-       ret = ib_nl_send_msg(query);
+       ret = ib_nl_send_msg(query, gfp_mask);
Quoted 5 lines

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.

Quoted 2 lines

Jason

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#12 lore raw

Re: [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC

In reply to a message not in the archive
Quoted 6 lines · Kaike
Quoted 2 lines

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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#21 lore raw

PATCH v2 1/1 efi: replace GFP_KERNEL with GFP_ATOMIC

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

---
 drivers/firmware/efi/vars.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)
drivers/firmware/efi/vars.c +9 -3
index 70a0fb1..d4eeebf 100644
@@ -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);
 
Signature · 1 line
1.9.1
Reviewed-by
#13 lore raw

RE: [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC

In reply to Jason Gunthorpe
Quoted 6 lines · Kaike
Quoted 4 lines
Quoted 3 lines

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.

Quoted 7 lines
Quoted 3 lines

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.

Applied
#2 lore raw
In reply to Saurabh Sengar
Quoted 3 lines · Saurabh Sengar

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

Applied. Thanks.

Rob

Quoted 20 lines
---
 drivers/of/fdt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/of/fdt.c +1 -2
index 6e82bc42..63699dd 100644
@@ -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

#23 lore raw

Re: [PATCH v2] efi: replace GFP_KERNEL with GFP_ATOMIC

In reply to a message not in the archive
Quoted 42 lines · 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

---
 drivers/firmware/efi/vars.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)
drivers/firmware/efi/vars.c +8 -2
index 70a0fb1..d4eeebf 100644
@@ -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;
 

drivers/firmware/efi/vars.c int efivar_init(int (*func)(efi_char16_t *, efi_guid_t, unsigned long, void *), · line 419

Quoted 7 lines
drivers/firmware/efi/vars.c +1 -1
@@ -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?

#24 lore raw

Re: [PATCH] efi: replace GFP_KERNEL with GFP_ATOMIC

Quoted 6 lines

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

#15 lore raw

Re: [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC

In reply to a message not in the archive
Quoted 4 lines · Ira

Until we can remove the spinlock the current proposed patch should be applied in the interim. Sorry for the noise before.

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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#17 lore raw

RE: [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC

In reply to a message not in the archive

I don't think so.

The following patch has rendered this patch unnecessary:

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

Kaike

Quoted 15 lines

-----Original Message-----
From: [email protected] [mailto:linux-rdma- [email protected]] On Behalf Of Saurabh Sengar
Sent: Friday, November 13, 2015 2:42 AM
To: Weiny, Ira; Wan, Kaike
Cc: Hefty, Sean; [email protected]; [email protected]; linux- [email protected]; [email protected]
Subject: Re: [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC

Quoted 4 lines · Ira

Until we can remove the spinlock the current proposed patch should be applied in the interim. Sorry for the noise before.

Quoted 7 lines

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 [email protected] 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#19 lore raw

Re: [PATCH] IB/sa: replace GFP_KERNEL with GFP_ATOMIC

In reply to a message not in the archive
Quoted 4 lines · Kaike

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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html