perform copyin/copyout of the file data into the usermode
buffer. Typical filesystem hold vnode lock and some buffer locks over
the VOP_READ() and VOP_WRITE() operations, and since page fault
handler may need to recurse into VFS to get the page content, a
deadlock is possible.
The facility works by disabling page faults handling for the current
thread and attempting to execute i/o while allowing uiomove() to
access the usermode mapping of the i/o buffer. If all buffer pages are
resident, uiomove() is successfull and request is finished. If EFAULT
is returned from uiomove(), the pages backing i/o buffer are faulted
in and held, and the copyin/out is performed using uiomove_fromphys()
over the held pages for the second attempt of VOP call.
Since pages are hold in chunks to prevent large i/o requests from
starving free pages pool, and since vnode lock is only taken for
i/o over the current chunk, the vnode lock no longer protect atomicity
of the whole i/o request. Use newly added rangelocks to provide the
required atomicity of i/o regardind other i/o and truncations.
Filesystems need to explicitely opt-in into the scheme, by setting the
MNTK_NO_IOPF struct mount flag, and optionally by using
vn_io_fault_uiomove(9) helper which takes care of calling uiomove() or
converting uio into request for uiomove_fromphys().
Reviewed by: bf (comments), mdf, pjd (previous version)
Tested by: pho
Tested by: flo, Gustau P?rez <gperez entel upc edu> (previous version)
MFC after: 2 months
the i/o regions of the vnode data space. The implementation is quite
simple-minded, it uses the list of the lock requests, ordered by
arrival time. Each request may be for read or for write. The
implementation is fair FIFO.
MFC after: 2 month
Fix a bug in crypt(3) ignoring characters of a passphrase. [12:02]
Security: FreeBSD-SA-12:01.openssl (revised)
Security: FreeBSD-SA-12:02.crypt
Approved by: so (bz, simon)
but odd permissions resulted in a security alert from 110.neggrpperm
PR: kern/165533
Submitted by: Anton Shterenlikht <mexas@bristol.ac.uk>
Submitted by: J B <jb.1234abcd@gmail.com>
Approved by: cperciva
MFC after: 1 week
this fflush may fail to write data in the buffer.
PR: kern/137819
Submitted by: Eric Blake <ebb9@byu.net>
Reviewed by: theraven
Approved by: cperciva
MFC after: 2 weeks
Allow unique_file to take a mode for file permissions, but default
to user only read/write.
and r156592 from upstream clang trunk:
For final output files create them with mode 0664 to match other
compilers and expected defaults.
This should fix clang creating files with mode 0600.
Reported by: James <james@hicag.org>
MFC after: 3 days
longer uses the active and inactive paging queues. Instead, the pmap now
maintains an LRU-ordered list of pv entry pages, and pmap_pv_reclaim() uses
this list to select pv entries for reclamation.
Note: The old pmap_collect() tried to avoid reclaiming mappings for pages
that have either a hold_count or a busy field that is non-zero. However,
this isn't necessary for correctness, and the locking in pmap_collect() was
insufficient to guarantee that such mappings weren't reclaimed. The new
pmap_pv_reclaim() doesn't even try.
Tested by: sbruno
MFC after: 5 weeks
via `camcontrol tags ... -N ...`. There is no need to tune it in
usual cases, but some users want to have it for debugging purposes.
MFC after: 2 weeks
