[LU-3319] Adapt to 3.10 upstream kernel proc_dir_entry change

• Type: Improvement
• Resolution: Fixed
• Priority: Minor
• Fix Version/s: Lustre 2.6.0
• Affects Version/s: Lustre 2.5.0
• Assignee: Lai Siyao
• Reporter: Peng Tao

Description

In kernel 3.10 merge window, there is an important change in procfs subsystem that hides all details of proc_dir_entry structure.

This affects Lustre in two ways. First is that the read_proc_t and write_proc_t members are now removed so Lustre has to be converted to use seq_file approach. The second one is that Lustre can no longer do child entry lookup inside lprocfs_srch.

With the private proc_dir_entry structure and related exported APIs, the only possible/safe way to do child lookup is through path walking. Each pde has a atomic counter that is initialized to 1. And remove_proc_entry will decrease the counter to 0 and the free the pde. The counter is only increased by procfs when the corresponding proc dentry is instantiated during path walk. And it is decreased when the proc inode is evicted. There is no way an external module can hold a ref count on the dentry thus a pde can go away at any time if remove_proc_entry is called on it.

Therefore, callers has to make sure that they don't use any removed pde directly. OTOH, Lustre saves its created pde and passes it around in many places. Later those pointers are used without any protection. Would it be a problem? The situation is true for pre-3.10 kernel as well because Lustre never holds references on proc_dir_entry.

The existence of LPROCFS_ENTRY_AND_CHECK() also seems confusing. It indicates that a pde may be already invalidated when accessed by Lustre. However, all callers of LPROCFS_ENTRY_AND_CHECK() are in fact part of pde->proc_fops, which is called in side of proc_reg_file_ops where pde is protected by pde->in_use counter (pde_users for older kernels). When pde->in_use is positive, there is no way a pde can be removed. So IMOH LPROCFS_ENTRY_AND_CHECK() seems unnecessary.

Also, it seems that _lprocfs_lock is to protect child pde insert/remove/search, whereas kernel already has proc_subdir_lock doing the same job. But lprocfs_srch is the only exception. If we can get rid of lprocfs_srch, I think we can get rid of _lprocfs_lock as well. Since 3.10 is still under development, we can make a patch to procfs exporting a search function and send it to upstream. In this way, lprocfs_srch can be removed.

Also, removing LPROCFS_ENTRY_AND_CHECK/_lprocfs_lock or not, we cannot dereference a removed pde directly. Is there any existing mechanism to make sure it doesn't happen? Many proc_dir_entry are created by Lustre and passed around without protection. It seems dangerous to me but since it is working so far, maybe I am missing something?

Issue Links

• is blocking: LU-3665 obdfilter-survey test_3a: unmount stuck in obd_exports_barrier()
• is related to: LU-4513 sanity test_220: prealloc_last_id: Found no match
• is related to: LU-4483 sanity test 133f: Panic
• is related to: LU-4510 Oops (use after free) in osp_prealloc_next_seq_seq_show
• is related to: LU-4678 obdfilter-survey repeated run causes crash on OST
• is related to: LU-5764 Crash of MDS on "apparent buffer overflow"
• is related to: LU-4511 proc_dir_entry 'lustre/osc' already registered
• is related to: LU-4532 Test failure on test suite sanity, subtest test_17n (remove_proc_entry: removing non-empty directory 'lustre/osc', leaking at least 'lustre-OST0007-osc-MDT0003')
• is related to: LU-5275 clean up technical debt for proc_dir_entry changes
• is related to: LU-4416 support for 3.12 linux kernel
• is related to: LU-3675 Support for linux 3.10 kernel