Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1375683 > unrolled thread

[PATCH] efi: Use GFP_ATOMIC instead of GFP_KERNEL

Back to article view | Back to linux.kernel

Contents

  [PATCH] efi: Use GFP_ATOMIC instead of GFP_KERNEL Vaishali Thakkar <vaishali.thakkar@oracle.com> - 2016-04-11 13:00 +0200
    Re: [PATCH] efi: Use GFP_ATOMIC instead of GFP_KERNEL Matt Fleming <matt@codeblueprint.co.uk> - 2016-04-15 00:00 +0200
      Re: [PATCH] efi: Use GFP_ATOMIC instead of GFP_KERNEL Julia Lawall <julia.lawall@lip6.fr> - 2016-04-15 08:40 +0200

#1375683 — [PATCH] efi: Use GFP_ATOMIC instead of GFP_KERNEL

Function dup_variable_bug is called inside the spinlock.
This may lead to issues when kzalloc sleeps, so it is
better to use GFP_ATOMIC in this spinlocked context.

Problem found using Coccinelle.

Signed-off-by: Vaishali Thakkar <vaishali.thakkar@oracle.com>
---
 drivers/firmware/efi/vars.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/vars.c b/drivers/firmware/efi/vars.c
index 0ac594c..d5e2f28 100644
--- a/drivers/firmware/efi/vars.c
+++ b/drivers/firmware/efi/vars.c
@@ -411,7 +411,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;
 
-- 
2.1.4

[toc] | [next] | [standalone]

#1379316

On Mon, 11 Apr, at 04:23:29PM, Vaishali Thakkar wrote:
> Function dup_variable_bug is called inside the spinlock.
> This may lead to issues when kzalloc sleeps, so it is
> better to use GFP_ATOMIC in this spinlocked context.
> 
> Problem found using Coccinelle.
 
Dang it, I broke coccinelle ;)

> Signed-off-by: Vaishali Thakkar <vaishali.thakkar@oracle.com>
> ---
>  drivers/firmware/efi/vars.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/firmware/efi/vars.c b/drivers/firmware/efi/vars.c
> index 0ac594c..d5e2f28 100644
> --- a/drivers/firmware/efi/vars.c
> +++ b/drivers/firmware/efi/vars.c
> @@ -411,7 +411,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;
>  

This was brought up by Saurabh last year,

  https://lkml.kernel.org/r/1446003747-3760-1-git-send-email-saurabh.truth@gmail.com

dup_variable_bug() is never called while holding the spinlock in
practice, and I'm guessing Coccinelle cannot understand that because
it'd need to look at program control flow, across multiple compilation
units.

If anyone wants to send a patch to clean up the EFI code so that it's
easier for coccinelle to check it, I'd be happy to review it.

[toc] | [prev] | [next] | [standalone]

#1379474

On Thu, 14 Apr 2016, Matt Fleming wrote:

> On Mon, 11 Apr, at 04:23:29PM, Vaishali Thakkar wrote:
> > Function dup_variable_bug is called inside the spinlock.
> > This may lead to issues when kzalloc sleeps, so it is
> > better to use GFP_ATOMIC in this spinlocked context.
> > 
> > Problem found using Coccinelle.
>  
> Dang it, I broke coccinelle ;)
> 
> > Signed-off-by: Vaishali Thakkar <vaishali.thakkar@oracle.com>
> > ---
> >  drivers/firmware/efi/vars.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/firmware/efi/vars.c b/drivers/firmware/efi/vars.c
> > index 0ac594c..d5e2f28 100644
> > --- a/drivers/firmware/efi/vars.c
> > +++ b/drivers/firmware/efi/vars.c
> > @@ -411,7 +411,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;
> >  
> 
> This was brought up by Saurabh last year,
> 
>   https://lkml.kernel.org/r/1446003747-3760-1-git-send-email-saurabh.truth@gmail.com
> 
> dup_variable_bug() is never called while holding the spinlock in
> practice, and I'm guessing Coccinelle cannot understand that because
> it'd need to look at program control flow, across multiple compilation
> units.
> 
> If anyone wants to send a patch to clean up the EFI code so that it's
> easier for coccinelle to check it, I'd be happy to review it.

I looked at it a bit with Vaishali.  I wonder if it would be possible at 
least to have only one flag?  Then one wouldn't have to maintain the 
subtle relationship between atomic and duplicates.  I'm not sure that it 
would help Coccinelle, but at least one could see more quickly that 
Coccinelle is giving a false positive.

julia

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web