[lustre-devel] [PATCH] staging: lustre: check result of register_shrinker

Dilger, Andreas andreas.dilger at intel.com
Mon Dec 4 16:50:25 PST 2017

On Dec 4, 2017, at 11:42, Aliaksei Karaliou <akaraliou.dev at gmail.com> wrote:
> On 12/04/2017 11:40 AM, Dan Carpenter wrote:
>> On Sun, Dec 03, 2017 at 07:59:07PM +0300, ak wrote:
>>> Thank you for your extensive comments.
>>> I've also thought about adding more protection into unregister_shrinker(),
>>> but not sure how to properly organize the patch set, because there will be
>>> three patches:
>>>     * change in mm/vmscan that adds protection and sanitizer.
>>>     * fixed change for Lustre driver
>>>     * there also two explicit usages of shrinker->nr_deferred in drivers -
>>>        good idea to fix too.
>>> All patches have different lists of maintainers, and second and third depend
>>> on first one. And I don't like to send them separately.
>>> So, I'm going to at least prepend this patch with mm/vmscan one.
>> Fix the style for the Lustre patch and resend.  Then patch
>> unregister_shrinker().  Then remove the checks.
>> The unregister_shrinker() changes seem like a good idea, but I haven't
>> really looked at it.  It might be more involved than it seems.
>> regards,
>> dan carpenter
> Thanks for the comments too.
> I'll send patch with accumulated fixes.
>>>  }
>>> diff --git a/drivers/staging/lustre/lustre/obdclass/lu_object.c b/drivers/staging/lustre/lustre/obdclass/lu_object.c
>>> index b938a3f9d50a..9e0256ca2079 100644
>>> --- a/drivers/staging/lustre/lustre/obdclass/lu_object.c
>>> +++ b/drivers/staging/lustre/lustre/obdclass/lu_object.c
>>> @@ -1951,7 +1951,7 @@ int lu_global_init(void)
>>>  	 * inode, one for ea. Unfortunately setting this high value results in
>>>  	 * lu_object/inode cache consuming all the memory.
>>>  	 */
>>> -	register_shrinker(&lu_site_shrinker);
>>> +	result = register_shrinker(&lu_site_shrinker);
>> There should be some error handling if the register fails. 
> Yeah, I think so, but it seems that it is out of scope of this patch.
> The whole negative branch in the mainline kernel looks broken (IMHO).
> In mainline Lustre's git there is a reworked version of upper function obdclass_init(),
> which at least calls lu_global_fini() before exiting `module_init` on further failure,
> but yeah, still lacks proper cleanup inside lu_global_initcall().
> I'll add one more patch in a patch-set so that maintainers may decide what to do with that.

I was looking at the lack of error handling as well, but then I wondered if the module_init() call returns an error, is module_exit() still called, or does the module not load at all in the error case?

Cheers, Andreas
Andreas Dilger
Lustre Principal Architect
Intel Corporation

More information about the lustre-devel mailing list