Re: removing expired once rules in pf_purge_thread()
On Wed, 16 Dec 2015, Alexandr Nedvedicky wrote: > On Wed, Dec 16, 2015 at 02:48:49PM +1300, Richard Procter wrote: > > Quoting pf.conf(5) "once - Creates a one shot rule that will remove itself > > from an active ruleset after the first match." > > > > A 'first' match presupposes a total ordering. This comes for free when pf > > is single-threaded but concurrent rule matching must take the trouble to > > re-impose it somewhere. (I assume that pf aims to do concurrent matching > > of packets against the ruleset.) > > pf@solaris allows the race here. > The price for correct behavior, which is to allow one and only one > packet to hit the rule is too high (given the once rules are kind of > special case). I agree, at least, I do for 'once' rules that aren't 'quick'. > What has to be granted is there is one 'winner' only, which puts the > rule to garbage collector list. The pragmatic approach wins here. Right. I'll just note though that the patch as it stands allows multiple winners: consider the window between testing PFRULE_EXPIRED and setting it (quoted below). Multiple threads may execute in that window before one of them closes it by setting PFRULE_EXPIRED. Each of them will delete the same rule in turn, causing a probable crash. At least, SLIST_INSERT_HEAD(&pf_rule_gcl, r, gcle); SLIST_INSERT_HEAD(&pf_rule_gcl, r, gcle); crashes my machine. Whether that's a realistic issue, I don't know. I have though been bitten by enough edge cases like this to be very wary of them. best, Richard. On Wed, 16 Dec 2015, Alexandr Nedvedicky wrote: @@ -3135,6 +3160,10 @@ pf_test_rule(struct pf_pdesc *pd, struct ruleset = &pf_main_ruleset; r = TAILQ_FIRST(pf_main_ruleset.rules.active.ptr); while (r != NULL) { + if (r->rule_flag & PFRULE_EXPIRED) { + r = TAILQ_NEXT(r, entries); + goto nextrule; + } r->evaluations++; PF_TEST_ATTRIB((pfi_kif_match(r->kif, pd->kif) == r->ifnot), r->skip[PF_SKIP_IFP].ptr); > @@ -3433,8 +3462,15 @@ pf_test_rule(struct pf_pdesc *pd, struct > } > #endif /* NPFSYNC > 0 */ > > - if (r->rule_flag & PFRULE_ONCE) > - pf_purge_rule(ruleset, r, aruleset, a); > + if (r->rule_flag & PFRULE_ONCE) { > + if ((a != NULL) && TAILQ_EMPTY(a->ruleset->rules.active.ptr)) { > + a->rule_flag |= PFRULE_EXPIRED; > + SLIST_INSERT_HEAD(&pf_rule_gcl, a, gcle); > + } > + > + r->rule_flag |= PFRULE_EXPIRED; > + SLIST_INSERT_HEAD(&pf_rule_gcl, r, gcle); > + } > > #ifdef INET6 > if (rewrite && skw->af != sks->af)
bgpd: dispatch_rtmsg_addr[change] mpath route not found
I updated a box running bgpd/ospfd/ospf6d earlier and ran into this when bgpd started at boot time: $ syslogc bgpd | cut -d' ' -f 3,5- 21:03:23 bgpd[2742]: startup 21:03:23 bgpd[2742]: rereading config 21:03:23 bgpd[8249]: route decision engine ready 21:03:23 bgpd[2742]: new ktable rdomain_0 for rtableid 0 21:03:34 bgpd[2742]: dispatch_rtmsg_addr[change] mpath route not found 21:03:34 bgpd[8249]: route decision engine exiting 21:03:34 bgpd[2742]: freeing ktable Loc-RIB rtableid 0 21:03:36 bgpd[2742]: Terminating Not sure what triggered it, and restarting it later it remained up. Any suggestions for additional logging in case I run into it again? OpenBSD 5.8-current (GENERIC.MP) #1751: Wed Dec 16 11:59:55 MST 2015 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8557764608 (8161MB) avail mem = 8294268928 (7910MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x7f3b9000 (51 entries) bios0: vendor American Megatrends Inc. version "1.0c" date 02/27/2014 bios0: Supermicro A1SAi acpi0 at bios0: rev 2 acpi0: sleep states S0 S5 acpi0: tables DSDT FACP FPDT SPMI MCFG WDAT UEFI APIC BDAT HPET SSDT HEST BERT ERST EINJ acpi0: wakeup devices PEX1(S0) PEX2(S0) PEX3(S0) EHC1(S0) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Atom(TM) CPU C2750 @ 2.40GHz, 2400.43 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,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT cpu0: 1MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 100MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Atom(TM) CPU C2750 @ 2.40GHz, 2400.01 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT cpu1: 1MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Atom(TM) CPU C2750 @ 2.40GHz, 2400.01 MHz cpu2: 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,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT cpu2: 1MB 64b/line 16-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Atom(TM) CPU C2750 @ 2.40GHz, 2400.01 MHz cpu3: 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,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT cpu3: 1MB 64b/line 16-way L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 8 (application processor) cpu4: Intel(R) Atom(TM) CPU C2750 @ 2.40GHz, 2400.01 MHz cpu4: 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,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT cpu4: 1MB 64b/line 16-way L2 cache cpu4: smt 0, core 4, package 0 cpu5 at mainbus0: apid 10 (application processor) cpu5: Intel(R) Atom(TM) CPU C2750 @ 2.40GHz, 2400.01 MHz cpu5: 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,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT cpu5: 1MB 64b/line 16-way L2 cache cpu5: smt 0, core 5, package 0 cpu6 at mainbus0: apid 12 (application processor) cpu6: Intel(R) Atom(TM) CPU C2750 @ 2.40GHz, 2400.01 MHz cpu6: 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,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT cpu6: 1MB 64b/line 16-way L2 cache cpu6: smt 0, core 6, package 0 cpu7 at mainbus0: apid 14 (application processor) cpu7: Intel(R) Atom(TM) CPU C2750 @ 2.40GHz, 2400.01 MHz cpu7: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,D
Re: scan regression fixes
On Thu, Dec 17, 2015 at 08:13:03PM +0100, Stefan Sperling wrote: > This should fix the infinite scanning loops people have been > reporting with 11n-enabled iwn(4), as well as the issue where > clients associating to 11g APs end up in 11b mode and can't > use OFDM data rates. > > ok? Updated diff which allows scanning to work after somebody decided to run 'ifconfig iwn0 media autoselect mode 11n' for some reason. (Don't do that, it won't enforce 11n -- 11n cannot really be set a priori because it's negotiated during association.) Also delete a bit of code from ieee80211_newstate() in ieee80211_proto.c which is pointless now that ieee80211_chan2mode() won't return MODE_11N. Index: ieee80211.c === RCS file: /cvs/src/sys/net80211/ieee80211.c,v retrieving revision 1.52 diff -u -p -r1.52 ieee80211.c --- ieee80211.c 16 Dec 2015 12:52:03 - 1.52 +++ ieee80211.c 17 Dec 2015 21:16:03 - @@ -856,10 +856,12 @@ ieee80211_next_mode(struct ifnet *ifp) { struct ieee80211com *ic = (void *)ifp; - if (IFM_MODE(ic->ic_media.ifm_cur->ifm_media) != IFM_AUTO) { + if (IFM_MODE(ic->ic_media.ifm_cur->ifm_media) != IFM_AUTO && + ic->ic_curmode != IEEE80211_MODE_11N) { /* * Reset the scan state and indicate a wrap around * if we're running in a fixed, user-specified phy mode. +* But 11n is not a valid phy mode for scanning (see below). */ ieee80211_reset_scan(ifp); return (IEEE80211_MODE_AUTO); @@ -874,6 +876,16 @@ ieee80211_next_mode(struct ifnet *ifp) /* Wrap around and ignore turbo mode */ if (ic->ic_curmode == IEEE80211_MODE_TURBO) continue; +#ifndef IEEE80211_NO_HT + /* +* Skip 11n mode while scanning. Its set of channels is +* the superset of all channels supported by other modes +* and 11n features cannot be negotiated without exchanging +* frames in another mode first. +*/ + if (ic->ic_curmode == IEEE80211_MODE_11N) + continue; +#endif if (ic->ic_curmode >= IEEE80211_MODE_MAX) { ic->ic_curmode = IEEE80211_MODE_AUTO; break; @@ -893,6 +905,11 @@ ieee80211_next_mode(struct ifnet *ifp) * caller can select a rate set. This is problematic and the * work here assumes how things work elsewhere in this code. * + * Because the result of this function is ultimately used to select + * a rate from the rate set of the returned mode, it must not return + * IEEE80211_MODE_11N. This function may be called in 11n mode to find + * a non-MCS rate to use for sending frames to non-HT STAs. + * * XXX never returns turbo modes -dcy */ enum ieee80211_phymode @@ -911,11 +928,6 @@ ieee80211_chan2mode(struct ieee80211com * characteristics. We assume that turbo-only channels * are not considered when the channel set is constructed. */ -#ifndef IEEE80211_NO_HT - if (IEEE80211_IS_CHAN_N(chan)) - return IEEE80211_MODE_11N; - else -#endif if (IEEE80211_IS_CHAN_T(chan)) return IEEE80211_MODE_TURBO; else if (IEEE80211_IS_CHAN_5GHZ(chan)) Index: ieee80211_input.c === RCS file: /cvs/src/sys/net80211/ieee80211_input.c,v retrieving revision 1.145 diff -u -p -r1.145 ieee80211_input.c --- ieee80211_input.c 12 Dec 2015 13:56:10 - 1.145 +++ ieee80211_input.c 17 Dec 2015 18:42:06 - @@ -2257,16 +2257,8 @@ ieee80211_recv_assoc_resp(struct ieee802 /* Hop out of 11n mode after associating to a non-HT AP. */ if (ic->ic_curmode == IEEE80211_MODE_11N && - (ni->ni_flags & IEEE80211_NODE_HT) == 0) { - if (IEEE80211_IS_CHAN_T(ni->ni_chan)) - ieee80211_setmode(ic, IEEE80211_MODE_TURBO); - else if (IEEE80211_IS_CHAN_A(ni->ni_chan)) - ieee80211_setmode(ic, IEEE80211_MODE_11A); - else if (IEEE80211_IS_CHAN_G(ni->ni_chan)) - ieee80211_setmode(ic, IEEE80211_MODE_11G); - else - ieee80211_setmode(ic, IEEE80211_MODE_11B); - } + (ni->ni_flags & IEEE80211_NODE_HT) == 0) + ieee80211_setmode(ic, ieee80211_chan2mode(ic, ni->ni_chan)); #endif /* * Configure state now that we are associated. Index: ieee80211_proto.c === RCS file: /cvs/src/sys/net80211/ieee80211_proto.c,v retrieving revision 1.56 diff -u -p -r1.56 ieee80211_proto.c --- ieee80211_proto.c 24 Nov 2015 13:45:06 - 1.56 +++ ieee80211_proto.c 17 Dec 2015 20:58:40 - @@ -894,15 +894,8 @@ justclea
Re: [patch] malloc: size that was passed to free() should land into the same bucket
On Thu, Dec 17, 2015 at 9:01 PM, Ted Unangst wrote: > Maxim Pugachev wrote: >> On Sun, Dec 13, 2015 at 10:38 PM, Ted Unangst wrote: >> > Maxim Pugachev wrote: >> >> Currently two checks in free() function confirm the correctness of >> >> freedsize argument. I think that it's better to check that provided >> >> freedsize fall into the same bucket that was recorded in kmemusage >> >> struct: it covers both cases. >> > >> > I don't know. This doesn't seem clearer to me. An error message with >> > bucket numbers isn't any more helpful. >> >> Ted, thank you for your comments! >> >> I can compare the buckets to generate a clearer message, but you're >> right, it'll look a bit complicated. >> >> I've read this code again and I think there is an error in a second >> check ("size too small"). For example, if freedsize = 2048 and size = >> 4096, then panic will not fire because "freedsize < size / 2" is >> false. But I guess it should, because BUCKETINDX(2048) == 11, but >> BUCKETINDX(4096) == 12. >> >> What do you think? > > I remember thinking about this before. I forgot what I thought though. > > Is there some case where the correct size is 1/2? I can't think of any. I'm sorry, but I think I don't understand your question.
Re: Allocation type in kern/exec_elf.c
On Thu, Dec 17, 2015 at 8:21 PM, Ted Unangst wrote: > Maxim Pugachev wrote: >> Hey all, >> >> I'm wondering, why an allocation type in kern/exec_elf.c is equal to >> M_TEMP? For instance, kern/exec_script.c and kern/kern_exec.c allocate >> memory as M_EXEC, and it looks more reasonable to me. >> >> What's the reason for this? > > I think the reason is M_TEMP is for any data that is short lived (will be > freed in the same function) and other types like M_EXEC are for data that > lasts longer. But this policy is not consistent, so there's lots of > counterexamples. Now it's clear, thank you!
scan regression fixes
This should fix the infinite scanning loops people have been reporting with 11n-enabled iwn(4), as well as the issue where clients associating to 11g APs end up in 11b mode and can't use OFDM data rates. ok? Index: ieee80211.c === RCS file: /cvs/src/sys/net80211/ieee80211.c,v retrieving revision 1.52 diff -u -p -r1.52 ieee80211.c --- ieee80211.c 16 Dec 2015 12:52:03 - 1.52 +++ ieee80211.c 17 Dec 2015 18:35:27 - @@ -874,6 +874,14 @@ ieee80211_next_mode(struct ifnet *ifp) /* Wrap around and ignore turbo mode */ if (ic->ic_curmode == IEEE80211_MODE_TURBO) continue; +#ifndef IEEE80211_NO_HT + /* +* Skip 11n mode while scanning. Its set of channels is +* the superset of all channels supported by other modes. +*/ + if (ic->ic_curmode == IEEE80211_MODE_11N) + continue; +#endif if (ic->ic_curmode >= IEEE80211_MODE_MAX) { ic->ic_curmode = IEEE80211_MODE_AUTO; break; @@ -893,6 +901,11 @@ ieee80211_next_mode(struct ifnet *ifp) * caller can select a rate set. This is problematic and the * work here assumes how things work elsewhere in this code. * + * Because the result of this function is ultimately used to select + * a rate from the rate set of the returned mode, it must not return + * IEEE802_MODE_11N. This funcion may be called in 11n mode to find + * a non-MCS rate to use for sending frames to non-HT STAs. + * * XXX never returns turbo modes -dcy */ enum ieee80211_phymode @@ -911,11 +924,6 @@ ieee80211_chan2mode(struct ieee80211com * characteristics. We assume that turbo-only channels * are not considered when the channel set is constructed. */ -#ifndef IEEE80211_NO_HT - if (IEEE80211_IS_CHAN_N(chan)) - return IEEE80211_MODE_11N; - else -#endif if (IEEE80211_IS_CHAN_T(chan)) return IEEE80211_MODE_TURBO; else if (IEEE80211_IS_CHAN_5GHZ(chan)) Index: ieee80211_input.c === RCS file: /cvs/src/sys/net80211/ieee80211_input.c,v retrieving revision 1.145 diff -u -p -r1.145 ieee80211_input.c --- ieee80211_input.c 12 Dec 2015 13:56:10 - 1.145 +++ ieee80211_input.c 17 Dec 2015 18:42:06 - @@ -2257,16 +2257,8 @@ ieee80211_recv_assoc_resp(struct ieee802 /* Hop out of 11n mode after associating to a non-HT AP. */ if (ic->ic_curmode == IEEE80211_MODE_11N && - (ni->ni_flags & IEEE80211_NODE_HT) == 0) { - if (IEEE80211_IS_CHAN_T(ni->ni_chan)) - ieee80211_setmode(ic, IEEE80211_MODE_TURBO); - else if (IEEE80211_IS_CHAN_A(ni->ni_chan)) - ieee80211_setmode(ic, IEEE80211_MODE_11A); - else if (IEEE80211_IS_CHAN_G(ni->ni_chan)) - ieee80211_setmode(ic, IEEE80211_MODE_11G); - else - ieee80211_setmode(ic, IEEE80211_MODE_11B); - } + (ni->ni_flags & IEEE80211_NODE_HT) == 0) + ieee80211_setmode(ic, ieee80211_chan2mode(ic, ni->ni_chan)); #endif /* * Configure state now that we are associated.
Re: initial 11n support for iwn (n, not m)
On 12/16/15 15:35, Stefan Sperling wrote: This diff adds 11n MCS 0-7 with A-MPDU and A-MSDU Rx to the iwn(4) driver. It also tweaks replay detection for CCMP encrypted frames, which needed tweaking for A-MPDU anyway (see comments in code). Even in non-11n modes this driver was discarding some retransmitted frames for no good reason. This driver supports a very wide range of hardware so please test this with as many iwn(4) adapters as possible. If we don't get enough tests this change may not be able to make the 5.9 release. Works for me on: iwn0 at pci3 dev 0 function 0 "Intel Centrino Advanced-N 6200" rev 0x35: msi, MIMO 2T2R, MoW Please post here or let me know in private which hardware you're testing on. Thanks. Note that if you'd like to test monitor mode you'll need to apply this to a -current source tree from today. Thanks for you work on this! I've tested it on my laptop and it gives me firmware errors. I've attached dmesg from both a the working and the patched, non-working kernels. Let me know if you need any other information. Frank OpenBSD 5.8-current (GENERIC.MP) #1737: Thu Dec 10 23:29:07 MST 2015 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4157837312 (3965MB) avail mem = 4027703296 (3841MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeba60 (23 entries) bios0: vendor American Megatrends Inc. version "UX31A.219" date 06/14/2013 bios0: ASUSTeK COMPUTER INC. UX31A acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT ECDT MCFG SSDT SSDT SSDT SSDT HPET SSDT SSDT SSDT SSDT DMAR MSDM acpi0: wakeup devices P0P1(S4) PEG0(S4) PEG1(S4) PEG2(S4) PEG3(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) EHC2(S3) USB5(S3) USB6(S3) USB7(S3) HDEF(S4) RP01(S4) RP02(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-3517U CPU @ 1.90GHz, 1796.22 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,OSXSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-3517U CPU @ 1.90GHz, 1795.92 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,OSXSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM) i7-3517U CPU @ 1.90GHz, 1795.92 MHz cpu2: 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,OSXSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i7-3517U CPU @ 1.90GHz, 1795.92 MHz cpu3: 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,OSXSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpiec0 at acpi0 acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P1) acpiprt2 at acpi0: bus -1 (PEG0) acpiprt3 at acpi0: bus -1 (PEG1) acpiprt4 at acpi0: bus -1 (PEG2) acpiprt5 at acpi0: bus -1 (PEG3) acpiprt6 at acpi0: bus 1 (RP01) acpiprt7 at acpi0: bus 2 (RP02) acpiprt8 at acpi0: bus -1 (RP03) acpiprt9 at acpi0: bus -1 (RP04) acpiprt10 at acpi0: bus -1 (RP05) acpiprt11 at acpi0: bus -1 (RP06) acpiprt12 at acpi0: bus -1 (RP07) acpiprt13 at acpi0: bus -1 (RP08) acpicpu0 at acpi0: C3(200@87 mwait.1@0x30), C2(500@59 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(200@87 mwait.1@0x30), C2(500@59 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C3(200@87 mwait.1@0x30), C2(500@59 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C3(200@87 mwa
Re: [patch] malloc: size that was passed to free() should land into the same bucket
Maxim Pugachev wrote: > On Sun, Dec 13, 2015 at 10:38 PM, Ted Unangst wrote: > > Maxim Pugachev wrote: > >> Currently two checks in free() function confirm the correctness of > >> freedsize argument. I think that it's better to check that provided > >> freedsize fall into the same bucket that was recorded in kmemusage > >> struct: it covers both cases. > > > > I don't know. This doesn't seem clearer to me. An error message with > > bucket numbers isn't any more helpful. > > Ted, thank you for your comments! > > I can compare the buckets to generate a clearer message, but you're > right, it'll look a bit complicated. > > I've read this code again and I think there is an error in a second > check ("size too small"). For example, if freedsize = 2048 and size = > 4096, then panic will not fire because "freedsize < size / 2" is > false. But I guess it should, because BUCKETINDX(2048) == 11, but > BUCKETINDX(4096) == 12. > > What do you think? I remember thinking about this before. I forgot what I thought though. Is there some case where the correct size is 1/2? I can't think of any.
Re: [patch] kern/exec_script: return error when the shell name is not specified
Maxim Pugachev wrote: > Ping? > > On Sun, Dec 13, 2015 at 12:28 AM, Maxim Pugachev > wrote: > > Hi, > > > > In a case when the shell name is not specified (i.e. just "#!" without > > a path), don't run the heavy logic that checks shell, simply return > > ENOENT. > > > > Also, as a tiny improvement: avoid a loop when calculating shell's args > > length. Not forgotten. Just not a very pretty file to look at. :)
Re: Allocation type in kern/exec_elf.c
Maxim Pugachev wrote: > Hey all, > > I'm wondering, why an allocation type in kern/exec_elf.c is equal to > M_TEMP? For instance, kern/exec_script.c and kern/kern_exec.c allocate > memory as M_EXEC, and it looks more reasonable to me. > > What's the reason for this? I think the reason is M_TEMP is for any data that is short lived (will be freed in the same function) and other types like M_EXEC are for data that lasts longer. But this policy is not consistent, so there's lots of counterexamples.
Re: [patch] Convert modulus to arc4random_uniform
Theo Buehler wrote: > I've now committed most of your diff, thanks once again. > > o I asked for further review on the kernel parts > o I'm going to skip hack for now > > Here's a patch for libc, based on the previous discussion. > I think this is easier to read and understand. No binary change on > amd64. > > ok? sure. the current code is safer for other values of randmax, but that seems an unlikely problem.
filedesc: size for free
hello, The following patch passes the correct size to free(9) for a filedesc's klist. Index: kern_descrip.c === RCS file: /cvs/src/sys/kern/kern_descrip.c,v retrieving revision 1.125 diff -u -p -r1.125 kern_descrip.c --- kern_descrip.c 5 Dec 2015 10:11:53 - 1.125 +++ kern_descrip.c 17 Dec 2015 15:16:00 - @@ -1093,7 +1093,7 @@ fdfree(struct proc *p) if (fdp->fd_rdir) vrele(fdp->fd_rdir); if (fdp->fd_knlist) - free(fdp->fd_knlist, M_TEMP, 0); + free(fdp->fd_knlist, M_TEMP, fdp->fd_knlistsize * sizeof(struct klist)); if (fdp->fd_knhash) free(fdp->fd_knhash, M_TEMP, 0); pool_put(&fdesc_pool, fdp); Index: kern_event.c === RCS file: /cvs/src/sys/kern/kern_event.c,v retrieving revision 1.67 diff -u -p -r1.67 kern_event.c --- kern_event.c5 Dec 2015 10:11:53 - 1.67 +++ kern_event.c17 Dec 2015 15:16:02 - @@ -1021,7 +1021,8 @@ knote_attach(struct knote *kn, struct fi memset(&list[fdp->fd_knlistsize], 0, (size - fdp->fd_knlistsize) * sizeof(struct klist)); if (fdp->fd_knlist != NULL) - free(fdp->fd_knlist, M_TEMP, 0); + free(fdp->fd_knlist, M_TEMP, + fdp->fd_knlistsize * sizeof(struct klist)); fdp->fd_knlistsize = size; fdp->fd_knlist = list; }
Re: initial 11n support for iwn - defunc: Intel WiFi Link 5300 rev 0x00
On Thu, Dec 17, 2015 at 12:40:48PM +0100, Marcus MERIGHI wrote: > iwn0: sending auth to 80:1f:02:c1:fd:86 on channel 5 mode 11b > iwn0: sending assoc_req to 80:1f:02:c1:fd:86 on channel 5 mode 11b > iwn0: received auth from 80:1f:02:c1:fd:86 rssi -54 mode 11b > iwn0: association failed (status 18) for 80:1f:02:c1:fd:86 IEEE80211_STATUS_BASIC_RATE = 18, This could mean we're sending a bad basic rate element in association requests while in 11n mode. I'll investigate. Is your AP restricting clients to a particular mode, like 11g-only? Perhaps it means your AP requires clients to support MCS higher than MCS 7, which we don't support yet? Can you somehow change AP settings in this regard?
Re: initial 11n support for iwn - defunc: Intel WiFi Link 5300 rev 0x00
On 2015/12/17 13:22, Stefan Sperling wrote: > On Thu, Dec 17, 2015 at 12:40:48PM +0100, Marcus MERIGHI wrote: > > iwn0: sending auth to 80:1f:02:c1:fd:86 on channel 5 mode 11b > > iwn0: sending assoc_req to 80:1f:02:c1:fd:86 on channel 5 mode 11b > > iwn0: received auth from 80:1f:02:c1:fd:86 rssi -54 mode 11b > > iwn0: association failed (status 18) for 80:1f:02:c1:fd:86 > > IEEE80211_STATUS_BASIC_RATE = 18, > > This could mean we're sending a bad basic rate element in > association requests while in 11n mode. I'll investigate. > > Is your AP restricting clients to a particular mode, like 11g-only? > Perhaps it means your AP requires clients to support MCS higher > than MCS 7, which we don't support yet? > > Can you somehow change AP settings in this regard? > It seems that some APs get upset if you send rates that are not in their advertised list. https://supportforums.cisco.com/document/141136/80211-association-status-80211-deauth-reason-codes says "Will happen if the rates in the assoc request are not in the BasicRateSet in the beacon" for this. We don't do much decode of assoc requests in tcpdump at the moment. Marcus, it might be useful to get a pcap file (tcpdump -s1500 -iiwn0 -yIEEE802_11_RADIO -w /tmp/iwn.pcap) from while it's trying to associate - if you send it to me off list (and probably best to cc stsp) I can take a look and see if I spot anything.
Re: Thinkpad display brightness control
> From: Christian Weisgerber > Date: Thu, 17 Dec 2015 11:50:53 + (UTC) > > On 2015-12-16, Mark Kettenis wrote: > > > The downside of this diff is that number of levels is limited to 16 > > whereas we currently have much finer granularity. But I think that is > > acceptable. The levels are probably better calibrated and we now have > > proper coordination between the OS and the firmware when it comes to > > brightness changes. > > I'm in favor of this change since it fixes various niggling problems. > > FWIW, the 16 levels also scale differently than the previous range. > Stepping through with the brightness keys on my X230, I get > respectively this: > >new old > 0.00% 1.17% min > 6.66% 2.34% > 13.33% 3.51% > 20.00% 4.68% > 26.66% 5.88% > 33.33% 7.43% > 40.00% 9.01% > 46.66% 10.97% > 53.33% 12.93% > 60.00% 15.68% > 66.66% 19.60% > 73.33% 25.49% > 80.00% 34.50% > 86.66% 49.01% > 93.33% 72.54% > 100.00% 100.00% max > > For instance, if you previously used wsconsctl display.brightness=20%, > you'd now find your display much darker and would want to use 67% > instead. Indeed. As far as the brightness keys are concerned, the actual levels should be the same, but they translate into different percentages. Also thanks for pointing out the issue with the thinkpad_get_param() code. I've committed a version with that fixed.
initial 11n support for iwn (n, not m)
Thanks Stefan! Works on my Thinkpad X220. iwn0 at pci2 dev 0 function 0 "Intel WiFi Link 1000" rev 0x00: msi, MIMO 1T2R, BGS, address 74:e5:0b:c6:3c:c8 dmesg: OpenBSD 5.8-current (GENERIC.MP) #1752: Thu Dec 17 01:17:05 MST 2015 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP RTC BIOS diagnostic error 80 real mem = 8451125248 (8059MB) avail mem = 8190865408 (7811MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdae9c000 (64 entries) bios0: vendor LENOVO version "8DET69WW (1.39 )" date 07/18/2013 bios0: LENOVO 4291G36 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC SSDT SSDT SSDT HPET APIC MCFG ECDT ASF! TCPA SSDT SSDT DMAR UEFI UEFI UEFI acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP4(S4) EXP7(S4) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2492.24 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.92 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.92 MHz cpu2: 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.92 MHz cpu3: 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiec0 at acpi0 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 2 (EXP1) acpiprt3 at acpi0: bus 3 (EXP2) acpiprt4 at acpi0: bus 5 (EXP4) acpiprt5 at acpi0: bus 13 (EXP5) acpiprt6 at acpi0: bus -1 (EXP7) acpicpu0 at acpi0: C3(350@104 io@0x415), C1(1000@1 halt), PSS acpicpu1 at acpi0: C3(350@104 io@0x415), C1(1000@1 halt), PSS acpicpu2 at acpi0: C3(350@104 io@0x415), C1(1000@1 halt), PSS acpicpu3 at acpi0: C3(350@104 io@0x415), C1(1000@1 halt), PSS acpipwrres0 at acpi0: PUBS, resource for EHC1, EHC2 acpitz0 at acpi0: critical temperature is 99 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model "42T4940" serial 4448 type LION oem "SANYO" acpibat1 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 acpidock0 at acpi0: GDCK not docked (0) cpu0: Enhanced SpeedStep 2492 MHz: speeds: 2501, 2500, 2200, 2000, 1800, 1600, 1400, 1200, 1000, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 2G Host" rev 0x09 inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 3000" rev 0x09 drm0 at inteldrm0 inteldrm0: msi inteldrm0: 1366x768 wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) "Intel 6 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured em0 at pci0 dev 25 function 0 "Intel 82579LM" rev 0x04: msi, address f0:de:f1:d1:94:39 ehci0 at pci0 dev 26 function 0 "Intel 6 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 azalia0 at pci0 dev 27 function 0 "Intel 6 Series HD Audio" rev 0x04: msi azalia0: codecs: Conexant CX20590, Intel/0x2805, using Conexant CX20590 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 "Intel 6 Series PCIE" rev 0xb4: msi pci1 at ppb0 bus 2 ppb1 at pci0 dev 28 function 1 "Intel 6 Series PCIE" rev 0xb4: msi
Re: Thinkpad display brightness control
On 2015-12-16, Mark Kettenis wrote: > The downside of this diff is that number of levels is limited to 16 > whereas we currently have much finer granularity. But I think that is > acceptable. The levels are probably better calibrated and we now have > proper coordination between the OS and the firmware when it comes to > brightness changes. I'm in favor of this change since it fixes various niggling problems. FWIW, the 16 levels also scale differently than the previous range. Stepping through with the brightness keys on my X230, I get respectively this: new old 0.00% 1.17% min 6.66% 2.34% 13.33% 3.51% 20.00% 4.68% 26.66% 5.88% 33.33% 7.43% 40.00% 9.01% 46.66% 10.97% 53.33% 12.93% 60.00% 15.68% 66.66% 19.60% 73.33% 25.49% 80.00% 34.50% 86.66% 49.01% 93.33% 72.54% 100.00% 100.00% max For instance, if you previously used wsconsctl display.brightness=20%, you'd now find your display much darker and would want to use 67% instead. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: initial 11n support for iwn - defunc: Intel WiFi Link 5300 rev 0x00
s...@stsp.name (Stefan Sperling), 2015.12.16 (Wed) 15:35 (CET): > This diff adds 11n MCS 0-7 with A-MPDU and A-MSDU Rx to the iwn(4) driver. > > It also tweaks replay detection for CCMP encrypted frames, which needed > tweaking for A-MPDU anyway (see comments in code). Even in non-11n modes > this driver was discarding some retransmitted frames for no good reason. > > This driver supports a very wide range of hardware so please test this > with as many iwn(4) adapters as possible. If we don't get enough tests > this change may not be able to make the 5.9 release. > > Works for me on: > iwn0 at pci3 dev 0 function 0 "Intel Centrino Advanced-N 6200" rev 0x35: msi, > MIMO 2T2R, MoW > > Please post here or let me know in private which hardware you're > testing on. Thanks. iwn0 at pci2 dev 0 function 0 "Intel WiFi Link 5300" rev 0x00: msi, MIMO 3T3R, MoW, address 00:21:6a:8c:3d:9c Does not link up with my access point as usual. An usb wifi dongle (run) does, contents of hostname.if are the same. iwn0 in debug mode says: iwn0: sending auth to 80:1f:02:c1:fd:86 on channel 5 mode 11b iwn0: sending assoc_req to 80:1f:02:c1:fd:86 on channel 5 mode 11b iwn0: received auth from 80:1f:02:c1:fd:86 rssi -54 mode 11b iwn0: association failed (status 18) for 80:1f:02:c1:fd:86 Fetched bsd.rd from ftp.openbsd.org directly. No mirror had the Dec 17 1:17 build already. Booted from SSD/bsd.rd and installed onto USB Stick. Booted from USB, ran fw_update -a. dmesg of three boots: install, normal boot, normal boot with iwn debug. followed by pcidump and usbdevs. acpidump available. Bye, Marcus OpenBSD 5.8-current (RAMDISK_CD) #1587: Thu Dec 17 01:22:12 MST 2015 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 4166717440 (3973MB) avail mem = 4038721536 (3851MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (68 entries) bios0: vendor LENOVO version "6DET72WW (3.22 )" date 10/25/2012 bios0: LENOVO 7470W1W acpi0 at bios0: rev 2 acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA DMAR SSDT SSDT SSDT 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 L9400 @ 1.86GHz, 1862.29 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,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR cpu0: 6MB 64b/line 16-way L2 cache cpu0: apic clock running at 265MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE cpu at mainbus0: not configured ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 2, remapped to apid 1 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) 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 wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation) "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 em0 at pci0 dev 25 function 0 "Intel ICH9 IGP M AMT" rev 0x03: msi, address 00:1f:16:32:df:5c 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" rev 0x03: apic 1 int 22 ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x03: apic 1 int 23 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 "Intel 82801I HD Audio" rev 0x03 at pci0 dev 27 function 0 not configured ppb0 at pci0 dev 28 function 0 "Intel 82801I PCIE" rev 0x03: msi pci1 at ppb0 bus 2 ppb1 at pci0 dev 28 function 1 "Intel 82801I PCIE" rev 0x03: msi pci2 at ppb1 bus 3 iwn0 at pci2 dev 0 function 0 "Intel WiFi Link 5300" rev 0x00: msi, MIMO 3T3R, MoW, address 00:21:6a:8c:3d:9c ppb2 at pci0 dev 28 function 3 "Intel 82801I PCIE" rev 0x03: msi pci3 at ppb2 bus 5 uhci3 at pci0 dev 29 function 0 "Intel 82801I USB" rev 0x03: apic 1 int 16 uhci4 at pci0 dev 29 function 1 "Intel 82801I USB" rev 0x03: apic 1 int 17 uhci5 at pci0 dev 29 function 2 "Intel 82801I USB" rev 0x03: apic 1 int 18 ehci1 at pci0 dev 29 function 7 "Intel 82801I USB" rev 0x03: apic 1 int 19 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 "Intel EHCI root hub" rev 2.00/1.00 addr 1 ppb3 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0x93 pci4 at ppb3 bus 13 "Intel 82801IEM LPC" rev 0x03 at pci0 dev 31 function 0 not configured ahci0 at pci0 dev 31 function 2 "Intel 82801I AHCI" rev 0x03: msi, AHCI 1.2 ahci0: port 0: 3.0Gb/s scsibus0 at ahci0: 32 targets sd0 at scsibus0 targ 0 lun 0: SCSI3 0/direct fixed naa.5001b44e1d7ef244 sd0: 228936MB, 512 bytes/sect
bus_dma: Size for free
Here is a diff to pass around the size to free(9) in amd64's _bus_dmamap allocations. i386 is symmetric but I don't have the hardware currently to test it. Index: bus_dma.c === RCS file: /cvs/src/sys/arch/amd64/amd64/bus_dma.c,v retrieving revision 1.48 diff -u -p -r1.48 bus_dma.c --- bus_dma.c 27 Jan 2015 05:10:30 - 1.48 +++ bus_dma.c 17 Dec 2015 11:16:34 - @@ -149,8 +149,11 @@ _bus_dmamap_create(bus_dma_tag_t t, bus_ void _bus_dmamap_destroy(bus_dma_tag_t t, bus_dmamap_t map) { - - free(map, M_DEVBUF, 0); + size_t mapsize; + + mapsize = sizeof(struct bus_dmamap) + + (sizeof(bus_dma_segment_t) * (map->_dm_segcnt - 1)); + free(map, M_DEVBUF, mapsize); } /*
Re: Fix csqrt(3)
On Thu, Nov 26, 2015 at 09:02:17PM +0500, Alexandr Shadchin wrote: > From http://en.cppreference.com/w/c/numeric/complex/csqrt : > > csqrt(conj(z)) == conj(csqrt(z)) > > Before patch > csqrt(-4.0 + -0.0i) = 0.0 + 2.0j > but should be > csqrt(-4.0 + -0.0i) = 0.0 - 2.0j This, too, looks right to me. FWIW: ok tb@ > > -- > Alexandr Shadchin > > Index: lib/libm/src/s_csqrt.c > === > RCS file: /cvs/src/lib/libm/src/s_csqrt.c,v > retrieving revision 1.6 > diff -u -p -r1.6 s_csqrt.c > --- lib/libm/src/s_csqrt.c3 Jul 2013 04:46:36 - 1.6 > +++ lib/libm/src/s_csqrt.c24 Nov 2015 08:45:25 - > @@ -79,7 +79,7 @@ csqrt(double complex z) > r = fabs (x); > r = sqrt (r); > if (x < 0.0) { > - w = 0.0 + r * I; > + w = 0.0 + copysign(r, y) * I; > } > else { > w = r + y * I; > Index: lib/libm/src/s_csqrtf.c > === > RCS file: /cvs/src/lib/libm/src/s_csqrtf.c,v > retrieving revision 1.2 > diff -u -p -r1.2 s_csqrtf.c > --- lib/libm/src/s_csqrtf.c 18 Jul 2010 18:42:26 - 1.2 > +++ lib/libm/src/s_csqrtf.c 24 Nov 2015 08:45:25 - > @@ -72,7 +72,7 @@ csqrtf(float complex z) > > if(y == 0.0f) { > if (x < 0.0f) { > - w = 0.0f + sqrtf(-x) * I; > + w = 0.0f + copysign(sqrtf(-x), y) * I; > return (w); > } > else if (x == 0.0f) { > Index: lib/libm/src/s_csqrtl.c > === > RCS file: /cvs/src/lib/libm/src/s_csqrtl.c,v > retrieving revision 1.2 > diff -u -p -r1.2 s_csqrtl.c > --- lib/libm/src/s_csqrtl.c 20 Jul 2011 19:28:33 - 1.2 > +++ lib/libm/src/s_csqrtl.c 24 Nov 2015 08:45:25 - > @@ -72,7 +72,7 @@ csqrtl(long double complex z) > > if (y == 0.0L) { > if (x < 0.0L) { > - w = 0.0L + sqrtl(-x) * I; > + w = 0.0L + copysign(sqrtl(-x), y) * I; > return (w); > } > else { >
Re: Fix casin(3)
On Fri, Nov 27, 2015 at 03:14:52PM +0500, Alexandr Shadchin wrote: > Fix wrong answer if the imaginary part is zero. > NetBSD also turn off this piece of code. > > See > http://en.cppreference.com/w/c/numeric/complex/casin > http://www.wolframalpha.com/input/?i=asin%28-2.0%29 Makes complete sense to me. FWIW: ok tb@ > > -- > Alexandr Shadchin > > Index: s_casin.c > === > RCS file: /cvs/src/lib/libm/src/s_casin.c,v > retrieving revision 1.6 > diff -u -p -r1.6 s_casin.c > --- s_casin.c 3 Jul 2013 04:46:36 - 1.6 > +++ s_casin.c 27 Nov 2015 09:59:45 - > @@ -63,6 +63,7 @@ casin(double complex z) > x = creal (z); > y = cimag (z); > > +#if 0 > if (y == 0.0) { > if (fabs(x) > 1.0) { > w = M_PI_2 + 0.0 * I; > @@ -73,6 +74,7 @@ casin(double complex z) > } > return (w); > } > +#endif > > /* Power series expansion */ > /* > Index: s_casinf.c > === > RCS file: /cvs/src/lib/libm/src/s_casinf.c,v > retrieving revision 1.3 > diff -u -p -r1.3 s_casinf.c > --- s_casinf.c20 Jul 2011 19:28:33 - 1.3 > +++ s_casinf.c27 Nov 2015 09:59:45 - > @@ -65,6 +65,7 @@ casinf(float complex z) > x = crealf(z); > y = cimagf(z); > > +#if 0 > if(y == 0.0f) { > if(fabsf(x) > 1.0f) { > w = (float)M_PI_2 + 0.0f * I; > @@ -75,6 +76,7 @@ casinf(float complex z) > } > return (w); > } > +#endif > > /* Power series expansion */ > /* > Index: s_casinl.c > === > RCS file: /cvs/src/lib/libm/src/s_casinl.c,v > retrieving revision 1.3 > diff -u -p -r1.3 s_casinl.c > --- s_casinl.c20 Jul 2011 21:02:51 - 1.3 > +++ s_casinl.c27 Nov 2015 09:59:45 - > @@ -71,6 +71,7 @@ casinl(long double complex z) > x = creall(z); > y = cimagl(z); > > +#if 0 > if (y == 0.0L) { > if (fabsl(x) > 1.0L) { > w = PIO2L + 0.0L * I; > @@ -81,6 +82,7 @@ casinl(long double complex z) > } > return (w); > } > +#endif > > /* Power series expansion */ > b = cabsl(z); >
Re: [patch] Convert modulus to arc4random_uniform
I've now committed most of your diff, thanks once again. o I asked for further review on the kernel parts o I'm going to skip hack for now Here's a patch for libc, based on the previous discussion. I think this is easier to read and understand. No binary change on amd64. ok? Index: lib/libc/stdlib/rand.c === RCS file: /var/cvs/src/lib/libc/stdlib/rand.c,v retrieving revision 1.15 diff -u -p -r1.15 rand.c --- lib/libc/stdlib/rand.c 13 Sep 2015 08:31:47 - 1.15 +++ lib/libc/stdlib/rand.c 16 Dec 2015 08:02:41 - @@ -37,7 +37,7 @@ int rand_r(u_int *seed) { *seed = *seed * 1103515245 + 12345; - return (*seed % ((u_int)RAND_MAX + 1)); + return (*seed & RAND_MAX); } DEF_WEAK(rand_r); @@ -50,7 +50,7 @@ int rand(void) { if (rand_deterministic == 0) - return (arc4random() % ((u_int)RAND_MAX + 1)); + return (arc4random() & RAND_MAX); return (rand_r(&next)); }
Re: rtdeletemsg & KASSERT
On 16/12/15(Wed) 23:57, Alexander Bluhm wrote: > On Wed, Dec 16, 2015 at 09:46:26PM +0100, Alexander Bluhm wrote: > > 10.188.70.17 fe:e1:ba:d0:d5:6d UHLS 03 - 8 vio0 > > This is this route that crashed the machine when the arp entry expired. > > When I move the rtref()/rtfree() calls into rtdeletemsg() it also > protects the calls from arptfree(). > > > __assert() at __assert+0x25 > > rtfree() at rtfree+0x11e > > rtable_delete() at rtable_delete+0x5d > > rt_delete() at rt_delete+0x6e > > rtdeletemsg() at rtdeletemsg+0x2d > > arptfree() at arptfree+0x4f > > arptimer() at arptimer+0x63 > > After rt_delete() has called rtable_delete(), the route is still > used and should not be destroyed. The diff below indeed corrects that, but I found another bug in it. The problem is that rtable_lookup() might return a non perfect match so we would now end up deleting the RTF_CLONING route instead of failing. The proper solution would be to always pass a mask (or prefix length) to rtable_lookup(). > Index: net/route.c > === > RCS file: /data/mirror/openbsd/cvs/src/sys/net/route.c,v > retrieving revision 1.292 > diff -u -p -r1.292 route.c > --- net/route.c 11 Dec 2015 08:58:23 - 1.292 > +++ net/route.c 16 Dec 2015 22:42:34 - > @@ -159,8 +159,7 @@ struct sockaddr *rt_plentosa(sa_family_t > > struct ifaddr *ifa_ifwithroute(int, struct sockaddr *, struct sockaddr > *, > u_int); > -int rtrequest_delete(struct rt_addrinfo *, u_int8_t, struct ifnet *, > - struct rtentry **, u_int); > +int rt_delete(struct rtentry *, struct ifnet *, unsigned int); > > #ifdef DDB > void db_print_sa(struct sockaddr *); > @@ -613,34 +612,22 @@ out: > } > > /* > - * Delete a route and generate a message > + * Delete a route and generate a message. The caller must hold a reference > + * on ``rt''. > */ > int > -rtdeletemsg(struct rtentry *rt, struct ifnet *ifp, u_int tableid) > +rtdeletemsg(struct rtentry *rt, struct ifnet *ifp, unsigned int rtableid) > { > int error; > - struct rt_addrinfo info; > - unsigned intifidx; > - struct sockaddr_in6 sa_mask; > > KASSERT(rt->rt_ifidx == ifp->if_index); > > - /* > - * Request the new route so that the entry is not actually > - * deleted. That will allow the information being reported to > - * be accurate (and consistent with route_output()). > - */ > - bzero((caddr_t)&info, sizeof(info)); > - info.rti_info[RTAX_DST] = rt_key(rt); > - if (!ISSET(rt->rt_flags, RTF_HOST)) > - info.rti_info[RTAX_NETMASK] = rt_plen2mask(rt, &sa_mask); > - info.rti_info[RTAX_GATEWAY] = rt->rt_gateway; > - info.rti_flags = rt->rt_flags; > - ifidx = rt->rt_ifidx; > - error = rtrequest_delete(&info, rt->rt_priority, ifp, &rt, tableid); > - rt_missmsg(RTM_DELETE, &info, info.rti_flags, ifidx, error, tableid); > + rtref(rt); > + error = rt_delete(rt, ifp, rtableid); > if (error == 0) > - rtfree(rt); > + rt_sendmsg(rt, RTM_DELETE, rtableid); > + rtfree(rt); > + > return (error); > } > > @@ -671,10 +658,10 @@ rtflushclone1(struct rtentry *rt, void * >* the routes are being purged by rt_if_remove(). >*/ > if (ifp == NULL) > - return 0; > + return 0; > > if (ISSET(rt->rt_flags, RTF_CLONED) && rtequal(rt->rt_parent, parent)) > - rtdeletemsg(rt, ifp, id); > + rtdeletemsg(rt, ifp, id); > > if_put(ifp); > return 0; > @@ -818,60 +805,20 @@ rt_getifa(struct rt_addrinfo *info, u_in > } > > int > -rtrequest_delete(struct rt_addrinfo *info, u_int8_t prio, struct ifnet *ifp, > -struct rtentry **ret_nrt, u_int tableid) > +rt_delete(struct rtentry *rt, struct ifnet *ifp, unsigned int rtableid) > { > - struct rtentry *rt; > - int error; > - > - splsoftassert(IPL_SOFTNET); > - > - if (!rtable_exists(tableid)) > - return (EAFNOSUPPORT); > - rt = rtable_lookup(tableid, info->rti_info[RTAX_DST], > - info->rti_info[RTAX_NETMASK], info->rti_info[RTAX_GATEWAY], prio); > - if (rt == NULL) > - return (ESRCH); > - > - /* Make sure that's the route the caller want to delete. */ > - if (ifp != NULL && ifp->if_index != rt->rt_ifidx) { > - rtfree(rt); > - return (ESRCH); > - } > + struct sockaddr_in6 sa_mask; > > -#ifndef SMALL_KERNEL > - /* > - * If we got multipath routes, we require users to specify > - * a matching gateway. > - */ > - if ((rt->rt_flags & RTF_MPATH) && > - info->rti_info[RTAX_GATEWAY] == NULL) { > - rtfree(rt); > - return (ESRCH); > - } > -#endif > + KASSERT(ifp->if_index == rt->rt_ifidx); > > - /* > -
Re: Do not grab the KERNEL_LOCK() in rtalloc(9)
I don’t have MPLS. No regression. > On 4 dec. 2015, at 14:51, Martin Pieuchot wrote: > > To reduce contention in the fast path we can use a mutex(9) to serialize > read/write operations on the radix tree instead of the KERNEL_LOCK. > > Note that the KERNEL_LOCK is still needed to serialize walk/delete/insert > because a call to rtable_delete() can be made inside rtable_walk(), and > we cannot use a mutex for such recursive problem. > > I'd be interested to know if this helps MPLS fowarding. > > Index: net/rtable.c > === > RCS file: /cvs/src/sys/net/rtable.c,v > retrieving revision 1.33 > diff -u -p -r1.33 rtable.c > --- net/rtable.c 4 Dec 2015 13:42:48 - 1.33 > +++ net/rtable.c 4 Dec 2015 13:45:53 - > @@ -292,6 +292,10 @@ rtable_l2set(unsigned int rtableid, unsi > } > > #ifndef ART > +#include > + > +struct mutex rn_mtx = MUTEX_INITIALIZER(IPL_NONE); > + > void > rtable_init_backend(unsigned int keylen) > { > @@ -319,15 +323,16 @@ rtable_lookup(unsigned int rtableid, str > { > struct radix_node_head *rnh; > struct radix_node *rn; > - struct rtentry *rt; > + struct rtentry *rt = NULL; > > rnh = rtable_get(rtableid, dst->sa_family); > if (rnh == NULL) > return (NULL); > > + mtx_enter(&rn_mtx); > rn = rn_lookup(dst, mask, rnh); > if (rn == NULL || (rn->rn_flags & RNF_ROOT) != 0) > - return (NULL); > + goto out; > > rt = ((struct rtentry *)rn); > > @@ -335,11 +340,13 @@ rtable_lookup(unsigned int rtableid, str > if (rnh->rnh_multipath) { > rt = rt_mpath_matchgate(rt, gateway, prio); > if (rt == NULL) > - return (NULL); > + goto out; > } > #endif /* !SMALL_KERNEL */ > > rtref(rt); > +out: > + mtx_leave(&rn_mtx); > return (rt); > } > > @@ -354,7 +361,7 @@ rtable_match(unsigned int rtableid, stru > if (rnh == NULL) > return (NULL); > > - KERNEL_LOCK(); > + mtx_enter(&rn_mtx); > rn = rn_match(dst, rnh); > if (rn == NULL || (rn->rn_flags & RNF_ROOT) != 0) > goto out; > @@ -366,7 +373,7 @@ rtable_match(unsigned int rtableid, stru > rt = rtable_mpath_select(rt, src); > #endif /* SMALL_KERNEL */ > out: > - KERNEL_UNLOCK(); > + mtx_leave(&rn_mtx); > return (rt); > } > > @@ -377,29 +384,37 @@ rtable_insert(unsigned int rtableid, str > { > struct radix_node_head *rnh; > struct radix_node *rn = (struct radix_node *)rt; > + int error = 0; > + > + KERNEL_ASSERT_LOCKED(); > > rnh = rtable_get(rtableid, dst->sa_family); > if (rnh == NULL) > return (EAFNOSUPPORT); > > + mtx_enter(&rn_mtx); > #ifndef SMALL_KERNEL > if (rnh->rnh_multipath) { > /* Do not permit exactly the same dst/mask/gw pair. */ > if (rt_mpath_conflict(rnh, dst, mask, gateway, prio, > ISSET(rt->rt_flags, RTF_MPATH))) { > - return (EEXIST); > + error = EEXIST; > + goto out; > } > } > #endif /* SMALL_KERNEL */ > > rn = rn_addroute(dst, mask, rnh, rn, prio); > - if (rn == NULL) > - return (ESRCH); > + if (rn == NULL) { > + error = ESRCH; > + goto out; > + } > > rt = ((struct rtentry *)rn); > rtref(rt); > - > - return (0); > +out: > + mtx_leave(&rn_mtx); > + return (error); > } > > int > @@ -408,22 +423,31 @@ rtable_delete(unsigned int rtableid, str > { > struct radix_node_head *rnh; > struct radix_node *rn = (struct radix_node *)rt; > + int error = 0; > + > + KERNEL_ASSERT_LOCKED(); > > rnh = rtable_get(rtableid, dst->sa_family); > if (rnh == NULL) > return (EAFNOSUPPORT); > > + mtx_enter(&rn_mtx); > rn = rn_delete(dst, mask, rnh, rn); > - if (rn == NULL) > - return (ESRCH); > + if (rn == NULL) { > + error = ESRCH; > + goto out; > + } > > +#ifdef DIAGNOSTIC > if (rn->rn_flags & (RNF_ACTIVE | RNF_ROOT)) > panic("active node flags=%x", rn->rn_flags); > +#endif /* DIAGNOSTIC */ > > rt = ((struct rtentry *)rn); > rtfree(rt); > - > - return (0); > +out: > + mtx_leave(&rn_mtx); > + return (error); > } > > int > @@ -432,6 +456,8 @@ rtable_walk(unsigned int rtableid, sa_fa > { > struct radix_node_head *rnh; > int (*f)(struct radix_node *, void *, unsigned int) = (void *)func; > + > + KERNEL_ASSERT_LOCKED(); > > rnh = rtable_get(rtableid, af); > if (rnh == NULL) >
Re: ARP input path without KERNEL_LOCK
No regression here. > On 4 dec. 2015, at 11:54, Martin Pieuchot wrote: > > Now that in_arpinput() only uses the routing table, if_get()/if_put() > and carp_iamatch being already mpsafe we can kill the ARP input queue. > > This moves the ARP input path processing from the softnet interrupt > context (under KERNEL_LOCK) to the sofnettask (without KERNEL_LOCK). > > ok? > > Index: net/if_ethersubr.c > === > RCS file: /cvs/src/sys/net/if_ethersubr.c,v > retrieving revision 1.231 > diff -u -p -r1.231 if_ethersubr.c > --- net/if_ethersubr.c2 Dec 2015 08:47:00 - 1.231 > +++ net/if_ethersubr.c4 Dec 2015 10:42:14 - > @@ -372,14 +372,14 @@ decapsulate: > case ETHERTYPE_ARP: > if (ifp->if_flags & IFF_NOARP) > goto dropanyway; > - inq = &arpintrq; > - break; > + arpinput(m); > + return (1); > > case ETHERTYPE_REVARP: > if (ifp->if_flags & IFF_NOARP) > goto dropanyway; > - inq = &rarpintrq; > - break; > + revarpinput(m); > + return (1); > > #ifdef INET6 > /* > Index: net/netisr.c > === > RCS file: /cvs/src/sys/net/netisr.c,v > retrieving revision 1.8 > diff -u -p -r1.8 netisr.c > --- net/netisr.c 3 Dec 2015 12:22:51 - 1.8 > +++ net/netisr.c 4 Dec 2015 10:43:35 - > @@ -20,7 +20,6 @@ > > #include > > -#include "ether.h" > #include "ppp.h" > #include "bridge.h" > #include "pppoe.h" > @@ -39,10 +38,6 @@ netintr(void *unused) /* ARGSUSED */ > while ((n = netisr) != 0) { > atomic_clearbits_int(&netisr, n); > > -#if NETHER > 0 > - if (n & (1 << NETISR_ARP)) > - arpintr(); > -#endif > if (n & (1 << NETISR_IP)) > ipintr(); > #ifdef INET6 > Index: net/netisr.h > === > RCS file: /cvs/src/sys/net/netisr.h,v > retrieving revision 1.43 > diff -u -p -r1.43 netisr.h > --- net/netisr.h 3 Dec 2015 12:27:33 - 1.43 > +++ net/netisr.h 4 Dec 2015 10:44:01 - > @@ -53,7 +53,6 @@ > #define NETISR_IP 2 /* same as AF_INET */ > #define NETISR_TX 3 /* for if_snd processing */ > #define NETISR_PFSYNC 5 /* for pfsync "immediate" tx */ > -#define NETISR_ARP 18 /* same as AF_LINK */ > #define NETISR_IPV6 24 /* same as AF_INET6 */ > #define NETISR_ISDN 26 /* same as AF_E164 */ > #define NETISR_PPP 28 /* for PPP processing */ > @@ -64,7 +63,6 @@ > #ifdef _KERNEL > extern intnetisr; /* scheduling bits for network */ > > -void arpintr(void); > void ipintr(void); > void ip6intr(void); > void pppintr(void); > Index: netinet/if_ether.c > === > RCS file: /cvs/src/sys/netinet/if_ether.c,v > retrieving revision 1.197 > diff -u -p -r1.197 if_ether.c > --- netinet/if_ether.c2 Dec 2015 22:02:18 - 1.197 > +++ netinet/if_ether.c4 Dec 2015 10:44:17 - > @@ -88,14 +88,10 @@ void arptfree(struct rtentry *); > void arptimer(void *); > struct rtentry *arplookup(u_int32_t, int, int, u_int); > void in_arpinput(struct mbuf *); > -void revarpinput(struct mbuf *); > void in_revarpinput(struct mbuf *); > > LIST_HEAD(, llinfo_arp) arp_list; > structpool arp_pool; /* pool for llinfo_arp structures */ > -/* XXX hate magic numbers */ > -struct niqueue arpintrq = NIQUEUE_INITIALIZER(50, NETISR_ARP); > -struct niqueue rarpintrq = NIQUEUE_INITIALIZER(50, NETISR_ARP); > int arp_inuse, arp_allocated; > int arp_maxtries = 5; > int arpinit_done; > @@ -426,43 +422,40 @@ bad: > * then the protocol-specific routine is called. > */ > void > -arpintr(void) > +arpinput(struct mbuf *m) > { > - struct mbuf *m; > struct arphdr *ar; > int len; > > - while ((m = niq_dequeue(&arpintrq)) != NULL) { > #ifdef DIAGNOSTIC > - if ((m->m_flags & M_PKTHDR) == 0) > - panic("arpintr"); > + if ((m->m_flags & M_PKTHDR) == 0) > + panic("%s", __func__); > #endif > > - len = sizeof(struct arphdr); > - if (m->m_len < len && (m = m_pullup(m, len)) == NULL) > - continue; > - > - ar = mtod(m, struct arphdr *); > - if (ntohs(ar->ar_hrd) != ARPHRD_ETHER) { > - m_freem(m); > - continue; > - } > + len = sizeof(struct arphdr); > + if (m->m_len < len && (m = m_pullup(m, len)) == NULL) > + return; > > - len += 2 * (ar->ar_hln + ar->ar_pln); > -