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

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

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 list.

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;

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;

[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);

[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

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 more compact and

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 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. Its

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

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 don't

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,

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: 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: 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, solaris is

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

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

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

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

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(). looks Uh-oh. Looks like hfs_cat_put() grabs some internal spinlock and calls write_entry(). If it really is what its name

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; touch five'

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: [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

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

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 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 for a 'usable' system should

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 scheme

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: [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

[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),

[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: [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

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

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

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

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 going in

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

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

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

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 !=

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 !=

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

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

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

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 recovers

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 no

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. looking through the thing raised brows Well, if you use GFP_ATOMIC for everything... grep... Erm... AFAICS, you

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. looking through the thing raised brows Well, if you use

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; >

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

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

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 don't

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 threads is

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: 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 >

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 shifted.

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

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

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

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

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 blocking &g

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

Re: [PATCH] devfs v181 available

On Mon, 18 Jun 2001, Richard Gooch wrote: - Widened locking in devfs_readlink and devfs_follow_link 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

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 devfs_readlink and devfs_follow_link No, you hadn't. Both vfs_readlink() and vfs_follow_link() are blocking functions, so BKL is worthless

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: 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 bogus...

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: 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 or

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

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

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

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

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: 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 /tmp/list grep -nw s_magic xargs

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 written a knew

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

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

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 m15BG8K-001UIwC@mozart you wrote: # Up... echo 1 /proc/sys/cpu/1 Wouldn't /proc/sys/cpu/num/enable be better? This way other per-cpu sysctls could be added more easily... Yep.

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

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 June

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

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

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

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: 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

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

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: 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, try

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

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 that code, would you mind to add some comments about IO

[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

[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

[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(>dq_dqb, 0, sizeof(struct dqblk)); } -void invalidate_dquots(kdev_t dev,

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 @@

[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(_lock); down_read(>s_umount);

  1   2   3   4   5   6   7   8   9   10   >