On 10/22/07, Latchesar Ionkov [EMAIL PROTECTED] wrote:
In v9fs_vfs_rename function labels don't match the fids that are clunked.
The correct clunk order is clunking newdirfid first and then olddirfid next.
Signed-off-by: Latchesar Ionkov [EMAIL PROTECTED]
Acked-by: Eric Van Hensbergen [EMAIL
This patch adds readpages support in support of readahead when using loose
cache mode. It substantially increases performance for certain workloads.
Signed-off-by: Eric Van Hensbergen [EMAIL PROTECTED]
---
fs/9p/v9fs.c|2 +-
fs/9p/vfs_addr.c| 98
On 9/12/07, Latchesar Ionkov [EMAIL PROTECTED] wrote:
Change the names of 'uid' and 'gid' parameters to the more appropriate
'dfltuid' and 'dfltgid'.
...
strcpy(v9ses-name, V9FS_DEFUSER);
strcpy(v9ses-remotename, V9FS_DEFANAME);
+ v9ses-dfltuid = V9FS_DEFUID;
+
On 9/12/07, Latchesar Ionkov [EMAIL PROTECTED] wrote:
- allow only one user to access the tree (access=uid)
Only the user with uid can access the v9fs tree. Other users that attempt
to access it will get EPERM error.
While access=uid and dfltuid=some-other-uid creates an interesting
On 9/3/07, Latchesar Ionkov [EMAIL PROTECTED] wrote:
This patch improves the 9P2000 support by allowing every user to attach
separately. The patch defines three modes of access (new mount option
'access'):
nit picks:
* you added/changed options without updated
On 5/15/07, Bharata B Rao [EMAIL PROTECTED] wrote:
So there can be two cases in union mounts:
1. A file exists in topmost layer and also in one or more lower layers. Deleting
the file would result in the top layer file being deleted and a whiteout being
created in the top layer.
2. A file
On 5/8/07, Andrew Morton [EMAIL PROTECTED] wrote:
On Tue, 8 May 2007 14:51:02 -0600
Latchesar Ionkov [EMAIL PROTECTED] wrote:
This patchset moves non-filesystem interfaces of v9fs from fs/9p to net/9p.
It moves the transport, packet marshalling and connection layers to net/9p
leaving only
On 4/6/07, H. Peter Anvin [EMAIL PROTECTED] wrote:
Jan Engelhardt wrote:
On Apr 6 2007 16:16, H. Peter Anvin wrote:
- users can use bind mounts without having to pre-configure them in
/etc/fstab
This is by far the biggest concern I see. I think the security implication
of
allowing anyone
On 9/3/05, Miklos Szeredi [EMAIL PROTECTED] wrote:
I agree that lots of people would like the functionality. I regret that
although it appears that v9fs could provide it,
I think you are wrong there. You don't appreciate all the complexity
FUSE _lacks_ by not being network transparent.
On 9/3/05, Miklos Szeredi [EMAIL PROTECTED] wrote:
While FUSE doesn't handle it directly, doesn't it have to punt it to
its network file systems, how to the sshfs and what not handle this
sort of mapping?
Sshfs handles it by not handling it. In this case it is neither
possible, nor
[PATCH] v9fs: Support to force umount
Support for force umount
Signed-off-by: Latchesar Ionkov [EMAIL PROTECTED]
Signed-off-by: Eric Van Hensbergen [EMAIL PROTECTED]
---
commit 3f92b2539fe581ee9011d687fbd43cebb641465e
tree cd34696129c3b636b85578f659f260100196dee1
parent
Van Hensbergen [EMAIL PROTECTED] Wed, 31 Aug 2005 16:02:42
-0500
committer Eric Van Hensbergen [EMAIL PROTECTED] Wed, 31 Aug 2005
16:02:42 -0500
fs/9p/trans_fd.c | 42 +++---
fs/9p/v9fs.c |5 -
2 files changed, 39 insertions(+), 8 deletions
[PATCH] v9fs: Fix Plan9port example in v9fs documentation.
Signed-off-by: Eric Van Hensbergen [EMAIL PROTECTED]
---
commit 678b78b5268b253e21aa818fac25ea13291eafff
tree fc3d94d10d23fedee95091e372c51e1156a0360f
parent 06e00e56fdf2c3e230ff60f6fdab6db789f16e73
author Eric Van Hensbergen [EMAIL
Hensbergen [EMAIL PROTECTED]
---
commit 30bdd61e96418043a07d2da71bcd757a0341113f
tree 3e268ece4b911b960b47b47182972d8f439667da
parent e189afc5ed8102a56f74cb5be91a6bf3e478a06a
author Eric Van Hensbergen [EMAIL PROTECTED] Sun, 28 Aug 2005 16:33:42
-0500
committer Eric Van Hensbergen [EMAIL PROTECTED] Sun, 28
On 8/28/05, Alexey Dobriyan [EMAIL PROTECTED] wrote:
On Sun, Aug 28, 2005 at 04:05:07PM -0500, Eric Van Hensbergen wrote:
[PATCH] v9fs: use standard kernel byteswapping routines
Originally suggested by hch, we have removed our byteswap code
and replaced it with calls to the standard
[PATCH] v9fs: Fix Plan9port example in v9fs documentation.
Resend: to fix typo that I should have caught first time around.
Signed-off-by: Eric Van Hensbergen [EMAIL PROTECTED]
---
commit 678b78b5268b253e21aa818fac25ea13291eafff
tree fc3d94d10d23fedee95091e372c51e1156a0360f
parent
On 7/28/05, Ronald G. Minnich rminnich@lanl.gov wrote:
On Thu, 28 Jul 2005, Christoph Hellwig wrote:
Couldn't the two other transports be implemented ontop of this one using
a mount helper doing the pipe or tcp setup?
that's how we did it in the version we did for 2.4. I don't see
On 7/14/05, Christoph Hellwig [EMAIL PROTECTED] wrote:
+static inline void buf_check_size(struct cbuf *buf, int len)
+{
+ if (buf-p+len buf-ep) {
+ if (buf-p buf-ep) {
+ eprintk(KERN_ERR, buffer overflow\n);
+ buf-p = buf-ep +
On 4/19/05, Ram [EMAIL PROTECTED] wrote:
On Tue, 2005-04-19 at 18:24, Eric Van Hensbergen wrote:
Is this sufficient to cover any exposure? What's the correct solution
for the shared sub-trees RFC? Should there be something similar for
user mounts/binds?
A new namespace in a shared
On 4/19/05, Al Viro [EMAIL PROTECTED] wrote:
On Tue, Apr 19, 2005 at 06:53:29PM -0500, Eric Van Hensbergen wrote:
On 4/19/05, Al Viro [EMAIL PROTECTED] wrote:
a) ability to create a private namespace without forking anything - sure,
that would be useful. However, that's not something I
On 4/20/05, Eric Van Hensbergen [EMAIL PROTECTED] wrote:
Yeah, that was really slimy, just wanted something that would be more
accessible to end users without having to affect changes to lots of
applications. A somewhat less slimy method would be to expose
something in /proc, but I suppose
On 4/20/05, Al Viro [EMAIL PROTECTED] wrote:
Excuse me, but could somebody give coherent rationale for such requirements?
_Especially_ for joining existing group by completely unrelated process -
something we don't do for any other component of process.
On Wed, Apr 20, 2005 at 09:51:26AM
On 4/20/05, Miklos Szeredi [EMAIL PROTECTED] wrote:
The user expects to have the see the same files in all sessions,
whether those be local logins, remote logins, ftp/scp/etc sessions.
A single global namespace makes perfect sense here. Why do people
want private namespaces?
I disagree
On 4/17/05, Bodo Eggert [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
I was thinking about this a while back and thought having a user-mount
permissions file might be the right way to address lots of these
issues. Essentially it would contain information about what
users/groups were
Somewhat related question for Viro/the group:
Why is CLONE_NEWNS considered a priveledged operation? Would placing
limits on the number of private namespaces a user can own solve any
resource concerns or is there something more nefarious I'm missing?
-
To unsubscribe from this list: send the
The motivation behind this patch is to make private namespaces more
accessible by allowing their creation at mount/bind time.
Based on some of the FUSE permissions discussions, I wanted to check
into modifying the mount system calls -- adding a flag which created a
new namespace for the resulting
On 4/19/05, Al Viro [EMAIL PROTECTED] wrote:
On Tue, Apr 19, 2005 at 05:13:32PM -0500, Eric Van Hensbergen wrote:
The motivation behind this patch is to make private namespaces more
accessible by allowing their creation at mount/bind time.
*UGH*
So what happens to those who happen
This is again related to the FUSE permission thread, but a slightly
different idea and without a slimy hack patch.
I really want to enable users to be able to create private namespaces,
but I want to try and avoid creating a venerability by allowing them
to abuse system resources. It looks like
On 4/12/05, Miklos Szeredi [EMAIL PROTECTED] wrote:
I think that would be _much_ nicer implemented as a mount which is
invisible to other users, rather than one which causes the admin's
scripts to spew error messages.
Is the namespace mechanism at all suitable for that?
It is
On 4/11/05, Miklos Szeredi [EMAIL PROTECTED] wrote:
1) Only allow mount over a directory for which the user has write
access (and is not sticky)
2) Use nosuid,nodev mount options
[ parts deleted ]
Do these solve all the security concerns with unprivileged mounts, or
are there
On 4/17/05, Miklos Szeredi [EMAIL PROTECTED] wrote:
1) Only allow mount over a directory for which the user has write
access (and is not sticky)
2) Use nosuid,nodev mount options
[ parts deleted ]
Do these solve all the security concerns with unprivileged mounts,
: irc://freenode.net/#v9fs
Thanks for your time in reading this message, I look forward to
hearing from all of you -- we are well aware that there is much work
to do, but I hope that with your help we can produce something that
everyone finds useful and valuable.
-Eric Van Hensbergen
Just wanted to thank everybody for their help. I ended up backing off
the lofty goals and worked towards just passing fsx for now. The main
thing needed was an invalidate_inode_pages2(inode-i_mapping) when I
wrote the file through the uncached method (in order to invalidate any
read buffers).
I'm trying to implement a completely synchronous mmap in my
filesystem, but am running into some difficulty and was wondering if
someone could give me some insight/clue.
I want all my file system's operations to be complete uncached and
synchronous, but I also want to support mmap. The problem
On Mon, 21 Mar 2005 13:33:55 -0800, Bryan Henderson [EMAIL PROTECTED] wrote:
I want all my file system's operations to be complete uncached and
synchronous, but I also want to support mmap.
...
What am I doing wrong? Is what I'm trying to do impossible, and if
so, how can I get as close as
Thanks for your time in reading this message, I look forward to
hearing from all of you -- we are well aware that there is much work
to do, but I hope that with your help we can produce something that
everyone finds useful and valuable.
-Eric Van Hensbergen
V9FS Project
36 matches
Mail list logo
