lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <94F2FBAB4432B54E8AACC7DFDE6C92E37C7D13E4@ORSMSX103.amr.corp.intel.com>
Date:	Fri, 24 Jan 2014 16:29:19 +0000
From:	"Moore, Robert" <robert.moore@...el.com>
To:	Hanjun Guo <hanjun.guo@...aro.org>,
	"Zheng, Lv" <lv.zheng@...el.com>
CC:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"devel@...ica.org" <devel@...ica.org>,
	"patches@...aro.org" <patches@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linaro-acpi@...ts.linaro.org" <linaro-acpi@...ts.linaro.org>
Subject: RE: [PATCH 1/2] ACPI / ACPICA: refactor acpi_evaluate_object() to
 reduce nesting if

Please file a bugzilla on this at:

https://bugs.acpica.org/

thanks.
Bob


> -----Original Message-----
> From: Hanjun Guo [mailto:hanjun.guo@...aro.org]
> Sent: Friday, January 24, 2014 8:20 AM
> To: Zheng, Lv; Moore, Robert
> Cc: Rafael J. Wysocki; linux-acpi@...r.kernel.org; devel@...ica.org;
> patches@...aro.org; linux-kernel@...r.kernel.org; linaro-
> acpi@...ts.linaro.org; Hanjun Guo
> Subject: [PATCH 1/2] ACPI / ACPICA: refactor acpi_evaluate_object() to
> reduce nesting if
> 
> acpi_evaluate_object() has nesting if judgement to make code a little bit
> complicated, refactor it to make things simple.
> 
> Signed-off-by: Hanjun Guo <hanjun.guo@...aro.org>
> ---
>  drivers/acpi/acpica/nsxfeval.c |  104 +++++++++++++++++++----------------
> -----
>  1 file changed, 50 insertions(+), 54 deletions(-)
> 
> diff --git a/drivers/acpi/acpica/nsxfeval.c
> b/drivers/acpi/acpica/nsxfeval.c index 1f0c28b..a1b0b88 100644
> --- a/drivers/acpi/acpica/nsxfeval.c
> +++ b/drivers/acpi/acpica/nsxfeval.c
> @@ -370,68 +370,64 @@ acpi_evaluate_object(acpi_handle handle,
>  	 * If we are expecting a return value, and all went well above,
>  	 * copy the return value to an external object.
>  	 */
> -	if (return_buffer) {
> -		if (!info->return_object) {
> -			return_buffer->length = 0;
> -		} else {
> -			if (ACPI_GET_DESCRIPTOR_TYPE(info->return_object) ==
> -			    ACPI_DESC_TYPE_NAMED) {
> -				/*
> -				 * If we received a NS Node as a return object,
> this means that
> -				 * the object we are evaluating has nothing
> interesting to
> -				 * return (such as a mutex, etc.)  We return an
> error because
> -				 * these types are essentially unsupported by this
> interface.
> -				 * We don't check up front because this makes it
> easier to add
> -				 * support for various types at a later date if
> necessary.
> -				 */
> -				status = AE_TYPE;
> -				info->return_object = NULL;	/* No need to delete
> a NS Node */
> -				return_buffer->length = 0;
> -			}
> +	if (!return_buffer)
> +		goto out;
> 
> -			if (ACPI_SUCCESS(status)) {
> +	if (!info->return_object) {
> +		return_buffer->length = 0;
> +		goto out;
> +	}
> 
> -				/* Dereference Index and ref_of references */
> +	if (ACPI_GET_DESCRIPTOR_TYPE(info->return_object) ==
> +		ACPI_DESC_TYPE_NAMED) {
> +		/*
> +		 * If we received a NS Node as a return object, this means
> that
> +		 * the object we are evaluating has nothing interesting to
> +		 * return (such as a mutex, etc.)  We return an error because
> +		 * these types are essentially unsupported by this interface.
> +		 * We don't check up front because this makes it easier to add
> +		 * support for various types at a later date if necessary.
> +		 */
> +		status = AE_TYPE;
> +		info->return_object = NULL;	/* No need to delete a NS Node
> */
> +		return_buffer->length = 0;
> +	}
> 
> -				acpi_ns_resolve_references(info);
> +	if (ACPI_FAILURE(status))
> +		goto out;
> 
> -				/* Get the size of the returned object */
> +	/* Dereference Index and ref_of references */
> 
> -				status =
> -				    acpi_ut_get_object_size(info->return_object,
> -							    &buffer_space_needed);
> -				if (ACPI_SUCCESS(status)) {
> -
> -					/* Validate/Allocate/Clear caller buffer */
> -
> -					status =
> -					    acpi_ut_initialize_buffer
> -					    (return_buffer,
> -					     buffer_space_needed);
> -					if (ACPI_FAILURE(status)) {
> -						/*
> -						 * Caller's buffer is too small or a
> new one can't
> -						 * be allocated
> -						 */
> -						ACPI_DEBUG_PRINT((ACPI_DB_INFO,
> -								  "Needed buffer size %X,
> %s\n",
> -								  (u32)
> -								  buffer_space_needed,
> -								  acpi_format_exception
> -								  (status)));
> -					} else {
> -						/* We have enough space for the
> object, build it */
> -
> -						status =
> -						    acpi_ut_copy_iobject_to_eobject
> -						    (info->return_object,
> -						     return_buffer);
> -					}
> -				}
> -			}
> +	acpi_ns_resolve_references(info);
> +
> +	/* Get the size of the returned object */
> +
> +	status = acpi_ut_get_object_size(info->return_object,
> +						&buffer_space_needed);
> +	if (ACPI_SUCCESS(status)) {
> +
> +		/* Validate/Allocate/Clear caller buffer */
> +
> +		status = acpi_ut_initialize_buffer(return_buffer,
> +							buffer_space_needed);
> +		if (ACPI_FAILURE(status)) {
> +			/*
> +			 * Caller's buffer is too small or a new one can't
> +			 * be allocated
> +			 */
> +			ACPI_DEBUG_PRINT((ACPI_DB_INFO,
> +					"Needed buffer size %X, %s\n",
> +					(u32)buffer_space_needed,
> +					 acpi_format_exception(status)));
> +		} else {
> +			/* We have enough space for the object, build it */
> +
> +			status = acpi_ut_copy_iobject_to_eobject(
> +					info->return_object, return_buffer);
>  		}
>  	}
> 
> +out:
>  	if (info->return_object) {
>  		/*
>  		 * Delete the internal return object. NOTE: Interpreter must
> be
> --
> 1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ