Re: USB install image for OpenBSD 5.5 - TESTING REQUIRED
On Tue, Mar 18, 2014 at 12:39 PM, Chris Cappuccio wrote: > sven falempin [sven.falem...@gmail.com] wrote: > > Some issue here, using install55.fs (today 18/3/2014 downloaded snaps) > > > > boot is ok (warn: entropy file missing) > > > > but /dev has no /dev/sd1 (is the usb key) and so i cannot look for the > sets . > > > > I did MAKEDEV all so i can mount keys to get the dmesg. > > > > The install script will create the devices on demand, as needed to mount > the source sets > the installer proposed http and i was not able to the right disk > > > currently outputing dmesg on usb3 key, the machine has no plug for the > > com port, no idea how to get the boot infos (i am bad at soldering) > > > > I fdisk the key, but i cannot disklabel it ( out of inode ) > > > > This is because you ran MAKEDEV all, the ramdisk has only minimal inodes > available > -- - () ascii ribbon campaign - against html e-mail /\
Re: USB install image for OpenBSD 5.5 - TESTING REQUIRED
sven falempin [sven.falem...@gmail.com] wrote: > Some issue here, using install55.fs (today 18/3/2014 downloaded snaps) > > boot is ok (warn: entropy file missing) > > but /dev has no /dev/sd1 (is the usb key) and so i cannot look for the sets . > > I did MAKEDEV all so i can mount keys to get the dmesg. > The install script will create the devices on demand, as needed to mount the source sets > currently outputing dmesg on usb3 key, the machine has no plug for the > com port, no idea how to get the boot infos (i am bad at soldering) > > I fdisk the key, but i cannot disklabel it ( out of inode ) > This is because you ran MAKEDEV all, the ramdisk has only minimal inodes available
Re: USB install image for OpenBSD 5.5 - TESTING REQUIRED
Some issue here, using install55.fs (today 18/3/2014 downloaded snaps) boot is ok (warn: entropy file missing) but /dev has no /dev/sd1 (is the usb key) and so i cannot look for the sets . I did MAKEDEV all so i can mount keys to get the dmesg. currently outputing dmesg on usb3 key, the machine has no plug for the com port, no idea how to get the boot infos (i am bad at soldering) I fdisk the key, but i cannot disklabel it ( out of inode ) OpenBSD 5.5-current (RAMDISK_CD) #2: Mon Mar 17 17:19:05 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 4143271936 (3951MB) avail mem = 4027494400 (3840MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb630 (78 entries) bios0: vendor American Megatrends Inc. version "7920D103" date 01/07/2013 bios0: NORCO BPC-7920 acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT SSDT ASF! acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-2670QM CPU @ 2.20GHz, 2197.54 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu0: 256KB 64b/line 8-way L2 cache cpu0: apic clock running at 99MHz cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG0) acpiprt2 at acpi0: bus -1 (PEG1) acpiprt3 at acpi0: bus -1 (PEG2) acpiprt4 at acpi0: bus -1 (PEG3) acpiprt5 at acpi0: bus -1 (P0P1) acpiprt6 at acpi0: bus 1 (RP01) acpiprt7 at acpi0: bus 2 (RP02) acpiprt8 at acpi0: bus 3 (RP03) acpiprt9 at acpi0: bus 4 (RP04) acpiprt10 at acpi0: bus 5 (RP05) acpiprt11 at acpi0: bus -1 (RP06) acpiprt12 at acpi0: bus -1 (RP07) acpiprt13 at acpi0: bus -1 (RP08) pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 2G Host" rev 0x09 vga1 at pci0 dev 2 function 0 "Intel HD Graphics 3000" rev 0x09 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) "Intel 7 Series xHCI" rev 0x04 at pci0 dev 20 function 0 not configured "Intel 7 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured "Intel 7 Series KT" rev 0x04 at pci0 dev 22 function 3 not configured em0 at pci0 dev 25 function 0 "Intel 82579LM" rev 0x04: msi, address 00:50:c2:21:60:70 ehci0 at pci0 dev 26 function 0 "Intel 7 Series USB" rev 0x04: apic 2 int 16 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 "Intel 7 Series HD Audio" rev 0x04 at pci0 dev 27 function 0 not configured ppb0 at pci0 dev 28 function 0 "Intel 7 Series PCIE" rev 0xc4: msi pci1 at ppb0 bus 1 em1 at pci1 dev 0 function 0 "Intel 82583V" rev 0x00: msi, address 00:50:c2:21:60:6b ppb1 at pci0 dev 28 function 1 "Intel 7 Series PCIE" rev 0xc4: msi pci2 at ppb1 bus 2 em2 at pci2 dev 0 function 0 "Intel 82583V" rev 0x00: msi, address 00:50:c2:21:60:6c ppb2 at pci0 dev 28 function 2 "Intel 7 Series PCIE" rev 0xc4: msi pci3 at ppb2 bus 3 em3 at pci3 dev 0 function 0 "Intel 82583V" rev 0x00: msi, address 00:50:c2:21:60:6d ppb3 at pci0 dev 28 function 3 "Intel 7 Series PCIE" rev 0xc4: msi pci4 at ppb3 bus 4 em4 at pci4 dev 0 function 0 "Intel 82583V" rev 0x00: msi, address 00:50:c2:21:60:6e ppb4 at pci0 dev 28 function 4 "Intel 7 Series PCIE" rev 0xc4: msi pci5 at ppb4 bus 5 em5 at pci5 dev 0 function 0 "Intel 82583V" rev 0x00: msi, address 00:50:c2:21:60:6f ehci1 at pci0 dev 29 function 0 "Intel 7 Series USB" rev 0x04: apic 2 int 23 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 "Intel EHCI root hub" rev 2.00/1.00 addr 1 "Intel QM77 LPC" rev 0x04 at pci0 dev 31 function 0 not configured ahci0 at pci0 dev 31 function 2 "Intel 7 Series AHCI" rev 0x04: msi, AHCI 1.3 scsibus0 at ahci0: 32 targets sd0 at scsibus0 targ 0 lun 0: SCSI3 0/direct fixed naa.5000c50022660557 sd0: 152627MB, 512 bytes/sector, 312581808 sectors "Intel 7 Series SMBus" rev 0x04 at pci0 dev 31 function 3 not configured isa0 at mainbus0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo 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 uhub2 at uhub0 port 1 "vendor 0x8087 product 0x0024" rev 2.00/0.00 addr 2 uhidev0 at uhub2 port 2 configuration 1 interface 0 "Dell Dell USB Keyboard" rev 1.10/3.06 addr 3 uhidev0: iclass 3/1 ukbd0 at uhidev0 wskbd1 at ukbd0 mux 1 wskbd1: connecting to wsdisplay0 uhub3 at uhub1 port 1 "vendor 0x8087 product 0x0024" rev 2.00/0.00 addr 2 umass0 at uhub3 port 4 configuration 1 interface 0 "Kingston Dat
Re: bgpctl show_attr bad length fix
Commited, thanks
On Tue, Mar 18, 2014 at 08:57:40AM +, rivo nurges wrote:
> Hi!
>
> When show_attr reads data length from provided data it reads carbage
> to alen and fails afterwards. This patch fixes the problem by casting
> the data to u_char. While at it I noticed data gets assigned twice.
>
>
> bgpctl.c: /* bad imsg len how can that happen!? */
> bgpctl.c: if (alen > len)
> bgpctl.c: errx(1, "show_attr: bad length");
>
> It can happen:D
>
>
> Example failing prefix with long community list:
> Before:
> BGP routing table entry for 5.44.0.0/20
> 25478 31499 39812
> Nexthop x.y.z.w (via 10.9.0.10) from x.y.z.w (x.y.z.w)
> Origin IGP, metric 4200, localpref 60, weight 0, internal, valid, best
> Last update: 00:12:11 ago
> bgpctl: show_attr: bad length
>
> After:
> BGP routing table entry for 5.44.0.0/20
> 25478 31499 39812
> Nexthop x.y.z.w (via 10.9.0.10) from x.y.z.w (x.y.z.w)
> Origin IGP, metric 4200, localpref 60, weight 0, internal, valid, best
> Last update: 00:11:13 ago
> Communities: 0:5429 0:6719 0:8241 0:8636 0:8641 0:24955 0:25478 0:25532
> 0:29000 0:29319 0:30784 0:31225 0:41349 0:41475 0:42511 0:42754 0:43973
> 0:44020
> 0:44053 0:44281 0:47104 0:47119 0:47321 0:48166 0:48293 0:48297 0:48781
> 0:49060
> 0:49124 0:50384 0:50448 0:50577 0:50911 0:50952 0:56462 0:57073 0:57363
> 1299:150
> 3249:10643 3249:11000 3249:11001 3356:90 6854:1009 6854:1509 6854:1605
> 6854:1665
> 8359:2094 8631:8631 8744:52994 8744:53124 8744:53134 8744:59994 12389:6992
> 12389:7130 12389:7993 12389:8020 12389:8995 25478:10011 25478:10931
> 25478:24000
> 25478:29000 31133:10008 31133:25002
> Originator Id: x.y.z.w
> Cluster ID List: x.y.z.w z.x.y.w
>
>
> --
> rix
>
>
>
> Index: usr.sbin/bgpctl/bgpctl.c
> ===
> RCS file: /OpenBSD/src/usr.sbin/bgpctl/bgpctl.c,v
> retrieving revision 1.173
> diff -u -p -r1.173 bgpctl.c
> --- usr.sbin/bgpctl/bgpctl.c 13 Nov 2013 22:52:41 - 1.173
> +++ usr.sbin/bgpctl/bgpctl.c 3 Mar 2014 13:21:23 -
> @@ -1346,7 +1346,6 @@ show_attr(void *b, u_int16_t len)
> u_int16_talen, ioff;
> u_int8_t flags, type;
>
> - data = b;
> if (len < 3)
> errx(1, "show_attr: too short bgp attr");
>
> @@ -1362,7 +1361,7 @@ show_attr(void *b, u_int16_t len)
> data += 4;
> len -= 4;
> } else {
> - alen = data[2];
> + alen = (u_char)data[2];
> data += 3;
> len -= 3;
> }
>
--
I'm not entirely sure you are real.
Re: bgpctl show_attr bad length fix
On 2014/03/18 08:57, rivo nurges wrote:
> Hi!
>
> When show_attr reads data length from provided data it reads carbage
> to alen and fails afterwards. This patch fixes the problem by casting
> the data to u_char. While at it I noticed data gets assigned twice.
>
>
> bgpctl.c: /* bad imsg len how can that happen!? */
> bgpctl.c: if (alen > len)
> bgpctl.c: errx(1, "show_attr: bad length");
>
> It can happen:D
>
>
> Example failing prefix with long community list:
> Before:
> BGP routing table entry for 5.44.0.0/20
> 25478 31499 39812
> Nexthop x.y.z.w (via 10.9.0.10) from x.y.z.w (x.y.z.w)
> Origin IGP, metric 4200, localpref 60, weight 0, internal, valid, best
> Last update: 00:12:11 ago
> bgpctl: show_attr: bad length
Haven't found any in my route views yet, though I only got part-way
through when I realised quite how much cpu time session engine was
burning doing a "sh rib d" (hundreds of clock_gettime a second)
and stopped as I worried about it not maintaining sessions and
tripping idle timers.
> Index: usr.sbin/bgpctl/bgpctl.c
> ===
> RCS file: /OpenBSD/src/usr.sbin/bgpctl/bgpctl.c,v
> retrieving revision 1.173
> diff -u -p -r1.173 bgpctl.c
> --- usr.sbin/bgpctl/bgpctl.c 13 Nov 2013 22:52:41 - 1.173
> +++ usr.sbin/bgpctl/bgpctl.c 3 Mar 2014 13:21:23 -
> @@ -1346,7 +1346,6 @@ show_attr(void *b, u_int16_t len)
> u_int16_talen, ioff;
> u_int8_t flags, type;
>
> - data = b;
> if (len < 3)
> errx(1, "show_attr: too short bgp attr");
>
> @@ -1362,7 +1361,7 @@ show_attr(void *b, u_int16_t len)
> data += 4;
> len -= 4;
> } else {
> - alen = data[2];
> + alen = (u_char)data[2];
> data += 3;
> len -= 3;
> }
This is OK sthen@
Re: Stop abusing rcvif pointer to pass wireless nodes
On Tue, Mar 18, 2014 at 12:28:41PM +0100, Martin Pieuchot wrote:
> On 18/03/14(Tue) 11:26, Mike Belopuhov wrote:
> > On 18 March 2014 07:20, Claudio Jeker wrote:
> > > On Mon, Mar 17, 2014 at 11:41:38AM -0600, Theo de Raadt wrote:
> > >> > What about using a more generic name which is not bound to 80211 since
> > >> > the
> > >> > field is a generic pointer. This may allow us to use something similar
> > >> > in
> > >> > other drivers like mpe(4), gif(4), gre(4).
> > >>
> > >> That is basically the only thought I had. I mean you could also start
> > >> passing it as a mbuf tag, but probably don't want the allocate/free
> > >> overhead.
> > >
> > > It would only make sense to use mbuf tags if the allocate/lookup/free
> > > path of mbuf tags can be made very small.
> >
> > meh. i'd say the cookie pointer is fine here.
> >
> > > Did somebody profile them after the switch to a pool backend?
> > >
> >
> > that i did, yes.
>
> So here's a diff with a more generic name for the pointer and an update
> of the structure in the manpage, ok?
Yeah, lets go with this. OK claudio@
> diff --git share/man/man9/mbuf.9 share/man/man9/mbuf.9
> index e3db548..ed0a511 100644
> --- share/man/man9/mbuf.9
> +++ share/man/man9/mbuf.9
> @@ -119,6 +119,7 @@ struct pkthdr {
> u_int16_t csum_flags;
> u_int16_t ether_vtag;
> u_int rdomain;
> + void*ph_cookie;
> struct pkthdr_pf pf;
> };
>
> diff --git sys/dev/ic/acx.c sys/dev/ic/acx.c
> index 39910bc..07c04e6 100644
> --- sys/dev/ic/acx.c
> +++ sys/dev/ic/acx.c
> @@ -948,8 +948,7 @@ acx_start(struct ifnet *ifp)
> IF_DEQUEUE(&ic->ic_mgtq, m);
> /* first dequeue management frames */
> if (m != NULL) {
> - ni = (struct ieee80211_node *)m->m_pkthdr.rcvif;
> - m->m_pkthdr.rcvif = NULL;
> + ni = m->m_pkthdr.ph_cookie;
>
> /*
>* probe response mgmt frames are handled by the
> @@ -976,8 +975,7 @@ acx_start(struct ifnet *ifp)
> /* then dequeue packets on the powersave queue */
> IF_DEQUEUE(&ic->ic_pwrsaveq, m);
> if (m != NULL) {
> - ni = (struct ieee80211_node *)m->m_pkthdr.rcvif;
> - m->m_pkthdr.rcvif = NULL;
> + ni = m->m_pkthdr.ph_cookie;
> goto encapped;
> } else {
> IFQ_DEQUEUE(&ifp->if_snd, m);
> diff --git sys/dev/ic/ath.c sys/dev/ic/ath.c
> index 83cd233..6c1bdca 100644
> --- sys/dev/ic/ath.c
> +++ sys/dev/ic/ath.c
> @@ -897,17 +897,7 @@ ath_start(struct ifnet *ifp)
> }
> wh = mtod(m, struct ieee80211_frame *);
> } else {
> - /*
> - * Hack! The referenced node pointer is in the
> - * rcvif field of the packet header. This is
> - * placed there by ieee80211_mgmt_output because
> - * we need to hold the reference with the frame
> - * and there's no other way (other than packet
> - * tags which we consider too expensive to use)
> - * to pass it along.
> - */
> - ni = (struct ieee80211_node *) m->m_pkthdr.rcvif;
> - m->m_pkthdr.rcvif = NULL;
> + ni = m->m_pkthdr.ph_cookie;
>
> wh = mtod(m, struct ieee80211_frame *);
> if ((wh->i_fc[0] & IEEE80211_FC0_SUBTYPE_MASK) ==
> diff --git sys/dev/ic/athn.c sys/dev/ic/athn.c
> index 3aa4f0b..dafd00a 100644
> --- sys/dev/ic/athn.c
> +++ sys/dev/ic/athn.c
> @@ -2554,7 +2554,7 @@ athn_start(struct ifnet *ifp)
> /* Send pending management frames first. */
> IF_DEQUEUE(&ic->ic_mgtq, m);
> if (m != NULL) {
> - ni = (void *)m->m_pkthdr.rcvif;
> + ni = m->m_pkthdr.ph_cookie;
> goto sendit;
> }
> if (ic->ic_state != IEEE80211_S_RUN)
> @@ -2562,7 +2562,7 @@ athn_start(struct ifnet *ifp)
>
> IF_DEQUEUE(&ic->ic_pwrsaveq, m);
> if (m != NULL) {
> - ni = (void *)m->m_pkthdr.rcvif;
> + ni = m->m_pkthdr.ph_cookie;
> goto sendit;
> }
> if (ic->ic_state != IEEE80211_S_RUN)
> diff --git sys/dev/ic/atw.c sys/dev/ic/atw.c
> index 443c1c0..8a0fd64 100644
> --- sys/dev/ic/atw.c
> +++ sys/dev/ic/atw.c
> @@ -3605,8 +3605,7 @@ atw_start(struct ifnet *ifp)
>*/
> IF_DEQUEUE(&ic->ic_mgtq, m0);
> if (m0 != NULL) {
> - ni = (struct ieee80211_node *)m0->m_pkthdr.rcvif;
> - m0->m_pk
Re: Stop abusing rcvif pointer to pass wireless nodes
On 18/03/14(Tue) 11:26, Mike Belopuhov wrote:
> On 18 March 2014 07:20, Claudio Jeker wrote:
> > On Mon, Mar 17, 2014 at 11:41:38AM -0600, Theo de Raadt wrote:
> >> > What about using a more generic name which is not bound to 80211 since
> >> > the
> >> > field is a generic pointer. This may allow us to use something similar in
> >> > other drivers like mpe(4), gif(4), gre(4).
> >>
> >> That is basically the only thought I had. I mean you could also start
> >> passing it as a mbuf tag, but probably don't want the allocate/free
> >> overhead.
> >
> > It would only make sense to use mbuf tags if the allocate/lookup/free
> > path of mbuf tags can be made very small.
>
> meh. i'd say the cookie pointer is fine here.
>
> > Did somebody profile them after the switch to a pool backend?
> >
>
> that i did, yes.
So here's a diff with a more generic name for the pointer and an update
of the structure in the manpage, ok?
diff --git share/man/man9/mbuf.9 share/man/man9/mbuf.9
index e3db548..ed0a511 100644
--- share/man/man9/mbuf.9
+++ share/man/man9/mbuf.9
@@ -119,6 +119,7 @@ struct pkthdr {
u_int16_t csum_flags;
u_int16_t ether_vtag;
u_int rdomain;
+ void*ph_cookie;
struct pkthdr_pf pf;
};
diff --git sys/dev/ic/acx.c sys/dev/ic/acx.c
index 39910bc..07c04e6 100644
--- sys/dev/ic/acx.c
+++ sys/dev/ic/acx.c
@@ -948,8 +948,7 @@ acx_start(struct ifnet *ifp)
IF_DEQUEUE(&ic->ic_mgtq, m);
/* first dequeue management frames */
if (m != NULL) {
- ni = (struct ieee80211_node *)m->m_pkthdr.rcvif;
- m->m_pkthdr.rcvif = NULL;
+ ni = m->m_pkthdr.ph_cookie;
/*
* probe response mgmt frames are handled by the
@@ -976,8 +975,7 @@ acx_start(struct ifnet *ifp)
/* then dequeue packets on the powersave queue */
IF_DEQUEUE(&ic->ic_pwrsaveq, m);
if (m != NULL) {
- ni = (struct ieee80211_node *)m->m_pkthdr.rcvif;
- m->m_pkthdr.rcvif = NULL;
+ ni = m->m_pkthdr.ph_cookie;
goto encapped;
} else {
IFQ_DEQUEUE(&ifp->if_snd, m);
diff --git sys/dev/ic/ath.c sys/dev/ic/ath.c
index 83cd233..6c1bdca 100644
--- sys/dev/ic/ath.c
+++ sys/dev/ic/ath.c
@@ -897,17 +897,7 @@ ath_start(struct ifnet *ifp)
}
wh = mtod(m, struct ieee80211_frame *);
} else {
- /*
-* Hack! The referenced node pointer is in the
-* rcvif field of the packet header. This is
-* placed there by ieee80211_mgmt_output because
-* we need to hold the reference with the frame
-* and there's no other way (other than packet
-* tags which we consider too expensive to use)
-* to pass it along.
-*/
- ni = (struct ieee80211_node *) m->m_pkthdr.rcvif;
- m->m_pkthdr.rcvif = NULL;
+ ni = m->m_pkthdr.ph_cookie;
wh = mtod(m, struct ieee80211_frame *);
if ((wh->i_fc[0] & IEEE80211_FC0_SUBTYPE_MASK) ==
diff --git sys/dev/ic/athn.c sys/dev/ic/athn.c
index 3aa4f0b..dafd00a 100644
--- sys/dev/ic/athn.c
+++ sys/dev/ic/athn.c
@@ -2554,7 +2554,7 @@ athn_start(struct ifnet *ifp)
/* Send pending management frames first. */
IF_DEQUEUE(&ic->ic_mgtq, m);
if (m != NULL) {
- ni = (void *)m->m_pkthdr.rcvif;
+ ni = m->m_pkthdr.ph_cookie;
goto sendit;
}
if (ic->ic_state != IEEE80211_S_RUN)
@@ -2562,7 +2562,7 @@ athn_start(struct ifnet *ifp)
IF_DEQUEUE(&ic->ic_pwrsaveq, m);
if (m != NULL) {
- ni = (void *)m->m_pkthdr.rcvif;
+ ni = m->m_pkthdr.ph_cookie;
goto sendit;
}
if (ic->ic_state != IEEE80211_S_RUN)
diff --git sys/dev/ic/atw.c sys/dev/ic/atw.c
index 443c1c0..8a0fd64 100644
--- sys/dev/ic/atw.c
+++ sys/dev/ic/atw.c
@@ -3605,8 +3605,7 @@ atw_start(struct ifnet *ifp)
*/
IF_DEQUEUE(&ic->ic_mgtq, m0);
if (m0 != NULL) {
- ni = (struct ieee80211_node *)m0->m_pkthdr.rcvif;
- m0->m_pkthdr.rcvif = NULL;
+ ni = m0->m_pkthdr.ph_cookie;
} else {
/* send no data packets until we are associated */
if (ic->ic_state != IEEE80211_
Re: Stop abusing rcvif pointer to pass wireless nodes
On 18 March 2014 07:20, Claudio Jeker wrote: > On Mon, Mar 17, 2014 at 11:41:38AM -0600, Theo de Raadt wrote: >> > What about using a more generic name which is not bound to 80211 since the >> > field is a generic pointer. This may allow us to use something similar in >> > other drivers like mpe(4), gif(4), gre(4). >> >> That is basically the only thought I had. I mean you could also start >> passing it as a mbuf tag, but probably don't want the allocate/free >> overhead. > > It would only make sense to use mbuf tags if the allocate/lookup/free > path of mbuf tags can be made very small. meh. i'd say the cookie pointer is fine here. > Did somebody profile them after the switch to a pool backend? > that i did, yes.
fix for fs tests
Somehow fstests from src/regress were broken.
Patch fix creation of temporary files and
add mark test target as required root permissions.
Ok?
Was: 3053 tests completed, 2738 failed.
Now: 3053 tests completed, 275 failed.
Another failes connected to abcense of syscalls (lchflags),
abcense of flags for chflags (like SF_SNAPSHOT). Do we need to
remove such tests?
P.S. pjd@ test source tree differs from OpenBSD test for at least
tests with ftruncate - https://github.com/pjd/pjdfstest
Is it worth to add absent tests?
Sergey B.
Index: Makefile
===
RCS file: /cvs/src/regress/sys/ffs/Makefile,v
retrieving revision 1.4
diff -u -p -u -r1.4 Makefile
--- Makefile18 Apr 2011 16:52:11 - 1.4
+++ Makefile16 Mar 2014 07:52:23 -
@@ -2,6 +2,8 @@
PROG= fstest
+REGRESS_ROOT_TARGETS= run-regress-fstest
+
mount:
dd if=/dev/zero of=${.CURDIR}/fakeobj bs=512 count=4k
vnconfig vnd0 ${.CURDIR}/fakeobj
Index: run
===
RCS file: /cvs/src/regress/sys/ffs/run,v
retrieving revision 1.1
diff -u -p -u -r1.1 run
--- run 30 Mar 2007 19:02:51 - 1.1
+++ run 16 Mar 2014 07:52:23 -
@@ -45,7 +45,7 @@ test_check()
# Generate a random file/directory name.
namegen()
{
- echo "fstest_`dd if=/dev/urandom bs=1k count=1 2>/dev/null | openssl md5`"
+ echo "fstest_`dd if=/dev/urandom bs=1k count=1 2>/dev/null | openssl md5 |
awk '{ print $2 }'`"
}
for arg in $*; do
bgpctl show_attr bad length fix
Hi!
When show_attr reads data length from provided data it reads carbage
to alen and fails afterwards. This patch fixes the problem by casting
the data to u_char. While at it I noticed data gets assigned twice.
bgpctl.c: /* bad imsg len how can that happen!? */
bgpctl.c: if (alen > len)
bgpctl.c: errx(1, "show_attr: bad length");
It can happen:D
Example failing prefix with long community list:
Before:
BGP routing table entry for 5.44.0.0/20
25478 31499 39812
Nexthop x.y.z.w (via 10.9.0.10) from x.y.z.w (x.y.z.w)
Origin IGP, metric 4200, localpref 60, weight 0, internal, valid, best
Last update: 00:12:11 ago
bgpctl: show_attr: bad length
After:
BGP routing table entry for 5.44.0.0/20
25478 31499 39812
Nexthop x.y.z.w (via 10.9.0.10) from x.y.z.w (x.y.z.w)
Origin IGP, metric 4200, localpref 60, weight 0, internal, valid, best
Last update: 00:11:13 ago
Communities: 0:5429 0:6719 0:8241 0:8636 0:8641 0:24955 0:25478 0:25532
0:29000 0:29319 0:30784 0:31225 0:41349 0:41475 0:42511 0:42754 0:43973 0:44020
0:44053 0:44281 0:47104 0:47119 0:47321 0:48166 0:48293 0:48297 0:48781 0:49060
0:49124 0:50384 0:50448 0:50577 0:50911 0:50952 0:56462 0:57073 0:57363 1299:150
3249:10643 3249:11000 3249:11001 3356:90 6854:1009 6854:1509 6854:1605 6854:1665
8359:2094 8631:8631 8744:52994 8744:53124 8744:53134 8744:59994 12389:6992
12389:7130 12389:7993 12389:8020 12389:8995 25478:10011 25478:10931 25478:24000
25478:29000 31133:10008 31133:25002
Originator Id: x.y.z.w
Cluster ID List: x.y.z.w z.x.y.w
--
rix
Index: usr.sbin/bgpctl/bgpctl.c
===
RCS file: /OpenBSD/src/usr.sbin/bgpctl/bgpctl.c,v
retrieving revision 1.173
diff -u -p -r1.173 bgpctl.c
--- usr.sbin/bgpctl/bgpctl.c13 Nov 2013 22:52:41 - 1.173
+++ usr.sbin/bgpctl/bgpctl.c3 Mar 2014 13:21:23 -
@@ -1346,7 +1346,6 @@ show_attr(void *b, u_int16_t len)
u_int16_talen, ioff;
u_int8_t flags, type;
- data = b;
if (len < 3)
errx(1, "show_attr: too short bgp attr");
@@ -1362,7 +1361,7 @@ show_attr(void *b, u_int16_t len)
data += 4;
len -= 4;
} else {
- alen = data[2];
+ alen = (u_char)data[2];
data += 3;
len -= 3;
}
