Campamentos Científicos para docentes y alumnos
OBSERVATORIO ASTRONOMICO AMPIMPA TUCUMAN - ARGENTINA Declarado de Interis Educativo por el Ministerio de Educacisn de la Nacisn _ tech@openbsd.org At. Campamentos Cientmficos 2012/2013 - Aqos del Maximo Solar - Docetes Campamentos Cientmficos exclusivos para Docentes La ciencia en el Aula. Nuevos enfoques didacticos 22 al 25 de Junio de 2012 (haga click para ver mayor informacisn) http://www.astrotuc.com.ar/Paginas/noticia.asp?id=145p=1 17 al 20 de Agosto de 2012 (haga Click para ver mayor informacisn) http://www.skytuc.com.ar/Paginas/noticia.asp?id=157p=1 (Ver aqum imagenes de campamentos docentes anteriores) http://www.astrotuc.com.ar/Paginas/img_campdoc.htm Presentacisn Tambiin: talleres http://www.astrotuc.com.ar/temp/BANNER%20CAMPAMENTOS%20OBSERVATORIO%20t allereslr.jpg Campamentos Cientmficos Educativos para grupos de alumnos Organice campamentos cientmficos con los alumnos de su Colegio/Escuela. Participe con ellos de esta experiencia Cohetes http://www.astrotuc.com.ar/temp/BANNER%20CAMPAMENTOS%20OBSERVATORIO%20c ohetes%20lr.jpg educativa znica. Ver aqum imagenes de Campamentos con Alumnos http://www.astrotuc.com.ar/Paginas/campamentos_esc.htm Ver Aqum Noticias en la Prensa: Pagina 1 http://www.skytuc.com.ar/temp/plano4lra.gif Pagina 2 http://www.skytuc.com.ar/temp/plano2lra.gif Ya se pueden reservar fechas del 2012 y 2013 !!! (Fechas y cupos limitados) Geologma http://www.astrotuc.com.ar/temp/BANNER%20CAMPAMENTOS%20OBSERVATORIO%20c aminatas%20lr.jpg Para ver mayor informacisn y/o consultas sobre campamentos con alumnos, haga click aqum http://www.astrotuc.com.ar/Paginas/noticia.asp?id=96 El Cielos de Ampimpa http://www.astrotuc.com.ar/temp/BANNER%20CAMPAMENTOS%20OBSERVATORIO%20c ielo.jpg Actividades Especiales en los Campamentos Cientmficos durante todo el aqo 2012 y 2013 Los esperamos. _ Si no desea recibir nuevas notificaciones por favor responda este mail solicitando ser removido de nuestra lista de contactos Observatorio Astronsmico Ampimpa - Tucuman - Argentina www.astrotuc.com.ar http://www.astrotuc.com.ar - institucio...@astrotuc.com.ar mailto:institucio...@astrotuc.com.ar
Re: Intel Atom E600 watchdog(4) support
* Jonathan Gray j...@jsg.id.au [2012-05-24 01:23:28]:
As a general policy drivers do not have numbers in their name,
so it will have to be renamed.
Yes, I got a couple of private mails stating the same, which explains
why I hadn't seen any others. Anyway, Mike Belopuhov suggested pchpcib
as an alternative name so I've renamed the driver to that along with
the man pages, etc.
Here's the dmesg now:
---8---
pchpcib0 at pci0 dev 31 function 0 Intel E600 LPC rev 0x00: watchdog
isa0 at pchpcib0
---8---
Looks much better to me too.
I'll have a look into trying it on a net6501 I have here with i386.
Thanks, much appreciated.
Updated patch below.
Matt
--- /dev/null Thu May 24 00:43:16 2012
+++ sys/dev/pci/pchpcib.c Thu May 24 00:34:28 2012
@@ -0,0 +1,220 @@
+/* $OpenBSD$ */
+
+/*
+ * Copyright (c) 2012 Matt Dainty m...@bodgit-n-scarper.com
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF MIND, USE, DATA OR PROFITS, WHETHER IN
+ * AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
+ * OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+/*
+ * Intel Atom E600 series LPC bridge also containing watchdog
+ */
+
+#include sys/param.h
+#include sys/systm.h
+#include sys/device.h
+
+#include machine/bus.h
+
+#include dev/pci/pcireg.h
+#include dev/pci/pcivar.h
+#include dev/pci/pcidevs.h
+
+#defineE600_LPC_SMBA 0x40/* SMBus Base Address */
+#defineE600_LPC_GBA0x44/* GPIO Base Address */
+#defineE600_LPC_WDTBA 0x84/* WDT Base Address */
+
+#defineE600_WDT_SIZE 64 /* I/O region size */
+#defineE600_WDT_PV10x00/* Preload Value 1
Register */
+#defineE600_WDT_PV20x04/* Preload Value 2
Register */
+#defineE600_WDT_RR00x0c/* Reload Register 0 */
+#defineE600_WDT_RR10x0d/* Reload Register 1 */
+#defineE600_WDT_RR1_RELOAD (1 0)/* WDT Reload Flag */
+#defineE600_WDT_RR1_TIMEOUT(1 1)/* WDT Timeout Flag */
+#defineE600_WDT_WDTCR 0x10/* WDT Configuration
Register */
+#defineE600_WDT_WDTCR_TIMEOUT (1 5)/* WDT Timeout Output
Enable */
+#defineE600_WDT_WDTCR_ENABLE (1 4)/* WDT Reset Enable */
+#defineE600_WDT_WDTCR_RESET(1 3)/* WDT Reset Select */
+#defineE600_WDT_WDTCR_PRE (1 2)/* WDT Prescalar Select
*/
+#defineE600_WDT_DCR0x14/* Down Counter
Register */
+#defineE600_WDT_WDTLR 0x18/* WDT Lock Register */
+#defineE600_WDT_WDTLR_LOCK (1 0)/* Watchdog Timer Lock
*/
+#defineE600_WDT_WDTLR_ENABLE (1 1)/* Watchdog Timer
Enable */
+#defineE600_WDT_WDTLR_TIMEOUT (1 2)/* WDT Timeout
Configuration */
+
+struct pchpcib_softc {
+ struct device sc_dev;
+
+ /* Watchdog interface */
+ bus_space_tag_t sc_wdt_iot;
+ bus_space_handle_t sc_wdt_ioh;
+
+ int sc_wdt_period;
+};
+
+struct cfdriver pchpcib_cd = {
+ NULL, pchpcib, DV_DULL
+};
+
+int pchpcib_match(struct device *, void *, void *);
+voidpchpcib_attach(struct device *, struct device *, void *);
+
+int pchpcib_wdt_cb(void *, int);
+
+struct cfattach pchpcib_ca = {
+ sizeof(struct pchpcib_softc), pchpcib_match, pchpcib_attach
+};
+
+/* from arch/*/pci/pcib.c */
+void pcibattach(struct device *parent, struct device *self, void *aux);
+
+const struct pci_matchid pchpcib_devices[] = {
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_E600_LPC }
+};
+
+#ifndef SMALL_KERNEL
+static __inline void
+pchpcib_wdt_unlock(struct pchpcib_softc *sc)
+{
+ /* Register unlocking sequence */
+ bus_space_write_1(sc-sc_wdt_iot, sc-sc_wdt_ioh, E600_WDT_RR0, 0x80);
+ bus_space_write_1(sc-sc_wdt_iot, sc-sc_wdt_ioh, E600_WDT_RR0, 0x86);
+}
+#endif /* !SMALL_KERNEL */
+
+int
+pchpcib_match(struct device *parent, void *match, void *aux)
+{
+ if (pci_matchbyid((struct pci_attach_args *)aux, pchpcib_devices,
+ sizeof(pchpcib_devices) / sizeof(pchpcib_devices[0])))
+ return (2);
+
+ return (0);
+}
+
+void
+pchpcib_attach(struct device *parent, struct device *self, void *aux)
+{
+#ifndef SMALL_KERNEL
+ struct pchpcib_softc
Re: Intel Atom E600 watchdog(4) support
On Thu, May 24, 2012 at 12:30 PM, Matt Dainty m...@bodgit-n-scarper.com wrote: * Jonathan Gray j...@jsg.id.au [2012-05-24 01:23:28]: As a general policy drivers do not have numbers in their name, so it will have to be renamed. Yes, I got a couple of private mails stating the same, which explains why I hadn't seen any others. Anyway, Mike Belopuhov suggested pchpcib as an alternative name so I've renamed the driver to that along with the man pages, etc. Here's the dmesg now: ---8--- pchpcib0 at pci0 dev 31 function 0 Intel E600 LPC rev 0x00: watchdog isa0 at pchpcib0 ---8--- Looks much better to me too. I'll have a look into trying it on a net6501 I have here with i386. Thanks, much appreciated. Updated patch below. Matt i don't think you need to include SMALL_KERNEL here as we're not going to add it to ramdisks anyway. in fact SMALL_KERNEL can be stripped of all the other *pcib drivers as we don't (or shouldn't) have them on the ramdisks anymore. no need to resend a diff just with this change though. wait a bit till something else pops up (;
Re: Intel Atom E600 watchdog(4) support
On Thu, May 24, 2012 at 06:30:02AM -0400, Matt Dainty wrote: * Jonathan Gray j...@jsg.id.au [2012-05-24 01:23:28]: As a general policy drivers do not have numbers in their name, so it will have to be renamed. Yes, I got a couple of private mails stating the same, which explains why I hadn't seen any others. Anyway, Mike Belopuhov suggested pchpcib as an alternative name so I've renamed the driver to that along with the man pages, etc. I'm not sure what it should be but pch seems a bit wrong, as the LPC device is part of the E600 chip not the EG20T PCH in this case. It isn't clear how compatible this is across the other chips either. Is it the sort of thing that is only compatible to tunnel creek/e600 or other chips as well? On another recent Atom PCH for example, the NM10 it still has a LPC controller and the watchdog seems to have a different register layout.
Re: Intel Atom E600 watchdog(4) support
On Thu, May 24, 2012 at 1:04 PM, Jonathan Gray j...@jsg.id.au wrote: On Thu, May 24, 2012 at 06:30:02AM -0400, Matt Dainty wrote: * Jonathan Gray j...@jsg.id.au [2012-05-24 01:23:28]: As a general policy drivers do not have numbers in their name, so it will have to be renamed. Yes, I got a couple of private mails stating the same, which explains why I hadn't seen any others. Anyway, Mike Belopuhov suggested pchpcib as an alternative name so I've renamed the driver to that along with the man pages, etc. I'm not sure what it should be but pch seems a bit wrong, as the LPC device is part of the E600 chip not the EG20T PCH in this case. It isn't clear how compatible this is across the other chips either. Is it the sort of thing that is only compatible to tunnel creek/e600 or other chips as well? On another recent Atom PCH for example, the NM10 it still has a LPC controller and the watchdog seems to have a different register layout. heh, my bad, i had doubts that wdt was actually part of the cpu...
Re: Intel Atom E600 watchdog(4) support
Works for me on net6501 on i386 GENERIC and GENERIC.MP after a succesfull watchdog fire: e600pcib0 at pci0 dev 31 function 0 Intel E600 LPC rev 0x00: watchdog, reboot on timeout It did fire a bit too early though, my watchdog period was set to 32 seconds and the machine did reset after 26 seconds on my stopwatch. Similarly, with a 60 second period it fired after ~50 seconds. Don't know if it really matters though Finally, can you mention that the valid period range is 1-600 seconds? The code does it right by silently lowering a too-high period to 600, but it would be nice to have it mentioned in the manpages too. [msata] # sysctl kern.watchdog.period=1 kern.watchdog.period: 0 - 1 [msata] # sysctl kern.watchdog.period kern.watchdog.period=1 [msata] # sysctl kern.watchdog.period=1 kern.watchdog.period: 1 - 1 [msata] # sysctl kern.watchdog.period kern.watchdog.period=600 Regards, Mitja P.S. While I was composing this reply some other mails have come through. How about esixoopcib ? :) -Original Message- From: owner-t...@openbsd.org [mailto:owner-t...@openbsd.org] On Behalf Of Jonathan Gray Sent: Thursday, May 24, 2012 7:23 AM To: Matt Dainty Cc: tech@openbsd.org Subject: Re: Intel Atom E600 watchdog(4) support As a general policy drivers do not have numbers in their name, so it will have to be renamed. I'll have a look into trying it on a net6501 I have here with i386. On Wed, May 23, 2012 at 04:52:03PM -0400, Matt Dainty wrote: Attached are some patches that add support for the watchdog device on boards based on the Intel Atom E600 series such as the Soekris net6501. Based on existing drivers such as amdpcib(4), ichpcib(4) and ichwdt(4) I've created an e600pcib(4) to override the standard pcib(4) which can then access the watchdog device. Here's the original dmesg: ---8--- pcib0 at pci0 dev 31 function 0 Intel E600 LPC rev 0x00 isa0 at pcib0 ---8--- Here's with my changes: ---8--- e600pcib0 at pci0 dev 31 function 0 Intel E600 LPC rev 0x00: watchdog isa0 at e600pcib0 ---8--- I tested the watchdog by setting kern.watchdog.period to 60 and then breaking into ddb and starting a stopwatch and timing until my net6501 resets, it take near enough to 60 seconds that I'm happy it's working. On a watchdog-triggered reboot, I've done similar to ichwdt(4): ---8--- e600pcib0 at pci0 dev 31 function 0 Intel E600 LPC rev 0x00: watchdog, reboot on timeout isa0 at e600pcib0 ---8--- I've included the driver itself, man pages, changes to GENERIC and the various infrastructure files. I'm using it with GENERIC.MP on amd64 and I compile tested it on i386. Any comments? Matt --- /dev/null Wed May 23 21:01:50 2012 +++ sys/dev/pci/e600pcib.c Wed May 23 21:00:44 2012 @@ -0,0 +1,220 @@ +/* $OpenBSD$ */ + +/* + * Copyright (c) 2012 Matt Dainty m...@bodgit-n-scarper.com + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + * WHATSOEVER RESULTING FROM LOSS OF MIND, USE, DATA OR PROFITS, WHETHER IN + * AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT + * OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ + +/* + * Intel Atom E600 series LPC bridge also containing watchdog + */ + +#include sys/param.h +#include sys/systm.h +#include sys/device.h + +#include machine/bus.h + +#include dev/pci/pcireg.h +#include dev/pci/pcivar.h +#include dev/pci/pcidevs.h + +#defineE600_LPC_SMBA 0x40/* SMBus Base Address */ +#defineE600_LPC_GBA0x44/* GPIO Base Address */ +#defineE600_LPC_WDTBA 0x84/* WDT Base Address */ + +#defineE600_WDT_SIZE 64 /* I/O region size */ +#defineE600_WDT_PV10x00/* Preload Value 1 Register */ +#defineE600_WDT_PV20x04/* Preload Value 2 Register */ +#defineE600_WDT_RR00x0c/* Reload Register 0 */ +#defineE600_WDT_RR10x0d/* Reload Register 1 */ +#defineE600_WDT_RR1_RELOAD (1 0)/* WDT Reload Flag */ +#defineE600_WDT_RR1_TIMEOUT(1 1)/* WDT Timeout Flag */ +#defineE600_WDT_WDTCR 0x10/* WDT Configuration Register */ +#defineE600_WDT_WDTCR_TIMEOUT (1 5)/* WDT Timeout Output Enable */ +#define
Re: Intel Atom E600 watchdog(4) support
Date: Thu, 24 May 2012 06:30:02 -0400 From: Matt Dainty m...@bodgit-n-scarper.com * Jonathan Gray j...@jsg.id.au [2012-05-24 01:23:28]: As a general policy drivers do not have numbers in their name, so it will have to be renamed. Yes, I got a couple of private mails stating the same, which explains why I hadn't seen any others. Anyway, Mike Belopuhov suggested pchpcib as an alternative name so I've renamed the driver to that along with the man pages, etc. No, pchpcib is inappropriate. This device is part of the CPU itself, not on EG20T Platform Controller Hub companion chip. ---8--- pchpcib0 at pci0 dev 31 function 0 Intel E600 LPC rev 0x00: watchdog isa0 at pchpcib0 ---8---
Memory leak in snmpd(8)
Hi,
with the OPENBSD-CARP-MIB a memory leak was introduced to snmpd(8):
RCS file: mib.c,v
retrieving revision 1.52
diff -u -p -r1.52 mib.c
--- mib.c 2012/03/20 03:01:26 1.52
+++ mib.c 2012/05/24 12:53:35
@@ -2713,7 +2713,7 @@ mib_carpiftable(struct oid *oid, struct ber_oid *o,
st
/* Get and verify the current row index */
idx = o-bo_id[OIDIDX_carpIfEntry];
- if ((cif = mib_carpifget(cif, idx)) == NULL) {
+ if (mib_carpifget(cif, idx) == NULL) {
free(cif);
return (1);
}
Gerhard
--
GeNUA, Gesellschaft fCr Netzwerk- und Unix-Administration mbH
Domagkstrasse 7, 85551 Kirchheim bei Muenchen
tel +49 89 991950-0, fax -999, www.genua.de
Geschaeftsfuehrer: Dr. Magnus Harlander, Dr. Michaela Harlander,
Bernhard Schneck. Amtsgericht Muenchen HRB 98238
Re: Intel Atom E600 watchdog(4) support
* Mitja MuEeniD mi...@muzenic.net [2012-05-24 07:23:22]: Works for me on net6501 on i386 GENERIC and GENERIC.MP after a succesfull watchdog fire: e600pcib0 at pci0 dev 31 function 0 Intel E600 LPC rev 0x00: watchdog, reboot on timeout It did fire a bit too early though, my watchdog period was set to 32 seconds and the machine did reset after 26 seconds on my stopwatch. Similarly, with a 60 second period it fired after ~50 seconds. Don't know if it really matters though Looking at the watchdog code, it looks like the kernel will refresh the timer every period / 2, so for a 60 second timeout, it could fire anywhere between 30-60 seconds after the host hangs. Finally, can you mention that the valid period range is 1-600 seconds? The code does it right by silently lowering a too-high period to 600, but it would be nice to have it mentioned in the manpages too. Yes, that makes sense. P.S. While I was composing this reply some other mails have come through. How about esixoopcib ? :) Better than esixhundredpcib ;-) Does anyone have any suggestions? e6xxpcib? atompcib? iatcpcib? Matt
Re: Intel Atom E600 watchdog(4) support
Date: Thu, 24 May 2012 08:47:52 -0400 From: Matt Dainty m...@bodgit-n-scarper.com * Mitja MuEeniD mi...@muzenic.net [2012-05-24 07:23:22]: Works for me on net6501 on i386 GENERIC and GENERIC.MP after a succesfull watchdog fire: e600pcib0 at pci0 dev 31 function 0 Intel E600 LPC rev 0x00: watchdog, reboot on timeout It did fire a bit too early though, my watchdog period was set to 32 seconds and the machine did reset after 26 seconds on my stopwatch. Similarly, with a 60 second period it fired after ~50 seconds. Don't know if it really matters though Looking at the watchdog code, it looks like the kernel will refresh the timer every period / 2, so for a 60 second timeout, it could fire anywhere between 30-60 seconds after the host hangs. Finally, can you mention that the valid period range is 1-600 seconds? The code does it right by silently lowering a too-high period to 600, but it would be nice to have it mentioned in the manpages too. Yes, that makes sense. P.S. While I was composing this reply some other mails have come through. How about esixoopcib ? :) Better than esixhundredpcib ;-) Does anyone have any suggestions? e6xxpcib? atompcib? iatcpcib? We typically prefer shorter names. tcpcib might not be such a bad name.
Re: Intel Atom E600 watchdog(4) support
We typically prefer shorter names. tcpcib might not be such a bad name. Come on. It obviously has to be yapcib since it's yet another pcib. Miod
Re: Memory leak in snmpd(8)
On Thu, May 24, 2012 at 01:54:36PM +0200, Gerhard Roth wrote:
Hi,
with the OPENBSD-CARP-MIB a memory leak was introduced to snmpd(8):
RCS file: mib.c,v
retrieving revision 1.52
diff -u -p -r1.52 mib.c
--- mib.c 2012/03/20 03:01:26 1.52
+++ mib.c 2012/05/24 12:53:35
@@ -2713,7 +2713,7 @@ mib_carpiftable(struct oid *oid, struct ber_oid *o,
st
/* Get and verify the current row index */
idx = o-bo_id[OIDIDX_carpIfEntry];
- if ((cif = mib_carpifget(cif, idx)) == NULL) {
+ if (mib_carpifget(cif, idx) == NULL) {
free(cif);
return (1);
}
Gerhard
--
GeNUA, Gesellschaft fCr Netzwerk- und Unix-Administration mbH
Domagkstrasse 7, 85551 Kirchheim bei Muenchen
tel +49 89 991950-0, fax -999, www.genua.de
Geschaeftsfuehrer: Dr. Magnus Harlander, Dr. Michaela Harlander,
Bernhard Schneck. Amtsgericht Muenchen HRB 98238
Calling mib_carpget() seems a tad over complex. Wouldn't the diff
below make it cleaner? Untested except by gcc.
And doesn't the socket 's' leak too, or does SIOCGVH returning -1
mean 's' was closed?
Ken
Index: mib.c
===
RCS file: /cvs/src/usr.sbin/snmpd/mib.c,v
retrieving revision 1.52
diff -u -p -r1.52 mib.c
--- mib.c 20 Mar 2012 03:01:26 - 1.52
+++ mib.c 24 May 2012 14:11:22 -
@@ -1360,7 +1360,7 @@ intmib_carpstats(struct oid *, struct
int mib_carpiftable(struct oid *, struct ber_oid *, struct ber_element **);
int mib_carpifnum(struct oid *, struct ber_oid *, struct ber_element **);
struct carpif
- *mib_carpifget(struct carpif *, u_int);
+ *mib_carpifget(u_int);
int mib_memiftable(struct oid *, struct ber_oid *, struct ber_element **);
static struct oid openbsd_mib[] = {
@@ -2647,9 +2647,10 @@ mib_carpifnum(struct oid *oid, struct be
}
struct carpif *
-mib_carpifget(struct carpif *cif, u_int idx)
+mib_carpifget(u_int idx)
{
struct kif *kif;
+ struct carpif *cif;
int s;
struct ifreq ifr;
struct carpreq carpr;
@@ -2692,9 +2693,12 @@ mib_carpifget(struct carpif *cif, u_int
if (ioctl(s, SIOCGVH, (caddr_t)ifr) == -1)
return (NULL);
- memset(cif, 0, sizeof(struct carpif));
- memcpy(cif-carpr, carpr, sizeof(struct carpreq));
- memcpy(cif-kif, kif, sizeof(struct kif));
+ cif = malloc(sizeof(struct carpif));
+ if (cif != NULL) {
+ memset(cif, 0, sizeof(struct carpif));
+ memcpy(cif-carpr, carpr, sizeof(struct carpreq));
+ memcpy(cif-kif, kif, sizeof(struct kif));
+ }
close(s);
@@ -2707,16 +2711,11 @@ mib_carpiftable(struct oid *oid, struct
u_int32_tidx;
struct carpif *cif;
- if ((cif = malloc(sizeof(struct carpif))) == NULL)
- return (1);
-
/* Get and verify the current row index */
idx = o-bo_id[OIDIDX_carpIfEntry];
- if ((cif = mib_carpifget(cif, idx)) == NULL) {
- free(cif);
+ if ((cif = mib_carpifget(idx)) == NULL)
return (1);
- }
/* Tables need to prepend the OID on their own */
o-bo_id[OIDIDX_carpIfEntry] = cif-kif.if_index;
Re: Memory leak in snmpd(8)
On Thu, 24 May 2012 16:16:02 +0200, Kenneth R Westerback
kwesterb...@rogers.com wrote:
On Thu, May 24, 2012 at 01:54:36PM +0200, Gerhard Roth wrote:
Hi,
with the OPENBSD-CARP-MIB a memory leak was introduced to snmpd(8):
RCS file: mib.c,v
retrieving revision 1.52
diff -u -p -r1.52 mib.c
--- mib.c 2012/03/20 03:01:26 1.52
+++ mib.c 2012/05/24 12:53:35
@@ -2713,7 +2713,7 @@ mib_carpiftable(struct oid *oid, struct ber_oid
*o,
st
/* Get and verify the current row index */
idx = o-bo_id[OIDIDX_carpIfEntry];
- if ((cif = mib_carpifget(cif, idx)) == NULL) {
+ if (mib_carpifget(cif, idx) == NULL) {
free(cif);
return (1);
}
Gerhard
Calling mib_carpget() seems a tad over complex. Wouldn't the diff
below make it cleaner? Untested except by gcc.
And doesn't the socket 's' leak too, or does SIOCGVH returning -1
mean 's' was closed?
Ken
Index: mib.c
===
RCS file: /cvs/src/usr.sbin/snmpd/mib.c,v
retrieving revision 1.52
diff -u -p -r1.52 mib.c
--- mib.c 20 Mar 2012 03:01:26 - 1.52
+++ mib.c 24 May 2012 14:11:22 -
@@ -1360,7 +1360,7 @@ intmib_carpstats(struct oid *, struct
int mib_carpiftable(struct oid *, struct ber_oid *, struct ber_element
**);
int mib_carpifnum(struct oid *, struct ber_oid *, struct ber_element
**);
struct carpif
- *mib_carpifget(struct carpif *, u_int);
+ *mib_carpifget(u_int);
int mib_memiftable(struct oid *, struct ber_oid *, struct ber_element
**);
static struct oid openbsd_mib[] = {
@@ -2647,9 +2647,10 @@ mib_carpifnum(struct oid *oid, struct be
}
struct carpif *
-mib_carpifget(struct carpif *cif, u_int idx)
+mib_carpifget(u_int idx)
{
struct kif *kif;
+ struct carpif *cif;
int s;
struct ifreq ifr;
struct carpreq carpr;
@@ -2692,9 +2693,12 @@ mib_carpifget(struct carpif *cif, u_int
if (ioctl(s, SIOCGVH, (caddr_t)ifr) == -1)
return (NULL);
- memset(cif, 0, sizeof(struct carpif));
- memcpy(cif-carpr, carpr, sizeof(struct carpreq));
- memcpy(cif-kif, kif, sizeof(struct kif));
+ cif = malloc(sizeof(struct carpif));
+ if (cif != NULL) {
+ memset(cif, 0, sizeof(struct carpif));
+ memcpy(cif-carpr, carpr, sizeof(struct carpreq));
+ memcpy(cif-kif, kif, sizeof(struct kif));
+ }
close(s);
@@ -2707,16 +2711,11 @@ mib_carpiftable(struct oid *oid, struct
u_int32_tidx;
struct carpif *cif;
- if ((cif = malloc(sizeof(struct carpif))) == NULL)
- return (1);
-
/* Get and verify the current row index */
idx = o-bo_id[OIDIDX_carpIfEntry];
- if ((cif = mib_carpifget(cif, idx)) == NULL) {
- free(cif);
+ if ((cif = mib_carpifget(idx)) == NULL)
return (1);
- }
/* Tables need to prepend the OID on their own */
o-bo_id[OIDIDX_carpIfEntry] = cif-kif.if_index;
Hi Ken,
I like your patch; it's better than mine.
And you are right about the socket fd leak. If an ioctl()
would close the filedes passed in that would be a very
awkward API.
Gerhard
--
GeNUA, Gesellschaft fCr Netzwerk- und Unix-Administration mbH
Domagkstrasse 7, 85551 Kirchheim bei Muenchen
tel +49 89 991950-0, fax -999, www.genua.de
Geschaeftsfuehrer: Dr. Magnus Harlander, Dr. Michaela Harlander,
Bernhard Schneck. Amtsgericht Muenchen HRB 98238
Re: mg - start up file diffs (2 of 2)
...Commands that are usually located in the startup file
(global-set-key, set-default-mode etc...) are unaffected since they are not
reliant on the buffers being created or not. However, wider testing would be
appreciated.
So its good to test.
Here is an updated diff, which DOES update any set-default-modes.
-lum
Index: main.c
===
RCS file: /cvs/src/usr.bin/mg/main.c,v
retrieving revision 1.64
diff -u -p -r1.64 main.c
--- main.c 12 Apr 2012 04:47:59 - 1.64
+++ main.c 24 May 2012 15:15:34 -
@@ -98,19 +98,28 @@ main(int argc, char **argv)
*/
update();
- /* user startup file */
- if ((cp = startupfile(NULL)) != NULL)
- (void)load(cp);
-
/*
* Create scratch buffer now, killing old *init* buffer.
-* This causes *scratch* to be created and made curbp,
-* ensuring default modes are inherited from the startup
-* file correctly
+* This causes *scratch* to be created and made curbp.
*/
-
if ((bp = bfind(*init*, FALSE)) != NULL)
killbuffer(bp);
+
+ /* user startup file. */
+ if ((cp = startupfile(NULL)) != NULL)
+ (void)load(cp);
+
+ /*
+* Now ensure any default buffer modes from the startup file are
+* given to any files opened when parsing the startup file.
+* Note *scratch* will also be updated.
+*/
+ for (bp = bheadp; bp != NULL; bp = bp-b_bufp) {
+ bp-b_flag = defb_flag;
+ for (i = 0; i = defb_nmodes; i++) {
+ bp-b_modes[i] = defb_modes[i];
+ }
+ }
/* Force FFOTHARG=1 so that this mode is enabled, not simply toggled */
if (init_fcn)
Bocaditos y Mini Sándwiches por Delivery. publicidad mo son
[demime 1.01d removed an attachment of type image/jpeg which had a name of fcraniano.jpg] [demime 1.01d removed an attachment of type image/jpeg which had a name of anhelante.jpg] [demime 1.01d removed an attachment of type image/jpeg which had a name of ndesventajosa.jpg] [demime 1.01d removed an attachment of type image/jpeg which had a name of tverdeceledon.jpg] [demime 1.01d removed an attachment of type image/jpeg which had a name of ecuestre.jpg] [demime 1.01d removed an attachment of type image/jpeg which had a name of cfrancolina.jpg] [demime 1.01d removed an attachment of type image/jpeg which had a name of flaqueado.jpg]
