On 2021-03-25 21:43, Arnout Vandecappelle wrote:
>
>
> On 25/03/2021 10:48, Felix Fietkau wrote:
>>
>> On 2021-03-24 13:27, Arnout Vandecappelle (Essensium/Mind) wrote:
>>> ubusd maintains a per-client tx_queue containing references to message
>>> buffers that have not been sent yet (due to
ubusd maintains a per-client tx_queue containing references to message
buffers that have not been sent yet (due to the socket blocking). This
is a fixed-size, 64-element queue.
When more than 64 elements are queued, subsequent elements are simply
dropped. Thus, a client that is waiting for those
No new message can be enqueued if this brings the total queue length of
that client over UBUS_CLIENT_MAX_TXQ_LEN.
Set UBUS_CLIENT_MAX_TXQ_LEN to UBUS_MAX_MSGLEN, i.e. 1MB. This limit
should be plenty for any practical use case.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind)
---
v3: new
On 25/03/2021 10:09, Sergey Zakharchenko wrote:
> Hi Arnout,
>
> JFYI: Much of your patch resembles
> https://patchwork.ozlabs.org/project/lede/patch/20180503100622.11168-1-i@qbox.audio/
> which was marked superseded for no apparent reason, but "anonymous
> remembers":).
It's delegated to
On 25/03/2021 10:48, Felix Fietkau wrote:
>
> On 2021-03-24 13:27, Arnout Vandecappelle (Essensium/Mind) wrote:
>> ubusd maintains a per-client tx_queue containing references to message
>> buffers that have not been sent yet (due to the socket blocking). This
>> is a fixed-size, 64-element
This became a bit of a tragedy, caused by a corner cases which wasn't
put into account during testing. DEFAULT_PACKAGES are defined in
target/linux//Makefile but also in
target/linux///target.mk.
The latter was no longer imported when using DUMP=1, however not using
DUMP=1 while running the
The CONFIG_USERIO option is unset in multiple target configurations. On
the sunxi target it is activated. Move the kernel configuration option
to the generic kernel configuration.
Signed-off-by: Hauke Mehrtens
---
target/linux/gemini/config-5.4 | 1 -
Instead of deactivating this in every target config, deactivate it once
in the generic kernel config. I was asked for this config option in a
x86 64 build in OpenWrt 21.02.
Signed-off-by: Hauke Mehrtens
---
target/linux/generic/config-5.10| 1 +
target/linux/generic/config-5.4 |
On 2021-03-24 13:27, Arnout Vandecappelle (Essensium/Mind) wrote:
> ubusd maintains a per-client tx_queue containing references to message
> buffers that have not been sent yet (due to the socket blocking). This
> is a fixed-size, 64-element queue.
>
> When more than 64 elements are queued,
Hi Arnout,
JFYI: Much of your patch resembles
https://patchwork.ozlabs.org/project/lede/patch/20180503100622.11168-1-i@qbox.audio/
which was marked superseded for no apparent reason, but "anonymous
remembers":).
As for the limits, one of them could include a timeout (e.g. no
progress in writing
On 24/03/2021 09:31, Petr Štetiar wrote:
> Arnout Vandecappelle (Essensium/Mind) [2021-03-23 16:23:25]:
>
> Hi,
>
>> Note that this infinite tx_queue opens the door to a DoS attack.
>
> memory is not infinite, so I think, that some sensible upper limit should be
> kept. It might be much
On 24.03.2021 19:10, Adrian Schmutzler wrote:
The usual nitpicks below ...
Thanks for review!
+ [ "$magic" = "GT-AC5300" ] && {
+ echo "asus"
+ return
+ }
+
+ echo "unknown"
+}
One could modify this towards a case with default "unknown" (and
12 matches
Mail list logo
