#
51369649 |
| 20-Nov-2017 |
Pedro F. Giffuni <pfg@FreeBSD.org> |
sys: further adoption of SPDX licensing ID tags.
Mainly focus on files that use BSD 3-Clause license.
The Software Package Data Exchange (SPDX) group provides a specification to make it easier for
sys: further adoption of SPDX licensing ID tags.
Mainly focus on files that use BSD 3-Clause license.
The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts.
Special thanks to Wind River for providing access to "The Duke of Highlander" tool: an older (2014) run over FreeBSD tree was useful as a starting point.
show more ...
|
#
c2c014f2 |
| 07-Nov-2017 |
Hans Petter Selasky <hselasky@FreeBSD.org> |
Merge ^/head r323559 through r325504.
|
#
50896984 |
| 10-Oct-2017 |
Enji Cooper <ngie@FreeBSD.org> |
MFhead@r324482
|
#
a1fc6a8c |
| 05-Oct-2017 |
Konstantin Belousov <kib@FreeBSD.org> |
On amd64, mark the set_user_ldt() function as static.
On i386, the function is used from the context switch code and needs to be accessible externally. Amd64 MD context switch does not lock an LDT
On amd64, mark the set_user_ldt() function as static.
On i386, the function is used from the context switch code and needs to be accessible externally. Amd64 MD context switch does not lock an LDT spinlock and inlines switching in assembly.
Discussed with: bde Sponsored by: The FreeBSD Foundation MFC after: 1 week
show more ...
|
Revision tags: release/10.4.0, release/11.1.0 |
|
#
4198293b |
| 17-Jun-2017 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r319801 through r320041.
|
#
43f41dd3 |
| 12-Jun-2017 |
Konstantin Belousov <kib@FreeBSD.org> |
Make struct syscall_args visible to userspace compilation environment from machine/proc.h, consistently on all architectures.
Reviewed by: jhb Sponsored by: The FreeBSD Foundation MFC after: 3 weeks
Make struct syscall_args visible to userspace compilation environment from machine/proc.h, consistently on all architectures.
Reviewed by: jhb Sponsored by: The FreeBSD Foundation MFC after: 3 weeks X-Differential revision: https://reviews.freebsd.org/D11080
show more ...
|
#
348238db |
| 01-Mar-2017 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r314420 through r314481.
|
#
fbbd9655 |
| 01-Mar-2017 |
Warner Losh <imp@FreeBSD.org> |
Renumber copyright clause 4
Renumber cluase 4 to 3, per what everybody else did when BSD granted them permission to remove clause 3. My insistance on keeping the same numbering for legal reasons is
Renumber copyright clause 4
Renumber cluase 4 to 3, per what everybody else did when BSD granted them permission to remove clause 3. My insistance on keeping the same numbering for legal reasons is too pedantic, so give up on that point.
Submitted by: Jan Schaumann <jschauma@stevens.edu> Pull Request: https://github.com/freebsd/freebsd/pull/96
show more ...
|
Revision tags: release/11.0.1, release/11.0.0 |
|
#
56e61f57 |
| 15-May-2016 |
Konstantin Belousov <kib@FreeBSD.org> |
Eliminate pvh_global_lock from the amd64 pmap.
The only current purpose of the pvh lock was explained there On Wed, Jan 09, 2013 at 11:46:13PM -0600, Alan Cox wrote: > Let me lay out one example for
Eliminate pvh_global_lock from the amd64 pmap.
The only current purpose of the pvh lock was explained there On Wed, Jan 09, 2013 at 11:46:13PM -0600, Alan Cox wrote: > Let me lay out one example for you in detail. Suppose that we have > three processors and two of these processors are actively using the same > pmap. Now, one of the two processors sharing the pmap performs a > pmap_remove(). Suppose that one of the removed mappings is to a > physical page P. Moreover, suppose that the other processor sharing > that pmap has this mapping cached with write access in its TLB. Here's > where the trouble might begin. As you might expect, the processor > performing the pmap_remove() will acquire the fine-grained lock on the > PV list for page P before destroying the mapping to page P. Moreover, > this processor will ensure that the vm_page's dirty field is updated > before releasing that PV list lock. However, the TLB shootdown for this > mapping may not be initiated until after the PV list lock is released. > The processor performing the pmap_remove() is not problematic, because > the code being executed by that processor won't presume that the mapping > is destroyed until the TLB shootdown has completed and pmap_remove() has > returned. However, the other processor sharing the pmap could be > problematic. Specifically, suppose that the third processor is > executing the page daemon and concurrently trying to reclaim page P. > This processor performs a pmap_remove_all() on page P in preparation for > reclaiming the page. At this instant, the PV list for page P may > already be empty but our second processor still has a stale TLB entry > mapping page P. So, changes might still occur to the page after the > page daemon believes that all mappings have been destroyed. (If the PV > entry had still existed, then the pmap lock would have ensured that the > TLB shootdown completed before the pmap_remove_all() finished.) Note, > however, the page daemon will know that the page is dirty. It can't > possibly mistake a dirty page for a clean one. However, without the > current pvh global locking, I don't think anything is stopping the page > daemon from starting the laundering process before the TLB shootdown has > completed. > > I believe that a similar example could be constructed with a clean page > P' and a stale read-only TLB entry. In this case, the page P' could be > "cached" in the cache/free queues and recycled before the stale TLB > entry is flushed.
TLBs for addresses with updated PTEs are always flushed before pmap lock is unlocked. On the other hand, amd64 pmap code does not always flushes TLBs before PV list locks are unlocked, if previously PTEs were cleared and PV entries removed.
To handle the situations where a thread might notice empty PV list but third thread still having access to the page due to TLB invalidation not finished yet, introduce delayed invalidation. Comparing with the pvh_global_lock, DI does not block entered thread when pmap_remove_all() or pmap_remove_write() (callers of pmap_delayed_invl_wait()) are executed in parallel. But _invl_wait() callers are blocked until all previously noted DI blocks are leaved, thus ensuring that neccessary TLB invalidations were performed before returning from pmap_remove_all() or pmap_remove_write().
See comments for detailed description of the mechanism, and also for the explanations why several pmap methods, most important pmap_enter(), do not need DI protection.
Reviewed by: alc, jhb (turnstile KPI usage) Tested by: pho (previous version) Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D5747
show more ...
|
Revision tags: release/10.3.0, release/10.2.0, release/10.1.0, release/9.3.0, release/10.0.0, release/9.2.0, release/8.4.0, release/9.1.0 |
|
#
6a068746 |
| 15-May-2012 |
Alexander Motin <mav@FreeBSD.org> |
MFC
|
#
38f1b189 |
| 26-Apr-2012 |
Peter Grehan <grehan@FreeBSD.org> |
IFC @ r234692
sys/amd64/include/cpufunc.h sys/amd64/include/fpu.h sys/amd64/amd64/fpu.c sys/amd64/vmm/vmm.c
- Add API to allow vmm FPU state init/save/restore.
FP stuff discussed with: kib
|
Revision tags: release/8.3.0_cvs, release/8.3.0 |
|
#
8833b15f |
| 03-Apr-2012 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Merge head r232686 through r233825 into projects/pf/head.
|
#
5730afc9 |
| 22-Mar-2012 |
Alan Cox <alc@FreeBSD.org> |
Handle spurious page faults that may occur in no-fault sections of the kernel.
When access restrictions are added to a page table entry, we flush the corresponding virtual address mapping from the T
Handle spurious page faults that may occur in no-fault sections of the kernel.
When access restrictions are added to a page table entry, we flush the corresponding virtual address mapping from the TLB. In contrast, when access restrictions are removed from a page table entry, we do not flush the virtual address mapping from the TLB. This is exactly as recommended in AMD's documentation. In effect, when access restrictions are removed from a page table entry, AMD's MMUs will transparently refresh a stale TLB entry. In short, this saves us from having to perform potentially costly TLB flushes. In contrast, Intel's MMUs are allowed to generate a spurious page fault based upon the stale TLB entry. Usually, such spurious page faults are handled by vm_fault() without incident. However, when we are executing no-fault sections of the kernel, we are not allowed to execute vm_fault(). This change introduces special-case handling for spurious page faults that occur in no-fault sections of the kernel.
In collaboration with: kib Tested by: gibbs (an earlier version)
I would also like to acknowledge Hiroki Sato's assistance in diagnosing this problem.
MFC after: 1 week
show more ...
|
#
8fa0b743 |
| 23-Jan-2012 |
Xin LI <delphij@FreeBSD.org> |
IFC @230489 (pending review).
|
Revision tags: release/9.0.0 |
|
#
70d8f36a |
| 27-Oct-2011 |
Peter Grehan <grehan@FreeBSD.org> |
IFC @ r226824
|
#
6bfe4c78 |
| 07-Oct-2011 |
Konstantin Belousov <kib@FreeBSD.org> |
Remove unused define.
MFC after: 1 month
|
Revision tags: release/7.4.0_cvs, release/8.2.0_cvs, release/7.4.0, release/8.2.0, release/8.1.0_cvs, release/8.1.0 |
|
#
7708106a |
| 26-May-2010 |
Marcel Moolenaar <marcel@FreeBSD.org> |
Merge svn+ssh://svn.freebsd.org/base/head@208557
|
#
afe1a688 |
| 23-May-2010 |
Konstantin Belousov <kib@FreeBSD.org> |
Reorganize syscall entry and leave handling.
Extend struct sysvec with three new elements: sv_fetch_syscall_args - the method to fetch syscall arguments from usermode into struct syscall_args. The
Reorganize syscall entry and leave handling.
Extend struct sysvec with three new elements: sv_fetch_syscall_args - the method to fetch syscall arguments from usermode into struct syscall_args. The structure is machine-depended (this might be reconsidered after all architectures are converted). sv_set_syscall_retval - the method to set a return value for usermode from the syscall. It is a generalization of cpu_set_syscall_retval(9) to allow ABIs to override the way to set a return value. sv_syscallnames - the table of syscall names.
Use sv_set_syscall_retval in kern_sigsuspend() instead of hardcoding the call to cpu_set_syscall_retval().
The new functions syscallenter(9) and syscallret(9) are provided that use sv_*syscall* pointers and contain the common repeated code from the syscall() implementations for the architecture-specific syscall trap handlers.
Syscallenter() fetches arguments, calls syscall implementation from ABI sysent table, and set up return frame. The end of syscall bookkeeping is done by syscallret().
Take advantage of single place for MI syscall handling code and implement ptrace_lwpinfo pl_flags PL_FLAG_SCE, PL_FLAG_SCX and PL_FLAG_EXEC. The SCE and SCX flags notify the debugger that the thread is stopped at syscall entry or return point respectively. The EXEC flag augments SCX and notifies debugger that the process address space was changed by one of exec(2)-family syscalls.
The i386, amd64, sparc64, sun4v, powerpc and ia64 syscall()s are changed to use syscallenter()/syscallret(). MIPS and arm are not converted and use the mostly unchanged syscall() implementation.
Reviewed by: jhb, marcel, marius, nwhitehorn, stas Tested by: marcel (ia64), marius (sparc64), nwhitehorn (powerpc), stas (mips) MFC after: 1 month
show more ...
|
#
9307d8bd |
| 08-May-2010 |
Marcel Moolenaar <marcel@FreeBSD.org> |
Merge svn+ssh://svn.freebsd.org/base/head@207793
|
#
19effccd |
| 08-May-2010 |
Konstantin Belousov <kib@FreeBSD.org> |
MFC r204051 (by imp): n64 has a different size for KINFO_PROC_SIZE.
Approved by: imp
MFC r207152: Move the constants specifying the size of struct kinfo_proc into machine-specific header files. Add
MFC r204051 (by imp): n64 has a different size for KINFO_PROC_SIZE.
Approved by: imp
MFC r207152: Move the constants specifying the size of struct kinfo_proc into machine-specific header files. Add KINFO_PROC32_SIZE for struct kinfo_proc32 for architectures providing COMPAT_FREEBSD32. Add CTASSERT for the size of struct kinfo_proc32.
MFC r207269: Style: use #define<TAB> instead of #define<SPACE>.
show more ...
|
#
945f418a |
| 06-May-2010 |
Kirk McKusick <mckusick@FreeBSD.org> |
Final update to current version of head in preparation for reintegration.
|
#
a4bf5fb9 |
| 28-Apr-2010 |
Kirk McKusick <mckusick@FreeBSD.org> |
Update to current version of head.
|
#
8bac9818 |
| 27-Apr-2010 |
Konstantin Belousov <kib@FreeBSD.org> |
Style: use #define<TAB> instead of #define<SPACE>.
Noted by: bde, pluknet gmail com MFC after: 11 days
|
#
ed780687 |
| 24-Apr-2010 |
Konstantin Belousov <kib@FreeBSD.org> |
Move the constants specifying the size of struct kinfo_proc into machine-specific header files. Add KINFO_PROC32_SIZE for struct kinfo_proc32 for architectures providing COMPAT_FREEBSD32. Add CTASSER
Move the constants specifying the size of struct kinfo_proc into machine-specific header files. Add KINFO_PROC32_SIZE for struct kinfo_proc32 for architectures providing COMPAT_FREEBSD32. Add CTASSERT for the size of struct kinfo_proc32.
Submitted by: pluknet Reviewed by: imp, jhb, nwhitehorn MFC after: 2 weeks
show more ...
|
Revision tags: release/7.3.0_cvs, release/7.3.0, release/8.0.0_cvs, release/8.0.0 |
|
#
10b3b545 |
| 17-Sep-2009 |
Dag-Erling Smørgrav <des@FreeBSD.org> |
Merge from head
|