On Tue, 3 Apr 2001, Richard Gooch wrote:
> However, a large number of people run devfs on small to large systems,
> and these "races" aren't causing problems. People tell me it's quite
> stable. I run devfs on my systems, and not once have I had a problem
> due to devfs "races". So I feel it's
Alan, please, replace the unmap_buffer() in fs/buffer.c with
static void unmap_buffer(struct buffer_head * bh)
{
if (buffer_mapped(bh)) {
mark_buffer_clean(bh);
lock_buffer(bh);
clear_bit(BH_Uptodate, &bh->b_state);
clear_bi
On Wed, 4 Apr 2001, Dawson Engler wrote:
> Hi,
>
> in the old days you couldn't call a sleeping function in a module
> before doing a MOD_INC or after doing a MOD_DEC. Then some safety nets
> were added that made these obsolete (in some number of places). I was
> told that people had decided
On Thu, 5 Apr 2001, Manoj Sontakke wrote:
> Hi
> I am getting linker error "undefined reference to __divdi3".
> This is because c = a/b; where a,b,c are of type "long long"
> I understand this is gcc problem.
> I am doing this on a pentium with gcc -v = egcs-2.91.66
Don't do it in
On Mon, 9 Apr 2001, warren wrote:
>
>
> Hi,
> I had post a simillar message before.
> Thanks for the replay from Albert D. Cahalan. But i found some results
> confusing me.
> For example, process 1 and process 2 run concurrently and execute the
> following system calls.
>
>
On Tue, 10 Apr 2001, kees wrote:
> Hi
>
> Unix/Linux have a lot of daemons that have to run as root because they
> need to acces some specific data or run special programs. They are
> vulnerable as we learn.
> Is there any way to have something like an exec call that is
> subject to a sudo lik
On Wed, 11 Apr 2001, Andreas Dilger wrote:
> I just discovered a similar problem when testing Daniel Philip's new ext2
> directory indexing code with bonnie++. I was running bonnie under single
> user mode (basically nothing else running) to create 100k files with 1 data
> block each (in a sin
On Thu, 12 Apr 2001, Jeff Garzik wrote:
> Alexander Viro wrote:
> > We _have_ VM pressure there. However, such loads had never been used, so
> > there's no wonder that system gets unbalanced under them.
> >
> > I suspect that simple replacement of goto ne
On Thu, 12 Apr 2001, Andreas Dilger wrote:
> Al writes:
> > We _have_ VM pressure there. However, such loads had never been used, so
> > there's no wonder that system gets unbalanced under them.
> >
> > I suspect that simple replacement of goto next; with continue; in the
> > fs/dcache.c::prun
On Thu, 12 Apr 2001, David S. Miller wrote:
>
> Alexander Viro writes:
> > If nobody objects I'll go for test_bit/set_bit/clear_bit here.
>
> Be sure to make d_flags an unsigned long when you do this! :-)
Oh, fsck... Thanks for reminder - I've com
On Thu, 12 Apr 2001, Marcin Kowalski wrote:
> Hi
>
> Regarding the patch
>
> I don't have experience with the linux kernel internals but could this patch
> not lead to a run-loop condition as the only thing that can break our of the
> for(;;) loop is the tmp==&dentry_unused statement.
On Thu, 12 Apr 2001, Jan Harkes wrote:
> But the VM pressure on the dcache and icache only comes into play once
> the system still has a free_shortage _after_ other attempts of freeing
> up memory in do_try_to_free_pages.
I don't think that it's necessary bad.
> sync_all_inodes, which is call
On Thu, 12 Apr 2001, Rik van Riel wrote:
> On Thu, 12 Apr 2001, Ed Tomlinson wrote:
>
> > I have been playing around with patches that fix this problem. What
> > seems to happen is that the VM code is pretty efficent at avoiding the
> > calls to shrink the caches. When they do get called its
On Thu, 12 Apr 2001, Rik van Riel wrote:
> Please take a look at Ed Tomlinson's patch. It also puts pressure
> on the dcache and icache independent of VM pressure, but it does
> so based on the (lack of) pressure inside the dcache and icache
> themselves.
>
> The patch looks simple, sane and it
On Thu, 12 Apr 2001, Alexander Viro wrote:
> Bad idea. If you do loops over directory contents you will almost
> permanently have almost all dentries freeable. Doesn't make freeing
> them a good thing - think of the effects it would have.
>
> Simple question: how many of
Folks, IMO ext2-dir-patch got to the stable stage. Currently
it's against 2.4.4-pre2, but it should apply to anything starting with
2.4.2 or so.
Ted, could you review it for potential inclusion into 2.4 once
it gets enough testing? It's ext2-only (the only change outside of
ext2 i
On Thu, 12 Apr 2001, Ed Tomlinson wrote:
> On Thursday 12 April 2001 11:12, Alexander Viro wrote:
> What prompted my patch was observing situations where the icache (and dcache
> too) got so big that they were applying artifical pressure to the page and
> buffer caches. I say art
On Fri, 13 Apr 2001, Jeff V. Merkey wrote:
> It would be nice if chrdev_open were added to ksyms.c along with
> blkdev_open since tape devices seem are always registered as character
> rather than block devices.
>
> I am finding that kernel modules that need to open and close a tape
> drive
On Fri, 13 Apr 2001, Jeff V. Merkey wrote:
> How are folks supposed to open disk and tape devices from kernel modules
> without these? Not everything should be done in user space Al. If you
Normally - filp_open(). If all you want is ioctl on block device -
blkdev_get() + ioctl_by_bdev() + bl
On Fri, 13 Apr 2001, Jeff V. Merkey wrote:
> Not meaning to offend, but how could you know what everyone
> who uses Linux needs in every instance? NT, NetWare, etc. all
> expose these types of APIs for Backup and anti-virus software,
> etc. The APIs in question are the very calls user space
On Fri, 13 Apr 2001, Jeff V. Merkey wrote:
> > Backup and AV software is not in the kernel, so they would
> > be unable to use the thing, exported or not. Please, don't
> > bring the strawmen.
>
> Some NT anti-virus stuff is in-kernel, and it's there to catch people
> writing viruses that act
On Fri, 13 Apr 2001, Linus Torvalds wrote:
>
>
> On 14 Apr 2001, John Fremlin wrote:
> >
> > . In fact, if you think
> > fork+exec is such a big performance hit why not go for spawn(2) and
> > have Linus and Al jump on you? ;-)
>
> spawn() is trivial to im
On Sun, 15 Apr 2001, Jeff Garzik wrote:
> Swivel wrote:
> >
> > drivers/char/char.c, line 247
> > create_proc_read_entry() is called regardless of the definition of
> > CONFIG_PROC_FS, simply wrap call with #ifdef CONFIG_PROC_FS and #endif.
>
> create_proc_read_entry exists, as a static inlin
On Mon, 16 Apr 2001, Jens Axboe wrote:
> > I can mount the same file on the same mountpoint more than once. If I
> > mount a file twice (same file on the same mount point)
>
> This is a 2.4 feature
Ability to losetup different loop devices to the same underlying
file is a bug, though. Not tha
Patch below switches the last 3 filesystems that are initialized from
filesystem_setup() to module_init/module_exit. Result: filesystem_setup() is
no more.
Linus, could you apply it?
Al
diff -urN S4-pre3/fs/devfs/bas
On Tue, 17 Apr 2001, Jeff Golds wrote:
> Hi folks.
>
> I noticed that proc_lookup is not exported in fs/proc/procfs_syms.c but
> that the function is an external in include/linux/proc_fs.h.
Not every public function needs to be exported. proc_lookup() is
shared between different files in fs/p
On Wed, 18 Apr 2001, Jeff Chua wrote:
> depmod: *** Unresolved symbols in /lib/modules/2.4.4-pre4/kernel/fs/nfsd/nfsd.o
> depmod: nfsd_linkage_Rb56858ea
Grrr...
Add #include to fs/filesystems.c. My apologies.
--- fs/filesystems.cTue Apr 17 23:40:32 2001
+++ /tmp/filesystems.c W
Linus, we need to make access to bits of ->d_flags atomic.
That used to be protected by BKL, but since we've got DCACHE_REFERENCED
it's no longer true - prune_dcache() and d_lookup() are not under BKL
and while they are safe wrt each other (both are under dcache_lock)
they race with every
On Wed, 18 Apr 2001, James Lewis Nance wrote:
> On Thu, Apr 12, 2001 at 12:33:42PM -0400, Alexander Viro wrote:
> > Folks, IMO ext2-dir-patch got to the stable stage. Currently
> > it's against 2.4.4-pre2, but it should apply to anything starting with
> > 2.4.2 or
On Wed, 18 Apr 2001, Jeff Golds wrote:
> I don't see why not. I created my own mkdir and rmdir handlers in my
> module. I'd like to use the lookup function that proc supplies instead
> of supplying my own, why shouldn't I be allowed to do that? It's not as
> if I am doing something other than
On Wed, 18 Apr 2001, Erik Mouw wrote:
> Hi all,
>
> While documenting the procfs interface (more of that later), I came
> across proc_mknod() which is supposed to be used to create devices in
> the procfs. IMHO it should therefore check if the mode parameter
> contains S_IFBLK or S_IFCHR.
Why
On Thu, 19 Apr 2001, Rik van Riel wrote:
> Hmmm, considering this, it may be wise to limit the amount of
> inodes in the inode cache to, say, 10% of RAM ... because we
> can cache MORE inodes if we store them in the buffer cache
> instead!
Rik, I'd rather check the effect of prune_icache() pat
On Wed, 18 Apr 2001, Rik van Riel wrote:
> On Thu, 19 Apr 2001, Daniel Phillips wrote:
>
> > OK, now I know what's happening, the next question is, what should be
> > dones about it. If anything.
>
> [ discovered by alexey on #kernelnewbies ]
>
> One thing we should do is make sure the buff
On Thu, 19 Apr 2001, Abramo Bagnara wrote:
> Alon Ziv wrote:
> >
> > Hmm...
> > I already started (long ago, and abandoned since due to lack of time :-( )
> > down another path; I'd like to resurrect it...
> >
> > My lightweight-semaphores were actually even simpler in userspace:
> > * the us
Erm... Folks, can ->s_inode_size be not a power of 2? Both
libext2fs and kernel break in that case. Example:
dd if=/dev/zero of=foo bs=1024 count=20480
mkfs -I 192 foo
corrupts memory and segfaults. Reason: ext2_read_inode() (same problem
is present in the kernel version of said beast) f
On Thu, 19 Apr 2001, Linus Torvalds wrote:
>
>
> On Thu, 19 Apr 2001, Alexander Viro wrote:
> >
> > I certainly agree that introducing ioctl() in _any_ API is a shootable
> > offense. However, I wonder whether we really need any kernel changes
> > at all.
&g
On Thu, 19 Apr 2001, Andreas Dilger wrote:
> Al, you write:
> > Erm... Folks, can ->s_inode_size be not a power of 2? Both
> > libext2fs and kernel break in that case. Example:
> >
> > dd if=/dev/zero of=foo bs=1024 count=20480
> > mkfs -I 192 foo
>
> I had always assumed that it would be
On Thu, 19 Apr 2001, Linus Torvalds wrote:
>
>
> On Thu, 19 Apr 2001, Alexander Viro wrote:
> >
> > Ehh... Non-lazy variant is just read() and write() as down_failed() and
> > up_wakeup() Lazy... How about
>
> Looks good to me. Anybody want to try this out a
On Thu, 19 Apr 2001, Matthew Jacob wrote:
>
> 'kay, great, thanks.. I'll put it in and see if things show up again
Guys, it's a known bug, fixed in 2.4.4-pre3. See the change to fs/super.c
between 2.4.4-pre2 and 2.4.4-pre3 - it's quite small.
-
To unsubscribe from this list: send the line "u
On 19 Apr 2001, Ulrich Drepper wrote:
> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> > I'm not interested in re-creating the idiocies of Sys IPC.
>
> I'm not talking about sysv semaphores (couldn't care less). And you
> haven't read any of the mails with examples I sent.
>
> If the new in
On Thu, 19 Apr 2001, Andreas Dilger wrote:
> Strange, I run "mke2fs -I 192 /dev/hdc2" and do not have a segfault or any
> problems with e2fsck or debugfs on the resulting filesystem. I'm running
> 1.20-WIP, but I don't think anything was changed in this area for some time.
May depend on the
On Thu, 19 Apr 2001 [EMAIL PROTECTED] wrote:
> This was a project that was never completed. I thought at one point
> of allowing the inode size to be not a power of 2, but if you do that,
> you really want to avoid letting an inode cross a block boundary ---
> for reliability and performance r
On Fri, 20 Apr 2001, Linus Torvalds wrote:
> Why are we doing the mntget/dget at all? We hold the spinlock, so we know
> they are not going away. Not doing the mntget/dget means that we (a) run
> faster and (b) don't have the bug, because we don't need to put the damn
> things.
>
> Comments?
On Fri, 20 Apr 2001, Jeremy Fitzhardinge wrote:
> This is a fix for a potential deadlock in autofs4's expire routine.
> It tries to use dput() while holding the dcache_lock. This isn't a
> problem in principle since dput() should only try to take the dcache_lock
> when the counter makes a tran
On Fri, 20 Apr 2001, Linus Torvalds wrote:
>
>
> On Fri, 20 Apr 2001, Jeremy Fitzhardinge wrote:
> >
> > I kept the dget/put out caution and ignorance, but they're clearly
> > problematic. I'm happy to drop them if holding dcache_lock is enough
> > to keep the tree stable while I traverse it
mkdir /A
mkdir /B
mkdir /C
touch /A/a
ln /A/a /B/b
ln /A/a /C/c
rm /A/a &
rm /B/b
can corrupt filesystem. Scenario:
unlink("/B/b") locks /B, removes "b" and unlocks /B. Then it calls
affs_remove_link(), which blocks.
unlink("/A/a") locks /A, removes "a" and unlocks /A. Then it calls
affs_remove
On Sat, 21 Apr 2001, Albert D. Cahalan wrote:
> Eric S. Raymond writes:
>
> > This is a proposal for an attribution metadata system in the Linux
> > kernel sources. The goal of the system is to make it easy for
> > people reading any given piece of code to identify the responsible
> > maintai
On Sun, 22 Apr 2001, Alon Ziv wrote:
> Well, that's the reason for my small-negative-integer semaphore-FD idea...
> (It won't support select() easily, but poll() is prob'ly good enough)
> Still, there is the problem of read()/write()/etc. semantics; sure, we can
> declare that 'negative FDs' ha
On Sun, 22 Apr 2001, David L. Parsley wrote:
> Hi,
>
> I'm still working on a packaging system for diskless (quasi-embedded)
> devices. The root filesystem is all tmpfs, and I attach packages inside
> it. Since symlinks in a tmpfs filesystem cost 4k each (ouch!), I'm
> considering using moun
On Sun, 22 Apr 2001, Eric S. Raymond wrote:
> Alexander Viro <[EMAIL PROTECTED]>:
> > Eric, it would save everyone a lot of time if you actually cared to
> > pull your head out of your... theoretical constructions and spent
> > some efforts figuring out how the th
On Sun, 22 Apr 2001, Eric S. Raymond wrote:
> Alexander Viro <[EMAIL PROTECTED]>:
> > Sigh... Would these broken things, by any chance, be "my grand ideas are
> > not met with applause"?
>
> Nope. Not at all. Stay tuned, because I'll explain.
>
On Mon, 23 Apr 2001, David L. Parsley wrote:
> What I'm not sure of is which solution is actually 'better' - I'm
> guessing that performance-wise, neither will make a noticable
> difference, so I guess memory usage would be the deciding factor. If I
Bindings are faster on lookup. For obvious
On Mon, 23 Apr 2001, Ingo Oeser wrote:
> Hi Chris,
>
> On Mon, Apr 23, 2001 at 04:54:02PM +0200, Christoph Rohland wrote:
> > > The question is: How? If you do it like ramfs, you cannot swap
> > > these symlinks and this is effectively a mlock(symlink) operation
> > > allowed for normal users.
On Tue, 24 Apr 2001, Ingo Oeser wrote:
> We have this kind of stuff all over the place. If we allocate
> some small amount of memory and and need some small amount
> associated with this memory, there is no problem with a little
> waste.
Little? How about quarter of kilobyte per inode? sizeof(
On Thu, 12 Apr 2001, Alexander Viro wrote:
> Folks, IMO ext2-dir-patch got to the stable stage. Currently
> it's against 2.4.4-pre2, but it should apply to anything starting with
> 2.4.2 or so.
>
> Ted, could you review it for potential inclusion into 2.4 o
On Mon, 23 Apr 2001, Richard Gooch wrote:
> - keep a separate VFSinode and FSinode slab cache
Yup.
> - allocate an enlarged VFSinode that contains the FSinode at the end,
> with the generic pointer in the VFSinode part pointing to FSinode
> part.
Please, don't. It would help with bloat o
Folks, updated namespace patch is on
ftp.math.psu.edu/pub/viro/namespaces-c-S4-pre6.gz
News:
* ported to 2.4.4-pre6
* fixes for d_flags races (already in -ac, hopefully will go into
the main tree soon)
* fixes for sync_inodes()/kill_super() races (submitted to L
On 24 Apr 2001, David Wagner wrote:
> Linus Torvalds wrote:
> >Ehh.. I will bet you $10 USD that if libc allocates the next file
> >descriptor on the first "malloc()" in user space (in order to use the
> >semaphores for mm protection), programs _will_ break.
> >
> >You want to take the bet?
>
On Mon, 23 Apr 2001, Jan Harkes wrote:
> On Mon, Apr 23, 2001 at 10:45:05PM +0200, Ingo Oeser wrote:
> > BTW: Is it still less than one page? Then it doesn't make me
> >nervous. Why? Guess what granularity we allocate at, if we
> >just store pointers instead of the inode.u. Or do you l
On Mon, 23 Apr 2001, Andreas Dilger wrote:
> Al posted a patch to the NFS code which removes nfs_inode_info from the
> inode union. Since it is (AFAIK) the largest member of the union, we
> have just saved 24 bytes per inode (hfs_inode_info is also rather large).
> If we removed hfs_inode_info
On Tue, 24 Apr 2001, David Woodhouse wrote:
>
> [EMAIL PROTECTED] said:
> > Oh, for crying out loud. All it takes is half an hour per filesystem.
>
> Half an hour? If it takes more than about 5 minutes for JFFS2 I'd be very
> surprised.
What's stopping you?
You _are_ JFFS maintainer, aren
On 24 Apr 2001, Christoph Rohland wrote:
> Hi Al,
>
> On Tue, 24 Apr 2001, Alexander Viro wrote:
> >> Half an hour? If it takes more than about 5 minutes for JFFS2 I'd
> >> be very surprised.
> >
> > What's stopping you?
> > You _are_
On Tue, 24 Apr 2001 [EMAIL PROTECTED] wrote:
> a friend of my asked me on how to make linux easier to use
> for personal/casual win user.
>
> i found out that one of the big problem with linux and most
> other operating system is the multi-user thing.
What, makes it hard to write viruses for
On Tue, 24 Apr 2001 [EMAIL PROTECTED] wrote:
[snip long wankage]
Equivalent of your "patch" can be achieved by making login(1) and
friends let everyone in as root without asking password. End of
story. If you don't understand even _that_ - you don't understand
the bloody basics of the system a
On Tue, 24 Apr 2001, Mohammad A. Haque wrote:
> [EMAIL PROTECTED] wrote:
[snip]
> Sounds to me like you really don't get the whole concept of permissions
> and that it's how Unix works.
>
> Besides, why should the kernel do anythign different for you when there
> are userland tools that you
On Tue, 24 Apr 2001, Tomas Telensky wrote:
> of linux distributions the standard daemons (httpd, sendmail) are run as
> root! Having multi-user system or not! Why? For only listening to a port
> <1024? Is there any elegant solution?
Sendmail is old. Consider it as a remnant of times when netwo
On Tue, 24 Apr 2001, Mohammad A. Haque wrote:
> Correct. <1024 requires root to bind to the port.
... And nothing says that it should be done by daemon itself.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordom
On Tue, 24 Apr 2001, Tomas Telensky wrote:
> Thanks for the comment. And why not just let it listen to 25 and then
> being run as uid=nobody, gid=mail?
Handling of .forward, for one thing. Or pipe aliases, or...
None of this stuff is unsolvable (e.g. handling of .forward belongs to
MDA, not M
On Tue, 24 Apr 2001, Alan Cox wrote:
> > On Tue, 24 Apr 2001, Mohammad A. Haque wrote:
> > > Correct. <1024 requires root to bind to the port.
> > ... And nothing says that it should be done by daemon itself.
>
> Or that you shouldnt let inetd do it for you
> And that you shouldn't drop the ca
On Tue, 24 Apr 2001, Alan Cox wrote:
> > > It is possible to implement the entire mail system without anything running
> > > as root but xinetd.
> >
> > You want an MDA with elevated privileges, though...
^
> What role requires priviledge once the port is open ?
.forward hand
On Tue, 24 Apr 2001, Andreas Dilger wrote:
> One thing to watch out for is that the current code zeros the u. struct
> for us (as you pointed out to me previously), but allocating from the
> slab cache will not... This could be an interesting source of bugs for
> some filesystems that assume z
On Tue, 24 Apr 2001, Andreas Dilger wrote:
> While I applaud your initiative, you made an unfortunate choice of
> filesystems to convert. The iso_inode_info is only 4*__u32, as is
> proc_inode_info. Given that we still need to keep a pointer to the
> external info structs, and the overhead of
On 24 Apr 2001, Trond Myklebust wrote:
> Hi Al,
>
> I believe your patch introduces a race for the NFS case. The problem
> lies in the fact that nfs_find_actor() needs to read several of the
> fields from nfs_inode_info. By adding an allocation after the inode
> has been hashed, you are crea
He's back. And this time he's got a chainsaw.
Yes, folks. We got per-process namespaces. Working. With proper
behaviour on exit(), yodda, yodda. Enjoy. Help with testing would be more
than welcome.
Current patch is on ftp.math.psu.edu/pub/viro/namespaces-S2.gz
It's against 2.4.2.
On Sun, 25 Feb 2001, Rick Hohensee wrote:
[I wrote]
> >ask. So far that's the best I can do - all documentation is a pile of
> >notes
> >+ CVS log.
[snip]
> That sounds like an especially fascinating pile of notes. Perhaps you
> could pile it next to the patch on the ftp site?
You know, CDA
On Tue, 6 Feb 2001, Wakko Warner wrote:
> > > > I found I could mount three partitions on /mnt
> > >
> > > Yes. New feature, appeared in the 2.4.0test series, or shortly before.
>
> I have a question, why was this idea even considered?
Direct request from HPA. Autofs can win from ha
On Wed, 7 Feb 2001, John R Lenton wrote:
> On Wed, Feb 07, 2001 at 12:25:10AM -0600, Peter Samuelson wrote:
> >
> > [Wakko Warner]
> > > I have a question, why was this idea even considered?
> >
> > Al Viro likes Plan9 process-local namespaces. He seems to be trying to
> > move Linux in that
On Wed, 7 Feb 2001, David L. Nicol wrote:
> Peter Samuelson wrote:
>
> > A more useful thing to fall out of the same hacking is loopback
> > mounting -- i.e. the same filesystem mounted multiple places. In
> > Linux-land I guess we call it 'mount --bind'.
> >
> > Peter
>
> Does this kind o
On Sun, 25 Feb 2001, Manfred Spraul wrote:
>
> > * large cleanup of boot process (ramdisk handling, etc.)
>
> Have you thought about supporting .tar.gz into ramfs? Creating custom
> boot images would be simpler.
*uh*. It's definitely easier to do than it used to be, but I'm seriously
scepti
On Sun, 25 Feb 2001, Sandy Harris wrote:
> One is just mount a ramdisk and extract a tarball into its root. Yes, this has
> some problems -- how do you load tar when you haven't set up your root? -- but
> I suspect they can be solved. At worst, this would involve some strictly limited
> kluge t
On Sun, 25 Feb 2001, Werner Almesberger wrote:
> Alexander Viro wrote:
> > No kludges actually needed. "Simplified boot sequence" _is_ simplified -
> > we overmount the "final" root over ramfs. Initially empty. So you have
> > the normal environment wh
On Sun, 25 Feb 2001, Jens Axboe wrote:
> On Sun, Feb 25 2001, Nate Eldredge wrote:
> > Nate Eldredge writes:
> > > Kernel 2.4.2-ac3.
> > >
> > > FLAGS UID PID PPID PRI NI SIZE RSS WCHAN STA TTY TIME COMMAND
> > > 40 0 425 1 -1 -20 0 0 downDW
On Mon, 26 Feb 2001, Werner Almesberger wrote:
> Alexander Viro wrote:
> > No. Just an overmount.
>
> Ah, too bad. Union mounts would have been really elegant (allowing the
> operation to be repeated without residues, and also allowing umounting
> of the covered FS as a
On Mon, 26 Feb 2001, Jens Axboe wrote:
> On Sun, Feb 25 2001, Alexander Viro wrote:
> > Jens, you have a race in lo_clr_fd() (loop-6). I've put the fixed
> > variant on ftp.math.psu.edu/pub/viro/loop-S2.gz. Diff and you'll
> > see - it's in the very beginnin
On Mon, 26 Feb 2001, Jens Axboe wrote:
> On Sun, Feb 25 2001, Alexander Viro wrote:
> > Erm... Jens, it really should be
> > if (atomic_dec_and_test(...))
> > up(...);
> > not just
> > atomic_dec(...);
> > up(...);
> >
>
On Sun, 25 Feb 2001, Alexander Viro wrote:
>
>
> On Mon, 26 Feb 2001, Jens Axboe wrote:
>
> > On Sun, Feb 25 2001, Alexander Viro wrote:
> > > Erm... Jens, it really should be
> > > if (atomic_dec_and_test(...))
> > > up(...);
>
On Mon, 26 Feb 2001, Jens Axboe wrote:
> On Sun, Feb 25 2001, Alexander Viro wrote:
> > Let me elaborate: the race is very narrow and takes deliberate efforts to
> > hit. It _can_ be triggered, unfortunately. This extra up() will mess your
> > life later on.
>
>
On Mon, 26 Feb 2001 [EMAIL PROTECTED] wrote:
> > BTW, we probably want to add mount --move - atomically moving
> > a subtree from one place to another. Code is there, we just need to
> > decide on API. Andries?
>
> Since we already have "mount --bind olddir newdir" this is not
> an unreasona
On Mon, 26 Feb 2001, Jens Axboe wrote:
> Ah ok, I see what you mean. Updated patch attached.
Corresponding patch against 2.4.2 is on ftp.math.psu.edu/pub/viro/loop-S2.gz
Cheers,
On Mon, 26 Feb 2001, Marco d'Itri wrote:
> On Feb 26, Alexander Viro <[EMAIL PROTECTED]> wrote:
>
> >There is no way to implement them without credentials' cache. Which needs
> >to be done for many other reasons, but that's a separate patch and
>
New version uploaded on ftp.math.psu.edu/pub/viro/namespaces-a-S2.gz
Changes:
* nosuid, nodev and noexec are per-mountpoint now.
* new flag for mount() - MS_MOVE (move a subtree, probable syntax
for mount(8) - mount --move old new; old must be a mountpoint)
* Fixes
New version uploaded on ftp.math.psu.edu/pub/viro/namespaces-d-S2.gz
Changes:
* fixed an idiotic bug in get_filesystem_info() that din't
unfortunately) show up on UP.
* nosuid/nodev/noexec work in any combinations (had been b0rken in
previous version).
* fixed m
On Tue, 27 Feb 2001, David L. Nicol wrote:
> /proc/cluster/this would be standard root point for clustering stuff
>
> /proc/mosix would go away, become proc/cluster/mosix
>
> and the same with whatever bproc puts into /proc; that stuff would move to
> /proc/cluster/bproc
#include
G
On Wed, 28 Feb 2001, Albert D. Cahalan wrote:
> Alexander Viro writes:
>
> > * CLONE_NEWNS is made root-only (CAP_SYS_ADMIN, actually)
>
> Would an unprivileged version that killed setuid be OK to have?
Not until we get decent resource accounting here.
> Evil
On Wed, 28 Feb 2001, Albert D. Cahalan wrote:
> Alexander Viro writes:
>
> > * CLONE_NEWNS is made root-only (CAP_SYS_ADMIN, actually)
>
> Would an unprivileged version that killed setuid be OK to have?
>
> Evil idea of the day: non-directory (even non-existant
On Wed, 28 Feb 2001, Ph. Marek wrote:
> Hi everybody!
>
> Hope I didn't forget something necessary.
>
>
>
> 1:
> Kernel bug/Segmentation fault when floppy disk removed 2nd time
>
>
> 2:
> Segmentation fault in a program,
> hanging processes in "D"-state,
> Kernel bug in inode.c:885!
>
On Wed, 28 Feb 2001, Manfred Spraul wrote:
> Alexander Viro wrote:
> >
> > - Doctor, it hurts when I do it!
> > - Don't do it, then.
> >
> Interesting bugfix:
> have you checked which BUG was triggered?
[snip]
Fsck. I plead guilty on replying to p
On Wed, 28 Feb 2001, David L. Parsley wrote:
> Alexander Viro wrote:
> > > Evil idea of the day: non-directory (even non-existant) mount points and
> > > non-directory mounts. So then "mount --bind /etc/foo /dev/bar" works.
> >
> > Try it. It _does_
On Thu, 1 Mar 2001, Peter Daum wrote:
> In that case, why was it changed for FAT only? Ext2 will still
> happily enlarge a file by truncating it.
Basically, the program depends on behaviour that was never guaranteed to
be there.
> Staroffice (the binary-only version; the new "open source"
> v
On Wed, 28 Feb 2001, Ion Badulescu wrote:
> On Wed, 28 Feb 2001 13:07:29 -0500 (EST), Alexander Viro <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 28 Feb 2001, David L. Parsley wrote:
>
> >> Yeah, mount --bind is cool, I've been using it on one of my projects
&g
1 - 100 of 969 matches
Mail list logo
