apply fix for CVE-2012-4244 from upstream

upstream changelog:
          --- 9.9.1-P3 released ---

   3364.  [security]      Named could die on specially crafted record.
                          [RT #30416]
Implement dynamic NPF extensions interface.  An extension consists of
dynamically loaded module (.so) supplementing npfctl(8) and a kernel
module.  Move normalisation and logging functionality into their own
extensions.  More improvements to come.
*Sigh* provide, by default, the dumb "allocate 64K on the stack" variant
of the lzf_compress API by default.  This is because there is evidently
code floating around out there in the world with broken autoconf scripts that
don't check for LZF_STATE_ARG in the lzf header files and just assume the
dumb version of the API.

We rename the sane API to lzf_compress_r and implement the dumb API in
terms of it.  Consequently, bump liblzf major version number.  This is
fine because nothing used our liblzf with the old API.

Add lzf(1) utility from LZF distribution.  Add manual page for lzf(1).
Take wiz's suggestion.
Update LLVM/Clang snapshot to r164464. This adopts the GCC options for
the SSP parameters and a not-yet-default rewrite of SROA.
Add regression test for cdbr(3) and cdbw(3).
Remove magic numbers.
Initial import of sljit @ r175.

svn co https://sljit.svn.sourceforge.net/svnroot/sljit@r175 dist
Adapt code to compile with -D_KERNEL.
from hostap.epitest.fi
Support transfers of up to MACHINE_MAXPHYS in all pciide variants, and ahci.
wd(4) limits its maxphys depending on the drives's capability (64k sectors
for LBA48, 256 sectors for LBA and 128 sectors for older devices).

I assumed all pciide controllers could do MACHINE_MAXPHYS transfers, but
this may not be true. The capabilities of each controller variants should be
looked at more closely.
Fix panic "bad chunksize ..." in read-ahead code:
- off comes from the pager, so should already be page-aligned.
  KASSERT() that it is, and remove the off = trunc_page(off)
- as off is not changed any more, the size of the transfer is chunksize.
  Don't compute bytelen any more,  which is what required chunksize
  to be a power of 2. KASSERT() that chunksize is a multiple of page size.
Redo previous: it seems that the point of the bytelen computation was to
get transfers aligned to chunksz. So reintroduce the code, but using chunksz
instead of chunksize (if the readahead is trucated there's no point in
trying to align it anyway).
Now I get 64k read requests at the drive level again.
Use mnt_maxphys not MAXPHYS to limit the size of I/O to disk.
Now the read-ahead code does issue 512k requests to disk.
We know vp is not NULL, no need to check
The pagedaemon ca emit write as large as the underlying device's maxphys,
so emergva size needs to be MACHINE_MAXPHYS, MAXPHYS is not enough.
take care of the signal safe syslog calls which are not exposed.
In the FFS writebehind code (ufs_readwrite.c:WRITE()), use division
and multiplication instead of shifts, to accomodate devices with
MAXPHYS that is a multiple of the page size, but not a power of 2.

MegaRAID neatly writes out 192k chunks now.

An open question: is is really a good idea to always writebehind
at the largest size supported by the device?  Likely not, as this
could have a major impact on I/O fairness.  OS X and Solaris both
seem to limit transfers to 128k likely for this reason (the same
problem exists with the readahead code but since it is adaptive,
it will not *always* do huge transfers).

However, simply imposing a smallish limit like 128k here seems
like a bad idea because then we cannot accomodate greedy devices
like RAID, for which you want something like 128k * number of
data components.  Hmmmmmm.
Add a minphys routine for raidframe.

For now, we will address the problem of someone adding, at runtime with
a filesystem mounted, a drive to an existing RAID set, that drive being
on a different controller or bus such that it has a smaller maximum
transfer size than the smallest such size of any component previously
in the set, by clamping RAIDframe's reported maximum transfer size at
the old MAXPHYS value multiplied by the number of data disks in the
set.

In the future, we could either implement transfer-splitting to
the device specific maxphys in a generic way for all disks (Manuel's
proposal, and probably the best solution) or simply forbid adding
new components to RAID sets while running if those new components
have a smaller maxphys than that of any component already in the set
(my proposal; less flexible but a lot less code to write).

Anyway, now you should be able to see your 5 disk RAID5 set do
256k transfers through the filesystem -- 64k per component
instead of 64K total.  A win!
Move sljit_mod.c to sys/external/bsd/sljit/sljit and share it between
builtin and standalone module.