| Age | Commit message (Collapse) | Author |
|
Drain input buffer for unhandled input.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
don't byteswap it.
|
|
The minor numbers have only four bits for the unit number, so unit
numbers past 15 can't be represented as is. Attempting to revoke
them was once harmless, when the system made no attempt to avoid
open/detach races; now it crashes because vdevgone assumes that the
minor number can be mapped back to an autoconf device, but it's the
wrong one. With this change, we stop trying to revoke units beyond
15, because they can't be opened anyway (which may be a bug in its
own right, requiring expansion of the minor number encoding!).
Reported-by: syzbot+6634ffd48997ae9b1eb0@syzkaller.appspotmail.com
https://syzkaller.appspot.com/bug?id=db40a795a0b078f9b3b9fa0d3b7a9addcd2534de
Reported-by: syzbot+d2df39bb3f72975c0a97@syzkaller.appspotmail.com
https://syzkaller.appspot.com/bug?id=cbdd598287529cff9a8c4230263f7414df88db4b
Reported-by: syzbot+1404969f68424f8f6e4b@syzkaller.appspotmail.com
https://syzkaller.appspot.com/bug?id=6e4782408d0351769215fe433986f1844a546774
Reported-by: syzbot+2a4174a65609b3a00abb@syzkaller.appspotmail.com
https://syzkaller.appspot.com/bug?id=886bbee544c2337683e24c801f9b632630a24681
Reported-by: syzbot+c0d9e49f22e571650736@syzkaller.appspotmail.com
https://syzkaller.appspot.com/bug?id=7fb2e5576ebae731e859283f85c97747d2824f35
Reported-by: syzbot+583ba2cdb8aa6e59a4bf@syzkaller.appspotmail.com
https://syzkaller.appspot.com/bug?id=2af44f5245eba572ebfb222070b9fd1378854303
|
|
- Allocate the usrbuf from kmem(9) instead of uvm(9). The usrbuf has used
uvm(9), in case mmap(2) might be issued later. However, despite the most
apps don't use mmap(2), allocating (and reallocating) uvm(9) every time
would be expensive. In addition, uvm(9) for recording usrbuf was totally
pointless now.
- For playback, the usrbuf memory will be allocated in pages. Because the
usrbuf for playback is mostly near 64KB for backward compatibility.
This will reduce reallocation especially from the initial ulaw to the most
commonly used format like slinear16/2ch/48kHz.
- When mmap(2) is called, it will replace the playback usrbuf from kmem(9) to
uvm(9).
- Prohibit changing playback format once mmap(2) is called.
It follows netbsd-7.
- For recording, the usrbuf memory will be allocated in the requested size
every time as before. Because the usrbuf for recording is only one block
and is enough small to the page in the most case.
Inspired by PR kern/56947.
|
|
No functional change intended, just sprinkling assertions to make it
clearer.
|
|
|
|
- audio_realloc() never returns NULL, so there is no need to check it.
- audio_free() is no point in this case.
|
|
These were used at very early phase of development.
|
|
|
|
On NetBSD7, when AUDIO_FLUSH was issued, .offset of AUDIO_GETOOFFS was
reinitialized (to one block ahead from zero) or unchanged depend on
whether the user encoding is hardware native or not (probably).
I don't believe that it's intended or we need to maintain it.
Now, AUDIO_FLUSH always clears the offset to zero.
|
|
|
|
- Count .samples/.deltablks in blocks. It makes .deltablks integer wrap
around safe.
- Remove suspicious one block offset from .offset. I added the offset
because it was observed so on NetBSD7. But according to manpage, it
should not be. And it looks fine without the offset.
- Related to that, remove a comment in AUDIO_WSEEK.
Limit the user-visible buffer to usrbuf only.
|
|
Previously, main buffer in recording track was usrbuf, which is the closest
buffer to the userland. Because, this buffer arrangement was symmetrical
with the playback track, and had affinity with the past implementation.
However, in the current implementation, read(2) (from user application)
takes recorded block out from inputbuf, which is the closest buffer to
rmixer, to usrbuf. So it was not good way to use the usrbuf as main buffer.
Now, usrbuf in recording track holds only fragment bytes in order to
transfer to the userland, and main buffer in recording track is the inputbuf,
the closest to rmixer.
Buffer size of the inputbuf is also modified. Previously, it was less than
64KB or at least 4 blocks. This had affinity with playback track and the
past implementation. But this was not appropriate for both formats with
too large frames or too small frames. In large frames (for example,
192kHz/12ch), 184KB buffer would be allocated but it corresponds to only
40msec. In opposite, in small frames (for example, 8000Hz/1ch), 64KB
buffer would be allocated and it corresponds to 4.1 seconds. But for such
machines that have 8000Hz/1ch device, in-kernel 64KB memory would probably
be expensive.
Now, inputbuf will always be allocated 16(NBLKIN) blocks, regardless of its
hardware format. It corresponds to 160msec on modern archs (if blk_ms=10),
or 640msec on antique archs (if blk_ms=40).
|
|
Divide by case. Reduce to one line if possible.
|
|
Otherwise detach may barge ahead and start freeing things before open
has finished and is about to use them after free.
Reported-by: syzbot+31d2619e72c2c8436cc9@syzkaller.appspotmail.com
|
|
Cheaper and adequate to make an atomic_swap into a load-acquire.
|
|
interfaces, make sure that initialization and destruction
follow the proper sequence. This is triggered by the recent
changes to the devsw stuff; per riastradh@ the required call
sequence is:
devsw_attach()
config_init_component() or config_cf*_attach()
...
config_fini_component() or config_cf*_detach()
devsw_detach()
While here, add a few missing calls to some of the detach
routines.
Testing of these changes has been limited to:
1. compile without build break
2. no related test failures from atf
3. modload/modunload work as well as
before.
No functional device testing done, since I don't have any
of these devices. Let me know of any damage I might cause
here!
XXX Some of the modules affected by this commit are already
XXX broken; see kern/56772. This commit does not break
any additional modules (as far as I know).
|
|
|
|
|
|
|
|
|
|
By previous commit (r1.116), the assersion no longer fires even without
this modification. But the condition was a bit inaccurate.
There is no need to check the data length must be aligned to blocks here
(though it also should be aligned now). What we should check here is that
the tail must be aligned.
|
|
audio_track_record() must be called when usrbuf has at least one free block.
I hope that this will fix the panic reported in PR kern/56644.
When an user process specifies the hardware format as its recording format
(i.e., there is no track conversions), if the user process read(2) a small
amount of data and the rmixer_process then runs, depending on the conditions,
the panic may happen. I have never reproduced it because it's difficult to
do intentionally.
Thanks Y.Sugahara and riastradh@ for help and comments.
|
|
Built the wrong kernel to compile-test AUDIO_DEBUG, oops.
|
|
Won't affect anything on x86 because atomic r/m/w operations are
always full sequential consistency barriers, but might potentially
fix problems on, e.g., arm.
Note 1: I'm not clear on why the track lock is a bespoke mutex made
out of an atomic -- why not just mutex(9)?
Note 2: I'm not convinced the audio_mlog_flush synchronization is
correct; what happens if the softint runs on two CPUs at the same
time and swaps mlog_wpage simultaneously?
Note 3: Should maybe use atomic_load/store_relaxed for mlog_full and
mlog_drop, and atomic_inc/dec for mlog_refs.
|
|
|
|
|
|
|
|
Breaks another deadlock between sc_lock and high-priority xcalls at
softint serial. With any luck, this should be the last such softint
deadlock in audio!
|
|
Holding sc_lock is not necessary -- I reviewed all ~70 cases in-tree,
and none of them rely on state protected by sc_lock. Essentially
everything just copies from static data or data initialized at attach
time.
(Exceptions: tms320av110.c issues a bus_space_read_1, but I don't see
any reason why that needs to be serialized; and uaudio.c reads from
sc_dying, but that's not necessary and also not protected by sc_lock
anyway.)
Holding sc_lock is harmful because at least hdafg(4) can trigger module
autoload that leads to pserialize_perform, which waits for logic to run
at softint serial on all CPUs; at the same time, audio_softintr_rd/wr
run at softint serial and take sc_lock, so this leads to deadlock.
|
|
define a flag FILTEROP_ISFD that has the meaning of the prior f_isfd.
Field and flag name aligned with OpenBSD.
This does not constitute a functional or ABI change, as the field location
and size, and the value placed in that field, are the same as the previous
code, but we're bumping __NetBSD_Version__ so 3rd-party module source code
can adapt, as needed.
NetBSD 9.99.89
|
|
|
|
|
|
|
|
Minor KNF along the way.
|
|
at the same time. Fix PR kern/56308.
|
|
Instead of refusing to open /dev/audioN for writes when the device
doesn't support playback, just refuse to issue writes.
Although it seems more sensible to me to reject writable opens early
on, and it seems Solaris does so, this makes querying device
properties a little trickier and is a change to the NetBSD semantics.
|
|
Previously, in revision 1.100, I factored the SLIST_REMOVE out of
audio_unlink and audio_close up into audioclose since it is now used
by /dev/audio, /dev/audioctl, and /dev/mixer alike. But I didn't
realize that the order
1. audio_track_drain
2. SLIST_REMOVE from sc_files
was significant; it matters because audio_track_drain waits for
wakeups that are delivered by hardware interrupts only to files
listed in sc_files.
This also fixes a bug introduced with the audiobell -- it was missing
the SLIST_REMOVE altogether.
For now, duplicate the SLIST_REMOVE calls in a few more places --
this is suboptimal but I want to make sure the logic works before
factoring it all out to tidy up.
|
|
|
|
This is necessary so that on detach we set file->dying before any
operations, particularly audioclose, try to acquire a psref by the
time the audio softc is gone.
Candidate fix for PR kern/56164.
|
|
No other file operations are possible by the time we get to
audioclose.
|
|
Otherwise we may race with open, leaking a cred no longer in use and
freeing a cred still in use.
|
|
|