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] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 4 Nov 2009 10:20:26 -0800
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Bjorn Helgaas <bjorn.helgaas@...com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org
Subject: Re: [PATCH] resources: when allocate_resource() fails, leave
 resource untouched

On Mon, 02 Nov 2009 10:45:36 -0700
Bjorn Helgaas <bjorn.helgaas@...com> wrote:

> When "allocate_resource(root, new, size, ...)" fails, we currently
> clobber "new".  This is inconvenient for the caller, who might care
> about the original contents of the resource.
> 
> For example, when pci_bus_alloc_resource() fails, the "can't allocate
> mem resource %pR" message from pci_assign_resources() currently
> contains junk for the resource start/end.
> 
> This patch delays the "new" update until we're about to return
> success.
> 
> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@...com>
> ---
>  kernel/resource.c |   26 ++++++++++++++------------
>  1 files changed, 14 insertions(+), 12 deletions(-)
> 
> diff --git a/kernel/resource.c b/kernel/resource.c
> index fb11a58..dc15686 100644
> --- a/kernel/resource.c
> +++ b/kernel/resource.c
> @@ -308,35 +308,37 @@ static int find_resource(struct resource *root,
> struct resource *new, void *alignf_data)
>  {
>  	struct resource *this = root->child;
> +	resource_size_t start, end;
>  
> -	new->start = root->start;
> +	start = root->start;
>  	/*
>  	 * Skip past an allocated resource that starts at 0, since
> the assignment
>  	 * of this->start - 1 to new->end below would cause an
> underflow. */
>  	if (this && this->start == 0) {
> -		new->start = this->end + 1;
> +		start = this->end + 1;
>  		this = this->sibling;
>  	}
>  	for(;;) {
>  		if (this)
> -			new->end = this->start - 1;
> +			end = this->start - 1;
>  		else
> -			new->end = root->end;
> -		if (new->start < min)
> -			new->start = min;
> -		if (new->end > max)
> -			new->end = max;
> -		new->start = ALIGN(new->start, align);
> +			end = root->end;
> +		if (start < min)
> +			start = min;
> +		if (end > max)
> +			end = max;
> +		start = ALIGN(start, align);
>  		if (alignf)
>  			alignf(alignf_data, new, size, align);
> -		if (new->start < new->end && new->end - new->start
> >= size - 1) {
> -			new->end = new->start + size - 1;
> +		if (start < end && end - start >= size - 1) {
> +			new->start = start;
> +			new->end = start + size - 1;
>  			return 0;
>  		}
>  		if (!this)
>  			break;
> -		new->start = this->end + 1;
> +		start = this->end + 1;
>  		this = this->sibling;
>  	}
>  	return -EBUSY;

Seems like a reasonable change to me.  Linus is usually the gatekeeper
for resource.c.

-- 
Jesse Barnes, Intel Open Source Technology Center
--
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