6:21 a.m.
Hello,
On Wed, Jan 22, 2020 at 08:57:21AM -0500, Daniel Gryniewicz wrote:
On 1/20/20 4:31 PM, Pasi Kärkkäinen wrote:
>Hi,
>
>On Mon, Jan 20, 2020 at 10:49:13AM -0500, William Katcher wrote:
>> Pradeep,
>> I believe the fix went into 3.2.
>>
>Is there a plan to do v2.8.4? Would be nice to have this patch in 2.8.x aswell,
>as it fixes a crash / coredump.
Yes
Any thoughts about v2.8.4 release timeframe?
Thanks,
-- Pasi
>
> Daniel
>
> >
> >
> >-- Pasi
> >
> >> Bill
> >> On Fri, Jan 17, 2020 at 2:41 PM Pradeep
<[1]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 <[2]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