Re: [PATCH 05/14] fs: don't allow kernel reads and writes without iter ops

On Fri, Oct 09, 2020 at 06:29:13PM -0700, Linus Torvalds wrote: > On Fri, Oct 9, 2020 at 6:19 PM Eric Biggers wrote: > > > > Okay, that makes more sense. So the patchset from Matthew > > https://lkml.kernel.org/linux-fsdevel/20201003025534.21045-1-wi...@infradead.org/T/#u > > isn't what you had i

Re: [PATCH] NFS: Stop sillyname renames and unmounts from racing

On Tue, Nov 06, 2007 at 10:24:50AM +0200, Benny Halevy wrote: > It'd be very nice if the silly renamed inodes (with silly_count > 1) were > moved > to a different list in the first pass, under the inode_lock, and then waited > on > until silly_count <= 1 in a second pass only on the filtered lis

Re: [PATCH] NFS: Stop sillyname renames and unmounts from racing

On Mon, Nov 05, 2007 at 09:06:36PM -0800, Andrew Morton wrote: > > Any objections to exporting the inode_lock spin lock? > > If so, how should modules _safely_ access the s_inode list? > That's going to make hch unhappy. That's going to make me just as unhappy, especially since it's pointless; in

[PATCH] nfsroot uses bogus mountd version for NFSv2

nfsroot uses bogus protocol version when it asks portmapper on server for mountd port. Fix is obvious: --- linux/fs/nfs/nfsroot.cFri Feb 16 18:56:03 2001 +++ linux/fs/nfs/nfsroot.c.new Thu Jul 19 23:55:09 2001 @@ -418,7 +418,7 @@ "as nfsd port\n", port);

Re: [Acpi] Re: ACPI fundamental locking problems

On Sat, 7 Jul 2001, Jamie Lokier wrote: > Daniel Phillips wrote: > > > Reading a tarball is the distillation of what you describe into > > > efficient form :) > > > > /me downloads tar file definition > > > > Um, gnu tar or posix tar? or some new, improved tar? > > I suggest cpio, which is m

Re: [Acpi] Re: ACPI fundamental locking problems

On 7 Jul 2001, Eugene Crosser wrote: > Doesn't the approach "treat a chunk of data built into bzImage as > populated ramfs" look cleaner? No need to fiddle with tar format, > no copying data from place to place. What the hell _is_ "populated ramfs"? The thing doesn't live in array of blocks.

Re: [Acpi] Re: ACPI fundamental locking problems

On Thu, 5 Jul 2001, Helge Hafting wrote: > Linus Torvalds wrote: > [...] > > We migth want to just make initrd a built-in thing in the kernel, > > something that you simply cannot avoid. A lot of these things (ie dhcp for > > NFS root etc) are right now done in kernel space, simply because we d

Re: ufs on linux question/problem

On Tue, 3 Jul 2001, Admin Mailing Lists wrote: > > Trying to mount a solaris x86 drive under linux. > kernel 2.4.5, ufs support and x86 partition support compiled in (no > module) > On boot, linux recognizes the drive, but shows no solaris partitions on > it. > Below, linux drive is hda, solar

Re: Recent change in directory g+s behavior (bug?)

On Tue, 3 Jul 2001, Ken Brownfield wrote: > Somewhere between 2.4.5-pre1 and 2.4.6-pre3, the behavior of the setgid > bit on directories has changed: Fsck... Linus, please apply the patch below. That's a bug in ext2_new_inode() that used to be hidden by redundant code in ext2_mkdir().

Re: A Possible 2.5 Idea, maybe?

On Sat, 30 Jun 2001, Philips wrote: > If I could choose what filesystem to run on / - it impact performance greatly No, it doesn't. Most of lookups go outside of root and within root you mostly deal with cached lookups from dcache (which doesn't give a damn for fs type) and with page cac

Re: VFS locking & HFS problems (2.4.6pre6)

On Fri, 29 Jun 2001, Benjamin Herrenschmidt wrote: > The deadlock happen in the HFS filesystem in hfs_cat_put(), apparently > (quickly looking at addresses) in spin_lock(). Uh-oh. Looks like hfs_cat_put() grabs some internal spinlock and calls write_entry(). If it really is what its name impl

Re: directory order of files

On Fri, 29 Jun 2001, Alan Cox wrote: > > With Linux ext2, and some other systems, when you create files in a > > new directory, the file system remembers their order: > > No - it merely seems too. > > > $ touch one two three four > > $ ls -U > > one two three four > > Then try 'rm three;

Re: [PATCH] Bug in 2.4.5 in proc_pid_make_inode ()

On Thu, 28 Jun 2001, Martin Wilck wrote: > Hi, > > I have recently experienced a number of kernel OOPSes > in "top" under heavy load. Kernel is 2.4.5 (IA64, but > this has nothing to do the IA64 patch). > > The OOPS happens in the call tree > > open () system call > [...] > real_lookup () >

Re: Maximum mountpoints + chrooted login

On Wed, 27 Jun 2001, Magnus Naeslund(f) wrote: > I'll wait for 2.5 then... > Where's that namespace patch located? The last one I've put on anonftp was against 2.4.6-pre2 (namespaces-a-S6-pre2, on ftp.math.psu.edu/pub/viro). It still includes tons of fs/super.c cleanups and fixes - they still

Re: mounting a fs in two places at once?

On Thu, 28 Jun 2001, Chris Wedgwood wrote: > On Mon, Jun 25, 2001 at 02:20:16AM -0700, Ben Ford wrote: > > > Feature. It actually makes it quite nice when you want to allow > > chrooted user(s) access to a common directory, you just mount a > > partition in all the users home dirs. > > For s

Re: Maximum mountpoints + chrooted login

On Wed, 27 Jun 2001, Magnus Naeslund(f) wrote: > I was thinking of doing a chrooted login for some ssh accounts. > The plan is this: [snip CLONE_NAMESPACE-by-hands] > Does this seem like a bad idea? > (then please tell me why :)) Mostly because there's a better way to do that. Yes, such sch

Re: [PATCH] User chroot

On Wed, 27 Jun 2001, Chris Wedgwood wrote: > On Tue, Jun 26, 2001 at 09:40:36PM -0400, Alexander Viro wrote: > > > You need /dev/zero to get anywhere near the normal behaviour of the > > system. > > Not commenting on the original patch, I think requiring /dev/zero

Re: [PATCH] User chroot

On Tue, 26 Jun 2001, Paul Menage wrote: > But only root can set this up, since you currently have to be root in > order to chroot(). The (only) advantage of the user chroot() patch would > be that users would be able to do the same thing without root > intervention. You need to be root to do m

[RFC] Checks in ext2_new_block()

Ted, could you comment on sanity checks in ext2_new_block()? a) if (tmp == le32_to_cpu(gdp->bg_block_bitmap) || tmp == le32_to_cpu(gdp->bg_inode_bitmap) || in_range (tmp, le32_to_cpu(gdp->bg_inode_table), sb->u.ext2_sb.s_itb_per_group))

Re: mounting a fs in two places at once?

On Sun, 24 Jun 2001, Marty Leisner wrote: > I just installed redhat 7.1 on a system. > > Cleaning up, a made a fs for home...(mounted on /mnt > to write the stuff to it) > > Then I accidently mounted it on /home. > > So it was mounted on /home and /mnt at the same time. > (I didn't bother go

RE: The Joy of Forking

On Sun, 24 Jun 2001, George Bonser wrote: > > no SMP > > x86 only (and similar, e.g. Crusoe) > > Never YHBT. YHL. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/ma

Re: [OT]Re: One more ZDNet article with BillG hammering Linux andOpen Source.

On 22 Jun 2001, Miles Lane wrote: > It would be great to see the "Shared Source" licenses that Microsoft has > made people sign. It would be especially interesting to compare the It would be great to see you learning WTF "offtopic" means and taking the advocacy crap to the places where it be

Re: 2.4.5-ac16 -- "proc_get_inode" still unresolved in /net/wan/comx.o

On Tue, 19 Jun 2001, Miles Lane wrote: > > depmod: *** Unresolved symbols in >/lib/modules/2.4.5-ac16/kernel/drivers/net/wan/comx.o > depmod: proc_get_inode And it won't be exported. Moreover, it has a very good chance to become static. If you have the hardware in question and are wil

Re: What happened to lookup_dentry?

On Tue, 19 Jun 2001, Timur Tabi wrote: > Well, I didn't write the driver that I'm trying to port, so it's a little > difficult. The code in question is: > > struct dentry * de = lookup_dentry(zfcdb[i].fullname, NULL, LOOKUP_FOLLOW); > if (IS_ERR(de)) > continue; > if (de != zfcdb[

Re: Alan Cox quote? (was: Re: accounting for threads)

On Thu, 21 Jun 2001, Alexander Viro wrote: > > > On Thu, 21 Jun 2001, Rusty Russell wrote: > > > Disagree. A significant percentage of the netfilter bugs have been > > SMP only (the whole thing is non-reentrant on UP). > > I really doubt it. > Well, if

Re: Alan Cox quote? (was: Re: accounting for threads)

On Thu, 21 Jun 2001, Rusty Russell wrote: > Disagree. A significant percentage of the netfilter bugs have been > SMP only (the whole thing is non-reentrant on UP). I really doubt it. Well, if you use GFP_ATOMIC for everything... grep... Erm... AFAICS, you call create_chain() with interrupts

Re: Controversy over dynamic linking -- how to end the panic

On Thu, 21 Jun 2001, Timur Tabi wrote: > In my opinion, this whole thing would just go away (including some of > Microsoft's anti-GPL rants), if the FSF officially declared that under the GPL, > #including a GPL header file does NOT force your code to be also GPL. The problem being, there is n

Re: rename problem on vfat file systems

On Thu, 21 Jun 2001, abc abc wrote: > If I reboot the machine just after the rename() call > is completed, when the machine comes up the file > /mnt/sns-c/segments/segfile has zero bytes and there > is no file in the tmp directory. Effectively the file > is lost some where. Running fsck recover

Re: [PATCH] remove null register_disk

On Wed, 20 Jun 2001 [EMAIL PROTECTED] wrote: > In fs/partitions/check.c we read > > void register_disk(struct gendisk *gdev, kdev_t dev, unsigned minors, > struct block_device_operations *ops, long size) > { > if (!gdev) > return; > grok_partitions(gdev,

Re: Alan Cox quote? (was: Re: accounting for threads)

On Wed, 20 Jun 2001, george anzinger wrote: > > around we _will_ get problems. Kernel UP programming is not different > > from SMP one. It is multithreaded. And amount of genuine SMP bugs is > > very small compared to ones that had been there on UP since way back. > > And yes, programming threa

Re: Threads are processes that share more

On Wed, 20 Jun 2001, bert hubert wrote: > Rounding up, it may be worth repeating what I think Alan said some months > ago: > > Threads are processes that share more ... and for absolute majority of programmers additional shared objects mean additional fsckup sources. I do

Re: 2.4.5 corruption (again)

On Tue, 19 Jun 2001, Larry McVoy wrote: > OK, my corruption is back and this time I'm saving the data. Al, send some > email when you are around, we can talk about access to the data. I'm tarring Doing that. > up both good & bad right now. I've looked at a few files and they look > "shift

Re: What happened to lookup_dentry?

On Mon, 18 Jun 2001, Timur Tabi wrote: > I'm porting a driver from 2.2 to 2.4, and this driver calls lookup_dentry, > which doesn't exist in 2.4. I've read through the source code and searched the > web and newsgroups, and I can't find any explanation as to why lookup_dentry no > longer exists

Re: [PATCH] devfs v181 available

On Mon, 18 Jun 2001, Richard Gooch wrote: > > Irrelevant. BKL provides an exclusion only on non-blocking areas. > > Yeah, I know all that. So what the hell are you talking about? > > _Moved_ them there from the callers of these functions. And AFAICS > > you do need BKL for get_devfs_entry_..

Re: Newbie idiotic questions.

On Mon, 18 Jun 2001, Roman Zippel wrote: > > I wouldn't call it "rather popular". > > You should also grep for '__typeof__'. :-) Yeeeccchhh. OK, there is more of that. However, the main user of that beast is, AFAICS, get_user()/put_user() and their ilk in include/asm-* The rest looks very bog

Re: function of getname() function

On Mon, 18 Jun 2001, SATHISH.J wrote: > Hi, > > Sorry if this question is too silly. > > I could not understand what getname(filename) function in the sys_open() > function is doing. I could not understand from the code what exactly it is > doing. Please help me with the same. It allocates a

Re: [PATCH] devfs v181 available

On Mon, 18 Jun 2001, Richard Gooch wrote: > Alexander Viro writes: > > > > > > On Mon, 18 Jun 2001, Richard Gooch wrote: > > > > > - Widened locking in and > > > > No, you hadn't. Both vfs_readlink() and vfs_follow_link() are blocki

Re: [PATCH] devfs v181 available

On Mon, 18 Jun 2001, Richard Gooch wrote: > - Widened locking in and No, you hadn't. Both vfs_readlink() and vfs_follow_link() are blocking functions, so BKL is worthless there. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROT

Re: Newbie idiotic questions.

On Sun, 17 Jun 2001, Daniel Phillips wrote: > typeof? It's rather popular in the kernel already. Besides, who is going to Really? 5 instances in PPC arch-specific code, 1 (absolutely gratitious) in drivers/mtd, 2 - in m68k (also useless), 4 - in drivers/video, 2 - in AFFS and 1 - in netfilt

Re: Newbie idiotic questions.

On Sun, 17 Jun 2001, Daniel Phillips wrote: > > macro that behaves like `new' in C++: > > | #define knew(type, flags) (type *)kmalloc(sizeof(type), (flags)) > > > > If the types in the assignment don't match, gcc will tell you. > > Well, since we are still beating this one to death, I'd writte

Re: Reg:magic number of the filesystem

On Sun, 17 Jun 2001, SATHISH.J wrote: > Hi, > > Every file system has a magic number. Can you please tell me what for this > magic number is used. When do we really use this unique magic number of > the file system and why? find . -name *.[chS] >/tmp/list xargs http://vger.kernel.org/majordom

Re: Reg:use of file_system_type structure

On Sun, 17 Jun 2001, SATHISH.J wrote: > Hi, > Every file system has file_system_type structure defined. Where else this > structure is referred. Does register_filesystem() refer this structure. > Does sys_mount refer to this structure by any means? Umm... No offense, but * all of these

Re: [ANNOUNCE] HotPlug CPU patch against 2.4.5

On Sun, 17 Jun 2001, Rusty Russell wrote: > In message <[EMAIL PROTECTED]> you write: > > In article you wrote: > > > # Up... > > > echo 1 > /proc/sys/cpu/1 > > > > Wouldn't /proc/sys/cpu//enable be better? This way other per-cpu > > sysctls could be added more ea

Re: Kernel 2.0.35 limits

On Fri, 15 Jun 2001, Paul Faure wrote: > Just this morning, our firewall get a kernel panic after 500 days of > uptime. > > As you can see from the log files, the date starts at June 15th, where we > get two div by zeros, then jumps May 11th, then a kernel panic. A reboot > brings it back to J

Re: unregistered changes to the user<->kernel API

On Thu, 14 Jun 2001, Richard Henderson wrote: > Yes, I saw those. What is the effect of O_NOFOLLOW? To not > follow symbolic links when opening the file. If you open a > regular file, in effect nothing happens. Moreover, if these > opens were not finding files now, the system wouldn't work.

Re: Download process for a "split kernel" (was: obsolete code mustdie)

On Thu, 14 Jun 2001, Daniel Phillips wrote: > This sounds a lot like apt-get, doesn't it? Folks, RTFFAQ, please. URL is attached to the end of each posting. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo i

Re: is there a way to export a fat32 file system using nfs?

On Wed, 13 Jun 2001, Neil Brown wrote: >Call fat_iget(i_location). > If this finds something, check i_logstart. > If it matches, assume SUCCESS. > >Then comes the tricky bit: read the directory entry > indicated by i_location, check the i_logstart is right, > if it is

Re: threading question

On Tue, 12 Jun 2001, Kip Macy wrote: > implementation of threads is not an accidental oversight, threads are not > looked upon favorably by most of the core linux kernel hackers. A quote s/threads/POSIX threads/. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the

Re: [CFT][PATCH] superblock handling changes

On Tue, 12 Jun 2001, Marcelo Tosatti wrote: > > > On Tue, 12 Jun 2001, Alexander Viro wrote: > > > Folks, the patch below the fixed and combined variant of > > the last series of patches sent to Linus. > > Al, > > Since you are working on t

[PATCH] fs/super.c stuff (3/10)

diff -urN S6-pre2-fsync_no_super/include/linux/fs.h S6-pre2-put_super/include/linux/fs.h --- S6-pre2-fsync_no_super/include/linux/fs.h Sun Jun 10 18:36:27 2001 +++ S6-pre2-put_super/include/linux/fs.hSun Jun 10 18:39:04 2001 @@ -1320,7 +1320,6 @@ extern struct file_system_type *get_f

[PATCH] fs/super.c stuff (8/10)

diff -urN S6-pre2-s_count/fs/inode.c S6-pre2-freeing/fs/inode.c --- S6-pre2-s_count/fs/inode.c Sun Jun 10 12:45:04 2001 +++ S6-pre2-freeing/fs/inode.c Sun Jun 10 12:45:47 2001 @@ -258,23 +258,6 @@ __sync_one(list_entry(tmp, struct inode, i_list), 0); } -static inline int wait_

[PATCH] fs/super.c stuff (5/10)

diff -urN S6-pre2-put_super/fs/dquot.c S6-pre2-dquot/fs/dquot.c --- S6-pre2-put_super/fs/dquot.cThu May 24 18:26:44 2001 +++ S6-pre2-dquot/fs/dquot.cSun Jun 10 18:46:54 2001 @@ -325,7 +325,7 @@ memset(&dquot->dq_dqb, 0, sizeof(struct dqblk)); } -void invalidate_dquots(kdev_

Re: [PATCH] fs/super.c stuff (6/10)

diff -urN S6-pre2-dquot/arch/parisc/hpux/sys_hpux.c S6-pre2-drop_super/arch/parisc/hpux/sys_hpux.c --- S6-pre2-dquot/arch/parisc/hpux/sys_hpux.c Fri Feb 16 20:46:44 2001 +++ S6-pre2-drop_super/arch/parisc/hpux/sys_hpux.c Sun Jun 10 18:38:23 2001 @@ -109,9 +109,11 @@ lock_kernel()

[PATCH] fs/super.c stuff (10/10)

diff -urN S6-pre2-alloc_super/fs/inode.c S6-pre2-current/fs/inode.c --- S6-pre2-alloc_super/fs/inode.c Sun Jun 10 19:09:35 2001 +++ S6-pre2-current/fs/inode.c Sun Jun 10 19:26:27 2001 @@ -357,11 +357,7 @@ spin_unlock(&inode_lock); down_read(&s->s_umount);

Re: [PATCH] fs/super.c stuff (3/10)

Grr... 4 of 10, that is. Sorry. On Mon, 11 Jun 2001, Alexander Viro wrote: > diff -urN S6-pre2-fsync_no_super/include/linux/fs.h >S6-pre2-put_super/include/linux/fs.h > --- S6-pre2-fsync_no_super/include/linux/fs.h Sun Jun 10 18:36:27 2001 > +++ S6-pre2-put_super/includ

[PATCH] fs/super.c stuff (7/10)

diff -urN S6-pre2-put_super/fs/inode.c S6-pre2-s_count/fs/inode.c --- S6-pre2-put_super/fs/inode.cSun Jun 10 12:25:34 2001 +++ S6-pre2-s_count/fs/inode.c Sun Jun 10 12:29:35 2001 @@ -339,30 +339,48 @@ spin_unlock(&inode_lock); } +/* + * Note: + * We don't need to grab a referen

[PATCH] fs/super.c stuff (9/10)

diff -urN S6-pre2-freeing/fs/super.c S6-pre2-current/fs/super.c --- S6-pre2-freeing/fs/super.c Sun Jun 10 12:45:47 2001 +++ S6-pre2-current/fs/super.c Sun Jun 10 12:53:15 2001 @@ -59,8 +59,6 @@ /* this is initialized in init/main.c */ kdev_t ROOT_DEV; -int nr_super_blocks; -int max_super_blo

[PATCH] fs/super.c stuff (3/10)

diff -urN S6-pre2-s_active/fs/block_dev.c S6-pre2-fsync_no_super/fs/block_dev.c --- S6-pre2-s_active/fs/block_dev.c Fri Jun 8 18:29:02 2001 +++ S6-pre2-fsync_no_super/fs/block_dev.c Sun Jun 10 12:13:03 2001 @@ -678,8 +678,10 @@ down(&bdev->bd_sem); /* syncing will go her

[PATCHes] fs/super.c stuff

OK. It works here(tm). I'm sending first 10 chunks - about 70% of locking changes. That's a good intermediate point and I'd rather avoid doing too large steps. Contents (patches will go in separate postings): 1, Eliminates mnt_instances and s_mounts. Instead of it we add new field to struct supe

[PATCH] fs/super.c stuff (2/10)

diff -urN S6-pre2-mnt_instances/fs/super.c S6-pre2-s_active/fs/super.c --- S6-pre2-mnt_instances/fs/super.cSat Jun 9 19:18:31 2001 +++ S6-pre2-s_active/fs/super.c Sun Jun 10 12:07:40 2001 @@ -388,7 +388,6 @@ spin_lock(&dcache_lock); list_add(&mnt->mnt_list, vfsmntlist.prev);

[PATCH] fs/super.c stuff (1/10)

diff -urN S6-pre2/fs/super.c S6-pre2-mnt_instances/fs/super.c --- S6-pre2/fs/super.c Fri Jun 8 18:29:03 2001 +++ S6-pre2-mnt_instances/fs/super.cSat Jun 9 19:18:31 2001 @@ -386,19 +386,20 @@ mnt->mnt_parent = mnt; spin_lock(&dcache_lock); - list_add(&mnt->mnt_instanc

[PATCH] Re: Oops with kernel 2.4.5 on heavy disk traffic

Please, apply. What's happing here is simple - we set i_ino by PID and get something out of range of per-process inode. Confusion follows... Fix: move initializing ->u.proc_i.task past the check. Then proc_delete_inode() will be happy with it. Alois, Bryce - that ought to fix the o

Re: [PATCH] sockreg2.4.5-05 inet[6]_create() register/unregistertable

On Sat, 9 Jun 2001, watermodem wrote: > He is discussing a theme with legal implications. (Legal and Slow tended > to be intertwined) I know what his position in the linux kernel > hierarchy is, and if he were in a corporation with that position he > could just say NO without any reason. But,

Re: [CHECKER] a couple potential deadlocks in 2.4.5-ac8

On Sat, 9 Jun 2001, Linus Torvalds wrote: > On Sat, 9 Jun 2001, Alexander Viro wrote: > > > > True, but... I can easily see the situation when ->foo() and ->bar() > > both call a helper function which needs BKL for a small piece of code. > > I'd

Re: [CHECKER] a couple potential deadlocks in 2.4.5-ac8

On Sat, 9 Jun 2001, Linus Torvalds wrote: > Anyway, in a 2.5.x timeframe we should probably make sure that we do not > have the need for a recursive BKL any more. That shouldn't be that hard to > fix, especially with help from CHECKER to verify that we didn't forget > some case. True, but... I

Re: [CHECKER] a couple potential deadlocks in 2.4.5-ac8

On 9 Jun 2001, Linus Torvalds wrote: > The big kernel lock rules are that it's a "normal spinlock" in many > regards, BUT you can block while holding it, and the BKL will magically > be released during the blocking. This means, for example, that the BKL > can never deadlock with a semaphore -

Re: [patch] truncate_inode_pages

> takes 45 seconds CPU time due to the O(clean * dirty) algorithm in > truncate_inode_pages(). The machine is locked up for the duration. > The patch reduces this to 20 milliseconds via an O(clean + dirty) > algorithm. Unfortunately, it's _not_ O(clean + dirty). > + while (truncat

Re: [CHECKER] a couple potential deadlocks in 2.4.5-ac8

On Sat, 9 Jun 2001, Dawson Engler wrote: > Hi All, > > we're starting to develop a checker that finds deadlocks by (1) > computing all lock acquisition paths and (2) checking if two paths > violate a partial order. > > E.g., for two threads T1 and T2: > T1: foo acquires A --> calls bar

Re: PROBLEM: I/O system call never returns if file desc is closedin the

On 7 Jun 2001, Florian Weimer wrote: > There's a subtle difference: For malloc(), libc has a mutex (or > whatever), but for open(), socket() etc., no locking is performed, and > many libc functions create (and destroy) descriptors imlicitely. So? You don't have to close() descriptors you had

Re: PROBLEM: I/O system call never returns if file desc is closedin the

On 7 Jun 2001, Florian Weimer wrote: > Matthias Urlichs <[EMAIL PROTECTED]> writes: > > > Select is defined as to return, with the appropriate bit set, if/when > > a nonblocking read/write on the file descriptor won't block. You'd get > > EBADF in this case, therefore causing the select to ret

Re: symlink_prefix

On Thu, 7 Jun 2001, Edgar Toernig wrote: > Alexander Viro wrote: > > ... > > dir = open("/usr/local", O_DIRECTORY); > > /* error handling */ > > new_mount(dir, MNT_SET, fs_fd); /* closes dir and fs_fd */ > > Do yo

Re: Break 2.4 VM in five easy steps

On Wed, 6 Jun 2001, Sean Hunter wrote: > This is completely bogus. I am not saying that I can't afford the swap. > What I am saying is that it is completely broken to require this amount > of swap given the boundaries of efficient use. Funny. I can count many ways in which 4.3BSD, SunOS{3,4}

[PATCH] more fs/super.c cleanups (5)

Chunk 5: * we put vfsmounts into hash, keyed by pair dentry/vfsmount of mountpoint. attach_mnt() and detach_mnt() do the obvious thing. * follow_down() and friends do lookup in that hash, instead of traversing ->d_vfsmnt. It kills scalability problem with many parallel trees (if yo

[PATCH] more fs/super.c cleanups (4)

Chunk 4: OK, this one is interesting. * new function - graft_tree(what, where). It does necessary locking and checks and mounts existing vfsmount on given point. Basically, it's the common part of mounting and binding. Checks are usual - mountpoint is not dead, we are not trying to mount d

[PATCH] more fs/super.c cleanups (3)

Chunk 3: Takes the normal mounting into a helper similar to do_loopback() et.al., makes do_mount() cleaner. Please, apply Al diff -urN S6-pre1-do_mount/fs/super.c S6-pre1-do_add_mount/fs/super.c --- S6-pre1-do_mount/fs/super.

[PATCH] more fs/super.c fixes (2)

Chunk 2: Since all branches of do_mount() (mounting, binding, remounting) do the same thing (lookup of directory) we can take that lookup in the beginning of do_mount() and pass to do_loopback() and do_remount() nameidata instead of name. Please, apply

[PATCH] more fs/super.c cleanups (1)

Linus, here's the next series of fs/super.c cleanups, cut into small chunks. Patches are incremental. Chunk #1: Switches special case in do_umount() to do_remount_sb() (from do_remount()); takes all per-superblock steps of remount into remount_sb(). That will allow to clean the lo

Re: symlink_prefix

On Sun, 3 Jun 2001 [EMAIL PROTECTED] wrote: > What I did was: add a field `char *mnt_symlink_prefix;' to the > struct vfsmount, fill it in super.c:add_vfsmnt(), use it in > namei.c:vfs_follow_link(). Pick the value up by recognizing > in super.c:do_mount() the option "symlink_prefix=" before

Re: symlink_prefix

On Sun, 3 Jun 2001 [EMAIL PROTECTED] wrote: > > Current interface had grown an impressive collection of warts. > > Worse yet, you _can't_ put parsing into generic code. > > There are filesystems that have a binary object as 'data'. > > Yes, that was a very unfortunate decision, back in the goo

Re: symlink_prefix

On Sun, 3 Jun 2001 [EMAIL PROTECTED] wrote: > [My version: keep interface constant, reorganize kernel source > to do certain things in one place instead of in several places. > Advantage: treatment becomes uniform and some options that make sense > for all filesystem types but are available tod

Re: symlink_prefix

On Sun, 3 Jun 2001 [EMAIL PROTECTED] wrote: > This evening I needed to work on a filesystem of a non-Linux OS, > full of absolute symlinks. After mounting the fs on /mnt, each > symlink pointing to /foo/bar in that filesystem should be > regarded as pointing to /mnt/foo/bar. > > Since doing ls

Re: unmount issues with 2.4.5-ac5, 3ware, and ReiserFS (was: kernel-2.4.5

On Fri, 1 Jun 2001, Hans Reiser wrote: > known VFS bug, ask viro for details, 2.4.5 is not stable because of it, use > 2.4.4 Different issue. Missing lock_kernel()/unlock_kernel() in kill_super() appeared in -pre6 and was fixed in -ac2 or so. -ac5 apparently had introduced something new, that

Re: Linux 2.4.5-ac6

On Fri, 1 Jun 2001, Alan Cox wrote: > o Fix the cs46xx right this time (me) > o Further FATfs cleanup (OGAWA Hirofumi) > o ISDN PPP code cleanup, cvs tag update (Kai Germaschewski) > o Large amount of UFS file system cleanup

Re: 2.4.4 Kernel Oops and ls+rm segfaults

On Fri, 1 Jun 2001, Gregor Jasny wrote: > Hi! > > Can anyone tell me, where this oops came from? > The machine is a HP NetServer II lc (EISA+PCI architecture). > The distribution is a slackware 7.0 with parts of 7.1 and current. > gcc: 2.95.4 20010319 (Debian prerelease) > > I hope you can he

Re: Configure.help is complete

On Thu, 31 May 2001, Arjan van de Ven wrote: > José Luis Domingo López wrote: > > > > On Thursday, 31 May 2001, at 13:24:54 -0400, > > Eric S. Raymond wrote: > > > > > It gives me great pleasure to announce that the Configure.help master > > > file is now complete with respect to 2.4.5. Ever

Re: OOPS with 2.4.5 [kernel BUG at inode.c:486]

On 30 May 2001, Trond Myklebust wrote: > The reason we haven't seen this before is that we had 'force_delete' > that would always set i_nlink = 0. Unfortunately force_delete is toxic > to mmap(), as it will discard any dirty pages rather than flushing > them to storage, so it was removed in the

Re: [CHECKER] 84 bugs in 2.4.4/2.4.4-ac8 where NULL pointers arederef'd

On Wed, 30 May 2001, Andreas Dilger wrote: > > b) doesn't fix anything that could be triggered - ext2_delete_entry() > > can happen only if you've already done lookup. I.e. no problems had been > > found in that block back when we were finding the entry. > > That means there is no need to

Re: [CHECKER] 84 bugs in 2.4.4/2.4.4-ac8 where NULL pointers arederef'd

On Tue, 29 May 2001, Dawson Engler wrote: > [BUG] seems like it. it's not guarded. or is there some weird dependence? > /u2/engler/mc/oses/linux/2.4.4-ac8/fs/ext2/dir.c:61:ext2_check_dir_entry: >ERROR:INTERNAL_NULL:53:61: [type=set] (set at line 53) Dereferencing NULL ptr "dir" >illegally!

Re: OOPS with 2.4.5 [kernel BUG at inode.c:486]

On Tue, 29 May 2001, Gergely Tamas wrote: > Warning (compare_maps): mismatch on symbol partition_name , ksyms_base says >c01c4020, System.map says c0154160. Ignoring ksyms_base entry > kernel BUG at inode.c:486! [snip] _Lovely_. NFS, apparently on revalidate path, doesn't care to hold on

Re: BUG?: 2.4.5 breaks reiserfs (kernel BUG)

On Sun, 27 May 2001, Bjerkeset, Svein Olav wrote: > Hi, > > Today I downloaded kernel 2.4.5 and compiled it. The kernel worked fine > until > I tried to halt the computer. When trying to unmount the reiserfs > filesystems, > the system freezes with the following output: > > journal_begin call

Re: Linux-2.4.5 and Reiserfs, oops!

On Sat, 26 May 2001, Chris Rankin wrote: > Well the first thing I checked was vanilla 2.4.5, and I managed to > bring that down hard too. It has nothing at all to do with reiserfs, > but may be related to USB instead. I have been able to reproduce the > problem by doing the following: > > a) B

RE: Linux-2.4.5 and Reiserfs, oops!

On Sat, 26 May 2001, Chris Rankin wrote: > Hi, > > Thanks for the patch; I successfully unmounted my reiserfs USB Zip 250 > MB disc. However, the box then locked up hard when I unmounted an NFS > mount and tried to switch to another virtual console. That's... interesting. With that patch chan

[FIX] Re: umount segfault on shutdown

On Sat, 26 May 2001, Gavin wrote: > Hi, > Hope this is enough info :P > > Unmounting file systems: journal_begin called without kernel lock held > kernel BUG at journal.c:423! --- fs/super.c Fri May 25 21:51:14 2001 +++ fs/super.c.new Sun May 27 00:21:53 2001 @@ -873,6 +873,7 @@

Re: Linux-2.4.5, reiserfs, Oops!

On Sat, 26 May 2001, Chris Rankin wrote: > Linux 2.4.5, SMP, devfs, < 1 GB memory, compiled with gcc-2.95.3 > drive. I didn't do anything clever with parameters or anything; just > "mkreisferfs /dev/sda1", mounted it and then unmounted it again. And > the kernel oopsed on me. Bloody hell. -

Re: kernel BUG at inode.c:654!

On Sat, 26 May 2001, Santiago Garcia Mantinan wrote: > Hi! > > That's what my server, wich is running 2.4.5, was shouting when I pluged in > my laptop at the console (ttyS0), all I could do was copy the output I was > seeing on minicom to a file, after rebooting I saw that the kernel had left

[CFT][PATCH] namespaces patch (2.4.5-pre6)

Folks, new version of the patch is on ftp.math.psu.edu/pub/viro/namespaces-c-S5-pre6.gz News: * ported to 2.4.5-pre6 * new (cleaner) locking mechanism * lock_super() is starting to become fs-private thing - first steps to removing it from VFS code are done. Please, help with te

[PATCH] (part 7) fs/super.c cleanups

Handling of refcounts for FS_SINGLE filesystems moved to add_vfsmnt(). That's the first half of real fix for FS_SINGLE mess - we should make it "read_super() if we hadn't done it yet, otherwise return what we have". That will make kern_mount() uses simpler and remove all special-casing wit

[PATCH] (part 6) fs/super.c cleanups

Expands add_vfsmnt() call in kern_mount(), takes alloc_vfsmnt() before reading superblock and makes (in add_vfsmnt()) insertion into vfsmntlist unconditional (kern_mount()) was the only case when we didn't want it to happen. Moreover, recovery in kern_mount() becomes simpler. Plea

[PATCH] (part 5) fs/super.c cleanups

Takes allocation/initalization of vfsmounts into separate function. We will need this separation to deal with several places where we need a non-blocking (and non-failing) equivalent of add_vfsmnt(). There allocation will be done outside of critical area. Please, apply. diff -urN

[PATCH] (part 4) fs/super.c cleanup

* MNT_VISIBLE is gone. We simply do not insert vfsmounts we don't want to see into the vfsmntlist. The only place where it is used is get_filesystem_info(), so it's obviously correct. Please, apply. PS: I've done a different locking scheme for superblocks, so right now I'

  1   2   3   4   5   6   7   8   9   10   >