[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20091212193134.GD1308@ucw.cz>
Date: Sat, 12 Dec 2009 20:31:35 +0100
From: Pavel Machek <pavel@....cz>
To: Al Viro <viro@....linux.org.uk>
Cc: linux-arch@...r.kernel.org, torvalds@...ux-foundation.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/19] untangling do_mremap(), part 1
Hi!
> Take locating vma and checks on it to a separate helper (it will be
> shared between MREMAP_FIXED/non-MREMAP_FIXED cases when we split
> them in the next patch)
> +static struct vm_area_struct *vma_to_resize(unsigned long addr,
> + unsigned long old_len, unsigned long new_len, unsigned long *p)
> +{
> + struct mm_struct *mm = current->mm;
> + struct vm_area_struct *vma = find_vma(mm, addr);
> +
> + if (!vma || vma->vm_start > addr)
> + goto Efault;
> +
> + if (is_vm_hugetlb_page(vma))
> + goto Einval;
> +
> + /* We can't remap across vm area boundaries */
> + if (old_len > vma->vm_end - addr)
> + goto Efault;
...
> +Efault: /* very odd choice for most of the cases, but... */
> + return ERR_PTR(-EFAULT);
> +Einval:
> + return ERR_PTR(-EINVAL);
> +Enomem:
> + return ERR_PTR(-ENOMEM);
> +Eagain:
> + return ERR_PTR(-EAGAIN);
> +}
Could we just do returns directly, w/o the gotos? In this case I do
not think goto has advantages, as there's no cleanup to do...
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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