Re: Order in which a driver attaches to devices
On Thursday, September 06, 2012 5:08:27 pm Navdeep Parhar wrote: > I have a system with multiple cards supported by cxgbe(4). When I build > a kernel with the driver compiled in, it attaches to the cards in a > different order from when it's loaded as a module. Why? The network > interfaces get re-ordered and this is quite annoying. H. The boot time probe does a depth first walk of the PCI bus. This is what is suggested by PCI-SIG for enumerating PCI buses (and is normally how BIOSs walk the bus assigning bus numbers). The walk that is done at kldload time walks the 'pciX' bus devices in numerical order (rather than walking the tree). I suspect your BIOS is doing something weird and assigning bus numbers in a non-depth first ordering so that the two orderings are not consisent as they are on other machines. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: analysing ia64 core dumps
On Thursday, September 06, 2012 4:57:31 am Anton Shterenlikht wrote: > I'm trying to debug firefox and related on ia64. > I was told in gecko@ to ask here about analysing core dumps. > > I rebuilt and reinstalled /usr/src/lib/libthr with > DEBUG_FLAGS='-g -O0' You don't need -O0, probably just -g. You should probably do this for libc as well I think. That might help your backtrace. What I tend to do for these btw is build debug shared libraries and use LD_LIBRARY_PATH to run my test program with those libraries rather than overwriting the main libraries in /lib. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: What happened to my /proc/curproc/file?
On Tuesday, September 04, 2012 7:46:23 pm Sam Varshavchik wrote:
> John Baldwin writes:
>
> > On Tuesday, September 04, 2012 7:10:42 am Sam Varshavchik wrote:
> > > Konstantin Belousov writes:
> > >
> > > > The procfs links, as well as any other user of vn_fullpath(9) function,
> > > > can only translate a vnode to path if namecache contains useful data.
> > > > As such, the facilities are not guaranteed to success all the time.
> > > >
> > > > In case of rmdir(2), UFS explicitely purges the cache for directory
> > > > which
> > > > contained direntry of the removed directory. I suspect that you have
> > > > your test program binary located in the same directory which was the
> > > > parent
> > > > of the removed one.
> > >
> > > Correct. Looks like the same thing applies if I try to use sysctl to get
> > > KERN_PROC_PATHNAME.
> > >
> > > I need some reliable way to get a process's executable file's name, as
> > > long
> > > as it's meaningful (the executable file hasn't been removed).
> >
> > There isn't one. What if the file is renamed, or what if it was executed
> > via
> > a symlink that has been removed?
>
> If the file is renamed, shouldn't its new name be known? If I give the
> file's supposed new name to realpath(3), its man page says I'll get back
> the equivalent absolute pathname. Works for me.
What if it was renamed by a different NFS client? :)
Also, files don't have backreferences to all their open file descriptors.
Even if they did they would have to have different sets for different paths.
That is a lot of overhead to maintain in the kernel, and it isn't maintained.
All the kernel effectively has internally is an i-node.
> And, I thought that the resolved pathname, in any case, would be the one
> after all the symlink resolution takes place, like /proc shows on Linux: if,
> say, I have /usr/local symlinked to /mnt/local-mnt,
> exec("/usr/local/bin/furgle") gives me a process that, according to /proc,
> is /mnt/local-mnt/bin/furgle.
That is what you would get by reverse-walking the name cache for
/proc/curproc/file as well.
> > The namecache bits are a best effort,
> >
> > but
> > if those are purged, the only approach are left with is a brute-force crawl
> >
> > of
> > the filesystem looking for a file whose stat() results match your
> > executable.
>
> Well, for logging purposes, after I get a client process's credentials
> passed through a domain socket, I was hoping to use the credentials' pid to
> log the process's executable name. At least that's the code that I'm porting
> is doing; but this is going to throw a big monkey wrench into the whole
> thing.
Do you need the whole path or just the command name? The command name is
stored in the kernel, and if you know the other process' pid you can fetch
that via kvm_getprocs().
> Is the dev+ino of what was exec()ed known, for another process? I might be
> able to get the client voluntarily submit its argv[0], then independently
> have the server validate it by stat()ing that, and comparing the result
> against what the kernel says the process's inode is.
It's known in the kernel certainly. I don't think we currently have any way
of exporting that info to userland however.
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: What happened to my /proc/curproc/file?
On Fri, Sep 07, 2012 at 10:33:52AM -0400, John Baldwin wrote: > On Tuesday, September 04, 2012 7:46:23 pm Sam Varshavchik wrote: > > Is the dev+ino of what was exec()ed known, for another process? I might be > > able to get the client voluntarily submit its argv[0], then independently > > have the server validate it by stat()ing that, and comparing the result > > against what the kernel says the process's inode is. > > It's known in the kernel certainly. I don't think we currently have any way > of exporting that info to userland however. It is, as KF_FD_TYPE_TEXT by sysctl kern.proc.filedesc. pgpjV72e1tcsj.pgp Description: PGP signature
Re: What happened to my /proc/curproc/file?
On Friday, September 07, 2012 11:59:36 am Konstantin Belousov wrote: > On Fri, Sep 07, 2012 at 10:33:52AM -0400, John Baldwin wrote: > > On Tuesday, September 04, 2012 7:46:23 pm Sam Varshavchik wrote: > > > Is the dev+ino of what was exec()ed known, for another process? I might > > > be > > > able to get the client voluntarily submit its argv[0], then independently > > > > > > have the server validate it by stat()ing that, and comparing the result > > > against what the kernel says the process's inode is. > > > > It's known in the kernel certainly. I don't think we currently have any way > > of exporting that info to userland however. > > It is, as KF_FD_TYPE_TEXT by sysctl kern.proc.filedesc. That doesn't include stat info though IIRC. You can get a pathname that is the same you would get from /proc/curproc/file (so it may fail and be empty), but you don't get st_dev or st_ino. I have thought that it might be useful for kinfo_file to include a full 'struct stat' and use the fo_stat() method of each file to fill it in, but that is not present currently. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: What happened to my /proc/curproc/file?
On Fri, Sep 07, 2012 at 12:23:54PM -0400, John Baldwin wrote: > On Friday, September 07, 2012 11:59:36 am Konstantin Belousov wrote: > > On Fri, Sep 07, 2012 at 10:33:52AM -0400, John Baldwin wrote: > > > On Tuesday, September 04, 2012 7:46:23 pm Sam Varshavchik wrote: > > > > Is the dev+ino of what was exec()ed known, for another process? I might > > > > be > > > > able to get the client voluntarily submit its argv[0], then > > > > independently > > > > have the server validate it by stat()ing that, and comparing the result > > > > > > > > against what the kernel says the process's inode is. > > > > > > It's known in the kernel certainly. I don't think we currently have any > > > way > > > of exporting that info to userland however. > > > > It is, as KF_FD_TYPE_TEXT by sysctl kern.proc.filedesc. > > That doesn't include stat info though IIRC. You can get a pathname that is > the same you would get from /proc/curproc/file (so it may fail and be empty), > but you don't get st_dev or st_ino. > > I have thought that it might be useful for kinfo_file to include a full > 'struct stat' and use the fo_stat() method of each file to fill it in, but > that is not present currently. ino is in kf_file_fileid, and rdev in kf_file_rdev. Also there is fsid in kf_file_fsid. pgpGXlmXql1Es.pgp Description: PGP signature
Re: What happened to my /proc/curproc/file?
On Friday, September 07, 2012 12:39:50 pm Konstantin Belousov wrote: > On Fri, Sep 07, 2012 at 12:23:54PM -0400, John Baldwin wrote: > > On Friday, September 07, 2012 11:59:36 am Konstantin Belousov wrote: > > > On Fri, Sep 07, 2012 at 10:33:52AM -0400, John Baldwin wrote: > > > > On Tuesday, September 04, 2012 7:46:23 pm Sam Varshavchik wrote: > > > > > Is the dev+ino of what was exec()ed known, for another process? I > > > > > might be > > > > > able to get the client voluntarily submit its argv[0], then > > > > > independently > > > > > have the server validate it by stat()ing that, and comparing the > > > > > result > > > > > against what the kernel says the process's inode is. > > > > > > > > It's known in the kernel certainly. I don't think we currently have > > > > any way > > > > of exporting that info to userland however. > > > > > > It is, as KF_FD_TYPE_TEXT by sysctl kern.proc.filedesc. > > > > That doesn't include stat info though IIRC. You can get a pathname that is > > the same you would get from /proc/curproc/file (so it may fail and be > > empty), > > but you don't get st_dev or st_ino. > > > > I have thought that it might be useful for kinfo_file to include a full > > 'struct stat' and use the fo_stat() method of each file to fill it in, but > > that is not present currently. > > ino is in kf_file_fileid, and rdev in kf_file_rdev. Also there is > fsid in kf_file_fsid. Oh, foo. I was looking at the 'o' variants. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
