Re: [Nfs-ganesha-devel] assert() in mdcache_lru_clean()
> Yeah, probably.
>
> Daniel
>
> On 08/04/2017 10:55 AM, Pradeep wrote:
> > For the first export, saved_ctx will be NULL. So the assignment at
> > line 1161 makes op_ctx also NULL. So when mdcache_lru_unref() is
> > called, op_ctx will be NULL. This will cause the assert in
> > mdcache_lru_clean() abort.
> >
> > Perhaps we can move the assignment in line 1161 after
> mdcache_lru_unref() call?
That sounds like a good fix. The put_gsh_export(export); also needs to be
moved so there is a valid export reference for the mdcache_lru_unref() call.
Frank
> > On 8/4/17, Daniel Gryniewicz wrote:
> >> Yep. We save the old context, run our loop, and then restore the old
> >> context.
> >>
> >> On 08/04/2017 10:45 AM, Pradeep wrote:
> >>> Thanks Daniel. I see it being initialized. But then it is
> >>> overwritten from saved_ctx, right?
> >>>
> >>> https://github.com/nfs-ganesha/nfs-
> ganesha/blob/next/src/FSAL/Stacka
> >>> ble_FSALs/FSAL_MDCACHE/mdcache_lru.c#L1161
> >>>
> >>> On 8/4/17, Daniel Gryniewicz wrote:
> Here:
>
> https://github.com/nfs-ganesha/nfs-
> ganesha/blob/next/src/FSAL/Stack
> able_FSALs/FSAL_MDCACHE/mdcache_lru.c#L1127
>
> On 08/04/2017 10:36 AM, Pradeep wrote:
> > Hi Daniel,
> >
> > I could not find where op_ctx gets populated in lru_run_lane().
> > I'm using 2.5.1.
> >
> > https://github.com/nfs-ganesha/nfs-
> ganesha/blob/next/src/FSAL/Stac
> > kable_FSALs/FSAL_MDCACHE/mdcache_lru.c#L1019
> >
> > On 8/4/17, Daniel Gryniewicz wrote:
> >> It should be valid. lru_run_lane() sets up op_ctx, so it should
> >> be set correctly even in the LRU thread case.
> >>
> >> Daniel
> >>
> >> On 08/04/2017 09:54 AM, Pradeep wrote:
> >>> It looks like the assert() below and the comment in
> >>> mdcache_lru_clean() may not be valid in all cases. For example,
> >>> if cache is getting cleaned in the context of the LRU background
> >>> thread, the op_ctx will be NULL and the code may get into the
> >>> 'else' part
> >>> (lru_run() -> lru_run_lane() -> _mdcache_lru_unref() ->
> >>> mdcache_lru_clean()):
> >>>
> >>> Do any of the calls after the 'if-else' block use 'op_ctx'? If
> >>> those don't us 'op_ctx', the 'else' part can be safely removed,
right?
> >>>
> >>>if (export_id >= 0 && op_ctx != NULL &&
> >>> op_ctx->ctx_export != NULL &&
> >>> op_ctx->ctx_export->export_id !=
> >>> export_id) {
> >>> } else {
> >>> /* We MUST have a valid op_ctx based
> >>> on the conditions
> >>> * we could get here.
> >>> first_export_id coild be
> >>> -1
> >>> or it
> >>> * could match the current op_ctx
export.
> >>> In
> >>> either case
> >>> * we will trust the current op_ctx.
> >>> */
> >>> assert(op_ctx);
> >>> assert(op_ctx->ctx_export);
> >>> LogFullDebug(COMPONENT_CACHE_INODE,
> >>> "Trusting op_ctx export
> >>> id %"PRIu16,
> >>>
> >>> op_ctx->ctx_export->export_id);
> >>>
> >>>
> >>>
> >>> -- Check out the vibrant tech community on one of
> >>> the world's most engaging tech sites, Slashdot.org!
> >>> http://sdm.link/slashdot
> >>> ___
> >>> Nfs-ganesha-devel mailing list
> >>> Nfs-ganesha-devel@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
> >>>
> >>
> >>
> >> -
> >> - Check out the vibrant tech community on one of the
> >> world's most engaging tech sites, Slashdot.org!
> >> http://sdm.link/slashdot
> >> ___
> >> Nfs-ganesha-devel mailing list
> >> Nfs-ganesha-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
> >>
>
>
> >>
> >>
>
>
>
--
> Check out the vibrant tech community on one of the world's most engaging
> tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
-
Re: [Nfs-ganesha-devel] assert() in mdcache_lru_clean()
Yeah, probably.
Daniel
On 08/04/2017 10:55 AM, Pradeep wrote:
For the first export, saved_ctx will be NULL. So the assignment at
line 1161 makes op_ctx also NULL. So when mdcache_lru_unref() is
called, op_ctx will be NULL. This will cause the assert in
mdcache_lru_clean() abort.
Perhaps we can move the assignment in line 1161 after mdcache_lru_unref() call?
On 8/4/17, Daniel Gryniewicz wrote:
Yep. We save the old context, run our loop, and then restore the old
context.
On 08/04/2017 10:45 AM, Pradeep wrote:
Thanks Daniel. I see it being initialized. But then it is overwritten
from saved_ctx, right?
https://github.com/nfs-ganesha/nfs-ganesha/blob/next/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c#L1161
On 8/4/17, Daniel Gryniewicz wrote:
Here:
https://github.com/nfs-ganesha/nfs-ganesha/blob/next/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c#L1127
On 08/04/2017 10:36 AM, Pradeep wrote:
Hi Daniel,
I could not find where op_ctx gets populated in lru_run_lane(). I'm
using
2.5.1.
https://github.com/nfs-ganesha/nfs-ganesha/blob/next/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c#L1019
On 8/4/17, Daniel Gryniewicz wrote:
It should be valid. lru_run_lane() sets up op_ctx, so it should be
set
correctly even in the LRU thread case.
Daniel
On 08/04/2017 09:54 AM, Pradeep wrote:
It looks like the assert() below and the comment in
mdcache_lru_clean() may not be valid in all cases. For example, if
cache is getting cleaned in the context of the LRU background thread,
the op_ctx will be NULL and the code may get into the 'else' part
(lru_run() -> lru_run_lane() -> _mdcache_lru_unref() ->
mdcache_lru_clean()):
Do any of the calls after the 'if-else' block use 'op_ctx'? If those
don't us 'op_ctx', the 'else' part can be safely removed, right?
if (export_id >= 0 && op_ctx != NULL &&
op_ctx->ctx_export != NULL &&
op_ctx->ctx_export->export_id != export_id) {
} else {
/* We MUST have a valid op_ctx based on
the
conditions
* we could get here. first_export_id coild
be
-1
or it
* could match the current op_ctx export.
In
either case
* we will trust the current op_ctx.
*/
assert(op_ctx);
assert(op_ctx->ctx_export);
LogFullDebug(COMPONENT_CACHE_INODE,
"Trusting op_ctx export id
%"PRIu16,
op_ctx->ctx_export->export_id);
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
Re: [Nfs-ganesha-devel] assert() in mdcache_lru_clean()
For the first export, saved_ctx will be NULL. So the assignment at
line 1161 makes op_ctx also NULL. So when mdcache_lru_unref() is
called, op_ctx will be NULL. This will cause the assert in
mdcache_lru_clean() abort.
Perhaps we can move the assignment in line 1161 after mdcache_lru_unref() call?
On 8/4/17, Daniel Gryniewicz wrote:
> Yep. We save the old context, run our loop, and then restore the old
> context.
>
> On 08/04/2017 10:45 AM, Pradeep wrote:
>> Thanks Daniel. I see it being initialized. But then it is overwritten
>> from saved_ctx, right?
>>
>> https://github.com/nfs-ganesha/nfs-ganesha/blob/next/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c#L1161
>>
>> On 8/4/17, Daniel Gryniewicz wrote:
>>> Here:
>>>
>>> https://github.com/nfs-ganesha/nfs-ganesha/blob/next/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c#L1127
>>>
>>> On 08/04/2017 10:36 AM, Pradeep wrote:
Hi Daniel,
I could not find where op_ctx gets populated in lru_run_lane(). I'm
using
2.5.1.
https://github.com/nfs-ganesha/nfs-ganesha/blob/next/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c#L1019
On 8/4/17, Daniel Gryniewicz wrote:
> It should be valid. lru_run_lane() sets up op_ctx, so it should be
> set
> correctly even in the LRU thread case.
>
> Daniel
>
> On 08/04/2017 09:54 AM, Pradeep wrote:
>> It looks like the assert() below and the comment in
>> mdcache_lru_clean() may not be valid in all cases. For example, if
>> cache is getting cleaned in the context of the LRU background thread,
>> the op_ctx will be NULL and the code may get into the 'else' part
>> (lru_run() -> lru_run_lane() -> _mdcache_lru_unref() ->
>> mdcache_lru_clean()):
>>
>> Do any of the calls after the 'if-else' block use 'op_ctx'? If those
>> don't us 'op_ctx', the 'else' part can be safely removed, right?
>>
>> if (export_id >= 0 && op_ctx != NULL &&
>>op_ctx->ctx_export != NULL &&
>>op_ctx->ctx_export->export_id != export_id) {
>>
>>} else {
>>/* We MUST have a valid op_ctx based on
>> the
>> conditions
>> * we could get here. first_export_id coild
>> be
>> -1
>> or it
>> * could match the current op_ctx export.
>> In
>> either case
>> * we will trust the current op_ctx.
>> */
>>assert(op_ctx);
>>assert(op_ctx->ctx_export);
>>LogFullDebug(COMPONENT_CACHE_INODE,
>> "Trusting op_ctx export id
>> %"PRIu16,
>>
>> op_ctx->ctx_export->export_id);
>>
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Nfs-ganesha-devel mailing list
>> Nfs-ganesha-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>
>>>
>>>
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
Re: [Nfs-ganesha-devel] assert() in mdcache_lru_clean()
Yep. We save the old context, run our loop, and then restore the old
context.
On 08/04/2017 10:45 AM, Pradeep wrote:
Thanks Daniel. I see it being initialized. But then it is overwritten
from saved_ctx, right?
https://github.com/nfs-ganesha/nfs-ganesha/blob/next/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c#L1161
On 8/4/17, Daniel Gryniewicz wrote:
Here:
https://github.com/nfs-ganesha/nfs-ganesha/blob/next/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c#L1127
On 08/04/2017 10:36 AM, Pradeep wrote:
Hi Daniel,
I could not find where op_ctx gets populated in lru_run_lane(). I'm using
2.5.1.
https://github.com/nfs-ganesha/nfs-ganesha/blob/next/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c#L1019
On 8/4/17, Daniel Gryniewicz wrote:
It should be valid. lru_run_lane() sets up op_ctx, so it should be set
correctly even in the LRU thread case.
Daniel
On 08/04/2017 09:54 AM, Pradeep wrote:
It looks like the assert() below and the comment in
mdcache_lru_clean() may not be valid in all cases. For example, if
cache is getting cleaned in the context of the LRU background thread,
the op_ctx will be NULL and the code may get into the 'else' part
(lru_run() -> lru_run_lane() -> _mdcache_lru_unref() ->
mdcache_lru_clean()):
Do any of the calls after the 'if-else' block use 'op_ctx'? If those
don't us 'op_ctx', the 'else' part can be safely removed, right?
if (export_id >= 0 && op_ctx != NULL &&
op_ctx->ctx_export != NULL &&
op_ctx->ctx_export->export_id != export_id) {
} else {
/* We MUST have a valid op_ctx based on the
conditions
* we could get here. first_export_id coild be
-1
or it
* could match the current op_ctx export. In
either case
* we will trust the current op_ctx.
*/
assert(op_ctx);
assert(op_ctx->ctx_export);
LogFullDebug(COMPONENT_CACHE_INODE,
"Trusting op_ctx export id
%"PRIu16,
op_ctx->ctx_export->export_id);
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
Re: [Nfs-ganesha-devel] assert() in mdcache_lru_clean()
Thanks Daniel. I see it being initialized. But then it is overwritten
from saved_ctx, right?
https://github.com/nfs-ganesha/nfs-ganesha/blob/next/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c#L1161
On 8/4/17, Daniel Gryniewicz wrote:
> Here:
>
> https://github.com/nfs-ganesha/nfs-ganesha/blob/next/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c#L1127
>
> On 08/04/2017 10:36 AM, Pradeep wrote:
>> Hi Daniel,
>>
>> I could not find where op_ctx gets populated in lru_run_lane(). I'm using
>> 2.5.1.
>>
>> https://github.com/nfs-ganesha/nfs-ganesha/blob/next/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c#L1019
>>
>> On 8/4/17, Daniel Gryniewicz wrote:
>>> It should be valid. lru_run_lane() sets up op_ctx, so it should be set
>>> correctly even in the LRU thread case.
>>>
>>> Daniel
>>>
>>> On 08/04/2017 09:54 AM, Pradeep wrote:
It looks like the assert() below and the comment in
mdcache_lru_clean() may not be valid in all cases. For example, if
cache is getting cleaned in the context of the LRU background thread,
the op_ctx will be NULL and the code may get into the 'else' part
(lru_run() -> lru_run_lane() -> _mdcache_lru_unref() ->
mdcache_lru_clean()):
Do any of the calls after the 'if-else' block use 'op_ctx'? If those
don't us 'op_ctx', the 'else' part can be safely removed, right?
if (export_id >= 0 && op_ctx != NULL &&
op_ctx->ctx_export != NULL &&
op_ctx->ctx_export->export_id != export_id) {
} else {
/* We MUST have a valid op_ctx based on the
conditions
* we could get here. first_export_id coild be
-1
or it
* could match the current op_ctx export. In
either case
* we will trust the current op_ctx.
*/
assert(op_ctx);
assert(op_ctx->ctx_export);
LogFullDebug(COMPONENT_CACHE_INODE,
"Trusting op_ctx export id
%"PRIu16,
op_ctx->ctx_export->export_id);
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>>>
>>>
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> ___
>>> Nfs-ganesha-devel mailing list
>>> Nfs-ganesha-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>>>
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
Re: [Nfs-ganesha-devel] assert() in mdcache_lru_clean()
Here:
https://github.com/nfs-ganesha/nfs-ganesha/blob/next/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c#L1127
On 08/04/2017 10:36 AM, Pradeep wrote:
Hi Daniel,
I could not find where op_ctx gets populated in lru_run_lane(). I'm using 2.5.1.
https://github.com/nfs-ganesha/nfs-ganesha/blob/next/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c#L1019
On 8/4/17, Daniel Gryniewicz wrote:
It should be valid. lru_run_lane() sets up op_ctx, so it should be set
correctly even in the LRU thread case.
Daniel
On 08/04/2017 09:54 AM, Pradeep wrote:
It looks like the assert() below and the comment in
mdcache_lru_clean() may not be valid in all cases. For example, if
cache is getting cleaned in the context of the LRU background thread,
the op_ctx will be NULL and the code may get into the 'else' part
(lru_run() -> lru_run_lane() -> _mdcache_lru_unref() ->
mdcache_lru_clean()):
Do any of the calls after the 'if-else' block use 'op_ctx'? If those
don't us 'op_ctx', the 'else' part can be safely removed, right?
if (export_id >= 0 && op_ctx != NULL &&
op_ctx->ctx_export != NULL &&
op_ctx->ctx_export->export_id != export_id) {
} else {
/* We MUST have a valid op_ctx based on the
conditions
* we could get here. first_export_id coild be -1
or it
* could match the current op_ctx export. In
either case
* we will trust the current op_ctx.
*/
assert(op_ctx);
assert(op_ctx->ctx_export);
LogFullDebug(COMPONENT_CACHE_INODE,
"Trusting op_ctx export id
%"PRIu16,
op_ctx->ctx_export->export_id);
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
Re: [Nfs-ganesha-devel] assert() in mdcache_lru_clean()
Hi Daniel,
I could not find where op_ctx gets populated in lru_run_lane(). I'm using 2.5.1.
https://github.com/nfs-ganesha/nfs-ganesha/blob/next/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c#L1019
On 8/4/17, Daniel Gryniewicz wrote:
> It should be valid. lru_run_lane() sets up op_ctx, so it should be set
> correctly even in the LRU thread case.
>
> Daniel
>
> On 08/04/2017 09:54 AM, Pradeep wrote:
>> It looks like the assert() below and the comment in
>> mdcache_lru_clean() may not be valid in all cases. For example, if
>> cache is getting cleaned in the context of the LRU background thread,
>> the op_ctx will be NULL and the code may get into the 'else' part
>> (lru_run() -> lru_run_lane() -> _mdcache_lru_unref() ->
>> mdcache_lru_clean()):
>>
>> Do any of the calls after the 'if-else' block use 'op_ctx'? If those
>> don't us 'op_ctx', the 'else' part can be safely removed, right?
>>
>> if (export_id >= 0 && op_ctx != NULL &&
>> op_ctx->ctx_export != NULL &&
>> op_ctx->ctx_export->export_id != export_id) {
>>
>> } else {
>> /* We MUST have a valid op_ctx based on the
>> conditions
>> * we could get here. first_export_id coild be -1
>> or it
>> * could match the current op_ctx export. In
>> either case
>> * we will trust the current op_ctx.
>> */
>> assert(op_ctx);
>> assert(op_ctx->ctx_export);
>> LogFullDebug(COMPONENT_CACHE_INODE,
>> "Trusting op_ctx export id
>> %"PRIu16,
>> op_ctx->ctx_export->export_id);
>>
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Nfs-ganesha-devel mailing list
>> Nfs-ganesha-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
Re: [Nfs-ganesha-devel] assert() in mdcache_lru_clean()
It should be valid. lru_run_lane() sets up op_ctx, so it should be set
correctly even in the LRU thread case.
Daniel
On 08/04/2017 09:54 AM, Pradeep wrote:
It looks like the assert() below and the comment in
mdcache_lru_clean() may not be valid in all cases. For example, if
cache is getting cleaned in the context of the LRU background thread,
the op_ctx will be NULL and the code may get into the 'else' part
(lru_run() -> lru_run_lane() -> _mdcache_lru_unref() ->
mdcache_lru_clean()):
Do any of the calls after the 'if-else' block use 'op_ctx'? If those
don't us 'op_ctx', the 'else' part can be safely removed, right?
if (export_id >= 0 && op_ctx != NULL &&
op_ctx->ctx_export != NULL &&
op_ctx->ctx_export->export_id != export_id) {
} else {
/* We MUST have a valid op_ctx based on the conditions
* we could get here. first_export_id coild be -1 or it
* could match the current op_ctx export. In either
case
* we will trust the current op_ctx.
*/
assert(op_ctx);
assert(op_ctx->ctx_export);
LogFullDebug(COMPONENT_CACHE_INODE,
"Trusting op_ctx export id %"PRIu16,
op_ctx->ctx_export->export_id);
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
[Nfs-ganesha-devel] assert() in mdcache_lru_clean()
It looks like the assert() below and the comment in
mdcache_lru_clean() may not be valid in all cases. For example, if
cache is getting cleaned in the context of the LRU background thread,
the op_ctx will be NULL and the code may get into the 'else' part
(lru_run() -> lru_run_lane() -> _mdcache_lru_unref() ->
mdcache_lru_clean()):
Do any of the calls after the 'if-else' block use 'op_ctx'? If those
don't us 'op_ctx', the 'else' part can be safely removed, right?
if (export_id >= 0 && op_ctx != NULL &&
op_ctx->ctx_export != NULL &&
op_ctx->ctx_export->export_id != export_id) {
} else {
/* We MUST have a valid op_ctx based on the conditions
* we could get here. first_export_id coild be -1 or it
* could match the current op_ctx export. In either case
* we will trust the current op_ctx.
*/
assert(op_ctx);
assert(op_ctx->ctx_export);
LogFullDebug(COMPONENT_CACHE_INODE,
"Trusting op_ctx export id %"PRIu16,
op_ctx->ctx_export->export_id);
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
