9:49 a.m.
Pradeep,
I believe the fix went into 3.2.
Bill
On Fri, Jan 17, 2020 at 2:41 PM Pradeep <pradeepthomas(a)gmail.com> wrote:
Hi Bill,
Do you know if there is a patch that fixes this core dump? I'm hitting the
same with 2.8.3.
Thanks,
Pradeep
On Mon, Dec 9, 2019 at 10:11 AM <katcherw(a)gmail.com> wrote:
> I think the bug is caused by the following:
>
> In nfs_dupreq_start, when the state is DUPREQ_START, the following code
> is entered:
>
> if (unlikely(dv->state == DUPREQ_START)) {
> status = DUPREQ_BEING_PROCESSED;
>
> Note that in this case req->rq_u1 is not assigned.
>
> Later, the caller of this routine, nfs_rpc_process_request, will check
> the status, and in the case of DUPREQ_BEING_PROCESSED will break out of the
> switch statement and jump to freeargs, which will call free_args and then
> nfs_dupreq_rele. Unfortunately, nfs_dupreq_rele is assuming that req->rq_u1
> points to a cache entry, but it was never assigned in this case, leading to
> dereferencing a null ptr. In 2.6, there was a check to see if res_nfs was
> assigned before calling nfs_dupreq_rele, but it appears that it was removed
> in 2.8 and later. The code should either check for req->rq_u1 or res_nfs.
>
> Although we noticed this bug in 2.8.2, from looking at the code it looks
> like it is also in the tip.
>
> Bill
> _______________________________________________
> Devel mailing list -- devel(a)lists.nfs-ganesha.org
> To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
>