December 2001 - Darwin-kernel

Re: UFS not 64-bit clean?
by Umesh Vaishampayan 13 Dec '01

13 Dec '01

On Thursday, December 13, 2001, at 12:43 PM, Chris Bednar wrote: Hmmm, also.... please don't ask me why I did this: @@ -366,7 +366,7 @@ #endif /* REV_ENDIAN_FS */ brelse(bp); - return (EIO); /* XXX needs translation */ + /*return (EIO); XXX needs translation */ I wonder why it did not panic later when you brelse(bp) the same buffer again.... 386 brelse(bp); --Umesh --Umesh Vaishampayan Apple Computer, Inc. Mac OS X Kernel Ph: (408) 974 0229

1 0

Support of dummynet in ipfw for bandwidth limiting
by Chris Lewicki 13 Dec '01

13 Dec '01

Hi, I'd like to bandwidth limit some services coming from my Mac OS X machine, and the use of ipfw w/dummynet (http://info.iet.unipi.it/~luigi/ip_dummynet/) seemed like the easiest and most appropriate thing for my application. However, it would seem that dummynet is not supported in Darwin, despite the presence of a few header files throughout the system to the contrary. When trying to add a pipe and configure it I get the following error: ipfw: setsockopt(IP_DUMMYNET_CONFIGURE): Protocol not available So, my question: Is anyone working on a port? I gave a quick try from FreeBSD sources, but haven't had much luck. I think I'm missing things like ip_dummynet.c, bridge.c etc.... Also, while I've been able to recompile a working IPFirewall kernel extension, perhaps I need to be updating /sbin/ipfw as well? But where's the source? Can't seem to find an Apple version of it anywhere. Anyway, hope this finds a quick solution. Thanks! -Chris

1 0

Re: UFS not 64-bit clean?
by Chris Bednar 13 Dec '01

13 Dec '01

Hmmm, also.... please don't ask me why I did this: > @@ -366,7 +366,7 @@ > #endif /* REV_ENDIAN_FS */ > > brelse(bp); > - return (EIO); /* XXX needs translation */ > + /*return (EIO); XXX needs translation */ ---- Chris J. Bednar Director, Distributed Computing Product Group http://AdvancedDataSolutions.com/

1 0

Re: UFS not 64-bit clean?
by Chris Bednar 13 Dec '01

13 Dec '01

> What does your patch look like? I'll include it at end... it's actually a bit worse than I described before... > > if (lbn < 0) > > return (EFBIG); > > You get this error when you do truncate(), right? Actually, at that time I was getting it just about everywhere, because (I think) fs_maxfilesize wasn't getting set anywhere, so I couldn't write any file greater than 0 bytes. That's a pretty safe setup! The patch included below causes a kernel panic when the file size gets > 4GB. I forgot to bring the backtrace I scrawled down with me, so if it is of interest, I'll get it later (is there anything else you'ld like to see; I don't mind krashing the machine again to get it ;) Note that there are a couple of these - ffs_oldfscompat(fs); + /*ffs_oldfscompat(fs);*/ /*cjb - guess*/ out of desperation; they don't appear to make any difference, as expected. > > in the superblock is 4GB. I'll have to play with dumpfs later (I wonder > > why that doesn't work on a mounted FS?) > > Supply the characher device corresponding to your mounted file system to > make it happy... Ah, kool. However, with or without my patch, on any UFS, I get something like dumpfs: /dev/rdisk2s10: error reading cg dumpfs: /dev/rdisk2s10: Operation not supported by device at some point. Is that normal? > > Just a side note - I should have known Apple would deliver a system > > wherein it's EASY to build and install a kernel ;) > > You are welcome :-D :-D Well, I do appreciate it for the first shot, but I might eventually want to configure all sorts of things. This kind of stuff goes especially quik on Linux, since you can config ufs support modular, and not have to reboot (except for panics, of course). I promise to RTFM before I complain... The downside of the Apple Way is that sometimes WYSIWYG == WISIAYG... ---- Chris J. Bednar Director, Distributed Computing Product Group http://AdvancedDataSolutions.com/ ----------------------------- --- xnu-201-5/bsd/ufs/ffs/ffs_vfsops.c.filesize Fri Sep 7 17:52:44 2001 +++ xnu-201-5/bsd/ufs/ffs/ffs_vfsops.c Thu Dec 13 10:07:52 2001 @@ -329,7 +329,7 @@ struct buf *bp; struct fs *fs, *newfs; int i, blks, size, error; - u_int64_t maxfilesize; /* XXX */ + /*u_int64_t maxfilesize; XXX */ int32_t *lp; #if REV_ENDIAN_FS int rev_endian = (mountp->mnt_flag & MNT_REVEND); @@ -366,7 +366,7 @@ #endif /* REV_ENDIAN_FS */ brelse(bp); - return (EIO); /* XXX needs translation */ + /*return (EIO); XXX needs translation */ } fs = VFSTOUFS(mountp)->um_fs; /* @@ -385,10 +385,10 @@ #endif /* REV_ENDIAN_FS */ brelse(bp); mountp->mnt_maxsymlinklen = fs->fs_maxsymlinklen; - ffs_oldfscompat(fs); - maxfilesize = (u_int64_t)0x100000000; /* 4GB */ - if (fs->fs_maxfilesize > maxfilesize) /* XXX */ - fs->fs_maxfilesize = maxfilesize; /* XXX */ + /*ffs_oldfscompat(fs);*/ /*cjb - guess*/ + /*maxfilesize = (u_int64_t)0x100000000; 4GB */ + /*if (fs->fs_maxfilesize > maxfilesize) XXX */ + /* fs->fs_maxfilesize = maxfilesize; XXX */ /* * Step 3: re-read summary information from disk. */ @@ -501,7 +501,7 @@ int32_t *lp; struct ucred *cred; extern struct vnode *rootvp; - u_int64_t maxfilesize; /* XXX */ + /*u_int64_t maxfilesize; XXX */ u_int dbsize = DEV_BSIZE; #if REV_ENDIAN_FS int rev_endian=0; @@ -727,14 +727,14 @@ for (i = 0; i < MAXQUOTAS; i++) ump->um_quotas[i] = NULLVP; devvp->v_specflags |= SI_MOUNTEDON; - ffs_oldfscompat(fs); - ump->um_savedmaxfilesize = fs->fs_maxfilesize; /* XXX */ - maxfilesize = (u_int64_t)0x100000000; /* 4GB */ -#if 0 - maxfilesize = (u_int64_t)0x40000000 * fs->fs_bsize - 1; /* XXX */ + /*ffs_oldfscompat(fs);*/ /*cjb - guess*/ + /*ump->um_savedmaxfilesize = fs->fs_maxfilesize; XXX */ + /*maxfilesize = (u_int64_t)0x100000000; 4GB */ +#if 1 + fs->fs_maxfilesize = (u_int64_t)0x40000000 * fs->fs_bsize - 1; /* XXX */ #endif /* 0 */ - if (fs->fs_maxfilesize > maxfilesize) /* XXX */ - fs->fs_maxfilesize = maxfilesize; /* XXX */ + /*if (fs->fs_maxfilesize > maxfilesize) XXX */ + /* fs->fs_maxfilesize = maxfilesize; XXX */ if (ronly == 0) { fs->fs_clean = 0; (void) ffs_sbupdate(ump, MNT_WAIT); --- xnu-201-5/bsd/ufs/ufs/ufs_readwrite.c.filesize Wed Aug 1 16:00:35 2001 +++ xnu-201-5/bsd/ufs/ufs/ufs_readwrite.c Thu Dec 13 09:19:14 2001 @@ -419,7 +419,7 @@ ip->i_size = uio->uio_offset + xfersize; if (UBCISVALID(vp)) - ubc_setsize(vp, (u_long)ip->i_size); /* XXX check errors */ + ubc_setsize(vp, (off_t)ip->i_size); /* XXX check errors */ } size = BLKSIZE(fs, ip, lbn) - bp->b_resid;

1 0

Re: UFS not 64-bit clean?
by Umesh Vaishampayan 13 Dec '01

13 Dec '01

On Wednesday, December 12, 2001, at 09:52 AM, Chris Bednar wrote: On Tue, 11 Dec 2001, Umesh Vaishampayan wrote: ... Now that VM supports 64 bit data paths, the code above can be removed. But will it work... well, I went through this with Linux; maybe I'll try it again. Yes it will. The VM paths are well tested using HFS+. And UFS paths are tested in Rhapsody^W Mac OS X Server 1.0 and in early xnu. So I have reason to believe that "it should just work". It looks like something nasty may have crept into the code along the way. I attempted a patch, and the good news is that I seem (in at least the cases I've tried) to get the 'File too large' error now, but that is also the bad news. What does your patch look like? Well, it's bad news if it's coming from something like if (lbn < 0) return (EFBIG); You get this error when you do truncate(), right? at bsd/ufs/ffs/ffs_balloc.c:114, but maybe not so bad if it's coming from something like if (length > fs->fs_maxfilesize) return (EFBIG); in bsd/ufs/ffs/ffs_inode.c:209, if all that means is that the maxfilesize in the superblock is 4GB. I'll have to play with dumpfs later (I wonder why that doesn't work on a mounted FS?) Supply the characher device corresponding to your mounted file system to make it happy... Just a side note - I should have known Apple would deliver a system wherein it's EASY to build and install a kernel ;) You are welcome :-D :-D --Umesh -- Umesh Vaishampayan Apple Computer, Inc. Mac OS X Kernel Ph: (408) 974 0229

1 0

Re: UFS not 64-bit clean?
by Chris Bednar 12 Dec '01

12 Dec '01

On Tue, 11 Dec 2001, Umesh Vaishampayan wrote: > ... > > >> Now that VM supports 64 bit data paths, the code above can be removed. > > > > But will it work... well, I went through this with Linux; > > maybe I'll try it again. > > > > Yes it will. The VM paths are well tested using HFS+. And UFS paths are > tested in Rhapsody^W Mac OS X Server 1.0 and in early xnu. So I have > reason to believe that "it should just work". It looks like something nasty may have crept into the code along the way. I attempted a patch, and the good news is that I seem (in at least the cases I've tried) to get the 'File too large' error now, but that is also the bad news. Well, it's bad news if it's coming from something like if (lbn < 0) return (EFBIG); at bsd/ufs/ffs/ffs_balloc.c:114, but maybe not so bad if it's coming from something like if (length > fs->fs_maxfilesize) return (EFBIG); in bsd/ufs/ffs/ffs_inode.c:209, if all that means is that the maxfilesize in the superblock is 4GB. I'll have to play with dumpfs later (I wonder why that doesn't work on a mounted FS?) Just a side note - I should have known Apple would deliver a system wherein it's EASY to build and install a kernel ;) ---- Chris J. Bednar Director, Distributed Computing Product Group http://AdvancedDataSolutions.com/

1 0

Re: setproctitle?
by Kevin Van Vechten 12 Dec '01

12 Dec '01

It's a known issue (#1677744), though I don't know whether it will be eventually supported or not. -Kevin On Wednesday, December 12, 2001, at 06:47 AM, Rob Newberry wrote: The man page for setproctitle is there, but when I use this routine, I get a link error that it's undefined. Is it present in some library, or just missing from Mac OS X? If missing, is there an alternate API? Are there plans to bring this functionality to Mac OS X? Thanks a ton. Rob

1 0

setproctitle?
by Rob Newberry 12 Dec '01

12 Dec '01

The man page for setproctitle is there, but when I use this routine, I get a link error that it's undefined. Is it present in some library, or just missing from Mac OS X? If missing, is there an alternate API? Are there plans to bring this functionality to Mac OS X? Thanks a ton. Rob

1 0

status of tunnel device?
by Rob Newberry 12 Dec '01

12 Dec '01

I took a stab at porting some software that uses the BSD tunnel device. What's the status of this device in Mac OS X? Do I need to do anything special to access it? I don't see a /dev/tunX currently -- is there a runtime configuration I can change, or will I have to build a new kernel? Or do I just need to build a KEXT from somewhere? I see that the man page for tun is there... Rob

1 0

Re: UFS not 64-bit clean?
by Umesh Vaishampayan 12 Dec '01

12 Dec '01

On Tuesday, December 11, 2001, at 03:55 PM, Chris Bednar wrote: On Tue, 11 Dec 2001, Umesh Vaishampayan wrote: On Tuesday, December 11, 2001, at 10:31 AM, Chris Bednar wrote: I'm fooling with using UFS, and I notice that I get in trouble at the 4-gig limit. That's artificial limitation put in UFS few years ago when I implemented UBC. At that time the VM did not support 64 bit data paths. Hence anything above 4GB was not accessible. [Well, you could try to access it, but the offset would wrap and lead to interesting :-) data corruption]. Hence the following code was added: Thanks for the clear answer! (and thanks to Louis for his, too) I feel better and better about this OS... I might even try building a kernel. Good! Now that VM supports 64 bit data paths, the code above can be removed. But will it work... well, I went through this with Linux; maybe I'll try it again. Yes it will. The VM paths are well tested using HFS+. And UFS paths are tested in Rhapsody^W Mac OS X Server 1.0 and in early xnu. So I have reason to believe that "it should just work". Is the darwin UFS implementation not 64-bit clean? Yes it is. Well, it is, in the sense that it won't (necessarily) crash if there's a file over 4GB on the platter, but truncating the file size this way doesn't seem all that clean to me... If there is an existing file over 4GB, NO, we do not truncate silently. stat() should still return the size to you. bsd/ufs/ufs/ufs_vnops.c: 321 int 322 ufs_getattr(ap) 323 struct vop_getattr_args /* { 324 struct vnode *a_vp; 325 struct vattr *a_vap; 326 struct ucred *a_cred; 327 struct proc *a_p; 328 } */ *ap; 329 { 330 register struct vnode *vp = ap->a_vp; /* ... */ 346 vap->va_size = ip->i_din.di_size; What the artificial limit does is, it does not let you grow the file beyond the limit. It also prevents you from reading the file past 4GB. bsd/ufs/ffs/ffs_inode.c: 174 /* 175 * Truncate the inode oip to at most length size, freeing the 176 * disk blocks. 177 */ 178 ffs_truncate(ap) 179 struct vop_truncate_args /* { 180 struct vnode *a_vp; 181 off_t a_length; 182 int a_flags; 183 struct ucred *a_cred; 184 struct proc *a_p; 185 } */ *ap; 186 { 187 register struct vnode *ovp = ap->a_vp; /* ... */ 209 if (length > fs->fs_maxfilesize) 210 return (EFBIG); 211 bsd/ufs/ufs/ufs_readwrite.c: 70 ffs_read(ap) 71 struct vop_read_args /* { 72 struct vnode *a_vp; 73 struct uio *a_uio; 74 int a_ioflag; 75 struct ucred *a_cred; 76 } */ *ap; 77 { 78 register struct vnode *vp; /* ... */ 115 if (uio->uio_offset > fs->fs_maxfilesize) 116 return (EFBIG); 117 /* ... */ 198 ffs_write(ap) 199 struct vop_write_args /* { 200 struct vnode *a_vp; 201 struct uio *a_uio; 202 int a_ioflag; 203 struct ucred *a_cred; 204 } */ *ap; 205 { 206 register struct vnode *vp; /* ... */ 255 if (uio->uio_offset < 0 || 256 (u_int64_t)uio->uio_offset + uio->uio_resid > fs->fs_maxfilesize ) 257 return (EFBIG); I am not sure who is dropping the EFBIG on the floor... Any way, with a kernel with the fix for 2660080, you should be able to read that file of yours just fine. --Umesh -- Umesh Vaishampayan Apple Computer, Inc. Mac OS X Kernel Ph: (408) 974 0229

1 0