Re: [PATCH] Fix OOPS in show_uevent()

[Cornelia Huck]

On Fri, 10 Aug 2007 14:13:43 +0400,
Pavel Emelyanov <xemul@xxxxxxxxxx> wrote:

> The last hunk in this patch fixes this.

Looks sane.

> The other problem is that the envp passed to bus, type and platform callbacks
> from dev_uevent() is the same, so the callbacks can overwrite the info, written
> by the others. Did I miss something important?

I don't think so. 

> 
> This is for 2.6.23-rc2-mm1
> 
> Signed-off-by: Pavel Emelyanov <xemul@xxxxxxxxxx>
> 
> ---
> 
> --- ./drivers/base/core.c.ubug	2007-08-10 14:07:26.000000000 +0400
> +++ ./drivers/base/core.c	2007-08-10 14:07:15.000000000 +0400
> @@ -222,6 +222,11 @@ static int dev_uevent(struct kset *kset,
>  		if (retval)
>  			pr_debug ("%s: bus uevent() returned %d\n",
>  				  __FUNCTION__, retval);
> +
> +		while (*envp != NULL) {
> +			envp++;
> +			num_envp--;
> +		}

Hm, we may also want to adjust the remaining buffer size here, but only
the ->uevent() method has that knowledge...

>  	}
> 
>  	if (dev->class && dev->class->dev_uevent) {
> @@ -230,6 +235,11 @@ static int dev_uevent(struct kset *kset,
>  		if (retval)
>  			pr_debug("%s: class uevent() returned %d\n",
>  				 __FUNCTION__, retval);
> +
> +		while (*envp != NULL) {
> +			envp++;
> +			num_envp--;
> +		}
>  	}
> 
>  	if (dev->type && dev->type->uevent) {
> @@ -238,6 +248,11 @@ static int dev_uevent(struct kset *kset,
>  		if (retval)
>  			pr_debug("%s: dev_type uevent() returned %d\n",
>  				 __FUNCTION__, retval);
> +
> +		while (*envp != NULL) {
> +			envp++;
> +			num_envp--;
> +		}
>  	}
> 
>  	return retval;
> --- ./drivers/base/platform.c.ubug	2007-08-10 14:07:44.000000000 +0400
> +++ ./drivers/base/platform.c	2007-08-10 13:58:55.000000000 +0400
> @@ -547,6 +547,7 @@ static int platform_uevent(struct device
> 
>  	envp[0] = buffer;
>  	snprintf(buffer, buffer_size, "MODALIAS=%s", pdev->name);
> +	envp[1] = NULL;
>  	return 0;
>  }
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/