[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTimTZKzXfBJCbzCyq3LwKvn3aCqyHjd5VXhnejfV@mail.gmail.com>
Date: Fri, 20 Aug 2010 12:43:28 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Ian Campbell <ijc@...lion.org.uk>
Cc: linux-kernel@...r.kernel.org, stable@...nel.org,
stable-review@...nel.org, akpm@...ux-foundation.org,
alan@...rguk.ukuu.org.uk, Greg KH <gregkh@...e.de>
Subject: Re: [2/3] mm: fix up some user-visible effects of the stack guard page
On Fri, Aug 20, 2010 at 11:59 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> It should be a pretty straightforward search-and-replace. And almost
> all of it would be real cleanups.
I take that back. Cleanups - probably. Simple search-and-replace? No.
That vm_next thing is all over the place, and all of the code knows
that the last vma has a vm_next that is NULL.
So switching it to the "<linux/list.h>" kind of accessors would be a major pain.
There's also lots of really ugly code that is all about the "we can't
easily get to the 'prev' entry in the list". Stuff that would be
cleaned up if we just had a vm_prev, but where the cleanups is just
pretty painful.
> And it would be trivial to change the loops like
>
> for (vma = mm->mmap; vma; vma = vma->vm_next)
>
> into basically just
>
> list_for_each_entry(vma, &mm->mmap, vm_list)
Yeah, no. It looks like adding a "vm_prev" and doing a regular doubly
linked list thing wouldn't be too bad. But switching over to the
list.h version looks like a nightmare.
Too bad.
Linus
--
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