On Wed, Oct 31, 2018 at 1:26 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
> On Wed, Oct 31, 2018 at 2:19 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> My 'strict' patch did not try to deal with implicitly enabling redirect_dir
> Vivek posted a different patch to deal with that.
What I mean, is that sections of your patch dealing with the
redirect_dir conflict and sections of Vivek's patch dealing with
_enforce are completely unnecessary if we just define the rules of
implicit enable/disable between metacopy and redirect_dir.
>> config->redirect_mode = match_strdup(&args[0]);
>> if (!config->redirect_mode)
>> return -ENOMEM;
>> +
>> + /* "redirect_dir=off" implies "metacopy=off" */
>> + if (strcmp(config->redirect_mode, "off") == 0 ||
>> + strcmp(config->redirect_mode, "nofollow") == 0)
>> + config->metacopy = false;
>
> This look completely counter to the 'strict' behavior definition.
> If user specified metacopy=on, we are not allowed to end up with metacopy=off.
What about "metacopy=on,metacopy=off"?
What I'm saying is that "metacopy=on,redirect_dir=off" should be
exactly equivalent to the above, if taking the implicit disable rule
into account.
>> @@ -548,6 +553,12 @@ static int ovl_parse_opt(char *opt, stru
>>
>> case OPT_METACOPY_ON:
>> config->metacopy = true;
>> +
>> + /* "metacopy=on" implies "redirect_dir=on" */
>> + kfree(config->redirect_mode);
>> + config->redirect_mode = kstrdup("on", GFP_KERNEL);
>> + if (!config->redirect_mode)
>> + return -ENOMEM;
>> break;
>>
>
> Helper please. from my "deprecated upper fs" v1 patch:
Yeah, definitely want that one.
Thanks,
Miklos
