icmp_error() packets. While here retire PACKET_TAG_PF_GENERATED (which
served the same purpose) and use M_SKIP_FIREWALL in pf as well. This should
speed up things a bit as we get rid of the tag allocations.
Discussed with: juli
of course, but I make an effort to accomodate GNU tar scripts that
use -o with -c (with a meaning that totally contradicts SUSv2) by
only issuing a benign warning message in that case.
using M_PROTO6 and possibly shooting someone's foot, as well as allowing the
firewall to be used in multiple passes, or with a packet classifier frontend,
that may need to explicitly allow a certain packet. Presently this is handled
in the ipfw_chk code as before, though I have run with it moved to upper
layers, and possibly it should apply to ipfilter and pf as well, though this
has not been investigated.
Discussed with: luigi, rwatson
information being sent to the RADIUS server.
Logging of RADIUS accounting information moves to a ``set log [+-]radius''
level, along with the RADIUS alive info, and the version number is bumped
to 3.2 to reflect this.
Mostly submitted by: alx@sm.ukrtel.net (back in January)
MFC after: 3 weeks
back into epoch time. Everytime I'm asked to do this by someone I
have to spend about ten minutes recreating the same command line.
So record it under examples.
since they are only accessed by curthread and thus do not need any
locking.
- Move pr_addr and pr_ticks out of struct uprof (which is per-process)
and directly into struct thread as td_profil_addr and td_profil_ticks
as these variables are really per-thread. (They are used to defer an
addupc_intr() that was too "hard" until ast()).
The attached patch fixes a number of problems present in rpc.lockd.
1)
Nfslocklist_head.lf_first is overwritten because of an off-by-one-bug
that happens when clnt_cache_next_to_use is incorrectly incremented.
2)
'struct sockaddr *addr' inside 'struct file_lock' is set to point to
the result from svc_getrpccaller(). This value is malloc:ed inside the
rpc libraries and is free:ed when clnt_destroy() is called. Fix,
maintain a copy of the result.
3)
The loop inside retry_blockingfilelocklist() that uses 3 pointers ifl,
nfl, and pfl thrashes the list pointed to by
blockedlocklist_head.lf_first. Fix, use a simpler loop. The new loop
does not preserve list order but the order is immaterial anyways. See
also revison 1.6-1.7 and kern/61122.
4)
struct file_lock
char client_name[SM_MAXSTRLEN];
and
struct host
char name[SM_MAXSTRLEN];
Be careful to not create open (non 0 terminated) C strings and later
passing them to e.g syslog. Fix, make sure that the strings are always
terminated with 0. When at it, move the strings to the end of the
structs and make them variable length. This saves about 1000 bytes for
every malloc:ed struct.
5)
The newfl = malloc(sizeof(struct file_lock)) memory was never properly
bzero:ed.
Minor changes:
A)
Nlmtonlm4(0) made assumptions about struct layouts.
B)
Don't close stdout and stderr when debugging (-d option).
C)
Remove unused pid_t locker and int fd in struct file_lock.
D)
s/printf/debuglog/
E)
Remove redundant sleep(1) and call to debuglog().
Cheers,
Björn
define NULL. This means we cannot use NULL in the definition of CMSG_NXTHDR.
So replace NULL with 0.
PR: kern/60309
Submitted by: Jeff King <peff-freebsd@peff.net>
left around after the PCI probe, acpi_video stopped attaching because while
it was an acpi child device, it really is a PCI device. Fix this by making
it a PCI child.
* Remove non-handle ivars accesses since child busses only implement
acpi_get_handle().
* Access the acpi softc directly through the devclass instead of through
the implied parent.
* Clean up a potential panic on unload by freeing the sysctl context before
storing NULL in the OID.
Found by: marks
apply the patch of bin/61718 (which should include/elimatate kern/61122 also).
It seems to fix a few annoying bugs.
PR: bin/61718, kern/61122
Submitted by: bg@sics.seohartman@mail.physik.uni-mainz.de
- Unlike the builtin relational operators, builtin floating-point
constants were not available until gcc 3.3, so account for this.[1]
- Apparently some versions of the Intel C Compiler fallaciously define
__GNUC__ without actually being compatible with the claimed gcc
version. Account for this, too.[2]
[1] Noticed by: Christian Hiris <4711@chello.at>
[2] Submitted by: Alexander Leidinger <Alexander@Leidinger.net>
