On 2012-05-28 19:52, Boaz Harrosh wrote:
> On 05/28/2012 07:09 PM, Benny Halevy wrote:
>
>> Signed-off-by: Benny Halevy <bhalevy@xxxxxxxxxx>
>> ---
>> fs/nfsd/Kconfig | 7 +++++++
>> fs/nfsd/pnfsd_lexp.c | 5 +++++
>> 2 files changed, 12 insertions(+), 0 deletions(-)
>>
>> diff --git a/fs/nfsd/Kconfig b/fs/nfsd/Kconfig
>> index 9d4d79b..f9b3426 100644
>> --- a/fs/nfsd/Kconfig
>> +++ b/fs/nfsd/Kconfig
>> @@ -132,3 +132,10 @@ config PNFSD_LEXP_LAYOUT_SEGMENT_SIZE
>> Set simulated layout segment size.
>>
>> If unsure, say N.
>> +
>> +config PNFSD_LEXP_RETURN_ON_CLOSE
>> + bool "Reply to LAYOUTGET with return_on_close set to true"
>> + depends on PNFSD_LOCAL_EXPORT
>> + default false
>> + help
>> + Set return_on_close response flag.
>> diff --git a/fs/nfsd/pnfsd_lexp.c b/fs/nfsd/pnfsd_lexp.c
>> index 30d9757..33a724c 100644
>> --- a/fs/nfsd/pnfsd_lexp.c
>> +++ b/fs/nfsd/pnfsd_lexp.c
>> @@ -153,6 +153,11 @@ static int get_stripe_unit(int blocksize)
>> res->lg_seg.offset = 0;
>> res->lg_seg.length = NFS4_MAX_UINT64;
>> #endif /* CONFIG_PNFSD_LEXP_LAYOUT_SEGMENTS */
>> +#ifdef CONFIG_PNFSD_LEXP_RETURN_ON_CLOSE
>> + res->lg_return_on_close = true;
>> +#else /* CONFIG_PNFSD_LEXP_RETURN_ON_CLOSE */
>> + res->lg_return_on_close = false;
>
>
> Back to my original question. With current code this case is a BUG.
> It will leak layouts and therefore file-reference in case of a layout-get
> with open-state ID.
>
> So I suggest hardcoding to true until such time that we actually can
> support it
so how will you debug the leak case?
pnfsd-lexp is for testing, and the default is on.
Benny
>
> Boaz
>
>> +#endif /* CONFIG_PNFSD_LEXP_RETURN_ON_CLOSE */
>>
>> layout = kzalloc(sizeof(*layout), GFP_KERNEL);
>> if (layout == NULL) {
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
