Re: [PATCH 0/2] Introduce dns_interval procfs setting

[Paulo Alcantara <pc@cjr.nz>]

Enzo Matsumiya <ematsumiya@suse.de> writes:

> On 06/09, Paulo Alcantara wrote:
>>Enzo Matsumiya <ematsumiya@suse.de> writes:
>>
>>> Currently, key.dns_resolver uses getaddrinfo() to resolve names, which
>>> doesn't contain the TTL for the record, hence *always* returns 0 to cifs.ko.
>>> This patch is just a way to provide some flexibility to the user, in
>>> case they don't want to use the currently-always-fixed 600s.
>>
>>It is not limited to key.dns_resolver.  The user is free to choose
>>whatever program he/she wants to be upcalled for dns_resolver key.
>>
>>For instance, some distros might still be using cifs.upcall(8) that
>>actually set record TTL, thus making it impossible for the user to
>>change default via /proc/fs/cifs/dns_interval.
>
> Ah sorry, I misunderstood.
>
> But this patch isn't supposed to allow the user to change the _default_ TTL
> value, but only to give them a chance to change the TTL value *iff* the
> upcall returned 0.

That was my concern.  If we expose it to users, they would probably
expect it work at all times regardless whether the key's expire time was
set or not.

> In case the upcall returns TTL != 0, dns_resolve_server_name_to_ip()
> will use that value instead, which, again, maintains the current behaviour.

Then it would start ignoring values from /proc/fs/cifs/dns_interval and
not telling the user why.

> But yes, if desired, I can adjust the patch to completely ignore the
> TTL value from upcall and manage it by ourselves always, either by
> procfs or by mount option.

That would work, too.  BTW, I'd personally go with the mount option
version.