cifs: enable and harden SMB3 multichannel on vendor 5.15

[juanruizm001]

Motivation

On the Xiaomi TV Box S 3rd Gen, the USB-attached Ethernet path is practically limited to the mid-300 Mbit/s range while 5 GHz Wi-Fi has substantial independent capacity.

The goal of this series is to let one SMB3 session use Ethernet and Wi-Fi concurrently via SMB Multichannel, so one real media application can benefit from aggregate bandwidth while retaining a surviving path if one transport is lost.

What was missing

The vendor 5.15 tree already contained cifs_try_adding_channels() and the basic multichannel data structures. The original functional gap was that the normal non-DFS cifs_mount() path did not invoke the channel-opening helper after mount.

The first commit adapts the upstream channel-opening behavior to that non-DFS vendor path. Subsequent commits adapt later upstream fixes for channel selection/loading, per-channel reconnect, reconnect serialization, reconnect-aware request selection, and read/write retry/replay behavior.

Tested head: 3294f2c166d2ce27d523f84243763b57e5641352

Base: CoreELEC/linux-amlogic:5.15.196_20260306 at 69e87fa40cc3a04bf91d92e388d2787a2efcb50c

Test environment

• Xiaomi TV Box S 3rd Gen / MDZ-32-AA
• CoreELEC 22 Piers
• Linux 5.15.196
• Samba server on ZimaOS
• SMB 3.1.1
• dedicated Ethernet SMB path: 10.77.77.2/30 <-> 10.77.77.1
• dedicated Wi-Fi SMB path: 10.77.78.2/30 <-> 10.77.78.1
• productive mount: /storage/zimaos
• normal productive state: CH=2 CH_ETH=1 CH_WIFI=1

Validation summary

Kernel acceptance matrix

51 scenarios completed: 48 PASS / 3 FAIL.

Local 4-reader capacity (cache=none, wire rate):

• ETH: 351.959 Mbit/s
• Wi-Fi: 247.500 Mbit/s
• BOTH: 535.459 Mbit/s

BOTH is about +52.1% above Ethernet-only and reaches about 89.3% of the arithmetic sum of the independently measured ETH and Wi-Fi ceilings.

All controlled synthetic READ reconnect scenarios passed, including intentional Wi-Fi and double-link loss. All WRITE reconnect scenarios passed their integrity checks.

One external 3DFF movie/double-drop failure coincided with demonstrated rclone/VFS backend degradation.

Two local Wi-Fi-only non-drop scenarios lost the original test SessionId mid-transfer. Both had already transferred normally before the identity disappeared.

Definitive Kodi production-direct matrix

Final accepted result set: 36/36 PASS.

Kodi always used /storage/zimaos, exactly one CIFS mount was allowed, and BOTH used the real productive CH=2/E=1/W=1 session.

Across six media files and two cache profiles, BOTH peak-1-second throughput exceeded the matched ETH result in 12/12 comparisons, with an average gain of about 25.5%.

Examples:

• Forrest ALL128: 362.288 ETH -> 491.197 BOTH Mbit/s
• Avengers ALL128: 361.125 ETH -> 499.521 BOTH Mbit/s

Across accepted BOTH scenarios, traffic was split approximately 50/50 between Ethernet and Wi-Fi. This is the main application-level result: one Kodi application using one SMB session family can consume capacity from both TCP transports and exceed the Ethernet-only ceiling.

The accepted set was completed with a reboot/resume after the first attempt at scenario 21 hit the residual issue below. That failed attempt is preserved separately as forensic evidence.

Residual Wi-Fi-only reconnect/session event

A later Wi-Fi-only failure was captured while the physical Wi-Fi link was still healthy (-41 dBm, carrier=1, operstate=up, route/neighbor valid), while CIFS entered reconnect/disconnected state and the channel count dropped to zero.

After reboot the identical scenario passed and the remaining campaign completed.

This resembles the two earlier SessionId-loss events, but the evidence does not prove identical root cause. Because the controlled reconnect battery passes intentional ETH/Wi-Fi/double link drops, I currently classify this as a rare, stress-sensitive session/reconnect-lifecycle edge case rather than a deterministic failover failure.

I would appreciate maintainer guidance on whether this resembles a known 5.15 CIFS reconnect issue and which newer fixes or tracing would be most useful for a focused follow-up.

AI assistance disclosure

I used AI assistance extensively for source comparison, upstream commit discovery, test-script drafting, log analysis, and documentation.

AI output was not accepted as evidence or applied blindly. Changes were traced to upstream work, adapted to this vendor tree, compiled, and validated through many laboratory iterations on real hardware. The 51- and 36-scenario matrices are the final acceptance evidence, not the full development history.

I remain responsible for the submitted code and for addressing review feedback.

Evidence package

A curated public evidence archive is ready to attach to this draft before marking it ready for review.

Archive: CoreELEC_SMBMC_Public_Submission_Evidence_20260913_v2.tar.gz

SHA-256: 3086abc890832516fe23ad3b7305fd49408b8c7676cfcc15b4c66e7cc29d1ae5

It contains the raw 51-test evidence, the definitive Kodi evidence, the forensic failure capture, exact runners, tables, plots, architecture/flow notes, and SHA-256 manifests.

CoreELEC_SMBMC_Public_Submission_Evidence_20260913_v2.tar.gz