Alexander Viro writes:
>
> On Wed, 14 Jun 2000, Richard Gooch wrote:
Sigh. It's taken me far to long to get back to this.
> > > Not only that, actually - order of invalidation was incorrect, IIRC.
> >
> > Let me check I understand what you mean. You&
Tigran Aivazian writes:
> On Thu, 29 Jun 2000, Richard Gooch wrote:
> > What happens when you try (user-space) mounting a FS_SINGLE filesystem
> > without calling kern_mount() first?
>
> I get an oops at the line of code I mentioned - it wasn't a theoretical
Tigran Aivazian writes:
> On Thu, 29 Jun 2000, Richard Gooch wrote:
> > Hm. Digging back into my archives, I see I said I got a kernel BUG. So
> > that means I got a BUG, not an Oops. Perhaps that means that *fs_type
> > hasn't been initialised to 0, or perhaps t
Tigran Aivazian writes:
> On Sat, 10 Jun 2000, Alexander Viro wrote:
> > > - although not documented, you need to do kern_mount() before trying
> > Yup.
> > > normal mounts of a FS_SINGLE; perhaps kern_mount()/kern_umount()
> > > should be called automatically in
> > > register_filesyste
Richard Gooch writes:
> Alexander Viro writes:
> >
> >
> > On Sun, 25 Jun 2000, Richard Gooch wrote:
> >
> > > Hi, Al. Recent kernels have a problem with unmounting via the device
> > > file. If I do:
> > >
> > > # mknod /mydev
Alexander Viro writes:
>
>
> On Sun, 25 Jun 2000, Richard Gooch wrote:
>
> > Hi, Al. Recent kernels have a problem with unmounting via the device
> > file. If I do:
> >
> > # mknod /mydev b ...
> > # mount -n /mydev /mnt
> > # /tmp/kumount /m
Hi, Al. Recent kernels have a problem with unmounting via the device
file. If I do:
# mknod /mydev b ...
# mount -n /mydev /mnt
# /tmp/kumount /mydev
Error unmounting: /mydevInvalid argument
This used to work. Note that kumount only does a call to umount(2).
If instead I do:
# /tmp/ku
Alexander Viro writes:
> On Fri, 16 Jun 2000, Richard Gooch wrote:
>
> > - mount procfs on boot :->
> >
> > - modify init(8) to not need /dev/tty (which would be a pity, because
> > session management before starting boot scripts is damn handy)
> >
>
Alexander Viro writes:
> On Fri, 16 Jun 2000, Richard Gooch wrote:
> > Agreed. /dev/tty always struck me as a bit evil^Wmagic. At the very
> > least, a symlink to /proc/self/tty would make it pretty damn clear
> > even to a novice.
>
> Unfortunately, unlike /proc
Alexander Viro writes:
>
>
> On Fri, 16 Jun 2000, Erez Zadok wrote:
>
> > Hey, we can make it yet another ioctl(2). Then we can trade a crapload of
> > syscalls for a crapload of ioctls --- a time-honored Unix tradition... :-)
> > :-)
> >
> > Seriously, an open/read/.../close would work fine,
Alexander Viro writes:
>
>
> On Tue, 13 Jun 2000, Richard Gooch wrote:
>
> > > Yes. And all that time mounting the thing at several point was a huge,
> > > fscking hole.
> >
> > Sure. And hence RedHat wasn't going to compile it in.
>
>
Alexander Viro writes:
>
> On Tue, 13 Jun 2000, Richard Gooch wrote:
>
> > I'd like to see something more drastic. Indeed, that union crap is by
> > far the worst offender and needs fixing. But there's a whole pile of
> > other junk that's just no
Alexander Viro writes:
>
> On Tue, 13 Jun 2000, Richard Gooch wrote:
>
> > Alexander Viro writes:
> > >
> > > On Tue, 13 Jun 2000, Richard Gooch wrote:
> > > > So I don't really expect wholesale VFS changes right now (but, hey,
> > &g
Hans Reiser writes:
> Richard Gooch wrote:
> > Another idea (probably too radical, and also CPU inefficient), is a
> > super lightweight inode that has just two pointers: one to FS-specific
> > data, another to FS-specific methods. The methods are used to
> > read/writ
Alexander Viro writes:
>
> On Tue, 13 Jun 2000, Richard Gooch wrote:
> > So I don't really expect wholesale VFS changes right now (but, hey,
> > that doesn't seem to stop you getting stuff in;-). But that shouldn't
>
> They would not be there if not for yo
Alexander Viro writes:
> On Tue, 13 Jun 2000, Richard Gooch wrote:
>
> > This is a lot closer to being feasible with all the VFS changes you've
> > been making, but there is one problem that really concerns me. VFS
> > inodes are very heavyweight. The devfs
Hi, Al. I'd like to explore an idea Linus suggested a while back. He
suggested using VFS inodes as the data store for devfs, rather than
keeping stuff in devfs entries. So the idea would be that the VFS
maintains the tree structure rather than devfs entries.
This is a lot closer to being feasib
Alexander Viro writes:
> On Sat, 10 Jun 2000, Richard Gooch wrote:
> > Will it really make much difference? What would be harder to do
> > without mount IDs? And how much harder?
>
> Beware of functions with many arguments... Besides, what about "kill
> the componen
Alexander Viro writes:
>
>
> On Sat, 10 Jun 2000, Richard Gooch wrote:
>
> > Yeah, sure. I did say "for example". Your format looks fine. One
> > question: is the mount ID really needed? Can't you distinguish based
> > on what FS you're
Alexander Viro writes:
>
>
> On Sat, 10 Jun 2000, Richard Gooch wrote:
>
> > What I mean by "real" mounts is a table that shows how each FS was
> > brought into the namespace (or each namespace, once you implement
> > CLONE_NEWNS). So for example:
>
Alexander Viro writes:
>
>
> On Sat, 10 Jun 2000, Richard Gooch wrote:
>
> > I see your point. However, that suggests that the naming of
> > /proc/mounts is wrong. Perhaps we should have a /proc/namespace that
> > shows all these VFS bindings, and separately a li
Alexander Viro writes:
>
>
> On Sat, 10 Jun 2000, Richard Gooch wrote:
>
> > Hi, all. I've just been looking at the FS_SINGLE implementation, and
> > have a few comments:
> >
> > - although not documented, you need to do kern_mount() before try
Hi, all. I've just been looking at the FS_SINGLE implementation, and
have a few comments:
- although not documented, you need to do kern_mount() before trying
normal mounts of a FS_SINGLE; perhaps kern_mount()/kern_umount()
should be called automatically in
register_filesystem()/unregiste
Alan Cox writes:
> How do you deal with the
>
> poll()
> do stuff
> poll()
>
> and a directory chage occuring during a 'do stuff' period
Check in the patch where I save some state (the event mask). Hm. I
recall answering this question before (can't remember who asked it,
thou
t, &pos);
out:
fput(file);
+ if (ret > 0)
+ vfs_poll_notify (file->f_dentry->d_inode, POLLWRINODE);
bad_file:
unlock_kernel();
return ret;
diff -urN linux.old/fs/vfs_poll.c linux/fs/vfs_poll.c
--- linux.old/fs/vfs_poll.c Thu Jan 1 10:00:00
Alexander Viro writes:
>
>
> On Wed, 3 May 2000, Richard Gooch wrote:
>
> > I think you're referring here to a "split" devfs, where each driver
> > exports a mini-devfs. In such an environment, your mount traps would
> > probably be good.
> >
Alexander Viro writes:
> Folks, I've tried to describe the stuff that may IMO become useful
> for autofs/devfs/portalfs/etc. Comments are more than welcome.
>
> Current problems:
> 5. Any schemes with automount-like stuff in devfs require
> (union-)mount being triggered if lookup brin
Alexander Viro writes:
> On Mon, 1 May 2000, Richard Gooch wrote:
> > Alexander Viro writes:
> > > On Mon, 1 May 2000, Richard Gooch wrote:
> > > > Eric W. Biederman writes:
> > > > > Last I saw it was his complaint that you varied what you
> &g
Alexander Viro writes:
>
>
>
> On Mon, 1 May 2000, Richard Gooch wrote:
>
> > Eric W. Biederman writes:
> > > Richard Gooch <[EMAIL PROTECTED]> writes:
> > >
> > > > Hi, Al. You've previously stated that you consider the mult
Eric W. Biederman writes:
> Richard Gooch <[EMAIL PROTECTED]> writes:
>
> > Hi, Al. You've previously stated that you consider the multiple
> > mount feature of devfs broken. I agree that there are some races in
> > there. However, I'm not clear
Hi, Al. You've previously stated that you consider the multiple
mount feature of devfs broken. I agree that there are some races in
there. However, I'm not clear on whether you're saying that the entire
concept is broken, or that it can be fixed with appropriate locking.
I've asked this before,
Tigran Aivazian writes:
> >
> > Hm. The chroot(2) call changes the apparent root to a directory. This
> > isn't necessarily the root of a mounted FS. So /dev/root should stay
> > as the root filesystem.
>
> I know - I thought that is all he wanted - perhaps I haven't read his
> message carefull
Tigran Aivazian writes:
>
>
> Richard,
>
> Using devfs /dev/root is fine to the real original root but not fine
> to find the device of the filesystem which contains the chroot;d
> environment. But rdev works fine in that case. Try it and see
> (using devfs was the first thing that came to my
Andrew Clausen writes:
> Hi all,
>
> On my machine, this happens:
>
> satisfactory:~$ cat /proc/mounts
> /dev/root / ext2 rw 0 0
> /proc /proc proc rw 0 0
> none /dev/pts devpts rw 0 0
> /dev/hda1 /mnt/dosc vfat rw 0 0
> automount(pid216) /misc autofs rw 0 0
>
PLEASE TAKE ME OFF THE CC LIST.
BTW: I'm on holidays and won't be replying to email for a while.
Richard B. Johnson writes:
> On Sun, 9 Jan 2000, Alexander Viro wrote:
> [SNIPPED]
>
> > > that we provide source to the end-user, they required that we supply
> a
> > > "current" distribution of L
Hans Reiser writes:
> Ok, I read the whole thread, and good reasons were given why it was bad, so I won't
> put it in.
>
> Also, if you are going to swear, then swear, or don't swear. References to fsck are
> pretty unpleasant to read.;-)
>
> And when Richard accuses someone else in this thread
Alan Curry writes:
> Richard Gooch writes the following:
> >
> >This misses the point. The proposed change would require me to make my
> >inodes writable by others in order to let them make hard links. That's
> >much worse than the problem you're concer
Alan Curry writes:
> Richard Gooch writes the following:
> >
> >Andrea Arcangeli writes:
> >> On Fri, 3 Dec 1999, Richard Gooch wrote:
> >>
> >> >as well as very very hostile environments.
> >>
> >> It doesn't work at all on e
Andrea Arcangeli writes:
> On Fri, 3 Dec 1999, Richard Gooch wrote:
>
> >as well as very very hostile environments.
>
> It doesn't work at all on environments where if there's an exploited
> "quota exceeded" is a major problem.
Of course it still works
Andrea Arcangeli writes:
> On Fri, 3 Dec 1999, Alexander Viro wrote:
>
> >Andrea, WHAT FOR? Give a rationale for your change, other than "let's
> >change it". Name a single benefit of proposed semantics.
>
> The rational is that I don't want to see my inodes sparse around the
> fs by an luser. I
Andrea Arcangeli writes:
> On Fri, 3 Dec 1999, Alexander Viro wrote:
>
> >... and F- on UNIX SA 101 - if you don't know the reasons to keep /tmp on
> >a separate filesystem.
>
> Would you call this a solution? This is a very ugly workaround. The
> fact this works is only a side effect of the li
Andrea Arcangeli writes:
> On Fri, 3 Dec 1999, Richard Gooch wrote:
>
> >Firstly, /tmp should be a separate partition anyway. Systems with /tmp
> >on the same FS as / (along with everything else :-() are
> >mis-configured.
>
> I disagree. It's mis-configu
Alexander Viro writes:
>
>
> On Fri, 3 Dec 1999, Andrea Arcangeli wrote:
>
> > I don't need quota for myself either. So? Do you suggest to remove quota
> > from the kernel because me and you don't need it? You can't just take
> > decisions for everybody only looking at your needs. Or you should
Andrea Arcangeli writes:
> On Fri, 3 Dec 1999, Richard Gooch wrote:
>
> >And I want the opposite: I want any user to be able to make hard links
> >to my files, without needing write access to the inodes, and without
> >needing some stupid set{u|g}id binary.
>
> A
Alexander Viro writes:
>
>
> On Fri, 3 Dec 1999, Andrea Arcangeli wrote:
>
> > On Fri, 3 Dec 1999, Richard Gooch wrote:
> >
> > >A hard link is the ideal solution. Many users can "lock" the file so
> > >that they will retain access to it w
Andrea Arcangeli writes:
> On Fri, 3 Dec 1999, Richard Gooch wrote:
>
> >What? Having group write on the directory? No thanks.
>
> You can't hardlink a directory.
Duh. I know that. One proposal was to use access permissions on the
directory to determine if hardlinking wa
Andrea Arcangeli writes:
> On Fri, 3 Dec 1999, Richard Gooch wrote:
>
> >[..] I can definately say that
> >making hardlinks to files in other directories (not owned by the
> >linking user) is a handy feature. [..]
>
> For what exactly is it an handy feature? I n
Andrea Arcangeli writes:
> On Fri, 3 Dec 1999, Richard Gooch wrote:
>
> >A hard link is the ideal solution. Many users can "lock" the file so
> >that they will retain access to it without consuming more space. When
> >each user has lost interest, the space is
Peter J. Braam writes:
>
> Let's just take one step back.
>
> Al has successfully pointed out that one should not expect too much in
> terms of security improvements for my hardlink suggestion.
>
> Al additionally gave two reasons, totally unrelated to the security
> issues, not to implemen
49 matches
Mail list logo
