Commit 04950f05 authored by Oliver Pinter +'s avatar Oliver Pinter +
Browse files

Merge remote-tracking branch 'origin/hardened/current/master' into...

Merge remote-tracking branch 'origin/hardened/current/master' into hardened/current/userlandenhanced
parents cc5861f4 889d2e8c
...@@ -357,7 +357,7 @@ cap_dns_family_limit(cap_channel_t *chan, const int *families, ...@@ -357,7 +357,7 @@ cap_dns_family_limit(cap_channel_t *chan, const int *families,
else else
limit_remove(limits, "family"); limit_remove(limits, "family");
for (i = 0; i < nfamilies; i++) { for (i = 0; i < nfamilies; i++) {
n = snprintf(nvlname, sizeof(nvlname), "type%u", i); n = snprintf(nvlname, sizeof(nvlname), "family%u", i);
assert(n > 0 && n < (int)sizeof(nvlname)); assert(n > 0 && n < (int)sizeof(nvlname));
nvlist_add_number(limits, nvlname, (uint64_t)families[i]); nvlist_add_number(limits, nvlname, (uint64_t)families[i]);
} }
......
...@@ -40,7 +40,7 @@ This paper contains the road-map for a stackable "BIO" system in ...@@ -40,7 +40,7 @@ This paper contains the road-map for a stackable "BIO" system in
FreeBSD, which will support these facilities. FreeBSD, which will support these facilities.
.AE .AE
.NH .NH
The miseducation of \fCstruct buf\fP. The miseducation of \f(CW.)struct buf\fP.
.PP .PP
To fully appreciate the topic, I include a little historic overview To fully appreciate the topic, I include a little historic overview
of struct buf, it is a most enlightening case of not exactly bit-rot of struct buf, it is a most enlightening case of not exactly bit-rot
...@@ -51,7 +51,7 @@ memory is was introduced into UNIX, all disk I/O were done from or ...@@ -51,7 +51,7 @@ memory is was introduced into UNIX, all disk I/O were done from or
to a struct buf. In the 6th edition sources, as printed in Lions to a struct buf. In the 6th edition sources, as printed in Lions
Book, struct buf looks like this: Book, struct buf looks like this:
.DS .DS
.ft C .ft CW
.ps -1 .ps -1
struct buf struct buf
{ {
...@@ -95,7 +95,7 @@ aspect and only a few fields relate exclusively to the cache aspect. ...@@ -95,7 +95,7 @@ aspect and only a few fields relate exclusively to the cache aspect.
If we step forward to the BSD 4.4-Lite-2 release, struct buf has grown If we step forward to the BSD 4.4-Lite-2 release, struct buf has grown
a bit here or there: a bit here or there:
.DS .DS
.ft C .ft CW
.ps -1 .ps -1
struct buf { struct buf {
LIST_ENTRY(buf) b_hash; /* Hash chain. */ LIST_ENTRY(buf) b_hash; /* Hash chain. */
...@@ -144,7 +144,7 @@ aspect, link buffers to the VM system, provide hacks for file-systems ...@@ -144,7 +144,7 @@ aspect, link buffers to the VM system, provide hacks for file-systems
.PP .PP
By the time we get to FreeBSD 3.0 more stuff has grown on struct buf: By the time we get to FreeBSD 3.0 more stuff has grown on struct buf:
.DS .DS
.ft C .ft CW
.ps -1 .ps -1
struct buf { struct buf {
LIST_ENTRY(buf) b_hash; /* Hash chain. */ LIST_ENTRY(buf) b_hash; /* Hash chain. */
...@@ -215,7 +215,7 @@ and Vinum. They all basically do the same: they map I/O requests from ...@@ -215,7 +215,7 @@ and Vinum. They all basically do the same: they map I/O requests from
a logical space to a physical space, and the mappings they perform a logical space to a physical space, and the mappings they perform
can be 1:1 or 1:N. \** can be 1:1 or 1:N. \**
.FS .FS
It is interesting to note that Lions in his comments to the \fCrkaddr\fP It is interesting to note that Lions in his comments to the \f(CW.)rkaddr\fP
routine (p. 16-2) writes \fIThe code in this procedure incorporates routine (p. 16-2) writes \fIThe code in this procedure incorporates
a special feature for files which extend over more than one disk a special feature for files which extend over more than one disk
drive. This feature is described in the UPM Section "RK(IV)". Its drive. This feature is described in the UPM Section "RK(IV)". Its
...@@ -258,7 +258,7 @@ limited extent diskslice/label, which ...@@ -258,7 +258,7 @@ limited extent diskslice/label, which
need only the I/O aspect, not the vnode, caching or VM linkage. need only the I/O aspect, not the vnode, caching or VM linkage.
.IP .IP
.I .I
The I/O aspect of struct buf should be put in a separate \fCstruct bio\fP. The I/O aspect of struct buf should be put in a separate \f(CW.)struct bio\fP.
.R .R
.NH 1 .NH 1
Implications for future struct buf improvements Implications for future struct buf improvements
...@@ -296,7 +296,7 @@ Anything that could be added to or done with ...@@ -296,7 +296,7 @@ Anything that could be added to or done with
the I/O aspect of struct buf can also be added to or done the I/O aspect of struct buf can also be added to or done
with the I/O aspect if it lives in a new "struct bio". with the I/O aspect if it lives in a new "struct bio".
.NH 1 .NH 1
Implementing a \fCstruct bio\fP Implementing a \f(CW.)struct bio\fP
.PP .PP
The first decision to be made was who got to use the name "struct buf", The first decision to be made was who got to use the name "struct buf",
and considering the fact that it is the I/O aspect which gets separated and considering the fact that it is the I/O aspect which gets separated
...@@ -344,7 +344,7 @@ Definition of struct bio ...@@ -344,7 +344,7 @@ Definition of struct bio
.PP .PP
With the cleanup of b_flags in place, the definition of struct bio looks like this: With the cleanup of b_flags in place, the definition of struct bio looks like this:
.DS .DS
.ft C .ft CW
.ps -1 .ps -1
struct bio { struct bio {
u_int bio_cmd; /* I/O operation. */ u_int bio_cmd; /* I/O operation. */
...@@ -375,7 +375,7 @@ Definition of struct buf ...@@ -375,7 +375,7 @@ Definition of struct buf
After adding a struct bio to struct buf and the fields aliased into it After adding a struct bio to struct buf and the fields aliased into it
struct buf looks like this: struct buf looks like this:
.DS .DS
.ft C .ft CW
.ps -1 .ps -1
struct buf { struct buf {
/* XXX: b_io must be the first element of struct buf for now /phk */ /* XXX: b_io must be the first element of struct buf for now /phk */
...@@ -424,7 +424,7 @@ And can be found at http://phk.freebsd.dk/misc ...@@ -424,7 +424,7 @@ And can be found at http://phk.freebsd.dk/misc
.FE .FE
and consists mainly of systematic substitutions like these and consists mainly of systematic substitutions like these
.DS .DS
.ft C .ft CW
s/struct buf/struct bio/ s/struct buf/struct bio/
s/b_flags/bio_flags/ s/b_flags/bio_flags/
s/b_bcount/bio_bcount/ s/b_bcount/bio_bcount/
......
...@@ -547,6 +547,8 @@ vlapic_update_ppr(struct vlapic *vlapic) ...@@ -547,6 +547,8 @@ vlapic_update_ppr(struct vlapic *vlapic)
VLAPIC_CTR1(vlapic, "vlapic_update_ppr 0x%02x", ppr); VLAPIC_CTR1(vlapic, "vlapic_update_ppr 0x%02x", ppr);
} }
static VMM_STAT(VLAPIC_GRATUITOUS_EOI, "EOI without any in-service interrupt");
static void static void
vlapic_process_eoi(struct vlapic *vlapic) vlapic_process_eoi(struct vlapic *vlapic)
{ {
...@@ -557,11 +559,7 @@ vlapic_process_eoi(struct vlapic *vlapic) ...@@ -557,11 +559,7 @@ vlapic_process_eoi(struct vlapic *vlapic)
isrptr = &lapic->isr0; isrptr = &lapic->isr0;
tmrptr = &lapic->tmr0; tmrptr = &lapic->tmr0;
/* for (i = 7; i >= 0; i--) {
* The x86 architecture reserves the the first 32 vectors for use
* by the processor.
*/
for (i = 7; i > 0; i--) {
idx = i * 4; idx = i * 4;
bitpos = fls(isrptr[idx]); bitpos = fls(isrptr[idx]);
if (bitpos-- != 0) { if (bitpos-- != 0) {
...@@ -570,17 +568,21 @@ vlapic_process_eoi(struct vlapic *vlapic) ...@@ -570,17 +568,21 @@ vlapic_process_eoi(struct vlapic *vlapic)
vlapic->isrvec_stk_top); vlapic->isrvec_stk_top);
} }
isrptr[idx] &= ~(1 << bitpos); isrptr[idx] &= ~(1 << bitpos);
vector = i * 32 + bitpos;
VCPU_CTR1(vlapic->vm, vlapic->vcpuid, "EOI vector %d",
vector);
VLAPIC_CTR_ISR(vlapic, "vlapic_process_eoi"); VLAPIC_CTR_ISR(vlapic, "vlapic_process_eoi");
vlapic->isrvec_stk_top--; vlapic->isrvec_stk_top--;
vlapic_update_ppr(vlapic); vlapic_update_ppr(vlapic);
if ((tmrptr[idx] & (1 << bitpos)) != 0) { if ((tmrptr[idx] & (1 << bitpos)) != 0) {
vector = i * 32 + bitpos;
vioapic_process_eoi(vlapic->vm, vlapic->vcpuid, vioapic_process_eoi(vlapic->vm, vlapic->vcpuid,
vector); vector);
} }
return; return;
} }
} }
VCPU_CTR0(vlapic->vm, vlapic->vcpuid, "Gratuitous EOI");
vmm_stat_incr(vlapic->vm, vlapic->vcpuid, VLAPIC_GRATUITOUS_EOI, 1);
} }
static __inline int static __inline int
...@@ -1092,11 +1094,7 @@ vlapic_pending_intr(struct vlapic *vlapic, int *vecptr) ...@@ -1092,11 +1094,7 @@ vlapic_pending_intr(struct vlapic *vlapic, int *vecptr)
irrptr = &lapic->irr0; irrptr = &lapic->irr0;
/* for (i = 7; i >= 0; i--) {
* The x86 architecture reserves the the first 32 vectors for use
* by the processor.
*/
for (i = 7; i > 0; i--) {
idx = i * 4; idx = i * 4;
val = atomic_load_acq_int(&irrptr[idx]); val = atomic_load_acq_int(&irrptr[idx]);
bitpos = fls(val); bitpos = fls(val);
......
...@@ -204,10 +204,6 @@ static void ixgbe_handle_phy(void *, int); ...@@ -204,10 +204,6 @@ static void ixgbe_handle_phy(void *, int);
static void ixgbe_reinit_fdir(void *, int); static void ixgbe_reinit_fdir(void *, int);
#endif #endif
/* Missing shared code prototype */
extern void ixgbe_stop_mac_link_on_d3_82599(struct ixgbe_hw *hw);
/********************************************************************* /*********************************************************************
* FreeBSD Device Interface Entry Points * FreeBSD Device Interface Entry Points
*********************************************************************/ *********************************************************************/
......
...@@ -251,6 +251,13 @@ tcp_twstart(struct tcpcb *tp) ...@@ -251,6 +251,13 @@ tcp_twstart(struct tcpcb *tp)
} }
} }
/*
* For use only by DTrace. We do not reference the state
* after this point so modifying it in place is not a problem.
*/
tcp_state_change(tp, TCPS_TIME_WAIT);
tw = uma_zalloc(V_tcptw_zone, M_NOWAIT); tw = uma_zalloc(V_tcptw_zone, M_NOWAIT);
if (tw == NULL) { if (tw == NULL) {
/* /*
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment