Hi Al Viro,
Is there is reason we have kept data->found++, if the dentry already
there in shrink list ?
static enum d_walk_ret select_collect(
...
if (dentry->d_flags & DCACHE_SHRINK_LIST) {
data->found++;
} else {
..
If the dentry is already there on shrink list, does it not mean that
data->found is already non-zero ?
Can't we just go out from here directly?
Regards,
Mukesh
On Fri, Aug 17, 2018 at 03:39:22PM +0530, Mukesh Ojha wrote:
> Hi Al Viro,
>
> Is there is reason we have kept data->found++, if the dentry already there
> in shrink list ?
>
> static enum d_walk_ret select_collect(
> ...
> ??????? if (dentry->d_flags & DCACHE_SHRINK_LIST) {
> ??????????????? data->found++;
> ??????? } else {
> ? ..
>
> If the dentry is already there on shrink list, does it not mean that
> data->found is already non-zero ?
Nope. It can be on *another* shrink list - if two processes are doing
that...
> Can't we just go out from here directly?
On 8/17/2018 6:28 PM, Al Viro wrote:
> On Fri, Aug 17, 2018 at 03:39:22PM +0530, Mukesh Ojha wrote:
>> Hi Al Viro,
>>
>> Is there is reason we have kept data->found++, if the dentry already there
>> in shrink list ?
>>
>> static enum d_walk_ret select_collect(
>> ...
>> if (dentry->d_flags & DCACHE_SHRINK_LIST) {
>> data->found++;
>> } else {
>> ..
>>
>> If the dentry is already there on shrink list, does it not mean that
>> data->found is already non-zero ?
> Nope. It can be on *another* shrink list - if two processes are doing
> that...
Ok, if we go out simply, letting others to do the job will break
`shrink_dcache_parent()`
and if someone touched that dentry made the refcount > 0 while it is on
shrink list
then owner will keep on looping in shrink_dentry_list() until refcount
becomes 0 .
Am i making sense here ?
Thanks.
Mukesh
>
>> Can't we just go out from here directly?