diff mbox

[v3,1/3] Revert "clk: ppc-corenet: Fix Section mismatch warning"

Message ID 1417596833-31456-2-git-send-email-haokexin@gmail.com (mailing list archive)
State Not Applicable
Delegated to: Scott Wood
Headers show

Commit Message

Kevin Hao Dec. 3, 2014, 8:53 a.m. UTC 
This reverts commit da788acb28386aa896224e784954bb73c99ff26c.

That commit tried to fix the section mismatch warning by moving the
ppc_corenet_clk_driver struct to init section. This is definitely wrong
because the kernel would free the memories occupied by this struct
after boot while this driver is still registered in the driver core.
The kernel would panic when accessing this driver struct.

Cc: stable@vger.kernel.org # 3.17
Signed-off-by: Kevin Hao <haokexin@gmail.com>
Acked-by: Scott Wood <scottwood@freescale.com>
Acked-by: Michael Turquette <mturquette@linaro.org>
---
v3: Cc stable and add ack.

v2: A new patch in v2.

 drivers/clk/clk-ppc-corenet.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Scott Wood Dec. 4, 2014, 4:04 a.m. UTC | #1 
On Wed, 2014-12-03 at 16:53 +0800, Kevin Hao wrote:
> This reverts commit da788acb28386aa896224e784954bb73c99ff26c.
> 
> That commit tried to fix the section mismatch warning by moving the
> ppc_corenet_clk_driver struct to init section. This is definitely wrong
> because the kernel would free the memories occupied by this struct
> after boot while this driver is still registered in the driver core.
> The kernel would panic when accessing this driver struct.
> 
> Cc: stable@vger.kernel.org # 3.17

I don't see stable@vger.kernel.org in the actual CC list.

-Scott
Kevin Hao Dec. 4, 2014, 4:38 a.m. UTC | #2 
On Wed, Dec 03, 2014 at 10:04:51PM -0600, Scott Wood wrote:
> On Wed, 2014-12-03 at 16:53 +0800, Kevin Hao wrote:
> > This reverts commit da788acb28386aa896224e784954bb73c99ff26c.
> > 
> > That commit tried to fix the section mismatch warning by moving the
> > ppc_corenet_clk_driver struct to init section. This is definitely wrong
> > because the kernel would free the memories occupied by this struct
> > after boot while this driver is still registered in the driver core.
> > The kernel would panic when accessing this driver struct.
> > 
> > Cc: stable@vger.kernel.org # 3.17
> 
> I don't see stable@vger.kernel.org in the actual CC list.

With the above cc tag, Won't this get automatically included in the stable
tree once it is merged into mainline? As I know, we only need to explicitly
send the patch to stable@vger.kernel.org only when that patch was already
merged into mainline without the corresponding cc stable tag and we also want
the stable tree include it. Did I miss something?

Thanks,
Kevin
Scott Wood Dec. 4, 2014, 4:46 a.m. UTC | #3 
On Thu, 2014-12-04 at 12:38 +0800, Kevin Hao wrote:
> On Wed, Dec 03, 2014 at 10:04:51PM -0600, Scott Wood wrote:
> > On Wed, 2014-12-03 at 16:53 +0800, Kevin Hao wrote:
> > > This reverts commit da788acb28386aa896224e784954bb73c99ff26c.
> > > 
> > > That commit tried to fix the section mismatch warning by moving the
> > > ppc_corenet_clk_driver struct to init section. This is definitely wrong
> > > because the kernel would free the memories occupied by this struct
> > > after boot while this driver is still registered in the driver core.
> > > The kernel would panic when accessing this driver struct.
> > > 
> > > Cc: stable@vger.kernel.org # 3.17
> > 
> > I don't see stable@vger.kernel.org in the actual CC list.
> 
> With the above cc tag, Won't this get automatically included in the stable
> tree once it is merged into mainline? As I know, we only need to explicitly
> send the patch to stable@vger.kernel.org only when that patch was already
> merged into mainline without the corresponding cc stable tag and we also want
> the stable tree include it. Did I miss something?

I reread stable_kernel_rules.txt and it looks like you're right, though
usually it ends up on the real CC list anyway due to how git send-email
works.

Since only this first patch is a critical bugfix, and there's no
arch/powerpc content in that patch, I think it should go via Mike's tree
if it's to go in for 3.18 (if it's not already too late).  Or, to keep
things simple given the dependency of the following patches, we could
batch them all together for -next and add a # 3.18 stable request.

-Scott
Kevin Hao Dec. 4, 2014, 6:06 a.m. UTC | #4 
On Wed, Dec 03, 2014 at 10:46:24PM -0600, Scott Wood wrote:
> Since only this first patch is a critical bugfix, and there's no
> arch/powerpc content in that patch, I think it should go via Mike's tree
> if it's to go in for 3.18 (if it's not already too late).  Or, to keep
> things simple given the dependency of the following patches, we could
> batch them all together for -next and add a # 3.18 stable request.

We don't need to explicitly add a #3.18 stable request in this case. As I know,
we only need to indicate the first version which is affected by the bug fixed by
this commit in the cc tag. This would imply that the applicable stable kernel
version rang should be from 3.17 to the previous version of the kernel which
finally merge this commit.

Thanks,
Kevin
Scott Wood Dec. 5, 2014, 1:10 a.m. UTC | #5 
On Thu, 2014-12-04 at 14:06 +0800, Kevin Hao wrote:
> On Wed, Dec 03, 2014 at 10:46:24PM -0600, Scott Wood wrote:
> > Since only this first patch is a critical bugfix, and there's no
> > arch/powerpc content in that patch, I think it should go via Mike's tree
> > if it's to go in for 3.18 (if it's not already too late).  Or, to keep
> > things simple given the dependency of the following patches, we could
> > batch them all together for -next and add a # 3.18 stable request.
> 
> We don't need to explicitly add a #3.18 stable request in this case. As I know,
> we only need to indicate the first version which is affected by the bug fixed by
> this commit in the cc tag. This would imply that the applicable stable kernel
> version rang should be from 3.17 to the previous version of the kernel which
> finally merge this commit.

OK.

-Scott
Scott Wood Dec. 5, 2014, 3:51 a.m. UTC | #6 
On Wed, 2014-12-03 at 16:53 +0800, Kevin Hao wrote:
> This reverts commit da788acb28386aa896224e784954bb73c99ff26c.
> 
> That commit tried to fix the section mismatch warning by moving the
> ppc_corenet_clk_driver struct to init section. This is definitely wrong
> because the kernel would free the memories occupied by this struct
> after boot while this driver is still registered in the driver core.
> The kernel would panic when accessing this driver struct.
> 
> Cc: stable@vger.kernel.org # 3.17
> Signed-off-by: Kevin Hao <haokexin@gmail.com>
> Acked-by: Scott Wood <scottwood@freescale.com>
> Acked-by: Michael Turquette <mturquette@linaro.org>
> ---
> v3: Cc stable and add ack.
> 
> v2: A new patch in v2.
> 
>  drivers/clk/clk-ppc-corenet.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/clk-ppc-corenet.c b/drivers/clk/clk-ppc-corenet.c
> index b6e6c85507a5..0a47d6f49cd6 100644
> --- a/drivers/clk/clk-ppc-corenet.c
> +++ b/drivers/clk/clk-ppc-corenet.c
> @@ -291,7 +291,7 @@ static const struct of_device_id ppc_clk_ids[] __initconst = {
>  	{}
>  };
>  
> -static struct platform_driver ppc_corenet_clk_driver __initdata = {
> +static struct platform_driver ppc_corenet_clk_driver = {
>  	.driver = {
>  		.name = "ppc_corenet_clock",
>  		.of_match_table = ppc_clk_ids,

This patch is going to conflict with commit a4ae8f3b0f7ac6ab3 "clk: drop
owner assignment from platform_drivers" in linux-next -- or rather,
you've based this on that patch, but it's not in mpe's next branch, so I
get a merge conflict and there'd be another merge conflict later on to
get back to the newer base.

I really think this should go via the clock tree.  That's where the
breakage was introduced in the first place...

-Scott
Kevin Hao Dec. 9, 2014, 1:34 a.m. UTC | #7 
On Thu, Dec 04, 2014 at 09:51:59PM -0600, Scott Wood wrote:
> This patch is going to conflict with commit a4ae8f3b0f7ac6ab3 "clk: drop
> owner assignment from platform_drivers" in linux-next -- or rather,
> you've based this on that patch, but it's not in mpe's next branch, so I
> get a merge conflict and there'd be another merge conflict later on to
> get back to the newer base.
> 
> I really think this should go via the clock tree.  That's where the
> breakage was introduced in the first place...

Hi Mike,

Could you pick up these patches?

Thanks,
Kevin
tang yuantian Jan. 15, 2015, 2:50 a.m. UTC | #8 
PING!

Thanks,
Yuantian

> -----Original Message-----
> From: Kevin Hao [mailto:haokexin@gmail.com]
> Sent: Wednesday, December 03, 2014 4:54 PM
> To: linuxppc-dev@lists.ozlabs.org
> Cc: Benjamin Herrenschmidt; Wood Scott-B07421; Mike Turquette; Lu
> Jingchang-B35083; Gerhard Sittig; Tang Yuantian-B29983
> Subject: [PATCH v3 1/3] Revert "clk: ppc-corenet: Fix Section mismatch warning"
> 
> This reverts commit da788acb28386aa896224e784954bb73c99ff26c.
> 
> That commit tried to fix the section mismatch warning by moving the
> ppc_corenet_clk_driver struct to init section. This is definitely wrong because the
> kernel would free the memories occupied by this struct after boot while this
> driver is still registered in the driver core.
> The kernel would panic when accessing this driver struct.
> 
> Cc: stable@vger.kernel.org # 3.17
> Signed-off-by: Kevin Hao <haokexin@gmail.com>
> Acked-by: Scott Wood <scottwood@freescale.com>
> Acked-by: Michael Turquette <mturquette@linaro.org>
> ---
> v3: Cc stable and add ack.
> 
> v2: A new patch in v2.
> 
>  drivers/clk/clk-ppc-corenet.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/clk-ppc-corenet.c b/drivers/clk/clk-ppc-corenet.c index
> b6e6c85507a5..0a47d6f49cd6 100644
> --- a/drivers/clk/clk-ppc-corenet.c
> +++ b/drivers/clk/clk-ppc-corenet.c
> @@ -291,7 +291,7 @@ static const struct of_device_id ppc_clk_ids[] __initconst
> = {
>  	{}
>  };
> 
> -static struct platform_driver ppc_corenet_clk_driver __initdata = {
> +static struct platform_driver ppc_corenet_clk_driver = {
>  	.driver = {
>  		.name = "ppc_corenet_clock",
>  		.of_match_table = ppc_clk_ids,
> --
> 1.9.3
Mike Turquette Jan. 17, 2015, 7:32 p.m. UTC | #9 
Quoting Kevin Hao (2014-12-08 17:34:15)
> On Thu, Dec 04, 2014 at 09:51:59PM -0600, Scott Wood wrote:
> > This patch is going to conflict with commit a4ae8f3b0f7ac6ab3 "clk: drop
> > owner assignment from platform_drivers" in linux-next -- or rather,
> > you've based this on that patch, but it's not in mpe's next branch, so I
> > get a merge conflict and there'd be another merge conflict later on to
> > get back to the newer base.
> > 
> > I really think this should go via the clock tree.  That's where the
> > breakage was introduced in the first place...
> 
> Hi Mike,
> 
> Could you pick up these patches?

Kevin,

I've taken patch #1 into clk-fixes (will be sent out later today) and
patches #2 & #3 into clk-next towards 3.20.

Regards,
Mike

> 
> Thanks,
> Kevin
diff mbox

Patch

diff --git a/drivers/clk/clk-ppc-corenet.c b/drivers/clk/clk-ppc-corenet.c
index b6e6c85507a5..0a47d6f49cd6 100644
--- a/drivers/clk/clk-ppc-corenet.c
+++ b/drivers/clk/clk-ppc-corenet.c
@@ -291,7 +291,7 @@  static const struct of_device_id ppc_clk_ids[] __initconst = {
 	{}
 };
 
-static struct platform_driver ppc_corenet_clk_driver __initdata = {
+static struct platform_driver ppc_corenet_clk_driver = {
 	.driver = {
 		.name = "ppc_corenet_clock",
 		.of_match_table = ppc_clk_ids,