If the system is currently loading-up and populating
data and the user quits then it was crashing because
of a call to a deleted ProcessCoordinator object.
This change implements the reference as BReference
ensuring that the ProcessCoordinator object is only
deleted after it is not used anywhere.
Resolves #16109
Change-Id: If535c151819da37d502283af3745e4148da69026
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2797
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
(cherry picked from commit f95ec23e9582b09d2067c39903ea8cbbe7bf1e94)
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2800
This fixes a SEGFAULT in the tcp add-on reported in issue #15952. See
that issue for some analysis.
The short version is that, when closing a session over the loopback
interface, there is a special branch which skips the TIME_WAIT state
and instead just releases the socket while handling a RST/ACK
segment. If the timing is right this can lead to the reference
counts becoming imbalanced, leading to the code in tcp_receive_data
segfaulting when it tries to release the reference it acquired from
EndpointManager::FindConnection.
I can't find any other systems which skip the TIME_WAIT state with
loopback sessions, and I'm not entirely certain that it's a totally
safe thing to do anyway. This patch instead just treats local sessions
the same way it does a remote session and uses the TIME_WAIT state.
Any workload which creates and discards lots of ephemeral sockets can
just use SO_REUSEADDR to handle this situation like any other system.
To add a final bit of safety, the only place where a net_socket can be
used after calling gSocketModule->release_socket(net_socket*) is in
tcp_receive_data(). release_socket() returns true if the reference
count falls to zero, deleting the socket. There was an unused segment
action flag DELETE_ENDPOINT that I renamed to DELETED_ENDPOINT, which
is used by tcp_receive_data to know whether its safe to release its
reference to the socket after calling TCPEndpoint::SegmentReceived().
Change-Id: I2652fb225c3c8419234cfd627f74ff2de8402003
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2793
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
(cherry picked from commit 51dd385e3ea8651afd345d724193365cc47dacf2)
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2799
In single package mode there was a crash owing to the
status bar not being present. This may as well be
added because it provides some feedback that the
application is actually doing something. The
behaviour of this is not ideal because the feedback
could be better, but it will resolve the crash
issue this ticket is raising.
Resolves #15964
Change-Id: I603a7b163139859f0c46a35ead0809e5d82e0f8d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2791
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
(cherry picked from commit 87016f8f49d6de59aedcf9a26f64362a4abe1d46)
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2792
This class can potentially be accessed by multiple "tabs" (windows)
at once, so it must be read/write locked to account for that.
Fixes #16027.
Change-Id: I9cc741874caed4997497b03c8893bc2acb0e6fe7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2779
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
(cherry picked from commit f0a8640b45451b9891fa641144acc33b90ac9a23)
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2790
Each TCPEndpoint has two BufferQueue members, one for the send queue
and one for the receive queue.
If DEBUG_BUFFER_QUEUE is enabled, then most methods of BufferQueue
call BufferQueue::Verify(), sometimes twice. This member function
performs some sanity checking which requires iterating through every
net_buffer in the queue.
Disabling this in a debug build improved throughput by a factor of 5x
over the loopback interface on my laptop. Using iperf the measured
throughput went from 900Mbps to around 4.8Gbps.
This patch turns this sanity checking off for release builds.
* Rename DEBUG_BUFFER_QUEUE to DEBUG_TCP_BUFFER_QUEUE
* Change the default in BufferQueue.h to disabled
* Set DEBUG_TCP_BUFFER_QUEUE to KDEBUG_LEVEL_2 in
kernel_debug_config.h
Change-Id: I262dac5d7e2889d2942bbdcf6b667cc0cbafa4c8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2780
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
(cherry picked from commit 44a4bc5fd6d2bf7a0cfbaf303f6ec4b3f46f7142)
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2782
This change removes two mistakes I made a long time ago
that caused unnecessarily copying of lists of data. This
fix speeds up the UI alot.
This change also clears data in UI list elements when a
bulk load is requested. It stops clearing otherwise and
instead uses "add" and "remove" operations in the lists
which is OK now because the UI list elements are much
faster than they have been in the past. This removes
the strange clean-and-reload that was visible in the UI
previously.
A threaded package loading system was put in place a long
time ago, but with these performance improvements this
mechanism is no longer necessary; it has been removed to
simplify the code.
Fixes #16012
Change-Id: I393cee929695726539602b51630ae285fb8384f1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2748
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
(cherry picked from commit c419919252f9076761900fd4e7575407a554255e)
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2777
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The local storage of the various repositories' config
needs to cater for different generations of storage
formats and also needs to be able to swap out legacy
repository identifiers.
Change-Id: Ib4b3857254b7b703858eff6815e2d6c54d69da3c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1963
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
(cherry picked from commit 9d8d114499db1f50f105c48c1a2172ea56e18bcd)
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2776
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Our sniffing rule is not perfect, but it is already a lot better than
what was done here.
Partially fixes #14437 (the icons also fails parsing for other reasons,
but with an error message, at least)
Change-Id: I25475b419b5fbe863c71f553a336757d7950bf48
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2662
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
(cherry picked from commit 17626df948e1d384072e6a2f8eab4f7fc6a18d0a)
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2775
The parser was based on an old example from agg. NanoSVG is originally
based on the same code, but has lots of bugfixes. So it makes sense
to use it.
Nanosvg revision 25241c5a8f8451d41ab1b02ab2d865b01600d949
Fixes #5955, #8586, #13021.
Change-Id: I38ff9aa4e1d403c41979ebe42f7b45d4500a870c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2661
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
(cherry picked from commit 2a3b385efba22655c4d6ff61ed59203283392ad7)
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2774
Actually check that the replacement font contains the needed glyph.
Change-Id: I6d774361fcf16a36dc3d05ce8b0fe1cb407fabff
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2767
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
(cherry picked from commit 4dcd8c81b12790b0ad7661f3ab8742ae619996be)
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2771
See #15808. Installer does not do what it promises to do, that is, that is
clean the system folder and essentially perform a clean install. Instead all
packages are copied to /system/packages, but they are not activated. To make it
worse, the system is then unable to upgrade through pkgman later on, as it
bails with the error that the files already exist.
This change at least stops Installer from pretending to do a clean install.
Change-Id: I5e2b1f571a99f9f8c020f77c314974719346f750
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2760
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
_user_read_link: don't write after the buffer end, anytime the buffer is too
short. It should honor the user bufferSize, instead of using the link length.
normalize_path: null-terminates when bufferSize is lower than B_PATH_NAME_LENGTH.
Change-Id: If3892dc1ffc4aa7a79a333bbe607449ca409a7f0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2752
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
(cherry picked from commit 10b5c00fca4a3f2f957116aa599ae5d8f5705fcb)
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2757
libnvme can break up transfers that are too large, but to do so,
it allocates one nvme_request struct (of which it has a large,
but finite, pool) per segment. Since we are already iterating
over "vecs", we might as well cut off transfers after they
would otherwise go over the limit.
Individual IOVs that are too large are left alone, though;
libnvme can still handle this. But at least we no longer try
to do all I/O in one go.
Tested in a similar manner to the previous commit.
(cherry picked from commit 4d0ad37aba376be915192ae142345efd72e00342)
Change-Id: Ib3ebcd4954c260e75211205b8ec59e346b119ce2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2747
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The "offset" parameter was not actually an IOV offset, but actually
a byte offset across all IOVs... whoops. Somehow, this went unnoticed
as most controllers have large enough maximum transfer sizes
that we would in practice not hit the limit (even with bs=1M
dd tests!)
KapiX's controller, as seen in #16049, however, has a maximum
transfer size of 64 pages; much smaller than these other controllers,
so it did trigger this behavior and exposed the bug.
Tested by adding an artificial limit of 2 blocks as the max
transfer size (which makes things pretty slow, as you might
expect.)
(cherry picked from commit 8eb950cd6421ce20123c99b899d6d7e24dcdddd3)
Change-Id: Ia87ba4962d401da62fdff015b19809b8908bdf3b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2746
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Fixes partial transfers being reported as larger than they actually were.
Change-Id: If7feda4e10203e8b6f2fd563fa4dcfb2b6cfc0d1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2745
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This change will move the display of the featured packages
from a dynamic layout to one that is static. This should
improve layout consistency and ui performance as well as
introduce keyboard navigation in the featured packages
list.
Resolves #11675, #15012
Helps #14675
Change-Id: Iddac7a9562763c7a890ec5dcf633e94f84684f43
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2708
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
(cherry picked from commit 9883929b9cf86d48b4e6ee22ba22da30f0e1a998)
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2737
I added this function to make the queued requests logic more robust,
but I failed to notice that since it is called from nvme_qpair_submit_request,
it would just result in a deadlock of any qpair that had requests
queued.
May help with some of the "qpair lockup" tickets.
Change-Id: I5ff63b509ae8812356d0d33f019027d3159b6685
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2735
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
(cherry picked from commit cb53bf1e28eed6de3d3d94da913b1bbc3e2f9947)
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2736
We do not need to go through all the overhead of mutex_lock_with_timeout()
if there is in fact no timeout.
Change-Id: I7891ae9138a7d45be934ac53412b82546d52b901
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2730
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
(cherry picked from commit a3a192c1cb6b4ae2403ffe7f50b48c663549d061)
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2731
The window may be gone (if its B_QUIT_REQUESTED was called before the
main Deskbar window one), so we can't safely call Quit() on it. Instead,
just send a B_QUIT_REQUESTED through the BMessenger, which is a bit
safer.
Should fix #16026.
Change-Id: I4c99c3a7f994044c3c3f0c08b35ae451c3ff9ea7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2721
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
(cherry picked from commit 54bff8ec8213acf63f2dae914560c9fac575dc45)
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2726
* Moved 'Power Off' on top of 'Restart system'.
* Made a few visual changes to the code that adhere better to the Haiku coding style.
* 'Suspend' is now at the bottom of the shutdown submenu.
Change-Id: I0d41e3e5656d5d9ea02e3cb072b6a6092c70c640
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2701
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
(cherry picked from commit 79ca65ac9d561fe4c83f88a015350e9f591d8b2c)
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2723
I forgot to change MUTEX_INITIALIZER following removal of the
unused field.
Change-Id: I011c023ae00bb4576c8bcecf83546892fef3a77e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2719
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
(cherry picked from commit e54b2d7cf2012fd0021025b0bb812838841fbd59)
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2720
As far as I can tell, there is no reason to ignore unlocks, ever;
if no threads are waiting, then mutex_unlock() will act appropriately.
So all we need to do is increment the lock's count here,
as we are relinquishing our request for locking.
On the other hand, if we did not find our structure in the lock,
that means we own the lock; so to return with an error from here
without changing the count would result in a deadlock, as the lock
would then be ours, despite our error code implying otherwise.
Additionally, take care of part of the case where we have woken up
by mutex_destroy(), by setting thread to NULL and checking for it
in that case. There is still a race here, however.
May fix #16044, as it appears there is a case where ACPICA
calls this with a timeout of 0 (we should make this be
a mutex_trylock, anyway.)
Change-Id: I98215df218514c70ac1922bc3a6f10e01087e44b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2716
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
(cherry picked from commit fd161d7bf2e391af79507f3710f4ac27e22fc88c)
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2718
