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