lkml.org 
[lkml]   [2003]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] page->flags corruption fix
On Sun, Oct 12, 2003 at 10:11:43AM -0400, Rik van Riel wrote:
> On Sun, 12 Oct 2003, Hugh Dickins wrote:
>
> > I agree on that too: I think Rik did it for atomicity throughout,
> > to make the safety obvious; but in practice it was already safe.
>
> Also to keep this fix future proof. Who knows whether
> a super-optimised patch that masks just this particular
> race condition will still be safe when XFS is merged ?
>
> I really don't like keeping the code fragile and making
> it easy to reintroduce bugs.

free_pages as said if it's buggy, then it can still trigger no matter
whatever you do there, at that deep point of free_pages a alloc_page
user will be able to get the page and corrupt it anyways, so it can't
help and it will never be able to help no matter what xfs or whatever
else gets merged. If that makes a difference alloc_page users will still
break it.

we can argue about the filemap.c part, but I'm sure the page_alloc.c part
can't make any sense ever.

Andrea - If you prefer relying on open source software, check these links:
rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.[45]/
http://www.cobite.com/cvsps/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.076 / U:0.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site