disk_striped: Fix the divide-by-zero error when chunk_size_in_kb field is missing in VTL2 settings

[SrinivasShekar]

Issue:

The VTL2 settings processing code crashes with a divide-by-zero panic when the chunk_size_in_kb field is missing from LUN configurations in the protobuf schema.

Closes: #1796

Fix:

Fix the code wherein chunk_size_in_bytes takes the default value when the field is missing in the protobuf schema.

From the striped code,

// If chunk_size_in_bytes is missing in protobuf, the below code will be Some(0).unwrap_or(..) which will result in zero.
let chunk_size_in_bytes = chunk_size_in_bytes.unwrap_or(CHUNK_SIZE_128K); 
....
let sector_count_per_chunk = (chunk_size_in_bytes / sector_size) as u64;  // Will result in divide-by-zero.

Include a conditional filter for setting the chunk_size to default(CHUNK_SIZE_128K) for such scenarios.

Validation:

Locally ran vmm_tests(striped_disk related tests) successfully.

Nextest run ID eeab7f93-a5a0-45a0-9ebf-3fad41281477 with nextest profile: default
Starting 2 tests across 2 binaries (171 tests skipped)
Running [ 00:00:00] 0/2: 0 running, 0 passed, 0 skipped
SLOW [> 60.000s] vmm_tests::tests x86_64::storage::openvmm_openhcl_uefi_x64_ubuntu_2504_server_x64_openhcl_linux_stripe_storvsp
SLOW [> 60.000s] vmm_tests::tests x86_64::storage::openvmm_openhcl_linux_x64_openhcl_linux_stripe_storvsp
PASS [ 97.852s] vmm_tests::tests x86_64::storage::openvmm_openhcl_linux_x64_openhcl_linux_stripe_storvsp
SLOW [>120.000s] vmm_tests::tests x86_64::storage::openvmm_openhcl_uefi_x64_ubuntu_2504_server_x64_openhcl_linux_stripe_storvsp
SLOW [>180.000s] vmm_tests::tests x86_64::storage::openvmm_openhcl_uefi_x64_ubuntu_2504_server_x64_openhcl_linux_stripe_storvsp
PASS [ 184.070s] vmm_tests::tests x86_64::storage::openvmm_openhcl_uefi_x64_ubuntu_2504_server_x64_openhcl_linux_stripe_storvsp
────────────
Summary [ 184.140s] 2 tests run: 2 passed (2 slow), 171 skipped

[Copilot]

Pull Request Overview

Fixes a divide-by-zero panic in the disk striping functionality when the chunk_size_in_kb field is missing from VTL2 settings protobuf schema. The issue occurred because missing protobuf fields default to 0, which caused division by zero in subsequent calculations.

• Adds a filter to check for zero chunk size values before using the default
• Prevents divide-by-zero errors when chunk_size_in_kb is missing from protobuf

[mattkur]

Elegant fix, but given that this code is already doing some validation, suggest you actually just return an error to the user. Or, are there some cases where you think this would regress something?

[SrinivasShekar]

TFTR Matt!

There are two scenarios where chunk_size_in_bytes will be Some(0)
(1) when it's not explicitly specified in the VTL2 settings - This is possible as per the bug
(2) set to 0 by the user.

Now for the latter scenario, we could return an error but for the former, IMO, it would break the existing user experience and tests probably (tests should be okay as we could fix them up).

But the intention of using unwrap_or() on chunk_size_in_bytes field was to set it to default when it's not specified, hence followed on the similar lines to accommodate the fix.

Please let me know your thoughts too :)

[smalis-msft]

If this is a case where a field is missing why are we deserializing it into Some(0) instead of None?