1. Adding a proper locking hierarchy with qdisc, tin, and flow level locks
2. Converting shared variables to use atomic operations
3. Making all configuration functions thread-safe
4. Protecting all critical sections with appropriate locks
5. Ensuring proper cleanup and initialization
The changes ensure that:
• Multiple threads can safely access the scheduler
• No race conditions exist in critical sections
• All shared data is properly protected
• Proper locking order prevents deadlocks
• Memory barriers ensure visibility of changes
I'm not a kernel programmer (but I do code low level C, C++ and Rust professionally). And that diff file looks odd to me.
Since C doesn't dispatch on type, shouldn't you change uses to also use atomic operations on the atomic variables? In particular I would expect great care being taken to use the proper memory access type (relaxed, acquire, etc) for each case.
To me it looks incomplete, like the patch changes the types and inisitialises a few variables. But none of the uses are actually converted?
Edit: it looks like the diff is literally incomplete, the actual C and orig files have more differences that are not included?
My apologies, It appears my Ubuntu VM install has become corrupted with random file restores. I'll try to finish it soon. Time for a fresh install and Clonezilla haha.
Much appreciated.. I am no expert, and I love the work these guys do to improve the firmware - but I am worried too many changes happen at once, without properly testing them before moving on..
Personally I wish they would focus on 24.10 (when final is released), with tweaks to improve the MT600 further.. Atleast then we have a stable main branch to work off, rather than an ever changing SNAPSHOT branch.
I do appreciate the work these guys do, but my MT6000 is the main router and with wife and kids having it go up and down is not an option.
My personal observation on lots of Samsung phones (flagman models or not) is that all recent models use only 20 MHz on the 2.4 GHz band. And I think that is a deliberate limitation (unfortunately) by the manufacturer although the WiFi chipset (Qualcomm or any other) used may fully support 40 MHz. And I see many other manufacturers do exactly the same with their recent models.
For example Motorola Edge 30 Fusion supports 40 MHz with QAM-256.
It's a pity that this specification (limitation) is not listed officially anywhere or at least I cannot find it.
Yes I know all the hurdles of using 40 MHz but in my local environment that is not an issue and I can get the benefits of using it even with the added support for QAM-256 in 2.4GHz 802.11n.
Life on the SNAPSHOT branch is not for the faint of heart. My household has not yet complained on any instability, I try to flash and evaluate after "office hours"
I fully understand that.. I just wish they focused on 24.10 MAIN once released, made their tweaks and released as a "stable" tweaked version of 24.10..
But again, I am happy to install the latest Pesa (with or without snapshot), provided it is stable - unfortunately I am unable to assist with any beta testing, which I know some of you are.. (and all credit to you).
The WiFi alone is like night & day compared to stock 23.05.5. I've done 1 week on/off with each and the Pesa 4.4.6 is amazing. It's what stock should be but won't because of politics.
I would suggest modifying the existing wan rule to add similar rate limiting to IPv4 pings to prevent potential abuse/ping flood attacks. This would still allow legitimate ping checks but prevent someone from overwhelming your router with a flood of ICMP requests.