diff mbox series

[v2] RAS/CEC: Fix cec_init prototype

Message ID 20200805095708.83939-1-luca.stefani.ge1@gmail.com (mailing list archive)
State New, archived
Headers show
Series [v2] RAS/CEC: Fix cec_init prototype | expand

Commit Message

Luca Stefani Aug. 5, 2020, 9:57 a.m. UTC
* late_initcall expects a function that returns an integer
  -> Update the function signature to match.

Fixes: 9554bfe403nd ("x86/mce: Convert the CEC to use the MCE notifier")
Signed-off-by: Luca Stefani <luca.stefani.ge1@gmail.com>
---
 drivers/ras/cec.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

Comments

Sami Tolvanen Aug. 12, 2020, 9:09 p.m. UTC | #1
Hi Luca,

On Wed, Aug 05, 2020 at 11:57:08AM +0200, Luca Stefani wrote:
> * late_initcall expects a function that returns an integer
>   -> Update the function signature to match.
> 
> Fixes: 9554bfe403nd ("x86/mce: Convert the CEC to use the MCE notifier")
> Signed-off-by: Luca Stefani <luca.stefani.ge1@gmail.com>

Thank you for fixing this!

[Note that this v2 email never landed in my inbox, perhaps Gmail filtered
 it out due to a missing To: line?]

> ---
>  drivers/ras/cec.c | 9 +++++----
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/ras/cec.c b/drivers/ras/cec.c
> index 569d9ad2c594..6939aa5b3dc7 100644
> --- a/drivers/ras/cec.c
> +++ b/drivers/ras/cec.c
> @@ -553,20 +553,20 @@ static struct notifier_block cec_nb = {
>  	.priority	= MCE_PRIO_CEC,
>  };
>  
> -static void __init cec_init(void)
> +static int __init cec_init(void)
>  {
>  	if (ce_arr.disabled)
> -		return;
> +		return -ENODEV;
>  
>  	ce_arr.array = (void *)get_zeroed_page(GFP_KERNEL);
>  	if (!ce_arr.array) {
>  		pr_err("Error allocating CE array page!\n");
> -		return;
> +		return -ENOMEM;
>  	}
>  
>  	if (create_debugfs_nodes()) {
>  		free_page((unsigned long)ce_arr.array);
> -		return;
> +		return -ENOMEM;
>  	}
>  
>  	INIT_DELAYED_WORK(&cec_work, cec_work_fn);
> @@ -575,6 +575,7 @@ static void __init cec_init(void)
>  	mce_register_decode_chain(&cec_nb);
>  
>  	pr_info("Correctable Errors collector initialized.\n");
> +	return 0;
>  }
>  late_initcall(cec_init);

The type mismatch broke allyesconfig in my test tree and your patch
fixes the issue. Please feel free to add:

  Reviewed-and-tested-by: Sami Tolvanen <samitolvanen@google.com>

Sami
Borislav Petkov Aug. 17, 2020, 3:13 p.m. UTC | #2
On Wed, Aug 12, 2020 at 02:09:09PM -0700, Sami Tolvanen wrote:
> The type mismatch broke allyesconfig in my test tree and your patch
> fixes the issue.

How are you building your allyesconfigs? Because allyesconfig works here
fine on latest Linus tree.

Thx.
Sami Tolvanen Aug. 17, 2020, 3:58 p.m. UTC | #3
On Mon, Aug 17, 2020 at 8:13 AM Borislav Petkov <bp@alien8.de> wrote:
>
> On Wed, Aug 12, 2020 at 02:09:09PM -0700, Sami Tolvanen wrote:
> > The type mismatch broke allyesconfig in my test tree and your patch
> > fixes the issue.
>
> How are you building your allyesconfigs? Because allyesconfig works here
> fine on latest Linus tree.

Sorry for not clarifying. This was in a tree with patches for enabling
Clang's Control-Flow Integrity. However, this type mismatch looks like
something that should be fixed regardless.

Sami
Borislav Petkov Aug. 17, 2020, 5:41 p.m. UTC | #4
On Mon, Aug 17, 2020 at 08:58:26AM -0700, Sami Tolvanen wrote:
> Sorry for not clarifying. This was in a tree with patches for enabling
> Clang's Control-Flow Integrity.

Well, I just did:

$ make CC=clang-10 HOSTCC=clang-10 allyesconfig
$ make -j...

and it built fine here, no complaints. So your toolchain must have
something else.

> However, this type mismatch looks like something that should be fixed
> regardless.

No question there - I'm just trying to figure out how something as minor
as this would break a build.

Thx.
Sami Tolvanen Aug. 17, 2020, 6:11 p.m. UTC | #5
On Mon, Aug 17, 2020 at 10:40 AM Borislav Petkov <bp@alien8.de> wrote:
>
> On Mon, Aug 17, 2020 at 08:58:26AM -0700, Sami Tolvanen wrote:
> > Sorry for not clarifying. This was in a tree with patches for enabling
> > Clang's Control-Flow Integrity.
>
> Well, I just did:
>
> $ make CC=clang-10 HOSTCC=clang-10 allyesconfig
> $ make -j...
>
> and it built fine here, no complaints. So your toolchain must have
> something else.

Not the toolchain, the tree has patches for LTO+CFI, which tends to
break with type mismatches. This doesn't affect just building the
kernel with Clang without other changes.

Sami
Borislav Petkov Aug. 17, 2020, 6:54 p.m. UTC | #6
On Mon, Aug 17, 2020 at 11:11:02AM -0700, Sami Tolvanen wrote:
> Not the toolchain, the tree has patches for LTO+CFI, which tends to
> break with type mismatches. This doesn't affect just building the
> kernel with Clang without other changes.

Ok, that explains it.

As for why I'm still chasing down the exact reason for the reported
breakage: this will determine the urgency with which this fix is handled
and to which trees it needs to go so please be more precise next time
when saying "it broke". :)

Thx.
diff mbox series

Patch

diff --git a/drivers/ras/cec.c b/drivers/ras/cec.c
index 569d9ad2c594..6939aa5b3dc7 100644
--- a/drivers/ras/cec.c
+++ b/drivers/ras/cec.c
@@ -553,20 +553,20 @@  static struct notifier_block cec_nb = {
 	.priority	= MCE_PRIO_CEC,
 };
 
-static void __init cec_init(void)
+static int __init cec_init(void)
 {
 	if (ce_arr.disabled)
-		return;
+		return -ENODEV;
 
 	ce_arr.array = (void *)get_zeroed_page(GFP_KERNEL);
 	if (!ce_arr.array) {
 		pr_err("Error allocating CE array page!\n");
-		return;
+		return -ENOMEM;
 	}
 
 	if (create_debugfs_nodes()) {
 		free_page((unsigned long)ce_arr.array);
-		return;
+		return -ENOMEM;
 	}
 
 	INIT_DELAYED_WORK(&cec_work, cec_work_fn);
@@ -575,6 +575,7 @@  static void __init cec_init(void)
 	mce_register_decode_chain(&cec_nb);
 
 	pr_info("Correctable Errors collector initialized.\n");
+	return 0;
 }
 late_initcall(cec_init);