Commit 889d2e8c authored by Oliver Pinter +'s avatar Oliver Pinter +
Browse files

Merge remote-tracking branch 'freebsd/master' into hardened/current/master

parents 39ac59a5 755b7854
......@@ -357,7 +357,7 @@ cap_dns_family_limit(cap_channel_t *chan, const int *families,
else
limit_remove(limits, "family");
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));
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
FreeBSD, which will support these facilities.
.AE
.NH
The miseducation of \fCstruct buf\fP.
The miseducation of \f(CW.)struct buf\fP.
.PP
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
......@@ -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
Book, struct buf looks like this:
.DS
.ft C
.ft CW
.ps -1
struct buf
{
......@@ -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
a bit here or there:
.DS
.ft C
.ft CW
.ps -1
struct buf {
LIST_ENTRY(buf) b_hash; /* Hash chain. */
......@@ -144,7 +144,7 @@ aspect, link buffers to the VM system, provide hacks for file-systems
.PP
By the time we get to FreeBSD 3.0 more stuff has grown on struct buf:
.DS
.ft C
.ft CW
.ps -1
struct buf {
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
a logical space to a physical space, and the mappings they perform
can be 1:1 or 1:N. \**
.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
a special feature for files which extend over more than one disk
drive. This feature is described in the UPM Section "RK(IV)". Its
......@@ -258,7 +258,7 @@ limited extent diskslice/label, which
need only the I/O aspect, not the vnode, caching or VM linkage.
.IP
.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
.NH 1
Implications for future struct buf improvements
......@@ -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
with the I/O aspect if it lives in a new "struct bio".
.NH 1
Implementing a \fCstruct bio\fP
Implementing a \f(CW.)struct bio\fP
.PP
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
......@@ -344,7 +344,7 @@ Definition of struct bio
.PP
With the cleanup of b_flags in place, the definition of struct bio looks like this:
.DS
.ft C
.ft CW
.ps -1
struct bio {
u_int bio_cmd; /* I/O operation. */
......@@ -375,7 +375,7 @@ Definition of struct buf
After adding a struct bio to struct buf and the fields aliased into it
struct buf looks like this:
.DS
.ft C
.ft CW
.ps -1
struct buf {
/* 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
.FE
and consists mainly of systematic substitutions like these
.DS
.ft C
.ft CW
s/struct buf/struct bio/
s/b_flags/bio_flags/
s/b_bcount/bio_bcount/
......
......@@ -547,6 +547,8 @@ vlapic_update_ppr(struct vlapic *vlapic)
VLAPIC_CTR1(vlapic, "vlapic_update_ppr 0x%02x", ppr);
}
static VMM_STAT(VLAPIC_GRATUITOUS_EOI, "EOI without any in-service interrupt");
static void
vlapic_process_eoi(struct vlapic *vlapic)
{
......@@ -557,11 +559,7 @@ vlapic_process_eoi(struct vlapic *vlapic)
isrptr = &lapic->isr0;
tmrptr = &lapic->tmr0;
/*
* The x86 architecture reserves the the first 32 vectors for use
* by the processor.
*/
for (i = 7; i > 0; i--) {
for (i = 7; i >= 0; i--) {
idx = i * 4;
bitpos = fls(isrptr[idx]);
if (bitpos-- != 0) {
......@@ -570,17 +568,21 @@ vlapic_process_eoi(struct vlapic *vlapic)
vlapic->isrvec_stk_top);
}
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->isrvec_stk_top--;
vlapic_update_ppr(vlapic);
if ((tmrptr[idx] & (1 << bitpos)) != 0) {
vector = i * 32 + bitpos;
vioapic_process_eoi(vlapic->vm, vlapic->vcpuid,
vector);
}
return;
}
}
VCPU_CTR0(vlapic->vm, vlapic->vcpuid, "Gratuitous EOI");
vmm_stat_incr(vlapic->vm, vlapic->vcpuid, VLAPIC_GRATUITOUS_EOI, 1);
}
static __inline int
......@@ -1092,11 +1094,7 @@ vlapic_pending_intr(struct vlapic *vlapic, int *vecptr)
irrptr = &lapic->irr0;
/*
* The x86 architecture reserves the the first 32 vectors for use
* by the processor.
*/
for (i = 7; i > 0; i--) {
for (i = 7; i >= 0; i--) {
idx = i * 4;
val = atomic_load_acq_int(&irrptr[idx]);
bitpos = fls(val);
......
......@@ -204,10 +204,6 @@ static void ixgbe_handle_phy(void *, int);
static void ixgbe_reinit_fdir(void *, int);
#endif
/* Missing shared code prototype */
extern void ixgbe_stop_mac_link_on_d3_82599(struct ixgbe_hw *hw);
/*********************************************************************
* FreeBSD Device Interface Entry Points
*********************************************************************/
......
......@@ -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);
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