by changing the symlink one to set vap's vatype to VLNK. All the other three
already set vatype to the correct type. Note that, however, in the mkdir
case (and now symlink too) this is not strictly necessary.
don't bother trying to write files bigger than this. Just return
EFBIG to caller, rather than panic()ing later.
From OpenBSD.
This closes my PR kern/30864: "panic when copying files of >4GB on msdosfs"
information about the context in which wdc_exec_command() was called, but
we may be in interrupt context here. Call wdcwait() with flags derived from
xfer->c_flags instead, as do other wdcwait() callers.
Should fix kern/31083 by Jukka Salmi.
and in a better way than what is done in wddump() (which also does it
for DMA transfers, limiting the dump speed significantly). So remove
code splitting transfers in wd->sc_multi chunks from wddump(), and call
wd->atabus->ata_bio() with the whole transfers.
Problem reported by Frank Kardel, and patch tested by him.
used in ioctl routines to do the right thing when the FKIOCTL flag is
passed to the IOCTL routine indicating its a in-kernel VOP_IOCTL call and
indirect addresses provided in the arguments are to be seen as kernel
adresses rather than userland adresses.
A simple substitution and prepending of the `flags' passed on to the ioctl
handler is enough to DTRT.
backing file per attribute type indexed by inode number to hold the extended
attributes.
This is working pretty well on my test systems, except for the "autostart"
feature. I need someone with a better handle on the VFS locking protocol
to go over that.
This is a work-in-progress. There are parts of this that could be re-factored
allowing this approach to be used on other types of file systems.
Adapted from FreeBSD.
standard scheme:
if (<configured> != <wildcard> && <configured> != <real>)
then fail
else
ask device match function
This is handled by config_stdsubmatch() now.
we can implement an universal submatch() function covering all
the standard cases:
if (<configured> != <wildcard> && <configured> != <real>)
then fail
else
ask device match function
explicitely by a plain integer array
the length in now known to all relevant parties, so this avoids
duplication of information, and we can allocate that thing in
drivers without hacks
instead of introducing 64-bit operations in these space-constrained
pieces of code with the recent change to ino_t. This is patterned
slightly after recent changes to libsa's ufs.c.
Approved by christos.
Fix vulnerability to a denial-of-service attack which passes a
length-0 crypto op. Check for zero length and return EINVAL, taken from:
http://cvsweb.FreeBSD.org/src/sys/opencrypto/cryptodev.c.diff?r1=1.25&r2=1.26
Original FreeBSD log mesage:
Modified files:
sys/opencrypto cryptodev.c
Log:
Fix bogus check. It was possible to panic the kernel by giving 0 length.
This is actually a local DoS, as every user can use /dev/crypto if there
is crypto hardware in the system and cryptodev.ko is loaded (or compiled
into the kernel).
Reported by: Mike Tancsa <mike@sentex.net>
thanks to Sam Leffler for passing on a heads-up about this issue.
Added a big FIXME because two group lists containing the same entries,
but ordered differently, still compare as unequal. The same holds if one
group list contains an entry twice while the other does not. ok'ed by
christos.
which attach to hypervisor. This allows to use config_found_ia() instead of
config_found(), instead of relying on the order of which device are
written in ioconf.c.
From Quentin Garnier.
802.11 header + opt(crypto header) + LLC writable, regardless of
crypto state. If s/w crypto is enabled, still make the entire
chain writable, as before.
Reviewed by: Nick Hudson
- Define _BUS_AVAIL_END to 0xffffffff, as we don't have an easy way to
find the upper bound for our machine address space (and this can change
when we swap pages with the hypervisor).
- implement _xen_bus_dmamem_alloc_range(), which will request a contigous
set of pages to the hypervisor if the pages returned by uvm_pglistalloc()
don't fit the constraints.
We can't deal with the low/high constraints yet, because Xen doesn't offer a
way to get pages in a specific ranges of addresses.
Based on patches from Dave Thompson (in private mail), with heavy hacking
by me.
- Allow _bus_dmamem_alloc_range to be provided from external source:
Use a _PRIVATE_BUS_DMAMEM_ALLOC_RANGE macro, defined to
_bus_dmamem_alloc_range by default.
- avail_end is the end of the physical address range. Define a macro
_BUS_AVAIL_END (defined by default to avail_end) and use it instead.
the generic pci_enumerate_bus() in Xen because the hypervisor may
hide the function 0, but give access to other functions of the same device
and pci_enumerate_bus() will stop if function 0 isn't available.
Ceri Storey to port-xen, with some additionnal changes by me:
- include bus_dma.c, bus_space.c and pci_machdep.c if pci is defined
instead of dom0ops
- Make various initialisations, and probe/attach pci busses based on NPCI
instead of DOM0OPS
- in conf/files.xen, move xen-specific devices before non-xen specific devices
so that the xen-specific match function is called first, to avoid false
attachement from too liberal match function in non-xen code.
-fill in the 802.11 "duration" before
-use the intended channel (still not perfect because this is not
necessarily the hardware setting, but better than before)
while this doesn't make the driver work for me, it kills some
red herrings which I've just wasted time for
- remove driver-private key allocators; use the default one instead
so wpa keys are handled properly (if_ral.c, if_ural.c rev 1.9)
- remove local mods that snuck into rev 1.6 (if_ral.c rev 1.10)
before testing the key flags.
XXX Problems remain. Nick Hudson points out my questionable
XXX M_COPY_PKTHDR usage. Also, it seems to me that we may not be
XXX protected against writing a read-only mbuf during the crypto
XXX encapsulation stage, even if hardware does the actual crypto.
jmmv