There is no need to use the lower 4 bits of the unit number to store the
device type number. Just use 0 and 1 to distinguish them. devfs also
guarantees that there can never be an open call on a device that has a
unit number different to 0 and 1, so there is no need to check for this
in open().
d_uid, d_gid and d_mode are unused, because permissions are stored in
cdevpriv nowadays. d_kind doesn't seem to be used at all. We no longer
keep a list of cdevsw's, so d_list is also unused.
uid_t and gid_t are 32 bits, but mode_t is 16 bits, Because of alignment
constraints of d_kind, we can safely turn it into three 32-bit integers.
d_kind and d_list is equal in size to three pointers.
Discussed with: kib
Ensure target/lun passed from user-level supported on this bus.
Scanning unsupported IDs causes different issues from duplicate
devices to system crash.
zfs_access() instead of vaccess() in this case as well.
- If VADMIN is specified with another V* flag (unlikely) call both
zfs_access() and vaccess() after spliting V* flags.
This fixes "dirtying snapshot!" panic.
PR: kern/139806
Reported by: Carl Chave <carl@chave.us>
In co-operation with: jh
MFC after: 3 days
input to be in non-buffering mode so that input lines are logged
as they occur rather than being saved up until a buffer's worth of
input has been logged.
- Don't bother to assign vb until we know we have enough space
- Add variables for sx2, sy2, dx2, dy2 so that these aren't
calculated over and over, also reduce chance of errors.
- Use switch to assign color/format
MFC after: 3 days
- We don't need to check malloc return values with M_WAITOK
- remove variables that we don't really need
- cleanup the error paths by just calling drm_sg_cleanup()
- fix drm_sg_cleanup() to be safe to call at any time
MFC after: 2 weeks
bspatch thus does not verify file hashes, and that consequently it
is recommended that users store hashes separately and verify files
before and after running bspatch.
Requested by: BugMagnet
MFC after: 1 week
lock and curproc->p_sigacts->ps_mtx. Reschedule_signals may need to have
ps_mtx locked to decide and wakeup a thread, causing recursion on the
mutex.
Inform kern_sigprocmask() and reschedule_signals() about lock state
of the ps_mtx by new flag SIGPROCMASK_PS_LOCKED to avoid recursion.
Reported and tested by: keramida
MFC after: 1 month
portion of the capture buffer (db_capture_bufoff vs db_capture_bufsize).
This could result in outputting garbage (e.g. lots of 'p' characters if
DIAGNOSTIC is enabled) after the end of the capture buffer. While here,
fix a spelling nit.
Reported by: Mikolaj Golub to my trociny of gmail
MFC after: 3 days
obsoleted in 1996 by ATA-2, and crashes some modern hardware like some
revisions of the Serverworks K2 SATA controller. Even very ancient
hardware seems not to require it. In the unlikely event this causes
problems, the previous behavior can be re-enabled by defining
ATA_LEGACY_SUPPORT at the top of this file.
Reviewed by: Alexander Motin <mav@freebsd.org>
partially fixed on amd64 earlier. Rather than forcing linux_mmap_common()
to use a 32-bit offset, have it accept a 64-bit file offset. This offset
is then passed to the real mmap() call. Rather than inventing a structure
to hold the normal linux_mmap args that has a 64-bit offset, just pass
each of the arguments individually to linux_mmap_common() since that more
closes matches the existing style of various kern_foo() functions.
Submitted by: Christian Zander @ Nvidia
MFC after: 1 week
is installed, we should at least have the tzsetup tool available!
Suggested by: Andriy Gapon <avg@freebsd.org>
Noticed by: Ben Kaduk <minimarmot@gmail.com>
MFC after: 1 week
