[PATCH v2 2/2] UBI: Make mtd parameter readable

[Richard Weinberger]

Am 10.01.2017 um 15:11 schrieb Andy Shevchenko:
> On Tue, 2017-01-10 at 14:54 +0100, Richard Weinberger wrote:
>> Am 10.01.2017 um 14:48 schrieb Andy Shevchenko:
>>>>> -module_param_call(mtd, ubi_mtd_param_parse, NULL, NULL, 000);
>>>>> +module_param_call(mtd, ubi_mtd_param_parse, NULL, NULL, 0400);
>>>> What is the use case?
>>>> AFAIKT the permissions are 000
>>>
>>> If it's not 0 in current case than you easily crash the kernel
>>> because
>>> parser will be gone at that time. This is fixed by patch 1.
>>
>> Before your changes it was non-issue, right? ;)
> 
> If annoying section mismatch is not an issue, then yes, correct.

Fixing the section mismatch is a good thing.

>>>>  because a parser is involved and to
>>>> "understand" the parameter,
>>>> a reader needs the ubi_mtd_param_parse() function.
>>>
>>> Are you implying that writer is a bot and reader is human being? 
>>> The use case is obvious (any security reasons are implied?) -- allow
>>> user to see what was written there in the first place.
>>
>> I'm asking for the use case, why is exposing this parameter to user
>> space
>> a good thing? Who will use it?
> 
> Any user. I like the idea to have initial string to be stored somewhere
> and visible (imagine the case when it's module and history is gone). It
> might be useful for debugging (okay, this case perhaps not anymore, but
> in general).
> 
>>> Permissions 0000 are error prone.
>>
>> Why?
> 
> Because of a trick is being used here.

You are not really the answering questions kind of guy? ;-)

> P.S. If you strongly against it I will give up, it doesn't cost my
> efforts anymore. That's why one of the possible "solution" is to put
> comment there for other brave guys.

I'm not at all against it, all I want to know why your patch improves the current
situation what it fixes.

Did you check? Do other drivers in the kernel that have a parser behind a non-trivial
module parameter also expose it to user space?

Thanks,
//richard