FreeBSD_HEAD_i386 - Build #4695 - Fixed:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4695/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4695/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4695/console

Change summaries:

312428 by kib:
Refcount tmpfs nodes and mount structures.

On dotdot lookup and fhtovp operations, it is possible for the file
represented by tmpfs node to be removed after the thread calculated
the pointer.  In this case, tmpfs_alloc_vp() accesses freed memory.

Introduce the reference count on the nodes.  The allnodes list from
tmpfs mount owns 1 reference, and threads performing unlocked
operations on the node, add one transient reference.  Similarly, since
struct tmpfs_mount maintains the list where nodes are enlisted,
refcount it by one reference from struct mount and one reference from
each node on the list.  Both nodes and tmpfs_mounts are removed when
refcount goes to zero.

Note that this means that nodes and tmpfs_mounts might survive some
time after the node is deleted or tmpfs_unmount() finished.  The
tmpfs_alloc_vp() in these cases returns error either due to node
removal (tn_nlinks == 0) or because of insmntque1(9) error.

Tested by:      pho (as part of larger patch)
Sponsored by:   The FreeBSD Foundation
MFC after:      2 weeks

312427 by erj:
e1000: Add support for Kaby Lake generation i219 (4) and i219 (5) devices

MFC after:      1 week
Sponsored by:   Intel Corporation

312426 by avg:
fix a thread preemption regression in schedulers introduced in r270423

Commit r270423 fixed a regression in sched_yield() that was introduced
in earlier changes.  Unfortunately, at the same time it introduced an
new regression.  The problem is that SWT_RELINQUISH (6), like all other
SWT_* constants and unlike SW_* flags, is not a bit flag.  So, (flags &
SWT_RELINQUISH) is true in cases where that was not really indended,
for example, with SWT_OWEPREEMPT (2) and SWT_REMOTEPREEMPT (11).

A straight forward fix would be to use (flags & SW_TYPE_MASK) ==
SWT_RELINQUISH, but my impression is that the switch types are designed
mostly for gathering statistics, not for influencing scheduling
decisions.

So, I decided that it would be better to check for SW_PREEMPT flag
instead.  That's also the same flag that was checked before r239157.
I double-checked how that flag is used and I am confident that the flag
is set only in the places where we really have the preemption:
- critical_exit + td_owepreempt
- sched_preempt in the ULE scheduler
- sched_preempt in the 4BSD scheduler

Reviewed by:    kib, mav
MFC after:      4 days
Sponsored by:   Panzura
Differential Revision: https://reviews.freebsd.org/D9230

312425 by kib:
Make tmpfs directory cursor available outside tmpfs_subr.c.

Tested by:      pho
Sponsored by:   The FreeBSD Foundation
MFC after:      1 week

312424 by hselasky:
Fix problem with suspend and resume when using Skylake chipsets. Make
sure the XHCI controller is reset after halting it. The problem is
clearly a BIOS bug as the suspend and resume is failing without
loading the XHCI driver. The same happens when using Linux and the
XHCI driver is not loaded.

Submitted by:           Yanko Yankulov <yanko.yanku...@gmail.com>
PR:                     216261
MFC after:              1 week

312423 by kib:
Refresh tmpfs(5) man page.

Provide more useful explanation of features and quirks.

Reviewed by:    emaste, vangyzen
Sponsored by:   The FreeBSD Foundation
MFC after:      1 week
Differential revision:  https://reviews.freebsd.org/D9211

312422 by ngie:
Only conditionally add in hyperv support if we're building amd64

This unbreaks the build because the assembly is written for x64.

MFC after:      3 weeks
X-MFC with:     r312418
Pointyhat to:   ngie
Reported by:    Jenkins (i386 job)
Sponsored by:   Dell EMC Isilon

_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to