On Tue, Feb 19, 2008 at 05:04:36AM +0100, Arnd Bergmann wrote:
+ char buf[3];
+ u32 *val = file-private_data;
+
+ if (*val)
+ buf[0] = 'Y';
+ else
+ buf[0] = 'N';
+ buf[1] = '\n';
+ buf[2] = 0x00;
+ return
On Tue, Feb 19, 2008 at 05:04:37AM +0100, Arnd Bergmann wrote:
There is a number of pseudo file systems in the kernel
that are basically copies of debugfs, all implementing the
same boilerplate code, just with different bugs.
This adds yet another copy to the kernel in the libfs directory,
On Tue, Feb 19, 2008 at 05:04:36AM +0100, Arnd Bergmann wrote:
The file operations in debugfs are rather generic and can
be used by other file systems, so it can be interesting to
include them in libfs, with more generic names, and exported
to modules.
This patch adds a new copy of these
On Tue, Feb 19, 2008 at 05:04:38AM +0100, Arnd Bergmann wrote:
With most of debugfs now copied to generic code in libfs,
we can remove the original copy and replace it with thin
wrappers around libfs.
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
Index: linux-2.6/fs/Kconfig
On Mon, Feb 18, 2008 at 12:47:59PM +0100, Miklos Szeredi wrote:
So what should I do?
Would Al be wanting to merge this into his VFS tree? (Can't find it
on git.kernel.org yet, BTW.)
FWIW, it's on hera right now, should propagate to git.kernel.org in a few.
Branches I'd pushed there:
On Sat, Feb 23, 2008 at 06:33:13PM +0100, Miklos Szeredi wrote:
c) just what is limited by that sysctl? AFAICS, rbind is allowed
if mountpoint is on user vfsmount and it seems to create vfsmounts without
eating into that limit just fine... What's the point of limiting the
amount of
On Thu, Feb 21, 2008 at 01:13:48AM +1100, Stephen Rothwell wrote:
Hi Miklos,
On Tue, 19 Feb 2008 14:32:28 +0100 Miklos Szeredi [EMAIL PROTECTED] wrote:
I've created a git tree with the following mounts related stuff:
- read-only bind mounts
- /proc/pid/mountinfo
-
On Wed, Feb 20, 2008 at 04:39:15PM +0100, Miklos Szeredi wrote:
mountinfo - IMO needs a sane discussion of what and how should be shown
wrt propagation state
Here's my take on the matter.
The propagation tree can be either be represented
1) from root to leaf listing members of peer
On Wed, Feb 20, 2008 at 11:29:13AM -0800, Ram Pai wrote:
I wonder, what is wrong in reporting mounts in other namespaces that
either receive and send propagation to mounts in our namespace?
A plenty. E.g. if foo trusts control over /var/blah to bar, it's not
obvious that foo has any business
On Sun, Feb 17, 2008 at 06:00:30PM +0900, Tetsuo Handa wrote:
Hello.
This is (c) Add new hooks. approach I proposed at
http://www.mail-archive.com/linux-fsdevel@vger.kernel.org/msg11536.html .
Although this is an incomplete patch,
I want to know whether you can tolerate this approach or
On Sat, Feb 02, 2008 at 01:45:15PM -0500, Erez Zadok wrote:
You are thinking about non-interesting case. _Files_ are not much
of a problem. Directory tree is. The real problems with all unionfs and
stacking implementations I've seen so far, all way back to Heidemann et.al.
start when
On Sat, Jan 26, 2008 at 12:08:30AM -0500, Erez Zadok wrote:
* lock_parent(): who said that you won't get dentry moved
before managing to grab i_mutex on parent? While we are at it,
who said that you won't get dentry moved between fetching d_parent
and doing dget()? In that case
On Wed, Jan 16, 2008 at 11:12:31PM +0100, Miklos Szeredi wrote:
The alternative (and completely safe) solution is to add another file
to proc. Me no likey.
Since we need saner layout, I would strongly suggest exactly that.
major:minor -- is the major minor number of the device hosting the
On Wed, Jan 16, 2008 at 04:09:30PM -0800, Andrew Morton wrote:
On Thu, 17 Jan 2008 00:58:06 +0100 (CET) Jan Engelhardt [EMAIL PROTECTED]
wrote:
On Jan 17 2008 00:43, Karel Zak wrote:
Seems like a plain bad idea to me. There will be any number of home-made
/proc/mounts parsers
After grep for locking-related things:
* lock_parent(): who said that you won't get dentry moved
before managing to grab i_mutex on parent? While we are at it,
who said that you won't get dentry moved between fetching d_parent
and doing dget()? In that case parent could've been _freed_
On Sun, Dec 16, 2007 at 05:52:08PM +0100, Indan Zupancic wrote:
What prevents them from mounting tmpfs on top of /dev, bypassing your fs?
Or binding /dev/null over nodes they want to get rid of...
Also, if they have root there are plenty of ways to prevent an administrator
from logging in,
On Wed, Nov 21, 2007 at 03:24:33PM -0800, Andrew Morton wrote:
-repeat:
- if (atomic_dec_and_lock(mnt-mnt_count, vfsmount_lock)) {
+ while (atomic_dec_and_lock(mnt-mnt_count, vfsmount_lock)) {
if (likely(!mnt-mnt_pinned)) {
On Fri, Oct 19, 2007 at 06:07:45AM +0930, David Newall wrote:
considerations of this whole scheme. Linux, like most Unix systems,
has never allowed hard links to directories for a number of reasons;
The claim is wrong. UNIX systems have traditionally allowed the
superuser to create hard
On Fri, Oct 19, 2007 at 12:27:16PM +0930, David Newall wrote:
Learn to read. Linux has never allowed that. Most of the Unix systems
do not allow that.
I did read the claim and it is ambiguous, in that it can reasonably be
read to mean that most UNIX systems never allowed such links,
It's time to sanitize prototypes of bdev -open(), -release()
and -ioctl(). This stuff had sat in need to fix for a long time
and there is a bunch of bugs hard to fix without dealing with it.
1) -open() gets inode * and file *. Almost all instances use only
inode-i_bdev
On Thu, Aug 16, 2007 at 03:57:24PM -0700, Linus Torvalds wrote:
I personally consider this an affront to everythign that is decent.
Why the *hell* would mkdir() be so magical as to need something like that?
Make it something sane, like a struct nameidata instead, and make it at
least try
On Fri, Jul 20, 2007 at 10:45:34AM +1000, David Chinner wrote:
On Thu, Jul 19, 2007 at 06:16:00PM -0400, Jan Harkes wrote:
On Thu, Jul 19, 2007 at 11:45:08PM +0200, Christoph Hellwig wrote:
-release is the proper way to detect the last close of a file,
file_count should never be used in
On Fri, Jul 20, 2007 at 12:36:01PM +1000, David Chinner wrote:
To the context that dropped the last reference. It can't be
reported to anything else
Oh, for fsck sake...
Send a datagram with SCM_RIGHTS in it. Have all other references
to these files closed. Now have close(2) kill the
On Fri, Jul 20, 2007 at 12:10:00AM -0400, Jan Harkes wrote:
I will try to find a clean way to block the close syscall until fput
drops the last reference. However I realize that such an implementation
would not be acceptable for other file systems, and there are some
interesting unresolved
On Tue, Jul 17, 2007 at 12:04:07AM -0700, Andrew Morton wrote:
I don't think any (all?) other filesystems perform checks like this.
Is this something which can/should be performed at the VFS level?
I don't see why we _should_ check that; VFS checks that we don't
turn directory into
On Mon, Jul 16, 2007 at 09:56:10AM +0200, Jan Engelhardt wrote:
Just one question: what the bleeding hell for? Not that the rest of
..at() family made any damn sense as an interface...
fd1 = open(dir1, O_DIRECTORY):
fd2 = open(dir2, O_DIRECTORY);
system(mount -t tmpfs none dir1);
On Sun, Jul 15, 2007 at 09:46:27PM +0200, Jan Engelhardt wrote:
Hi,
recently, the family of *at() syscalls and functions (openat, fstatat,
etc.) have been added to Linux and Glibc, respectively.
In short: I am missing xattr at functions :)
No. They are not fscking forks. They are
On Sun, Jul 15, 2007 at 02:13:21PM -0700, Nicholas Miell wrote:
I suspect he was asking for
int getxattrat(int fd, const char *path, const char *name, void *value,
size_t size, int flags)
int setxattrat(int fd, const char *path, const char *name, void *value,
On Wed, Jul 11, 2007 at 12:01:06PM +0300, Pekka J Enberg wrote:
From: Pekka Enberg [EMAIL PROTECTED]
The revokeat(2) and frevoke(2) system calls invalidate open file descriptors
and shared mappings of an inode. After an successful revocation, operations
on file descriptors fail with the
On Wed, Jul 11, 2007 at 10:37:33AM +0100, Al Viro wrote:
On Wed, Jul 11, 2007 at 12:01:06PM +0300, Pekka J Enberg wrote:
From: Pekka Enberg [EMAIL PROTECTED]
The revokeat(2) and frevoke(2) system calls invalidate open file descriptors
and shared mappings of an inode. After an successful
On Wed, Jul 11, 2007 at 12:50:48PM +0300, Pekka J Enberg wrote:
Hi Al,
On Wed, 11 Jul 2007, Al Viro wrote:
Better: I have the only opened descriptor for foo. I send it to myself
as described above. I close it. revoke() is called, finds no opened
instances of foo in any descriptor
On Wed, Jul 11, 2007 at 01:01:07PM +0300, Pekka J Enberg wrote:
On Wed, 11 Jul 2007, Al Viro wrote:
BTW, read() or write() in progress might get rather unhappy if your
live replacement of -f_mapping races with them...
For writes, we (1) never start any new operations after we've cleaned up
On Wed, Jun 20, 2007 at 01:57:33PM -0700, H. Peter Anvin wrote:
... or, alternatively, add a subfield to the first field (which would
entail escaping whatever separator we choose):
/dev/md6 /export ext3 rw,data=ordered 0 0
/dev/md6:/users/foo /home/foo ext3 rw,data=ordered 0 0
On Thu, May 24, 2007 at 08:10:00PM +0200, Andreas Gruenbacher wrote:
Read it like this: we don't have a good idea how to support multiple
namespaces so far. Currently, we interpret all pathnames relative to the
namespace a process is in. Confined processes don't have the privilege to
On Wed, May 23, 2007 at 08:36:04AM +0200, Miklos Szeredi wrote:
Interesting... How do you deal with mount propagation and things like
mount --move?
Moving (or doing other mount operations on) an ancestor shouldn't be a
problem. Moving this mount itself is not allowed, and neither is
On Wed, May 23, 2007 at 09:19:17AM +0200, Miklos Szeredi wrote:
Eh... Arbitrary limitations are fun, aren't they?
But these mounts _are_ special. There is really no point in moving or
pivoting them.
pivoting - probably true, moving... why not?
What about MNT_SLAVE stuff being set up
On Tue, May 22, 2007 at 08:48:49PM +0200, Miklos Szeredi wrote:
*/
-static int __follow_mount(struct path *path)
+static int __follow_mount(struct path *path, bool enter)
{
int res = 0;
while (d_mountpoint(path-dentry)) {
- struct vfsmount *mounted =
On Wed, May 23, 2007 at 11:03:08AM +0200, Miklos Szeredi wrote:
I still don't get it where the superblock comes in. The locking is
interesting in there, yes. And I haven't completely convinced
myself it's right, let alone something that won't easily be screwed up
in the future. So there's
On Wed, May 23, 2007 at 12:09:19PM +0200, Miklos Szeredi wrote:
Right. After locking vfsmount_lock, mount_dironfile() should recheck
if there was a race and bail out.
Owww... Not pretty, that...
I don't think the filesystem ought to try _creating_ a vfsmount. I
imagine, that the fs has
When the real superblock is created. It could even be the _same_
super block as the real one. There'd be just the problem of anchoring
the dir-on-file dentries somewhere...
Or with fuse the dir-on-file mount can just come from any mounted
filesystem, again possibly the same one as the
On Wed, May 23, 2007 at 12:39:25PM +0100, Al Viro wrote:
Then I do not understand what this mechanism could be used for, other
than an odd way to twist POSIX behaviour and see how much of the userland
would survive that. Certainly not useful for your look into tarball
as a tree, unless you
On Wed, May 23, 2007 at 08:34:42AM -0400, Trond Myklebust wrote:
On Wed, 2007-05-23 at 08:36 +0100, Al Viro wrote:
On Wed, May 23, 2007 at 09:19:17AM +0200, Miklos Szeredi wrote:
Eh... Arbitrary limitations are fun, aren't they?
But these mounts _are_ special. There is really
On Wed, May 23, 2007 at 03:01:38PM +0200, Miklos Szeredi wrote:
Someone might think of a way to make those work with directories.
Invisible directory entries, anyone? /me ducks
Not unless you manage to get working union-mount [*NOT* unionfs]
* invalidation on unlink is still an open
On Wed, May 23, 2007 at 03:23:54PM +0200, Ph. Marek wrote:
How about some special node in eg. /proc (or a new filesystem)?
Eg.
/fileAsDir/etc/passwd/owner ...
would work for all *files*. For directories we do not know whether we're
still
climbing the hierarchy or would like to see
On Wed, May 23, 2007 at 04:32:37PM +0200, Miklos Szeredi wrote:
Umm... It is related to detached subtrees, but I'm not sure if it is what
you are thinking about.
I was thinking of a similar one by Mike Waychison. It had the problem
of requiring a spinlock for mntget/mntput. It was also
On Wed, May 23, 2007 at 05:25:49PM +0200, Miklos Szeredi wrote:
How will this work with copy_tree() and namespace duplication, which
currently walk the tree with only namespace_sem held?
Easy - grab namespace_sem, grab vfsmount_lock, walk the subtree and bump
mnt_busy on everything
On Thu, Apr 12, 2007 at 02:08:10AM -0700, [EMAIL PROTECTED] wrote:
This is needed for computing pathnames in the AppArmor LSM.
Which is an argument against said LSM in current form.
- error = security_inode_create(dir, dentry, mode);
+ error = security_inode_create(dir, dentry, nd ?
On Thu, Apr 12, 2007 at 02:08:49AM -0700, [EMAIL PROTECTED] wrote:
+ } else if (profile1 profile2) {
+ /* profile1 cannot be NULL here. */
+ spin_lock_irqsave(profile1-lock, profile1-int_flags);
+ if (profile2)
+
+char *d_namespace_path(struct dentry *dentry, struct vfsmount *vfsmnt,
+char *buf, int buflen)
+{
+ char *res;
+ struct vfsmount *rootmnt, *nsrootmnt;
+ struct dentry *root;
+
+ read_lock(current-fs-lock);
+ rootmnt = mntget(current-fs-rootmnt);
+
On Thu, Mar 15, 2007 at 02:20:25AM +0100, Jan Engelhardt wrote:
Why is EXDEV returned when _vfs mountpoints_ are crossed? Should not it
be more like the following?
error = -EXDEV;
if (oldnd.mnt-mnt_sb != newnd.mnt-mnt_sb)
goto exit2;
No. This is
On Sun, Jan 07, 2007 at 12:44:56AM +0300, Alexey Dobriyan wrote:
#if defined(CONFIG_EXPORTFS) || defined(CONFIG_EXPORTFS_MODULE)
#define set_export_ops(sb, ops) sb-s_export_op = ops
#else
#define set_export_ops(sb, ops) 0
#endif
That way you can get rid of the
On Fri, Jan 05, 2007 at 12:11:17PM -0500, Shaya Potter wrote:
ok, I guess what I don't understand is when are
dentry-d_sb-s_root and nd-mnt-mnt_root not equivalent.
I guess it would be when crossing a mountpoint on the server, so I
look at nfs_follow_mountpoint() and basically see that you
On Wed, Dec 20, 2006 at 05:50:11PM +0100, Miklos Szeredi wrote:
I don't see any problems with changing struct kstat. There would be
reservations against changing inode.i_ino though.
So filesystems that have 64bit inodes will need a specialized
getattr() method instead of generic_fillattr().
On Wed, Nov 15, 2006 at 11:42:38AM -0500, Jeff Layton wrote:
+{
+ int rv;
+
+ rv = idr_pre_get(inode-i_sb-s_inode_ids, GFP_KERNEL);
+ if (! rv)
+ return -ENOMEM;
+
+ lock_super(inode-i_sb);
[EMAIL PROTECTED]
Please, use something saner. Use of lock_super()
On Fri, Aug 19, 2005 at 12:14:48PM +0100, Anton Altaparmakov wrote:
Hi,
There is a bug somewhere in 2.6.11.4 and I can't figure out where it is.
I assume it is present in older and newer kernels, too as the related
code hasn't changed much AFAICS and googling for Bad page state
returns
On Fri, Aug 19, 2005 at 09:07:35AM -0700, Linus Torvalds wrote:
Hmm.. NFS _does_ use the page cache for symlinks, but uses it slightly
differently: instead of relying on the page cache entry being the same
when freeing the page, it just caches the page it looked up in the page
cache (ie
On Fri, Aug 19, 2005 at 09:43:17AM -0700, Linus Torvalds wrote:
Actually, looking at the ncpfs patch, I'd rather not apply that patch
as-is. It looks like it will totally disable symlink caching, which would
be kind of sad. Somebody willing to do the same thing NFS does?
NFS hides away the
On Fri, Aug 19, 2005 at 05:53:32PM +0100, Al Viro wrote:
I'm taking NFS helpers to libfs.c and switching ncpfs to them. IMO that's
better than copying the damn thing and other network filesystems might have
the same needs eventually...
[something like this - completely untested
On Fri, Aug 19, 2005 at 07:00:38PM +0100, Christoph Hellwig wrote:
On Fri, Aug 19, 2005 at 07:02:18PM +0100, Al Viro wrote:
On Fri, Aug 19, 2005 at 05:53:32PM +0100, Al Viro wrote:
I'm taking NFS helpers to libfs.c and switching ncpfs to them. IMO that's
better than copying the damn
On Fri, Aug 19, 2005 at 03:04:52PM -0700, Linus Torvalds wrote:
On Fri, 19 Aug 2005, Anton Altaparmakov wrote:
Yes, sure. I have applied your patch to our 2.6.11.4 tree (with the one
liner change I emailed you just now) and have kicked off a compile.
Actually, hold on. The
On Sat, Aug 20, 2005 at 12:15:42AM +0100, Al Viro wrote:
That looks OK except for
* jffs2 is b0rken (see patch in another mail)
* afs, autofs4, befs, devfs, freevxfs, jffs2, jfs, ncpfs, procfs,
smbfs, sysvfs, ufs, xfs - prototype change for -follow_link()
* befs, smbfs
On Fri, Aug 19, 2005 at 06:08:12PM -0700, Linus Torvalds wrote:
On Sat, 20 Aug 2005, Al Viro wrote:
That looks OK except for
* ncpfs fix is actually missing here
Well, the thing is, with the change to page_follow_link() and
page_put_link(), ncpfs should now work fine
On Wed, Apr 20, 2005 at 10:45:58AM +0100, Jamie Lokier wrote:
For FUSE, what's needed is that a user can mount something, and the
mounted fs is visible only to that user, but it's visible to _all_ of
the user's processes.
So get that namespace as soon as you log in.
We think namespaces are
On Wed, Apr 20, 2005 at 01:03:40PM +0100, Jamie Lokier wrote:
It shouldn't be literally per-user - it should be possible for a user
to have several environment _when_ they want that. chroot-jail style
virtual server environments require that too.
But that shouldn't be the only option -
On Wed, Apr 20, 2005 at 09:51:26AM -0700, Ram wrote:
Reading through the thread I assume the requirement is:
1) A User being able to create his own VFS-mount environment
2) being able to use the same VFS-mount environment from
multiple login sessions.
3) Being able to switch some
On Wed, Apr 20, 2005 at 09:43:47PM +0100, Jamie Lokier wrote:
Al Viro is right to point out that environment variables are not
shared. But he forgets that _files_ are shared.
So they are. ~/.profile, for instance ;-)
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel
On Wed, Apr 20, 2005 at 07:53:04PM +0200, Miklos Szeredi 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.
Umm... You know, I would be *very* unhappy if I found that some process
on parcelfarce was able
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.
Based on some of the FUSE permissions discussions, I wanted to check
into modifying the mount
On Tue, Apr 19, 2005 at 06:53:29PM -0500, Eric Van Hensbergen wrote:
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
On Mon, Apr 18, 2005 at 10:07:14AM -0700, Bryan Henderson wrote:
On Fri, Apr 15, 2005 at 01:22:59PM -0700, David S. Miller wrote:
Make a -compat_read_super() just like we have a -compat_ioctl()
method for files, if you want to suggest a solution like what
you describe.
I don't think
On Mon, Apr 18, 2005 at 06:33:09PM +0100, David Howells wrote:
Al Viro [EMAIL PROTECTED] wrote:
Architecture-dependent blob passed to mount(2) (aka nfs4_mount_data).
If you want it to be a blob, at least have a decency to use encoding
that would not depend on alignment rules and word
On Sun, Jan 16, 2005 at 11:02:13AM -0500, J. Bruce Fields wrote:
On Thu, Jan 13, 2005 at 10:18:51PM +, Al Viro wrote:
6. mount --move
prohibited if what we are moving is in some p-node, otherwise we move
as usual to intended mountpoint and create copies for everything that
gets
On Sun, Jan 16, 2005 at 01:42:09PM -0500, J. Bruce Fields wrote:
On Sun, Jan 16, 2005 at 06:06:56PM +, Al Viro wrote:
On Sun, Jan 16, 2005 at 11:02:13AM -0500, J. Bruce Fields wrote:
On Thu, Jan 13, 2005 at 10:18:51PM +, Al Viro wrote:
6. mount --move
prohibited
On Sat, Jan 15, 2005 at 07:46:59PM -0500, J. Bruce Fields wrote:
On Thu, Jan 13, 2005 at 10:18:51PM +, Al Viro wrote:
2. mount
We have a new vfsmount A and want to attach it to mountpoint somewhere in
vfsmount B. If B does not belong to any p-node, everything is as usual
74 matches
Mail list logo
