Ù0254974
26
1754
121
159
237
127
1999
288
293
976
146
101
110
257
245
234
294
198
156
704
218
108
1710
387
134
162
204

K 10
svn:author
V 3
jlh
K 8
svn:date
V 27
2013-08-27T21:20:28.801687Z
K 7
svn:log
V 1660
Make the period of each periodic security script configurable.

There are now six additional variables
  weekly_status_security_enable
  weekly_status_security_inline
  weekly_status_security_output
  monthly_status_security_enable
  monthly_status_security_inline
  monthly_status_security_output
alongside their existing daily counterparts.  They all have the same
default values.

All other "daily_status_security_${scriptname}_${whatever}"
variables have been renamed to "security_status_${name}_${whatever}".
A compatibility shim has been introduced for the old variable names,
which we will be able to remove in 11.0-RELEASE.

"security_status_${name}_enable" is still a boolean but a new
"security_status_${name}_period" allows to define the period of
each script.  The value is one of "daily" (the default for backward
compatibility), "weekly", "monthly" and "NO".

Note that when the security periodic scripts are run directly from
crontab(5) (as opposed to being called by daily or weekly periodic
scripts), they will run unless the test is explicitely disabled with a
"NO", either for in the "_enable" or the "_period" variable.

When the security output is not inlined, the mail subject has been
changed from "$host $arg run output" to "$host $arg $period run output".
For instance:
  myfbsd security run output ->  myfbsd security daily run output
I don't think this is considered as a stable API, but feel free to
correct me if I'm wrong.

Finally, I will rearrange periodic.conf(5) and default/periodic.conf
to put the security options in their own section.  I left them in
place for this commit to make reviewing easier.

Reviewed by:	hackers@

END
K 10
svn:author
V 3
jlh
K 8
svn:date
V 27
2013-08-27T21:28:12.152248Z
K 7
svn:log
V 29
Install 450.status-security.

END
K 10
svn:author
V 7
davidcs
K 8
svn:date
V 27
2013-08-27T21:29:21.001184Z
K 7
svn:log
V 63
Fix bug in Flash access code

Submitted by: David C Somayajulu

END
K 10
svn:author
V 6
jilles
K 8
svn:date
V 27
2013-08-27T21:47:01.102952Z
K 7
svn:log
V 141
wordexp(): Avoid leaking the pipe file descriptors to a parallel fork/exec.

This uses the new pipe2() system call added on May 1 (r250159).

END
K 10
svn:author
V 4
jkim
K 8
svn:date
V 27
2013-08-27T22:37:29.899640Z
K 7
svn:log
V 34
Fix a typo introduced in r254975.

END
K 10
svn:author
V 3
ken
K 8
svn:date
V 27
2013-08-27T23:02:20.105297Z
K 7
svn:log
V 1905
MFC change 254389:

There are some slight differences from the version in FreeBSD/head.
__FreeBSD_version has been bumped to 902503 for the availability
of the SI_UNMAPPED cdev flag, and the D_UNMAPPED_IO cdevsw flag
remains in place.  D_UNMAPPED_IO no longer does anything.  Drivers that
use that flag will just wind up having mapped I/O by default.  The
impact will only be on performance, not functionality.

  Change the way that unmapped I/O capability is advertised.

  The previous method was to set the D_UNMAPPED_IO flag in the cdevsw
  for the driver.  The problem with this is that in many cases (e.g.
  sa(4)) there may be some instances of the driver that can handle
  unmapped I/O and some that can't.  The isp(4) driver can handle
  unmapped I/O, but the esp(4) driver currently cannot.  The cdevsw
  is shared among all driver instances.

  So instead of setting a flag on the cdevsw, set a flag on the cdev.
  This allows drivers to indicate support for unmapped I/O on a
  per-instance basis.

  sys/conf.h:	Remove the D_UNMAPPED_IO cdevsw flag and replace it
  		with an SI_UNMAPPED cdev flag.

  kern_physio.c:	Look at the cdev SI_UNMAPPED flag to determine
  		whether or not a particular driver can handle
  		unmapped I/O.

  geom_dev.c:	Set the SI_UNMAPPED flag for all GEOM cdevs.
  		Since GEOM will create a temporary mapping when
  		needed, setting SI_UNMAPPED unconditionally will
  		work.

  		Remove the D_UNMAPPED_IO flag.

  nvme_ns.c:	Set the SI_UNMAPPED flag on cdevs created here
  		if NVME_UNMAPPED_BIO_SUPPORT is enabled.

  vfs_aio.c:	In aio_qphysio(), check the SI_UNMAPPED flag on a
  		cdev instead of the D_UNMAPPED_IO flag on the cdevsw.

  sys/param.h:	Bump __FreeBSD_version to 1000045 for the switch from
  		setting the D_UNMAPPED_IO flag in the cdevsw to setting
  		SI_UNMAPPED in the cdev.

  Reviewed by:	kib, jimharris
  Sponsored by:	Spectra Logic

END
K 10
svn:author
V 3
sjg
K 8
svn:date
V 27
2013-08-27T23:09:34.704755Z
K 7
svn:log
V 195
Use .SHELL to tell bmake to use 'set -e' when running scripts
since most FreeBSD makefiles it is in effect.

Move the other bmake compatability knobs out of the POSIX block.

Reviewed by: obrien

END
K 10
svn:author
V 7
zeising
K 8
svn:date
V 27
2013-08-27T23:30:02.216898Z
K 7
svn:log
V 196
Really regen after r254962.

This removes the WITH_BSDCONFIG description alltogether, since this option
is removed.
At the same time, fix the WITHOUT_LIBCPLUSPLUS option that had gotten
inverted.

END
K 10
svn:author
V 7
delphij
K 8
svn:date
V 27
2013-08-28T00:39:47.714806Z
K 7
svn:log
V 879
Previously, both zfs_rename and zfs_link does a check on whether
the passed vnode belongs to the same mount point (v_vfsp or also
known as v_mount in FreeBSD).  This check prevents the code from
proceeding further on vnodes that do not belong to ZFS, for
instance, on UFS or NULLFS.

The recent change (merged as r254585) on upstream changes the
check of v_vfsp to instead check the znode's z_zfsvfs.  On Illumos
this would work because when the vnode comes from lofs, the
VOP_REALVP() would give the right vnode, this is not true on
FreeBSD where our VOP_REALVP is a no-op, and as such tdvp is
not guaranteed to be a ZFS vnode, and will later trigger a
failed assertion when verifying the vnode.

This changeset modifies our local shims (zfs_freebsd_rename and
zfs_freebsd_link) to check if v_mount matches before proceeding
further.

Reported by:		many
Diagnostic work by:	avg

END
K 10
svn:author
V 5
gonzo
K 8
svn:date
V 27
2013-08-28T01:10:51.581890Z
K 7
svn:log
V 52
Fix GT PCI controller driver on big-endian hardware

END
K 10
svn:author
V 4
joel
K 8
svn:date
V 27
2013-08-28T05:12:29.448835Z
K 7
svn:log
V 9
mdoc fix

END
K 10
svn:author
V 3
uqs
K 8
svn:date
V 27
2013-08-28T07:48:44.768911Z
K 7
svn:log
V 18
Fix 'make depend'

END
K 10
svn:author
V 6
ivoras
K 8
svn:date
V 27
2013-08-28T10:06:20.254662Z
K 7
svn:log
V 161
Take a very small step toward the Century of the Anchovy by increasing the
time dirhash entries stay in memory before being considered for eviction to
1 minute.

END
K 10
svn:author
V 5
gavin
K 8
svn:date
V 27
2013-08-28T14:29:33.330314Z
K 7
svn:log
V 150
Support the PCI-Express SSD in the new MacBook Air (model A1465)

Submitted by:	Johannes Lundberg <johannes brilliantservice.co.jp>
MFC after:	3 days

END
K 10
svn:author
V 4
loos
K 8
svn:date
V 27
2013-08-28T14:39:24.762415Z
K 7
svn:log
V 140
Properly free gpiobus ivars when gpiobus_parse_pins() fails and also on
gpiobus detachment.

Suggested by:	imp
Approved by:	adrian (mentor)

END
K 10
svn:author
V 4
loos
K 8
svn:date
V 27
2013-08-28T14:43:04.464700Z
K 7
svn:log
V 200
Add the default hints to make the GPIO pins, rf led and reset switch work
out of the box on RouterStation.

PR:	177832
Submitted by:	Petko Bordjukov (bordjukov@gmail.com)
Approved by:	adrian (mentor)

END
K 10
svn:author
V 4
loos
K 8
svn:date
V 27
2013-08-28T14:46:15.249568Z
K 7
svn:log
V 104
Make ar71xx_spi attach the next free unit of spibus and not only spibus0.

Approved by:	adrian (mentor)

END
K 10
svn:author
V 4
loos
K 8
svn:date
V 27
2013-08-28T14:49:36.734150Z
K 7
svn:log
V 63
Fix a few typos for s25fl types.

Approved by:	adrian (mentor)

END
K 10
svn:author
V 5
gavin
K 8
svn:date
V 27
2013-08-28T15:12:15.801604Z
K 7
svn:log
V 609
After writing a kernel core dump into /var/crash, call sync(8).

If we panic again shortly after boot (say, within 30 seconds), any core
dump we wrote out may be lost on reboot.  In this situation, we really
want to keep that core file, as it may be the only way to have the issue
resolved.  Call sync(8) after writing out the core file and running
crashinfo(8), in the hope that these will not be lost if we panic
again.  sync(8) is only called in the case where there is a core dump
to be written out, so won't be called during normal boots.

Discovered by:	Trying to debug an IPSEC panic
MFC after:	1 week

END
K 10
svn:author
V 3
gnn
K 8
svn:date
V 27
2013-08-28T15:12:51.318971Z
K 7
svn:log
V 125
Add firmware for Centrino 2200-N wireless devices.

Driver software for this firmware will be updated in a following commit.

END
K 10
svn:author
V 5
kargl
K 8
svn:date
V 27
2013-08-28T16:59:55.984022Z
K 7
svn:log
V 14
* Whitespace.

END
K 10
svn:author
V 8
mckusick
K 8
svn:date
V 27
2013-08-28T17:38:05.052450Z
K 7
svn:log
V 1611
A performance problem was reported in PR kern/181226:

    I have 25TB Dell PERC 6 RAID5 array. When it becomes almost
    full (10-20GB free), processes which write data to it start
    eating 100% CPU and write speed drops below 1MB/sec (normally
    to gives 400MB/sec). The revision at which it first became
    apparent was http://svnweb.freebsd.org/changeset/base/249782.

The offending change reserved an area in each cylinder group to
store metadata. The new algorithm attempts to save this area for
metadata and allows its use for non-metadata only after all the
data areas have been exhausted. The size of the reserved area
defaults to half of minfree, so the filesystem reports full before
the data area can completely fill. However, in this report, the
filesystem has had minfree reduced to 1% thus forcing the metadata
area to be used for data. As the filesystem approached full, it
had only metadata areas left to allocate. The result was that
every block allocation had to scan summary data for 30,000 cylinder
groups before falling back to searching up to 30,000 metadata areas.

The fix is to give up on saving the metadata areas once the free
space reserve drops below 2%. The effect of this change is to use
the old algorithm of just accepting the first available block that
we find. Since most filesystems use the default 5% minfree, this
will have no effect on their operation. For those that want to push
to the limit, they will get their crappy block placements quickly.

Submitted by:  Dmitry Sivachenko
Fix Tested by: Dmitry Sivachenko
PR:            kern/181226
MFC after:     2 weeks

END
K 10
svn:author
V 8
mckusick
K 8
svn:date
V 27
2013-08-28T17:46:32.144881Z
K 7
svn:log
V 289
In looking at block layouts as part of fixing filesystem block
allocations under low free-space conditions (-r254995), determine
that old block-preference search order used before -r249782 worked
a bit better. This change reverts to that block-preference search order.

MFC after:	2 weeks

END
K 10
svn:author
V 4
jkim
K 8
svn:date
V 27
2013-08-28T17:58:30.264317Z
K 7
svn:log
V 41
Avoid unnecessary signedness conversion.

END
K 10
svn:author
V 4
jkim
K 8
svn:date
V 27
2013-08-28T18:13:37.982522Z
K 7
svn:log
V 69
Make sure to free stale buffer before allocating new one for safety.

END
K 10
svn:author
V 4
jkim
K 8
svn:date
V 27
2013-08-28T19:06:22.812919Z
K 7
svn:log
V 110
Do not save/restore video memory if we are not using linear frame buffer.
Note this partially revert r233896.

END