address specified in the ioctl and for drivers that need the address
to locate a key (e.g. for delete).
Note this changes net80211-private api's but not the driver callback;
may want to change that in the future.
Reviewed by: sephe, thompsa
on amd64. Note the only difference is the iovec32 part so I use the
native structure for everything else.
Also I plan to MFC all the changes in -current to 7-stable and 6-stable
shortly since I've been running them. This does not include the cam
changes.
MFC after: 3 days
o construct a name for the com lock as done for other locks
o pass the device name to IEEE80211_LOCK_INIT so the mtx name
is constructed as foo_com_lock
o introduce *_LOCK_OBJ macro's to hide the lock contents and
minimize redundant code
Right now we perform some of the checks inside the fcntl()'s F_DUPFD
operation twice. We first validate the `fd' argument. When finished,
we validate the `arg' argument. These checks are also performed inside
do_dup().
The reason we need to do this, is because fcntl() should return different
errno's when the `arg' argument is out of bounds (EINVAL instead of
EBADF). To prevent the redundant locking of the PROC_LOCK and
FILEDESC_SLOCK, patch do_dup() to support the error semantics required
by fcntl().
Approved by: philip (mentor)
inlining resulted in constant propagation to the extend that cmpval
was known to the compiler to be URWLOCK_WRITE_OWNER (= 0x80000000U).
Unfortunately, instead of zero-extending the unsigned constant, it
was sign-extended. As such, the cmpxchg instruction was comparing
0x0000000080000000LU to 0xffffffff80000000LU and obviously didn't
perform the exchange.
But, since the value returned by cmpxhg equalled cmpval (when zero-
extended), the _thr_rtld_lock_release() function thought the exchange
did happen and as such returned as if having released the lock. This
was not the case. Subsequent locking requests found rw_state non-zero
and the thread in question entered the kernel and block indefinitely.
The work-around is to zero-extend by casting to uint64_t.
This makes blowfish password hashes look normal when set using
pw(8)/adduser(8). [1]
- Make it possible to have a '/' in the salt.
PR: 121146 [1]
Submitted by: Jaakko Heinonen [1]
Approved by: rwatson (mentor)
MFC after: 1 month
documents away from being public accessible. Replace link to
the Bluetooth specification document with the document name.
Pointed out by: SoftLover < slserg at uic dot tula dot ru >
MFC after: 3 days
which label mbufs. This leak can occur if one policy successfully allocates
label storage and subsequent allocations from other policies fail.
Spotted by: rwatson
MFC after: 1 week
and be usable in scripts, etc.
This also changes the semantics in case when we lose one of n packets.
In that case, before we exited by SIG, now we exit with return(0).
Submitted by: Gert Doering (gert space.net)
MFC after: 10 days
characters. [1]
Add $FreeBSD$ tag so that I can actually commit this.
PR: bin/118782
Reported by: Bjoern Koenig
Patch by: edwin, Jaakko Heinonen (not used patch)
MFC after: 1 week
Approved by: imp (mentor, implicit)
Because clists are also used outside the TTY layer, rename the file
containing the clist routines to something more accurate.
The mpsafetty TTY layer doesn't use clists. It uses its own buffers,
which also implement the unbuffered copying to userspace. We cannot
simply remove the clist routines then, because this would break various
drivers that are present within the kernel.
Approved by: philip (mentor)
When run without this option, multiple runs of `pkg_create -Rb' will
recreate common packages multiple times. This can take a lot of time
for large packages. With the -n option `pkg_create -b' checks with
stat(2) and skips packages that already exist.
Note that this may *not* be safe of the existing output file is not
really a package, or if it has been corrupted, modified or otherwise
tinkered with between subsequent pkg_create runs. For this and POLA
reasons, the default behavior is to *rebuild* the packages, and the -n
option can be used when we know it is `safe' to run in no-regenerate
mode.
Inspired by: A post to freebsd-questions
by Matthias Apitz < matthias.apitz at oclc.org >
Reviewed by: marcus, flz
Approved by: marcus
MFC after: 2 weeks
calling destroy_dev() with sleepable malloc(9). The entire opetation
is being serialized through pcm cv from top down, so dropping mutex is
rather safe.
Reported by: delphij
