lkml.org 
[lkml]   [2004]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectVFS interactions with UML and other big UML changes (was: Re: [patch 1/2] Uml - first part rework of run_helper() and users.)
Date
On Wednesday 01 December 2004 00:20, Andrew Morton wrote:
> blaisorblade_spam@yahoo.it wrote:
> > Fixed a file descriptor leak in the network driver when changing an IP
> > address.
> >
> > Fixed the error handling in run_helper.

> > Paolo notes:
> >
> > Actually, this is part one of the change, the exact one extracted from
> > Jeff Dike's incrementals tree before 2.6.9-rc big UML merge.
> >
> > There is some changes must be done, so I'm also sending a second patch
> > with this one, too. Separated for tracking purposes.
> >
> > Don't send this pair of ones to Linus before Jeff ACK's it - just put
> > into -mm for now.

> That makes five UML patches which I have queued up pending confirmation:
Ok, detailed answers for each one.


> hostfs-uml-set-sendfile-to-generic_file_sendfile.patch
> hostfs-uml-add-some-other-pagecache-methods.patch

For these two, I'm waiting mainline answers - the first one was tested and
worked, while the second not, but is no more intrusive. In general, the
patches themselves are good: hostfs already makes full use of the page cache.

My doubt (which actually is not related to the patches themselves) is here:

static struct address_space_operations hostfs_aops = {
.writepage = hostfs_writepage,
.readpage = hostfs_readpage,
/* .set_page_dirty = __set_page_dirty_nobuffers, */
.prepare_write = hostfs_prepare_write,
.commit_write = hostfs_commit_write
};

Actually, hostfs is a nodev filesystem, but I simply don't know if that
implies that it uses no buffers. So, should

.set_page_dirty = __set_page_dirty_nobuffers

be uncommented? Or should it be deleted (leaving it there is not a good
option).

I'm holding the patches because I don't know if using them could anyhow
trigger data loss from this bug, if it's a bug.

> uml-terminal-cleanup.patch

I don't know technically this one. It won't probably go in 2.6.10, I think
later... tested in the SuSE tree, but let's be quiet in merging _big_ things,
ok? It was also tested in a different tree, so it perfectly working on 2.6.9
does not mean perfectly working on current kernels.

Some other well tested patches (not these ones) are causing host problems,
i.e. UML processes crashing and staying in D state (this seems some kind of
ptrace bug, but still digging on this) - acked on 2.6.9 hosts.

Or dying completely but keeping some FS (a tmpfs mount used only for UML) from
being unmounted (yes, checked lsof, which shows nothing - I've heard rumors
of locks alive). It does not seem to be related to tmpfs in particular,
however.

> uml-first-part-rework-of-run_helper-and-users.patch
> uml-finish-fixing-run_helper-failure-path.patch
These are littler and somehow widely tested... but nobody complained with the
1st alone.

> Could you gents please put heads together and tell me whether and when
> these should go upstream?
--
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade
-
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 14:08    [W:0.044 / U:0.624 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site