SYSCTL_PROCs and check that the default mss for neither v4 nor
v6 goes below the minimum MSS constant (216).
This prevents people from shooting themselves in the foot.
PR: kern/118455 (remotely related)
Reviewed by: silby (as part of a larger patch in March)
MFC after: 2 months
duplication of code in fdisk and boot0cfg. Also make use of g_providername to
fix an issue with fdisk and boot0cfg not using the correct provider when
writing the MBR.
Reviewed by: phk
Approved by: pjd (mentor)
- Add a routine for looking up a device and checking if it is a valid geom
provider given a partial or full path to its device node.
Reviewed by: phk
Approved by: pjd (mentor)
somehow.
As a consequence we may now get an unexpected result(*).
Catch that error cases with a well defined panic giving appropriate
pointers to ease debugging.
(*) While the concensus was that the case should never happen unless
there was a bug, noone was definitively sure.
Discussed with: kmacy (about 8 months back)
Reviewed by: silby (as part of a larger patch in March)
MFC after: 2 months
This is different to the first one (as len gets updated between those
two) and would have caught various edge cases (read bugs) at a well
defined place I had been debugging the last months instead of
triggering (random) panics further down the call graph.
MFC after: 2 months
logic here gets a little complex, but the net effect is that the
SECURE_SYMLINKS flag will prevent us from ever following a symlink.
Without it, we'll only follow symlinks to dirs. bsdtar specifies
SECURE_SYMLINKS by default, suppresses it for -P.
I've also beefed up the write_disk_secure test to verify this
behavior.
PR: bin/126849
the default rule number but also the maximum rule number. User space
software such as ipfw and natd should be aware of its value. The
software that already includes ip_fw.h should use the defined value. All
other a expected to use sysctl (as discussed on net@).
MFC after: 5 days.
Discussed on: net@
As discussed with Robert on IRC, checking the permissions on
/dev/console to see if we can call TIOCCONS could be unreliable. When we
run a chroot() without a devfs instance mounted inside, it won't
actually check the permissions on the device node inside the devfs
instance.
Using the already existing PRIV_TTY_CONSOLE for this seems like a better
idea.
Approved by: rwatson
Initially, 'acl' (an 'acl_t *') is allocated, and its ACCESS_ACL and
DEFAULT_ACL fields are passed to the 'libc' ACL routines for subsequent
allocation. If the '-m' option (merge existing ACL with a new one) is
specified, then 'set_acl_mask()' will be called and passed one of the
two ACLs. This function, in turn, replaces this given ACL structure by
another, freshly allocated. However, the pointer in the 'acl' variable
in the caller is not updated. The caller then proceeds to free the ACL,
incurring in a double free condition.
Submitted by: Pedro Martelletto <pedro at ambientworks.net>
Approved by: rwatson (mentor)
reading from EEPROM doesn't seem to work on these controllers.
Reported by: Milan Obuch ( freebsd-net at dino dot sk )
Tested by: Milan Obuch ( freebsd-net at dino dot sk )
driver will need more serious help to work with an interrupt driven
path. There's many subtleties in driving the DMA engine with
interrupts in many configurations. Best to not "guess" what the right
way would be and mislead people.
memory allocation. It was change to include the range in the normal
memory area, so these ifdef'd out special cases are no longer useful
to keep around.
the device indicates that it wasn't able to write all the data in the
buffer out.
Ed Schouten doesn't like the idea of a panic here. I think for
production code, we need something better. For right now, while we're
trying to assess the impact of this issue, a panic is OK. So complain
to me, not him if this is hit.
