Re: Portable way to compare struct stat's?
Kelly Yancey wrote: > > Is there a portable method for determining if the contents of two struct > stat's are identical? On a single system, if st_dev and st_ino are equal, you must be referring to the same object. If not, I'd like to hear about it. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Portable way to compare struct stat's?
Is there a portable method for determining if the contents of two struct
stat's are identical? I believe there is not. The problem is that while
Posix defines a base set of fields for the stat structure, it appears that
most implementations (including FreeBSD's) extend the structure with
additional fields. Comparing all of the Posix fields will only determine
the relationship between the Posix subset of the structures.
My first inclination was to do a memcmp() which in theory should work
across all stat structure definitions. But being that my development box
runs FreeBSD, I quickly discovered that at least on FreeBSD, memcmp won't
work.
The reason? Because the FreeBSD struct stat defines 2 spare fields:
st_lspare and st_qspare. The kernel never initializes the values of these
fields when returning structures back to userland. So the values are more
or less random contents that were on the kernel stack.
Besides the possible security implications of passing random kernel
stack contents into userland (I am no security expert, so there may not be
any problem with this, it just doesn't seem right), there is the nasty
side effect the memcmp cannot be used to compare 2 stat structures for
equality.
I have made a small set of changes to my local kernel source which
addresses the problem by bzero'ing the struct stat memory in the kernel
before filling it (which ensures that the spare fields get reset to a
known state). I've attached the patches below (they need to be applied in
the /sys/kern directory).
So, back to my original question: is there a better way for comparing
stat structures? Or, should memcmp work on other platforms (as well as
FreeBSD given the attached patch)?
--
Kelly Yancey - [EMAIL PROTECTED] - Richmond, VA
Director of Technical Services, ALC Communications http://www.alcnet.com/
Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/
Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/
--- kern_descrip.c.orig Mon Nov 15 22:11:57 1999
+++ kern_descrip.c Mon Nov 15 22:27:43 1999
@@ -548,9 +548,11 @@
panic("ofstat");
/*NOTREACHED*/
}
- cvtstat(&ub, &oub);
- if (error == 0)
+ if (error == 0) {
+ bzero(&oub, sizeof (oub));
+ cvtstat(&ub, &oub);
error = copyout((caddr_t)&oub, (caddr_t)uap->sb, sizeof (oub));
+ }
return (error);
}
#endif /* COMPAT_43 || COMPAT_SUNOS */
@@ -578,6 +580,7 @@
if ((unsigned)uap->fd >= fdp->fd_nfiles ||
(fp = fdp->fd_ofiles[uap->fd]) == NULL)
return (EBADF);
+ bzero(&ub, sizeof (ub));
switch (fp->f_type) {
case DTYPE_FIFO:
@@ -646,6 +649,7 @@
/*NOTREACHED*/
}
if (error == 0) {
+ bzero(&nub, sizeof (nub));
cvtnstat(&ub, &nub);
error = copyout((caddr_t)&nub, (caddr_t)uap->sb, sizeof (nub));
}
--- vfs_syscalls.c.orig Mon Nov 15 23:25:48 1999
+++ vfs_syscalls.c Mon Nov 15 23:29:08 1999
@@ -1514,6 +1514,7 @@
vput(nd.ni_vp);
if (error)
return (error);
+ bzero(&osb, sizeof (osb));
cvtstat(&sb, &osb);
error = copyout((caddr_t)&osb, (caddr_t)SCARG(uap, ub), sizeof (osb));
return (error);
@@ -1552,6 +1553,7 @@
vput(vp);
if (error)
return (error);
+ bzero(&osb, sizeof (osb));
cvtstat(&sb, &osb);
error = copyout((caddr_t)&osb, (caddr_t)SCARG(uap, ub), sizeof (osb));
return (error);
@@ -1613,6 +1615,7 @@
SCARG(uap, path), p);
if (error = namei(&nd))
return (error);
+ bzero(&sb, sizeof (sb));
error = vn_stat(nd.ni_vp, &sb, p);
vput(nd.ni_vp);
if (error)
@@ -1648,6 +1651,7 @@
SCARG(uap, path), p);
if (error = namei(&nd))
return (error);
+ bzero(&sb, sizeof (sb));
vp = nd.ni_vp;
error = vn_stat(vp, &sb, p);
vput(vp);
@@ -1707,6 +1711,7 @@
vput(nd.ni_vp);
if (error)
return (error);
+ bzero(&nsb, sizeof (nsb));
cvtnstat(&sb, &nsb);
error = copyout((caddr_t)&nsb, (caddr_t)SCARG(uap, ub), sizeof (nsb));
return (error);
@@ -1745,6 +1750,7 @@
vput(vp);
if (error)
return (error);
+ bzero(&nsb, sizeof (nsb));
cvtnstat(&sb, &nsb);
error = copyout((caddr_t)&nsb, (caddr_t)SCARG(uap, ub), sizeof (nsb));
return (error);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
vmpfw in pine via NFS
I am noticing a large number of pine (and only pine) procs stuck in disk-wait. All of the are in the WCHAN "vmpfw". Any ideas what this may mean? -- David Cross | email: [EMAIL PROTECTED] Acting Lab Director | NYSLP: FREEBSD Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Support for USB floppies like Y-E Data FlashBuster-u ?
> Anyone working on such support yet ? This drive came with the Sony > Vaio Z505R. If you ask the 3 IDE disks and ethernet hub that have gone pop this weekend, they would say no, but myself I was pretty firm that I was going to do something about it this weekend. Bastard things, they should be shot and they will be. All is well now, so maybe this week, maybe next, top of the prioritised list in any case. And it would be great if by the time something is working I could count on a few people with machines that can boot from USB floppies to give me a hand in getting booting and installing on those machines to work. Cheers, Nick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Set the baud rate on remote debugging
Greg Lehey wrote... > On Monday, 15 November 1999 at 15:13:53 -0700, Kenneth D. Merry wrote: > > Zhihui Zhang wrote... > >> > >> I have set up a remote debugging environment. But I think default 9600 > >> bps is slow. I can use "set remotebaud 19200" on the debugging machine > >> side. How can I set the baud rate on the target machine that is running > >> the debugged kernel? (I press CTRL+ESC+ALT to drop to DDB mode and find > >> no command to set the baud rate). > >> > >> Any help is appreciated. > > > > Use the CONSPEED option in the kernel config file on the target machine. > > e.g.: > > > > options CONSPEED=115200 > > I'm planning to modify ddb to specify the bit rate as a parameter to > the gdb command: > > db> gdb 19200 > Next trap will enter GDB remote protocol mode at 19200 bps > > Comments? It might also be nice to have it tuneable as a kernel variable from the loader and a sysctl variable. Oh, I see it's already available as the 'machdep.conspeed' sysctl variable. Obviously, specifying the baud rate at the ddb prompt should override any previous baud rate setting. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Set the baud rate on remote debugging
On Mon, 15 Nov 1999, Greg Lehey wrote: > On Monday, 15 November 1999 at 15:13:53 -0700, Kenneth D. Merry wrote: > > Zhihui Zhang wrote... > >> > >> I have set up a remote debugging environment. But I think default 9600 > >> bps is slow. I can use "set remotebaud 19200" on the debugging machine > >> side. How can I set the baud rate on the target machine that is running > >> the debugged kernel? (I press CTRL+ESC+ALT to drop to DDB mode and find > >> no command to set the baud rate). > >> > >> Any help is appreciated. > > > > Use the CONSPEED option in the kernel config file on the target machine. > > e.g.: > > > > options CONSPEED=115200 > > I'm planning to modify ddb to specify the bit rate as a parameter to > the gdb command: > > db> gdb 19200 > Next trap will enter GDB remote protocol mode at 19200 bps > > Comments? > That will be useful. I have just found out that I can use sysctl -w machdep.conspeed=19200 to achieve this. But I can not go higher than 19200. -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Set the baud rate on remote debugging
On Monday, 15 November 1999 at 15:13:53 -0700, Kenneth D. Merry wrote: > Zhihui Zhang wrote... >> >> I have set up a remote debugging environment. But I think default 9600 >> bps is slow. I can use "set remotebaud 19200" on the debugging machine >> side. How can I set the baud rate on the target machine that is running >> the debugged kernel? (I press CTRL+ESC+ALT to drop to DDB mode and find >> no command to set the baud rate). >> >> Any help is appreciated. > > Use the CONSPEED option in the kernel config file on the target machine. > e.g.: > > options CONSPEED=115200 I'm planning to modify ddb to specify the bit rate as a parameter to the gdb command: db> gdb 19200 Next trap will enter GDB remote protocol mode at 19200 bps Comments? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel debug assistance?
On Monday, 15 November 1999 at 11:03:04 -0500, Thomas David Rivers wrote: > > I'm trying to track down a problem in 3.3-RELEASE > (which I _think_ might be a linux emu bug that's > crashing the kernel.) > > Anyway - I thought I might ask here for some > kernel debugging assistance... > > I've got a debuggable kernel, with DDB. > > When the panic occurs (which I can readily reproduce) > I drop down into DDB... > > Which is great - right? > > But - IP is 0x0 (or, sometimes 0x8000) - so the > trace command in DDB (to show the stack traceback) > doesn't seem to work - all I get is the Trap 12 message. That in itself doesn't mean you can't do a backtrace. I'm currently fighting this one: (kgdb) bt #0 0x0 in ?? () #1 0xc0184494 in spec_close (ap=0xc5f9de58) at ../../miscfs/specfs/spec_vnops.c:673 #2 0xc01f804e in ufsspec_close (ap=0xc5f9de58) at ../../ufs/ufs/ufs_vnops.c:1872 #3 0xc01f8521 in ufs_vnoperatespec (ap=0xc5f9de58) at ../../ufs/ufs/ufs_vnops.c:2317 (etc). > Does anyone have any sage words of advice on how to proceed with > tracking this down? At least some neat trick for determining where > the bad branch is taken? The real problem is that you have probably trashed your stack. I'd recommend using remote serial gdb; few people are happy with the level of support provided by ddb. Then you need to guess where it's happening, and set some breakpoints round likely places. It's not easy. The first thing to do would be to establish whether you're in process or interrupt context. If you're in a process context, you can at least find what process it is, and the macros in /usr/src/sys/modules/vinum/.gdbinit.kernel should help you determine what it's doing (sorry, the only documentation on these macros is the source code, including the gdb 'help user' command). Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Set the baud rate on remote debugging
Zhihui Zhang wrote... > > I have set up a remote debugging environment. But I think default 9600 > bps is slow. I can use "set remotebaud 19200" on the debugging machine > side. How can I set the baud rate on the target machine that is running > the debugged kernel? (I press CTRL+ESC+ALT to drop to DDB mode and find > no command to set the baud rate). > > Any help is appreciated. Use the CONSPEED option in the kernel config file on the target machine. e.g.: options CONSPEED=115200 Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Set the baud rate on remote debugging
I have set up a remote debugging environment. But I think default 9600 bps is slow. I can use "set remotebaud 19200" on the debugging machine side. How can I set the baud rate on the target machine that is running the debugged kernel? (I press CTRL+ESC+ALT to drop to DDB mode and find no command to set the baud rate). Any help is appreciated. -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Vnodes and Pathnames
Thanks for your response. Both you and Alfred have answered my questions. All I really needed was VDIR, since I can get to the filename from the process-context call to open. I thought I'd ask about VREG anyway. My search of the archives was fragged and I didn't find anything (I did upon restarting my browser. g). Dan On Mon, 15 Nov 1999, Julian Elischer wrote: > you can for VDIR as the getcwd call does so, but not for VREG becasue you > don't know the directory entry that you used to get to it. > (You could look in the name cache using a reverse lookup, but I don't know > that you are guaranteed of success.) PHK may have more to say on this > topic. > > > On Mon, 15 Nov 1999, Dan Seguin wrote: > > > > > > > Hello Gurus, > > > > > > Is there any way of getting filepath information from a vnode? What I'm > > looking for is pathname info for VDIR and VREG types, sort of a reverse > > namei(). > > > > Thanks! > > Dan Seguin Texar Software, Corporation. The trouble with doing something right the first time is that nobody appreciates how difficult it was. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Vnodes and Pathnames
you can for VDIR as the getcwd call does so, but not for VREG becasue you don't know the directory entry that you used to get to it. (You could look in the name cache using a reverse lookup, but I don't know that you are guaranteed of success.) PHK may have more to say on this topic. On Mon, 15 Nov 1999, Dan Seguin wrote: > > > Hello Gurus, > > > Is there any way of getting filepath information from a vnode? What I'm > looking for is pathname info for VDIR and VREG types, sort of a reverse > namei(). > > Thanks! > > > > > Dan SeguinTexar Software, Corporation. > > The trouble with doing something right the first time is that nobody > appreciates how difficult it was. > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Vnodes and Pathnames
On Mon, 15 Nov 1999, Dan Seguin wrote: > > > Hello Gurus, > > > Is there any way of getting filepath information from a vnode? What I'm > looking for is pathname info for VDIR and VREG types, sort of a reverse > namei(). It's really not possible since a file may have mutiple parent directories. There were some discussions on the lists in the last 30 days that went into greater detail. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Vnodes and Pathnames
Hello Gurus, Is there any way of getting filepath information from a vnode? What I'm looking for is pathname info for VDIR and VREG types, sort of a reverse namei(). Thanks! Dan Seguin Texar Software, Corporation. The trouble with doing something right the first time is that nobody appreciates how difficult it was. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
3.3-STABLE panic
I received the following panic() on our primary user fileserver. Note that
this is the first panic we have received in well over 80 days.
Below is a backtrace obtained from a kernel with debugging symbols:
IdlePTD 2977792
initial pcb at 264d38
panicstr: softdep_lock: locking against myself
panic messages:
---
panic: allocdirect_check: old 0 != new 1225576 || lbn 13 >= 12
syncing disks... panic: softdep_lock: locking against myself
dumping to dev 30001, offset 851968
dump 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69
68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40
39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11
10 9 8 7 6 5 4 3 2 1
---
#0 boot (howto=260) at ../../kern/kern_shutdown.c:285
285 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 boot (howto=260) at ../../kern/kern_shutdown.c:285
#1 0xc014f429 in panic (fmt=0xc023bd04 "softdep_lock: locking against myself")
at ../../kern/kern_shutdown.c:446
#2 0xc01dc3bd in acquire_lock (lk=0xc0258214)
at ../../ufs/ffs/ffs_softdep.c:266
#3 0xc01dfd71 in softdep_update_inodeblock (ip=0xc0d9ed00, bp=0xc2befa00,
waitfor=0) at ../../ufs/ffs/ffs_softdep.c:3447
#4 0xc01db40c in ffs_update (vp=0xc6700f40, waitfor=0)
at ../../ufs/ffs/ffs_inode.c:105
#5 0xc01e2e2c in ffs_sync (mp=0xc0cedc00, waitfor=2, cred=0xc0690300,
p=0xc027ce0c) at ../../ufs/ffs/ffs_vfsops.c:1001
#6 0xc0175ff7 in sync (p=0xc027ce0c, uap=0x0) at ../../kern/vfs_syscalls.c:549
#7 0xc014efd1 in boot (howto=256) at ../../kern/kern_shutdown.c:203
#8 0xc014f429 in panic (
fmt=0xc023c124 "allocdirect_check: old %d != new %d || lbn %ld >= %d")
at ../../kern/kern_shutdown.c:446
#9 0xc01dd373 in allocdirect_merge (adphead=0xc10761c4, newadp=0xc10b5980,
oldadp=0xc10bdb00) at ../../ufs/ffs/ffs_softdep.c:1238
#10 0xc01dff45 in merge_inode_lists (inodedep=0xc1076180)
at ../../ufs/ffs/ffs_softdep.c:3523
#11 0xc01dfe03 in softdep_update_inodeblock (ip=0xc0e31100, bp=0xc2c562b8,
waitfor=1) at ../../ufs/ffs/ffs_softdep.c:3471
#12 0xc01db40c in ffs_update (vp=0xc68ebd80, waitfor=1)
at ../../ufs/ffs/ffs_inode.c:105
#13 0xc01e40cb in ffs_write (ap=0xc6708c7c)
at ../../ufs/ufs/ufs_readwrite.c:508
#14 0xc01a8775 in nfsrv_write (nfsd=0xc1017100, slp=0xc0cf7300,
procp=0xc66beb20, mrq=0xc6708e34) at vnode_if.h:331
#15 0xc01be8a6 in nfssvc_nfsd (nsd=0xc6708e94, argp=0x8071f04 "", p=0xc66beb20)
at ../../nfs/nfs_syscalls.c:656
#16 0xc01be1c1 in nfssvc (p=0xc66beb20, uap=0xc6708f94)
at ../../nfs/nfs_syscalls.c:342
#17 0xc0213c0b in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = 8,
tf_esi = 0, tf_ebp = -1077944892, tf_isp = -965701660, tf_ebx = 0,
tf_edx = -1077945288, tf_ecx = 0, tf_eax = 155, tf_trapno = 12,
tf_err = 2, tf_eip = 134518972, tf_cs = 31, tf_eflags = 642,
tf_esp = -1077945280, tf_ss = 39}) at ../../i386/i386/trap.c:1100
#18 0xc0208e7c in Xint0x80_syscall ()
#19 0x80480e9 in ?? ()
--
David Cross | email: [EMAIL PROTECTED]
Acting Lab Director | NYSLP: FREEBSD
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself. | WinNT:Linux::Linux:FreeBSD
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: upcall
On Saturday, 13 November 1999 at 16:14:02 -0500, Clinton Xavier Berni wrote: > > Hello, > > How do I access a user level data structure from the kernel. In general, you don't, unless the user wants you to. > Are there any Upcalls that I could use? No. What are you trying to do? The only way to get data is to have it passed. You can then use copyin() to move it to the kernel. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Kernel debug assistance?
I'm trying to track down a problem in 3.3-RELEASE (which I _think_ might be a linux emu bug that's crashing the kernel.) Anyway - I thought I might ask here for some kernel debugging assistance... I've got a debuggable kernel, with DDB. When the panic occurs (which I can readily reproduce) I drop down into DDB... Which is great - right? But - IP is 0x0 (or, sometimes 0x8000) - so the trace command in DDB (to show the stack traceback) doesn't seem to work - all I get is the Trap 12 message. Does anyone have any sage words of advice on how to proceed with tracking this down? At least some neat trick for determining where the bad branch is taken? - Thanks - - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
