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@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@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