Re: dlsym() on implicit loaded symbols
On Sun, Jul 16, 2006 at 03:26:33PM +0200, Roland Dittel wrote:
Am 16.07.2006 um 14:33 schrieb Simon 'corecode' Schubert:
Roland Dittel wrote:
We have a issue with dlsym() on symbols imported by a library that
was loaded with dlopen(). Our code loads the libssl with dlopen()
and then do a dlsym() on several symbols. This works for all
symbols exported by libssl itself but fails for symbols exported by
libcrypto.
[..]
func = dlsym(handle, CRYPTO_set_id_callback);
you have to use RTLD_DEFAULT instead of handle, but I agree, this is
not in conformance with SUSv3:
That's it. Thank you very much.
Roland
The dlsym() function shall search for the named symbol in all
objects loaded automatically as a result of loading the object
referenced by handle (see dlopen()). Load ordering is used in dlsym()
operations upon the global symbol object. The symbol resolution
algorithm used shall be dependency order as described in dlopen().
The RTLD_DEFAULT and RTLD_NEXT flags are reserved for future use.
Note in all objects loaded automatically. Good catch!
Try this (against RELENG_6), patch for CURRENT needs some editing.
Index: rtld.c
===
RCS file: /usr/local/arch/ncvs/src/libexec/rtld-elf/rtld.c,v
retrieving revision 1.106.2.2
diff -u -r1.106.2.2 rtld.c
--- rtld.c 30 Dec 2005 22:13:56 - 1.106.2.2
+++ rtld.c 16 Jul 2006 18:05:39 -
@@ -123,7 +123,7 @@
static const Elf_Sym *symlook_default(const char *, unsigned long hash,
const Obj_Entry *refobj, const Obj_Entry **defobj_out, bool in_plt);
static const Elf_Sym *symlook_list(const char *, unsigned long,
- Objlist *, const Obj_Entry **, bool in_plt, DoneList *);
+ const Objlist *, const Obj_Entry **, bool in_plt, DoneList *);
static void trace_loaded_objects(Obj_Entry *obj);
static void unlink_object(Obj_Entry *);
static void unload_object(Obj_Entry *);
@@ -1805,25 +1805,22 @@
def = symlook_default(name, hash, obj, defobj, true);
}
} else {
+DoneList donelist;
+
if ((obj = dlcheck(handle)) == NULL) {
rlock_release(rtld_bind_lock, lockstate);
return NULL;
}
+ donelist_init(donelist);
if (obj-mainprog) {
- DoneList donelist;
/* Search main program and all libraries loaded by it. */
- donelist_init(donelist);
def = symlook_list(name, hash, list_main, defobj, true,
donelist);
} else {
- /*
-* XXX - This isn't correct. The search should include the whole
-* DAG rooted at the given object.
-*/
- def = symlook_obj(name, hash, obj, true);
- defobj = obj;
+ def = symlook_list(name, hash, (obj-dagmembers), defobj, true,
+ donelist);
}
}
@@ -2274,7 +2271,7 @@
}
static const Elf_Sym *
-symlook_list(const char *name, unsigned long hash, Objlist *objlist,
+symlook_list(const char *name, unsigned long hash, const Objlist *objlist,
const Obj_Entry **defobj_out, bool in_plt, DoneList *dlp)
{
const Elf_Sym *symp;
pgpmppDFtcE3r.pgp
Description: PGP signature
[RFT]: InFlight Mode Patch
Hi Folks, After receiving no feedback on -current, figured I'd send this to -hackers... probably should of in the first place. Please CC any comments as I'm not on the hackers list. - Hi All, Whilst looking on the FreeBSD projects page I noticed the 'InFlight' mode project. A patch is available at: http://www.clearchain.com/people/benjsc/download/20060712-inflight_mode.patch.gz Which implements a boot menu item, sysctl tunable (hw.inflight_mode) and prevents all wireless bluetooth drivers from attaching (probe succeeds still). Testing / comments welcome. Cheers, Benjamin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
[Fwd: Interrupts question]
No responses from [EMAIL PROTECTED] Anyone here understand what's going on? Thanks]. __ I was monitoring a machine with systat -vmstat and noticed something about the interrupts and I don't know if it's a problem or not. If it is a problem, is there anything I can do about it? The interrupts for the network interface (em0) on irq 64 exactly match those for a uhc device on irq 16. And the interrupts for the hardware raid (amr) on irq 46 exactly match those for a uhc device on irq 18. The machine is a Dell 2850 running 5.4. Relevant bits from the dmesg are: ioapic0: Changing APIC ID to 2 ioapic1: Changing APIC ID to 3 ioapic1: WARNING: intbase 32 != expected base 24 ioapic2: Changing APIC ID to 4 ioapic2: WARNING: intbase 64 != expected base 56 ioapic3: Changing APIC ID to 5 ioapic3: WARNING: intbase 96 != expected base 88 ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 32-55 on motherboard ioapic2 Version 2.0 irqs 64-87 on motherboard ioapic3 Version 2.0 irqs 96-119 on motherboard [...] amr0: LSILogic MegaRAID 1.51 mem 0xdfdc-0xdfdf,0xd80f-0xd80f irq 46 at device 14.0 on pci2 [...] em0: Intel(R) PRO/1000 Network Connection, Version - 1.7.35 port 0xecc0-0xecff mem 0xdfae-0xdfaf irq 64 at device 7.0 on pci6 [...] uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0xace0-0xacff irq 16 at device 29.0 on pci0 [...] uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0xaca0-0xacbf irq 18 at device 29.2 on pci0 [...] Turning off USB isn't an option as it's required for the pseudo-keyboard/mouse used by the DRAC. Here a sample of the interrupt section. The number of interrupts for [EMAIL PROTECTED]/[EMAIL PROTECTED] can easily be in the thousands rather than hundreds. Interrupts 1950 total 6: fdc0 128 8: rtc 13: npx 14: ata 450 16: uhc 409 18: uhc 19: uhc 23: ata 409 46: amr 450 64: em0 4 65: em1 106: ah 107: ah Any insight appreciated, --Alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
automatic KSE for multithreaded programs
Hello, the KSE system is complicated. Are there projects or possibilities to split automatically threads into groups given a SMP system in a clever manner ? Mathieu ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: automatic KSE for multithreaded programs
On Mon, 17 Jul 2006, Mathieu Prevot wrote: Hello, the KSE system is complicated. Are there projects or possibilities to split automatically threads into groups given a SMP system in a clever manner ? Not yet, that was one of the things on my TODO list and isn't really too difficult to allow depending on how you define clever (my definition is to allow the application to decide). -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Fwd: Interrupts question]
On Monday 17 July 2006 10:22, Alex Zbyslaw wrote: No responses from [EMAIL PROTECTED] Anyone here understand what's going on? Thanks]. __ I was monitoring a machine with systat -vmstat and noticed something about the interrupts and I don't know if it's a problem or not. If it is a problem, is there anything I can do about it? The interrupts for the network interface (em0) on irq 64 exactly match those for a uhc device on irq 16. And the interrupts for the hardware raid (amr) on irq 46 exactly match those for a uhc device on irq 18. The machine is a Dell 2850 running 5.4. Relevant bits from the dmesg are: FAQ. It's due to brain damage in the Intel PCIX hubs and can't be fixed directly. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Fwd: Interrupts question]
John Baldwin wrote: On Monday 17 July 2006 10:22, Alex Zbyslaw wrote: No responses from [EMAIL PROTECTED] Anyone here understand what's going on? Thanks]. __ I was monitoring a machine with systat -vmstat and noticed something about the interrupts and I don't know if it's a problem or not. If it is a problem, is there anything I can do about it? The interrupts for the network interface (em0) on irq 64 exactly match those for a uhc device on irq 16. And the interrupts for the hardware raid (amr) on irq 46 exactly match those for a uhc device on irq 18. The machine is a Dell 2850 running 5.4. Relevant bits from the dmesg are: FAQ. It's due to brain damage in the Intel PCIX hubs and can't be fixed directly. Thanks. I did search and couldn't find anything; guess I didn't search for the right thing :-( Any idea how much this might impact performance, especially of the disk? One thing I realised I missed from original dmesg was Interrupt storm detected on irq18: uhci2; throttling interrupt source which ties to the disk interrupt. Will that be slowing things down? Would increasing the storm threshold help (especially disk performance)? Guess I'm looking for any mitigation that might be possible. Thanks again, --Alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Fwd: Interrupts question]
On Monday 17 July 2006 12:41, Alex Zbyslaw wrote: John Baldwin wrote: On Monday 17 July 2006 10:22, Alex Zbyslaw wrote: No responses from [EMAIL PROTECTED] Anyone here understand what's going on? Thanks]. __ I was monitoring a machine with systat -vmstat and noticed something about the interrupts and I don't know if it's a problem or not. If it is a problem, is there anything I can do about it? The interrupts for the network interface (em0) on irq 64 exactly match those for a uhc device on irq 16. And the interrupts for the hardware raid (amr) on irq 46 exactly match those for a uhc device on irq 18. The machine is a Dell 2850 running 5.4. Relevant bits from the dmesg are: FAQ. It's due to brain damage in the Intel PCIX hubs and can't be fixed directly. Thanks. I did search and couldn't find anything; guess I didn't search for the right thing :-( Any idea how much this might impact performance, especially of the disk? One thing I realised I missed from original dmesg was Interrupt storm detected on irq18: uhci2; throttling interrupt source which ties to the disk interrupt. Will that be slowing things down? Would increasing the storm threshold help (especially disk performance)? Guess I'm looking for any mitigation that might be possible. Thanks again, There's no easy answer on this. You'll have to run your own benchmarks. If you don't need USB, then you may just want to leave it out of your kernel which might help some. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [RFT]: InFlight Mode Patch
Benjamin Close wrote: Hi Folks, After receiving no feedback on -current, figured I'd send this to -hackers... probably should of in the first place. Please CC any comments as I'm not on the hackers list. I initially thought this was a patch for the tcp_inflight packet window calcualtion code. I think relabelling it as Mode for FreeBSD when on an aeroplane (airplane) to catch people's attention. - Hi All, Whilst looking on the FreeBSD projects page I noticed the 'InFlight' mode project. A patch is available at: http://www.clearchain.com/people/benjsc/download/20060712-inflight_mode.patch.gz Which implements a boot menu item, sysctl tunable (hw.inflight_mode) and prevents all wireless bluetooth drivers from attaching (probe succeeds still). Testing / comments welcome. Cheers, Benjamin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
On the use of Tun interfaces.
The man pages of if_tun are out-of-date in some respects, but with comments from the group and reading the sources of ppp, I have worked around most of the problems I've found. However, I'm stuck with one quandry. My tunnel setup process produces the following: tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1500 inet6 fe80::214:22ff:fede:f175%tun0 prefixlen 64 scopeid 0x5 inet 192.168.12.2 -- 192.168.22.1 netmask 0x Opened by PID 86506 but then I ask: [3:14:[EMAIL PROTECTED]:~/devel/failsafe route get 192.168.22.1 route to: 192.168.22.1 destination: default mask: default gateway: strike1 interface: bge0 and indeed: [3:15:[EMAIL PROTECTED]:~/devel/failsafe netstat -rn Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire defaultxx.yy.zz.33UGS 0 1629642 bge0 xx.yy.zz.32/27 link#1 UC 00 bge0 xx.yy.zz.3300:80:c8:c9:22:31 UHLW2 16 bge0 1046 127.0.0.1 127.0.0.1 UH 0 4111852lo0 192.168.22.1 192.168.12.2 UH 00 tun0 shouldn't the last route there be active? Any clues here? Dave. -- |David Gilbert, Independent Contractor. | Two things can be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [RFT]: InFlight Mode Patch
On Mon, Jul 17, 2006 at 04:14:14PM +0930, Benjamin Close wrote: Which implements a boot menu item, sysctl tunable (hw.inflight_mode) and prevents all wireless bluetooth drivers from attaching (probe succeeds still). Attaching isn't the problem. The FAA and other international air authorities specifically disallow any transmitting of receiving. The only way you'll get this is by disabling the hardware itself. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
