I noticed on a system at home that restarting named(8) causes the
/var/named/dev mount to be moved to the bottom of the mount list,
because it gets remounted. When I received the daily security email this
morning, I was quite amazed to see that the security report listed the
differences, while it was nothing out of the ordinary.
If we just throw the `mount -p' output through sort(1), we'll only
receive notifications about changes to mounts if something has really
changed.
are possibly still being created. The d_secperunit field
contains the number of sectors of the disk and not of the
slice/partition to which the disklabel applies.
Rather than reject the disklabel, we now silently adjust
the field. Existing code, like bslabel(8), does not seem
to check the label that extensively and seems to adjust
fields as a side-effect as well.
In other words, it's not that important apparently, so
gpart should not be too strict about it.
Reported by: nyan@
Reported by: Andriy Gapon <avg@icyb.net.ua>
Olaf Kirch noticed that the i915_set_status_page() function of the i915
kernel driver calls ioremap with an address offset that is supplied by
userspace via ioctl. The function zeroes the mapped memory via memset
and tells the hardware about the address. Turns out that access to that
ioctl is not restricted to root so users could probably exploit that to
do nasty things. We haven't tried to write actual exploit code though.
It only affects the Intel G33 series and newer.
Approved by: bz (secteam)
Obtained from: Intel drm repo
Security: CVE-2008-3831
Memory Interface (CFI). The flash memory can be read and written
to through /dev/cfi# and an ioctl() exists so processes can read
the query information.
The driver supports the AMD and Intel command set, though only
the AMD command has been tested.
Obtained from: Juniper Networks, Inc.
established a valid link or not.
In rl_start_locked, don't try to send packets unless we have valid
link. While I'm here add a check that verifies whether driver can
accept Tx requests by inspecting IFF_DRV_OACTIVE/IFF_DRV_RUNNING
flag.
- The hardware does not support DAC so limit DMA address space to
4GB.
- Removed BUS_DMA_ALLOC_NOW flag.
- Created separated Tx buffer and Rx buffer DMA tags. Previously
it used to single DMA tag and it was not possible to specify
different DMA restrictions.
- Apply 4 bytes alignment limitation of Tx buffer.
- Apply 8 bytes alignment limitation of Rx buffer.
- Tx side bus_dmamap_load_mbuf_sg(9) support.
- Preallocate Tx DMA maps as creating DMA maps take very long time
on architectures that require real DMA maps.
- Adjust guard buffer size to 1522 + 8 as it should include VLAN
and additional reserved bytes in Rx buffer.
- Plug memory leak in device detach. Previously wrong buffer
address was used to free allocated memory.
- Added rl_list_rx_init() to clear Rx buffer and cleared the
buffer.
- Don't destroy DMA maps in rl_txeof() as the DMA map should be
reused. There is no reason to destroy/recreate the DMA maps in
this driver.
- Removed rl_dma_map_rxbuf()/rl_dma_map_txbuf() callbacks.
- The hardware does not support descriptor based DMA on Tx side
and the Tx buffer address should be aligned on 4 bytes boundary
as well as manual padding for short frames. Because of this
hardware limitation rl(4) always used to invoke m_defrag(9) to
get a 4 bytes aligned single buffer. However m_defrag(9) takes
a lot of CPU cycles on slow machines and not all packets need
the help of m_defrag(9). Armed with the information, don't
invoke m_defrag(9) if the following conditions are true.
1. Buffer is not fragmented.
2. Buffer is aligned on 4 bytes boundary.
3. Manual padding is not necessary.
4. Or padding is necessary but upper stack passed a writable
buffer and the space needed for padding is satisfied.
This change combined with preallocated DMA maps greatly
increased Tx performance of driver on sparc64.
- Moved bus_dmamap_sync(9) in rl_start_locked() to rl_encap() and
corrected memory synchronization operation specifier of
bus_dmamap_sync(9).
- Removed bus_dmamap_unload(9) in rl_stop(). There is no need to
reload/unload Rx buffer as rl(4) always have to copy from the
buffer. It just needs proper bus_dmamap_sync(9) calls before
copying the received frame.
With this change rl(4) should work on systems with more than 4GB
memory.
PR: kern/128143
with several points unappropriate for the present parser. This patch
disables input-to-output analog monitoring but instead fixes recording.
Tested by Tobias Grosser on ThinkPad T61p.
from the description but not the errors section. This revision removes it
from the errors statement.
Add a statement about the non-portability of non-page-aligned offsets.
might make Qualcomm and Option cards (which have all endpoints in 1
interface) work.
- Change the USB buffer sizes to depend on the transfer speed. With UMTS
we use a buffer 384k / 1000 frames/sec * 50msecs =~ 15kB for example.
- Add a MODULE_VERSION statement
when thread is in kernel mode, it can cause dead loop, now unlock
process lock after acquired sleep queue lock and thread lock to
avoid the problem. This means TDF_NEEDSIGCHK and TDF_NEEDSUSPCHK must
be set with process lock and thread lock being hold at same time.
but I inadvertently overwrote the change when I synced to git. Commit
the fix in both places, so this doesn't happen again.
Approved by: jhb (mentor)
MFC after: 2 weeks
This update fixes a transmit bug in the multi-queue (MSI-X) firmware
which happens when RDMAs complete out of order, and provides
improved support for the new Myri10GE NIC models (10G-PCIE-8Bx)
Sponsored by: Myricom Inc.
MFC after:3 days
With our new TTY layer we use a two step device destruction procedure.
The TTY first gets abandoned by the device driver. When the TTY layer
notices all threads have left the TTY layer, it deallocates the TTY.
This means that the device unit number should not be reused before a
callback from the TTY layer to the device driver has been made. newbus
doesn't seem to support this concept (yet), so right now just add a
destructor with a big comment in it. It's not ideal, but at least it's
better than panicing.
Reported by: rnoland
unnecessary, the normal process lock and thread lock are enough. The
spin lock is still needed for process and thread exiting to mimic
single sched_lock.
