[PATCH 2/2] powerpc/fadump: use kstrtoint to handle sysfs store

Hari Bathini hbathini at linux.vnet.ibm.com
Mon Nov 13 04:30:03 AEDT 2017


Thanks for the patch, Michal.


On Monday 26 June 2017 07:36 PM, Michal Suchanek wrote:
> Currently sysfs store handlers in fadump use if buf[0] == 'char'.
>
> This means input "100foo" is interpreted as '1' and "01" as '0'.
>
> Change to kstrtoint so leading zeroes and the like is handled in
> expected way.
>
> Signed-off-by: Michal Suchanek <msuchanek at suse.de>

Acked-by: Hari Bathini <hbathini at linux.vnet.ibm.com>

> ---
>   arch/powerpc/kernel/fadump.c | 17 +++++++++++++----
>   1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
> index 5a7355381dac..241eff0b5f76 100644
> --- a/arch/powerpc/kernel/fadump.c
> +++ b/arch/powerpc/kernel/fadump.c
> @@ -1161,10 +1161,15 @@ static ssize_t fadump_release_memory_store(struct kobject *kobj,
>   					struct kobj_attribute *attr,
>   					const char *buf, size_t count)
>   {
> +	int input = -1;
> +
>   	if (!fw_dump.dump_active)
>   		return -EPERM;
>
> -	if (buf[0] == '1') {
> +	if (kstrtoint(buf, 0, &input))
> +		return -EINVAL;
> +
> +	if (input == 1) {
>   		/*
>   		 * Take away the '/proc/vmcore'. We are releasing the dump
>   		 * memory, hence it will not be valid anymore.
> @@ -1198,21 +1203,25 @@ static ssize_t fadump_register_store(struct kobject *kobj,
>   					const char *buf, size_t count)
>   {
>   	int ret = 0;
> +	int input = -1;
>
>   	if (!fw_dump.fadump_enabled || fdm_active)
>   		return -EPERM;
>
> +	if (kstrtoint(buf, 0, &input))
> +		return -EINVAL;
> +
>   	mutex_lock(&fadump_mutex);
>
> -	switch (buf[0]) {
> -	case '0':
> +	switch (input) {
> +	case 0:
>   		if (fw_dump.dump_registered == 0) {
>   			goto unlock_out;
>   		}
>   		/* Un-register Firmware-assisted dump */
>   		fadump_unregister_dump(&fdm);
>   		break;
> -	case '1':
> +	case 1:
>   		if (fw_dump.dump_registered == 1) {
>   			goto unlock_out;
>   		}


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20171112/e8c82f92/attachment.html>


More information about the Linuxppc-dev mailing list