[LU-660] OSC procfs data is accessible when OSC is not ready to process it

• Status: Resolved
• Project: Lustre
• Affects Version/s: Lustre 2.1.0
• Type: Bug
• Priority: Minor
• Reporter: Mikhail Pershin
• Assignee: WC Triage
• Resolution: Low Priority
• Severity: 3

Description

some OSC procfs functions use osc_device which is lu_device. It must be linked with obd_device given not NULL obd->obd_lu_dev. It is done at the end of obd_setup() function. But procfs files are accessible before that because obd procfs data is initialized inside OSC o_setup. Solution can be artificial setting obd->obd_lu_dev to the osc_device inside osc_setup().

The same problem exists during obd_cleanup - first it free osc_device therefore obd->obd_lu_dev is NULL again but OBD procfs data is cleaned up after that in osc_cleanup(). Solution can be moving lprocfs_obd_cleanup to the precleanup function.

Comments

[Mikhail Pershin]

forgot to mention - this issue can be seen during test 57 from recovery-small. There is such code:

test_57_helper() {
        # no oscs means no client or mdt 
        while lctl get_param osc.*.* > /dev/null 2>&1; do
                : # loop until proc file is removed
        done
}

this scans OSC procfs data in cycle and may sneak to that window when obb_lu_dev is NULL

[Lai Siyao]

Hi Mike, I think LU-106 has covered this, and you're one of an inspector also.

[Mikhail Pershin]

Lai, yes, it will cover problems during umount, but it may exist during setup also. For example, in so OSC procfs functions use not obd_device but osc_device. It is taken from OBD throught obd->obd_lu_dev, the problem is that obd_setup() calls osc_init() before set obd_lu_dev, so there is short window when proc data is accessible but obd_lu_dev is NULL. I would suggest to set obd_lu_dev right inside osc_init() but not sure is it safe or not. Need to look at that code closely