Re: Switch to -fstack-protector-all by default
On Sat Sep 22 2012 00:03, Norman Golisz wrote: > On Sat Sep 15 2012 20:44, Norman Golisz wrote: > > On Wed Sep 12 2012 10:23, Matthew Dempsky wrote: > > > The diff below changes GCC's default behavior to -fstack-protector-all > > > (i.e., add stack protection code to every function instead of just > > > some based on heuristics), but you can still revert to the heuristic > > > behavior by passing -fstack-protector on the command line. > > > > [...] > > > > > You can now try building things as usual. > > > > I did a complete `make build` of src and xenocara without problems on > > i386. > > But not on my amd64 machine, unfortunately. I applied the diff to a clean > src checkout and compiled both GENERIC and GENERIC.MP. When booting the > system with either kernel, it panics and triggers the ddb. Please see > below for its output for `trace` and `ps`. Ah, I missed to add: when compiled with -fstack-protector, the kernel boots just fine.
Re: Switch to -fstack-protector-all by default
On Sat Sep 15 2012 20:44, Norman Golisz wrote: > On Wed Sep 12 2012 10:23, Matthew Dempsky wrote: > > The diff below changes GCC's default behavior to -fstack-protector-all > > (i.e., add stack protection code to every function instead of just > > some based on heuristics), but you can still revert to the heuristic > > behavior by passing -fstack-protector on the command line. > > [...] > > > You can now try building things as usual. > > I did a complete `make build` of src and xenocara without problems on > i386. But not on my amd64 machine, unfortunately. I applied the diff to a clean src checkout and compiled both GENERIC and GENERIC.MP. When booting the system with either kernel, it panics and triggers the ddb. Please see below for its output for `trace` and `ps`. ddb> trace Debugger() at Debugger+0x16 panic() at panic+0xf4 isadmaattach() at isadmaattach+0xa7 config_attach() at config_attach+0x1da isascan() at isascan+0x14c config_scan() at config_scan+0xca config_attach() at config_attach+0x1da pcib_callback() at pcib_callback+0x55 config_process_deferred_children() at config_process_deferred_children+0x73 config_attach() at config_attach+0x1e2 mainbus_attach() at mainbus_attach+0x171 config_attach() at config_attach+0x1da cpu_configure() at cpu_configure+0x28 main() at main+0x405 end trace frame: 0x0, count: -14 ddb> ps PID PPID PGRP UID S FLAGS WAIT COMMAND * 0 -10 0 7 0x200 swapper The full dmesg leading to the panic (this is with GENERIC.MP, but GENERIC looks exactly the same): OpenBSD 5.2-current (GENERIC.MP) #1: Fri Sep 21 22:20:29 CEST 2012 nor...@theos.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4182446080 (3988MB) avail mem = 4048654336 (3861MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (80 entries) bios0: vendor LENOVO version "7UET93WW (3.23 )" date 12/15/2011 bios0: LENOVO 6475BE3 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA DMAR SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) UART(S3) IGBE(S4) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) PCI1(S4) USB0(S3) USB3(S3) USB5(S3) EHC0(S3) EHC1(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz, 2261.36 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xT PR,PDCM,SSE4.1,NXE,LONG,LAHF cpu0: 3MB 64b/line 8-way L2 cache cpu0: apic clock running at 265MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz, 2261.00 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF cpu1: 3MB 64b/line 8-way L2 cache ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 2, remapped to apid 1 acpimcfg0 at acpi0 addr 0xe000, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (AGP_) acpiprt2 at acpi0: bus 2 (EXP0) acpiprt3 at acpi0: bus 3 (EXP1) acpiprt4 at acpi0: bus -1 (EXP2) acpiprt5 at acpi0: bus 5 (EXP3) acpiprt6 at acpi0: bus 13 (EXP4) acpiprt7 at acpi0: bus 21 (PCI1) acpicpu0 at acpi0: C3, C2, C1, PSS acpicpu1 at acpi0: C3, C2, C1, PSS acpipwrres0 at acpi0: PUBS acpitz0 at acpi0: critical temperature is 127 degC acpitz1 at acpi0: critical temperature is 100 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model "42T5264" serial 3499 type LION oem "Panasonic" acpibat1 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 acpidock0 at acpi0: GDCK docked (15) cpu0: Enhanced SpeedStep 2261 MHz: speeds: 2267, 2266, 1600, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x07 vga1 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) intagp0 at vga1 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0 at vga1: apic 1 int 16 drm0 at inteldrm0 "Intel GM45 Video" rev 0x07 at pci0 dev 2 function 1 not configured "Intel GM45 HECI" rev 0x07 at pci0 dev 3 function 0 not configured puc0 at pci0 dev 3 function 3 "Intel GM45 KT" rev 0x07: ports: 1 com com2 at puc0 port 0 apic 1 int 17: ns16550a, 16 byte fifo com2: probed fifo depth: 0 bytes em0 at pci0 dev 25 function 0 "Intel ICH9 IGP M AMT" rev 0x03: msi, address 00:1c:25:95:39:e7 uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x03: apic 1 int 20 uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x03: apic 1 int 21 uhci2 at pci0 dev 26 function 2 "Intel 82801I USB
Re: proto cksum madness
On 2012/09/20 20:16, Henning Brauer wrote: > I need your help testing. This diff has a kinda high breakage > potential, since there are quite a few output pathes. On the plus side > breakage is easy to spot, since that'll result in bad checksums and > thus these packets getting dropped. Should be all or none per given > output path. > > Just run it. You'll notice when your network connections fail. The > more obscure your setup, the better, basically. bridge, tunnels, you > name it. > > if you spot breakage, drop me a mail. if you don't, do so as well > please. I'm running this on my home firewall, my normal use is a mix of ipv4 and ipv6 over two pppoe(4) interfaces, some vlans, and light use of an etherip+ipsec bridge which is vlan->gif, sent large enough packets over it that frags are involved too. The physical interfaces behind all of this are vr(4). $ ifconfig vr0 hwfeatures|head -2 vr0: flags=8b43 mtu 1500 hwfeatures=8017 No problems noticed yet. (this is running i386). $ ifconfig vlan6 hwfeatures|head -2 vlan6: flags=8943 mtu 1500 hwfeatures=0<> Is it right/expected that CSUM_* aren't propagated to the vlan ifaces?
Mi propuesta para que vivas del multinivel en pocos meses, solo entraran 5 personas
*** Merci de lire ce courriel au format HTML ***
Re: remove mapstore
> Date: Fri, 21 Sep 2012 17:01:21 +0200 > From: Tobias Ulmer > > ping? The diff looks good to me, but I haven't had the oppurtunity to test it yet.
Re: Use ACPI to detect secondary PCI root segments on x86
> Date: Fri, 21 Sep 2012 13:48:48 +0200
> From: Christian Ehrhardt
>
> Hi,
>
> thanks to Mark, we have enough PCI bus number accounting, now to allow us
> to attach ACPI bus numbers via ACPI. A patch to do this is below.
>
> regards Christian
Hi Christian,
Any chance of having a diff with the amd64 bits as well?
Also:
> Index: arch/i386/i386/mainbus.c
> ===
> RCS file: /cvs/src/sys/arch/i386/i386/mainbus.c,v
> retrieving revision 1.49
> diff -u -r1.49 mainbus.c
> --- arch/i386/i386/mainbus.c 19 Sep 2012 23:03:12 - 1.49
> +++ arch/i386/i386/mainbus.c 21 Sep 2012 11:36:59 -
> @@ -245,6 +245,9 @@
> mba.mba_pba.pba_domain = pci_ndomains++;
> mba.mba_pba.pba_bus = 0;
> config_found(self, &mba.mba_pba, mainbus_print);
> +#if NACPI > 0
> + acpi_pciroots_attach(self, &mba.mba_pba, mainbus_print);
> +#endif
> }
> #endif
>
> Index: dev/acpi/acpi.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
> retrieving revision 1.239
> diff -u -r1.239 acpi.c
> --- dev/acpi/acpi.c 7 Sep 2012 19:19:59 - 1.239
> +++ dev/acpi/acpi.c 21 Sep 2012 11:37:01 -
> @@ -394,6 +394,8 @@
>
> TAILQ_HEAD(, acpi_pci) acpi_pcidevs =
> TAILQ_HEAD_INITIALIZER(acpi_pcidevs);
> +TAILQ_HEAD(, acpi_pci) acpi_pcirootdevs =
> +TAILQ_HEAD_INITIALIZER(acpi_pcirootdevs);
>
> int acpi_getpci(struct aml_node *node, void *arg);
> int acpi_getminbus(union acpi_resource *crs, void *arg);
> @@ -482,6 +484,7 @@
> node->pci = pci;
> dnprintf(10, "found PCI root: %s %d\n",
> aml_nodename(node), pci->bus);
> + TAILQ_INSERT_TAIL(&acpi_pcirootdevs, pci, next);
> }
> aml_freevalue(&res);
> return 0;
> @@ -600,6 +603,25 @@
> }
>
> return PCI_PMCSR_STATE_D3;
> +}
> +
> +void
> +acpi_pciroots_attach(struct device *dev, void *aux, cfprint_t pr)
> +{
> + struct acpi_pci *pdev;
> + struct pcibus_attach_args *pba = aux;
> +
> + if (pba->pba_busex == NULL) {
> + printf("cannot attach ACPI discovered busses\n");
> + return;
> + }
Instead of doing a printf here, I think you should just do a
KASSERT(pba->pba_busex != NULL);
here. If somebody changes the code such that they call
acpi_pciroots_attach() without having initialized the busex they
deserve to get a panic!
Habilidades Gerenciales de Alto Impacto
Curso Ejecutivo Internacional Habilidades Gerenciales de Alto ImPACTO Panama 10-12 de Octubre de 2012 Sheraton Panama Hotel & Convention Center QUALITY TRAINING, presenta un extraordinario seminario que se llevará a cabo en la ciudad de Panamá ¡No se pierda uno de los eventos más interesantes en el mundo gerencial actual! El éxito de su organización descansa sobre sus hombros... - Cómo responder a la presión abrumadora y a los problemas aparentemente insuperables con confianza y serenidad. - Deje de preocuparse sobre qué camino de acción seguir Tome las decisiones del negocio de manera más rápida y efectiva. - Dirija con la confianza, el valor y la convicción que inspira a sus colaboradores a dar su mayor esfuerzo. - Identifique y elimine las barreras de la productividad. - Cómo reconocer los puntoso débiles en su personal y saber con seguridad cuándo dejar que las personas se vayan. - Reenfoque las prioridades sobre los asuntos que son más importantes y cambie direcciones rápidamente si es necesario. - ¡Aprenda a negociar para GANAR! - Cómo hacer de su empresa una organización donde el cambio, el aprendizaje y la evolución del individuo sean las bases de una organización virtuosa. - Desarrolle habilidades para comunicarse con dinamismo y poder. - Comuníquese con tacto, profesionalismo y diplomacia hasta en los más desafiantes momentos. ¡¡ Un encuentro único que usted no puede dejar pasar!! Adquiera la información completa y sin compromiso, solo responda este correo con asunto -Deseo Folleto Gerentes o Comuníquese al (507) 279-1083 / 279-0258 / 279-0887 - y a la brevedad lo recibirá! ESTE CORREO NO PUEDE SER CONSIDERADO INTRUSIVO YA QUE CUMPLE CON LAS POLÍTICAS ANTISPAM INTERNACIONALES Y LOCALES: Responda este correo con el Asunto borrar y automáticamente quedará fuera de nuestras listas. Este correo ha sido enviado a: tech@openbsd.org
Re: remove mapstore
ping?
Re: hook-up acpi locking
On Wed Sep 19 2012 00:22, Paul Irofti wrote: > Any reason we have this disabled? > I ran with this diff in for quite some time w/o any problems. > Can you test this and let me know if anything bad happens? My Thinkpad runs stable so far, everything still seems to work fine (suspending to RAM also). OpenBSD 5.2-current (GENERIC.MP) #2: Thu Sep 20 22:35:13 CEST 2012 nor...@theos.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4182446080 (3988MB) avail mem = 4048658432 (3861MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (80 entries) bios0: vendor LENOVO version "7UET93WW (3.23 )" date 12/15/2011 bios0: LENOVO 6475BE3 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA DMAR SSDT SSDT SSDT uhub3 at usb3 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb4 at uhci2: USB revision 1.0 uhub4 at usb4 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb5 at uhci3: USB revision 1.0 uhub5 at usb5 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb6 at uhci4: USB revision 1.0 uhub6 at usb6 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb7 at uhci5: USB revision 1.0 uhub7 at usb7 "Intel UHCI root hub" rev 1.00/1.00 addr 1 isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) pckbc0: using irq 12 for aux slot wsmouse0 at pms0 mux 0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 aps0 at isa0 port 0x1600/31 mtrr: Pentium Pro MTRR support umass0 at uhub0 port 1 configuration 1 interface 0 "TOSHIBA TransMemory" rev 2.00/1.00 addr 2 umass0: using SCSI over Bulk-Only scsibus1 at umass0: 2 targets, initiator 0 sd1 at scsibus1 targ 1 lun 0: SCSI2 0/direct removable serial.09306544C940942403F1 sd1: 7643MB, 512 bytes/sector, 15654848 sectors uhub8 at uhub0 port 5 "IBM product 0x4485" rev 2.00/0.01 addr 3 uhidev0 at uhub8 port 1 configuration 1 interface 0 "Logitech USB Receiver" rev 1.10/30.07 addr 4 uhidev0: iclass 3/1 ukbd0 at uhidev0: 8 variable keys, 6 key codes wskbd1 at ukbd0 mux 1 wskbd1: connecting to wsdisplay0 uhidev1 at uhub8 port 1 configuration 1 interface 1 "Logitech USB Receiver" rev 1.10/30.07 addr 4 uhidev1: iclass 3/1, 4 report ids ums0 at uhidev1 reportid 1: 16 buttons, Z dir wsmouse1 at ums0 mux 0 uhid0 at uhidev1 reportid 2: input=2, output=0, feature=0 uhid1 at uhidev1 reportid 3: input=1, output=0, feature=0 uhid2 at uhidev1 reportid 4: input=3, output=0, feature=0 uhidev2 at uhub8 port 3 configuration 1 interface 0 "Avago USB Optical Mouse" rev 2.00/2.00 addr 5 uhidev2: iclass 3/1 ums1 at uhidev2: 3 buttons, Z dir wsmouse2 at ums1 mux 0 ugen0 at uhub3 port 1 "AuthenTec Fingerprint Sensor" rev 2.00/17.03 addr 2 vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets softraid0: sd2 was not shutdown properly sd2 at scsibus3 targ 1 lun 0: SCSI2 0/direct fixed sd2: 74790MB, 512 bytes/sector, 153171136 sectors root on sd2a (df2030acdc6bfd3c.a) swap on sd2b dump on sd2b ugen0 detached ugen0 at uhub3 port 1 "AuthenTec Fingerprint Sensor" rev 2.00/17.03 addr 2 ugen0 detached ugen0 at uhub3 port 1 "AuthenTec Fingerprint Sensor" rev 2.00/17.03 addr 2
Re: Use ACPI to detect secondary PCI root segments on x86
Hi,
thanks to Mark, we have enough PCI bus number accounting, now to allow us
to attach ACPI bus numbers via ACPI. A patch to do this is below.
regards Christian
Index: arch/i386/i386/mainbus.c
===
RCS file: /cvs/src/sys/arch/i386/i386/mainbus.c,v
retrieving revision 1.49
diff -u -r1.49 mainbus.c
--- arch/i386/i386/mainbus.c19 Sep 2012 23:03:12 - 1.49
+++ arch/i386/i386/mainbus.c21 Sep 2012 11:36:59 -
@@ -245,6 +245,9 @@
mba.mba_pba.pba_domain = pci_ndomains++;
mba.mba_pba.pba_bus = 0;
config_found(self, &mba.mba_pba, mainbus_print);
+#if NACPI > 0
+ acpi_pciroots_attach(self, &mba.mba_pba, mainbus_print);
+#endif
}
#endif
Index: dev/acpi/acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.239
diff -u -r1.239 acpi.c
--- dev/acpi/acpi.c 7 Sep 2012 19:19:59 - 1.239
+++ dev/acpi/acpi.c 21 Sep 2012 11:37:01 -
@@ -394,6 +394,8 @@
TAILQ_HEAD(, acpi_pci) acpi_pcidevs =
TAILQ_HEAD_INITIALIZER(acpi_pcidevs);
+TAILQ_HEAD(, acpi_pci) acpi_pcirootdevs =
+TAILQ_HEAD_INITIALIZER(acpi_pcirootdevs);
int acpi_getpci(struct aml_node *node, void *arg);
int acpi_getminbus(union acpi_resource *crs, void *arg);
@@ -482,6 +484,7 @@
node->pci = pci;
dnprintf(10, "found PCI root: %s %d\n",
aml_nodename(node), pci->bus);
+ TAILQ_INSERT_TAIL(&acpi_pcirootdevs, pci, next);
}
aml_freevalue(&res);
return 0;
@@ -600,6 +603,25 @@
}
return PCI_PMCSR_STATE_D3;
+}
+
+void
+acpi_pciroots_attach(struct device *dev, void *aux, cfprint_t pr)
+{
+ struct acpi_pci *pdev;
+ struct pcibus_attach_args *pba = aux;
+
+ if (pba->pba_busex == NULL) {
+ printf("cannot attach ACPI discovered busses\n");
+ return;
+ }
+ TAILQ_FOREACH(pdev, &acpi_pcirootdevs, next) {
+ if (extent_alloc_region(pba->pba_busex, pdev->bus,
+ 1, EX_NOWAIT) != 0)
+ continue;
+ pba->pba_bus = pdev->bus;
+ config_found(dev, pba, pr);
+ }
}
void
Index: dev/acpi/acpivar.h
===
RCS file: /cvs/src/sys/dev/acpi/acpivar.h,v
retrieving revision 1.72
diff -u -r1.72 acpivar.h
--- dev/acpi/acpivar.h 7 Sep 2012 19:19:59 - 1.72
+++ dev/acpi/acpivar.h 21 Sep 2012 11:37:01 -
@@ -323,6 +323,8 @@
void acpi_powerdown_task(void *, int);
void acpi_sleep_task(void *, int);
+void acpi_pciroots_attach(struct device *, void *, cfprint_t);
+
#endif
#endif /* !_ACPI_WAKECODE */
Re: Fix for sftp(1) tab-complete
On Tue, Sep 11, 2012 at 11:27 AM, Jean-Marc Robert wrote: > This is a diff that should fix a few issues I've encountered with sftp's > tab-complete, and a few others that I found in the process. Thanks, these have been committed (with some mild style adjustment). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
Re: 32-bit ucas on amd64
> Date: Wed, 19 Sep 2012 15:41:09 +0300
> From: Paul Irofti
>
> I need this for acpi locking, okay?
>
> (I'd also like to get rid of the silly x86_* prefix to match the i386
> function name, but that's a different topic)
I disagree with the off-topic bit. What we do need is a consistent
set of atomic operations across platforms. Haphazardly adding stuff
to match the local MD naming conventions isn't going to help.
And there is another issue in this case. The i386 version does the
whole PCB_FAULT dance, whereas this version doesn't. So I think the
#define atomic_ucas_32 ucas_32
that was added (by you) is a mistake.
> Index: arch/amd64/include/atomic.h
> ===
> RCS file: /cvs/src/sys/arch/amd64/include/atomic.h,v
> retrieving revision 1.8
> diff -u -p -r1.8 atomic.h
> --- arch/amd64/include/atomic.h 23 Mar 2011 16:54:34 - 1.8
> +++ arch/amd64/include/atomic.h 19 Sep 2012 12:38:31 -
> @@ -90,6 +90,17 @@ x86_atomic_clearbits_u32(volatile u_int3
> __asm __volatile(LOCK " andl %1,%0" : "=m" (*ptr) : "ir" (~bits));
> }
>
> +static __inline int
> +x86_atomic_ucas_32(volatile uint32_t *ptr, uint32_t expect, uint32_t set)
> +{
> + u_long res;
> +
> + __asm volatile(LOCK " cmpxchgl %2, %1" : "=a" (res), "=m" (*ptr)
> + : "r" (set), "a" (expect), "m" (*ptr) : "memory");
> +
> + return (res);
> +}
> +
> static __inline u_long
> x86_atomic_cas_ul(volatile u_long *ptr, u_long expect, u_long set)
> {
Threads related SIGSEGV in random.c (diff, v2)
On Fri, Sep 21, 2012 at 10:36 AM, Alexey Suslikov
wrote:
> On Wed, Sep 19, 2012 at 10:24 PM, Ted Unangst wrote:
>> On Wed, Sep 19, 2012 at 18:50, Alexey Suslikov wrote:
>>> On Wednesday, September 19, 2012, Theo de Raadt wrote:
>>>
> arc4random() is also thread-safe (it has interal locking) and very
> desirable for other reasons. But no way to save state.
The last part of this is intentional. Saving the state of pseudo
random number generators is a stupid concept from the 80's.
>>>
>>> I see many rng functions behaving very differently. Is it a good idea
>>> to create a common locking layer on top of need-to-be-safe rng
>>> functions? Or we should deal only with original problem (and only
>>> port random.c code from netbsd)?
>>
>> just slap a mutex around it.
>
> With the diff below Kannel no longer crashes. Only protecting random()
> for now.
>
> Make random() thread-safe by surrounding real call with a mutex locking.
> Found by and diff from Roman Kravchuk. Mainly from NetBSD.
Sorry. Here is correct diff.
We kinda unsure about the approach. For now, we follow arc4random pattern.
Should we use generic _thread_mutex_lock/_thread_mutex_unlock instead?
Index: lib/libc/include/thread_private.h
===
RCS file: /cvs/src/lib/libc/include/thread_private.h,v
retrieving revision 1.25
diff -u -p -r1.25 thread_private.h
--- lib/libc/include/thread_private.h 16 Oct 2011 06:29:56 - 1.25
+++ lib/libc/include/thread_private.h 21 Sep 2012 07:59:34 -
@@ -172,4 +172,16 @@ void _thread_arc4_unlock(void);
_thread_arc4_unlock();\
} while (0)
+void _thread_random_lock(void);
+void _thread_random_unlock(void);
+
+#define _RANDOM_LOCK() do {\
+ if (__isthreaded) \
+ _thread_random_lock(); \
+ } while (0)
+#define _RANDOM_UNLOCK() do {\
+ if (__isthreaded) \
+ _thread_random_unlock();\
+ } while (0)
+
#endif /* _THREAD_PRIVATE_H_ */
Index: lib/libc/stdlib/random.c
===
RCS file: /cvs/src/lib/libc/stdlib/random.c,v
retrieving revision 1.17
diff -u -p -r1.17 random.c
--- lib/libc/stdlib/random.c1 Jun 2012 01:01:57 - 1.17
+++ lib/libc/stdlib/random.c21 Sep 2012 07:59:35 -
@@ -35,6 +35,7 @@
#include
#include
#include
+#include "thread_private.h"
/*
* random.c:
@@ -376,21 +377,38 @@ setstate(char *arg_state)
*
* Returns a 31-bit random number.
*/
-long
-random(void)
+static long
+random_unlocked(void)
{
int32_t i;
+ int32_t *f, *r;
if (rand_type == TYPE_0)
i = state[0] = (state[0] * 1103515245 + 12345) & 0x7fff;
else {
- *fptr += *rptr;
- i = (*fptr >> 1) & 0x7fff; /* chucking least random bit */
- if (++fptr >= end_ptr) {
- fptr = state;
- ++rptr;
- } else if (++rptr >= end_ptr)
- rptr = state;
+ /*
+* Use local variables rather than static variables for speed.
+*/
+ f = fptr; r = rptr;
+ *f += *r;
+ i = (*f >> 1) & 0x7fff; /* chucking least random bit */
+ if (++f >= end_ptr) {
+ f = state;
+ ++r;
+ } else if (++r >= end_ptr)
+ r = state;
+ fptr = f; rptr = r;
}
return((long)i);
+}
+
+long
+random(void)
+{
+ long r;
+
+ _RANDOM_LOCK();
+ r = random_unlocked();
+ _RANDOM_UNLOCK();
+ return (r);
}
Index: lib/libc/thread/unithread_malloc_lock.c
===
RCS file: /cvs/src/lib/libc/thread/unithread_malloc_lock.c,v
retrieving revision 1.8
diff -u -p -r1.8 unithread_malloc_lock.c
--- lib/libc/thread/unithread_malloc_lock.c 13 Jun 2008 21:18:43 -
1.8
+++ lib/libc/thread/unithread_malloc_lock.c 21 Sep 2012 07:59:35 -
@@ -21,6 +21,12 @@ WEAK_PROTOTYPE(_thread_arc4_unlock);
WEAK_ALIAS(_thread_arc4_lock);
WEAK_ALIAS(_thread_arc4_unlock);
+WEAK_PROTOTYPE(_thread_random_lock);
+WEAK_PROTOTYPE(_thread_random_unlock);
+
+WEAK_ALIAS(_thread_random_lock);
+WEAK_ALIAS(_thread_random_unlock);
+
void
WEAK_NAME(_thread_malloc_lock)(void)
{
@@ -53,6 +59,18 @@ WEAK_NAME(_thread_arc4_lock)(void)
void
WEAK_NAME(_thread_arc4_unlock)(void)
+{
+ return;
+}
+
+void
+WEAK_NAME(_thread_random_lock)(void)
+{
+
Re: Threads related SIGSEGV in random.c
On Wed, Sep 19, 2012 at 10:24 PM, Ted Unangst wrote:
> On Wed, Sep 19, 2012 at 18:50, Alexey Suslikov wrote:
>> On Wednesday, September 19, 2012, Theo de Raadt wrote:
>>
>>> > arc4random() is also thread-safe (it has interal locking) and very
>>> > desirable for other reasons. But no way to save state.
>>>
>>> The last part of this is intentional. Saving the state of pseudo
>>> random number generators is a stupid concept from the 80's.
>>>
>>
>> I see many rng functions behaving very differently. Is it a good idea
>> to create a common locking layer on top of need-to-be-safe rng
>> functions? Or we should deal only with original problem (and only
>> port random.c code from netbsd)?
>
> just slap a mutex around it.
With the diff below Kannel no longer crashes. Only protecting random()
for now.
Make random() thread-safe by surrounding real call with a mutex locking.
Found by and diff from Roman Kravchuk. Mainly from NetBSD.
Index: include/thread_private.h
===
RCS file: /cvs/src/lib/libc/include/thread_private.h,v
retrieving revision 1.25
diff -u -p -r1.25 thread_private.h
--- include/thread_private.h16 Oct 2011 06:29:56 - 1.25
+++ include/thread_private.h20 Sep 2012 22:10:49 -
@@ -172,4 +172,16 @@ void _thread_arc4_unlock(void);
_thread_arc4_unlock();\
} while (0)
+void _thread_random_lock(void);
+void _thread_random_unlock(void);
+
+#define _RANDOM_LOCK() do {\
+ if (__isthreaded) \
+ _thread_random_lock(); \
+ } while (0)
+#define _RANDOM_UNLOCK() do {\
+ if (__isthreaded) \
+ _thread_random_unlock();\
+ } while (0)
+
#endif /* _THREAD_PRIVATE_H_ */
Index: stdlib/random.c
===
RCS file: /cvs/src/lib/libc/stdlib/random.c,v
retrieving revision 1.17
diff -u -p -r1.17 random.c
--- stdlib/random.c 1 Jun 2012 01:01:57 - 1.17
+++ stdlib/random.c 20 Sep 2012 22:10:50 -
@@ -35,6 +35,7 @@
#include
#include
#include
+#include "thread_private.h"
/*
* random.c:
@@ -376,21 +377,38 @@ setstate(char *arg_state)
*
* Returns a 31-bit random number.
*/
-long
-random(void)
+static long
+random_unlocked(void)
{
int32_t i;
+ int32_t *f, *r;
if (rand_type == TYPE_0)
i = state[0] = (state[0] * 1103515245 + 12345) & 0x7fff;
else {
- *fptr += *rptr;
- i = (*fptr >> 1) & 0x7fff; /* chucking least random bit */
- if (++fptr >= end_ptr) {
- fptr = state;
- ++rptr;
- } else if (++rptr >= end_ptr)
- rptr = state;
+ /*
+* Use local variables rather than static variables for speed.
+*/
+ f = fptr; r = rptr;
+ *f += *r;
+ i = (*f >> 1) & 0x7fff; /* chucking least random bit */
+ if (++f >= end_ptr) {
+ f = state;
+ ++r;
+ } else if (++r >= end_ptr)
+ r = state;
+ fptr = f; rptr = r;
}
return((long)i);
+}
+
+long
+random(void)
+{
+ long r;
+
+ _RANDOM_LOCK();
+ r = random_unlocked();
+ _RANDOM_UNLOCK();
+ return (r);
}
Index: thread/unithread_malloc_lock.c
===
RCS file: /cvs/src/lib/libc/thread/unithread_malloc_lock.c,v
retrieving revision 1.8
diff -u -p -r1.8 unithread_malloc_lock.c
--- thread/unithread_malloc_lock.c 13 Jun 2008 21:18:43 - 1.8
+++ thread/unithread_malloc_lock.c 20 Sep 2012 22:10:50 -
@@ -21,6 +21,12 @@ WEAK_PROTOTYPE(_thread_arc4_unlock);
WEAK_ALIAS(_thread_arc4_lock);
WEAK_ALIAS(_thread_arc4_unlock);
+WEAK_PROTOTYPE(_thread_random_lock);
+WEAK_PROTOTYPE(_thread_random_unlock);
+
+WEAK_ALIAS(_thread_random_lock);
+WEAK_ALIAS(_thread_random_unlock);
+
void
WEAK_NAME(_thread_malloc_lock)(void)
{
@@ -53,6 +59,18 @@ WEAK_NAME(_thread_arc4_lock)(void)
void
WEAK_NAME(_thread_arc4_unlock)(void)
+{
+ return;
+}
+
+void
+WEAK_NAME(_thread_random_lock)(void)
+{
+ return;
+}
+
+void
+WEAK_NAME(_thread_random_unlock)(void)
{
return;
}
