drivers: of: removing assignment of 0 to static variable

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

Signed-off-by Saurabh Sengar <[email protected]>

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

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

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

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

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.

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

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 <[email protected]>

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

Reviewed-by Ira Weiny <[email protected]>

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

I don't think so.
The following patch has rendered this patch unnecessary:
https://patchwork.kernel.org/patch/7526811/
Kaike

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 <[email protected]>

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

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?