linux-kernel - Re: [PATCH 2/6] pm: at91: move the copying the sram function to the sram initializationi phase

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 7 Mar 2015 00:22:24 +0100
From:	Sylvain Rochet <sylvain.rochet@...secur.com>
To:	Wenyou Yang <wenyou.yang@...el.com>
Cc:	nicolas.ferre@...el.com, linux@...im.org.za,
	linux@....linux.org.uk, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org, alexandre.belloni@...e-electrons.com,
	patrice.vilchez@...el.com, sergei.shtylyov@...entembedded.com,
	mark.rutland@....com, lorenzo.pieralisi@....com
Subject: Re: [PATCH 2/6] pm: at91: move the copying the sram function to the
 sram initializationi phase

Hello Wenyou,


On Thu, Feb 12, 2015 at 10:46:49AM +0800, Wenyou Yang wrote:
> To decrease the suspend time, move copying the sram function to the sram
> initialization phase, instead of every time go to suspend.
> 
> In the meanwhile, substitute fncpy() for memcpy().
> 
> If there is no sram allocated for PM, the PM is not supported.

My board doesn't boot anymore with this change, I am not equipped enough 
to debug more, looks like fncpy() is writing the function on top of 
existing kernel code.

You said you had issues with fncpy(), I guess I am having the issue you 
had.


Moving the function copy from at91_pm_sram_init() to at91_pm_suspend() 
fixes the problem:

-------------------------8<-----------------------------------
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 9d74c85..31339b0 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -155,6 +155,10 @@ static void at91_pm_suspend(suspend_state_t state)
 	flush_cache_all();
 	outer_disable();
 
+	/* Copy the pm suspend handler to SRAM */
+	at91_suspend_sram_fn = fncpy(at91_suspend_sram_fn,
+			&at91_pm_suspend_in_sram, at91_pm_suspend_in_sram_sz);
+
 	at91_suspend_sram_fn(at91_pmc_base, at91_ramc_base[0],
 				at91_ramc_base[1], pm_data);
 
@@ -305,10 +309,6 @@ static void __init at91_pm_sram_init(void)
 		pr_warn("SRAM: Could not map\n");
 		return;
 	}
-
-	/* Copy the pm suspend handler to SRAM */
-	at91_suspend_sram_fn = fncpy(at91_suspend_sram_fn,
-			&at91_pm_suspend_in_sram, at91_pm_suspend_in_sram_sz);
 }
 
 static void __init at91_pm_init(void)
-------------------------8<-----------------------------------


Or using memcpy() instead of fncpy() also fixes the problem:

-------------------------8<-----------------------------------
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 9d74c85..feab89a 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -307,8 +307,8 @@ static void __init at91_pm_sram_init(void)
 	}
 
 	/* Copy the pm suspend handler to SRAM */
-	at91_suspend_sram_fn = fncpy(at91_suspend_sram_fn,
-			&at91_pm_suspend_in_sram, at91_pm_suspend_in_sram_sz);
+	memcpy(at91_suspend_sram_fn, at91_pm_suspend_in_sram,
+					at91_pm_suspend_in_sram_sz);
 }
 
 static void __init at91_pm_init(void)
-------------------------8<-----------------------------------


It works and fixes the hard fault, but I have no clue why :(


Sylvain
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/