From: Ingo van Lil <inguin@gmx.de>
To: Jeff Dike <jdike@addtoit.com>
Cc: user-mode-linux-devel@lists.sourceforge.net
Subject: Re: [uml-devel] hostfs oddities
Date: Tue, 08 Jul 2008 16:15:00 +0200 [thread overview]
Message-ID: <48737664.3000608@gmx.de> (raw)
In-Reply-To: <20080707203912.GB7648@c2.user-mode-linux.org>
Jeff Dike wrote:
>> 1. If a file is held read-only by one process it cannot by creat()'ed by
>> another one:
>>
[...]
>>
>> I tracked that problem down to the set_attr() function in hostfs_user.c:
>> It tries to ftruncate() the read-only file descriptor. The file should
>> be re-opened writable before changing its length.
>
> Looks like a good diagnosis. There is code in host_file_open which is
> supposed to handle this case, but it's not being hit when the shell
> opens the file, which I don't understand.
I tracked that down step-by-step on Saturday: If the O_TRUNC flag is set
in the open() syscall the file will first be truncated and then opened.
The call stack for truncating the file:
- sys_open (fs/open.c)
- do_sys_open (fs/open.c)
- do_filp_open (fs/open.c)
- open_namei (fs/namei.c)
- may_open (fs/namei.c)
- do_truncate (fs/open.c)
And the call stack for actually opening the file:
- sys_open (fs/open.c)
- do_sys_open (fs/open.c)
- do_filp_open (fs/open.c)
- nameidata_to_filp (fs/open.c)
- __dentry_open (fs/open.c)
Maybe that helps.
> Correct. I've pondered using [id]notify to track changes on the host
> and either invalidate the UML cache or update it. Both involve
> interactions with the page cache that I'm not entirely comfortable
> with right now.
That problem is actually more severe for my UML use case: I'm developing
firmware for an embedded device, and I'm using UML because it's quicker
and more convenient than developing on the target hardware. Now, if I
re-compile some library which is still in use by another process the
changes will not be visible until I reboot (or kill these background
processes).
How do similar filesystems (e.g. NFS) solve that problem?
Cheers,
Ingo
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
next prev parent reply other threads:[~2008-07-08 14:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-05 18:46 [uml-devel] hostfs oddities Ingo van Lil
2008-07-07 20:39 ` Jeff Dike
2008-07-08 14:15 ` Ingo van Lil [this message]
2008-07-10 17:37 ` Jeff Dike
2008-07-09 19:43 ` Ingo van Lil
2008-07-10 17:28 ` Jeff Dike
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48737664.3000608@gmx.de \
--to=inguin@gmx.de \
--cc=jdike@addtoit.com \
--cc=user-mode-linux-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox