From patchwork Tue Aug 3 17:24:53 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Layton X-Patchwork-Id: 60782 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 9CDC4B6F0E for ; Wed, 4 Aug 2010 03:25:09 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754753Ab0HCRZE (ORCPT ); Tue, 3 Aug 2010 13:25:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:28907 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751882Ab0HCRZB (ORCPT ); Tue, 3 Aug 2010 13:25:01 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o73HOtkx025823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Aug 2010 13:24:55 -0400 Received: from tlielax.poochiereds.net (vpn-10-142.rdu.redhat.com [10.11.10.142]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o73HOswG007324; Tue, 3 Aug 2010 13:24:55 -0400 Date: Tue, 3 Aug 2010 13:24:53 -0400 From: Jeff Layton To: linux-nfs@vger.kernel.org Cc: netdev@vger.kernel.org, bfields@fieldses.org Subject: sunrpc: what prevents an xprt from being freed before task_cleanup runs? Message-ID: <20100803132453.4fa18444@tlielax.poochiereds.net> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org We got a report recently about a panic in RHEL5 (2.6.18 based kernel). The problem appears to be that a task_cleanup workqueue job ran and got passed a pointer to an xprt that had been freed. The bug is here in case anyone is interested in the details: https://bugzilla.redhat.com/show_bug.cgi?id=611938 The situation seems to be pretty difficult to reproduce, but I don't see anything that's intended to ensure that this doesn't occur in RHEL5 or mainline. The task_cleanup workqueue job doesn't hold a reference to the xprt, and the job isn't canceled when the xprt is torn down. Bruce had a look and suggested that we may need something like the patch below (pasted in, so it probably won't apply correctly). I've tested a backported version of it on RHEL5 and it seems to work fine. Is it reasonable to cancel task_cleanup when destroying the xprt? Or, am I missing something that should prevent this situation in mainline (and perhaps isn't in RHEL5's kernel). Any help is appreciated... -----------------------------[snip]--------------------------------- -----------------------------[snip]--------------------------------- Thanks, diff --git a/net/sunrpc/xprt.c b/net/sunrpc/xprt.c index dcd0132..2a1f664 100644 --- a/net/sunrpc/xprt.c +++ b/net/sunrpc/xprt.c @@ -1129,6 +1129,7 @@ static void xprt_destroy(struct kref *kref) rpc_destroy_wait_queue(&xprt->sending); rpc_destroy_wait_queue(&xprt->resend); rpc_destroy_wait_queue(&xprt->backlog); + cancel_work_sync(&xprt->task_cleanup); /* * Tear down transport state and free the rpc_xprt */