Bug: `KernelPtConfig::item_from_raw` does not restore an exacly same `MappedItem`

[rikosellic]

@hiroki-chen @Marsman1996 @SNoAnd According to the documentation, PageTableConfig::item_from_raw should restore the exact item that item_into_raw consumed. Unfortunately, KernelPtConfig failed to clear the AVAIL1 bit, which is used to indicate trackedness, violating the documented constraint and complicating verification.

As the PageTableConfig has been refactored in newer Asterinas versions, I propose changing this code to deal with AVAIL1 only in our codebase in #622 to make our verification smoother.

vostd/ostd/src/mm/page_table/mod.rs

Lines 108 to 110 in f918b43

	/// - if the provided raw form matches the item that was consumed by
	/// `item_into_raw`, `item_from_raw` restores the exact item that was
	/// consumed by `item_into_raw`.

[Marsman1996]

As the PageTableConfig has been refactored in newer Asterinas versions,

Reproduced in the latest version of Asterinas (main b91ce0947fa3cc5af74d6a1cadd8745cca48dc1d), with ktest

#[ktest]
fn kernel_pt_tracked_item_second_roundtrip_panics() {
    let frame = FrameAllocOptions::new().alloc_frame().unwrap();
    let item = MappedItem::Tracked(frame.into(), default_prop());

    let (paddr, level, prop) = KernelPtConfig::item_into_raw(item);
    assert!(prop.priv_flags.contains(PrivilegedPageFlags::AVAIL1));

    // SAFETY: These are the unchanged raw parts returned by `item_into_raw`,
    // so ownership of the tracked frame is transferred back to `item`.
    let item = unsafe { KernelPtConfig::item_from_raw(paddr, level, prop) };

    // Panics because `item_from_raw` retained `AVAIL1` in the item property.
    let _ = KernelPtConfig::item_into_raw(item);
}

the log

---- /root/asterinas/ostd/src/mm/kspace/test.rs:25:0 - kernel_pt_tracked_item_second_roundtrip_panics ----

[caught panic] Panicked at /root/asterinas/ostd/src/mm/kspace/mod.rs:160:17
assertion failed: !prop.priv_flags.contains(PrivilegedPageFlags::AVAIL1)

[rikosellic]

Should we report this to the kernel devs?

[Marsman1996]

I may create a PR for this this afternoon

[Marsman1996]

However, considering PR asterinas/asterinas#3587, it appears that the developers intentionally use assert or debug_assert as a guard, so a panic in this case may be considered acceptable.

Therefore, I now think we should report this as an issue for discussion rather than submit a PR directly.

[rikosellic]

Created an issue asterinas/asterinas#3597.